プロトタイピングは、アイデアを「試せる形」に変え、仮説を最短で検証するための行為です。「完成品に近いものを作る」という誤解が、プロトタイピングを遅く・高コストにする最大の原因です。このガイドは、ペーパープロトタイプ・Wizard of Oz・デジタルプロトタイプの3手法を「いつ・なぜ・どう使うか」という実践の観点から解説します。

プロトタイピングとは何か——よくある誤解の解消

問題（Problem）

「プロトタイプを作ろう」と言うと、多くのチームが「Figmaで作りましょう」と始めます。しかし Figmaで動くUIを作るのに丸2日かかり、ユーザーテストで「根本的な概念が伝わらなかった」と気づく——このパターンは珍しくありません。作り込むほど「せっかく作ったから」という埋没コストが意思決定を歪めます。

親近感（Affinity）

ワークショップでよく起こるのは、ファシリテーターが「低忠実度でいい」と言っても、参加者が「ちゃんと見せられるものを作りたい」という心理でどんどん精密にしていくパターンです。「粗いものを見せるのが恥ずかしい」という感覚は、プロトタイピングの本質と真逆です。 粗いほうが、ユーザーが自由にフィードバックを言いやすい。

解決策（Solution）

プロトタイプの目的は「検証したい仮説を最小コストで試すこと」です。どの手法を選ぶかは「忠実度（Fidelity）」ではなく「何を検証したいか」で決まります。このガイドでは3手法の選択基準を明確にし、テスト設計との統合まで扱います。

プロトタイピングの基本原則

Stanford d.school が定義する「プロト思考」

Stanford d.school の Bootcamp Bootleg では、プロトタイピングを「考えるためのツール（Think with your hands）」と定義しています。プロトタイプを「完成品の前段階」ではなく「思考の道具」として捉えることが、手法選択の出発点です。

IDEO のデザインプロセスでも、「Fail early, fail often」というプロト哲学が貫かれています。早く・多く・安く失敗することで、方向性の誤りを修正するコストを最小化します。プロトタイプは失敗を許可する場であり、失敗を歓迎する構造を持ちます。

忠実度の2軸

プロトタイプの忠実度は「視覚的忠実度」と「機能的忠実度」の2軸で考えます。

	視覚的忠実度（低）	視覚的忠実度（高）
機能的忠実度（低）	ペーパープロトタイプ	モックアップ（静的UI）
機能的忠実度（高）	Wizard of Oz	インタラクティブプロトタイプ

どちらの軸を上げるかは「何を検証したいか」によって決まります。コンセプトの理解を検証したいなら視覚的忠実度が低くても機能します。操作フローを検証したいなら機能的忠実度を上げます。

手法1：ペーパープロトタイプ

なぜ紙で始めるのか

紙は最速・最安・最修正しやすいプロトタイプ素材です。Sharpie（マジック）と付箋があれば30分で試せます。ユーザーが「ここが変」と言った瞬間に、目の前でその場で修正できます。200回以上のワークショップで繰り返し観察されてきたのは、紙で始めたチームがデジタルに進む前に概念の誤りを発見し、開発コストを大幅に圧縮できているというパターンです。

IDEO の David Kelley は「最初の10個のプロトタイプは紙で作れ」と語ります。デジタルで作ったものは「直してもらうのが申し訳ない」とユーザーが気を使い、本音のフィードバックが減ります。紙の粗さが「これは試作なので何でも言ってください」というシグナルになります。

ペーパープロトタイプの実施手順

Step 1：検証仮説を1文で書く（5分）

何を確かめたいかを「ユーザーは〜できると思っているか？」という形式で1文で書きます。この1文がなければ、作ることが目的になります。 例：「ユーザーは申請ステータスを3秒以内に確認できると思っているか？」

Step 2：画面の流れをアウトライン化する（10分）

紙（またはカード）1枚 = 1画面として、検証したいフローの画面を列挙します。全ての機能を作る必要はありません。検証仮説に関係する画面だけを対象にします。

