第10章　検証：三段階で合格を担保するプロセス

第4段階の叙述執筆が終わると、1,500個のLLMブロックはすべて文章で満たされます。しかし、文章が入ったことだけでVaultが完成したとは言えません。

この時点のVaultは膨大ですが、まだ検証を経ていません。切れたリンク、同一人物の重複見出し、誤った世界観軸に分類された見出しが残っている可能性があります。そうした問題を見つけないまま下流の作業に引き渡せば、誤った情報がそのまま受け継がれます。

本章では、こうした潜在的な問題を発見し処理する検証段階を扱います。

検証が創作を遅くするという誤解

初めて検証に触れると、「確認項目が多すぎる。すべてを通過しなければならないなら、創作はかえって遅くなるのではないか」と感じることがあります。検証を創作の障害とみなす見方ですが、ソフトウェア開発の歴史は長い経験を通じて、その見方が誤りであることを示してきました。

1960年代初期のソフトウェア開発では、まずコードを速く書き、問題が起きてから直すやり方がありました。検証せずに公開し、利用者が不具合を見つけた時点で修正する方式です。結果はよくありませんでした。誤りは蓄積し、一つを直すと別の場所に新しい誤りが生じ、コードが大きくなるほど修正費用は指数的に増えました。業界が学んだのは、誤りは発生時点に近いほど修正費用が低いということです。第1段階の抽出で生じた誤りをその段階で見つければ費用は1ですが、第2・第3段階を通り、Vaultの1,500ファイルに広がってから見つければ何十倍にもなります。検証は創作を遅くしません。検証がなければ、創作のほうが遅くなります。

製造業にも同じ教訓があります。トヨタ生産方式の重要な原則の一つは、異常を見つけたら直ちにラインを止めることです。不良品を作り続けるほうが速そうに見えても、あとで回収・廃棄・修理する費用のほうがはるかに大きいからです。ライブラリングの三段階検証は、この原則を創作工程に移したものです。各段階が、異なる層の問題を異なる費用で捕まえます。

検証が創作を守る二つの事例

大規模に検証を運用している公開創作物の代表はWikipediaです。Wikipediaには中核となるコンテンツ方針が三つあり、その一つが検証可能性です。疑問を持たれ得る記述と引用には信頼できる出典を付けなければなりません。この原則に反する編集はrevertによって以前の状態へ戻され、同じ文書で編集が衝突した場合は、紛争解決の掲示板や意見募集（RfC）などの手続きで合意を探します。これは創作を妨げる規制ではなく、創作を守る仕組みです。出典のない叙述が積み重なれば、何が事実なのか誰にも分からなくなり、百科事典全体を信頼できなくなります。検証可能性と差し戻しが、その崩壊を防ぎます。ライブラリングの自動段が切れたリンクや重複見出しを見つけることも、同じ役割を果たします。

ゲーム分野にも似た例があります。大規模なゲームは発売前にQA（品質保証）で回帰テストを行い、新機能を入れる過程で既に動いていた部分が壊れていないかを確認します。発売後はパッチノートで何がどう変わったかを公開します。この二つが、ゲームという大きな世界の整合性を守ります。ライブラリングも同じです。第3段階の骨格ビルドや第4段階の執筆をやり直した後、自動段を再実行して新たな問題がないか確かめることが回帰テストに当たり、検証状態をVaultのインデックスに一行で記録することがパッチノートに当たります。

イシューの優先順位：P0・P1・P2

検証で見つかったイシューは三段階に分けます。等級を分けることで、すべての問題を同じ重さで扱って無駄にすることを防げます。

P0はVaultの利用可能性に直接影響する、または見出しの同一性を損なうイシューで、発見したら直ちに修正します。同一人物が二つの見出しに重複登録されている、hub見出しに切れたリンクがある、frontmatter YAMLの解析に失敗するファイルがある、世界観軸の許容値にない値が入っている、といったものです。どれもVault自体が正しく動かない水準の問題です。たとえばYAML解析に失敗するファイルが一つあれば、それを読む下流作業でエラーが起きます。最初に見つければ3分で直せるものが、あとから原因を追えば30分かかることもあります。

追跡可能性や参照整合性を損なうイシューはP1に分類し、ハンドオフ前に直します。relatedフィールドのリンクが存在しないファイルを指す場合や、manifestの見出し数と実ファイル数が一致しない場合がこれに当たります。Vaultそのものは動いても、追跡可能性を傷つける問題です。

