プロトタイピングとは｜手法の使い分けと進め方・ツール

プロトタイピングとは、本格的に作り込む前に試作品（プロトタイプ）を作り、アイデアや仕様を早い段階で検証する手法です。紙のスケッチから実際に動くコードまで手法には幅があり、使い分けの軸は「何を確かめたいか」と「どこまで本物に近づける必要があるか（忠実度）」の2つに集約されます。

この記事では、定義と進め方、手法の分類、忠実度の使い分け、2026年時点で現役のツールまでを整理します。そのうえで、生成AIの登場で使い分けの定石がどう変わったかを、実際の現場で起きた出来事から解説します。

プロトタイピングとは

定義

プロトタイピング（prototyping）は、製品やサービスの試作品を作って検証する行為・工程を指します。試作品そのものがプロトタイプ、それを作って確かめる営みがプロトタイピングです。ソフトウェア開発、UI/UXデザイン、新規事業の検証で広く使われ、対象も画面のスケッチから動くアプリまでさまざまです。

共通するのは「完成させる前に、安く間違えておく」という考え方です。完成後に間違いが見つかると、直すのに大きなコストがかかります。試作の段階で同じ間違いに気づけば、小さなコストで済みます。頭の中のアイデアは、形にして初めて他人と一緒に検証できるようになります。

なぜ必要か：実装前に潰せる意思決定がある

プロトタイピングの価値は、「投資1に対してリターン数十倍」のような派手な数字で語られることがあります。しかし、そうした倍率は出所が曖昧なものが多く、持ち出す必要はありません。価値の正体は、実装前に決着をつけられる意思決定の種類にあります。

具体的には、仕様の合意（関係者が同じ完成像を見ているか）、操作の迷い（利用者が説明なしで使えるか）、優先順位（どの機能が本当に要るか）の3つです。この3つは、実装が終わってから発覚すると、直すのに数週間〜数か月の手戻りになります。試作の段階なら数日で答えが出ます。つまりプロトタイピングとは、直すのに高くつく意思決定を、直すのが安い段階に前倒しする仕組みです。これがプロトタイピングの経済合理性です。

メリット

実務で得られる効果は3つに整理できます。課題の早期発見（作り込む前に問題が見える）、品質の向上（利用者の反応を設計に反映できる）、コミュニケーションの改善（動くものが関係者の共通言語になる）です。

3つ目は過小評価されがちですが、実務では最も効きます。仕様書は読む人の数だけ解釈が生まれますが、実際に触れる試作なら、全員が同じものを見て話せます。

進め方：3ステップ

プロトタイピングの工程はシンプルです。

1. 目的の設定——この試作で何を確かめるかを1行で書く

2. 試作——確かめたいことに必要な最低限の忠実度で作る

3. テスト・評価——想定利用者に触ってもらい、結果を次の試作か実装に反映する

工程の肝は1です。目的を書かないまま作り始めた試作は、できあがっても評価のしようがありません。触った人の感想を聞くだけで終わり、次の判断につながらなくなります。

落とし穴6つと、現場での検知シグナル

UXリサーチや開発の現場で共通して報告される落とし穴を、気づくためのシグナルとセットで挙げます。

落とし穴	現場での検知シグナル
目的なしに作り始める	「何を確かめる試作か」に誰も即答できない
実用性を作り込もうとする	試作に3日以上かけ始めている
アイデアに固執する	否定的な反応を「使い方が悪い」と解釈し始める
自分の試作に惚れ込む	捨てる選択肢が会話から消えている
紙のスケッチを軽視する	最初の案からツールで清書している
誤った忠実度を選ぶ	操作性を確かめたいのに静止画を見せている

いずれも能力の問題ではなく、工程の問題です。シグナルに気づいたら、目的の1行に立ち返ってください。

隣接概念との切り分け

プロトタイピングの周辺用語を4つ切り分けます。ここが曖昧だと、チーム内の会話がすれ違います。

PoC・MVPとの違い

PoC（概念実証）は技術やアイデアが成立するかの検証、MVPは市場に需要があるかの検証です。プロトタイピングは主に仕様・操作性・合意形成の検証を担います。確かめる相手で覚えると簡単です。PoCは技術に、プロトタイプは関係者と利用者に、MVPは市場に問いかけます。MVPの定義と作り方はMVPとはで詳しく解説しています。

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

