AIエージェントのための効果的なコンテキストエンジニアリング

!NOTE原文: Effective context engineering for AI agents (Anthropic Engineering Blog, 2025年9月29日公開)

!TIP

Claude Codeユーザーへの適用可能性評価

テクニック	Claude Codeでの適用	説明
システムプロンプト設計	✅ 適用可能	CLAUDE.md、.claude/rules/ で実装可能
ツール設計の原則	⚠️ 間接的に適用	MCP サーバー設計時に参考になる
Few-shot例の活用	✅ 適用可能	CLAUDE.md にサンプルコード記載可能
Just-in-time検索	✅ 既に実装済み	Claude Codeはglob/grepで動的にファイル取得
コンパクション（圧縮）	✅ 自動適用	Claude Codeは長いセッションで自動圧縮
構造化メモ取り	✅ 適用可能	タスクリスト機能、外部ファイルへのメモ書き出し
サブエージェント構造	❌ 直接は不可	Claude Code単体では未対応（将来的に可能性あり）
ハイブリッド検索戦略	✅ 既に実装済み	CLAUDE.md（事前読込）+ glob/grep（動的取得）

はじめに

何年もの間、応用AI分野ではプロンプトエンジニアリングが主要な議論のテーマでした。しかし今、コンテキストエンジニアリングが新たな焦点として浮上しています。完璧なフレーズを作り上げることではなく、核心的な問いは「モデルに望ましい振る舞いを生成させる最も適切なコンテキスト構成は何か」というものになりました。

コンテキストとは、LLMからサンプリングする際に含まれるトークンを指します。エンジニアリングの課題は、望ましい結果を得るためにLLMの制約に対してトークンの有用性を最適化することです。これには「コンテキストで考える」こと—LLMが利用可能な包括的な状態と、それが生み出す可能性のある振る舞いを考慮すること—が必要です。

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

Anthropicでは、コンテキストエンジニアリングはプロンプトエンジニアリングの自然な進化形と捉えています。プロンプトエンジニアリングがLLMへの指示の書き方と構成に焦点を当てるのに対し、コンテキストエンジニアリングは推論時に最適なトークンをキュレーションし維持するための戦略全体を包含します。これには以下が含まれます：

• システム指示
• ツール
• Model Context Protocol（MCP）
• 外部データ
• メッセージ履歴

初期のLLMエンジニアリングは、ワンショット分類やテキスト生成のためのプロンプティングを優先していました。しかし、エージェントが複数の推論ターンにわたって、より長い時間軸で動作するようになると、コンテキスト状態全体の管理が不可欠になります。ループ内のエージェントは、循環的な洗練を必要とする、ますます関連性の高いデータを生成します。コンテキストエンジニアリングは、絶えず進化する情報から限られたコンテキストウィンドウに何を入れるかをキュレーションする「技術と科学」なのです。

なぜコンテキストエンジニアリングが優れたエージェントに重要なのか

処理能力を持っていても、LLMは—人間と同様に—集中力の低下を経験します。「干し草の山の中の針」ベンチマークは**コンテキストの劣化（context rot）**を明らかにしました：コンテキストトークンが増えるにつれて、正確な情報想起が低下するのです。

コンテキストは有限で収穫逓減があるものとして扱う必要があります。人間が「限られたワーキングメモリ容量」を持つように、LLMには新しいトークンごとに消耗する注意力予算があります。この希少性はLLMのアーキテクチャに起因します：トランスフォーマーはコンテキスト全体で各トークンが他のすべてのトークンに注意を向けることを可能にし、nトークンに対してn²のペアワイズ関係を作り出します。

コンテキストが長くなるにつれて、これらの関係を捉えることは薄く引き伸ばされ、コンテキストサイズと注意力の集中の間に緊張関係が生まれます。モデルは、短いシーケンスが支配的な訓練データから注意パターンを発達させ、長距離の依存関係に対する経験が限られています。

