コンテキストエンジニアリング：ウィンドウ管理とコスト最適化の実践ガイド

本稿は、LLM エージェントを運用する際に直面する「コンテキスト エンジニアリング」の課題と、ウィンドウ（コンテキスト）をどのように管理すべきかをまとめたフィールドノートです。

コンテキストウィンドウの物理的制約

コンテキストウィンドウは、モデルが 1 回の呼び出しで処理できるトークン数の上限です。システムプロンプト、ツールの結果、過去の会話ターンすべてがこの上限を巡って競合し、上限に達すると新しいトークンは既存のトークンを排除しなければなりません。ウィンドウはキャッシュとして振る舞い、メモリとして扱うと長期的なエージェント実行で致命的な情報喪失が起こります。

何が保管され、何がドロップされるか

ウィンドウをキャッシュと認めた上で行うべきは「パッキング」の決定です。主に二つの障害モードがあります。

• 汚染：不要な情報や失敗した試行結果が残り続け、次のターンで誤ったコンテキストとなる。
• 圧縮：重要な情報を過度に削除し、必要なファクトが失われる。

どちらもウィンドウ内の保持・削除ポリシーが不適切であることが原因です。解決策は、永続的に保持すべき「ビン」（制約、ID、タスク目標など）と、一時的に削除しても問題ないコンテンツを区別し、スキーマ化されたパッキング決定を行うことです。

誤ったウィンドウ管理が招くコスト

ウィンドウを拡張せずに情報を蓄積し続けると、トークン使用量は二次関数的に増大します。例えば N ステップの実行では総トークン数は N²/2 に近づき、実行時間が長くなるほどコストは急激に上昇します。また、情報が欠落すると精度が低下し、人間のレビューが必要になるため、トークン料金以上の追加コストが発生します。

実践的な対策

コンテキストエンジニアリングを専門領域として扱うための具体的な手順は次の通りです。

1. 永続ビンを明示的に列挙し、テスト可能にする。削除禁止項目（制約、ID、タスク目標など）はサマライザの対象外とし、復元テストを行う。
2. ウィンドウサイズを固定予算として設定し、タスクに必要な長さに基づいて調整する。訓練データの長さ分布と実運用の分布を照らし合わせる。
3. すべてのエビクションとスクラブ（削除）を記録し、何が落とされたかを監査できるようにする。
4. パッキングポリシーをテストし、圧縮されたコンテキストだけでエージェントが必要な情報を再現できるか確認する。

これらの取り組みによって、ウィンドウ管理の意思決定が透明化され、コスト増大や情報喪失といったリスクを抑制できます。

元記事: https://dev.to/loopandretry/context-engineering-what-fits-and-what-gets-dropped-34ki