ワイヤーフレームは画面の配置を示す骨組み、モックアップは色やデザインまで作り込んだ静止画です。どちらも「動かない」点でプロトタイプと区別されますが、実務ではワイヤーフレームやモックアップも忠実度の低いプロトタイプとして検証に使います。つまり別物というより、忠実度の階段の途中にある存在です。

アジャイルとの違い

アジャイル開発は短い周期で開発を繰り返す進め方の枠組みで、プロトタイピングは検証の手法です。層が違うため、アジャイルの各スプリントの中でプロトタイピングを行う、という入れ子の関係になります。「アジャイルだからプロトタイプは不要」にはなりません。

豆知識：語源は製造業の試作

プロトタイピングという言葉はソフトウェア以前からあり、製造業では金型を起こす前に樹脂や金属で試作品を作る工程を指してきました。3Dプリンタによる高速な試作はラピッドプロトタイピングと呼ばれ、現在も製造の現場で使われています。この記事はソフトウェア・新規事業の文脈に絞りますが、「量産の前に安く確かめる」という思想は同じものです。

手法の使い分け

プロトタイピングの手法は、忠実度と作成手段の2軸で整理すると迷いません。

忠実度：ローファイとハイファイ

忠実度（fidelity）は、試作がどれだけ本物に近いかの度合いです。本物から遠い順に、ローファイ（低忠実度）・ミドルファイ（中忠実度）・ハイファイ（高忠実度）と呼びます。

忠実度	例	向く検証	コスト
ローファイ	紙のスケッチ、ワイヤーフレーム	概念・情報構成・流れの合意	数分〜数時間
ミドルファイ	画面遷移するモック	操作の流れ・画面設計	数時間〜数日
ハイファイ	実デザイン・実データで動く試作	操作性の詳細・完成イメージ	数日〜

原則は「検証に足りる最低の忠実度を選ぶ」です。忠実度を上げるほどコストが増えるだけでなく、作った本人の愛着も増え、検証結果が悪くても捨てにくくなります。

手法の4分類

作成手段で分けると4系統になります。

• ペーパープロトタイピング——紙に描いた画面を並べ、指で操作を模擬する
• ワイヤーフレーム——配置と情報構成を線画で固める
• デジタルプロトタイピング——Figmaなどのツールで画面を繋ぎ、遷移を再現する
• コードプロトタイピング——実際に動くコードで作る。実データ・実環境の検証まで可能

下に行くほど忠実度の上限が上がり、コストも上がります。従来の定石は、上から順に段階的に進めることでした。この定石が近年崩れつつある点は、後半の実測の節で扱います。

ツールで再現できること

デジタルプロトタイピングツールで再現できるのは、画面のデザイン、画面間の遷移、タップやスクロールへの反応、簡単なアニメーションです。逆に、実データの表示、検索や計算の結果、外部システムとの連携は再現できないか、作り込みに大きな手間がかかります。確かめたいことがデータや性能に及ぶ場合は、コードプロトタイピングの領域です。

検証したい問いから忠実度を逆算する早見表

手法から選ぼうとすると迷うので、問いから逆算します。実務で使っている対応表を置きます。

検証したい問い	最低限の忠実度	使う手法
この流れで業務が回るか	ローファイ	紙・ワイヤーフレーム
画面構成と導線は自然か	ミドルファイ	デザインツールの遷移モック
説明なしで操作できるか	ミドル〜ハイファイ	デジタルプロトタイプ＋観察
この見た目で世界観が伝わるか	ハイファイ	デザイン作り込み版
実データでも成立するか	ハイファイ（コード）	コードプロトタイプ
技術的に実現できるか	コード（PoC寄り)	動く検証コード

問いが複数あるときは、上の行から順に別々の試作で確かめるほうが、1つの豪華な試作で全部を確かめるより速く安く済みます。