「位置エンコーディング補間」のような技術は、元々訓練されたコンテキストへの適応を通じてより長いシーケンスを可能にしますが、位置理解に劣化が見られます。これは厳密な崖ではなくパフォーマンスの勾配を生み出します—モデルはより長いコンテキストでも高い能力を維持しますが、情報検索と長距離推論において精度が低下します。

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

良いコンテキストエンジニアリングは、**「望ましい結果の可能性を最大化する、最小限の高シグナルトークンセット」**を見つけることです。

システムプロンプト

システムプロンプトは極めて明確で直接的であるべきで、アイデアを「適切な高度」で提示します—これは失敗の間のゴルディロックスゾーン（適切な中間点）です。

一方の極端は複雑で脆いロジックをプロンプトにハードコーディングすることで、脆弱性とメンテナンスの複雑さを生み出します。もう一方の極端は具体的なシグナルを提供できず、共有コンテキストを誤って仮定する曖昧で高レベルのガイダンスを提供することです。最適な高度は具体性と柔軟性のバランスを取ります。

プロンプトを明確なセクション（<background_information>、<instructions>、## ツールガイダンス、## 出力の説明など）に整理し、XMLタグやMarkdownヘッダーを使用します。期待される振る舞いを完全に概説する最小限の情報を目指してください。最小限は短いという意味ではなく、エージェントは十分な事前情報が必要です。利用可能な最良のモデルで最小限のプロンプトのテストを開始し、失敗モードに基づいて指示と例を追加していきます。

ツール

ツールはエージェントが環境と対話し、新しいコンテキストを取得することを可能にします。ツールは以下であるべきです：

• 自己完結型
• エラーに対してロバスト
• 意図された使用について極めて明確

入力パラメータは説明的で、曖昧でなく、モデルの強みを活用するべきです。

一般的な失敗には、機能をカバーしすぎる肥大化したツールセットや曖昧な判断ポイントの作成があります。エンジニアが状況においてどのツールが適用されるかを明確に特定できなければ、エージェントにそれ以上のことを期待できません。最小限の実行可能なツールセットは、長いインタラクション中の信頼性の高いメンテナンスとコンテキストの刈り込みを可能にします。

例（Few-shotプロンプティング）

例（few-shotプロンプティング）はベストプラクティスであり続けます。しかし、すべての可能なルールを明確にしようとするエッジケースのリストを詰め込むことは避けてください。代わりに、期待される振る舞いを効果的に描写する多様で標準的な例をキュレーションしてください。

LLMにとって、**例は「千の言葉に値する画像」**です。

コンテキストコンポーネント全体に対する全体的なガイダンス：思慮深く、コンテキストを情報豊かでありながらタイトに保つこと。

コンテキスト取得とエージェント型検索

エージェントの単純な定義—「ループ内で自律的にツールを使用するLLM」—に従うと、この分野はこのパラダイムに収束しています。

従来、多くのアプリケーションは、重要なコンテキストを表面化させる埋め込みベースの推論前検索を採用していました。この分野がよりエージェント型のアプローチに移行するにつれて、チームは検索システムを**「ジャストインタイム」コンテキスト戦略**で補強しています。

ジャストインタイム検索

すべてのデータを事前に処理するのではなく、「ジャストインタイム」エージェントは軽量な識別子（ファイルパス、クエリ、Webリンク）を維持し、ツールを使用して実行時にデータを動的にロードします。

Claude Codeは大規模データベース上で複雑なデータ分析を実行し、対象を絞ったクエリを書き、headやtailのようなBashコマンドを活用して、完全なデータオブジェクトをコンテキストにロードすることなく処理します。これは人間の認知を反映しています：情報コーパスを記憶するのではなく、人間はファイルシステム、受信トレイ、ブックマークなどの外部組織システムを使用して、必要に応じて関連情報を取得します。

これらの参照からのメタデータは、明示的に提供されるか直感的であるかにかかわらず、効率的に振る舞いを洗練します。testsフォルダ内のtest_utils.pyのようなファイル名は、src/core_logic/内の同一の名前とは異なる目的を示します。フォルダ階層、命名規則、タイムスタンプは、人間とエージェントが情報の活用方法を理解するのに役立つシグナルを提供します。

