コンテキストエンジニアリング：それが何であり、より良いAIエージェントを構築するために私がどのように使用するか

目次

2026年7月公開。

TL;DR： プロンプトエンジニアリングは言葉の選択に関するものですが、コンテキストエンジニアリングは情報アーキテクチャに関するものです。有限のコンテキストウィンドウがあり、すべてのトークンはトレードオフです。エージェントのコンテキストを4層に構造化し、ウィンドウを予算として扱うことで、モデルを切り替えるよりも信頼性が向上しました。

[オペレーターノート] 30以上のエージェントを本番環境で運用しています。昨年最も差をつけたのは、より良いモデルでも、より洗練されたフレームワークでもありません——コンテキストウィンドウに何を入れ、何を除外するかについてより意識的になることです。コンテキストエンジニアリングは、エージェントの作業を評価する際に私が求めるコアスキルです。

ほとんどの人は、AIと作業するための重要なスキルとして「プロンプトエンジニアリング」について語り続けています。プロンプトエンジニアリングは実在し、重要です。しかし、それはより大きな規律のサブセットです——それを全体の仕事として扱うことが、デモでは良く見えても本番環境で失敗するエージェントが多い理由です。

「プロンプトエンジニアリング」が間違ったフレームになった理由

「プロンプトエンジニアリング」は、主要なレバーがシステムプロンプトやユーザーメッセージに書くテキストであることを意味します。適切な指示、適切な言葉、適切なフォーマットを作成するのに十分な時間を費やせば、モデルは必要なことをしてくれる。

これはある程度まで正しいです。よく書かれたシステムプロンプトは必要です。しかし、モデルの動作はコンテキストウィンドウにあるすべてのものによって決定されます——システムプロンプトだけではありません。以下によって形成されます：

• 会話履歴（以前のターンで何が起こったか）
• 取得して注入したドキュメントやデータ
• モデルがこれまでに見たツール呼び出し結果
• 各情報のトークン数と位置

プロンプトの言葉遣いだけを考え、コンテキストウィンドウを埋める残りの部分を無視している場合、1つの入力を最適化しながら他の入力を管理しないままにしています。だからこそ、「コンテキストエンジニアリング」が真剣なエージェント作業のより正確なフレームなのです。

コンテキストエンジニアリングとは実際に何か

コンテキストエンジニアリングは、どの情報がモデルのコンテキストウィンドウに入るか、どのような順序で、会話のどの時点でを決定する規律です。

コンテキストウィンドウはモデルのワーキングメモリです。それは有限です。中に入れるすべてのトークンは他の何かを押しのけます——またはコストを増加させます。そして、人間のワーキングメモリとは異なり、モデルはウィンドウの外にある何かを「調べる」方法がありません（そのためのツールを与えない限り）。見えるものがすべてです。

コンテキストエンジニアリングは、そのウィンドウを意図的に管理されるリソースとして扱う実践です：

• このステップを完了するためにモデルは何を知る必要があるか？
• 前のステップで知る必要があったが、もう必要ないものは何か？
• 実行間で安定しているものは何か、リクエストごとに動的なものは何か？
• 各情報はウィンドウのどこに現れるべきか？

これらはプロンプトの言葉遣いに関する質問ではありません。情報アーキテクチャの質問です。そして答えは、モデルの選択と同様にエージェントの信頼性を左右します。

私が設計する4つのレイヤー

私が構築するすべてのエージェントには4つの異なるコンテキストレイヤーがあります。それぞれを別々に考えます。

レイヤー1：システムプロンプト

これは安定した、ターンに依存しない基盤です。エージェントが誰であるか、何ができるか、何ができないか、エッジケースをどのように処理すべきかを定義します。

ほとんどの人がここで犯す間違いは、システムプロンプトを一度書いて完成とみなすことです。実際には、システムプロンプトは3つの質問に明示的に答える必要があります：

1. このエージェントは何のためにあるか？（モデルには漠然とした使命ではなく、明確なスコープが必要です。）
2. 入力が曖昧または不完全な場合、どうすべきか？
3. 何を絶対にしてはならないか？（否定的な制約が重要です。）

システムプロンプトを最小限に保ちます。不必要な文はすべて、実際の推論が行われる動的コンテンツと競合するオーバーヘッドです。

実践的なヒント：Claude APIを使用している場合、システムプロンプトにcache_controlを使用します。大型の安定したシステムプロンプトをキャッシュすると、ターンごとにキャッシュされていないものの約10%のコストになります。

レイヤー2：会話履歴

マルチターンエージェントでは、会話履歴は動的で、各ターンで成長します。管理なしでは、コンテキストの膨張の最大の要因になります。

