AI・信頼性・評価

コンテキストエンジニアリングとは？プロンプトとの違いと圧縮の判断

2026/6/21 （更新: 2026/10/13） シリーズ「AIエージェント入門」 第3回 / 全4回

🤖 AIを使用して執筆

「プロンプトを書く」から「コンテキストを設計する」へ

少し前まで、AIをうまく使うコツは「プロンプトエンジニアリング」、つまり一回の指示文の書き方だと言われていた。 だが、長く自律的に動くエージェントの時代になると、話の重心が移った。大事なのは一回の言い回しより、机の上の情報“全体”をどう組み立て続けるかである。新しい呼び名が広まりはじめたのは2025年6月ごろだ。Shopify の CEO Tobi Lütke が「プロンプトエンジニアリングより『コンテキストエンジニアリング』のほうが中身を言い当てている」と書き、Andrej Karpathy がそれを増幅した。Willison はこのとき「定着するだけの力があるかもしれない」と書いている¹。実際に、以後1年で Anthropic も Cline も、自社の設計をこの語で説明するようになった（後述）。OpenAI の Codex 解説記事は、机の采配そのものを説きながら、この語は使っていない。

机に載るものは、大まかに次のとおりである。

• 指示（システムプロンプト）：そもそも何を目指し、どう振る舞うか（常に置いておく土台）。
• 短期記憶：直近のやりとり（さっき何をして何が返ってきたか）。
• 長期記憶：過去の経験や、必要なときに外から引っぱってくる知識（検索＝RAG的なもの）²。
• ツールの結果：行動して返ってきた観察。

ハーネスの仕事は、毎ステップ、この中からいま必要な分だけを机に載せることである。

多いほどよいわけではない。長いコンテキストの「lost in the middle」

ありがちな誤解が、「机に載せる情報は多いほどいい」というものである。実際は違う。 情報が少なすぎれば、AIは手がかりを失う。逆に多すぎても、肝心な情報がノイズに埋もれ、AIは注意散漫になる。AIは、長いコンテキストの真ん中あたりに置かれた大事な情報ほど見落としやすい。この「中央に置かれた情報を取りこぼす」現象は、lost in the middle という名前で知られている（測られたのは複数文書からの質問応答と、キーと値の取り出しの2課題。2023年当時のモデルでの話だ）²。同じ論文は、もっと強い数字も出している。GPT-3.5-Turbo に20〜30本の文書を渡し、答えの載った一本が真ん中に沈んだ最悪ケースでは、正答率が文書を一本も渡さなかったとき（56.1%）を下回った。つまり文書を多く積んでも、その一本の置き場しだいで、積まない場合に負けうる。加えて、載せる量を増やすほどお金（計算コスト）もかかる²。

載せすぎの害は、何十手も続くエージェントの仕事でも測られている。ただしそこで数えられた害は、中ほどの取りこぼしではなく、古くなった状態を参照して誤ることだった。2026年6月のプレプリントで、Microsoft の研究者らが Dynamics 365 の上に経費処理の課題を50件用意し、GPT-5 に渡す履歴の量を変えて完了率を比べた³。どの条件にも、GPT-5 が非対話のハーネスで途中で止まらないよう、gpt-4.1 で作った利用者役のモデルが対話相手として付いている。3条件の結果を並べる（71%と79%の差は信頼区間がわずかに重なる、と著者らは注記している）。

• 全履歴を保持：完了率 71.0%（約148万トークン・14.6時間）
• 直近5つのツール呼び出しに刈り込み：79.0%（約54万トークン・5.4時間）
• 刈り込み＋要約：91.6%（約55万トークン・5.8時間）

全履歴を渡した条件が最も低かった。論文は失敗の中身も数えている。非完了のうち古い状態を参照して誤ったものは、全履歴で47%（34/73）、刈り込みで11%（6/53）だった。一方、刈り込みだけにすると、残高が見えなくなって手続きを打ち切る失敗が9件から18件へ倍増し、要約を足すと3件まで減った³。最良だった構成は、直近5件のツール呼び出しを生のまま残し、そこから押し出された直近3件だけを1つの要約に圧縮して差し込む。

伸び幅のほうは、モデルが変わると大きく縮む。Claude Sonnet 4.5 は利用者役なしで回され、何も手を入れない状態ですでに88.0%を完了していた（同じ条件の GPT-5 は8.0%）。刈り込みで92.0%、刈り込み＋要約で94.5%と、並び順は同じでも上積みは +6.5 ポイントにすぎない。トークンは 3,562K から 2,235K に減ったが、実行時間は 6.20 時間から 11.30 時間へと約1.8倍に延びた³。著者らが「モデル固有の停止（stalling）挙動を反映している」と書くのは、利用者役なしの8.0%から全履歴の71.0%への跳ね上がりのほうである。71→79→91.6 の並びはその対象ではなく、著者らはコンテキストエンジニアリングについての主張を、全履歴・刈り込み・刈り込み＋要約の3条件の比較だけに置くと明記している³。

