ミステリーゲームでAIキャラクターの対話による手がかりの捏造を防ぐ方法
AIキャラクターが手がかりについて話せるようにする場合は、実行可能なすべての主張を、作成済みのソースおよびゲーム側で管理される発見状態に依存させるようにします。モデルにはプレイヤーがすでに発見した証拠のみを提供し、手がかりのような発言の根拠となるソースの特定を義務付け、裏付けのない詳細は利用不可として扱います。雑談や雰囲気作りの会話は、事件の記録を更新したり進行を解除したりできない独立したフレーバー用チャンネルに分けておきます。これにより、即興の対話によってミステリーの真相が書き換わってしまうのを防ぎつつ、キャラクターが柔軟に話せるようになります。
捏造された手がかりがミステリーを破綻させる理由
ミステリーゲームにおいて、プレイヤーは情報を集め、結論を導き出し、得た知識を活用してさらなる情報を探します。そのため、手がかりとプレイヤーの知識との関係は、対話スタイルの細部というよりは、ゲームの中心的なループの一部となります。配置されていない手紙に自信満々で言及したり、プレイヤーが遭遇したことのない人物の名前を挙げたりするキャラクターは、図らずも新たな手がかりを作り出してしまう可能性があります。プレイヤーには、その詳細が意図された手がかりなのか、故意の嘘なのか、あるいは生成された穴埋めテキストなのかを確実に判断する方法がありません。「Generative Forensics: Procedural Generation and Information Games」という論文では、情報ゲームを「知識を集め、それを使って謎を理解すること」と説明しています。この枠組みを当てはめると、追跡されていない生成された主張は、プレイヤーが推理の拠り所とすべき知識を濁らせてしまう可能性があります。
その解決策は、明確な区別から始まります。「手がかり」とはプレイヤーが行動を起こせるゲーム上の事実であり、「フレーバー」とはゲームの事実を追加または変更しない表現豊かな対話です。キャラクターが曖昧に聞こえたり、はぐらかしたり、面白おかしく話したり、生き生きとしていたりしても構いませんが、説得力のある言い回しだからといって、そのセリフが証拠になってしまってはなりません。
対話を生成する前に、作成済みの手がかりレコードを用意する
行動につながるすべての手がかりについて、明示的で小規模なレコードを保持します。これはデータベース、コンテンツファイル、またはシナリオ制作ツール内に配置できます。重要なのは、モデルがその内容を捏造しないことです。その手がかりが何を伝えているか、どこから得られたか、誰がそれを知ることができるか、いつ利用可能になるかという項目を含めます。
フィールド: clue_id; 記録内容: 証拠の安定した識別子; 例（例示）: note_blue_01
フィールド: canonical_fact; 記録内容: ゲームが確立する事実; 例（例示）: 「メモにはイニシャルMの署名がある。」
フィールド: source_id; 記録内容: それを裏付ける作成済みのオブジェクト、シーン、またはセリフ; 例（例示）: archive_note_03
フィールド: discovery_condition; 記録内容: 言及可能になる前に必要なゲーム状態; 例（例示）: found_archive_note_03
フィールド: allowed_speakers; 記録内容: それを知ることや話すことが許可されているキャラクター; 例（例示）: Mara, Ivo
フィールド: certainty; 記録内容: ソースが事実を述べているか、解釈を示唆しているか; 例（例示）: explicit
フィールド: player_facing_label; 記録内容: 手帳などでの証拠の表示名（該当する場合）; 例（例示）: 「署名のないメモ」
上記の名前と値はフォーマットを示すための架空の例であり、特定のゲームに関する主張ではありません。このレコードがソースの明示的な内容と解釈を分けている点に注目してください。署名のイニシャルだけでは、誰がメモを書いたかは確定しません。この区別により、対話システムはキャラクターに推測をさせつつも、その推測を新たに検証された証拠として提示しないようにする余地が生まれます。
会話だけでなく、発見状態によって手がかりを制限する
発見状態をゲームが管理するステートとして表現します。例えば、found_archive_note_03 はプレイヤーが実際にそのメモを見つけたときにのみ true になります。会話の開始時に、プレイヤーの発見状態とキャラクターの知識によってフィルタリングされた、言及を許可された作成済み事実のリストをキャラクターに渡します。手がかりは、「プレイヤーがその発見条件を達成していること」と「話し手がそれを知ることを許可されていること」の両方のチェックをパスした場合にのみ利用可能になります。
これは、検索拡張生成（RAG）の実践的な応用です。関連するレコードを検索し、それらをモデルのコンテキストに配置し、それらのレコードから生成を行います。MicrosoftのRAGの概要では、この「検索–拡張–生成」のフローを説明し、検索が不十分または不完全だと不正確な出力につながる可能性があると警告しています。ゲームの場合、検索結果がモデルに到達する前に発見条件を尊重する必要があります。モデルに「ネタバレをしないで」と指示するだけでは、未発見の証拠を完全に差し控えることよりも効果が薄くなります。
権限のチェックは可能な限りモデルの外部で行うようにしてください。生成された文章のセリフではなく、ゲーム側が証拠を手帳に記録するか、パズルを解決するか、インタラクションを解放するかを決定すべきです。モデルは許可された事実を言葉で表現できますが、そもそもその事実が許可されているかどうかはゲームの状態が決定するべきです。
モデルに厳格な制約と安全なフォールバックを与える
有用なプロンプトでは、キャラクターの口調、現在のシーン、許可された手がかりレコード、および証拠とフレーバーの違いを指定する必要があります。質問が提供された証拠の範囲を超えた場合の対応（確認を拒否する、キャラクターが知らないと答える、またはキャラクターらしい行動につながらないセリフで返すなど）を明記します。矛盾するレコードや曖昧なレコードに対する指示も含めてください。MicrosoftのRAGプロンプトエンジニアリングガイダンスでは、明確なグラウンディングの制限、フォールバックの動作、ソース識別子、および矛盾への指示を推奨しています。これらは情報アシスタントだけでなく、制御されたキャラクターの対話にとっても有用な設計原則です。
例えば、イニシャルMがマーラ（Mara）がメモを書いた証拠になるかとプレイヤーが尋ねた場合、許可される回答としては「Mとは書いてあるが、それだけでは誰が署名したのかは分からない」などが考えられます。システムはこの言い回しを許可できます。なぜなら、ソースの事実と結論の違いが保たれているからです。回答をより満足のいくものにするために、目撃者や筆跡の一致、別の文書などを即興で作り出してはなりません。
モデルに spoken_text、claim_type、source_ids などの構造化フィールドを返させます。手がかりを含む回答の場合は、少なくとも1つの有効なソース識別子を要求し、そのターンに提供されたレコードと照合します。フレーバーの場合は、回答を非証拠としてマークし、手がかりフラグを設定させないようにします。構造化された出力は文章が真実であることの証明ではありませんが、表示や状態変更の前にゲーム側がチェックできる対象を作り出します。
プレイヤーが重要性を判断できるようにフレーバーにラベルを付ける
フレーバーテキストには、キャラクターの気分、他愛のない冗談、部屋に対する漠然とした反応などが含まれる場合があります。プレイヤーが手がかりとして合理的に捉えかねない日付、場所、物、具体的な目撃者、動機などの詳細を、さりげなく導入してはなりません。推測による発言をさせたい場合は、言葉遣いでその不確実性を明確にし、証拠リスト、クエスト状態、手がかりに基づくインタラクションなどの客観的なシステムからは除外してください。
この区別は、データと表示の両方に反映させることができます。内部的にはセリフに「証拠」「解釈」「フレーバー」のタグを付け、インターフェース上では証拠風のスタイルや手帳への記載をゲーム側で作成された手がかり専用にします。キャラクターが「もしかしたら、急いでメモを残したのかもしれない」と言うことはあっても、ゲーム側がその可能性を許可された解釈として作成していない限り、確認された手がかりとして表示されたり、新たな分岐のトリガーになったりしてはなりません。この3つの分類によるラベリングは、ソースが述べていること、誰かが推測したこと、単なる表現上の対話であることを維持する必要性から導き出された設計上の推奨事項です。
状態と条件の追跡にナラティブツールを活用する
このアプローチを適用するために特定のエンジンは必要ありません。インタラクティブナラティブツールは一般的に、パッセージ（節）やセクション、変数、条件付きコンテンツをサポートしています。Inkの公式ライティングドキュメントでは、ストーリーコンテンツを制御するための変数と条件分岐ロジックについて説明されています。また、Twine Cookbookのパッセージガイドでは、テキストの表示方法や反応に影響を与えるコードも含められるコンテンツセクションとしてパッセージを解説しています。対話自体が生成されたものか作成されたものかに関わらず、これらの機能を使用して発見状態、話し手の知識、条件付き対話を表現できます。
ナラティブレコードとゲームロジック全体で、手がかりIDと状態名の一貫性を保ちます。found_archive_note_03 のような変数は、特に異なるシーンで読み取りや設定を行う場合、曖昧な clue2 フラグよりも監査が容易です。行動につながる生成された各セリフから、許可されたソースレコードへの追跡可能なリンクを追加します。セリフに有効なソースがない場合、ランタイムはそれを証拠として扱うのではなく、拒否するか安全なフォールバックを要求できます。
焦点を絞ったプレイテストで境界を検証する
状態のルールが破綻しやすい「発見の境界」で会話をテストします。手がかりが見つかる前、見つかった直後、そして異なる知識を持つキャラクターが話した後に、それぞれ新しい会話を試してみてください。未発見の証拠について直接質問したり、ソースが部分的にしか答えていない質問を投げかけたり、ゲームが対応していればシーンをやり直したりします。表示されたセリフ、返されたソースID、手帳やストーリーの状態への変更を比較・検証します。
簡潔なテストチェックリストを用意すると、それらのチェックを具体的に進めるのに役立ちます：
行動につながるすべての主張が、作成済みの手がかりまたは明示的に許可された解釈に対応していること。
手がかりの発見条件が、それが利用可能な知識として現れる前に true になっていること。
話し手がそのシーンでその情報を知ることを許可されていること。
裏付けのない質問に対しては、新たな具体的な事実ではなく、設定されたフォールバックが返されること。
フレーバーのセリフが手帳のエントリを追加したり、手がかりの判定を満たしたり、証拠の状態を変更したりできないこと。
曖昧または矛盾するレコードに対しては、勝手に新しい解決策を出すのではなく、不確実性を示すか確認可能なフォールバックを生成すること。
グラウンディング（根拠付け）によって捏造された手がかりが生じる余地は減りますが、生成された文章が常に提供された事実を尊重するという保証はありません。MicrosoftがRAGの制限事項に関するガイダンスで指摘しているように、検索で関連レコードが見逃されることがあり、モデルはグラウンディングを行っていても不正確なテキストを生成することがあります。手がかりに関する最終的な決定権は作成済みのレコードとゲームロジックに委ね、生成はその境界線の周りに「声（語り口）」を添えるために使用してください。
実践的なルールはシンプルです。モデルに言葉を選ばせ、それらの言葉が何を確立してよいかは、作成済みのミステリーと現在のゲーム状態に決定させます。行動につながるすべての手がかりにソース、発見による制限、明確なステータスがあれば、ゲームが配置した覚えのない証拠をプレイヤーに与えてしまうことなく、キャラクターをより自然に会話させることができます。