コンテキストエンジニアリングはプロンプトエンジニアリングを置き換えた言葉なのか — 測定されたものと、そうでないもの

はじめに — まず質問に答えると
用語はいつ、誰から生まれたか
二つの仕事が別物であることを示す一つの測定
コンテキストウィンドウと実効コンテキストは別の数字だ
では2026年のモデルはこの問題を解いたのか
Lost in the middleは実際どれほど悪いのか
ではコンテキストを論理的に整えればよいのか — 測定が逆に出た場所
「アテンション予算」は測定された概念か
Compactionは本当に損失が少ないのか
では何をすべきか — 決定ルール
コンテキストエンジニアリングが答えでないのはいつか
おわりに
参考資料

はじめに — まず質問に答えると

「コンテキストエンジニアリングがプロンプトエンジニアリングを置き換えた」という言い方を最近よく見かけます。結論から言えば代替ではなく包含です。そしてこれは私の意見ではなく、用語を広めた当人たちが自分で書いた文です。Karpathyはコンテキストエンジニアリングを定義しながら、その構成要素として「タスクの説明と解説、few-shotの例、RAG、ツール、状態と履歴、compacting」を列挙しました — few-shotの例とタスク説明は、まさにプロンプトエンジニアリングそのものです。Anthropicに至っては「コンテキストエンジニアリングをプロンプトエンジニアリングの自然な進展(natural progression)と見なす」と書きました。どの一次出典も「死んだ」とは言っていません。あの文はヘッドラインから生まれたのです。

ただ、ここで止まると半分しか正しくありません。包含関係というのは用語の整理にすぎず、本当の質問は「では新しく学ぶことはあるのか」です。これは測定で答えられます — そして答えは「ある」です。Chromaが2025年7月に行った実験が最もきれいです。同じ質問、同じタスク、同じ文言をそのままにして、周辺コンテキストの量だけを変えました(関連する内容だけを収めた約300トークン vs 無関係な内容まで含んだ約113kトークン)。18モデルすべてで性能が下がりました。プロンプトの文言は一文字も変わっていないのに数字が動いたなら、それはプロンプトエンジニアリングの手が届かない軸です。それがこの用語の稼いだ価値です。

本稿の目的は、ハイプを取り払って測定されたものと、測定なしに繰り返されているものを分けて置くことにあります。コンテキストウィンドウそのものの活用戦略は1Mコンテキストウィンドウ時代のLLM活用戦略で、エージェントメモリ設計の実務パターンはコンテキストエンジニアリング — AIエージェントに記憶を設計する方法ですでに扱いました。ここでは、それらの記事が前提として敷いていた根拠そのものを監査(audit)します。

用語はいつ、誰から生まれたか

時系列で整理するとこうなります。

2025年6月12日 — CognitionのWalden Yanが「Don't Build Multi-Agents」を公開します。ここでコンテキストエンジニアリングをプロンプトエンジニアリングの「次の段階」と位置づけ、「動的なシステムでこれを自動的に行うこと」と定義します。そしてエージェントを作るエンジニアの「最優先の仕事」だと明言します。
2025年6月19日 — Shopify CEOのTobi LütkeがXに「プロンプトエンジニアリングよりコンテキストエンジニアリングという用語の方が好きだ」と書きます。彼の定義は「タスクがLLMで十分に解けるものになるために必要なすべてのコンテキストを提供する技術」です。
2025年6月25日 — Karpathyがこれを増幅します。冒頭で引用したあの文です。
2025年6月27日 — Simon Willisonが二つのツイートを引用しながら「この用語は定着しそうだ」と書きます。彼の観察が興味深いところです — プロンプトエンジニアリングは「チャットボットに何かをタイプする仕事を大げさに呼ぶ言葉」として大衆に誤解され、コンテキストエンジニアリングなら大衆が類推する意味が意図した意味に近いだろう、というのです。つまりこの用語交代の動機のかなりの部分は、技術ではなく語感でした。
2025年7月17日 — ちょうど1年前の今日、1400本を超える論文を渉猟したサーベイ(arXiv 2507.13334)が公開され、用語が学術的な外形を得ます。
2025年9月29日 — Anthropicがエンジニアリングブログに「Effective context engineering for AI agents」を掲載します。ベンダーが公式にこの用語を採択した時点です。

