このウィキがエージェントとそのコンテキストについて持つページ群は、1 つの前提を共有している。推論時に言語モデルが利用できるコンテキストは、満たすべき容器ではなく、限界収益が逓減する有限の資源だという前提である。このページはそのページ群への入口である。この領域がどこから始まるのか、なぜその制約が存在するとされるのか、何がウィンドウを埋めるのか、タスクがウィンドウに収まらなくなったときにセッション内とセッションをまたいで何がなされるのか、そしてこの領域が拠って立つ説明がどこから来ているのかを示す。
領域の出発点
入口は コンテキストエンジニアリング である。このページは、推論中にモデルのコンテキストウィンドウを占める情報をキュレーションし、動的に管理する実践を名指すものであり、その実践についての異なる説明を並べて集めたページでもある。そこには、各説明がこの実践を プロンプトエンジニアリング に対してどう位置づけるかも含まれる。すなわち、その自然な発展とみなすか、それとは根本的に異なるものとみなすか、それを部分集合として包含するものとみなすかである。その「When It Applies」節は、この領域が拠って立つ前提を述べている。この実践は、コンテキストが限界収益の逓減する有限の資源であることを前提としており、その根拠を特定のウィンドウサイズではなく、コンテキストロットとアテンション予算という捉え方に置いている。
なぜウィンドウが希少なものとして扱われるのか
この制約を支える論拠は、経験的なページと説明的なページが担っている。
- コンテキストロット は経験的な側面である。コンテキスト内の情報を想起するモデルの能力は、トークン数が増えるにつれて低下する。Anthropic はこの概念を「干し草の山から針を探す」（needle-in-a-haystack）型のベンチマークに由来するものとし、その効果を急な崖ではなく性能の勾配として説明している。
- アテンション予算 は説明的な側面である。これは、アテンションを追加のトークンごとに目減りしていく有限のプールとみなす Anthropic の捉え方であり、Anthropic はその原因を、Transformer のアテンションがトークン間に生み出すペアワイズの関係、短い系列のほうが一般的な訓練データの分布、そしてコンテキスト長を拡張する手法が伴う精度上のコストに求めている。
LLM エージェントにおける外部化：メモリ、スキル、プロトコル、ハーネスエンジニアリングの統一的レビュー は、アテンションの偏りと並ぶ第二の理由を加える。コンテキストは一時的なものであり、状態を別の場所に外部化しない限り、新しいセッションは毎回部分的な記憶喪失の状態から始まる。長時間稼働エージェント は、有限のコンテキスト、永続的な状態の欠如、自己検証の欠如をまとめて、通常のエージェント設計が数時間から数日にわたって機能しなくなる障害として挙げている。
解決策としてのより大きなウィンドウ
複数のページが、ウィンドウを大きくしても問題はなくならないという立場を、それぞれ独自の根拠から記録している。コンテキストロット と コンテキストエンジニアリング は、あらゆるサイズのウィンドウがコンテキスト汚染と情報の関連性の問題にさらされ続けるという Anthropic の議論を載せている。LLM エージェントにおける外部化：メモリ、スキル、プロトコル、ハーネスエンジニアリングの統一的レビュー は「Lost in the Middle」の知見を引きつつ、ウィンドウを拡張しても根底にある緊張関係は解消しないと論じる。長時間稼働エージェント は、大きなウィンドウであってもいずれは埋まり、コンテキストロットはハードリミットに達する前に性能を劣化させると指摘する。「ハーネスエンジニアリング」（Harness Engineering）とは何か？ では、著者が、問題はタスクの組み立て方にあったのだから、より大きなウィンドウがあってもずれていくスライドデッキは直らなかっただろうと論じている。トークンキャッシュ はコストの観点を加える。キャッシュミスのコストはコンテキスト長に比例して増えるため、トークン単価が同じであっても、非常に大きなウィンドウはタダではない。
何がウィンドウを埋めるのか
一群のページは、作業そのものに先立って、あるいはそれと並んでコンテキストを占めるものを扱っている。
- 常設の指示。 AI IDE ルール とその背後にある研究 AI IDE におけるルールの分類法と進化：マイニングと調査による研究 は、リンターのほうが確実に強制できるフォーマットや構文に限られたコンテキストウィンドウを費やさないよう勧めており、またルールへの準拠がそのルールを導入したコミットの後に低下していくことを報告している。研究はこれを、コンテキストウィンドウの複雑さが増していくことに一部起因するとしている。Claude Code は、CLAUDE.md を簡潔に保つようにという Anthropic の助言を記録しており、肥大化したファイルは実際の指示が無視される原因になると警告している。
- 必要に応じて読み込まれる機能。 Agent Skills は 段階的開示（Progressive Disclosure） を説明している。スキルのメタデータは常に読み込まれ、本体はトリガーされたときに、同梱リソースは読まれたときにだけ読み込まれる。また、同梱スクリプトは実行され、その出力だけがコンテキストに入る。「ハーネスエンジニアリング」（Harness Engineering）とは何か？ は、著者が蓄積してきた各スキルが読み込まれたときにどれだけのコンテキストを占めるかを測定したことを報告している。これは作業が始まる前に消費されるコンテキストである。Dive into Claude Code：現在および将来の AI エージェントシステムの設計空間 は、Claude Code の拡張メカニズムをコンテキスト上のコストの順に並べている。
- ツールとテストの出力。 並列に動く Claude のチームで C コンパイラを構築する は、テスト出力をコンテキストウィンドウの汚染を念頭に設計した。数行だけを出力して残りはファイルにログとして書き出し、各エラーとその理由を grep できるよう 1 行にまとめるというものである。
ハーネスエンジニアリング で紹介されている LLM エージェントにおける外部化：メモリ、スキル、プロトコル、ハーネスエンジニアリングの統一的レビュー は、この競合をハーネスレベルの調整問題として扱う。メモリ検索、スキルの読み込み、プロトコルのスキーマ、ツールの説明、そしてモデル自身の推論トレースは、いずれも同じ有限の割り当てから引き出されており、適切な配分は実行のフェーズによって異なる。
セッション内で何がなされるのか
Anthropic の記事 AI エージェントのための効果的なコンテキストエンジニアリング は、この制約への対応を 1 つの指導原則を軸に整理している。可能な限り小さな、高シグナルのトークンの集合を見つけるという原則であり、それをシステムプロンプト、ツール、例示に適用する。続いて検索に話を移し、ジャストインタイムのコンテキスト取得 への移行を説明したうえで、ウィンドウに収まらないタスクのための 3 つの手法、すなわち コンパクション、構造化ノートテイキング、サブエージェントアーキテクチャ を取り上げる。それぞれが異なるタスクの形に適している。
Lance Martin の エージェントのためのコンテキストエンジニアリング と LangChain の コンテキストエンジニアリング は、モデルを CPU、そのコンテキストウィンドウを RAM とみなす捉え方から出発し、よく使われているエージェントに見られる戦略を、書き込み（write）、選択（select）、圧縮（compress）、分離（isolate）の 4 つの区分にまとめている。LangChain の記事はさらに、各区分を自社の LangGraph の機能に対応づけており、そのページはこれをベンダーによるガイダンスとして明記している。
2 つのページが、1 つの本番エージェントにおけるコンテキストの扱いを異なる角度から説明している。Claude Code は文書化された挙動を記録している。古いツール出力がまず消去され、必要に応じて会話が要約されるというものであり、セッションの制御手段として /clear と /compact がある。Dive into Claude Code：現在および将来の AI エージェントシステムの設計空間 はソースコードを読み、コンテキストウィンドウを拘束力のあるリソース制約と特定している。それは、モデルを呼び出すたびにその前に実行される一連のシェイパーによって管理され、より安価な戦略では不十分だと判明したときにだけ段階的に強化される。
分離はそれ自体が独立した対応として繰り返し現れる。Dive into Claude Code：現在および将来の AI エージェントシステムの設計空間 は、サブエージェントが分離されたコンテキストウィンドウで動作し、親には要約テキストだけを返すことを説明している。「ハーネスエンジニアリング」（Harness Engineering）とは何か？ は、作業の各単位を、設計ルール一式を持たせた独立したエージェントに任せたことを報告しており、その結果として、エージェントの核となる価値は並列性ではなくコンテキストの分離にあるという著者の見解を述べている。
Context as a Tool（CAT） は別の道をとる。コンテキストの維持をエージェント自身の意思決定の中で呼び出せるツールにし、追記のみのコンテキストや受動的にトリガーされる圧縮に頼るのではなく、エージェントがマイルストーンで自らの履歴を圧縮するようにする。
セッションをまたいで何がなされるのか
タスクが 1 つのウィンドウに収まる長さを超える場合、各ページは状態をウィンドウの外に移し、新たに始めることを説明している。
- 長時間稼働エージェント は、新しいコンテキストウィンドウが何よりも必要とするのは作業の状態を素早く把握する手段であり、それは git の履歴と並ぶ進捗ファイルによって提供されるという Anthropic の説明を記録している。
- Ralph Loop は、選択・実装・検証・コミットのサイクルを反復するたびにエージェントのコンテキストをリセットし、リセットをまたぐ状態をウィンドウではなくファイルシステム上に持ち越す。
- 並列に動く Claude のチームで C コンパイラを構築する では、各エージェントをコンテキストを持たない新しいコンテナで開始させ、詳細な README と進捗ファイルを維持するようエージェントに指示した。
- 外部化 は、コンテキストウィンドウを履歴の唯一の担い手として扱うのではなく、メモリを時間をまたいで状態を外部化するものとして捉える。
- DeepCode：オープンなエージェント型コーディング は、自らの問題全体を有限のコンテキストウィンドウに対する情報過多として捉え、生成されたファイルについての状態を持つ要約ベースのメモリを、素朴なスライディングウィンドウ方式で古い内容を追い出すベースラインと比較している。このベースラインは、切り捨てによって基礎的な定義を失った。
それぞれの説明はどこから来ているのか
この領域が記録していることの大半は、実践者が自らの実践を測定するのではなく説明したものである。コンテキストエンジニアリング は、そこに集めた説明のいずれも独立した評価ではないと明記している。AI エージェントのための効果的なコンテキストエンジニアリング は Anthropic の Applied AI チームが自らのエンジニアリング経験に基づいて書いたものであり、ベンチマークの集合ではなくメンタルモデルとして自らを提示している。書き込み・選択・圧縮・分離を扱う 2 つの記事は、その区分をすでに使われているパターンのまとめとして提示している。「ハーネスエンジニアリング」（Harness Engineering）とは何か？ と 並列に動く Claude のチームで C コンパイラを構築する は当事者による報告であり、Ralph Loop について報告されている限界は、Geoffrey Huntley 自身がこの手法を用いた経験に由来する。
測定された結果はいくつかの箇所に現れるが、それぞれに固有の範囲がある。Context as a Tool（CAT） と DeepCode：オープンなエージェント型コーディング はそれぞれ単一の論文のベンチマーク結果を報告しており、AI IDE におけるルールの分類法と進化：マイニングと調査による研究 はルールファイルについての混合研究法による研究である。LLM エージェントにおける外部化：メモリ、スキル、プロトコル、ハーネスエンジニアリングの統一的レビュー は測定結果ではなく統合的な論考であり、Dive into Claude Code：現在および将来の AI エージェントシステムの設計空間 はソースコードの 1 つの静的なスナップショットを読んだもので、自らの主張をエビデンスの段階ごとに格付けしている。
関連ページ
コンテキストポイズニング、コンテキストの混乱、ツール呼び出しのオフロード、コンテキストリセット、イニシャライザーエージェント、エージェントハーネス