PoCの進め方5ステップ｜評価基準の具体例・評価シート・失注させない管理まで【2026年版】

編集部注: 本記事はデジタルセールスルーム（DSR）ツール「Terasu」を提供するTerasu編集部が作成しています。PoCの進め方・評価基準・費用の解説は特定ツールに依存しない一般論を基本とし、後半で「売り手（ベンダー営業）がPoCで失注しないための管理」にDSRを活用する実装例を紹介します。費用相場や統計は目安であり、個別の見積り・適法性判断は必ず各社の専門家にご確認ください。

「PoCをやることになったが、何から手をつければいいか分からない」——SaaSやITツールの導入を検討する買い手にも、それを提案する売り手（ベンダー営業）にも、共通する悩みです。

PoC（概念実証）は、正しく設計すれば「本番導入すべきか」を低リスクで見極められる強力な手段です。しかし多くの現場では、評価基準が曖昧なまま実施し、結局「なんとなく良かった気がする」で終わったり、逆に検証を延々と繰り返して本番に進まない「PoC地獄」に陥ったりします。

本記事では、PoCの進め方を5ステップで整理し、競合記事が曖昧にしがちな評価基準の具体例、そのまま使えるPoC評価シート、そして売り手がPoCで失注しないための管理までを、買い手・売り手の両視点で解説します。

PoCとは？意味・読み方・目的をまず整理

PoCとは、新しい技術・製品・アイデアが「本当に効果を出せるか」を、本格導入の前に小規模に検証する取り組みです。まずは言葉の意味と、混同しやすい隣接概念との違いを押さえておきましょう。PoCの定義や業界別の使われ方をより広く知りたい方は、PoCとは何かもあわせてご覧ください。

PoCの読み方と意味

PoCは「ポック」または「ピーオーシー」と読み、**Proof of Concept（概念実証）**の略です。「このアイデア・技術は、うちの現場で本当に機能するのか」という仮説を、実データ・実業務に近い環境で確かめる工程を指します。

PoCの目的は、製品を作り込むことでも、導入を既成事実化することでもありません。「本番導入すべきか（Go）／方針を変えるか（Pivot）／やめるか（Stop）」を判断するための材料を集めることが本質です。この目的を見失うと、PoCそのものがゴール化し、検証のための検証に陥ります。

PoV・PoB・MVP・プロトタイプ・トライアルとの違い

PoCは似た用語と混同されがちです。何を検証する工程なのかを区別しておくと、社内やベンダーとの会話がかみ合います。

SaaSやITツールの導入検討では、ベンダーが用意する無料トライアルや有償の評価版を使って自社データで検証すること自体が、事実上のPoCになります。「トライアルを申し込んだ」で終わらせず、評価基準を決めてPoCとして進めることが、失敗しない導入の分かれ目です。

なぜPoCが必要か／PoCが向くケース・向かないケース

PoCが必要な理由は、本番導入の失敗コストが大きいからです。全社に展開してから「現場で使われない」「既存システムと連携できない」と判明すれば、投資と時間が丸ごと無駄になります。PoCは、その失敗を「小さく・早く」体験して回避するための保険です。

ただし、あらゆる導入にPoCが必要なわけではありません。向くケースと向かないケースを見極めましょう。

「PoCをやること」自体が目的化して、判断が自明なものにまでPoCを課すと、導入が遅くなるだけです。不確実性が高く、投資が大きいところにこそPoCを使う——これが基本方針です。

PoCの進め方 5ステップ【全体像】

PoCは、次の5ステップで進めます。競合記事の多くは各ステップの「所要期間の目安」を書きませんが、計画を立てるうえで重要なので、あわせて示します。

期間はスコープと組織の意思決定スピードで大きく変わります。AI関連のPoCでは全体で3〜6ヶ月が一つの目安とされますが、SaaSツールのトライアル型PoCなら2〜4週間で完結することも珍しくありません。重要なのは開始前に「いつ判定するか」という締め切り（タイムボックス）を決めておくことです。締め切りがないPoCは、後述するPoC地獄の入り口になります。

STEP1 目的・仮説を定義する

最初のステップは、「何のためにPoCをやるのか」を1〜2文で言い切れるまで具体化することです。ここが曖昧だと、後続のすべてがぶれます。

