「Gemini Enterprise Agent Platform の評価機能を活用してエージェントを最適化する ― エージェント品質向上のフライホイールを構築する」: Google Cloud Next 2026セッションレポート

はじめに

こんにちは、NRIの森川です。
私は現在、レガシーシステムを対象とした現行可視化・モダナイズ支援に関するサービス開発に従事しており、AI Agentを組み込んだシステムの開発に取り組んでいます。システムの開発を進める中で、「開発環境のテストでは完璧に動いていたAgentが、実業務の複雑なデータに直面すると想定外の挙動をしてしまう」という実運用に向けた壁に直面することがあります。Agentの出力品質をいかに担保し、リリース後も継続的な評価・改善サイクルを回していくかは、多くの開発者にとって共通の課題ではないでしょうか。
こうした現場での課題感を解決するヒントを探るべく、先日ラスベガスで開催されたGoogle Cloud Next '26に参加してきました。本稿では、数あるプログラムの中でも、実践的なアプローチが語られていたセッション「Engineer the agent-quality flywheel: Using Gemini Enterprise Agent platform evaluation to optimize agents」をレポートします。生成AIを組み込んだシステムにおいて、どのように品質評価・改善サイクル（Flywheel）を構築していくのか、その最新の方法論について紹介します。

テスト合格後の罠：「連鎖的障害」とAgentの最も恐ろしい失敗

セッションの冒頭、Google Cloud のDima Melnyk 氏は自身の苦い経験を共有しました。数年前、彼のチームは Google Cloud Platform（以下、GCP）の障害解析Agentを開発しました。用意したすべての評価（Evals）を見事にパスし、万全の状態でリリースを迎えたといいます。
しかし本番環境に投入された途端、テストでは想定していなかった問題に直面します。例えば、「データベースの遅延が原因で認証がタイムアウトし、さらに下流の3つのサービスがダウンする」といった複合的なインシデントです。Agentは個々のエラーを切り離して見れば正しく分析できていたものの、それらが「一つの連鎖した障害である」というシステム全体の文脈を見逃し、ユーザーに対して“自信満々に間違った回答”をしてしまいました。

Dima氏はこの経験から、「Agent開発において最も恐ろしい失敗は、システムがエラーで止まることではない。本当に怖いのは、Agentが正常に動いているように見えて、実は裏でユーザーの信頼を失い、二度と戻ってこなくなることだ」と語りました。

Google Cloud に関するソリューション・事例はこちら

品質を継続的に向上させる「Flywheel」の全体像

このような問題の解決策として、Dima氏はエージェントの品質を「Build and Test」「Ship and Monitor」「Learn and Refine」という3つのフェーズから成る、継続的なサイクル（flywheel）として捉えて解決するエンジニアリング手法を紹介しました。

Build and Test
デプロイ前に多様なユーザーをシミュレーションし、網羅的なテストを実施して失敗を修正する。
Ship and Monitor
本番環境へデプロイ後、そのトラフィックをトレースし、テスト環境と同じ指標でリアルタイムに評価・監視する。
Learn and Refine
本番環境での失敗ログを収集・クラスタリングし、それらを「次のテストケース」として還元する。

このループを回すことで、本番環境で発生したエラーが次世代Agentのテストデータとなり、サイクルを回すたびに品質が複利的に向上していく設計となっています。

Geotab社のアプローチの変遷と「評価スケールの壁」

続いて登壇した、大規模なフリート管理プラットフォームを提供するGeotab社のDaniel Lewis氏から、エンタープライズ規模でAI Agentを組み込んだシステムを運用する事例が共有されました。同社は5万以上の顧客と600万台以上の車両データを抱え、毎日30テラバイトものデータを処理しています。この膨大なデータからインサイトを引き出すため、初期段階として自然言語からSQLを生成するAgentを開発しました。初期は、社内の専門家が用意した想定問答を用いて実行精度を評価しており、ユーザーから好意的な評価を得ていました。
しかし、ユースケースが広がりはじめると、ユーザーの予期せぬ質問の言い回しや、意図しないテーブルの呼び出しによってシステムがクラッシュする事態が発生します。
開発者視点で作られたテストデータでは、実際のユーザーの予測不可能な振る舞いをカバーしきれなかったことが原因でした。

この課題に対し、Geotab社は評価の仕組みを段階的に進化させるアプローチをとりました。

シンプルな正解データの活用
初期の単純な実行精度の評価。
LLM-as-a-judgeの導入
LLMが想定とは異なる解決策や解釈を出した際にペナルティを与えないよう、人間の好みに調整したLLMを評価者（LLM-as-a-judge）として導入。
フィードバックの直接確認
アプリケーション内にフィードバック機能を作成し、エラー情報を1件ずつ確認・対応。
エラーログのクラスタリング
セマンティック埋め込みを活用して失敗ログをグループ化（クラスタリング）し、優先度順にバグを修正。
合成データによる事前シミュレーション
「特定のユーザーペルソナ」を作成し、リリース前に特有の言い回しや想定外の行動をシミュレーションして最適化に活用。

