ストーリーの整合性を損なわずにAIワールドビルディング・バイブルを作成する方法
確定したすべての事実に固有のID、人間の決定責任者、情報源、明確な適用範囲を割り当てて、AIワールドビルディング・バイブルを構築しましょう。それがいつ真実となるのか、どこに適用されるのか、どの登場人物がそれを知っているのかを追跡します。AIに追加の提案や矛盾の指摘を求め、それらの提案が正史（カノン）となる前に、人間による明示的な編集上の決定を必須とします。本ガイドは、次の章、シーン、またはクエストのための実用的なリファレンスを作成する小説家やゲームライターを対象としています。目的は、ストーリーのルールを誤って変えてしまうことなく、参照や改訂ができるバイブルを作成することです。以下の再利用可能な整合性台帳は、事実とそれに依存するシーンを結びつけます。
AIワールドビルディング・バイブルには何を含めるべきか？
まずは、執筆時の実践的な疑問に答えられる小さなリファレンスシステムから始めましょう。「このキャラクターは日没までに天文台に到着できるか？」「天文台の扉の開き方を彼らは知っているか？」「その答えは別のストーリー分岐でも変わらないか？」といった疑問です。
バイブルを関連する6つのセクションに整理します：
スプレッドシート、リンクされたドキュメント、または無理なく管理できるデータベースを使用してください。エンティティにはLOC-01やCHAR-02などの固定IDを割り当て、表示名や別名は別のフィールドで管理します。「ガラスの天文台」の名前を変更しても、その場所レコードへのすべての参照が壊れないようにするためです。
物語の要約は、台帳の便利なビューとして扱いましょう。要約が元のレコードと食い違う場合は、どちらかのバージョンをもとに執筆を進める前に、情報源を確認して矛盾を解消してください。
事実の所有者は誰であり、何をもって正史（カノン）とするか？
このワークフローにおいて、事実の所有権（オーナーシップ）には2つの側面があります。1つの信頼できるレコードがその記述を保持していること、そして1人の人間が変更の承認に責任を持つことです。個人の作家であれば、その人がその役割を果たします。チームの場合は、場所に関する決定をワールドデザイナーに、登場人物の秘密の開示をナラティブリードに割り当て、判断が重複する事項については指定された1名の解決者を置くといった形をとることができます。
所有権と併せて出所（プロベナンス）も記録してください。W3CのPROV概要（https://www.w3.org/TR/prov-overview/）では、出所を「何かの制作に関与した実体（エンティティ）、活動、人物に関する情報」と説明しています。これをストーリーバイブルに適用すると、ある記述がどこから生じ、どのように変化し、誰がそれを承認したかを保持することを意味します。ここでの台帳はその原則を応用したものであり、厳密なPROVの実装ではありません。
各レコードに明示的なステータスを付与します：
既存の原稿を取り込む際は、正確なシーンの参照先と裏付けとなる短い引用を付けて、AIに候補となる事実を抽出させましょう。その参照先は必ず自分自身で確認してください。登場人物が「天文台にはいつも鍵がかかっている」と言った場合、それは「その発言がなされた」という事実を示すだけであり、客観的なルールが自動的に確立されるわけではありません。
プロジェクトの権限ポリシーを文書化しておきましょう。例えば、「承認されたレトコン（過去設定の改変）の決定は以前のカノンエントリーを上書きする」「承認された元のシーンが事実を確立する」「作業中の下書きやブレインストーミングは暫定的なものにとどめる」などです。承認済みの2つのシーンが矛盾する場合は、どちらを変更するか決定するまで、その衝突を未解決としてマークします。
タイムラインと場所をどのように連動して追跡するか？
作中時間（ストーリー時間）と改訂時間は分けて記録してください。「6日目に橋が閉鎖される」は作中の出来事を表します。「作家が改訂版4で橋の閉鎖日を変更した」は編集上の決定を表します。これらを混同すると、作中の世界が変わったのか、それとも記述が修正されただけなのかが曖昧になります。
各出来事について、考えられる最も早い時刻と最も遅い時刻、場所、参加者、前提条件、および結果として生じる状態を記録します。厳密な正確さが不要な場合は幅を持たせましょう。「朝の配達の後、日没前」という表現は、でっち上げた何分何秒よりも役立つことがあります。設定が独自の暦や季節を使用している場合は、カレンダーの単位を定義してください。
ルートごとに、出発地、目的地、移動手段、所要時間（またはその範囲）、および利用条件を記録します。双方向の移動が可能かどうかも明記してください。地図上では2つの場所が近くに見えても、設定されたルート上では大幅な迂回が必要になる場合があります。
明確な例として、次のような整合性チェックを考えてみましょう。配達員が09:00に果樹園を出発し、天文台に到着するまでに3時間かかり、さらにレンズを回収するのに30分を費やすとします。最も早い到着時刻は12:30です。承認された例外が適用されない限り、配達員が正午にそこにいるシーンは、これらの入力データと矛盾します。
裏付けとなる入力要素（出発時刻、ルート、遅延、または待ち合わせ時刻）を変更して矛盾を解決します。移動に2〜4時間かかる場合は、到着時刻も範囲として扱われます。明確な矛盾として処理するのではなく、その不確実性を維持してください。
世界の真実と登場人物の知識をどう区別するか？
知識の記録は客観的な事実とは別に管理してください。重要な新事実が判明するたびに、登場人物、事実または思い込み、獲得した出来事、時間、および分岐条件を記録します。「知っている」「疑っている」「誤って信じている」「まだ知らされていない」を区別します。記録が存在しないことは知識が記録されていないことを意味するだけであり、無知を証明するものではありません。
これはインタラクティブナラティブにおいて直接的な対応物を持っています。Inkleの公式inkチュートリアル（https://www.inklestudios.com/ink/web-tutorial/）では、以前に訪れたストーリーセクションに基づいた条件付きテキストと選択肢の実装を示しています。また、カスタム変数についても説明されています。これらの仕組みは情報へのアクセスを表現できますが、シーンを通過したことで登場人物が特定の事実を実際に知るかどうかは、ライターが決定しなければなりません。
例えば、銅のディスクを目印に合わせると天文台の扉が開く、とします。これは「世界の事実」です。ミラが実演中にその手順を知ることは、別の出来事です。不完全なメモを読んだ別の登場人物は、どう動くのかを「疑っている」だけにすぎないかもしれません。
分岐型ゲームの場合、知識獲得イベントを関連するルートまたはステータス条件に紐付けます。キャラクターが手順を知ったルートと、それをスキップしたルートの両方をテストしてください。小説の場合は、作中時間において説明や会話が知識獲得イベントの後に起きているかを確認します。章が時系列順に並んでいない場合でも同様です。
再利用可能な整合性台帳
以下のフィールドをスプレッドシートの列として、またはノート内の繰り返し可能なレコードとして使用してください。1つのレコードにつき、個別に改訂可能な主張を1つだけ記述します。掲載している例は、ワークフローを説明するためだけに作成された架空のものです。
以下は、リンクされた3つのレコードのコンパクトな表示例です。実際の完全な台帳では、各行に上記の証拠および所有権フィールドが保持されます。
「未解決」を暗黙のうちに「不可（いいえ）」にしてはいけません。問いQ-003は、代替ディスクの選択肢を未定のままにしています。許可も禁止もしていません。答えを必要とするシーンが出てきた場合は、決定リクエストを発行する必要があります。
各オープンクエスチョンに責任者と決定ポイント（「S-15の執筆前に解決」など）を割り当てます。その答えが読者に対して意図的に伏せられている場合は、作者がすでにその答えを知っているかどうかを記録しておきます。作者が答えを持っている場合と、未決定のデザイン上の選択とでは、扱いが異なります。
執筆中にAIはバイブルをどのように活用すべきか？
対象となるシーンの時間、場所、視点、分岐、関連するカノンレコード、および未解決の依存関係を含む「シーンパケット」を用意します。シーンのキーワードを共有しているエントリーだけでなく、リンクされた前提条件も含めてください。扉が登場するシーンは、別の場所で行われた以前の実演に依存している場合があります。
以下のような再利用可能な指示プロンプトを使用します：
提供されたシーンを、添付された整合性レコードおよび明記された改訂版と照合して確認してください。矛盾の可能性がある箇所ごとに、シーンの該当箇所を引用し、関連するレコードIDを特定してください。それを「矛盾」「情報不足」「提案された追加事項」のいずれかに分類してください。時系列、移動、場所へのアクセス、登場人物の知識、分岐条件をチェックしてください。未解決の問いはそのまま維持してください。修正案は別途提案し、カノンを変更したり出典の参照先を捏造したりしないでください。提供された資料からは完了できなかったチェック項目があれば明記してください。
生成作業を行う場合は、明確な制約の中で代替案を求めてください。「F-014を変更せず、E-008の前にミラへ知識を与えることもなく、彼女の足を止める方法を3つ提案してください」のように指示します。求める雰囲気、ペース配分、設定の特徴などは、ご自身の言葉で説明してください。
出力は2段階で確認します。まず、引用されたレコードがその指摘内容を裏付けているかを確認します。次に、どの提案がストーリーにとって有益かを判断します。承認された変更のみが台帳に記録されます。必要な情報源が見当たらない場合は、それを取り出すか、指摘事項を未解決のままにしておきます。
歴史を消去することなくレトコン（過去設定の改変）を扱うにはどうすればよいか？
通常の作中の出来事とレトコンを区別しましょう。11日目に扉に新しい仕組みが導入されるのであれば、移行イベントと期間が限定された新しいルールを追加します。「以前からずっと別の仕組みが使われていた」ことに変更する場合は、過去のカノンを改訂し、依存するすべてのシーンを検証します。
バージョン履歴があれば、以前の状態を復元できます。Git公式本のバージョン管理の概要（https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control）では、バージョン管理がどのように変更を記録し、比較をサポートし、以前のバージョンを呼び出せるようにするかを説明しています。Gitはその選択肢の1つですが、ご自身の作業により適しているなら、実用的な履歴機能を備えたドキュメントシステムを選んでも構いません。物語上の決定が変更された理由は、別途記録しておきます。
提案されたレトコンごとに、次の手順を行います：
再利用可能な変更ログのエントリーには、変更ID、改訂日、決定責任者、理由、古いレコード、置き換えレコード、影響を受ける資料、および検証ステータスを含める必要があります。例えば、「CH-006：位置を合わせたディスクが2枚必要という変更を提案。F-014、E-008、K-009、S-12に影響。決定待ち」のように記述します。承認されただけで、それらに依存するシーンの修正が完了したと見なしてはなりません。
シーンを承認する前に何をチェックすべきか？
クリエイティブな改訂を行った後、整合性を確認するためにシーンを通読します。必要な出来事が起きているか、移動やアクセスの条件が満たされているか、登場人物が利用している情報を実際に持っているか、分岐固有の事実がその分岐内に留まっているかを確認してください。新しい詳細描写がカノンとして承認されているか、あるいは暫定的なものであることが明確に分かるようになっているかをチェックします。
そのチェックに使用したバイブルの改訂版を記録してください。後からの変更がそのシーンの依存関係のいずれかに触れた場合は、そのシーンを再確認の対象とします。まずは1つの場所、1人のキャラクター、そして次のシーンに不可欠な事実から始め、新しい詳細によってその後の展開に制約が生じるたびに台帳を拡張していくとよいでしょう。