Step 3：手書きで作る（15〜30分）

Sharpie で手書きします。鉛筆ではなくSharpie を使う理由は、細部を描き込めないため、構造だけを描く習慣がつくからです。 ボタンの色や角の丸みは今は関係ない。「このボタンを押したら次に何が起きるか」という構造だけを確認します。

Step 4：役割分担を決める（5分）

ユーザーテストの際、「コンピューター役」の担当者を決めます。ユーザーが「このボタンを押す」と言ったら、コンピューター役が次の画面のカードをテーブルに出します。これがペーパープロトタイプの核心的な仕組みです。

Step 5：3人以上のユーザーでテストする

1人でのテストでは「この人の特異な行動」なのか「設計上の問題」なのかが区別できません。最低3人でテストし、2人以上が同じ箇所で詰まったときを「設計上の問題」と判断します。

ペーパープロトの材料リスト

Sharpie または太マーカー
A4白紙（大量に用意する。何度でも作り直す前提）
付箋（画面の一部を隠したり追加するための「オーバーレイ」に使う）
はさみ
テープ
タイマー（テスト中のタスク時間計測用）

手法2：Wizard of Oz プロトタイプ

「裏で人間が操作する」という発想

Wizard of Oz プロトタイプは、ユーザーに「システムが動いている」と思わせながら、実際にはバックグラウンドで人間がリアルタイムに操作・応答するプロトタイプ技法です。

名称の由来は映画「オズの魔法使い」です。偉大なオズ大魔王が実はカーテンの裏で操作している老人だったように、「魔法のような体験」の裏に人間の手作業が隠れています。

Wizard of Oz が有効な場面は、AIや音声認識など「本物のシステムを作るコストが極めて高い」機能の検証です。AIチャットボットの会話品質を検証したいとき、本物のAIを作る前に人間がチャットを打って「ユーザーはこの回答で満足するか？」を確認できます。

Wizard of Oz の典型的なセットアップ

音声アシスタントの検証

ユーザーが「明日の天気は？」と話しかける。別室（または画面の外）のオペレーターがその言葉を聞いて、あらかじめ用意した回答リストから選んでスピーカーから応答する。ユーザーはシステムが応答していると体験します。

パーソナライズ機能の検証

Webサービスの「あなたにおすすめ」機能を本物のレコメンデーションエンジンなしで検証します。ユーザーがサービスを使い始めたら、オペレーターがユーザーの行動を観察して手動でコンテンツを選び表示します。ユーザーは「AIが選んでいる」と体験します。

実際にやってみると、Wizard of Oz の最大の発見は「どんな精度のレコメンドなら満足か」という閾値の発見です。人間が選んだものでも「機械的に感じる」と言うユーザーがいれば、パーソナライズの表現方法の問題が浮かびます。

Wizard of Oz の落とし穴

落とし穴1：オペレーターの疲労

1セッションが長くなると、リアルタイム応答を担当するオペレーターの集中力が低下します。1セッションは15〜20分を上限にし、オペレーターを交代させます。 疲弊したオペレーターの応答ミスが、「システムのバグ」としてログに記録されると分析が混乱します。

落とし穴2：「Wizard がバレる」場合の記録

ユーザーが「あれ、これ自動じゃないんですか？」と気づいた瞬間は、テストを止めるのではなく「気づいた理由」を必ず記録します。 バレたことで無効になるのではなく、「どこが不自然だったか」がシステム設計のインサイトになります。

落とし穴3：スクリプトの準備不足

オペレーターがアドリブで対応すると、セッションごとに回答品質がばらつきます。あらかじめ「ユーザーがこの文脈でこう質問したら、この回答を返す」というスクリプトを作成し、オペレーターはスクリプトから選択する設計にします。

手法3：デジタルプロトタイプ

デジタルに進む判断基準