伸び幅と費用はモデルで変わるが、どちらのモデルでも全部載せる条件は最良にならなかった。だから本質は「全部載せる」ことではなく、「いま要る最小限を、的確に選ぶ」ことにある。引き算の技術である。

実在のハーネスは、どう机を采配しているか

本節では、プロが実際に使うハーネスが、この「引き算」をどう機構にしているかを見る（設計は各社が公開している）。

• コンテキストを「予算」として扱う（Claude Code）。 Anthropic は、トークンが増えるほどモデルの想起精度が落ちる context rot（コンテキストの腐り） を挙げ、モデルには読むたびに目減りする「注意の予算」がある、と言う。なぜ多く載せればいいわけではないのか。同社はこう説明する。Transformer ではすべてのトークンが互いを参照するので、n 個のトークンには n² 通りの関係が生じ、コンテキストが長くなるほどその関係を捉える力は薄く伸びる。加えてモデルは、短い系列のほうが多い学習データから注意の張り方を身につけている。だから長いコンテキストで起きるのは「崖」ではなくなだらかな劣化だ、とも断っている。能力そのものは長いコンテキストでも高いままで、落ちるのは情報の取り出しと長距離の推論の精度だ、という書き分けである。そのうえで机の作り方はハイブリッドだと自ら規定する⁴。Claude Code は、プロジェクト規約 CLAUDE.md を先に丸ごと載せ、個々のファイルは grep/glob でその場で取りに行く。Anthropic はこの方式が事前に索引を作るより遅いと認めたうえで、索引が古びる問題を避けるためにこれを選んでいる。同社は長丁場の仕事向けに、さらに三つの手を挙げる。会話を要約して差し替える（compaction。「最初に引く梃子」だという）、机の外にノートを書いて後で戻す、脇道をサブエージェントに出す、の三つである。サブエージェントには別の机で数万トークン探索させ、戻すのは1〜2千トークンの要約に絞る。
• 要約で圧縮し、脱線をつなぎ止める（Cline）。 オープンソースの Cline は自らを「コンテキストエンジニアリングのハーネス」と呼ぶ。机が一杯に近づくと、膨れた履歴を要約で置き換えて続きから再開する（Auto Compact）。残すと明言するのは決定・コード変更・状態だ。加えて todo チェックリストを机へ再注入して、話が逸れるのを防ぐ（Focus Chain）。間隔は設定でき、既定は6メッセージごとだ。残り容量はコンテキストウィンドウの進捗バーで見せ、利用者が不意の“物忘れ”に驚かないようにする⁵。
• 履歴は「追記のみ」でキャッシュを効かせる（Codex CLI）。 OpenAI の Codex は、プロンプトの静的部分を先に固定して過去を書き換えない。プロバイダのプロンプトキャッシュは前方一致で効くので、ツール集合やモデルを途中で変えるとキャッシュが外れるからである。コンパクションは専用の /responses/compact エンドポイントに委ね、設定した閾値（auto_compact_limit）を超えると自動で走る。もっとも、コンパクションだけは「追記のみ」を破る。コンパクションは履歴そのものを短い代表列に差し替えるからである。キャッシュが当たっているあいだサンプリングは二次でなく一次で済む、と同社は書いている。ただし差し替わるのは入力（input）の列で、システムメッセージ・ツール・指示はその外、プロンプトの先頭に置かれる。コンパクションの直後にキャッシュがどこまで当たるかは、同記事には書かれていない⁶。

同じ順序を Anthropic も Claude Code について公開しており、静的内容を先・動的内容を後に置き、ツールやモデルを途中で変えないと書く。圧縮する側にも工夫があり、要約を作る呼び出しを親と同じシステムプロンプト・同じツール定義のまま分岐させ、親の接頭辞のキャッシュを再利用するという⁷。Claude Platform（API）の利用者向けには、分岐したサブエージェントが親のキャッシュを共有できる条件（接頭辞がバイト単位で同一・同じモデル・同じ effort 設定）も示している⁸。

三者に共通するのは、本稿の原則である机に積み上げるより、要るものを的確に選んで載せるという考え方だ。三者とも、満杯が近づけば履歴を要約で圧縮する。脇道を別の机（サブエージェント）へ出す手を、引いた三本の記事のうち機構として書いているのは Anthropic だけである。Anthropic は、別の机で数万トークン規模の探索をさせ、本線へ戻すのは1〜2千トークンの要約に絞る⁴。Codex の解説記事がコンテキストウィンドウの枯渇に対して挙げるのは圧縮することだけで、単一の入力列に追記し、閾値を超えたらより小さな代表列へ丸ごと差し替える⁶。Cline の設計記事も同様に、別の入れ物へ出す手（/newtask・Deep Planning）は脇道の委譲ではなく本線の引き継ぎとして説明する⁵。ただし製品としては、Cline は2025年10月に実験機能としてサブエージェントを加え、Codex は2026年10月時点の現行版でサブエージェントを既定で有効にしており、両社とも探索の出力で主のコンテキストを汚さないための手だと説明している⁵⁶。差が出るのは「何を捨てないか」の指定で、Anthropic は設計上の判断と未解決のバグを、Cline は決定とコード変更を残すと書く。追記のみでキャッシュを効かせる手と、todo をコンテキストの末尾へ書き直して脱線を防ぐ手は、Manus も2025年7月の設計記事で自社の機構として公開している⁹。「何を載せ続けるか」は、実在のハーネスが競って設計している一級の技術である。

