生成AIのPoCで最初に止まるのは「何を試すか」です。便利そうだけで選ぶと、確認作業が増える検証になります。PoCは、価値を出せる業務と人の確認が不可欠な境界を知る実験です。
最初に外すべきテーマを決める
最初の候補から、取り消しにくい処理を外します。自動送信、採否の自動判定、確定処理、権限変更は小さな検証に向きません。データの所在・権限が不明な業務も止めます。
AI事業者ガイドライン第1.2版は、利用者を含め、ガバナンス、安全性、プライバシーを共通指針として整理しています[1]。PoCでも、速さと確認責任を分けます。
候補を集めるときは、部門ごとに「生成AIで何でもできるか」ではなく、現在の業務で繰り返している手順を書き出します。依頼を受ける、資料を探す、下書きを作る、確認して送る、といった単位に分ければ、AIに任せる部分と人が確定する部分を混ぜずに済みます。担当者の印象だけで候補を決めず、実際の入力、参照資料、承認者、例外処理を一つずつ確認します。
この段階で「便利だがPoCにしない」候補が出ても失敗ではありません。データの整理、権限設計、業務ルールの明文化が先に必要だと分かれば、それ自体が導入順序の判断材料になります。AIの出力品質と、業務へ安全に接続できる準備を一つの評価へ丸めないことが重要です。
候補を四つの軸で比べる
テーマは、四軸で比較します。
- 業務価値：何の待ち時間を変えるか。
- データ準備度：資料、権限、入力範囲を説明できるか。
- 確認負荷：誰が原資料へ戻るか。
- 実行意欲：実案件で試せるか。
Microsoftも、選定時に能力、データ、スキル、コストを確認するよう示しています[2]。四軸はその翻訳で、公式の採点表ではありません。
四軸を合計点だけで並べる必要はありません。たとえば業務価値が高くても、原資料へのアクセス権が整理されていなければ、今回はデータ整備を優先します。確認負荷が高い場合は、出力の利用範囲を下書きや論点抽出に限定して試します。反対に、データが整っていても利用者が自分の仕事として困っていなければ、研修後に使われない可能性があります。弱い軸ごとに「今回の検証で改善するのか、前提条件として別に解くのか」を記録します。
いちばん難しい工程を小さく試す
簡単な要約だけでは本番価値は分かりません。根拠資料の選別、例外の差戻し、入力可否を試します。Microsoftは、投資前に最難関工程を検証することを勧めています[3]。
研修も、対象業務を匿名化し、入力範囲、原資料との照合、判断不能時の相談を一つの演習にします。
たとえば問い合わせ回答の下書きを試すなら、正しい文案を生成できたかだけで終わらせません。参照すべき社内資料を選べたか、資料にないことを断定しなかったか、例外を誰へ渡すかまで確認します。要約業務なら、要点が短くなったかだけでなく、数字・固有名詞・期限を原文へ戻って確認できるかを見ます。最難関工程を避けたまま成功を宣言すると、本番展開後に確認者の負荷や誤利用が表面化します。
対象者は、ツールに詳しい人だけで固めません。実際にその業務を担い、例外や繁忙期を知る人を含めます。研修中に出た質問、止まった手順、判断が割れた例を、教材・利用ルール・データ整備のどこへ戻すか分類します。こうすると、受講満足度ではなく、導入を阻む具体的な条件を次の改善へ渡せます。
成功・停止・拡大を事前に置く
開始前に、「根拠を確認できない出力は採用しない」「判断不能時は有人レビューへ渡す」と決めます。NISTは利用文脈、ガバナンス、評価、管理を扱います[4]。記録と例外を残します。
終了時の選択肢も、成功か失敗かの二択にしません。価値と確認手順が両立した業務は、対象部門を限定して拡大します。価値はあるがデータや権限が未整備なら、前提を整えてから再試行します。確認負荷や影響が許容できない場合は、利用範囲を狭めるか停止します。この三つを事前に置くと、PoCを続けること自体が目的になるのを避けられます。
Google掲載のXero事例では、候補ツールを四段階評価し、四仮説を60日間、8部門の250人で検証しています[5]。成功人数の基準ではなく、仮説と評価条件を先に置く例です。
研修・導入を一つの反復にする
「便利だった」だけでは投資判断に足りません。価値が確認できたら広げ、準備が弱ければ整備へ戻り、確認負荷が高ければ範囲を狭めます。AIと人の判断の境界は自明ではありません[6]。
次の部門へ渡すのは、成功したプロンプト集だけではありません。対象業務、入力してよい情報、参照した原資料、確認者、例外、停止条件を短い実施記録として渡します。これがあれば、別部門は同じ失敗を繰り返さず、自分たちの業務差分だけを確かめられます。研修・業務設計・技術設定を別々の施策にせず、同じ検証記録から直すことが定着への近道です。
関連： 研修の効果測定、Copilot×BPR、Claude Code導入。
生成AIの導入テーマ・PoC設計を相談する
適用限界
小規模PoCは、全社ROI、長期定着、法令適合を証明しません。ベンダー事例も再現を保証しません。認証・権限、個人情報、外部送信など高影響の業務は、専門家レビューと技術統制を先に置きます。
一次情報と確認範囲
確認日：2026年9月17日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。