2025年6月18日、Shopify CEO の Tobi Lütke が X に「”context engineering” の方が “prompt engineering” より良い。LLMがタスクを解けるよう文脈を全部用意する技能を的確に指している」と投稿したのが起点。6月25日に Andrej Karpathy が “+1” して拡散し、2025年下半期に業界標準語化した。2025年7月にはGartnerが「context engineering is in, and prompt engineering is out」と宣言。
LangChain の Harrison Chase の定義が最も引用される:
Context engineering is building dynamic systems to provide the right information and tools in the right format such that the LLM can plausibly accomplish the task.
Anthropic公式も「LLM推論中に最適なトークン集合をキュレーションし維持するための戦略群」と定義し、prompt engineeringの自然な進化形と位置づけている。
プロンプトをいじるだけでは解けない問題が増えた。典型的失敗モードが2つ:
結果、「何を入れるか」と同じくらい「何を入れないか」「どう整形するか」が決定的になった。
ただし巷の “context engineering” が扱っているのは、実質的にはコンテキストウィンドウに何をどう詰めるかの話に偏っている。RAG・compaction・scratchpad・マルチエージェント分離など、全部「いま目の前のLLM呼び出しに何を入れるか」。Karpathyの有名な比喩も「LLMはCPU、ウィンドウはRAM、エンジニアはOSのようにワーキングメモリへ適切なコード・データをロードする」で、プロセス実行時の内部状態最適化の話。
これまでの議論で確認したのは、「コンテキスト」という語が少なくとも3つの異なる主語を持つということ:
巷の用語は切り口がバラバラなので混乱する:
3層とも「何のContextか」を主語で指定して揃える:
| 層 | 主語 | 定義 |
|---|---|---|
| Window Context | コンテキストウィンドウ | 推論時にLLMが実際に読むトークン列 |
| Agent Context | エージェント | そのエージェントを成立させる構成の束(モデル・ツール・メモリ・ポリシー) |
| Human Context | 人間/組織 | 目的に照らして解釈・選択・整形された情報 |
主語を揃えたから、並べた瞬間に3層の関係が見える。
[Human Context] 人間側の解釈・キュレーション
↓
[Agent Context] エージェント構成への組み込み
↓
[Window Context] 実行時のウィンドウ充填
↓
LLM推論
下流に行くほど抽象度が下がり、具体的なトークン列に収斂していく。逆に言えば、上流のHuman Contextが貧弱なままAgent ContextやWindow Contextをいくら磨いても、出力の天井は上がらない。業界内でも同じ認識が共有されつつあり、「ほとんどのエージェント失敗はモデルの失敗ではなくコンテキストの失敗」と言われる。素材の質が成否を分ける。
定義: 推論の瞬間、LLMのコンテキストウィンドウに乗っているトークン列そのもの。system prompt、retrieval結果、ツール定義、会話履歴、few-shot例、全部含む。
扱う問題: context rot、attention budget、ウィンドウ上限、コスト最適化。
代表技術:
主要プレイヤー: LangChain / LangGraph、Anthropic(effective context engineering記事群)、Weaviate、LlamaIndex。
定義: 個々のエージェントを成立させる構成一式。「このエージェントはどのモデルを使い、どのツール群を持ち、どのメモリポリシーで動くか」という構成の束。Langbaseの”Pipes”やGoogle CaaS提案の”Block”に相当。
扱う問題: エージェントのバージョン管理、ツールセットの取捨選択、モデル切り替え、エンタープライズガバナンス。
代表技術:
位置づけ: 実行時の話ではなく、エージェントそのものの”品種”を定義する話。MCPはここへの接続口の規格として機能する。
定義: 人間や組織が持つ素材プール(日記、Slack、Drive、DB、センサーデータ、業務記録)から、目的に照らして解釈・選択・整形・重み付けした情報の束。
扱う問題:
具体例: 「フルリモート年収600万の仕事に移りたい」という目的に対し、3年分の日記・家計簿・カレンダーから「可処分時間の推移」「固定費と必要年収の関係」「ストレス源の頻出パターン」を抽出する営み。素材そのものではなく、この抽出結果こそがHuman Context。
主要プレイヤー(現状): Glean(企業内検索の進化形)、一部のパーソナルナレッジツール。独立した領域として名指されていないのが現状。
各層は概念的に独立しており、別々に設計できるが、下流は上流に依存する:
逆方向の影響もある: Window Contextでcontext rotが起きやすいことが判明したから、Agent Context側で「要約エージェント」を分離したり、Human Context側で「最初から圧縮済みの形で保存する」設計が要請される。
業界の関心と投資は下2層に集中している。Window ContextにはAnthropic・OpenAI・LangChainが、Agent ContextにはGoogle・Microsoft・AWSが揃って取り組む。対してHuman Contextは、触れているプレイヤーも少なく、言語化自体が遅れている。
前段の議論で「②にもう一段組み込める」と指摘した領域はここ。MCPが配管を標準化した今、次に問題になるのは「その配管を通して何を流すか、どう整形してから流すか」。これはMCPの仕様ではなく、その手前にある情報設計の問題。
想定される動き:
この3層命名の最大の効用は、業界がまだ名付けていない領域(Human Context)に名前を与えること。現状の “context engineering” という語はこの層を指せないまま使われているので、議論が下2層に閉じがち。
主語で揃えた命名を採ると:
議論の地図として実用的に機能する。