どこまで圧縮するかは、動かすモデルの地力で変わる

三者とも満杯が近づけば圧縮するが、強く圧縮するほど得というわけでもない。それを示したのが、2026年のプレプリント「AdaCoM」である¹⁰。この研究は、仕事をするエージェントとは別のLLMを管理役に立て、何を残し何を圧縮するかを強化学習で覚えさせた。著者らによれば、Web検索や深いリサーチ系のベンチマークで、エージェント自身にコンテキストを制御させる方式や、要約のような固定戦略を上回った。BrowseComp-Plus の4エージェント平均では、コンテキスト管理なしの ReAct が 24.17、AdaCoM が 33.60（+39.0%）で、比較対象のうち最も強い SumCoM の 29.39 に対しても +14.3% にあたる¹⁰。

著者らが中心に置く知見は、忠実さと信頼性のトレードオフである。地力のあるエージェントほど、生のコンテキストを多く残し、圧縮は遅く軽く入れる方が得をする。地力の乏しいエージェントは、強く圧縮して扱える量に収めると安定する¹⁰。つまずきが出るのは前者で、固定の要約を当てた場合である。同じ表では、エージェント自身が要約を書き換え続ける固定方式が、4エージェント平均でコンテキスト管理なしを下回った（24.17→22.06）。コンテキスト管理なしで最も成績の良い GLM では 32.56 から 11.56 まで落ちている¹⁰。著者らは、生のコンテキストを多く残すほど得をする GLM や Qwen には固定の要約が向かず、学習させた固定要約でも GLM の成績が下がったと書いている¹⁰。どこまで圧縮するのが最適かは一律に決まらず、動かすモデルの強さに合わせて決めることになる。ただし著者らは、コードエージェントではこの手法を評価していないと断っている¹⁰。

圧縮する仕組みにも費用がかかる。AdaCoM の著者らは、管理役を毎ステップ呼ぶのでトークンと待ち時間が増えること、コンテキストを書き換えるのでKVキャッシュを再利用しにくくなることを明記しており、要約で圧縮する方式にも同じことが言える¹⁰。捨てすぎの危険もある。答えに要る証拠まで捨てれば、刈り込みは逆に失敗を招く。長い対話履歴への質問応答では、残せる量を同じ予算に揃えた方式どうしで比べると、答えに要る証拠を選んで残す方式が他を上回ったと報告する研究もある¹¹。同じ研究では、読む時点で生の履歴全体を検索できる参照条件は、正答の指標（F1）がそれより高かった¹¹。60の科学的発見タスクで8種の圧縮法を比べた研究では、どの方法でも仮説の質は有意に変わらず、LLMによる要約はトークンをかえって24〜94%増やした。ただし課題は5〜22手と短く、トークンが減ったのは10手を超える課題で規則型の圧縮を使ったときだけだった¹²。

これは「新しい技術」なのか、それとも“言い換え”なのか

「コンテキストエンジニアリングは、結局プロンプトエンジニアリングの言い換えでは？」と疑うのは自然だ。実際、当事者たちも新旧を断絶としては書いていない。Anthropic はこれを「プロンプトエンジニアリングの自然な延長」と位置づけている⁴。新語を推した Simon Willison 自身、本来は旧称にこの複雑さを込めたかったのに、世間の受け取りは「チャットに何か打ち込むことを指す、笑ってしまうほど尊大な言葉」に落ちたと振り返る。彼は定着するのは受け取られ方のほうだと書いたうえで、「『コンテキストエンジニアリング』のほうは、受け取られ方が本来意図した意味にずっと近いだろう」と結んでいる¹。 私は、重心の移動は本物だとみる。「一発の指示を磨く」から「長く走る情報の状態を管理し続ける」へ、という強調点の変化は実在する。もっとも、この語を推す当の Anthropic 自身が「モデルが賢くなるほど、人が采配する量は減っていく」と書き添えていることは、押さえておいてよい⁴。ただし同社は結びで、能力が上がってもコンテキストを有限の資源として扱うことは中心であり続ける、とも書いている⁴。争点は中身の新しさというより、どこまでを一つの語で囲うかにある。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。