AIエージェントのコンテキストエンジニアリング：コンテキストウィンドウには実際何を入れるべきか

目次

2026年8月公開。

TL;DR: コンテキストエンジニアリングとは、各ステップでどのトークンがエージェントのコンテキストウィンドウに場所を得るに値するかを決める規律だ——システム指示、ツール定義、取得データ、会話履歴はすべて同じ限られたスペースを奪い合っている。プロンプトエンジニアリングはこれをどう表現するかを問い、コンテキストエンジニアリングはモデルが今まさに何を知る必要があるかを問う。よくある失敗モードはコンテキストが少なすぎることではなく、多すぎることだ——古びた履歴、無関係なツールスキーマ、誰も求めていない取得文書、これらすべてがシグナルを薄め、コストを押し上げる。私はカテゴリごとに固定予算を設け、アイデンティティより先に履歴を削り、切り捨てる前に要約する。

オペレーターの読み: 最もデバッグに苦労したエージェントは、モデルが弱かったから失敗したのではない。コンテキストウィンドウを雑多な引き出しにしてしまっていたから失敗したのだ——タスクに不要な6つのツールスキーマ、元の依頼から40ターンも逸れた会話履歴、技術的には関連しているが実質的には無用な取得文書。プロンプトを直しても助けにならなかった。プロンプトの前にあるものを直すことが、助けになった。

プロンプトエンジニアリングは動くエージェントをもたらした。コンテキストエンジニアリングは、それが実際のボリューム、実際の履歴、実際のエッジケースを扱うようになったときにも動き続けさせるものだ——そして今の私は、プロンプトの言い回しよりもこのスキルに多くの時間を費やしている。

プロンプトエンジニアリングとコンテキストエンジニアリングは同じ仕事ではない

プロンプトは一つの指示だ。コンテキストは、モデルがその指示に基づいて行動する際に見るものすべてを指す：システムプロンプト、呼び出せるツール、取得または照会した内容、そしてどれだけの過去の会話や実行履歴を持ち越すかという判断。プロンプトエンジニアリングは前者の言い回しを最適化する。コンテキストエンジニアリングは4つすべての構成を最適化する。

この区別は語彙上だけでなく、実務上も重要だ。もし私が入念に磨き上げたプロンプトを書いても、エージェントに無関係なツールスキーマを5つと古びた履歴を40ターン分渡してしまえば、言い回しはもう関係なくなる——モデルはほとんどノイズでできたコンテキストの上で推論しているのだ。私のエージェントで「デモでは動く」から「午前3時の妙な入力でも動く」に変わったものはすべて、ウィンドウの中身を直すことで到達しており、その中の指示を言い換えることでではない。

スペースを奪い合う4つの要素

各ターン、4つのカテゴリが同じ限られたスペースを奪い合う：

1. システム指示 ——アイデンティティ、ルール、出力形式。システムプロンプトに使っている5つの層を参照——これはほぼ固定のままであるべき唯一のカテゴリだ。プロンプトキャッシングはプレフィックスが動かないときにしか元が取れないからだ。
2. ツール定義 ——このターンでエージェントが呼び出す可能性があるすべてのツールのスキーマ、必要かどうかに関わらず。
3. 取得データ ——データベース、ベクトルストア、API呼び出しから引き出すあらゆるもの：メモリ、文書、顧客記録。
4. 会話または実行履歴 ——このセッションまたはこの実行ですでに起きたこと。

これらはどれも無料ではない。どのカテゴリのトークンも、モデルが次に何をすべきか決める際に他のすべてのトークンと天秤にかけなければならないトークンであり、キャッシュヒットでないリクエストごとに支払うトークンでもある。

間違いはほぼ常に多すぎることであり、少なすぎることではない

エージェントの挙動がおかしくなると、直感的にはコンテキストを追加したくなる——より多くの指示、より多くの背景、「念のため」のより多くの履歴。私の経験では、それはむしろ逆であることが多い。

ツールスキーマが多すぎる。 私はエージェントが正しいツールが欠けていたからではなく、そのタスクに不要な他の6つのツールの後ろに埋もれていたために間違ったツールを呼び出すのを見てきた。現在のステップに関連するツールだけを送り、呼び出しのたびにツールボックス全体を送らないこと。どのツールのサブセットを公開するかを決めるルーティング層は構築コストが低く、誤った呼び出しを一度でも防げればすぐに元が取れる。