問題：初期のターンにはモデルがもう必要としない情報が含まれています。すべてを保持するとトークンが無駄になり、古いコンテキストを推論に使用することでモデルが混乱する可能性があります。

私がすること：

• 履歴がしきい値を超えたら古いターンを切り捨てるか要約する。
• まだ関連性のあるツール呼び出し結果のみを保持する。
• 長期実行エージェントでは履歴を無限に成長させない。

レイヤー3：取得コンテンツ

これが平凡なエージェントと優れたエージェントを分けるレイヤーです。ほとんどのエージェントは実行時に外部データを引き出す必要があります。

私が適用する2つの原則：

現在のステップに関連するものだけを取得する。 現在のステップが1つのセクションだけを必要としているときに、50ページのドキュメントを注入しないでください。

位置が重要です。 コンテキストの最初と最後の情報は、中間の情報よりも重く重み付けされます。モデルが絶対に使用しなければならない取得コンテンツがある場合、長い注入の中間に埋めないでください。

レイヤー4：ツール出力

エージェントループでは、モデルはツールを呼び出してその結果を受け取ります。それらの結果が蓄積されます。会話履歴とは異なり、それらを管理することを考える人はほとんどいません。

解決策は同じです：ツール結果がその目的を果たしたら、ウィンドウに保持する必要はありません。マルチステップエージェントでは、前の各ステップの生の出力ではなく、「これまでに確立したこと」の構造化された要約を前方に運びます。

コンテキスト予算：何を含めて何を削減するか

シンプルなメンタルモデルを使用します：コンテキストウィンドウは予算であり、すべてのトークンは支出です。各エージェントターンの前に問います：

• このステップを行うために今モデルは何を知る必要があるか？
• 重要なものを失わずに何を省略または要約できるか？
• レイヤー間で何が重複しているか？

目標は、包括的であることではなく、各ステップで可能な限り高いシグナルの情報でウィンドウを詰め込むことです。

本番環境で私が犯した3つのコンテキストエンジニアリングの間違い

1. 安定したプレフィックスに浮動するタイムスタンプ。 システムプロンプトの先頭に現在の日付：{{日付}}を置いていました。その文字列は毎日変わり、24時間ごとにプロンプトキャッシュが静かに無効化されていました。タイムスタンプ、ユーザーIDなどの揮発性情報を、安定したプレフィックスの後のコンテキストの末尾に移動します。

2. ツール出力を追加専用として扱う。 各ツール呼び出し結果がコンテキストに残るエージェントループを実行していました。ターン8では、モデルは80%が古いツール出力のコンテキストから推論していました。

3. コンテキスト変更時に評価をスキップする。 コンテキストの変更はモデルの動作の変更です。今では、プロンプト変更と同じ評価ハーネスをコンテキスト変更にも実行しています。

実際のコンテキストエンジニアリングワークフロー

エージェントコードの1行を書く前に、コンテキストレイヤーをスケッチします：

システムプロンプト：    ~500トークン、安定、キャッシュ済み
履歴予算：             ~2000トークン最大、各ステップ後に要約
取得コンテキスト：     ステップごとに~1000-3000トークン、関連チャンクのみ
出力予算：             現在のステップのみ、前方に要約して運ぶ

モデル選択の質問はその後です。どのようなコンテキストエンジニアリングが必要かがわかったら、正しいコンテキスト設定で信頼性の基準を維持する最も安価なモデルを選択します。

FAQ

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

プロンプトエンジニアリングは、システムプロンプトとユーザーメッセージの言葉遣いに焦点を当てています。コンテキストエンジニアリングはより広い規律です：完全なコンテキストウィンドウ（会話履歴、取得データ、ツール出力を含む）にどの情報が入るか、どのような順序で、どのようなトークンコストで決定することです。

システムプロンプトはどのくらい大きくすべきですか？

具体的でありながら可能な限り小さくすること。ほとんどのエージェントで800トークン未満を目指しています。すべてのシナリオを予測しようとするシステムプロンプトは、モデルが信頼性を持って読むには長すぎる結果になります。

コンテキストエンジニアリングは一部のモデルにとって他よりも重要ですか？

すべてのモデルに重要ですが、小さいモデルではリスクが高くなります。大型フロンティアモデルは時に構造が不良なコンテキストから回復できます；より厳しい予算の小型モデルはできません。

コンテキストエンジニアリングが機能しているかどうかはどうすればわかりますか？

信頼性の変更を追跡するのと同じ指標を追跡します：評価セットの成功率、成功した結果ごとのコスト、ステップ別のエラー分布。

常に履歴を圧縮または要約すべきですか？

短い取引エージェントの場合：不要。5〜6回以上のやりとりを実行するマルチターンエージェントの場合：はい、常に。私が使用する経験則——履歴予算がコンテキスト予算合計の30%を超えたら、要約を始めます。