段階的開示（Progressive Disclosure）

自律的なエージェントナビゲーションは段階的開示を可能にします—探索を通じて関連するコンテキストを段階的に発見することです：

• ファイルサイズは複雑さを示唆
• 命名規則は目的をほのめかす
• タイムスタンプは関連性の代理指標

エージェントは層ごとに理解を組み立て、必要なワーキングメモリのみを維持し、永続化のためにメモ取りを活用します。自己管理されたコンテキストウィンドウは、網羅的な情報に溺れるのではなく、エージェントを関連するサブセットに集中させます。

トレードオフ

トレードオフは存在します：実行時の探索は事前計算された検索より遅いです。適切なガイダンスなしでは、エージェントはツールの誤用、行き止まり、または重要な情報の見落としによってコンテキストを浪費します。

効果的なエージェントは、速度のために一部のデータを事前に取得しながら、自律的な探索を追求するハイブリッド戦略を採用するかもしれません。Claude Codeはこれを例示しています：CLAUDE.mdファイルは素朴にコンテキストに投入される一方、globやgrepのようなプリミティブは、古いインデックス作成や複雑な構文木をバイパスしてジャストインタイムのファイル取得を可能にします。

ハイブリッド戦略は、法務や財務業務のようなあまり動的でないコンテキストに適しています。モデルが改善するにつれて、エージェント設計は、人間のキュレーションを徐々に減らしながら、知的なモデルに知的に行動させる方向にトレンドしています。「うまくいく最も単純なことをする」は、Claudeでエージェントを構築するチームにとって、おそらく最良のアドバイスであり続けるでしょう。

長期タスクのためのコンテキストエンジニアリング

長期タスクは、エージェントがLLMのコンテキストウィンドウを超えるアクションシーケンス全体で一貫性、コンテキスト、目標指向の振る舞いを維持することを必要とします。数十分から複数時間にわたるタスク—大規模なコードベース移行や包括的な調査など—には、専門的なコンテキスト制限技術が必要です。

より大きなコンテキストウィンドウは明らかな解決策に見えますが、予見可能な将来のウィンドウはコンテキスト汚染と関連性の懸念に直面するでしょう。拡張された時間軸での効果を可能にするために、Anthropicは3つの技術を開発しました：コンパクション（圧縮）、構造化されたメモ取り、マルチエージェントアーキテクチャ。

コンパクション（圧縮）

コンパクションは、コンテキスト制限に近づいた会話を要約し、要約でウィンドウを再初期化します。これは通常、より良い長期的一貫性を推進するための最初のコンテキストエンジニアリングのレバーとして機能し、高忠実度のコンテキストウィンドウの内容を蒸留して、最小限の劣化で継続を可能にします。

Claude Codeはこれを、メッセージ履歴をモデルに渡して重要な詳細を要約・圧縮することで実装しています。モデルは以下を保持します：

• アーキテクチャの決定
• 未解決のバグ
• 実装の詳細

一方で、冗長なツール出力やメッセージは破棄します。エージェントは圧縮されたコンテキストと最近アクセスした5つのファイルで継続します。ユーザーはコンテキストの制限なしに継続性を得られます。

コンパクションの芸術は選択にあります—何を残し何を破棄するか—積極的なコンパクションは後で明らかになる微妙で重要なコンテキストを失う可能性があるためです。実装においては、複雑なエージェントトレースでプロンプトを慎重に調整してください。すべての関連するトレースの詳細が捕捉されるように想起を最大化することから始め、次に余分なコンテンツを排除することで精度を改善するために反復します。

低位置にある余分なコンテンツには、ツール呼び出しと結果のクリアが含まれます—履歴の深くで呼び出されたら、なぜエージェントは再び生の結果を必要とするでしょうか？ツール結果のクリアは安全で軽いタッチのコンパクションを表し、最近Claude Developer Platformの機能としてリリースされました。

