AIエージェント評価とは？軌跡・ツール呼び出し・タスク達成を測る指標と実装の進め方【2026年版】

AIエージェント評価とは、エージェントが返した最終回答だけでなく、そこへ至る手順（どのツールをどの順で呼び、何回やり直したか）まで含めて採点し、品質が落ちた原因を層ごとに切り分ける作業です。チャットボットの評価と決定的に違うのは、正解の出力が1つに定まらない点にあります。同じ「返品を受け付ける」という結果でも、規約を確認してから処理した軌跡と、確認せずに処理した軌跡では、業務上の意味がまったく違うためです。本記事では評価対象の分解から、各クラウドが用意する指標名、自動採点に任せてよい範囲までを実装目線で整理します。

まとめ：AIエージェント評価の要点と合否ラインの引き方を先に示す

結論から述べます。評価対象は4層に分けてください。最終回答の品質、タスクが達成されたかどうか、そこへ至った軌跡（トラジェクトリ）、そして所要時間・トークン・呼び出し回数といったコストです。この4層を同時に見ると、失敗したときに直す場所がほぼ一意に決まりました。

指標は自作せず、まず既製のものへ寄せるのが手堅い選択です。2026年7月時点で、Google CloudのGen AI Evaluation Serviceは軌跡の一致を測るtrajectory_exact_matchやtrajectory_precisionなどを持ち、Ragasはツール呼び出しの正確さやゴール達成を測るエージェント向け指標を備えています。Microsoft Foundryはエージェントの定義から採点基準（ルーブリック）を生成する方式を主軸に据えました。

そして合否の引き方です。単発の成功率（pass@1）だけを合格判定に使うのは避けてください。エージェントは同じ入力でも試行ごとに挙動が揺れるため、複数回すべて成功したかを見る指標（pass^k）で再現性を確認したうえで、業務が許容できる失敗の型からラインを逆算する必要があります。理由は独自章で条件付きに述べます。

AIエージェント評価とは？結果と過程を分けて測る評価設計の考え方

AIエージェント評価の定義と、成功率だけを追うと改善が止まる理由

AIエージェントは、LLMが状況を判断してツールを呼び、その結果を見て次の行動を決める反復構造で動きます。この反復そのものについてはエージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計を実装者視点で解説【2026年版】で扱っていますので、前提が曖昧なら先にそちらをご覧ください。

評価が難しくなるのは、この反復が入るからです。入力から出力までが一往復のモデル評価であれば、出力文を採点すれば済みます。ところがエージェントでは、途中で誤ったツールを呼んでも、後段で辻褄を合わせて正しい最終回答へ着地することがあります。逆に、手順は模範的なのに最後の要約で数値を書き損じる場合もあるわけです。最終回答の正誤という1つの数字だけでは、この2つがまったく区別できません。

結果として、成功率が70%へ落ちたときに「プロンプトを直すのか、ツールの説明文を直すのか、そもそもツールが足りないのか」が決められない状態に陥ります。過程を記録して採点する設計は、精度を上げるためというより、次の一手を決められる状態を作るために要る措置でした。

評価の対象を4つの層へ分けて、故障箇所を一意に絞り込む診断表

実務では、次の表の並びで見ていくと切り分けが速く進みます。上から順に確認し、最初に閾値を割った層が直すべき場所です。

検索を伴う構成（RAG）を内部に持つエージェントでは、最終回答の層をさらに検索側と生成側へ割る必要があります。その分解はRAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】で詳述しているため、本記事では軌跡とツール呼び出しの層に集中します。

軌跡評価とツール呼び出し精度を、実装できる単位の指標へ分解する

軌跡の一致をどの厳しさで測るかによって、拾える失敗の型が変わる

軌跡評価は、期待するツール呼び出しの並び（参照軌跡）を先に用意し、実際の呼び出し列と突き合わせる方式が基本です。Google CloudのGen AI Evaluation Serviceは、この突き合わせの厳しさを段階的に用意しています。公式ドキュメントに記載された指標名は、完全一致を求めるtrajectory_exact_match、余分な呼び出しを許しつつ順序を求めるtrajectory_in_order_match、順序を問わないtrajectory_any_order_match、そして割合で返すtrajectory_precisionとtrajectory_recall、特定ツールの使用有無だけを見るtrajectory_single_tool_useです。加えて遅延と失敗有無が既定で付きます（2026年7月時点でプレビュー提供）。

使い分けの勘所は、業務が手順を強制するかどうかにあります。本人確認を経てから残高を返す、といった順序に意味がある処理なら順序一致を、情報収集のように順番が任意なら順序を問わない一致を使ってください。すべてを完全一致で縛ると、模範解答と等価だが別経路の正しい振る舞いまで不合格になり、指標が改善の邪魔をします。