デジタルプロトタイプは高コスト・高時間のため、「ペーパーまたはWizard of Ozで確認できた方向性を、より精密に検証する段階」で使います。 デジタルプロトタイプでなければ検証できない問いとして以下があります。

アニメーションやトランジションの体験（「画面が切り替わる速さは適切か？」）
実際のデバイスのサイズ・解像度・タッチ操作での体験
ユーザーが自分でナビゲーションを探索する動線（誘導なしで目的を達成できるか）

ツール選択の基準

ツール	向いている用途	所要時間目安
Figma	UIフロー・画面遷移の検証	4〜16時間
Marvel / InVision	スクリーンショット連結の簡易フロー	1〜4時間
Framer	インタラクション・アニメーション重視	8〜24時間
コーディング（HTML/CSS）	ブラウザ上の実際の操作感	16時間以上

重要な原則は、選んだツールで「検証したい仮説」を試せるかどうかが唯一の基準です。「Figmaが使えるからFigmaで作る」ではなく「今回の仮説はスクリーンショット連結で十分検証できるか」という問いで選びます。

デジタルプロトのよくある失敗

失敗：「完成に近いもの」を作りすぎる

デジタルプロトタイプが「本番前の完成品」に見えるほど、ユーザーは「ここはもっとこうしてほしい」という重要なフィードバックを遠慮します。わざと未完成感を演出することが有効です。グレースケールのみで作る、フォントを統一しない、ダミーテキストを残す——これらが「試作品である」というシグナルになります。

「いつどの手法を選ぶか」判定フローチャート

検証したい仮説は何か？
│
├─ 「このコンセプトで解決すべき問題が合っているか？」
│   └─ → ペーパープロトタイプ
│      （方向性の確認。最短で試す）
│
├─ 「AIや音声など、開発コストが高い機能の体験価値は？」
│   └─ → Wizard of Oz
│      （本物を作る前に体験を先行検証）
│
├─ 「画面遷移・ナビゲーション・操作フローは直感的か？」
│   └─ → デジタルプロトタイプ（Figma等）
│      （フローの精密検証）
│
└─ 「実際のデバイスでのインタラクション品質は？」
    └─ → コーディングプロトタイプ
       （最終段階の体験検証）

複合的な検証が必要な場合は、ペーパープロトで方向性を確認 → デジタルプロトで操作フローを検証という順で進めます。Wizard of Oz はペーパープロトの後、またはデジタルプロトと並行して実施できます。

プロトタイピングとテスト設計は不可分

なぜテスト設計と一緒に考えるか

プロトタイプを作ってから「どうテストするか」を考えるチームは、テストで集めたいデータが取れないことが多い。プロトタイプを設計する時点で「このプロトで何をどう測るか」を決めることが、有効なプロトタイピングの条件です。

テスト設計で事前に決める3点：

タスク定義：「ユーザーに何をやってもらうか」を1〜3タスクで定義する
成功基準：「何ができたら仮説が支持されるか」の閾値を決める（例：「3分以内に目的の画面に到達」）
観察ポイント：「詰まりが起きたらどこで記録するか」のシートを事前に作る

テスト中の「ユーザーへの声かけ」

プロトタイプテスト中にファシリテーターがやりがちな失敗が「誘導」です。ユーザーが迷った瞬間に「これを押してみてください」と言ってしまう。ユーザーが迷う場面こそが最も重要なデータなのに、誘導によって問題が隠れてしまいます。

「Think Aloud（思考発話）」という技法を使います。ユーザーに「今何を考えているか、口に出しながら操作してください」と事前に伝えます。「えーと、ここを押したらどうなるんだろう」という独り言が、設計上の問題を特定するための生データになります。

ユーザビリティテストとの統合については、テストフェーズの記事で詳しく扱います。

材料別コスト・時間・効果比較

