AIエージェントの評価指標とは、自律的にタスクを実行する AI エージェントや Agentic Workflow の品質・性能を定量的に測定するための基準体系です。

単純な応答精度を測る従来の AI 評価と異なり、エージェント評価ではツール呼び出しの正確さ・複数ステップにわたるタスク完了率・コストとレイテンシのバランスなど、多次元の指標を組み合わせて判断します。

本記事では、AI BPO や業務自動化の現場担当者を対象に、以下の内容を解説します。

AIが「正しい答え」を返したかどうかだけを問うなら、従来の評価手法で十分でした。しかし、複数のツールを呼び出しながら自律的にタスクを進めるエージェントが登場したことで、その前提は崩れています。

Agentic Workflow Evaluation（AWE）は、こうした自律ワークフローの品質を多角的に測るための評価体系です。単一の回答精度ではなく、ツール呼び出しの適切さ、ステップ間の連鎖、最終的なタスク完了までを一連の流れとして評価する点が従来手法との根本的な違いになります。以降では、その違いをより具体的に掘り下げながら、何をどう評価するのかを順に見ていきます。

従来の AI 評価は、主に「単一の質問に対して正しい回答を返せるか」という精度軸で設計されていました。BLEU スコアや F1 スコアによる出力テキストの照合、あるいは分類タスクの正解率がその典型です。

最初は「エージェントも同じ指標で測れる」と考えがちですが、実際には複数ステップにわたる自律的な行動シーケンスを評価しなければ、品質の実態が見えてきません。

従来評価とエージェント評価の主な違いは次の通りです。

• 評価単位: 従来は「1 入力 → 1 出力」の単一ターン。エージェントは「計画 → ツール呼び出し → 状態更新 → 次アクション」という複数ターンの軌跡（Trajectory）全体が対象
• 成功の定義: 従来は出力テキストの正確さ。エージェントは最終的なゴール達成可否（Agent Goal Accuracy）と、各ステップでのツール選択の正確さ（Tool Call Accuracy）の両面が必要
• エラーの性質: 従来は出力単体の誤り。エージェントではステップ途中の誤りが後続処理に伝播するエラー伝播が起きるため、どのステップで何が崩れたかを追跡できる評価設計が求められる
• 評価者の役割: 従来は人手レビューや参照テキストとの照合で完結するケースが多い。エージェントでは LLM-as-a-Judge（NVIDIA の推奨では 70B パラメータ以上）を組み合わせた自動評価が現実的な選択肢になっている

このように、評価の「粒度」と「時間軸」が根本的に異なります。

翻訳や分類、要約といった従来の単一タスク AI は、「入力 → 出力」の 1 ステップで完結します。だからこそ、精度や F1 スコアといった静的な指標で十分に評価できました。ところが自律ワークフローでは、エージェントが複数のツールを呼び出しながら中間結果を判断し、次のステップを自ら決定していきます。この「連鎖的な意思決定」が、既存の指標では対応しきれない根本的な理由です。

たとえばエラーの伝播を考えてみてください。ステップ 2 での判断ミスがステップ 5 の出力を静かに壊していても、最終出力だけを眺めていては原因にたどり着けません。また、10 ステップ中 9 ステップが正解でも最後の 1 ステップで失敗すれば、単純な二値評価は「失敗」とだけ記録します。途中の積み上げが一切反映されない評価は、改善の手がかりをほとんど与えてくれません。さらに、正しいツールを正しい引数で呼び出せているかどうかは、最終回答の正誤とは独立して確認する必要があります。加えて、同じプロンプトでも実行パスが変わる非決定性があるため、1 回の評価で結論を出すのではなく、複数回の統計的な評価が求められます。

評価設計の方向性は、タスクの性質によって変わります。エージェントが最初から最後まで判断する完全自律型であれば、Goal Accuracy や Task Completion Rate を中心に据えるのが適切です。一方、人間との協調型（Human-in-the-Loop）であれば、最終精度よりもハンドオフのタイミングや引き継ぎ品質を重視する設計が有効になります。