「問いから逆算する」の実例を1つ挙げます。この記事を発信しているARCHECO（AIプロダクト開発の支援会社）が関わったプロダクトでの話です。検証の中身は、先に切り分けたMVP寄り——市場に問いかける検証——ですが、ここで見てほしいのは手法ではなく、試作の出来より先に「答えるべき問い」の設定が結果を分けた点です。旅行者向けの注文サービスを立ち上げるにあたり、ログイン機能すらない最低限の注文画面だけの試作を作り、訪れた人がその場で注文画面を開いて試せる形にして、まず観光案内所に置きました。結果は、1件も売れませんでした。ところが、同じ試作をそのままホテルに置き換えた途端、注文が入り始めました。試作は1文字も変えていません。変えたのは置き場所だけです。つまりこの検証で答えを出すべき問いは「試作の完成度が足りているか」ではなく「どの場所なら売れるか」でした。試作の出来を上げる前に、その試作がどの問いに答えるためのものかを1行で書いてみてください。

ツール比較：2026年時点の現役

ツール紹介記事には、Adobe XD（すでに新機能開発を終了しメンテナンスモードに移行済み）や旧世代のツールが残っていることが多いため、2026年時点で実務に使える選択肢を海外の第一線を含めて整理します。

ツール	提供元	得意領域
Figma	Figma（米）	画面設計〜遷移モックの業界標準。共同編集
ProtoPie	Studio XID（韓）	タップ以外の動き（傾き・入力値など）まで再現する高忠実度の試作
Framer	Framer（蘭）	高忠実度モック〜実サイト公開まで
UXPin	UXPin（米）	部品単位で画面を組み上げる詳細設計
v0	Vercel（米）	プロンプトから動くUIコードを生成
Claude・ChatGPT	Anthropic／OpenAI（米）	対話で動く試作コードを生成・修正
ノーコードツール（Bubble等）	各社	データを持つ動く試作を非エンジニアが構築

現在の中心はFigmaで、画面設計から遷移モックまでを1つで賄えます。変化が大きいのは下3行のAI・ノーコード系です。従来は、デザインツールで作る「見た目の試作」と、開発しないと作れない「動く試作」の間に、コストの大きな段差がありました。AI・ノーコード系のツールは、この段差を埋めつつあります。

この記事が語る範囲

ここからは、ソフトウェア・新規事業の検証で使うプロトタイピングに絞って進めます。開発会社に外注するときの費用や契約の話は、発注者の視点で書いたプロトタイプ開発の記事で扱っています。この記事は、手法を選ぶ立場——自分で作る人、検証を設計する人——に向けて、使い分けの実際を掘り下げます。

手法の分類は正しい。ただし失敗の原因は手法選びではない

ここまで、忠実度の考え方、手法の4系統、問いから逆算する早見表を整理してきました。この分類は実務でそのまま機能します。分類自体に異論はありません。

ただし、プロトタイピングが実際に失敗するとき、原因の大半は手法の選び間違いではありません。「この試作で何を確かめたいか」が決まっていないことです。落とし穴の節で挙げた6つのうち5つは、目的が決まっていないことから派生しています。手法の知識を増やすより先に、試作を1つ作るごとに検証したい問いを1行書く習慣をつけるほうが、成果に直結します。そして問いさえ固まれば、先ほどの早見表が忠実度と手法を自動的に決めてくれます。

実測：AI時代にプロトタイピングの定石はどう変わったか

この記事を発信しているARCHECOは、AIプロダクト開発の支援会社です。顧客の支援と自社サービスの開発の両方で、プロトタイピングを日常的に行っています。生成AIを試作の工程に取り入れてから、教科書に書かれてきた定石が、実際の現場で2か所崩れました。何がどう崩れたかを共有します。

忠実度の逆算が崩れた：高精度なプロトタイプが最安になる瞬間がある

従来の定石は「検証に足りる最低の忠実度を選ぶ」でした。この定石には、「忠実度が低いほど安く早く作れる」という前提があります。紙のスケッチは数分で描けるが、実際に動くアプリを作るには数週間かかる。だからまず紙で確かめ、必要になったら段階的に本物へ近づける、という考え方です。

生成AIでコードの試作が作れるようになり、この前提が部分的に逆転しました。要件を文章で伝えれば、実際に動く高精度なプロトタイプが数時間から数日で出てくるようになったからです。ケースによっては、紙のスケッチやデザインツールでのモック作成という中間の工程を全部飛ばして、最初から動くコードで作るほうが、速くて安くなります。

