【プロンプト付き】PoCが「試して終わり」になる。AIとつくる検証計画7項目

「まずはトライアルで試してみましょう」

商談終盤で、この言葉が出ると少し安心します。

契約には至っていないものの、お客様が前向きに検討しているように見えるからです。

ところが、1か月後。

利用した人は数名。感想は「便利そう」「もう少し使ってみないと分からない」。本導入するか、条件を変えて再検証するか、見送るかを誰も決められません。

トライアルを実施した事実だけが残ります。

問題は、使い方の説明が足りなかったことだけではありません開始前に「検証後、何を判断するのか」を決めていないことです。

PoCはProof of Conceptの略で、日本語では概念実証と呼ばれます。アイデアや製品が、限られた条件の中で成立するかを確かめる取り組みです。

トライアルやパイロットも厳密には意味が異なりますが、営業現場では、導入前に実際の業務や利用者で確かめる場面として扱われることが多いでしょう。

この記事では便宜上、PoC、トライアル、パイロットをまとめて「検証」と表現します。

扱うのは、技術検証の手順だけではありません。

お客様が本導入、条件変更、再検証、見送りを判断できるように、営業がAIと一緒に検証計画をつくる方法です。

本文の事例は説明用の架空例です。実在する顧客、製品、社内運用を示すものではありません。

PoCの成果は「成功」ではなく「判断できること」

PoCは、成功を証明するイベントだと思われがちです。

しかし、検証を成功させること自体を目的にすると、簡単な対象だけを選ぶ、都合のよいデータだけを使う、問題が出ないように条件を整える、といった動きが起きます。

見栄えのよいデモは完成しても、本番で使えるかは分かりません。

Microsoftの公式ガイダンスでは、PoCは未確認の前提を検証する限定的な実装であり、開始前に目的、範囲、使用データ、実演方法、環境、成功条件を定めることが勧められています。

また、失敗を早期に特定することも、期待どおり動かない解決策への追加投資を避けるための成果とされています。Microsoft Learn

つまり、PoCの合格点は「問題なく動いた」ではありません。

ここが出発点です。

「何を試すか」より先に「何を決めるか」を置く

営業がPoCの相談を受けると、機能、アカウント数、期間、操作説明の日程から決めがちです。

しかし、これらは検証手段です。

先に置くのは、検証後の意思決定です。

たとえば「AI議事録機能を試す」では、終わり方が分かりません。

「商談後の記録作成をAIで支援した場合、営業担当が内容を確認・修正したうえで、現在の品質を維持しながら登録負担を減らせるかを判断する」と置けば、測るものが見えてきます。

• 現在、記録にどれくらい時間がかかっているか

• どの項目をAIが作り、どこを人が確認するか

• 顧客発言や次の行動を正しく記録できるか

• 修正時間を含めて負担が減るか

• 機密情報や誤記録のリスクを管理できるか

• 利用者が実際の業務で継続できるか

判断を先に置くと、検証範囲を増やす誘惑にも耐えやすくなります。

開始前に合意するPoC設計7項目

PoC計画は、次の7項目で整理します。

1．判断：検証後に何を決めるのか

最初に、検証後の選択肢を書きます。

• 現在の条件で本導入する

• 対象者、機能、業務範囲を変えて導入する

• 不足条件を整えて再検証する

• 現時点では導入しない

「本導入するか」だけでは、期待に届かなかったときの分岐がありません。

条件変更や再検証、見送りも最初から選択肢に入れます。見送りを失敗扱いしないことが、率直な検証につながります。

2．仮説：何が分かっておらず、何を確かめるのか

PoCは、製品紹介の延長ではありません。未確認の仮説を確かめるものです。

仮説は「事実」「顧客発言」「営業の見立て」「未確認」に分けます。

架空例なら、次のようになります。

• 事実：営業担当は商談後にCRMへ活動記録を入力している

• 顧客発言：「記録に時間がかかり、後回しになることがある」

• 営業の見立て：AIで下書きを作れば登録負担が減る可能性がある

• 未確認：修正時間を含めても負担が減るか、記録品質を維持できるか

営業の見立てを、顧客課題として確定させないことが大切です。

3．範囲：誰が、どの業務を、どこまで試すのか

範囲を広げるほど、本番に近づくとは限りません。原因を切り分けにくくなります。

• 対象業務

• 対象部門・利用者

• 利用件数やケース

• 検証する機能

• 対象外にする業務・機能

• 本番導入との違い

参加者は、協力的な人だけで固めないようにします。

一方で、いきなり全社へ広げる必要もありません。「小さいが、判断には使える範囲」を選びます。

4．条件：データ、環境、支援をそろえる

結果を解釈するために、検証条件を記録します。

• 使用するデータと期間

• 実データ、サンプル、合成データの区別

• 本番環境と検証環境の違い

• 権限、連携、セキュリティ上の制約