ここで注目すべき点があります。Cognitionの記事はツイート群より1週間早く出ており、三つの出典(Cognition、Karpathy、Anthropic)がそれぞれ独立に同じ構造の定義を出しました — プロンプトエンジニアリングを部分集合として含む上位概念です。誰も代替とは言いませんでした。

二つの仕事が別物であることを示す一つの測定

用語の系譜はここまでにして、根拠に進みましょう。「コンテキストエンジニアリングは別の仕事だ」を主張ではなく測定で示す実験が一つあります。Chromaの技術報告書「Context Rot: How Increasing Input Tokens Impacts LLM Performance」(Hong、Troynikov、Huber、2025年7月14日)です。

核心の設計はこうです。LongMemEvalという対話型QAベンチマークを使いつつ、同じ質問を二つの方式で投げます。

Focused条件:  質問 + 答えに必要な関連部分のみ           -> 平均 約300トークン
Full条件:     質問 + 関連部分 + 無関係な内容すべて       -> 平均 約113kトークン

質問は同一。タスクも同一。プロンプトの文言も同一。
変わったのは: 関連情報の周りに、何がどれだけ敷かれているか。

結果はChromaの表現そのままに「すべてのモデルでfocusedプロンプトがfullプロンプトより有意に高い性能」です。評価対象はGPT-4.1、Claude 4、Gemini 2.5、Qwen3を含む18モデルでした。

これがなぜ決定的かというと、この実験はプロンプトエンジニアリングの変数をすべて固定しているからです。文言も、例も、指示文もそのままです。プロンプトエンジニアリングが触れるつまみには一切手を付けていないのに、数字が動きました。したがって「コンテキストエンジニアリングはプロンプトエンジニアリングのリブランディングだ」という主張は、この一枚の実験で反証されます。逆に「プロンプトエンジニアリングは死んだ」も間違いです — focused条件で性能がよく出るということは、プロンプトが依然として機能しているという意味ですから。二つの軸は直交します。

正直に付け加えるべき条件もあります。著者らはLongMemEval_sからknowledge update、temporal reasoning、multi-sessionのカテゴリを選んで使い、曖昧または回答不能な38問を除いて306問を残しました。採点はLLM審査(LLM-as-judge)であり、著者らはこの審査を人間の判断にキャリブレーションしたと明かしています(LongMemEvalの出力約600件を手動ラベリング)。ChromaはベクトルDBの会社なので、「検索でコンテキストを減らせ」という結論に利害関係がある点も踏まえるべきです。ただしコードベースは公開されており、再現可能です。

コンテキストウィンドウと実効コンテキストは別の数字だ

「1Mコンテキスト」と書かれた数字は入力が拒否されない上限であって、性能が維持される上限ではありません。これを正面から測定したのがRULER(Hsiehら、arXiv 2404.06654、COLM 2024)です。

RULERの方法論は明快です。13タスクの平均点を測り、Llama2-7Bが4Kで出した85.6%を基準線として、この線を超えられる最大長を「実効長(effective length)」と定義します。基準線の選択自体は恣意的ですが、恣意的であることを論文が明示して固定した点が重要です。17モデルの結果の一部です。

モデル	公称長	実効長	4K	32K	128K
Gemini-1.5-Pro	1M	128K超	96.7	95.9	94.4
GPT-4	128K	64K	96.6	93.2	81.2
Llama3.1 (70B)	128K	64K	96.5	94.8	66.6
Qwen2 (72B)	128K	32K	96.9	94.1	53.7
Yi (34B)	200K	32K	93.3	87.5	77.3
GradientAI/Llama3 (70B)	1M	16K	95.1	85.4	72.1
LWM (7B)	1M	`4K未満`	82.3	69.1	65.0

