AnthropicのContext Engineering論 — 長時間エージェントを動かす4つの実装戦略

背景 — なぜいまcontext engineeringなのか

2025年9月29日、Anthropicの応用AIチーム(Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield)がengineering blogで「Effective Context Engineering for AI Agents」という記事を公開しました。エージェントを長時間動かしたときに起きる「会話が長くなると精度が落ちる」「ツールが増えると判断がぶれる」といった現象を、コンテキスト窓全体の設計問題として正面から扱った内容です。

ここ1年でChatGPT・Claude・Geminiのいずれもコンテキスト長を100K〜1Mトークン級まで広げてきました。一方で、長尺の文脈に詰め込めば精度が上がるわけではない、というのが現場の実感です。Anthropic自身もClaude Codeや内部のリサーチエージェントで「数十回のツール呼び出しをまたいで状態を保つ」運用にぶつかっており、プロンプトを書く技芸(prompt engineering)から、推論時に何を載せ何を捨てるかを設計する技芸(context engineering)への重心移動を提案しています。

本稿はAnthropicの主張を一次引用で短くたどりつつ、Claude Code / Agent SDKを運用する立場から「日本語で意思決定に使える形」に翻訳していきます。

prompt engineeringとcontext engineeringはどう違うのか

Anthropicの定義はシンプルで、context engineeringとは「推論時にLLMへ渡すトークン全体を最適化する戦略」です。システム指示・ツール定義・ツール出力・会話履歴・外部ドキュメント・例示など、コンテキスト窓に入るすべてのものが対象になります。

両者の違いは次の通りです。

prompt engineeringが消えるわけではなく、context engineeringの一部分として包含される、という関係です。エージェントが自律的に動く時間が長くなるほど、後者の比重が上がります。

効果的なコンテキストを構成する4つの素材

Anthropicは効果的なコンテキストの構成要素を、システムプロンプト / ツール / 例示 / メッセージ履歴とその他の4つに分解しています。

1. システムプロンプトは「高度」を合わせる

Anthropicは適切なシステムプロンプトの抽象度を「ゴルディロックス・ゾーン(ちょうどよい高度)」と表現しています。

• 低すぎる(具体的すぎる): if-elseの分岐をプロンプト内にハードコードしてしまい、想定外の入力で脆く崩れる
• 高すぎる(抽象的すぎる): 「適切に対応してください」のような曖昧な指示で、文脈を勝手に仮定して期待動作から外れる
• ちょうどよい: 行動の方針を示しながら、判断の余地をモデルに残す

実装としては、<background_information> <instructions> ## Tool guidance のようにXMLタグまたはMarkdownの章立てで構造化することが推奨されています。Claude Codeで運用する場合、プロジェクト直下の CLAUDE.md がこの役割を担うので、書き方の具体パターンはClaude CodeのCLAUDE.mdを実用に引き上げる10のパターンで個別に整理しています。

2. ツールは「契約」として設計する

ツール定義は、エージェントと外界(情報空間・行動空間)の契約にあたります。設計原則として記事が挙げているのは次の3点です。

• 機能の重複を最小化する
• 入力パラメータは説明的で曖昧でないこと
• 「どのツールを使えばよいか」がエージェントから明確に判断できること

よくある失敗は、機能が膨張したツールセットによって判断ポイントが曖昧になり、選択ミスの確率が上がるパターンです。MCPで複数のサーバを繋げるときも同様で、機能が被るツールが並ぶとエージェントの精度が落ちやすくなります。MCP経由でのツール接続はMCP実用ガイドで扱っています。

3. 例示は「正規的なものを少数」

「例は千言に勝る」と引用しつつ、推奨アプローチはエッジケースを列挙するのではなく、多様で正規的(canonical)な例を少数示すこと。期待動作の輪郭を例で伝え、細部はモデルの判断に委ねる発想です。

4. メッセージ履歴とその他