「どのエージェントから評価すればよいのか」と迷う現場担当者は少なくありません。エージェントの種類によって評価すべき指標が大きく異なるため、まず対象を整理することが重要です。

代表的なエージェントの種類は以下の通りです。

• シングルターン完結型エージェント: 1 回の入力に対して 1 つの回答を返すシンプルな構成。RAG チャットボットや FAQ 応答ボットが典型例で、Answer Accuracy や Topic Adherence を主な評価軸とします。
• マルチステップ・ツール使用型エージェント: 外部 API やデータベースを複数回呼び出しながらタスクを完遂するタイプ。Tool Call Accuracy や Trajectory Evaluation が重要になります。IBM が列挙する Policy Adherence Rate も、このタイプで特に意味を持ちます。
• マルチエージェント協調型: オーケストレーターと複数のサブエージェントが連携して動作する構成。エージェント間のハンドオフ品質が品質全体を左右するため、Agent Handoff F1-Score（HF1）のような指標が必要になります。
• ヒューマン・イン・ザ・ループ型: 判断の一部を人間に委ねる設計で、AI BPO 現場でよく採用されます。自動評価だけでは測れないエスカレーション適切率や応答遅延も評価対象に含める必要があります。

評価の設計に着手したはいいが、途中で「そもそも何を測りたかったのか」が曖昧になってしまう——そんな経験はないだろうか。原因のほとんどは、走り出す前の準備不足にある。

具体的には、何を測るかのスコープ定義、比較基準となるテストデータ、そして実行ログの収集基盤という3つの土台を先に整えておくことが、評価の精度を左右する。それぞれの準備内容については、以降のセクションで順に解説していく。

「とりあえず全機能を評価しよう」と考えがちですが、実際はスコープを絞り込んで優先度の高いワークフローから着手するほうが、改善サイクルが速く回ります。

評価を始める前にまず問うべきは、「何のためにエージェントを評価するのか」という目的の明確化です。品質保証なのか、リリース判断なのか、継続的な性能監視なのかによって、測定すべき指標も評価頻度も変わります。

スコープ設定で確認すべき観点

• 対象ワークフローの範囲: 単一ツール呼び出しか、複数エージェントが連携するマルチステップかを明確にする
• ユーザー・業務への影響度: 失敗時のリスクが高い業務（請求処理・顧客対応など）を優先評価対象に設定する
• 評価の粒度: エンドツーエンドのタスク完了を見るのか、個々のツール呼び出し精度を見るのかを区別する

ゴール設定で決めること

• 合格・不合格を判定する閾値（例: ServiceNow の定義では Overall task completeness が 90〜100% を Excellent、70〜89% を Good とするなど、業界標準を参考に自社基準を設ける）
• 評価サイクルの頻度（デプロイごと・週次・月次）
• 評価結果の責任者と意思決定フロー

スコープとゴールが曖昧なまま評価を開始すると、膨大なログが集まっても「どこを直すべきか」が見えにくくなります。最初に 1〜2 本の代表的なワークフローを選び、そこで評価プロセス全体を試行することで、後続のワークフローへの展開がスムーズになります。

評価の精度は、テストデータの質とベースライン設定によってほぼ決まります。どれほど優れた評価指標を用意しても、データが偏っていれば結果は実態を反映しません。

テストデータを設計する際は、以下の 3 種類を揃えることが推奨されています。

• ハッピーパス: 正常系の入力でエージェントが期待通りに動作するシナリオ
• エッジケース: 曖昧な指示・不完全な情報・ツール呼び出し失敗など、例外的な入力
• リグレッションケース: 過去に発生した障害や誤動作を再現するシナリオ

この 3 種類をバランスよく含めることで、成功率の過大評価を防げます。

ベースラインの設定方法は、エージェントの開発フェーズによって異なります。開発初期であれば人間オペレーターの処理ログや既存ルールベースシステムの実績をベースラインとして使用し、本番稼働後は直前バージョンのエージェントのスコアをベースラインとするのが現実的です。比較対象が変わると改善幅の解釈が変わるため、ベースラインは一度設定したら評価サイクルをまたいで固定することが重要です。

