ミステリーゲームで失踪したキャラクターのAIアシスタントは実際に何を知り得るのか？
架空のミステリーゲームにおいて、AIアシスタントは作者が開示した物語の記録のみを、そしてそれらの記録にアクセス可能となった時点からのみ知るべきです。すべての事実に情報源、判明した時点、アクセスルールを設定してください。これにより、アシスタントがいつの間にか全知の語り手になってしまうことなく、プレイヤーが手がかりを結びつける手助けをすることができます。
物語の記録とアシスタントのアクセス権を分離する
まずは、作者側が把握する物語の完全な記録から始めます。イベント、キャラクターの発言、アイテム、メッセージ、そしてそれらがゲームに登場する順序です。その上で、アシスタント向けにより限定されたビューを定義します。ある事実は、設定資料（ストーリーバイブル）に存在していても、アシスタントにはまだ利用可能でない場合があります。この区別こそが公平なミステリーの基盤です。作者は何が起きたかを知っていても、アシスタントはその架空の役割によって閲覧が許可された記録しか使用できません。
Twineなどのインタラクティブノベル制作ツールは、物語をパッセージ（節）に整理し、変数や条件分岐ロジックを使用してプレイヤーが見る内容を変更できます。これは有用な設計上のアナロジーとなります。作者が作成した各記録を個別の単位として扱い、関連するパッセージ、イベント、選択肢に応じてその記録へのアクセスを条件付けします。Twineの基本概念
たとえば、マーラという架空のキャラクターがコミュニティガーデンの展示を準備しているとします。アシスタントは、彼女が共有した計画メモ、グループの掲示板に投稿されたスケジュール、そして後に彼女が送信したペイントした看板を屋内に移動させたことに関するメッセージにアクセスできるかもしれません。単に彼女がガーデニングを好むと知っているだけで居場所を推測すべきではありませんし、自身に共有されなかった私的な下書きを見るべきでもありません。これらの制限は、現実のAIシステムがアクセスできるものについての主張からではなく、物語の中で作成されたアクセスルールから生じるものです。
各事実に情報源と「判明した日時」を付与する
有用な事実の記録は、少なくとも4つの質問に答えます。何が主張されているか、誰（または何）がそれを提供したか、アシスタントがいつアクセスできるようになったか、そしてそれが直接的なものか推論によるものかです。W3Cのプロベナンス（来歴）モデルは、情報の発祥を実体（エンティティ）、活動（アクティビティ）、主体（エージェント）の観点から記述し、ある項目が別の項目からどのように導出されたかを記録することも可能にしています。これは、ゲームが正式なモデルの代わりに単純なラベルを使用する場合でも、架空の記録に対する実用的なフレームワークとなります。W3C PROVモデル入門
コンパクトな記録は以下のようになります。
主張：マーラは庭の看板をペイントする予定だった；情報源：共有された計画メモ；アシスタントへの判明日時：月曜 10:00；種別：直接的な記述
主張：看板は屋内に移動された；情報源：グループ掲示板の更新；アシスタントへの判明日時：火曜 16:30；種別：直接的な更新
主張：雨の予報だったためマーラが看板を移動させた可能性がある；情報源：天気メモ＋更新情報；アシスタントへの判明日時：火曜 16:30；種別：推論（未確認）
日時の例は説明のためのものです。重要な区別は、イベントがいつ発生したかと、アシスタントがそれをいつ知ったかの間にあります。月曜日に作成されたメモが火曜日に共有された場合、物語が明示的にそれ以前のアクセス権を与えていない限り、アシスタントの知識は火曜日から始まります。両者のタイムスタンプが異なる場合は、両方を保持してください。
観察、報告、推論を明確に区別する
情報源があるからといって、その内容が確実であるとは限りません。キャラクターが見たものを説明しているだけかもしれませんし、メモが不完全であったり、スケジュールが実際に起きた行動ではなく計画を記録していたりすることもあります。記録の種別にラベルを付けることで、アシスタントは正確な言い回しで応答できるようになります。「掲示板には看板が移動されたと書かれています」は「マーラが看板を移動させました」とは異なり、どちらも「天候のせいで彼女が移動させたのでしょう」とは異なります。
直接観察、キャラクターの報告、作成された記録、推論といった少数の語彙を一貫して使用してください。推論は裏付けとなる記録を指し示し、推論であるとマークされたままであるべきです。W3C PROVは、活動に対するエージェントの責任や、ある実体から別の実体への導出を明示的にモデル化しています。この区別を対話に適用することで、ゲームは結論を新たな事実として提示するのではなく、どこから得られたものかを示すことができます。W3C PROV-O
これは有益な執筆テストにもなります。プレイヤーは、アシスタントの確信に満ちた発言の根拠を、アシスタントへのアクセスが許可されていた記録まで遡ることができるでしょうか？できない場合は、回答を修正するか、不足している記録を追加するか、十分な情報がないとアシスタントに言わせるようにしてください。
キャラクターだけでなく、物語内の時間でアクセスを定義する
すべての記録について、アシスタントのアクセスを解除するイベントを指定します。共有メッセージは送信された直後に利用可能になるかもしれません。掲示板に貼られた通知はアシスタントが掲示板を確認したときに利用可能になるかもしれません。会話はプレイヤーがそれについて質問することを選択した後にのみ利用可能になるかもしれません。「アシスタントはアーカイブ内のすべてを知っている」といった曖昧なラベルに依存するのは避けてください。物語内でそのアーカイブに何が含まれ、いつ更新されるかが確立されている場合は別です。
実用的なアクセスルールは、記録の対象読者、利用可能になるトリガー、遅延の3つの要素で構成されます。たとえば、「アシスタントはプレイヤーが掲示板を開いた後にグループ掲示板の投稿を読むことができる。個人的な下書きは読めない」といった具合です。分岐するストーリーでは遅延が重要になります。プレイヤーが掲示板を訪れていない場合、作者のファイル内の別の場所にその投稿が存在しているからといって、アシスタントが最新の投稿を見たかのように振る舞うべきではありません。
Twineでは、ストーリー変数はパッセージをまたいで利用できますが、一時変数はHarloweやSugarCubeでは現在のパッセージに限定されます。この違いは、ある事実が物語全体を通じて持続するのか、それとも特定のシーンにのみ属するのかを作者が意図的に決定すべき理由を示しています。正確な実装はストーリーのフォーマットに依存するため、このルールはコードの指示ではなく設計モデルとして扱ってください。Twineクックブック：変数
不確実性をプレイヤーにとって有益なものにする
記録が見当たらない、古い、または曖昧な場合、アシスタントにはその情報の不足を具体的な言葉で説明させましょう。月曜日の計画はあるがその後の確認が取れていないことや、あるキャラクターは看板を移動させたと報告したが掲示板には更新がないことなどを伝えることができます。これにより、プレイヤーには有意義な次の一歩が生まれます。作者が用意した別の情報源を調べる、キャラクターとの会話を振り返る、あるいはその手がかりは未解決のままだと判断するなどです。
このアプローチは、恣意的な全知に頼ることなくミステリーを支えます。インタラクティブナラティブに関する研究では、限定された知識がプレイヤーの行動をどのように形作ることができるかが検証されており、これにはインタラクティブフィクション『Anchorhead』を用いてプレイヤーモデルを探求した研究も含まれます。執筆されたアシスタントにとって、設計上の示唆はシンプルです。プレイヤーとアシスタントが学んだことが次の選択に影響を与える可能性があるため、それらの知識状態を明示的に追跡することです。Rivera-Villicanaらによる『Informing a BDI Player Model for an Interactive Narrative』
アシスタントの台詞を書く前の簡単な監査
回答の下書きを作成する前に、重要な主張ごとに以下の点を確認してください。
その主張は作成された記録に存在しているか、あるいは推論としてラベル付けされているか？
その記録には情報源が明記され、計画、報告、観察、またはその後の確認が区別されているか？
物語内のどの時点でアシスタントはそれにアクセスできるようになったか？
アシスタントの架空の役割は、その情報源へのアクセスを許可しているか？
記録が不完全であったり矛盾していたりする場合、対話はその不確実性を保持しているか？
これらのいずれかに対する答えが不明確な場合は、利用可能な記録と一致するまでアシスタントの発言を限定してください。そうして作られたキャラクターであっても、十分に役立つ存在であり得ます。見たものを要約し、未確認のまま残されているものを特定し、作者が用意した次の手がかりへとプレイヤーを導くことができます。その信頼性は、物語の完全な記録と、アシスタントが実際に受け取った情報との間の明確な境界から生まれるのです。