あるチームが、まとまりのないリクエストを有用な計画に変換してくれるアシスタントのテストを計画しているとします。基盤となるシステムを構築するには何カ月もかかるかもしれませんが、想定される回答のスライドを見せるだけでは、ユーザーが実際にどんな質問をするのかはほとんどわかりません。そこで中間のステップとして役立つのが「オズの魔法使い（Wizard of Oz）」テストです。これは、システムが自律的に応答しているように見せかけたインターフェースを通じて、人間が回答の一部またはすべてを裏で返す手法です。

この手法では、リサーチ中に「オズの魔法使い」と呼ばれる人間のオペレーターが裏で機能をシミュレーションします。これにより、自動化が実現する前の段階で、ユーザーが何を求め、どのような返答を期待し、意図どおりにいかないときにどう反応するかといったインタラクションを検証できます。ただし、オペレーターによるパフォーマンスと、最終的なテクノロジーで実現できるエビデンスは、明確に区別しておく必要があります。

オペレーターが再現するシステムの枠組みを定義する

架空の献立作成アシスタントを想像してみてください。参加者が「予算内に収まり、余り物を使い、家族のアレルギーを避けた夕食」を求めたとします。スキルのあるリサーチャーなら非常に気の利いた回答を作れるかもしれませんが、その調査でシステムがアクセスできる情報や能力が事前に定義されていなければ、将来のシステム開発にとってはあまり参考になりません。

セッションの前に運用ルールを策定しておきましょう。アシスタントが受け付ける入力、アクセス可能な情報、再現すべき応答時間、サポート外のリクエストへの対処法などを決めます。具体例を用意し、参加者向けのインターフェースとオペレーター間の連携もリハーサルしておきます。

Nielsen Norman Groupによるオズの魔法使い手法のガイドでは、全機能を実装することなく体験を検証するために、人間が制御するシミュレーションを活用する方法が解説されています。再現する振る舞いが明確に定義されているほど、シミュレーションから得られる洞察はチームにとって解釈しやすいものになります。

オペレーターの機転ではなく、体験そのものをテストする

参加者にはリアルなタスクシナリオを提供し、チームが予期していなかったリクエストが出る余地も残しておきます。そうしたリクエストとそれに対する回答の両方を記録しましょう。もしオペレーターがあらかじめ決めたルールを超えてアドリブで対応した場合は、それを通常のシステムの振る舞いとして暗黙のうちに流すのではなく、ルールからの逸脱として記録に残します。

献立作成の例で言えば、1週間分を丸ごと再生成することなく、1つの食材だけを変更したいというニーズが見つかるかもしれません。これは有用なインタラクション要件です。しかし、人間が入念に作った献立に対する満足度は、自動化されたモデルが同じように適切な提案を出せることの証明にはなりません。

リサーチの問いに関わるのであれば、あえて現実的な制約も含めておきます。理想的な応答ばかりをテストしていると、修正や拒否、確認、リカバリーといった対応の必要性が見落とされてしまいます。チームがそうした状態の設計を終えたら、ユーザーがそれにどう対処するかを別のプロトタイプテストで検証できます。

シミュレーション前に同意とデブリーフィングを計画する

参加者は、プロトタイプのどの部分が人間によって操作されているのかを正確には把握していない場合があります。そのため、どこまで情報を開示するかはリサーチ設計における重要な判断となります。検証したい問いの妨げにならない限りは、シミュレーションであることをオープンにする姿勢を優先し、単にリアリティを持たせるためだけの不必要な隠蔽は避けるべきです。

何らかの情報を伏せておく場合は、リサーチ計画において適切な倫理的検討、明確な制限、配慮の行き届いたデブリーフィング（事後説明）が必要です。参加者が何が起きたのか、また自身のデータがどのように扱われるのかを理解できるようにしてください。最終的なネタばらしを単なるサプライズのように扱うだけでは、インフォームド・コンセントを満たしたことにはなりません。

この取り組みは、あくまでリサーチの枠組み内に安全にとどめておく必要があります。先ほどの献立の例なら、生成されたプランを信頼できるアレルギー情報として扱ったり、シミュレーションされたサービスが確かなものであるかのように行動させたりしてはいけません。検証されていない推奨事項に参加者を依存させることなく、適切なシナリオを用いて期待値を調査することができます。

得られた洞察を実装可能なバージョンへ引き継ぐ

リクエスト内容やインターフェースの理解度、リカバリーに関する知見は、回答の質そのものに依存する知見とは切り離して整理します。後から参照するメンバーが参加者の体験した実態を把握できるよう、オペレーターの関与度合い、応答の遅延、ルールからの逸脱などをドキュメントに残しておきましょう。

次のリサーチサイクルでは、実際の機能が利用可能になった段階で改めて検証を行います。ユーザーは同じリクエストを出したとしても、本物の遅延や回答のばらつき、利用可能なデータの制限などに対しては異なる反応を示すことがあります。オズの魔法使いテストは、何を作り、何をテストすべきかを見極めるのに役立ちますが、最終的にオペレーターの代わりとなるシステムそのものの品質を保証するものではありません。