AIエージェントの評価方法：テストセット、採点器、回帰チェック

優れたAI製品の裏には必ず、evalsと呼ばれる堅実なAIエージェント評価プロセスがあり、エラーを早期に発見して、エージェントが適切に機能することを保証しています。evalsは、人に代わって返金処理などのリスクの高いアクションを実行するAIエージェントにとって不可欠です。

このプロセスを構築するには、ある程度の技術的知識とデータ分析のスキルが必要です。とはいえ、思われているほど難しくも、とっつきにくくもありません。取り組みを始めやすいよう、AIエージェントを評価するための6つの実践的なステップと、プロセスを台無しにしがちなよくある誤解をまとめました。

AIエージェントを評価するとはどういうことか？

AIエージェントを評価するとは、タスクを正しく完了できているか、そしてその判断が組織の要件を満たしているかという観点から、エージェントのパフォーマンスを評価することです。実務的には、AIエージェント評価、つまりevalsとは、エージェントが想定された役割を果たせるだけの信頼性をもって機能するかどうかを組織が判断するための具体的な指標です。

製造工場で予備部品の在庫を確認し、補充依頼を準備するAI購買エージェントを考えてみましょう。承認済みの部品が入手できない場合や、サプライヤー情報が古くなっている場合、エージェントは問題を報告するでしょうか。それとも、未承認の代替品を推奨してしまうでしょうか。

そして、その問題を解決するためにシステムプロンプトを変更した場合、別の問題を新たに生んでいないことを、どうすれば確認できるでしょうか。

評価の仕組みがなければ、プロダクトマネージャーは事実上、推測に頼るしかありません。そのため、evalsは、パフォーマンスを測定し、繰り返し発生する問題を見つけ、より確信を持って変更をテストするためのフィードバックシグナルとなります。

そのうえで、エージェント評価では、1回の実行について次のような側面を検証できます。

• 最終結果の品質
• エージェントが使用した情報
• エージェントが呼び出したツール
• エージェントの動作を規定するルールに従ったかどうか

AIエージェント評価の一般的な指標

evalsは定性データと定量データの両方を扱います。定性評価は、エージェントの判断を手作業でレビューすることも含め、何が起きているのか、そしてなぜ起きているのかを理解するのに役立ちます。定量評価は、特定の失敗モードの発生頻度を数えたり、タスク成功率を算出したりするなど、そうした観察結果を測定可能なシグナルに変換します。

AIエージェント評価の基本的な指標は次のとおりです。

• タスク成功は、エージェントが意図した成果を達成したかどうかを測定します。通常は、有効な結果を生み出した実行の割合で測定されます。
• アクションの正確性は、エージェントがツールを適切に使用し、有効な引数を選択し、権限を順守したかどうかを測定します。
• 回答の品質は、最終出力が正確で、完全で、有用かどうかを評価します。事実の正確性、指示への準拠、そしてエージェントが利用可能な情報で自らの判断を裏付けているかどうかなどが含まれます。
• 信頼性は、繰り返しの試行、さまざまな入力、エッジケースにわたる一貫性を測定します。
• コストとレイテンシは、実行時間、トークン消費量、ツール呼び出しなど、成功する結果を得るために必要なリソースを測定します。

何を測定するかに応じて、evalsはエージェントのエンドツーエンドのパフォーマンス、実行の軌跡（トラジェクトリ）、あるいはツール呼び出しや情報取得ステップといった個々のコンポーネントを評価できます。

ステップ1：エージェントの実行が成功した状態を定義する

まず、エージェントが何を達成すべきか、つまりプロダクト要件を明確に記述します。当たり前に聞こえますが、これが意外と難しいのです。この問題には仕様ギャップ（specification gap）という名前まで付いています。

当社のシニアデータサイエンティストであるAndrey Khomutov氏は、次のようなアプローチを勧めています。

「まずは2つの問いから始めましょう。『何ができれば仕事をしたと言えるか？』、そして『一見成功した実行であっても、何があれば受け入れられないものになるか？』です。