論文の文はこうです — 「ほぼすべてのモデルが、公称のコンテキスト長に達する前に基準線を下回る」。LWMは1Mを公称しながら、4KですらLlama2-7Bを超えられません。つまり公称長は実効長を予測せず、順序すら保存しません — 1Mを公称したGradientAI/Llama3(実効16K)は、128Kを公称したGPT-4(実効64K)よりはるかに下です。

ここで必ず付けるべき条件があります。これは2024年のモデルです。だから「今もそうなのか」が当然の質問であり、その答えが次節です。

では2026年のモデルはこの問題を解いたのか

解いていません。そしてこれを最も新しく測定したのがATLAS(arXiv 2605.28079、2026年5月27日提出)です。26モデルを8Kから1Mまでの固定グリッド上で、6,438インスタンスで評価しました。

ATLASが著者自己測定として報告した結果のうち、実務に直結するものが二つあります。

第一に、長さによって順位が入れ替わります。著者らは128Kまでのスコアと1Mまでのスコアを別々に集計しましたが、7モデルが2ランク以上順位を移動し、個別の順位差は最大12位まで開きました。報告された首位も割れます — 128KではGemini-3.1-Pro-Previewが、1MではClaude-Opus-4.6が先んじます。あなたが128Kのベンチマークを見て選んだモデルが、1Mでも最善だという保証はないということです。

第二に、検索がうまいからといって活用がうまいわけではありません。アブストラクトの表現では「強い検索性能が下流の利用(downstream use)に転移しない場合がある」であり、基礎演算のレイヤーと応用ワークロードのレイヤーはモデル間分散の61%しか共有していません。ここで「なら残りは間違うのだ」と算術をひっくり返してはいけません — この数値が語るのは、二つのレイヤーにおけるモデル間の性能変動がかなりの部分で別々の方向を指しているということ、したがってNIAH系の検索スコア一つで応用性能の順位を代わりに立てることはできない、ということです。著者らの結論は「単一のヘッドラインスコアではなく、能力別・長さ別に報告せよ」です。

ATLASはまだ査読を経ていないプレプリントであり、数字は著者の自己測定です。ただし方法論(固定グリッド、AUCベースのスコア、不確実性の伝播)を公開し、下位コンポーネントを監査可能にしたという点で、自ら検証可能性を高めた側に属します。

ここで本当のメタなポイントが出てきます。同じ現象が4世代にわたって再現されました。

2023  Lost in the Middle    GPT-3.5-Turbo, Claude-1.3 世代
2024  RULER                 GPT-4, Llama3.1, Qwen2 世代
2025  NoLiMa / Context Rot  GPT-4o, GPT-4.1, Claude 4, Gemini 2.5 世代
2026  ATLAS                 Gemini-3.1-Pro, Claude-Opus-4.6 世代

一つの世代の欠陥なら、次のモデルが直してくれるまで待てばいい。4世代連続なら、それは待つ対象ではなく設計する対象です。これが、コンテキストエンジニアリングが流行語以上のものである唯一にして十分な理由です。

Lost in the middleは実際どれほど悪いのか

最も多く引用されながら、最も頻繁に丸められてしまう論文です。「Lost in the Middle: How Language Models Use Long Contexts」(Liuら、arXiv 2307.03172、TACL掲載)の実際の主張はこうです。

正解の入った文書をコンテキストの最初か最後に置くと性能が最も高く、中間に置くと大きく落ちます。先頭側のバイアスをprimacy bias、末尾側のバイアスをrecency biasと呼び、二つが合わさってU字カーブを作ります。

効果量が重要ですが、論文が明示した数字はこれです。GPT-3.5-Turboのマルチ文書QA性能は20%以上下がりうるものであり、最悪の場合、20文書・30文書の設定での性能は文書を何も与えなかったとき(closed-book、56.1%)より低くなります。ちなみに正解文書を一つだけ与えるoracle設定は88.3%です。

この文の重さは見逃されがちなので、もう一度読んでください。正解が入っている文書をコンテキストに入れたのに、位置が悪ければ入れなかった場合に劣るのです。「とりあえず全部投げ込んでモデルに探させよう」がなぜ危険かについての、最も圧縮された反例です。

