コンテンツにスキップ

カンム Synapse — ADK コンパクションで「200k の崖」を避けてコストを抑える

作成日: 2026-08-08 出典 / きっかけ: カンム テックブログ（2026-08-07、佐野氏）「Synapse開発日記: Google ADKのコンパクションで社内AIエージェントのコストを抑える」 一次資料: ADK v2.4.0 _configs.py / Vertex AI Generative AI Pricing 関連: カンム_synapse_セマンティックレイヤーの育て方_整理（同シリーズ・精度の軸）claude_code_dynamic_workflows_グラフエンジニアリング_整理（要約ノードを安いモデルに落とす型）AI支出を横ばいに保つ_デフォルト_ルーティング_キャッシング cursor_agent_swarm_planner_worker経済性_整理 Fable5_3日間で300万円課金_並列エージェント運用の物理的課題 タイミー_dre_looker_adk_社内aiエージェント_整理（同じく ADK 採用）

0. 要点（3行）

  • 一言で言うと: LLM API はステートレスなので、エージェントフレームワークは毎コール会話履歴とツール定義を丸ごと送り直す。1セッションの累計入力トークンは O(n²) で膨らみ、カンムでは4月→6月で月額コストが 2.18倍になった。
  • 効かせどころは「崖」: Gemini 3.1 Pro は プロンプトが 200k トークンを超えると入力単価が2倍（$2→$4 / 1M）になる。しかも超過分だけでなく全トークンが long-context 単価になる。だから最適化は「じわじわ削る」ではなく「崖を踏まない」設計になる。
  • 実装は自前不要: Google ADK 2.4.0 にコンパクション（会話履歴の要約圧縮）が同梱されていた。token_threshold=160_000（200k まで 40k のバッファ）＋ event_retention_size=15（直近15イベントは生のまま）＋ 要約器は gemini-3.6-flash（安いモデル）。翌月のトークン量とコストは大幅に削減された。

1. 何が起きたか

Synapse はカンム（バンドルカード）の社内 AI エージェント。FastAPI ＋ Google ADK（Gemini） で構築され、基盤は Gemini Enterprise Agent Platform（旧称 Vertex AI）。会話履歴は Platform 側に置くこともできるが、カンムは自前の PostgreSQL（セッション DB）に保存している。

Gemini Enterprise Agent Platform (旧称: Vertex AI) の月額コストが4月から6月にかけて 2.18 倍になりました。ユーザ数および利用回数はもちろん増えていますがそれを加味しても爆発的なコスト増です。

※ 改名は事実確認済み。Google Cloud Next 2026 で Vertex AI と Agentspace が統合され「Gemini Enterprise Agent Platform」に改称された（既存顧客の移行作業は不要、サービス実体は同じ）。

注意すべき記事の誠実さ: 実トークン量は「そこからコストが算出できてしまう」ため非公開。著者は「原因分析からなぜコンパクションを選んだかのストーリーを書きたいが書けない」と明示している。つまり削減率の定量値は本記事には無い（「先月比で大幅に削減」という定性的な記述と GCP 課金画面のスクリーンショットのみ）。

2. なぜ膨らむか — ADK の挙動と O(n²)

登場人物は ユーザ / Google ADK / セッション DB / LLM(Gemini)。用語は3層:

  • セッション = 会話の単位。この中にやりとりが積み上がる
  • Invocation = 1ユーザプロンプト → 1応答 までの1ターン
  • LLM Call = 1 Invocation の中で1回以上発生する実際のモデル呼び出し

Gemini へのリクエストはステートレスなので、ADK は毎コール履歴を丸ごと送り直す（v2.4.0 の実装）。記事が具体化している中身がこれ:

LLM Call 1: システムプロンプト + tool schema + 「今月の売り上げは？」
LLM Call 2: システムプロンプト + tool schema + 「今月の売り上げは？」
            + function call + function response
LLM Call 3: システムプロンプト + tool schema + 「今月の売り上げは？」
            + function call + function response + 「売上は〇〇です」 + 「ありがとう」

