新規事業のPoCとは｜確かめることとMVPとの使い分け

新規事業のPoCは、アイデアや技術が「実際にできるのか」を、小さな規模で確かめる段階です。この記事では、PoCで何を確かめるのか、プロトタイプやMVPとどう違うのか、どの順番で使い分けるのかを整理します。PoCを「やること自体が目的」にしないための、事前の決めごとも取り上げます。

新規事業のPoCとは何か

PoCは「Proof of Concept」の略で、日本語では「概念実証」と訳されます。頭の中にある構想や、これまで試したことのない技術が、現実の条件で成り立つのかを確かめる取り組みです。

もともとは研究開発や製造、システム開発の現場で使われてきた言葉です。「理屈の上では可能なはずだが、実際にやってみないと分からない」という点を、本格的な投資の前に小さく試す、という意味合いがあります。

新規事業の文脈でも考え方は同じです。事業としての全体像を作り込む前に、「この前提が成り立たなければ事業そのものが成り立たない」という部分だけを切り出して、先に確かめます。

PoCが対象にする範囲

PoCは、事業全体を検証するものではありません。確かめる対象は、次のような「成り立つかどうかが分からない一点」に絞るのが基本です。

• 使いたいデータが、実際に取得できるか
• AIや外部サービスの出力が、事業で使える水準に届くか
• 既存の設備や他システムと、つなぐことができるか
• 想定している処理が、現実的な時間と手間で終わるか

「これができなければ、その先を考えても意味がない」という前提を先に確かめておけば、大きな投資をしたあとで前提が崩れる事態を避けやすくなります。

新規事業で「PoC」と呼ばれるものの幅広さ

実務では、PoCという言葉がかなり広い意味で使われています。技術の検証だけでなく、「少人数の顧客に試してもらう」「画面を作って見せる」といった取り組みまでPoCと呼ばれることがあります。

言葉の幅が広いぶん、社内で「PoCをやろう」と言ったときに、人によって思い描いている中身が違うことがあります。ある人は技術の実験を、別の人は顧客への見せ方の確認を想像している、といった具合です。ここがそろっていないと、PoCを終えても「結局、何が分かったのか」が曖昧になりがちです。

PoCで確かめる3つの問い

新規事業のアイデアは、大きく3つの問いに分けて考えると整理しやすくなります。PoCが主に受け持つのは、このうち最初の問いです。

1. 技術的にできるのか（実現性）

構想を支える技術やデータが、現実に使えるかどうかの問いです。生成AIを使ったサービスなら、期待する品質の出力が安定して得られるか。外部のAPI（他のシステムの機能を呼び出す窓口）を使うなら、必要な情報が必要な頻度で取れるか。こうした点が該当します。

この問いは、顧客に見せる画面がなくても確かめられることが多く、PoCの典型的な守備範囲です。

2. 使う人に価値があるのか（受容性）

技術的にできても、使う人が「ほしい」「使い続けたい」と感じなければ事業にはなりません。ここで確かめるのは、課題が本当にあるか、提案する形が課題に合っているか、という点です。

この問いは、実際に触れる形を見せたときの反応から分かることが多く、プロトタイプやMVPが力を発揮する領域です。

3. 事業として成り立つのか（事業性）

価値を感じてもらえたとして、それが継続的な収益や利用につながるか、運営の手間と釣り合うか、という問いです。実際に利用が積み上がるかどうかの観測が必要になるため、MVPや小さな公開の段階で確かめていく範囲になります。

3つの問いは順番に並んでいますが、新規事業ごとに「いちばん不確かなのはどれか」は違います。技術に不確かさが集中している事業ならPoCから、需要に不確かさが集中している事業ならプロトタイプやMVPから始める、というように、出発点が変わります。

PoC・プロトタイプ・MVPの違いと使い分け

3つの言葉は混同されやすいのですが、「何を確かめるか」で整理すると違いがはっきりします。

呼び方	主に確かめること	相手	成果物のイメージ
PoC（概念実証）	技術的に成り立つか	社内・開発側	検証用の仕組み、検証結果の記録
プロトタイプ（試作）	形にしたときの使い勝手・伝わり方	決裁者・利用者候補	実際に触れる試作品
MVP（実用最小限の製品）	顧客が価値を感じて使い続けるか	実際の顧客	最小限の機能で公開できる製品

