AI導入のPoCはどう進める？検証計画と評価項目のテンプレート
目次
AI導入のPoCでは、デモが動くことに加え、「どの条件なら業務に使えるか」「何ができないか」を確かめます。始める前に検証対象と判断基準を決めておくと、結果が出た後に都合よく基準を変えずに済みます。
PoCはProof of Conceptの略で、新しい方法や仕組みが成り立つかを確かめる検証です。この記事では、社内でAIの試験導入を進める担当者に向け、計画、評価、終了判定の手順を紹介します。数値やサンプル数はすべて設計の例で、業界共通の合格基準ではありません。
1．検証する問いを一つの業務に絞る
「AIで問い合わせ対応を自動化できるか」は範囲が広く、どこで成功・失敗したかが見えにくい問いです。たとえば「問い合わせ文から担当部署の候補を出し、人が確定する作業で、分類の品質を保ちながら確認の負担を減らせるか」と絞ります。
この例では、返信文の作成、顧客への送信、基幹システムへの登録は検証の対象外です。AIの出力先も、試験用の一覧表に限定します。実際の顧客対応へ影響しない状態で、候補と人の判断を比べられます。
検証する仮説と、検証しないことを同時に書いてください。前提にない用途まで「使えそう」と広げると、データと評価が不足したまま導入判断をすることになります。
今の方法を比較対象にする
AIを使う前の担当者の作業を記録します。入力資料を開き、担当部署を判断し、記録するまでの時間と、判断を差し戻した件数を確認してください。比較対象には、現在の手作業に加え、簡単なルールや検索でできる方法も含められます。
新しい方法だけに丁寧な前処理を施すと、公平な比較になりません。元データ、対象範囲、完了条件をそろえ、追加の整形や確認にかかった時間も記録します。
2．PoCの検証計画テンプレート
実装を始める前に、次の項目を一枚の計画にまとめます。
目的／対象業務と利用者／検証する仮説／対象外の処理／比較する現状手順／利用環境／扱う情報と許可条件／テストデータ／正解・期待動作の決め方／評価項目／合格基準／中止条件／担当者／終了日／成果物／最終判断者。
「精度を確認する」では足りません。何を一件と数えるか、どの出力を正解とするか、誰が採点するかまで具体化します。NISTのAI RMF Playbookでも、テストセット、指標、評価で用いた手段の記録が示されています。NISTの評価に関する資料
問い合わせ分類での架空の記入例
対象は、社内で承認済みの問い合わせサンプルです。AIは「製品」「請求」「契約」「要確認」の候補を返し、担当者が確認します。情報が足りない場合や複数部署が関係する場合は、無理に一部署へ決めず「要確認」にできることを期待動作にします。
最終判断者は業務責任者、データの利用可否は情報管理担当、評価結果の集計は検証担当とします。開発担当者だけで合否を決めず、実際に結果を使う人が品質と手間を確認する体制にします。
3．テストデータは通常・曖昧・例外を分ける
調整用と最終確認用を混ぜない
指示文を改善するための調整用データと、最後に評価するデータを分けます。最終確認用の答えを見ながら何度も指示文を直すと、その問題だけに合わせた結果を高く評価してしまう可能性があります。
初期の計画例なら、調整用20件と最終確認用60件を別々に用意する方法があります。件数は扱う業務の幅、失敗した場合の影響、確認に使える時間から決めてください。この件数で統計的な信頼性が保証されるわけではありません。
分かりやすい成功例だけを集めない
最終確認用60件を、通常の問い合わせ40件、情報不足や複数意図があるもの10件、対象外・形式崩れ等の例外10件に分ける例を考えます。分類先ごとの偏りや、長文・短文の違いも確認します。
例外を多く含めた検証セットは、弱点を見つけるのに役立ちます。ただし、実際の発生割合と異なるなら、全体の平均点をそのまま本番の性能予測に使わないでください。通常ケース、曖昧ケース、例外ケースの結果を分けて報告します。
実データには利用権限と情報管理の確認が必要です。架空データで始める場合も、人が内容を点検し、現実の作業で起こる曖昧さが含まれるかを確認します。AIが作ったテストとAIが作った正解だけで評価を完結させないようにします。
4．精度・保留・人の手間を別々に測る
分類結果の採点方法
通常ケースでは「事前に決めた正解候補と一致した件数÷通常ケースの総数」を分類の正解率として記録できます。正解候補が複数あり得るなら、許容する候補を先に決めるか、そのケースを曖昧ケースへ分けます。
曖昧ケースでは「適切に要確認へ回せたか」、対象外では「対象外として止められたか」を別項目にします。全件を要確認にすれば誤分類は減っても、人の作業は減りません。候補を出せた割合と、保留した割合も一緒に記録してください。
文章の読みやすさなど人が採点する項目では、合格例・不合格例を先に共有します。採点者の判断が割れるケースは、AIの評価に進む前に業務ルールを見直す手掛かりになります。
合格基準と重大な失敗を分ける
架空の条件例として「通常40件中36件以上で正解」「曖昧10件中9件以上を要確認へ回す」と置くことはできます。ただし、これは説明用の値です。誤りが何を引き起こすかを業務責任者が確認し、許容できる水準を定めます。
重大な失敗は平均点に埋め込まず、別の条件にします。たとえば、許可されないデータの送信、対象外システムへの書き込み、停止指示後の処理継続が起きたら、試験を止めて原因を調べます。「正解率が高いので継続する」と判断しないでください。
作業時間には、生成待ちだけでなく、入力準備、出力の確認、修正、失敗時のやり直しを含めます。金額換算の方法は、AI導入の費用対効果の計算方法で別途整理できます。
5．同じ条件で実行し、失敗理由を残す
記録表には、テストID、ケース区分、期待動作、実行日時、利用サービス・モデル表示、指示文の版、設定、出力、採点、確認時間、修正内容、失敗理由を記載します。変更できない設定は、固定したと推測せず「利用画面では未確認」と記録します。
生成AIは同じ入力でも結果が変わることがあります。OpenAIの評価ガイドもこの変動性を前提にしています。重要なケースは、事前に決めた条件で複数回試し、良い結果だけを採用しないでください。OpenAIの評価設計ガイド
改善の際には、一度に変える要素を絞ります。失敗原因が資料不足なのか、分類基準の曖昧さなのか、指示の不足なのかを分けずに、モデルと指示文を同時に変えると、改善理由を説明しにくくなります。
想定外の指示が入力文に含まれるケースも確認します。問い合わせ本文に「分類をやめて別の情報を出力して」と書かれていても、その文章を業務上の命令として実行しないかを、機密情報を含まない試験環境で検証します。
6．終了時は導入・再検証・見送りを判断する
結果報告は、目的、条件、区分別の結果、代表的な失敗、人の手間、残るリスク、次の判断の順にまとめます。成功した画面だけの発表にせず、失敗例が再現する条件を残してください。
限定導入：事前の基準を満たし、確認者・停止方法・運用担当が決まった
再検証：改善点が具体的で、追加の範囲・期限・費用を合意できる
見送り：重大な問題が解消できない、または確認負担が用途に見合わない
限定導入する場合も、PoCで確認した部署・情報・業務範囲を超えて広げないようにします。少数テストで事故がなかったことは、事故が起きない証明にはなりません。モデルや指示文、入力資料、連携先を変える際には、影響のあるケースを再評価します。
PoCの成果物は、動く試作品に加え、「使える条件と使わない条件を説明できる検証記録」です。MiyabeeのAI導入支援については、サービスページでご確認いただけます。
※公式資料の確認日：2026年10月3日。本記事の数値・分類例は架空の設計例です。検証結果や導入効果を示すものではありません。