プロトタイプ開発とは｜進め方・費用とMVPへ進む基準

プロトタイプ開発とは、本開発に入る前に試作品（プロトタイプ）を作り、完成イメージと仕様を関係者で確かめながら進める開発手法です。目的は、動くものを早く見ることで認識のズレを潰し、手戻りのコストを本開発の前に払い終えることにあります。

発注側にとっての論点は3つです。どう進むのか、いくらかかるのか、そしてどこまで確かめたら次（MVP・本開発)へ進んでよいのか。この記事では定義と種類、進め方、費用の決まり方を先に整理し、ウォーターフォール・アジャイル・MVP・PoCとの違いを切り分けたうえで、生成AIによって試作のコスト構造が変わった現在の判断基準までを解説します。

プロトタイプ開発とは：定義・種類・進め方・費用

定義と目的

プロトタイプ（prototype）は「原型・試作品」を意味し、プロトタイプ開発は試作→評価→修正のサイクルを本開発の前に置く進め方を指します。完成品の一部の機能や画面だけを先に形にし、発注者・利用者・開発者の3者が同じものを見ながら仕様を固めます。

目的は試作品を作ること自体ではありません。「文書では合意できない部分を、動くもので合意する」ことです。要件定義書の行間で起きる解釈のズレは、画面を触れば数分で発見できます。

種類：使い捨て型と進化型

プロトタイプには大きく2つの型があります。

型	別名	特徴
使い捨て型	ラピッドプロトタイピング	検証専用に素早く作り、本開発では作り直す
進化型	進化型プロトタイピング	試作をそのまま育てて本番システムに近づける

使い捨て型は速度優先で、検証が終われば捨てる前提のため品質を作り込みません。進化型は試作の資産を活かせる反面、初期の設計品質が後々まで残ります。発注時は「この試作は捨てる前提か、育てる前提か」を最初に確認してください。契約と見積の前提が変わります。

メリット：4つに整理する

開発会社各社の解説が挙げるメリットは、次の4つに集約できます。

• 完成イメージのズレを早期に発見し、手戻りを削減できる
• 利用者の意見を開発の早い段階で反映できる
• 技術的な実現可能性を先に検証できる
• 発注者が開発に不慣れでも、要件を具体的に議論できる

いずれも「後工程で払うはずだったコストを、安い前払いに変える」効果です。仕様変更は本開発後に起きるほど高くつくため、変更を前倒しできること自体が金額的な価値になります。

プロトタイプで検証できること・できないこと

メリットの裏側として、プロトタイプで確かめられる範囲には境界があります。検証できるのは、操作性・画面遷移・完成イメージの合意・技術的な成立性です。検証できないのは、市場にその製品の需要があるかどうかです。

需要の検証は、実際の利用者に使ってもらい反応を測るMVPの領分になります。プロトタイプを何往復しても「社内の合意」しか得られていない、という状態は珍しくありません。何を確かめたくてこの試作を作るのかを、着手前に1行で書けるようにしておいてください。

デメリットと対策

デメリットも各社の解説でほぼ共通しています。対策とセットで押さえます。

デメリット	対策
試作のコストと時間が追加でかかる	検証したい問いを絞り、作る範囲を最小にする
フィードバック反映で開発が長期化しやすい	評価の範囲と期間を先に決める（後述）
試作と完成品を混同され、期待値がずれる	「これは検証用」と明示し、性能・品質の約束と分ける

3つ目は見落とされがちです。見た目が動いてしまうため、経営層や現場が「ほぼ完成している」と誤解し、本開発の期間と費用に不満が出る型です。デモの冒頭で試作の位置づけを毎回言葉にするだけで、かなり防げます。

進め方：5つのステップ

標準的な工程は次の5段階です。

1. 要件定義——検証したい問いと、試作で作る範囲を決める

2. 設計・試作——対象の画面・機能だけを素早く形にする

3. 評価・フィードバック——発注者・利用者が実際に触って確認する

4. 修正・改善——指摘を反映し、必要なら3に戻る

5. 本開発——固まった仕様で開発に入る

工程自体は単純で、難しいのは3と4の回数管理です。ここが無限ループになると、デメリットで挙げた長期化がそのまま起きます。

フィードバックの範囲と期間を先に決める

長期化を防ぐ実務的な方法は、評価の範囲と期間を契約段階で固定することです。「評価は2往復まで」「対象は主要3画面の操作性のみ」「追加の要望は本開発のバックログへ送る」といった線を先に引きます。

範囲を決めずに始めると、試作は要望の受け皿になります。良いプロトタイプ開発は、意見を全部反映した開発ではなく、検証したい問いに答えが出た開発です。

費用の目安と決まり方

