第12章　Vaultの出口：次の仕事が受け取るもの

検証を終えたVaultは出口側の作業へ進みます。1,500の見出し語が集まり、それらを結ぶwikilinkが張られ、9分類と世界観軸という二つの座標系の上に、各見出し語の叙述が満たされています。

ここから出る出口は四つです。短編執筆、キャラクタービルド、多言語刊行、百科事典・ロアブック制作です。この四つの作業はそれぞれVaultを入力として受け取り、何かを作り出します。後で扱うB2Bは出口ではありません。複数のチームが同じVaultを前に更新権限を分ける運用環境なので、四つの出口とは分けて考えます。

Vaultがなければ何が起きるか

長くIPを運営してきたチームには、似た経験があります。

「この人物名は、ある所ではカン・ミンジ、別の所ではカン・ミンソになっている。どちらが正しいのだろう？」

「この装置の制約条件は何だったっけ。ルールブック第3版のどこかにあったはずだが……」

「昨年この設定を変えたけれど、翻訳チームに知らせただろうか。翻訳原稿にはまだ旧版の名前が使われている。」

「新しい編集者が入ったが、世界観を学ぶのに一か月はかかりそうだ。」

これらの問題はすべて一つの原因から生じます。情報が複数の場所に分散し、どれが現在の公式情報なのかを確認する単一の出所がないことです。

情報分散のコストは、考える以上に大きいものです。チーム員5人がそれぞれ週に1時間ずつ「この設定で正しいか」を確かめるなら、1年で260時間の確認コストが積み上がります。その確認を経ても誤った情報を含む原稿が出れば、差し戻して直すコストまで続きます。

Vaultは、すべての情報の公式版を一か所に集めることでこの問題を解きます。確認が必要ならVaultを開けばよいのです。

単一の真実の供給源：借りてきて、より難しくなった概念

単一の真実の供給源（Single Source of Truth、SSOT）という概念はソフトウェア工学から来ました。しかし、IPがこの概念をそのまま持ち込むとは言いません。借りてはいますが、より難しい問題の中へ置いたのです。

ソフトウェアのSSOTは比較的解きやすいものです。コードは一組であり、その一組が真実です。同じ関数が同時に二つの真実を持つことはできず、どの値が正しいかを争えば、実行されるコードが答えを決めます。真実が一つだけだから、SSOTは自然に成り立ちます。

IPのSSOTはそうではありません。小説、ゲーム、ドラマがそれぞれ別の系統へ分かれる『ウィッチャー』のようなIPでは、正史は一つではありません。分かれた複数の正史について、どの系統がどの作業にとっての真実なのかを取り落とさず、一か所で同時に管理しなければなりません。コードは一組なのでこの問題を経験しませんが、IPのVaultは複数の連続性を並べて抱えながらSSOTの役割を果たす必要があります。結局、ソフトウェアが解く必要のなかった問題をIPのSSOTが引き受けるのです。

原理そのものはIPより古くあります。法律事務所が一件を扱う時、全チーム員が共有する一つの事件ファイルを公式記録とします。誰かがこのファイルを脇へ置き、自分のメモだけで仕事をすれば誤りが起きるため、全員が同じファイルを見ること自体が原則です。

学術研究チームがデータを一つの共有リポジトリに置くのも同じ理屈です。メンバーが同じデータを複製して別々に保管すれば複製の間に不一致が生じ、「バージョン2」「最終版」「最終最終版」がすべて異なるファイルになってしまいます。このとき、共有リポジトリ一つだけを「本物」と認める約束がSSOTです。

Wikipediaは、公開知識のSSOTを目標にして作られたプロジェクトでもあります。「カン・ミンジ」という名前が公式かを知りたければ「Wikipediaにはどう載っているか」を確認するように、IPの設定を確かめる時に「Vaultにはどう載っているか」を最初に見るのがLibraryingの運用です。

一冊のよく整理されたIP辞典が複数メディアの共通入力になる姿は、実際のコンテンツにも見られます。『俺だけレベルアップな件』は2016年のウェブ小説から始まり、ウェブトゥーンへ続き、2024年にはアニメーションとNetmarbleのモバイルゲーム、さらにスピンオフのウェブトゥーンへと、同じ世界を共有したままメディアを広げました。私はこれを、一つの整理された世界観がウェブ小説、ウェブトゥーン、アニメーション、ゲームという異なる作業の共通入力値になった例として読みます。

ただし、メディアが増えれば全員が同じ系統を共有するわけではありません。先に挙げた『ウィッチャー』がその例で、ポーランドの小説からCD ProjektのゲームとNetflixのドラマへ広がる間、ゲームとドラマは原作と別の系統へ枝分かれしました。このようなIPでSSOTは一つの真実を強制する装置ではありません。分かれた系統があるなら、その系統間の関係と各系統の正史の範囲までVaultに明記して、初めてSSOTとして機能します。