目的定義では、次の3点をセットで言語化します。

• 検証したい問い（What）: 例「問い合わせ対応の一次回答をAIで自動化し、応答品質を保てるか」
• なぜ検証するのか（Why）: 例「一次回答の工数が月200時間かかり、削減余地が大きいから」
• 検証仮説（Hypothesis）: 例「定型的な問い合わせの7割はAIで自動応答でき、品質は現行と同等に保てるはず」

ポイントは、仮説を「検証可能な形」で書くことです。「AIで業務を効率化できるか」では漠然としすぎて、後で合否を判定できません。「定型問い合わせの7割を自動化」のように、数字と対象範囲を含めて仮説化します。

曖昧な目的と、検証可能な目的の違いを具体例で見てみましょう。

右側はいずれも「対象・数字・期間」が入っており、実施後に合否を判定できます。目的を書いたら、「これは終わったときにYes/Noで答えられるか」を自問してください。答えられないなら、まだ具体化が足りません。

ここでよくある失敗が、PoCの目的に「製品の導入」を据えてしまうことです。導入ありきでPoCを始めると、都合の良いデータだけを見て「成功」と結論づけてしまい、本番で破綻します。目的はあくまで「導入すべきかを判断すること」に置きます。売り手（ベンダー営業）の立場でも、この目的定義を買い手と一緒に作れるかどうかが、その後のPoCを主導できるかの分かれ目になります。

STEP2 評価基準（合否ライン）を設定する

PoCの成否を最も左右するのが、この評価基準の設定です。 多くの解説記事は「成功基準を事前に決めましょう」で終わりますが、実務で困るのは「では具体的に何を、どの水準で測ればいいのか」です。ここを埋めます。

評価基準は、次の5つの観点から設計します。各観点について「指標」と「合格ライン」、そして「どう測るか（測定方法）」を、PoC開始前にセットで決めておくのが鉄則です。

すべての観点を満点で満たす必要はありません。「絶対に外せない必須条件（Must）」と「あれば望ましい条件（Want）」を分け、Mustを1つでも割ったら不合格、というルールにしておくと、判定がぶれません。たとえば「既存CRMと連携できること」はMust、「レポート機能が高機能なこと」はWant、といった具合です。

数値の合格ラインは、導入前のベースライン（現状値）を計測してから決めるのが正確です。「工数を30%削減」と言うためには、まず現状の工数を測る必要があります。ベースラインなしの目標は、達成したのかどうかすら判断できません。

評価基準は「後から都合よく変えない」ことが最重要です。 PoCの結果が芳しくないときに合格ラインを下げるのは、検証の意味を失わせる典型的なアンチパターンです。基準は開始前に関係者全員（買い手側の決裁者・現場、売り手側の営業）で合意し、記録に残しておきましょう。

なお、合格ラインの水準感に迷ったら、次の考え方が目安になります。①課題解決度・効果は「現状より明確に改善したと言える最低ライン」を置く（現状維持では投資する意味がないため）。②技術的実現性は妥協できないMust条件が多く、基本は「できる／できない」の二値で判定する。③運用フィットは現場の主観が入るため、「継続利用したいと答えた人の割合」のように定量化する。④コスト対効果は回収期間（何ヶ月で投資を回収できるか）で見ると、他の投資案件と横並びで比較しやすくなります。⑤定着可能性は、導入初期のつまずき（学習コスト・サポートの手厚さ）を軽視すると本番で使われなくなるため、必ず基準に含めます。

STEP3 体制をつくる（買い手・売り手の役割）

PoCは技術検証であると同時に、組織の合意形成プロセスでもあります。「誰が評価し、誰がGo/Stopを判断するか」を決めずに始めると、結果が出ても意思決定が宙に浮きます。

PoCの体制は、買い手側・売り手側それぞれに役割があります。SaaS導入のPoCでは、この両者がかみ合って初めて機能します。

とくに見落とされがちなのが、買い手側の「決裁者を早期に巻き込む」ことです。決裁権を持つ層がPoCの目的と評価基準に合意していないと、良い結果が出ても「聞いていない」「予算がない」で本番移行が止まります。後述するPoC地獄の主因の一つが、この経営層・決裁者の不在です。

