AI導入の検収基準はどう決める？｜実際の問い合わせ・伝票でつくる評価テスト

AIを試してみると、デモではそれらしく動きます。ところが「では、どの条件を満たせば業務で使えると判断してよいのか」と聞かれると、答えに詰まることがよくあります。結論から言えば、AI導入の検収基準は、実際の問い合わせや伝票から作った評価テストと、テストの前に合意した合格基準で決めるのが確実です。

ここでいう検収は、開発を委託したAIの仕組みや、試行（PoC）を終えたAIを、業務で使ってよい状態かどうか確かめて受け入れることを指します。評価テストを作って検収し、運用で測り直すまでの手順は、次の5段階です。

1. 1実データを集める — 直近の問い合わせや伝票から、よくある種類と例外を選ぶ
2. 2ケースを分ける — 正常・例外・判断不能・入力不備の4種類に分けて正解を書く
3. 3正答以外も確かめる — 誤った実行・根拠・引き継ぎ・応答時間・コストも確かめる
4. 4合格基準を合意する — データ・正解・基準・確認担当者をテストの前に決める
5. 5更新後に再評価する — モデルや資料を変えたら同じテストで測り直す

試行から本番運用までの全体の流れは生成AI導入の進め方｜PoCで終わらせず本番運用に乗せる4ステップで解説しています。この記事は、そのなかの「何をもって合格とするか」を決める手順に絞り、開発を担う立場から整理します。

デモが動いても、なぜ検収の判断はできないのか？#

デモには、うまく動く入力が選ばれやすいからです。業務では、質問の言い回しが人によって違い、伝票には書き間違いや訂正が混じり、資料に答えのない質問も届きます。こうした入力で試していない限り、「業務で使える」とは言い切れません。

AIの検収は、通常のシステムと何が違うのか？#

通常のシステムは、同じ入力に同じ結果を返すことを前提に、仕様どおりかを確かめます。生成AIは、同じ質問でも回答の表現が変わることがあります。Anthropicは、評価の成功基準の例として一貫性（Consistency）を挙げ、同じ質問を2回したときに意味の近い回答が得られることがどれだけ重要かを検討するよう促しています（出典：Define success criteria and build evaluations｜Anthropic）。

出力が揺れることがある以上、1件を試して「動いた」で判断すると、たまたまうまくいった結果を見ているだけかもしれません。AIの検収では、まとまった件数のテストを通して、どの種類の入力で、どのくらい期待どおりに動くかを確かめます。

利用する側は、何を確認しておくべきか？#

仕組みが想定どおりに動いているかを確認することと、出力の精度やリスクの程度を理解しておくことです。総務省と経済産業省の「AI事業者ガイドライン（第1.2版）」は、法的な拘束力を持たない指針ですが、AIを業務で使う「AI利用者」にとって重要な事項として、「AI システム・サービスが想定された仕様に基づき適切に動作しているかを確認する」ことを挙げ、出力の精度とリスクの程度を理解したうえで利用することも挙げています（出典：AI事業者ガイドライン（第1.2版）第5部 U-2）i（P.40）｜総務省・経済産業省）。弊社は、開発を委託した場合でも、受け入れてよいかの最終判断は、業務で使う会社が自社のデータで確かめたうえで持つべきだと考えています。

一方で、生成AIの導入段階で専門的な審査の体制があると答える企業は、日本では多くありません。総務省の「令和8年版 情報通信白書」で、生成AIの導入・活用に関するリスク対策の取組を尋ねた設問（複数回答）では、「製品・サービスの企画・導入段階で、専門的な知見から審査する体制がある」と答えた割合が日本は26.1%で、米国の52.5%、ドイツの38.1%、中国の59.0%を下回りました（出典：令和8年版 情報通信白書 データ集（図表Ⅰ-2-1-9）｜総務省）。専門の審査役を置けない場合でも、業務の担当者が実データで評価テストを作れば、受け入れの判断材料はそろえられます。

評価テストは、どのデータから作ればよいか？#

直近の実際の問い合わせ・伝票・判断の場面から作ります。想定で作った例文では、現場の書き方の揺れや例外を拾えないためです。Anthropicも、評価は実際の業務で起きる入力の分布に近づけて作り、例外的な入力（edge cases）も含めるよう勧めています（出典：Define success criteria and build evaluations｜Anthropic）。

テストに入れるデータは、どう選ぶか？#

次の順で選ぶと、偏りが出にくくなります。