プロトタイプ開発の費用は、開発会社への外注でおおむね数十万円〜300万円程度と幅があります。金額を動かす変数は主に3つです。

• 忠実度——紙のスケッチに近いものか、実データで動くものか
• 画面数・機能数——検証対象の範囲
• 連携の有無——既存システムやAPIと繋ぐか、単体で閉じるか

デザインツール上で画面遷移を再現するだけなら数十万円規模、実データベースや外部連携を含む動くプロトタイプは百万円規模に乗ります。見積を比べるときは総額ではなく、この3変数の前提を揃えてください。

作成手段：デザインツール・AI・ノーコード

試作の作成手段は3系統あります。Figmaなどのデザインツールで画面遷移を再現する方法、生成AIにコードを書かせて動くものを作る方法、ノーコードツールで組む方法です。どの手段が適するかは検証したい問いの種類で決まります。手法と忠実度の使い分けそのものは、姉妹記事のプロトタイピング手法解説で詳しく扱うため、この記事では発注判断に必要な範囲に留めます。

隣接概念との違い

プロトタイプ開発の周辺には紛らわしい用語が多く、発注の会話がすれ違う原因になります。5つを切り分けます。

ワイヤーフレーム・モックアップとの違い

ワイヤーフレームは画面の骨組み（配置図）、モックアップは見た目まで作り込んだ静止画です。プロトタイプはそこに「動き」が加わり、画面遷移や操作を実際に試せます。骨組み→見た目→動きの順に忠実度が上がる関係で、どこまで作るかはコストと検証したい問いのバランスで決めます。

ウォーターフォール開発との違い

ウォーターフォールは要件定義→設計→実装→テストを一方向に進め、原則として後戻りしません。文書で仕様を確定できる案件では効率的ですが、作ってみないと分からない要素が多いと、テスト段階で大きな手戻りが出ます。プロトタイプ開発は、この「作ってみないと分からない」部分を最初に潰すための逆張りです。実務では、プロトタイプで仕様を固めてからウォーターフォールで本開発する併用が広く使われています。

アジャイル・スパイラル開発との違い

アジャイル開発は短い周期で開発とリリースを繰り返す進め方の総称で、スパイラル開発は設計→試作→評価を工程ごとに繰り返す進め方です。プロトタイプ開発との違いは対象範囲にあります。プロトタイプ開発は「本開発前の検証」に焦点があり、アジャイル・スパイラルは「開発全体の回し方」の話です。層が違うため対立せず、アジャイルの最初のスプリントでプロトタイプを作る、といった組み合わせが自然です。

MVP開発との違い

MVP（Minimum Viable Product）は、市場の需要を検証するために最小限の機能で実際にリリースする製品です。プロトタイプが「社内・関係者への検証」なのに対し、MVPは「市場への検証」で、本物の利用者が実際に使う点が決定的に違います。定義と作り方の詳細はMVPとはで解説しています。

PoCとの違い

PoC（概念実証）は「その技術・アイデアが成立するか」を確かめる取り組みで、対象は技術的な成立性です。プロトタイプは「どう作るか・どう見えるか」の確認に軸があります。PoCは成立性が確認できたら終わりですが、そこで止まって本番に進まない「PoC疲れ」が問題になりやすい領域です。この構造はPoC疲れとはで扱っています。

概念	確かめる相手	確かめる内容
プロトタイプ	発注者・関係者・利用者	完成イメージ・操作性・技術成立性
PoC	技術チーム・意思決定者	技術・アイデアの成立性
MVP	市場（実際の利用者）	需要があるか

向き不向きと外注判断

プロトタイプ開発は万能ではありません。向く案件・向かない案件と、内製か外注かの分岐を整理します。

向いているプロジェクト：3つの型

開発会社各社の解説が一致して挙げるのは、次の3型です。

• 新規事業・前例のない開発——文書だけでは仕様を確定できない
• UI/UXが成否を分ける開発——操作性は触らないと評価できない
• 発注側に開発経験が少ない、または関係者の合意形成が難しい——動くものが共通言語になる

3つに共通するのは「言葉での合意が構造的に難しい」ことです。逆に言えば、プロトタイプは合意形成の道具として最も効きます。

向かない場合

仕様が完全に固まっている定型的な開発や、画面をほぼ持たないバッチ処理・基盤系の開発では、試作のコストが検証の価値を上回ります。また、大規模開発の全体をプロトタイプで確かめようとすると、試作自体が第二の開発プロジェクト化します。大規模案件では、リスクの高い一部分だけを切り出して試作するのが定石です。

内製と外注の分岐

分岐の軸は2つあります。検証したい問いがデザイン寄りか実装寄りか、そして社内に試作を作れる人がいるかです。

