第7章　骨格ビルド──CSVがObsidianファイルになるまで

13列のCSVには1,000から2,000の見出し語が整然と並んでいますが、この表はまだファイルではありません。Obsidianの画面には何も表示されず、グラフビューもなく、サイドバーのファイル一覧も空で、IPの語彙全体は一枚のスプレッドシートにとどまっています。

この表を一つひとつのファイルへ変える作業が、第3段階の骨格ビルドです。表の一行が一ファイルになり、この段階を終えて初めてVaultが画面いっぱいに広がります。

構造と内容の分離という、古くからの原則

一冊の本が印刷所へ入る前、原稿を受け取った編集者は赤ペンで余白に印を付けます。「この見出しは14ポイントのゴシック体で」「この段落は字下げなしで」「この引用はイタリックで」といった具合です。ここで編集者が指定しているのは内容ではなく構造です。内容は著者の原文のままにして、その原文をどう配置し、どう表示するかだけを別に記録します。

これが構造と内容の分離、すなわち内容に手を加えなくてもデザインだけを変えられなければならないという原則です。同じ原稿を判型だけ変えて文庫として再版できるべきだ、ということでもあります。コンピュータの登場でこの原則はいっそう鮮明になりました。代表例が、Webページを組むHTMLとCSSの分業です。HTMLが「これは見出し、これは段落」と文章の骨組みを記述し、CSSが「見出しはこの大きさと色で、段落はこの間隔で」と見た目を決めます。したがって同じHTMLに別のCSSを当てれば、まったく異なる視覚的結果になります。データベースも同様で、スキーマはどの欄があるかという構造を定義し、データはその欄に実際に入る値です。

Wikipediaのインフォボックスはこの原理をもっとも日常的に示しています。どの人物記事を開いても、右上の箱には生年月日、国籍、職業、配偶者がいつも同じ場所に置かれています。人物情報枠という一つのテンプレートが構造を決め、各人物記事はその枠に自分のデータを入れるだけです。枠を少し直すだけで、それを使う何万ものページに一斉反映されます。これが可能なのも、構造と内容を分けているからです。

ライブラリングの第3段階の骨格ビルドは、まさにこの原則をObsidianファイルの中で実装します。Markdown（.md）ファイル上部のfrontmatterが構造を担い、下部の本文テキストが内容を担います。両者は明確に分かれ、それぞれ異なる役割を果たします。

決定的変換とは何か

第3章では、第3段階の骨格ビルドを「決定的自動化」と呼びました。第1次抽出はAIの仕事仲間が文書を読み、キーワードを取り出す段階なので、同じ文書を再抽出すると結果が少しずつ変わることがあります。第2次統合も、同義語候補を改めて絞り込めば、わずかに異なるまとまりになることがあります。二つの段階はいずれもAI特有の確率的な変数を抱えています。

第3段階の骨格ビルドは性格が異なります。13列CSVを受け取り、Markdownファイルへ変換する規則が明確に定められているからです。どの列をどのfrontmatterフィールドへ入れ、どの列を本文のどこへ置くかが最初から固定されています。同じCSVに同じ自動化ツールを走らせれば、いつでも同じ結果になります。これが決定的変換です。

現在の運用では、この決定的変換を単なる「スクリプト実行」としては扱わず、一つの契約として扱います。何を入力に受け、何を出力し、いつ実行し、何を合格条件にするかが、あらかじめ決まっています。見出し語ファイル数が第2次CSVの行数と合うか、壊れたYAMLのファイルがないか、ファイル名の衝突がないか、世界観軸フィールドが欠けたファイルがないかを、ビルド直後に確認するところまでが第3段階の骨格ビルドです。ファイルを作ってから後で検査するのではなく、作りながら同時に検証レポートを受け取る仕組みです。

この段階でプロデューサーがすることは、ほとんどないように見えます。ただし重要なのは「ない」のではなく「ないように見える」という点です。その違いは実はプロデューサーの姿勢で分かれます。原則どおりなら、自動化が出した1,500件の結果を一つも漏らさず検査すべきです。しかし実際にすべてを一件ずつ見れば、激しい非効率とボトルネックが生じます。かといって自動化の出力をそのまま放置すれば、成果物はきちんと立ち上がりません。手間のかかる変換を自動化へ渡すのは、第3段階から人が完全に抜けてよいという意味ではなく、人の手が本当に必要な第4段階の叙述執筆のために力を残すためです。