• よくある種類を漏れなく入れる：問い合わせなら質問の種類、伝票なら取引先や書式の種類ごとに、件数の多いものから選ぶ
• 繁忙期のデータを含める：月末や季節の繁忙期は、件数が増えるだけでなく、書き方が乱れることもある
• 過去に人が迷った例を足す：差し戻しや訂正になった伝票、担当者に回った問い合わせを集める
• 個人情報を伏せる：氏名や連絡先は置き換えてから使う

最後の点について、AI事業者ガイドラインも、AI利用者にとって重要な事項として、個人情報を不適切に入力することがないよう注意を払うことを挙げています（出典：AI事業者ガイドライン（第1.2版）第5部 U-4）i（P.40）｜総務省・経済産業省）。置き換えの方法は、社内の利用ルールに沿って決めます。

テストの件数は、どう考えるか？#

件数に決まった基準はありません。目安は、業務の担当者が「これで普段の仕事は一通り試せている」と言えることです。そのうえで、次の2点に気をつけます。

• 種類ごとに必要な件数を確保する：例外・判断不能・入力不備は実データでは数が少なくなりがちなので、過去の記録から意図して集める
• 「0件」を確かめたい項目は件数を多めに取る：誤った実行が0件という結果も、数件のテストでは安心材料になりにくい

正解は、どう書いておくか？#

ケースごとに、業務の担当者が「期待する結果」と「許容範囲」を書きます。伝票の読み取りのように正解が一つに決まるものは、項目ごとの正しい値を書きます。問い合わせへの回答のように表現が変わりうるものは、文章の正解ではなく、次の3点で書きます。

• 回答に必ず含める内容（配送予定日、返品の条件など）
• 誤ってはいけない内容（金額、日付、在庫の有無など）
• 書いてはいけない内容（約束できない納期、社外秘の情報など）

正解を書く作業は、業務の判断基準を言葉にする作業でもあります。ここで担当者ごとに答えが割れたら、AIより先に業務の基準をそろえる必要があります。

ケースは、どう分けて評価するか？#

正常・例外・判断不能・入力不備の4種類に分け、種類ごとに期待する動きを決めます。まとめて正答率を出すと、件数の多い正常ケースで数字が高く出て、例外や判断不能での失敗が埋もれてしまうためです。

4種類のケースと期待する動きは次のとおりです。

判断不能と入力不備は、なぜ正常ケースと分けて数えるのか？#

期待する動きが「正しく答える」ではなく、「答えずに止まる」「人に引き継ぐ」だからです。正常ケースと同じ物差しで採点すると、もっともらしい回答を返しただけで合格に見えてしまいます。資料に答えがない質問にAIが推測で答えれば、誤った案内がそのまま顧客に届きます。品番の欠けた注文を推測で補って登録すれば、誤出荷の原因になります。この2種類では、答えずに止まったか、人に引き継いだかを合格の条件にします。

Anthropicも、評価に含める例外的な入力の例として、関係のない入力や入力データが欠けているケース、人でも判断が割れるあいまいなケースを挙げています（出典：Define success criteria and build evaluations｜Anthropic）。AI事業者ガイドラインも、AIを提供する側にとって重要な事項として、提供時点で予想される利用条件の下だけでなく、さまざまな状況の下で性能の水準を保てるようにすることを挙げています（出典：AI事業者ガイドライン（第1.2版）第4部 P-2）i（P.37）｜総務省・経済産業省）。

正答率のほかに、何を確認するか？#

誤った実行、根拠、引き継ぎ、応答時間、コストの5項目を、正答とあわせて確認します。回答が正しくても、待ち時間が長すぎたり、1件あたりの利用料が想定を超えたりすれば、業務では使えないからです。Anthropicも、ほとんどの用途では複数の観点で評価する必要があるとし、観点の例に応答時間（Latency）と費用（Price）を挙げています（出典：Define success criteria and build evaluations｜Anthropic）。

5つの項目と、テストでの確かめ方は次のとおりです。

誤った実行は、どう試すのか？#

メールの送信、受注の登録、在庫の引き当てのように、AIが操作まで行う仕組みでは、出力の正しさより先に「誤って実行しないか」を確かめます。テストでは、実際の送信先や本番のデータベースにつながない検証用の環境を使い、例外や入力不備のケースで、AIが実行の手前で止まり人の承認を待つかを見ます。

根拠は、どこまで確かめるか？#

社内資料をもとに回答する仕組みでは、AIが示した資料を開き、その記載が回答の内容と合っているかまで確かめます。資料名が表示されているだけでは不十分です。存在しない資料名を挙げたり、別の資料の内容を混ぜたりしていないかを、テストの採点項目に入れます。

引き継ぎ・応答時間・コストは、どう測るか？#