P2は構造的な改善または後続の補強であり、次のサイクルへ繰り越せます。leaf見出しの叙述が基準分量に少し届かない、%% LLM %%ブロックが未記入の見出しが全体の5%以下である、といったものです。Vaultの利用を妨げる問題ではありません。

今直すべきものと、あとに回せるものを意識して決めることが、等級分類の核心です。

第1段階：自動段――機械が捕まえられるものは機械に捕まえさせる

自動段は、スクリプトや自動化ツールで点検できる整合性項目を確認する段階です。人の判断を介さず、合格か不合格かが決まります。

ソフトウェア開発の単体テストに似ています。関数一つが期待どおりに動くかを自動で確認し、失敗すれば問題箇所が直ちに分かるため、人がコード全体を読むより速く正確です。

ライブラリングの自動段には、パイプラインの各段階に確認項目があります。第1段階の完了確認では、作業計画書のチェックボックスが100%完了しているか、入力文書が偏りなくカバーされているか、9分類すべてに1件以上あるかを見ます。物品分類が異常に空なら、ひしゃくや釜のような小道具を丸ごと見落とした合図かもしれません。第2段階では、代表キーワード重複0件、英語名欠落0件、切れたwikilink 0件、バージョン状態「未定」が全体の5%以下、世界観軸「未定」が10%以下、許容値外の世界観軸0件を確認します。第3段階では.mdファイル数と第2段階CSV行数の一致、frontmatter YAML解析失敗0件、ファイル名衝突0件、worldbuilding_axis欠落0件を確認します。第4段階では、LLM叙述完成率95%以上、書式に対する本文比率60%以上、hub見出し4段落以上、leaf見出し1段落以上、category別の構造化セクションの存在、自己リンク0件、manifestの進捗と実ファイル状態の一致を確認します。

これらは自動化によってほぼ即座に確認できます。失敗が出ればP0またはP1として登録し、すぐに処理します。自動段には二つの価値があります。人が読まなければ見つからないのではなく機械が即座に見つけること、そして骨格ビルドや叙述執筆を再実行した後にも同じ項目を再確認でき、新しい問題をすぐ知れることです。

第2段階：手動サンプル段――意味と判断を要する検収

自動段は構造的な整合性を捕まえます。しかし「この同義語群は本当に同じ人物か」のように、意味と判断が必要な項目は自動化できません。手動サンプル段が扱うのは、まさにその領域です。

ここでは標本抽出の原理が役に立ちます。工場の製品1,000個をすべて検査しなくても、一部を無作為に選んで調べれば、全体状態を示す実務的な信号を低い費用で得られます。手動サンプル段も同じ原理を使います。1,500個の見出しをすべて人が読む代わりに、無作為に抽出した標本を丁寧に検収し、全体品質の危険信号を探します。

したがって原則は全数検査ではなく、分類ごとに1〜2件を無作為に選んで直接読むことです。確認項目は四つあります。

統合判断の適切性では、無作為に選んだ見出し5件の異称と別名が本当に同じ対象を指すか、異なる人物が一つの見出しにまとめられていないかを見ます。第2段階の統合でAIが誤判断した内容がVaultまで降りてきた場合であり、自動化ではなく人が読んで初めて分かります。

第4段階叙述のトーン一貫性では、hub見出し1件と同じ分類の中間見出し5件を比べ、hubで確立した中核フレーミングが他の見出しでも同じように働いているかを見ます。バッチごとにAIインスタンスが異なるため、バッチ境界でトーンが急に変わることがあります。

世界観軸分類の適切性では、各世界観軸から見出し5件を無作為に選び、本当にその軸に属するかを見ます。「天命」軸に分類された見出しの中に、実際には「出来事」により近いものが混じることがあります。

構造化セクションの正確性では、装置見出しの「制約条件」セクションが実際の出典を指しているかを見ます。AIが出典のない推測を制約条件として書いていれば、P1です。

この手動段は30分から1時間かかります。見つかったイシューはP1またはP2として登録します。標本で重大なイシューが見つかれば、そのイシューが属する分類全体をより広く検収します。標本が警告信号を送れば、全体をさらに見ます。

第3段階：統合ビルド段――実際に使うとき正しく動くか

