AIエージェントの受入テスト｜仕様書の6項目

AIエージェントの開発で、発注者とSIerの会話が止まりやすい場面がある。「どこまで動けば納品とするか」を決めるときだ。

デモで一度うまく動いても、受入テストの合格にはできない。参照した情報、使ったツール、承認の有無、処理後の状態まで再現できなければ、本番で同じ品質を確認できないからである。

AIエージェントのテストを受入試験仕様書へ落とすには、入力と出力だけでなく、要件ID、期待状態、禁止動作、証跡、再試験条件をつなぐ必要がある。ここでは、発注者、業務担当、SIer、運用担当が合意したい6項目を整理する。

AIエージェントのテストは評価と受入で役割が違う

評価は、複数の案や変更前後を比べるために使う。受入テストは、契約やプロジェクトで合意した仕様を満たしたか判断するために使う。似ているが、成果物が違う。

Microsoftのエージェント評価チェックリストでは、テストプロンプト、期待応答、受け入れ基準を一組にした評価セットが示されている。Salesforceのテスト観点も、主要な利用場面、表現の違い、複数ターンをテストケースへ含めるよう勧めている。

受入試験仕様書では、そこへ次の情報を加える。

• どの要件を確認する試験か
• 誰が正解を決めたか
• どの環境と版で実行したか
• 何を証跡として残すか
• 不合格時にどこまで戻って直すか
• 誰の承認で完了とするか

AIエージェントの評価設計で成功条件を決めた後、その条件を一件ずつ実行可能な試験へ変換するのが受入テストである。

受入試験仕様書に必要な6項目

受入試験仕様書には、次の6項目をそろえる。出力だけでなく、禁止動作・証跡・再試験までを一続きにする。

1．要件IDと業務シナリオを結びつける

試験ケースの先頭には、要件IDを書く。「会議後のタスク整理をテストする」だけでは、仕様変更の影響範囲を追えない。

たとえば、営業会議の後処理を行うAIエージェントなら、要件を次のように分ける。

一つの試験ケースですべてを確認しようとすると、失敗原因が曖昧になる。通常系のシナリオは業務要件と機能要件を確認し、権限境界や例外は別ケースに分ける。

逆方向の追跡も必要だ。要件一覧から、それを確認する試験ケースを一件以上たどれるようにする。要件に試験がなければ確認漏れ、試験に要件がなければ根拠のない試験である。要件ID、設計ID、試験IDをつなぐと、変更時に再実行する範囲を選びやすい。

2．入力と正解データを固定する

生成AIの出力にはばらつきがある。それでも、試験に使う入力と正解の根拠は固定できる。

会議後のタスク抽出なら、次を試験データとして一組にする。

• 会議メモ
• 対象の案件ID
• 既存タスク一覧
• 担当者の役割一覧
• 正解となるタスク候補一覧
• 「情報不足で作ってはいけない候補」の一覧

正解データは、SIerだけで作らない。業務担当が「この会話なら誰に確認するか」「この期限は確定として扱えるか」を判断し、発注者が承認する。システム上は似た文章でも、業務上の意味が異なる場合があるからだ。

入力の揺れは、同じ正解データから派生させる。

表現を変えたケースと、正解そのものが変わるケースは分ける。前者は入力への強さを測り、後者は別の業務要件として扱う。

3．期待出力と処理後の状態を書く

期待結果を「適切な回答」と書いてはいけない。文章の一致を求める項目と、意味が満たされればよい項目を分ける。

たとえばタスク候補の生成なら、次のように合否を定義する。

• 正解一覧にある必須候補をすべて含む
• 作成禁止一覧の候補を一件も含まない
• 担当者と期限の根拠を会議メモの該当箇所へ結びつける
• 不明な項目は推測せず、確認事項として分ける
• 外部送信やCRM登録は実行しない

さらに、処理後の状態を確認する。下書きが作られたのか、承認待ちになったのか、外部システムへ登録されたのか。画面の文章が正しくても、裏側で二重登録されていれば不合格である。

Microsoft Foundryのテスト手順は、単体、ローカル統合、デプロイ後の統合、同じテストデータによる評価を分けている。受入テストでは、本番に近い環境で外部連携後の状態まで読み戻す。

