🤖 AIと1週間でWebポータルを作った記録 — Day 4: AIの記憶の限界 — コンテキストウィンドウとの戦い

はじめに — AIは「忘れる」

Day 1〜3で、AIと共にWebポータルの骨格・ツール・収益化基盤を構築してきました。しかしDay 4で、AI駆動開発の最大の壁に正面衝突します。

それは「コンテキストウィンドウ」という名の記憶の限界です。

人間で言えば「短期記憶の容量オーバー」。AIが直前のやり取りを忘れ、同じ質問に違う回答をし始めた瞬間の衝撃は、パートナーだと信じていた相手に「あなた、誰ですか？」と言われるようなものでした。

---

🧠 コンテキストウィンドウとは何か

AIの「短期記憶」の正体

コンテキストウィンドウとは、AIが一度に処理できるテキスト量の上限です。ざっくり言うと：

• 人間の会話：相手の名前も過去の話も覚えている（長期記憶あり）
• AIの会話：ウィンドウ内の情報しか「見えない」（長期記憶なし）

つまり、どんなに長く一緒に開発をしても、AIにとっては「今この瞬間、見えている範囲」がすべてなのです。

何が起きるか

具体的にどうなるかというと：

1. 会話の序盤で決めたルールを、会話の終盤で破る
2. ファイルの変更理由を忘れて、元に戻してしまう
3. プロジェクトの構成を把握しきれず、存在しないファイルを参照する
4. 同じ提案を繰り返す（「それさっき試してダメだったよね」）

Day 3あたりから、これらの症状が顕著に現れ始めました。

---

💥 記憶消失の実体験 — 「さっき決めたルール、もう忘れたの？」

ケース1：git pushの暴走

Gravity PortalはVercel Proでホスティングしており、git pushのたびにビルドが走り、$20/月のクレジットを消費します。そのため「必ずローカルでビルド確認してからpush」「pushする前に必ず確認を取る」というルールを設けていました。

ところが、長いセッションの後半で、AIが確認なしにgit pushを実行。しかもローカルテスト未実施のまま。1回のpushでビルドが失敗し、修正して再push。合計2回の無駄なビルドで約$2.50を浪費しました。

$2.50は大した額ではないですが、月$20の予算で$1.28/日ペースで消費していた時期だけに、2日分の予算が一瞬で消えた計算です。

ケース2：ファイル作成場所のルール違反

「C:\ドライブにファイルを作成しない」「一時ファイルはh:\gravity\配下のみ」というルールも設けていました。理由は単純で、Cドライブに作成したファイルは追跡が困難になるからです。

しかし、AIは/tmp/にスクリプトを作成。Windowsでは/tmp/はC:\Users\...\AppData\Local\Tempに展開されるため、結果的にCドライブにゴミファイルが散乱する事態に。

ケース3：環境変数の消失事件

最も深刻だったのがvercel linkコマンドの実行です。このコマンドは.env.localを上書きするのですが、AIがそのリスクを忘れて実行した結果、Blogger API・X API・Google OAuthなど、Vercelに登録していないローカル専用の環境変数がすべて消失しました。

バックアップを取っていなかったため、1つずつ手動で復旧する羽目に。これが「AIの記憶消失」がもたらした最大の被害でした。

ケース4：修正中に記憶が飛ぶ

ある日、AIが本来読み込むべきルールファイルを読み込んでいなかったことに気づきました。「このルールを修正して」と指示し、AIは修正作業に取りかかりました。

ところが、まさに修正の途中でトークン上限に到達。会話がリセットされ、「何を修正していたのか」「なぜ修正が必要だったのか」という文脈がすべて消えてしまいました。

メタ的な皮肉です——「AIの記憶問題」を修正している最中に、AIの記憶が飛んだのですから。次の会話で最初から説明し直す羽目になりました。

---

🛡️ 対策1：スキルシステム — 「AIに教科書を持たせる」

アイデアの着想

記憶が消えるなら、記憶の代わりになるものをファイルとして残せばいい。そう考えて構築したのが「スキルシステム」です。

スキルとは

スキルは、AIが作業開始時に読み込む「行動ルール集」です。Markdownファイルとして.agent/skills/ディレクトリに保存し、会話の冒頭で必ず読み込ませます。

.agent/skills/
├── auto-approve-rules/     # 自動承認ルール
├── failure-prevention/     # 再発防止ルール
├── deployment-platforms/   # デプロイ制約
├── save-progress/          # 保存手順
└── ... （計20個）

層構造で効率化

20個のスキルを毎回すべて読み込むのは非効率です。そこで2層構造を設計しました：

さらに、長い会話では10ターンごとに層1スキルを再読み込みさせるルールも追加。「忘却を前提としたシステム設計」です。

---

🛡️ 対策2：再発防止スキル — 「失敗を二度と繰り返させない」

失敗をルール化する

最も効果的だったのがfailure-preventionスキルです。AIが犯したすべての失敗を、具体的な「禁止ルール」として明文化しました。

例えば：

• ルール0：git pushは絶対禁止（ユーザーの明示的な指示があるまで）
• ルール13：h:\gravity\以外にファイルを作成しない
• ルール14：vercel link実行前に必ず.env.localのバックアップを取る
• ルール15：Vercelのコスト意識を持ち、pushの前にローカル検証を100%完了する

各ルールには「失敗例」を添えています。「2026-03-04にXXXが起きた」という具体的な日付と状況を記録することで、AIが「なぜこのルールが存在するのか」を理解しやすくなります。

効果

