Agent Factory のハイライト: エージェントの評価、実用的なツール、マルチエージェント システムの詳細
Annie Wang
Google AI Cloud Developer Advocate
Mollie Pettit
Developer Relations Engineer
※この投稿は米国時間 2025 年 10 月 21 日に、Google Cloud blog に投稿されたものの抄訳です。
エージェントが実際に機能しているかどうかをどのように判断すればよいでしょうか？これは、開発において最も複雑でありながら、最も重要な問題の一つです。Agent Factory ポッドキャストの最新エピソードでは、セッション全体を通してエージェント評価を徹底解説しました。引き続き、エージェント評価の真の意味、測定すべきこと、ADK と Vertex AI を使用した測定方法について説明します。また、マルチエージェント システムにおけるより高度な評価についても学びます。
この投稿では、今回の対談からの重要なアイデアをいくつか紹介します。リンクやタイムスタンプを使って、トピックを素早く振り返ったり、特定のセクションを深く掘り下げてみてください。
エージェントの評価を分解する
まず、エージェントの評価が他の形式のテストとどのように異なるのかを定義します。
単体テストの先へ: エージェントの評価が異なる理由
Timestamp: [02:20]
まず理解すべきことは、エージェントの評価は従来のソフトウェア テストとは異なるということです。
従来のソフトウェア テストには決定性があり、同じ入力に対しては、毎回同じ出力が生成されることが期待されます（A は常に B に等しい）。
LLM の評価は、学校の試験のようなものです。Q&A ペアを使用して静的な知識をテストし、モデルが物事を「知っている」かどうかを確認します。
一方、エージェント評価は、仕事のパフォーマンス評価に似ています。最終的な回答をチェックするだけではありません。自律性、推論、ツール使用、予測不可能な状況への対処能力など、複雑なシステムの動作を評価しています。エージェントは非決定性であり、同じプロンプトを 2 回入力すると、2 つの異なる結果が得られます。どちらも有効な結果です。
フルスタック アプローチ: 測定対象
Timestamp: [04:15]
では、最終的な出力だけを見るのではなく、何を測定すればよいのでしょうか。簡単に言うと、すべてです。エージェントの動作の 4 つの主要なレイヤを考慮するフルスタック アプローチが必要です。
-
最終結果: エージェントは目標を達成したか？これは、単純な合格 / 不合格だけでなく、出力の品質も評価します。一貫性、正確性、安全性を確保できているか？ハルシネーションは回避されたか？
-
思考の連鎖（推論）: エージェントはどのようにして回答にたどり着いたのか？タスクが論理的なステップに分割されているか、推論に一貫性があるかを確認する必要があります。たまたま正解したエージェントは信頼できません。
-
ツールの利用: エージェントは作業に適したツールを選択し、正しいパラメータを渡したか？重要なのは、効率的であったかどうかです。エージェントが費用のかかる冗長な API 呼び出しループに陥ることは少なくありませんが、それをここで検出します。
- 記憶とコンテキストの保持: エージェントは、必要に応じて会話の初期の情報を思い出すことができるか？新しい情報が既存の知識と矛盾する場合、その矛盾を正しく解決できるか？
測定方法: グラウンド トゥルース、LLM-as-a-Judge（LLM による評価）、人間参加型
Timestamp: [06:43]
測定対象がわかったら、次の疑問は測定方法です。3 つの一般的な方法について説明しました。それぞれに長所と短所があります。
-
グラウンド トゥルース チェック: 客観的な測定に適した、迅速で安価、かつ信頼性の高い方法です。これらは、エージェントの出力に対する単体テストのようなものです。「これは有効な JSON か？」や「形式はスキーマと一致するか？」といったテストです。その限界は、ニュアンスを捉えられないことです。
-
LLM-as-a-Judge: ここでは、強力な LLM を使用して、エージェントの計画の整合性などの主観的な品質を評価します。このアプローチには非常に優れた拡張性がありますが、評価の精度はモデルのトレーニングとバイアスに依存します。
-
人間参加型: これは、ドメイン エキスパートがエージェントの出力をレビューする、最も信頼性の高い方法です。ニュアンスを捉えるには最も正確な方法ですが、最も時間がかかり、費用もかかります。
重要なポイントは、1 つだけを選ばないことです。最善の戦略は、キャリブレーション ループでこれらを組み合わせることです。まず、人間の専門家が小規模で高品質な「ゴールデン データセット」を作成します。次に、そのデータを使用して、LLM-as-a-Judge でスコアが人間のレビュー担当者のスコアと一致するまで、ファインチューニングします。これにより、大規模な自動化環境で人間レベルの精度を実現できます。
The Factory Floor: エージェントを 5 ステップで評価する
「The Factory Floor」は、実践コーナーです。ここでは、概念的な内容から Agent Development Kit（ADK）を使用した実用的なデモへと話を移しました。
ハンズオン: ADK を使用した 5 ステップのエージェント評価ループ
Timestamp: [08:41]
ADK ウェブ UI は、開発中の迅速なインタラクティブ テストに最適です。間違ったツールを使用していた簡単な商品調査エージェントをデバッグする、5 ステップの「インナーループ」ワークフローを説明しました。
1. 「ゴールデン パス」をテストして定義する。 エージェントにプロンプト（「A-phones について教えて」）を入力したところ、誤った情報（お客様向けの説明ではなく、社内 SKU）が返されました。次に、[評価] タブで回答を修正し、最初の「ゴールデン」テストケースを作成しました。
2. 障害を評価して特定する。テストケースを保存したら、評価を実行します。予想どおり、すぐに失敗しました。
3. 根本原因を特定する。ここから評価に入ります。トレースビューに切り替えると、エージェントの段階的な推論プロセスが表示されます。get_product_details の代わりに、間違ったツール lookup_product_information が選択されたことがすぐにわかりました。
4. エージェントを修正する。根本原因は、指示が曖昧だったことです。エージェントのコードを更新し、顧客向けのリクエストと社内データでどのツールを使用するかをより具体的にしました。
5. 修正を検証します。ADK サーバーがコードをホットリロードした後、評価を再実行したところ、今回はテストに合格しました。エージェントは、顧客向けの正しい説明を返しました。
開発から本番環境へ
この ADK ワークフローは開発には最適ですが、拡張性がありません。拡張性を持たせるには、本番環境グレードのプラットフォームに移行する必要があります。
インナーループからアウターループへ: ADK と Vertex AI
Timestamp: [11:51]
ワークフローは 2 つのループで構成されていると考えてください。
-
インナーループ用の ADK: 開発中に手動でインタラクティブに行う高速なデバッグ用に構築されています。
-
アウターループ用の Vertex AI: より豊富な指標（LLM-as-a-Judge など）を使用して大規模に評価を実行する必要がある場合は、Vertex AI の Gen AI Evaluation Service のような本番環境グレードのプラットフォームが必要です。このプラットフォームは、エージェントの複雑な定性評価を大規模に処理し、モニタリング ダッシュボードの構築に使用できる結果を生成するように設計されています。
コールド スタートの問題: 合成データの生成
Timestamp: [13:03]
どちらのワークフローにもデータセットが必要ですが、データセットがない場合はどうすればよいでしょうか。これは「コールド スタート問題」と呼ばれる問題ですが、合成データの生成によって解決できます。4 ステップのレシピで説明しています。
-
タスクの生成: LLM に現実的なユーザー タスクを生成させます。
-
完全なソリューションの生成: 「エキスパート」エージェントに、各タスクの理想的なステップバイステップのソリューションを生成させます。
-
不完全な試行の生成: より弱いエージェントや異なるエージェントに同じタスクを試行させ、欠陥のある試行のセットを作成します。
-
自動採点: LLM-as-a-Judge で不完全な回答と完全なソリューションを比較して採点します。
エージェント テストの 3 段階フレームワーク
Timestamp: [14:10]
評価データを入手したら、開発者の次の課題は明らかです。つまり、そのデータを使用して、スケーリング可能なテストをどのように設計するかということですが、すべての出力を手動でチェックし続けることはできません。この問題には、3 段階のテスト戦略で対処します。
-
Tier 1: 単体テスト。これは基礎となる階層です。従来のコーディングと同様に、エージェントの最小単位を個別にテストします。たとえば、エージェント全体を実行せずに、fetch_product_price などの特定のツールがサンプル入力からデータを正しく抽出することを確認します。
-
Tier 2: 統合テスト。これはエージェントの「試乗」です。ここでは、1 つのエージェントの複数ステップのジャーニー全体を評価します。完全なタスクを与え、推論とツールをうまく組み合わせて、最終的に期待される結果を生成できることを確認します。
- Tier 3: エンドツーエンドの人間によるレビュー。これは、自動化と人間の判断が組み合わされた、究極の健全性チェックです。複雑なタスクの場合、人間の専門家がエージェントの最終出力を評価し、品質、ニュアンス、正確性を確認します。これにより、「人間参加型」フィードバック システムが作成され、エージェントのパフォーマンスが継続的に調整および改善されます。この段階は、より大きなシステム内で複数のエージェントがどのように相互作用するかのテストを開始するフェーズでもあります。
次のフロンティア: マルチエージェント システムの評価
Timestamp: [15:09]
単一のエージェントからマルチエージェント システムに移行するにつれて、評価も進化する必要があります。エージェントを個別に評価しても、システム全体のパフォーマンスについてはほとんどわかりません。
ここでは、2 つのエージェント（初期対応を行うエージェント A と払い戻し処理を行うエージェント B）があるカスタマー サポート システムの例を使用しました。お客様から払い戻しを求められた場合、エージェント A の仕事は情報を収集してエージェント B に引き渡すことです。
エージェント A のみを評価すると、実際には払い戻しを行っていないため、タスク完了スコアはゼロになる可能性があります。しかし実際には、タスクを正常に引き渡すことで、その役割を完璧に果たしました。逆に、エージェント A が間違った情報を渡すと、エージェント B のロジックが完璧であっても、システム全体が失敗します。
マルチエージェント システムでは、エンドツーエンドの評価が重要になる理由がここにあります。エージェントがタスクをスムーズに引き継ぎ、コンテキストを共有し、連携して最終目標を達成しているかを測定する必要があります。
未解決の問題と今後の課題
Timestamp: [18:06]
最後に、エージェントの評価における現在の大きな未解決の課題をいくつか取り上げました。
-
費用とスケーラビリティのトレードオフ: 人間による評価は高品質ですが、費用がかかります。LLM-as-a-Judge はスケーラブルですが、慎重な調整が必要です。適切なバランスを見つけることが重要です。
-
ベンチマークの完全性: モデルの性能が向上するにつれて、ベンチマークの質問がトレーニング データに混入し、スコアの意義が薄れるリスクがあります。
-
主観的な属性の評価: エージェントの出力における創造性、積極性、ユーモアなどの質を客観的に測定するにはどうすればよいでしょうか。これらはまだ未解決の課題であり、コミュニティが解決に向けて取り組んでいます。
構築してみる
このエピソードでは多くのコンセプトを紹介しましたが、その目的は、堅牢な評価戦略を考え、実装するための実用的なフレームワークを提供することでした。ADK の高速な反復ループから Vertex AI のスケールアップされたパイプラインまで、適切な評価マインドセットを持つことが、優れたプロトタイプを本番環境対応のエージェントに変える鍵となります。
デモの様子をぜひエピソード全編でご覧いただき、これらの手法をプロジェクトで使ってみてください。
ソーシャル メディア
-Google AI クラウド デベロッパー アドボケイト、Annie Wang
-デベロッパー リレーションズ エンジニア、Mollie Pettit
