[要約翻訳] AIエージェントのための効果的なコンテキストエンジニアリング

• 9月29日にAnthropicが公開した Effective context engineering for AI agents を要約翻訳しました。ブログ記事では、原文にあった画像とリンクを可能な限り維持しています。

---

プロンプトエンジニアリング vs コンテキストエンジニアリング

• プロンプトエンジニアリングはシングルトンクエリをよりうまく行うためのものであり、
• コンテキストエンジニアリングは、（特にエージェント向けに）多様なコンテキストの中から本当に必要なものだけをキュレーションすることだ。

エージェント構築にコンテキストエンジニアリングが重要な理由

• 現在のエージェントは、「より長時間、より多くのツール」を使うように開発されている。
• そうなるとコンテキストはどうしても長くなるが、LLMは人間と似て、コンテキストに大量のデータが詰め込まれると集中力を失い、必要な情報を引き出しにくくなる。
• そのため、コンテキストを効果的に制御することがエージェント開発で非常に重要になる。

効果的なコンテキストの解剖学

良いコンテキストエンジニアリングとは、望ましい結果の可能性を最大化する、可能な限り最小の高シグナルトークン集合を見つけることを意味する。
> Smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome

1) システムプロンプト

• システムプロンプトは、非常に明確で、単純かつ直接的な言葉で、ちょうど適切な粒度に保つべきだ。具体的すぎるとさまざまなケースに対応できず、抽象的すぎるとLLMが推測しなければならないことが多くなりすぎる。
• 期待する動作についての最小限の記述から始め、フロンティアモデルが失敗するケースに対してのみ、明確な指示と例を追加して改善していくべきだ。
• XMLやMarkdownに似た手法でセクションを区切るとよいが、厳密な文法を守ろうとしすぎる必要はない。

2) Tools

• Toolsはトークン効率よく情報を返し、同時にエージェントがトークン効率よく動作するよう促すべきだ。LLMが理解しやすい形である必要があり、相互の機能の重なりは最小限でなければならない。
• 最もよくある失敗は、1つのツールが機能を持ちすぎていること、あるいはLLMがどのツールを使うべきか判断しづらい状況になっていることだ。人間のエンジニアがいつ何を使うべきか決めにくいなら、AIエージェントにとっても難しい。
• 例を与えるfew-shotプロンプティングは常に強く推奨される。ただし、あまりに多くのエッジケースを盛り込むと汎用性が下がる。慎重に選んだ期待動作を示す例を、多様に含めるべきだ。

コンテキスト取得とエージェンティック検索

• エージェントとは、目標達成のためにループを回しながら自律的にツールを実行する存在である。モデルが強力になるほど、より多くの権限（自律性）をエージェントに与えられる。
• エージェンティックなアプローチが発展するにつれて、JIT（Just in Time）でコンテキストを与える戦略がますます多く見られるようになっている。Claude Codeはこれを非常にうまく使っている。プロンプト中のファイルパスやリンクを見て、その場で取得するという形だ。
• 良いコンテキストをJITで読み込むには、最初から良い構造で情報を保存しておく必要がある。これには、取得に役立つメタデータをどう保存するかという検討も含まれる。フォルダ構造、命名規則、タイムスタンプなど、人間にとって重要で意味のあるシグナルは、エージェントにとっても情報活用に大きく役立つ。

長時間タスク（long-horizon tasks）のためのコンテキストエンジニアリング

長時間タスクはたいてい、LLMのコンテキストウィンドウを容易に超えてしまう。したがって、エージェントがどのように良いコンテキストを維持しながら、目標達成に向けて着実に進めるようにするかが非常に重要になる。

タスクの特性に応じて、大きく3つの手法を使うことができる。

• 圧縮 は、広範な双方向コミュニケーションが必要なタスクで、会話の流れを維持するのに適している。
• 構造化ノートテイキング は、明確なマイルストーンがあるタスクを反復しながら開発するのに適している。
• サブエージェントアーキテクチャ は、並列探索が効果を発揮する複雑な調査や分析の処理に適している。

1) 圧縮

• コンテキストウィンドウの制限に近づいたら、重要な内容を要約して新しいウィンドウに渡すこと。Claude Codeでは、メッセージ履歴を渡して要約させる。アーキテクチャ上の意思決定、未解決のバグ、実装の詳細など。
• 圧縮の肝は、結局のところ何を残し、何を捨てるかにある。最も捨てやすいのはツール呼び出しとその結果だ。メッセージ履歴にすでに入っているなら、それらを持ち続ける必要はほとんどない。
• Sonnet 4.5で導入されたメモリツールにより、Context Editingが可能になった: https://www.anthropic.com/news/context-management

2) 構造化ノートテイキング

• エージェンティックメモリとも呼ばれる。定期的にコンテキストウィンドウの外側（つまりファイルシステム）にノートを残し、後で取り出す手法だ。
• 同様に、Sonnet 4.5からはメモリツールによってこの手法がより使いやすくなった。

3) サブエージェントアーキテクチャ

• メインエージェントが大局的な計画を立てて調整し、サブエージェントたちが深い技術的作業を行ったり、ツールを使って関連情報を探したりする手法だ。
• マルチエージェント調査システムをどのように構築したか を述べた記事を参照。

結論

• モデルが強力になるにつれて、単にプロンプトをうまく作るだけでなく、各段階でどの情報を「注意予算」の中に入れるかを選別することが重要な課題になった。
• 長期タスクのための圧縮を実装するにせよ、トークン効率の高いツールを設計するにせよ、エージェントが適切なタイミングで環境を探索できるようにするにせよ、これらの指針となる原則は同じである。すなわち、望ましい結果の可能性を最大化する、最小の高シグナルトークン集合を見つけることだ。
• この文章で紹介された手法は、モデルの改善とともに継続的に進化し、より自律的に動くようになるだろうが、それでもなお「コンテキストは貴重で有限な資源である」という見方は、信頼できて効果的なエージェント構築の中核であり続けるだろう。
• 詳しくは メモリおよびコンテキスト管理クックブック を参照してほしい。