推論の観測、できていますか？ 〜 Google Cloud Gemini Enterprise Agent Platformで 3つの Gemini モデルを実測して踏んだ、評価の罠 〜

2026年9月4日(金)開催の「【3-shake × enechain】SRE Tech Talk #15」でのLT登壇スライドです。
イベントページ: https://3-shake.connpass.com/event/402777/

◼︎概要
本セッションでは、Google CloudのGemini 3世代モデル（gemini-3.7-flash / gemini-3.5-flash-lite / gemini-3.1-pro-preview）をCI上で実測評価した際に直面した、「推論モデル（Thinking Model）特有の評価・観測の罠」とその解決アプローチについて共有しました。

◼︎ハイライト
・見落とされがちな監視項目: レイテンシやコストだけでなく「推論トークン数（thoughts_token_count）」と「finish_reason」の観測が必須な理由
・推論トークンが出力枠を食う罠: MAX_TOKENS の上限を内部推論が圧迫し、可視出力が文の途中で強制終了していた実例
・設定1行でスコアが逆転: 測定条件の欠陥を是正したことで、正答率が 79.7% → 100% へ
・「記録していなかったものは、永久に見えない」: SRE視点で考える生成AIアプリケーションのオブザーバビリティ

◼︎検証リポジトリ
ADK (Agent Development Kit) と Gemini を用いた検証用チャットボット実装・CI評価コードはこちらで公開しています。
👉 https://github.com/shu-kob/adk-agent-chat

Transcript

1. 推論の観測、できていますか？ 〜 Google Cloud Gemini Enterprise Agent Platformで 3つの Gemini モデルを実測して踏んだ、評価の罠 〜 2026年9月4日 @SRETT #15 株式会社スリーシェイク 小渕 周 Shu Kobuchi
2. 自己紹介 小渕 周 (Shu Kobuchi) こぶシュー X: @shu_kob 株式会社スリーシェイク Sreake 事業部 アプリケーション開発支援チーム マネージャー • Google Cloud, Geminiを用いた生成 AI アプリケーション開発 • 生成AIアプリ開発とSREの真ん中にいる人間 • Google Cloud 認定試験全冠 ／ Jagu'e'r AI/ML分科会運営メンバー 2
3. 監視項目で推論モデルという考慮漏れ 【前提】LLMは壊れずに劣化する • HTTP 200 OKを返却 • レイテンシもエラーレートも不変 • 落ちているのは出力の内容だけ → チャットの入力・出力のデータセット作成でテスト • 既存の監視項目 ◦ レイテンシ ／ エラーレート ／ トークン数 ／ コスト • 漏れた項目 ◦ 推論トークン ／ finish_reason → アプリ使用で可視化されないので推論計測の抜け落ち 3
4. 簡易AIチャットボットの CI作って3モデルで測定 項目 内容 プラットフォーム Google Cloud Gemini Enterprise Agent Platform（旧 Vertex AI） モデル gemini-3.7-flash / gemini-3.5-flash-lite / gemini-3.1-pro-preview データセット 30ケース（3カテゴリ × 10ケース） 試行回数 各3回・中央値（計 270試行） パラメータ temperature = 0.0 / seed = 42 MAX_TOKENS 256 〜 1024（ケースによる） 採点 100% 決定論的 ◦ MAX_TOKENS : 256 〜 1024 ▪ CIで回すのに出力トークン絞った 4
5. 推論トークンが応答出力の枠を食う（１） • 出力長の中央値 ◦ 3.5-flash-lite 304文字 ◦ 3.7-flash 87文字 ◦ 3.1-pro-preview 54.5文字 • gemini-3.7-flash / 禁止語＋記号制限付の要約を問い (MAX_TOKENS = 512 で設定) • • • 推論トークン数 : 492 出力応答トークン数 : 16 finish_reason : MAX_TOKENS • 「自然言語処理技術の劇的な進化により、プログラミング支援や文章」 ⬆ 文の途中で停止 • なぜ、上位モデルの出力が文の途中で切れるのか？ 5
6. 推論トークンが応答出力の枠を食う（２） • • 仕様 ◦ 推論トークン + 応答本文 が MAX_TOKENS に到達すると、 ▪ finish_reason = MAX_TOKENS ◦ 推論が枠を食うと、応答本文の残枠が削られる それでも踏んだ ◦ finish_reason を記録するまで、原因が不明 打ち切り率 (禁止制約の遵守条件付質問) • 3.7-flash 100% (30/30) • 3.1-pro-preview 100% (30/30) • 3.5-flash-lite 0% 禁止制約の遵守条件付質問は 推論トークンを大きく消費 打ち切りの2種別 • 推論起因 推論 大 / 応答 極小 → 測定条件の欠陥 • 出力起因：推論 0 / 応答 上限付近 → 正 当な打ち切り 6
7. 設定1行で結果が逆転 • 変更点 ◦ MAX_TOKENS : 256 〜 1024（ケースによる） → 4096 設定変更 ◦ 他は全て同一 (temperature / seed / 試行回数 / データセット / 指示文) 非推論 モデル • • モデル (禁止制約の遵守 条件付き質問を入力 ) MAX_TOKENS = 256 〜1024設定の正答率 MAX_TOKENS = 4096設定 の正答率 gemini-3.7-flash 79.7% 100.0% gemini-3.1-pro-preview 79.7% 100.0% gemini-3.5-flash-lite 88.3% 88.3%（不変） 測定の欠陥が除去されただけ ※ モデルの性能が上昇しているわけではない（性能は変更なし） 7
8. 設定1行で結果が逆転（２） • 3.5-flash-lite は3カテゴリすべて不変 ◦ 段階的推論（計算・制約充足） 80.0% → 80.0% ◦ JSON整形精度 96.8% → 96.8% ◦ thoughts_token_count は null（推論モデルではない） → 対照群が動かないことが、原因の特定を裏付け ※ 上昇は能力向上ではなく、測定の欠陥が除去された結果 ※ この評価セットでの挙動。モデルの総合的な優劣ではない ※ 79.7% は欠測を解消し全ケースを測り直した実測値 8
9. 答え — データはあった（１） 推論の観測、できてますか？ • thoughts_token_count も finish_reason も API は返す • データはあった • 監視項目に入っていなかっただけ プラットフォーム側 • thoughts_token_count / finish_reason の記録 • 打ち切り率の 可視化が必要 プロダクト側 • 異常とみなす打ち切り率の閾値 • そのスコアを能力値として扱うかの判 断 → プロダクトの要件で決まる 9
10. 答え — データはあった（２） • 記録していなかったものは、永久に見えない ◦ finish_reason が無ければ、打ち切りは 「短く答えるモデル」として解釈され続けた ◦ finish_reason を項目に入れるだけ。それだけで見える ※ 代償：所要時間 26分30秒 → 2時間15分（5倍） 同期的なCIゲートには載らないので、 モデル変更時にSTGなどでがっつりテスト 10
11. 最後に ご清聴ありがとうございました 参考 • 検証リポジトリ ◦ https://github.com/shu-kob/adk-agent-chat ▪ ADK(Agent Development Kit)・Geminiを 用いたチャットボット 11