長時間動くAIエージェントは、会話だけを覚えているわけではない。検索で見つけたURL、ツール実行の結果、編集したファイルのパス、ユーザーが途中で加えた修正指示、失敗から得た原因、再開に必要なハンドルなどを抱え込む。
この履歴が長くなると、入力トークンの費用と応答遅延が増える。そこで多くの仕組みは、古い履歴を要約するか、古いメッセージやツール出力を消す。しかし、単に古い情報を減らすと、後で必要になるURL、ファイルID、正確な表の値、ユーザーの禁止事項まで失いかねない。
Self-GC: Self-Governing Context for Long-Horizon LLM Agentsは、この問題を「コンテキストを短くする」ことではなく、エージェントの実行中に生まれる情報を、復元可能性を含めて管理することとして扱う。論文の主張は、エージェントの記憶を一続きのトークン列ではなく、寿命と依存関係が異なる実行オブジェクトとして扱おう、というものだ。
長いコンテキストは「会話履歴」だけではない
単発の質問なら、過去の会話を要約しても大きな問題は起きにくい。だが、Webを調べ、シェルを実行し、文書や表を編集するエージェントでは、履歴に次のような情報が混ざる。
ユーザーの目的・制約
├─ 「表の見出しは変えない」
├─ 「本番への変更はしない」
└─ 「このURLを根拠に使う」
実行の状態
├─ 読み込んだファイルパス・文書ID
├─ 実行中ジョブのハンドル・コールバックURL
├─ 検索結果・ツール出力・エラーログ
└─ 成功した再実行の結果
成果物と根拠
├─ 編集済み本文・差分
├─ 表の値・SQL条件・スタックトレース
└─ 引用する一次情報
ここで重要なのは、情報の長さや古さと、将来必要かどうかは一致しないことだ。古いツール出力にしかないURLは後で再び開く必要がある。一方、直前の失敗ログは、再実行が成功した後なら不要かもしれない。
固定ルールで「最も古い履歴を消す」「ツール出力を消す」と決めると、この違いを扱えない。Self-GCは、ユーザーの発話、ツール実行の範囲、スキル状態をID付きのオブジェクトとして扱い、別のplannerモデルに今後の依存関係を考えさせる。論文の問題設定
Self-GCの中心は、削除ではなく三つのライフサイクル操作
Self-GCがplannerに選ばせる操作は三つある。すべてを要約するのではなく、情報の性質に応じて扱いを分ける。
| 操作 | 何をするか | 向く情報 | 注意点 |
|---|---|---|---|
| Fold | 本文を別のストレージへ退避し、アクティブな文脈には復元用の短い参照を残す | 後で原文の再編集・再引用が必要な長い文書や成果物 | 退避先のアクセス制御、保存期間、完全性が必要 |
| Mask | 冒頭と末尾など構造的な手掛かりを残し、途中の反復部分を省く | 大きく反復的なログやブラウザ出力 | 途中にある少数の重要値を消さない設計が必要 |
| Prune | アクティブな文脈から不要な情報を除く | 依存関係が解消した失敗ログや古い検索 | 復元不要とする根拠を残す必要がある |
例えば、完成したが後で修正される可能性がある報告書本文はFoldが向く。ログイン失敗を何度も繰り返した長いログは、原因を示す数行を残してMaskできるかもしれない。既に解決済みで、後続タスクに関係しない探索失敗はPruneの候補になる。
この違いは実務上大きい。普通の要約は「何があったか」を文章で残す。しかしFoldは、どこに原本があり、必要なら同じ内容を復元できるかを残す。長時間エージェントに必要なのは、もっともらしい記憶ではなく、再開・監査・修正に使える記憶である。
plannerに判断を任せても、plannerに削除を任せ切らない
Self-GCの設計で注目すべきなのは、LLMが削除計画を出しても、LLMの出力をそのまま本番の履歴へ適用しない点だ。
アクティブなコンテキスト
│
├─ ID付きオブジェクトに分割
▼
side-channel planner
└─ Fold / Mask / Prune の計画を出す
▼
harnessがコピー上でリハーサル
├─ 現在のターンを壊す操作を除外
├─ ID・メッセージ形式・依存関係を検証
├─ 削減量とキャッシュ破棄の影響を見積もる
└─ Fold対象を回復可能なsidecarへ保存
▼
安全なターン境界でのみ反映
論文では、モデルは将来必要な情報を推測する役、harnessは復元可能性やメッセージ形式、反映時点などの実行時不変条件を守る役、と分けている。これはAIエージェントの一般原則にも通じる。モデルは意味に基づく候補を出せるが、データ削除、権限、整合性、監査可能性の保証までをモデルの文章出力だけに委ねてはいけない。計画・検証・反映の分離
特に、現在の依頼や実行中の応答を途中で切断しないこと、Foldした内容を再取得できること、実際のメッセージ形式がAPIの契約を満たすことは、決定的なプログラム側で検証すべきだ。
キャッシュを壊してまで短くすべきとは限らない
コンテキストを短くすれば、常に安くなるわけではない。プロバイダーのプロンプトキャッシュを使っている場合、前方の履歴を編集するとキャッシュが無効になり、短期的にはかえって費用や遅延が増える可能性がある。
Self-GCは、削減後の入力コストだけでなく、planner呼び出しの費用とキャッシュ破棄の影響も考慮し、効果が見込める場合だけ反映する。論文の実験設定では、30%以上の圧縮が見込めるときに反映する方針を採用した。これは普遍的なしきい値ではなく、対象モデル、キャッシュ条件、今後の再利用回数によって変わる設計値である。キャッシュを含む反映条件
したがって実装では、次の判断を分けるとよい。
| 問い | 代表的な判断 |
|---|---|
| 今すぐ短くする価値があるか | 次回以降の入力削減が、plannerとキャッシュ損失を上回るか |
| どの情報を残すか | 将来の操作に必要な根拠、ID、ユーザー制約、成果物か |
| どこに退避するか | 暗号化、アクセス制御、保持期間、完全性検証ができる場所か |
| いつ反映するか | 実行中のツール呼び出し・承認待ち・ストリーミングを壊さない境界か |
| どう復旧するか | オブジェクトIDから原本を取得し、再投入・再実行できるか |
数字は「出力品質」ではなく、将来の継続に必要な情報を残せたか
著者らは、実ユーザーの会話を途中で切り、その時点までの履歴をSelf-GCで短縮した後、実際に後続会話で使われた情報を残せたかをGPT-5.5で判定した。これは、圧縮後のエージェントが後続タスクをどれだけうまく完了できるかを直接測る評価ではない。あくまで、将来の継続に影響しなかった割合（no-impact）を測るオフライン評価である。
| 評価セット | Self-GCの削減率 | Self-GCのno-impact | 比較対象の特徴 |
|---|---|---|---|
| Hard Set（33セッション） | 43.95% | 84.85% | 固定ルール群は61.90〜69.87%を削減する一方、no-impactは54.55〜69.70% |
| Production Suite（332セッション） | 31.04〜33.98% | 91.27〜94.58% | 固定ルール群は40.19〜47.76%を削減、no-impactは77.71〜87.46% |
この結果は、Self-GCが「より多く消す」より「必要な依存情報を残す」側へ寄った設計であることを示す。一方、判定にはGPT-5.5を使っており、データセットも著者らの本番由来トレースである。異なる業務、異なるエージェント、異なる評価者で同じ差が出るかは、独立した再現を待つべきだ。評価条件と結果
オンラインのアカウント分割では、日中の平均入力トークンが10〜15%減ったと報告される。ただし論文自身も、この結果だけではユーザー品質の維持や、実際の請求額の純減を証明しないと述べている。推論費用は入力トークンだけでなく、キャッシュ、planner、ツール、再試行、運用基盤まで含むからだ。
Agent Memoryは新しいデータ管理対象になる
Self-GCが示すのは、エージェントのメモリをモデル内部の便利機能として放置できない、ということだ。URL、ファイルパス、ユーザー指示、ツールログ、途中成果物は、どれも業務データになり得る。
エージェントを本番で動かすなら、少なくとも次を決めたい。
- 状態の分類：ユーザー制約、根拠、成果物、実行ハンドル、失敗ログを区別する。
- 保存先と権限：Foldした本文やファイルを、誰が復元・閲覧できるかを定める。
- 保持と削除：会話終了後、案件完了後、契約終了後の保持期間と削除証跡を決める。
- 参照可能性：要約だけでなく、必要なときに原本へ戻れるID・リンクを持つ。
- 監査：何をMask／Fold／Pruneし、誰のどのポリシーで反映したかを記録する。
- 安全な失敗：復元できないPruneを、機密情報や法的保存対象へ適用しない。復元不能な削除を行う権限も分離する。
ここでは特に、Foldを単なるコスト最適化と考えない方がよい。sidecarへ退避した原本は、アクセストークン、顧客情報、ソースコード、個人情報を含むかもしれない。コンテキストから見えなくなっただけで、データ保護責任は消えない。
実装を始めるなら、削除ではなく「回復可能な縮退」から
いきなりLLMに履歴を削除させるのは危険である。まずは読み取り専用で、コンテキストの何が重いか、どれが将来再利用されるかを観測するところから始める。
| 段階 | 実施内容 | 合格条件 |
|---|---|---|
| 1. 観測 | オブジェクトID、サイズ、再参照回数、依存関係をログ化 | 高コストな履歴の内訳が分かる |
| 2. 提案 | plannerにFold／Mask／Prune候補だけを出させる | 人間レビューで危険な提案を分類できる |
| 3. Fold | 原本を保持し、短い回復参照だけをアクティブ文脈へ残す | 指定IDから原文を正確に復元できる |
| 4. Mask | 再現可能な大きなログだけを部分的に省略 | 必要な値・エラー原因・IDが残る |
| 5. Prune | 依存解消が確認できた低リスク情報だけを消す | 継続作業、監査、復旧を妨げない |
評価では、削減率だけをKPIにしない。後続タスクの完了率、根拠の再現率、復元成功率、誤った再実行率、人間の手戻り、エージェント1件あたりの総コストを並べる。これらを満たせないなら、入力トークンを減らしても本番品質は上がらない。
エージェントの記憶は、捨て方までが設計になる
Self-GCの価値は、LLMを使って履歴を短くすること自体ではない。情報を「残す・隠す・捨てる」に分け、モデルの意味判断とharnessの復元・検証・反映を分離した点にある。
長時間エージェントでは、文脈を長く持つことだけが能力ではない。必要な根拠と状態を失わずに、不要な情報を減らし、止めた後にも監査・復元・再開できることが能力になる。
AIエージェントを実務へ入れる技術者にとって、メモリ管理はプロンプトの小技ではない。データのライフサイクル、コスト、可観測性、権限、復旧をつなぐ、実行基盤の設計課題である。
作成日：2026年8月28日