AIエージェントの評価方法｜成功率・権限逸脱・費用を測る設計

評価対象を最終成果・判断経路・業務結果の三層に分ける

第一層は最終成果です。回答の正確さ、必要項目の充足、根拠との整合、形式、利用者が次の行動へ進めるかを測ります。第二層は判断経路です。どの情報を取得し、どのツールを選び、どの順序で実行し、承認を求め、終了条件へ到達したかをトレースで確認します。第三層は業務結果です。人の手戻り、処理時間、完了件数、顧客への影響、成功一件当たり費用を、導入前の基準値と比較します。

OpenAIの現行「Evaluation best practices」は、評価を構造化されたテストと位置付け、目的、データセット、指標、比較、継続評価の順で設計するよう案内しています。また、数値だけでなく人の判断を組み合わせ、実際の利用分布に合うタスク固有のテストを使う点を重視しています^[1]。これは製品横断の公的標準ではありませんが、曖昧な印象評価を避ける実装資料として利用できます。

OpenAIの「Evaluate agent workflows」は、トレースにモデル呼び出し、ツール呼び出し、ガードレール、引き継ぎを記録し、評価基準で採点する方法を示しています^[4]。本稿ではこの製品固有の考え方を、AIエージェントの判断経路、ツール選択、権限逸脱を最終回答と分けて検査する用途に限定して参照します。

一つの評価点は経営向けの要約には使えますが、改善箇所の診断には使えません。元の三層指標と失敗ケースを必ず残し、総合点だけを保存しないことが評価設計の前提です。

モデル・状態・ツール・外部系が結果を変える仕組みを捉える

AIエージェントの出力は、モデルとプロンプトだけで決まりません。入力文、検索で得た情報、会話または案件状態、提示されたツール定義、権限、外部APIの応答、再試行、終了判定が連鎖して決まります。同じ最終回答でも、検索が一度で済んだランと、不要なデータを大量取得した後に答えたランでは、費用とリスクが異なります。評価ログには、最終出力に加えて各段階の入力・出力・版を残します。

ばらつきには二種類あります。一つは、同一条件でもモデルの選択が変わる確率的なばらつきです。もう一つは、検索結果の更新、API障害、権限変更、時刻依存データなど環境差によるばらつきです。前者を測るには同じケースを複数回実行し、後者を測るには外部応答を固定した試験と実環境に近い試験を分けます。両方を混ぜたまま候補モデルを比較すると、モデル差か接続先差かを説明できません。

OpenAIのEvalsに関する公式資料は、テスト基準とデータソースを構成し、異なるモデルや設定で評価ランを比較できる仕組みを示しています^[2]。自社ツールを使う場合も、ケースID、構成ID、ランID、モデル版、プロンプト版、ツール版、開始時刻、終了理由を共通キーとして保存すれば、同じ考え方で追跡できます。

case_id: refund-042
configuration_id: agent-b_prompt-7_tools-3
run_id: 20260730-00421
input_snapshot: sha256:...
tool_catalog_version: 3
authorization_policy_version: 5
final_status: handed_off
stop_reason: refund_limit_exceeded

モデルが正解を返したかだけでなく、どこで不確実性が入ったかを記録すると、モデル変更、検索改善、ツール説明の修正、権限縮小のどれが必要かを切り分けられます。

実運用の分布を反映した評価セットと基準値を作る

評価セットは成功しやすい代表例だけで作りません。通常ケース、入力不足、境界値、例外、過去の失敗、攻撃的入力、外部障害、権限不足を別の層として収集します。たとえば問い合わせ回答エージェントを五十件で試すなら、通常二十件、情報不足八件、複数意図六件、社内規程の例外六件、誤った文書を含む検索五件、ツール障害三件、権限逸脱を誘う入力二件というように、件数と目的を先に登録します。この配分は想定例であり、実運用ログの割合と損失の大きさに合わせて変更します。

正解は一文の模範回答に限定しません。必須事実、許容できる表現差、禁止事項、使うべき根拠、不要な個人情報、必要なツール、使ってはいけないツール、承認または人への引き継ぎ条件を採点基準にします。複数の正解がある業務では、二択の完全一致よりも、項目別の判定や候補A・Bのどちらが基準に近いかという比較を使います。OpenAIの公式ガイドも、LLMによる採点では自由生成より分類、基準に沿った採点、ペア比較を優先し、人の評価で自動採点を校正する考え方を示しています^[1]。

