「このAI機能は本当に使われるのか」——その答えは、実装してみるまでわからない、と思われがちだ。しかしWizard of Ozプロトタイピングは、AIを一行も実装せずに「AIらしさの体験」をユーザーに提供し、行動データを収集できる手法だ。名前の由来は映画『オズの魔法使い』。強大な魔法使いに見えた「オズ」が、実はカーテンの裏の小さな人間だったように——被験者には自動で動いているように見えて、裏ではウィザード（人間オペレーター）が手動で応答を返す。
なぜWizard of Ozが必要なのか
問題：「実装コスト先払い」の罠
AI機能・チャットボット・パーソナライズ・複雑な自動化——これらの機能は、ペーパープロトタイプでは検証できない。ユーザーが入力した内容に応じてリアルタイムに応答が変わる体験は、静的なモックアップでは再現不可能だからだ。
しかし実装を先行させると、データパイプライン構築・モデル選定・推論環境整備で最低でも数週間〜数ヶ月のエンジニアリング投資が発生する。「実装してみたら、ユーザーがそもそも欲しくなかった」という発見は、AIプロダクト開発における最も高価な失敗だ。
親近感：「最小検証」の難しさ
ワークショップでよく起こるのは「最低限の機能で試そう」という合意が崩れていくプロセスだ。「最低限」と言いながら、エンジニアが「せめてこれくらいの品質でないと検証にならない」と判断し、実装スコープが膨らむ。その結果、検証が3ヶ月後に始まる。
参加者からの声として多いのは「いつの間にかMVPが普通の製品開発になっていた」という振り返りだ。Wizard of Ozはこの構造を断ち切る。「最低限の検証」を技術的に担保するのではなく、人間の手作業で担保する発想の転換だ。
解決策：人間がAIを演じる
Wizard of Ozの核心は「被験者をだます」ことではなく「実使用文脈での行動データを得る」ことだ。被験者は「自動で動いているシステム」と思って自然に操作し、その結果として「本番と近い文脈での反応」が生まれる。ウィザードが人間であるという事実は、テスト終了後にデブリーフィングで開示する。
この手法が最初に体系化されたのは、1983年にJohn F. KelleyがJohns Hopkins大学の博士論文として発表した自然言語インタフェース研究に端を発する。後にIBMがこの手法を採用したことで広く知られるようになり、プロダクト開発の文脈では「開発なしにユーザー体験を検証する」スタンダードな手法として定着している。
実施手順：ステップバイステップ
ステップ1：検証スコープの確定（30分）
最初に「何を検証するか」を一つに絞る。複数の機能を同時に検証しようとすると、ウィザードの操作が破綻する。
確定すべき4項目：
- 入力：ユーザーが何をするか（テキスト入力/ボタン操作/音声など）
- 処理：ウィザードが裏で何をするか（応答文を選ぶ/画面を切り替えるなど）
- 出力：被験者の画面に何を表示するか
- 応答時間：実際のAIを想定した遅延時間（2〜5秒が多い）
スコープ確定の判断基準： 「ウィザード1人が15秒以内に応答できるか」。これを超えると被験者が「おかしい」と感じ始める。
ステップ2：ウィザード用ツール・環境の準備（60〜90分）
被験者側の環境：
- FigmaプロトタイプまたはHTMLモック（操作可能な状態）
- 可能であれば実際のサービスに見えるUI
ウィザード側の環境：
- 被験者の画面をリアルタイムで確認できる手段（画面共有、別ウィンドウなど）
- 応答を返す手段（テキスト注入ツール、Slack経由の更新など）
- 応答スクリプト（20〜30パターンを事前に用意）
応答スクリプトの設計が全体の品質を決める。 想定パターンが薄いと即興応答に頼ることになり、ウィザードの個性が滲んでAI感が崩れる。スクリプトは「想定パターン」「時間稼ぎ用テンプレ（「処理中…」「より詳しい情報を確認しています」）」「エラー応答パターン」の3種類に分類しておく。
ステップ3：シナリオ設計（30分）
被験者に自然に操作してもらうための「状況設定」を作る。
設計の要素：
- 文脈（Context）： 「あなたは来週のプレゼン資料を作っています。このツールを使って〜」
- タスク： 具体的にやってもらうこと
- 成功基準： 「ここまで達成できたら次のシナリオへ」
- 制限時間： 10〜15分/シナリオ
重要： シナリオは「ツールを使ってください」ではなく「〇〇という状況で〇〇したい」という自然な文脈で提示する。ツール操作を目的にすると、本来の利用文脈とかけ離れた行動が観察されてしまう。
ステップ4：ウィザードのリハーサル（30分）
本番前に必ずリハーサルを行う。チームメンバーが被験者役を担い、ウィザードが応答する練習をする。
確認項目：
- 応答時間が自然か（速すぎず遅すぎず）
- 想定外の入力への対処ができるか
- ウィザードの存在が漏れないか（操作音、通知音など）
実際にやってみると、リハーサルで「想定外の入力」が大量に出てくる。これがスクリプトの穴を埋める最良の機会だ。
ステップ5：テスト実施（40〜60分/被験者）
開始前の説明： 「これはシステムの動作確認です。自由に操作してください。考えたことを声に出してもらえると助かります」——「裏で人が動かしている」ことは言わない。ただし「AI機能」と明示的に説明する必要もない。
ウィザードの心得：
- 応答テンプレを最大限活用し、即興を最小化する
- 「100%正解」を出し続けない。たまに「理解できませんでした」の応答を混ぜる（AI感の維持）
- 応答時間に軽いランダム性を入れる（毎回ぴったり3秒は不自然）
テスト進行役の役割： 被験者の発話を促す。「今何を考えましたか」「期待通りでしたか」の問いかけを自然なタイミングで挟む。
ステップ6：デブリーフィング（15〜20分）
テスト終了後、被験者に「実は裏で人が動かしていました」と開示する。これは倫理的な義務であり、追加のデータ収集の機会でもある。
デブリーフィングで引き出す情報：
- 「途中で変だと感じた瞬間はありましたか」
- 「もし本当のAIだったら何が変わると思いますか」
- 「期待していた応答と違った瞬間はどこでしたか」
- 「このシステムを日常的に使うとしたら、どんな状況ですか」
種明かし後の驚きの反応と、その後の発言を丁寧に記録する。このタイミングで出る言葉は率直で価値が高い。
ファシリテーションのコツ
ウィザードは「AI」を演じるのではなく「自然なシステム」を演じる。 AIらしさを過剰に演出しようとすると、かえって不自然さが際立つ。「適切な応答を返すシステム」として振る舞うことで、被験者の没入が維持される。
セッション間に30分の振り返りを挟む。 複数セッションを連続で実施すると、ウィザードの疲労から応答品質が下がる。セッション間の振り返りで「想定外だったパターン」を共有し、スクリプトに追加する。
応答テンプレを全員が把握しておく。 ウィザードが2名体制の場合（1名が応答、1名が記録）、記録担当もスクリプトを理解していると「この応答で被験者の反応がどうだったか」の分析が深まる。
既存メソッドとの比較・使い分け
| 軸 | ペーパープロト | Wizard of Oz | 高忠実度プロト |
|---|---|---|---|
| 適した検証 | 静的UI・画面遷移 | 動的応答・AI・自動化 | UIの細部・実使用感 |
| 準備コスト | 低（1〜2時間） | 中（半日） | 高（数日〜数週間） |
| ウィザード要否 | 不要 | 必要（1〜2名） | 不要 |
| 得られる学び | 概念伝達・情報設計 | 期待値・応答品質・行動パターン | 視覚品質・操作感 |
| 適したタイミング | Discovery初期 | Discovery後半〜Define | Develop後半 |
ペーパープロトとWizard of Ozの組み合わせが最もコスト効率が高い。 まずペーパープロトで「画面の概念が伝わるか」を検証し、次にWizard of Ozで「動的な振る舞いに対する期待値」を検証する流れが定石だ。
ペーパープロトタイピングとプロトタイピング手法の全体像も参照してほしい。
よくある失敗と対策
失敗1：ウィザードの存在が被験者にバレる
最も頻繁に起こる失敗だ。応答時間が一定すぎる、応答内容に個人の文章スタイルが出る、操作音が漏れる——いずれかで被験者が「これは人が動かしている」と気づく。一度気づくと、被験者の行動データが「演技への反応」になってしまう。
対策：
- ウィザードを物理的に別室または別ウィンドウに隔離する
- 応答テンプレを中心に使い、即興を最小化する
- 応答時間に1〜2秒のランダム性を加える
- 事前リハーサルで「バレるポイント」を洗い出す
失敗2：応答スクリプトの準備不足
「20パターン用意したのに、被験者が全く別の方向で操作した」というケースは珍しくない。準備したスクリプトが被験者の行動パターンを前提としすぎると、即興で対応する局面が増える。
対策：
- スクリプトを「想定入力への応答」ではなく「応答カテゴリ」で分類する（情報提供型、確認型、エラー型、時間稼ぎ型）
- 「理解できませんでした。もう少し詳しく教えてください」系の時間稼ぎを10種類以上用意する
- リハーサルで「チームメンバーが一番変な操作をするコンテスト」を開いてスクリプトの穴を埋める
失敗3：デブリーフィングを省略する
「テスト観察で十分なデータが取れた」と判断して種明かしを省略すると、倫理的な問題だけでなくデータの損失にもなる。デブリーフィング後の率直な発言は、観察データでは得られない洞察を含む。
対策： テスト進行のアジェンダに「デブリーフィング15分」を必ず含める。時間が足りなくなった場合も、種明かしと最低限の反応収集は省略しない。
B2B・社内プロジェクトへの応用
Wizard of Ozは「消費者向けAI製品」のイメージが強いが、社内システム・B2B SaaSの検証でも高い効果を発揮する。
社内ワークフロー自動化の検証： 「AIが申請書を自動分類する」機能を実装前に検証する場合、人間が分類担当者として申請書を手動でふり分け、それを「自動分類されたもの」として申請者に提示する。申請者が「誤分類」にどう反応するか、「どんな誤分類は許容できるか」が実装前に把握できる。
コールセンターの自動応答検証： 顧客の問い合わせに対してオペレーターが「AIらしい応答テンプレ」で回答し、顧客がどの段階で「人間に繋いでほしい」と言うかを観察する。
ワークショップでよく起こるのは「社内向けなら多少精度が低くても許容される」という楽観的な想定が崩れるケースだ。B2B・社内でもユーザーの期待値は高く、Wizard of Ozで検証することで「許容できる誤答率」を事前に把握できる。