第三段階は最も高い層位の検証です。自動段がファイルごとの整合性を見て、手動サンプル段が意味の正確性を見るなら、統合ビルド段はこのVaultが実際に使われたときどのような体験を与えるかを見ます。ソフトウェアでいえばユーザー受け入れテスト（UAT）に当たります。単体テストと統合テストを通過したソフトウェアでも、実際の利用者が使えば予期しない問題が現れるからです。

統合ビルド段で行うことは三つです。

hub見出し一つを最初から最後までたどります。 hub見出しを開き、frontmatter、定義、詳細説明、LLM叙述、related、backlinks（この見出しを指す他の見出し）を順に確認します。その順で情報が十分か、リンクが正しくつながるか、叙述がIPの問いに答えるかを見ます。「ウサブ」の「祈雨祭」見出しをたどったとき、「この儀礼を行った人物が後にどうなるか」を知りたいのに、その情報へ進むリンクがなければP2です。Vaultが今すぐ止まるわけではありませんが、この見出しからつながるべきリンクが欠けています。

仮想の短編一本をシミュレーションします。 Vaultだけを見て短い物語を書こうとし、どこで行き詰まるかを見ます。詰まる場所こそ資料の補強が必要な場所です。初めて祈雨祭を行う人物の場面を書こうとしても、儀礼をどこで行うかという情報がVaultになければ、場所に関する見出しか祈雨祭の叙述にその情報を補う必要があります。こうしたイシューはP2です。

新規利用者をシミュレーションします。 Vaultを初めて見る人が、インデックスから核となる見出しへ、さらに関連見出しへ移動し、30分以内にIPの世界観を把握できるかを見ます。長くIPを作ってきたプロデューサーはVaultの内容を既に知り、欠けた情報があっても記憶で補えますが、新規利用者はそうできません。新しい編集者や翻訳者が加わったとき、Vaultだけを見てIPを把握できなければなりません。統合ビルド段の新規利用者シミュレーションは、まさにその準備状態を確認します。

この統合ビルド段は1〜2時間かかります。発見したイシューはP2として登録し、インデックス、hub見出し、補助文書の補強計画につなげます。

ハンドオフ合格チェックボックス

三段階の検証が終わったら、ハンドオフ合格チェックボックスを確認します。必須項目がすべて通過して初めて、Vaultを下流作業へ渡せます。

必須項目は一つでも通過しなければハンドオフを保留します。自動段の全項目通過、第4段階の委任後に行う5段階検収の全通過、manifestの「ハンドオフ準備完了」表示、全P0の即時修正完了、全P1の修正完了または明示的な繰越決定、プロファイル・世界観軸カタログ・補助文書カタログの添付が必須です。推奨項目は1件まで未通過を許容します。手動サンプル段の通過、統合ビルド段で資料だけで情報が十分であること、補助文書がカタログどおりに作られていること、hub見出しがプロデューサーによって直接書かれたことです。

このチェックボックスが完成したら、検証状態をVaultのインデックスファイルに一行で記録します。誰がVaultを初めて見ても、どんな状態かをすぐ確認できるようにするためです。

合格線の体系：段階ごとに基準が異なる理由

パイプライン段階ごとに合格線は異なります。第1段階は「できるだけ多く集める」ことが目的なので、60%集まれば次へ進めます。第2段階は統合と精製の段階であるため、ほとんどの見出しが13列を満たして95%に達する必要があり、残る5%は「未定」のままでもかまいません。第3段階は決定的な自動化段階なので、ファイル一つも誤りなく生成される100%が必要です。第4段階はhubとleafで分量基準が違いますが、運用用Vault全体ではLLM叙述完成率95%以上を求めます。leaf見出しが短くてよいということは、大量に空でもよいという意味ではありません。残る未作成分は全体の5%以下のP2として明示し、次のサイクルの補強計画に載せなければなりません。

この合格線の体系があれば、どこで完全さを求め、どこで適切に進めてよいかが明確になります。第1段階で100%を求めるのは時間の無駄であり、第3段階で99%しか達成できなければ問題です。段階ごとに異なる基準には理由があります。

検証を終え、ハンドオフへ

この三段階を通過したVaultは、下流作業へのハンドオフ準備が整っています。しかしハンドオフの後、Vaultはそこで止まるのでしょうか。そうではありません。VaultはIPとともに生き続けます。

新しいIPコンテンツが発表されたときVaultをどう更新するか、新しい見出しがどう逆流するか、IPが生きている限りVaultもともに生き続ける運用サイクルを、第11章で見ていきます。

第10章 検証：三段階で合格を担保するプロセス