この逆転を目の当たりにした出来事を1つ紹介します。ARCHECOは、複数の企業が集まって新しいサービスを共同で作るプロジェクト（共創プロジェクト）に参画しています。そのプロジェクトで、各社がアプリの企画を持ち寄って発表する会が予定されていました。その会の前日、参加者の1人が、プロジェクトのチャットにURLを1本投稿しました。開いてみると、翌日発表されるはずの企画が、すでに動くアプリの試作になっていました。アプリストアで配信できそうな見た目で、実際に画面を操作できます。

翌日の会で、投稿した本人が作り方を説明しました。生成AIに企画資料のファイルを渡し、出てきた試作に修正の指示を数回出しただけ。かかった時間は40分ほどだったといいます。しかも指示文は細かく作り込まず、あえて雑なまま出したそうです。指示文を磨き込む時間すら、掛ける必要がなかったということです。

この出来事の何が大きいのか。半年前まで、このプロジェクトでの企画の議論は「それを作るには何か月かかるか」を前提に組み立てられていました。作るのに何か月もかかるからこそ、作る前に企画書で完成像を言葉で説明し、関係者の合意を取る工程が必要だったわけです。ところが、動く試作が40分で出てくるなら、完成像を言葉で説明する工程そのものが要らなくなります。最初から、触れる試作を囲んで議論を始めればいい。実際、このプロジェクトの議論の進め方は、この週を境に変わりました。見出しに書いた「高精度なプロトタイプが最安になる瞬間」とは、この状態のことです。動く試作をいきなり作ることが、説明資料を作るよりも安くて速い——そういう瞬間が、実際に存在するようになりました。

ただし、崩れたものと残ったものを区別しておく必要があります。崩れたのは「忠実度が低いほど安い」というコストの前提です。一方、「検証したい問いから逆算して手法を選ぶ」という原則は崩れていません。ブランドの世界観が伝わるかを確かめたい場合や、デザインの細部を詰めたい場合など、デザインの意思決定が主題なら、デザインツールで作り込む工程は今も必要です。変わったのは、動くものを検証するときのコストだけです。

作り直し回数が増え、1案あたりの愛着が減った

試作を1つ作るコストが下がると、検証の回し方そのものが変わります。従来は、試作を作るのに時間がかかるため、1つの案をじっくり磨き込む進め方が中心でした。現在は、同じ画面の試作を複数パターン同時に作り、実際に触り比べて、良くないものを捨てる進め方が成立します。ARCHECOの実務でも、複数案を並行で作って比較し、残った1案だけを磨く形が標準になりました。

この変化には、良い副作用がありました。前半の落とし穴で挙げた「アイデアに固執する」「自分の試作に惚れ込む」が、起きにくくなったのです。理由は単純で、捨てるコストが下がると、人は素直に捨てられるからです。何日もかけて作った試作には愛着が湧いて手放せなくなりますが、短時間で作ったものなら未練なく捨てられます。プロトタイピングの落とし穴として語られてきたことの多くは、人の性格の問題ではなく、試作が高価だった時代のコスト構造が生んでいた問題だった、ということです。観察を通じた検証設計の考え方はデザイン思考の観察で、AI時代のUI/UX設計の変化はAI時代のUI/UXデザインで扱っています。手法の使い分けを実装で支援する体制はサービス紹介ページにまとめています。

現場の壁

手法を正しく選んでも、運用でぶつかる壁があります。代表は3つです。

1つ目は、評価者の偏りです。社内の関係者だけで評価すると、操作の迷いが検出されません。作った経緯を知っている人は、迷わず操作できてしまうからです。想定利用者に触ってもらう場を、最低1回は工程に入れてください。テストの実施方法自体は独立した論点なので、ここでは「作る工程と同じ重さで評価の工程を設計する」とだけ述べておきます。

2つ目は、役目を終えた試作の扱いです。検証が終わって捨てるはずだった試作が、社内で資料として独り歩きし、いつの間にか正式な仕様として扱われてしまう、という事故が起きます。防ぐには、試作にバージョンと状態（検証済み・破棄）を明記しておきます。