いずれも「業務で受け入れられる範囲」を先に決めてから測ります。

• 引き継ぎ：判断不能のケースで人に引き継いだ件数に加え、正常ケースを不要に人へ回した件数も数える。何でも人に回せば判断不能のケースは合格になるが、それでは人の作業が減らない
• 応答時間：画面の前で顧客を待たせる用途か、夜間にまとめて処理する用途かで、許容できる時間が変わる。現場の担当者に「何秒までなら待てるか」を聞いて決める
• コスト：テストで使った利用料を件数で割って1件あたりを出し、月の処理件数を掛けて試算する。試算した月額が、導入の稟議で見込んだ継続費用に収まるかを確かめる

合格基準は、誰と何を合意するか？#

業務の責任者・担当者と開発会社（社内で作る場合は開発の担当者）のあいだで、テストデータ、正解と許容範囲、合格基準、確認担当者の4点を、評価テストを実行する前に合意します。テストの結果を見てから基準を決めると、結果に合わせて基準が動いてしまうためです。開発を委託する場合は、要件定義の時点で決めておきます。

合意する4項目と決め方の例は次のとおりです。

合格の数値は、何を基準に決めるか？#

いまの人の作業の誤りを目安にして、対象業務ごとに決めます。精度の数値に、どの業務にも当てはまる合格ラインはないため、調査や他社の事例にある数値をそのまま基準にはしません。比べるときは、誤りの件数そのものではなく、処理した件数に対する割合で比べます。可能であれば、同じテストケースを人にも処理してもらい、同じ採点方法で比べると公平です。

条件は、ケースの種類ごとに分けて書きます。たとえば、正常ケースの誤りの割合が人の作業より高くないこと、誤った実行は0件であること、判断不能のケースはすべて人に引き継ぐこと、のように書きます。導入前に記録しておく数字と、継続・停止の条件の書き方は、AI導入の稟議書に何を書く？｜削減工数・品質・継続費用の説明方法で解説しています。

開発を委託するときは、どこに書いておくか？#

評価テストと合格基準を、要件定義の成果物や検収の条件として書面に残します。AIの出力は表現が揺れることがあるため、「十分な精度」のような言葉だけでは、検収の場面で受け入れてよいか判断できません。要件定義で決めておく事項の全体は、システム開発の要件定義の進め方｜失敗しない手順と決めることで解説しています。

不合格だったら、どうするか？#

不合格になった種類のケースを開発会社と一緒に見て、原因を分けます。指示文や資料の不足なら直して同じテストで測り直し、業務の基準があいまいなら正解の書き方から見直します。一部の業務範囲だけが基準に届かない場合は、合格した範囲（問い合わせの種類や伝票の書式など）に限ってAIに任せ、残りは人が対応する形で本番に進める判断もあります。ただし、誤った実行が出た場合や、判断不能・入力不備のケースが基準に届かない場合は、範囲を絞っても本番には進めません。修正と再テストを何回、どの期間で行うかも、合格基準とあわせて事前に決めておくと、検収が長引きません。

そのまま使えるテスト表のひな形は？#

次の表を、表計算ソフトにそのまま貼り付けて使えます。1〜4行目は問い合わせ対応を例にした記入例で、5行目以降は空欄の記入行です。

採点の欄には、次の言葉を記入します。

• 誤った実行：なし／あり
• 根拠：一致／不一致／該当なし
• 引き継ぎ：適切／不要な引き継ぎ／引き継ぎ漏れ
• 判定：合格／不合格

判定は、期待する結果・許容範囲を満たし、誤った実行が「なし」、根拠が「不一致」でなく、引き継ぎが「適切」のときに「合格」とします。集計は、ケースの種類ごとに合格の件数を数えます。種類をまたいで合計した正答率だけで判定しないようにします。応答時間とコストは1件ずつではなく、テスト全体で測った値を表の外に記録します。

モデルや資料を更新したら、どう再評価するか？#

検収のときと同じテストで測り直し、前回の結果と比べます。モデルの切り替えや資料・設定の変更で、検収後も動きが変わることがあるからです。

再評価が必要になる主な場面は次のとおりです。

• モデルの更新：AnthropicのClaude APIでは、提供終了日を過ぎたモデルへのリクエストは失敗します。同社は、後継のモデルについて、提供終了日より十分前に自社のアプリケーションでテストするよう勧めています（出典：Model deprecations｜Anthropic）
• 資料の更新：社内規程、商品情報、価格表などを差し替えたとき
• 指示文や設定の変更：回答の書き方や、人に引き継ぐ条件を変えたとき

