「テストは全部通ったのに、本番で崩れる」問題
エージェント開発でよくある誤解があります。「テストケース200件全部パスしたから大丈夫」という判断です。しかしリリースから一週間、誰も想定していなかった入力が飛んでくると、エージェントは静かに挙動を崩し始めます。
これはテスト設計の失敗というより、本番のタスクが事前に書けるどんなスイートよりも大きく、そして奇妙であるという事実そのものの問題です。だからこそ必要なのは、「開発中の評価」と「リリース後の評価」を同じ物差しで測る仕組みです。測定方法が違うと、本番でスコアがぶれたときに、それがエージェントの問題なのか測定方法の問題なのか切り分けられません。
Google CloudのGemini Enterprise Agent Platformにおいて、エージェント・モデル評価機能が正式リリース（GA）となりました。開発段階のローカル実験からライブトラフィックのモニタリングまで、単一のエンジン上で一貫したメトリクスで回すことができます。根拠資料はGoogle Developers Blogの公式発表をご参照ください。
日本のエンタープライズ案件、特に金融・医療系では「エージェントがなぜその回答をしたか」の監査ログ要件が既に顕在化しています。評価アーティファクトがCloud Storageにバージョン付きで残る点は、コンプライアンス観点で大きな利点です。
Experiment単位で回る評価パイプライン
評価の基本単位：Experiment
Agent Platform評価の一次作業単位はexperimentです。構成はシンプルです。
- eval casesデータセット：採点対象となる入力と期待値のセット
- metrics + scoresセット：何で、どう採点するか
これをUIで定義し、実行し、結果をレビューします。失敗ケース1件まで掘り下げると、エージェントの完全なtraceとセッションログを開いて「何が起きたか」を正確に確認できます。
実行経路は4つ
| 経路 | 用途 |
|---|---|
| Agent Platform SDK | コードベースのCI/CD統合 |
| agents-cli | ターミナルワークフロー（ADK-Python対応） |
| Google Cloud Console | UI上での実験定義・実行・レビュー |
| ADK直接呼び出し | 開発中のローカル反復（pytest含む） |
ローカル実行 vs サーバーサイド実行
- ローカル実行：高速な反復。全プロバイダーのモデルが利用可能
- サーバーサイド実行：既にデプロイ済みエージェントのセッション・traceをそのまま採点、またはuser simulatorを有効にしてユーザー反応が来る前にtraceを生成
すべての実験アーティファクトはCloud Storageに透過的に保存され、バージョン管理と監査が可能です。
コードベースカスタムメトリクスの例
# code-based metric: この形式の関数を登録する
from agent_platform.eval import code_metric
@code_metric(name="json_shape_check")
def json_shape_check(response: str, expected: dict) -> float:
"""レスポンスが期待するJSONスキーマに従っているか確認する"""
import json
try:
parsed = json.loads(response)
except json.JSONDecodeError:
return 0.0
# 必須キーがすべて存在するかチェック
required_keys = set(expected.keys())
if not required_keys.issubset(parsed.keys()):
return 0.0
return 1.0
コードベースメトリクスと計算ベースメトリクス（ROUGE、BLEU、MetricX、COMET、exact match）は追加コストがかかりません。LLM-as-a-judge系のみ、モデル呼び出しの標準料金が発生します。
Adaptive Rubric — Google DeepMindと共同開発したLLM-judge
なぜ「適応型」なのか
一般的なLLM-judgeは固定プロンプトで採点します。Adaptive Rubricは違います。eval case定義 + 開発者インストラクション + ツール宣言を読み、そのケース専用のpass/failルーブリックをその場で生成します。そして各ルーブリックについて判定（verdict）と根拠（rationale）をセットで返します。
標準搭載メトリクス（20種以上）
- Task Success：会話全体を通じた目標達成度（観測可能な結果＋確認応答ベース）
- Tool Use Quality：ツール選択、引数の正確性、スキーマ準拠
- Safety：ヘイト・ハラスメント・危険コンテンツ・性的表現・PIIポリシー違反の検出
- Trajectory Quality / Final Response Quality / Hallucination / Grounding
- 画像・動画品質メトリクス
Issue Clustering
大規模評価ジョブでは、失敗ケースを独自の失敗分類体系（taxonomy）に沿ってクラスタリングします。分類体系がない場合は、Adaptive Rubric用に事前構築されたtaxonomyを利用できます。
限界と注意点（批判的視点）
正直に指摘すべき点があります。
- LLM-judgeの判定は依然として確率的です。 Adaptive Rubricが根拠を返すのは大きな前進ですが、judgeモデル自体が誤る前提は変わりません。特にドメイン特化判断（医療・法律・金融）では、コードベースメトリクスを必ず併用してください。
- コスト構造がトラフィックに比例します。 オンラインモニターを全件で回すと費用が急増します。内蔵のサンプリングとターゲットフィルタを必ず設定し、ドリフトアラートは閾値ベースで設定するのが安全です。
- 日本の規制環境：PIIポリシー違反スコアが出たからといって、それが即座にコンプライアンス通過を意味するわけではありません。個人情報保護法の観点で別途レビューが必要です。
自然言語ガイドライン
ルーブリック生成を自然言語の指示で誘導でき、生成されたルーブリックグループはレビュー後に他のエージェントへ再利用可能です。チーム単位でルーブリック資産を蓄積するワークフローが現実的になります。
リリース後はCloud Traceからtraceをワンクリックで評価するか、オンラインモニターを立ててライブトラフィックを採点します。ダッシュボードで時系列のスコア推移を確認し、ドリフトアラートをメール・Slackなどで受け取れます。
まとめ — 「鋭いテスト」より「持続する測定」が勝つ
今回のGAの本質は、機能追加ではなく測定の連続性です。
- 開発中のローカル実験とリリース後のライブトラフィックが同じメトリクス、同じレジストリで回る
- 本番スコアがぶれたら、それはエージェントの問題であり測定方法の問題ではない
- アーティファクトはCloud Storageに残り、監査・バージョン管理が可能
- ケース生成器＋user simulator＋environment simulatorで手書きでは作れないシナリオまでカバー
特にenvironment simulatorは実務での効果が大きいです。バックエンドが遅い、あるいは失敗したときエージェントがどう耐えるかを、本番に触れずに事前確認できます。外部API障害が珍しくない環境では、ほぼ必須と言えます。
次のステップ学習方向
- ADKベースのエージェントにevalセットを付け、pytestでCIに載せる — ここから始めてください。
- Adaptive Rubricで独自taxonomyを作る — チームのドメインに合った失敗類型の定義が資産になります。
- オンラインモニター＋ドリフトアラートの設定 — リリース翌週には必ず必要になります。
あわせて読みたい記事
- AIエージェントがお金を払ってAPIを使う？Cloudflareの新しい決済ゲートウェイ分析 — エージェントが実際の支払主体になる時代のインフラ変化
- Claude Opus 4.6、Microsoft Foundryで正式リリース — コーディングとエージェントワークフローの新基準 — 評価対象となるモデル側の最新動向