In Silico

AI・信頼性・評価

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

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

🤖 AIを使用して執筆

シリーズAIエージェント入門全4回
  1. 第1回AIエージェントとは？LLMとの違い・仕組み・落とし穴
  2. 第2回AIエージェントのハーネスとは？同じモデルで成績が変わる仕組み
  3. 第3回コンテキストエンジニアリングとは？プロンプトとの違いと圧縮の判断
  4. 第4回AIエージェントはなぜ長い作業で失敗する？成功率の掛け算と評価方法

このシリーズの紹介へシリーズ一覧へ

  • コンテキストエンジニアリング
  • AIエージェント
  • LLM
  • Claude Code
  • Cline
  • Codex CLI
  • Manus
  • プロンプトエンジニアリング
  • コンテキストウィンドウ
  • lost in the middle
  • context rot
  • コンパクション
  • プロンプトキャッシュ
  • サブエージェント
  • Auto Compact
  • Focus Chain
  • ハーネス
  • AdaCoM
  • 刈り込み
  • 短期記憶
  • 長期記憶
  • RAG
  • Transformer
  • CLAUDE.md
  • システムプロンプト
  • トークン
  • Anthropic
  • OpenAI
  • Simon Willison
  • Andrej Karpathy
目次
背景・問い・要点
背景

AIエージェントは、LLM（Large Language Model、大規模言語モデル。渡された文章を読み、その続きの文章を生成するモデル）を何十回も呼び出して仕事を進めるプログラムである。LLM が「このファイルを開く」「このテストを実行する」のように次にすることを出力すると（この出力を行動と呼ぶ）、エージェントはそれを実行し、返ってきた結果を添えて LLM をもう一度呼ぶ。ファイルの読み書きやコマンドの実行のように、エージェントが LLM の代わりに動かす機能をツールと呼ぶ。LLM を呼び、出力どおりにツールを動かし、その結果を次の入力へ足す、という周りのプログラムをハーネスと呼ぶ。

LLM を一回呼ぶときに渡す文章の全体を、コンテキストと呼ぶ。LLM は前の呼び出しで読んだものを覚えていない。何を目指すか、何を禁じられているか、これまで何をして何が返ってきたかは、毎回コンテキストに入れ直さなければ LLM には見えない。コンテキストの長さには上限があり、この上限をコンテキストウィンドウと呼ぶ。長さはトークン（LLM が文章を区切って数える単位で、単語や数文字ほどの断片）で数える。

エージェントが長く走ると、一手ごとに履歴が伸び、やがて上限に当たる。全部を入れ続けることはできないので、どこかで何かを外すことになる。外し方を誤ると、エージェントはさっき決めた制約を忘れ、関係ない古いやりとりを何度も読み返し、少しずつ的を外していく。コンテキストエンジニアリングは、ハーネスが LLM を呼ぶたびに、コンテキストへ何を入れ、何を外し、何を要約に置き換えるかを設計する技術である。指示・制約・これまでの履歴・ツールの結果を受け取り、それを上限の中の一つの入力に組み直して、次の一手に要る情報が LLM に見える状態を保つ。一度書く指示文の言い回しを磨くプロンプトエンジニアリングが扱うのは、このうち指示の部分である。

問い

コンテキストエンジニアリングは、プロンプトを書く技術と何が違うのか。

要点

プロンプトエンジニアリングは一度書く指示文を磨く。コンテキストエンジニアリングは、LLM を呼ぶたびに入力の全体を組み直し、何を入れ、何を外し、何を要約に置き換えるかを決める。

コンテキストに載せる情報は多いほどよいわけではない。査読前の実験（GPT-5・経費処理50件）では、完了率は全履歴を載せると71.0%、直近5回のツール呼び出しを生のまま残し、そこから押し出された3回を要約すると91.6%だった。どこまで圧縮するのが得かは、動かすモデルの地力（コンテキストに手を入れない状態での成績）で変わる。

モデル・例示

上限 8,000 トークンのエージェントが、17手目の前に何を外すか

※ この節の例は、説明のために作った架空のものです。