VaultがSSOTになる具体的な仕組み

Vaultが単一の真実の供給源になるには、二つの条件が必要です。すべての公式語彙がVaultにあること、変更がVaultで起きることです。

まず、IPで使う語彙のうちVaultにないものが一つでもあれば、その語彙についてVaultはSSOTの役割を果たせません。第1次抽出で十分に広く集め、逆流で継続的に補強する理由はここにあります。Vaultのカバレッジが高いほど、SSOTとしての役割も強くなります。

変更がVaultで起きるとは、こういう意味です。チーム員が原稿の人物名を変えたい時、原稿に手を入れる前に、まずVaultの代表キーワードを変えなければなりません。Vaultを先に直せば、その変更がwikilinkを通ってVault全体へ伝播するからです。「カン・ミンジ」を「カン・ミンソ」に変えた瞬間、Vault内で [[カン・ミンジ]] とつながれたすべてのファイルのリンクは [[カン・ミンソ]] に更新されます。反対に原稿を先に変え、Vaultを後で変えるか、まったく変えなければ、Vaultと原稿の間に不一致が生じます。これがSSOT崩壊の始まりです。

ただし、刊行済みのロアブックや公式百科事典があるIPには、もう一つの階層が加わります。刊行物は読者に公開された公式テキストなので、その本文はVaultの作業用叙述より優先されます。この場合Vaultは刊行物を押しのける上位の真実源ではなく、刊行物と同期して次の作業を準備する作業資料の中心になります。Vaultと刊行ロアブック本文が衝突すれば、刊行本文を基準にVaultを更新しなければなりません。LibraryingのSSOTは「何であっても永遠にVaultが勝つ」という意味ではありません。現在の作業段階でどの資料が基準なのかを明確にし、その基準をVaultに反映して、全員が同じ資料を見るようにするという意味です。

短編執筆ツールでVaultを活用する方法

短編、小説、シナリオを書くための作業ツールは、Vaultを三つの方法で使います。世界観語彙の参照、一貫性検査、カバレッジ分析です。

世界観語彙の参照とは、執筆中に特定の設定を再確認する必要が生じた時にVaultを開くことです。たとえば「この装置の制約条件は何だったか」という疑問が出たら、その答えをVaultで探します。第9章で構造化セクション（制約条件と確定事実）を丁寧に作るように述べた理由はここにあります。このセクションは執筆ツールがプログラムから読むことも、執筆者が直接読むこともあります。

織物世界観「ヌビの地」で「織り直し」が登場する場面を書くとします。ヌビを織り直して歴史と法を変えるには何が必要か、誰がその権限を持つか、織り直された偽りを誰が見抜くかは、すべてVaultに整理されています。執筆者は場面を書き進める途中にVaultを開き、この情報をすぐ確認できます。Vaultがなければ、古い原稿を一つずつ探すか、記憶に頼るしかありません。

一貫性検査は、書き終えた原稿でVaultの語彙とは異なる表記を探すことです。代表キーワードと別名がすべてVaultに登録されていれば、検査ツールが原稿中の表記を見つけます。たとえば「カン・ミンジ」と「カン・ミンソ」が両方出た場合、どちらがVaultの公式表記かを示します。Vaultにない新しい表記が見つかれば逆流キューへ上がるので、執筆者が新しく作った語彙を自動追跡する仕組みにもなります。

カバレッジ分析は、Vaultのどの見出し語が執筆済み短編でどの程度活用されているかを見ることです。まだ原稿に登場していないhub見出し語があれば、その見出し語を中心に新しい短編を企画する余地が見えます。この意味でVaultは「まだ書かれていない物語の地図」でもあります。

キャラクタービルド作業でVaultを活用する方法

キャラクターシートを作る作業ツールは、Vaultから二種類の情報を受け取ります。世界観キーワードの参照と、人物関係地図の参照です。

新しいキャラクターを作る時は、そのキャラクターが属する世界観軸の見出し語をVaultから取ってきます。たとえば織りの記録世界観軸のキャラクターなら、その軸の装置、概念、価値の見出し語が背景をなし、キャラクターシートの「世界観キーワード」欄を自動で満たします。新しいキャラクターがこの世界にどれだけ自然に入り込めるかは、そのキャラクターを説明する際にVaultの見出し語をどれほど活用できるかで測れます。Vaultの語彙では説明できないキャラクターは、その分だけこのIP世界で異質な存在です。

氏族、織り、階級を扱うIPで、「無紋者」という新キャラクターを作るとします。模様を読めも織れもしないのに、ただ裸の記憶だけで氏族のすべてを見通している人物です。

