主張ごとに検証の単位を決める
回答が正しい割合、業務が完了した割合、人が編集しなかった割合はそれぞれ異なる判断に使います。担当者が替わっても同じ条件で判断できるよう、指標と対象業務、判定の証拠を結びつけます。NISTの生成AIプロファイルも、供給元の事前調査、運用監視、配備前に実証できる方法で能力を試すことを勧めています。
精度95%という表現だけでは、何を一件としたか分かりません。一件の問い合わせから五項目を抽出し、一項目の誤りで人に戻す場合、項目単位の高い精度と業務単位の自動完了率は異なります。申込書の振り分けと不備通知なら分類、通知、業務状態更新を個別に判定します。
業務の開始から終了までの範囲を合わせます。契約への問い合わせに承認済み資料で答えて台帳に記録する例なら、回答、正しい案件への記録、必要な人への引継ぎが実際に作られたことを確認します。適切な引継ぎを業務上の成功とみなす場合でも、自動完了率では引継ぎを別に集計します。Anthropicのエージェント評価資料[1]は対話記録と環境の最終状態を分けています。
分母は受付対象として合意した入力から決めます。方針上サービス範囲外の要求と、対象だが引継ぎやタイムアウトが生じた要求を区別します。共通評価に含まれる入力を一社だけが支援しないなら、対象業務の差として記録します。成功、失敗、未実行、人が処理した案件は事例IDで追えるようにします。
二社の架空の提案を同じ表で比較する
A社は精度95%を示し、採点した80件のうち76件の回答が適切だったと説明しました。受付100件のうち複雑な20件は人に渡して採点対象から外し、正解扱いの76件のうち12件は送信前に担当者が内容を修正しました。B社は100件のうち70件を人の介入なしに完了したとして、自動完了率70%を示しました。B社の数値からは回答や台帳が正しいか分かりません。数値は比較方法を説明する架空のものです。
| 提案の主張 | 分母と確認済みの事実 | 比較に必要な追加証拠 |
|---|---|---|
| A社の精度95% | 受付100件のうち採点80件、適切な回答76件 | 除外20件の種類、編集前後の判定、台帳の最終状態 |
| A社の編集なしの適切な回答 | 76件から編集した12件を除いた64件。受付100件の64% | 64件の業務結果、人への引継ぎが必要な場合の処理 |
| B社の自動完了率70% | 受付100件のうち70件を人の介入なく完了 | 70件の正しさ、重大な権限違反、誤った自動処理と残る30件の結果 |
A社の64%は回答、B社の70%は介入のない完了です。双方に同じ100件を入力し、検証済み完了、重要な編集、引継ぎ、誤り、拒否を共通条件で集計します。改行の調整と金額、送信先、結論の変更を区別すると、業務リスクや作業負担との関係を読み取れます。
供給元が選んだデモは機能説明に使えます。選定では買い手側が代表業務、境界条件、失敗経路を用意し、デモの事例と重複していないか調べます。同じ入力を繰り返す場合は、異なる事例数と実行回数を分けます。一件を十回試すと、その一件の動作のばらつきを確認できます。
要件から承認までつながる根拠 — 要件、テスト、不具合対応、承認記録をつなぎ、共通の基準で品質を判断します。
全候補に同じ十二の質問を送る
調達担当者が共通の書式を送り、業務担当者が期待結果を承認し、技術担当者が証拠と再現性を確かめます。回答に追加の試験が必要なら、担当、提出する証拠と期限を記録します。受け入れ判断には実際に観測した結果を使います。
- 一件の成功とは何ですか。 開始条件、最後の業務状態、ユーザーへの応答と確認方法を例示してください。
- 公表指標は何を数えていますか。 受付、対象、実行、失敗、引継ぎ、除外を事例IDで照合してください。
- 人はどこに介入しましたか。 入力修正、下書きの確認、再試行、ツール実行、承認、供給元側の後処理を含めてください。
- 期待結果を誰が決めましたか。 発注側が確かめられる規程、契約、版、責任者を示してください。
- 開発と最終評価で事例をどう使いましたか。 調整用事例、別に確保した受け入れ資料、露出や類似事例の点検方法を示してください。
- どの構成で再現できますか。 ビルド、モデルと引数、プロンプト、資料、索引、ツール、権限、判定基準の識別子を示してください。
- 危険な例外をどう止めますか。 権限不足、根拠不足、古い資料、外部タイムアウト、危険な要求での実行と最終状態を示してください。
- 一件の費用には何が入りますか。 同じ利用条件の下でモデル、検索、保管、連携、再実行、人の確認を説明してください。
- モデルや検索を変える際の通知・承認は誰が行いますか。 予定した変更と予告のない依存変更それぞれの影響分析、再試験、復旧を示してください。
- 障害時に誰がどこまで対応しますか。 初動、機能停止、提供元への連絡、照合、利用者への案内、再開を担当別に示してください。
- 運用移管や契約終了時に何を引き取れますか。 入出力、評価証拠、設定、資料の状態、権限設定、制限と復元・削除証拠を示してください。
- 未確認の点とデモとの差は何ですか。 環境差、証拠不足、未実行、既知の問題、運用制限、担当と判定日を分けてください。
平常時と繁忙時を比較します。運用側は利用量、担当者の確認可能件数、業務ごとの期限を提示します。供給元は検索やツール呼び出しの再試行と見積りの範囲を同じ分布で説明します。失敗した仕事にも利用料と確認時間がかかるため、調達担当者に受付件数と検証済み完了件数を渡します。
担当者やツールが変わっても受け入れ試験を再現する
チャネル、業務の種類、役割、資料と権限の有効時点、結果を確認する場所を指定します。代表事例で一般的な経路を調べ、別のリスク事例で止めるべき境界を試します。発注組織が利用できる承認済みの匿名化資料や合成入力を用意し、調整用に渡した例は最終評価に入れません。技術と業務の担当者で解釈が異なるときは、合意の時点と根拠を残します。
| 確認する主張 | 受け入れ前に受け取る証拠 | 試験と判定の例 |
|---|---|---|
| 承認済みの商品方針で回答 | 方針ID、版、発効日、回答、引用、根拠不足時の動作 | 有効な版を使い、根拠がなければ保留または引き継ぐ |
| 承認された内容だけ変更 | 権限の対応表、操作と承認記録、前後の台帳 | 承認者、対象、金額、宛先を照合し、拒否時には変更がない |
| 顧客業務が自動で完了 | 事例の入出力、編集、再試行、完了記録 | 介入と除外の定義を守り、最終状態から数値を再現できる |
| 変更後も品質を維持 | 構成一覧、通知・承認、回帰試験と復帰条件 | モデルや資料を変え、どの証拠を再試験するか示す |
| 費用と遅延が条件内 | 件数、入力規模、再試行、確認工数と実測値 | 業務別の費用、遅延、滞留と上限時の動作を確認 |
| 社内で運用や移行が可能 | 評価資料、エクスポート、設定仕様、アカウント引継ぎ | 社内担当者が受領資料を使って別環境で合意した試験を行う |
規程が変わる業務ではモデル名に加え、提供元が示すモデル識別子、プロンプトのハッシュ、資料のスナップショット、検索設定、ツールの引数、権限、判定条件を実行IDに結びつけます。識別子を固定できない場合は観測した構成、日付、通知範囲と必要な試験を定めます。Google Cloudの生成AI運用ガイド[2]は運用入力の変化と出力の継続評価を扱っています。
評価データには事例ID、出所、責任者、許可範囲、適用方針、期待結果の版を記録します。調整に使える例と検収担当者のみが扱う資料の権限を分けます。社内チームが維持する項目では、試験を再実行するための資料と方法を受領します。持ち出し制限があれば、社内の代替データとルールで必要な結果を再現できるか合意します。
モデル変更と資料更新をそれぞれ試す
試験環境で架空の規程の版と発効時刻を変更します。供給元は索引更新と確認方法を示し、業務担当者は新規程と有効な例外を正しく使ったか判定します。次にモデルやツールの設定を変えて同じ事例を実行し、以前の証拠がどこまで使えるか確認します。社内担当者が一項目を実際に変更すると、文書、アクセス権と運用責任を合わせて検証できます。
運用チームが警報を受けても供給元だけが実行環境にアクセスできるなら、緩和や調査、結果の照合に時間がかかります。サービス合意では初動、緩和、復旧確認のそれぞれを確認します。MSPの障害対応責任は受付から変更・確認までを作業別に割り当てる例を示しています。ビルド、配備、基本権限、バックアップはソフトウェアの受け入れ基準へつなげます。
受け入れ会議では構成IDつきの共通試験結果、移管する運用資料、例外、未確認事項を確認します。危険な操作を止められる証拠がない場合や重要業務が未実行の場合は機能を制限し、受け入れを保留します。条件付き運用なら役割、機能、担当、期限、再試験と終了条件を記録します。構成変更後は影響を受けた証拠を取り直します。
