投稿日：2026.09.04 最終更新日：2026.09.20
MVPとプロトタイプの違い｜試作と顧客検証の使い分け
MVPとプロトタイプは、どちらも小さく試すための手段です。ただし、試作品が好評だったことと、顧客が使い続けることは同じではありません。
プロトタイプは、形や操作、提供方法を確かめるための試作です。MVP（Minimum Viable Product）は、顧客についての仮説を検証するために必要な、最小限の製品・サービスを指します。違いは完成度よりも、何を確かめて次に何を決めるかにあります。プロトタイプを顧客に見せることも、MVPの裏側を手作業で運用することもあります。本記事では、一次資料の考え方を踏まえ、同じサービスの具体例で違いを整理します。作る順番、検証結果の読み方、試作から顧客検証へ進む手順まで、開発を依頼する前に決めたいことが分かります。
この記事のポイント
- プロトタイプは試作の形、MVPは顧客から学ぶための最小限の提供として捉える
- 両方とも顧客に試してもらえるため、相手だけで区別しない
- 操作できた、使われた、購入された、続けられた、を別々に確認する
- 作るものを決める前に、対象顧客・確認する行動・次の判断をそろえる
目次
MVPとプロトタイプは、完成度ではなく確かめる目的が違う
「プロトタイプを仕上げればMVPになる」とは限りません。両者は重なることがありますが、試作品を使って設計を確かめることと、顧客の利用や購入を通じて事業の仮説を確かめることは、分けて考える必要があります。
プロトタイプは、作り方や使い方を試すための試作品
プロトタイプとは、製品やサービスの案を具体的な形にした試作品です。紙に描いた画面、クリックできる画面、模型、動作する試作機などが当てはまります。何を確かめたいかに合わせて、必要な部分だけを作ります。
英国政府のGOV.UK「Making prototypes」（2016年）では、本格的に作る前に複数の設計案を試し、うまくいかない案を捨てられることを利点として挙げています。また、プロトタイプは紙のスケッチから動くコードまで幅があり、公開後の改善にも使うと説明しています。
つまり、プロトタイプは「開発初期の粗い画面」に限りません。使いにくい部分を見直すため、提供中のサービスでも使えます。想定顧客に触ってもらい、説明なしで操作できるかを観察する使い方もあります。
MVPは、顧客についての仮説を確かめる最小限の製品・サービス
MVPはMinimum Viable Productの略です。一般に「実用最小限の製品」などと訳されますが、単に機能が少ない製品を指すわけではありません。
Eric Riesは「Minimum Viable Product: a guide」（2009年）で、少ない労力で顧客について検証に基づく学びを得ることを、MVPの中心に置いています。同じ記事では、誰も欲しがらなかった機能に2週間を費やした経験を述べ、もっと早く需要を確かめられたと振り返っています。
この考え方を実務に当てはめると、MVPで残す機能は「作れそうなもの」ではなく「顧客の反応を確かめるために必要なもの」です。自動化していなくても、担当者が手作業で価値を届け、利用や再利用を確かめる方法があります。MVPの全体像は、MVPの意味と作り方でも解説しています。
比較するときは、見栄えや開発期間ではなく、目的と得られる事実を見ます。以下はイノベーション総研による実務上の整理であり、両者を重なりのない工程に分けるものではありません。
| 比較する点 | プロトタイプ | MVP |
|---|---|---|
| 中心となる目的 | 設計案や操作、体験を試す | 顧客に関する仮説を検証する |
| 使う場面の例 | 想定利用者に、申込画面を操作してもらう | 対象顧客に限定提供し、実際の申込みや利用を確かめる |
| 確かめられる事実の例 | どこで迷ったか、何を理解できなかったか | 誰が使ったか、再利用したか、どの条件で購入したか |
| 必要な完成度 | 確認したい操作や体験を再現できる範囲 | 検証に必要な価値を、約束した条件で届けられる範囲 |
| 次の判断の例 | 画面や提供手順を採用・修正する | 対象顧客や提供内容を変える、次の投資へ進む |
プロトタイプを顧客に見せた、というだけでMVPになるわけではありません。どちらも顧客と試せます。会議では名称に加えて「今回は、誰のどの行動から、何を判断するのか」を一文で共有すると、結果の読み違いを減らせます。
同じサービスで見る、試作とMVPの具体例
ここでは、店舗の在庫確認を助けるサービスを考えます。以下は違いを説明するための架空例であり、実在企業の支援実績ではありません。「在庫を見る画面」を作る場合でも、何を試すかで必要なものが変わります。
試作では、担当者が画面を見て補充品を選べるかを確かめる
最初に、在庫数と補充候補を表示した画面を作ります。データは架空のもので構いません。店舗担当者には「明日の補充品を選んでください」と依頼し、どこを見て、どこで迷うかを観察します。
もし在庫数は読めても補充の優先順位が分からなければ、並び順や表示を直します。この時点で確かめたのは、画面を使って判断できるかという設計上の問いです。操作できたからといって、忙しい営業中にも使われることや、料金を払ってもらえることまでは分かりません。
MVPでは、実際の店舗で利用が続くかを確かめる
次は、協力店舗に対象を絞り、実際の補充作業でサービスを使ってもらいます。最初から在庫システムと自動連携せず、許可されたデータを担当者が確認して補充候補を返す方法も考えられます。
ここで見るのは、補充担当者が結果を使ったか、次の補充時にも依頼したか、従来の手順のどこが変わったかです。作り手が説明し続けたときだけ使えた場合は、説明なしでも役立つかを改めて確かめます。
有償化を判断したいなら、利用者への感想の確認に加えて、費用を負担する人へ価格と提供範囲を示します。「便利そう」という発言、社内検討への同意、有償契約では、それぞれ確認できることが違います。成立した行動だけを記録し、未確認の購入まで成功扱いにしません。
好評だった画面と、続けて使われるサービスは分けて評価する
この例では、同じ画面を使っても、前半は操作の確認、後半は実業務での利用の確認です。プロトタイプの見た目を磨くだけでは、後半の問いには答えられません。
反対に、再利用されなかった理由が「サービスに価値がない」ではなく「入力方法が分からない」なら、画面の試作に戻って直す方が適切です。試作とMVPを行き来しながら、問題が設計にあるのか、提供価値にあるのかを切り分けます。
先に作るものは、いちばん確かめたい前提から選ぶ
「プロトタイプ、MVPの順に全部実施する」という固定の順番は不要です。ただし、安く早く終わる作業だけを選んでも、事業の判断が進むとは限りません。まず、その前提が外れると計画を見直す必要があるかを考えます。
次の表は、確認したいことから手段を選ぶための対応表です。名称を決めるためではなく、いま不要な開発を避けるために使ってください。
| まだ分からないこと | 最初に試すこと | その結果だけでは分からないこと |
|---|---|---|
| 想定する困りごとが実際にあるか | 直近の仕事や対応方法を、顧客への聞き取りで確かめる | 新しい解決策を使うか、購入するか |
| 画面や手順が理解されるか | プロトタイプを使った操作テスト | 実業務での継続利用や購入 |
| 必要な技術や方式が成立するか | 条件を限定したPoC（概念実証） | 顧客が導入したいか、採算が合うか |
| 顧客が利用・再利用するか | MVPを限定提供し、実際の行動を記録する | 全顧客への展開や、大規模運用の可否 |
| 提示価格で購入されるか | 費用負担者へ価格と提供条件を示し、購入判断を確かめる | 長期継続や、販売を拡大したときの採算 |
作る前に、「この結果が出たら何を変えるか」を決めます。例えば、想定する困りごとが見つからなければ、画面を改良する前に対象顧客や課題を見直します。画面の操作だけが分からないなら、事業全体を止めず、設計を直して試します。
複数の前提が未確認なら、影響の大きさと確認にかかる負担を合わせて優先順位を決めます。対象者や判断条件の書き方は、仮説検証の進め方も参照できます。
PoCは技術の成立、モックアップは見た目を確かめる
PoCとモックアップも、MVPやプロトタイプと並べて使われます。用語には現場による幅があるため、本記事では次のように役割を整理します。
PoCはProof of Conceptの略で、日本語では「概念実証」です。考えた技術や方式が、定めた条件で成立するかを確かめます。在庫確認の例なら、「必要なデータを読み込めるか」「補充候補を所定の条件で計算できるか」といった確認です。技術が動いた事実だけでは、店舗が使う理由や購入条件は確かめられません。
モックアップは、形や見た目を確かめるための模型・画面見本を指します。プロトタイプの一種として扱われることもあり、別々の必須工程ではありません。見た目の確認で足りるなら静止画を、操作の順番を確かめたいならクリックできる試作を選びます。
PoCにプロトタイプを使うことも、MVPの一部を試作品で実現することもできます。四つの名前を開発の順番として並べるより、「何を確認したら、その次の作業を承認できるか」を決める方が実務では役立ちます。技術検証との境界は、MVPとPoCの違いで詳しく扱っています。
いま止まっているところから、次の確認を選ぶ
近い状態を開くと、確認項目と記事内の説明・関連支援が分かります。
NEXT STEP
次のステップ
作る範囲を決める前に、検証する問いを絞る。
判断に足りない材料を整理したい方は無料診断へ。検証設計やMVP開発を進める体制が必要な方は、支援内容をご確認ください。
プロトタイプからMVPへ進む5ステップ
次の顧客検証へ進むときは、試作で分かったことと、まだ分からないことを分けます。試作品をそのまま製品化するのではなく、以下の5ステップで提供内容と判断条件を組み直します。
1. 試作で分かったことと、まだ分からないことを分ける
観察した事実を、推測と分けて書きます。「説明なしで補充候補を選べた」は事実ですが、「これなら売れる」は、その結果からはまだ言えません。誰が、どの状況で、何をしたかが追える記録を残します。
そのうえで、次の判断に足りない点を一つ選びます。在庫確認の例なら、「実業務でも繰り返し使われるか」を次の問いにできます。操作方法がまだ伝わっていないなら、顧客への限定提供を急ぐ前に、試作を直します。
2. 提供する顧客と利用場面を絞る
「小売業全般」のような広い対象では、使われなかった理由を絞り込めません。誰がどの作業で困り、いつサービスを使うのかまで書きます。例えば「毎朝、補充品を決める店舗担当者」のように、役割と場面で対象を決めます。
法人向けでは、使う人と購入を判断する人が異なる場合があります。利用を確かめる相手、費用を確認する相手、データの扱いを確認する相手を区別してください。全員へ同じ質問をするのではなく、それぞれが決められる条件を聞きます。
3. 確かめたい行動に必要な範囲だけを作る
機能候補ごとに「これがないと、今回の問いに答えられないか」を確認します。補充候補の再利用を確かめたいなら、候補を届ける仕組みと利用記録は必要ですが、将来の全店舗管理画面や高度な分析機能は、今回の検証には不要かもしれません。
裏側の手作業も選択肢ですが、作業時間は記録します。少数の店舗に提供できたことと、同じ原価で多くの店舗に提供できることは別です。自動化を後回しにした部分が、事業化の際にどれくらいの負担になるかを残しておきます。
GOV.UKの前掲ガイドも、試作用コードをそのまま本番へ移さず、品質を確認するよう注意しています。画面や設計上の学びは引き継いでも、実装の再利用は別に判断します。顧客への提供では、必要な品質・情報管理・問い合わせ対応を省略しません。
4. 観察する行動と、判断する日を決める
「好評なら継続」では、人によって合格の意味が変わります。誰のどの行動を確認し、結果によって何を選ぶかを、提供前に決めます。利用回数だけでなく、利用機会が何回あったかも記録すると、単に作業が発生しなかった場合を区別できます。
判断条件は、事業や利用頻度に合わせて設定します。週に一度の作業なら、初日の反応だけで継続利用を決めない、という考え方です。途中で条件を変更する必要が出たら、変更理由と判断者を残し、当初の計画と混ぜません。
以下は、チームで検証条件をそろえるための記入例です。期間や判断条件は架空の設定であり、共通の成功基準ではありません。
| 決めること | 架空の記入例 |
|---|---|
| 今回の問い | 補充担当者が、実際の作業で補充候補を繰り返し使うか |
| 対象と期間 | 協力店舗の補充担当者。複数回の補充機会を含む2週間 |
| 提供する内容 | 対象商品の補充候補を、合意した時刻に届ける。集計は担当者が手作業で行う |
| 残す記録 | 補充の機会、利用の有無、候補を変えた理由、提供側の作業時間 |
| 次の判断 | 利用が続けば購入条件の確認へ。操作で止まれば設計を修正。価値が見いだせなければ対象や課題を見直す |
| 担当と判断日 | 検証担当が記録をまとめ、終了翌営業日に事業責任者が次の検証を決める |
この例では、購入や全店展開はまだ承認していません。何を次に確認するかを決めるための検証であり、一度の結果で事業全体に合格を出さないことがポイントです。
5. 結果をもとに、続ける・修正する・止めるを選ぶ
判断日に、確認できたこと、想定と違ったこと、未確認のことを整理します。良い反応だけを抜き出さず、利用されなかった場面や、途中で止めた理由も確認してください。
継続する場合も、すぐに本格開発へ進むとは限りません。利用は確認できても購入条件が不明なら、次は価格を示して判断者と話します。操作で止まったならプロトタイプに戻り、対象顧客の困りごと自体が違ったなら、その仮説への追加投資を止めて対象を見直します。
検証結果を読み違えないための3つの注意点
手段を正しく選んでも、結果を広く解釈しすぎると投資判断を誤ります。特に、評価の高さ、機能の少なさ、協力者の反応をそのまま事業の成功へ結び付けないようにします。
1. 「使いやすい」と「使い続けたい」を一緒にしない
操作テストで高く評価されても、日常の仕事に取り入れる理由が弱ければ使われません。逆に、必要性を感じていても、社内のデータ持ち出しや導入手続きが障害になることがあります。
何に対する評価だったかを確かめ、次の行動と分けて記録します。「分かりやすい」という発言を聞いた後は、実際の利用機会に試せるか、購入条件を検討できるかなど、次に確認したい行動へ進みます。
2. 最小限にするために、価値や必要な品質まで削らない
補充候補を知りたい顧客に、見栄えだけの画面を渡しても、業務上の価値は確かめられません。「機能を減らす」ことと、「確かめたい価値を届けられなくする」ことを区別します。
提供できる内容、対応時間、利用できるデータ、試用終了時の扱いを事前に共有してください。試作だからという理由で、不具合や情報管理の負担を顧客に押し付けないことも、検証の前提です。
3. 協力者の反応を、そのまま市場全体へ広げない
協力的な顧客は、担当者の手厚い説明や個別対応があるから使ってくれているかもしれません。限定提供で利用が続いた結果は、その対象・条件での手がかりであり、他の顧客にも売れる証明ではありません。
次の段階では、対象者を変える、個別対応を減らす、実際の価格を示すなど、広げたい条件を一つずつ確かめます。売上を伸ばす前に、どの支援がなくても価値を届けられるかを確認すると、開発だけでなく提供体制の課題も見えてきます。
MVPとプロトタイプのよくある質問
ここでは、顧客に見せる範囲、無料での検証、同じ試作品の再利用、検証人数について答えます。
まとめ｜MVPとプロトタイプは、次に決めたいことから使い分ける
プロトタイプは、設計案を具体化して試す手段です。MVPは、顧客に関する仮説を小さく検証するための製品・サービスです。両者は完成度や相手だけでは分けられず、同じ試作品が両方の役割を持つこともあります。
次の会議では、「この試作で確認できたことは何か。次の開発を決めるために、まだ何が足りないか」を一つずつ書き出してください。作るものを増やす前に、その問いに答えられる検証相手と方法を決めることが出発点です。
CONTACT
お問い合わせ
次の検証で、何を確かめるかを一緒に整理する。
試作の評価は得たものの、次に何を作るか決まらない場合はご相談ください。対象顧客、検証する範囲、利用・購入を確かめる方法から、進め方を検討します。