メッセージ履歴・取得した外部ドキュメント・ツールの出力は、エージェントが動くにつれて指数的に増えます。原則は「情報量を保ちながらコンテキストを絞る」こと。すべてを保持するのではなく、シグナルの高い部分だけを残す設計が要ります。

この「シグナルの高い部分だけ残す」を具体化したのが、後述のjust-in-time / compaction / ノート / サブエージェント の4戦略です。

context rot — 長くなるほど精度が落ちる現象

Anthropicは、コンテキストが長くなるほどモデルの想起精度が落ちる現象を「context rot(コンテキスト腐敗)」と呼んでいます。重要なのは、これは特定のトークン数で急に壊れる「クリフ」ではなく、徐々に劣化する「勾配」である、という整理です。

根本原因として記事が挙げているのは3つです。

Anthropicの結論は「トークンを貴重で限られたリソースとして扱う」。1Mトークン入るからといって1Mトークン詰め込めば良いわけではなく、「最小の高シグナルなトークン集合が、望ましい結果の確率を最大化する」という指針が提示されています。Claude Codeにおける1Mトークン文脈の位置付けはClaude Code完全ガイド2026で扱っており、本稿の指針と合わせて読むと運用判断がしやすくなります。

just-in-time戦略 — 全部読み込まず識別子で持つ

ここから具体的な4戦略です。1つ目がjust-in-time(必要なときに取りに行く)。

従来のRAG的な発想は「事前に関連ドキュメントを取ってきてコンテキストに詰める」です。これに対しjust-in-timeは、ファイルパスやクエリ、リンクといった軽量な識別子だけを保持し、必要になった瞬間にツール経由で取得するやり方を推します。

• 人間の認知に近い: すべてを記憶せず、必要に応じて外部参照する
• メタデータ(階層・命名規則・更新時刻)自体が判断材料になる
• 「漸進的開示(progressive disclosure)」: やり取りの中で関連文脈を段階的に発見していく

Claude Code自身がこのパターンの実例で、巨大なデータベースを head / tail などのBashコマンドで断片的に読み解き、データオブジェクト全体をコンテキストに載せない設計になっています。

トレードオフは速度です。事前取得より遅く、エージェントには適切なツールとヒューリスティックが必要になります。Anthropicは**「一部は事前取得、一部は自律探索」のハイブリッド**を現実解として挙げています。

long-horizonタスクの3つの解 — compaction / ノート / サブエージェント

数時間〜数十時間に及ぶ大規模タスク(コードベース移行、長尺リサーチなど)では、コンテキスト窓を超えた状態管理が必要になります。Anthropicは3つのアプローチを提示しています。

compaction(圧縮) — 会話を要約して再開する

会話がコンテキスト上限に近づいたところで、これまでの内容をモデル自身に要約させ、新しいウィンドウで続きから走らせる手法です。Claude Codeの実装では:

• アーキテクチャ決定・未解決バグ・実装の細部は保持
• 冗長なツール出力は破棄
• 直近アクセスした5ファイルを補足として含める

注意点として、過度な圧縮は後で重要になるニュアンスを失うリスクがあるため、まず想起率(recall)を最大化し、そのうえで精度(precision)を上げる順でチューニングする、とされています。軽量版として「ツール結果だけクリアする」やり方もあり、Claude Developer Platformで実装済みです。

structured note-taking(構造化ノート) — 外部メモリに書き出す

エージェントが定期的に外部メモリへノートを書き出し、必要時に読み戻すパターンです。Anthropicが具体例として挙げるのが「Claude plays Pokémon」プロジェクトで、Claudeは1,234ステップを越えても「Route 1で訓練中、ピカチュウは目標レベル10まであと2レベル」のような形で進捗を記録し、コンテキストリセット後にノートを読み込んで数時間分の訓練やダンジョン探索を再開できた、という事例が紹介されています。

Sonnet 4.5ではMemory Toolが追加され、ファイルベースで外部メモリを永続化する仕組みがプラットフォーム側で提供されています。

