プロトタイプの種類と使い分け — ペーパー・Figma・コード

プロトタイプを作れと言われた。

だが、何を作ればいいのか。紙に描けばいいのか、Figmaで作るのか、コードを書くのか。

答えは「検証したい仮説による」だ。

プロトタイプは目的ではない。仮説を検証するための道具だ。道具の選び方を間違えると、3日で済むものに3ヶ月かける。あるいは、コードまで書いたのに検証できない。

この記事では、4種類のプロトタイプの特徴と、新規事業のフェーズに応じた使い分けを整理する。

プロトタイプの4つの種類

1. ペーパープロトタイプ

紙とペンで描くプロトタイプ。最も原始的で、最も速い。

作り方: A4の紙に画面を描く。ボタン、テキスト、レイアウト。手描きでいい。1画面5分。5画面あれば30分で完成する。

特徴:

• 制作時間: 30分〜2時間
• コスト: ゼロ
• 必要なスキル: なし
• 忠実度: 低い（見た目はラフ）

強み: 速い。とにかく速い。アイデアが浮かんだその場で作れる。チーム内の認識合わせに使える。「こういうイメージ？」「いや、こっち」。この会話が5分で成立する。

弱み: 顧客に見せると「何これ？」となることがある。操作感がないので、UIの使いやすさは検証できない。動的なインタラクション（入力→結果表示など）の検証には向かない。

向いている検証:

• 情報構造の確認（何をどの画面に置くか）
• チーム内の方向性の合意形成
• コンセプトの初期検討

2. Figmaプロトタイプ

Figmaなどのデザインツールで作るプロトタイプ。画面遷移を設定すれば、タップやクリックで「動いている」体験を作れる。

作り方: Figmaでワイヤーフレームまたはデザインカンプを作成し、プロトタイプ機能で画面遷移を設定する。生成AIのプラグイン（Figma AI等）を使えば、ワイヤーフレームの生成も高速化できる。

特徴:

• 制作時間: 1〜3日
• コスト: Figma利用料のみ（無料プランあり）
• 必要なスキル: Figmaの基本操作
• 忠実度: 中〜高（見た目はきれいに作れる）

強み: コーディング不要で「触れるもの」が作れる。画面遷移があるので、顧客に操作してもらえる。デザインの自由度が高く、ブランドガイドラインに沿った見た目も作りやすい。

弱み: データの入出力がシミュレーションになる。フォームに入力しても結果が返ってこない。「動いている感」に限界がある。BtoB向けの複雑なダッシュボードなどは、Figmaだけでは伝わりにくい。

向いている検証:

• 画面遷移とユーザーフローの確認
• UIの直感性の検証
• モバイルアプリのコンセプト検証
• デザインの方向性の確認

3. コードプロトタイプ

実際にコードを書いて動くWebアプリやモバイルアプリを作る。生成AIの登場で、制作のハードルは大幅に下がった。

作り方: CursorやClaude Codeなどのコード生成AIを使い、Next.js、React等でWebアプリを構築する。Vercel等にデプロイすれば、URLを共有するだけで顧客に触ってもらえる。

特徴:

• 制作時間: 2〜5日
• コスト: AI利用料＋ホスティング費用（ほぼゼロ）
• 必要なスキル: 最低限のプログラミング知識（生成AIが補完）
• 忠実度: 高い（実際に動く）

強み: 実際にデータの入力・表示ができる。顧客が「使う体験」をできる。「ここに数値を入れると、こう分析される」が実演できる。反応の質が、Figmaとは段違いに変わる。

弱み: Figmaよりは時間がかかる。最低限のプログラミング理解が必要。ただし、生成AIの指示だけで8割は作れるレベルまで来ている。

向いている検証:

• SaaS型サービスのコンセプト検証
• データの入出力がある機能の検証
• 支払い意欲の確認（実際に使った上での反応）
• BtoB向けダッシュボード・ツールの検証