プロトタイプとMVPの違いは、別の記事「プロトタイプとモックアップ・MVPの違い｜新規事業の使い分け」でも詳しく扱っています。ここではPoCとの関係に絞って整理します。

「何を確かめたいか」から選ぶ

使い分けの基準は、製品の完成度ではなく、確かめたい中身です。

• 「そもそも技術的に可能か分からない」→ PoC
• 「形にしたら伝わるか、使いやすいか分からない」→ プロトタイプ
• 「顧客が実際に使い続けるか分からない」→ MVP

たとえば、既存システムとの連携がうまくいくか分からない場合に、きれいな画面を作り込んでも意味がありません。逆に、技術的な不安がほとんどなく、顧客が興味を持つかが最大の不確かさなら、PoCに時間をかけるより、早く触れる形を見せたほうが多くのことが分かります。

3つは前後の関係ではなく、重なることもある

3つは必ずしも「PoC → プロトタイプ → MVP」の一方向ではありません。実際には次のように重なります。

• PoCの結果を見せるために、簡単な画面を付けたプロトタイプにする
• プロトタイプを触ってもらった結果、技術面の不安が新しく見つかり、PoCに戻る
• MVPを公開してみて、特定の機能の精度が足りないと分かり、その部分だけPoCをやり直す

「試作の形」を取っていても、確かめている中身が技術なのか、使い勝手なのか、需要なのかで、呼び方と評価の仕方が変わる、と捉えると混乱しにくくなります。

MVPで最初に何を作り、何を後回しにするかは、「MVP開発の機能の絞り方｜最初に作るものと後回しの基準」で整理しています。

PoCが「やって終わり」になりやすい理由

PoCは小さく始められるぶん、次のような形で行き詰まることがあります。この点は「PoC失敗で終わる新規事業の共通点と本開発への進み方」でも取り上げていますが、ここでは原因を3つに絞って整理します。

目的と判断基準が曖昧なまま始まる

「AIでできそうか試してみよう」という動機で始めると、終わったときに「できた」「できなかった」を判断する基準がありません。結果として、「まあまあ良さそう」という感想だけが残り、次に進む根拠にも、やめる根拠にもなりません。

技術の確認だけで終わり、事業の問いにつながらない

PoCで技術的な実現性が確認できても、それが事業の収益や顧客価値にどう関わるかが整理されていないと、次の投資判断ができません。「技術的にはできる」ことと「事業として進める」ことの間には、別の問いが残っているためです。

決裁者に伝わる形になっていない

PoCの成果は、検証用のコードや数値の記録といった形で残ることが多く、技術に詳しくない決裁者には判断材料になりにくい面があります。企画書だけでは伝わりにくいという課題は、「新規事業の決裁を企画書だけで取るのが難しい理由」でも触れた通りです。PoCの成果も、実際に動く形で見せたほうが、意思決定の場で共有しやすくなります。

PoCを始める前に決めておきたい5つのこと

PoCが成果につながるかどうかは、始める前の準備でほぼ決まります。次の5点を、短い文章でもよいので書き出しておくと、途中でぶれにくくなります。

1. 確かめたい一点を、一文で書く

「顧客からの問い合わせ文を、AIが9割の精度で分類できるか」のように、検証したい点を1つの文にします。複数の問いを抱え込むと、PoCが長引き、どれも中途半端に終わります。なお、ここでの「9割」は説明のための例であり、実際の水準は事業ごとに決めるものです。

2. 「できた」の基準を数字か状態で決める

精度、処理時間、取得できたデータの件数、担当者が手作業でやるより手間が減ったか、など、結果を見て「成功」「失敗」を分けられる基準を先に置きます。基準を後から決めると、結果に合わせて都合よく解釈してしまいやすくなります。判断基準の作り方は「MVP検証の指標を先に決める方法｜判断基準の作り方」が参考になります。

3. 期間と使う範囲を区切る

PoCは「いつまでに、どこまで」を決めないと、際限なく広がります。期間を短く区切り、検証に使うデータや機能の範囲も限定します。区切ることで、「ここまでやって分からなければ見直す」という判断ができるようになります。

4. 結果ごとの次の動きを決めておく

