AIエージェントをどう評価するか？タスク、軌跡、信頼性、コスト

AIエージェントの評価とは、代表的なタスクを確実に完了できるか、許容される手順に従うか、定められた境界を守るか、そしてコストに見合う価値を提供するかを検証することです。最終的な回答だけでは十分ではありません。エージェントは、安全でない行動、根拠のない主張、過剰な再試行、あるいは偶然によって、もっともらしい結果にたどり着くこともあるからです。

エージェントの評価が難しいのは、システムが時間の経過とともに動作するためです。モデルはツールを選び、変化する環境を観察し、実行のたびに異なる経路をたどることがあります。そのため、効果的な評価では、試行を繰り返しながら結果と軌跡の両方を測定します。

エージェント評価の基本用語

Anthropicによるエージェント評価をわかりやすく解説するガイドでは、次のような用語が紹介されています。

• タスク：目的、環境、入力、成功基準を定めた1つのテストケース。
• 試行：エージェントが1つのタスクを完了しようとする1回の試み。
• トランスクリプトまたは軌跡：試行中に交わされたメッセージ、下された判断、ツールの呼び出し、観察内容、実行した行動の一連の記録。
• 評価器：性能の一部を採点するルール、プログラム、モデル、または人。
• 評価ハーネス：環境を準備し、試行を実行し、トレースを収集し、評価器を呼び出して、結果を報告するシステム。

これらの概念を区別しておけば、よくある誤りを防げます。つまり、成功した実演が1回あっただけで、エージェントが安定して性能を発揮すると判断してしまうことです。

まず、タスクを明確に定義する

有用な評価タスクでは、初期状態、利用可能なツール、制約、期待される結果、そして避けるべき重要な行動を記述します。テストは、特定の手順をあらかじめ示すことなく、実際の業務を再現するものであるべきです。

サポートエージェントに「チケットを解決する」と指示するだけでは、曖昧すぎます。より適切なタスクでは、顧客の記録、適用されるポリシー、許可された対応策、必要な連絡内容、そしてシステム・オブ・レコードに反映すべき変更を明確にします。そうすれば、客観的に評価できます。

エージェント評価を構成する4つの層

報告では、これらの層を分けて扱うべきです。すべてを1つの平均値にまとめると、容認できない挙動が見えなくなることがあります。たとえば、タスク成功率が高くても、許可されていないツールの呼び出しが頻発している場合があります。まず、チームで厳格な安全性の合格基準を設け、その基準を満たした実行の間で、結果の質と効率を比較できます。

1. 結果の質

エージェントは目標を達成したか。結果の評価器では、状態が正確に変更されたか、必須フィールドが入力されているか、テスト結果、事実の正確性、引用の根拠、または評価基準に基づく品質を確認できます。

可能であれば、エージェント自身の主張ではなく、環境の最終状態を使って評価します。コーディングエージェントは、バグを修正したと述べただけでは成功とはいえません。関連するテストと動作による確認が必要です。

2. 軌跡の質

エージェントは適切な手順をたどったか。軌跡の評価では、不要なデータへのアクセス、禁止されたツールの使用、失敗の繰り返し、検証の省略、観察内容の捏造、承認手続きへの違反を検出できます。

参照経路から外れたからといって、必ずしも誤りとは限りません。評価者が想定していなかった有効な解決策を見つけることもあります。評価器は、本当に必要な要件を適用しつつ、効率的な代替手段も認めるべきです。

3. 安全性とポリシーの遵守

エージェントは権限の範囲内で行動したか。テストには、プロンプトインジェクション、指示の競合、機密データ、ユーザーの意図が曖昧なケース、拒否またはエスカレーションが必要なリクエストを含めるべきです。

安全性評価は、サンドボックス内で現実的な結果が生じるようにする必要があります。ポリシーに沿った文を返したとしても、その前にエージェントがメッセージを送信したり、記録を変更したり、データを漏えいさせたりしていれば、それだけでは十分ではありません。

4. 運用効率

成功にどれだけの時間と費用がかかったか。モデルのトークン数、ツール呼び出し回数、実経過時間での遅延、再試行回数、人による介入、外部サービスの費用を記録します。不要な操作を100回行って成功するエージェントより、シンプルなワークフローのほうが有用な場合があります。

複数の種類の評価器を使う

決定論的な評価器は、テストに合格したか、ファイルが正しく変更されたか、データベースのフィールドに必須の値が設定されているか、禁止されたエンドポイントが呼び出されたかといった、厳密な条件を検査します。処理は速く、一貫性もありますが、開発者がコードに組み込んだ内容しか評価できません。

モデルベースの評価器は、明瞭さ、完全性、関連性、細かな基準への準拠といった品質を評価します。人によるレビューより大規模に実施できますが、偏りや一貫性の欠如が生じる可能性があるため、評価器自体の検証も必要です。

人間の評価者は、専門的な判断が必要な場合、判断が難しいケース、自動評価器の検証において重要です。評価には時間も費用もかかるため、チームは多くの場合、サンプル、不一致が生じたケース、影響の大きい分野に絞って活用します。

最も効果的な評価スイートは、これらのアプローチを組み合わせます。OpenAIのEvalsプラットフォームも同様に、評価を、非公式な確認ではなく、テストや評価器を定義し、実験を繰り返す体系的なプロセスとして扱っています。

信頼性の評価には試行の繰り返しが必要

サンプリング、ツールの変更、環境の状態によるばらつきを把握できるだけの回数、各タスクを実行します。平均的な性能と、重大な失敗が発生する頻度の両方を報告してください。複数の依存するステップから成るワークフローでは、各ステップの正解率が高く見えても、1回の失敗でタスク全体が頓挫するため、エンドツーエンドの信頼性は低いままの場合があります。

