「次はモックアップを作成します。その後にプロトタイプで検証しましょう」。開発会社からそう提案された瞬間、何にどの順番で承認印を押せばよいか分からず手が止まってしまった経験はないでしょうか。ワイヤーフレーム・モックアップ・プロトタイプの3つは似て非なる成果物で、違いを曖昧にしたまま進めると後工程で修正コストの爆発を招きかねません。
発注者として困るのは、各成果物の「定義」だけでなく「自分が何を見てOKを出すか」という承認観点まで踏み込んだ情報源が少ない点です。多くの解説記事はデザイナー視点で書かれており、発注プロセスのどこに位置づき、承認漏れがどのような手戻りを生むかまでは触れていません。
本記事ではWeb・アプリ開発を発注する事業会社の担当者を想定し、3者の違いを「発注者の意思決定」という軸で整理します。比較表・承認観点・発注プロセス上の位置づけ・代表的なツール・受領時チェックリストまで押さえれば、ベンダーの提案に対して「今はモックアップ段階だから色とフォントを確認すべき」と自信を持って次のアクションを依頼できるようになります。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ワイヤーフレーム・モックアップ・プロトタイプの違いをひと目で理解する
まず結論から確認しましょう。3者は「どの段階で・何を確認するための成果物か」が明確に異なります。
項目 | ワイヤーフレーム | モックアップ | プロトタイプ |
|---|---|---|---|
主な目的 | 情報設計・画面構成の確定 | 見た目・トンマナの確定 | 操作感・遷移の検証 |
成果物の形式 | 線画・モノクロの静止画 | 色・画像を反映した静止画 | クリック・入力ができる動く試作物 |
主な担当 | UI/UX デザイナー・PM | UI デザイナー | UI/UX デザイナー・フロントエンド |
発注者が承認すべきポイント | 配置・遷移・情報の過不足 | 色・フォント・ブランドイメージ | 操作の自然さ・エラー時の挙動 |
主な使用ツール | Figma / Miro / 手書き | Figma / Adobe XD / Sketch | Figma / ProtoPie / コード試作 |
ポイントは「忠実度（fidelity）」の階段になっていることです。ワイヤーフレームは骨組み、モックアップは皮を被せた静止画、プロトタイプは触れる試作物という順で完成イメージへ近づきます。発注者として大切なのは、自分のプロジェクトが今この階段のどこにいて、次にどの成果物の承認を求められているかを把握することです。
なお「デザインカンプ」はモックアップとほぼ同義で使われ、「プロトタイプ」は動くモックアップを指す場合と PoC・MVP に近い実装試作を指す場合があります。社内外で言葉の意味がずれていないかを最初に確認しておくと認識違いを防げます。
モックアップとは何か（本記事の主役）
モックアップとは、ワイヤーフレームに色・フォント・画像・アイコンなどの視覚要素を加え、完成イメージに近づけた静止画の成果物です。英語の「mockup」は「実物大の模型」が原義で、「実際の画面に限りなく近い見本」と理解すれば十分です。
モックアップは「ユーザーが画面を開いた瞬間にどう感じるか」をすり合わせる最後の静止画段階です。ここで違和感を残したまま開発に進むと、コードでの修正コストはモックアップ修正の数倍に跳ね上がります。受領時は「綺麗かどうか」ではなく、後述のチェックリストで体系的に確認することが求められます。
モックアップの目的（発注者が見るべきもの）
モックアップ段階で発注者が承認すべき観点は、大きく次の3つです。
- ビジュアル整合性: ロゴ・コーポレートカラー・既存サービスとのトーン統一が取れているか
- 情報の優先度: 重要な訴求や CTA が視覚的に十分目立つ位置・サイズで配置されているか
- 可読性: 文字サイズ・行間・コントラストが想定ユーザーにとって読みやすいか
逆にこの段階で「ボタンを押したらどう動くか」を完全に判定するのは困難です。動きの検証は次のプロトタイプフェーズに譲り、モックアップでは静止画として確認できる項目に集中するのが効率的です。
デザインカンプとモックアップの違い（実務上はほぼ同義）
「モックアップとデザインカンプは何が違うのか」という疑問はよく聞かれますが、結論から言えば現在の Web・アプリ制作現場では両者はほぼ同義です。歴史的にはデザインカンプ（Comprehensive layout の略「Comp」が語源）は紙媒体の「印刷前の最終確認用見本」を指す言葉で、Web でも当初は PSD で作る完成イメージをそう呼びました。近年は Figma などのツールに集約され区別する意味は薄れているため、会議の冒頭で「呼び方が違うだけで同じものを指している」と確認しておけば認識違いは防げます。
ワイヤーフレームとは何か
ワイヤーフレームとは、画面に「何を・どこに・どの優先度で配置するか」を線画レベルで定義した設計図です。線・四角・テキストだけで描かれることが多く、色や装飾は最小限に抑えられます。建築でいえば間取り図に相当し、「玄関・リビング・寝室の配置」を確定させる段階と考えると分かりやすいでしょう。
ワイヤーフレームの本質は「情報設計（IA: Information Architecture）」の確定であり、見た目を作る作業ではありません。ここで「会員登録ボタンの位置」「ページ間の遷移」が決まり、以降のモックアップ・実装はこの骨組みの上に肉付けされていきます。
ワイヤーフレームで承認すべきこと（情報設計・導線）
発注者が承認すべきは、見た目ではなく「ユーザーが目的を達成できる導線になっているか」です。
- 情報の過不足: 必要な項目が網羅され、不要な情報で画面が散らかっていないか
- 配置の優先度: 一番見せたい情報・押させたいボタンが視線の集まる位置にあるか
- ページ間の遷移: 目的のページまで何クリックで到達できるか、戻る導線は確保されているか
- 入力フォーム: 必須/任意の区別、エラー表示位置、確認画面の有無
色や装飾がない分、見た目に惑わされず冷静に構造を判断できるのがメリットです。「この導線で本当にユーザーは登録完了まで進めるか」という観点で読み解くのがコツです。
ワイヤーフレームとモックアップの違い（本質的な差）
両者の違いを「色やフォントの有無」だけで覚えるのは表面的で、本質的な差は確定させる対象の違いにあります。
観点 | ワイヤーフレーム | モックアップ |
|---|---|---|
確定する対象 | 情報設計・導線 | 見た目・トンマナ |
主な議論 | 何を・どこに置くか | どう見せるか |
修正コスト | 比較的低い | やや高い（配色・素材の再制作） |
発注者の判断軸 | 構造として成立しているか | ブランドに合っているか |
ワイヤーフレーム段階で導線の不整合を見逃すと、モックアップ以降の各段階で修正が必要になり手戻りコストが累積します。「導線確定はワイヤーフレームで」「見た目確定はモックアップで」と役割を切り分けて承認することが、後工程のトラブルを防ぐ最大のコツです。
プロトタイプとは何か
プロトタイプとは、実際にクリック・入力・画面遷移ができる動く試作物です。モックアップが静止画で「見た目」を確認するのに対し、プロトタイプは「操作したときに何が起きるか」を体感するための成果物です。
Figma などのツールでは画面同士を矢印でつなぐことで簡易プロトタイプを作成でき、より高度な検証が必要な場合はコードを書いて動作する試作版を作るケースもあります。PoC や MVP との関係、開発手法としてのプロトタイピングの詳細はプロトタイプ開発の解説記事で深掘りしています。
プロトタイプで検証すべきこと（操作感・遷移・例外パターン）
プロトタイプ段階で発注者が承認・検証すべき主なポイントは以下の通りです。
- 操作の自然さ: タップ・クリックの反応が想定通りか、押せる場所が直感的に分かるか
- 遷移の妥当性: 画面が切り替わるタイミングと方向（戻る・進む・モーダル）に違和感がないか
- 例外パターン: 入力エラー・通信失敗・データが空のときの表示が用意されているか
- タスク完遂: 想定ユーザーが「会員登録」「購入」など主要タスクを迷わず完了できるか
可能であれば実際の想定ユーザー数名にプロトタイプを触ってもらい、「どこで詰まったか」を観察するユーザーテストを実施するとさらに効果的です。ここで発見した課題は実装前に低コストで修正できます。
プロトタイプとモックアップの違い（動かないと分からないこと）
両者はいずれも高忠実度の成果物ですが、動きの有無が決定的な差を生みます。「ボタンを押した瞬間のローディング表示が何秒続くと不安になるか」「フォームでエラーが出たとき、どこを直せばよいかが視覚的に分かるか」といった検証は静止画では判断しきれません。「モックアップで OK を出したが、実装後に動かしてみたら操作感に違和感があった」という典型的な手戻りは、プロトタイプ検証を省いた場合に起きやすい失敗パターンです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
3者を発注プロセスのどこで使うか（意思決定フロー）
次に、3者が発注プロセスのどこに登場し、どの順番で何を承認していくかを見ていきます。本記事の中核セクションです。
発注プロセス全体での位置づけ
一般的なシステム開発の発注フローでは、3者は次の順で登場します。
要件定義
↓
ワイヤーフレーム作成 → 【承認1: 情報設計・導線】
↓
モックアップ作成 → 【承認2: 見た目・ブランド整合】
↓
プロトタイプ作成 → 【承認3: 操作感・例外挙動】
↓
開発（実装）着手 → テスト・リリース
各承認ポイントで確認対象が明確にレイヤー化されているため、発注者は段階ごとに集中して判断できます。
各フェーズで発注者が承認すべきこと
フェーズ | 承認すべき主な観点 | 確定するもの |
|---|---|---|
要件定義 | 機能一覧・優先度・スコープ | 開発する範囲 |
ワイヤーフレーム | 配置・遷移・情報の過不足 | 情報設計・導線 |
モックアップ | 色・フォント・ブランド整合 | 見た目・トンマナ |
プロトタイプ | 操作感・遷移演出・例外時の挙動 | UX・インタラクション |
ベンダーから事前に承認対象を伝えられない場合は、自分から「今回承認するのは導線ですか、見た目ですか、それとも操作感ですか」と確認することをお勧めします。承認対象を明確化するだけで会議の生産性が大きく上がります。
承認漏れが起きた場合の手戻りリスク
各フェーズで承認漏れが起きると、後工程に進むほど修正コストが指数的に増加します。
承認漏れの段階 | 後で気づいたタイミング | 想定される手戻り |
|---|---|---|
ワイヤーフレームの導線見落とし | モックアップ段階 | 配置やり直し・モックアップ作り直し（数日〜1週間） |
ワイヤーフレームの導線見落とし | 実装後 | フロント・バックエンド両方の改修（数週間〜1ヶ月） |
モックアップの色・トンマナ見落とし | 実装後 | CSS 修正・画像素材作り直し（数日〜1週間） |
プロトタイプの操作感未検証 | リリース後 | UX 改善のための再開発・利用者離脱（影響大） |
特に「ワイヤーフレーム段階の導線見落としを実装後に発見」は最も避けたいパターンで、情報設計の根幹をひっくり返すことになりスケジュール・予算の双方に大きな影響が出ます。
アジャイル開発でのプロトタイプサイクル
アジャイル型開発では、3者は1回作って終わりではなくスプリント（1〜2週間）ごとに小さく作って検証するサイクルを繰り返します。発注者の判断頻度はウォーターフォールより高くなる点を理解しておくとよいでしょう。
モックアップ制作の代表的なツール
モックアップ・プロトタイプ制作で広く使われているツールを発注者目線で整理します。ツール選定はベンダー側に委ねることが多いですが、共有・確認手段を理解しておくとレビューの生産性が変わります。
発注者がツール選定で確認すべきこと
- 共有形式: ブラウザの URL で閲覧できるか（専用アプリのインストールが不要か）
- コメント機能: 該当箇所に直接コメントを残せるか
- バージョン管理: 過去の版に戻せるか、差分が見られるか
- 権限管理: 閲覧のみ・編集可能などをメンバーごとに設定できるか
これらが満たされていれば社内の関係者に手軽にレビュー依頼でき、修正履歴も追えるため、コミュニケーションコストが下がります。
Figma（現在の業界標準）
Figma はブラウザベースで動作するデザイン・プロトタイピングツールで、現在の Web・アプリ制作の事実上の業界標準です。共有 URL を発行するだけで関係者全員がブラウザから閲覧・コメントでき、リアルタイム共同編集にも対応しています。専用ソフトのインストールが不要で、画面上にピンで残せるコメント機能により認識違いが起きにくい点が発注者から見たメリットです。
Adobe XD（Adobe エコシステム連携）
Adobe XD は Adobe 製品との連携に強みを持つツールでしたが、2023年1月に単体販売が停止され、2024年2月には Adobe から「今後 XD への追加投資は行わない」と正式発表されました（実質メンテナンスモード）。新機能開発は止まっており、既存の Creative Cloud ユーザーが継続利用できるのみで新規採用には向きません。これから始めるプロジェクトでは Figma を選ぶのが安全です。
モックアップツール比較表
ツール | 主な用途 | 共有形態 | 発注者目線の特徴 |
|---|---|---|---|
Figma | ワイヤーフレーム・モックアップ・プロトタイプ | ブラウザ URL | 業界標準。インストール不要・コメント可能・リアルタイム共同編集 |
Adobe XD | モックアップ・プロトタイプ | クラウド共有リンク | 2023年1月に単体販売停止・新機能開発も停止。既存 Creative Cloud ユーザーのみ継続利用可能で新規採用には向かない |
Sketch | モックアップ | ファイル受け渡し中心 | Mac 専用。歴史的ツール。Windows ユーザーは閲覧に工夫が必要 |
Miro | ワイヤーフレーム・初期構想 | ブラウザ URL | オンラインホワイトボード。付箋・図解と組み合わせた初期段階向け |
ベンダーから「Sketch のファイルで共有します」と提示された場合、Windows メインの発注組織では閲覧環境を別途整える必要が出ます。受領前に「ブラウザで見られる形式に変換可能か」を確認しておくのが安全です。
モックアップの作り方（発注者として確認すべきポイント）
モックアップ制作は通常、以下の流れで進みます。各ステップで何が決まるかを把握しておくとレビュー時の判断軸がぶれません。
モックアップ制作の一般的な流れ
- 要件整理: 機能一覧・対象ユーザー・ブランドガイドラインの確認
- ワイヤーフレーム作成: 情報設計・導線の確定
- デザイン要素の追加: 色・フォント・画像・アイコンを適用
- モックアップ完成: 主要画面（5〜20画面程度）を作成
- 発注者レビュー: 後述のチェックリストに沿って確認
- 修正反映 → 承認: フィードバックを元に修正し、次工程へ引き継ぎ
ステップ5の「発注者レビュー」が本記事のキモです。感覚レベルではなく具体的な観点で確認することで、後工程の手戻りを最小化できます。
受領時の確認チェックリスト（5項目）
会議前にこの表を手元に置き、各項目を埋める形でレビューすると漏れを防げます。
# | 確認項目 | 具体的なチェック観点 |
|---|---|---|
1 | ブランド整合性 | ロゴ・コーポレートカラー・既存サービスとのトーン統一が取れているか |
2 | 情報の優先度 | 一番伝えたいメッセージ・押させたい CTA が視覚的に十分目立っているか |
3 | 可読性 | 文字サイズ・行間・コントラストが想定ユーザーにとって読みやすいか |
4 | レスポンシブ対応 | PC・タブレット・スマホそれぞれのレイアウト案が提示されているか |
5 | コンテンツ反映 | 実際の文言・商品画像が反映されているか（または反映予定が明示されているか） |
なお、フィードバックを伝える際は「全体的にもう少し明るく」のような抽象表現ではなく、「項目2の CTA ボタンを20%大きく」「項目3の本文を14pxから16pxへ」のように該当箇所と具体的な修正内容をセットで伝えると、修正コストが下がり認識違いも減ります。
よくある質問
Q1: ワイヤーフレームを省略してモックアップから始めてもよいですか
小規模なランディングページなど画面数が少ないケースでは省略する場合もあります。ただし複数ページにまたがるサービスや業務システムでは省略すべきではありません。情報設計を飛ばすと見た目の議論に引きずられ導線の不備に気づきにくくなります。
Q2: モックアップだけで開発に進めますか
可能ですが、操作感に依存する機能が多い場合はプロトタイプによる検証を強くお勧めします。入力フォームが複雑なサービスや独自の操作感を売りにするアプリでは、静止画では発見できない違和感が実装後に表面化するリスクがあります。
Q3: モックアップとデザインカンプはどう違いますか
現代の Web・アプリ制作現場では両者はほぼ同義として扱われています。歴史的経緯から呼び方が異なるだけで、Figma などのツール上で作成される成果物としては同じものを指すことがほとんどです。社内外で呼称が異なる場合は最初に「同じものを指している」と確認しておきましょう。
Q4: 小規模なサイトでもプロトタイプは必要ですか
サイトの規模より「操作感が重要な機能を含むか」で判断します。静的な情報提供が中心ならモックアップで十分な場合が多く、会員登録・予約・決済などのインタラクションを含む場合は規模が小さくてもプロトタイプ検証を行う価値があります。
Q5: 各成果物の制作にかかる期間の目安はどれくらいですか
10画面程度の中規模サービスでは、ワイヤーフレーム1〜2週間、モックアップ2〜4週間、プロトタイプ1〜2週間が目安です。社内レビューと修正の往復で期間は伸びるため、レビュー観点を事前に整理しておくことが期間短縮の鍵です。
まとめ
ワイヤーフレーム・モックアップ・プロトタイプの3者は、それぞれ「情報設計」「見た目」「操作感」という異なるレイヤーを確定させるための成果物です。発注者として大切なのは、各フェーズで何を承認すべきかを正しく理解し、観点をぶらさずに判断することです。
- ワイヤーフレームで承認すべきは情報設計と導線。色や見た目ではなく、構造として成立しているかを確認する
- モックアップで承認すべきはブランド整合と可読性。受領時は5項目チェックリストで体系的にレビューする
- プロトタイプで検証すべきは操作感と例外パターン。動かして初めて分かる課題を実装前に洗い出す
ベンダーから次のレビューを提案されたとき、「今回は何を承認するフェーズか」を冒頭で確認するだけで会議の精度は大きく向上します。本記事の観点を持ち込み、自信を持って次のアクションを依頼していきましょう。
プロトタイプを「実装を伴う試作」として捉え、PoC や MVP との関係を含めて深掘りしたい方はプロトタイプ開発の解説記事もご覧ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
