あなたの AI エージェントは最初の 10 ステップでは完璧に動きます。
しかし、15 ステップ目あたりから、だんだん雑になってきます。
間違ったツール呼び出し。最初の指示を忘れる。低品質な出力。
ほとんどの人はモデルのせいにします。
でも、原因はほとんどモデルではありません。
原因は、モデルが見ているものにあります。
モデルが見るものを整理することを コンテキストエンジニアリング と呼びます。
これは、AI エージェントを構築するすべての人にとって、すぐに最も重要なスキルになりつつあります。
以下が完全なプレイブックです。
プロンプトエンジニアリングは死んだ。今重要なのはコンテキストエンジニアリングだ。
プロンプトエンジニアリングについては聞いたことがあるでしょう。
明確な指示を書くこと。良い例を示すこと。モデルにどの役割を演じるか伝えること。
それはチャットボットには完璧に機能します。
しかし、エージェントを構築した瞬間に機能しなくなります。
その理由は以下の通りです。
チャットボットは 1 つの質問に答えて停止します。
エージェントはアクションを実行します — Web の閲覧、API の呼び出し、コードの記述、コマンドの実行 — ステップ・アンド・ステップ、時には何十ものステップにわたります。
すべてのステップで出力が生成され、それがモデルのコンテキストに追加されます。
そして、そのコンテキストは有限です。
Anthropic のエンジニアリングチームは、次のように定義しています。
「コンテキストとは、LLM からサンプリングするときに含まれるトークンのセットです。コンテキストエンジニアリングとは、それらのトークンの有用性を最適化し、一貫して望ましい結果を達成することです。」
簡単に言えば、エージェントが適切な情報を、適切な形式で、適切なタイミングで確実に見られるようにすることです。
プロンプトエンジニアリングは、コンテキストエンジニアリングのサブセットです。
コンテキストエンジニアリングこそが全てです。
エージェントのコンテキストウィンドウは RAM だ。そして、それは埋まりつつある。
LangChain がこの適切な例えを提供しています。
LLM を新しい種類のオペレーティングシステムと考えてみてください。
モデルは CPU です — 思考を行います。
コンテキストウィンドウは RAM です — モデルが現在見ることができ、推論できるすべてのものが存在するワーキングメモリです。
コンピュータが RAM でいっぱいになると遅くなるのと同じように、コンテキストウィンドウが混雑するとエージェントの推論は低下します。
これは コンテキストロット（Context Rot） と呼ばれます。
Chroma は、GPT-4.1、Claude 4、Gemini 2.5、Qwen3 など、18 のフロンティアモデルを評価する研究を実施しました。
すべてのモデルで、入力長が増加するにつれてパフォーマンスが低下しました。
ハードリミットではありません。そのかなり前からです。
200K トークンのウィンドウを持つモデルでも、50K トークンで顕著な低下が見られる可能性があります。
低下は継続的です。崖のように急落するわけではありません。
なぜでしょうか？ Transformer は、すべてのトークンが他のすべてのトークンにアテンションすることで機能します — n の二乗の関係を生み出します。コンテキストが増えるにつれて、モデルがそれらすべての関係を保持する能力は薄れていきます。
そして、「Lost in the Middle」問題もあります。
LLM は U 字型のアテンション曲線を示します。
→ コンテキストの最初：よく記憶される
→ コンテキストの最後：よく記憶される
→ 中間：ほとんど無視される
研究者は、関連情報がコンテキストの最初から中間に移動すると、精度が 30 パーセントポイント以上低下することを測定しました。
元の指示 — 50,000 トークンのツール出力の下に埋もれて — 事実上消えてしまいます。
Claude Code のユーザーは、出力品質がコンテキスト容量の 40～60% で低下することを発見しています。どのハードリミットよりもかなり前です。
エージェントのコンテキスト内で実際にスペースを競い合っているもの
7 つのカテゴリ。すべてが同じ有限のウィンドウを争っています。
1. システムプロンプト
エージェントのアイデンティティ。行動ルール。制御フローロジック。さまざまなタスクタイプの指示。エージェントの場合、これは単に「役に立つこと」ではありません。アーキテクチャ全体を定義することもあります。
2. ツール定義
エージェントが呼び出す可能性のあるすべてのツールには、そのツールが何をするか、どのようなパラメータを取るか、いつ使用するかを説明するスキーマが必要です。
3. ツール呼び出し結果
すべてのツール呼び出しは、その出力をコンテキストに追加します。Web ページの取得：5,000～10,000 トークン。ファイルの読み取り：同様。これらは急速に蓄積されます。
4. 取得された知識（RAG）
ベクターデータベースから取得されたドキュメント、検索結果、API 応答 — エージェントの意思決定に情報を提供するために取得されたものすべて。
5. 会話履歴
発生したすべての完全なトランスクリプト。ユーザーメッセージ、エージェントの応答、推論、以前の決定。ターンごとに直線的に増加します。
6. メモリ
現在のセッションからの短期メモリ。以前のセッションからの長期メモリ — ユーザーの好み、以前の結果、学習されたパターン。
7. エージェント状態
現在の計画、ToDo リスト、進捗マーカー、スクラッチパッドのメモ。マルチステップタスクでエージェントがどこにいるかを追跡するメタ情報。
7 つすべてが同じウィンドウを競い合っています。
コンテキストエンジニアリングとは、何が勝つかを決めることです。
4 つの中核戦略
LangChain は、すべてのコンテキストエンジニアリング手法を 4 つのバケットに整理するフレームワークを公開しました。
あなたが今後学ぶすべてのテクニックは、これらのいずれかに当てはまります。
書く。選択する。圧縮する。分離する。
戦略 1 — 書く （エージェントは忘れる。記憶する手段を与えよ。）
エージェントのコンテキストがいっぱいになって圧縮されると、情報が失われます。
その前にエージェントが何も書き留めていなければ、その情報は永久に失われます。
書く とは、エージェントがコンテキストウィンドウの外側に情報を永続化する手段を与えることを意味します。
3 つの形式があります。
スクラッチパッド
エージェントに、タスク中にメモを取らせるツールを与えます。中間的な発見。下した決定。後で必要になることがわかっている情報。
Anthropic は「考える」ツールを構築しました — Claude が問題を解決するための専用スペースです。
tau-bench ベンチマークでは、これにより特定のタスクでパフォーマンスが最大 54% 向上しました。
ルールファイル
永続的な手続き的記憶。
Claude Code を使用したことがあれば、CLAUDE.md を見たことがあるでしょう。
セッションの開始時に毎回読み込まれる指示 — プロジェクトアーキテクチャ、規約、テストの実行方法、注意すべき点。
エージェントは起動するたびにそれを読みます。
基本を決して忘れません。
メモリ抽出
エージェントが事実、ユーザーの好み、学習したパターンを保存し、セッション間で取得できるようにします。
コンテキストウィンドウの完全に外側に存在します。
明日エージェントが必要とする情報は、明日が来たときにそこに待っています。
戦略 2 — 選択する （エージェントにすべてを与えるな。今必要なものだけを与えよ。）
40 のツール、大規模な知識ベース、そして数セッションの履歴を持つエージェントは、それらすべてを一度に読み込むことはできません。
何かが、このステップに関連するものを決定しなければなりません。
従来の RAG： システムが決定します。
ユーザーが尋ねる → ドキュメントを取得 → プロンプトに詰め込む → 完了。
静的。ワンショット。モデルに発言権はありません。
エージェンティック RAG： エージェントが決定します。必要なものを検索し、クエリを洗練し、ツールを選択し、十分な情報を得たかどうかを判断します。
取得は、ワンショットパイプラインではなく、反復的なプロセスです。
これは重要です。なぜなら、関連するものはステップごとに変化し、次に何が必要かを知っているのはエージェントだけだからです。
ツール選択の問題は、ほとんどの人がつまずくポイントです。
もしあなたのエージェントが 40 以上のツールを持っている場合、それは作業を始める前に、潜在的に 10,000 トークンのツール定義がコンテキストに存在することを意味します。
修正方法：ツール説明に対する RAG。
すべてのツール定義をすべての呼び出しにダンプする代わりに、セマンティック検索を使用して、現在のステップに関連するツールのみを表面化します。
RAG-MCP と呼ばれる論文でこれがテストされました。
ツール選択精度：14% → 43%（3 倍の改善）。トークン使用量：約半分に削減。
Anthropic はこれを ハイブリッド戦略 と呼んでいます：事前に重要なコンテキスト（CLAUDE.md など）をロードし、その他についてはエージェントにジャストインタイムの取得を任せます。
基本を先にロード。残りはオンデマンドで取得。
戦略 3 — 圧縮する （コンテキストは蓄積される。意味を保ち、トークンを削減せよ。）
適切な選択を行っても、コンテキストは蓄積されます。
すべてのツール呼び出し、取得されたドキュメント、決定がウィンドウに残ります。
あなたのエージェントが 20 回のツール呼び出しを行ったと想像してください。
コンテキスト：80,000 トークンの蓄積されたツール出力、会話履歴、推論トレース。
そのほとんどはもはや関連しません。エージェントはすでにそれに基づいて行動しました。
しかし、それらはまだそこにあり、スペースを取り、アテンションを低下させ、コストとレイテンシーを押し上げています。
3 つのポイントで圧縮できます。
情報がコンテキストに入る前：
→ 取得前に大きなドキュメントを一貫したチャンクに分割する
→ 最も有用なチャンクだけが入るように再ランク付けする
→ メインコンテキストに入る前にツール出力をその場で要約する
エージェントが作業している間：
→ 会話履歴のローリングサマリー — 継続的に更新
→ 一般的なハイブリッド：最新の 10 メッセージをそのまま保持 + それより古いものをすべて要約
→ ハードトリミング：コンテキストがサイズしきい値に達したら古いメッセージを削除
→ Claude Code の自動圧縮：容量の 95% でトリガー、全軌跡を自動的に要約
エージェントが何かに基づいて行動した後：
→ ツール結果のクリア：ツール結果が 15 ステップ前に使用された場合、それをドロップ
→ 1 行の要約に置き換えるか、完全に削除
→ エージェントは 20 ステップ前に取得した Web ページの全文を必要としない
目標：トークン数を削減する。実際に重要なものを保存する。
戦略 4 — 分離する （最も強力な戦略。マルチエージェントシステムを可能にする。）
ここに、長時間のエージェント実行におけるより深い問題があります。
それは単なるスペースの問題ではありません。それは汚染です。
調査段階での詳細なファイル検索が、エージェントがコードの記述に移行したときにもまだコンテキストに残っています。
その古い調査コンテキストは今やノイズです。クリーンな実装に集中する必要があるフェーズで、モデルを distracted させています。
分離 とは、作業の異なる部分にそれぞれ別のコンテキストウィンドウを与えることを意味します。
サブエージェント
親エージェントが「コードベースから認証関連ファイルをすべて検索して」という焦点を絞ったサブタスクを子エージェントに委任します。
子エージェントは、それ自身のクリーンなコンテキストウィンドウで作業します。
報告するときは、凝縮されたサマリーのみを返します。
面倒な検索操作はすべて子エージェントのコンテキスト内に分離されたままで、親を汚染することはありません。
ステートスキーマ分離（LangGraph のアプローチ）
エージェントの状態を、異なるフィールドが異なるタイプのコンテキストを保存するように設計します。
LLM は、現在のステップに関連するフィールドのみを見ることができます。
ツール結果は「バックステージ」フィールドに置かれます — 明示的に表面化されるまでモデルからは見えません。
別々のサブエージェントを起動することなく、各ステップでエージェントが見るものをきめ細かく制御します。
分離こそが、複雑なマルチステップワークフローを実際に信頼できるものにするのです。
異なるジョブ。異なるコンテキストウィンドウ。汚染なし。
エージェントが失敗する 4 つの方法 （失敗を特定せよ。修正せよ。）
Drew Breunig 氏は、エージェントのコンテキストが成長するにつれて、4 つの明確な障害モードを特定しました。
あなたがこれまで見たどんな壊れたエージェントも、これらのいずれかに当てはまります。
障害 1: コンテキストポイズニング
幻覚やエラーがコンテキストに入り込みます。
エージェントは後続のステップでそれを何度も参照します。
ステップ 5 の悪いデータが、後のすべてのステップに複合的に影響します。
修正方法: ツール出力がコンテキストに入る前に検証する。エラーから回復した後、失敗した試行の履歴を圧縮する。解決策だけが重要な場合に、10 ステップの行き詰まりのデバッグ履歴を残さない。
━━━
障害 2: コンテキストディストラクション
コンテキストが非常に長くなり、モデルが最近の履歴に過度に依存し始めます。
新しい計画を合成する代わりに、最近行ったことをそのまま繰り返します。
考えるのをやめます。繰り返し始めます。
修正方法: 積極的に要約し、刈り込む。大きなコンテキストウィンドウが利用可能な場合でも。大きなウィンドウは、それを埋めることを意味しない。
━━━
障害 3: コンテキストコンフュージョン
余計なコンテンツが、モデルを低品質な決定に導きます。
典型的な例：46 のツールを与えられたモデルがベンチマークで失敗する — コンテキストは十分範囲内であったにもかかわらず — しかし、19 のツールだけでは正常に動作する。
ツールが多すぎてコンテキストが保持できなかったわけではありません。
モデルが明確に推論するには多すぎたのです。
修正方法: 動的なツール管理。RAG-MCP を使用して、現在のステップに関連するツールのみを表面化する。ツールセットを現在のフェーズに一致させる。
━━━
障害 4: コンテキストクラッシュ
新しい情報が、コンテキスト内の既存の情報と矛盾します。
システムプロンプトが 1 つのことを言います。取得されたドキュメントが別のことを言います。
エージェントは矛盾を調整できません。一貫性のない動作を生成します。
修正方法: 明確な権威順序を確立する。システムプロンプト > 取得された事実 > 会話履歴。新しい情報をコンテキストに注入する前に、既存のコンテキストに対して検証する。XML タグと明確なヘッダーを使用して、モデルがどのソースを信頼すべきかを認識できるようにする。
エージェント用のシステムプロンプトの書き方 （チャットボット用ではない。エージェント用だ。）
チャットボットのシステムプロンプトはトーンを設定します。
「あなたは役立つアシスタントです。簡潔で親切にしてください。」
エージェントのシステムプロンプトはアーキテクチャを定義します。
それは制御フローを指定します — タスクの種類にどうアプローチするか、どのツールをいつ使うか、エラー時に何をするか、どのガードレールに従うか。
それは、性格プロンプトというよりも、自律型従業員のための職務記述書を書くことに近いです。
Anthropic は、それを「適切な高度」で書くことと呼んでいます。
細かすぎる場合：「ユーザーが請求に言及し、かつ返金に言及し、かつ金額が 100 ドルを超える場合は、ツール X を呼び出す。」脆弱。想定外のエッジケースごとに破綻します。
曖昧すぎる場合：「役に立ち、適切なツールを使用してください。」エージェントに何も与えません。具体的なシグナルなしに、自律的に良い決定を下すことはできません。
スイートスポット：自律的な行動を導くのに十分具体的。モデルが新しい状況で判断を適用できるほど柔軟。強力なヒューリスティック。硬直したルールではない。
実用的なヒント：
→ XML タグまたはマークダウンヘッダーで整理する — 背景、指示、ツールガイダンス
→ 最小限から始めて、失敗に基づいて反復する — すべてのエッジケースを事前に予測しようとしない
→ 最小限は短いことを意味しない — 複雑なエージェントシステムプロンプトは数千トークンになる可能性があり、すべてのトークンがその価値を証明している限り問題ない
→ 少数ショット例を使用する — すべてのルールを言葉で説明しようとする代わりに、良い振る舞いがどのようなものかをエージェントに示す
KV-Cache: コンテキスト順序を気にするべき $$$ の理由
ほとんどのエージェント構築者は、これが存在することを知りません。
トークンを LLM に送信すると、モデルは各トークンのキーとバリューの表現を計算します。
計算コストが高いです。
そのため、推論プロバイダーはこれらの表現をキャッシュします。
コンテキストの先頭 — プレフィックス — が API 呼び出し間で同じままである場合、プロバイダーはキャッシュされた計算を再利用し、最後の新しいトークンのみを処理します。
高速。低コスト。
しかし、呼び出し間でコンテキストの前半部分を再配置または変更すると、キャッシュが無効になります。プロバイダーはすべてを最初から再計算します。
Claude Sonnet でのコスト差：
→ キャッシュされた入力トークン：100 万トークンあたり 0.30 ドル
→ キャッシュされていない入力トークン：100 万トークンあたり 3.00 ドル
10 倍の差。
タスクあたり 30～40 回の API 呼び出しを行うエージェントの場合、これはすぐに積み上がります。
KV キャッシュ効率のための実用的なルール：
→ 安定したコンテンツはコンテキストの 先頭 に置く — システムプロンプト、ツール定義、ターン間で変更されないもの
→ 動的なコンテンツは 最後 に置く — 会話履歴、現在のステップ、エージェント状態
→ 会話の途中でツールを動的に追加・削除しない — キャッシュが無効になる
→ ツール削除の代わりに ツールマスキング を使用する — すべてのツール定義をプレフィックス（キャッシュされる）で安定させ、現在のフェーズで利用できないものとしてマークするだけ
7 時間で 35,000 行のコードをリリースするワークフロー
Dex Horthy 氏（HumanLayer の CEO）は、AI Engineer Code Summit でこれを発表しました。
彼のチームはこれを使用して、1 回の 7 時間セッションで大規模な Rust コードベースに約 35,000 行のコードをリリースしたと報告されています。
その方法：頻繁な意図的な圧縮。
エージェントの作業をフェーズに構造化します。各フェーズは、圧縮されたアーティファクトを生成します。新しい各フェーズは、そのアーティファクトのみを含む新しいコンテキストウィンドウで開始します。
常に、コンテキストウィンドウの 40～60% 未満に意図的に留まります。
フェーズ 1 — 調査
サブエージェントがコードベースを探索します。ファイルを読みます。データフローを追跡します。アーキテクチャをマッピングします。
面倒な grep 結果やファイルコンテンツはすべてサブエージェントのコンテキストに留まります。親には決して触れません。 (分離)
出力：コンパクトな research.md — ファイルパス、関数シグネチャ、パターン、落とし穴。 (書く)
コンテキストリセット：生の調査ではウィンドウの 60～80% を使用していました。調査アーティファクトにより 15～20% に圧縮されます。 (圧縮)
フェーズ 2 — 計画
新しいコンテキストウィンドウ。含まれるもののみ：調査ドキュメント + 問題定義。
エージェントは詳細な実装計画を作成します。
これが最も重要な人間によるレビューチェックポイントです。
ここでロジックエラーを発見すれば、修正は簡単でコストもかかりません。後になると何時間もかかります。
フェーズ 3 — 実装
さらに新しいコンテキストウィンドウ。含まれるもののみ：計画。
エージェントはそれをステップバイステップで実行します。
複雑なタスクの場合：progress.md が完了したものと残っているものを追跡します。 (書く)
結果：すべてのフェーズでクリーンで集中したエージェント。汚染なし。コンテキストロットなし。「だらしない 20 ステップ目」なし。
トッププラットフォームがこれをどのように異なる方法で処理するか
Claude Code
ハイブリッド検索。CLAUDE.md が事前にロードされます。glob や grep などのツールがジャストインタイムのコードベースナビゲーションを処理します。
95% で自動圧縮 — アーキテクチャ上の決定と最後にアクセスした 5 つのファイルを保持します。
複雑なサブタスクのためにサブエージェントを生成でき、それぞれが独自のクリーンなコンテキストを持ちます。
哲学：「最もシンプルでうまくいくことをする。」モデルに何が必要かを賢く判断させ、それを見つけるためのツールを与えます。
Manus
KV キャッシュ対応のコンテキスト順序：安定したプレフィックス、動的なサフィックス。ツールのマスキング（削除ではない）。
観測圧縮パイプライン — すべてのツール出力は、エージェントのコンテキストに入る前に処理されます。
状態追跡のための永続的な ToDo リスト。
削除されたコンテキストのためのオーバーフローメモリとしてのファイルシステム。
拡張性を考慮して構築。効率性がビジネス上のコスト問題となる何十万ものユーザーにサービスを提供。
ChatGPT Agent
ビジュアルファーストのアプローチ。エージェントは GUI ブラウザと対話します。
スクリーンショットがビジュアルスナップショットとしてコンテキストに追加されます。モデルは見たものに基づいて推論します。
ビジュアルトークンは高価であるため、エージェントはスクリーンショットの数を選択的にします。
RL を使用して、明示的にプログラミングする代わりに、何千もの仮想マシンにわたって最適なツール使用戦略を学習します。
Google ADK
最も原則的なアーキテクチャアプローチ。
3 つの設計原則：
- ストレージとプレゼンテーションを分離する — 永続的な状態は、各 API 呼び出しに表示されるものと同じではない
- 明示的な変換 — テスト可能で構成可能なステップでコンテキストを変換する、名前付きの順序付けられたプロセッサ
- デフォルトでコンテキストをスコープする — すべてのモデル呼び出しは、必要最小限の情報のみを見る
プロンプト作成よりもエンジニアリング規律。
ユニバーサルエージェントターンパイプライン
すべての本格的なプラットフォームは、エージェントターンごとに同じ 5 ステップのループに収束します：
→ 収集 — ユーザー入力、会話履歴、ツール結果、取得されたドキュメント、エージェント状態
→ 選択 — 残りのトークン予算内でこのステップに関連するもの
→ 圧縮 — 要約、切り捨て、または再構築してコンテキストに適合させる
→ 配置 — 安定したコンテンツを最初に（キャッシュ）、動的なコンテンツを最後に
→ アセンブルして呼び出す — 最終コンテキスト → API 呼び出し → 出力を取得 → ループ
これが、あなたがこれまで使ったすべてのプロダクションエージェント内部で実行されているループです。
これを理解することが、信頼できるエージェントをリリースする構築者と、なぜエージェントが 15 ステップ目で雑になるのか疑問に思う構築者を分けます。
まとめ
コンテキストロットは現実であり、コンテキスト制限のかなり前から始まります。
それを修正する 4 つの戦略：
→ 書く — コンテキスト外に情報を永続化し、エージェントが忘れないようにする
→ 選択する — このステップに必要なものだけを取り込む
→ 圧縮する — トークンを削減し、意味を保持し、事後対応的ではなく事前対応的に行う
→ 分離する — 別々のジョブに別々のコンテキスト、汚染なし
注意すべき 4 つの障害モード：
→ ポイズニング — 悪いデータがすべてのステップに複合的に影響する
→ ディストラクション — 長い履歴によりエージェントが考える代わりに繰り返す
→ コンフュージョン — ツールが多すぎると決定品質が低下する
→ クラッシュ — 矛盾により一貫性のない動作が発生する
KV キャッシュは 10 倍のコスト削減に値します。安定したコンテンツを最初に置きましょう。
最適なワークフロー：調査 → 圧縮 → 計画 → 圧縮 → 実装。すべてのフェーズで新しいコンテキスト。
コンテキストエンジニアリングは、本格的なエージェント作業にとってオプションではありません。
それが仕事そのものです。
これが役に立ったなら：
→ あなたが知っているすべてのエージェント構築者と共有するためにリポストしてください
→ あなたが眠っている間も機能するシステムについてもっと知るために @sairahul1 をフォローしてください
→ これをブックマークしてください — 4 つの戦略フレームワークに何度も戻ることになるでしょう
私は AI、製品構築、そして実際に機能するシステムについて書いています。