売り手側から見れば、PoC責任者だけでなく決裁者との接点を持ち、評価軸を握れているかが、そのまま受注確度に直結します。エンタープライズ領域で複数部門が絡む意思決定をどう乗り越えるかは、エンタープライズSaaSのDSR導入事例で具体的に解説しています。

STEP4 PoCを実施する（スコープ・期間・データ収集）

体制と基準が整ったら、いよいよ実施です。実施フェーズの成否は、スコープを絞れるかにかかっています。

• スコープを最小限に絞る: 全機能・全部門ではなく、「最も効果が見込める1業務・1チーム」に絞る。欲張ると検証が長期化し、評価もぼやけます。
• 本番に近い環境・データで検証する: 理想的なサンプルデータではなく、実際の業務データ・実際のユーザーで試す。きれいすぎる環境での「成功」は本番で再現しません。
• 評価に必要なデータを計測し続ける: STEP2で決めた指標を、実施中ずっと記録します。「終わってから振り返る」のではなく、途中経過を可視化しておくと、判定がスムーズです。
• タイムボックスを守る: 「もう少し改善できるかも」と延長を繰り返さない。決めた期間で一度必ず判定に進みます。

データ収集では、「定量データ」と「定性データ」の両方を集めるのがコツです。定量データ（工数・精度・処理時間など）は合否判定の根拠になり、定性データ（現場の声・つまずいた場面・要望）は、なぜその数字になったかを説明し、本番導入後の改善ポイントを教えてくれます。定量だけだと「なぜダメだったか」が分からず、定性だけだと「本当に効果があったか」を証明できません。

具体的には、次のような形で記録を残しておくと、判定フェーズがスムーズです。

• ベースライン: 検証開始前の現状値（STEP2で計測済みの数字）
• 検証中の実測値: 指標ごとに、できれば日次・週次で推移を記録
• 現場フィードバック: 操作でつまずいた場面、良かった点、要望を都度メモ
• 想定外の事象: 計画になかったトラブルや発見（本番リスクの重要な手がかり）

実施中に問題が起きたときは、「これはMust条件に関わるか、Want条件か」で切り分けます。Mustに関わる問題（例：基幹システムと連携できない）は本番導入の可否を左右するので徹底検証、Wantの問題（例：画面が少し使いにくい）は改善要望として記録するだけにとどめ、検証を止めないようにします。この切り分けができないと、些細な使い勝手の不満で検証全体が停滞し、判定が先送りになります。

STEP5 結果を判定する（Go/Pivot/Stop）

最後に、集めたデータを評価基準に照らして判定します。判定は「成功／失敗」の二択ではなく、Go/Pivot/Stopの3択で考えると、次のアクションが明確になります。

判定で重要なのは、「Pivot」と「Stop」を明確に区別することです。曖昧なまま「もう一回やってみよう」を繰り返すと、Pivotのつもりが延々と続くPoC地獄になります。Pivotするなら「何を変えて、次はどの基準で判定するか」を必ず決め直します。

判定結果は、数字と根拠をセットにした簡潔なレポートにまとめ、決裁者が意思決定できる形にします。ここで「レポートを作って終わり」にせず、Goなら本番導入の次アクション、Stopなら学びの記録まで残すのが、投資を無駄にしないコツです。

判定レポートに最低限含めたいのは、次の4点です。①検証目的と仮説（何を確かめようとしたか）、②評価基準ごとの実測値と合否、③総合判定（Go/Pivot/Stop）とその理由、④次アクションと担当・期限。とくに決裁者向けには、細かな検証ログよりも「Must条件を満たしたか」「投資回収の見込みはどうか」を先頭に置くと、判断が早まります。逆に、この4点が揃っていないレポートは、決裁者が判断できず「持ち帰り」となり、そのまま案件が止まる原因になります。

PoC評価シートの作り方【テンプレート】

評価基準を「その場の感覚」で運用すると、関係者の主観がぶつかって合意できません。評価シートを使い、観点ごとにスコアと重みをつけて合議するのが有効です。

以下は、そのまま流用できるPoC評価シートの構造です。表計算ソフトに落とし込んで使ってください。

【PoC評価シート】

■ 基本情報
  - 検証対象製品／技術：
  - 検証目的（1〜2文）：
  - 検証期間：____年__月__日 〜 ____年__月__日
  - 評価者：買い手PM／現場／情シス／決裁者