決定性には利点と危険が同居します。変数がないため、1,500のファイルを人の手を経ずに一度に作れます。しかし変換規則に欠陥が一つでもあれば、1,500のファイルが同じ欠陥を一斉に引き受けます。一か所の誤りが1,500回複製されるのです。だからビルド後には人が一度検査します。欠陥は個別ファイルではなく規則段階で直せるため、規則を修正してビルドを再実行すれば、1,500ファイルを一括修正できます。規則を正しく立て、自動化が処理し、人が結果を確認する流れです。

frontmatter、機械が読む契約書

骨格ビルドで作られるMarkdownファイル一つの構造を見てみましょう。ロマンス・ファンタジー世界観「香宮」の見出し語「調香師」を例にします。

---
title: 調香師
aliases: [調香家, 香師]
category: 人物
worldbuilding_axis: 香
english: Perfumer
romanization: Johyangsa
version: 現行
tags:
  - category/人物
  - axis/香
  - version/現行
sources:
  - ルールブック第3版 p.24
related:
  - "[[香]]"
  - "[[社交界]]"
  - "[[無嗅覚者]]"
---

**調香師は香りを調合し、人の感情と忠誠を動かす技術者である。香りそのものが魔法であるこの世界で、調香師は権力と情報をともに握る。**

調香師は[[香]]を採集して蒸留し、魅惑香と忠誠香を作り、[[社交界]]で誰の心を買うかを設計する。しかし香りに免疫を持つ[[無嗅覚者]]の前では、どのような調香も通じない。

**翻訳**: Perfumer。香宮の調香師。単なる香水製作者ではなく、香りで感情と忠誠を操作する魔術的な階層なので、「perfumer」だけでは意味が狭い。「scent-weaver」または「scent-mage」と意訳するか、原語を併記することを推奨する。

%% LLM %%

%% /LLM %%

%% メモ %%

%% /メモ %%

ファイル上部の、---で囲まれた領域がfrontmatterです。YAMLという形式で書かれたこのブロックを人が直接見ることはあまりなく、代わりに検索機能と自動化ツールがこのフィールドを読み取ります。

frontmatterを「機械が読む契約書」と呼ぶのには理由があります。人は「調香師」という文字を見るだけで、文脈と経験から、香りを扱う人物で人物分類に属すると容易に推測できます。しかし機械にはそれができないため、「このファイルの分類は人物で、属する世界観軸は香である」と漏れなく明示しなければなりません。frontmatterがその役割を担い、Obsidianでcategory/人物やaxis/香のようなタグを検索すれば、そのファイルはすぐに絞り込まれます。将来このVaultをもとに新しい自動化ツールを作るときも、そのツールはfrontmatterを読んでファイルの性質を把握します。今組むfrontmatterは目下の作業だけのものではなく、今後このIPと共に働くすべてのツールへ渡す約束の文書なのです。

第2次CSVの列がfrontmatterフィールドへ変わる対応は、一つひとつ明確です。代表キーワードはファイルの正式名であるtitleへ、異称・別称は代替検索語の一覧であるaliasesへ、分類は九分類の一つであるcategoryへ、世界観軸はIP固有の軸であるworldbuilding_axisへ入ります。英語名はenglish、ローマ字はromanization、バージョン状態はversion、出典一覧はsources、関連キーワードはwikilink一覧であるrelatedへ移ります。対応が一対一で明白だから、この変換は完全に自動化できます。人が判断する余地はありません。

メタデータという古い約束

frontmatterはライブラリングだけの発明ではありません。デジタル資料を長く扱ってきた分野では、題名、説明、日付、形式、出典、関係のような情報を本文の外に別置きする方法をメタデータと呼んできました。Dublin Coreのようなメタデータ体系が扱うのも、結局は「この資料の名前は何か」「何についての資料か」「いつ作られ、何と関係するか」といった基本的な問いです。

ライブラリングのfrontmatterも同じ役割を果たします。titleは見出し語の名前、aliasesは代替名、categoryとworldbuilding_axisはこの資料の種類と位置、sourcesはどこから来たかの記録です。本文が見出し語の意味を説明するなら、frontmatterは見出し語ファイルそのものがどのような資料かを説明します。

この区別が重要なのは、後でツールがVaultを読むとき、本文全体を解釈しなくて済むからです。「香軸の装置だけを集めよ」「廃棄された見出し語だけを探せ」「出典がルールブック第3版の項目を抜き出せ」といった問いは、frontmatterがあればすぐ処理できます。メタデータが堅固なら、Vaultは読みやすい文書の束から、検索・検証・再利用できる資料の束へと高まります。

