6月18日、Jim Allen Wallaceが「5 Context-Engineering Principles for Production AI」と題した記事を公開した。この記事では、本番環境でAIエージェントを安定稼働させるための5つのコンテキストエンジニアリング原則について詳しく紹介されている。
デモでは完璧に動くエージェントが、本番投入後の1週間でループし始め、トークンコストが急騰し、存在しない事実を自信満々に返す——。モデルは何も変わっていない。変わったのはその周囲のコンテキストだ。
コンテキストエンジニアリングとは、LLM推論時に最適なトークンセット（情報）をキュレーション・維持するための戦略群を指す。1日に数千セッションをさばく環境では、プロンプト単位の最適化だけでは追いつかない問題が次々と顕在化する。
原則1（最重要）：コスト単位は「ターン」ではなく「1回の実行全体」
最も見落とされがちな観点がここだ。
プロンプトを最適化してトークン数を30%削っても、請求額がほとんど変わらない経験はないだろうか。それはコスト単位を間違えているサインだ。各APIコールは個別に課金されるが、毎ターンの入力には会話履歴の全体が再送される。その結果、1ターンあたりの入力は線形に増えるが、実行全体の累積コストははるかに速く膨らむ。記事のコストモデルでは、ツール呼び出しを伴うマルチターンエージェント（元記事ではGPT-4クラスのモデルを想定）において、会話長を2倍にするとコストは約4倍になるとしている。
さらに悪化させるのがツール出力だ。ファイル読み込み、ターミナル出力、検索結果は過去のターンのものも毎回再送される。ターン10の時点で、エージェントが二度と参照しない数千トークンの古いツール出力を毎回再処理することになる。
この問題への処方箋の一つがセマンティックキャッシングだ。新しいクエリが過去のキャッシュ済みクエリと意味的に同一であれば（表現が違っても）、モデルを呼ばずにキャッシュされたレスポンスを返す。Redisが提供するセマンティックキャッシュライブラリLangCacheは、反復トラフィックの多いワークロードで最大73%の推論コスト削減をRedis自身のベンチマークで報告している。
ただしマルチターンエージェントでは、フォローアップの質問が以前の無関係なプロンプトと誤マッチングされないよう、キャッシュキーと類似度閾値をセッション状態を考慮して設計する必要がある。
原則2：ツール出力はウィンドウが膨らむ前に、取り込み時点でフィルタする
LLM以前に設計されたAPIは決定論的システム向けに作られており、エージェントが必要とする3フィールドのために大量のネストしたJSONを返してくる。これをそのままコンテキストに積み上げると、シグナルがノイズに埋まる。
直感的には「会話が長くなったら要約する」という後処理に走りがちだが、これは順序が逆だ。取り込み時点でフィルタする方が効果的な理由は2つある。次のステップに必要な情報だけを残せること、そしてコンテキストポイズニング（早期の誤情報が「事実」として保存され、後続の推論に複利式に影響する現象）を防げることだ。
実践的なパターンとしては以下の3つが挙げられている：
- 大きなレスポンスはオフロード：プロンプト外に保存し、ポインタと短いプレビューだけ埋め込む
- ノイジーなコンテンツはトランケート：トークンポリシーでツール出力を上限設定し、次ターン前にトリムする
- 古い結果はクリア：メッセージ履歴の奥に沈んだツール結果の生データはもう不要
トリミング時は、メッセージの途中で切るよりターン単位で丸ごと削除する方がコヒーレンスを保ちやすい。
原則3：静的コンテキストと動的コンテキストを別レイヤーに分ける
指示・取得データ・履歴を一つの文字列に混ぜ込む設計が、エージェントの信頼性問題の多くの根本にある。
推奨パターンは静的レイヤー（システム指示、ペルソナ、行動ルール）と動的レイヤー（取得した知識、会話履歴、作業状態）の分離だ。静的部分はキャッシュが効き、動的部分は毎ターン新鮮にする必要がある。本番チームはさらにセッションレイヤーを加えた3層構成を取ることが多い。
重要な設計原則は「ストアすることとモデルに送ることは別の判断」という点だ。エージェントはトラッキングしているすべてを構造化状態として保持しつつ、特定のターンにはその関連部分だけをLLMに渡す。残りはプロンプトのコストを払わずに保持できる。
このレイヤー分離は実装の複雑さを増やすように見えるが、逆にデバッグを大幅に容易にするという副次的効果がある。障害発生時に「問題が静的な指示にあるのか、動的な取得データにあるのか、セッション状態にあるのか」を切り分けられるようになるためだ。一枚岩のプロンプト設計ではこの切り分けができず、コンテキスト劣化の原因追跡に余分なコストがかかる。
原則4：検索は「全部取ってくる」のがデフォルトではなく、予算の判断
より多くの関連ドキュメントを取得しても、回答精度は必ずしも向上しない。むしろ悪化することがある。
背景にあるのは「lost in the middle」問題だ——入力の先頭や末尾に関連情報があるときモデルのパフォーマンスは高く、中間に埋まると劣化する。さらに反直感的な事実として、意味的に近いが正解でないドキュメントは、明らかに無関係なドキュメントよりも精度を落とす。一つのRAG研究では、クエリに意味的に近いが実際には答えていないドキュメントを追加すると、ランダムノイズの追加より精度が悪化したと報告されている。高精度なリトリーバーほど「ハードネガティブ」（意味的に近いが事実として誤った文章）を引っ張ってきてしまうリスクがある。
対策は広く取得してリコールを確保し、クロスエンコーダーで再ランキングしてプレシジョンを高める構成だ。クロスエンコーダーがコンテキストウィンドウに入る前にハードネガティブを弾く。
原則5：コンテキスト障害は標準的なEvalに映らない
残りの原則をすべて守っても、テストスイートはコンテキスト劣化を検出できない可能性が高い。
LLMの標準ベンチマークは短い質問形式が中心で、コンテキストが容量限界に近づいた状態でのパフォーマンスをほとんどテストしない。あるエージェント評価では、25,000〜150,000トークンのセッションで成功率が40〜50%から10%未満に落ち込み、エージェントがループに入り本来のタスクを見失ったと報告されている。別の長コンテキスト評価では、コンテキスト長を32Kから256Kに増やすと**精度が29%から3%**まで落下した。
これを元記事では 「context rot（本稿では"コンテキストロット"と訳す）」 と呼ぶ。モデルはエラーなく動き続けながら、静かに精度が劣化していく現象だ。例外も失敗アサーションも出ない。
標準的なユニットテストや短セッションのEvalがこれを検出できない理由は構造的だ。テストケースは通常、クリーンな状態から始まる単発の質問で構成されており、セッションが30ターンを超えた状態でのゴール達成度や履歴が蓄積した後のツール選択の一貫性は評価軸に入っていないことがほとんどだ。
対策はデプロイ前テストだけでなく本番トレースを使ったセッションレベルの評価を行うことだ。コヒーレンス、コンテキスト保持、ゴール達成度といった軸でセッション全体を評価し、実際の本番トレースをオフラインのテストセットにフィードバックする仕組みが有効だ。長セッションの本番データを意図的に収集・ラベリングしてEvalセットに組み込むことが、コンテキストロットの早期検知における現実的な出発点となる。
まとめ
5原則に共通する根本原因は一つ——コンテキストの管理不備はデータの問題であり、モデルの問題ではない。コンテキストウィンドウを広げても解決しない。それはただ「間違いを積める上限」を引き上げるだけだ。
エンジニアが本番AIエージェントを安定させたいなら、プロンプトレベルの最適化ではなく、コスト単位・フィルタリング・レイヤー設計・検索戦略・評価設計という5つのデータ層の問題として捉え直す必要がある。
詳細は5 Context-Engineering Principles for Production AIを参照していただきたい。