エージェントの動作は確率的です。同じタスクでも、異なる計画、ツール呼び出し、結果が生じることがあります。重要なタスクは複数回実行し、最良の例だけでなく、合格率やスコアの分布を報告してください。

信頼性を測る2つの指標は、それぞれ異なる問いに答えます。

• Pass@k：k回の試行のうち、少なくとも1回成功する確率です。複数回の試行が許容される場合に役立ちます。
• Pass^k：k回の試行すべてが成功する確率です。すべての実行で成功する必要がある場合の一貫性を示します。

Pass@kが魅力的な値でも、各回の実行が不安定であれば、自動運用には適さない場合があります。

代表性のあるタスクセットを構築する

実際に発生した失敗や、本番環境でよくあるリクエストから始めます。簡単なタスク、難しい境界ケース、曖昧な入力、ツールのエラー、古いデータ、情報の欠落、敵対的なコンテンツを含めてください。

結果をタスクの種類とリスクごとに分類します。全体の平均では、金融関連の操作、長期にわたるタスク、特定のアプリケーションにおける深刻な弱点が見えなくなることがあります。プロンプトの調整を繰り返しても評価スイートが学習用データセットにならないよう、評価に使わないデータセットを確保してください。

モデルだけでなく、実行環境も評価する

エージェントの性能は、ツールの定義、権限、メモリ、コンテキスト管理、ユーザーインターフェース、ネットワークの挙動、オーケストレーションに左右されます。モデルのアップグレードによって、あるエラーが減る一方、別のエラーが表面化することもあります。

各実行で使用したスタック全体のバージョンを管理します。モデル、プロンプト、ツール、データのスナップショット、環境、予算、評価器のバージョンを記録してください。そうしなければ、スコアの変化を意味のある原因に結び付けられません。

評価でよくある間違い

データ漏えいもリスクの一つです。ベンチマークのタスクや期待される回答、採点パターンがモデルの学習データやプロンプトのコンテキストに含まれていると、スコアが汎化能力ではなく、既知の内容を認識する能力を測っている可能性があります。非公開のホールドアウトタスクを維持し、システムの変更に応じてテストケースを更新するとともに、実行ごとに使用したモデル、プロンプト、ツールのバージョン、環境を正確に記録してください。

• デモ主導の評価：エージェントの得意なことを見てからタスクを選ぶ。
• 最終回答だけの採点：危険または無駄の多い実行過程を無視する。
• 単一実行からの結論：運よく成功した結果を、安定した能力だとみなす。
• 漏えいのあるテスト：回答や参照用の実行過程をエージェントのコンテキストに含める。
• 未検証のモデル採点器：自動判定が専門家の評価と一致するかを確認せず、正しいと決めつける。
• 固定された環境：単一のインターフェース、アカウント状態、またはデータ構成だけでテストする。
• 否定的なテストがない：タスクの完了だけを測定し、エージェントが適切に拒否したり、上位の担当者に対応を引き継いだりするかを確認しない。
• 経済性を無視する：コストとレイテンシが実用に耐えなくなるまで、成功率の最適化を続ける。

オフライン評価から本番環境のモニタリングへ

オフライン評価は、条件を制御して繰り返し実施できます。リリース前にプロンプト、モデル、ツール、ポリシーを比較するのに最適です。一方、本番環境のモニタリングでは、実際のユーザー行動や環境の変化に伴って生じる多様なケースを把握できます。

成熟したプログラムでは、この二つを連携させます。本番環境で発生したインシデントや信頼度の低い実行トレースを、新たなオフラインタスクにします。変更候補は回帰テストスイートに合格しなければなりません。デプロイ後は、タスクの成功率、介入率、ポリシー関連のイベント、ツールのエラー、コスト、レイテンシ、ユーザーからのフィードバックを監視します。

実用的なエージェント評価スコアカード

スコアカードでは、必須の合否基準と最適化の指標を区別する必要があります。ポリシーの遵守、権限の確認、必須の証拠提示は合否基準にできます。そのうえで、合格した実行について、正確性、レイテンシ、コスト、レビュー担当者の作業負荷を比較できます。これにより、平均スコアでは見えなくなる安全性の後退を招いてまで、わずかな効率向上を追求する事態を防げます。

有用なスコアカードには、次の項目を含められます。

• タスク成功率と品質スコア
• 試行を繰り返した場合の一貫性
• 重大なポリシー違反率
• ツールの選択と引数の正確性
• ツールまたは環境の障害からの復旧率
• 人間へのエスカレーション率と人間による介入率
• レイテンシの中央値とテールレイテンシ
• タスク成功1件あたりのモデル、ツール、人間にかかるコスト
• 妥当なベースラインと比較した実行過程の効率

実行1回あたりのコストだけでなく、タスク成功1件あたりのコストを報告してください。安価なエージェントでも、何度も失敗すれば、一度で成功する高性能なモデルよりコストがかさむことがあります。

AIエージェントの評価について覚えておくべきこと

エージェントの評価とは、現実的な条件のもとで、目標達成を目指すシステム全体をテストするための取り組みです。作業が正しいか、そこに至る過程が許容できるか、振る舞いを再現できるか、そして費用対効果が妥当かを測定します。

まずは、重要度の高いタスクを少数選び、複数回試行するとともに、複数の採点器を組み合わせて、実行過程全体を記録することから始めましょう。次に、本番環境で発生した意味のある失敗をすべて回帰テストに加えます。エージェントの能力は急速に変化します。持続的に使える評価システムがあれば、チームは実際の進歩と、説得力のあるデモとを見分けられます。