コンテキストは、ハーネスが手番ごとに組み直す一つの文章である。上限に当たったときに何を外し、何を要約に回すかによって、最初に置いた制約が LLM に見え続けるかどうかと、古い手のどの細部が残るかが決まる。

tests/test_price.py のテストが一つ落ちていて、エージェントがプログラムの側を直す場面を考える。コンテキストの上限は 8,000 トークンとする。ハーネスが1手目に組むコンテキストは、指示と制約の二つだけである。

[指示] tests/test_price.py の落ちているテストが通るように、プログラムを直す。（40 トークン）
[制約] tests/ の中のファイルは書き換えない。（20 トークン）

1手目は次のように進む。

  1. ハーネスLLM1. 指示と制約だけのコンテキストを渡す
  2. LLMハーネス2. テストを実行する、という行動を返す
  3. ハーネスツール3. テストを実行する
  4. ツールハーネス4. 1000 円の 10% 引きが 900 円でなく 990 円になった、と返す
  5. ハーネス5. 行動と結果をコンテキストの末尾に足す

2手目の LLM は、指示・制約・1手目の行動と結果を読み、「price.py を開く」という行動を返す。ハーネスがファイルを読むと、次の中身が結果としてコンテキストの末尾に足される。

def discounted(price, percent):
    return price - price * percent / 1000

def shipping(weight):
    return 500 if weight < 2 else 800

1000−1000×10/1000=9901000 - 1000 \times 10 / 1000 = 990 なので、割合を 100 でなく 1000 で割っていることが原因である。1手の行動と結果で 500 トークン増えるとすると、nn 手目を終えたコンテキストは 60+500n60 + 500n トークンになる。15手目を終えると 7,560 トークンで、16手目の行動と結果を足すと 8,060 トークンになり、上限を 60 トークン超える。ハーネスは17手目に LLM を呼ぶ前に、何かを外さなければならない。

古いものから外すやり方では、ハーネスは先頭から 60 トークン分を外す。先頭にあるのは指示（40）と制約（20）なので、二つがまとめて外れ、コンテキストはちょうど 8,000 トークンになる。17手目の LLM が読むのは1〜16手目の行動と結果だけで、「tests/ の中は書き換えない」という文はもう無い。LLM がテストの期待値 900 を 990 に書き換えてテストを通す行動を返しても、それを禁じる文はコンテキストのどこにも無い。指示の文をいくら磨いても、このやり方では17手目の LLM にその文は届かない。

もう一つのやり方では、指示と制約を常に先頭に置き、上限に当たったら古い手をまとめて短い要約に置き換える。17手目を呼ぶ前に、ハーネスが1〜10手目（5,000 トークン）を 60 トークンの要約に置き換えると、コンテキストは次の 3,120 トークンになる。

[指示] tests/test_price.py の落ちているテストが通るように、プログラムを直す。（40 トークン）
[制約] tests/ の中のファイルは書き換えない。（20 トークン）
[1〜10手目の要約] 原因は price.py の discounted で、割合を 100 でなく 1000 で割っていた。修正はまだ当てていない。（60 トークン）
[11〜16手目の行動と結果]（3,000 トークン）

17手目の LLM にも制約は見えており、要約から、直す場所と、まだ直していないことが分かる。一方、2手目に読んだ price.py の中身そのものは要約に書かれていないので、もう見えない。17手目の LLM は「price.py を開き直す」を返し、18手目で「/ 1000」を「/ 100」に書き換える。shipping の行は要約から落ちたが、この修正には要らない。

二つのやり方で17手目の LLM に見えていたものから、次の三つが言える。

  1. LLM に見えるのは、その手番でハーネスが組んだコンテキストだけで、外したものは次の手から見えない。
  2. 古いものから外すと、最初に置いた指示と制約から先に消える。
  3. 指示と制約を固定し、古い手を要約に置き換えると制約は残るが、要約に書かなかった細部は消え、要るならツールで取り直すことになる。何を固定し、何を生のまま残し、何を要約に回すかの配分を決めることが、設計の中身になる。

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