エージェントの場合、技術的な観点からは、結果と、エージェントがそこに至った過程の両方を確認することを意味します」

エージェントは、流出した解答キーにアクセスして正しい答えを出したり、タスクを完了する過程で許可されていないアクションを実行したりする可能性があります。Khomutov氏は、解答の漏洩や評価中の安全でないアクションこそ、最終的な回答だけで判断すべきではない具体的な理由だと指摘します。

「トラジェクトリの検査は、結果が疑わしく見えるときだけ行うものではなく、エージェントのevalスイートの標準的な一部になると予想しています」と同氏は付け加えます。

次に、ドメインエキスパートに成功基準を検証してもらいます。その分野の実務知識を持つ人なら、AIエージェントに設定した条件が成功した成果を反映しているかどうかを判断できます。

ステップ2：実際のタスクと失敗からテストセットを構築する

エージェントの実際の動作を調べ、良いパフォーマンスと悪いパフォーマンスがどのようなものかを把握しましょう。問題が起こりそうだと思うことだけに基づいて、いきなり何十ものテストを生成したくなる誘惑に負けないようにしてください。

Hamel Husain氏（Parlance Lab、MLエンジニア）とShreya Shankar氏（MLシステムおよび応用AIのevals研究者）が推奨しているのは、機械学習とデータサイエンスから借用した手法であるエラー分析から始めることです。このプロセスは、エージェントの実行トレース（ユーザーの入力、ツール呼び出し、取得された情報、エージェントの出力を示す記録）の定性分析から始まります。

1. 個々のトレースをレビューし、エラーに注釈を付ける（オープンコーディング）。ドメインエキスパートにエージェントの実行を調べてもらい、何が問題だったのかについて短い所見を書いてもらいます。最初に生じた意味のあるエラーに注目しましょう。
2. 観察結果を失敗モードごとにグループ化する（軸足コーディング）。十分なメモが集まったら、LLMを使って類似したエラーのカテゴリを提案させます。たとえば、互換性のない部品の推奨、不正確な在庫情報の取得、人間への引き継ぎの失敗などが考えられます。
3. 発生回数を数える。各観察結果をカテゴリに割り当て、スプレッドシートやピボットテーブルを使って、各失敗モードの発生頻度を算出します。
4. 対処すべき事項に優先順位を付ける。その際は、頻度と深刻度の両方を考慮します。
5. 重要な失敗をテストケースに変換する。関連する入力、開始条件、期待される結果、採点基準を保存して、同じシナリオでエージェントを再度テストできるようにします。

トレースはいくつ調べればよいのでしょうか。目安は約100件ですが、決まった数はありません。理論的飽和、つまり追加のトレースをレビューしても意味のある新たな失敗パターンが見つからなくなる時点に達したら、早めに切り上げて構いません。

まだアプリケーションをリリースしていない場合は、合成した例を使って初期のテストセットを構築できます。ただし、実際のユーザーデータが利用可能になり次第、それをテストセットに反映させるべきです。

AIエージェント評価におけるベンチマークの活用

独自のテストケースを作成するだけでなく、ベンチマークと呼ばれる既存の標準化された評価タスク集を使って、エージェントの能力を評価することもできます。

ただし、ベンチマークも完璧ではありません。SWE-benchの監査、Epoch AIによるベンチマークのレビュー、そしてTheoPhysEvalで正解が当初は不正解とされた事例は、欠陥のあるタスクや期待される解答が評価結果をいかに歪めうるかを示しています。

Khomutov氏のアドバイスによれば、自分のドメインに関連する最新のベンチマークを選び、スコアをエージェントのパフォーマンスの信頼できる証拠として扱う前に、予想外の合格や不合格を調査すべきです。

ステップ3：再現可能なテスト環境でエージェントを実行する

再現可能なテスト環境とは、同じテストケースに対して同じ開始条件のもとでAIエージェントを実行し、結果を比較できる管理されたセットアップのことです。これには、テストケースのフォルダ、エージェントを実行するPythonスクリプト、結果を評価する一連のチェックなどが含まれます。