tool schema（BigQuery・GitHub ソース参照などの定義）も毎回送る。モデルにどんなツールがあるか教える必要があるため。

【累積入力トークン】各ターンで増える履歴量が一定と仮定すると

  n 回目のコールが送る履歴量      = O(n)
  セッション全体で送る累計入力    = O(n²)   ← ここが効く

  n=1  ■
  n=2  ■■
  n=3  ■■■
  n=4  ■■■■          累計 = 1+2+3+4+… = n(n+1)/2
  ...
  ツール結果が大きい / 1 invocation 内でツール呼び出しが続く場合はさらに急峻

「長い会話ほど1コールが高い」ではなく「長い会話は2乗で高い」が正確な理解。

3. 課金構造 — 200k の「崖」

Synapse のメインモデル gemini-3.1-pro-preview の Standard 単価（記事の表を公式ページで検証、一致を確認）:

項目 ≤200k トークン >200k トークン
入力 $2 / 1M $4 / 1M（2倍）
キャッシュ済み入力 $0.2 / 1M $0.4 / 1M（通常の 1/10）
出力 $12 / 1M $18 / 1M

公式ページで追加確認できた重要な点（記事に無い）:

  • 200k を超えると「全トークン」が long-context 単価になる（超過分だけの課金ではない）。だから 200k は連続的な傾きではなく踏んだ瞬間に倍になる崖であり、token_threshold=160_000 の 40k バッファは「崖から距離を取る」設計として理解するのが正しい
  • Standard 以外に Priority（入力 $3.6 / $7.2、出力 $21.6 / $32.4）と Flex/Batch（入力 $1 / $2、出力 $6 / $9）のティアがある。バッチ処理に落とせる用途なら単価が半分になる

2つの独立したレバー: ①200k 超えで単価2倍（long-context）②キャッシュヒットで単価 1/10。Gemini 2.5 以降は暗黙的キャッシュがデフォルトで有効。

カンムがキャッシュ最適化を選ばなかった理由（意思決定として率直で良い）:

キャッシュヒットをうまく制御できるかわからなかったため、トークンそのものを縮める施策を優先しました。

なお公式ドキュメントによればキャッシュヒット率を上げるコツは「大規模で一般的なコンテンツをプロンプトの先頭に置く」「類似した接頭辞を含むリクエストを短時間で送る」。

分析データの出所: LLM コール時に Platform から返る usage_metadata（送受信トークン量・キャッシュヒット量）が本番セッション DB に保存されているので、それを使って調査した。計測できる場所を最初から持っていたのが効いている。

4. コンパクションの実装（ADK 2.4.0）

「コンパクションするかぁ〜」と実装アルゴリズムを調べようとしたら僥倖なことに Google ADK 2.4.0 にコンパクション機能が入っていた

ADK のコンパクションには2方式がある。invocation 数ベースの定期実行と、プロンプトトークン数ベースの発火。目的が「long-context 単価に入らないこと」なので後者だけを使う。

EventsCompactionConfig(
    summarizer=LlmEventSummarizer(
        llm=Gemini(model="gemini-3.6-flash"),   # 要約は安いモデルに落とす
        prompt_template="<要約の方針>",           # 要約方針はここで指示できる
    ),
    token_threshold=160_000,        # 200k の崖まで 40k のバッファ
    event_retention_size=15,        # 直近15イベントは要約せず生で残す
    compaction_interval=1_000_000,  # invocation 数ベースの定期実行を実質無効化
    overlap_size=0,
)

【動作イメージ】
 セッションの累積プロンプト ─────────────────────────→
 [ 古いイベント群 ................ ][ 直近15イベント ]
   └─ gemini-3.6-flash が要約して置換 ─┘   └─ 生のまま保持 ─┘
                     ▲
   直近コールの実測プロンプトトークンが 160k を超えたら、
   invocation の「後」に圧縮が走る（＝事後トリガー）

落とし穴（ADK 2.4.0 固有・記事の一次情報）

