Wizard of Oz プロトタイプ 応用としてAIシステムを検証したいとき、基本的な手法の枠組みだけでは通用しない場面があります。チャットボット・音声アシスタント・生成AIを対象にした場合、ウィザード（人間オペレーター）が演じるべき「AIらしさ」の質が、一般的なUIモックとは桁違いに高い要求水準になるからです。AIシステム固有の検証問いに対応するためのウィザード構成バリエーションと、上級テクニック、陥りやすい失敗パターンをまとめます。
基本手法との違い：AIシステムに固有の難しさ
一般的なWizard of Ozでは、静的なUIモックの画面遷移をウィザードが操作します。被験者がボタンを押したら、ウィザードが次の画面に切り替える——この操作は準備した選択肢から選ぶ作業です。
AIシステムの場合、それだけでは足りません。
問題1：応答の「粒度」が検証の核心になる
チャットボットや音声アシスタントで検証したいのは「UIを操作できるか」ではなく、「この応答の品質・温度・粒度に対してユーザーはどう反応するか」です。ウィザードが返す応答の質そのものが検証変数になります。
問題2：無限の入力バリエーション
ボタンクリックは有限の選択肢ですが、自然言語入力は事実上無限です。「期待していない入力が来たときにどうするか」を設計しておかないと、ウィザードは即興で破綻します。
問題3：「人間っぽさ」と「AIっぽさ」の矛盾
被験者がAIと対話していると信じるためには、応答が「人間的すぎない」必要があります。しかし品質を上げようとすると、ウィザードは自然と人間的な応答を書いてしまう。この矛盾の管理が、基本手法にはない課題です。
セットアップ手順：AIシステム向けの準備
Step 1：検証問いの解像度を上げる（30分）
AIシステムのWoZでは、検証問いが曖昧なまま始めると何も分からずに終わります。以下の3軸で問いを分解します。
- 信頼軸：ユーザーはこのAIの応答を信頼して行動を変えるか
- 期待軸：ユーザーがAIに期待する応答の粒度・トーン・文量はどのくらいか
- 依存軸：AIがなければできない操作が発生したとき、ユーザーはどう対処するか
例えば「採用スクリーニング支援AIのチャットボット」を検証する場合、「信頼軸：AIが出したスコアを根拠に面接を省略するか」を問いにすると、観察すべき行動が明確になります。
Step 2：応答スクリプトの設計（45〜60分）
基本手法の20〜30パターンを、AIシステム向けには30〜50パターンに拡張します。設計の原則は「AIトーン・文量・エラーパターンの3セット」を用意することです。
AIトーン設計：想定するAIのキャラクター（簡潔なビジネス向けか、会話的な消費者向けか）に合わせて、ウィザードが使う言い回しのガイドラインを文書化します。「〜です」「〜ました」で終わる、1応答あたりの文量は2〜4文以内、感嘆符は使わない、といったルールを事前に確定します。
エラーパターン設計：「処理できませんでした」「情報が不足しています」「もう少し具体的に教えてください」など、AIがよく出す「外し方」のテンプレートを5〜8種類準備します。完全に正解し続けるAIは不自然で、被験者の没入が浅くなります。
時間稼ぎパターン：ウィザードが応答を考える時間が必要なとき、「確認中です」「分析しています」など処理中を示す短文を5〜7種類用意します。2〜4秒程度のディレイの後に出すことで、AIの処理時間を演出します。
Step 3：ウィザード2名体制の役割分担（15分）
AIシステムのWoZでは、ウィザード1名での運用は推奨しません。
- 応答担当ウィザード：スクリプトを参照しながら応答を生成し、被験者の画面に送る
- ログ担当ウィザード（ビハインドザシーン観察者）：被験者の発言・行動・表情の変化を記録する。応答担当がログを同時に取ると、応答品質が落ちます
2名が同じチャンネル（Slackのプライベートチャンネルなど）でリアルタイムに情報共有しながら進行します。「次の入力が来る前に応答担当がどのパターンを使うか」を事前に擦り合わせる短い合図ルールも設計しておきます。
AIシステム固有のWoZバリエーション
バリエーション1：チャットボットWoZ
最もシンプルな構成です。被験者がWebまたはモバイルのチャット画面に入力し、ウィザードが別端末から応答を送る形式です。
注意点：メッセージアプリのリアルタイム通知（「入力中…」表示）がウィザードの操作スピードと噛み合わないと、「人間が返している」と被験者が察知します。対策として、Figmaのプロトタイプでチャット画面をスタティックに作り込み、応答はウィザードが画面を書き換える形式にすると制御しやすくなります。
適した検証問い例：「ユーザーは自発的にAIに複数ターン以上の質問を続けるか」「AIの提案を拒否するときにどんな言葉を使うか」
バリエーション2：音声アシスタントWoZ
「Siriに話しかけるつもりで使ってください」と被験者に伝え、実際の音声認識と合成音声をウィザードが代替します。
ツール構成：被験者の発話をウィザードが聞き取り（または文字起こしツールを補助的に使い）、テキストで応答を選択し、音声合成ソフト（macOSのsay コマンド、またはElevenLabsなどのリアルタイムTTS）で再生します。
注意点：音声合成のレイテンシが高いと、発話してから応答が来るまでの沈黙が長くなり、被験者の集中が切れます。ウィザードが応答を入力し始めるタイミングを、被験者の発話が終わる直前（発話パターンを読む）にする練習が必要です。
適した検証問い例：「ユーザーは音声AIに対してどの程度の文量で話しかけるか」「AIが聞き返したとき、ユーザーは言い直すか諦めるか」
バリエーション3：生成AI埋め込み機能WoZ
「文書要約」「コード補完」「翻訳改善提案」など、既存ワークフローに生成AIを組み込む機能の検証に使います。ウィザードが実際のAI出力を「事前生成」しておくか、セッション中にリアルタイムで生成します。
ツール構成：検証シナリオで使われると想定する入力パターンを事前に洗い出し、それぞれに対してChatGPT・Claude等で実際に出力を生成しておきます。セッション中はウィザードがその出力をコピー&ペーストします。これにより「本物のAI出力への反応」を検証できます。
注意点：事前生成した出力が網羅できない入力が来たとき、ウィザードがリアルタイムに生成ツールを操作する必要があります。この作業に時間がかかりすぎると、ディレイが不自然になります。「30秒以上かかりそうなら処理中テンプレを挟む」ルールを決めておきます。
適した検証問い例：「AI生成の要約に不満があるとき、ユーザーはどの程度の精度を期待して編集するか」「AI出力をそのまま使う/編集する/無視するの分岐はどこで起きるか」
失敗しやすいポイントと対策
失敗1：「AIトーン統一」を怠る
ウィザードが2〜3セッション進むうちに、疲れや慣れで応答スタイルが崩れます。最初は簡潔だった応答が長くなったり、口語的な言い回しが混じったりします。被験者間で体験の質が変わると、データが比較できません。
対策：各セッション開始前に応答ガイドラインを声に出して読み合わせる（30秒）。セッション後にログ担当がトーンの逸脱箇所を指摘し、次セッション前に修正します。
失敗2：被験者のタスクスコープが広すぎる
「AIを使って業務を効率化してみてください」のような曖昧なタスクでは、被験者がAIのどの側面を試しているのかが分散します。ウィザードが対応しなければならない入力バリエーションが爆発し、スクリプトが破綻します。
対策：タスクを「〇〇をAIに依頼して、その結果でXXをしてください」の形式に絞ります。入力の起点と終点が明確なタスクにすることで、ウィザードが準備すべきシナリオの範囲が定まります。
失敗3：デブリーフィングを「種明かし」で終わらせる
「実は人間が操作していました」と伝えた後、被験者が照れて正直に話さなくなるケースがあります。特にAIシステムに期待しすぎていた場合、「だまされた」という感覚が反応の正直さを阻害します。
対策：種明かしの伝え方を工夫します。「システムではなく、チームの一員が手動で応答していました。これはAIの振る舞いを設計するための研究です」と伝え、被験者の判断ではなく「チームが学ぶための材料」というフレームに変えます。その上で「もしAIの応答がもっと完璧だったとしたら、どう感じましたか」と仮定形で聞くと、被験者が本音に戻りやすくなります。
失敗4：「AIが完璧すぎる」セッションになる
ウィザードが全問正解し続けると、被験者はAIを過信した状態でテストを終えます。実際の製品では必ず「外れ」が発生するため、完璧なセッションから得られるデータは現実との乖離が大きくなります。
対策：意図的に「外し」を設計します。例えば5〜6ターンに1回、若干ずれた応答（ユーザーの質問を少し取り違えた内容）を返す計画を組み込みます。被験者が外れに対してどう反応するか（再入力・諦め・別の言い方）は、AIシステムのエラー回復設計にとって最も価値の高いデータです。
セッション後の分析：AIシステム固有の観察点
基本的なWoZのデータ収集に加えて、AIシステム固有で記録すべき観察点があります。
応答待機中の行動：被験者がAIの応答を待っている間に何をするか（別タブを開く、スマホを見る、声に出して独り言を言う）は、AIへの信頼・期待値の間接的な指標です。
言い直しの回数と変化パターン：AIに期待通りの応答が来なかったとき、被験者がどう言葉を変えて再入力するかは、ユーザーが「AIに何を求めているか」の最も生々しいデータです。この言い直しのログは、プロンプト設計とUIコピーの両方に持ち帰ります。
信頼の臨界点：何度目の外れで「このAIは使えない」と判断したか、または最後まで諦めずに使い続けたか。この臨界点の個人差を記録しておくと、ターゲットユーザーのAIリテラシーと忍耐閾値の設計根拠になります。