生成AIのPoC、本開発に進む前に確認したい5つの判断基準

生成AIのPoCから本開発へ進む判断には、回答品質・業務効果・情報管理・費用と速度・運用の5つを、同じ利用条件で確認することをおすすめします。デモで一度うまく回答できたことと、日々の業務で使い続けられることは、分けて評価する必要があります。

この記事は、社内問い合わせ対応や文書検索などの生成AI導入を検討する企業向けに、発注前の確認事項をFor fの視点で整理したものです。以下の5項目はFor fによる検討用の整理であり、公的な認証基準や、すべての業務に共通する合格ラインではありません。

PoCの目的は「できた」より「次を判断できる」こと

PoCは、小さな範囲で実現性や効果を確かめる検証です。たとえば社内文書に答えるAIなら、「質問に答えられるか」だけでなく、「どの資料を参照し、どの質問には答えられず、人の確認がどれだけ必要か」まで記録すると、本開発の範囲を決めやすくなります。

Google Cloudの評価ドキュメントでは、利用目的を反映した評価データを用意し、評価指標を決め、個々の回答と集計結果を確認する流れが示されています。公開ベンチマークだけでなく、自社の業務に合わせて検証する考え方が参考になります。出典：Google Cloud「Gen AI evaluation service overview」

本開発に進む前に確認したい5つの判断基準

発注企業と開発側で合意する、評価項目のたたき台

評価項目	PoCで確かめること	残しておく成果物
1. 回答品質	根拠に沿って回答できるか。答えられない質問を適切に扱えるか。	質問・期待する回答・実際の回答・判定理由
2. 業務効果	確認や修正を含めて、現場の作業が改善するか。	現行業務とAI利用時の作業手順・比較記録
3. 情報管理	利用者ごとの閲覧範囲や、機密情報の扱いを守れるか。	データの流れ・権限別テスト・未解決事項
4. 費用と速度	想定利用量で費用と待ち時間が許容できるか。	測定条件・利用量・費用の内訳・応答時間
5. 運用	資料やモデルを変更した後も、品質を確認できるか。	更新手順・再評価用データ・人へ戻す手順

1. 回答品質：正答率だけでなく、誤りの中身を見る

社内問い合わせなら、よくある質問だけでなく、資料に答えがない質問、古い資料と新しい資料で条件が違う質問、前提が不足した質問も用意します。評価する担当者と、何を正しい回答とするかを先に決めておきましょう。

NISTの生成AIプロファイルは、自信のある表現で誤った内容を生成するリスクを挙げ、狭い範囲の非体系的な評価から性能を一般化しないことや、生成内容の出典を確認することを提案しています。出典：NIST AI 600-1、2.2節・MS-2.5-001・MS-2.5-003

検討用の判定例として、「そのまま使える」「人が修正すれば使える」「回答を控えて担当者へ引き継ぐ」「誤った回答」のように分けると、改善が必要な箇所を話し合いやすくなります。これは運用に合わせて調整する分類例です。

2. 業務効果：人の確認時間まで含めて比べる

AIの回答が速くても、確認や書き直しに時間がかかれば、業務全体の負担は減らないかもしれません。現行の手順と、AIを使う手順について、入力・確認・修正・後処理まで比較します。

たとえば問い合わせ対応では、「回答案を作る時間」だけでなく、「根拠の確認」「担当部署への照会」「最終回答の修正」も記録する方法が考えられます。削減率を先に約束するのではなく、実際に測れる範囲と測定方法を合意することをおすすめします。

3. 情報管理：同じ質問を、違う権限でも試す

社内文書を扱う場合は、誰がどの資料を参照できるかを一覧にします。一般社員と管理者など、権限の異なる利用者で同じ質問を試し、回答だけでなく引用元やリンク先も確認します。入力データの保存先、ログの閲覧者、保存期間も検討項目です。

「答えが合っている」ことと「その人に見せてよい」ことを、別々の確認欄に分けると見落としを減らせます。実際の機密資料を検証に使う前に、共有できる範囲と取り扱い条件を社内・委託先で確認してください。

4. 費用と速度：利用量と測定条件をそろえる