基準値は、現在の人手処理または既存システムを同じ定義で測ります。人が月百件を処理し、完了八十八件、差戻し十二件、総作業時間五十時間なら、完了率88%、一件当たり平均30分です。AI候補だけ成功の定義を緩めたり、人の確認時間を費用から外したりしません。人が担当した時点で発生していた検索、承認、修正も含めて比較します。

モデルや構成候補を比べる軸と実行条件を固定する

候補比較では、モデル名以外の条件をそろえます。プロンプト、利用可能ツール、ツール説明、検索スナップショット、最大ターン数、再試行、温度などの生成設定、タイムアウト、権限ポリシー、採点器を固定します。モデルとプロンプトを同時に変えた比較は、改善理由が分からないため別の構成IDとして扱います。比較日に外部情報が変わる業務では、固定応答による再現試験と、現行データによる実環境試験を分けて報告します。

比較軸は、成果品質、経路品質、安全性、安定性、効率の五つです。成果品質は正答や必須項目、経路品質は不要な呼び出しと適切な引き継ぎ、安全性は越権・漏洩・承認順守、安定性は同一ケースの反復成功、効率は成功一件当たりの時間・トークン・外部費用で測ります。安価でも重大事故がある候補を採用しないよう、安全性は独立ゲートにします。

各ケースを三回実行する場合、五十ケースなら百五十ランです。「三回中一度でも成功」と「三回すべて成功」は別指標です。本番で一度きりの処理を確実に完了させたい業務では後者を重視し、複数候補を生成して人が選べる業務では前者も参考になります。反復回数と採用ルールを結果確認後に変更しません。

評価環境の権限境界を本番より狭く設計する

エージェント評価は、意図的に攻撃入力や誤った指示を試すため、本番データと本番権限で始めてはいけません。テスト専用テナント、架空または匿名化済みデータ、送信できないメールドメイン、取り消せる更新、費用上限付き資格情報を使います。評価実行者にはケース投入権限、採点者には結果閲覧権限、環境管理者には資格情報発行権限を分け、採点者が合格させるためにログを書き換えられない構成にします。

権限境界はツール単位で記録します。検索ツールはテスト顧客のみ、更新ツールは評価用レコードのみ、外部送信は疑似受信箱だけ、削除・決済・契約確定は提供しません。本番で高リスク操作を予定していても、最初は「実行予定の構造化データを出す」段階に置き換え、人が期待値と照合します。書き込み試験へ進む条件は、読み取りと提案の評価が合格し、ロールバックが実演済みであることです。

評価ログの閲覧範囲も設計対象です。攻撃ケースに秘密情報の模擬値を含める場合は、本物と混同しない接頭辞を付けます。ログに実データが混入したら評価を止め、データ管理者が削除・通知・再発防止を判断します。

タスク成功率・経路・安全・効率を式と限界付きで測る

評価指標は、分子、分母、集計期間、除外条件を定義します。タスク成功率だけでは、簡単な案件へ偏った場合や、重大な失敗の種類を説明できません。最低でも、成功、重大失敗、適切なツール選択、承認順守、反復安定性、成功一件当たり費用を並べます。費用にはモデル利用料、検索や外部API、実行基盤、人の確認時間を含めます。

タスク成功率 = 合格ラン数 ÷ 評価ラン総数 × 100
重大失敗率 = 重大失敗ラン数 ÷ 評価ラン総数 × 100
ツール選択適合率 = 正しく選ばれた呼び出し数 ÷ 全呼び出し数 × 100
必要ツール実行率 = 実行できた必須呼び出し数 ÷ 必須呼び出し総数 × 100
承認順守率 = 正しい承認を経た対象操作数 ÷ 承認対象操作総数 × 100
三回連続成功率 = 三回すべて合格したケース数 ÷ 反復対象ケース数 × 100
成功一件当たり費用 = 総運用費 ÷ 合格ラン数

総合評価Eは、経営向けに候補を要約する編集部提案です。E = 0.35T + 0.20J + 0.20A + 0.15R + 0.10F とし、Tはタスク成果、Jは判断経路、Aは権限・承認順守、Rは反復安定性、Fは費用と時間の適合度です。各領域を0〜100へ正規化します。ただし、未承認操作、秘密情報開示、記録されない書き込みのいずれかが一件でもあれば、Eを計算してもリリース不合格です。配点は対象業務の損失に合わせ、試験計画の承認時に固定します。

想定例として、T=92、J=88、A=100、R=84、F=90ならEは91.4点です。百五十ラン中に未承認送信が一件あれば、91.4点という表示の横に「重大ゲート不合格」と記載します。母数五十ケースでは、1件の差が2ポイントになるため、小差をモデルの優劣と断定しません。重要ケースの層別結果、反復時の連敗、95パーセンタイルの処理時間を併記します。