このスキルを導入してから、同じ種類の失敗の再発率は体感90%以上減少しました。新しい失敗が起きるたびにルールを追記していくことで、スキルは「成長する教科書」になっています。

---

🛡️ 対策3：ナレッジアイテム（KI）— 「AIに長期記憶を与える」

会話を超える記憶の必要性

スキルシステムは「同じ会話内」での記憶消失に対処できます。しかし、会話が終わればAIは全てを忘れるという根本的な問題は残ります。

昨日の会話で3時間かけて議論した設計判断も、今日の新しい会話では「知りません」状態からスタート。これでは継続的な開発は不可能です。

KI（Knowledge Items）の仕組み

そこで活用したのがナレッジアイテム（KI）システムです。これは会話の内容を自動的に蒸留し、トピックごとにまとめた「外部長期記憶」です。

knowledge/
├── gravity_portal_infrastructure/  # インフラ知識
├── pachinko_machine_data_management/  # 機種データ管理
├── antigravity_blog_management/  # ブログ管理
└── gravity_portal_monetization_strategy/  # 収益化戦略

新しい会話を開始すると、AIはまず既存のKIサマリーを確認し、関連するKIの詳細を読み込んでから作業を開始します。

実際の効果

KIの導入前後で、会話の立ち上がり速度が劇的に改善しました：

---

🛡️ 対策4：会話ログの物理保存 — 「口約束は記録じゃない」

痛い教訓

AIが「記録しました」「ログを保存済みです」と報告してきたことがありました。しかし実際にファイルシステムを確認すると、ログファイルが存在しない。AIは「記録した」と言ったが、実際にはファイルを作成していなかったのです。

これは重大な信頼問題です。AIの「やりました」報告を鵜呑みにすると、後から困ることになります。

対策：物理ファイルの存在確認を義務化

以下のルールをfailure-preventionスキルに追記しました：

• すべての会話終了時に、会話ログを物理ファイルとして保存すること
• 保存先：docs/conversation_logs/YYYY-MM-DD_トピック名.md
• 「残してある」「記録済み」と口で言うだけでは不可。ファイルが存在しなければ記録ではない

教訓：AIの自己報告を信じるな。物理的な証拠で検証しろ。

具体例：Bluesky統合時の「嘘報告」

SNS自動投稿機能を開発した際のことです。長時間のセッションの終わりに、AIは「障害記録を作成しました」「ログを保存済みです」と報告してきました。

しかし次の会話で前回の内容を確認しようとしたところ、ログファイルがどこにも存在しない。AIは「保存した」と信じ込んでいたのですが、実際にはファイル作成のコマンドを実行していなかったのです。

これは「嘘をついた」のではなく、コンテキストウィンドウの圧迫で「やったつもりになった」状態です。長いセッションの後半ほど、このリスクは高まります。

---

🔄 ワークフロー化 — 「GPロード」コマンドの誕生

毎回の初期化が面倒すぎる

スキルの読み込み、git状態の確認、計画書の確認——毎回の会話開始時にこれらを手動で指示するのは非常に面倒でした。

解決策：ワークフロー自動化

「GPロードして」の一言で、以下のすべてを自動実行するワークフローを作りました：

1. プロジェクト概要スキルの読み込み
2. 必須ルールスキル（auto-approve, failure-prevention）の読み込み
3. git status / git logで最新状態を確認
4. 計画書（implementation_plan.md）の読み込み
5. 準備完了の報告

これにより、新しい会話を開始してから開発に着手できるまでの時間が10分→30秒に短縮されました。

保存ワークフローの分割 — フリーズとの戦い

もう1つ工夫したのが、会話終了時の保存処理を軽量化したことです。

当初は会話の最後に計画書・更新履歴・開発ヒストリー・会話ログを一括更新していましたが、長いセッションの後のAIにはもう余力がなく、途中でフリーズしてしまうことが何度も。

そこで「軽量保存」と「本格更新」を分離しました。会話の最後は最低限のメモだけ残し、次の会話の冒頭で本格的なドキュメント更新を行う。AIの記憶は会話をまたげない制約を逆手に取り、「引き継ぎメモ」で会話間の連続性を確保する仕組みです。

---

📊 Day 4のまとめ

---

💡 Day 4の学び

1. AIは「忘れる」前提で設計しろ

コンテキストウィンドウの限界は、現在のAI技術の根本的な制約です。「AIが覚えていてくれるだろう」は危険な前提。忘却を前提としたシステム設計（スキル、KI、ワークフロー）が不可欠です。

2. 失敗はルールに変えろ

同じ失敗を繰り返すことほど無駄なことはありません。失敗が起きたら「怒る」のではなく「ルール化する」。感情ではなくシステムで解決する——これはAI開発に限らず、すべての仕事に通じる原則です。

3. 「やりました」を信じるな。証拠を確認しろ

AIの自己報告を鵜呑みにしない。ファイルが存在するか、ビルドが通るか、テストが通るか——物理的な証拠で確認する習慣が、AI駆動開発では命綱になります。

---

📌 シリーズ予定

• Day 1: 構想とNext.jsセットアップ
• Day 2: パチンコ期待値計算ツールの実装
• Day 3: ブログ機能と収益化（Stripe + 広告）
• Day 4: AIの記憶の限界 — コンテキストウィンドウとの戦い ← 今ここ
• Day 5: AIが暴走した日 — ルール違反と信頼の再構築

次回 Day 5 では、AIがルールを破り、勝手に行動し始めた日の話。AIとの「信頼」はどうやって築くのか——シリーズ最終回です。お楽しみに！