少し前まで、AIをうまく使うコツは「プロンプトエンジニアリング」、つまり一回の指示文の書き方だと言われていた。 だが、エージェントが LLM（Large Language Model、大規模言語モデル）を何十回も呼ぶようになると、一回の言い回しより、呼ぶたびにコンテキストの全体をどう組み立てるかのほうが大事になった。新しい呼び名が広まりはじめたのは2025年6月ごろだ。Shopify の CEO Tobi Lütke が「プロンプトエンジニアリングより『コンテキストエンジニアリング』のほうが中身を言い当てている」と書き、Andrej Karpathy がそれに賛同して広めた。Willison はこのとき「定着するだけの力があるかもしれない」と書いている1。実際に、以後1年で Anthropic も Cline も、自社の設計をこの語で説明するようになった（後述）。OpenAI の Codex 解説記事は、コンテキストに何を載せるかの制御そのものを説きながら、この語は使っていない。

コンテキストに入るものは、大まかに次のとおりである。

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

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

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

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

全履歴を渡した条件が最も低かった。論文は失敗の中身も数えている。非完了のうち古い状態を参照して誤ったものは、全履歴で47%（34/73）、刈り込みで11%（6/53）だった。一方、刈り込みだけにすると、残高が見えなくなって手続きを打ち切る失敗が9件から18件へ倍増し、要約を足すと3件まで減った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倍に延びた3。

GPT-5 の 8.0% と 71.0% の差は、3条件の差とは別に読む。GPT-5 は利用者役なしだと8.0%しか完了せず、利用者役を付けた全履歴の条件で71.0%に上がる。この上がり幅について、著者らは「モデル固有の停止（stalling）挙動を反映している」と書く。著者らは、コンテキストエンジニアリングについての主張を全履歴・刈り込み・刈り込み＋要約の3条件の比較だけに置くと明記しており、71→79→91.6 の並びはその比較に当たる3。

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

実在のハーネスは、どうコンテキストを采配しているか

本節では、プロが実際に使うハーネスが、載せるものを減らす手をどう機構にしているかを見る（設計は各社が公開している）。

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

三者に共通するのは、コンテキストに積み上げるより、要るものを的確に選んで載せるという考え方だ。三者とも、満杯が近づけば履歴を要約で圧縮する。

三本の設計記事の説明が分かれるのは、脇道の探索を別のコンテキストへ出す手を機構として書くかどうかである。脇道を別のコンテキストで動くサブエージェントへ出す手を、引いた三本の記事のうち機構として書いているのは Anthropic だけである。Anthropic は、サブエージェントのコンテキストで数万トークン規模の探索をさせ、元のコンテキストへ戻すのは1〜2千トークンの要約に絞る4。Codex の解説記事がコンテキストウィンドウの枯渇に対して挙げるのは圧縮することだけで、単一の入力列に追記し、閾値を超えたらより小さな代表列へ丸ごと差し替える6。Cline の設計記事も同様に、別の入れ物へ出す手（/newtask・Deep Planning）は脇道の委譲ではなく本線の引き継ぎとして説明する5。ただし製品としては、Cline は2025年10月に実験機能としてサブエージェントを加え、Codex は2026年10月時点の現行版でサブエージェントを既定で有効にしており、両社とも探索の出力で主のコンテキストを汚さないための手だと説明している56。

もう一つの差は「何を捨てないか」の指定で、Anthropic は設計上の判断と未解決のバグを、Cline は決定とコード変更を残すと書く。追記のみでキャッシュを効かせる手と、todo をコンテキストの末尾へ書き直して脱線を防ぐ手は、Manus も2025年7月の設計記事で自社の機構として公開している9。「何を載せ続けるか」は、実在のハーネスが競って設計している一級の技術である。

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

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

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

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

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

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

