「リニューアルしたら、社内から『イメージと違う』と言われてしまった」——先日、ある発注担当の方から相談を受けました。デザインのレビューでは全員が「いいですね」と合意していたのに、本番公開後に「思っていた使い心地と違う」という声が噴き出した、というのです。よく聞いてみると、レビューで見ていたのは Figma 上のきれいな完成イメージ。実際にユーザーが文字を打ち込んだり、読み込みを待ったり、入力ミスをしたりする様子は、一度も確認されていませんでした。
これは珍しい話ではありません。Smashing Magazine が 2026 年 5 月に公開した Your Prototype Is Not Being Honest With Your Users は、まさにこの問題を扱っています。記事の主張はシンプルで、多くのプロトタイプは「クリックすると次の画面に進む紙芝居」でしかなく、ユーザーに対して正直ではない、というものです。本物のアプリなら、入力欄には実際にキーボードで文字を打てるし、間違ったパスワードを入れればエラーが出る。空欄のまま進もうとすれば止められる。ところが静的プロトタイプは、そのどれも再現しません。レビューで合意した「体験」は、実は体験ではなく、止まった一枚の絵にすぎなかったわけです。
静的プロトタイプがついている「嘘」
ここでいう「嘘」は、誰かが意図的についているものではありません。ツールの構造的な限界です。Figma に代表される画面遷移型のプロトタイプは、あらかじめ用意した複数の画面（フレーム）を、クリックで切り替えて見せる仕組みです。一つひとつの画面は美しく、提案資料としては完璧に見えます。だからこそレビューが通る。けれど、その美しさは「すべてがうまくいったときの、たった一通りの姿」だけを切り取ったものです。
実際のユーザーは、その一通りには収まりません。長い会社名を入力欄に打ち込むかもしれないし、回線が遅くて画像の読み込みを数秒待たされるかもしれない。必須項目を空欄のまま送信ボタンを押すかもしれないし、検索しても結果がゼロ件かもしれない。スマートフォンの縦画面で見れば、PCで整っていたレイアウトが窮屈に折り返るかもしれない。静的プロトタイプは、こうした「うまくいかない瞬間」をすべて省略しているのです。発注者はその省略に気づかないまま「OK」を出し、開発が進み、本番で初めて現実に直面します。
Smashing Magazine の記事が指摘するのも同じ構図です。ユーザーテストでログイン画面に差しかかった参加者が「これ、本物のアプリじゃないな」と気づいた瞬間、それ以降のすべての反応が「どうせ作り物だから」というフィルターを通ってしまう。つまり正直でないプロトタイプからは、正直なフィードバックが返ってこない。これは発注者のレビューでも同じことが起きています。
なぜ「本番で」崩れるのか
合意した体験が本番で崩れるのは、プロトタイプと実装の間に「誰かの推測」が大量に挟まるからです。海外の開発現場でも、曖昧な仕様は手戻りの最大要因として繰り返し指摘されています。静的プロトタイプには「入力中はどう見えるか」「エラー時に何を表示するか」「データが無いときの画面はどうか」が描かれていない。すると実装者は、締め切りに追われながら自分の判断で埋めていきます。その判断のいくつかは必ず外れ、外れた分が手戻りになります。
ある制作会社（仮に B社とします）の案件では、申込フォームのプロトタイプが「入力済みの理想状態」だけで作られていました。本番でテストしたところ、住所の自動補完が効かない、エラーメッセージが入力欄から離れた場所に出る、送信中にボタンを連打できてしまう、といった問題が次々に発覚。設計段階で見えていれば数時間で直せたものが、実装後だと画面構造まで遡って作り直すことになり、結果として当初見積もりに無い追加工数が発生しました。発注者にとっては「OKを出したはずの画面が、なぜ追加費用になるのか」が腑に落ちず、信頼関係にもひびが入りかけました。崩れているのは画面だけでなく、合意そのものなのです。
何を「忠実化」すべきか
では、本番に忠実なプロトタイプとは何を再現するものなのか。私たちが受託で重視しているのは、見た目の美しさではなく、ユーザーが実際に通る「うまくいかない経路」です。具体的には次の5つです。
| 忠実化する対象 | 静的プロトでの扱い | 本番で起きること |
|---|---|---|
| 入力（実データ） | プレースホルダの飾り文字 | 長い社名・記号・全角半角で崩れる |
| 遅延（読み込み） | 一瞬で次画面へ | 数秒の待ち時間に離脱・連打 |
| エラー（検証） | エラー画面が存在しない | どこに何が出るか未設計で迷う |
| 空状態（ゼロ件） | データ満載の理想状態のみ | 検索0件・初回利用時に空白画面 |
| レスポンシブ | PC1枚で合意 | スマホで折り返し・はみ出し |
入力は、実際にキーボードで打てる状態にして、長い文字列や記号を入れたときの挙動まで確かめます。遅延は、読み込み中のスケルトンやスピナーを設計に含め、待ち時間の体感を発注者に体験してもらいます。エラーは「入力欄のすぐ下に、何が・なぜ間違っているかを出す」という原則(エラー表示の基本)に沿って、起こりうる失敗パターンを洗い出します。空状態は、初めて使う人やデータがまだ無い状態の画面を必ず作る。そしてレスポンシブは、合意の前にスマホ実機で確認する。これらは「happy path（うまくいく道）」の外側にある体験で、実装作業の半分を占めるとも言われる領域です。ここを発注前に見えるようにしておくことが、手戻りを防ぐ最大のレバーになります。
受託でのプロトタイプ検証の進め方
私たちが受託案件で実際に踏むステップは、おおむね次の流れです。
| フェーズ | やること | 発注者の関わり |
|---|---|---|
| 1. 経路の洗い出し | 主要導線と失敗経路をリスト化 | 業務上の例外ケースを共有 |
| 2. 忠実プロトタイプ作成 | 入力・遅延・エラー・空状態を再現 | 実機で操作して確認 |
| 3. 検証レビュー | 「迷う・止まる」箇所を記録 | 違和感をその場で指摘 |
| 4. 合意と凍結 | 体験を文書化して認識を固定 | 仕様として承認 |
ポイントは、レビューを「画面を眺める会」ではなく「発注者自身に触ってもらう会」にすることです。担当者がスマホを手に取り、わざと空欄で送信し、わざと長い文字を打ち込む。その瞬間に「あ、ここ分かりにくい」が出てくれば、それは実装前の、最も安く直せるタイミングでの発見です。あるクライアントでは、この触る検証で経営者自身が「自分が一番つまずいた」と笑い、結果として本番後のクレームがほぼゼロになりました。
なお、忠実化と「とにかく作り込む」は違います。例外をすべて完璧に再現しようとすれば、プロトタイプ自体が小さな開発プロジェクトになってしまう。どこまで作るかの線引きは、作り込みすぎを避ける要件設計の考え方と同じで、「意思決定を間違えやすい箇所」に検証コストを集中させます。フォームや決済、検索のように失敗が直接離脱や問い合わせにつながる導線は手厚く、説明ページのような一方向の画面は静的なままでも構いません。
どこまで作り込むかの線引き
線引きの基準は「その経路で失敗したとき、ビジネスにいくら響くか」です。問い合わせフォームのエラー設計が甘ければ、見込み客がそのまま離脱します。これは直接の機会損失なので、忠実プロトタイプの対象にすべき筆頭です。一方、会社沿革のような静的なページは、文字量が増えたときの崩れさえ確認すれば十分で、インタラクションの再現に時間をかける必要はありません。
検証の深さは「テストで何を確かめたいか」で決めます。レイアウトの好みを聞きたいだけなら静的な画面で十分ですが、「この導線で人は最後まで進めるか」を確かめたいなら、入力もエラーも遅延も再現した忠実なプロトタイプでなければ意味がありません。問いと忠実度がずれていると、せっかくの検証が空回りします。デザインシステムを前提に量産する案件では、AI-ready なデザインシステムの受託で触れたように、状態（入力中・エラー・空）をコンポーネント単位で定義しておくと、忠実プロトタイプの作成自体が速くなります。
価格の考え方
忠実プロトタイプ検証は、独立した工程として見積もると費用が膨らむように見えます。けれど実際には、後工程の手戻りを前倒しで潰すための投資です。目安としての価格モデルを示します（要件により変動します）。
| プラン | 対象範囲 | 価格目安 |
|---|---|---|
| スポット検証 | 主要1導線（例: 申込フォーム） | 15万〜30万円 |
| 標準パッケージ | 主要3〜5導線＋スマホ実機検証 | 40万〜80万円 |
| 制作一体型 | 設計〜実装に検証を組み込み | 制作費に内包 |
最も費用対効果が高いのは「制作一体型」です。検証を別工程ではなく設計プロセスの中に織り込むことで、追加費用としてではなく、手戻りを防ぐ標準手順として機能します。スポット検証は、既に他社で進行中の案件に「公開前のセカンドオピニオン」として入る場合に向いています。
よくある落とし穴
一つめは、忠実プロトタイプを「最終デザイン」と勘違いされることです。検証用に作った画面を見て「もう完成では」と受け取られると、本来の実装工程が値切られかねません。検証はあくまで「合意を固めるための実験」だと、最初に位置づけを共有しておきます。
二つめは、例外を出し尽くせないことです。どれだけ洗い出しても、本番には想定外が残ります。だからこそ、公開後に問題を拾って直す仕組み（アクセス解析・問い合わせの分類）まで含めて設計します。アクセシビリティ観点の見落としも頻出で、Webアクセシビリティ対応ガイドで扱う観点は、忠実プロトタイプの検証項目にそのまま組み込めます。
三つめは、ツールに振り回されることです。忠実化のためにインタラクション特化ツールを導入するのは有効ですが、目的は「正直な体験を発注者と確かめる」ことであって、凝った動きを作ることではありません。リニューアルの全体像を整理したい段階なら、まずコーポレートサイトリニューアルの進め方で工程を俯瞰してから、どこに検証を差し込むかを決めると無駄がありません。
まとめ
きれいな静止画でOKを出すと、本番で「イメージと違う」が返ってきます。原因は発注者でも制作者でもなく、入力・遅延・エラー・空状態・スマホ崩れを省略したプロトタイプが、体験について嘘をついていたことにあります。これを正直にする——つまり本番に忠実な状態でレビューする——だけで、合意のズレと手戻りは大きく減らせます。
次の一歩として、(1) いま進行中・計画中のリニューアルで「フォームや検索の失敗経路まで確認できているか」を一度棚卸ししてみてください。確認できていない経路が見つかったら、(2) その導線だけでも忠実プロトタイプで触って確かめる場を設けることをおすすめします。どこから手をつければよいか分からない場合は、お問い合わせからご相談ください。御社の主要導線を一緒に洗い出し、公開前に体験を確かめる検証設計をご提案します。
Sources
- Your Prototype Is Not Being Honest With Your Users (And Here’s How To Fix It) — Smashing Magazine
- How To Design Error States For Mobile Apps — Smashing Magazine
- Design Hand-off: Best Practices Beyond Static Mockups — Miro
- 作り込みすぎを避ける要件設計（GH Media）
- AI-ready なデザインシステムの受託（GH Media）
- Webアクセシビリティ対応ガイド（GH Media）
- コーポレートサイトリニューアルの進め方（GH Media）