本文の三層

frontmatterの下、---の次からが本文です。本文は三つの層でできています。

定義は太字の最初の段落で、第2次CSVの定義列を一、二文で完結した形のまま移します。他の見出し語ファイルがこの見出し語を参照するとき、あるいはAIの仕事仲間がこのファイルを文脈として読み込むとき、最初に目に入る文がこれです。一、二文に圧縮した見出し語の核であるこの定義がよく磨かれているほど、Vault全体の引用品質は上がります。

詳細説明は定義に続く段落で、第2次CSVの詳細説明列が入り、関連見出し語が[[リンク]]の形で結ばれています。リンクの一つひとつがVaultの連結網を編む糸であり、詳細説明中の[[香]]という一つのリンクは、「調香師」ファイルと「香」ファイルを結ぶ線となり、グラフビューでは点と点を結ぶ線として現れます。

翻訳ノートは第2次CSVの翻訳ノート列に入る内容で、未来の翻訳者へ宛てた手紙のようなものです。この見出し語をある言語へ移す際に何へ注意するか、どの訳語が既に承認済みか、直訳できないならなぜなのかを記しておきます。

この三層の下には、骨格ビルド時点では空のまま作られる二つのブロックが続きます。LLMブロックとメモブロックです。

LLMブロックを空にしておく理由

%% LLM %%から%% /LLM %%までのブロックは、なぜ空なのでしょうか。第4段階の叙述執筆で初めて文章が満たされるブロックだからです。一つの見出し語を一つの流れとして描く、200字から1,000字ほどの文章がここに入ります。

さらに重要な理由があります。第3段階の骨格ビルドは自動化であり、自動化は構造を立てられても創作はできません。定義も詳細説明も第2次CSVからそのまま移るため自動化できますが、LLMブロックに入る叙述は異なります。その叙述は、見出し語をIP世界の中で息づく存在として描く文章です。「調香師は香りで感情と忠誠を動かす技術者である」という定義と、「香りで社交界の心をすべて買い取った調香師が、自分の香りが通じない無嗅覚者の前で、生まれて初めて取り繕われていない反応に出会った瞬間」を書く叙述は、性質がまったく異なります。後者は創作であり、第4段階で行われます。

第3段階の骨格ビルドを終えたVaultは辞書です。第4段階の叙述執筆まで終えたVaultは、生きたIP世界の記憶庫です。その差を生むのがLLMブロックです。%%記号はObsidianで「ここは出力に現れないコメント」を意味し、LLMブロックとメモブロックはいずれもこのコメント記号で囲まれることで、作業空間と完成した出力を分けています。

冪等性──二度実行しても安全に

冪等性（idempotency）とは、同じ演算を複数回実行しても、結果が一回だけ実行したときと同じに保たれる性質を指します。たとえば「電灯のスイッチを押す」は、一度目で点き、二度目で消えるため冪等ではありません。対して「電灯を点灯状態にする」は、すでに点いている状態で再びそうしても結果が変わらないため冪等です。データベースでたとえれば、同じデータをそのまま追加するINSERTは二度入れると二行になるので冪等ではなく、既存なら更新し、なければ追加するUPSERTは同じデータを二度処理しても一つの結果にとどまるため冪等です。

ライブラリングで冪等性が重要なのはなぜでしょうか。IPは運用中に絶えず変わります。新しい本が出て既存設定が手直しされ、新しい見出し語が加わり、第2次CSVが更新されるたびに第3段階の骨格ビルドを再実行しなければなりません。その時点では、第4段階で既に%% LLM %%ブロックへ1,500本の叙述を書いているかもしれません。骨格ビルドを再実行したからといって、その叙述が消えてはなりません。何百時間もかけた叙述が再ビルド一回で失われるなら、それは災害です。

ライブラリングの冪等更新規則が、この問題を解きます。frontmatterと定義、詳細説明、翻訳は再実行のたびに第2次CSVを基準として上書き更新します。一方、%% LLM %%ブロックと%% メモ %%ブロックは保存対象とし、第4段階で書いた叙述と作業者が加えた編集には触れません。