sub-agent architectures(サブエージェント) — 関心を分離する

1体のエージェントですべてを管理するのではなく、親エージェントが計画を立て、特化したサブエージェントが深いタスクを担当する構造です。記事が挙げる典型挙動は:

• 親: 高レベルの計画と統合
• 子: 数万トークン以上を消費して深い探索やツール使用を行い、1,000〜2,000トークン程度の凝縮サマリーだけを親に返す

これにより、詳細な探索コンテキストはサブエージェント内に隔離され、親のコンテキストを汚さない、という効果があります。サブエージェント構造を自前で組む場合、Agent SDKの query とCustom Toolの組み合わせが現実的な実装の入り口になります。最小構成はAgent SDK入門 — Python / TypeScriptで最小エージェントを組むでまとめています。

3戦略の使い分け早見表

3つは排他ではなく、タスク特性で選びます。

編集視点 — 「context engineering」は何を意味する転換か

ここまでがAnthropicの主張のまとめです。ここからは、Claude Code / Agent SDKを運用する立場から見た解釈を3つ挙げます。

1. RAGの議論が一段、前提を変える

just-in-timeは事実上「RAGをやめろ」ではなく「RAGの位置を後ろにずらせ」という主張に近い読み方ができます。事前取得を全否定するのではなく、まずは識別子(ファイルパス・クエリ)だけ持ち、ツール呼び出しの形で必要になった瞬間に取りに行く。RAGをエージェントの設計の中央ではなく、ツールセットの一つとして扱う発想の転換が含まれています。

2. サブエージェントは「分業」ではなく「コンテキスト隔離」が本質

サブエージェントの利点を「速くなる」「並列化できる」と受け取りやすいのですが、この記事の整理を踏まえると、本質はコンテキスト汚染の隔離にあります。深い探索で発生する数万トークンの試行錯誤を親に持ち込まず、要点だけを返す——これは並列化の話ではなく、context rotから親を守る設計です。Agent SDKでサブエージェントを呼ぶときに「サマリーを何トークンに圧縮させるか」を最初に決めると、運用が安定しやすくなります。

3. システムプロンプトは「高度」が合っているかを定期点検する

CLAUDE.md やAgent SDKのsystem promptは、放置するとどちらかに偏ります。長く運用しているプロジェクトほど、トラブル対応のたびに分岐ルールが追加され、気付くと「低すぎる(具体的すぎる)」側にずれていることが多いです。逆に、立ち上げ初期は「高すぎる(抽象的すぎる)」側にいがちです。半年に一度くらい、システムプロンプトを「いま自分が読んで、判断の余地があるか / 文脈を仮定しすぎていないか」で点検すると、context engineeringの観点でも効果が出やすい部分です。

まとめ

Anthropicの「Effective Context Engineering for AI Agents」は、エージェントを長時間動かす前提でコンテキスト窓全体の設計を扱った記事です。要点を改めて並べると次のとおりです。

• prompt engineeringはcontext engineeringの一部分。エージェントが自律的に動くほど後者の比重が上がる
• システムプロンプト・ツール・例示・履歴の4素材それぞれに、シグナルを保ちつつ絞る設計が要る
• context rotは勾配で起きる。1Mトークン入っても、最小の高シグナル集合が結果を最大化する
• long-horizonタスクはcompaction / 構造化ノート / サブエージェント をタスク特性で使い分ける
• just-in-timeは識別子だけ持って必要時に取りに行く戦略で、RAGの位置付けを後ろにずらす含意がある

エージェント運用の現場感としては、「迷ったら、いま機能する最もシンプルなやり方を取る」というAnthropicの締めくくりが実務的です。Claude Codeでの具体的な運用はClaude Code完全ガイド2026 ・ CLAUDE.mdを実用に引き上げる10のパターン ・ Agent SDK入門で扱っているので、本稿の枠組みと合わせて読むと、自分のプロジェクトのコンテキスト設計を見直しやすくなります。