再現率と適合率の読み分けも実務的です。再現率が低ければ必要な呼び出しを飛ばしており、ツールの説明文が足りないか、そもそも呼ぶ動機が伝わっていません。適合率が低い場合は余計な呼び出しが多く、コストと遅延に跳ね返ります。ツール定義そのものの書き方はAIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】が具体的です。

ツール呼び出しの正誤は、引数の中身まで見ないと誤りが通り抜ける

ツール名が合っていても、引数が誤っていれば結果は誤ります。OSSの評価ライブラリRagasは、エージェント向けにツール呼び出しの正確さを測る指標を用意しており、呼び出しの並びと引数の一致を見る方式と、順不同で適合率・再現率から求める方式の両方を持ちます。あわせて、会話が想定の領域から外れていないかを見る指標、参照ありと参照なしの2通りでゴール達成を判定する指標も提供されました。いずれも0から1のスケールで、ゴール達成は0か1の二値です。

実装の順序としては、引数の型と必須項目をスキーマで縛れる部分は、LLM判定ではなくコードで検証してください。日付形式や列挙値の誤りは決定的に判定でき、LLMへ投げれば費用と揺らぎが増えるだけです。LLM判定は「顧客の意図に照らして呼ぶべきツールだったか」のように、規則で書き下せない部分へ温存するのが費用対効果に見合います。この採点役としてのLLMの性質はLLM-as-a-Judgeとは何か？AIモデルを評価者にする最新の自動評価手法の概要と仕組みを徹底解説で整理しています。

公開ベンチマークの点数を、自社の合否ラインへ持ち込んではいけない

公開ベンチマークは、モデルやフレームワークの相対比較には役立ちます。一方で、そのスコアは自社業務の合格ラインにはなりません。ベンチマークは版が上がると採点方法やタスク定義が変わり、版をまたいだ数字の比較が成立しなくなるためです。参照する際は、必ず版と測定時点をセットで記録してください。

ベンチマーク側から借りるべきは点数ではなく考え方です。たとえば顧客対応系のベンチマークで用いられるpass^kは、k回試してすべて成功した割合を見ます。単発成功率が90%のエージェントでも、5回連続で成功する確率は0.9の5乗で約59%、8回なら約43%まで落ちる計算です。業務で同じ処理を1日に何十回も回すなら、見るべきはこの再現性の側でした。

評価基盤の選び分け：マネージド評価とOSSツールの守備範囲を比べる

クラウドの組み込み評価は、採点基準の生成と運用連携まで含み込む

Microsoft Foundryは、エージェントの名称・指示文・保有ツールから採点基準（ルーブリック）を自動生成し、それを主要な評価軸に据える方式を採っています。生成されたルーブリックは意図の認識、ツール使用の正確さ、タスク完了、伝達の明快さといった観点へ分解され、観点ごとに1から5で採点したうえで重み付き平均を0から1へ正規化する仕組みです。ドキュメント上は、タスク準拠の合格率85%といった受け入れ閾値を配置前に定める例が示されました。Python SDKはazure-ai-projectsの2.2.0以上が前提です（2026年7月時点）。

マネージド側の利点は、評価の実行だけでなく、本番トレースを評価用データセットへ変換する導線や、CIのゲートとして使うための連携が最初から揃っていることにあります。逆に制約もあり、機能によって利用できるリージョンが限られる点は設計前に確認が要ります。

OSS側の強みは、フレームワークを問わず同じ物差しで測れること

Ragasのような評価ライブラリと、Langfuseのようなトレース基盤を組み合わせる構成は、特定のクラウドに縛られません。エージェントの実装がどのフレームワークであっても、呼び出し履歴をトレースとして残せば同じ指標で採点できます。トレース基盤側の選択肢はLangfuseとは？読み方・機能・使い方とLangSmithとの違いを解説【2026年最新】で比較しました。土台となるフレームワーク自体の選定はAIエージェントフレームワークとは？主要8種の比較と受託開発視点の選定基準【2026年版】が判断材料になります。

複数のエージェントが分担して動く構成では、評価の単位を決める作業が先に来ます。系全体の達成率だけを見るとどのエージェントが足を引っ張っているか分からず、個別エージェントだけを見ると受け渡しの失敗が見えません。両方を測る前提で設計してください。構成そのものの整理はマルチエージェントとは？仕組み・構成パターンと採用判断を実装者視点で解説【2026年版】で扱っています。

どこまで自動採点へ委ね、どこに人手と本番ログを残すかを言い切る

ここが本記事の主張です。エージェント評価を自動化すべき条件は3つあります。第1に、ツールの追加や指示文の改訂を月に何度も行う運用であること。第2に、ツール呼び出しの引数と結果までトレースとして保存できていること。第3に、失敗が「呼ぶべきものを呼んだか」で説明できる領域であること。この3つが揃うなら、評価基盤への投資は改善速度として回収できます。