→ AIプロトタイピングで検証を加速する — 3日でプロトタイプを作る方法

→ AI時代のプロトタイピング — Cursor / v0 / Bolt を活用した高速検証

4. ノーコードプロトタイプ

Bubble、Glide、STUDIOなどのノーコードツールで作るプロトタイプ。プログラミング不要で「動くもの」が作れる。

作り方: ノーコードツールのUIビルダーでページを構成し、データベースと接続する。フォーム、一覧表示、検索、マッチングなどの基本機能は、テンプレートで短期間に実装できる。

特徴:

• 制作時間: 3〜7日
• コスト: ツール利用料（月額数千円〜）
• 必要なスキル: ノーコードツールの操作知識
• 忠実度: 中〜高（動くが、カスタマイズに限界）

強み: プログラミング不要で動くサービスが作れる。データベースと連動するので、フォーム送信やデータ管理の検証が可能。

弱み: 複雑なロジックやカスタムUIには限界がある。ツールの制約に引っ張られて、本来作りたいものと違うものができることがある。

向いている検証:

• マッチングサービスの検証
• フォームベースの業務ツール
• シンプルなデータ管理サービス

→ ノーコードで新規事業のプロトタイプを作る — ツール選定と実践

4つのプロトタイプを一覧で比較

検証したい仮説で選ぶ

プロトタイプの種類は、検証したい仮説によって決まる。

コンセプトの方向性を確認したい → ペーパー or Figma

「この機能があったら嬉しいか」「画面構成はこれで伝わるか」。方向性の確認なら、ペーパーかFigmaで十分だ。

コードを書く必要はない。作るのに3日もかけない。30分で描いて、チームで議論する。方向が固まったら次に進む。

UIの使いやすさを検証したい → Figma

「この画面遷移で迷わないか」「ボタンの位置は直感的か」。UIの検証にはFigmaが最適だ。

画面遷移を設定して、顧客に操作してもらう。「次に何をすればいいかわかりますか？」。迷いや質問が出たポイントが、UIの改善点だ。

→ 仮説検証インタビューで聞くべき5つの質問

実際の使用体験を検証したい → コード

「このツールを使うと業務がどう変わるか」「入力から結果表示までの体験はどうか」。使用体験の検証には、動くプロトタイプが必要だ。

Figmaでは「入力したら結果が返ってくる」体験は作れない。コードプロトタイプなら、ダミーデータでもいいから実際にデータが動く。この差が、顧客の反応の具体性を変える。

支払い意欲を検証したい → コード or ノーコード

「このサービスに月額いくら払うか」。支払い意欲の検証には、顧客が「使った」と感じるレベルのプロトタイプが必要だ。

パワーポイントを見せて「月いくら払いますか？」と聞いても、正確な答えは返ってこない。実際に触った後に聞く「これに月3万円は妥当ですか？」の方が、はるかに信頼できるデータが取れる。

→ MVPとは何か — 新規事業で「最小限」をどう定義するか

新規事業のフェーズ別の選び方

新規事業には段階がある。段階によって、使うべきプロトタイプが変わる。

フェーズ1: アイデア初期（仮説整理段階）

使うプロトタイプ: ペーパー

まだアイデアが固まっていない段階。この段階でFigmaを開く必要はない。

紙に描いて、チームで共有して、「これは違う」「こっちの方が近い」を繰り返す。1日で10案描いて5案捨てる。この速度感が重要だ。

→ 仮説検証とは何か — 新規事業で「正解」を見つけるプロセス

フェーズ2: 課題検証段階（インタビュー中）

使うプロトタイプ: ペーパー or Figma

顧客インタビューで課題を確認している段階。インタビューの後半で「こういうものを考えている」と見せるための素材が欲しい。

この段階では、Figmaのワイヤーフレームレベルで十分。きれいなデザインは不要。「この方向性で課題は解決しそうか？」の反応が取れればいい。

フェーズ3: 解決策検証段階