データ量については、タスク種別ごとに最低でも数十件以上のサンプルを確保することが望ましいとされています。サンプルが少ない場合、Agent Goal Accuracy のような二値スコアでは統計的なばらつきが大きくなり、改善効果の判断が困難になります。

また、テストデータには本番データに近い分布を持たせることが重要です。

「どのステップで失敗したのか、ログを見ても何もわからない」という経験は、エージェント評価の現場でよく聞かれます。評価指標を設計する前に、まず観測できる状態を作ることが不可欠です。

エージェントは複数のツール呼び出しや LLM 推論を連鎖させるため、単純なリクエスト／レスポンスのログだけでは品質の原因追跡が困難です。必要なのは、各ステップの入出力・ツール呼び出し結果・所要時間を一本の「トレース」として紐づける仕組みです。

整備すべき主な要素は以下の通りです。

• 分散トレーシング: 各エージェントステップに一意のトレース ID を付与し、ステップ間の親子関係を記録する
• ツール呼び出しログ: ツール名・入力パラメータ・返却値・成否フラグを構造化ログとして保存する
• LLM 推論ログ: プロンプト全文・モデル出力・トークン数・レイテンシを記録し、後から再現できる状態にする
• エラー分類タグ: タイムアウト・ツール失敗・不正出力など、エラー種別をタグで分類して集計しやすくする

ログの粒度はコストとトレードオフになります。本番環境ではサンプリング率を調整しつつ、失敗トレースは全件保存する方針が現実的です。

結論: エージェント成功率の測定には、タスク完了率・ステップ精度・コスト効率など複数の指標を組み合わせる必要があります。

単一の数値だけでは自律ワークフローの品質は見えてきません。次の H3 では各指標の定義と計測方法を順に解説します。

エージェントの評価に初めて取り組む現場では、「タスクが完了したかどうか」を二値（成功/失敗）で判定しようとしがちです。しかし実際には、途中ステップまで正しく実行できているケースを「失敗」と一括りにすると、改善の手がかりを見失います。部分完了率を合わせて計測するほうが、ボトルネックを特定しやすくなります。

タスク完了率（Task Success Rate / TSR） は、エージェントが最終ゴールを達成したシナリオの割合を指します。ServiceNow の評価体系では、Overall task completeness のスコアを「3: Successful / 2: Partially successful / 1: Unsuccessful」の三段階で記録し、Excellent（90〜100%）から Poor（0〜49%）までのラベルで管理します。

部分完了率 は、このうち「Partially successful」に相当するケースの比率です。主な計測ポイントは以下のとおりです。

• 全テストシナリオ数に対して「部分完了」と判定されたシナリオの割合を算出する
• 部分完了が多い場合、どのステップで処理が止まったかをトレースログで確認する
• 部分完了率が高止まりしているときは、ツール呼び出しの失敗やコンテキスト欠落が原因であるケースが多い

二つの指標を組み合わせると、「完了率は低いが部分完了率は高い」という状態が見えてきます。

エージェントが複数ステップを連鎖させる場合、タスク全体の成否は「各ステップが正しく実行されたか」に直結します。そこで注目されるのがステップ精度（Step Accuracy）とエラー伝播率の二指標です。

ステップ精度とは、エージェントが実行した個々のアクション（ツール呼び出し・判断分岐・データ抽出など）のうち、期待通りに完了したステップの割合を指します。NVIDIA NeMo の Trajectory Evaluation や Tool Call Accuracy はこの考え方を基盤としており、各ステップの正誤を0〜1のスコアで記録します。

エラー伝播率は、上流ステップの誤りが下流に波及する度合いを示します。たとえば請求書処理ワークフローで「金額抽出ステップ」が誤れば、後続の「承認ルーティング」「会計仕訳」も連鎖して失敗するケースが報告されています。エラーが伝播するほど修正コストは指数的に増大するため、ステップ精度と組み合わせた監視が重要です。

判断軸としては次のように整理できます。