まずは、代表的な入力をJSONファイルとして保存し、Pythonスクリプトでエージェントのワークフローを実行して、アサーションで出力をチェックすることから始めるとよいでしょう。この製造工場の在庫エージェントの場合、再現可能なテスト環境は次のようになります。

拡大

再現可能なテスト環境をセットアップするには、次の手順に従います。

1. 代表的な入力を保存する。実際のイベントやテストケースを、本番環境でアプリケーションが受け取るのと同じ構造で保存します。今回のシナリオでは、機械ID、必要な予備部品、保守日を含む保守依頼をJSONファイルとして保存し、あわせて在庫データと承認済み部品データのスナップショットも保存します。
2. ワークフローを実行する。情報取得ステップ、ツール呼び出し、応答生成を含め、各入力をエージェントで処理します。
3. 結果とトレースを記録する。最終出力と関連する中間アクション（在庫の照会など）を記録しておけば、エージェントが失敗したかどうかだけでなく、どこで失敗したかもわかります。
4. 失敗の深刻度、頻度、問題修正の難しさに基づいてケースを繰り返す。LLMアプリケーションは非決定的（同一の入力から異なる結果を生成することがある）なため、1回の実行が成功しても次の実行が成功するとは限りません。成功した試行の割合を報告し、失敗を調査しましょう。

後者について、Khomutov氏はpass@1（エージェントが1回の試行で成功する頻度）とpass@k（指定した回数の試行のうち少なくとも1回成功する確率）を測定することを勧めています。pass@kを報告する場合は、試行回数を明記してください。複数の回答の中に正解が1つ含まれていても、エージェントがどれを選ぶべきかを理解しているとは限らないからです。

アプリケーションの規模が大きくなってきたら、pytestのようなテストフレームワークを使ってテストを整理・実行し、大規模なテストデータセットと結果をデータベースに保存することも検討しましょう。

ステップ4：チェックごとに適切なグレーダーを選ぶ

グレーダー（評価器（evaluator）とも呼ばれます）とは、コード、採点ルーブリックに従うLLM、または人間のレビュアーといった形で、定義された基準に照らしてエージェントの出力やアクションをチェックする仕組みです。グレーダーは合格／不合格の判定と、関連する根拠を示す説明を返します。

情報：採点ルーブリックとは、何をもって正しい結果または許容できる結果とするかを定義する一連の基準と指示です。

適切なグレーダーの種類は、何を検証したいかによって異なります。3つのアプローチを比較すると、次のようになります。

同じ実行でも、側面によって異なる評価方法が必要になる場合があるため、グレーダーを組み合わせる必要があるかもしれません。

グレーダーはどのように組み合わせればよいか？

次のように自問します。「結果は既知のルールや期待値に照らして検証できるか、それとも人間のような判断が必要か？」

• 結果を厳密に検証できる場合は、コードベースのグレーダーから始めましょう。コードベースのグレーダーは、構造化された出力、有効なフィールド値、ツールの引数、データベースの最終状態なども検証できます。
• チェックに文脈の解釈が必要な場合は、LLM-as-a-judgeを使用します。
• ドメイン固有の判断や意見が分かれる判断には、人間のレビュアーを起用します。

重要：LLMグレーダーは、根拠を誤って解釈したり、ルーブリックを誤って適用したりすることがあります。そのため、人間の判断に照らしたキャリブレーションという追加の評価ステップが必要です。

LLMグレーダーを人間の判断に照らしてキャリブレーションします。

基本的に、キャリブレーションでは、ドメインエキスパートが実際のエージェントの実行を評価する必要があります。その後、エキスパートは自身の判断をLLMの判断と比較し、意見が食い違った点に基づいて採点ルーブリックを改良します。

以下は、5つのステップからなるグレーダーのキャリブレーションプロセスです。

1. エージェントの入力、出力、関連するトレースの例を収集します。
2. ドメインエキスパートに、各例が評価基準を満たしているかどうかを独立して評価してもらいます。
3. それらの例に対してLLMグレーダーを実行します。
4. 人間とモデルの判断を比較します。
5. 判断が食い違った点を調査し、新しい例でテストする前にグレーダーのルーブリックを改良します。