AI事業者ガイドラインも、AIを提供する側が関連するステークホルダー（AI利用者を含む）に提供する情報の例として、AIシステムを更新した場合の更新内容とその理由を挙げています（出典：AI事業者ガイドライン（第1.2版）第4部 P-6）ii（P.38〜39）｜総務省・経済産業省）。契約するサービスや委託先から更新の連絡を受けたら、再評価を始めるきっかけにします。連絡がどの範囲で届くかは、契約や利用規約で確認しておきます。

再評価で、何を見て切り替えを判断するか？#

ケースの種類ごとに、合格の割合が前回より下がっていないか、合格基準を下回っていないかを見ます。運用中に足したケースは、前回と共通のケースと分けて集計します。全体の正答率が同じでも、判断不能や入力不備の合格が減っていれば、そのまま切り替えず原因を確かめます。再評価は更新のときだけでなく、四半期ごとなど定期の時期も決めておくと、実データの変化にも気づけます。

運用中に見つかった失敗は、どう扱うか？#

運用中にAIが誤った回答や処理をしたら、その入力を新しいテストケースとして表に足します。こうしておくと、同じ失敗が再び起きていないかを次の再評価で確かめられます。テスト表は検収で使い終えるものではなく、運用とともに増やしていく記録です。

検収基準づくりで見落としやすい点は？#

次の5点は、検収の前と再評価のたびに確認してください。

• 判断不能のケースだけを見て、正常ケースを不要に人へ回していないかを数えていない
• 不合格だった場合の修正・再テストの回数と期間を決めていない
• テストデータの個人情報を、置き換えずにAIに入力している
• モデルや資料の更新の連絡がどこから届くかを、契約や利用規約で確かめていない
• 検収のときのテストデータが古くなり、いまの問い合わせや伝票と合わなくなっている

まとめ#

AI導入の検収基準は、次の5つの手順で整えます。

• 実データを集める：直近の問い合わせや伝票から、よくある種類と例外を選ぶ
• ケースを分ける：正常・例外・判断不能・入力不備の4種類に分けて正解を書く
• 正答以外も確かめる：誤った実行・根拠・引き継ぎ・応答時間・コストも確かめる
• 合格基準を合意する：データ・正解・基準・確認担当者をテストの前に決める
• 更新後に再評価する：モデルや資料を変えたら同じテストで測り直す

合格の数値は業務ごとに決めること、判断不能と入力不備では「止まったか」「人に引き継いだか」を合格の条件にすること。この2点を押さえると、デモの印象ではなく、自社の業務で確かめた結果で受け入れを判断できます。

よくある質問（FAQ）#

Q. AIの検収で、正答率は何%あれば合格ですか？

A. どの業務にも当てはまる合格ラインはありません。いまの人の作業の誤りの割合を目安に、対象業務ごとに決めます。正答率は種類ごとに分けて見て、誤った実行は0件、判断不能のケースはすべて人に引き継ぐ、といった条件もあわせて合格基準にします。

Q. テストケースは何件くらい必要ですか？

A. 決まった件数はありません。よくある種類ごとに複数のケースがあり、例外・判断不能・入力不備も含めて、業務の担当者が普段の仕事を一通り試せていると言える量を目安にします。運用中に見つかった失敗を足して、件数を増やしていきます。

Q. PoCの評価と検収は、何が違いますか？

A. PoCの評価は、AIで効果が出そうかを小さな範囲で見極めるものです。検収は、業務で使ってよいかを受け入れの条件に照らして判断するものです。PoCで作った評価テストを実データで広げ、合格基準を合意したうえで検収に使うと、試行から本番への判断がつながります。

Q. 社内にAIに詳しい人がいなくても、検収基準は作れますか？

A. 作れます。テストの入力と正解を書くのに必要なのは、AIの知識より業務の知識です。誤った実行の試し方や応答時間の測り方など、仕組みに関わる部分は開発会社に手順を出してもらい、採点と判定は業務の担当者と責任者が行う、という分担が現実的です。

評価テストの設計から、ご相談ください#

弊社（株式会社TryWith）は、AIソリューション開発とシステム開発支援を通じて、実際の問い合わせや伝票を使った評価テストの設計、試行の結果にもとづく本番移行の判断、既存システムへの組み込みまでを、開発を担う立場から支援しています。

対象業務のケースの洗い出しから、正解と許容範囲の書き方、誤った実行を防ぐ仕組みの検証、モデル更新後の再評価の進め方まで、一緒に整理します。PoCは動いたが本番に進めてよいか判断できない、という段階からのご相談も承ります。

お問い合わせはこちら