95% の分母は何か？
評価すること
- 回答、閲覧、ツール操作、業務完了を個別に判定する方法
- 拒否や引き継ぎを含む評価セットと、確定データを使った採点
- 公開範囲、保留、停止の判断条件
対象は、顧客サポート、社内検索、文書処理、注文・CRM エージェントを本番へ出すチームです。配備する機能の実際の動作を評価します。
架空の顧客サポート機能で、200 件のうち 190 件が成功したとします。表示される成功率は 95% です。
| 依頼 | 試験 | 合格 | 失敗の意味 |
|---|---|---|---|
| 公開製品の案内 | 120 | 120 | 製品条件を誤って説明 |
| 本人の注文照会 | 50 | 48 | 注文状況や照会結果が不正確 |
| 他の顧客や組織の照会 | 20 | 17 | 閲覧制限のある情報が開示された |
| 承認済み注文変更と重複 | 10 | 5 | 承認・変更・重複防止に失敗 |
| 合計 | 200 | 190 | 異なる失敗を一つに集計 |
権限の試験で 3 件、状態変更で 5 件が失敗しています。容易な質問を 800 件追加してすべて合格すると 990/1,000、つまり 99% になります。リスクのある 8 件は残ります。
これは試験構成で集計の見え方が変わる例です。本番で予想される発生率とは切り分け、業務とリスクごとの結果を示します。
NIST の生成 AI プロファイルは、限られた評価や逸話を広い運用条件へ一般化しないよう勧めています。自社のデータ、利用者、ルールで合格を示す証拠を作ります。[1]
どの組み合わせを評価するか？
同じモデルでも検索対象やツールの実行権限で動作が変わります。モデル ID、システム指示、検索設定、文書の版、ツール定義、権限方針、アプリケーションの版を記録します。
返品案内が流暢でも先月の規程を参照すれば現時点の誤答です。引数が正しくても別組織の注文をサーバーが返せば認可に失敗しています。「処理しました」という表示だけでは状態が変わりません。
利用者の画面、API、業務の状態、運用への引き継ぎを含めて、公開する機能を定義します。
従来の QA は何を証明するか？
ログイン、セッション期限、認可、金額計算、永続化、重複防止は明示的なルールで試験できます。説明の十分さ、質問の適切さ、根拠と回答の一致には評価基準を用意します。
API やブラウザーのテストでシステムを確認し、その出力を AI がどう解釈したかは別に評価します。失敗した層が分かれば修正する担当と範囲を絞れます。
リリース判断につながる検証 — 主要フローを検証し、実行結果と残る条件をリリース判断の根拠につなげます。
合格判定の七つの質問は？
下の表は業務型 AI の合格基準で不足している箇所を探す例です。
| 評価の質問 | 調べるもの | 証拠 | 失敗の例 |
|---|---|---|---|
| 業務上正しい回答か | 事実、計算、規則 | 期待結果、適用ルール、判定理由 | 条件を省いて返品可能と回答 |
| 根拠は回答を支えるか | 検索文書、出典、適用日 | 文書 ID、版、該当箇所 | 無関係な文書を引用 |
| この利用者が閲覧できるか | 組織、役割、対象 | 要求者とサーバー判定 | 別の顧客の注文を要約 |
| 許された操作か | ツール、引数、承認 | 実行値、承認対象、結果 | 照会の許可で取消を実行 |
| 業務は完了したか | DB と外部システム | 更新前後、操作 ID | 対応済みと表示し記録がない |
| 失敗時に停止・引き継ぎできるか | リトライ、不明状態、引き継ぎ | 原因、引き継ぎ内容、停止状態 | 成否不明の支払いを再実行 |
| 時間と費用を負担できるか | 遅延、再処理、総費用 | 完了までの時間、呼出・確認費 | 返信は速く確認待ちが増加 |
Google Cloud の評価資料は、応答品質、指示への準拠、根拠とツールの利用を別の観点として扱います。[2] 影響の違う失敗には個別の基準を使います。
返金額や閲覧許可など、システムで確定できる事実は正本データと業務ルールで判定します。
どんな依頼には止まることを期待するか？
まず一つの業務に絞ります。公開の製品案内なら、通常の質問、境界条件、引き継ぎを試します。注文を変更する機能がない場合は、変更を実行せず適切な案内を返すか調べます。
架空のサポート機能を例にします。
| 分類 | 入力例 | 期待する動作 |
|---|---|---|
| 通常 | 現在の返品期間についての質問 | 有効な規程を根拠に回答 |
| 必須項目不足 | 対象の注文が不明な返金依頼 | 必要な情報だけ尋ねて保留 |
| 根拠なし・矛盾 | 契約の特約と一般規程が異なる | 優先する規程を確認または引き継ぐ |
| 権限境界 | 組織が変わった後で以前の注文を照会 | 現権限を確認し閲覧範囲を守る |
| 状態変化 | 承認後に数量・受取人を変更 | 実行値を提示し必要な承認を取り直す |
| 成否不明 | 外部処理中に接続断 | 再実行する前に状態を照合 |
| 外部文書の指示 | 文書本文が無関係な実行を要求 | 文書を資料として扱い、実行の認可を強制 |
実際の問い合わせも評価に活用できます。利用目的、アクセス権、保管を確認し、必要な情報に絞ります。注文番号や特異な状況から本人や顧客企業を特定できないかも確認します。
開発用と最終評価用をどう分けるか？
開発チームが日常的に見る例は、修正や回帰確認に向いています。同じ例で指示を調整し、その例だけで合格を決めると、未知の入力での改善が分かりません。
判断用のセットを予約し、閲覧履歴と更新条件を決めます。アクセスと保管の責任を明確にします。Google の安全性ガイドも、開発時の評価と分離管理する検証評価を区別します。[3]
何を使って採点するか？
Anthropic はコード、モデル、人によるエージェントの評価を説明しています。判定する事実に合った証拠を使います。[4]
金額、注文状態、重複、認可はプログラムとサーバー記録で検証します。自由な説明は、一文との完全一致だけで判定せず、意味を評価する基準を使います。
LLM 採点は説明の欠落や根拠の不足を調べる補助になります。指示、参照資料、版を残し、人の判定と照合します。未実行、環境による阻害、証拠不足で判定不能な実行は別に数えます。採点可能な実行の結果と計画全体の実施率を併記します。
複数のモデルでも誤った資料や偏りを共有することがあります。研究では位置や回答の長さへの偏りが報告されています。順序を反転させ、人の判定と一致しない事例を確認します。[5]
期待結果を誰が管理するか？
開発と担当部門で答えが違えば、どの規程がいつ適用されるかを見ます。期待結果の承認者と変更履歴を残すと、点数の変化を説明できます。
意見が分かれる例は判断が必要なまま記録し、適用範囲の縮小や人の確認を検討します。
対話の後にどの状態が残るか？
架空の注文変更で、次の試験を行います。
- 顧客が自分の注文の配送先変更を依頼します。
- AI が住所と注文を提示し、承認を求めます。
- 顧客が住所をそのままにして受取人だけ変えると言います。この段階では実行しません。
- AI が新しい操作内容を提示して承認を得た後、外部処理の応答が失われる場面を作ります。
- 顧客が完了したか尋ねます。実際に照合するまで確定しません。
最初の返信に加え、最終的な受取人、住所、承認値、実行回数、利用者に示した状態を調べます。
住所変更は承認されていないため住所を保ちます。受取人変更に別の本人確認が必要なら、実行側で強制します。外部の結果が不明なら照合か引き継ぎへ進めます。
有効な実行経路が複数あれば許容します。本人確認、金額上限、承認など業務ルールが要求する境界はどの経路でも確認します。
どの比率が業務結果を表すか？
根拠のない質問まで答えれば応答率は上がりますが、実業務の品質は低下し得ます。すべてを担当者に送ると、想定した自動化の便益が失われます。
分母を分けて記録します。
| 指標 | 分母 | 調べたいこと |
|---|---|---|
| 回答可能な依頼の成功率 | 事前に回答可能と分類した依頼 | 対応範囲の仕事ができるか |
| 適切な引き継ぎ率 | 人の確認・引き継ぎが必要な依頼 | 止まるべき時に止まるか |
| 不要な引き継ぎ率 | 自動処理可能と分類した依頼 | 不要な負担が発生しているか |
| 実行業務の完了率 | 権限と条件を満たした依頼 | 正本の状態が変わったか |
| 禁止操作の発生率 | そのリスクを試した有効実行数 | 無権限の閲覧・操作があったか |
事例数と繰り返し数は別に報告します。10 事例を 3 回ずつなら 10 事例、30 実行です。環境問題や証拠不足で判定できない実行も理由と一緒に記録します。
分母が決まらないなら、機能が受け付ける依頼と責任の範囲を先に明確にします。
禁止操作の観測がゼロでも、対象となった入力、権限、試行回数での結果です。未検証の依頼まで同様に安全とは判断できません。
繰り返しの公平な比較をどう保つか？
重要な事例は複数回実行します。成功と失敗、その種類をすべて記録します。
以前の注文、キャッシュ、会話、作業ファイルの影響を除きます。すでに完了した注文で起きる二回目の失敗は、モデル由来の回帰と区別します。
同じ事例と基準を使います。文書や採点モデルも変わったなら原因を一つに絞れないことを記録します。模擬応答の合格と、実際の遅延・認可・重複防止を試す隔離環境での合格は証拠の範囲が違います。
繰り返しは、偶然良かった実行を公開判断の根拠として選ぶことを防ぎます。[4]
公開を保留・停止する条件は？
架空のサポートが製品案内、注文照会、返金を準備したとします。製品案内は基準を満たしましたが、照会には権限問題があり、返金はリトライが未検証です。
公開情報に限定できます。注文照会と返金をツールとサーバーで無効にし、実際に操作を拒否するか試験します。
保留条件の例を挙げます。
- 他の顧客や組織の情報を返せる。
- 無承認で外部送信や状態変更ができる。
- 成否不明の操作を繰り返せる。
- 根拠がない重要な事実を断定する。
- 評価した構成と公開構成の差を説明できない。
- 停止後の未完了案件と担当者を特定できない。
承認した範囲、残余のリスク、監視の担当者を記録します。一般的な判断手順は リリース判断の基準 を参照してください。
どの変更で再評価するか？
コードが同じでもモデル、指示、検索文書、権限、ツールが変われば動作が変わります。変更と確認し直す証拠を対応させます。
文体の調整でも必須の告知や引き継ぎが漏れることがあります。文書を差し替えると根拠と適用日が変わります。ツールの追加やモデルの変更では、実行経路と例外を見直します。
本番の誤りは原因の層に足します。方針なら規程、検索漏れなら検索試験、実行エラーなら API と状態確認です。本番障害を回帰テストに変える方法 も参照できます。
構成と評価セットの版、失敗の種類、未検証範囲、公開範囲、停止担当者、次の確認条件を記録します。
自社の評価範囲をどう決めるか？
公開したい機能と利用者の経路を一つ選びます。参照する情報、変えられる状態、失敗時の引き継ぎ先を記録し、七つの質問に対して利用できる証拠を割り当てます。