Khomutov氏は、LLMグレーダーの一貫性を個別にテストすることの重要性も強調しています。

「エージェントを再実行せずに、保存したまったく同じ実行結果とファイルを何度か与えてみてください。そうすれば、エージェントの作業のばらつきと採点のばらつきを切り分けることができます」

同じ出力に対して異なる判定が下される場合、スコアの変化がすべてエージェントに起因すると考えないでください。代わりに、グレーダーがエラーを正しく特定したケース、見逃したケース、許容できる出力を誤ってエラーと判定したケースを示す混同行列を調べましょう。

人間によるレビューは、基準となる判断の確立、意見が分かれるケースの解決、そして既存のグレーダーでは検出するように設計されていない新たな失敗モードの発見において、依然として不可欠です。

ステップ5：バージョンを比較し、リグレッションチェックを実行する

エラー分析の結果、在庫エージェントが未承認の交換部品を頻繁に推奨していることが判明したとします。そこで、明示的な互換性チェックを必須とするようにシステムプロンプトを修正します。元々失敗していたケースは合格するようになりました。しかし、この変更が他のタスクに影響していないことは、どうすればわかるでしょうか。

そこで登場するのがリグレッションテストです。

リグレッションテストとは、エージェントのプロンプト、モデル、またはワークフローを変更した後に、以前成功したテストケースを再実行し、変更によって新たな失敗が生じていないことを確認することです。

1. テストセットに保存された入力を使って、元の失敗を再現します。
2. プロンプト、モデル、またはワークフローに的を絞った変更を加えます。
3. 失敗したテストを再実行し、問題が解決されたかどうかを確認します。
4. 他のテストを実行し、変更によって以前は正常に動作していた挙動が損なわれていないことを確認します。
5. 結果を確認し、新たな失敗があれば調査します。

正確な結果を得るために、同じテストケースと採点基準を使ってベースラインのエージェントと更新後のエージェントを比較します。

ステップ6：本番環境でAIエージェントのパフォーマンスを監視する

エージェントの評価は、アプリケーションをデプロイしたら終わりではありません。HusainとShankarが説明しているように、開発中に使用するのと同じ評価器を実際の本番データに対しても実行することで、エージェントのパフォーマンスを継続的に測定できます。

これはオンライン評価と呼ばれ、繰り返し発生する失敗やこれまで知られていなかった失敗を明らかにする、より広範な本番監視プロセスの一部です。

このプロセスは反復的なもので、相互に補完し合う次の4つの活動で構成されます：

• 本番環境のトレースに対して、キャリブレーション済みのLLMジャッジを実行する。実際のエージェントのやり取りをサンプリングし、人間の判断との整合性をすでに検証済みの評価器を適用します。
• 失敗率を継続的に追跡する。エラー分析の際に定めた失敗カテゴリを使って、繰り返し発生する問題を定量化します。
• トレースの手動レビューを続ける。自動採点器が検出できるのは、検出するように設計された問題だけです。実際のエージェントのやり取りのサンプルを手動で確認し、新たなエラーや通常とは異なるユーザーリクエストを見つけ出しましょう。
• A/Bテストでビジネス成果を測定する（適切な場合のみ）。タスク完了率、ユーザー満足度、解決までの時間などの指標を使って、異なるプロンプト、モデル、ワークフローを比較します。このプロセスにより、個々のテストに合格するだけでなく、変更が実際の製品体験を向上させるかどうかを判断できます。

重要な注意点が1つあります。評価は完璧に磨き上げる必要はありません。製品の改善に役立つレベルであれば十分です。

AIエージェント評価に関するよくある誤解

