コンテキストエンジニアリング完全ガイド：AIに何を見せるかを設計する
LLMの有限な注意予算に対して、指示・ツール・外部データ・履歴・メモリを選択、構造化、圧縮、分離するコンテキストエンジニアリングを体系的に解説します。
コンテキストエンジニアリングとは
コンテキストエンジニアリングとは、LLMが推論する瞬間に利用できる情報を、目的に合わせて選び、構造化し、維持する設計活動です。
Anthropicは、コンテキストを「推論時にモデルへ含まれるトークンの集合」と捉え、その有限な注意予算から最大の効用を得る問題として説明しています。重要なのは、情報を多く渡すことではありません。望む行動につながる、最小限で高シグナルな情報を渡すことです。
コンテキストには次が含まれます。
- システム指示とユーザーの依頼
- 会話履歴
- 取得した文書やデータ
- ツール定義とツール実行結果
- 画像などのマルチモーダル入力
- タスク状態と外部メモリ
- サブエージェントからの報告
プロンプトエンジニアリングとの違い
| 観点 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
| 主な対象 | 指示の内容と表現 | 推論時に見せる情報全体 |
| 時間軸 | 1回のモデル呼び出しが中心 | 複数ターン・長時間タスク |
| 操作 | 明確化、例示、出力形式 | 選択、取得、圧縮、分離、永続化 |
| 失敗例 | 指示が曖昧 | 情報過多、古い状態、誤った取得 |
両者は競合しません。プロンプトはコンテキストの一部です。
Context・Harness・Loop・Graphの関係
| 領域 | 設計対象 |
|---|---|
| Context Engineering | 各推論でモデルに見せる情報 |
| Harness Engineering | 1回のエージェント実行を支える環境・ツール・検証 |
| Loop Engineering | 実行・評価・再試行・停止の反復サイクル |
| Graph Engineering | 分岐・並列・合流を含むワークフロー全体 |
ループの各周回でコンテキストが再構成され、ハーネス内で実行されます。複数経路が必要ならグラフとして表現します。
コンテキストは有限の注意予算
コンテキストウィンドウの公称上限と、タスクで有効に使える情報量は同じではありません。ChromaのContext Rot研究などでは、入力長、情報の類似性、配置、タスクの性質によって性能低下の仕方が変わることが示されています。
「上限の何％までなら安全」という共通の固定値はありません。次を実タスクで評価します。
- 必要情報を正しく取り出せるか
- 無関係な情報に引きずられないか
- 指示や重要な制約を保持できるか
- ツール選択を誤らないか
- コストと待ち時間が許容範囲か
5つの基本操作
1. Write：外部へ書く
すべてを会話履歴へ残さず、タスク状態、計画、証拠、成果物を外部へ保存します。
- 進捗ファイル
- Git履歴
- 構造化されたタスク一覧
- データベース
- オブジェクトストレージ
外部保存した情報は、誰が、いつ、どの条件で読み戻すかまで設計します。
2. Select：必要な情報を選ぶ
検索、フィルタリング、権限制御によって、現在の推論に必要な情報だけを取得します。
- キーワード・ベクトル・ハイブリッド検索
- メタデータフィルタ
- ツール検索
- ファイルパスやURLを使ったJust-in-time取得
Anthropicは、すべてを事前投入する方法だけでなく、軽量な参照を持たせてエージェント自身に必要な情報を取得させる方法を紹介しています。
3. Structure：構造化する
情報の境界、優先順位、出典、版を明示します。
目的 制約 現在の状態 参照データ 利用可能なツール 期待する出力 完了条件
構造化は装飾ではなく、異なる種類の情報を混同させないために行います。
4. Compress：圧縮する
長時間タスクでは、履歴やツール結果を要約・トリミングします。
- 古いツール出力を成果と失敗理由へ変換
- 重複した会話を削除
- 完了済み作業を状態スナップショットへ変換
- 大きな成果物は参照だけ残す
要約によって失われた情報を復元できるよう、原文や成果物への参照を保持します。
5. Isolate：分離する
タスクごとにコンテキスト境界を作ります。
- サブエージェントへ限定された入力だけを渡す
- 生成と評価でコンテキストを分ける
- 機密情報を不要なツールや担当へ渡さない
- 長い履歴を新しいセッションへそのまま引き継がない
分離はトークン節約だけでなく、安全性と責任分界にも効きます。
コンテキストの構成要素
指示
役割だけでなく、目的、制約、判断基準、完了条件を含めます。細かい手順を過剰に固定すると、モデル改善後も古い制約が残ります。
外部データ
RAGは有力な取得方法ですが、常にベクトル検索が必要とは限りません。ファイル検索、SQL、API、全文検索、知識グラフなど、データと質問に適した取得方法を選びます。
ツール
ツール名、説明、入力スキーマ、出力、失敗時の情報がモデルの判断材料です。大量のツール定義を常時投入せず、名前空間やツール検索で絞ります。
履歴と状態
会話履歴は「何が話されたか」、タスク状態は「今どこにいるか」を表します。長時間処理では両者を分離し、状態を外部の正本として持ちます。
メモリ
メモリには、ユーザー設定、過去の出来事、事実、手順など異なる種類があります。保存条件、検索条件、更新・削除方法、出典を決めずに蓄積すると、古い情報が新しい判断を汚染します。
典型的な失敗
情報を全部入れる
取得漏れは減っても、関連性、コスト、指示追従が悪化します。
要約だけを正本にする
要約ミスを検証できません。原文への参照を残します。
古い状態を再利用する
データやコードが更新された後も古い評価結果を使うと、誤った完了判定になります。入力版を記録します。
ツール出力を無加工で戻す
巨大なログやAPIレスポンスが注意を消費します。エラー、重要値、成果物参照へ整形します。
メモリを無制限に増やす
保存より、検索・更新・忘却の設計が重要です。
実践手順
- タスクの成功条件を定義する
- モデルが判断に必要な情報を列挙する
- 常時必要な情報とJust-in-time取得を分ける
- 情報ごとに正本、版、権限を定義する
- コンテキスト予算を指示・データ・履歴・出力へ配分する
- 長時間化した場合の圧縮と外部状態を設計する
- 生成・評価・専門タスクの分離を検討する
- 実タスクで精度・コスト・待ち時間を評価する
- 失敗例を基に取得・圧縮・構造を更新する
評価指標
- タスク成功率
- 必要情報の取得率
- 不要情報の混入率
- 根拠との整合性
- ツール選択の正確さ
- 入力・出力トークン
- 1件成功あたりの費用
- コンテキスト構築時間
単一のRAG指標だけでなく、最終タスクが成功したかを確認します。