• ステップ数が少ない（3〜5 ステップ以内）場合は、タスク完了率だけで品質を把握できることが多い
• ステップ数が多い・分岐が複雑な場合は、ステップ精度とエラー伝播率を別途計測し、どのステップで誤りが発生しやすいかをピンポイントで特定する

改善サイクルでは、エラー伝播率が高いステップを「クリティカルノード」として優先的にログを取得し、プロンプト修正やツール設計の見直しに反映させます。

「このエージェント、精度は高いのにコストが膨らんで本番に出せない」という状況は、現場でよく耳にします。精度指標だけを追っていると、レイテンシやコストの問題が後から顕在化するため、これらは成功率と並行して計測することが重要です。

レイテンシの主な計測ポイント

• エンドツーエンドレイテンシ: ユーザーリクエスト受信から最終応答返却までの総所要時間
• ステップ別レイテンシ: LLM 推論・ツール呼び出し・外部 API 待機を分解して記録する
• P95 / P99 パーセンタイル: 平均値だけでなく外れ値を捉えることで、遅延スパイクの頻度を把握できる

ステップ別に分解することで、「LLM 推論が遅いのか、外部ツールの応答待ちが遅いのか」というボトルネックの切り分けが可能になります。

コスト効率の計測ポイント

• タスクあたりトークンコスト: 1 タスク完了に消費した入出力トークン数をログから集計する
• ツール呼び出し回数: 不要なループや重複呼び出しがないかを確認する
• コスト対成果比（Cost per Successful Task）: IBM が列挙する代表指標の一つである Cost を、タスク成功件数で割ることで費用対効果を定量化できる

計測の実践ポイント

レイテンシとコストは、トレーシング基盤にスパン単位のタイムスタンプとトークン使用量を記録することで一元管理できます。

結論: 品質評価は「シナリオテスト → 人間評価・LLM-as-a-Judge → 継続的モニタリング」の3ステップで体系化できる。

評価指標を定義したら、次は実際の評価プロセスを設計する必要があります。以下の各ステップで、機能確認から本番監視まで段階的に品質を担保する方法を解説します。

最初は「できるだけ多くのランダムな入力でテストすれば網羅性が高まる」と考えがちですが、実際はゴールから逆算したシナリオを先に設計するほうが、問題の早期発見につながります。

シナリオテストでは、エージェントが実際に担う業務フローを「正常系」「異常系」「境界値系」の 3 カテゴリに分けて用意します。

• 正常系: 想定どおりの入力でタスクが最後まで完了するか
• 異常系: 必須パラメータの欠落・ツール呼び出し失敗など、エラー条件下で適切に処理できるか
• 境界値系: 入力が曖昧・複数ゴールが競合するなど、エッジケースで誤ったツールを選択しないか

各シナリオには「期待するツール呼び出し列」と「最終アウトプット」の両方を定義しておくことが重要です。IBM が列挙する主要指標のうち、Success rate / task completion と Error rate はこの段階で直接測定できます。

テスト実行後は、以下の観点でスコアを集計します。

1. シナリオ単位の合否（Pass / Fail）
2. ツール呼び出しの精度（正しいツールを正しい順序で呼んだか）
3. エラー発生時のリカバリー動作の有無

NVIDIA NeMo の Tool Call Accuracy や Trajectory Evaluation はこの集計と対応しており、スコア範囲 0.0〜1.0 で定量比較が可能です。

シナリオテストで機能面の合否が確認できたら、次は「どれだけ自然で的確な応答・行動だったか」という品質面の評価に移ります。ここで現場がよく直面するのが、「自動化したいけど精度が不安」というジレンマです。そのバランスを取るために広く使われているのが、人間評価とLLM-as-a-Judgeを組み合わせるアプローチです。

使い分けの基本的な考え方はシンプルで、出力の正誤が明確に定義できるかどうかで判断します。ツール呼び出しの正確性やタスク完了の二値判定のように答えが一意に決まるものはLLM-as-a-Judgeで自動スコアリングし、回答の自然さ・倫理的妥当性・ビジネス文脈への適合度といった判断基準が曖昧なものは人間評価を優先します。

