第11章　Vaultの生涯：逆流と運用サイクル

検証を終えたVaultが下流作業へ渡ると、それを基に短編が書かれ、キャラクターシートの作業が進みます。一度作ったVaultは、そこで役目を終えるのでしょうか。

いいえ。答えは、ライブラリング運用の最も重要な原則の一つから導かれます。

「完成」という概念そのものの誤り

「Vaultの完成」という言葉には、完成したVaultがもう変わらない安定状態になるという前提が暗黙にあります。

しかしIPは変化します。新作が出て設定が修正され、新しい人物が登場し、既存の人物も新しい面を見せます。IPが生きている限り、その語彙もともに変わります。

Vaultを一度完成させれば終わりだと考えると、次のようなことが起きます。最初に手をかけて1,500個のファイルを作っても、二年の間に十本の新作が出たのにVaultが最初の状態のままです。執筆者は新しい語彙を探しても見つけられず、使えないVaultを使わなくなり、使われないVaultは更新する理由も失います。こうしてVaultは放置され、機能しなくなります。

Wikipediaを思い出すとよいでしょう。Wikipediaは一度も「完成」していません。英語版には毎日数百の新項目が生まれ、数万の既存項目が修正され、昨日の出来事が今日には項目になります。これが生きた文書です。

Vaultも同じく生きた文書です。完成して終わるのではなく、IPが生きている限りともに変わります。この認識の転換が第11章の出発点です。

逆流：執筆がVaultへ戻るサイクル

ライブラリングは基本的にIP文書からVaultへ情報が流れる仕組みです。第1段階の抽出が原文書からキーワードを取り出し、第2段階から第4段階を経てVault見出しとして完成します。

逆流（backflow）はその反対で、Vaultを使った短編執筆の過程で新たに作られた語彙がVaultへ戻る流れです。

この逆向きの流れが起こる理由を理解すれば、逆流は例外ではなく創作に自然に伴う副産物だと分かります。

既存のVaultを参照しながら、ミステリー世界観「ロージーホロウ」の「訂正」と「補正」を使って短編を書く場面を考えてみます。場面を書くうちに、既存設定にない概念が必要になり、執筆者は「逆読」という概念を新しく作ります。訂正が傷を消す際に残す、あまりに新しい痕跡を原案者が逆に読み、いま消されたものを復元する行為です。傷を消す訂正とは反対方向に、消されたものを読み戻す作業だと言えます。

この概念はこの短編で初めて登場するため、まだVaultにはありません。しかし同じIPの別作品でも使われる可能性は高い。ここで逆流が必要になります。

執筆者は簡単な定義と短編内での出典をメモに残し、そのメモは逆流キューに積まれます。次の増分実行でライブラリングはキューを確認し、新しい語彙を検討します。ここで即座に自動登録しないことが重要です。その語が本当にVaultへ入る見出しか、既存見出しの別名か、一つの短編だけで消える一時表現かを、まず人が判断します。登録を決めた項目だけを第2段階CSVへ加え、世界観軸が許容値内かを確認します。次に第3段階の骨格ビルドを増分で実行して新しい.mdファイルを生成し、第4段階で叙述を入れ、逆流キューには登録完了時点を残します。

執筆で新語彙を見つけてVaultへ登録し、次の執筆でまた参照する。この循環が止まらないとき、Vaultは生きた辞書へ育ちます。

逆流の実用的な運用

執筆者が短編を書いていると、Vaultにない用語を使うことはよくあります。そのときは二つの方法から選びます。一つは即時登録で、執筆を少し止めて用語をすぐVaultへ加える方法です。もう一つは逆流キューに積む方法で、執筆を止めず、新語を見つけたというメモだけを残し、短編が終わってからキューをまとめて処理します。新語が短編の核となる概念なら即時登録がよく、周辺語彙が初めて出ただけならキューに置いて後で処理して構いません。即時登録しておけば、同じ短編でその語を再び使う際に、すぐVaultを参照できる利点もあります。

逆流をまったく行わなければ、Vaultはいずれ機能を止めます。逆流なしに執筆だけを続けると、Vaultと執筆の隔たりは広がり、ある時点で執筆に使う語彙がVaultで見つからなくなります。するとVaultは役に立たないという認識が定着し、執筆者は参照しなくなります。

だからといって逆流を厳格にしすぎるのも現実的ではありません。単語一つを書くたびに執筆を止めてVaultを更新すれば流れが切れます。逆流が執筆の負担になってはなりません。短編一本が終わるたびに逆流キューを処理するリズムが、実務上の均衡です。

増分更新：変更された部分だけを再処理する

IPを運用して新資料が追加・修正されれば、ライブラリングを再実行する必要があります。しかし全体を最初から回せば、最初のサイクルにかかった9〜16時間がまた必要になり、毎回そうするのは明らかに非効率です。

