コンテキストは有限で劣化する資源である#
LLM エージェントの回答品質は、渡されたコンテキスト量に比例しない。むしろ反比例する場面が多い。コンテキストは有限かつ劣化する資源として扱うのが、実運用での正しい前提。
コンテキスト量と品質の関係#
flowchart LR
S[短い<br/>コンテキスト] -->|品質が高い| Q1[高品質な応答]
M[中程度] -->|最適点| Q2[実用的な応答]
L[長い] -->|品質低下| Q3[ハルシネーション<br/>指示無視]
観察される事実#
- 長いセッションほど品質が落ちる: ハルシネーションや指示無視が増え、前のターンで決めたことが次のターンで覆る
- 指示予算には実効上限がある: システムプロンプトに書く指示は、体感で 100〜150 命令あたりから遵守率が急落する
- ツール定義もコンテキストを食う: MCP や関数ツールの定義がコンテキストの 10% を超えると、ツール選択の精度が下がる
- コンテキスト圧縮は情報を失う: 自動圧縮が走ると、重要な決定や前提が静かに消える
コンテキストの消費構造#
pie title コンテキスト消費の内訳（典型例）
"システムプロンプト" : 15
"MCP/ツール定義" : 10
"会話履歴" : 45
"添付ファイル" : 15
"出力予約領域" : 15比率は状況で変動するが、会話が長くなるほど「会話履歴」が全体を圧迫する。ツール定義やシステムプロンプトを減らすより、セッションを区切る方が効果的な局面が多い。
扱い方の原則#
- 使う分だけ積む: 関連 ADR・関連ファイルだけを作業開始時に読ませる。関係ないものは読ませない
- 索引と本体を分ける: システムプロンプトは索引（どこに何があるか）に徹し、詳細は必要時に参照する構造にする
- 外部永続化を前提にする: 重要な決定は MEMORY.md / ADR / TODO ファイル等に外出しし、コンテキストから逃がす
- セッションを区切る: 長く引っ張らず、1 セッション 1 目的で切り上げる。チェックポイントで明示的に終わらせる
- ハーネスで節約する仕組みを組み込む: タイムスタンプを動かさないようにする、ツール数を絞る等、キャッシュを活かす設計にする
影響する他のトピック#
- システムプロンプトの行数上限（パターン：「システムプロンプトを 200 行以上書く」）
- ADR 分離パターン（ケーススタディ：「CLAUDE.md 肥大化を ADR 分離で回復した事例」）
- セッションを跨いだ情報保持（Patterns の Context Compression Amnesia など）
コンテキストを「潤沢な作業領域」と誤解すると、ほぼ全ての設計判断がズレる。有限で劣化する資源として扱うのが出発点になる。