Vaultからこの人物の背景を形作る見出し語を出すと、織り軸から [[ヌビ]]、[[模様]]、[[織り直し]] が、記憶軸から [[裸の記憶]]、[[焚書]]、[[無紋者]] が出てきます。さらに人物関係として、模様を読み織る者 [[織女（人物）]] も一緒に現れます。

こうして集まった見出し語がキャラクターシートの「世界観キーワード」欄に入ります。作成者がVaultを直接探さなくても、織り軸と記憶軸の交差する見出し語が候補として自動提示されるのです。Vaultなしに同じキャラクターを作るなら、作成者はIP原典を読み直しながら世界観語彙を手で集める必要があります。

人物関係地図の参照も同じです。既存人物の見出し語にある related フィールドと構造化セクションの「関連人物」を見れば、人物間の関係網が一目で分かります。新キャラクターをこの関係網のどこに加えるか、師弟、ライバル、家族、同僚といったどの関係にするかを、その網をたどって決めます。Vaultがなければ、既存人物の関係を頭の中で一つずつ描きながら作業しなければなりません。

多言語刊行作業でVaultを活用する方法

IPを他の言語で刊行するには翻訳が必要で、この時Vaultの翻訳関連カラムが中核資料になります。

各見出し語の英語名カラム、ローマ字カラム、翻訳ノートカラムこそ翻訳者が最初に開く資料です。第5章で説明した「未来の翻訳者へ送る手紙」が、まさにこの翻訳ノートです。

翻訳者が原稿で「無紋者」という語彙に出会い、英語へどう移すか判断しなければならない場面を考えてみます。Vaultの「無紋者」見出し語を開くと、次のように書かれています。

英語名: Munmunja (the unwoven) 翻訳ノート: 「無紋者（無紋者）」は、すべての知識を布に織り込むこの世界で、模様を読めも織れもしない者を指す複合概念であり、直訳はできません。単に “illiterate” と訳すと、布に織られた文字を読めないというこの世界固有の含意が失われます。一度 “Munmunja (the unwoven)” と定義した後は、原語を併記せず “Munmunja” と書きます。原稿内の初出時だけ括弧による解説を付けます。

翻訳者がこの決定に従えば、このIPのすべての翻訳者が「無紋者」を同じ方法で訳せます。Vaultがなければ翻訳者ごとにこの判断を独立して行うため、ある人は “Munmunja”、別の人は “the unwoven”、また別の人は “illiterate” と訳し、同じIPの英語版第1巻と第2巻で同じ語彙の訳が異なる問題が起きます。

異称・別称カラムも翻訳では同じように重要です。原文に「織り直し」「ヌビ偽造」「再び織る」がすべて登場する時、この三つが実は同じものを指すとVaultが教えてくれます。翻訳者は三つを一つの訳語に統一するか、それぞれ異なる訳語を使うかを判断できます。別名情報がなければ、翻訳者は「再び織る」に初めて出会った時、それが既出の概念だと気付けません。

翻訳が終わると、その過程で下した翻訳判断がVaultへ逆流します。「この語彙は特定の訳語に確定する」という決定が翻訳ノートに記録され、次の翻訳作業でそのまま再利用されます。

翻訳産業では、このような資料は用語データベース、すなわちtermbaseに近いものです。ITSのような国際化・ローカライゼーション体系が、どの文字列を翻訳すべきか、どの用語が特定の意味を持つか、翻訳者にどのノートを見せるべきかを分けて示すのも同じ理由です。翻訳者は単語だけでなく、その単語をどの条件でどう扱うべきかまで受け取らなければなりません。

LibraryingのVaultが翻訳チームに渡せる情報も、まさにこれです。ある固有名は翻訳せず原語のまま置くべきであり、ある用語は初出時だけ括弧の解説を付けるべきであり、ある別名は同じ見出し語を指しても場面により意図的に違う訳にすべきです。この情報が翻訳ノートにあれば、翻訳者は毎回あらためて判断せず、IPがすでに下した決定を引き継げます。

したがって多言語刊行においてVaultは、単なる参考資料ではなく、承認された用語決定を保存する運用資料です。原文表記、公式訳名、禁止表記、原語併記の有無、初出時の解説、文化的注意事項を一つの見出し語の中で共に管理する時、翻訳の一貫性は個人の記憶ではなく資料構造に支えられます。

百科事典・ロアブック制作でVaultを活用する方法

IPの公式百科事典やロアブックを作る時、Vaultはそのまま原資料になります。

Vaultの1,500見出し語は百科事典の1,500項目となり、第4段階で書いたLLM叙述がその項目の本文になります。hub見出し語の叙述を最初から百科事典項目の水準で書いていれば、ほとんど手を入れずに項目へ移せます。