LLM-as-a-Judgeを使う際は、Judge LLMのモデルサイズが評価精度に直結する点に注意が必要です。NVIDIA NeMoのAgent Goal Accuracyでは70Bパラメータ以上、推奨では405B超のモデルを使うと精度が高まる傾向があります。Tool Call AccuracyやTopic Adherenceのように0.0〜1.0のスコアで返るメトリクスは自動採点との相性がよく、評価プロンプトに採点基準（ルーブリック）を明示しておくことでスコアの再現性も確保できます。

一方、全件を人間が評価するのはコストの面で現実的でないことが多いです。そのため実務では、LLM-as-a-Judgeでスコアが低いサンプルや境界値付近のサンプルを優先的に人間レビューに回す運用が定着しています。レビュアーには評価軸と具体例を事前に共有しておくと、評価者間のばらつきを抑えやすくなります。

この二段構えによって、スケーラビリティと評価精度を両立できます。

「シナリオテストで合格したのに、本番稼働後に誰も異常に気づかなかった」——そうした事態を防ぐのが継続的モニタリングの役割です。

一回限りの評価では、モデルの挙動ドリフトや外部 API の仕様変更など、時間軸で起きる劣化を捉えられません。本番環境でのリアルタイム観測を仕組み化することが、エージェント品質を維持する上で不可欠です。

モニタリングで追うべき主要指標

• タスク完了率の推移: ServiceNow の閾値を参考にすると、Excellent（90%以上）を維持できているかを週次で確認する
• ツール呼び出し成功率: Tool Call Accuracy が低下し始めたら、外部 API や内部ツールの仕様変更を疑う
• レイテンシ・コスト: 平均応答時間やトークン消費量が基準値から一定割合を超えた場合にアラートを発火させる
• エラー率: 想定外の例外やタスク中断が急増していないかをリアルタイムで監視する

アラート設定の考え方

アラートは「静的閾値」と「変化率閾値」の 2 層で設計するのが効果的です。

• 静的閾値: タスク完了率が 70% を下回ったら即時通知
• 変化率閾値: 前週比でエラー率が 20% 以上悪化したら警告

Amazon Bedrock AgentCore Evaluations のようなマネージドサービスを活用すると、ログ収集からアラート発火までのパイプラインを短期間で構築できます。

評価指標を導入したのに、なぜか現場が改善されない——そういう話は珍しくありません。原因を掘り下げると、たいてい指標の選び方か、評価環境の設定に問題が潜んでいます。「測っているのに何も変わらない」という状態は、測る対象がズレているサインだと考えると分かりやすいでしょう。AI BPOの現場でよく見かける失敗パターンを把握しておくことが、評価サイクルの精度を上げるうえで近道になります。

「タスク完了率が高ければ品質は問題ない」と判断しがちだが、実際には単一指標だけでは見えないリスクが蓄積しやすい。

エージェント評価でよく起きる失敗の一つが、特定の指標だけを追いかけてしまうパターンです。たとえばタスク完了率（Task Completion Rate）を唯一のKPIとして設定した場合、以下のような盲点が生じます。

• ステップの質が見えない: 最終的にタスクが「完了」と判定されても、途中で不要なツール呼び出しが発生していたり、エラーを自己修正した痕跡が残っていたりするケースがあります
• コストとレイテンシが無視される: 完了率が高くても、1タスクあたりのLLM呼び出し回数やコストが許容範囲を超えていれば、本番運用には耐えられません
• ポリシー逸脱が隠れる: IBMが指摘するPolicy adherence rateのように、社内ルールや法令への準拠状況は完了率には反映されません

ServiceNowの評価フレームワークでは、Overall task completenessとTool performance recordを別軸で記録することが推奨されています。これは「完了したかどうか」と「正しいツールを使ったかどうか」を切り離して評価するためです。

改善のためには、最低でも以下の3軸をセットで追跡することが望ましいです。

1. 成果指標: タスク完了率・部分完了率
2. プロセス指標: ツール呼び出し精度・ステップ数

