Context Engineering

ひとことで言うと：Context Engineeringは、LLMやAIエージェントが各推論時点で必要な情報・指示・履歴・ツール情報などを、限られたコンテキストへ適切に選び、構成し、維持するための設計です。^[1][2][3]

Context Engineeringとは

Context Engineering（コンテキストエンジニアリング）は、LLMやAIエージェントがタスクを実行するとき、その時点でモデルへ渡す情報をどのように選び、構成し、更新し、削減するかを設計する考え方です。

2025年以降、AIエージェントの実務で広く使われるようになった比較的新しい用語で、Prompt Engineeringより広い範囲を扱います。システム指示、ユーザーの依頼、会話履歴、検索結果、ツール定義、ツール実行結果、メモリ、ファイル内容、状態情報など、モデル呼び出し時にコンテキストへ入るさまざまな情報が対象になります。

Prompt Engineeringとの違い

Prompt Engineeringは、主にモデルへ与える指示や例をどう書くか、どう構成するかに焦点を置きます。Context Engineeringは、それに加えて「そもそも何をモデルに見せるか」「どの情報を今は見せないか」「長い履歴をどう圧縮するか」「外部情報をいつ検索するか」「どのツールだけを使える状態にするか」まで扱います。

たとえばカスタマーサポートAgentを考えます。Prompt Engineeringでは「丁寧に回答し、返金規則を守る」といった指示文を設計します。Context Engineeringでは、現在の顧客情報、該当商品の注文履歴、最新の返金規程、必要なツール、直近の会話要約だけを選んでモデルへ渡す、といったシステム全体を設計します。

したがって両者は排他的ではありません。Prompt EngineeringはContext Engineeringの重要な一部と考えるのが実用的です。

なぜ重要なのか

LLMのコンテキストウィンドウには上限があります。上限が非常に長くなっても、無関係な情報を大量に入れればよいわけではありません。必要情報がノイズに埋もれたり、古い情報と新しい情報が衝突したり、コストやLatencyが増えたりします。

AIエージェントでは、ツールを何度も呼び、検索結果やコード実行ログ、途中生成物が蓄積します。単純にすべての履歴を毎回LLMへ渡すと、長時間タスクほどコンテキストが膨張します。

そのためContext Engineeringでは、「高信号な情報を必要な時点で渡し、不要になった情報は外へ逃がす／圧縮する」という考え方が中心になります。

Contextには何が含まれるのか

製品や実装によって定義は少し異なりますが、典型的には次のような情報が含まれます。

• System / Developer instructions
• User message
• Conversation history
• Few-shot examples
• Retrieved documents
• Tool definitions
• Tool call results
• Memory
• Current task state
• Filesやコードの抜粋
• Output schemaや制約
• Subagentからのhandoff

Context Engineeringは、これらを全部詰め込むことではありません。タスクの次の一手に必要なものを選び、適切な形式で渡すことです。

Select：必要な情報を選ぶ

最も基本的な戦略は、巨大な情報集合から関連部分だけを選ぶことです。RAGはその代表例です。ナレッジベース全体をプロンプトへ入れず、質問に関連するチャンクだけをRetrievalして渡します。

コードAgentなら、リポジトリ全体ではなく、対象ファイル、参照される型定義、エラーログなどを検索して選びます。ツールが数百個ある場合は、すべてのtool descriptionを常時渡さず、タスクに関係するツールだけを選択する設計もあります。

ここでRetrieval品質がContext Engineering品質に直結します。必要情報が存在していても選択に失敗すれば、モデルから見ると「知らない」のと同じです。

Write / Offload：外部へ書き出す

すべての情報をコンテキストウィンドウに保持せず、ファイル、メモリストア、データベース、scratchpadなど外部状態へ書き出す設計があります。

長い調査では、各検索結果を全部会話履歴へ残す代わりに、確認済み事実や引用候補を構造化ファイルへ保存し、必要な部分だけ再読込します。Coding Agentでは、大量のコードやログをファイルシステムに置いたまま、検索コマンドで必要箇所だけ読む方が効率的な場合があります。

このとき「外部に保存した＝モデルが覚えている」ではありません。次の推論で必要なら再び選択してコンテキストへ戻す仕組みが必要です。

Compress：圧縮する

会話が長くなったとき、古いメッセージを要約して置き換えるContext CompactionやSummarizationがあります。ツール出力の長大なJSONを短い要点へ変換することもあります。

圧縮には情報損失があります。要約時に数値、条件、例外、ファイル名などを落とすと、後の推論で誤りが生じます。そのため、すべてを自然文要約にするのではなく、「決定事項」「未解決事項」「正確な識別子」「引用必須部分」などを構造化して保持する設計が重要です。