■ 評価基準（開始前に確定・変更禁止）
  観点              | 種別  | 指標          | 合格ライン    | 重み
  ①課題解決度・効果  | Must | 工数削減率    | 30%以上       | 30%
  ②技術的実現性      | Must | CRM連携・エラー率 | 連携可・5%未満 | 25%
  ③運用フィット      | Want | 継続利用意向  | 現場8割       | 20%
  ④コスト対効果      | Must | 投資回収期間  | 12ヶ月以内    | 15%
  ⑤定着可能性        | Want | 習得時間      | 研修30分      | 10%

■ 判定（実施後に記入）
  観点              | 実測値 | 合否 | スコア(0〜5) | 重み付きスコア
  ①課題解決度・効果  |        |      |             |
  ②技術的実現性      |        |      |             |
  ③運用フィット      |        |      |             |
  ④コスト対効果      |        |      |             |
  ⑤定着可能性        |        |      |             |
  ─────────────────────────────────────
  合計重み付きスコア：____ / 5.0

■ 総合判定（Must条件が1つでも不合格なら自動的にStop/Pivot）
  □ Go（本番へ）  □ Pivot（方針変更）  □ Stop（中止）
  判定理由：
  次アクション：

このシートの肝は、Must条件を1つでも割ったら、重み付きスコアがいくら高くても自動的にGoにしないという運用ルールです。「総合点は高いが基幹連携ができない」ようなケースを、スコアの高さでごまかさないための歯止めです。

記事末尾で、この構造をそのまま使えるPoC評価シートのダウンロードをご案内しています。

PoCの費用相場と期間の目安

PoCにかかる費用は、検証の規模・技術の複雑さ・外部委託の有無で大きく変わります。あくまで公開されている相場感の目安ですが、規模別に整理すると次の通りです。

費用の多くは人件費が占めます。SaaSツールの導入検討であれば、ベンダーの無料トライアルや評価版を使い、自社の担当者が主体で回すことで、費用をほとんどかけずにPoCを実施できるケースも多くあります。**「まず自社の手で無料トライアルを評価基準に沿って回す」→「必要なら有償の本格検証に進む」**という段階設計が、コストを抑えるうえで有効です。

なお、AI関連のPoCは、外部予測でも導入のハードルが高いことが示されています。米調査会社ガートナーは2024年、「2025年末までに、少なくとも30%の生成AIプロジェクトが概念実証（PoC）の後に放棄される」と予測しました（出典: Gartner, 2024年7月）。PoCに投資する前に、評価基準と本番移行のルールを固めておくことの重要性を裏づけるデータです。

PoCが失敗する原因と対策（PoC地獄を抜ける）

PoC地獄とは、PoCを繰り返しても本番導入に進まず、実証段階で停滞し続ける状態を指します。PoCが本番の成果に結びつきにくいことは、データにも表れています。前掲のガートナー予測では、生成AIプロジェクトの少なくとも30%が2025年末までにPoC後に放棄されると見込まれています（出典: Gartner, 2024年7月）。またDX全般に視野を広げても、独立行政法人IPAの『DX白書2023』では、DXの取り組みで「成果が出ている」と回答した日本企業は58.0%にとどまり、裏を返せば約4割は十分な成果に至っていません（出典: IPA『DX白書2023』, 2022年度調査）。いずれもPoC単体の失敗率を示す数字ではありませんが、「試したものを本番の成果に変える」ことの難しさを裏づけています。

PoCが失敗する原因は、技術そのものよりも「設計と運用の欠陥」にあります。主要な失敗パターンを、原因・兆候・対策の因果でまとめます。

これらに共通する処方箋は、**「開始前に、評価基準と本番移行の判断ルールを決めておく」**という一点に集約されます。PoC地獄の多くは、検証を始めてしまってから基準や体制を考えようとするために起きます。導入後に失敗する典型パターンとその回避策は、DSR導入が失敗する原因でも詳しく整理しています。

【売り手向け】PoCを失注させない管理

ここまでは主に買い手（導入検討者）の視点でしたが、SaaSやITを提案する売り手（ベンダー営業）にとって、PoCは受注の最大の山場です。PoCがうまく回れば受注に直結し、逆にPoC地獄に付き合わされれば、案件は塩漬けになり失注します。