テスト環境で高スコアを記録したエージェントが、本番投入後に急激にパフォーマンスを落とすことがあります。この「ギャップ問題」は、評価設計の段階で見落とされやすい落とし穴のひとつです。

原因はおおむね三つの層に分かれます。まず入力分布のズレで、テストデータは整形済みのシナリオが中心になりがちなため、本番で発生する曖昧な指示・誤字・口語表現に対応できていないケースが多いです。次にツール・APIの状態差で、テスト環境では常に正常レスポンスを返すモックを使っている一方、本番では外部APIのタイムアウトや仕様変更が突然発生します。そして三つ目がコンテキスト長の違いで、実運用では会話履歴が長くなるにつれ、テスト時には現れなかったコンテキスト溢れによるエラーが顕在化してきます。

対処の判断軸は、ギャップの発生源によって変わってきます。入力分布のズレが原因であればテストデータへのリアルサンプル混入率を高めることが優先事項となり、ツールや外部依存の問題であればカオスエンジニアリング的な障害注入テストを評価フローに組み込む方が効果的です。

実践的な手として有効なのが、本番ログの一部をサンプリングして定期的にテストセットへ還流させる「ライブデータフィードバックループ」です。現実の入力パターンに評価シナリオが自然と追従していくため、スコアと実態のズレが縮まりやすくなります。あわせて、本番環境に近いステージング環境を用意し、外部APIとの実接続テストを評価プロセスに含めておくと、ギャップをさらに絞り込めます。

テスト環境のスコアだけを改善指標として追い続けると、本番品質の実態を見誤るリスクがあります。スコアはあくまで「テスト上の成績」であり、本番との距離を意識した設計なしには、その数字は安心材料になりません。

数字が出たとき、「スコアが低いな」と眺めて終わってしまうケースは少なくありません。しかし評価結果の本当の価値は、そこから何を変えるかにあります。

まず着目すべきは「どのステップで失敗が集中しているか」というボトルネックの特定です。タスク成功率が全体的に低い場合と、特定のツール呼び出しだけで失敗が頻発している場合とでは、打ち手がまったく異なります。前者はプロンプトの指示設計そのものを見直す必要があり、後者はツールのインターフェース定義や入出力スキーマの問題である可能性が高いです。

ボトルネックが絞り込めたら、変更は一度に一箇所に留めるのが原則です。複数の修正を同時に加えると、どの変更がスコアを動かしたのか判断できなくなります。プロンプトを変えたなら、ツール設計はそのまま維持して再評価します。この地道な一変数ずつの検証が、サイクルを回すうえでの土台になります。

改善を実装したら、同じ評価セットで必ず再測定します。スコアが改善した場合も、他の指標が意図せず悪化していないかを確認することが重要です。たとえばレイテンシを下げようとしてツール呼び出し回数を削減したら、タスク達成率が落ちた、というトレードオフは実際に起こりやすいです。評価指標を単一の数字で見るのではなく、複数指標をセットで追うことで、こうした副作用を早期に捉えられます。

評価結果は、パイプライン全体の「どこで詰まっているか」を示す地図のようなものです。スコアの低いステップを見つけたら、まずそこを重点的に掘り下げるのが改善の基本です。

ボトルネック特定の手順

• トレースログを確認する: ステップ別の成功率・レイテンシ・エラー種別をステップ単位で並べ、スコアが急落している箇所を探す
• エラー分類を行う: ツール呼び出し失敗・ハルシネーション・ループ離脱不能など、エラーの種類ごとに件数を集計する
• 再現テストを実施する: 失敗シナリオを最小単位で再現し、原因がプロンプトなのかツール設計なのかを切り分ける

ボトルネックの原因がプロンプトにあると判断できたら、次のアプローチが有効です。

プロンプト改善の主なアプローチ