• 評価は単なるユニットテストである。そうではありません。ユニットテストは小規模な自動チェックであり、評価の一部にすぎません。評価には、アプリケーションの品質を測定するための定性的なエラー分析、人間による判断、本番監視、実験も含まれます。
• 評価プラットフォームがすべてを代行してくれる。既製のツールで一部のチェックを自動化することはできますが、製品にとってどの失敗モード（エラーの種類や望ましくないエージェントの挙動）が重要かを判断することはできません。
• すべての評価をLLMに任せられる。これは大きな誤りです。LLMにはあらゆる問題を発見するために必要なビジネス上のコンテキストが欠けているため、人間主導のエラー分析と採点器のキャリブレーションは依然として不可欠です。
• A/Bテストや、単にエージェントを使ってみることが評価の代わりになる。誤りです。A/Bテストでは、選択した指標に照らしてどのバージョンのパフォーマンスが優れているかはわかりますが、それだけでは根本的な問題を説明することはできません。

AIエージェント評価に関するよくある質問

1. AIエージェント評価とLLM評価の違いは何ですか？

LLM評価は、質問への回答、ドキュメントの要約、情報の抽出など、特定のタスクを言語モデルがどれだけうまく実行できるかを測定します。AIエージェント評価は、タスクを完了するために複数のステップを自律的に実行するシステムを評価します。

一般的なLLM評価とは異なり、エージェント評価では最終結果だけでなく、ツール呼び出し、意思決定、事前に定義されたルールの遵守など、その結果に至るまでの一連のアクションも検証します。

2. AIエージェント評価の主要な指標

AIエージェント評価の指標は、大きく2つのカテゴリに分けられます：

• 技術的なパフォーマンス指標：タスク成功率、アクションの正確性、回答の品質、信頼性（pass@1およびpass@k）、レイテンシ、トークン使用量、成功したタスクあたりのコスト。
• ビジネスおよびユーザーエクスペリエンス指標：顧客満足度（CSAT）、問題解決率、エスカレーション率、コンバージョン率、タスク完了時間、その他エージェントの役割に固有の成果。

たとえば、カスタマーサポートエージェントは問題を解決できたかどうかや顧客満足度で評価される一方、AI購買エージェントは補充リクエストの正確性、承認率、調達サイクルタイムで測定される場合があります。

適切な指標は、エージェントがどれだけ確実に機能するか、そしてその作業がビジネス成果を向上させるかどうかの両方を反映している必要があります。

3. AIエージェントの評価に最適なツールは何ですか？

一般的な選択肢には次のようなものがあります：

• テストフレームワーク：Pythonのアサーションやpytestは、反復可能なテストケースを実行したり、エージェントが正しいツールを選択したか、有効な部品IDを返したかといった厳密な条件を確認したりするのに役立ちます。
• AIエージェント評価フレームワーク：DeepEvalやGoogleのagent-eval toolkitは、実行トレース、LLMベースの採点器、自動回帰テストなど、より複雑な評価をサポートします。
• 評価およびオブザーバビリティプラットフォーム：LangSmith、Arize Phoenix、MLflowは、チームがエージェントの挙動を調査し、評価データセットを管理し、エージェントのバージョンを比較し、本番環境でのパフォーマンスを監視するのに役立ちます。

4. AIエージェントの評価を自動化するにはどうすればよいですか？

AIエージェントの評価は、反復可能なテストを構築し、自動採点器を適用して、それらのチェックを開発および本番のワークフローに統合することで自動化できます：

1. 評価データセットを作成する：代表的なユーザータスク、期待される結果、既知の失敗、エージェントの実行トレースを収集します。ツール呼び出しの失敗、情報の欠落、権限のないアクションなどのエッジケースも含めます。
2. テストの実行と採点を自動化する：pytestやDeepEvalなどのフレームワークを使ってテストケースを実行し、コードベースのチェックやLLM採点器を適用します。LLM採点器のスコアに頼る前に、人間の判断と照らし合わせて検証してください。
3. 評価をCI/CDに統合する：開発者がエージェントのプロンプト、モデル、ツール、ワークフローを更新したときに、回帰テストを自動的に再実行します。結果をベースラインと比較し、重要なチェックが失敗した場合にリリースを阻止する品質しきい値を設定します。
4. サンプリングした本番トレースにキャリブレーション済みの採点器を適用し、失敗率やその他のパフォーマンス指標を追跡して、手動レビューを通じて新たなエラーを調査します。