問い合わせ回答エージェント向けの固有評価票で合否を出す

評価票は業務別に作ります。以下は、社内規程と顧客契約を検索し、回答案を作り、必要時に担当者へ引き継ぐエージェントの想定例です。自動送信は評価範囲に含めません。正答だけでなく、根拠の取得、不要な個人情報を読まないこと、契約変更を提案に留めること、引き継ぎ理由を残すことを合格条件にしています。

総合点90以上を本番候補、80〜89.9を制限付き継続、80未満を構成見直しとするのは想定基準です。重大ゲートに加えて、通常ケースだけ高得点で例外層が下限未満の場合も本番候補にしません。部門責任者は総合点ではなく、失敗ケース一覧と残余リスクを確認して受容します。

NIST AI 600-1は、生成AIの測定を単発の精度評価に限定せず、組織のリスク管理活動へ結び付ける資料です^[3]。この評価票も、モデル選びだけに使わず、担当者、監視頻度、変更時の再評価、停止権限を含む運用判断へ接続します。

自動採点器を専門家の判定で校正してから全件へ使う

LLMやルールによる自動採点は、評価件数を増やす助けになりますが、採点器も誤ります。文章が丁寧という理由で事実誤認を見逃す、模範解答と表現が違うだけで正答を落とす、引用URLの有無だけで根拠の適切さを判定する、といった偏りがあります。そこで全件採点の前に、業務専門家二人が独立判定した校正用ケースを用意し、自動採点器の一致率だけでなく、重大な誤りを合格にする「見逃し」と、正しい結果を不合格にする「過剰判定」を分けて測ります。

採点一致率 = 人と自動採点器の判定が一致した件数 ÷ 校正ケース総数 × 100
重大見逃し率 = 人が重大不合格・自動採点器が合格の件数 ÷ 人の重大不合格総数 × 100
過剰不合格率 = 人が合格・自動採点器が不合格の件数 ÷ 人の合格総数 × 100

想定例として校正用四十件を使い、一致三十六件なら一致率90%です。ただし、人が重大不合格とした八件のうち二件を自動採点器が合格にした場合、重大見逃し率は25%となり、全件の合否を任せられません。採点基準を細分化し、重大項目はルール判定または人手確認へ戻します。OpenAIの評価ガイドが、人のフィードバックで自動評価を校正するよう示している点も、この工程の一次情報上の根拠です^[1]。

採点器のモデル、指示、基準、入力形式を変えた場合は再校正します。合格後も本番ログから無作為抽出した結果と重大ケースを人が監査し、見逃しを一件確認した時点で、その項目の自動合否を停止します。

目的の承認から結果の固定まで八段階で評価を実施する

評価はツールを起動する前に、成功条件と意思決定を承認します。評価結果を見てからケースを除外したり、重みを変更したりすると候補間の比較が崩れます。OpenAIの公式ガイドが示す「目的、データ、指標、実行・比較、継続評価」という流れを基礎にしつつ^[1]、エージェント固有の権限と経路確認を加えた手順が次の八段階です。

1. 意思決定を定義する。モデル採用、プロンプト改訂、本番移行、権限拡張など、評価後に一つだけ決める事項を記載します。
2. 業務の正解を承認する。必須事実、許容差、禁止事項、引き継ぎ条件を業務責任者がケース別に確定します。
3. ケース層と母数を固定する。通常、境界、例外、攻撃、障害の件数を登録し、各ケースに損失区分を付けます。
4. 構成と権限を凍結する。モデル、指示、ツール、検索データ、認可、採点器へ版IDを付け、評価中の無断変更を防ぎます。
5. 小規模な採点校正を行う。十件程度を二人の評価者と自動採点器で判定し、不一致理由を基準へ反映します。校正に使ったケースは最終比較から分けます。
6. ランを実行して証跡を保全する。候補順を交互にし、外部応答を固定した試験と実環境試験を区別し、失敗ランも削除しません。
7. 層別に分析する。全体平均、ケース層、重大度、反復、ツール、費用、時間を分け、候補差の原因を失敗IDまで追います。
8. 判定と再評価契機を記録する。本番候補、制限付き継続、中止を決め、モデル・指示・ツール・規程・利用分布が変わった場合の再評価範囲を指定します。