画面イメージと操作性の検証なら、デザインツールやAIツールで内製する敷居が大きく下がっています。一方、既存システムとの連携や性能の検証は、本開発を担う候補の会社に試作から入ってもらうほうが、検証結果がそのまま本開発の設計に繋がります。

外注時の依頼のしかた

外注する場合、依頼書に書くべきことは仕様書ではありません。検証したい問いです。「この3画面の操作で、現場の入力が今より速くなるかを確かめたい」のように、問い・対象範囲・評価者・評価の期限を1枚にまとめます。

もう1つ、試作を見せる相手の順番を設計してください。最初から経営層に見せると、細部の指摘で試作が迷走しがちです。実際の利用者→現場責任者→意思決定者の順に見せ、各層で確かめることを分けるのが実務的です。開発会社の選定自体は、試作の目的を明確に共有できるか、評価の回数管理を提案してくるかが見極めどころになります。

この記事が語る範囲

ここからは、新規事業・業務システムを外部に発注する立場でのプロトタイプ開発に絞ります。手法の分類・忠実度の設計・ツールの個別比較は姉妹記事（プロトタイピング手法解説）の担当範囲です。発注側にとっての核心は「いくらで・何を確かめ・いつ次へ進むか」の3点だからです。

教科書の工程は正しい。ただしコスト構造が変わった

ここまで整理した定義・工程・費用は、各社の解説と一致する標準形であり、そのまま使えます。

ただし、前提が1つ変わりました。「試作にはコストと時間がかかる」というデメリットの重さです。生成AIでコードごと試作を作れるようになり、従来は週単位・数十万円規模だった動くプロトタイプが、日単位で作れるようになりました。コストが下がると、単に安くなるだけではなく、プロトタイプ開発の使い方そのものが変わります。作ってから考える、が現実的な選択肢になるからです。

実測：AIプロトタイピングで「作って壊す回数」はどう変わったか

この記事の発信元であるARCHECOは、AIプロダクト開発の支援会社として、生成AIを使ったプロトタイピングを自社の標準工程にしています。その実測から、教科書に未反映の変化を3つ共有します。

試作は「作るか検討する」対象から「まず作る」対象になった

従来のプロトタイプ開発は、試作自体に見積と稟議が必要でした。現在は、要件のたたき台になる動く画面を生成AIで日単位・場合によっては数時間で用意できます。ARCHECOの実務では、初回の打ち合わせに要件ヒアリングシートではなく、公開情報から推測して作った動く試作を持ち込む形が増えました。

変化の本質は速度ではなく、失敗の単価です。作り直しが安いため、1案を磨くのではなく複数案を作って壊しながら絞る進め方が成立します。従来なら1往復ぶんの予算で、数往復の検証が回ります。

規模感の実測を1つ置いておきます。ARCHECOは、複数の企業が集まって新しいサービスを共同で作るプロジェクト（共創プロジェクト）に参画しています。そのプロジェクトで生成AIを使って3日間で実装したのは、旅行者向けの注文サービス——注文から決済までが一連で動く画面と仕組み——です。これを従来の開発の見積りに換算すると、15〜25人月・2,000〜4,000万円相当になりました。「失敗の単価が下がった」は比喩ではなく、試作1回の重さの桁が変わった実数の話です。

「作って見せてから要件を聞く」順番が成立する

言葉で要件を聞いてから作る順番では、発注側は見たことのないものを言葉で説明する無理を強いられていました。試作が安くなったことで、先に叩き台を見せて「どこが違うか」を聞く順番に反転できます。人は白紙に要望を書くより、目の前の実物への違和感を指摘するほうがはるかに正確です。

この進め方は、対話でAIに指示を出してコードごと試作を作らせるvibe codingと呼ばれる領域と地続きで、ARCHECOではバイブコーディングの支援として工程化しています。

プロトタイプからMVPへ進む基準

試作が安くなった今、難所は「作れるか」から「いつ試作をやめるか」に移りました。ARCHECOが使っている基準は3つです。

• 検証したい問いに、答えが出たか——出たなら追加の往復は磨きであって検証ではない
• 残っている不安が「社内の合意」か「市場の需要」か——後者なら試作では答えが出ない
• 次の意思決定に必要な材料が揃ったか——揃ったら試作の役目は終わり

市場の需要が論点になった時点で、検証の場をプロトタイプからMVPへ移します。実際に4週間でMVP検証まで進めた工程は4週間MVP検証の実録に、プロトタイプからMVPへ進める基準を含む開発支援の体制はサービス紹介ページにまとめています。

現場の壁

進め方を整えても、実務でぶつかる壁が3つあります。

