Googleが2026年6月30日に公開した「Driving the Agent Quality Flywheel from Your Coding Agent」は、AIエージェントの評価を“勘”ではなく継続運用に変えるための実務ガイドです。ポイントは、OpenTelemetry tracesを起点に、AutoRatersで採点し、failure clustersで原因をまとめ、改善案を再評価まで回すことです。単にプロンプトを直すのではなく、変更が本当に品質改善につながったかを追跡しやすくなります。
Agent Quality Flywheelとは何か
Googleはこの仕組みを、Build & Test → Ship & Monitor → Learn & Refineの循環として説明しています。今回追加されたのは、coding agentがその循環を代行しやすくする開発者向けの入り口です。ブログでは5段階として、1) データ準備、2) 推論実行、3) 評価、4) 失敗分析、5) 改善と再試行、を明示しています。つまり評価基盤の中心は“モデルを1回試すこと”ではなく、“改善を比較可能な形で残すこと”にあります。
何が変わるのか
従来は「この修正で良くなった気がする」で進みがちでしたが、Googleの整理ではその状態を明確に否定しています。評価は独立した仕組みで行い、改善提案を出す側が自分で採点しないことが重要です。ブログでも optimizer と evaluator を分離し、自己採点はメトリクスを“攻略”しやすくなると説明しています。運用現場では、開発担当が修正し、別の評価サービスが同じ基準で点数を返す設計にすることで、リグレッション検知がしやすくなります。
評価運用で先に確認したい3要素
第一に traces です。Google Cloudの tracing ドキュメントでは、trace は各リクエストの時系列記録で、LLM呼び出しやツール実行を span として持つと説明されています。第二に metrics です。Google管理の predefined metrics には task success や tool use quality があり、さらに独自 rubric を registry に保存できます。第三に failure analysis です。結果を平均点だけで終わらせず、rubric verdict と rationale を見て、似た失敗を clusters にまとめるところまでがワンセットです。
OpenTelemetry tracesはなぜ重要か
AIエージェントの失敗は、最終回答だけ見ると見逃されます。Googleの例でも、内部状態やツール呼び出しは正しかったのに、最後の自然言語応答だけが古い条件を返していました。trace を取っておけば、「どの turn で条件が更新され」「どの tool call までは正しく」「どの final response で崩れたか」を切り分けられます。ADKでは telemetry を有効化する環境変数が案内されており、入力・出力や user.id の扱いには同意とデータポリシー整備が必要だと明記されています。つまり observability とプライバシー管理はセットです。
AutoRatersとcustom rubricの使い分け
Googleの managed metrics は、multi-turn の task success や trajectory quality のような汎用指標をすぐ使えるのが利点です。一方で、ブログの事例では「途中で変更された条件を最終回答が反映したか」を安定して追うため、revision_honored という custom rubric を追加していました。実務でも同じで、共通KPIは managed metrics、部門固有の合否は custom rubric に分けると運用しやすくなります。たとえば営業AIなら見積条件反映、社内FAQなら根拠URL提示、サポートAIならエスカレーション判断を独自指標にできます。
導入時の最短ステップ
最初から本番データがなくても進められます。Google Cloudの simulation ドキュメントでは、1) scenario generation、2) simulated sessions の2段階を案内しています。まず agent の instructions と tools から想定ケースを自動生成し、その後 User Simulator が multi-turn 会話を再生して traces を作ります。そこで fail case を見つけたら、evaluation dashboard や result.show() で aggregate と case別結果を見て、Automatic Loss Analysis で失敗群をまとめます。社内導入では、最初の25〜50ケースを synthetic で作り、その後は production traces を混ぜる形が現実的です。
よくある質問
Q. すべてのチームで Google の managed metrics をそのまま使えば十分ですか？ A. いいえ。汎用指標は比較の軸として便利ですが、実運用では“何を失敗とみなすか”を custom rubric で明文化しないと、改善が事業成果に結びつきません。
Q. まだ本番利用前でも導入する価値はありますか？ A. あります。Googleは simulation による scenario generation と user simulation を用意しており、production traffic がなくても初期評価セットを作れます。ただし sharp な改善ループにするには、後から実トレースを混ぜる前提で設計すべきです。
Agent評価の設計、trace設計、rubric定義まで含めて整えたい場合は、 HelloCraftAIにご相談ください。 PoCの精度確認で止まらず、運用段階の継続評価まで見据えたAI導入を支援します。