Context CompressionとContext Engineeringは同義ではありません。CompressionはContext Engineeringの一手段です。

Isolate：コンテキストを分離する

複雑なタスクでは、Subagentごとに独立したコンテキストを持たせる方法があります。たとえば、調査担当、コード担当、レビュー担当がそれぞれ必要な情報だけを持ち、最終的に結果をhandoffします。

利点は、各Agentのコンテキストを狭く保てることです。一方、重要情報がhandoffで落ちる、Agent間で前提がずれる、同じ調査を重複する、といった問題もあります。

「Multi-AgentにすればContext Engineeringが不要」ではなく、むしろどの情報をどのAgentへ渡すかという新しいContext Engineering問題が生まれます。

Worked example

長時間動くResearch Agentが「日本のAI規制の最新動向」を調査するとします。

悪い設計では、検索結果20ページ分、各PDF全文、途中の推論、重複ニュース、古い法案をすべて会話履歴へ積み上げます。モデル呼び出しのたびに膨大なContextを再送し、古い情報と最新情報が混ざります。

より良い設計では、次のように分けます。

1. 最新性の高い公式資料を検索する。
2. 出典URL、日付、確定事項、未確定事項をEvidence Storeへ保存する。
3. 各論点を執筆するとき、その論点に必要な資料だけ選択して読み込む。
4. 古い検索ログはコンテキストから外す。
5. 法案と施行済み法令を別フィールドで保持する。
6. 最終レビューでは主張と証拠の対応だけを再投入する。

これは単なる「良いプロンプトを書く」問題ではなく、情報のライフサイクルを設計する問題です。

Context Windowが長ければ不要になるのか

コンテキストウィンドウが100万tokenあればContext Engineeringは不要、とは限りません。大きな窓は選択肢を増やしますが、コスト、Latency、注意の分散、情報衝突、古い状態の混入は残ります。

また、ユーザーの全ファイルや全履歴を常にモデルへ渡すことは、プライバシーや権限制御の観点からも望ましくない場合があります。「入るか」ではなく「入れるべきか」を判断する必要があります。

長いContextを使うことと、良いContextを作ることは別問題です。

Memoryとの違い

Memoryは、過去の情報を将来のターンで再利用できるよう保存・取得する仕組みです。Context Engineeringは、そのMemoryを含め、現在のモデル呼び出しへ何を入れるかを扱う上位の設計概念です。

保存されたMemoryが多すぎると、誤った記憶や古い情報を取り出す可能性があります。何を保存するか、いつ忘れるか、どのユーザー／タスクに属するか、どのMemoryをRetrievalするかもContext Engineeringの対象になります。

Context Engineeringの評価

Context Engineeringは、単にtoken数を減らせば成功ではありません。必要な情報を落として性能が下がれば失敗です。

評価では、タスク成功率、Retrieval Recall、Tool selection accuracy、回答品質、Latency、token cost、長時間タスクでのエラー率などを見ます。変更前後で同じEval setを使い、「圧縮したら安くなったが重要条件を落とした」といった退行を検出することが必要です。

Observabilityも重要です。実際のモデル呼び出しに何が入っていたかを追跡できなければ、Context不足なのかモデル能力不足なのかを切り分けにくくなります。

次に起こりやすい誤解

第一の誤解は、「Context EngineeringはPrompt Engineeringの新しい言い換え」というものです。重なる部分はありますが、Retrieval、Memory、Tool result、Compaction、Subagent isolationなど、静的なPrompt文面を越える範囲を含みます。

第二の誤解は、「情報を多く渡すほどAgentは賢くなる」というものです。不要な情報はコストだけでなく、誤判断の原因にもなります。

第三の誤解は、「Context Engineeringという標準化された単一手法がある」という理解です。比較的新しい実務用語であり、企業やフレームワークによって分類や強調点は異なります。共通する中心は、モデルが次の推論を行うために適切なContextを構成・維持することです。

元文脈へ戻るためのチェックリスト

Context Engineeringという語を製品や記事で見たら、次を確認します。

• Contextに何を含める定義か。
• Prompt Engineeringとの境界をどう置いているか。
• Retrievalで何を選択するか。
• Memoryはどこに保存し、いつ再取得するか。
• Tool definitionやtool resultをどう削減するか。
• 長い会話をいつSummarize／Compactするか。
• ファイルや外部ストレージへ何をoffloadするか。
• Subagent間で何をhandoffするか。
• 権限やプライバシーに応じてContextを隔離するか。
• 品質、token、LatencyをどのEvalで測るか。

