ゲームプロトタイプにおけるAI対話の役割：主役に据えるか、サポートにするか、舞台裏に留めるか？
プレイアブルなプロトタイプにおいてAI対話の役割を選ぼうとしているインディー開発者なら、まずはプレイヤーのタスクから始めましょう。あらかじめ用意されたセリフでは上手くサポートできない、プレイヤーに何を可能にさせたいのか？ キャラクターとのアドリブのやり取りそのものが遊びとなる場合にのみ、AIをメインのインタラクションに据えてください。固定されたゲームプレイやストーリーが主導権を握り続ける場合は、サポートレイヤーとして活用します。プレイヤーに生成型の会話が全く必要ない場合は、クリエイターツールとして舞台裏に留めておきましょう。それぞれの選択によって、プレイヤーができること、システムが失敗したときに起こること、そして開発チームが背負うべき作業負荷が変わってきます。
プレイヤーのタスクから始める
「AI対話」という言葉は、大きく異なる2つのものを指すことがあります。1つはプレイヤーがキャラクターとやり取りする最中に生成される対話、もう1つはクリエイターが後から選択・編集するためのドラフトを作成するために使用されるAIです。また、その中間として、基本的には手動制作されたゲームでありながら、限定的なサポート役として生成対話を使用するという選択肢もあります。これらはすべてのゲームが順に登るべき3つの段階ではなく、それぞれ異なるデザイン上の決定です。
Ubisoftの[NEO NPC プロトタイプ](https://news.ubisoft.com/en-us/article/5qXdxhshJBXoanFZApdG3L/how-ubisofts-new-generative-ai-prototype-changes-the-narrative-for-npcs)では、ライターによって形作られ、シナリオやキャラクターの指針によって制約されたNPCとの、プレイヤー向けの自由形式な会話が探求されました。UbisoftはNEO NPCをあくまでプロトタイプとして位置づけており、このアプローチがリリースされるすべてのゲームで機能する証拠ではないとしています。対照的に、[Ghostwriter](https://news.ubisoft.com/en-gb/article/7Cm07zbBGy4Xml6WgYi25d/the-convergence-of-ai-and-creativity-introducing-ghostwriter)は、ライターが選択して推敲できるように、周囲の環境音的なセリフ（バーク）のドラフトバリエーションを生成します。対象ユーザーはライターであり、生成されたテキストがプレイヤーとのライブな会話として提示されることはありません。
3つ目のデザインの参考例は、完全に手動制作されたものです。[Strange Scaffoldによる『Sunshine Shuffle』の開発記録](https://www.gamedeveloper.com/design/deep-dive-creating-seamless-dialogue-for-sunshine-shuffle)において、デザイナーのStav Hinenzon氏は、ポーカーのゲームプレイに合わせてセリフ、掛け声、長めの短い物語（ストーリーレット）を整理し、どのコンテンツを優先するかを管理するための優先順位とタイミングのルールについて説明しています。このゲームの対話システムは、生成テキストを必要とせずに体験を支えています。これらの事例は合わせて、実用的なプロトタイプの問いを提示しています。プレイヤーはキャラクターとアドリブで話す必要があるのか、ゲームは手動制作されたコンテンツの周囲に応答性のあるレイヤーを必要としているのか、あるいはチームは主にドラフト作成の支援を必要としているのか？
3つの役割を比較する
**メインインタラクション**：キャラクターを通じて目標を達成するために、自由形式の会話で質問したり発言したりする。プレイヤーの入力によって、利用可能になる有用な情報、アクション、または関係性の状態が変化します。タスクの完了状況と、応答が次の意図したアクションを正しくサポートしているかを追跡します。キャラクターに対応可能なトピックと状態変更の定義されたセットを与え、サポートされていない入力に対しては、事前に書かれたリダイレクトを使用するか、既知の会話状態に戻します。制作負荷：最高。チームはキャラクターとシナリオの制約を定義し、対話をゲーム状態に接続し、予期しない入力を処理し、固定スクリプトよりもはるかに多くのやり取りをテストする必要があります。
**サポートレイヤー**：対話が選択されたイベントに反応したり、オプションの応答を提供したりする中で、コアとなるゲームをプレイする。セリフはコアのアクションをブロックすることなく、イベントを明確にしたり、色を添えたり、反応したりできます。プレイヤーが関連するセリフに気付いているか、待たされることなくタスクを続けられるかを追跡します。メインパスと不可欠な情報は手動制作のまま維持します。生成が利用できない、または不適切な場合は、固定のセリフ、控えめな応答、またはセリフなしを使用します。制作負荷：中〜高。チームは生成された出力を、手動制作されたビート、タイミング、キャラクターの声、およびそれをトリガーできるゲームプレイ状態と調和させる必要があります。
**クリエイターツール**：手動制作されたゲームをプレイし、ライターやデザイナーが制作中にAIを使用してバリエーションを下書きする。プレイヤーは選択され、編集されたコンテンツを受け取ります。制作上の影響は、ツールがチームにとって定義された執筆タスクで使える選択肢を生み出す助けになるかどうかです。ライターが承認したスクリプトがフォールバックであり、最終的なゲーム内コンテンツとなります。制作負荷：変動的ですが、サポートすべきライブ対話システムはありません。コストはツールのセットアップ、レビュー、選択、編集、および執筆プロセスへの組み込みへとシフトします。
これらの影響はテストすべき設計目標であり、保証された効果ではありません。プロトタイプのタスクにとって重要なことだけを測定してください。会話がいかに流暢であっても、実行可能な情報を提供しなければ失敗です。生成されたセリフがどれほど魅力的であっても、プレイヤーが取るべき行動のターンを妨げてしまえば問題となります。
アドリブがメカニクスである場合はメインインタラクションを選択する
デザイナーが事前に網羅的に用意できないようなアイデアをプレイヤーが表現することにゲームの核となる魅力が依存しており、キャラクターの応答がプレイヤーの次の行動に有意義な影響を与えうる場合に、プレイヤー向けの自由な対話を採用してください。モデルを構築する前に、何をもってやり取りが成功したとみなすかを決定します。たとえば、プレイヤーが手がかりを得る、NPCにいくつかの有効なアクションのいずれかを実行させる、あるいは選んだ質問の流れを通じて事実を知る、などです。
プロトタイプの世界に境界を設けてください。キャラクターが何を知っているか、何をしないか、どのようなゲーム状態を変更できるか、そしてプロンプトが無関係な場合に何が起こるかを定義します。UbisoftのNEO NPCの説明では、ライターが作成したキャラクターの背景や行動指針とともに、モデルが意図したキャラクターから逸脱した際のイテレーションが強調されています。これは現実の制作タスクを示しています。つまり、各応答がキャラクターやシナリオに合致しているかどうかを、制作陣が依然として判断する必要があるということです。明示的に設計・テストされたパスでない限り、アドリブのテキストが勝手に新しいプロット上の事実やゲーム状態のコマンドにならないようにしてください。
有用なフォールバックは手動制作され、デザイン上目に見える形にしておくことです。入力がサポートされているタスクの範囲外になった場合、キャラクターは確認の質問をしたり、自分が何を手伝えるかを説明したり、プレイヤーを既知の選択肢に戻したりすることができます。プロトタイプが確実に目標を維持できない場合は、目標に必要な不可欠な情報を固定の対話や別の手動制作されたルートから入手できるようにしてください。
手動制作されたビートがゲームを牽引する場合はサポートレイヤーを選択する
メインのインタラクションの予測可能性を保ちながら、サポートレイヤーによってゲームプレイのイベントに反応させることができます。これには、オプションの環境セリフ、少数のアクションに対する短い応答、または固定された物語のビート周辺の生成バリエーションなどが考えられます。どのイベントがセリフをトリガーできるか、セリフが割り込めるかどうか、そしてその内容が新しい情報を導入することを許可されているかといった境界線を設定してください。
『Sunshine Shuffle』は手動制作の優れた比較対象となります。その対話ユニット、優先順位、タイミングは、ポーカーのターンとストーリーのペース配分に合わせて設計されていました。開発者の記録によれば、プレイヤーが読む時間を残す必要があり、プレイヤーの入力によってストーリーレットのセリフが進むようになっていました。サポートAIレイヤーへの教訓は具体的です。応答性はアクティビティのタイミングに合っていなければなりません。判断を行っている最中に届くセリフは、たとえ言い回しが優れていても、プレイの邪魔になる可能性があります。
指示、手がかり、決定、およびタイミングが重要となるビートには、手動制作されたテキストを維持してください。オプションの反応については、セリフをスキップする、固定の代替セリフを使用する、またはアクティビティに余裕ができるまで延期するなど、控えめな失敗時の処理（サイレントフェイルモード）を定義します。生成レイヤーをオフにしても、プレイヤーが依然としてコアタスクを実行できるかどうかをテストしてください。
プレイヤーに生成された発話が必要ない場合はクリエイターツールを選択する
もし必要なものがより多くの執筆素材、特に多数の短いバリエーションである場合は、まずクリエイターツールの役割を試してみてください。UbisoftはGhostwriterについて、プロセス内に人間のフィードバックが組み込まれており、脚本家が選択して推敲できるセリフのドラフトを提案するものだと説明しています。これは制作のワークフローであり、プレイヤー向けのNPCインタラクションではありません。承認されたセリフはライターの管理下に置き、1人のキャラクターの1つのイベントに対する反応の代替案を作成するなど、現実的で限定されたドラフト作成タスクに対してツールをテストしてください。
この選択肢は、ゲームがすでに手動制作の対話を使用しており、バリエーションは有用であるもののそれ自体はメカニクスではない場合に特に適しています。プロトタイプは実行時にツールなしでプレイできます。生成されたセリフの数を単純に数えるのではなく、レビュー後にその提案が実用的であるか、チームの執筆プロセスに適合しているかによってツールを評価してください。なお、記載された内容はUbisoftのツールとワークフローに関するものであり、同じアプローチがすべてのチームやプロジェクトで時間を節約できると証明するものではありません。
規模を拡大する前に小規模なプレイテストを実施する
ここで紹介するのは公開された研究の結果ではなく、例示的なテストです。プレイヤーが警備員の巡回の手がかりを入手し、ドアを通り抜けなければならないプロトタイプを想像してみてください。テスターの少人数グループに、警備員が自由形式の質問を受け付けるバージョン、ゲームがあらかじめ用意された対話の選択肢とオプションの反応的な発言を提供するバージョン、そして完全に手動制作されたバージョンの3つを提供します。目標と手がかりはすべてのバージョンで同一にしておきます。
試行ごとに、プレイヤーが手がかりを入手できたか、ドアを開けることができたか、どこで立ち往生したか、または待たされたかの3点を記録します。また、会話によってプレイヤーの下した決定が変化したかどうかもメモしてください。自由形式の会話が多様な言い回しを生み出しても、プレイヤーのルートや選択に有意義な変化をもたらさないのであれば、このプロトタイプでそれをメインのインタラクションにする根拠としては薄いと言えます。手動制作されたパスが明確に機能し、オプションの反応がそれを邪魔しないのであれば、サポート役で十分かもしれません。チームの主な困難が警備員の追加のセリフの下書きにあり、プレイヤーのタスクがすでに満たされている場合は、プレイアブルビルドの外でクリエイターツールをテストしてください。
これらの観察は、次のプロトタイプのイテレーションを選択するのに役立ちます。小規模なプレイテストでは普遍的なパフォーマンスを確立したり、より大規模なオーディエンスがどう反応するかを予測したりすることはできません。プレイヤーのタスク、フォールバック、そしてそれぞれを維持するために必要な作業を比較できるよう、バージョンは十分に小さく保ちましょう。
3つの質問で決定を下す
AI対話を追加する前に、以下の質問への回答を書き出してみてください：
**プレイヤーは対話を通じて何を達成しようとしているのか？** 単に「自然な会話をする」ことではなく、具体的なアクションや決定を明記してください。
**やり取りが成功した場合、どのような結果が生じるべきか？** 情報、選択肢、または許可される状態変化を特定し、それをプレイテストでどのように観察するかを決定します。
**生成が利用できない、または的を射ていない場合はどうなるのか？** プレイヤーがタスクを完了する能力を維持できる、手動制作されたルートを提供してください。
その上で、プロトタイプの規模と照らし合わせて制作負荷を見積もります。状態やトリガーの数、キャラクターやシナリオの指針の量、生成された素材に必要なレビュー、そして作成しなければならないフォールバックコンテンツなどです。プレイヤーに対する約束が大きい役割ほど、出力を有用で一貫したものに保つ責任も重くなります。小さなプロトタイプにおいては、範囲を絞ったテストを行うことで、その追加の負担がプレイヤーのタスクに寄与しているかどうかを判断できます。
この選択は、ゲームにおけるAIの是非を問うものではありません。この特定のプレイ体験において、生成対話がどこに属するべきかという決定です。プレイヤーが行うことの中心なのか、制御されたサポート役なのか、あるいはクリエイターのワークフローの中なのか。プレイヤーに体験させたい結果を実証できる最小限の役割を選び、それを拡大する正当な理由をプロトタイプ自体から見出していきましょう。