開発会社のサイトを見ていると、「まずはPoCから」「プロトタイプを作りましょう」「MVPで小さく始める」と、似た言葉が並んでいます。どれも「いきなり全部作らない」という意味では同じに見えますが、確かめる中身と、出来上がって手元に残るものは別物です。自己資金で立ち上げる個人がこの違いを曖昧にしたまま依頼すると、欲しかったのは人に使ってもらえるサービスなのに、受け取ったのは「実現できそうです」という報告書だった、という食い違いが起きます。
先に要点をまとめます。
- PoCは「技術的にできるか」、プロトタイプは「使う流れが想定どおりか」、MVPは「お金や時間を払ってでも使う人がいるか」を確かめるものです
- 予約・会員登録・決済のように実績のある部品を組み合わせるWebサービスなら、PoCは省けることが多い。必要になるのは、AIの精度や外部データの取得など「できるかどうか分からない部分」がサービスの売りになる場合です
- プロトタイプまではAIやノーコードで自作できる範囲が広く、外注を考える境目は、他人のお金・個人情報・継続利用を扱い始めるMVPからです
PoC・プロトタイプ・MVPは、それぞれ何を確かめるもの？
3つは「誰に向けて、どの問いに答えるか」で分かれます。PoCは作り手が技術の成否を、プロトタイプは作り手と協力者が操作の流れを、MVPは実際の利用者が価値の有無を確かめます。
| 確かめる問い | 触る人 | 手元に残るもの | 終わりの判断 |
|---|---|---|---|
| PoC（概念実証） | その仕組みは技術的に成り立つか | 作り手 | 検証結果のレポート、部分的に動くもの |
| プロトタイプ | 画面や操作の流れが想定どおりか | 作り手・身近な協力者 | 触れる試作品（本番には使わない前提） |
| MVP | お金や時間を払ってでも使う人がいるか | 実際の利用者 | 公開して運用できる最小限のサービス |
PoC（概念実証）という言葉は、もともと新しい考え方や技術の実現可能性を、部分的に作って確かめる工程を指します。経済産業省の「AI・データの利用に関する契約ガイドライン」では、AI開発を「アセスメント」「PoC」「開発」「追加学習」の4段階に分ける進め方を示しており、PoC段階の目的を「学習用データセットを用いてユーザが希望する精度の学習済みモデルが生成できるかを検証する」こと、想定される成果物を「レポート」や「学習済みモデル（パイロット版）」としています。つまりPoCで受け取るのは、サービスではなく「検証の結果」です。
プロトタイプは、画面の並びやボタンを押したあとの流れを、実物に近い形で確かめるための試作品です。見た目だけを再現したモックアップから、データが実際に保存されるところまで動くものまで幅がありますが、共通するのは「本番のまま使い続ける前提ではない」という点です。
MVP（実用最小限の製品）（Minimum Viable Product）は、リーン・スタートアップを提唱したエリック・リース氏が「最小の労力で、顧客についての検証された学びを最大限集められる、新しい製品のバージョン」と定義しています（原文は英語、編集部訳）。ポイントは「顧客についての学び」です。作り手が触って満足するものではなく、実際の利用者に使ってもらい、その反応から次の判断を得るためのものです。
個人のWebサービスに、PoCは必要？
予約・会員登録・決済・通知など、多くのサービスで使われている部品の組み合わせなら、技術的に成り立つかはすでに分かっているため、PoCは省けることが多いです。
たとえば「美容室の予約をLINEから受けて、前日にリマインドを送る」サービスは、仕組みとしては既存の技術で作れることが明らかです。ここで確かめるべきなのは「作れるか」ではなく、「店が本当に使うか」「お金を払うか」のほうです。この場合にPoCへ予算を割くと、答えが分かりきった問いに費用を払うことになります。
一方で、次のような部分がサービスの売りになる場合は、本格的に作り込む前に小さく確かめる価値があります。
- AIの出力精度が価値の中心になる：専門書類の読み取り、相談内容の自動分類、回答文の下書きなど。「AIが十分な精度で答えられるか」は作ってみないと分からない
- 外部のデータやサービスから、必要な情報を取れるか分からない：他社サービスのAPIで取得できる項目や利用条件が、想定と合っているか
- 処理の速さや量に不安がある：大量の画像や長い音声を扱うなど、現実的な時間・費用で処理できるかが不明
AIの精度を確かめるPoCは、開発会社に頼む前に自分でも試せます。実際の書類や相談文を10件ほど用意し、生成AIに処理させて、専門家としての自分の目で合否を付けてみる。これだけでも「このまま進めてよいか」の判断材料になります。AIで試せる範囲の目安はAIコーディングツールの無料枠、どこまで検証できるか——投資前の見極め方も参考になります。
プロトタイプは、自分で作るか頼むか？
画面の流れを確かめるためのプロトタイプは、バイブコーディングやノーコードで自作できる範囲が広く、個人の立ち上げでは自分で作るほうが予算配分として合理的な場面が多いです。
プロトタイプの役割は、頭の中の「こう使ってもらうはず」を、触れる形にして確かめることです。身近な協力者や見込み客に触ってもらい、「ここで迷った」「このボタンの意味が分からない」という反応を集められれば、目的は果たせています。見た目が荒くても、本番の品質でなくても問題ありません。
注意したいのは、プロトタイプが思ったよりよく動いたとき、そのまま公開したくなることです。自分や協力者が触る分には問題がなくても、見知らぬ利用者が使い始めると、ログインの安全性、データの消失、同時に複数人が使ったときの挙動といった論点が一気に出てきます。試作と本番の間にある差はバイブコーディングの試作を、本番品質に引き上げる3つの視点で整理しています。
プロトタイプを開発会社に頼む選択肢もあります。操作の流れが複雑で自分では形にできない場合や、本業が忙しく試作に時間を割けない場合です。その際は「本番に流用するのか、捨てる前提か」を最初に伝えておくと、見積もりの前提がそろいます。
MVPは、どこから外注を考える？
他人のお金・個人情報・継続利用を扱い始める時点が、外注を考える境目です。MVPは「最小限」でも、公開して見知らぬ人に使ってもらう以上、安全面の最低ラインは下げられません。
MVPの「最小限」は、機能の数を絞るという意味です。品質や安全性を下げてよいという意味ではありません。自作のまま公開するか、開発会社に頼むかを考えるときは、次の4つに当てはまるかを確認してください。
- 決済を扱う（利用者がカード情報を入力する、定期課金がある）
- 個人情報を保存する（氏名・連絡先・相談内容などをサービス側で持つ）
- 見知らぬ利用者が、公開URLから自由に登録・利用できる
- 利用者が継続して使い、データが蓄積していく前提になっている
1つでも当てはまる場合、自作で進めるなら少なくともその部分だけは専門家に見てもらう前提で計画しておくと、公開後に慌てずに済みます。どの機能を専門家に任せるべきかの線引きは決済・個人情報。専門家に頼むべき機能の見分け方で詳しく扱っています。
MVPに残す機能の選び方は「削れない機能」と「後回しにできる機能」を仕分ける考え方、予算内で作れる範囲の目安は予算300万円で、現実的にどこまでの機能が作れるかが判断材料になります。
300万円は、3つの段階にどう配分する？
PoCとプロトタイプには上限を決めて小さく使い、予算の大部分は公開して運用するMVPと公開後のために残しておくのが基本の考え方です。
自己資金の立ち上げでは、試作の段階で予算を使い切ってしまい、公開や集客、公開後の改修に回す余力が残らない、という失敗が起こりがちです。試作が思ったより動くと「もう少し直せば」と手を入れ続けたくなりますが、プロトタイプは本番に使わない前提のものです。そこに注いだ費用は、MVPの品質にはほとんど引き継がれません。
段階ごとの予算の目安と、使いすぎのサインは、ガイド予算300万円のうち、試作段階でいくらまで使ってよいかで具体的に整理しています。着手前に「試作にはここまで」と自分の上限を決めておくと、3つの段階を通して予算の使い方を判断しやすくなります。
開発会社に頼むとき、呼び方のズレで何が起きる？
同じ「PoC」「プロトタイプ」でも、会社によって想定する成果物や契約の形が違います。言葉で頼むのではなく、「誰が・何を・どこまでできれば完成か」で伝えると食い違いを防げます。
前述の経済産業省のガイドラインでも、PoC段階で締結する契約は「導入検証契約書」、本開発の段階は「ソフトウェア開発契約書」と、段階ごとに別の契約として整理されています。開発会社に「PoCをお願いしたい」と伝えると、会社によっては検証結果の報告を主な成果物とする、完成を約束しない形の依頼として受け取られることがあります。欲しかったのが利用者に公開できるMVPだった場合、ここで認識がずれます。
依頼の段階では、呼び方よりも次の3点を文章で伝えてください。
- 誰が使うか：自分だけか、協力者数名か、公開して見知らぬ利用者か
- 何ができれば完成か：「会員登録して予約を1件入れ、確認メールが届く」のように操作の単位で書く
- その後どうするか：本番に流用するのか、検証が終わったら作り直す前提か
この3点が決まると、契約の形（完成を約束する請負か、業務の遂行に対して払う準委任か）の相談もしやすくなります。契約形態の違いは個人が開発を発注するときに知っておきたい契約の基本（請負・準委任）、依頼内容を1枚にまとめる方法は個人でも書ける、簡易RFPの型で扱っています。
まとめ：自分がいまどの段階かを、問いで確かめる
PoC・プロトタイプ・MVPの違いは、名前ではなく「いま答えを出したい問い」で見分けると整理できます。
- 「そもそも技術的にできるのか」が分からない → PoC。多くのWebサービスでは省けるが、AIの精度や外部データが売りなら小さく試す
- 「この流れで使ってもらえるか」を確かめたい → プロトタイプ。自作しやすく、本番に使わない前提で作る
- 「お金や時間を払ってでも使う人がいるか」を確かめたい → MVP。他人のお金や個人情報を扱うなら、安全面は専門家の手を借りる前提で計画する
次に開発会社へ相談するときは、「PoCから」「MVPで」という言葉の代わりに、自分が答えを出したい問いと、完成とみなす操作を1行ずつ書いて持っていくと、見積もりの前提がそろいます。