罠 内容
compaction_interval が必須 invocation ベースを使いたくなくても値を渡さねばならない。None はバリデーションで弾かれる
0 を渡すと逆効果 compaction_interval=0 にすると毎回コンパクションが走る。無効化のつもりが最悪の設定になる → だから 1_000_000 のような巨大値を入れる
ハードリミットではない 閾値判定は直近コールの実測値を使う（事後トリガー）。次のイベントが巨大なら 160k の設定を飛び越えて 200k 超の入力が発生しうる
experimental ADK のコンパクション機能は記事執筆時点で experimental
品質劣化 要約で詳細な文脈が失われ回答品質が落ちる可能性。「どの程度劣化するのかは別途注目する必要がある」（＝未計測、著者も留保している）

著者は upstream に修正を投げており、「次のバージョンでは required ではなく optional になるはず」と書いている。→ これは実際に入った（§5 で検証）。

5. 一次資料での検証結果

# 記事の記述 検証 判定
1 gemini-3.1-pro-preview の Standard 単価（入力 $2/$4、キャッシュ $0.2/$0.4、出力 $12/$18、境界 200k） 公式 pricing ページと完全一致 ✅
2 200k 超で入力単価が2倍 一致。さらに公式は「超えたら全トークンが long-context 単価」と明記（記事より厳しい） ✅（+補強）
3 ADK 2.4.0 で compaction_interval / overlap_size が必須 v2.4.0 の _configs.py を確認: compaction_interval: int / overlap_size: int は必須、token_threshold / event_retention_size は Optional[int] = None ✅
4 token_threshold は事後トリガーでハードリミットでない docstring が「most recently observed prompt token count meets or exceeds this threshold」で事後・実測ベースと明言。記事の説明どおり ✅
5 token_threshold と event_retention_size はセットで指定 @model_validator が「両方セットか両方 None」を強制していることを確認。記事が両方書いているのはこの制約による 🆕 補足
6 「次のバージョンで optional になるはず」 main ブランチで実現済みを確認。compaction_interval / overlap_size ともに Optional[int] = None になっている ✅ 実現
7 Gemini Enterprise Agent Platform ＝ 旧 Vertex AI Google Cloud Next 2026 で Vertex AI ＋ Agentspace を統合して改称。既存顧客の移行不要 ✅
8 削減率 定量値は非公開（トークン量からコストが逆算できるため）。「先月比で大幅に削減」＋課金画面のみ ⚠️ 定量なし

唯一の食い違い（記事も自認）: GCP の課金画面には「Gemini 3.0 Pro」と表示されるが実際に使っているのは 3.1 Pro。著者は「請求上はこうなる模様...」と注記している。

6. シリーズの中での位置

この記事は Synapse シリーズの最新回。精度の軸（前回まで）から運用コストの軸へ移った回、と読むのが正しい。

回 日付 テーマ Vault のノート
1 2025-12-24 Synapse の開発と運用 —
2 2026-03-30 MCP サーバ化＋Entra ID 認証 —
— 2026-06-03 手元のエージェントから SageMaker Studio の Jupyter を操作（別著者・新田氏） —
3 2026-06-18 セマンティックレイヤーの育て方（登壇＋補足） カンム_synapse_セマンティックレイヤーの育て方_整理
4 2026-07-29 LLM 切り替えで露呈するモデル依存性 未整理（後述）
5 2026-08-07 ADK コンパクションでコスト削減 本ノート

面白い接続: 前回ノート（§3-1）で「軽い質問を Flash に振るマルチ LLM ルーティングは精度低下で失敗し 3.1 Pro に一本化した」と書かれていた。今回再び Flash（3.6-flash）が登場するが、役割が違う。

  • 前回の失敗: ユーザ質問そのものを Flash に振った（判断が要る仕事を安いモデルに落とした → 精度低下）
  • 今回の成功: 要約（コンパクション）だけを Flash に振った（機械的で境界の明確な仕事だけ落とした）

これは claude_code_dynamic_workflows_グラフエンジニアリング_整理 §4-5 のモデルティア分けとまったく同じ型である。「安いモデルをどこに置くか」は "どのモデルか" ではなく "そのノードに判断が宿るか" で決まる。カンムは1度失敗してから正しい置き場所を見つけた、という読み方ができる。

