はじめに
こんにちは、KDDIアイレット株式会社の伊藤です。
Google Cloud Next Tokyo ’26 に参加し、セッション「Gemini Enterprise Agent Platform 入門! 進化した次世代エージェント構築基盤の全貌」を聴講しました。
私は普段、サポートデスク向けの AI チャットボット/AI エージェントの開発運用に携わっています。
エージェントは作って終わりではなく、本番で動かし始めた途端に悩みが「どう作るか」から「どう運用し続けるか」に変わります。
そうした立場として、まさに知りたいことが詰まったセッションでした。
本記事では、セッションの要約と、運用者としての目線で感じたことを中心にまとめます。
セッション概要
AI エージェント活用の「崖」
冒頭で提示されたのは「AI エージェント活用の崖」という問題意識です。作る側と使う側で視点もアプローチも異なり、その間に断絶があるという整理でした。
- 利用者側の視点:「ウチの部門ではそういう使い方はしない」「こういう機能がないから使いづらい」
- 開発者・IT 管理者側の視点:「多数のエージェントを取り揃えたのに現場が使わない」「個別のバラバラな要件を全部聞いていたらキリがない」
これに対する Google Cloud の回答が、次の役割分担です。
- Gemini Enterprise: 使うための「アプリ」。AI エージェントのエントリポイント
- Gemini Enterprise Agent Platform (GEAP): 開発・運用のための「プラットフォーム」
本セッションは後者の GEAP を掘り下げるものでした。
本番移行時に起こる 4 つの課題
プラットフォームの機能説明に入る前に、「エージェントの本番移行時に起こる課題」が 4 つに整理されました。
- Quality: 誤った回答の生成、想定外の回答
- Observability: 想定外のコスト高騰、エラー発生時のデバッグの複雑化
- Safety & Security: 悪意あるプロンプトによる情報漏洩、不適切発言
- Identity: 許可されないシステムへの接続、未許可ユーザーのアクセス
GEAP の機能群は、この 4 課題への対応として位置付けられていました。エージェントを運用したことがある人なら、どれも心当たりのあるリストではないでしょうか。
プラットフォームの 4 本柱: Build / Scale / Govern / Optimize
Build(作る)
エージェントを作るための選択肢が、コードファーストからノーコードまで階層的に用意されています。
- ADK (Agent Development Kit): オープンソースの開発フレームワーク。2.0 が 2026 年 5 月に GA となり、Python / TypeScript / Go / Java に対応
- Agents CLI: コーディングエージェントからエージェントのライフサイクルを操作する CLI と Skills。「Build agents with agents」というコピーが印象的でした
- Antigravity: エージェントファーストの開発プラットフォーム。デスクトップ型の Antigravity 2.0 とターミナルベースの Antigravity CLI があり、Agent Platform のプロジェクトでも使用可能
- Managed Agents API: 構成管理を担う Agents API と実行時の対話を担う Interactions API の 2 層構成。各エージェントは専用コンテナ内で隔離され、外部ネットワークからはデフォルトで遮断される
- Agent Studio: 迅速なプロトタイピング向けのビジュアルワークスペース(ローコード)
モデルは Model Garden から選択でき、Gemini 系に加えて Anthropic (Claude) や Mistral AI のパートナーモデル、Gemma / Llama などのオープンウェイトモデルも利用できます。
Scale(スケールさせる)
本番運用を支えるフルマネージドサービス群です。
- Agent Runtime: デプロイ・スケーリングを担うサーバーレス環境。ノーコード・ハイコード双方のデプロイに対応
- Agent Sandbox: 分離された環境でコードを安全に実行。Code Execution は GA で、カスタムコンテナを持ち込める Sandbox BYOC や、スナップショット取得・実行の巻き戻しに対応した GUI 自動化の Computer Use がプレビューで紹介されました
- Agent Sessions: セッション内の文脈を保持する短期記憶。チャット履歴用のデータベースを自前で構築する必要がなくなる
- Agent Memory Bank: 数週間〜数ヶ月にわたりユーザーの好みや事実情報を抽出・保存する長期記憶
Govern(統制する)
組織内のエージェントを統制する機能群です。
- Agent Gateway: 全エージェントのトラフィック・権限・アクセス制御を単一ポイントで中央管理。トラフィックがゲートウェイを通過するため、ログと Trace ID で全アクションを可視化できる
- Agent Identity (GA): SPIFFE ID による暗号化認証でエージェント固有の識別子を実現。トークンをランタイムに直接紐付けることで、万が一の流出時にも不正利用を防ぐ
- Agent Registry: エージェント・ツール・MCP サーバーを一元管理する中央カタログ。AI 資産の利用状況・コスト・コンプライアンスを横断的に把握できる
- Governance Policies: 自然言語で定義したビジネスルールを、ユーザー操作の文脈に合わせて動的に適用
住宅ローン審査アシスタントのデモでは、許可していないメール送信が認可でブロックされる例や、SSN (社会保障番号) が Model Armor でマスキングされる例が示され、統制が実際に効く様子を確認できました。
Optimize(最適化する)
- Agent Observability (GA): OpenTelemetry 形式でのトレーシング
- Agent Evaluation: オフライン/オンラインの品質評価
後述しますが、個人的にはこの Optimize 領域が最も刺さりました。
特に学びになったこと
評価基準を「固定」ではなく「会話ごとに生成」する Adaptive Rubrics
エージェントの評価アプローチとして、3 つの方式が紹介されました。
- ルールベース: ROUGE や Exact Match など、正解データとの一致度で評価
- LLM-as-Judge: 評価用プロンプトに基づき LLM がスコアリング
- 適応型 (Adaptive): エージェントとのやりとりに応じて評価基準を自動生成し、LLM がスコアリング
中でも Adaptive Rubrics のスライドの例が分かりやすいものでした。スケジュール調整エージェントに対して、ユーザーが途中で「やっぱり 45 分間にしてもらえますか」と要望を変えた会話を題材に、次の流れで評価が行われます。
- 会話の内容から Rubrics Generator が「check_availability ツールが呼ばれたか」「時間は 45 分間か」などの評価基準を自動生成する
- 実際のトレースを Rubrics Validator が検証し、「時間が 45 分ではなく 30 分」という不備を検出してスコア 3/4 を付ける
マルチターンでツールを呼ぶエージェントは、固定の評価基準では会話の文脈変化を追いきれません。「評価基準を書く」のではなく「評価基準の生成までを LLM に任せる」という設計は、この課題への現実的な答えだと感じました。
なお、オフライン評価を担う GenAI Evaluation Service では、適応型ルーブリック(推奨)のほかに、固定基準で評価する静的ルーブリック、ROUGE / BLEU などの計算ベース指標、Python で独自ロジックを定義するカスタム関数が選べ、評価対象の性質に応じて方式を使い分けられます。
評価サイクルの規模感: オフライン 10 件から始めてよい
もう一つ持ち帰りたいのが、評価サイクルの規模感の提示です。
- オフライン評価: 10 件程度のテストケースと golden dataset で回す
- オンライン評価: 本番の実ユーザー入力を対象に 10,000 件規模でモニタリングする
- オンラインで得た実際の入力をオフラインのテストケースに還流し、エージェントを改善する
オンライン評価はプレビューの Agent Evaluation (Online Monitors) が担い、Final Response Quality / Tool Use Quality / Hallucination / Safety といったメトリクスを、ターン数・トークン数によるフィルタやサンプリング率の設定と組み合わせて常時監視できます。
評価というと網羅的なテストケースを最初に揃えなければと構えてしまいがちです。しかし実際に運用してみると、リリース前に想定したテストケースと本番で飛んでくる入力はズレるもので、「本番の入力をテストケースに還流する」ループこそが評価の本体だというのは実感と一致します。
Observability: エージェントの中で何が起きたかを記録できる
Agent Observability は、エージェントが内部で何をしていたかを記録して、あとから追跡できるようにする機能です。記録されるのは次のような情報です。
- どんなプロンプトとレスポンスをやりとりしたか(画像などを含む)
- どの Tool やモデルを呼び出したか
- トークンをどれだけ使ったか、処理にどれだけ時間がかかったか
これらが Cloud Logging や Cloud Storage に保存され、「応答が遅い原因はどこか」「エラーはどこで起きたか」の調査に使えます。ADK であればバージョン 1.17.0 以上で環境変数を設定するだけで有効化できる、という手軽さも紹介されました。
もう一つのポイントは、この記録が Google 独自の形式ではなく、OpenTelemetry というオープンな標準規格(さまざまな監視ツールが対応している、ログやメトリクスの共通フォーマット)で出力されることです。
以前監視運用の業務に携わっていた経験からも、これはありがたい方向性だと感じます。記録の形式が共通であれば、エージェントも普通の Web アプリやデータベースと同じ監視ツールでまとめて見られます。「AI だから特別な監視の仕組みを別に用意する」のではなく、使い慣れた既存の監視の延長線上にエージェントを載せられる。運用者として歓迎したいところです。
成功指標は「回答品質」だけではない
エージェントの成功指標を計測する観点として、4 つの分類が示されました。
- ビジネスメトリクス: 収益の向上、コスト削減、ROI
- 目標達成率: タスク成功率、Response / trajectory の正確性
- テレメトリ: レイテンシ、システムエラー発生率、トークン使用量
- フィードバック: ユーザー満足度 (CSAT / NPS)、定性的評価
サポートの現場では満足度 (CSAT) を追いがちですが、それは 4 分類の 1 つに過ぎません。回答品質・システム指標・ビジネス成果を別のレイヤーとして計測する枠組みは、エージェントの効果を説明するときの整理としてそのまま使えると感じました。
まとめ
セッションを聴き終えて残ったのは、「答え合わせができた」という感覚でした。
エージェントの運用では、評価をどう回すか、何を計測するかを手探りで組み立てる場面が多く、自分たちのやり方が妥当なのかを確かめる機会はなかなかありません。
評価の還流サイクルや可観測性の標準化がプラットフォームの機能として形になったことで、進んできた方向を確認できた一方、この領域は自前の工夫で差がつく段階から、標準機能を使いこなす段階へ移りつつあるとも感じました。
エージェント開発の情報は「どう作るか」に偏りがちですが、本番運用の課題に正面から向き合った本セッションは、運用者の立場として得るものが多い内容でした。
次回の Google Cloud Next では、こうした運用機能を使い倒した事例の話が増えているはずです。自分もその一人として話せるように、キャッチアップを続けていきたいと思います。
簡単30秒