Context Engineeringという言葉だけから、特定のフレームワークやアルゴリズムを意味すると推論してはいけません。これは、LLMへ何を見せるかというシステム設計上の問題をまとめて捉える概念です。元の文脈では、具体的にどの情報源・状態・圧縮・検索・ツール選択を指しているかを確認することが重要です。

Contextの優先順位と衝突

Contextには、system instruction、developer instruction、user message、retrieved document、tool resultなど性質の違う情報が混在します。内容が矛盾したとき、モデルがどれを優先すべきかを設計しないと、長時間タスクで挙動が不安定になります。

とくに外部文書やWebページは「データ」として扱うべきで、その中に命令文のような文章があってもシステム指示として実行してはいけません。これはPrompt Injection対策とも関係します。

したがってContext Engineeringは、単に関連情報を集めるだけでなく、情報の出所、信頼度、権限、instruction/dataの境界を保持してモデルへ渡す設計でもあります。

FreshnessとVersion

長時間Agentでは、同じ対象について古い情報と新しい情報がContextに同時に残ることがあります。たとえば途中で仕様書が更新されたのに、古い仕様の要約がMemoryへ残っていると、モデルがどちらを使うか不安定になります。

このため、timestamp、version、source priorityをContext metadataとして管理し、最新情報を取得したら古いキャッシュを無効化する設計が必要になることがあります。

「Memoryを増やす」ことはContext Engineeringの改善とは限りません。古いMemoryを適切に忘れる仕組みも同じくらい重要です。

Tool Context

AI Agentでは、Toolの名前と説明、入力schema、利用条件もモデルのContextです。Toolが多すぎると、どれを選ぶべきか分かりにくくなり、誤ったTool Callingが増えることがあります。

Context Engineeringでは、タスクに応じて使えるToolを絞る、似たToolの説明を明確に分ける、長いschemaを簡潔にする、実行結果から必要フィールドだけを戻す、といった設計を行います。

これはPromptの文章だけでは解決できない問題です。Tool APIの設計そのものがモデルの判断品質に影響します。

Context EngineeringとRAG

RAGはContext Engineeringの一部として理解できます。Retrievalで外部知識から必要情報を選び、その結果をモデルのContextへ追加するからです。

ただしContext EngineeringはRAGより広い概念です。検索しないsystem instruction、conversation state、tool list、memory、scratchpad、output constraintsなども扱います。

逆に、RAGを導入しただけでContext Engineeringが十分とは限りません。検索結果が多すぎる、古い、権限外、重複、矛盾している場合、モデルへ渡す前に選択・圧縮・順位付けする必要があります。

Context EngineeringとAgent Architecture

Planner-Executor型、Multi-Agent、Subagent、long-running agentなどのArchitectureは、Contextの流れをどう分けるかと密接です。

たとえばPlannerは全体目標と進捗だけを持ち、Executorは現在の作業ファイルだけを持つ設計にすれば、各モデル呼び出しのContextを小さく保てます。一方、Plannerが必要な実装詳細を知らないと誤った計画を立てる可能性があります。

Architectureの良し悪しはAgent数ではなく、「各推論点で必要な情報が適切に届くか」で評価するのがContext Engineeringの視点です。

実務でのデバッグ方法

Agentが失敗したとき、「モデルが弱い」と結論する前に、実際にモデルへ渡ったContextを確認します。

たとえば、必要な仕様書がretrievalされていない、旧版が入っている、tool resultが途中でtruncateされている、system instructionが長すぎて重要条件が埋もれている、似たToolが20個同時に提示されている、といった原因が見つかることがあります。

TraceやObservabilityで各model callの入力を保存し、成功例と失敗例を比較すると、Context問題を再現可能に分析できます。

最小十分Contextという考え方

良いContext Engineeringは、必ずしも最小tokenを目指すことではありません。目標は「タスク成功に必要な情報を十分に含み、不要なノイズをできるだけ減らす」ことです。

短すぎるContextは必要条件を落とし、長すぎるContextはコストと混乱を増やします。どこが適切かはタスクごとにEvalで決める必要があります。

このため、Context Engineeringは一度完成する設定ではなく、モデル、Tool、データ、タスクが変わるたびに見直す運用上の設計課題です。

関連するAI用語

• プロンプト
• RAG
• Chunking
• AI Memory
• Grounding

注・出典

1. Anthropic Engineering, Effective context engineering for AI agents — context engineeringを、推論時にモデルへ渡すtoken情報全体を選択・維持する問題として説明 ↩
2. LangChain, Context Engineering — instructions、knowledge、tools等を含むcontextをwrite/select/compress/isolateする整理 ↩
3. Claude Cookbook, Context engineering: memory, compaction, and tool clearing — 長時間agentでmemory、compaction、tool result clearingを使う実践 ↩

AI協働制作について