「実装してから検証しよう」という判断が、最も高い学習コストを生む。Wizard of Ozテストは実装ゼロのまま、本番に近い文脈でユーザー行動を観察できる手法だ。
名前の由来は映画『オズの魔法使い』。全能の魔法使いに見えた「オズ」が、カーテンの裏にいた普通の人間だったように——被験者には自動で動くシステムと見せておいて、裏側では人間（ウィザード）が手動で応答を返す。被験者は自然に操作し、チームは「実装なしにリアルな行動データ」を手に入れる。
本記事はテストフェーズでのWizard of Oz活用に焦点を当てる。「いつ使うか」の判断基準から、セッション設計・実施・分析・よくある失敗と対策まで、ファシリテーター視点で解説する。
いつWizard of Ozテストを選ぶか
手法の選択を誤ると、得られるデータが問いとずれる。Wizard of Ozが「正解」となる条件は3つある。
条件1：機能が「動的」でペーパープロトでは再現できない
ユーザーの入力に応じてリアルタイムに変化する体験は、静的なモックアップでは検証できない。チャットボット・AI推薦・音声アシスタント・パーソナライズ表示——これらの動的な体験を検証したい場合に、Wizard of Ozが最も有効だ。
条件2：実装コストが検証コストを大幅に上回る
エンジニアリング工数が数週間〜数ヶ月かかる機能の場合、「作ってから検証する」アプローチは投資リスクが高い。Wizard of Ozなら準備2〜3時間・実施数時間で「ユーザーはそもそもこの機能を使うか」という問いに答えが出る。
条件3：ユーザーの「実際の行動」を観察したい
インタビューで「使いたいと思う」と言っても、実際に使う行動は別物だ。Wizard of Ozは実際の操作行動・つまずき・離脱を観察できる。アンケートやインタビューでは得られない行動データが目的のときに選ぶ。
逆に、Wizard of Ozを選ぶべきでない場面もある。パフォーマンス（応答速度・処理能力）を検証したい場合、デザインの細部（フォント・色・アニメーション）を検証したい場合は、別の手法を選ぶ。
テスト設計の5ステップ
ステップ1：検証問いを1つに絞る
複数の問いを同時に検証しようとすると、セッションが散漫になる。Wizard of Ozは「1セッション1つの問い」が原則だ。
良い問いの例：「ユーザーは自然言語で検索条件を入力する行動を自発的に取るか」「AIのレコメンドに対してユーザーはどのような判断基準で受け入れ/拒否するか」
問いが決まったら、「何を観察すれば問いに答えられるか」を逆算する。完了行動・離脱行動・言語化した発言・身体的反応（戸惑い・前のめり・画面から目を離す）のどれを記録するかを事前に決める。
ステップ2：ウィザード環境を設計する
ウィザード（人間オペレーター）が被験者に気づかれずに応答を返す仕組みを作る。
オンライン実施の場合： 被験者の画面共有を別ウィンドウで確認しながら、Figmaの変数書き換え・外部ツールへのテキスト送信・バックエンドの管理画面操作で応答を返す。ウィザードは被験者と別の通話に入り、進行役から「次のシナリオへ」のサインをもらう。
対面実施の場合： ウィザードは隣室または衝立の裏で、被験者の画面をミラーリングしながら操作する。進行役との連絡はチャットツールで行い、被験者には聞こえないようにする。
応答スクリプトが品質を決める。 事前に20〜30パターンの想定入力と応答を用意する。「処理中です」「もう少し詳しく教えていただけますか」など時間稼ぎ用のテンプレートも3〜5個準備する。
スクリプトが薄いと即興応答が増え、ウィザード個人の語彙癖が滲んでAI感が崩れる。
ステップ3：シナリオを設計する
「このツールを自由に使ってみてください」ではデータが取れない。ユーザーが実際の文脈で行動するように「状況設定」を用意する。
シナリオの4要素：
- 背景（Context）： 「あなたは来週の企画会議に向けて競合調査をしています」
- 目標： 「この調査ツールを使って、3社の競合情報を比較したい」
- 制約： 「30分以内に情報をまとめる必要がある」
- 成功基準： 「比較表を作成できた状態」
ツール操作を目的にしたシナリオは、本来の利用文脈とかけ離れた行動を引き出してしまう。「ツールをテストする」のではなく「目標を達成しようとする人を観察する」という視点でシナリオを書く。
ステップ4：リハーサルを行う
本番前に必ずチームメンバーで通し練習をする。ウィザードが応答を返す速度・スクリプトのカバー率・進行役のファシリテーション——これらの連携をリハーサルで確認する。
実際にやってみると分かるのは、「想定外の入力」がリハーサル中に大量に出てくることだ。スクリプトに抜けが多いほど、本番でウィザードが焦る。リハーサルで出た想定外パターンをスクリプトに追加してから本番に臨む。
ステップ5：デブリーフィング計画を立てる
セッション終了後、被験者に「実は裏で人間が応答していた」を開示するデブリーフィングが必要だ。これは倫理的に必須のステップであり、同時に最も豊かなデータが得られる瞬間でもある。
「実は手動で応答していたことをお伝えします。この体験を通じてどんな感想を持ちましたか」——この問いへの反応は、観察中に得られる行動データとは別の次元の洞察を含む。デブリーフィングの質問リストを事前に用意する。
セッション中の観察と記録
観察すべき3種類のデータ
行動データ： 何を入力したか、どこでつまずいたか、離脱したか完了したか。これは録画から後で確認できるが、リアルタイムでも進行役が簡単なメモを取る。
言語データ： 思考発話（Think Aloud）を依頼している場合の発言内容。「えっ、何これ」「あ、なるほど」「ここがよく分からない」——この発言は後の分析で重要な文脈を提供する。
非言語データ： 前のめりになる・椅子に寄り掛かる・画面から目を離す・眉をひそめる——これらの身体的反応は、行動データには含まれないが体験の質を示す。対面セッションでは進行役が記録し、オンラインではカメラ映像を確認する。
進行役が犯しやすいミス
誘導的なフォローアップ質問。 「ここが分かりにくかったですか？」という問いは被験者に答えを示唆してしまう。「今、少し手が止まりましたが、何を考えていましたか？」というオープンな問いで観察する。
沈黙を埋めようとする衝動。 被験者が考え込んで沈黙している時間は、最も重要な観察対象だ。進行役が焦って助け船を出すと、「ユーザーが自力でどう対処するか」というデータが消える。沈黙は最低30秒待つ。
分析：データから洞察を抽出する
パターンの発見
複数セッションの録画と観察メモを並べて、「同じ場所でつまずいた人が何人いたか」を数える。1人なら個人差・2人以上ならパターンだ。パターンになった箇所が、設計課題の有力候補となる。
完了/離脱の構造化
シナリオごとに「完了率」「離脱タイミング」「完了までの時間」を集計する。これだけで「どのフローに問題があるか」の地図が見える。次に「なぜそのタイミングで離脱したか」を、観察メモと発言データから仮説化する。
驚きを記録する
分析中に「これは予想していなかった」と感じた瞬間を全てメモする。POVステートメントの作成につながる洞察は、多くの場合「驚き」の中に潜んでいる。仮説を確認するデータより、仮説を崩すデータの方が価値が高い。
よくある失敗と対策
失敗1：ウィザードの応答が遅すぎて「壊れてる」と思われる
対策：応答スクリプトに「ただいま処理中です（3〜5秒の遅延を自然に見せるテンプレート）」を必ず含める。応答時間の目安は2〜8秒。10秒を超えると不自然さが際立つ。
失敗2：被験者がテスト中に「実は人間ですか？」と聞いてくる
対策：事前のブリーフィングで「自動システムです」と明言するか「詳細はセッション後にお話しします」と伝える。セッション中に問われたら「後ほど詳しくご説明します」と答え、デブリーフィングで必ず開示する。
失敗3：ウィザードがスクリプトにない入力に対応できない
対策：リハーサルで想定外入力を収集し、スクリプトを厚くする。それでも対応できない場合のために「お問い合わせの内容をより深く理解するためにもう少し時間が必要です」という汎用テンプレートを用意する。
失敗4：セッション後に被験者から「騙された」という不満が出る
対策：デブリーフィングの冒頭で「研究倫理上、事前に開示できない手法でした。ご協力に感謝します」と真摯に説明し、研究目的と意義を伝える。透明性と誠実さが参加者の理解につながる。
ペーパープロトタイピングとの使い分け
ペーパープロトタイプは静的な画面遷移の検証に適している。Wizard of Ozは動的な応答・インタラクションの検証に適している。「押したらどこに遷移するか」はペーパーで、「入力した内容に対してどんな応答が返るか」はWizard of Ozで検証する。
ユーザビリティテストとの違いも押さえておく。ユーザビリティテストは実装済みのプロダクトやハイファイプロトタイプで「操作の問題点を発見する」ことが主目的だ。Wizard of Ozはそれより前段階で「そもそもこの機能・インタラクションは必要か」を問う。フェーズが違う。
Wizard of Ozテストの最大の価値は、「作らずに学べる」という速度にある。しかし「作らなかった分だけ設計が甘い」というトレードオフも存在する。ウィザードが応答したパターンをそのまま設計に採用するのではなく、「ユーザーがどう反応したか」という行動データを次の設計判断の材料として使う——これがこの手法を正しく活かす姿勢だ。