AIエージェントの評価方法｜本番導入前に測る5つの指標

はじめに

AIエージェントを業務に組み込むとき、デモで自然に会話できることだけを合格条件にすると、本番で品質を測れなくなります。エージェントは、回答文だけでなく、目的を理解し、適切なツールを選び、権限の範囲で処理し、失敗時に止まるところまでを含むシステムです。

本記事では、AIエージェントの本番導入前に測っておきたい指標を、5つに整理します。特定の製品やモデルの優劣を決めるためではなく、自社の業務で「何ができたら成功か」を再現可能な形にするための考え方です。

1. まず「正解」を会話の上手さから業務の完了条件へ変える

AIエージェントの評価では、最終回答の文章だけを採点しがちです。しかし、業務では「必要な情報を取得した」「指定された形式で記録した」「承認が必要な処理を勝手に実行しなかった」といった状態が成果になります。

AnthropicのAIエージェント評価に関する解説では、評価対象のタスクに成功条件を定め、複数回の試行と実行履歴を使って評価する考え方が示されています。最初に作るべきものは、抽象的な「賢さ」の点数ではなく、代表タスクごとの期待結果です。

例えば社内の問い合わせ対応なら、次のように記述します。

• 問い合わせの種類を正しく分類する
• 参照してよいナレッジだけを使う
• 回答に根拠となるページを含める
• 判断が必要なケースは担当者へ引き継ぐ
• 引き継ぎ前に顧客へ確定的な約束をしない

この形なら、回答が少し違う言い回しでも、業務上の合否を判断できます。要件定義をAI開発の前工程で終わらせず、テスト可能な受け入れ条件まで落とすことが重要です。要件の整理方法は「AI要件定義の進め方」も参考になります。

2. 指標1：タスク達成率を測る

第一の指標は、依頼されたタスクを最後まで完了できた割合です。単に「回答が返った」ではなく、事前に決めた完了条件を満たしたかで判定します。

タスク達成率は、成功した試行数を評価した試行数で割って求めます。ただし、1回の成功だけで判断しないことが大切です。同じ代表タスクを条件を少し変えて繰り返し、安定して完了するかを見ます。

評価用のタスクには、通常ケースだけでなく、情報不足、曖昧な依頼、期限切れのデータ、権限のない要求を含めます。通常ケースだけの達成率は、実運用の強さを表しません。

また、全体の平均だけでなく、業務カテゴリ別にも分けます。請求、採用、営業、顧客対応では許容できる失敗の大きさが異なるためです。低リスクの定型作業で高い達成率が出ても、重要な判断を含む業務へそのまま広げないようにします。

3. 指標2：指示遵守率と制約違反を分ける

MicrosoftのAgent Evaluatorsでは、タスク完了だけでなく、指示の遵守やツール選択・引数の正確性も評価観点として扱われています。これはAIエージェント特有のポイントです。

例えば、ユーザーが「下書きまで」と指定したのに送信まで進めた場合、最終結果が一見正しくても失敗です。逆に、権限不足を検出して処理を止めたなら、タスクは未完了でも安全面では正しい挙動かもしれません。

そこで、次の2つを別々に記録します。

• 指示遵守率：許可された範囲、出力形式、手順を守った割合
• 制約違反率：禁止されたツール、宛先、データ、操作に触れた割合

特に制約違反は、平均点で薄めない設計にします。公開、削除、送信、権限変更などは、1回の違反が重大なためです。テストでは「してはいけない依頼」を明示的に混ぜ、拒否・確認・エスカレーションのどれを選んだかを評価します。

4. 指標3：ツール選択と実行経路の正確性を測る

エージェントが複数のAPIや社内システムを使う場合、最終回答が正しくても途中の実行経路が不適切なことがあります。読み取り専用で済む処理に書き込みAPIを使う、別の顧客のデータを参照する、引数の期間を取り違える、といった問題です。

評価では、次の証跡を残します。

• 選択したツール名
• 渡した引数と対象ID
• 実行順序
• 失敗時の再試行
• 人間の承認を挟んだ位置

Microsoftの評価資料でも、ツールの選択と引数の正確性は重要な評価対象とされています。ログを残すだけでは不十分で、期待する経路と比較できる形式にします。

業務ごとに「必須の確認」「実行してよい操作」「実行してはいけない操作」を表にしておくと、回帰テストに使えます。仕様書が更新されたときは、関連するテストケースも更新します。仕様と実装のずれを防ぐには「仕様書レビューのチェックポイント」の考え方も役立ちます。

5. 指標4：根拠・品質・安全性を評価する

回答の正確さは、正解に近いかだけでなく、どの情報に基づいているかで確認します。古い資料を使っていないか、参照範囲を越えていないか、推測を事実のように述べていないかを見ます。

評価項目の例は次の通りです。

• 参照した情報が質問時点で有効か
• 引用やリンクが主張を支えているか
• 不明な点を不明と表現しているか
• 個人情報や機密情報を必要以上に出していないか
• プロンプトインジェクションや不正な指示を拒否できるか

Google Cloudは、本番の実行トレースを継続的に採点するオンライン評価の考え方を紹介しています。導入前のテストで終わらせず、運用後もサンプリングして評価する仕組みを用意します。

重要な業務では、AIの採点だけに頼らず、人間による確認を組み合わせます。人間のレビューは全件でなくても、失敗の影響が大きいケース、評価器の信頼度が低いケース、初めて扱うケースに絞れます。

6. 指標5：時間・費用・再現性を業務単位で見る

最後は運用効率です。タスク1件あたりの処理時間、呼び出し回数、トークン使用量、エラー率、担当者が介入した時間を記録します。モデルの単価だけを比較すると、再試行や人手の確認にかかる費用を見落とします。

同じ入力に対して毎回異なる結果になる場合は、平均値より分布を見ます。最短時間だけでなく、遅いケースの割合、タイムアウト率、再試行後の成功率を確認します。業務のSLAがあるなら、平均ではなく「期限内に完了した割合」を指標にします。

技術指標と業務価値は分けて記録します。処理時間が短くなっても、確認漏れが増えているなら導入効果とは言えません。Microsoftの価値測定ガイドが示すように、技術的な品質と業務上の価値を結び付け、経営層へ報告できる形にします。

本番導入前に作る評価表

最初から完璧な評価基盤を作る必要はありません。まずは代表タスクを10〜20件程度選び、次の列を持つ表を作ります。

• タスクIDと業務カテゴリ
• 入力条件と期待する完了状態
• 許可されたツールと禁止事項
• タスク達成、指示遵守、根拠、安全性の判定
• 所要時間、再試行回数、担当者の介入
• 失敗理由と改善する仕様

合格基準は業務ごとに決めます。安全性に関する違反はゼロを求め、時間や文体には許容範囲を設ける、といった具合です。評価表を基に回帰テストを行い、プロンプトやツール定義を変えるたびに同じ条件で再実行します。

AIエージェントの品質は、モデルを一度選んで終わるものではありません。成功条件を決め、実行経路を記録し、失敗を分類し、改善後に再測定する循環で保ちます。業務フローからAI活用を設計する考え方は「AI業務フロー設計の進め方」にも整理しています。

Atsumellでは、業務の目的と制約を整理したうえで、AIエージェントの要件化から運用設計まで支援しています。自社の代表タスクで評価表を作りたい、既存のAI活用を本番運用へ進めたいという方は、お問い合わせからご相談ください。Kakusillの詳細は仕様・要件の整理を支援するKakusillをご覧ください。