第4章: コンテキストエンジニアリング — 有限資源としてのコンテキスト

第3章で「会話配列がエージェントの状態そのもの」だと述べました。本章のテーマは、その配列に何を入れ、何を入れないか。 Anthropic はこれを「コンテキストエンジニアリング＝LLM推論の各ターンで、最適なトークン（情報）集合をキュレーション・維持するための戦略の集合」と定義します。 プロンプトエンジニアリング（指示文を書く）の自然な発展形であり、ハーネスエンジニアリングの本質はほぼここにあると言ってよいでしょう。

コンテキストは有限資源 — context rot

直感に反するかもしれませんが、コンテキストは多いほど良いわけではありません。 LLMは人間の限られたワーキングメモリと同様に「アテンション予算（attention budget）」を持ち、トークンを足すほどそれを消耗します。 原因は Transformer の構造にあります——n個のトークンは n² の対関係を生むため、コンテキストが長くなるほど、各トークンに払えるアテンションが薄く引き伸ばされるのです。

コンテキストの失敗モード

Drew Breunig は、長いコンテキストが壊れる典型的なパターンを整理しています。これらを知っておくと、エージェントの不可解な挙動を診断しやすくなります。

JIT取得 vs 事前取得

必要な情報をどうコンテキストに入れるか。ここに大きなトレードオフがあります。 従来型の RAG（事前取得） は、推論の前に関連データを埋め込み検索し、あらかじめコンテキストに前置きします。 対して JIT（Just-in-Time）取得＝エージェンティック検索 は、軽量な識別子（ファイルパス・保存済みクエリ・URL）だけを保持し、 エージェントが必要を認識した時点でツールとして動的にロードします。これは人間の認知に近く、「漸進的開示（progressive disclosure）」を可能にします。

graph TD
  Q[必要な情報の取得方式]
  Q --> R[事前取得 / RAG]
  Q --> J[JIT / エージェンティック検索]
  R --> R1[推論前に埋め込み検索し\nコンテキストに前置き]
  J --> J1[識別子だけ保持し\n必要時にツールで動的ロード]
  R1 --> R2[速い・静的だが\n文脈を汚しやすい]
  J1 --> J2[漸進的開示\n探索は遅いが文脈を節約]
  style Q fill:#3b82f6,stroke:#1d4ed8,color:#fff
  style R fill:#8b5cf6,stroke:#6d28d9,color:#fff
  style J fill:#f97316,stroke:#ea580c,color:#fff
  style R2 fill:#14b8a6,stroke:#0d9488,color:#fff
  style J2 fill:#14b8a6,stroke:#0d9488,color:#fff

実際の製品はハイブリッドです。Claude Code は CLAUDE.md のような重要情報は素朴に事前投入する一方、 ソースコードは glob / grep で実行時に必要なファイルだけを探索します。 第2章で見た SWE-agent が RAG（3.8%）からエージェント探索（12.5%）へ性能を伸ばしたのも、この発想の延長線上にあります。

コンパクション — 会話を畳む

ループが長くなり、コンテキストが上限に近づいたらどうするか。答えが コンパクション（compaction） です。 会話履歴をモデルに渡して最重要詳細を要約・圧縮し、その要約で新しいコンテキストウィンドウを再初期化します。 Claude Code はトークン使用がコンテキストウィンドウの概ね98%に達すると自動コンパクションを行い、 アーキテクチャ上の決定・未解決バグ・実装詳細を保持しつつ、冗長なツール出力を破棄し、圧縮後の要約＋直近アクセスした5ファイルで継続します。

メモリとノートテイキング

コンテキストウィンドウの外に情報を逃がす手もあります。構造化ノートテイキングは、 エージェントが定期的にメモをファイル等に書き出し、後で必要な分だけコンテキストに引き戻す技術です。 最小のオーバーヘッドで永続メモリを提供し、数十〜数千のツール呼び出しをまたいで失われがちな進捗や依存関係を追跡できます。 Anthropic の memory tool（セッションをまたいで知識ベースを構築）もこの系譜です。 「短期メモリ＝コンテキスト内の履歴」「長期メモリ＝外部に永続化し必要時に呼び戻す」という整理が、長時間タスクの成否を分けます。

プロンプトキャッシュ — ループの経済性

最後に、長いループを安く回すための前提技術が プロンプトキャッシュ です。 APIはプレフィックス（接頭辞）単位でキャッシュが効き、リクエスト先頭が過去のキャッシュと一致すれば再利用されます。 長いプロンプトでコストを最大90%、レイテンシを最大85%削減できるとされます。 そのため「システムプロンプトやツール定義など毎ターン同じ前置きを先頭に、変動部分は末尾に置く」のがハーネス設計の定石です。 第10章で見るコスト爆発の対策の一つでもあります。