3つ目は、AIで作った試作の品質の誤認です。動いているように見えても、本番のプロダクトに求められる設計品質は備わっていません。実装に引き継ぐ場合は、試作を土台に拡張するのではなく、作り直しを前提に見積もってください。

まとめ

プロトタイピングとは、完成前に試作で検証する手法であり、使い分けの軸は「検証したい問い」と「それに足りる最低の忠実度」の2つです。手法はペーパー・ワイヤーフレーム・デジタル・コードの4系統、ツールはFigmaを中心にAI系が加わった構成が2026年時点の現役です。

そして、手法選びより先に効くのは、試作ごとに問いを1行書くことです。問いが決まれば忠実度は逆算でき、忠実度が決まれば手法とツールは自動的に決まります。

この先

生成AIによる試作の低コスト化は、まだ途中です。動く試作の単価が下がり続けると、プロトタイピングは専門家の工程から、企画・営業・現場を含む全員の日常動作に近づいていきます。

そのとき希少になるのは、ツールを操作する技能ではなく、検証を設計する技能です。何を確かめるべきか、誰に触ってもらうべきか、結果をどう判断に繋ぐか。プロトタイピングの本体は、最初からツールの外側にあります。

よくある質問

プロトタイピングとはどういう意味ですか？

製品やサービスを本格的に作り込む前に、試作品（プロトタイプ）を作ってアイデアや仕様を検証する手法・工程のことです。紙のスケッチから動くコードまで忠実度に幅があり、検証したい問いに合わせて使い分けます。

プロトタイピングとアジャイルの違いは何ですか？

アジャイルは短い周期で開発を繰り返す進め方の枠組みで、プロトタイピングは検証の手法です。層が違うため対立せず、アジャイルの各スプリントの中でプロトタイピングを行う入れ子の関係になります。

プロトタイピングの例にはどんなものがありますか？

紙に描いた画面を指で操作するペーパープロトタイプ、Figmaで画面を繋いだ遷移モック、生成AIで作った動く試作アプリなどが代表例です。製造業では3Dプリンタによる試作（ラピッドプロトタイピング）が同じ思想の例になります。

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

試作→評価→修正のサイクルを本開発の前に組み込んだ開発の進め方を指します。プロトタイプ開発とも呼ばれ、発注・費用など開発プロジェクトとしての論点は、プロトタイプ開発の記事で発注視点から解説しています。

プロトタイピングツールは何を選べばよいですか？

画面設計と遷移モックならFigmaが業界標準です。高度なインタラクションの検証はProtoPie、実サイトに近い形ならFramer、動く試作を素早く作るならv0や対話型AIによるコード生成が2026年時点の現役の選択肢です。確かめたい問いを先に決めると、ツールは逆算で決まります。

ローファイとハイファイはどちらで作るべきですか？

原則は「検証に足りる最低の忠実度」です。流れや構成の合意ならローファイ、操作性の詳細や世界観の検証ならハイファイが必要になります。ただし生成AIの登場で動く試作の単価が下がり、最初からコードで作るほうが速いケースも増えています。

プロトタイピングの落とし穴は何ですか？

代表的なのは、目的を決めずに作り始める、試作を作り込みすぎる、アイデアに固執する、誤った忠実度を選ぶ、の4つです。いずれも「この試作で何を確かめるか」を1行書いてから作ることで、大半を防げます。

プロトタイプは何回作り直すものですか？

決まった回数はありませんが、検証したい問いに答えが出たら終わり、が原則です。生成AIの活用で作り直しの単価が下がったため、複数案を並行で作って触り比べ、残した案だけを磨く進め方が現実的になっています。

生成AIがあるなら、最初からハイファイで作るべきですか？

動くものの検証が主題なら、それが最も安いケースが実際にあります。実例では、企画資料を添付した簡単な指示だけから、実際に操作できるアプリの試作が40分で出てきました。ただし崩れたのは「忠実度が低いほど安い」というコストの前提だけで、「検証したい問いから逆算する」原則は残ります。世界観やブランドの検証が主題なら、デザインツールの工程は今も必要です。

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

AIプロダクト開発について・お問い合わせ