• 指示の粒度を調整する: 曖昧な指示を具体的なステップ記述に変えると、ツール選択の誤りが減少する傾向があります
• コンテキスト長を見直す: 不要な情報を削り、エージェントが参照すべき情報を絞り込む。詳しくは コンテキスト・エンジニアリング入門｜プロンプト設計の次のステップ も参考になります
• Few-shot 例を追加する: 失敗パターンに対応する正解例をプロンプトに組み込み、判断精度を高める

改善後は必ず同じテストシナリオで再評価し、スコアの変化を数値で確認してください。

プロンプト改善で解消できなかった問題が残る場合、次の打ち手はファインチューニングとツール設計の見直しになります。ただし、最初から「ファインチューニングすれば精度が上がる」と考えるのは早計で、実際にはツール設計の不備が原因であるケースが多いです。まずそちらを疑うほうが効果的です。

ファインチューニングが有効なのは、特定ドメインの語彙・文体に繰り返し失敗する場合、プロンプトだけでは出力フォーマットが安定しない場合、あるいはTool Call Accuracyのスコアが継続的に低い場合など、限定的な状況に絞られます。

一方、ツール呼び出しの引数定義が曖昧だったり、返り値のスキーマが不統一だったりする場合は、ファインチューニングより先にツール仕様を整備するべきです。高コストな学習を走らせる前に、ツール設計の見直しポイントを一つひとつ確認していきます。

Q1. AIエージェントの評価指標は、従来のチャットボット評価と何が違うのですか？

従来のチャットボット評価は、1 回の応答の正確さ（回答精度・BLEU スコア等）を測ることが中心でした。一方、AIエージェントの評価では、複数ステップにまたがるタスク全体の完了率や、ツール呼び出しの正確さ（Tool Call Accuracy）、目標達成の有無（Agent Goal Accuracy）など、一連の自律的な行動の連鎖を評価します。単一ターンではなく、プロセス全体の品質を問う点が本質的な違いです。

Q2. エージェント成功率（Agentic Success Rate）とタスク完了率（Task Success Rate）は何が異なりますか？

タスク完了率（TSR）は「最終的にタスクが完了したか否か」を二値で判定する指標です。これに対して Agentic Success Rate（ASR）は、エージェントが途中でどのような状態遷移を経たかも考慮し、Transition Recall と Transition Precision に分解して評価します。TSR だけでは「たまたま正解にたどり着いたが、途中のステップが非効率だった」ケースを見逃しやすいため、ASR を組み合わせることでプロセス品質まで把握できます。

Q3. 評価に使う Judge LLM はどのくらいの規模が必要ですか？

NVIDIA NeMo の公式ドキュメントによると、Judge LLM には少なくとも 70B パラメータのモデルが必要とされており、405B パラメータ超のモデルが推奨されています。小規模モデルを Judge に使うと、微妙なニュアンスの判定精度が低下し、評価結果そのものの信頼性が損なわれる傾向があります。コスト制約がある場合は、重要度の高いシナリオのみ大規模 Judge LLM を使い、それ以外はルールベース評価と組み合わせる運用が現実的です。

Q4. ServiceNow の Overall Task Completeness スコアはどのように解釈すればよいですか？

ServiceNow の定義では、Overall Task Completeness のスコアは 3（Successful）・2（Partially successful）・1（Unsuccessful）の 3 段階で記録されます。また、達成率のラベルとして Excellent（90〜100%）・Good（70〜89%）・Moderate（50〜69%）・Poor（0〜49%）が設定されています。本番運用では Good 以上を最低ラインとして設定し、Moderate 以下のシナリオを優先的に改善対象とする運用が一般的です。

Q5. 評価指標を整備しても改善につながらない場合、どこを見直すべきですか？

指標を測っても改善が進まない場合、多くのケースでは「指標の粒度が粗すぎてボトルネックが特定できていない」ことが原因です。まず、タスク完了率のような集計値だけでなく、ステップごとのエラー伝播率やツール呼び出し精度など細粒度の指標を追加します。次に、失敗シナリオのトレースログを精査し、プロンプト設計・ツール定義・外部 API の応答品質のどこに問題があるかを切り分けます。コンテキスト・エンジニアリング入門｜プロンプト設計の次のステップも改善の参考になります。