この規則が生む結果を見ましょう。運用中に「調香師」の公式英語名が「Perfumer」から「Scent-Weaver」へ変わったとします。第2次CSVの当該行の英語名列を直し、第3段階の骨格ビルドを再実行すればよいのです。「調香師」ファイルのfrontmatterにあるenglishフィールドは新しい値へ更新されますが、LLMブロック内に既に完成している叙述はそのまま残ります。新しいIPコンテンツの発表で「残香」という見出し語の詳細説明を補強した場合も同様です。第2次CSVを更新して再ビルドすれば詳細説明は新しくなりますが、LLMブロックは触れずに維持されます。この冪等性の規則のおかげで、IPが生き続ける間Vaultを繰り返し更新しても、既に完成した創作作業を失いません。

Stubファイル──別称ごとに固有のファイル名を用意する方法

骨格ビルドが作るのは見出し語ファイルだけではありません。Stubファイルも同時に生成されます。

Obsidianで[[調香家]]というリンクを入力すると、Obsidianは「調香家」という名前のファイルを探します。このときfrontmatterのaliasesフィールドも検索対象なので、「調香師」ファイルのaliases一覧に「調香家」があれば、検索はそのファイルへつながります。

ただし、Obsidianのwikilinkはファイル名を基準に働くという罠があります。aliasesは検索で機能しても、他ファイルから[[リンク]]として結ぶときはファイル名と正確に一致しなければなりません。ファイル名が「調香師」なのに[[調香家]]を入力すれば、Obsidianは「調香家」ファイルがないため未作成ファイルとして表示し、二つのファイル間の接続線は結ばれません。

Stubファイルがこの問題を解きます。別称ごとに一つのファイルを作り、そのファイルから代表見出し語ファイルを指すようにするのです。

---
title: 調香家
redirect: 調香師
type: stub
tags: [stub]
---

[[調香師]]を参照。

これで[[調香家]]は「調香家」ファイルにつながり、そのファイルが再び「調香師」を指すため、切れていた接続がつながります。英語で「Kimchi」と検索しても「キムチ」記事へ導かれるのは、「Kimchi」が「キムチ」へ送るリダイレクト（redirect）ページだからです。Stubファイルはこのリダイレクトページに当たります。

「調香師」の別称が「調香家」と「香師」なら、二つのStubファイルが作られます。一つのIPに数百から数千のStubファイルが生まれるのは正常です。1,500の見出し語に平均一、二個の別称があれば、Stubファイルは1,500から3,000になります。これらは下位フォルダなしで見出し語ファイルと同じフォルダに並び、frontmatterのtype: stubで区別されるので、グラフビューで個別に絞り込んだり隠したりできます。

manifestファイル──ビルドの領収書

第3段階の骨格ビルドが出すのはMarkdownファイルだけではありません。ビルド結果を要約するmanifestファイルも作られます。名前は_vault_manifest.jsonで、Vaultフォルダと同じ場所に置かれます。

これはソフトウェア開発におけるビルドmanifestと同じ役割です。アプリケーションをビルドすると、作られたファイル、そのサイズ、ハッシュ値を記録するファイルが共に生成され、配布時にはmanifestだけでどのバージョンがどの状態かを把握できます。ライブラリングのmanifestも同様ですが、ファイルハッシュの代わりにIPの語彙統計を収めます。

プロジェクト名、Vaultパス、ビルド日時、元CSV名のほか、世界観軸の許容値と各軸の見出し語数、全見出し語数と九分類別の数、バージョン状態別の数、Stubファイル数が記録されます。これがVaultの統計です。

さらに二つが加わります。進捗状態は、このVaultが第1次から第4次のどこまで来たか、どのバッチが完了し何が残るかをmanifestに記憶させます。第4段階の執筆が中断して翌日再開する場合、作業者は記憶に頼らず、manifestでpendingのバッチから始められます。ハンドオフ状態は、このVaultを次の作業が読んでよいか、検証前か、最後にいつ引き渡したかを残します。

人物関係図や年表のような補助文書のカタログも入れます。見出し語ファイルではなくてもVaultの利用者に必要な文書は、最初からmanifestに登録されていなければ、後の検証で「作ると決めた補助文書が本当にあるか」を確認できません。以前は第4段階の後に記憶で扱っていましたが、いまは骨格ビルド時点から一覧に加えます。

manifestの実用的な価値は検収にあります。第2次CSVが1,847行なら、ビルド後の見出し語ファイルも1,847でなければなりません。manifestを開けば五秒で確かめられます。「人物」分類が二件だけなら異常の兆候であり、香を背景とするIPなのに香の世界観軸が十件しかなければ抽出不足の兆候です。第4段階の叙述執筆を複数回に分ける場合にも、manifestは再開地点を示します。

