「コンテキストウィンドウ 200Kトークン」という仕様だけを見ると、たいていのコードベースを丸ごと入れられそうです。ところが実際にすべて入れると、応答品質は大きく低下します。
長いコンテキストでは、モデルが中間の内容を見落とす現象が複数の研究で確認されています。入れられることと、うまく使えることは別の問題です。
そこで生まれた概念がコンテキストエンジニアリングです。一言でいえば、有限のコンテキストウィンドウを予算として扱い、その時点で最も有効な情報だけを載せる設計手法です。
この記事では、なぜコンテキストが予算なのか、予算を節約する4つの戦略、そしてCLAUDE.mdのような常時ロードファイルの設計基準まで整理します。
まずは要点から見ていきましょう。
- コンテキストは大きいほどよいのではなく、関連性が高いほどよい。
- 戦略は大きく4つです。選択的ローディング、要約（圧縮）、分離、外部化（メモリ）。
- 常時ロードファイル（CLAUDE.mdなど）は「常に正しいこと」だけを含め、短く保ちます。
- ツールや指示書もコンテキストを消費します。登録してあるだけで使わないツールはコストです。
なぜ予算なのか、コンテキストのコスト構造
コンテキストウィンドウには3種類のコストが同時にかかります。
1つ目は性能コストです。無関係な内容が多いほど、モデルの注意が分散します。特に長いコンテキストの中間部分は想起率が下がる「lost in the middle」現象が知られています。
2つ目は金銭的コストです。入力トークンはリクエストごとに課金されます。会話が長くなるほど、同じ内容が繰り返し課金されます。
3つ目は機会費用です。不要な情報が占める分だけ、本当に必要なコードやドキュメントを入れる余地が失われます。
コンテキストエンジニアリングの視点の転換はこれです。「どれだけ入れられるか」ではなく、「このトークンは今ここに置く価値があるか」を問います。
戦略1・2、選択的ローディングと要約
選択的ローディング（retrieval）は、必要なときに必要なものだけを取得する戦略です。2,000行のファイルをすべて読む代わりに関連する関数だけを読み、文書全体ではなく検索で該当箇所だけを取得します。
Skillの段階的ローディング（通常は1行の説明だけを表示し、実行時に本文をロードする）も同じ原理です。
要約（compaction）は蓄積した履歴を圧縮します。何十回ものツール呼び出し履歴を、「これらのファイルを修正し、テストに合格した」という1段落にまとめるのです。
コーディングエージェントが会話が長くなると自動的に行う、あの圧縮です。
要約には情報の損失が伴うことだけ覚えておいてください。詳細が折り畳まれて消える可能性があるため、重要な決定事項は要約前にファイルへ書き出しておくと安全です。
戦略3・4、分離と外部化
分離（isolation）は、コンテキストを乱す作業を別セッションに切り出す戦略です。大規模な探索をサブエージェントに任せれば、ファイルダンプはそのコンテキストで消費され、メインには結論数行だけが戻ります。
メインセッションの予算を守る最も確実な方法です。
外部化（memory）はコンテキスト外のストレージを使います。セッションが終わるとコンテキストは消えますが、ファイルに書いた内容は残ります。
作業状態をMarkdownに記録し、次のセッションが引き継ぐパターンが代表例です。プロジェクト知識をCLAUDE.mdやメモリファイルに蓄積するパターンもこれに当たります。
| 戦略 | 一言でいうと | 代表例 |
|---|---|---|
| 選択的ローディング | 必要なときだけ取得する | 部分読み、Skillの段階的ローディング |
| 要約 | 履歴を折り畳む | 自動コンパクション |
| 分離 | 別セッションに任せる | サブエージェント |
| 外部化 | ファイルに書いておく | メモリファイル、状態ドキュメント |
常時ロードファイルの設計基準
CLAUDE.mdのようなファイルは、毎セッションの予算から先に差し引かれる固定費です。だからこそ基準を明確にする必要があります。
含めるのは「常に正しく、破ってはいけないこと」です。コーディング規約、禁止事項、ビルドコマンドなどが該当します。
外すのは「たまにしか必要ないこと」です。特定作業の詳細な手順はSkillへ、過去の作業記録はメモリファイルへ移すのが適切です。
ツールの登録にも同じ論理が当てはまります。MCP（Model Context Protocol）サーバーを接続するほど、ツール定義が固定費として積み上がります。
使っていないサーバーが10個あるだけでも、性能低下の要因になります。定期的に整理する価値があります。
まとめ
コンテキストエンジニアリングは、結局のところ関連性の管理です。大きなウィンドウができたからといってすべて埋めるのではなく、その瞬間に作業に関係するものだけをモデルの机の上に置きます。
ハーネスエンジニアリング編で扱った実行ループと、この記事の予算管理を組み合わせると、エージェント設計の全体像が完成します。次回は、これらを実際に組み立てたパイプラインの事例を扱います。