AIのPoCは、精度の前に「誤ったときにどうなるか」を決める
AIを使ったPoCの進め方は、通常のPoCと同じく、問いを決め、範囲を絞り、合否条件を合意してから実施します。違いは、AIの出力には誤りが含まれうる、という前提を最初から計画に入れる点にあります。
通常のシステムは、決めたとおりに動くかどうかを確かめれば足ります。AIは、同じ種類の入力でも正しく答えるときと誤るときがあり、生成AIでは同じ入力に対して出力が変わることもあります。そのため、AI開発のPoCで確かめるのは「動くか」ではなく、「誤りを含んだ状態で、業務として成り立つか」です。
この問いに答えるために、AIのPoCには次の三つの準備が加わります。
- 評価に使うデータと、正解の決め方
- 精度以外の合否条件（誤りの影響、人の確認工程、運用コスト）
- データと権限の確認
以下、順に説明します。特定のモデルや製品の優劣、性能の数値はこの記事では扱いません。変化が速く、自社のデータで確かめた結果だけが判断の根拠になるためです。
評価データを先に作る
AIのPoCで最初に作るものは、画面でもプログラムでもなく、評価用のデータです。これがないと、出力を見た人の印象で良し悪しが決まり、改善したかどうかも分かりません。
評価データを作る手順は次のとおりです。
- 実際の業務で発生する入力を集める。作り物の例ではなく、現場の実物を使います。
- よくある場合だけでなく、難しい場合、例外、入力が欠けている場合も含める。都合のよい例だけで評価すると、本番で想定外の誤りが出やすくなります。
- それぞれの入力に対して、期待する出力、または合格とみなす条件を決める。
- 正解を決める人を決める。業務に詳しい人が複数いる場合は、判断が割れた例を記録し、基準をそろえます。
- 調整に使うデータと、最後の評価に使うデータを分ける。調整に使ったデータで評価すると、実力より良く見えます。
生成AIのPoCでは、文章の要約や回答の作成のように、正解が一つに決まらない作業を扱うことがあります。その場合は、「事実と異なる内容を含まない」「必要な項目が入っている」「社内の表現の決まりに反していない」のように、観点ごとの確認項目を作り、人が採点します。採点する人によって結果がぶれないよう、項目は具体的に書きます。
正解を決める作業は手間がかかりますが、ここで業務の判断基準が言葉になること自体が、PoCの成果の一つです。現場でも基準が人によって違っていた、と分かることもあります。
精度以外の合否条件を決める
精度がどの水準なら十分かは、精度だけを見ていても決まりません。次の三つの観点と組み合わせて初めて決まります。
誤りの影響。AIが誤ったとき、何が起きるかを種類ごとに書き出します。たとえば、社内文書の分類を誤る場合と、顧客への回答を誤る場合では、影響の大きさが違います。また、「見つけるべきものを見逃す誤り」と「問題のないものを問題ありとする誤り」では、業務への影響が異なります。どちらの誤りをどこまで許容できるかを、業務の責任者と決めます。
人の確認工程。AIの出力をそのまま使うのか、人が確認してから使うのかを決めます。人が確認する場合は、次の点が合否条件に入ります。
- 確認にかかる時間は、AIを使わない場合の作業時間より短いか。
- 確認する人は、誤りに気づけるか。気づくために必要な情報（根拠となる箇所など）が示されているか。
- 確認が形だけにならず、続けられる量か。
人の確認を前提にしているのに、確認の手間を測っていないPoCは、本番で「結局、全部見直すので楽にならない」という結果になりがちです。
運用コスト。利用量に応じてかかる費用、評価や調整を続ける人の作業、問い合わせへの対応を見積もります。PoCの期間は利用量が小さいため費用は目立ちませんが、対象を広げたときにどうなるかを、利用量の見込みから試算しておきます。事業として提供する場合は、顧客一件の採算から拡大を判断する考え方と合わせて確認します。
これらを含めた合否条件の書き方は、PoCの終了日に次の投資を決められる評価設計の枠組みがそのまま使えます。
データと権限を着手前に確認する
AIのPoCが途中で止まる原因になりやすいのが、データと権限です。着手前に次の点を確認します。
- 使いたいデータは、今回の目的で使ってよいものか。取得したときの目的や、契約上の制約に反していないか。
- 個人情報や機密情報が含まれるか。含まれる場合、取り除くか、匿名化するか、扱える環境を用意するか。
- 外部のAIサービスを使う場合、入力したデータがどう扱われるか。社内の情報管理の決まりに合っているか。
- AIが参照する情報に、利用者ごとの閲覧権限があるか。権限のない人に、AIを通じて情報が見えてしまわないか。
- 生成した内容の権利や責任の所在を、社内でどう整理するか。
法令や契約に関わる具体的な判断は個別の事情によるため、法務の担当者や専門家に確認してください。設計上の考え方は、個人情報の設計を入力フォームから削除までつなげる方法も参考になります。
これらの確認は、情報システム部門や法務との調整に時間がかかります。開発と並行して始めるのではなく、計画の段階で相談を始めておくと、途中で止まる危険が減ります。
実施と判断の流れ
準備が整ったら、次の順で進めます。
- 評価データで、最初の状態の結果を測る。これが比較の出発点になります。
- 指示の書き方、参照させる情報、前後の処理を調整し、そのたびに同じ評価データで測る。
- 一定の水準に達したら、実際の利用者に、実際の業務の中で使ってもらう。確認にかかる時間、修正した箇所、使わなかった場面を記録します。
- 誤りの例を集め、種類ごとに分ける。調整で減らせるもの、人の確認で補うもの、対象から外すべきものに分けます。
- 合否条件に照らして、進む、対象を絞る、止めるを判断する。
判断のときに見落としやすいのが、「対象を絞る」という選択肢です。全体では合格に届かなくても、入力の種類を限れば十分に使える、ということがあります。誤りの例を種類ごとに分けておくと、この判断ができます。
本番の設計で考えることは、生成AIのMVPで失敗時の仕事まで設計する考え方にまとめています。
よくある質問
Q. 評価データは、どのくらいの件数が必要ですか。
一律の件数は示せません。業務で起きる入力の種類を一通り含み、難しい場合や例外が入っていることが先です。種類ごとに結果を見たときに、傾向を読み取れるだけの数があるかで判断します。少数から始め、誤りが出た種類を追加していく進め方が現実的です。
Q. 精度が合格に届かない場合、モデルを変えれば解決しますか。
解決する場合もありますが、先に誤りの例を見てください。入力の情報が足りない、正解の基準が曖昧、参照させる情報が古い、といった原因であれば、モデルを変えるだけでは改善しにくくなります。原因を分けてから手段を選ぶほうが、時間と費用を使わずに済みます。
Q. 生成AIは短期間で試せるので、計画なしで始めてもよいのではないですか。
試すこと自体は問題ありません。手元で試して感触をつかむことは、問いを具体的にするのに役立ちます。ただし、予算と関係者の時間を使うPoCにする段階では、評価データと合否条件を決めてください。決めないまま試作を重ねると、良くなった気がする状態が続き、判断の日が来ません。
Otsumuに相談できること
Otsumuは、新規事業のMVPシステム開発（AIを活用した開発）と、自社サービス運用の自動化コンサルティングを、戦略と開発を分けずにひとつのチームで支援しています。PoC / MVP Sprintでは、検証目的・機能範囲の合意、主要画面と利用シナリオ、検証用のPoC / MVPシステム、効果測定の項目・計測設計、検証結果と次フェーズの改善方針などを成果物としています。参考価格は税別300万円〜、6週間を目安に設計し、機能数・外部連携・セキュリティ要件で変動します。クラウド利用料等は別途で、正式な見積もりは相談後です。秘密保持や成果物の取り扱いは、相談時に確認のうえ合意します。
評価データを作れる人が社内にいて、調整と計測を回せる体制があるなら、自社で進められます。どの業務から試すべきか、合否条件をどう置くかで迷っている場合は、30分の無料診断でお話をうかがいます。法人の新規事業・DX部門の方は、法人向けのページもご覧ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。記載の価格はOtsumuの税別・参考価格で、正式なお見積もりはご相談後にご案内します。法務・税務・会計・補助金などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.21