結果が出てから考えるのではなく、「基準を超えたら次は何をするか」「届かなかったら、方式を変えるのか、事業そのものを見直すのか」を、あらかじめ書いておきます。撤退の考え方は「新規事業の撤退判断｜プロトタイプで「やめる」と決める基準」で整理しています。

5. 結果を誰に、どの形で見せるかを決める

PoCの結果を共有する相手が決裁者なら、数値の表だけでなく、実際に動く様子を見せられる形が望ましいといえます。誰が最終判断をするのか、その人が何を見れば納得できるのかを、最初に確認します。

システムを軸にした新規事業での進め方

システムそのものが事業の中心になる新規事業では、PoCとプロトタイプを別々の工程にせず、一つの流れとして設計すると無駄が出にくくなります。

不確かさの大きい順に確かめる

最初に、事業が成り立つための前提を洗い出し、「分からない度合いが大きいもの」から順に並べます。たとえば次のような前提です。

• 必要なデータが手に入るか（技術）
• AIの出力が事業で使える水準か（技術）
• 利用者が操作を理解し、使ってくれるか（受容性）
• 利用が続き、事業として成立するか（事業性）

上位の前提が崩れれば、下位を検証しても意味がありません。この順番で、小さな検証を重ねていきます。

技術の検証は、触れる形にして見せる

技術の検証結果は、ログや数値だけで報告するよりも、最小限の画面を付けて触れる状態にしておくと、技術に詳しくない人にも伝わります。PoCを「実際に動く試作品」の形で出すことで、決裁者や現場の担当者が同じものを見ながら話せます。進め方のズレが話し合いを難しくする問題は、「新規事業で経営陣と現場がすれ違う原因は進め方のズレ」でも触れています。

動く試作品を使った検証の手順は、「新規事業のアイデア検証方法｜動くシステムで確かめる手順」に整理しています。

試作品を触ってもらい、次の問いに移る

技術的な前提が確認できたら、次は実際の利用者候補に試作品を触ってもらい、受容性の問いに移ります。質問の組み立て方は「プロトタイプのユーザーテスト｜新規事業での確かめ方と質問」が参考になります。その先で、限られた相手に使ってもらう段階に進む場合は、「新規事業のクローズドβ｜進め方と公開範囲の決め方」で公開範囲の考え方を扱っています。

小さく作って確かめながら投資を段階的に判断する考え方は、「新規事業の開発は小さく作って確かめる投資判断の進め方」にまとめています。PoCは、この考え方の「最初の一歩」にあたります。

稟議の場で使える形にする

PoCや試作品の結果は、社内の稟議に使えてはじめて次の投資につながります。何を確かめ、何が分かり、次に何を確かめるのかが一続きで説明できると、判断材料として扱いやすくなります。具体的な使い方は「稟議を通すシステム開発｜プロトタイプの使い方」で扱っています。

まとめ

新規事業のPoCは、事業全体ではなく「成り立つかどうか分からない一点」を、小さく確かめる段階です。主に技術的な実現性を対象にするのに対し、プロトタイプは形にしたときの伝わり方や使い勝手、MVPは顧客が価値を感じて使い続けるかを確かめる手段として使い分けます。

ポイントを整理すると、次のようになります。

• PoCは「技術的に成り立つか」、プロトタイプは「形にして伝わるか」、MVPは「顧客が使い続けるか」を確かめる
• 選ぶ基準は完成度ではなく、いま最も不確かな問いが何か
• 3つは一方向の工程ではなく、行き来したり重なったりする
• PoCが形だけで終わらないよう、「確かめたい一点」「判断基準」「期間」「結果ごとの次の動き」「見せる相手」を先に決める
• 結果は、決裁者が触れて判断できる形にすると、次の投資判断につながりやすい

私たちJustFitは、「先に作って、後から決める（PROTOTYPE FIRST）」という考え方で、構想をもとに約1ヶ月で実際に動くプロトタイプを開発しています。実物を見てから契約を判断できるため、PoCで確かめた技術の可能性を、決裁者や現場が同じ画面を見ながら話せる形にしたいときの選択肢になります。仕様が固まっていない段階や稟議の前でも相談できますので、確かめたい一点が見えてきた段階で、JustFitのサービス紹介もご覧ください。