• 操作説明や伴走支援の内容

• 比較対象となる現在の業務

サンプルデータで動いたからといって、本番の量、品質、例外に耐えられるとは限りません。
反対に、準備不足で使えなかった場合も、製品そのものの限界とは限りません。

条件を残しておけば、「何が原因で結果が出たか」を分けやすくなります。

5．基準：成功、条件付き、見送りをどう判定するか

成功条件は「担当者が便利だと感じた」だけでは足りません。

次の三層で設定します。

• 業務：時間、手戻り、処理件数、抜け漏れなど

• 利用：対象者が決めた場面で使えたか、継続できたか

• 品質・リスク：正確性、セキュリティ、性能、承認手順など

架空のAI議事録検証なら、次のような基準が考えられます。

• 業務：確認・修正を含む記録時間を、現行方法と比較できる

• 利用：対象者が指定した商談で利用し、使わなかった理由も記録できる

• 品質：顧客発言、決定事項、宿題について、誤りの種類と修正量を確認できる

• リスク：顧客情報の入力、保存、共有について社内基準を満たす

ここで特定の削減率を勝手に置いてはいけません。

現状値、顧客の期待、投資規模を踏まえて、お客様と合意します。測定できないものは、数値目標のように装わず、観察方法や質問を決めます。

また、「成功」と「失敗」の二択にしないことも有効です。

• 基準を満たした：本導入の手続きへ

• 一部を満たした：条件変更または追加確認

• 満たさなかった：見送り、原因確認

• 判定できない：データ不足を明示し、再検証の必要性を判断

判定できない状態を、無理に成功へ寄せない。ここに営業の誠実さが出ます。

6．運営：誰が、いつ、何を記録するか

PoCの途中で問題が出ても、最終日にまとめて聞けば原因を追えません。

• 顧客側の責任者

• 実利用者

• 技術・セキュリティ担当

• 営業、プリセールス、CS、サポート

• 定例確認の頻度

• 問題・要望・質問の記録場所

• 変更を承認する人

フィードバックは、感想だけでなく場面と一緒に残します。

「使いづらい」ではなく、「どの業務で、何をしようとしたとき、どこで止まり、代わりに何をしたか」です。

AIは記録の分類や未回答事項の整理に使えます。ただし、顧客の感情、問題の原因、要望の優先度を断定させません。

7．終了：いつ終え、結果をどう判断につなげるか

終了日は、利用期限を知らせるためだけに置くものではありません。

いつデータ収集を終え、誰が評価し、どの会議で判断するかまで決めます。

• 検証の開始日・終了日

• 中間レビュー日

• 結果を集計する担当者

• 最終レビューの参加者

• 本導入、条件変更、再検証、見送りの次の行動

• 検証環境やデータの削除・返却

Microsoftの公式資料でも、PoCがいつ終了し、その後の正式な開発や展開へどう移るかを明確にすることが勧められています。Microsoft Learn

検証が終わってから「で、どうしましょうか」と聞かないための設計です。

顧客との合意に使える会話例

PoCを提案するときは、機能説明の前に判断をそろえます。

成功条件を決める場面では、営業側の数字を押しつけません。

途中で想定外の課題が出たときは、隠さず分類しましょう。

実践プロンプト1：PoCで検証すべき仮説を整理する

人が判断するのは、そもそもPoCが必要か、通常の説明や確認で足りるか、どの不確実性に時間と費用を使うかです。

実践プロンプト2：7項目の検証計画をつくる

AIが作るのは、合意のたたき台です。

検証期間、無償・有償の条件、提供範囲、セキュリティ対応は、権限を持つ人が確定します。

実践プロンプト3：途中レビューから未確認事項を見つける

実践プロンプト4：最終報告を導入提案ではなく判断資料にする

AIに任せること、人が引き受けること

AIに任せやすいのは、記録の整理、仮説と事実の分類、抜けている項目の指摘、評価表や会議案の下書きです。

営業が考えるのは、PoCで解くべき不確実性、顧客にとっての判断、検証範囲、次の選択肢です。

実利用者は、現場で起きたことと使わなかった理由を伝えます。技術、セキュリティ、法務、製品部門は、それぞれの条件と制約を確認します。

最終判断をするのは、お客様です。

AIは「導入すべき」と決めません。利用者の意欲や顧客の本音も推測しません。

営業も、受注のために成功条件を後から変えない。結果が厳しければ、条件変更や見送りを含めて説明する。

判断に耐える検証。そこまで設計して、PoCは営業活動になります。

今日の一歩

進行中のPoCやトライアルがあれば、計画書を開いてください。

そして、最初の1行を確認します。

「この検証が終わったとき、誰が、何を決めるのか」

答えが書かれていなければ、機能やスケジュールを増やす前に、その1行を顧客と合意します。

PoCは、製品を気に入ってもらう期間ではありません。不確実なことを減らし、次へ進むかを決める期間です。