古びた会話履歴。 3つの無関係な過去のインシデントから60ターン分の履歴を引きずっているサポートエージェントは、「顧客を覚えている」のではない——無関係なノイズで現在のリクエストを薄め、時にはすでに真実でなくなったことに基づいて行動している。これはまさに有界なウィンドウを持つエピソード記憶が防ぐべき失敗モードであり、自分のウィンドウが本当に有界なのか、それとも静かに際限なく成長してしまったのかを確認する価値がある。

誰も求めていない取得文書。 意味的検索が上位2件の関連するチャンクではなく上位10件の「最も似た」チャンクを返すと、答えはもっともらしく見える気晴らしの下に埋もれてしまう。取得コンテキストが多いことはシグナルが多いことを意味しない——ある点を超えると、それは積極的に悪化する。モデルが重要な部分を見つけるためにより多くの労力を払わなければならなくなるからだ。

防御的に繰り返される指示。 これは、エージェントの以前のバージョンが一度無視したという理由で、同じルールを4通りの異なる言い方で繰り返すプロンプトに見られる。これは、そのルールをプロンプトのより早い位置に移すか、構造的に強制する（ツールスキーマ内の制約、検証ステップ）必要があるという合図であり、繰り返しでコンテキストを埋める合図ではない。

私が実際に使っている予算

30以上の本番エージェントにわたって、エージェントを構築する前に——挙動がおかしくなり始めた後ではなく——カテゴリごとに明示的なトークン予算を設定する：

最後の列の順序が実際の意思決定フレームワークだ：まず履歴、次に取得の幅、次にツールの範囲、そしてシステム指示は最後に削る。 履歴は正確さを失わずに圧縮するのに最も安上がりだ——「1〜30ターンで何が起きたか」を2文で要約したものは、通常、完全な書き起こしと同じ運用上の価値を持つ。システム指示を削ることが最も危険だ。そこにエージェントの実際の挙動が宿っているからだ。

切り捨てる前に要約する

トランケーション——単に古いターンを落とすこと——はこれの粗いバージョンだ。落としたターンにエージェントが必要とする唯一の事実が含まれていた場合を除けば機能する。より良いパターンはコンパクションだ：生の履歴を破棄する前に、それを決定と事実を捉えた短い構造化サマリーに折りたたみ、生のターンが消えた後もそのサマリーを永続的に保持する。

// workers/compact-history.ts

interface HistoryDigest {
  summary: string; // 2〜3文：何が決定・解決されたか、あるいは未解決か
  keyFacts: Record<string, string>; // そのまま保持する価値がある安定した事実
  turnCount: number; // このダイジェストが置き換える生のターン数
}

async function compactIfNeeded(
  history: ConversationTurn[],
  env: Env
): Promise<{ digest: HistoryDigest | null; recent: ConversationTurn[] }> {
  const RECENT_WINDOW = 10;
  if (history.length <= RECENT_WINDOW) {
    return { digest: null, recent: history };
  }

  const toCompact = history.slice(0, -RECENT_WINDOW);
  const recent = history.slice(-RECENT_WINDOW);

  // このステップには安価なモデルによる要約でほぼ常に十分
  const digest = await summarizeTurns(toCompact, env);
  return { digest, recent };
}

これは、あらゆる本番障害を恒久的なテストケースに変える評価ハーネスと同じ原則だ（AIエージェントを出荷するために使っている評価ハーネスを参照）：情報を捨てるのではなく、保持コストが低く、それでいて有用な形に圧縮するのだ。生のターンは使い捨てでよい。その中の事実は通常そうではない。

検索：より少なく、より関連性の高い結果はより多くの結果に勝る

同じ規律は、ベクトルストアやデータベースから取り出すあらゆるものにも当てはまる。「コンテキストが多いことは害にならない」という理論のもと、気前よく検索する——top-10、top-20——のは魅力的だ。だが害になる。無関係なチャンク一つひとつが、モデルが読み、天秤にかけ、捨てなければならないチャンクであり、ほぼ一致する結果が十分な量積み重なると、実際に質問に答えている唯一のチャンクより重くなりかねない。

私のデフォルトは小さいk（2〜4）から始め、その幅で実際に答えが欠けていることを実際のケースで示せたときにのみ広げることだ——より広い網が安全に感じられるからではない。検索の質が一貫しない場合、解決策は通常より良いクエリか再ランキングのステップであり、より大きなkではない。