手法	材料費	作成時間	向いている仮説	E-E-A-T適合度
ペーパープロト	100円以下	30〜60分	コンセプト・概念合意	◎
Wizard of Oz	ほぼ0円	2〜4時間（スクリプト込み）	AI/音声/パーソナライズ体験	◎
デジタル（Figma等）	0〜月額費用	4〜24時間	操作フロー・遷移	○
コーディング	0円	16時間以上	実装品質・インタラクション	△（最終段階向け）

POVからプロトタイプへの流れ

プロトタイピングは独立したフェーズではなく、POVステートメントで定義した問題に対する「仮説の具体化」です。POVに書いたインサイトとニーズをもとに「もしこう解決したら？」という仮説を形にするのがプロトタイプです。

POV → 仮説 → プロトタイプの例：

POV文：「毎朝の会議で議事録を担当する田中さんは、重要な発言を聞き逃さずに記録する方法を必要としている。なぜなら、書きながら聞く行為が分断されると議論への参加が困難になるからだ」

仮説：「もし発言が自動でテキスト化され、後で修正できる設計なら、田中さんは会議に集中しながら記録できるのではないか」

プロトタイプ（Wizard of Oz）：研究者が別室からリアルタイムで発言を文字起こしするシステムを「自動変換」として見せ、「このUIで編集しやすいか」を検証する。

よくある失敗と対策

失敗1：仮説なしにプロトタイプを作り始める

「とりあえず作ってみよう」は最も多い失敗です。何を確認したいかが不明なまま作ると、ユーザーテストで「何がわかったのか」が不明なままになります。 作る前に「このプロトで確かめる仮説は1文で書けるか？」を問います。

失敗2：プロトタイプを「完成品の縮小版」として作る

「せっかく作るなら全機能入れよう」という発想が、プロトタイプを重くします。プロトタイプには「今回の仮説検証に関係しない機能は入れない」というシンプルなルールを設定します。 余計な機能がユーザーの注意を分散させます。

失敗3：1人のユーザーの意見で大改修する

「このユーザーに受けなかったから作り直そう」は、単一サンプルの危険な解釈です。1人の反応はデータの一点に過ぎません。3〜5人のパターンを見てから方向転換の判断をします。

失敗4：テスト後の記録が「良かった/悪かった」で終わる

テスト後の振り返りが「大体うまくいった」「あの部分が悪かった」という主観で終わると、次のプロトタイプの改善点が不明確になります。タスク完了率・詰まりが起きた箇所・ユーザーの発言（Think Aloud の記録）という3種のデータを記録し、改善の根拠を事実に基づかせます。

ポイント

「何を確かめたいか」が手法選択の唯一の基準 — 忠実度や見た目のクオリティではなく、検証仮説から手法を逆算する
ペーパーファースト — コンセプトの方向性はまず紙で確認してからデジタルへ進む
Wizard of Oz は高コスト機能の事前検証に最強 — AI・音声・パーソナライズを本番構築前に試す唯一の現実的手段
プロトタイプとテスト設計は同時に設計する — 作ってからテストを考えると、欲しいデータが取れない
粗さを恐れない — 粗いほど本音のフィードバックが集まる。完成度が上がるほどユーザーは遠慮する
3人以上でテストする — 1人の反応を構造的な問題と判断しない
プロトタイプ後のユーザー検証をより体系的に設計したい場合は、Desirability Testing 完全ガイドで感情的共鳴の測定手法を確認してほしい。Microsoft Reaction Cardsを用いたDesirability Testingの全手順とファシリテーション失敗パターンについては、Desirability Testing とユーザー検証完全ガイドに体系化している。

参考文献

Stanford d.school, Bootcamp Bootleg, Institute of Design at Stanford, 2018年改訂版
IDEO.org, The Field Guide to Human-Centered Design, IDEO.org, 2015
Tim Brown, Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, HarperCollins, 2009
Steve Krug, Don’t Make Me Think: A Common Sense Approach to Web Usability, New Riders, 2014（第3版）
Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product, O’Reilly, 2014