精度を数値化するときは、分母と判定単位を書く。必須候補10件中9件なら再現率は90%である。出力した12件のうち正解が9件なら適合率は75%になる。「正解率90%」だけでは、漏れと余計な出力のどちらが多いか分からない。

4．禁止動作と重大度ゲートを決める

平均点が高くても、一件の危険な動作で受入不可になる業務がある。支払、契約、外部送信、削除、権限変更などだ。

禁止動作は、正常系とは別の欄へ明記する。

• 対象外の顧客情報を参照しない
• 承認前に外部送信しない
• 根拠のない担当者や期限を補完しない
• 既存データを確認せず新規登録しない
• 一部失敗を全件成功として報告しない
• 削除対象が曖昧なまま処理しない

不具合の重大度も先に決める。

危険操作を止めた割合は、重大度を混ぜて平均しない。S1は100%阻止を必須にし、分母となる攻撃・誤操作ケース数も記録する。通常ケースの成功率が高くても、S1が一件あれば合格にはしない。

社内AIエージェントの権限設計で決めた「許可」「承認後に許可」「禁止」の三段階を、そのまま試験ケースへ変換すると漏れが減る。

5．再現条件と証跡を残す

「昨日は通った」が試験結果にならないよう、実行条件を固定する。

• モデル名と設定
• 指示文のバージョン
• 連携ツールのバージョン
• 参照データの基準日時
• 実行環境と権限ロール
• リトライ回数と時間上限
• 実行日時と実行者

証跡には、入力、最終出力、ツール実行の結果、承認記録、処理後の状態を残す。思考過程を丸ごと保存する必要はない。どの情報源とツールを使い、何が成功または失敗したかを再現できればよい。

機密情報や認証情報を証跡へ入れないことも仕様にする。対象ID、結果コード、所要時間、承認有無など、判定に必要な最小限へ絞る。AIエージェントの監視で残すログと項目を合わせると、受入時の基準を本番監視へ引き継げる。

同じケースは複数回実行する。通常ケースは、たとえば5回実行して成功回数を記録する。ところがS1の安全ケースは「5回中4回成功」で合格にしてはいけない。一度でも越境したら不合格とする。

6．責任者、承認欄、再試験条件を置く

受入試験は、SIerだけでは完了できない。役割ごとの責任を決める。

不合格時は、再試験の範囲を決める。指示文の修正なら影響するシナリオ群、権限設定の修正なら全権限ケース、モデル変更なら全必須ケースを再実行する、といった規則だ。

条件付き合格にする場合は、残件、回避策、責任者、解消期限を書く。「軽微なので後で対応」だけでは、本番後に消える。S1を条件付き合格へ回さないことも明記する。

受入テストを作る6つの手順

仕様書は、次の順で作ると役割がぶれにくい。

1. 業務シナリオを選ぶ：業務担当と発注者が対象範囲を決める
2. 要件から期待結果を作る：SIerが要件IDと試験IDを結ぶ
3. 正解データを承認する：業務担当が正解と禁止候補を確定する
4. 揺れと障害を加える：SIerと運用担当が例外ケースを作る
5. 実行して証跡を保存する：版と環境を固定し、処理後の状態を読む
6. 判定して再試験する：重大度に従って改修範囲と再実行範囲を決める

Google Cloudのエージェント評価は、開発中の迅速評価、CI/CDでの回帰テスト、本番の継続監視を分けている。受入完了後も、合格した必須ケースを回帰テストとして残す。指示文、モデル、ツール、権限仕様を変更したら同じケースを再実行する。

受入試験仕様書の記入例

この形なら、仕様変更から影響する試験をたどれる。発注者は何を承認したか説明でき、SIerは不合格の原因と改修範囲を切り分けられる。

OpenAIの企業向け評価解説が示すように、曖昧な目標を明確な基準へ変え、実際の業務条件で測り、失敗から改善する循環が必要になる。受入試験仕様書は、その循環を納品時だけで終わらせず、本番の回帰確認へ渡す接点である。

株式会社Atsumellでは、業務フローと要件の整理から、権限・承認・受入テストを含むAIエージェントの設計、構築、運用まで支援している。発注者とSIerの合格条件が揃わない場合は、対象業務と要件IDを一つ選ぶところから相談してほしい。

関連記事

• AIエージェントの評価設計
• AIエージェントのPoC｜本番へ渡す5条件
• AI社員の引き継ぎ設計
• AI社員の運用で毎週見直す項目