ストーリーバイブルとは、創作の物語が保持すべき事実のための参照資料です。登場人物、関係性、ルール、場所、時系列、未解決の伏線などを整理します。AIで作成するには、自分のメモや関連する抜粋を用意し、構造化された項目を作るよう依頼して、提案されたあらゆる事実が「正典（canon）」になる前に必ず精査してください。作り出した提案は、すでに本文で確立している情報とは別に扱います。
役に立つ成果物は、必ずしも長大な文書である必要はありません。書きながら「この人物はその秘密を知っているのか？」「旅は1晩で起こせるのか？」「このルールはすでに変わっているのか？」といった問いに答えるための参照になります。以下のワークフローでは、それをXPTで構築し、その後原稿が育っていく中で参照として有用に保つ方法を示します。
XPTで参照を作る方法
1. 素材を集め、ステータスをラベル付けする
AI Novel Generator を開き、コンパクトなメモのセットを用意します。自分が受け入れた判断と、まだ検討中のアイデアを分けてください。既存の下書きがある場合は、提出する前に抜粋を章またはシーンごとにラベル付けします。
山の天文台を舞台にしたミステリーを想像してください。メモには「嵐の後に道路が閉鎖される」「望遠鏡ログが改ざんされている」「技術者のRowanは最後にコントロールルームに入った人物を知っている」と書いてあります。却下したアウトラインには「Rowanは嵐の前に去った」とあります。モデルに対して両方を同じだけ権威があるものとして提示しないでください。どちらが現在の下書きに属するのかを明確にします。
2. 拡張の前に抽出を依頼する
すでに文章があるなら、それに明確に裏付けられた事実を明示的に要求します。新しい世界設定のアイデアが欲しい場合は、別のセクションでそれを依頼してください。抽出と創作をラベルなしで混ぜてしまうと、各項目がどこから来たのか判別しにくくなります。
“提供されたメモを、作業用のストーリーバイブルに整理してください。前提、登場人物、関係性、設定ルール、タイムライン、未完のスレッド用のセクションを用意します。記載されている事実のみを抽出してください。重要な項目の横に、出典となる章またはメモのラベルを添えてください。推論や新しいアイデアは「Proposed Additions（提案の追加）」の下にまとめます。矛盾や不足している事実は、黙って訂正せず、質問として列挙してください。素材とラベル： [メモまたは関連抜粋を貼り付け].”
参照を生成し、いくつかの重要な項目について元の素材と突き合わせて確認します。人物の疑いが確定した知識になっているなら、今ここで正してください。この区別によって、会話全体がどれほど信じられるかが決まることがあります。
3. シーンに影響するセクションをレビューする
登場人物については、現在の目標、関係性、制約、知識を記録します。世界のルールについては、仕組みと例外を記録してください。タイムラインについては、出来事の順序と、行動を制約する間隔を追跡します。天文台の創設についての詳細が重要というより、「道路が通行不能になるのはいつか」を把握しているほうが重要です。
XPTに、読み取り（スキャン）しやすいほど参照を簡潔にするよう依頼しつつ、判断を支える詳細は残してください。文書が完成して見えるように、推測による空欄埋めをしてしまうのは避けます。
4. 受け入れたマスターコピーを保存する
レビューした資料を、自分が管理できるドキュメントに移します。版または改訂日をラベル付けし、提案の代替案は別の場所に保管してください。マスターコピーは、話を現在書いている「その物語」を表すべきで、話し合ったあらゆる方向性ではありません。
より深い登場人物の項目が必要になったら、その集中タスクに向けてAI Character Description Generator を使います。バイブルに追加する前に新しい提案をレビューしてください。別のツールに依頼したことが、その提案を自動的に受け入れ済みの歴史として認めさせるわけではありません。
5. シーンサマリーでバイブルをテストする
1つだけ計画しているシーンを選び、そのシーンが必要とする項目だけを抽出します。天文台なら、「閉鎖された道路」「Rowanの知識」「改ざんされたログ」「コントロールルームへアクセスできるのは誰か」が該当します。そうした事実を尊重するシーンプランを依頼し、結果に矛盾がないか検査してください。
もし、そのプランが道路の閉鎖を回避する新しい乗り物に依存しているなら、参照によってシーンの論理が解決したことにはなりません。都合の良い便利さは却下するか、前提を意図的に修正してください。複数の章をそこから下書きする前に、テストを使って参照を改善します。
事実・推論・アイデアをはっきり分けておく
| ラベル | そこにあるべきもの | 例 |
|---|---|---|
| Established | 受け入れた下書きに明記された事実 | Rowanは深夜0時前にコントロールルームに入った。 |
| Inferred | レビューが必要な、もっともらしい解釈 | Rowanは改ざんされたログを見たかもしれない。 |
| Proposed | 新しい創造的な選択肢 | ログには2つ目のタイムスタンプがある。 |
| Undecided | まだ決めていない質問 | 控室（コントロールルーム）の予備キーを持っているのは誰？ |
これらのラベルは、異なる書き方の判断を支えます。提案されたタイムスタンプは、あなたがそれを使うと決めるまで、第6章の手がかりになってはいけません。推論は、登場人物が確実に知っているものとして扱わなくても、役に立つままで構いません。
確認できる項目を書く
曖昧な人物像の要約より、具体的な断定と出典ラベルを好みましょう。「Rowanはシーン3で訪問者に鍵を渡すことを拒む」は、「Rowanは慎重だ」よりも検証しやすいです。解釈を入れることはできますが、観察された行動から切り分けてください。
下書きに矛盾する事実が含まれている場合は、両方の通路ラベル（パッセージラベル）と、解決するべき質問を記録します。どちらか「よりありそう」だと感じる方をモデルに選ばせないでください。その矛盾は、意図的な嘘、不確かな語り手、あるいはまだ反映しきれていない改訂を示しているかもしれません。
リライト後は章だけでなく更新する
改訂された移動時間は、タイムライン、アリバイ、メッセージ到着に影響します。数字を1か所だけ置き換えるのではなく、「影響を受ける項目」を依頼してください。次に、すでに書いたシーンがまだ成立するか確認します。
短い変更ログを残しましょう。古い事実、新しい事実、影響を受けるシーン、判断です。こうしておけば、「忘れた更新」と「意図的な矛盾」とを区別しやすくなります。比較のために明確に必要でない限り、使われなくなった詳細をコンテキストパケットに残さないでください。
よくあるストーリーバイブルの質問
短編には1つ必要ですか？ 多くの場合、小さな参照で十分です。名前、知識、物の場所、そして推測のルールのように、間違いの原因になり得る事実を追跡します。物語が必要とするときだけ拡張してください。
AIは完全な参照を覚えてくれますか？ 自動記憶に頼らないでください。新しい依頼では、関連する項目を提示し、応答が実際に何を使ったかをレビューしてください。受け入れ済みの事実については、自分自身で出典を管理しましょう。
バイブルはアウトラインの代わりになりますか？ いいえ。アウトラインは出来事の順序を計画し、バイブルは、その順序が尊重すべき事実を記録します。筋の良いプロジェクトなら、すべての段落を重複させることなく、両方を使えます。
メンテする最小の参照を作る
次のシーンに必要な事実から始め、不確実性は正直にラベル付けし、物語が変わったら受け入れ済みバージョンを更新します。使い続けるコンパクトな参照は、決して採用しなかった判断で埋め尽くされた大きな文書よりも、原稿をより良く支えてくれます。