manifestは、Vaultがどの入力から、どの活動を経て、誰の検収を通って現在の状態になったかを残す履歴表でもあります。W3C PROVがデータの信頼性を判断するため、生成過程と関連主体を記録するように、ライブラリングのmanifestは原本文書、抽出、統合、ビルド、検証、ハンドオフを一本の流れにつなぎます。原本文書・CSV・.mdは成果物、抽出・統合・ビルドは活動、人・AIの仕事仲間・自動化ツールは参加主体です。

したがってmanifestは単なる統計ファイルではありません。「このVaultは今、信頼できるか」という問いに答える証拠の束です。いつビルドされ、どのCSVから来て、どの検証を通り、次の作業へ渡してよいかを残すので、数か月後に再び開いても状態を判断できます。

骨格ビルド後、初めてVaultと向き合うとき

1,500のファイルが一度に作られ、フォルダへ積み上がった瞬間を今も覚えています。直前まで画面には一枚のスプレッドシートしかありませんでしたが、自動化を実行して少し待つと、サイドバーがファイル名で埋まりました。表の一つのセルにとどまっていた語が、それぞれ固有のファイル名を持つファイルになったのです。左のサイドバーには1,500から2,000のファイルが韓国語の五十音順に並びます。「魅惑香」「無風の谷」「無嗅覚者」「聞香」「封香」「社交界」「残香」といった名前をたどれば、このIPにどんな存在が生きているかがかすかに感じられます。

一つのファイルを開くと定義と詳細説明が入り、その下のLLMブロックはまだ空です。辞書の骨組みだけが整った状態です。

グラフビューを押すと画面は一変し、1,500の点とそれらを結ぶ線が一面に広がります。点一つが見出し語一つ、線一つがwikilink一つです。九分類により人物は青、場所は緑、装置は橙と区別されます。特に多くの線が集まる点が中心見出し語、すなわちhub候補です。

このグラフを初めて見る感覚は、いくつもの都市の路地をそれぞれ歩いていただけだったのに、空から初めて全体地図を見下ろす感覚に似ています。見出し語を一つずつ読むだけでは見えなかった構造がグラフビューでは一目で入ります。どの見出し語がIPの中心または周縁にあるか、どの分類で特に多くの見出し語が出たかが分かります。この図がライブラリングの第3段階の成果物であり、第4段階の叙述執筆の地図になります。線が多く集まる点から執筆を始めればよいのです。

第3段階で人がすること

第3段階の骨格ビルドはほとんど自動で進みます。それでも人が直接確認すべきことは三つあります。

ビルド後のmanifest検収は数字を照合する作業です。第2次CSVの行数とMarkdownファイル数が正確に一致するか、ある分類や世界観軸で見出し語数が予想から大きく外れていないか、Stubファイル数が合理的な範囲にあるかを見ます。三分から五分で済みます。

Vaultファイルの無作為標本検収では、サイドバーから十から二十ファイルを無作為に開き、frontmatterフィールドが正しく入っているか、定義が見出し語に合うか、詳細説明のwikilinkが正しく張られているかを確かめます。五分で十分です。異常があれば変換規則か第2次CSVのデータ品質に問題があります。原因を規則段階で直して再ビルドすべきで、一つずつ手で直すのは誤った方法です。

ビルド直後の自動検証確認。 詳細説明に[[リンク]]があるのに対象ファイルがなければ、それは切れたリンク（dangling link）で、Obsidianのグラフビューではどの点にも届かない空所を指します。こうしたリンク整合性に加え、.mdファイル数、frontmatterの解析、ファイル名衝突、worldbuilding_axisの欠落は、すべて自動検査で見つけられます。見つけたら即座に修正すべき問題です。切れたリンクは通常二つの理由から生じます。第2次CSVで関連キーワードを入力する際、代表キーワードと異なる表記を使った場合と、関連キーワードとして結んだのにその語が見出し語に登録されていない場合です。前者は表記を統一し、後者は見出し語に追加するかを検討します。

骨格が立った後に

第3段階の骨格ビルドは、ライブラリングのパイプラインで最も人の手が少ない段階です。創造的な判断はほとんど不要で、自動化が黙々と処理します。この段階が終わると、Vaultは初めて目に見える形を得ます。

第8章ではhubとleafを扱います。グラフ上の点のうち、何を基準に中心のhubと末端のleafを分けるのか、そしてなぜ執筆をhubに先に集中すべきなのかを見ていきます。

第7章 骨格ビルド──CSVがObsidianファイルになるまで