コンテキストエンジニアリング
コンテキストエンジニアリングとは、LLMが受け取るコンテキスト（指示、検索結果、ツール、メモリ、会話履歴）を設計・管理し、可能な限り最良の出力を引き出すための分野です。これは、文言に焦点を当てるプロンプトエンジニアリングを包含する、より広範な概念であり、何を、どの形式で、いつコンテキストに入れるかに対応します。
コンテキストエンジニアリングとは、推論時にLLMのコンテキストウィンドウを満たすトークン（指示、検索結果、ツール、メモリ、会話履歴）を設計・管理するための分野です。
プロンプトエンジニアリング、つまりプロンプト文言そのものを洗練させる技術は、プロンプトが全体のコンテキストの一部にすぎないため、コンテキストエンジニアリングのサブセットです。
Anthropicはこれを「推論中に最適なトークン集合を選定し、維持するための一連の戦略」と定義しています（2025年9月）。
LangChainは、コンテキストを扱うための4つの戦略として、write、select、compress、isolate を挙げています。
コンテキストウィンドウが「容量（RAM）」だとすれば、コンテキストエンジニアリングは、その限られた空間に何を入れるかを設計・管理する実践に焦点を当てています。
概要
コンテキストエンジニアリングとは、LLMがタスクを実行する際に与えられるコンテキスト全体、すなわちシステム指示、検索結果、ツール定義、長期メモリ、会話履歴を設計・管理し、最良の出力を引き出すための分野です。同じモデルでも、どの情報がコンテキストウィンドウに入り、どのような形式で入るかによって結果は大きく変わるため、コンテキストの構築はモデル選定と同じくらい出力品質を左右します。
Google DeepMindのPhil Schmidは、コンテキストエンジニアリングを「LLMがタスクを達成するために必要なすべてを与えるべく、適切な情報とツールを、適切な形式で、適切なタイミングで提供する動的システムを設計・構築する分野」と定義しています（2025年6月）。彼は、コンテキストは「文字列ではなくシステム」として扱うべきだと強調し、エージェントの失敗は通常モデルの限界ではなくコンテキストの質に起因すると説明しています。
この概念は特にAIエージェントの環境で重要になります。そこでは、ツールが呼び出され、メモリが1回の質疑応答ではなく複数のステップにわたって蓄積されるためです。タスクが長引くほど、ツールの結果や中間出力が積み重なり、コンテキストウィンドウの上限を超えたり、コストやレイテンシが増加したり、パフォーマンスが低下したりしやすくなります。
プロンプトエンジニアリングvs. コンテキストエンジニアリング
この2つは対立概念ではなく、包含関係にあります。Anthropicは、プロンプトエンジニアリングを「最適な結果を得るためにLLMの指示を記述・整理する手法」と区別し、コンテキストエンジニアリングを「推論中に最適なトークン集合を選定し、維持するための一連の戦略」と定義しています。つまり、プロンプトエンジニアリングはコンテキストエンジニアリングの一部であり、よく書かれたプロンプトは依然として重要ですが、本番環境のエージェントでは、それは全体コンテキストの一要素にすぎません。
項目 | プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|---|
扱う対象 | モデルに送るテキスト（指示と質問） | 全体のコンテキストウィンドウ（指示、ツール、メモリ、検索結果、履歴） |
中心となる問い | どのような文言で、どのように指示するか | 何を、どの形式で、いつ含めるか |
性質 | 静的な文字列を書くこと | 動的なシステムを設計・管理すること |
主な領域 | 単発の質問応答 | マルチステップのエージェント、長時間実行されるタスク |
関係性 | コンテキストエンジニアリングの一部 | プロンプトエンジニアリングを包含する、より広い概念 |
コンテキストの構成要素
Phil Schmidは、コンテキストを構成する7つの要素を挙げています。コンテキストエンジニアリングとは、これらの要素を選定し、配置する作業です。
指示 / system prompt— エージェントの行動ルールと例を定める初期指示
ユーザープロンプト— 対応すべき直近の質問またはタスク
状態 / 履歴（短期記憶）— これまでに交わされた現在の会話
長期記憶— 過去の会話や学習済みの好みに基づいて蓄積された知識
取得した情報（RAG）— ドキュメント、データベース、API から取得した新しい外部知識
利用可能なツール— モデルが呼び出せる関数定義
構造化出力— JSON スキーマなどの応答フォーマット仕様
コア戦略とエビデンス
2025年7月のブログ投稿で、LangChain はさまざまなエージェントと論文を分析し、コンテキストエンジニアリングの4つの共通戦略を抽出した。同記事では Andrej Karpathy の比喩を引用し、LLM を「新しい種類のオペレーティングシステム」にたとえ、「LLM は CPU であり、コンテキストウィンドウはその作業メモリとして機能する RAM だ」と説明している。RAM の容量に限りがあるのと同様に、要点はその限られた空間にどの情報を読み込むかを決めることにある。
Write— スクラッチパッドやメモリを使ってコンテキストウィンドウの外に情報を保存し、後で書き戻す。
Select— メモリ、ツール、RAG などを通じて、必要な情報だけをコンテキストウィンドウに取り込む。
Compress— 要約とトリミングを使って、「タスクを実行するのに必要なトークンだけ」を保持する。
Isolate— 複数のエージェント、サンドボックス、または状態オブジェクト間でコンテキストを分離し、それぞれを個別に管理する。
Anthropic も同様に、2025年9月のエンジニアリング投稿で長時間実行タスク向けの具体的な手法を提示している。Compactionはコンテキストの内容を要約し、その要約から新しいコンテキストウィンドウを再起動する。一方、structured note-takingは、エージェントがコンテキストウィンドウの外にメモを残し、後でそれを呼び出すことで、最小限のオーバーヘッドで永続的なメモリを維持する。これらに加えて、同社は次のようなパターンも推奨している。サブエージェントをクリーンなコンテキストハンドルで使うと、集中した作業を行い、圧縮された要約だけを返せます。あわせて、just-in-time retrievalは、すべてのデータを事前に読み込むのではなく軽量な識別子だけを保持し、実行時に必要なデータを取得する仕組みです。
実行チェックリスト
システムプロンプトは、十分な具体性を持たせつつ、過度に細かくも曖昧でもない、明確で直接的な言葉で書く。
ツールは最小限に絞り、ツール結果にはモデルが次の行動を判断するために必要なメタデータだけを含め、長すぎる結果は切り詰める。
長いタスクでは、会話履歴を無限に蓄積させず、要約と圧縮を使って「必要なトークンだけ」に保つ。
メモリは、状態データをJSONのような構造化形式に分け、進捗メモは非構造化テキストとして分けて管理する。
すべての情報を事前に注入するのではなく、識別子だけを保持し、必要な瞬間に just-in-time retrieval で取得する。
1つのコンテキストでは大きすぎるタスクは、サブエージェントに分割し、要約だけを回収する。