論文が併せて報告した、あまり引用されないもののより痛い結果もあります — 拡張コンテキストモデルが元のモデルと同一の性能を示すことがしばしばあり、著者らはこれについて「拡張コンテキストモデルが必ずしも入力コンテキストをよりうまく使うわけではない」と書いています。コンテキストウィンドウを広げることと、コンテキストをうまく使うことは別の仕事です。

条件も付けます: これは2023年のモデルです(GPT-3.5-Turbo、Claude-1.3)。だからこの数字を2026年のモデルにそのまま持ち込んではいけません。しかし現象そのものは再現されました — NoLiMa(Modarressiら、arXiv 2502.05167)はneedleと質問の語彙の重なりを取り除いて文字通りのマッチングを使えなくしたうえで、128K以上を公称する13モデルを再評価し、32Kでは11モデルが短いコンテキスト(1K未満)基準線の50%を下回りました。上位圏のGPT-4oでさえ99.3%から69.7%に下がりました。著者らは、CoTプロンプティングや推論能力を付けてもこの低下を防げなかったと付け加えています — プロンプトでは直らないという意味です。

ではコンテキストを論理的に整えればよいのか — 測定が逆に出た場所

ここで通念が一つ崩れます。Chromaはhaystack(無関係な埋め草テキスト)の構造を二つの条件で比較しました — 原文どおり論理的な流れを持つエッセイの束 vs 文をランダムにシャッフルして局所的な一貫性をなくしたもの。常識的には、よく整った方が良いはずです。

結果は逆でした。18モデルすべてで、シャッフルしたhaystackの方が性能が高かったのです。Chromaの解釈はこうです — 一貫したエッセイの中にneedleが刺されば、論理の流れを断ち切って目立ちそうに思えるが、実際にはその逆に働く、というのです。

この結果は慎重に扱うべきです。これは周辺の埋め草テキストの構造に関する実験であって、「あなたのコンテキストをシャッフルせよ」という処方ではありません。そしてChroma自身が限界の節で線を引いています — なぜそうなるのかは説明できない、と。しかし方向は明白です。コンテキストを人間が読みやすく整えればモデルもよく読む、というのは検証された命題ではありません。直観が覆った地点がすでに一つ測定されたのなら、残りの直観も測定までは直観にすぎません。

「アテンション予算」は測定された概念か

ここからが、本稿で最も引用に値する部分でしょう。上の現象にはたいてい説明が付いてきますが、その説明の地位は測定値とは異なります。

Anthropicの記事はメカニズムをこう提示します — トランスフォーマーはすべてのトークンが他のすべてのトークンにアテンションするため、nトークンに対してn²のペア関係が生じ、長さが伸びるほどこの関係を捉える能力が「薄く引き伸ばされる」ということ。そしてモデルは短いシーケンスの方が多い学習分布でアテンションのパターンを身につけるため、長い依存関係の経験が少ないということ。ここから「アテンション予算(attention budget)」という表現が出てきます — すべての新しいトークンがこの予算を少しずつ消費するという比喩です。

もっともらしく、おそらく方向も正しいでしょう。Anthropicが適切にヘッジしている点も明記しておきます — 彼らは「ハードな崖ではなく性能の勾配」と書き、モデルが長いコンテキストでも依然として有能だと明示しています。しかし正直に言えば、これは説明であって測定ではありません。あの記事には、n²項を原因として分離する実験(ablation)がありません。「アテンション予算」は観察したものを物語としてまとめるのに使う比喩であって、計測器で読み取れる量ではないのです。

そして決定的なくだりがあります。この現象を実際に測定した側であるChromaは、限界の節でこう書いています — 性能低下のメカニズムは説明しておらず、なぜそれが起きるのかについて確定的な答えは持っていない、と。そしてそれを明らかにするには機械的解釈可能性(mechanistic interpretability)の研究が必要で、本報告書の範囲を超えるとも付け加えています。

整理するとこうです。