売り手がPoCで管理すべきことは、次の4つです。

• 評価軸を握る: 買い手の評価基準づくりを支援し、自社製品が正当に評価される観点（Must条件）をすり合わせておく。基準が曖昧なPoCは、判断されずに流れます。
• 決裁者との接点を持つ: PoC責任者だけでなく、Go/No-goを出す決裁者に評価軸と進捗が共有されている状態をつくる。決裁者不在のPoCは、成功しても本番に進みません。
• 進捗と次アクションを可視化する: 「今どのステップで、次に誰が何をするか」を常に明示する。買い手の検討が沈黙したまま放置されると、そのまま失注します。
• 温度の低下を早期に検知する: 買い手側の反応が鈍くなった兆候（資料が見られない、返信が遅い）を掴み、手を打つ。

これらを属人的な勘や、メール・チャットの追いかけで管理するのは限界があります。ここで有効なのが、デジタルセールスルーム（DSR）でPoCを一元管理するアプローチです。

Terasuのようなデジタルセールスルームでは、顧客ごとに専用の「PoC Room」を作り、検証に必要な資料・評価軸・スケジュール・次アクションを1か所に集約できます。さらに、送った提案資料や評価シートを「誰が・どのページを・いつ見たか」まで追跡できるため、買い手側の検討状況（＝温度）が可視化されます。決裁者が資料を見ているか、現場の関心が続いているか——これまで見えなかった検討の中身が分かるので、沈黙による失注を防ぎ、次の一手を打てます。

PoC Roomの使い方を、PoCの5ステップに沿って具体化すると次のようになります。

たとえば、決裁者を招待したのに一度も資料が閲覧されていなければ、それは「決裁者が検討に入っていない」危険信号です。逆に、特定のページ（たとえば料金や連携仕様）が繰り返し見られていれば、そこが買い手の関心事・懸念点だと分かり、次の商談で先回りして手を打てます。PoCの温度を「勘」ではなく「行動データ」で掴めることが、DSRでPoCを管理する最大の利点です。

PoCを商談プロセスのどこに位置づけ、どう前に進めるかは、BtoB営業プロセスの設計や商談の進捗を可視化する方法とあわせて設計すると、失注リスクをさらに下げられます。DSRそのものの全体像はデジタルセールスルーム完全ガイドで解説しています。

PoCの後にやること（本番導入の判断と進め方）

「PoCのあとは何をすればいいか」という問いへの答えは、Go/Pivot/StopそれぞれでSTEP5の判定表に示したとおりです。ここで強調したいのは、Go判定が出ても、いきなり全社展開しないことです。

PoCが成功しても、本番環境では検証時に見えなかった負荷・例外・運用の壁が現れます。そこで、Goの後にMVP（最小構成での本番運用）や一部門での先行導入を挟むと、スケールアップ時のリスクをさらに下げられます。小さく始めて、成果を確認しながら広げるのが定石です。

全社展開に進む場合は、規模に応じた導入期間の見積もりが欠かせません。企業規模別の導入スケジュールと、期間を短縮するコツは、DSR導入期間の比較で詳しく解説しています。なお、複数部門が関与する大型案件で、PoCから本番導入までの意思決定をどう前に進めたかは、エンタープライズSaaSのDSR導入事例（商談サイクル40%短縮）が参考になります。

まとめ

PoCの進め方は、①目的・仮説の定義 → ②評価基準の設定 → ③体制づくり → ④実施 → ⑤判定、の5ステップです。成否を分ける最大のポイントは、開始前に「合格ライン（評価基準）」と「本番移行の判断ルール（Go/Pivot/Stop）」を決めておくことに尽きます。

• 評価基準は「観点×指標×合格ライン×測定方法」で具体化し、Must/Wantを分ける
• 決裁者を早期に巻き込み、タイムボックスを守る
• 売り手は評価軸を握り、進捗・温度を可視化して失注を防ぐ

これらを押さえれば、「なんとなく良かった」で終わるPoCも、延々と続くPoC地獄も回避できます。まずは本記事のPoC評価シートを使って、あなたの検証の合格ラインを言語化するところから始めてみてください。