ソフトウェア開発のバージョン管理（git）はよい比較になります。コードを修正したとき、全体を再ビルドせず変更ファイルだけを再コンパイルし、変更していないファイルには以前のビルド結果を使います。これが全体ビルドよりずっと速い増分ビルドです。

ライブラリングの増分更新も同じ原理で、変更部分だけを再処理します。新しい短編一本が入った場合の流れは次のとおりです。

新しい短編ファイルだけを第1段階で抽出します。 既存の第1段階CSVに新しい行を加え、既存行には触れません。
第2段階の統合を全体で再実行します。 新しい行は既存見出しに吸収されるか、新しい見出しになります。この過程で既存見出しの異称、別名、関連キーワードが補強されることもあります。
第3段階の骨格ビルドを増分で実行します。 新しい見出しの.mdファイルだけを作ります。既存ファイルは冪等規則に従いfrontmatterと本文だけを更新し、LLMブロックを保存します。
第4段階の叙述執筆を増分で実行します。 新しく生成されたファイルのLLMブロックだけを満たします。

短編一本で新たに生まれる見出しは、通常30〜50個です。この規模の増分更新は1.5〜2時間で済み、全体再実行のおよそ8分の1から10分の1です。

既存LLM叙述が保存される理由：冪等規則の長期的価値

第7章で扱った冪等更新規則は、骨格ビルドを再実行してもfrontmatter、定義、詳細は更新し、人が満たしたLLM叙述ブロックには触れず保存する規則です。二年間に短編50本と増分更新50回があったとしても、二年前の第4段階で書いた叙述から最近書いたものまで、一行も失われず残ります。この規則がなければ、二年の執筆作業は50回の再ビルドのどこかで消える可能性がありました。

ただし第2段階CSVの定義や詳細が変わると、frontmatterと本文は新情報に変わってもLLM叙述は旧情報を参照したままの場合があります。見つけたら全消去ではなく既存叙述を参照し、変化部分だけを増分で書き直します。公式英語名だけの変更ならP2ですが、概念の核が変われば叙述全体の書き直しが必要なP1です。

再構成：より大きな範囲の更新

逆流と増分更新が日常運用なら、再構成は不定期の大規模更新です。一つは世界観軸の再設計です。IPが想定外の方向に拡張し、既存の軸で分類できない語が積み重なったら、プロファイリングをやり直し、軸と全見出しの分類を更新します。必要な信号を見たら早く処理するほど、誤分類と再分類コストの累積を防げます。

もう一つは命名方針の変更です。代表キーワードが韓国語・英語・混用で不統一なら、第2段階CSVで一括修正し、第3段階骨格ビルドを再実行します。LLMブロックは冪等規則で保存されます。

再構成では旧見出しを削除せず、版状態を変えて保存します。新設定の見出しは現行、作品には残る旧設定は過去版、完全に無効なものだけを廃棄とします。改名時も旧ファイルをすぐ消さず隔離し、LLMとメモを新見出しへ移すか確認します。名前が変わっても、蓄積した叙述と判断は作業資産だからです。

運用サイクルの周期

増分更新の頻度はIPの形によって異なります。短編プロジェクトなら短編完成ごとに更新します。十本をためてから処理すると逆流キューが大きくなり、新語彙が長くVaultにないままになります。長編原稿やゲームなら、章の完成またはパッチのリリースごとが適切です。定期更新のIPなら、たとえば毎月第一月曜日を増分更新日にして、Vaultを常に最新に近い状態へ保ちます。

Vaultの更新が「時間ができたらやろう」になる瞬間、Vaultは放置され始めます。 短編完成、章完成、パッチ公開のようなIPイベントへ更新を自動的に結び付けることが最も安全です。

10年運用したVaultはどう見えるか

運用サイクルがよく働けば、最初の1,500見出しは新作から逆流した語彙によって3,000〜5,000へ増えます。後年の作品で頻繁に引用されたことで、当初hubではなかった見出しがhubへ昇格することもあります。

LLM叙述には十年前のものと最近のものが混じりますが、冪等規則により古い叙述も再ビルドで消えずに残ります。それらを通して読めば、このIPが長年どんな声で世界を語ってきたかが現れます。これはライブラリングが作るIPの記憶の保管所であり、一つのIPの十年が一つのフォルダに収まっている状態です。

Vaultを生かし続けること

Vaultを初めて作ることより、生かし続けることのほうが難しい場合があります。六か月後にも逆流キューを処理し、増分更新を実行するには、それが付随作業ではなくIP創作と運用の自然な一部にならなければなりません。

第12章ではVaultの出口を扱います。ライブラリングが作ったVaultを次の作業がどう使い、IP生態系でどんな役割を果たすかを見ます。

第11章 Vaultの生涯：逆流と運用サイクル