コストと正確さに結びつける

コンテキストエンジニアリングは品質の問題であるだけでなく、エージェントの運用コストに対する最大の単一のレバーでもある。ほとんどのエージェントのワークロードでは、出力トークンよりも入力トークンにはるかに多くの課金がされるからだ。肥大化したコンテキストウィンドウは、挙動のバグになる前に、肥大化した請求書になる。モデルの層を選ぶためのコスト計算をまだ見ていないなら、適用するコンテキスト予算がその計算を直接変えることを知っておいてほしい：小さく、よく境界づけられたコンテキストは、より安いモデルをより多くのタスクで実用的にする。モデルに不必要に巨大な干し草の山から針を探させずに済むからだ。

私が運用しているすべてのエージェントはClaude上で動いており、モデルの層に関する判断はコンテキスト予算が固定された後にのみ意味を持つ——肥大化し境界のないコンテキストの上でコストを比較しても、そのタスクが実際に何を必要としているかは何も分からない。

そして、コンテキストウィンドウの中身を変えることはプロンプトを変えることと同じくらい挙動を変えるため、あらゆるコンテキストの変更は、プロンプトの変更と同じゲートを通る：出荷する前に実際の本番障害から構築された評価セットに対して実行するのだ。履歴を削ったり検索の幅を狭めたりすることは、まさに「明らかに安全」に見えて、確認しなければ静かにエッジケースを退行させる類の変更だ。

オペレーターの結論

コンテキストエンジニアリングとは、各ターンで何が限られたウィンドウの場所に値するかを決めることであり、デフォルトの失敗は少なすぎることではなく含めすぎることだ。システム指示は安定させ、最後に削るものにすること。ツール定義は現在のステップに限定すること。検索は狭く行い、証拠がある場合にのみ広げること。履歴は破棄する前にサマリーに圧縮し、最も古い生のターンから先に削ること。そして、あらゆる変更を評価に照らして検証すること。コンテキストの変更はプロンプトの変更とまったく同じように挙動を変えるからだ——ただ、そうではないふりをする方が簡単なだけだ。

よくある質問

AIエージェントのコンテキストエンジニアリングとは何ですか？

これは、システム指示、ツール定義、取得データ、会話履歴といったどのトークンが各ステップでエージェントのコンテキストウィンドウに入るかを決める規律であり、単一の指示がどう表現されるかに関わるプロンプトエンジニアリングとは異なる。4つのカテゴリすべてがリクエストごとに同じ限られたスペースを奪い合う本番環境で最も重要になる。

コンテキストエンジニアリングはプロンプトエンジニアリングとは違うものですか？

はい。プロンプトエンジニアリングは指示の言い回しを最適化する。コンテキストエンジニアリングは、その指示と並んでモデルが見るその他すべて——どのツールが公開されているか、何が取得されたか、どれだけの履歴が持ち越されるか——を最適化する。よく書かれたプロンプトでも、無関係なツールスキーマや古びた履歴に囲まれていれば、それでも失敗する。

AIエージェントはどれくらいの会話履歴を保持すべきですか？

思っているより少なくてよい。有界なスライディングウィンドウ（直近10〜20ターンが典型的）に、それより古いものすべての圧縮サマリーを加えたものは、通常、完全な生の書き起こしより優れている。ノイズを取り除きつつ重要な事実を失わないからだ。履歴を捨てる前に圧縮すること、単に切り捨てるのではなく。

コンテキストウィンドウが大きいほど、必要なコンテキストエンジニアリングは少なくて済みますか？

いいえ——それは厳しい技術的な上限を取り除きますが、コストやノイズの問題は取り除きません。ウィンドウが大きくなると雑さが安上がりになりますが、無関係なトークンはそれでもモデルが処理しなければならないシグナルを薄め続け、キャッシュヒットでないリクエストごとに引き続きお金がかかります。この規律は200Kトークンでも8Kトークンでも同じくらい重要です。

関連： 本番環境で失敗しないAIエージェントのシステムプロンプトの書き方 · AIエージェントにメモリを追加する方法 · プロンプトキャッシング：モデルを変えずにClaudeのコストを削減 · AIエージェントを出荷するために使っている評価ハーネス

あなたのユースケースに合わせてエージェントのコンテキストとメモリを設計する手助けが必要ですか？ お問い合わせ — オペレーターチームのための本番エージェントシステムを設計しています。