7. 持ち帰り（自分の環境）

  • usage_metadata を最初から保存しておくが最大の教訓。カンムが素早く手を打てたのは「本番セッション DB にトークン使用量が既に溜まっていた」から。コスト分析は計測基盤が先で、爆発してから作ると間に合わない
  • 単価の非線形点（崖）を把握しておく。Gemini は 200k、モデルによって位置は違う。「じわじわ最適化」ではなく「崖の手前にバッファを取って張り付く」が正しい設計。40k バッファのような具体値は自分の環境でも決めておく価値がある
  • コンパクションは劣化ではなく手段。著者の指摘どおり「コンパクション＝悪い現象」という受け取り方が SNS には多いが、トークンコストとメモリ効率を得るための意図的な操作。ただし品質劣化は未計測なので、入れるなら劣化の測り方（前回ノートの Execution Accuracy のような結果ベース指標）とセットにする
  • フレームワーク同梱機能をまず探す。自前実装に入る前に ADK に入っていた、という展開はそのまま「search-first」の実例
  • Flex/Batch ティアの存在（単価が Standard の半分）は記事に無いが、~/ai-engineering-digest / ~/st-japan-lab のようなバッチで回る日次パイプラインには直接効く可能性がある。ただし現状は Claude API 利用なので Gemini の話がそのまま移るわけではない — Anthropic 側の Batch API 割引と対応づけて考える

8. まとめ — 早見表

状況 打ち手
エージェントのコストが利用増以上に伸びている まず O(n²) を疑う（履歴＋tool schema の毎回再送）。セッション長の分布を見る
どこを削るか分からない usage_metadata 相当（送受信トークン・キャッシュヒット）をセッション単位で保存し、実データで決める
単価を下げたい ①崖を踏まない（long-context ティアに入らない）②キャッシュヒット率を上げる（大きく共通な内容を先頭へ・類似接頭辞を短時間に）— 両者は独立に効く
キャッシュ制御が読めない トークンそのものを縮める方を先にやる（カンムの判断）。制御可能性が高い方から着手
履歴が長すぎる コンパクション（要約圧縮）。閾値は崖の手前にバッファを取る。直近 N イベントは生で残す
要約にどのモデルを使うか 安いモデル（機械的タスクなので判断が宿らない）。ユーザ質問のルーティングに安いモデルを使うのとは別の話
コンパクションを入れた 品質劣化を測る指標をセットで用意する（未計測のまま運用しない）
バッチで済む処理がある Flex/Batch ティア（Gemini では Standard の約半額）を検討

9. フォローアップ

  • シリーズ第4回「Synapse 開発日記: LLM 切り替えで露呈する社内 AI エージェントのモデル依存性」（2026-07-29）が未整理。「各社が新モデルを出すたびに乗り換えるが、単に最高性能のモデルを使えばよいわけではない」という論旨。前回ノートのマルチ LLM 失敗談の続きにあたり、本ノート §6 の「Flash の置き場所」とも直結する。読む価値が高い
  • カンム テックブログは ~/ai-engineering-digest/config/feeds.yaml に未登録（grep で確認）。Synapse シリーズの継続性・具体性を考えると巡回先に入れる価値がある（RSS 実在の確認が前提）

参考リンク

出典 - Synapse開発日記: Google ADKのコンパクションで社内AIエージェントのコストを抑える（カンム テックブログ、2026-08-07、佐野氏） - 社内 AI エージェント Synapse と セマンティックレイヤーの育て方（2026-06-18）

一次資料（検証に使用） - google/adk-python v2.4.0 apps/_configs.py（EventsCompactionConfig の定義） - google/adk-python v2.4.0 apps/compaction.py - google/adk-python v2.4.0 flows/llm_flows/compaction.py - Vertex AI Generative AI Pricing（gemini-3.1-pro-preview の Standard / Priority / Flex 単価） - Gemini Enterprise Agent Platform（旧 Vertex AI） - コンテキストのキャッシュ保存（Gemini）

作成: 2026-08-08 ／ 最終更新: 2026-08-08