デベロッパー

エージェント評価への体系的なアプローチ: 堅牢な品質ゲートの構築

2025年12月4日

Hugo Selbie

Staff Customer & Partner Solutions Engineer, Google

Try Nano Banana 2

State-of-the-art image generation and editing

※この投稿は米国時間 2025 年 11 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

AI は、単一の回答モデルから、推論、ツールの使用、高度なタスクの完了が可能な複雑なマルチステップエージェントへと移行しています。機能が向上したということは、これらのシステムを評価する方法も進化させる必要があるということです。一連の意思決定を行うシステムでは、最終的な出力のみに焦点を当てた指標ではもはや不十分です。

主な課題は、エージェントが正しい出力を生成しても、そのプロセスが非効率的または不適切な場合があるということです。これは「サイレント障害」と呼ばれます。たとえば、在庫報告を担当するエージェントであれば、正しい数を提示していても、誤って昨年のレポートを参照していることがあります。この場合、結果は正しいように見えますが、実行プロセスには問題があります。このようにエージェントに問題があった際に、単に「間違っている」または「正しい」と表示されるだけでは、システムのどこで障害が発生したかを判断するために必要な診断情報が得られません。

効果的にデバッグして品質を確保するには、エージェントのアクションの複数の側面を理解する必要があります。

軌跡: 結果に至るまでの推論とツール呼び出しのシーケンス。
全体的なエージェントとのやり取り - ユーザーとエージェント間の会話全体（チャットエージェントを想定）
エージェントが操作されてアクションを実行したかどうか

この記事では、堅牢でカスタマイズされたエージェント評価戦略を構築するための構造化されたフレームワークの概要を説明します。これにより、確信を持ってエージェントを概念実証（POC）から本番環境に移行できるようになります。

成功から始める: エージェントの目的を定義する

効果的な評価戦略は、明確で曖昧さのない成功基準を基盤として構築されます。そこでまず、次の重要な問いから始める必要があります。この特定のエージェントにとっての成功の定義とは何ですか？ここでの成功の定義は、測定可能な指標に直接つながる具体的なものでなければなりません。

曖昧な目標（役に立たない）	明確な成功の定義（測定可能）
「エージェントは役に立つ存在であるべきです。」	RAG エージェント: 成功とは、既知の文書に完全に裏付けられた、事実に基づく正確で簡潔な概要を提供することです。
「エージェントは旅行の予約を問題なく完了すべきです。」	予約エージェント: 成功とは、ユーザーの制約条件（時間、費用、航空会社）をすべて満たす複数区間のフライトを、エラーなく正しく予約することです。

最初に成功を定義することで、エージェントが達成すべき明確なベンチマークを確立できます。

目的主導の評価フレームワーク

堅牢な評価には、3 つの柱をカバーする成功基準と、それに関連するテスト可能な指標が必要です。

柱 1: エージェントの成功と品質

ここでは、最終的な出力とユーザーエクスペリエンスに焦点を当て、エージェントのインタラクション全体を評価します。これは、エージェントが本番環境で使用されるのとまったく同じようにテストされる統合テストのようなものだと考えてください。

測定対象: 最終結果。
指標の例: インタラクションの正確性、タスク完了率、会話の根拠性、会話の一貫性、会話の関連性。

柱 2: プロセスと軌跡の分析

ここでは、エージェントの内部意思決定プロセスに焦点を当てます。これは、複雑で動的な推論を行うエージェントにとって非常に重要です。エージェントの意思決定パスごとに行う一連の単体テストのようなものと考えてください。

測定対象: エージェントの推論プロセスとツールの使用状況。
主な指標: ツール選択の精度、推論ロジック、効率性。

柱 3: 信頼性と安全性の評価

ここでは、理想的ではない状況下でのエージェントの信頼性と復元力を評価します。これは、エージェントに対する悪意ある入力を回避するためのものです。実際には、エージェントが本番環境で稼働しているときに、予期しない方法でテストされる可能性があるため、エージェントがそのような状況に対処できるという信頼を築くことが重要です。

測定対象: 悪条件下での信頼性。
主な指標: 堅牢性（エラー処理）、セキュリティ（プロンプトインジェクションへの耐性）、公平性（バイアスの軽減）。

テストを定義する: 評価方法

フレームワークが整備されていれば、選択した指標によって明確に決定されるべき具体的なテストを定義できます。多層的なアプローチがおすすめです。

人間による評価

人間による評価は、評価スイート全体を実際のパフォーマンスとドメインの専門知識に基づいて構築するために不可欠です。このプロセスでは、製品が実際に示している特定の障害モードと、成功基準を満たせない箇所を特定することで、グラウンドトゥルースを確立します。

