コンテキスト圧縮戦略

エージェントセッションが数百万トークンの会話履歴を生成する場合、圧縮は必須になります。素朴なアプローチはリクエストあたりのトークンを最小化するための積極的な圧縮です。正しい最適化の目標は、タスクあたりのトークン数です。つまり、圧縮が重要な情報を失った場合の再取得コストを含む、タスク完了までに消費された合計トークン数です。

使用時機

このスキルを有効にする条件:

• エージェントセッションがコンテキストウィンドウ制限を超える場合
• コードベースがコンテキストウィンドウを超える場合 (5M+ トークンシステム)
• 会話要約戦略を設計している場合
• エージェントが修正したファイルを「忘れてしまう」ケースをデバッグしている場合
• 圧縮品質の評価フレームワークを構築している場合

中核概念

コンテキスト圧縮はトークン削減と情報損失をトレードオフします。本番環境で使用可能な3つのアプローチが存在します:

1. アンカー付き反復要約: セッション意図、ファイル修正、決定、次のステップに関する明確なセクションを持つ構造化された永続的な要約を維持します。圧縮がトリガーされた場合、新しく切り詰められたスパンのみを要約し、既存の要約とマージします。構造により、特定の情報タイプに専用セクションを割り当てることで保存を強制します。

2. 不透明な圧縮: 復元忠実度に最適化された圧縮表現を生成します。最高の圧縮率 (99%以上) を実現しますが、解釈可能性を犠牲にします。何が保存されたかを検証できません。

3. 再生成フル要約: 各圧縮時に詳細な構造化要約を生成します。読み取り可能な出力を生成しますが、増分マージではなく完全な再生成のため、反復的な圧縮サイクルを通じて詳細が失われる可能性があります。

重要な洞察: 構造が保存を強制します。専用セクションはチェックリストのように機能し、要約者は入力する必要があるため、静かな情報ドリフトを防止します。

詳細トピック

なぜトークン・パー・タスクが重要か

従来の圧縮メトリクスはトークン・パー・リクエストをターゲットにしています。これは間違った最適化です。圧縮がファイルパスやエラーメッセージなどの重要な詳細を失うと、エージェントは情報を再取得し、アプローチを再度探索し、コンテキスト回復にトークンを浪費する必要があります。

正しいメトリクスはトークン・パー・タスク、つまりタスク開始から完了までに消費された合計トークン数です。0.5% 以上のトークンを保存する圧縮戦略でも、20% 多くの再取得コストを引き起こすと、全体的により多くのコストがかかります。

アーティファクトトレイル問題

アーティファクトトレイルの整合性は、すべての圧縮方法を通じて最も弱い側面であり、評価では2.2～2.5点(5.0点満点)のスコアを取得しています。明示的なファイルセクションを持つ構造化要約でさえ、長いセッション全体で完全なファイル追跡を維持するのに苦労しています。

コーディングエージェントが知る必要がある情報:

• どのファイルが作成されたか
• どのファイルが変更され、何が変わったか
• どのファイルが読み取られたが変更されなかったか
• 関数名、変数名、エラーメッセージ

この問題は、一般的な要約を超えた特別な処理が必要な可能性があります。エージェントスキャフォルディングの独立したアーティファクトインデックスまたは明示的なファイル状態トラッキングが必要です。

構造化要約セクション

効果的な構造化要約には明示的なセクションが含まれます:

## Session Intent
[ユーザーが達成しようとしていることは何か]

## Files Modified
- auth.controller.ts: JWTトークン生成を修正
- config/redis.ts: 接続プーリングを更新
- tests/auth.test.ts: 新しい設定のモックセットアップを追加

## Decisions Made
- リクエスト毎の接続の代わりにRedis接続プールを使用
- 一時的な障害に対するエクスポーネンシャルバックオフを伴う再試行ロジック

## Current State
- 14テスト合格、2テスト失敗
- 残り: セッションサービステスト用のモックセットアップ

## Next Steps
1. 残りのテスト失敗を修正
2. フルテストスイートを実行
3. ドキュメンテーションを更新

この構造は、各セクションが明示的に対処される必要があるため、ファイルパスや決定の無声損失を防止します。

圧縮トリガー戦略

圧縮のタイミングは、圧縮方法と同じくらい重要です:

