AIエージェント評価とは？導入判断に使える比較基準・評価項目・実務手順
AI脆弱性診断
そのAIシステム、従来の診断だけで十分ですか？
外部・内部の弱点に加え、プロンプトインジェクションや過剰な権限などAI固有の攻撃面も診断します。
AIエージェント評価とは、AIがもっともらしい回答を返せるかではなく、指定した権限・手順・停止条件の範囲で、業務の目的を安全かつ採算に合う形で達成できるかを確かめる取り組みです。
AIエージェントは、文章を生成するだけでなく、検索、社内システム照会、ファイル操作、API呼び出し、外部サービスへの更新などを複数ステップで行います。そのため、最終回答だけを採点すると、「正しい答えだが更新処理をしていない」「正しい更新をしたが権限外のデータを参照した」「一度は成功したが繰り返すと失敗する」といった違いを見落とします。AIエージェントの基本的な対象業務や、チャットボット・RPAとの使い分けは、AIエージェントとは？で整理しています。
Anthropicは、エージェントを評価する際には、エージェントハーネスとモデルがともに評価対象になると説明しています。また、試行の記録であるトレースと、環境に残った最終状態を区別して確認する考え方を示しています。Anthropic: Demystifying evals for AI agents
結論：比較するのは「モデルの賢さ」だけではなく、業務を完了する仕組み
経営・事業の導入判断では、ベンチマークの順位やデモの印象だけで候補を選ばず、次の6項目を同じ業務条件で比較します。
- 業務達成：必要な成果物またはシステム上の最終状態に到達したか
- 正確性・完全性：必要な情報・条件・根拠を満たし、必須項目を落としていないか
- 安全性・権限順守：許可されていない参照・操作・外部送信をしていないか
- 運用性：人へ適切に確認・引き継ぎでき、失敗時に止めて復旧できるか
- 安定性：同じ条件で複数回実行したとき、必要な成功率を維持できるか
- 経済性：1件あたりの総コスト、処理時間、人の確認時間が許容範囲か
この6項目の優先度は一律ではありません。たとえば、社内文書の下書き支援では処理時間と修正時間が中心になりやすく、顧客へのメール送信や返金処理では、安全性・承認・監査可能性が先に来ます。モデル、入力データの品質、評価ケース、許容誤差、与える権限によって結論は変わります。
AIエージェント評価と、通常の生成AI評価の違い
観点 | 通常の生成AI評価 | AIエージェント評価 |
|---|---|---|
主な対象 | 回答文、要約、分類、抽出、コード | 回答に加え、計画、ツール呼び出し、状態変更、引き継ぎ |
成功の判定 | 出力が正解・基準に合うか | 業務上の最終状態に到達し、過程も制約を守ったか |
代表的な失敗 | 誤答、形式違反、根拠不足 | 誤操作、操作漏れ、重複実行、権限逸脱、停止不能 |
必要な証跡 | 入力・出力・採点結果 | 加えてツール入出力、権限、承認、状態遷移、実行ログ |
本番後の確認 | 品質・利用者評価 | 品質・利用者評価に加え、外部影響、コスト、例外、復旧状況 |
AI全般の評価指標やLLM-as-a-judgeの基本は、AIの評価とは？、LLM as a judgeとは？で解説しています。本記事では、その考え方を「外部ツールを使って仕事を進めるエージェント」に拡張します。
評価の出発点：最終回答ではなく「1業務の完了条件」を決める
評価対象を「問い合わせに答えるAI」のように曖昧にすると、候補比較もPoCの合否判定もできません。評価を始める際は、エージェントが完了すべき業務を、開始条件・許可操作・完了条件・禁止操作・人へ渡す条件に分けます。
以下はMojiによる設計提案です。
項目 | 定義する内容 | 記入例（架空の例） |
|---|---|---|
開始条件 | 誰が、何を依頼した時点で実行できるか | 認証済みのサポート担当者が、注文番号を含む返品依頼を登録した場合 |
目的 | 業務として達成したい結果 | 返品可否を判定し、下書き返信と社内処理案を作る |
許可操作 | 参照・更新してよいシステムと操作 | 注文DBの参照、CRMへの下書き保存まで |
禁止操作 | エージェントにさせない操作 | 返金確定、顧客へのメール送信、住所変更 |
完了条件 | 結果として存在すべき状態 | 根拠付きの下書きと、担当者向け確認事項がCRMに保存されている |
人へ渡す条件 | 自動処理を止める例外 | 規程外の要求、高額案件、本人確認不一致 |
外部送信、金銭、権限変更などを伴う業務では、出力品質とは別に、委任範囲・承認・停止・監査を設計してください。具体的な設計方法は、AIエージェントのガードレール設計も参照してください。
評価項目：6軸で採点し、1つの総合点に潰さない
複数の評価項目を単純な総合点だけで比較すると、「安価で速いが危険な候補」と「遅いが安全な候補」が同じ点数になる場合があります。特に高影響の操作では、重大な安全違反を平均点で相殺しないルールが必要です。
評価軸 | 確認する問い | 測定例 |
|---|---|---|
業務達成 | 正しい最終状態を作れたか | 完了件数、状態検証の合格率 |
品質 | 根拠、必須項目、形式、判断が要件を満たすか | 必須要件充足率、専門担当者レビュー |
安全・統制 | 権限外の操作、不要なデータ取得、危険な実行がないか | 重大違反件数、承認漏れ件数、停止試験の成否 |
安定性 | 再実行で結果がぶれないか | ケース別成功率、複数試行での全試行成功率 |
効率 | 費用・待ち時間・人手を許容できるか | 1件あたりコスト、P95待ち時間、確認時間 |
回復性 | 失敗時に止まり、再開・取り消し・引き継ぎできるか | 復旧成功率、重複実行の防止率、未処理例外数 |
NIST AI RMF 1.0は、AIリスク管理をGOVERN、MAP、MEASURE、MANAGEの4機能で整理しています。GOVERNは他の機能を横断するものと位置付けられ、リスク管理はAIシステムのライフサイクルを通じて継続的に行うべきだと示されています。NIST AI RMF 1.0
評価データセットの作り方：通常例・境界例・失敗例を分ける
デモでうまくいく依頼だけを集めても、本番で問題になる例外を検出できません。評価ケースは、少なくとも次の4群に分けます。
- 通常ケース：頻度が高く、期待する処理が比較的明確な依頼
- 境界ケース：情報不足、複数規程の競合、曖昧な依頼、例外条件を含む依頼
- 失敗再現ケース：手作業、試作、問い合わせ履歴で確認済みの失敗を匿名化・再構成したもの
- 安全ケース：権限外の指示、悪意ある文書、禁止操作の誘導、承認が必要な依頼
初期段階では、完全な網羅を待つ必要はありません。現場で起きた失敗、重要業務の代表パターン、実施頻度は低くても影響が大きい例外から着手します。Anthropicは、初期の評価セットは実際の失敗から集めた20〜50件程度のタスクから始める方法を例示しています。ただし、必要な件数は業務、評価目的、期待する検出力によって変わります。Anthropic: Demystifying evals for AI agents
エージェントは複数回のツール操作や環境状態の変化を伴うため、各ケースには「期待する最終状態」と「許されない操作」の両方を記録します。RAGを含むエージェントの場合は、回答評価だけでなく、検索対象に正解根拠があったか、最終的に渡した文脈に残ったか、回答が根拠を使ったかを分けます。評価データの設計は、RAG評価データセットの作り方も参考になります。
ケース記述テンプレート（Mojiによる提案）
ケースID:
業務名:
利用者の依頼:
初期状態:
利用可能なツール・権限:
期待する最終状態:
必須の確認・操作:
禁止操作:
人への引き継ぎ条件:
採点方法:
確認者:
「架空の例：顧客へ返金する」といった高影響操作を評価する場合も、本番の決済環境ではなく、状態を検証できる隔離環境で行う方法を検討します。テスト環境の安全性自体も評価範囲です。OWASPの「Top 10 for Agentic Applications」は、エージェント型AIシステムに関する重大なセキュリティリスクを整理しています。OWASP Top 10 for Agentic Applications for 2026
採点方法：結果・経路・人の判断を組み合わせる
エージェント評価では、1種類の採点方法だけに依存しないことが重要です。Mojiでは、次の3層を分けて設計することを提案します。
採点層 | 向く対象 | 例 | 注意点 |
|---|---|---|---|
決定的な自動検証 | 状態、形式、数値、権限 | DBの更新値、必須フィールド、承認IDの有無、テスト通過 | 「自然な文面」を測るには不十分 |
ルーブリック採点 | 説明品質、根拠、応対、要約 | 根拠に基づくか、確認事項を明示したか | LLM採点なら人の評価と定期的に照合する |
人によるレビュー | 高影響判断、曖昧な品質、採点器の校正 | 専門担当者が判断の妥当性を確認 | 全件レビューではなく、重点ケースと標本抽出に使う |
Anthropicは、エージェント評価でコードベース、モデルベース、人による採点を組み合わせる方法を説明しています。また、モデルベースの採点には人による採点との校正が必要だとしています。最終状態を主に見るか、トレースも見るかは、評価したい失敗に応じて選びます。Anthropic: Demystifying evals for AI agents
安定性をどう測るか：1回の成功だけで導入を判断しない
AIエージェントは、同一入力でも毎回同じ経路・結果になるとは限りません。特に、ツール選択、長いタスク、外部検索、複数エージェント構成では、1回の成功だけでは再現性を判断しにくい場合があります。
同一ケースを複数回実行し、次の2つを分けて見ます。
- 各試行の成功率：1回実行したときに成功する割合を把握する
- 連続成功率：繰り返し利用しても失敗しにくいかを把握する
Anthropicは、少なくとも1回成功する確率を見るpass@kと、すべての試行が成功する確率を見るpasskを区別しています。前者は複数案から1案を選べる用途、後者は毎回の信頼性が求められる用途で有用性が異なります。Anthropic: Demystifying evals for AI agents
たとえば「複数回のうち1回でも成功すればよい」業務と、「顧客対応で毎回安全に成功しなければならない」業務では、必要な指標が異なります。重要な案件ほど、平均的な成功率だけでなく、重大失敗の有無、引き継ぎの正しさ、停止条件の作動を分けて確認してください。
PoCの進め方：候補選定を目的にした比較実験にする
PoCは「動くこと」の確認ではなく、本番化・限定継続・中止を選ぶための比較実験として設計します。以下はMojiによる実務上の進め方です。
- 対象業務を1つに絞る：頻度、影響、データ利用可否、可逆性を確認する
- 委任レベルを決める：提案のみ、下書き保存、社内更新、外部送信などを区別する
- ベースラインを取る：現行の処理時間、差し戻し、例外、確認工数を記録する
- 評価ケースと採点器を作る：通常・境界・失敗再現・安全ケースを含める
- 同一条件で候補を比較する：モデルだけでなく、プロンプト、ツール定義、検索、権限、環境を固定または記録する
- 合否ゲートを適用する：重大安全違反、必要成功率、待ち時間、コスト、運用負荷を別々に判定する
- 限定運用で監視する：本番ログ、失敗、例外、人の修正を評価ケースへ戻す
PoCの開始前に決めるべきKPI・移行ゲート・定着指標は、AI PoCを本番化する進め方で詳しく解説しています。
導入可否を判断するチェックリスト
次のチェックは、製品比較やPoC終了時の会議で使うためのMojiによる提案です。すべてを満たすことが唯一の正解ではありませんが、未確認のまま本番権限を広げないための確認項目として使えます。
- □ 対象業務の完了条件を、回答文ではなく状態・成果物として定義した
- □ エージェントに与えるツール、データ、書き込み権限を一覧化した
- □ 禁止操作、承認必須操作、停止条件を定義した
- □ 通常・境界・失敗再現・安全ケースを評価セットに含めた
- □ 最終状態を自動検証できるケースを、可能な範囲で用意した
- □ トレースを確認し、危険な経路や採点漏れを点検した
- □ 同一ケースを複数回試し、安定性を確認した
- □ 1件あたりのモデル費用だけでなく、人の確認・例外対応を含む総コストを比べた
- □ 本番後の監視担当、失敗の受付、停止権限、見直し日を決めた
- □ モデル・プロンプト・ツール・権限・検索設定の変更時に再評価する運用を決めた
よくある失敗：正答率だけで「導入可能」と判断する
失敗1：デモ用の簡単な依頼だけで比較する
通常ケースだけでは、情報不足、規程競合、例外処理、悪意ある入力を含む本番の難所が見えません。失敗ログや現場の差し戻し理由を、匿名化・一般化して評価ケースへ追加します。
失敗2：最終回答だけを採点する
エージェントでは、回答が正しくても、誤ったツールを使った、余計なデータを読んだ、二重処理した、といった問題が残り得ます。結果とトレースを分けて確認します。
失敗3：平均点で重大な安全違反を相殺する
高い平均品質でも、許可されていない送信・更新・参照が起きるなら、同じ権限のまま本番化するかは改めて判断が必要です。重大違反は総合点と別の不合格条件にします。
失敗4：評価セットを固定したままにする
モデル更新、ツール仕様変更、業務ルール改定、利用者の使い方の変化で、過去の評価結果はそのまま使えなくなる場合があります。NIST AI RMF 1.0は、AIリスク管理をライフサイクル全体で継続的に行う考え方と、継続的な監視・定期的な見直しの計画を示しています。NIST AI RMF 1.0
まとめ：AIエージェント評価は「安全に任せられる範囲」を決めるための仕組み
AIエージェント評価の目的は、最も高いモデル名を選ぶことではありません。自社の業務で、何を任せ、何を人が確認し、どの失敗なら止めるかを根拠付きで決めることです。
まずは可逆的で影響範囲が小さい1業務を選び、完了条件・禁止操作・評価ケース・合否ゲートを定義してください。そのうえで、結果、実行経路、安全性、安定性、コスト、回復性を分けて測れば、「使えそう」という印象ではなく、限定導入・改善継続・中止を判断できる材料になります。
なお、AIエージェント評価はモデルの種類だけで結論が決まるものではありません。入力品質、検索対象、ツール仕様、権限設計、評価指標、許容誤差、業務上の失敗コストをそろえた条件で比較してください。