「PoCは成功しました。タスク完了率は85%です」——ベンダーからこのような成果報告を受けたとき、あなたはその数字を根拠に本番移行のGO判断ができるでしょうか。多くの発注者は、この85%という数字を前にして「良いのか悪いのか判断できない」と足踏みしています。
問題は、AIエージェントが従来のAIシステムとは根本的に異なる仕組みで動いている点にあります。単純な入力と出力のペアで正解・不正解が判定できた分類モデルや、テキストの流暢さで品質を測れたLLM単体とは違い、AIエージェントは自分でツールを選び、外部APIを呼び出し、その結果を見て次の行動を決めるという自律的な連鎖動作をおこないます。「タスク成功率85%」という一つの数字だけでは、途中で余計なAPI呼び出しを繰り返してコストを浪費していないか、危険な操作を勝手に実行していないか、同じ入力で再実行しても再現できるか——といった本番稼働で本当に重要な観点が見えないのです。
そこで本記事では、AIエージェント特有の評価指標を「発注者・PoC判定者の視点」から体系的に整理します。タスク完了率、ツール呼び出し精度、トラジェクトリ評価、コスト効率、安全性・信頼性など、押さえるべき7つの指標を一つずつ解説し、最後にPoC検収時にベンダー報告書へ含めるよう要求すべき数字リストと、本番移行判定の稟議書に書くGO条件テンプレートを提供します。読み終えたときには、ベンダーに「これとこれを数値で出してほしい」と具体的に指示できる語彙が身につき、稟議書に自信を持って判定条件を記載できる状態を目指します。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
AIエージェントの評価指標が「従来のAI評価」と何が違うのか
まず前提として、AIエージェントの評価が「なぜ従来のAI評価では不十分なのか」を整理します。ここを理解しないまま個別指標の話に入っても、「結局どの数字を見ればいいの？」という混乱が残ります。一般的なAI評価指標（正解率・F値・BLEU・ROUGEなど）の基礎については、当社の別記事AIの評価指標を発注者向けに解説でも解説していますので、あわせて参照してください。
従来のAIモデルは「入力→出力の一発判定」だから評価が単純
従来の機械学習モデル、たとえば「メールがスパムかどうか判定する分類モデル」や「顧客が離反するかを予測する回帰モデル」は、入力と出力が一対一で対応しています。あるメール本文（入力）に対して「スパム」または「非スパム」という判定（出力）が返り、その判定が正解ラベルと合っているかを比べれば評価は完了します。指標としては正解率・適合率・再現率・F値などが定番です。
LLM単体の場合も、評価対象は「与えたプロンプトに対する回答テキストの品質」であり、BLEU・ROUGEなどの類似度指標や、人間評価やLLM-as-a-Judgeによる主観評価で品質を測ります。ここでも「一つの入力に対して一つの出力を評価する」という構造は保たれています。
AIエージェントは「ツールを選ぶ→実行する→結果を見て次を決める」の連続だから軌跡ごと評価する必要がある
一方、AIエージェントは根本的に構造が異なります。たとえば「先月の売上データを取得して、前年同月比を計算し、Slackで営業部長に共有する」というタスクを与えられたエージェントは、次のような複数ステップの意思決定を自律的におこないます。
- 「売上データを取得する必要がある」と判断し、社内BIツールAPIを呼び出す
- 取得したデータの粒度が違うと気づき、別のクエリで再取得する
- 前年同月のデータも必要と判断し、追加でAPIを呼ぶ
- 計算結果を整形し、Slack APIで指定チャンネルに投稿する
ここでの評価対象は、最終的な投稿結果だけではありません。「正しいAPIを選んだか」「正しい引数で呼んだか」「必要以上に何度も呼び直していないか」「途中で危険な操作をしていないか」——といった軌跡（トラジェクトリ）そのものが評価対象になります。これは、Google CloudのVertex AI 生成AIエージェント評価ドキュメントでも「最終的な回答」と「軌跡（trajectory）」を分けて評価する仕組みが提供されていることからも分かります。
だから「タスク成功率だけ」のPoC報告書は情報不足の可能性が高い
以上を踏まえると、ベンダーから受け取った「タスク完了率85%」という報告は、氷山の一角に過ぎない可能性が高いといえます。仮に85%完了していても、残りの15%が「取り返しのつかない誤操作」で失敗しているのか、「たまたま外部APIが応答遅延しただけ」なのかで、意味はまったく異なります。また完了した85%のなかにも、「余計なAPIを10回叩いた末に完了した」ケースが混在していれば、本番稼働時のコストは想定の何倍にも膨らみます。
つまり、PoC報告書に「タスク成功率」しか記載されていない場合、その報告書は本番移行判定の材料としては情報不足だと判断すべきです。次章から、押さえるべき評価の全体像を4つの視点で整理します。
AIエージェント評価の4つの視点
AIエージェントの評価は、次の4つの視点で全体像を捉えると整理しやすくなります。それぞれの視点は独立した評価軸であり、すべてを見ないと本番稼働の妥当性は判断できません。
視点1 最終アウトカム系（タスクをそもそも完了できたか）
最も基本となる視点で、「与えたタスクを最終的に完了できたか」を測ります。代表指標はタスク完了率（Task Completion Rate）と、完了した回答の品質評価（回答品質スコア）です。ベンダー報告書に載っているのはたいていこの指標であり、多くのPoCがここまでで評価を止めてしまいます。
視点2 途中プロセス系（正しい道筋で完了したか）
エージェント特有の視点で、「正しい道筋で完了したか」を測ります。トラジェクトリ評価、ツール呼び出し精度、ステップ効率などが該当します。最終的にタスクが完了していても、途中で誤ったAPIを呼んで人間の手動リカバリが入っていたり、必要なステップを大幅に上回るリトライを繰り返していたりする可能性があるため、視点1だけでは見えない品質を可視化します。
視点3 運用コスト系（本番稼働で耐えうるか）
本番稼働時の運用コストが持続可能かを測る視点です。1タスクあたりのトークン消費、API呼び出し回数、レイテンシ（応答時間）などが該当します。PoCではデータ量が少なく気づきにくいのですが、本番で1日数千件のタスクをこなす想定なら、1タスクあたり数十円のコスト差が月次で数十万円の差に膨れ上がります。
視点4 安全性・信頼性系（危険な動きをしていないか）
エージェントが自律的に動く以上、避けて通れない視点です。人間承認が必要な操作を勝手にやってしまう誤実行率、不明な状況で暴走せず「分かりません」と止まれる停止判断能力、同じ入力で同じ結果が出る再現性などが該当します。本番稼働では「うまくいく確率」よりも「取り返しのつかない失敗を起こさない確率」のほうが重要になるケースが多く、この視点を軽視すると重大インシデントにつながります。
以降の章では、これら4視点のそれぞれを深掘りしていきます。
最終アウトカム系の指標——タスク完了率と回答品質
視点1の最終アウトカム系は、ベンダー報告書で最もよく見る指標群ですが、実は「定義次第で数字が大きく変わる」落とし穴があります。
タスク完了率の定義次第で数字は大きく変わる（「何をもって完了とするか」の落とし穴）
「タスク完了率85%」という報告を受けたとき、まず確認すべきは「完了の定義」です。同じタスクでも、次のように定義が異なれば数字はまったく別物になります。
- 定義A: エージェントが「タスクを完了した」と自己申告した割合（自己申告ベース）
- 定義B: 最終出力が期待通りの形式で返ってきた割合（形式チェックベース）
- 定義C: 最終出力の内容が業務要件を満たしていた割合（内容チェックベース）
- 定義D: 上記に加え、途中の副作用（誤送信・データ破損等）が発生しなかった割合（副作用込み判定）
同じタスクを100件流したとき、定義AだとPoCで95%だが、定義Dで測ると60%まで落ちる、というケースは珍しくありません。ベンダーが「85%完了」と報告してきたら、どの定義で測ったのかを必ず確認してください。副作用込みで判定していないなら、その85%は本番投入の判断材料としては弱いと考えるべきです。
回答品質はLLM-as-a-Judgeが主流だが人間評価と併用する
回答品質の評価には、近年LLM-as-a-Judge（大規模言語モデルを評価者として使う手法）が主流となっています。あらかじめ定めた評価観点（正確性・網羅性・簡潔さなど）に基づいて、別のLLMがエージェントの回答を採点する仕組みです。Anthropicの公式ブログでもエージェント評価における自動評価の重要性が言及されており、開発現場で広く使われています。
ただしLLM-as-a-Judgeには「評価者LLM自体のバイアス」や「主観的な観点で採点がぶれる」といった限界があります。発注者としては、ベンダーが100%LLM-as-a-Judgeで評価しているなら、「サンプル数十件でよいので人間評価（社内SME評価）とスコアが一致しているかを検証してほしい」と要求すべきです。
発注者がベンダーに確認すべきこと（完了の定義・評価者の内訳）
本セクションの内容を踏まえ、発注者がベンダーに確認すべき最低限の項目をまとめます。
- タスク完了の定義は上記A〜Dのどれか（副作用込みで測っているか）
- 回答品質の評価方法（LLM-as-a-Judge / 人間評価 / 併用）とその比率
- 人間評価がある場合、評価者の職種・人数・評価観点の定義書
- サンプルサイズ（何件のタスクで測定したか）と、業務ユースケース全体をカバーする代表性
途中プロセス系の指標——トラジェクトリ・ツール呼び出し精度・ステップ効率
ここが本記事で最も重要な章です。競合記事の多くはタスク完了率を中心に据えていますが、AIエージェントの本質的な品質を測るには、途中プロセスを見なければ話になりません。
トラジェクトリ評価とは——最終回答ではなく「軌跡」を評価する
トラジェクトリ評価（Trajectory Evaluation）とは、エージェントが「どのような思考と行動の連鎖を経て最終回答に至ったか」を評価する手法です。たとえば「先ほどの売上集計タスク」で言えば、「BIツールAPI呼び出し→データ取得→フォーマット判断→Slack投稿」という一連の軌跡が期待通りかどうかを検証します。
先ほど参照したVertex AI のエージェント評価ドキュメントでは、トラジェクトリ評価の観点として次のような指標が定義されています。
- 完全一致（Exact Match）: 期待した軌跡と完全に同じか
- 順序一致（In-Order Match）: 期待したステップが順序通りに含まれるか
- どんな順序でも一致（Any-Order Match）: 期待したステップが順序を問わず含まれるか
- 精度（Precision）と再現率（Recall）: 期待したステップと実際のステップの過不足を評価
発注者としては、少なくとも「順序一致率」と「余計なステップの有無」の2点はベンダーに数値で報告してもらうべきです。
ツール呼び出し精度——正しいAPIを正しい引数で呼べたか
ツール呼び出し精度（Tool Call Accuracy）は、エージェントが提供された関数・APIのなかから「正しいものを、正しい引数で」呼び出せたかを評価します。この指標を測るための代表的な公開ベンチマークがBerkeley Function-Calling Leaderboard（BFCL）で、各モデルのツール呼び出し能力を比較できます。
発注者視点では、ツール呼び出し精度は次のような観点で分解して見るのがおすすめです。
- API選択精度: 適切なAPIを選べた割合（誤ったAPIを呼んだ回数）
- 引数指定精度: 引数の型・値・必須項目が正しかった割合
- 多段呼び出しの整合性: 前のAPIの出力を次のAPIの入力に正しく引き渡せた割合
たとえば「顧客IDを取得して請求書を送るタスク」で、顧客IDを間違ったフォーマットで請求書APIに渡してしまえば、タスクは失敗します。BFCL のようなベンチマークスコアだけでなく、自社の業務APIを対象にした呼び出し精度を測ってもらうことが重要です。
ステップ効率——タスクは完了したが余計な動きをしていないか
ステップ効率は「最短経路と比較して余計なステップが多くないか」を評価します。同じ「売上集計を通知する」タスクでも、A社のエージェントは3ステップで完了し、B社のエージェントは12ステップかけて完了する——というケースがあります。B社の12ステップのうち9ステップが試行錯誤による再実行なら、本番稼働時のAPIコストと応答時間は3倍以上になります。
代表的なステップ効率指標は次の通りです。
- 平均ステップ数: 1タスクあたりの平均ステップ数
- 最短経路との比較: 期待経路のステップ数に対する実際の比率
- リトライ率: 同一APIを短時間に繰り返し呼んだ割合
「ベンダー報告書にステップ効率が載っていない場合、平均ステップ数と最短経路との比率を追加で報告してほしい」と要求するのが安全です。
補足: Agent-as-a-Judgeという新しい評価アプローチ
近年、Agent-as-a-Judgeという新しい評価アプローチも登場しています。これは「別のAIエージェントを使って評価対象エージェントの軌跡を採点する」手法で、LLM-as-a-Judgeが「最終回答の品質」を評価するのに対し、Agent-as-a-Judgeは「軌跡全体の妥当性」を評価します。
現時点では研究段階の色合いが強く、業務PoCで採用しているベンダーは少数派ですが、大規模なエージェントシステムを本番運用するフェーズでは今後標準になっていく可能性があります。ベンダーの技術動向を見る観点として、「Agent-as-a-Judgeへの取り組みはあるか」を質問してみるのもよいでしょう。
運用コスト系・安全性系の指標——本番稼働で耐えうるか
視点3と視点4は、PoC段階では見過ごされがちですが、本番移行判定では絶対に外せない領域です。
運用コスト系（トークン消費・レイテンシ・API呼び出し回数）
運用コスト系の主要指標は次の3つです。
- 1タスクあたりトークン消費: LLM APIの課金基準となる入力・出力トークンの合計。GPT-4系・Claude系ともに、入力トークンと出力トークンで単価が異なるため両方を分けて把握する
- 1タスクあたりAPI呼び出し回数: 外部API・社内APIそれぞれの呼び出し回数。有料APIを使う場合は回数がそのままコストに直結する
- レイテンシ（応答時間）: タスク開始から最終回答までの時間。ユーザー対面業務では体感速度に直結する
PoCではデータ量が少ないため気づきにくいのですが、本番で1日数千件のタスクをこなす想定なら、1タスクあたり数円〜数十円のコスト差が月次で数百万円の差に膨れ上がります。詳細なコスト構造の考え方については、AIエージェントのコスト構造ガイドもあわせて参照してください。
安全性・信頼性系（誤実行率・停止判断・再現性）
安全性・信頼性系の主要指標は次の3つです。
- 誤実行率: 人間承認が必要な操作（大量メール送信・データ削除・金銭移動など）を勝手に実行してしまった割合
- 停止判断能力: 判断に迷った際に無理にタスクを進めず「分かりません」「人間の判断が必要です」と止まれる割合
- 再現性: 同じ入力で同じ結果を返す割合。エージェントの内部でLLM推論を使う以上、完全な再現性は難しいが、本番運用ではこの指標が低いと監査対応が困難になる
とくに誤実行率は、業務ドメインによっては1%あっても本番投入不可となるケースがあります。金融・医療・法務など不可逆的な操作を含む業務では、誤実行率0%を目標とし、そのために「停止判断能力」を意図的に高める設計が求められます。
コストと安全性はPoCで見過ごされやすい——発注者からベンダーに要求すべき数字
PoC段階では、少量のテストデータで動作確認をおこなうため、コストと安全性の問題が顕在化しにくい傾向があります。発注者としては、次の数字を明示的に要求すべきです。
- 1タスクあたりの平均トークン消費（入力・出力別）と平均API呼び出し回数
- 想定本番稼働量（例: 1日1,000タスク）を掛け合わせた月次コスト試算
- 誤実行率（人間承認が必要な操作の勝手実行の割合）
- 停止判断能力（判断に迷った際に止まれる割合）
- 再現性（同じ入力での結果一致率）
これらの数字がベンダー報告書に含まれていない場合、本番稼働のリスクが可視化されていないと判断すべきです。
PoC検収・本番移行判定チェックリスト
ここまで解説した指標群を、発注者が実務で使えるチェックリスト形式にまとめます。稟議書テンプレートやベンダーへの追加要求リストとしてそのまま活用できる粒度で整理しました。
PoC検収時にベンダー報告書へ含めるよう要求すべき数字リスト
PoC完了報告を受ける前に、ベンダーへ次の項目の数値報告を要求してください。含まれていない項目は、その場で追加報告を求めます。
最終アウトカム系
- タスク完了率（完了の定義がA〜Dのどれか明記されているか。副作用込み判定が推奨）
- 回答品質スコア（LLM-as-a-Judgeか人間評価か、比率と評価観点定義書を添付）
- サンプルサイズと業務全体のカバー率
途中プロセス系
- トラジェクトリの順序一致率（期待した順序でステップが実行された割合）
- ツール呼び出し精度（API選択精度・引数指定精度・多段呼び出しの整合性）
- 平均ステップ数と最短経路との比較（余計なステップの有無）
運用コスト系
- 1タスクあたり平均トークン消費（入力・出力別）
- 1タスクあたり平均API呼び出し回数
- レイテンシ（p50・p95・p99）
- 想定本番稼働量を掛け合わせた月次コスト試算
安全性・信頼性系
- 誤実行率（人間承認が必要な操作の勝手実行の割合）
- 停止判断能力（判断に迷った際に止まれる割合）
- 再現性（同じ入力での結果一致率）
本番移行判定の稟議書テンプレート（GO条件の書き方）
本番移行の稟議書には、次のような形式でGO条件を明記します。「AI導入案件だから曖昧な表現でよい」ということはなく、通常のシステム導入と同じレベルで判定条件を数値化するのが望ましい姿です。
【本番移行判定のGO条件】
以下すべてを満たすこと。
1. タスク完了率（副作用込み判定）: X%以上
2. トラジェクトリ順序一致率: Y%以上
3. ツール呼び出し精度（API選択・引数指定）: Z%以上
4. 誤実行率: W%以下
5. 停止判断能力: V%以上
6. 1タスクあたり平均コスト: R円以下（月次コスト試算Q万円以内）
7. レイテンシ p95: S秒以内
【NO-GO条件（1つでも該当すればNO-GO）】
- 誤実行が不可逆的な操作（データ削除・金銭移動等）で1件でも発生した
- サンプル数が業務全体をカバーしていない（ユースケース網羅性が不足）
- ベンダーからトラジェクトリ・コスト系指標の報告がない
このテンプレートを叩き台に、社内稟議のフォーマットに合わせて数値の閾値をカスタマイズしてください。PoC段階の設計そのものについては、AIエージェントPoC設計ガイドもあわせてご覧いただくと、判定条件と設計を一気通貫で議論できます。
閾値の決め方——業種・ユースケースで許容誤差は変わる
上のテンプレートで「X%以上」「W%以下」と書いた閾値は、業種・ユースケースによって大きく異なります。閾値決定の観点をいくつか挙げます。
- 不可逆性の高い業務ほど誤実行率を厳しく: 金融取引・医療診断補助・法務書類作成など、間違いを取り消せない業務では誤実行率0%が実質的な必達目標
- ユーザー対面業務ほどレイテンシを厳しく: 顧客対応チャットボットではp95で3秒以内など体感速度基準、バッチ処理なら1タスク数分でも許容
- 大量処理業務ほどコストを厳しく: 1日1万件を超える処理量では、1タスク1円の差が月次30万円の差になる
- 社内バックオフィス業務は完了率・品質を優先: 誤実行のリスクが小さい業務では、完了率・回答品質の閾値を高めに設定して業務効率化効果を最大化
閾値決定の議論では、「AIだから精度100%は無理」という常識論に流されず、「業務要件として何%必要か」から逆算する姿勢が重要です。
まとめ——PoCの「次のアクション」へ
本記事では、AIエージェントの評価指標を「発注者・PoC判定者の視点」から体系的に整理しました。要点をおさらいします。
- AIエージェントの評価は、従来の「入力→出力の一発判定」では測れない。ツールを自律的に選び複数ステップで動く「軌跡」ごと評価する必要がある
- 押さえるべき視点は4つ（最終アウトカム・途中プロセス・運用コスト・安全性/信頼性）。タスク完了率だけを見て本番移行判定するのは危険
- 途中プロセス系（トラジェクトリ評価・ツール呼び出し精度・ステップ効率）はエージェント特有の指標で、ここが欠けているベンダー報告書は情報不足
- 運用コスト系・安全性系はPoC段階では見過ごされやすいため、発注者から明示的に数値報告を要求する
- 本番移行判定は「業種・ユースケースに応じた閾値」を稟議書に数値で明記する
本記事を通じて評価指標の見方が理解できたら、次はいくつかの方向で意思決定ジャーニーを進めてください。
これからAIエージェントのPoCそのものを設計する立場の方は、AIエージェントPoC設計ガイドで企画・検証設計の考え方を確認できます。PoCの合否判定を経て本番移行が決まった方は、AIエージェントのオブザーバビリティと本番監視ポイントで継続監視の設計に進むのが自然な流れです。またAIエージェント以外の一般的なAI評価指標（分類・回帰・LLM単体）の基礎を復習したい方は、AIの評価指標で全体像を押さえておくと、ベンダーとの会話がさらにスムーズになります。
AIエージェント導入の意思決定は、単一記事の情報で完結するものではありません。PoC設計→評価指標での判定→本番運用の監視という3段階を一貫した視点で捉え、各段階で必要な数字を発注者側から要求できる状態になることが、成功する導入の共通点です。本記事がその一助となれば幸いです。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- タスク完了率が85%あれば本番移行してよいのでしょうか？
完了率が「副作用込み判定（誤送信・データ破損等が発生していない）」かどうかを確認できなければ、85%という数字だけでは本番移行の判断材料になりません。自己申告ベースの85%と副作用込みの85%では意味がまったく異なるため、必ず後者で確認してください。
- ベンダーがトラジェクトリ評価に対応していない場合はどうすればよいですか？
まずは平均ステップ数と最短経路との比率、リトライ率など、実行ログから追加算出できる代替指標の報告を求めてください。それも困難な場合は、途中プロセスの品質が未検証のままである旨をリスクとして稟議書に明記した上で判断することになります。
- LLM-as-a-Judgeだけで評価された報告書はどこまで信頼できますか？
LLM-as-a-Judge単独では評価者自体のバイアスを排除できません。サンプル数十件でよいので人間評価（社内SME評価）とのスコア一致率を検証してもらい、乖離が大きい場合は評価観点の定義から見直すよう依頼してください。
- 業種によって指標の閾値はどのくらい変えるべきですか？
不可逆な操作を伴う業務（金融・医療・法務など）は誤実行率を厳しく、顧客対応など体感速度が重要な業務はレイテンシを厳しく設定します。閾値は「AIだから精度100%は無理」ではなく、業務要件から逆算して決めるのが基本です。
- PoCでコスト面に問題がなければ本番でも安心してよいですか？
PoCはデータ量が少なく、1タスクあたり数円のコスト差が本番稼働量では月次で数十万〜数百万円規模になる問題に気づきにくいため、安心はできません。想定稼働量ベースの月次コスト試算を必ず確認してください。