戦略	トリガーポイント	トレードオフ
固定閾値	70-80% コンテキスト利用率	シンプルだが早期に圧縮する可能性
スライディングウィンドウ	最後のN個のターン + 要約を保持	予測可能なコンテキストサイズ
重要度ベース	低関連性セクションを最初に圧縮	複雑だが信号を保存
タスク境界	論理的なタスク完了時に圧縮	クリーンな要約だがタイミングは不規則

スライディングウィンドウアプローチと構造化要約の組み合わせは、ほとんどのコーディングエージェント使用例で予測可能性と品質のバランスが最適です。

プローブベース評価

ROUGEや埋め込み類似度などの従来のメトリクスは、機能的な圧縮品質をキャプチャするのに失敗します。要約は字句オーバーラップで高いスコアを取得しても、エージェントが必要とする1つのファイルパスを見落とす可能性があります。

プローブベース評価は、圧縮後に質問を提示することで、機能的品質を直接測定します:

プローブタイプ	テスト内容	質問例
Recall	事実の保持	「元のエラーメッセージは何でしたか?」
Artifact	ファイル追跡	「どのファイルを修正しましたか?」
Continuation	タスク計画	「次に何をすべきですか?」
Decision	推論チェーン	「Redisの問題について何を決定しましたか?」

圧縮が正しい情報を保存した場合、エージェントは正しく答えます。そうでない場合、推測または幻覚が生じます。

評価次元

6つの次元がコーディングエージェント向けの圧縮品質をキャプチャします:

1. 正確性: 技術的詳細は正確か? ファイルパス、関数名、エラーコード。
2. コンテキスト認識: 応答は現在の会話状態を反映しているか?
3. アーティファクトトレイル: エージェントは読み取られたか修正されたファイルを知っているか?
4. 完全性: 応答は質問のすべての部分に対処しているか?
5. 継続性: 情報の再取得なく作業を続行できるか?
6. 指示に従う: 応答は述べられた制約を尊重しているか?

正確性は圧縮方法間で最大の変動を示しています (0.6ポイント差)。アーティファクトトレイルは普遍的に弱いです (2.2～2.5範囲)。

実践的ガイダンス

3フェーズ圧縮ワークフロー

大規模なコードベースまたはコンテキストウィンドウを超えるエージェントシステムの場合、3つのフェーズを通じて圧縮を適用します:

1. 調査フェーズ: アーキテクチャ図、ドキュメント、主要インターフェースから調査ドキュメントを作成します。探索を要素と依存関係の構造化分析に圧縮します。出力: 単一の調査ドキュメント。

2. 計画フェーズ: 調査を関数シグネチャ、型定義、データフローを備えた実装仕様に変換します。5Mトークンコードベースは約2,000語の仕様に圧縮されます。

3. 実装フェーズ: 仕様に対して実行します。コンテキストは生のコードベース探索ではなく仕様に焦点を当てたままです。

サンプルアーティファクトをシードとして使用

手動移行の例または参照PRが提供された場合、それをテンプレートとして使用してターゲットパターンを理解します。この例は、静的分析が表面化できない制約を明らかにします: どの不変量が保持される必要があるか、変更時にどのサービスが壊れるか、クリーンな移行がどのようなものかです。

エージェントが本質的な複雑性 (ビジネス要件) と偶発的な複雑性 (レガシーワークアラウンド) を区別できない場合、これは特に重要です。サンプルアーティファクトはその区別をエンコードします。

アンカー付き反復要約の実装

1. エージェントのニーズに合わせた明示的な要約セクションを定義します
2. 最初の圧縮トリガー時に、切り詰められた履歴をセクションに要約します
3. 後続の圧縮時に、新しく切り詰められたコンテンツのみを要約します
4. 新しい要約を既存セクションにマージするのではなく再生成します
5. デバッグのため、どの情報がどの圧縮サイクルから来たかを追跡します

各アプローチの使用時機

アンカー付き反復要約を使用する場合:

• セッションは長時間実行 (100+メッセージ)
• ファイル追跡が重要 (コーディング、デバッグ)
• 何が保存されたかを検証する必要がある

不透明な圧縮を使用する場合:

• 最大トークン削減が必要
• セッションは比較的短い
• 再取得コストが低い

再生成要約を使用する場合:

• 要約解釈可能性が重要
• セッションに明確なフェーズ境界がある
• 各圧縮での完全なコンテキスト確認が受け入れられる

