Context Compression
Context Compressionは、モデルが動作するために実際に必要な情報を保持しながら、各呼び出しでモデルに提供されるトークン数を削減します。長期稼働するエージェントや長い会話で使用することで、コストとレイテンシを削減し、コンテキストウィンドウ内に収めることができます。3つの手段は、履歴の要約、無関係なコンテキストの整理、およびプロンプトの圧縮です。主なリスクは、重要な詳細を1つ落としてしまうという、情報の非可逆性（ロス）です。単に節約されたトークン数だけでなく、保持された情報を測定してください。
課題
長時間実行されるエージェントや複数ターンの会話はコンテキストを蓄積します。すべてのツール実行結果、過去のメッセージ、取得されたドキュメントが次の呼び出し時に再送されます。トークン数はインタラクションに伴ってほぼ線形に増加するため、呼び出しごとのコストとレイテンシが上昇し、最終的にはウィンドウが溢れて最も古い（時には最も重要な）コンテンツが暗黙的に切り捨てられます。単純な解決策（ウィンドウの拡大、よりアグレッシブな切り捨てなど）は、コストを上昇させるか、モデルが一貫性を維持するために必要な情報を破壊するかのどちらかです。
適用対象
単一のステップが必要とする量に対して、コンテキストが際限なく増加する場合に適用されます。例えば、長い履歴を持つ会話型アシスタント、多数のツール呼び出しをループする自律型エージェント、過剰に取得を行うRAGパイプライン、プロンプトサイズがコストの大部分を占めるバッチジョブなどです。蓄積されたコンテキストの多くが冗長または古くなっており、プロンプトの組み立てを制御でき、ある程度の再構成エラーを許容できる場合に適しています。すべてのトークンが不可欠である場合（法務、監査、正確な想起が求められるタスク）や、インタラクションが十分に短くウィンドウが圧迫されることがない場合には適していません。
解決策
稼働中のコンテキストを、単なる追記専用のログではなく、能動的に管理すべき「予算」として扱います。これには、相互に補完し合う3つの手段があります。要約（Summarization）は、履歴の一部をより短い概要に置き換えます。通常、古いターンのローリングサマリーを定期的に更新し、最近のターンはそのまま残します。プルーニング（Pruning）は、現在のステップに関連のないコンテキストを削除します。重複を排除し、古いツールの出力を破棄し、関連性しきい値を超える取得済みチャンクのみを選択します。プロンプト圧縮（Prompt compression、例：LLMLingua）は、より小さなモデルを使用して、プロンプトを送信する前に情報量の少ないトークンを削除または言い換え、わずかな精度低下と引き換えに大幅なトークン削減を実現します。 これらを明確な境界を持つパイプラインに構成します。そのまま残す直近のウィンドウ、古い履歴のローリングサマリー、そしてオンデマンドで埋められる取得スロットを維持します。識別子、制約事項、現在の目標など、決して圧縮してはならない事実のために「ピン留め（pinned）」領域を保護します。極めて重要なのは、結果を計測可能にすることです。圧縮ありと圧縮なしの回答を比較する評価セットを実行して、品質が低下するタイミングを把握し、グローバルではなくワークロードごとに圧縮の強度を調整します。圧縮は品質とコストのバランスを調整するダイヤルであり、無条件のメリットではありません。
コンポーネント
メリット
- 送信するトークン数を減らすことで、呼び出しごとの入力コストが直接削減され、長いエージェントループや大量のトラフィック全体でその効果が累積されます。
- プロンプトが小さくなると、エンコード量が減り、Time-to-First-Token（TTFT）が短縮されるため、インタラクティブなフローやエージェントフローにおける応答性が向上します。
- 稼働中のコンテキストを制限することで、ウィンドウのオーバーフローや暗黙的な切り捨てを発生させることなく、長い会話や多数のステップを持つエージェントの実行を継続できます。
- 冗長で古いコンテキストを削除することで、ノイズ（注意をそらす要素）が減り、モデルが現在重要な事項に集中できるようになるため、品質が向上する可能性があります。
リスク
- 要約やプルーニングによって、後から決定打となるはずだった唯一の詳細情報が破棄され、もっともらしい誤回答（ハルシネーション）が生成される可能性があります。
- ローリングサマリーは過去のサマリーをさらに要約するため、わずかな欠落が多くのサイクルを経て累積し、最終的に会話の文脈がいつの間にか逸脱してしまう可能性があります。
- 要約器や圧縮器を実行すること自体がレイテンシ、コスト、および障害点を増加させ、短いインタラクティブなやり取りにおいては削減効果が相殺される可能性があります。
- アグレッシブな排除を行うと、モデルが依然として依存している制約や指示が、明確なエラーシグナルなしに暗黙的に削除されてしまう可能性があります。
非推奨のケース
- すべてのトークンが不可欠である場合（法務、監査、コンプライアンス、または正確なデータ抽出など）、非可逆圧縮は許容されません。
- 会話がウィンドウを圧迫することがほとんどない場合、圧縮のオーバーヘッドは節約できるコストを上回り、不要な複雑さを招くだけです。
- 保持評価ハーネス（retention evaluation harness）がない場合は、何もデプロイすべきではありません。圧縮によって回答の品質が暗黙的に低下しているかどうかを判断できないためです。
テクノロジー
事例
- 大規模なコードベースを反復処理するエージェントが、直近のウィンドウをそのまま残しつつ、以前のステップのローリングサマリーを保持し、タスク仕様とファイルパスをピン留めすることで目標を見失わないようにします。
- マルチセッションのサポートボットが、過去のターンをコンパクトなケースサマリーに要約し、解決済みのサブイシューをプルーニング（削除）する一方で、顧客のアカウント制約をピン留めします。
- 多数のチャンクを取得する検索パイプラインが、関連性プルーニングとプロンプト圧縮を適用してシグナルの高い一節のみを送信し、回答を損なうことなくトークンを削減します。
本番環境での実績
- コンテキスト
- 57日間にわたり観察された、シングルオペレーターかつローカルファーストのOpenClawデプロイメント（161セッション / 2,776ターン）。エージェント自身のトラジェクトリトレースから集計。
- シナリオ
- 長い自律的なトランスクリプトが先制的に圧縮され、プロンプト予算内に収まるようにツールの実行結果が切り捨てられます。
- テクノロジー
- 安全マージンを設けた先制的な圧縮、ツール実行結果の切り捨て、コンテキストプルーニングフック、およびターン途中でのオーバーフロー事前チェック。
- 負荷
- 57日間にわたる2,776ターンにおける、2,810件のコンテキストコンパイルイベント。
- 結果
- 圧縮処理がウィンドウ全体でインライン実行され、コンテキストオーバーフローによる障害を発生させることなく、複数ステップの自律的なターンを予算内（ターンあたりp95 87.6秒）に維持しました。シングルオペレーターかつローカルファーストのデプロイメント。
KPI
- 呼び出しあたりのトークン数（入力）
- 主要なコスト要因。圧縮前後の分布を追跡します。健全な結果とは、下流の（後続の）エラーが増加することなく、明確に削減されている状態です。
- 情報保持 / タスク品質
- 評価セットを用いて、圧縮ありと圧縮なしの回答を比較します。良好な状態とは、トークン数が減少しても、許容範囲内で品質が安定している状態です。
- エンドツーエンドのレイテンシ
- 圧縮のオーバーヘッドを差し引いた正味の値。良好な状態とは全体のレイテンシが低下することです。要約器や圧縮器の呼び出しによって削減効果が相殺されないよう注意してください。
- コンテキストオーバーフロー / 切り捨て率
- インタラクションがウィンドウ制限に達する頻度。良好な状態とは、ピン留めされたコンテンツの破棄に頼ることなく、この頻度をゼロに近づけることです。
観察された失敗パターン
- 要約によって初期に言及された制約が省略され、何ターンも後に、その事実がコンテキストから完全に消失したためにエージェントが制約に違反してしまいます。
- 再要約が繰り返されることで、言い換えのエラーや省略が増幅され、最終的に実行中のサマリーが実際に起こったことを反映しなくなります。
- 予算の設定ミスにより、保護されるべき識別子や指示が圧縮され、暗黙的に正確性が損なわれます。
- アグレッシブな関連性しきい値によって、エッジケースで重要となるコンテキストが除外されてしまい、テストでは品質に問題がないように見えても、本番環境で失敗します。
得られた教訓
- トークン削減を最大化することは容易ですが、それ単体では意味がありません。真の指標は、モデルが依然として正しく回答できるかどうかです。
- 識別子、制約事項、および現在の目標を明示的に保護し、いかなる圧縮ステージでもそれらが排除されないようにします。
- アクティブなコンテキストではなく、古い履歴を圧縮します。直近のやり取りには、意思決定に最も関連するシグナルが含まれています。
- 評価セットを用いて、ワークロードごとに圧縮の強度を調整します。雑談において安全な設定であっても、監査タスクにおいては無謀な設定になり得ます。
FAQ
- これは長期記憶とどのように違うのですか？
- 長期記憶はプロンプトの外部に事実を永続化し、必要に応じてそれらを取得します。一方、コンテキスト圧縮は、呼び出しごとに送信される稼働中のコンテキストを縮小します。これらは補完関係にあります。記憶が「何を呼び戻すか」を決定し、圧縮が「それをいかにコンパクトにウィンドウ内に収めるか」を決定します。
- 要約、プルーニング、圧縮のどれを使用すべきですか？
- まずプルーニングを行います（コストがかからず、真の冗長性を排除する場合はロスレスです）。次に、古い履歴が際限なく増加する場合は要約を行い、さらに余裕（ヘッドルーム）が必要で、品質への影響を検証できる場合にのみプロンプト圧縮を追加します。ほとんどのシステムでは、これら3つすべてを組み合わせて使用します。
- 圧縮が品質を損ねているかどうかをどのように判断すればよいですか？
- 圧縮のオンとオフを切り替えて評価セットを実行し、トークン数だけでなくタスクの結果を比較します。もっともらしい誤回答や制約の欠落に注意してください。これらは、非可逆圧縮が過度に行われた際の特徴的な兆候です。