出典12件

  1. Simon Willison「Context engineering」simonwillison.net, 2025-06-27. https://simonwillison.net/2025/Jun/27/context-engineering/ — Lütke と Karpathy の投稿（2025年6月）を引き、新語は定着しはじめたところで、受け取られ方が本来の意図に近く着地するだろうと結ぶ。 ↩ ↩2

  2. Liu ほか「Lost in the Middle: How Language Models Use Long Contexts」arXiv, 2023. https://arxiv.org/abs/2307.03172 https://lilianweng.github.io/posts/2023-06-23-agent/ — 2課題・当時のモデル。正解が中央の最悪ケースは閉本の56.1%を下回る（両端は上回る）。増やすほど遅延とコストも増す。記憶の区分は Weng（2023）。 ↩ ↩2 ↩3

  3. Abhilasha Lodha ほか「Less Context, Better Agents…」arXiv:2606.10209, 2026. https://arxiv.org/abs/2606.10209 — GPT-5・経費処理50課題で刈り込み＋要約（N=5, W=3）が最良。打ち切りの増加は原典本文の triples でなく Table 5 の2倍を採る。 ↩ ↩2 ↩3 ↩4

  4. Anthropic「Effective context engineering for AI agents」2025-09-29. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — context rot と注意の予算、Claude Code のハイブリッドな取得、長丁場向けの三手、なだらかな劣化を説き、コンテキストは有限の資源であり続けると結ぶ。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  5. Cline「How to think about context engineering in Cline」2025-08-19. https://cline.bot/blog/how-to-think-about-context-engineering-in-cline https://cline.bot/blog/understanding-the-new-context-window-progress-bar-in-cline https://docs.cline.bot/features/subagents https://github.com/cline/cline/releases/tag/v3.33.0 — Auto Compact と Focus Chain（既定6メッセージごと）。進捗バーは別記事、サブエージェントは docs と v3.33.0（2025-10-16・実験）が一次。 ↩ ↩2 ↩3

  6. M. Bolin「Unrolling the Codex agent loop」OpenAI, 2026年1月. https://openai.com/index/unrolling-the-codex-agent-loop/ https://developers.openai.com/codex/subagents — 追記のみの履歴でキャッシュを効かせ、圧縮は専用エンドポイントに委ねる。context engineering の語は使わない。サブエージェントは docs が一次（2026-10 は既定有効）。 ↩ ↩2 ↩3

  7. T. Shihipar「Lessons from building Claude Code: Prompt caching is everything」claude.com, 2026-04-30. https://claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything — 前方一致のキャッシュのため静的内容を先に置き、ツールとモデルを途中で変えず、コンパクションも親と同じ接頭辞で分岐させる。 ↩

  8. L. Martin「Reducing cost and improving performance with Claude Platform」claude.com, 2026-09-08. https://claude.com/blog/reducing-cost-and-improving-performance-with-claude-platform — 分岐が親のキャッシュを共有する条件は接頭辞のバイト一致・同じモデル・同じ effort。 ↩

  9. Manus「Context Engineering for AI Agents: Lessons from Building Manus」manus.im, 2025-07-18. https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus — KV キャッシュのヒット率を最重要の指標とし、コンテキストを追記のみにし、todo.md を書き直して目標をその末尾へ再掲することを挙げる。 ↩

  10. Lu Yi ほか「Learning Agent-Compatible Context Management for Long-Horizon Tasks」arXiv, 2026. https://arxiv.org/abs/2605.30785 — 外部LLMが強化学習でコンテキストを管理する AdaCoM。地力が高いほどより忠実な保持、低いほど強い圧縮が得。検索系の2課題のみで評価。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  11. Yilong Li ほか「EMBER: Efficient Memory via Budgeted Evidence Retention for Long-Horizon Agents」arXiv, 2026. https://arxiv.org/abs/2606.05894 — 同じ予算内では残す証拠で成績が決まると論じる。生履歴全体を引ける参照条件の F1 はより高い。査読前。 ↩ ↩2

  12. R. Chintalapati ほか「Evaluating Memory Condensation Strategies for Coding Agents…」arXiv, 2026. https://arxiv.org/abs/2605.18854 — 8種の圧縮はどれも仮説の質を有意に変えず、LLMを使う圧縮はトークンを24〜94%増やした。査読前。 ↩

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