圧縮率の考慮

方法	圧縮率	品質スコア	トレードオフ
アンカー付き反復	98.6%	3.70	最高品質、わずかに少ない圧縮
再生成	98.7%	3.44	良好な品質、中程度の圧縮
不透明	99.3%	3.35	最高圧縮、品質損失

構造化要約により保持される0.7% の追加トークンは0.35の品質ポイントを得ます。再取得コストが重要なタスクの場合、このトレードオフは構造化アプローチを支持します。

例

例1: デバッグセッション圧縮

元のコンテキスト (89,000トークン、178メッセージ):

• /api/auth/loginエンドポイントでの401エラー
• 認証コントローラ、ミドルウェア、セッションストアを追跡
• 古いRedis接続を発見
• 接続プーリング修正、再試行ロジック追加
• 14テスト合格、2テスト失敗

圧縮後の構造化要約:

## Session Intent
有効な認証情報であるにもかかわらず、/api/auth/loginエンドポイントで401 Unauthorizedエラーをデバッグします。

## Root Cause
セッションストアのRedis接続が古い。JWTは正しく生成されるがセッションを永続化できません。

## Files Modified
- auth.controller.ts: 変更なし (読み取りのみ)
- middleware/cors.ts: 変更なし (確認)
- config/redis.ts: 接続プーリング設定を修正
- services/session.service.ts: 一時的な障害用に再試行ロジックを追加
- tests/auth.test.ts: モックセットアップを更新

## Test Status
14合格、2失敗 (モックセットアップの問題)

## Next Steps
1. 残りのテスト失敗を修正 (モックセッションサービス)
2. フルテストスイートを実行
3. ステージングにデプロイ

例2: プローブ応答品質

圧縮後、「元のエラーは何でしたか?」と質問:

良好な応答 (構造化要約):

「元のエラーは/api/auth/loginエンドポイントからの401 Unauthorizedレスポンスでした。ユーザーは有効な認証情報でもこのエラーを受け取ります。根本原因はセッションストアのRedis接続の古さでした。」

不良な応答 (積極的な圧縮):

「認証の問題をデバッグしていました。ログインに失敗していました。設定の問題を修正しました。」

構造化応答はエンドポイント、エラーコード、根本原因を保存します。積極的な応答はすべての技術詳細を失います。

ガイドライン

1. トークン・パー・リクエストではなくトークン・パー・タスクに最適化する
2. ファイル追跡用の明示的なセクションを持つ構造化要約を使用する
3. 70-80% コンテキスト利用率時に圧縮をトリガーする
4. 完全な再生成ではなく増分マージを実装する
5. プローブベース評価で圧縮品質をテストする
6. ファイル追跡が重要な場合、アーティファクトトレイルを別途追跡する
7. より良い品質保有のため、わずかに低い圧縮率を受け入れる
8. 再取得頻度を圧縮品質信号として監視する

統合

このスキルはコレクション内の他のいくつかに接続します:

• context-degradation - 圧縮は劣化の緩和戦略
• context-optimization - 多くの最適化手法の1つ
• evaluation - プローブベース評価は圧縮テストに適用される
• memory-systems - 圧縮はスクラッチパッドと要約メモリパターンに関連

参考資料

内部参考:

• 評価フレームワークリファレンス - 詳細なプローブタイプとスコアリングルーブリック

このコレクション内の関連スキル:

• context-degradation - 圧縮が防ぐものを理解する
• context-optimization - より広い最適化戦略
• evaluation - 評価フレームワークの構築

外部リソース:

• Factory Research: Evaluating Context Compression for AI Agents (2025年12月)
• LLM-as-judge評価方法論に関する研究 (Zheng et al., 2023)
• Netflix Engineering: 「The Infinite Software Crisis」 - 3フェーズワークフローとスケール時のコンテキスト圧縮 (AI Summit 2025)

---

スキルメタデータ

作成: 2025-12-22 最終更新: 2025-12-26 著者: Agent Skills for Context Engineering Contributors バージョン: 1.1.0

制限事項

• このスキルは、タスクが上記で説明されたスコープと明確に一致する場合にのみ使用してください。
• 出力を環境固有の検証、テスト、または専門家レビューの代替として扱わないでください。
• 必要な入力、権限、安全境界、または成功基準が不足している場合は停止し、確認を求めてください。