測定されたもの   : 入力が長くなると性能が不均質に落ちる           (Chroma, NoLiMa, RULER, ATLAS)
説明されたもの   : n^2 アテンション、学習分布、「アテンション予算」  (ベンダーブログ、ablationなし)
測定した側の立場 : 「なぜそうなるかは我々にも分からない」           (Chroma 限界の節、明記)

現象は頑健で、メカニズムは未解決です。この区別は実務上も重要で、メカニズムの物語を事実として受け取ると、そこから処方を演繹したくなるからです(「n²なんだからトークンを減らせば二乗で良くなるだろう」)。そうした演繹を裏付ける測定はありません。

Compactionは本当に損失が少ないのか

コンテキストがウィンドウからあふれるときの標準処方がcompactionです — 会話を要約し、新しいウィンドウをその要約で始めること。Anthropicの記事は、Claude Codeがこれをどうやっているかまで説明しています: メッセージ履歴をモデルに渡して要約させ、アーキテクチャ上の決定・未解決のバグ・実装の詳細は保存しつつ重複したツール出力は捨て、直近にアクセスしたファイル5件を一緒に渡す、と。

そしてこう書きます — compactionはコンテキストウィンドウの内容を「高い忠実度で」圧縮し、エージェントが「最小限の性能低下で」続行できるようにする、と。

この文を裏付ける測定値は公開されていません。忠実度がどれほどか、性能低下が何パーセントか、どの評価セットで測ったのか — ありません。同じ記事はcompactionのリスクも正直に認めています(「過度に積極的なcompactionは、後になって重要性が明らかになる微妙な文脈を失いうる」)。しかし、そのトレードオフの位置を教えてくれる数字はありません。

Cognitionも同様です。Walden Yanは履歴を核心情報へ圧縮する別モデルを置くよう勧めながら「正しくやるのは難しい」と書き、Cognitionは実際に小さなモデルをファインチューニングしたと明かしています。やはり数字はありません。そして率直にこう付け加えます — それでも結局は限界にぶつかる、と。

では公開された数字には何があるのか。Anthropicが2025年9月29日にコンテキスト管理機能を発表した際に出したものが、唯一それに近い数値です。

測定	報告値	条件
メモリツール + コンテキスト編集	基準線比39%向上	エージェント検索用の内部評価セット
コンテキスト編集単独	29%向上	同一
トークン消費	84%削減	100ターンのウェブ検索評価

これらの数字はベンダー自己測定であり、評価セットは公開されていません。タスク数も、基準線の構成も、分散も示されていません。再現は原理的に不可能です。

より重要なのは、これがcompactionの数字ではないという点です。コンテキスト編集は古いツール呼び出し・結果をウィンドウから消すものであり、compactionは会話を要約するものです。メカニズムが違います。ところが実務の議論ではこの二つがしばしば混ざり、「39%向上」がcompactionの根拠のように引用されるのを見かけます。違います。

だから正確な文はこうです。業界全体がcompactionを必須と言いながら、compactionの要約忠実度を測った公開数値は存在しません。これは非難ではなく地図です — ここが空欄だと知って入れば、他人の数字を借りる代わりに、自分の評価セットで圧縮前後を直接測るようになります。それが唯一の正直な経路です。

では何をすべきか — 決定ルール

「状況による」では終わらせません。上の根拠から直接導かれる順序があります。

ステップ1. focused/fullギャップをまず測る。Chromaの実験設計をそのまま複製すればよいのです。あなたの評価質問を30〜50問選び、(a) 人が手で選んだ関連情報だけを入れたバージョンと、(b) 実際のパイプラインが入れる全コンテキストのバージョンでそれぞれ回します。この二つの数字の差が、あなたのシステムでコンテキストエンジニアリングが稼ぎうる上限です。

ステップ2. ギャップが小さければ止まる。focusedとfullが似ているなら、モデルはあなたのコンテキストをうまく使えています。この場合、compactionもメモリ階層もグラフも要りません。プロンプトとタスク設計に戻ってください。この段階で止まるのが、大部分のチームにとっての正解です。

ステップ3. ギャップが大きければ、まず検索から。最大のレバーは常に「関係ないものを最初から入れない」です。lost-in-the-middleもcontext rotも、入れなかったトークンには作用しません。