これらのアプローチにより、エージェントシステムの品質を80%程度まで担保することは可能になりました。しかし、より高い精度を目指す「残りの20%」の領域を突破することが極めて困難であるとDaniel氏は指摘します。システムがマルチエージェント化し複雑になるにつれ、サブエージェントやルーティング、ツール呼び出しといったあらゆる中間ステップで個別の評価が必要になり、リリースまでの時間は大幅に引き延ばされました。評価に費やされるトークン量は膨大になり、気がつけば本番システムよりも評価パイプラインのトークン消費量の方が多くなる事態に直面します。さらに開発者たちは、マージリクエストを早く通すために、CI/CDの評価プロセスそのものを回避しようとし始めました。

結果的に「評価」の壁は技術的な問題の枠を超え、組織のプロセスや開発者の心理にまで悪影響を及ぼす事態へと発展したのです。Daniel氏はこの経験から、「データサイエンティストが手作業で完璧な評価基準を作る時代は終わった。それでは到底スケールしない」と断言しました。そして、「人間の専門家の時間は最もクリティカルな部分にだけ投資し、あとはLLMによる自動評価（Auto-raters）や合成テストジェネレーターなどのツールを最大限に活用して、顧客より先を行く評価サイクルを作らなければならない」と強いメッセージを発信していました。

Gemini Enterprise Agent platformを活用した「人間主導」の評価基盤

Daniel氏が語った「評価スケールの壁」に対する解決策として、Google Cloud のAlex Martin氏からは、Gemini Enterprise Agent Platformに組み込まれた評価システムによる「人間主導（Human-driven）の品質フライホイール」がデモを交えて紹介されました。

Alex氏の発表で筆者が注目したのは、「適応型ルーブリック（Adaptive Rubrics）」という新しい評価指標のアプローチです。従来の「LLM-as-a-judge」では、Agentの多様なタスクを網羅するために巨大で複雑な条件分岐を持つプロンプトが必要になるという課題がありました。適応型ルーブリックでは、ユーザーの「入力」に基づいてその都度動的に評価基準を生成し、その基準を用いてAgentの出力を評価します。
同プラットフォームには、GoogleやDeepMindの専門家が調整した「Response quality（応答品質）」「Tool use quality（ツール使用品質）」「Task success（タスク成功度）」など、7つの事前構築済みルーブリックが用意されており、多様なタスクを人間が評価した結果と高い相関を持って、自動的かつ正確に評価できるそうです。

「Agent支援型」の評価、最適化ループ

Alex氏が解説した「人間が主導する（Human-in-the-loop）」アプローチに続き、Dima氏が再び登壇し、AI Agentを活用した「Human-on-the-loop（人間の監督下で行う）」アプローチについて解説しました。Agentを新規に開発する際、手元には評価データも本番トレースもない「コールドスタート」の状態から始まることがほとんどです。ここで活躍するのが、GitHubで公開されている評価設計のベストプラクティスがMarkdownとしてカプセル化された『品質フライホイール・スキル（Quality Flywheel Skill）です。

Claude Code などのコーディングエージェントにこのSkillを読み込ませると、開発中のAgentのプロンプトやツール定義を読み込み、テストケースの件数や適切な評価指標（マルチターンのタスク成功度など）を自動で提案してくれます。さらに、生成されたテストパイプラインを実行し、その結果から具体的な修正案まで提示します。ここでDima氏が強調した非常に重要なポイントは、「最適化を行うAI（コーディングエージェント）と、評価を行うシステム（Evalサービス）を明確に分離すること」です。AIに評価と改善の両方を任せてしまうと、AIが評価指標のスコアだけを上げるような誤った最適化をしてしまう危険性があります。評価を独立したシステムとして機能させることで、スコアの健全性を保ちながら改善のサイクルを回すことができます。

まとめ：Agentは「ハンマー」ではなく「子犬」である

セッションの締めくくりとして、Dima氏は「初日から完璧なフライホイールを構築する必要はない」と語り、スモールスタートの重要性を説きました。そして最後に、ある顧客との会話から生まれたという、非常に印象的な比喩が共有されました。「従来のエンタープライズ・ソフトウェアは『ハンマー』です。設計し、機能させ、バグが出たらパッチを当てる。しかし、Agentは『子犬（Puppy）』のようなものです。継続的なフィードバックを与え、訓練し、関心を払い続けることで、時間とともに成長していくのです。Agentは最初から完璧である必要はありません。重要なのは、『改善可能（Improvable）であること』です。」
セッション全体を聴講して、生成AIを組み込んだシステム開発において、「作って終わり」のウォーターフォール的な発想は通用しなくなってきたと感じました。予測不可能なユーザーの入力や複雑化するタスクに対して、リリース後も継続的に品質を監視し、本番の失敗を次のテストデータとして還元していく「Flywheel（フライホイール）」の仕組みは、これからのAI開発における必須のエンジニアリング手法になると思ったので、今後も継続的にキャッチアップを続けていきたいと思います。

※本記事は「Engineer the agent-quality flywheel: Using Gemini Enterprise Agent Platform evaluations to optimize agents」(Google Cloud Next '26) の聴講内容をもとに、筆者の解釈・補足を交えて構成しています。