見送るべき場面も明確です。ツールが2〜3個しかなく分岐も浅い社内向けエージェントでは、参照軌跡を整備する工数のほうが目視より高くつきます。また、外部への送信・決済・データ削除のように取り消せない操作を含む場合、スコアが高いことは安全の証明になりません。この領域では自動評価を合否判定に使わず、人の承認を挟む設計を残したうえで、評価はレビュー対象を絞り込む前段として使ってください。

実務上の折衷案は二段構えです。全件を自動採点にかけ、軌跡またはタスク達成の指標が閾値を割った試行だけを人手レビューへ送ります。加えて、取り消せない操作を含む経路は件数にかかわらず全件レビューへ回します。閾値そのものは、失敗1件あたりの損害額から逆算して決めてください。指標は判断材料であり、判断そのものではありません。

なお、評価の設計を後から足すと、トレース取得のための改修が発生して手戻りになります。設計段階から評価と承認フローまで含めて相談したい場合はAIエージェント開発でご相談ください。

運用への組み込み：CIでの回帰検知と本番トレースからの継続評価

評価は一度回して終わりではありません。ツールを1つ足しただけで、既存の質問群で別のツールが選ばれ始める、という現象が日常的に起きます。そこで、評価セットの実行をCIへ組み込み、タスク達成率や軌跡の一致が前回比で一定以上下がったらマージを止める形にしておきます。

費用と時間の設計も要ります。エージェント評価は1件の採点でエージェント本体を実際に走らせるため、モデル評価より桁違いに時間がかかります。プルリクエスト時はコードで判定できる指標と少数のサンプルに限り、LLM判定を含む全件実行は日次バッチへ回す二層構成が現実的でしょう。再現性を見るpass^k形式の測定はさらに試行回数が倍加するため、週次など頻度を落として回す割り切りが要ります。

本番側では、参照軌跡が存在しないため、参照なしで計算できる指標へ切り替えます。ゴール達成の推定、ツール呼び出しの失敗率、ループの打ち切り発生率、1タスクあたりのトークンと所要時間を継続的に記録し、日ごとの推移で見てください。単日の値より、いつ何を変えたかという変更履歴と並べたときの段差に意味があります。外部モデルの版が更新された直後に静かに劣化する事象は、この推移でしか捕まえられません。

よくある質問

評価用のデータセットは何件から始めればよいですか？

まずは業務の代表的な経路を20〜30件から始めるのが現実的です。エージェント評価は1件あたりの実行時間が長く、いきなり数百件を組むと回す前に運用が止まります。本番で失敗した試行をトレースから拾って追加していく育て方のほうが、机上で網羅するより早く実効性が出ます。

参照軌跡（正解の手順）は誰がどう作るのですか？

業務担当者と実装者で、代表タスクごとに「呼ぶべきツールと順序」を書き出す作業になります。既に動いているエージェントがあるなら、成功した試行のトレースを人が確認して参照軌跡へ昇格させる方法が最も省力です。ゼロから全件を書き起こす必要はありません。

最終回答が正しければ、軌跡は多少ずれていても問題ないのでは？

結果が同じでも、監査や責任分界の観点では過程が問われます。確認手順を飛ばして正解に当たった試行は、次回に外れる可能性が高い不安定な成功です。軌跡の指標は、たまたま当たった成功と再現性のある成功を区別するために使ってください。

評価に使うLLMは、エージェント本体と同じモデルで構いませんか？

動作はしますが、自分の行動を自分で採点する形になり甘い方向へ寄りやすくなります。可能なら判定側は別系統のモデルを指定してください。少なくとも、判定モデルの版は比較期間中に変えないことが前提になります。

公開ベンチマークのスコアで製品を選んでも大丈夫ですか？

一次の絞り込みには使えます。ただし採点方法は版によって変わるため、版と測定時点の記載がないスコアは比較に使えません。最終判断は、自社の代表タスク20件程度で同じ条件を組んで測り直してから下してください。

関連記事

• エージェントループとは？AIエージェントが自律的に動く仕組み・ReActと終了条件の設計を実装者視点で解説【2026年版】
• AIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説【2026年版】
• AIエージェントフレームワークとは？主要8種の比較と受託開発視点の選定基準【2026年版】
• マルチエージェントとは？仕組み・構成パターンと採用判断を実装者視点で解説【2026年版】
• RAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】
• LLM-as-a-Judgeとは何か？AIモデルを評価者にする最新の自動評価手法の概要と仕組みを徹底解説
• Langfuseとは？読み方・機能・使い方とLangSmithとの違いを解説【2026年最新】