Vaultから百科事典へ移す際に追加で必要なのは、編集と配列だけです。読者がどの順で読むかを考えた配列、画像と図表の追加、出版フォーマットの編集がこれに当たります。これらにかかる時間は、Vaultがない場合の百科事典制作全体と比べればはるかに短くなります。Vaultがあれば「どの項目をどう書くか」がすでに決まった状態で出版作業に入れるからです。

百科事典・ロアブック制作がLibrarying後にどれほど変わるかを実際に経験した制作者は、こう言います。「以前は百科事典一冊を作るのに数か月かかりましたが、Vaultがあれば編集とデザインだけに集中できます。」

B2B環境におけるVaultの役割

四つの出口を見たので、ここからは運用環境の話に移ります。B2BはVaultが何かを作り出す出口ではなく、複数チームが同じVaultを置き、更新権限を分ける環境です。ここでVaultはチーム間の共有資料として使われます。

IP開発チーム、翻訳チーム、ゲーム開発チーム、出版チームが同じIPを扱うとします。IP開発チームが設定を更新すれば、他のチームは即座にその変更を知る必要があります。Vaultがなければ更新はメール、文書、会議を経て伝わるため、受け取るチームと見落とすチームが出ます。Vaultがあれば、更新された瞬間にすべてのチームが同じ最新情報を手にします。

この環境で鍵になるのは更新権限です。どのチームがVaultを更新し、その更新を他チームがいつ受け取るかという流れを、あらかじめ決めておかなければなりません。

一般的な構造では、IP開発チームがLibrarying担当チームを兼ねます。IPの公式設定変更はこのチームがVaultへ反映します。他チームはVaultを読めますが直接は修正せず、修正が必要ならLibrarying担当チームへ依頼します。

この構造がなければ、複数チームがVaultをそれぞれ変更してVaultがチームごとに分かれ、結局SSOTがチーム数だけ生まれてしまいます。

ここには別の保守層も加わります。インデックスを作ること、どの見出し語が十分使われたかカバレッジを確認すること、どのhubが他の見出し語に大きく影響するかを定期的に見ることは、短編執筆や翻訳のような出口作業とは異なります。これはVaultを長く使うための運用作業です。自動化があればインデックス、カバレッジ、影響力のスナップショットを定期作成し、未整備なら担当者が手動でも状態を記録しなければなりません。

長期的にはこのVaultを、より構造化された知識ベースへ移すこともあります。Wikibaseのようなツールは、多くの人が構造化情報を協働で修正し、人と機械が共に再利用できるようにする点で強みがあります。Obsidian Vaultが人にとって読み書きしやすい作業場なら、Wikibase式知識ベースはクエリ、再利用、公開連携により近い運用場です。

最初からその段階に行く必要はありません。創作チームが今必要とするのは完成したデータベースではなく、今日使えるVaultだからです。ただしfrontmatter、manifest、見出し語関係を一定に保てば、後で一部資料を知識グラフやデータベースに移す道が開きます。Libraryingはこの可能性を残したまま、まず人が実際に運用できる形から始めます。

Vaultがある時とない時

VaultがあるIP運用と、ないIP運用を並べて比べてみましょう。

Vaultがない時、設定を一つ確認するにも原典文書を探さなければならず、その場所さえ記憶が曖昧です。同じ概念が原稿ごとに異なる表記で使われ、新しいチーム員が世界観をつかむには1〜3か月かかります。翻訳者は同じ語彙をそれぞれ違って訳し、百科事典を作るには原典を最初から読み直して項目を新たに書かなければなりません。5年後に原作者ではない人がIPを引き受けた時には、世界観の相当部分が執筆者の頭の中だけに残り、引き継ぎそのものが詰まります。

Vaultがある時は事情が異なります。設定確認はObsidianを開いて検索すれば終わり、見出し語ごとに公式表記が一つに定まり、別名もすべて登録されています。新しいチーム員はhubを100個読めばIPの核心をつかめ、翻訳者は翻訳ノートに従って統一された翻訳決定を引き継ぎ、百科事典制作は編集とデザインだけに集中できます。5年後にIPを新しく担当するチームもVaultを開けば世界観を最初から把握できます。

Vaultは出発点である

Vaultは終着点ではなく出発点です。Libraryingが作ったVaultから短編執筆が始まり、キャラクターシートが作られ、翻訳作業が進みます。そして、それらの作業から生じた新しい語彙と決定が、再び逆流によってVaultへ戻ります。単一の真実の供給源とは、結局、すべてのチーム、すべての作業、すべてのツールが同じ一つのVaultを見ているという意味です。

第13章は実践の回顧です。1,500個を直接形作りながら学んだこと、予想と異なった点、そしてもう一度するなら何を変えるかを率直に収めます。

第12章 Vaultの出口：次の仕事が受け取るもの