1つ目は、試作の無限ループです。フィードバックのたびに要望が増え、検証が終わらない型で、対策は評価の範囲と期間の事前固定に尽きます。2つ目は、進化型のつもりで使い捨て品質の試作を育ててしまうことです。AIで素早く作った試作は検証には十分でも、本番の設計品質を持っていないことがあります。本開発の冒頭で「引き継ぐもの・作り直すもの」を仕分けしてください。3つ目は、試作の完成度が高すぎて需要検証を飛ばしてしまうことです。よくできた試作は社内を納得させますが、市場の答えは持っていません。先の共創プロジェクトで3日間・数千万円相当の実装ができたその同じ日、その注文サービスに入った注文は0件でした。動く試作が数千万円分できた日でも、市場はまだ1円も動いていない——完成度と需要は別の軸で、試作が埋めるのは前者だけです。

まとめ

プロトタイプ開発とは、試作→評価→修正を本開発の前に置き、認識のズレと手戻りのコストを前払いする開発手法です。使い捨て型か進化型かを最初に決め、費用は忠実度・画面数・連携の3変数で読み、フィードバックの範囲と期間を先に固定する——ここまでが標準形です。

そのうえで、生成AIによって試作の単価は桁で下がりました。「作るか検討する」より「まず作って違和感を聞く」ほうが速く安くなった今、発注側に残る仕事は、検証したい問いを1行で書くことと、試作をやめてMVPへ進む基準を持つことの2つです。

この先

試作のコストが下がり続けると、プロトタイプ開発は特別な工程ではなく、打ち合わせの標準装備になっていきます。議事録の代わりに動く画面が残る打ち合わせは、すでに現実になりつつあります。

一方で、安くなった試作が乱造されるほど、「この試作は何を確かめるためのものか」を設計する力の価値が上がります。次に差がつくのは、作る速度ではなく、検証の設計です。

よくある質問

プロトタイプ開発とはどういう意味ですか？

本開発の前に試作品（プロトタイプ）を作り、完成イメージ・操作性・技術的な成立性を関係者で確かめながら進める開発手法です。文書だけでは合意しづらい仕様を、動くものを触って確認できるため、手戻りの削減に効きます。

プロトタイプ開発の目的は何ですか？

認識のズレを本開発の前に発見し、修正コストが安いうちに払い終えることです。仕様変更は工程が進むほど高くつくため、変更を前倒しできること自体が金額的な価値になります。試作を作ること自体は目的ではありません。

プロトタイプ開発とアジャイル開発の違いは何ですか？

プロトタイプ開発は「本開発前の検証」に焦点を当てた手法で、アジャイル開発は「短い周期で開発を繰り返す進め方全体」の話です。層が違うため対立せず、アジャイルの初期スプリントでプロトタイプを作るなどの組み合わせが一般的です。

プロトタイピング開発とは何ですか？

プロトタイプ開発と同じ意味で使われる呼び方です。試作（プロトタイピング）の工程を組み込んだ開発、という意味合いで、内容はこの記事で解説した定義・進め方と同じです。

プロトタイプ開発の費用はどのくらいかかりますか？

外注の場合、画面遷移の再現なら数十万円規模、実データや外部連携を含む動く試作なら百万円規模が目安です。金額は忠実度・画面数・連携の有無の3変数でほぼ決まるため、見積を比べる際はこの前提を揃えてください。

プロトタイプ開発の期間はどのくらいですか？

範囲によりますが、デザインツールでの試作なら1〜2週間、動く試作で1〜2か月程度が従来の目安でした。生成AIを使う場合、初版の試作は日単位まで短縮できるようになっており、期間の中心は作る時間から評価と修正の往復に移っています。

プロトタイプは社内で作るべきですか、外注すべきですか？

画面イメージや操作性の検証なら、デザインツール・AIツールでの内製の敷居が下がっています。既存システムとの連携や性能の検証を含むなら、本開発の候補会社に試作から入ってもらうと、検証結果が本開発の設計にそのまま繋がります。

MVPとプロトタイプはどちらを先に作るべきですか？

通常はプロトタイプが先です。プロトタイプで完成イメージと操作性を固め、市場の需要が論点になった時点でMVPに移ります。確かめたい相手が社内・関係者ならプロトタイプ、市場ならMVP、と覚えると判断しやすくなります。

生成AIで試作のコストは実際どのくらい変わりましたか？

実測では、旅行者向けの注文サービスを生成AIで3日間で実装し、従来見積り換算で15〜25人月・2,000〜4,000万円相当という桁の変化が起きています。ただし同じ日、そのサービスに入った注文は0件でした。作る側の単価が桁で下がっても、需要の検証は1歩も進んでいない——安くなったのは「作ること」だけで、「売れるかを確かめること」は安くなっていない点に注意してください。

検証したい問いの設計から、試作、MVPまでを一気通貫で支援しています。

AIプロダクト開発（MVP開発支援）について・お問い合わせ