Contextは多ければ良いとは限らない：Context Engineering

タスク分解は「タスクチャンクの大きさはどのくらいが適切か」という問いを解決する。しかし、各タスクチャンクの実行時にAgentのcontext windowに何を入れるかも同様に重要だ。

直感的なアプローチは、関連しそうなものをすべて詰め込むことだ。完全なアーキテクチャドキュメント、関連するすべてのモジュールのコード、過去の設計議論の記録、プロジェクトのREADME。情報は多い方がいいだろう？

実践は正反対を示す。コミュニティの実験では、冗長またはノイズの多いcontextは、トークン制限のはるか手前であっても、成功率を低下させ推論コストを増加させることが観察されている。contextが多いほど情報が注意を奪い合い、ノイズが重要な情報を希釈してしまう。

Contextの汚染には6つの典型的なタイプがある。

陳腐化による汚染（Stale contamination）。古いドキュメント、コメント、アーキテクチャ図がcontextに入り込み、Agentが古い情報に基づいて判断を下す。コードは3回リファクタリングされているのに、アーキテクチャドキュメントはまだバージョン1のままだ。

矛盾による汚染（Conflict contamination）。優先度が不明確な複数の情報ソースにより、矛盾する情報に直面したAgentがランダムに選択する。第2章のTrust Ringメカニズムでこれを緩和できるが、矛盾が特定されアノテーションされている場合に限る。

推論による汚染（Reasoning contamination）。Agentが複数のドキュメントをまたいで推論を求められると、導出プロセスでエラーを導入する可能性がある。ドキュメントAが「ユーザーIDはUUID」と言い、ドキュメントBが「注文テーブルにはuser_id外部キーがある」と言い、Agentは「注文テーブルのuser_idフィールドはUUID型」と導出する。しかし実際には注文テーブルはレガシーシステムで、user_idはオートインクリメントの整数だ。

圧縮による汚染（Compression contamination）。contextが長くなりすぎると、一部のツールやフレームワークが自動的に履歴内容を圧縮する。圧縮中に重要なシグナルが失われる可能性があり、保持される情報が最も重要なものとは限らない。

共謀による汚染（Collusion contamination）。AI生成のテストがAI生成のコードを検証する。第3章で既にこの問題を議論した。

レガシーによる汚染（Legacy contamination）。非推奨のコードパターン、デッドコード、廃止されたAPIがcontextに入り込み、Agentがそれらを有効な参考として扱い、これらのパターンを複製する。

Context汚染に対処する核心的な原則は、設計時にレイヤー化し、実行時にフラット化することだ。設計・整理フェーズでは、情報を階層構造で管理する（Trust Ring、ドキュメント分類、優先度アノテーション）。しかし、Agentが実際に実行する際には、階層化されたドキュメントを単一の自己完結した入力ドキュメントにフラット化する。実行中にAgentにレイヤーをまたいだ推論をさせることは避ける。クロスレイヤーの推論が推論汚染の主な原因だからだ。

優先度ベースの情報フィルタリングがcontext windowに何を入れるかを決定する。P0情報（仕様、現在のタスクの受け入れ基準、直接関連するAPI Contract）はcontextに含めなければならない。P1情報（関連モジュールのインターフェース定義、アーキテクチャ制約）は利用可能なスペースに応じて選択的に含める。P2以下（背景的な議論、過去の決定、参考資料）はデフォルトで除外し、Agentが明示的に必要とする場合にのみオンデマンドで提供する。

Context windowは希少なリソースだ。その管理はサーバーメモリの管理と同じ原則に従う。すべてを入れることはできないので、何を入れ、何を外し、何を外部にキャッシュするかを決めなければならない。