使うプロトタイプ: Figma or コード

課題の存在が確認できた。次は「この解決策で顧客の課題は解決するか」を検証する段階。

SaaS型ならコードプロトタイプ。モバイルアプリならFigma。検証したい体験によって使い分ける。

ここで重要なのは、全機能を作らないこと。検証する仮説は1つに絞る。コア機能だけ。ログイン画面、設定画面、プロフィール画面は要らない。

フェーズ4: 収益検証段階

使うプロトタイプ: コード or ノーコード

「顧客はこの解決策にいくら払うか」を検証する段階。実際に「使った」と感じるレベルの体験が必要だ。

価格の検証は、プロトタイプの忠実度に比例して精度が上がる。Figmaで見せた「月3万円払う」より、動くプロトタイプを触った後の「月3万円払う」の方が信頼できる。

よくある失敗パターン

失敗1: 最初からコードプロトタイプを作る

課題が検証されていないのに、いきなりコードを書き始める。

2週間かけて動くプロトタイプを作り、顧客に見せたら「そもそもその課題を感じていない」と言われる。2週間が無駄になる。

順番が大事だ。まずペーパーかFigmaで方向性を確認し、課題の存在をインタビューで検証してから、コードプロトタイプに進む。

失敗2: Figmaで完璧なデザインを作る

検証用なのに、デザインの完成度にこだわる。色、フォント、アイコン、余白。3日間Figmaと格闘して、顧客に見せるのは来月。

検証用プロトタイプは、顧客が反応できれば十分だ。ワイヤーフレームレベルでいい。色は2色。フォントは1つ。完璧なデザインは、事業判断が出た後でいい。

失敗3: プロトタイプを作ることが目的になる

「プロトタイプを作る」がゴールになっている。作って満足する。顧客に見せない。

プロトタイプは顧客の反応を引き出すための道具だ。作っただけでは何もわからない。大事なのは、プロトタイプを使って何を検証するか。その設計が先にある。

プロトタイプを使ったユーザーテストのコツ

プロトタイプを作ったら、顧客に見せる。このとき、いくつかのコツがある。

1. 説明しない。操作してもらう。

「これはこういうサービスで...」と説明を始めない。「触ってみてください。何をするものか、見てわかりますか？」。操作中の迷い、質問、表情。すべてがデータだ。

2. インタビューの後半で見せる。

いきなりプロトタイプを見せない。まず30分、課題のインタビューをする。顧客が自分の課題を語った直後に、「実はこういうものを作っています」とプロトタイプを見せる。課題を語った直後だから、反応がリアルになる。

3. 行動レベルの質問をする。

「どう思いますか？」ではなく。「これが明日から使えるとしたら、最初に何をしますか？」「月額いくらなら使いますか？」「今使っている〇〇と比べて、どちらを選びますか？」。

→ 仮説検証インタビューで聞くべき5つの質問

→ ユーザーテストの進め方 — プロトタイプの反応を正しく読む

まとめ

プロトタイプには4つの種類がある。ペーパー、Figma、コード、ノーコード。

選び方の原則は1つ。検証したい仮説に合わせて選ぶ。

• コンセプトの方向性確認 → ペーパー（30分）
• UIの直感性検証 → Figma（1〜3日）
• 使用体験の検証 → コード（2〜5日）
• 支払い意欲の検証 → コード or ノーコード（3〜7日）

高忠実度のプロトタイプが常に正解ではない。低忠実度で十分な検証に、コードプロトタイプは要らない。逆に、支払い意欲の検証にペーパープロトタイプでは精度が出ない。

仮説が先。プロトタイプの形はその後で決まる。

LITMUSは、新規事業の検証に特化したスタジオです。検証したい仮説に応じたプロトタイプの設計・制作から、ユーザーテスト、事業判断レポートまで一気通貫で提供します。 50万円から始められるEntry Moduleもあります。詳しくは LITMUS をご覧ください。