構造化されたメモ取り

構造化されたメモ取り（エージェント型メモリ）は、エージェントがコンテキストウィンドウの外に永続化されるノートを定期的に書き、後で引き戻すことを含みます。

これは最小限のオーバーヘッドで永続的なメモリを提供します。Claude Codeがやることリストを作成したり、カスタムエージェントがNOTES.mdファイルを維持したりするように、このシンプルなパターンはエージェントが複雑なタスク全体で進捗を追跡し、数十のツール呼び出しにわたって失われる可能性のある重要なコンテキストと依存関係を維持することを可能にします。

ClaudeがPokemonをプレイすることは、非コーディングドメインでメモリが能力を変革することを実証しています。エージェントは数千のステップにわたって正確な集計を維持します—「過去1,234ステップで、私はルート1でポケモンを訓練しており、ピカチュウは目標の10に対して8レベル上がった」などの目標を追跡します。メモリ構造のプロンプトなしに、探索した地域のマップを開発し、アンロックした実績を覚え、どの攻撃が相手に効くかを学習する戦略的な戦闘ノートを維持します。

コンテキストリセット後、エージェントはノートを読んで複数時間のシーケンスを継続します。要約全体でのこの一貫性は、すべての情報をコンテキストだけに保持することでは不可能な長期戦略を可能にします。

Sonnet 4.5のリリースに伴い、AnthropicはClaude Developer Platformでパブリックベータとしてメモリツールをリリースし、ファイルベースのシステムを通じてコンテキストウィンドウ外の情報保存を容易にしました。これにより、エージェントは時間をかけて知識ベースを構築し、セッション間でプロジェクトの状態を維持し、すべてをコンテキストに保持することなく以前の作業を参照することができます。

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

サブエージェントアーキテクチャはコンテキストの制限を回避します。単一のエージェントがプロジェクト全体で状態を維持するのではなく、専門化されたサブエージェントがクリーンなコンテキストウィンドウで集中したタスクを処理します。メインエージェントは高レベルの計画で調整し、サブエージェントは深い技術的作業を実行したり、関連情報を見つけたりします。各サブエージェントは数万トークンを使用して広範囲に探索し、凝縮された要約のみ（通常1,000〜2,000トークン）を返す可能性があります。

これは明確な関心の分離を達成します—詳細な検索コンテキストはサブエージェント内で分離され、リードエージェントは結果を統合・分析します。このパターンは、「マルチエージェント研究システムの構築方法」で議論され、複雑な研究タスクで単一エージェントシステムに対して大幅な改善を示しました。

タスク特性に基づくアプローチ選択

モデルが改善しても、拡張されたインタラクション全体での一貫性の維持は、効果的なエージェント構築の中心であり続けます。

結論

コンテキストエンジニアリングは、LLM構築における根本的な転換を表しています。モデルがより有能になるにつれて、課題は完璧なプロンプトを作成することを超えて、モデルの限られた注意力予算に入る情報を思慮深くキュレーションすることに拡張されます。長期タスクのためのコンパクションの実装、トークン効率の良いツールの設計、またはジャストインタイムで環境探索を可能にするかどうかにかかわらず、指導原則は一定のままです：

望ましい結果の可能性を最大化する、最小限の高シグナルトークンセットを見つけること。

これらの技術はモデルが改善するにつれて進化し続けるでしょう。よりスマートなモデルはより少ない規範的エンジニアリングを必要とし、より大きな自律性を可能にします。能力がスケールしても、コンテキストを貴重で有限なリソースとして扱うことは、信頼性が高く効果的なエージェントを構築する上で中心的であり続けます。

謝辞

AnthropicのApplied AIチームによる執筆：Prithvi Rajasekaran、Ethan Dixon、Carly Ryan、Jeremy Hadfield。Rafi Ayub、Hannah Moran、Cal Rueb、Connor Jenningsからの貢献あり。Molly Vorwerck、Stuart Ritchie、Maggie Voのサポートに特別な感謝を。

公開日: 2025年9月29日