費用は、モデルの利用料だけでなく、検索・データ保存・アプリの稼働・運用作業も分けて整理します。応答時間は短い質問と長い質問、少人数での利用と同時利用など、想定する条件を記録して比べましょう。

PoCの測定値をそのまま本番の費用とせず、「何人が、どの程度の頻度で、どの長さのデータを使うか」を明示した試算にします。サービス料金は変わるため、見積もり時点の公式料金と利用条件の再確認が必要です。この記事では未検証の費用・期間・性能数値は掲載していません。

5. 運用：更新した後に、もう一度確かめられるか

検証した質問と期待する回答、参照資料の版、利用したモデルや設定を残します。資料や設定を変更した際に、同じ質問で再評価できる状態を目指してください。誤回答が報告されたときの担当者と、AIを止めて人の対応へ切り替える方法も決めておきます。

Google Cloudは、生成AIの評価を開発の各段階で継続する取り組みとして説明しています。PoCの最後に一度判定するだけでなく、変更後も評価を繰り返す考え方が参考になります。出典：Google Cloud Blog「How good is your AI? Gen AI evaluation at every stage, explained」（2025年6月13日）

結果は「進む・追加検証・見送る」に分ける

For fでは、相談時の整理として、次のように結果を分けることを提案します。すべての項目を一つの平均点にまとめるより、重大な未解決事項を別に扱う方が、発注範囲を明確にできます。

• 本開発へ進む：合意した利用範囲で基準を満たし、残る課題と本開発の対応範囲を説明できる。
• 対象を絞って追加検証する：効果が見込める一方、資料整備や権限、回答品質などに未確認の点があり、追加で確かめる内容を特定できる。
• 導入を見送る・別の方法を検討する：業務上の利点が確認できない、または重要な課題を解決する見通しが立たない。

PoCを行ったからといって、必ず本開発へ進む必要はありません。進まない理由が明らかになることも、検証結果の一つです。

相談・見積もりの前に用意するとよいもの

• 対象業務と、現在困っていること
• 実際の質問や入力の例と、期待する出力
• 参照する資料と、利用者ごとの閲覧範囲
• 現行の作業手順、分かる範囲の件数や所要時間
• 希望時期、予算の考え方、今回の検証で判断したいこと

資料が揃っていなくても、現状から整理できます。依頼時は、対象範囲・評価方法・成果物・対象外の作業・次へ進む条件を明確にしておくと、PoCと本開発の見積もりを分けて検討しやすくなります。

よくあるご質問

正答率が高ければ、本開発に進んでよいですか？

正答率だけでは判断できません。誤りが起きる場面とその影響、情報管理、人の確認負担、費用、運用を、実際の利用条件に照らして確認してください。

合格ラインは何％にすればよいですか？

一律の数値をこの記事で設定することはできません。対象業務、誤りの影響、人が確認する範囲によって必要な基準が変わります。通常の質問への回答品質と、許されない情報開示などの重大な失敗を分けて設計することをおすすめします。

要件が決まっていなくても相談できますか？

はい。For fでは、現状の業務や課題から対象範囲を整理します。AI導入・業務整理から始めるか、AI PoC・実証検証として評価範囲を決めるか、検討状況に合わせてご相談いただけます。

AI PoC / NEXT STEP

「何を検証するか」から、ご一緒に。

For fは、AI導入・業務整理、PoC、本開発、データ基盤・分析を支援しています。対象業務と検証で判断したいことを伺い、必要な範囲・成果物・進め方を整理してご提案します。

AI PoCについて相談する ↗支援内容・成果物を見る ↗

検証結果をもとに進める場合は、AIシステム本開発もご覧ください。

参考資料・情報確認日

情報確認日：2026年9月7日。以下の公開資料を参照し、発注時の確認事項はFor fによる解説としてまとめています。サムネイルはAI生成による概念ビジュアルで、実際の評価結果やシステム画面を示すものではありません。

1. Google Cloud：Gen AI evaluation service overview — 評価データ・指標・結果の確認方法。
2. NIST AI 600-1：Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — 生成AIの誤情報に関するリスクと評価上の注意。2024年7月。
3. Google Cloud Blog：How good is your AI? Gen AI evaluation at every stage, explained — 開発段階を通じた評価。2025年6月13日。