TRACERYプロダクトマネージャーの haru です。
システム開発では、要求の妥当性を早期に検証し、関係者との認識を揃えるために、UIの構造や操作イメージを視覚的に表現し、合意形成を促進する手法が用いられます。
特に企画や要件定義フェーズでは、テキストだけでは伝わりにくい仕様の意図やユーザー体験を、ワイヤーフレームやプロトタイプなどを通じて共有し、認識のズレを減らすことが重要です。
本記事では、こうした場面で活用されるワイヤーフレーム、モック、プロトタイプの違いや、それぞれの適切な使いどころと注意点について解説します。
ワイヤーフレーム、モック、プロトタイプの違い
３つの手法の違いを下表にまとめました。
| 用語 | 概要 | 表現の精度 | 操作性 | 主な目的 |
|---|---|---|---|---|
| ワイヤーフレーム (Wireframe) | 画面レイアウトの構造を示す簡易図 | 低 | なし | 情報設計・構造の確認 |
| モック (Mock / Mockup) | デザインを反映した静的な画面の見た目見本 | 中〜高 | なし | ビジュアル確認・レビュー |
| プロトタイプ (Prototype) | 実際に操作可能な動作付き画面 | 高 | あり | 操作性やユーザーフローの検証 |
以下にそれぞれについて説明します。
ワイヤーフレーム
ワイヤーフレームは、画面構成を簡素な線やテキストで表現した図です。色や画像、装飾などの要素は排除され、ボタンや入力欄などのUIパーツの配置や、画面遷移の流れを伝えることに特化しています。
たとえば、要件定義初期に「とりあえず画面の構成をざっくり共有したい」といった状況で有効です。細部にとらわれず、情報設計の方向性を早く確認できるのが最大の利点です。
留意点
ワイヤーフレームは見た目がシンプルなだけに、レビューが形骸化しやすい点には注意が必要です。
「あとで直せばいい」とスルーされがちですが、この時点で構造上の見落としがあると、後工程での手戻りにつながります。
モック
モックは、実際のデザインに近い静的な画面イメージです。配色、フォント、画像なども含まれ、画面がどのように見えるかを視覚的に伝えることができます。ただし、操作はできません。
特に、ビジュアルを重視する意思決定者に「完成イメージ」を伝える際に効果を発揮します。「この画面でOKですか？」という合意形成にも使われます。
留意点
モックはデザインが完成されて見えるがゆえに、「このまま動く」と誤解されるリスクもあります。設計や開発の準備が整っていない段階でモックだけが先行すると、見た目だけ進んで中身が追いつかない、という事態に陥ることもあります。
プロトタイプ
プロトタイプは、画面を実際に操作できる動作付きのモデルです。クリックで画面が遷移したり、アニメーションが動いたりと、ユーザーの操作体験を検証できる点が特徴です。
実務では、ユーザビリティテストやUXの確認に使われることが多く、動くものを通して「このUIで迷わず操作できるか」「想定した導線は機能しているか」を検証できます。
留意点
プロトタイプは動くがゆえに誤解も生まれやすく、「このまま製品として使えるだろう」と判断されることがあります。
実際には、UIだけを仮に組んだものであり、アーキテクチャやコード品質が製品基準に達していないケースがほとんどです。目的と再利用の可否を明示することが極めて重要です。
プロトタイプの取り扱いに関する事前合意の重要性
プロトタイプを開発する際は、着手前にその目的と取り扱い方について、関係者間で明確な合意を形成しておくことが不可欠です。
とくに「プロトタイプを製品コードに転用するのか」「あくまで検証用として破棄するのか」といった位置づけを曖昧にしたまま進めてしまうと、後続工程に深刻な影響を及ぼします。
たとえば、開発側が短期間で仮実装を行う際、以下のような割り切りがよく見られます。
- ビジネスロジックを本来の責務に分けず、コントローラやビューの中に直接書き込む実装*1
- SPA構成を前提とする本番環境（例：Next.js）に対して、プロトタイプではバックエンドのテンプレート機能（例：Djangoテンプレート）のみを用い、SPAとしての分離や動的処理を省略するなど、フロントエンド技術スタックを簡略化した構成とする
- 入力チェックやエラーハンドリングの省略
こうしたコードは「動くこと」に特化しており、品質・保守性・拡張性といった製品として求められる要件を満たしていない場合が多くあります。
それにもかかわらず、発注側が「このプロトタイプが動くなら、これをベースに製品開発できるはず」と認識してしまうと、実際の製品開発フェーズで全面的なリファクタリングやアーキテクチャの再設計が必要となり、開発コストや納期に大きな影響が出ます。
「暫定コードを残したまま本番運用に突入し、技術的負債が固定化する」といったリスクも高まります。
こうした事態を防ぐためには、プロトタイプの技術的前提（再利用の可否、品質レベル、寿命など）をあらかじめ明示し、関係者と合意しておくことが重要です。
ソフトウェアエンジニアリングの名著『実践ソフトウェアエンジニアリング (第9版)』第4章では、「推奨されるプロセスモデル」として、製品化を見据えたインクリメンタルかつスパイラル型のプロトタイプ開発プロセスが解説されています。興味のある方はぜひ参照してみてください。
まとめ
ワイヤーフレーム、モック、プロトタイプは、それぞれ異なる精度・目的・操作性を持つ表現手法であり、企画や要件定義の各フェーズで使い分けることが重要です。
ワイヤーフレームは情報構造の把握に、モックは見た目の合意形成に、プロトタイプは操作感や導線の検証に向いています。
特にプロトタイプは、見た目も動きもそれらしく仕上がるため、「このまま製品に使える」と誤解されるリスクが高い点に注意が必要です。
実際には、開発スピードを優先した仮実装であることが多く、製品レベルの品質・構造を満たしていないケースも少なくありません。
近年では、AIを活用してUIコンポーネントやレイアウトを瞬時に生成できるツール（例：v0）が登場し、プロトタイプ作成は格段に容易になりました。
一方で、こうしたツールで生成されたプロトタイプは、使用されている技術スタックを共有せずに利用したり、独自デザインやビジネスロジックを組み込む際の追加コストを把握しないまま採用したりすると、完成度や開発工数に対する誤った認識を招きやすくなります。
こうした誤解を防ぐには、プロトタイプの目的、寿命、再利用の可否といった前提条件を、開発着手前に関係者間で明確に合意しておくことが不可欠です。
「何のために」「どこまで作り」「どこまで使うか」を明確にすることが、プロジェクト全体の品質と効率に直結します。
*1:エンタープライズアプリケーションアーキテクチャパターンでは、トランザクションスクリプトというパターンで紹介されています。