ステップ4. 実効コンテキストをあなたの課題で測る。ベンダーの公称長は入力の上限であって、性能の上限ではありません。RULERがやったことを縮小版でやればいいのです — タスクを固定し、長さだけを伸ばしながらカーブを描いてください。ATLASの結論のとおり、単一のスコアではなくカーブが必要です。

ステップ5. compactionは最後に、そして必ず測ってから。圧縮前後を同じ評価セットで回し、どれだけ失うかを直接確認してください。公開された参考数値がない以上、これは選択ではなく必須です。

コンテキストエンジニアリングが答えでないのはいつか

この部分が抜けている記事は信じないでください。

コンテキストが短いとき。これらの論文の効果量は、おおむね32K以上で現れます。数千トークンの単発の分類・抽出・要約なら、context rotはあなたの問題ではありません。プロンプトエンジニアリングが正しい道具です。
評価セットがないとき。測定なしのコンテキストエンジニアリングは、ただの好みです。上の5ステップがすべて「測れ」で始まるのは偶然ではありません。評価セットを作るのが最初の仕事であって、コンテキスト構造を変えるのが最初の仕事ではありません。
モデルをまだ選んでいないとき。ATLASの順位逆転が語るとおり、長さの区間によって最善のモデルは分かれます。コンテキストパイプラインを精緻にするより、あなたの長さ区間でより良いモデルを選ぶ方が効果が大きいかもしれません。
問題が実は生成側にあるとき。1400本を渉猟したサーベイ(arXiv 2507.13334)が指摘した非対称がこれです — モデルは複雑なコンテキストを理解することには長けているのに、同じくらい精緻な長文を生成することには明確な限界を見せる、ということ。出力が問題なら、入力をどれだけ丁寧にキュレーションしても解決しません。
マルチターンそのものが原因のとき。「LLMs Get Lost In Multi-Turn Conversation」(Labanら、arXiv 2505.06120)は、20万件を超えるシミュレーション会話にもとづき、シングルターン比のマルチターン性能が6つの生成タスクで平均39%低いと報告します(この39%は、上のAnthropicの39%とは何の関係もない別個の数値です)。著者らの分解が興味深いのですが、低下の大部分は能力の損失ではなく不安定性の増大でした。モデルが序盤のターンで当て推量をして早まって最終回答に走り、そこに過度に依存する、というのです。一行で言えば「間違って入った道から戻って来られない」です。これはコンテキストをよりうまく詰めることではなく、会話を最初からやり直すことで解く問題かもしれません。

おわりに

用語の質問への答えは、つまらないものです。コンテキストエンジニアリングはプロンプトエンジニアリングを置き換えていません — 包含しています。これを作った人たちがそう書いたのであり、「死んだ」という文は一次出典のどこにもありません。

興味深い答えはその次です。包含関係なのに新しい名前を持つ資格があるのか — あります。根拠は正確に一つで、それで十分です。プロンプトのすべての変数を固定したまま周辺コンテキストだけを変えても性能が動くこと(Chromaのfocused vs full)。その軸はプロンプトエンジニアリングの語彙には存在せず、だから名前が必要だったのです。

そして、その名前の下に実際に立っている根拠は思ったより少ない。頑健なのは現象です — 長さが伸びると性能が不均質に落ち、公称長は実効長ではなく、中間は消え、このすべてが2023年から2026年まで4世代にわたって再現されました。一方でメカニズム(「アテンション予算」)は比喩であり、処方の効果量(特にcompaction)はほとんど公開数値がありません。

実務者にとってこの地図が与える指針は単純です。現象は信じて設計に反映しつつ、メカニズムの物語から処方を演繹せず、他人の処方の数字を借りて使わないこと。focused/fullギャップを一つ測るだけでも、あなたのシステムでこの議論が有効かどうかは30分以内に分かります。大部分のチームにとって正解は「うちの問題ではない」であり、それを確認するのにかかる費用は、コンテキストパイプラインを新しく作る費用よりはるかに安いのです。