AIゲームの対話プレイテストを20分で観察する方法
小規模スタジオが生成AIによる対話シーンを1つテストする場合、プレイヤーがNPCの回答に対してどう行動するかを観察します。異なる質問を試しているか、有用な情報に基づいて行動しているか、でっち上げられた事実から立ち直っているか、シーンをクリアするために対話を終了しているか、などを確認します。短いアンケートを行えば、事後にプレイヤーが何を感じたか、どう理解したと述べているかを把握できます。しかしアンケート単体では、その時々に発生した選択や寄り道を明らかにすることはできません。プレイ中はシンプルなイベントシートを使用し、その後に焦点を絞ったフォローアップの質問を行います。観察結果は、このシーンとビルドに関する客観的事実として扱い、満足度の指標や全プレイヤーの行動の証明として捉えないようにしてください。
生成AIの対話シーンで何を観察すべきか？
明確な目的が1つあり、NPCの回答によってプレイヤーの進め方が変わり得るシーンを選びます。たとえば架空のシーンとして、プレイヤーは換気サイクルが終わる前に密閉された温室のゲートを開けなければならないとします。整備担当のNPCは、自由形式の会話を通じて手がかりを提供できます。想定されているルートはツール小屋で青いバルブハンドルを見つけることですが、NPCはたまに「ハンドルは水浸しのポンプ室にある」などと詳細をでっち上げることがあります。
以下の4つの指標は、プレイヤーの行動とシーンの結果に焦点を当てています。質問が巧みであるか、プレイヤーがゲームを楽しんでいるように見えるかを判断する必要はありません。
指標：**多様な質問** — イベントを記録するタイミング：プレイヤーが回答の後に言い回し、トピック、またはアプローチを変えたとき（例：バルブの場所を尋ねた後、何色か、あるいはどの部屋が安全かを尋ねる）。 — 記録すべき状態のエビデンス：何を質問し、NPCがどう答え、次の質問がその回答を受けてのものだったか。単なる言葉の繰り返しと、真に異なる問いかけを区別する。 — 事後に尋ねる内容：「それらの質問で何を知ろうとしていましたか？」
指標：**回答による次の行動の変化** — イベントを記録するタイミング：プレイヤーがNPCの回答に従う形で移動したり、何かを調べたり、計画を変更したりしたとき。 — 記録すべき状態のエビデンス：回答内容、プレイヤーの次の行動、および見落とされた目に見える代替手段。関連性を「明確」「もっともらしい」「不確か」として記録する。回答後の行動が必ずしも回答に起因するとは限らない。 — 事後に尋ねる内容：「会話のどの部分が、もしあれば、その後の行動に影響を与えましたか？」
指標：**でっち上げられた事実による誤った回り道** — イベントを記録するタイミング：プレイヤーがNPCの根拠のない、または虚偽の特定の主張に従い、その結果として無駄な行動を取ったとき。 — 記録すべき状態のエビデンス：正確な主張内容、それによって引き起こされた行動、ビルド上で確認できるコストや回り道、およびプレイヤーがどのようにして誤りを発見または修正したか。主張をでっち上げと判断する前に、セッション後にシーンの想定事実を確認する。 — 事後に尋ねる内容：「なぜそのルートが正しいと思えたのですか？いつ方針転換を決めましたか？」
指標：**プレイヤーが対話を終了してシーンをクリアできるか** — イベントを記録するタイミング：プレイヤーがこれ以上の会話を終了、一時停止、または辞退し、それでも目的を追求して達成できるとき。 — 記録すべき状態のエビデンス：終了の選択肢が視認可能か、会話を離脱した後に何が起こるか、有用な進行が依然として可能か、そしてプレイヤーがシーンの完了状態に達するか。プレイヤーが話し続けることを選択したケースと、進行不能要因（ブロッカー）を区別して記録する。 — 事後に尋ねる内容：「会話をいつでも切り上げられると感じましたか？会話を続けた、あるいは止めた理由は何ですか？」
これらはイベントの定義であり、質のスコアではありません。表情、沈黙、プレイ時間から意図を推測するのではなく、プレイヤーの実際の言葉や行動を記録してください。イベントが発生しなかった場合は、失敗と決めつけるのではなく「このセッションでは観察されず」と記録します。
観察シートをビルドと連動させておく
各セッションの前に、ビルドバージョン、初期の目的、シーンの既知の事実、および認められている完了状態を記録します。プレイ中は、プレイヤーの質問、NPCの回答、次に目に見える行動、および確定したゲーム状態の変化を書き留めます。役立ちそうに聞こえるセリフであっても、このビルドに存在しない場所を指している場合は誤りとなり得ます。
セッション後、でっち上げが疑われる事実を実際のシーン定義シートと照合します。シーンの事実と矛盾している場合のみ、根拠のない主張を「確認済み」とマークします。それ以外の場合は「未解決」とラベルを付けて調査します。進行役による促しや技術的な中断は、プレイヤーの次の行動を変えてしまう可能性があるため、別途メモを残しておきます。このささやかな証拠の記録により、1回のプレイスルーを普遍的な結果へと一般化しすぎることなく、その後の議論をより精緻なものにできます。
20分で区切るセッションの実施方法
参加者には次のように伝えます。「普段通りにこのシーンをプレイしてください。キャラクターと話すことも、いつでも会話を離れることも自由です。あなたが試すことを見届けるため、私は口を挟まないかもしれません。」多様な質問をするよう誘導したり、事実のでっち上げについて警告したりすることは避けてください。セッションで明らかにしようとしている行動が変わってしまいます。プレイヤーから助けを求められた場合は一貫した対応を取り、介入したことを記録し、その後の行動はその助けがあったことを念頭に置いて扱います。
実用的なスケジュールは以下の通りです：
**0〜2分：準備。** 想定される解決策を説明することなく、タスクと操作方法を説明します。プレイヤーが操作可能になった時点で計時を開始し、各参加者に対してシーンを同じ状態から始めます。
**2〜15分：観察。** プレイヤーに自由に探索させ、会話させます。関連する回答と次の行動をそれぞれログに記録します。特に、主張によってどこかへ向かわされた場合は注意深く追跡します。プレイヤーが立ち止まって先に進むための促しが必要な瞬間のために、「どう考えていますか？」といった中立的な問いかけを用意し、介入した事実を書き留めておきます。
**15〜20分：終了と質問。** プレイヤーがまだ終了していない場合でも、15分プレイした時点で停止し、スピードテストに落ちたような印象を与えるのではなく、現在の状態を記録します。観察されたイベントに紐づくフォローアップの質問を行い、最後に「会話や次のステップについて、何か不明な点はありましたか？」という大まかな質問を1つ行います。自己申告の内容は、観察された行動とは分けて記録します。
20分という制限はこの例における実用的なセッションの境界線であり、経験的なベンチマークではありません。会話に長い時間を費やしたプレイヤーが、それによってより高い満足度を示したとは言えませんし、早く終わったプレイヤーが必ずしもシーンを理解したり楽しんだりしたわけではありません。ビルドの都合でタスクにより多くの時間が必要な場合は、セッション前にスケジュールを調整し、一貫性を保ってください。
実際に起きたこととプレイヤーの発言を分ける
[『The Turing Test』のポストモーテム](https://www.gamedeveloper.com/business/postmortem-building-i-the-turing-test-i-around-a-secret-mechanic)の中で、デザインディレクターのDavid Jonesは、学生を対象にパズルをテストし、楽しさや難易度の評価、プレイ時間を収集した上で、プレイヤーの行動を観察することをより重要視したと述べています。彼は難易度曲線を評価するために、評価と観察を組み合わせることについて語っています。対話シーンにおいて有益な教訓は、この2種類のエビデンスをまとめつつも、明確に区別しておくことです。イベントログは何をしたかを示し、フォローアップはその説明や評価を記録します。一方が他方を自動的に説明することはありません。
Kleiの[『Mark of the Ninja』ポストモーテム](https://www.gamedeveloper.com/design/classic-postmortem-klei-entertainment-s-i-mark-of-the-ninja-i-)では、デザインの前提を検証するために、新規プレイヤーを対象としたテストを頻繁に行ったことが述べられています。チームは不満の背後にある動機を探り、初心者がどこで苦戦しているかを観察し、キュー（手掛かり）やデザインを調整しました。これを本件に適用すると、プレイヤーの回り道は調査すべき手がかりであり、単にNPCのセリフを長くするためのきっかけではありません。回答、インターフェース、またはシーンの何がそのルートをもっともらしく見せたのかを問い、何を変更するかを決める前に録画やビルドの状態を確認してください。
ユービーアイソフトの[「Teammates」の発表](https://staticctf.ubisoft.com/8aefmxkxpxwl/2QCAorjku7w7gH1LGORV3t/6e8f347be3ecab7daa4769e5300086bc/Ubisoft_Unveils_%C3%A2__Teammates%C3%A2____Its_First_Playable_Generative_AI_Experience_Through_Closed_Player_Testing.pdf)では、プレイアブルな生成AI体験に関するクローズドプレイヤーテストが紹介されています。同発表はチームがクローズドテストを発表したことを示すものであり、引用された発表内には公開されたプレイヤーの結果は含まれていないため、プレイヤーが何を行ったかや、その体験が成功したかどうかについての主張を裏付けることはできません。
観察結果を次のビルド決定に活かす
セッション後、タイムラインを振り返り、NPCの各回答とプレイヤーの次の行動を結びつけます。誤った回り道のように思えるケースごとに、関連するシーンの事実を確認し、考えられる原因を特定します。NPCが誤った詳細を提供したのか、プレイヤーが正しい回答を誤解したのか、あるいは場所やインタラクションのキューが別の場所を示していたのかなどを分析します。これらの説明は、記録された一連の流れや、必要に応じて別のセッションと照合されるまでは、あくまで仮説にすぎません。
4つの指標を活用して、具体的な改善や次回のテスト内容を決定します。プレイヤーがいくつかの異なる質問をしているにもかかわらず、行動の手がかりにならない回答しか得られていない場合は、シーンが行動につながる情報を提供できているかを見直します。特定のでっち上げられた主張によって誤った部屋に行ってしまう場合は、その主張を検証する方法や、行き止まりにならずに復帰できる手段がシーンに必要かどうかを検討します。プレイヤーが対話を終了してクリアできない場合は、離脱の導線と目的のフローを確認します。問題なく離脱してシーンを完了できた場合は、このビルドでそのパスが利用可能だったことをメモし、分かりやすかったと結論付ける前にプレイヤーがどう理解していたかを質問してください。
わずか20分のセッション1回でも、特定の混乱や不足しているルートを浮き彫りにすることはできますが、その問題がどれほど一般的であるかを証明することはできません。次に何を調査すべきかを決定する際は、観察者のイベントメモ、検証済みのシーンの事実、およびプレイヤーの事後回答を分けて管理してください。そうすることで、アンケートだけに頼るよりもはるかに有用な、このプレイヤーが生成AIの対話シーンをどのように進んだかについての記録を小規模チームが得ることができます。