OpenAIのEvals公式資料が説明するように、評価は設定した基準とデータソースに対して複数のランを管理できます^[2]。専用製品を使わない場合も、八段階の成果物をケース台帳、構成台帳、ランログ、判定記録の四ファイルへ分ければ、再現可能な比較ができます。

試験を止める条件と本番を止める条件を別に定める

評価中の即時停止は、未承認の外部操作、テスト範囲外データへのアクセス、秘密情報の出力、監査ログを残さない書き込み、評価用費用上限の超過です。資格情報を無効化し、最後の正常ランと最初の異常ランを保全します。連続五回のツール障害、p95処理時間が計画の二倍、日次費用が上限の150%に到達した場合は、原因を切り分けるまで新しいランを止める想定ルールも使えます。数値は接続先の制約と試験予算に合わせて承認します。

本番停止は、評価時に存在しなかったツールの呼び出し、権限ポリシーの不一致、重大失敗が一件、重要ケースの週次成功率が合格下限から5ポイント以上低下、監査ログ欠落などをトリガーにします。単純な一時障害は対象ツールだけを止められますが、原因不明のデータ越境や資格情報の疑いはエージェント全体を止めます。人への引き継ぎ経路と未完了案件の一覧がない状態では、停止操作そのものが業務事故になるため、移行前に演習します。

再開時に過去の高得点を流用せず、停止原因を含むケースを評価セットへ追加します。外部API障害が原因ならモデル評価と運用可用性を分け、どちらの責任者が再発防止を持つかも判定記録へ残します。

正解・証跡・比較条件がない案件では評価が成立しない

業務責任者が合格と不合格を説明できない案件、入力と出力しか保存できずツール経路を追えない案件、候補ごとに利用データや権限が異なる案件では、公平な評価ができません。ケースが五件しかないのに小数点以下の差でモデルを選ぶ、成功したランだけを残す、人の確認時間を費用から外す、重大事故を総合点で相殺する方法も避けます。

法的判断、医療判断、雇用・与信など高い影響を持つ用途では、この記事の社内評価票だけで自動実行を正当化できません。該当分野の法令、専門家レビュー、差別や説明責任の評価、異議申立て手続を追加します。評価対象を下書きや情報整理へ狭めても正解を定義できない場合は、AI導入より先に業務判断の標準化が必要です。

一つの点数にまとめない方がよいケース

安全性が絶対条件の業務、複数部門で損失の意味が異なる業務、対象ケースが少ない試行、正解が複数あり専門家間でも一致しない業務では、総合点より領域別の合否と失敗一覧を使います。経営報告で要約点を出す場合も、重大ゲート、母数、信頼できない層を同じ画面に表示します。

次に取る行動

まず、AIエージェントに任せたい一つの業務から匿名化した通常・境界・例外・攻撃・障害ケースを合計五十件用意し、必須事実、禁止事項、必要ツール、引き継ぎ条件を業務責任者が承認します。候補ごとの構成と権限を固定し、各ケースを三回実行してください。重大ゲート、五領域の元指標、失敗ID、成功一件当たり費用を評価票へ記録し、本番候補・制限付き継続・中止を決めます。完成物は評価セット台帳、構成台帳、ランログ、判定記録の四点です。

自動採点を使う場合は、四十件程度の校正用ケースを最終比較とは別に確保し、業務専門家二人の判定と照合します。品質保証担当はケース版と採点器版を固定し、セキュリティ担当は重大ゲートの失敗を確認し、業務責任者は層別下限と残余リスクを承認します。候補名と総合点だけではなく、構成ID、母数、失敗ケース、評価日、再評価トリガーまで記録した時点で判定を確定してください。

参考文献・出典

1. OpenAI公式ドキュメント「Evaluation best practices」：版＝継続更新ページ（版番号なし）、更新日＝ページ内表示なし、参照日＝2026年7月30日。評価設計の工程と自動採点・人手校正の考え方を参照。
2. OpenAI公式ドキュメント「Working with evals」：版＝継続更新ページ（版番号なし）、更新日＝ページ内表示なし、参照日＝2026年7月30日。Evalsの構成とラン管理は製品固有仕様として参照。
3. NIST公式文書「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」。版はNIST AI 600-1、公開日は2024年7月26日、公開ページ更新日は2026年4月8日、参照日は2026年7月30日です。重大リスクを平均点で相殺しない評価票の設計に参照しました。
4. OpenAI公式ドキュメント「Evaluate agent workflows」。版は継続更新ページ（版番号なし）、更新日はページ内表示なし、参照日は2026年7月31日です。AIエージェント評価でトレース、ツール選択、引き継ぎ、権限逸脱を検査する用途に参照しました。