Context Engineeringは、LLMが推論するたびに、限られたContextへ何を入れ、何を外し、何を外部状態へ残すかを設計する工程です。
Agentを長く動かすと、会話履歴とTool結果は増え続けます。全部を次の推論へ渡していると、Goalより過去の試行の方が大きくなります。
Prompt EngineeringがInstructionや例の改善を中心にするのに対し、Context Engineeringは会話履歴、Tool定義、Tool結果、取得文書、Memory、進捗状態まで扱います。
Contextは一度作って終わりではない
AnthropicのContext Engineering解説は、Context Engineeringを、推論時に利用できるTokenを選び、維持するStrategyとして説明しています。
AI Agentは、実行するたびに新しい情報を生みます。
- 利用者の依頼を受け取る
- ModelがToolを選ぶ
- Tool結果が返る
- Modelが次の判断を行う
- 途中結果とErrorが増える
すべてを履歴へ足し続けると、古い情報、重複、失敗した試行がContextを占有します。各Stepで次の判断に必要な情報を選び直します。
Contextを構成する層を分ける
| 層 | 例 | 管理方法 |
|---|---|---|
| Stable instruction | 目的、Policy、出力契約 | Version管理 |
| Task state | 現在のGoal、完了条件、未解決事項 | 構造化状態 |
| Working context | 直近のMessage、Tool結果 | Window内で更新 |
| Retrieved context | 文書、DB、Web検索 | 必要時に取得 |
| Long-term memory | Preference、過去の決定 | 外部Storageと取得Policy |
| Artifact | File、Plan、Patch、Report | URIやPathで参照 |
固定Instructionと動的状態を一つの長文へ混ぜると、更新箇所と信頼境界が分かりにくくなります。
PreloadとJust-in-time Retrievalを使い分ける
すべての情報を最初に渡すPreloadは、単純でRequest回数も少なくできます。ただし、不要な情報までContextを使います。
File path、Resource ID、検索Toolだけを先に渡し、必要になった時点で取得するJust-in-time Retrievalは、Contextを絞れます。一方で、Agentが適切な情報を見つけられるToolと説明が必要です。
AgentはGoalとStable instructionを起点に、追加Contextが必要かを都度判断します。必要な場合だけSearchまたはResource Toolから情報を選び直し、不要ならそのままActionまたはAnswerへ進みます。
- GoalとStable instructionをAgentへ渡します。
- Agentが追加Contextの必要性を判定します。
- 必要ならToolで検索してSelected contextをAgentへ戻します。
- Contextが十分ならActionまたはAnswerへ進みます。
業務ルールや必須の安全条件は先に渡し、大きな文書や詳細データは必要時に取得するHybrid構成が現実的です。
Compaction、Memory、Artifactを分ける
長時間処理では、一つのContext Windowに収まり続けません。
Compaction
会話や実行履歴を要約し、重要な決定、未解決事項、次のStepを残します。情報を失う処理なので、元のTraceやArtifactへ戻れるようにします。
Structured Memory
利用者設定、確定した事実、過去の決定をFieldへ分けて保存します。モデルが生成した推測を、確認済み事実と同じ場所へ保存しません。
Artifact
Code、文書、Plan、Test結果をFileやObjectとして外部へ置き、ContextにはPath、要約、必要な抜粋だけを載せます。
Anthropicの長時間Agent向けHarnessは、複数Sessionにまたがる作業で、進捗FileやCommitなどのArtifactを引き継ぐ方法を示しています。
Context品質を評価する
Context Engineeringの失敗は、単にToken上限を超えることだけではありません。
- 必要な情報が入っていない
- 古い情報が残っている
- 相反するInstructionがある
- 未信頼データをInstructionとして扱った
- 要約で例外条件が消えた
- Tool結果が大きすぎてGoalが埋もれた
- 同じ資料を繰り返し取得している
Traceから、各StepでどのContextを渡し、その情報が次の判断に使われたかを確認します。Token削減だけでなく、Task成功率と誤操作を一緒に見ます。
よくある誤解
Context Engineeringは長いSystem Promptを書くこと
System Promptは一部です。履歴、Tool、検索結果、Memory、Artifactを含む推論時の情報全体を扱います。
Context Windowが広がれば不要になる
上限が広がっても、情報の鮮度、信頼度、矛盾、取得費用は残ります。Lost in the Middleが示すように、長い入力内の情報利用も別に評価が必要です。
Compactionすれば情報を失わない
要約は選別です。数値、条件、例外、未解決事項が落ちる可能性をTestします。
Agentに検索Toolを渡せば必要情報を必ず見つける
Toolの説明、検索範囲、Index、権限、停止条件が不十分なら、見落としや無駄な探索が起きます。
EastBraver Labsの判断基準
EastBraver Labsでは、Contextを会話全文ではなく、目的に必要な作業状態として扱います。
確定事実、モデルの推測、利用者入力、外部文書を分け、出所を追える状態にします。長時間処理では、進捗と完了条件を構造化Artifactへ残します。
一番大きなContextを使うのではなく、次の判断に必要な情報を戻せる構成を選びます。
情報を減らすこと自体が目的ではありません。Agentが迷わず検証できる状態を作るためです。