【AIコーディング300回超】みんながハマる「コンテキスト管理」の落とし穴と脱出術

AIを使って開発するなら、コンテキスト管理は「あると嬉しい機能」なんかじゃない。マジで最重要な攻略ポイントだ。

多くの人がアウトプットの質を落とすのは、モデルが悪いからじゃなくて、コンテキストがぐちゃぐちゃだからなんだよね。

GPT-5-codexと連日徹夜セッション（マジで脳が溶けるかと思った）を繰り返した結果、ようやくワークフローが崩壊しなくなった方法がこれだ！

1. チャットは短く、範囲を絞る
チャットスレッドが長くなったら、新しいのを作ってくれ。マジで。コンテキストウィンドウはすぐにいっぱいになる。そうなると、GPTはパターン、ファイル名、ロジックフローを忘れ始める。それに気づいたら、新しいチャットを開いて、どこまでやったかを要約するんだ。「チェックアウトページを作成中。主なファイルはcheckout.tsx、cartContext.ts、api/order.ts。ここから続けて。」

毎回リポジトリ全体をダンプするな。関連ファイルだけを共有しろ。コンテキスト圧縮はマジ重要。

2. 「instructions」または「context」フォルダを使う
コンポーネントの例、ファイル構造、規約、命名規則、AIへの指示など、必要なドキュメントをすべて格納するフォルダ（MarkdownファイルでOK）を作成する。新しいセッションを開始するときは、このフォルダから関連するドキュメントをAIに読み込ませる。これが、セッションを超えて持ち運び可能なコンテキストメモリになる。

3. 以前のコンポーネントを活用して一貫性を保つ
AIは暴走しがち。固定しないと、UI全体を再設計し始める。新しい部分を作成するときは、すでに記述した古いコンポーネントについて言及する。「スタイリングの一貫性のために、ProductCard.tsxと同じ構造を使用する。」基本的には、持ち運び可能な脳として機能する。

4. 「AIのよくある間違い」ファイルを管理する
バカみたいに聞こえるかもしれないけど、AIが繰り返す間違い（hooksの名前を間違える、env configを書き換えるなど）をすべてリストアップしたファイルを作る。新しいプロンプトを開始するときは、「commonMistakes.mdを参照して、それらの繰り返しを避けてください」のような簡単な行を追加する。精度がマジで向上する。

5. 大量のドキュメントには外部サマライザーを使用する
破壊的な変更でいっぱいの新しいライブラリを取り込む場合は、ドキュメント全体をコンテキストに貼り付けない。代わりに、GPT-5-codexの「deep research」モード（またはperplexity、context7など）を使用して、短い「新機能+例」の要約ドキュメントを生成する。これにより、モデルはシャープな状態を保ち、コンテキストはクリーンな状態を保つ。

6. セッションログを作成する
session_log.mdファイルを作成する。新しいチャットを開くたびに、次のように書く。

• 現在の機能：「決済連携」
• 関連ファイル：PaymentAPI.ts、StripeClient.tsx
• 前回のAIの行動：「webhookを追加。保留中のエラー修正」

この小さな塊を新しいスレッドごとに貼り付けるだけで、GPTにインスタントメモリを与えているようなものだ。正直、ほとんどの場合、組み込みのメモリウィンドウよりも効果がある。

7. メタレビューでAIの出力を検証する
主要な機能を完了したら、コードをコピーしてクリーンなチャットに貼り付け、GPT-5-codexに次のように指示する。「このコードをレビューするシニア開発者として振る舞ってください。弱いパターン、欠落している最適化、または論理的なずれを特定してください。」これにより、コンテキストがリセットされ、以前のスレッドからのバイアスが削除され、長いセッションの後に発生しがちなずれをキャッチできる。

8. アーキテクチャの決定を早期に伝える
特定のパターン（zustand、shadcn、monorepoなど）を使用している場合は、新しいチャットごとに早い段階でそれを伝える。AIは、あなたが実際にアーキテクチャを持っていることを思い出させない限り、あなたのアーキテクチャに従わない。

これが役に立てば幸いです。

追記：関心が高かったため、これについてさらに詳しく書きました。https://gigamind.dev/blog/ai-code-degradation-context-management

その「よくある間違い」ファイルをくれ。

マジか、これ意外と悪くないな。タイトルからして、もっとクソみたいな内容かと思ってた。

めっちゃ分かりやすい解説ありがとう。

俺も似たようなことやってるんだけど、ちょっと構成が違ってて。
.cursorrules ファイル1個じゃなくて、各プロジェクトのルートに .cursor/rules/ ってフォルダを作って、そこに10〜15個くらいの小さい .mdc ルールファイルを置いてるんだ。

AIがミスるたびに、それを指摘して、修正版を書き直させて、それを新しいルールファイルにしてる。
バックオフィス、フロントエンド、モバイルアプリ、Supabaseのリポジトリ全体で一貫性を保つのにめっちゃ役立ってる。

でも、同じような問題に遭遇してないかな？
小さいルールファイルがたくさんあると、特に大きいプロジェクトだとコンテキストウィンドウの使用量がかなり増える気がするんだよね。
Cursorはちゃんと認識してるけど、長期的な戦略として一番効率的なのかどうか疑問。

ルールを1つのファイルで管理してる？それとも、俺みたいに分割してる？
コンテキストの重みをどう扱ってるか、何かトレードオフに気づいたことがあれば教えてほしいな。

マジでその通り！時間かけてちゃんとやったね。コンテキストを絞って、一発のプロンプトで完璧を求めない。あと、メタレビューのプロンプトが最高！毎日使わせてもらってるよ！

俺は「LLMジャッジ」プロンプトを使って、めっちゃいいフィードバックをもらってる。君のメタレビュープロンプトと似たような感じだけど、俺のはもう少し長いかな。ナイス投稿！

良いアドバイス。

モデルが悪いからじゃなくて、

どうしてもそのパターンが見えちゃうんだよな。

素晴らしいアドバイス。常にplan modeを使うべし！！！

これはいいね、シェアありがとう。俺の場合は、Windsor aiみたいなETLツールからMCPサーバーを使って、Claudeにデータソースへの自動アクセスを提供してるよ。データ構造とか現在のメトリクスを覚えてくれるんだ。セッションログみたいなもんだけど、自分で更新してくれるんだよね。