MEJE PROCESS · MEJE ライブラリング・ワークフロー白書 (21 章)
第1章.グロッサリーからクラウドへ:私たちが扱う資料の変化
第1章.グロッサリーからクラウドへ:私たちが扱う資料の変化
スター・ウォーズを一語で説明することは不可能です。
「宇宙を背景にした善悪の対決」と言った瞬間、肝心な何かが抜け落ちます。まずフォースが抜けます。フォースのないスター・ウォーズは、スター・ウォーズと呼びにくい。しかしフォースを入れるとジェダイ騎士団が自然についてきて、ジェダイを入れるとライトセーバーが、ライトセーバーを入れるとダース・ベイダーが、ダース・ベイダーを入れると「私はお前の父だ」というあの台詞が次々についてきます。
反乱同盟軍と銀河帝国があり、デス・スターとミレニアム・ファルコンがあります。これらは別々に離れて存在するのではなく、互いにかみ合っています。ジェダイとダース・ベイダーがつながり、フォースとライトセーバーがつながり、反乱同盟軍と銀河帝国がつながります。
スター・ウォーズは、この関係網全体です。 一つの単語ではなく、その単語たちが編まれている関係網こそがスター・ウォーズです。
読者のIPも同じです。小説でもゲームでもウェブトゥーンでもルールブックでも、一つのIPを一語で説明すれば嘘になってしまいます。そのIPを構成するすべての単語が、互いにどうつながっているか。それこそがIPです。
ライブラリングと呼ぶ作業は、この関係網を意図的に築く仕事です。創作者の頭の中だけに生きていた関係網を取り出し、目で見て手で触れられる資料にする仕事であり、本書はその仕事を十四章にわたって案内します。
資料がつながっていないということ
一つのIPを五年ほど運営してきた人の机は、たいていこんな姿です。
ルールブックがあれば七冊ほど積まれているでしょう。本編は第一版、第二版、第三版に分かれ、その間に補助資料集が二冊ほど挟まり、一度全面改訂しようとしてやめた第零版が一冊残っている、といった具合です。短編が蓄積していればフォルダには軽く百編を超え、外部ウィキも片方のモニターに開かれています。五年前に誰かが始めて手が止まったページが千近く積まれていても、生きているページは二百にも満たず、企画書フォルダを開けば同じ名前のファイルが版を変えて三十枚ほど入っています。v1.0、v1.1、v1.1_修正、v1.2_最終、v1.2_最終_再最終、といった名前で。
こんな机の前で新しい短編を書こうとすると、すぐに細かな質問に足を取られます。三年前のルールブックに出たあの人物の名前は何だったか、その人物の所属勢力は企画書のどこに書かれていたか、その勢力と敵対する集団はどの短編で初めて登場したか。思い出さなければなりませんが、答えるには七冊のルールブックと百編の短編を一つずつ探るほかありません。検索ができず、リンクがなく、同じ単語がどの資料にも一貫して整理されていないからです。
結局、作者は似た名前の新しい人物を作るか、設定を少し変えて既存人物として使うか、あるいはそのまま通り過ぎます。その間にIPの中には小さな矛盾が積もり始めます。一人の人物が二つの名前を持ち、一つの事件の日付が二冊で食い違い、一つの場所の描写が前編と後編で変わります。IPが大きくなるほど、この矛盾の量も一緒に膨らみます。
これが資料が散らばる問題の実体です。用語がないために起こる問題ではなく、関係がないために起こる問題です。
古い問題
この問題は新しいものではありません。トールキンは数十年にわたり手書きの膨大なノートを残しましたが、資料が体系的に管理されなかったため、死後に息子クリストファーがそれを整理するのに再び数十年を要しました。フランク・ハーバートの『デューン』世界観も、息子がシリーズを継ぐ際、再構成に少なからぬ困難を抱えました。
ウェブ小説とウェブトゥーンの時代になると、この問題ははるかに大きな規模で表面化します。数百話を連載するあいだ、数十人の人物と数百の固有用語を一貫して管理しなければなりません。ファンが先にウィキを作ってくれることはありますが、それはあくまで読者の資料であり、作者の内部資料にはなりません。読者の解釈や誤読が混じり込むうえ、何より作者が次の話を書く際にそばに置いて参照する道具として機能しないからです。
一つのIPの資料が一か所に整理されていない。 この問題は今も解かれないまま残っています。
グロッサリーという最初の答え
この問題への最初の答えは、グロッサリー、すなわち用語集です。一つの作品に登場する固有名詞、専門用語、世界観キーワードを順に並べ、各項目の横に短い定義を付けた一枚の表がグロッサリーです。
グロッサリーを作る作業方式自体は誰にとってもなじみがあります。作品を始めると作者ノートの片隅にグロッサリーページを別に置き、新しい語が登場するたびに一行ずつ加えていく方式です。一つの作品の枠内だけを見れば、この方式は十分に効率的です。グロッサリーを開くだけで、どの人物が抜けていてどの機構がまだ定義されずに残っているかを一目で確かめられるからです。
しかし作品が二つになった瞬間、景色が変わり始めます。第二作の新しい項目を第一作のグロッサリーへ加えなければなりませんが、その中には第一作ですでに一行だけ言及された人物がいるかもしれず、同じ人物か別の人物かを先に決めなければなりません。同じ人物だと判断したなら、第一作の一行を第二作の情報で補強しなければならず、作品が五作、十作と増えると、このような決定の量は爆発的に増えます。
グロッサリーが失敗する理由は、単に量が多いからではありません。リストという形式そのものが、IP知識の性格と構造的に合わないからです。
リスト形式には二つの欠陥があります。
第一に、項目と項目の間の関係を収められません。 一人の人物がどの場所で生まれ、どの事件でどんな役割をしたかという関係は、「関連:A、B、C」と書いておくことはできます。しかし、そのA、B、Cがそれぞれどんな項目かを確認するには、またリストを初めからめくらなければなりません。関係が保存されていても、その関係をたどって移動しにくいのです。
これが重要なのは、IP知識の核心が事実ではなく関係にあるためです。「ある人物がある名前を持つ」という事実より、「その人物がこの事件であの人物と、なぜ衝突したか」の方がはるかに重要な情報です。関係を楽にたどれない資料形式は、まさにその核心を表すところで限界を見せます。
第二に、リストは一方向です。 人物Aの項目に「関連:場所B、事件C」と書いても、場所Bの項目へ行ったとき「この場所に関連する人物:A、D、E」という逆方向の情報は自動で現れません。逆方向の情報を保つには、人物Aと場所Bの両方に同じ内容を手で書かなければならず、項目が増えるほど、この手作業の管理は非現実的になります。
実作業でこの二つの欠陥がどう現れるかを見てみましょう。あるIPで「ハンスフォード牧師館」という場所を修正する必要が生じ、グロッサリーでその項目を探して直したとします。しかし、ハンスフォード牧師館で起きた事件、その牧師館を背景にした場面、その牧師館が登場する人物の物語まで探して一貫性を合わせるには、結局グロッサリー全体を初めから読み直すほかありません。項目同士に接続がないからです。
接続がなければ、一方を直したとき、その変化が他方にどんな影響を与えたかを確認しにくくなります。これがIPが大きくなるほど作者が経験するもどかしさの構造的原因です。
関係を収める形式
グロッサリーの失敗から始まる代案は、項目と項目を直接つなごうという発想です。
百科事典を開くと「→参照:項目名」のような表記が付いていますが、このように項目を直接つなぐ発想自体は、実はかなり古いものです。読者がAを読みながらBへ移り、さらにBからCへ移る連鎖を、紙の百科事典もそれなりの方法で実現しようとしてきました。
この発想を完全に実現したのがインターネットです。ワールドワイドウェブの核心アイデアは文書と文書をリンクでつなぐことであり、ウィキペディアはそのアイデアを百科事典形式へ適用した結果です。「ナポレオン戦争」を読んで「トラファルガーの海戦」をクリックし、さらに「ネルソン提督」へ移る連鎖が可能です。どの項目にも「この文書を参照する文書」が表示され、逆方向の接続まで確認できます。
興味深いことに、人気IPは成長するほど、結局このようなリンクされた辞典の形に近づきます。私は『全知的な読者の視点から』をその例としてよく挙げます。原作ウェブ小説、ウェブトゥーン、映画がそれぞれ大きな項目に分かれ、リンクでつながり、一人の人物からその人物が属する事件や世界観設定へすぐ渡れます。人気韓国ウェブ小説も、結局は表題語同士がリンクされた辞典へ育つのです。ゲームの側では、『リーグ・オブ・レジェンド』の制作会社がUniverseという公式ロアサイトを直接運営し、チャンピオン一人から彼が属する地域と事件へすぐ移れるリンクされたカノン・データベースを備えています。
IP資料管理へこの発想を適用すると、次のような姿になります。一人の人物ページの中に、その人物が関わる事件、よく登場する場所、使う機構がすべてリンクでつながり、事件ページにはその事件に関わる他の人物が、場所ページにはその場所を背景にした事件が再びリンクで並ぶ姿です。
これがIPの資料をリストではなく網で管理する発想であり、この接続された網をキーワードクラウドと呼びます。グロッサリーが接続のないリストなら、キーワードクラウドはそのキーワードたちが互いにつながった関係網です。
ここではリンク自体が情報です。二つの項目の間にリンクがあることは、両者がIP内で何らかの形で関連するという編集者の判断を含んでいます。そのため接続密度の高い項目はIPの核心に、接続がほとんどない項目は周辺部に置かれます。リンクをたどると、IPの地形が自然に現れます。
グラフビューを初めて開いた日
この発想を実現する道具があります。Obsidianというノートツールです。
Obsidianは、ユーザーが作ったすべてのノートを一つの作業フォルダ内に .md ファイルの形で保管します。.mdはMarkdownという形式の拡張子で、平文テキストに軽い記号をいくつか加え、見出し、強調、リンクを示せるようにする形式です。Wordファイルのような重い形式ではなく、メモ帳でも開ける軽いテキストです。
Obsidianは、この.mdファイルを [[項目名]] という表記で自由につなげます。この表記を通常wikilinkと呼びます。wikilinkでつながった関係網を、Obsidianはグラフビューという画面で一度に展開して見せます。点が画面上に浮かび、その点の間に線がかかる図が現れます。
五年分の資料をObsidianへ移し、初めてグラフビューを開いた日がありました。
それまでは資料がどれほどあるかさえ見当がつきませんでした。グロッサリーに書かれた項目数は知っていましたが、その項目たちがどうつながるか、どの人物がこのIPの実際の中心にいて、どの人物が予想に反して周辺部にいるか、どの事件が最も多くの表題語とつながるか、どの概念がこの世界観を最も深く支えるかを知る術はありませんでした。
グラフビューを開くと、初めてこれらが見え始めました。IPのどの領域が密で、どの領域が空いているか。どの人物が思ったよりはるかに多くの表題語とつながり、どの人物が孤立しているか。グロッサリーではついに見えなかった資料の風景が、一目で目に入ってきました。
グロッサリーからクラウドへ移ったのは、まさにその瞬間でした。
ライブラリングという作業
一つのIPの資料をクラウドとして築くこの作業を、**〈ライブラリング〉**と呼びます。
ライブラリ(library)が図書館または辞典を意味するなら、ライブラリング(librarying)はその辞典を築く作業を動詞形にした言葉です。一つのIPの図書館を築くことを、ライブラリングと呼ぶのです。
この呼称には小さな意図があります。図書館が一度建てられて終わりではないように、ライブラリングも一度築いて終わる仕事ではありません。新しい本が入れば分類体系を見てどこに置くかを決め、書棚が埋まれば新しい書棚を入れ、分類が乱れればときどき整理します。図書館の運営と同じく、一つのIPのキーワードクラウドも生きて動く資料です。
図書館という比喩には、もう一つ意味があります。図書館は本をただ積んでおかず、分類し、決まった基準に従ってすべての本に番号を付け、位置を指定します。この分類がなければ図書館はただの倉庫であり、本がどれほど多くても見つけられなければ、ないのと変わりません。
ライブラリングも同じです。キーワードを積むことが目的ではなく、分類し、つなぎ、見つけられるようにすることが目的です。その目的へ向かう四段階の作業が、ライブラリングの本体です。
ウィキ作りではない
ここで誤解を一つ断っておきたいと思います。Obsidianでウィキを作る方法はすでに多く、検索すれば数十件が出てきます。しかしライブラリングは、そのウィキ作りではありません。違いは器ではなく、切り分け方にあります。
ライブラリングはキーワードを五十音順や登場順に並べず、物語的機能で分けます。この言葉は人物か、装置か、価値かをまず問うのです。その上にIPごとに異なるよう設計した世界観軸を交差させれば、『共同』で「協会と絡む人物表題語だけ」または「ダンジョンに付随する物体表題語だけ」といった二座標検索が可能になります。分類基準が一つだけの辞典にはできないことです。
そのため、成果物の位相が異なります。ファンウィキが読者の参照用で、メモアプリのVaultが個人の記憶補助なら、ライブラリングが築くVaultはプロデューサーがIP全体を運営する唯一の原本です。新しい短編も、新しいキャラクターも、外国語翻訳も、百科事典も、すべてこの一冊を通っていきます。器は同じObsidianでも、何をどう収めるかが違うのです。
人が読むグラフと機械が読むグラフ
この地点でライブラリングは、知識グラフというより大きな流れに触れます。ウィキデータとその基盤道具であるWikibaseを見ると、複数の人が同じ知識を協業で修正しつつ、その結果が機械も読める構造化データとして残ります。人は項目の名前と説明を読み、機械はその項目の属性と関係を読みます。同じ資料を人と機械が異なる方法で読むのです。
ライブラリングのVaultは、今すぐそのような構造化データベースを作ろうとする作業ではありません。Obsidianの.mdファイルは人が読みやすい側により近く、プロデューサーが創作の途中で直ちに開いて見られなければなりません。ただし、表題語、別称、9分類、世界観軸、関連キーワード、出典を一定のフィールドに分ける瞬間、このVaultも機械が読める知識グラフの性格を少しずつ持ち始めます。
だからライブラリングを「ウィキ作り」と呼べば小さくなり、「完成した知識グラフ・システム」と呼べば過剰になります。正確にはその間にあります。人の手に合うObsidian Vaultから始めながら、長期的には構造化データと知識グラフへ移れる形で、IPの関係網を整理する作業です。
4段階の流れ
ライブラリングの入力には、ルールブック、短編、企画書、外部ウィキ、台本のような散らばった文書がすべて入り、出力としてObsidianウィキが出ます。その間をつなぐのが、一次抽出、二次統合、三次骨格ビルド、四次叙述執筆という四段階です。
一次抽出は、すべての入力からキーワードを引き出す段階です。一つのルールブックに登場するすべての人物、場所、物、事件、装置、概念、価値を、九つの分類に従って漏れなく書き留めます。ただし重複は気にせず、同じ人物が別の表記で登場しても、いったんそのまま引き出します。一つのIPの一次抽出結果は、5,000行から15,000行に及ぶ巨大な表になります。
その表が二次統合へ入ると、同じ意味が一つの表題語にまとめられます。表題語とは、辞典の項目のようにキーワードが正式に登録された形です。たとえば「黒霧」「黒い煙」「Tenebre」という三表記を一つの表題語にまとめれば、その行には英語と韓国語、定義、関連キーワード、翻訳候補が整然と並びます。その結果、5,000〜15,000行が1,000〜2,000の表題語へ減ります。
表題語表が整うと、三次骨格ビルドはその表をObsidianの.mdファイル1,500個へ変換します。一つの表題語が一つの.mdファイルになり、そのファイルには定義、詳細説明、関連キーワードのwikilinkが入り、まだ文章が入っていない執筆空間が残ります。
最後の四次叙述執筆は、その執筆空間に各表題語の文章を書き入れます。一表題語あたりの分量は200字から1,000字です。現代ハンター物世界観の『共同』を例にすると、「濃度とはゲートから染み出したマナの密度である」という定義一行にとどまらず、その概念がこのIPの世界でどんな意味を持つかを一つの流れで解きます。1,500の執筆空間がこうした叙述で満たされて初めて、一つのIPのキーワードクラウドが完成します。
一次、二次、三次の本質が機械的な整理なら、四次の本質は執筆です。この二つの本質の違いが作業の性格を分け、まさにこの違いが本書で最も重要に扱う主題、AIの仕事仲間との協業の質感を決めます。
二つの手で築く作業
1,500個の.mdファイルを、一人の人がすべて築けるでしょうか。
可能です。ただし一人が手だけで引いていけば数か月かかります。手だけで作業していた時代には、一つのIPのライブラリングに半年近くかかりました。半年かかる作業は結局頻繁には行わなくなり、頻繁に行わなければ資料は更新されず、更新されない資料はついに死んだ資料になります。
ライブラリングを今のように定期的に運営できるようになった背景には、二つの変化があります。第一は手順の整理です。四段階の流れを立て、各段階の入力、出力、合格ラインをあらかじめ決めました。第二はAIの仕事仲間の導入です。
AIがなくてもライブラリングは動きます。 方法論自体はAIと無関係で、四段階のパイプラインも、九つの分類体系も、二座標軸の設計も、十三カラムの表題語構造もそうです。見慣れない用語が一度に出ましたが、今覚える必要はありません。第4章から第9章にかけて一つずつ解きます。ここで重要なのは、これらがAIの登場前にも手作業で実装できる方法であり、実際に長いあいだそうしてきた事実です。
ただし現在の運営型ワークフローは、AIの仕事仲間と自動化の契約を前提とします。人の手でも可能な方法を、反復可能な時間の中で、複数のIPへ再適用可能にしたものが現在のライブラリングです。AIは方法論を代替せず、その方法論を持続可能な運営時間の中へ引き込みます。
AIが担う仕事は具体的です。一次抽出の大量処理、同義語候補の抽出、四次叙述執筆の草稿作成がAIの担当であり、人が手でやれば数か月かかる仕事がAIとの協業なら一日か二日で終わります。
しかし決定的な判断は常に人の役目です。どの表記が同じ人物を指すか、表題語を何と命名するか、世界観軸をどう設計するか、執筆が合格ラインを超えたかを最後に決めるのは、AIではなく人です。
AIが1,500個を書くと言うと量産物のように聞こえますが、正確には逆です。プロデューサーが直接書いた代表hub数編が、残りの表題語の声を決めます。AIは手で、プロデューサーは声です。手が速いだけで、何をどんなトーンで書くかは声が決めます。
二つの役割が共に進むとき、その一日二日は実際には9〜16時間の作業です。正直、最初のサイクルはそれよりかかります。手になじむ前は予想の1.4倍ほどかかり、二、三回目のサイクルからこの範囲に落ち着きます。それでも半年が数日に縮んだことになります。
本書は各段階で、何を受け渡すか、なぜ委任するか、何が良くなるか、どこまでを人が直接決めるべきかを一行ずつ指します。「AIを使えばよい」という漠然とした勧めではなく、どこで人が止まり、どこで道具が始まるかを明瞭に区分して見せる文章です。
姉妹テキストとの関係
本書と共に続く姉妹テキストが二つあります。〈西燕閣〉と〈新規キャラクタービルド〉です。
〈西燕閣〉は外国語作品を深く読む作業を扱います。ジェイン・オースティンの『高慢と偏見』のような作品を一冊受け取り、翻訳と翻案へ入る前に人物、事件、世界観、言語を精密に分析し文書化する六段階の作業を、十四章にわたって解く文章です。〈新規キャラクタービルド〉は、ゼロから一人の人物を造形する作業を扱います。
本書は、二つの姉妹テキストが共に使う共通資料基盤を築く仕事を扱います。〈西燕閣〉が作品を深く読む仕事で、〈新規キャラクタービルド〉が人物を造形する仕事なら、〈ライブラリング〉はその深い読解と人物造形がすべて通過する一冊の辞典を築く仕事です。姉妹テキストをまだ読んでいなくても、本書は独立して追えます。
これからの流れ
十四章の流れをあらかじめ広げておきます。
第1章ではグロッサリーからクラウドへ、リストから網へ、一人から二つの手へ移る方向をつかみました。続いて第2章はプロデューサーとAIの仕事仲間の役割をさらに詳しく見つめ、第3章は四段階の流れの全貌を一度に広げます。
第4章から本格的な作業です。第4章で一次抽出の方法を、第5章で二次統合を、第6章で二つの分類基準である9分類と世界観軸を扱います。第7、8、9章はVaultの形に関する章です。第7章は三次骨格ビルドを、第8章はhubとleafの分類を扱います。本書のクライマックスである第9章は、プロデューサーが直接書いた代表hub数編が残りのトーンを決め、AIの仕事仲間がそのトーンで表題語を満たしていく四次叙述執筆の規格を、一章全体にわたって詳しく見つめます。
第10、11、12章は検証と運営を扱い、第13章は実戦の回顧、第14章は締めくくりの章です。
関係網へ戻りながら
最初のスター・ウォーズへ戻ります。
フォースとジェダイ、ライトセーバー、ダース・ベイダー、反乱同盟軍、銀河帝国が互いにどうつながるかが、すなわちスター・ウォーズです。この関係網はまずジョージ・ルーカスの頭の中にあり、その頭の中の関係網がルールブックになり、映画脚本になり、キャラクター設定集になりました。資料が十分に整理されていたため、スター・ウォーズは一世代が過ぎた後にも別のプロデューサーの手で一貫して生き続けます。
v1.2_最終_再最終がまだフォルダのどこかにあり、その関係網が一か所に整理されていない状態なら、十四章をすべて通ったあと初めて見えるものがあります。どの人物がこのIPの実際の中心にいるか、どの概念がこの世界観を最も深く支えているかが目に入ります。
その関係網を意図的に築く十四章を、今始めます。
© 2026 MEJE WORKS Corp. & 김동은WhtDrgon. All rights reserved.