LLM が判定

人間の専門家が特定の障害モードを特定して文書化したら、LLM を使ってエージェントのパフォーマンスをスコア化する、スケーラブルな自動テストを構築できます。LLM を判定者として活用するプロセスは、複雑で主観的な障害やアクティビティに使用され、エージェントの改善を判断するための迅速かつ再現可能なテストとして使用できます。導入する前には、LLM の判定結果を人間の評価と整合させる必要があります。そのために、LLM の出力を元の手動による人間の出力と比較し、結果のグラウンドトゥルーシングを行います。

コードベースの評価

これは最もコストが低く決定的なテストであり、多くの場合、柱 2 でエージェントの軌跡を観察することで特定されます。出力が JSON 形式であることや、特定の長さの要件を満たしていることの確認など、単純な Python 関数やロジックでチェックできる障害モードに最適です。

メソッド	主要目標	評価対象	スケーラビリティと速度
人間による評価	主観的な品質とニュアンスに関する「グラウンドトゥルース」を確立すること。	柱 1（UX、スタイル、安全性）と柱 2（倫理的 / 高価なツールの使用）。	低スケーラビリティで低速。コストと時間がかかる。
LLM が判定	大規模な主観的品質に関する人間の判断を近似すること。	柱 1（一貫性、有用性）と柱 2（内部推論の質）。	中～高のスケーラビリティで高速。慎重なプロンプトエンジニアリングが必要。
プログラムによる評価	既知の基準に対する客観的な正確性を測定すること。	柱 1（事実の正確性、RAG の根拠）と柱 2（ツール呼び出しの正確性）。	高スケーラビリティで高速。自動回帰テストに最適。
敵対的テスト	予期しない入力や悪意のある入力に対するエージェントの堅牢性と安全性をテストすること。	エージェントの障害モード（エージェントが安全に障害を起こすか、有害な出力を生成するか）。	スケーラビリティも速度も中程度。テストケースのクリエイティブな生成が必要。

高品質な評価データを生成する

堅牢なフレームワークも、実行対象となるデータが良質でなければ意味がありません。数千ものテストケースを手動で作成すると、ボトルネックが生じます。最も堅牢なテストスイートは、複数の手法を組み合わせて、多様で関連性の高い、現実的なデータを大規模に生成します。

「対決する LLM」による会話の合成: 2 つ目の LLM をユーザー役として使用することで、多様な複数ターンの会話データを生成して、エージェントを大規模にテストできます。これは、柱 1 の評価に使用するデータセットの作成に最適です。
本番環境のデータの使用と匿名化: 匿名化された実際のユーザーインタラクションを使用して、実際の使用パターンとエッジケースを捉えた「ゴールデンデータセット」を作成します。
人間参加型のキュレーション: 開発者は、ログやトレースから貴重なインタラクティブセッションを永続的なテストケースとして保存し、有意義な例でテストスイートを継続的に充実させることができます。

ゴールデンデータセットは必要ですか？

評価を実行するには、ログやトレースなどの評価データが常に必要です。ただし、必ずしも開始時に事前にラベル付けされたゴールデンデータセットが必要になるわけではありません。高度な検証（RAG でエージェントが既知の回答に到達する方法の理解や、回帰の検出など）には、完璧で既知の良好な出力を提供するゴールデンデータセットが不可欠ですが、それが障害になるべきではありません。

ゴールデンデータセットなしで開始する方法

初期の品質を判断するために、人間による評価と雰囲気に基づく評価指標だけで始めることもできます。これらの初期の主観的な指標とフィードバックは、「LLM が判定」のスコアリングに適応できます。

たとえば、「LLM が判定」でテストされた正確性、簡潔性、安全性などの主要な側面について、初期の人間によるフィードバックを集計し、一連のバイナリスコア（合格 / 不合格）に変換します。「LLM が判定」は、これらのバイナリ指標に基づいてエージェントのインタラクションを自動的にスコアリングし、全体的な成功または失敗を判断します。エージェントの全体的な品質は、カテゴリ別の文字による評価システムで集計してスコアリングできます。たとえば、「A」はすべてのバイナリテストに合格、「B」はバイナリテストの 3 分の 2 に合格、「C」はバイナリテストの 3 分の 1 に合格、といった具合です。

このアプローチにより、実際の失敗と成功をキュレートすることで、ゴールデンデータセットを継続的に構築しながら、構造化された品質ゲートをすぐに確立できます。