長時間動くAIエージェントでは、会話やツール実行の履歴が増えるほど、毎回モデルへ渡す文脈も膨らみます。履歴を丸ごと送り続ければ、応答は遅くなり、コストも上がり、やがてコンテキスト上限にぶつかります。
一方、古い履歴を機械的に捨てれば、「誰が何を承認したか」「直前にどのツールを呼んだか」が抜け落ちます。GoogleのAgent Development Kit（ADK）が提供するコンテキスト圧縮から、長時間エージェントの履歴を小さく保ちながら、仕事の連続性を守る設計を考えます。
履歴は「保存」と「モデル投入」を分けて考える
ADKのSessionは、ユーザーの入力、エージェントの応答、ツール操作などを時系列のイベントとして保持します。しかし、保存されている全イベントを、毎回そのままモデルへ投入する必要はありません。
Google公式ドキュメントによると、ADKのContext Compactionは古いセッション履歴を要約し、モデルへ渡す文脈を圧縮します。狙いは、長いセッションでも直近の重要なやり取りを残しつつ、レイテンシーとコストを抑えることです。
ここで大切なのは、圧縮を「ログ削除」と混同しないことです。本稿の設計方針としては、次の3つを別物として扱うと整理しやすくなります。
- 原本：監査や障害解析に使う完全なイベント履歴
- 作業文脈：直近の生イベントと、古い履歴の要約
- 業務状態：承認結果、注文番号、処理段階などの構造化データ
モデルに見せる作業文脈を軽くしても、原本と業務状態まで失う必要はありません。
Google ADKに学ぶ2つの圧縮トリガー
ADK公式ドキュメントは、圧縮の開始条件を2種類に分けています。
1. トークン量で発火する
トークンベース方式は、文脈が設定したトークン数を超えたときに圧縮します。巨大なコードや長いツール出力が突然入るような、負荷を予測しにくい仕事に向いています。
公式ドキュメントでは、トークン方式を主要な安全網として位置づけています。設定例のtoken_threshold=4000は製品の固定値ではなく、説明用のサンプルです。本番値は、利用モデルの上限、通常時の入力サイズ、出力用に確保したい余白から決める必要があります。
2. 会話ターン数で発火する
スライディングウィンドウ方式は、一定回数のやり取りごとに古いイベントを要約します。問い合わせ対応のように、1ターン当たりの情報量が比較的そろう仕事では扱いやすい方式です。
両方を設定した場合、ADKはトークン上限を超えたターンでトークンベースの圧縮を優先します。つまり、ターン数による圧縮を通常時の運用条件とし、トークン量による圧縮を大容量入力への保護条件として設計できます。
圧縮しても連続性を壊さない4つの設計原則
原則1：直近イベントは生のまま残す
要約は便利ですが、固有名詞、数値、否定表現、ツール引数を落とす可能性があります。ADKのevent_retention_sizeは、圧縮後も直近のイベントを未圧縮で残すための設定です。
「さっきの案で進めて」のような指示を理解するには、最後の数往復がそのまま残っている方が安全です。要約だけに置き換えず、古い履歴は要約、直近は原文という二層構造にします。
原則2：圧縮区間を少し重ねる
スライディングウィンドウでは、前回圧縮した末尾を次の圧縮にも含めるoverlap_sizeを設定できます。公式例では、3回ごとに圧縮し、直前の1回を重ねています。境界をまたぐ指示と応答が分断されにくくなる仕組みです。
これにより、圧縮境界の直前に出た指示と、その直後の応答が別々の要約に分断されにくくなります。重複はわずかなコストになりますが、文脈の継ぎ目を保てます。
原則3：重要事項は要約ではなく状態に昇格する
人の承認、支払額、対象ファイル、完了条件などを自然文の要約だけに預けるのは危険です。本稿の提案として、これらはADKのSession State、または必要に応じて業務データベースへ、型を持つ値として保存します。
approved=trueapproved_by=user_123target_file=/reports/q2.pdfworkflow_step=reviewed
要約は「会話を思い出す」ため、構造化状態は「処理を正しく再開する」ため、と役割を分けます。
原則4：圧縮品質も評価対象にする
圧縮後に答えが自然でも、重要な制約が消えていれば失敗です。テストでは、長い会話を流した後に次を確認します。
- ユーザーが禁止した操作を覚えているか
- 承認済みと未承認を取り違えないか
- ツール呼び出しと結果の対応が崩れていないか
- 数値、単位、対象物が保持されているか
- 圧縮前後でトークン量と応答時間がどう変わったか
圧縮率だけをKPIにすると、短くても役に立たない要約が勝ちます。本稿のQA提案として、保持すべき事実の再現率と、禁止事項の維持率も一緒に測るべきです。
車載開発にたとえると「リングバッファ＋故障記録」
車載システムでも、すべてのCAN通信を制御ロジックへ毎周期入力し続けるわけではありません。直近データはリングバッファで保持し、故障コードや重要イベントは別の不揮発領域へ残し、詳細ログは解析用に保管します。
AIエージェントも同じです。直近の会話は生データ、古い流れは要約、承認や処理結果は構造化状態、完全履歴は監査ログへ分ける。この分離によって、モデルの「作業机」を散らかさず、必要な証拠も失いません。
まとめ
長時間エージェントでは、履歴を増やし続けることも、古い順に捨てることも正解ではありません。Google ADKのコンテキスト圧縮から学べる要点は4つです。
- トークン量を安全網、ターン数を定期清掃として使う
- 古い履歴は要約し、直近イベントは原文で残す
- 承認や業務上の事実は構造化状態へ昇格する
- 圧縮率だけでなく、重要事実と禁止事項の保持を評価する
AIの記憶設計は、「どれだけ覚えるか」ではなく、何を原文で持ち、何を要約し、何を状態として固定するかの設計です。