ゲームプランナーのための AI 実務ワークフロー

作り話の数字はひとつもない — Claude Code・プロンプト・検証・制作メモリの実践記録

24年目のディレクターが中規模（10〜50人）チームで実際に運用した304のルール・48のツール・自動化システムをそのまま収録

著者 イ・ミンス（李旼洙）・2026

本文の内容はすべて2026年上半期を基準としています。AIツールの料金・モデル・機能は変化が速いため、具体的な数値やインストール方法は各公式ページで最新情報をご確認ください。

本書の配布と著作権

本書は、広く読まれることを願って無料で公開されています。ただし、韓国語の原本であれ英語・日本語の翻訳版であれ、本書の原著者がイ・ミンス（Minsoo Lee）であるという事実だけは、どこでも維持されなければなりません。

• ライセンス: クリエイティブ・コモンズ 表示-非営利-継承 4.0（CC BY-NC-SA 4.0）
• 原著者: イ・ミンス（Minsoo Lee）、2026
• 正本（canonical）: https://eremes81.github.io/game-design-ai-practice（著者のGitHub Pages — 編集権が著者にある正本）

自由に行えます。 個人の学習、非営利の共有と引用、非営利の翻訳、社内勉強会での活用 — ただし、原著者と正本へのリンクをあわせて表示し、内容を変更したり他の言語に翻訳したりした場合は、その事実を明記してください。二次的著作物も同じ条件で共有してください。

別途許諾を得てください。 商業的な出版・販売、有料講座の教材としての使用、企業の商品・サービスへの組み込み、そして原著者表示を削除した再配布です。

本書に収められた知識は一冊で完結しており、それ自体は無料です。もし役に立ち、著者を応援したいと思われたら、正式な電子書籍や有料キットで気持ちを添えていただければ幸いです。

序文 — 三度書かれた本

本書は三度書かれました。

最初は本ではなく、社内マニュアルでした。会社で6か月間AIワークフローを回しながら、チームが同じルールを二度尋ねなくて済むように、決定とツールと手順を文書として固定しました。出版のために作ったのではなく、毎日の繰り返しを減らすために積み上げた運用文書でした。本書の具体性はそこから来ています — 本のために作り上げた事例ではなく、実際に回っていたマニュアルが土台にあるという意味です。

二度目は、そのマニュアルを本に書き起こした最初の原稿でした。ところが、「AIでこんなことができる」をもっともらしく並べた一般論になってしまいました。表が多く、効果を示す数字がたくさんありました。その数字の大半には、小さな文字で「架空の数値」と書かれていました。読み返したとき、それが最大の欠陥でした。AI活用を語りながら肝心の実際の画面を見せず、効果を語りながらでっち上げた数字を挙げていたのですから。マニュアルの具体性を本に移す過程で、かえって失ってしまったわけです。

そこで三度目に、すべてを書き直しました。いま手にしているこの本文です。社内マニュアルの具体性をよみがえらせつつ、本の原則はシンプルに定めました。

第一に、すべての章は実際のセッションを最後までお見せします。 私が打ち込んだプロンプトの全文、AIが返した生の出力、その出力から私が何を拒否したのか、どうやり直させたのかまで収めました。「AIがやってくれる」という文章で章を終えることはしません。

第二に、数字は三つのうちのいずれかです。 誰でも確認できる公開標準（モデルのトークン単価、アクセシビリティガイドライン）、私のシステムのコードに実際に入力されている定数、あるいは「これは私の推定です」と明示した値。でっち上げた削減額の表は一つもありません。正直さを差別化のポイントにしました。

第三に、実務で6か月運用した本物のシステムをそのまま引用します。 304枚の決定カード（atom）、48個のツール（skill）、入力のたびに関連する記憶を自動で引き出すフック（hook）、一人で4人分のコラボレーションの文脈を運用するメモリー構造まで。抽象的な「何かのツール」ではなく、ファイル名とコードとスコアをそのまま記しました。本文の事例では会社・プロジェクト名とチームメンバーの名前を伏せただけで、ワークフローの具体性は消していません。（本書の出版を許可してくれた会社については、謝辞で実名を明らかにしています — 了解を得ているためです）。

私は24年目のゲームプランナーです。シングルプレイゲームのQA・チェックの仕事でこの業界に足を踏み入れ、その後、数十か国でサービスされたMMORPGのディレクターから、200人規模のAAA MMORPGの初期開発、グローバルモバイルMMORPGの運営（ライブオプス）まで — RPGとMMORPG、その変種を作りながら過ごしてきました。ラグナロクオンライン、ブレス（Bless Online）、MIR（ミル）シリーズのようなプロジェクトに、ディレクター・リードプランナー・システムプランナー、ときにはPMなどさまざまな職務で参加し、小さなモバイルゲーム会社を起業したこともあります。

正直に言えば、ディレクターの肩書きを早く付けすぎました。その後、システムプランナーとしてマスターデータと戦闘の数値を直接さわり、コンテンツプランナーとしてクエストとNPCを一行ずつ量産し、イベントを企画し、新規コンテンツを量産していたメンバー時代が長くありました。本書に登場するワークフローの多くは、その立場 — 管理する側ではなく、自分の手を直接汚す立場 — で「この繰り返しをどうにかして減らしたい」という思いから作ったものです。いまは現場で一つのMMORPGの企画ディレクターとして中規模（10〜50人）のチームを率いていますが、本書のツールはディレクターの管理ツールではなく、実務者の手から生まれました。だからこそ、本書のシステムは理論ではなく、毎日回っている作業環境です。家で一人で作った小さなパズルゲーム1本の事例も同じ方式で扱います — そのゲームのgitコミットと実際のコードをそのまま引用しました。

AIがゲームプランナーの仕事を置き換えることはできません。ただ、雑務から手を離させてくれます。その手で何をするかは、依然として人の役割です。本書がその転換の実務ガイドになることを願っています。

本書の読み方

本書は最初から最後まで順番に読まなくてもかまいません。自分の状況に合った道を選べば大丈夫です。ターミナルやインストールが初めてなら、何よりもまず1.0「始める前に」から開いてください — 黒い画面への怖さを先に和らげてくれる章です。

各章の最後には「やってみよう」があります。読んで閉じる章ではなく、今日、自分の環境で一段階でも手を動かしてもらうことが目標です。

ゲームの外で働く方に、もう一言だけ添えます。本書のワークフローの多く — 議事録を決定に変える、決定の波及の追跡、検証ゲート、コスト管理、著作権・倫理 — は、ゲームと無関係にそのまま機能します。ゲーム企画を自分の職務に置き換えて読んでいただいてもかまいません。 各章の「ゲーム外への応用」ボックスがその橋渡しであり、時間がなければ90分の超短縮コース（17.1 → 16.2 → 22.1 → 21.1）だけたどっても、核心の骨格を手で体感できます。

一つ区別をしておきます。本書で「一人」は二つの意味で使われます。一つは一人ディレクター — 複数人分のコラボレーションの文脈を一人で抱えるリード — であり、もう一つは一人でゲームを作る個人・趣味開発者です。各章の最後の「一人ミニ版」は後者のためのもので、チームも会社のフォルダーもなしに、その章の核心だけを持ち帰る道を記しました。

本書は一冊として通読してもいいですし、二つの枝 — 第1〜15部「基盤・分野」と第16〜24部「プロセス・運営」 — に分けて、必要な側から読んでもかまいません。また、本文のコードはほとんどが外部依存なしに、Pythonの標準ライブラリーだけでそのまま実行できます。関係グラフのような一部のツールだけ標準外のパッケージ（networkx、PyYAML）が必要で、その箇所にはインストールの1行（pip install …）をコードの横に添えてあります。その場合を除けば、別途ダウンロードするものはなく、コードブロックをコピーしてすぐ実行して確認できます。

用語でつまずいたら、その場で止まらず、いったん先へ進んでください。黒いターミナルが見慣れないのはツールの欠陥ではなく慣れの問題であり、その距離感は1.0と第1部で一緒に縮めていきます。

いちばん簡単な活用法

最後に、本書のいちばん速い活用法を一つお教えします。本書そのものを、Claude CodeのようなAIツールに丸ごと読ませることです。

本書は人だけが読むために書かれたのではありません。各章のプロンプト全文・コード・検証手順は、AIがそのまま理解して再現できる形で記しました。ですから、自分のプロジェクトフォルダーで本書をAIに渡し — PDFでもテキストでも — 「この本の整合性チェックのパターンを読んで、うちのマスターデータに合うチェックツールを作って」のように頼むことができます。するとAIが、該当する章のワークフローを自分の環境に合わせて構築してくれます。人が一章ずつ手で作りながらたどる道と、本を丸ごとAIに渡して一緒に作る道 — どちらも開かれています。

ただし、一つだけ変わらないことがあります。何を採用し何を拒否するか、その最後の決定は — 本書が最初から最後まで繰り返し述べるとおり — 依然としてあなたの役割です。AIに本を読ませてシステムを構築しても、そのシステムが出す候補をレビューする持ち場は、人が守ります。いちばん簡単な活用法でさえ、その原則の上で動くのです。

一つの約束

本書のどの表にも、「読者を説得するために水増しした数字」はありません。効果を誇張する代わりに、効果が生まれる構造をお見せします。同じ構造を自分のプロジェクトに移せば、自分の数字は自分で測ることになります。それが、本書が差し上げられるもっとも正直な助けです。

「再構成」という言葉の約束

本書の本文では、ワークド・トランスクリプトの出力にしばしば「再構成（reconstruction）」という表記が付きます — たとえば「ステップ3 — Claudeの出力（再構成）」のように。この言葉が何を保存し、何に手を加えたという意味なのか、一度だけ正確に約束しておきます。正直さを看板に掲げた本が、もっとも曖昧にしてはいけない場所だからです。

「再構成」は、でっち上げたという意味ではなく、実際のセッションを編集したという意味です。 境界は次のとおりです。

言い換えれば、再構成された出力において、効果を水増しした数字や、なかった成功を加えることはしていません。 匿名化し、抜粋し、紙面に合わせて整えただけです。失敗した出力を成功に書き換えた箇所はありません — むしろ失敗をあえて残しました。それが、人が何を拒否するのかを見せる場所だからです。（対照的に、コードの実行結果やシステムログを「実測」「そのまま引用」と記した箇所は、編集なしに移したものです）。

【訳注】本版では、コードブロック内のプロンプトと出力も読みやすさのために日本語に翻訳しています。本版のワークド・トランスクリプトはすべて、韓国語で行われた元セッションの翻訳であり、日本語で再実行したものではありません。本書が『手を加えない』と約束した一次資料の韓国語原文は、韓国語版にそのまま保存されています。コードの文法・識別子・数値・検証値には手を加えていません。

第1部 · Foundation

1.0 始める前に — インストール・アカウント・料金・ターミナルサバイバルキット

1.1は「初めての出会い」です。点滅するカーソルの前に座り、何かを打ってみる場です。ただ、その席に着くには、先に揃えておくべきものがあります。ツールがインストールされていて、ログインが済んでいて、料金がどのように発生するのかをおおよそ知っていて、黒い画面で文字をいくつか打てること。本章は1.1より1段階手前にあります。

多くの入門書はこの段階を飛ばします。「ターミナルを開いてください」と1行書いて先へ進みます。しかし、入門者はまさにその1行でつまずきます。ターミナルがどこにあるのか、何をインストールすればいいのか、インストール中に赤い文字が出たらどうすればいいのか。最初の1行で止まった人は、1.1までたどり着けません。本章の目標はただ一つ、最初の1行でつまずかせないことです。

本章は五つの部分で構成されています。インストール、アカウントとログイン、料金プランの考え方、ターミナルサバイバルキット、そして「5分で初回実行」チェックリストです。順番に進めば、1.1の席に着く準備が整います。

flowchart LR
    A["1.0 準備段階
(この章)"] --> B["1.1 初めての出会い
(カーソルの前に座る)"]
    A1["① インストール"] --> A2["② アカウント・ログイン"]
    A2 --> A3["③ 料金プランの考え方"]
    A3 --> A4["④ ターミナルサバイバルキット"]
    A4 --> A5["⑤ 5分で初回実行"]
    A5 --> B
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class A1,A2,A3,A4,A5 human
    class B pass

1.0.1 インストール — OS別の1行

インストールは公式の案内に従うのが原則です。ツールは頻繁に変わりますし、非公式な経路で入手したインストールファイルは危険です。そのため本書はダウンロードリンクを載せず、公式の入り口を見つける方法を案内します。検索窓に「Claude Code 公式ドキュメント」または「Claude Code install」と入力すれば、Anthropicの公式ドキュメントページが最初に出てきます。インストールコマンドは、そのページのものをそのまま使うのが最も安全です。

全体像は知っておくとよいでしょう。Claude Code（クロードコード。本書では英語表記に統一します）はターミナルで動くツールで、通常は1行のコマンドでインストールします。OSごとに流れが少し異なります。

三つのOSとも流れは同じです。「ターミナルを開く → 公式ドキュメントの1行を貼り付ける → Enter」。コマンドを暗記する必要はありません。公式ドキュメントからコピーして貼り付けるのが定石です。

インストール中に赤い文字（エラー）が出ても、慌てる必要はありません。入門者が出会うインストールエラーは、ほとんどが二つのうちどちらかです。権限の問題か、前提となるツール（例：Node.jsのようなランタイム）がない場合です。赤い文字が出たら、その文章全体をそのままコピーして検索するか、AIに聞けば十中八九解決します。エラーメッセージは敵ではなく手がかりです。

インストールがうまくいったか確認する方法：ターミナルにclaude --versionと打ってEnter。バージョン番号が1行表示されればインストール成功です。「コマンドが見つかりません」のようなメッセージが出る場合は、まだインストールされていないか、ターミナルを開き直す必要があるケースです。ターミナルを完全に閉じてから開き直し、もう一度確認してみましょう。

1.0.2 アカウント・ログイン

インストールが終わったからといって、すぐに使えるわけではありません。Claude CodeはAnthropicのAIモデルを借りて使うツールなので、誰が使っているのかを確認するログインの段階が必要です。

流れは単純です。ターミナルでclaudeを初めて実行すると、ログインの案内が表示されます。通常はWebブラウザーが自動で開くので、そこでAnthropicアカウントでログインします（アカウントがなければ、その画面で新規作成できます）。ログインが終わると、ブラウザーには「もうターミナルに戻って大丈夫です」のような案内が、ターミナル側にも完了の表示が出ます。

ここで入門者がよくつまずくポイントが2か所あります。

一つ目は、ブラウザーが自動で開かない場合です。このときはターミナルに長いアドレス（URL）が1行表示されます。そのアドレスをコピーして、ブラウザーのアドレスバーに貼り付けて開けば大丈夫です。行き詰まったわけではなく、手動でもう1段階進めばよいだけです。

二つ目は、アカウントの種類を混同する場合です。Webチャット（Claude.ai）で使っていたアカウントと、Claude Codeのアカウント・料金がどうつながるかは、時期によってポリシーが異なることがあります。ログイン画面の案内と公式ドキュメントに従うのが最も正確です。初回実行の画面の指示どおりに進めば、ほとんどの場合は問題なくログインできます。

ログインは一度しておけば、そのPCでは維持されます。毎回やり直す必要はありません。

1.0.3 料金プランの考え方 — 定額サブスクリプション vs API従量課金

入門者が一番不安に思うのは「お金がいくらかかるのか」です。文字を打つたびに料金が発生するのではないか、という漠然とした恐れがあります。全体像を先につかめば、この不安は小さくなります。料金の方式は大きく二つに分かれます。

定額サブスクリプションは、月単位で決まった金額を払い、上限まで使う方式です。携帯電話の定額プランに似ています。毎月同じ金額なので予測がしやすく、「1行打つたびにいくら」を気にする必要がありません。そのため、入門者は定額サブスクリプションで始めるのが気楽です（著者の推定。正確なプラン構成と上限は時期によって変わるため、公式の料金ページで確認してください）。上限を超えたら、次の周期まで待つか、上位プランに上げます。

API従量課金は、実際に使った量（トークン）に比例して課金される方式です。電気メーターのように、使った分だけ請求されます。大量処理や自動化パイプライン、ほかのプログラムとの連携に向いています。うまく使えば効率的ですが、入門の段階では、使用量の感覚がつかめるまでコストの予測が難しいことがあります。

トークンとは何か、なぜそれを単位に課金するのかは、1.2（AIモデル・トークン・ハーネス）で詳しく扱います。ここでは一つだけ覚えておけば十分です。入門者は通常、定額サブスクリプションで始めます。毎月の金額が固定なので、「使っているうちに高額請求が来るのでは」という恐れなしに練習できるからです。プラン名・価格・上限は頻繁に変わるため、本書は特定の数字を載せていません。本書の内容は2026年半ばの時点を基準に書かれており、料金プラン・モデル・機能はその後も変わり続けます。現在の値は公式の料金ページで確認するのが最も正確です。

1行まとめ：使うたびにお金が出ていくのではという恐れ → 定額サブスクリプションなら毎月固定。入門は定額で始めると安心です。

1.0.4 ターミナルサバイバルキット — 黒い画面の恐怖を減らす

いよいよ最大の壁、黒い画面です。1.1が「点滅するカーソルの前でたじろぐ」から始まる理由がここにあります。GUIで24年働いてきた手にとって、ターミナルは不慣れなものです。しかし、最初の1行でつまずかないために必要なコマンドは、それほど多くありません。次の六つで十分です。

（Windows PowerShellでもls・cd・pwdはそのまま通ります。macOS・Linuxも同じです。つまり、この六つはOSを選びません）。

この六つですることを図にすると、次のようになります。ターミナルでの移動は、結局フォルダーの中と外を行き来することであり、GUIでフォルダーをダブルクリックしたり「戻る」を押したりするのと同じ動作です。

flowchart TD
    Q["pwd
ここはどこ？"] --> L["ls
ここに何がある？"]
    L --> D{"入るフォルダーが
見えるか？"}
    D -- "はい" --> IN["cd フォルダー名
中に入る"]
    D -- "いいえ、上へ" --> UP["cd ..
外に出る"]
    IN --> L
    UP --> L
    RUN["コマンドを打ったら"] --> ENT["Enter
実行"]
    STUCK["何かが止まったように見えたら"] --> STOP["Ctrl + C
中断してカーソルを取り戻す"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    class Q,L,IN,UP,ENT,STOP code
    class D human

黒い画面が怖い本当の理由は、「打ち間違えたら壊れそう」という感覚です。しかし、上の六つの中に何かを壊すコマンドはありません。pwd・ls・cdは見るか移動するだけで、ファイルを消したり変えたりしません。Enterは実行、Ctrl + Cは中断にすぎません。ですから、この六つはいつでも安心して打って大丈夫です。

画面が止まったように見えることがあります。コマンドを打ったのにしばらく反応がなかったり、カーソルが別の行で点滅して、さらに何かの入力を待っているように見えたりするときです。そんなときはCtrl + Cを一度押せば、たいてい元のカーソルに戻ります。この「停止ボタン」があると知っているだけでも、黒い画面はずっと怖くなくなります。行き詰まったらCtrl + Cで抜け出して、やり直せばいいのです。

最後に、打った文字が大量にたまって画面がごちゃごちゃしてきたら、画面を空にできます。Windows PowerShell・macOS・Linuxのいずれもclearコマンドで空にします。空にしても、やったことが消えるわけではなく、見えている文字が片付くだけです。

1.0.5 「5分で初回実行」チェックリスト

ここまで来たら、準備は完了です。次の五つの項目を5分以内に通過できれば、1.1の席に着く資格ができたということです。一つでもつまずいたら、該当する節（1.0.1〜1.0.4）に戻ってください。

flowchart LR
    C1["① ターミナルが
開く"] --> C2["② claude --version
バージョンが表示される"]
    C2 --> C3["③ claudeを実行 →
ログイン完了"]
    C3 --> C4["④ pwd・lsで
自分のフォルダーが見える"]
    C4 --> C5["⑤ Ctrl+Cで
抜け出せる"]
    C5 --> OK["✅ 1.1へ"]
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class C1,C2,C3,C4,C5 human
    class OK pass

• [ ] ① ターミナルを開ける（Windows：PowerShell / macOS：ターミナル）
• [ ] ② claude --versionと打つとバージョン番号が1行表示される（インストール確認）
• [ ] ③ claudeを実行するとログイン済みになっている（または案内どおりにログイン完了）
• [ ] ④ pwdで現在地を、lsでフォルダーの中身を見られる
• [ ] ⑤ 何かが止まったとき、Ctrl + Cで抜け出せる

五つの項目をすべて埋めたなら、黒い画面はもう未知の壁ではありません。ツールがインストールされ、ログインが済み、料金方式の全体像を知り、画面の中で移動し、止め方も分かっています。1.1はこの準備の上から始まります。点滅するカーソルの前に座り、初めて「このフォルダーに何があるか要約して」と打ってみる、その席に向かえば大丈夫です。

1.0.6 Python・pip — ツールを動かすには（必要なときだけ）

本書の前半（第1部・第2部）は、自然言語のプロンプトだけでついて来られます。ただし、第4部以降の一部の章では、小さなPythonスクリプトを直接動かします（例：pip install pyyaml、pip install pyvis）。Pythonが初めてでも大丈夫です。道は二つあります。

一つ目は、自分でインストールする道です。Pythonはpython.orgからダウンロードしてインストールし（インストール画面で［Add to PATH］に必ずチェックを入れます）、ターミナルでpython --versionと打って確認します。pipはPythonと一緒にインストールされるパッケージ管理ツールで、pip install pyyamlのように必要なパッケージを1行で取得します。

二つ目は、AIに任せる道（推奨）です。より簡単なのは、環境構築そのものをAIにやらせることです。ターミナルでこう頼めば大丈夫です。

Pythonが入っているか確認して、なければ自分のOSに合ったインストール方法を教えて。
あわせて、この章で必要なpyyamlパッケージをインストールするコマンドを1行でちょうだい。

（プロンプトの大意：「Pythonが入っているか確認して、なければ自分のOSに合ったインストール方法を教えて。あわせて、この章で必要なpyyamlパッケージをインストールするコマンドを1行でちょうだい」という依頼です）。

AIが環境を点検し、インストールコマンドを作ってくれます。行き詰まったら、その場でエラーメッセージをそのまま貼り付けて「このエラーはどう解決する？」と聞けば大丈夫です。ツールを動かす章ごとに、このパターン一つで十分です。Python・pipが負担に感じられる段階では、その章の「一人ミニ版」が、コードなしで進めるより軽い道を案内します。

次章のプレビュー

• 1.1 ゲームプランナーのClaude Codeとの初めての出会い — カーソルの前に座って最初の30分を持ちこたえる

やってみよう

setup 1. お使いのOSのターミナルを開きましょう（Windows：PowerShell、macOS：ターミナル）。 2. 「Claude Code 公式ドキュメント」を検索して、公式のインストール案内ページを開いておきましょう。 3. タイマーを5分にセットしましょう。1.0.5のチェックリストの五つの項目を通過するのが目標です。

prompt（1行ずつ、順番に打ってみましょう。これはコマンドであって、自然言語の質問ではありません）

① claude --version      # バージョンが表示されればインストール成功
② pwd                   # 今自分がどのフォルダーにいるか
③ ls                    # このフォルダーに何があるか
④ cd ..                 # 1段階上に出る (そしてもう一度ls)
⑤ claude                # Claude Code 実行 (ログイン案内が出たら従う)

（コメントの大意：① バージョンが表示されればインストール成功／② 今自分がどのフォルダーにいるか／③ このフォルダーに何があるか／④ 1段階上に出る（そしてもう一度ls）／⑤ Claude Codeを実行（ログイン案内が出たら従う））

verify - ①でバージョン番号が1行表示されれば、インストールは完了です。「コマンドが見つかりません」と出たら、ターミナルを閉じて開き直し、もう一度試してみましょう。 - ②・③・④でフォルダーを見たり移動したりしている間、何も壊れないことを自分の目で確かめましょう。この三つは見る・移動するだけの安全なコマンドです。 - ⑤の実行中に止まったように見えたら、Ctrl + Cで抜け出しましょう。抜け出せたなら、「停止ボタンがある」ことを体で確認できたということです。

一人ミニ版

チームも会社のフォルダーもない個人なら、まずインストール（①）と、Ctrl + Cで抜け出すことだけ先に身につけておきましょう。claude --versionで「ツールが入った」ことを、Ctrl + Cで「行き詰まっても抜け出せる」ことを確認できれば、黒い画面の恐怖の半分は、一人でも5分以内に片付きます。料金はまず定額サブスクリプションで始めれば、コストの心配なく思う存分練習できます。

1.1 ゲームプランナーとClaude Codeの最初の出会い

黒い画面が立ち上がりました。カーソルが点滅しています。その前に、24年目のゲームプランナーが座っています。PPTとExcel、WikiとFigmaで24年間働いてきた手が、キーボードの上で一瞬止まります。その昔、パソコン教室というものがあった時代のDOSのようにも見えます。それ以降、ターミナルというものはプログラマーの机の上でしか見かけない存在でした。何を打てばいいのか分からず、打ち間違えたら何かが壊れそうな気がします。このためらいが、本書の出発点です。

ほとんどの人は、ここでウィンドウを閉じます。そして会議でまた「うちも何かやってみないと」を繰り返します。本章は、そのウィンドウを閉じずに最初の30分を持ちこたえる席に、一緒に座ります。大げさな導入戦略ではなく、点滅するカーソルの前で何を打ってみれば距離感がほぐれるのかを、手に握らせることが目標です。

ゲームプランナーが初めてClaude CodeのようなAIコーディングツールの前に座ると、物珍しさと居心地の悪さが同じ場所で同時に湧き上がります。二つの感情が衝突するという事実そのものが、導入の最初の手がかりです。

物珍しさの理由ははっきりしています。半日ずつ食いつぶしていたマスターデータの整合性チェックが数分で終わり、だらだらと長くなった議事録が決定事項の表に要約され、1年前に埋もれていた仕様書を自然言語の一行で再び引っ張り出せるのです。

居心地の悪さの理由も同じくらいはっきりしています。黒い画面、点滅するカーソル、英語のコマンドが、日々の作業風景とあまりにも違います。ゲームプランナーの一日はGUIの上を流れていくのに、黒いターミナルに文字を打ち込む行為は、職務のアイデンティティとうまく結びつきません。ただし、この居心地の悪さはツールの欠陥ではなく、GUIに慣れた人間の適応コストです。この点を認めるだけで、距離感の半分はすでに片づいています。

本書は、その距離感を縮めるための本です。1.1では、最初の出会いの席に一緒に座り、何を見て、何を試し、何はいったん後回しにしてよいのかを整理します。

1.1.1 なぜ今、ゲームプランナーがAIを使うべきなのか

ゲーム企画は、ほかの職種より遅れてAIの流れに合流しました。コードを扱う人たちが先に、デザイナー・アーティストがその次に入っていきました。プランナーは「うちも何かやってみないと」を繰り返しながら先送りするパターンがよく見られました。

先送りした理由には合理性がありました。プランナーの成果物はコードのように定型化されておらず、テキスト・表・ダイアグラム・会議・口頭合意が一緒くたに混ざります。AI出力の信頼性は低く見え、もっともらしい嘘が危険であり、AIがゲームシステムを本当に理解しているのかも疑わしかったのです。

しかし2024〜2026年の間に、三つのことが変わりました。

第一に、AIモデルの推論能力が臨界点を超えました。単純な文章生成を超えて、複雑なシステム設計・整合性検証・影響分析を扱います。最新のClaude系列は、ゲーム企画ワークフローのかなりの部分を補助します。ただし、すべてを任せられるという意味ではありません。検証と責任は依然として人間の持ち分です（補助の幅は作業の種類とチームの成熟度によって大きく分かれます — 著者の推定、未検証）。

第二に、ハーネス（harness）が成熟しました。Claude Codeのようなツールは、単なるチャットではありません。ファイルを直接読み書きし、コマンドを実行し、その結果を再び入力として受け取ります。人間の働き方に似ています。

第三に、メモリー・atom・skillといった運用技法が定着しました。AIを一度使って終わりにするのではなく、チームの知識を蓄積して、時間が経つほど賢くしていく方法論が根づいたのです。本書の後半が扱う核心が、まさにこの蓄積です。

この三つがそろうと、ゲームプランナーにとってもAI導入が合理的なタイミングになります。これ以上遅くなる前に始めるほうが得です。

1.1.2 Claude Codeとは何か — ほかのツールとの違い

プランナーがよく目にするAIツールは2種類です。チャット欄に質問を投げるチャットボット型（ChatGPT、Claudeウェブアプリ）と、コードエディターの中で自動補完を行うエディター統合型（Cursor、Copilot）です。

Claude Codeは第三の部類です。CLI（ターミナル）で動作し、人間の作業環境全体にアクセスします。三つの部類がどこで分かれるのかを1枚で見ると、次のとおりです。

ゲームプランナーの作業はコードではなく、文書・表・関係です。Claude Codeの強みは、人間が働くフォルダー全体を見て、理解し、操作するという点です。チャットボットのように、毎回資料をコピーして貼り付ける必要はありません。

オフィスにたとえると、チャットボット型は受付デスクです。質問1回に回答1回、資料は毎回出し直さなければなりません。Claude Codeは隣の席の同僚に近い存在です。資料がどこにあるかを知っていて、自分の手でファイルを開き、結果を整理してまた机の上に置いてくれます。同じClaudeでも、どの机に座らせるかによって得意な仕事が変わるのです。

1.1.3 最初の30分 — 何を見て、何を試すのか

インストール・設定は1.0で扱います。1.1では、最初の30分に何を経験すれば距離感が縮まるのかに集中します。最初の30分は四つの区間に分かれ、区間ごとに距離感の一部が段階的に消えていきます。

flowchart LR
    A["見る（5分）
このフォルダーを要約して
→『自然言語が通じる』"]
    B["検索（5分）
キーワード・最近のファイル探し
→『毎日の雑務を肩代わりする』"]
    C["変換（10分）
議事録→表、Excel→Markdown
→『時間を生み出してくれる』"]
    D["検証（10分）
直前の出力を疑う
→『このツールは疑われるべきだ』"]
    A --> B --> C --> D
    D --> E["距離感80%解消"]
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class A,B,C ai
    class D human
    class E pass

最初の5分 — 見る

ターミナルを開いてClaude Codeを実行すると、黒い画面が立ち上がり、カーソルが点滅します。多くの人はここで立ち止まりますが、立ち止まると、距離感がほぐれる最初の機会を逃してしまいます。自然言語の一文を入力します。

このフォルダーに何があるのか要約して

コードでもコマンドでもない、一つの文です。Claude Codeはフォルダー構造をスキャンし、どんなファイルがあるのか、何を扱うプロジェクトに見えるのかを整理して答えます。企画文書が入ったフォルダーでこの一行を打つと、おおよそ次のような応答が返ってきます。

このフォルダーに何があるのか要約して


このフォルダーをスキャンしました。ゲームデータ・企画文書の作業フォルダーと見られます。

  ファイル種類      個数    内容の推定
  ─────────────   ────    ───────────────────────────
  .xlsm            12     データシート (アイテム・クエスト・NPCなど)
  .md              34     企画書・議事録の草案
  .png             88     UIモックアップ・リファレンス画像
  サブフォルダー      6     /data /docs /ref /meeting /export /tmp

観察:
  - /meeting フォルダーに直近1週間の議事録5件が溜まっています。
  - item_table.xlsm と quest_table.xlsm が同じIDカラムを
    共有しているように見えます(FK候補)。
  - /tmp フォルダーに一時exportファイルが多数 — 整理対象かもしれません。

何から先に見てみましょうか？

この一度の応答で、「このツールはコマンドではなく自然言語を理解する」という事実が体に染み込みます。フォルダーを直接開かなくても、何がどこにあるのかが整理された見取り図を受け取る経験が、距離感の半分をその場で削り取ります。

次の5分 — 検索

小さな検索をさせてみます。「直近1週間に修正されたMarkdown（マークダウン）ファイルを5個教えて」や「『リワード』という単語が入ったファイルはどこにある？」のような頼み方です。プランナーが毎日Find in Filesを開き、キーワードを打ち込み、結果をスクロールしていた仕事を、Claude Codeは自然言語で受け取り、整理して返してくれます。このツールが毎日の雑務を肩代わりしてくれるという感覚が、二度目の5分で根を下ろします。

次の10分 — 変換

小さな変換をさせてみます。「この議事録から決定事項だけを抽出して表にして」や「このExcelシートの1〜10行をMarkdownの表に変えて」のような頼み方です。手作業なら5〜10分かかる変換が短い時間で処理される経験は、ツールが検索を肩代わりするにとどまらず、時間を生み出してくれるという感覚につながります。

最後の10分 — 検証

ここで止まると危険なのは、AIがもっともらしい嘘をつくからです。たった今つくられた出力を、ツール自身に疑わせます。

さっき作ってくれた表が原本と一致するか、もう一度確認して。抜けている項目はある？

するとClaude Codeは原本を読み直し、自分の出力と一行ずつ突き合わせて、不一致を報告します。実際、この区間ではこんな画面がよく出てきます。

さっき作ってくれた表が原本と一致するか、もう一度確認して。抜けている項目はある？


原本(meeting_0603.md)とさっき作った表を再度照合しました。
3件の不一致を見つけました。

  ⚠ 欠落   「チュートリアル報酬50%下方修正」 — 原本の12行目にあるが表から漏れ
  ⚠ 誤記   担当者「キムOO」 → 表には「イOO」と誤って記入
  ⚠ 曖昧   「リワード再協議」 — 決定なのか保留なのか原文が不明確。
           私が独断で「決定」に入れましたが、確認が必要です。

修正した表を作り直しましょうか？ 曖昧な項目はどう処理するか
教えていただければ反映します。

ツールが自分の出力を疑えるという点、そしてその疑いを人間と一緒に行うという点が、最後の10分の核心です。三つ目の項目のように「自分が独断で判断したので確認してほしい」と問い返す態度こそが、検証を人間の手に残す安全弁です。

30分が経つころには、距離感の80%は消えています。残りの20%は、続く章で少しずつ縮んでいきます。

1.1.4 会社で見た風景 — 中規模チームの6か月

著者が企画ディレクターとして運営しているあるMMORPGプロジェクト（以下「プロジェクトA」）では、企画チーム（4〜5人）と約6か月間、Claude Code中心のワークフローを運用してきました（プロジェクトA全体の開発チームは中規模、10〜50人）。いくつかの風景を書き写します。

最も手応えのある1件だけを、実測として切り出してみましょう。30余りのマスターデータシートにまたがるFK（外部キー）整合性チェックです。あるシートのIDがほかのシートで正しく参照されているかを人間の目で追いかける作業で、シートが増えるほど組み合わせは幾何級数的に膨れ上がります。

• Before：プランナーが1人でシートを交互に開き、IDを突き合わせ。30余りのシートを1回巡回するのに半日（約4時間）。途中で集中が途切れると、見落とす行が出てきます。
• After：関係検出ツールがシート間のFKを自動で突き合わせ、壊れた参照だけをリストで出力。1回の巡回は約5分。

半日から5分へ。この一行を一般化するつもりはありません。ほかの作業は削減幅がもっと小さかったり、レビュー時間が新たに付いたりもします。同じ6か月の間に見たほかの風景は、方向と比率だけで記します。

• 議事録からの決定事項抽出（週5〜10件の累積）：人間が検索・スクロールで追跡していた仕事 → 自動抽出の表へ。追跡の負担はほぼ消滅。
• GDD（Game Design Document）草案：作成時間が半分以下に減り、代わりにレビュー・推敲の時間が増えました。総量は減るものの、仕事の重心は「書く」から「判断する」へ移行。
• マスターデータの関係図：会議で口頭で繰り返し説明していた依存構造 → インタラクティブHTMLとして一度生成して共有。

各ツールが一度つくられたあと、6か月間に積み上がった節約時間は、人週（person-week）ではなく人月（person-month）単位だというのが著者の体感です（正確な合算は未測定、推定値）。その時間で、より深い企画に集中できるようになりました。

こうしたツールは、一度つくられると長く働きます。ただし「長く」がそのまま「無人」ではありません。運用する人間と検証の仕組みがそろってこそ長持ちし、ツールだけを残して人間が去れば、2四半期のうちに朽ちていきます。本書の後半の部では、上記のツールそれぞれがどのようにつくられ、運用されるのかを扱います。

1.1.5 不安と期待 — 正直に向き合う

ゲームプランナーがAIツールの前でよく抱く不安を、正直に押さえておきましょう。目をそらさずに扱うことが、導入の第一歩です。

「AIが自分の仕事を奪う」という不安は、半分は当たっていて半分は外れています。単純な雑務（整合性チェック・文書変換・検索）はAIが置き換えますが、決定・優先順位・プレイヤー感情の設計は置き換えられません。むしろAIをうまく使うプランナーは、雑務から解放されて本質に集中します。自問してみましょう。「自分の仕事のうち、雑務と本質の比率は？」雑務が70%なら、本質の30%はそのまま本人の持ち分であり、その30%がより重要になることが核心です。

「AIが間違えたら責任は誰が取るのか」という質問もよく出ます。プランナーの決定に対する責任は、いつでもプランナーのものです。AI出力を検証なしにそのまま使うのはプランナーのミスであって、AIのミスではありません。検証手順を一緒に設計することが、導入の一部です。1.1.3の最後の10分で見た「自分の出力を疑わせる」が、その手順のいちばん小さな種です。

「コードがよく分からないから使えない」という不安は、すぐにほどけます。Claude Codeは自然言語で動くので、コードを知らないなら知らないなりに始められます。AIがつくったスクリプトを一緒に読むため、数か月もすれば簡単なスクリプトは読んで修正できるようになります。学習が自動的についてくるのです。

「ツールの変化が速すぎる」もよくある心配です。モデル・機能・トレンドをすべて追いかけようとすると疲れてしまいます。自分のワークフローに役立つ1〜2個の機能だけを深く身につけ、残りは必要なときに見れば十分です。

あらかじめ断っておきます。1.1.3の応答画面が滑らかに見えたとしても、実際の最初の30分には、的外れな答え、見当違いのファイル要約、もたつく出力が混ざって出てきます。それが正常です。本書は滑らかな成功談ではなく、外れた出力をどう要求し直して正すのかのほうを、多く扱います。

1.1.6 本書の使い方

本書は24の部で構成されています。最初から最後まで順番に読む必要はありません。次の三つのパターンから、自分の状況に合うものを選んでください。

どの道を選べばよいか見当がつかないなら、自分がどれに近いかで分ければ大丈夫です。ゲーム外のプランナー・PM・一般のオフィスワーカーなら、上の三つのパターンの代わりに「一般職務の道」（第1・2部 → 第17部 議事録 → 第16部 コラボレーション → 第18部 意思決定 → 第21・22部 自己改善・ガバナンス）をおすすめします — ゲームドメインの章を飛ばしても核心の骨格はそのまま立ち、各章の「ゲーム外への応用」ボックスが、自分の職務へ読み替える橋になります（索引は付録F.5）。時間がなければ、17.1 → 16.2 → 22.1 → 21.1の4章だけたどっても構いません。AIツールを始めたばかりの専門外の読者なら、「導入パターン」で自分の分野（または最も近い分野）を一つだけ最後までやり抜き、深い分野の部（4・8・11など）は導入部の「非専門者のための一行」だけ押さえて、必要なときに本文へ降りていけば大丈夫です。

本書のすべての章は、学術的な深さまでは行かず、運用可能な水準で止めています。中規模チームで6か月間実際に回った技法をそのまま書き写し、小さく始めて大きく育てる道を一緒に歩くことが目標です。

1.1.7 次の章へのつながり

1.1は距離感を縮める章でした。1.2では一段階内側に入り、このツールの基本メカニズムを、ゲームプランナーに親しみやすい言葉で説明します。モデル・トークン・コンテキスト・ハーネスといった単語を怖がらなくて済むようにすることが、1.2の目標です。本格的なセットアップ（メモリー・権限・settings.json）は1.3で扱います。

本章のポイント

• 最初の出会いの距離感はツールの欠陥ではなく、GUIに慣れた人間の適応コストです
• Claude Codeはチャットボットではなく、フォルダー全体を扱う隣の席の同僚に近い存在です
• 最初の30分で「見る・検索・変換・検証」を一度ずつ通過すれば、距離感の80%は消えます

次章のプレビュー

• 第2章 AIモデル・トークン・ハーネス — ゲームプランナーのための基本メカニズム

やってみよう

setup 1. ターミナルを開きましょう（WindowsはPowerShell、macOSはターミナル）。 2. 企画文書が集まったフォルダーに移動してから、Claude Codeを実行しましょう（インストールは1.0）。 3. タイマーを30分にセットしましょう — 5分（見る）・5分（検索）・10分（変換）・10分（検証）。

prompt（1区間に1行ずつ、順番に打ってみましょう）

① このフォルダーに何があるのか要約して
② 「リワード」という単語が入ったファイルはどこにある？
③ この議事録から決定事項だけ抜き出して表にして
④ さっき作った表が原本と一致するか、もう一度確認して。抜けている項目はある？

verify - ①でフォルダー構造の要約が実際のフォルダーと合っているか、目で突き合わせましょう。 - ④の不一致報告が1件でも出れば成功です。AIが自分の出力を疑う場面を直接見たという意味です。 - 的外れな答えが出ても失敗ではありません。「さっきの答えは間違っている、このファイルだけ見直して」のように要求し直すところまでが、最初の30分の練習です。

一人ミニ版

チームも会社のフォルダーもない個人なら、自分のPCの適当な作業フォルダー一つ（例：ダウンロードフォルダー、メモフォルダー）で、上のprompt①と④だけ打ってみましょう。①で「自然言語が通じる」を、④で「出力を疑わせられる」を確認できれば、本章の核心の二つは、一人でも5分以内に体感できます。

1.2 モデル・トークン・ハーネス — 一つの作業のトークンが流れる道

一つの作業を終えて、使用量を見たときのことです。今週の議事録が5件フォルダーに溜まっていて、月曜午前のスタンドアップの前までに「決定されたことだけ」を1枚にまとめなければなりません。私はClaude Codeのウィンドウに一行を打ち込みます。「このフォルダーの議事録から決定事項だけを抜き出して表にして」。エンターを押してから0.4秒ほど、画面の下のほうで小さな灰色の文字が点滅します。

Reading meeting-2026-05-25.md ... (1,840 tokens)
Reading meeting-2026-05-27.md ... (2,310 tokens)

この灰色の文字が本章のテーマです。韓国語の一文を投げると、ツールはそれをトークンに刻み、ファイルをトークンとして読み込んでモデルに入れ、モデルの答えを受け取ってファイルに書き込みます。この往復が1回回るたびにコストが計上され、モデルの「視野」に資料が積み上がっていきます。本章では、その灰色の文字の裏で起きていることをゲームプランナーの言葉で分解します。モデル・トークン・コンテキスト・ハーネス、四つの言葉で十分です。

用語メモ - モデル（model）：答えを作る頭脳。Opus・Sonnet・Haikuのように、サイズと性格の異なる種類があります。 - トークン（token）：文章を細かく刻んだ断片。課金・速度・視野はすべてこの単位で数えます。 - コンテキストウィンドウ（context window）：モデルが一度に頭の中に収められるトークンの最大量。 - ハーネス（harness）：モデルを働かせる車体。Claude Codeがその例です。

1.2.1 ハーネスループ — 灰色の文字の正体

先ほどの灰色の文字は、ランダムなログではなく、決まった循環の中の一つのボックスです。ハーネスがしていることは、結局のところ同じループを高速で回すことです。ファイルを読み込んでモデルに入れ、モデルが「このコマンドを実行せよ」と言えば実行し、その結果を再びモデルに入れます。このループが作業の終わりまで回り続けます。

flowchart TD
    Start([人間：一行の指示]) --> Read[ハーネス：ファイル・資料の読み込み
トークンに変換]
    Read --> Inject[ハーネス：コンテキストに注入
+ 累積トークンを合算]
    Inject --> Model{モデル：次の行動を決定}
    Model -->|コマンド実行が必要| Exec[ハーネス：シェルコマンド・スクリプトを実行]
    Exec --> Result[実行結果を
トークンとして再入力]
    Result --> Inject
    Model -->|回答が準備できた| Write[ハーネス：ファイル書き込み・出力]
    Write --> Verify{検証通過？}
    Verify -->|失敗| Inject
    Verify -->|通過| Done([結果を保存])
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class Start,Verify human
    class Read,Inject,Exec,Write code
    class Model ai
    class Result data
    class Done pass

この図で人間が手を触れるボックスは、いちばん上（指示）といちばん下（検証結果の確認）の二つだけで、真ん中のループはハーネスが自律的に回します。議事録5件を読み込む間に灰色の文字が5回点滅したのは、Read → Injectのボックスを5周したということです。Webチャットなら、ファイル5個を自分で開いてコピー＆ペーストしなければなりません。その労働をハーネスが肩代わりしてくれること。これがチャットボットとCLI型ハーネスを別の道具にする決定的な違いです。

ループが1周するたびに、Injectのボックスで累積トークンが合算されます。だからトークンを先に理解しないと、このループのコストも限界も見えてきません。まずトークンから見ていきます。

1.2.2 トークン — 一つの作業が使う実際の通貨

トークンは文字ではなく、モデルが文章を刻んだ断片です。経験則として、英語はおよそ4文字で1トークン、韓国語はおよそ2文字で1トークンに近い値になります（公式の換算ではなく、あくまで運用上の目安です。実際の値はモデルのトークナイザーが決め、文章ごとに異なります）。韓国語でスペース込み20文字なら、だいたい10トークン前後です。

あの議事録作業をトークンで追いかけてみます（以下の数値は同一作業の単一測定1回分です。議事録の分量や要約の長さによって変わるため、絶対値ではなく桁数と比率で読むことをおすすめします）。

二つのことが目に留まります。第一に、私が打った指示は25トークンなのに、作業全体では入力だけで1万1000トークンを超えています。コストのほとんどすべてが、私の文章ではなくツールが読み込んだ資料から発生しているのです。第二に、出力（1,810）は入力（11,225）の6分の1程度です。企画業務の自動化の大半は、このように多く読んで少なく書きます。だからコストを減らすには、出力を磨くより入力資料の量を制御するほうがはるかに効果が大きいのです。

作業が終わったあとに/contextを打つと、そのセッションがコンテキストをどれだけ占有したかが見えます。トークンは意識しなければ印刷用紙のように無意識のうちに流れ出ていきますが、一度可視化すると姿勢が変わります。この可視化が節約の出発点です。

トークンを制御する道具は、抽象的な節約精神ではなく、入力資料を細かく扱う具体的なテクニックです。

1. JIT注入 — 資料を全部あらかじめ積み込むのではなく、必要なときだけキーワードマッチングで引き込みます。上の表の「分類ルールの注入480トークン」がその例です。会議分類ルールの文書全体（数千トークン）ではなく、マッチしたatom 1件だけが入ってきました。
2. 要約キャッシュ — 長い文書は、人間用の原本とは別にAI用の要約版を置きます。AIは要約版を読みます。
3. atom分割 — 一つのファイルに一つの決定だけを収めれば（2.2で詳述）、必要な断片だけを正確に引き込めるので、トークンが節約できます。
4. コンテキスト整理 — セッションが長くなったら圧縮します。Claude Codeは自動圧縮をサポートしています。
5. モデル選択 — 単純な変換に大きなモデルを使うと、同じトークンでもコストが高くつきます。次の節のテーマです。

このうち1番のJIT注入は、本書の作業環境で実際に回っている仕掛けです。入力が一行入ってくると、inject_memory.pyフックがメモリーatomをスコア順にマッチングして上位数件だけを選んで注入し、失敗しても作業の流れを止めません（実装の詳細は1.3で詳述）。「必要な資料だけ、上位数件だけ、失敗しても静かに」というトークン節約の原則が、コード1ファイルにそのまま収まっています。

1.2.3 モデル — 同じ車体、異なるエンジン

モデルは自動車のエンジンのようなもので、Claude Codeという同じ車体にOpus・Sonnet・Haikuという異なるエンジンを載せ替えられます。エンジンを替えると作業の性格が変わります。

企画作業に当てはめると、こう分かれます。システム設計のレビューや、複数の資料を統合するGDD（Game Design Document、詳細仕様書）ドラフトの合成のように深い推論と整合性が必要な仕事はOpus、議事録からの決定抽出や日次要約のような日常作業の大半はSonnet、マスターデータの単純なフォーマット変換のようにほとんど判断のいらない仕事はHaikuに振ります。前の節の議事録作業をSonnetで回したのもこの基準です。決定を選んで表に移す仕事には、深い推論よりバランスと速度が合っています。

導入初期に誰もがはまる罠があります。すべての作業をいちばん良いエンジン、つまりOpusで回したくなる衝動です。その衝動に従うと、コストと速度の負担がそのまま運用の負担として返ってきて、作業にモデルを合わせる感覚が身につきません。運用の本当の技術は、毎回頭の中でモデルを選ぶことではなく、パターンが固まったあとに自動化として固定しておくことです。

• 日次の振り返り作成 → 自動的にSonnet
• システム設計レビュー → 自動的にOpus
• マスターデータの整合性チェック → 自動的にHaiku

こうした固定は、settings.jsonやスラッシュコマンドの中にモデルを明示しておくことで行います（1.3で詳述）。一度固めれば、毎回選ぶ手間がなくなります。

モデルはおおむね半年周期で新バージョンが出て、同じ名前でも4.5と4.6は別物です。新バージョンが出たら、ワークフローの中核となる作業5個だけを同じ入力で比較します。全部テストしようとすると疲れ果てます。5個の結果の違いだけでも、乗り換えるかどうかの判断には十分です。

1.2.4 コンテキストウィンドウ — ループが満ちていく限界

ループが1周するたびにInjectのボックスでトークンが累積すると述べました。その累積がぶつかる天井がコンテキストウィンドウ、つまりモデルが一度に処理できるトークンの最大量です。人間でいえばワーキングメモリー（working memory）です。

• Claude 4系：標準200Kトークン、拡張1Mトークンのオプション
• 200Kトークン ≈ 韓国語基準でA4約400ページ分

先ほどの議事録作業は累積入力が1万1000トークン台で、200Kの天井に対して6%あまりと余裕があります。しかし作業を切り替えずに同じウィンドウでセッションを長く引きずると、天井に近づいていきます。満杯になると古い内容が切り捨てられ、モデルが前半の「記憶」を失い始め、自動圧縮が発動して以前の会話が要約版に置き換えられます。

この天井を制御する習慣は四つです。

ゲームプランナーがよく出会う重いケースは、会議資料・仕様書・マスターデータが同時に必要な作業で、こういうときに1Mオプションが役立ちます。ただし1Mにはコストと速度の負担が伴うので、普段は200Kで十分、資料の束が本当に大きいときだけ取り出します。

1.2.5 ハーネスが実際に嘘をふるい落とすとき — 検証ボックス

ループ図のいちばん下にある검증 통과?（検証通過？）のボックスに戻ります。このボックスがなければ、モデルのもっともらしい嘘がそのままファイルに保存されます。モデルは自信満々に間違った答えを正解のように出すことがあり（ハルシネーション、hallucination）、その頻度は世代が上がるほど減りますが、0にはなりません。だから検証を常設のボックスとして置きます。

企画の現場で危険なハルシネーションは具体的です。存在しないマスターデータのカラムを引用したり、間違った数式でバランスを計算したり、会議で決定されていない事項を決定済みのように要約したりします。議事録作業でいちばん怖いのは三つ目です。「議論だけして保留になった件」が決定の表にしれっと載ってくるケースです。

検証には五つのパターンがあります。

1. 原本照合 — AIの出力を原本資料ともう一度比較します（「これが本当にその資料にあったのか確認して」）。
2. 双方向変換 — A→Bに変換したあとB→Aに逆変換して、一致するかを見ます。
3. サンプルチェック — 出力のうち無作為の3〜5件を人が直接確認します。
4. Linterによる自動化 — 出力が決められた形式・範囲・ルールに違反していないかを自動検査します。
5. 2モデルのクロスチェック — Sonnetの出力をOpusがレビューします。

五つを毎回すべて行うのではなく、作業のリスクに応じて1〜3個を選びます。議事録作業では、4番のLinter（「決定に主体・内容・期限がすべて揃っているか」）と3番のサンプルチェック1回を組み合わせました。先ほどのトークン表の最後の行「検証の再入力320トークン」が、まさにLinterが漏れを捕まえてモデルに問い直したその往復で、ループ図でいえば검증 실패 → Inject（検証失敗 → Inject）としてもう1周回ったということです。

毎回人がすべてを検証していては導入効果が半減するので、検証もまた自動化の対象です。議事録の決定抽出ではLinterが形式の漏れを、マスターデータ変換では行数・合計・外部キーの整合性を、GDD自動生成では主要セクションの欠落を自動検査します。通過すれば人は見なくてよく、通過しなかったものだけを見ます。キャビネットいっぱいの書類のうち、赤い印のついたフォルダーだけを手に取る風景です。人の視線が危険な場所にだけ落ちるように設計すること。それが検証自動化の目的です。

1.2.6 四つの言葉が一つの作業に束ねられる場所

最後に、あの議事録作業を最初から最後まで、四つの言葉がどのように一本の糸に通されるのかを整理します。

手作業なら、議事録5件を開いて読み、決定だけを選んで書き写し、形式を整えるのに30分かかります。自動化されると5分に縮み、その5分の中で人の手がすることは、検証サンプルを一度ざっと確認することだけです。人の時間が本当に必要な場所（保留の件が決定として誤って載っていないか）にだけ、視線が落ちます。節約された25分ではなく、その視線の行き先が変わったこと。それが核心です。

1.2.7 よくある誤解

「Opusが常に優れている」が最もよくある誤解です。コストと速度を無視すればそのとおりですが、単純作業にOpusは無駄遣いです。作業ごとのマッチングが答えです。

「1Mコンテキストが常に必要だ」もよく出てきます。大半は200Kで十分で、1Mには負担が伴うので、本当に大きな資料の束にだけ使います。

「検証は人がやるもの」は半分だけ正しい考えです。自動検証できる部分が大半で、人は残りに集中します。

「トークンは気にしなくていい」は個人作業ではある程度通用しますが、複数人で一緒に使うと累積コストが急速に膨らみます。初期から可視化と節約のパターンを定着させるほうが安全です。

「ハーネスに違いはない」も意外と多い誤解です。同じモデルでも、チャットボットかCLIかで別の道具のように分かれます。先ほど見たコピー＆ペースト労働の有無がその違いです。

1.2.8 やってみよう

小さな作業一つで、本章の四つの言葉を自分で回してみましょう。

setup

• Claude Codeがインストールされた状態で、テキストノート（議事録・メモ）が2〜3個入ったフォルダーを一つ用意してください。
• そのフォルダーでClaude Codeを開いてください。

prompt

このフォルダーのノートから「決定されたこと」だけを選んで
主体・内容・期限の3列の表にして。
保留・議論中の件は除いて、表に入れた各行が
どのファイルから来たのかファイル名も一緒に書いて。

verify

• 作業が終わったら/contextを打って、このセッションが使ったトークンを見てみましょう（思ったより入力が大きいことが確認できます）。
• 表の行を1〜2行選んで、書かれているファイル名を開き、本当に「決定」と書かれていたか原本と突き合わせてください（原本照合の検証）。
• 保留だった件が表に誤って載っていないか、一度ざっと確認してください（サンプルチェック）。

一人ミニ版

ツールを始めたばかりなら、上のうち二つだけを押さえてください。第一に、ノートはフォルダーごと任せて、コピー＆ペーストを自分でやらないこと（ハーネスループに任せます）。第二に、出力の表は必ずファイル名つきで受け取り、疑わしい行だけ原本を開いて見ること。モデル選択やトークンの可視化は、慣れてから足しても遅くありません。資料を手で運ばないことと、出力を原本と突き合わせること。この二つの習慣だけで、導入の半分は土台が固まります。

本章のポイント

• ハーネスは「読み込み→実行→再入力」のループを自律的に回し、人は指示と検証の二つのボックスにだけ手を入れます
• 一つの作業のコストは、自分が打った指示ではなく、ツールが読み込んだ資料からほとんどすべてが発生します
• モデルは作業に合わせて載せ替え、コンテキストの天井と検証は自動化で制御します

次章のプレビュー

• 第3章 メモリー・権限・設定インフラ — 一度セットアップすれば永久に働く基盤

1.3 メモリー・権限・設定インフラ

新しいセッションを開き、「スキルのクールタイムバランスをちょっと見よう」と入力しました。エンターを押す前、画面の下のほうに小さなグレーの文字が1行、すっと流れていきます。[memory injected: 2 atoms, 1,842 chars]。私は何のファイルも開いていないのに、先週ルール化しておいたクールタイム（クールダウン）ルールの文書が、すでにモデルの入力の前に付け加えられて入っているという意味です。これが、インフラの敷かれた作業環境の最初のシグナルです。ツールを立ち上げた瞬間、ツールが私を覚えているのです。

この場面が可能になるためには、3つのものがあらかじめ整っていなければなりません。AIが何を記憶するか（メモリー）、AIが人の承認なしに何をできるか（権限）、その2つをオン・オフする中央スイッチ（settings.json）です。最初のセットアップにかかる時間は長くても1時間で、その1時間は以降6か月間、毎日節約される時間として返ってきます。ほぼ全額回収できる投資です。

この章は、著者が実際に個人PCで動かしているsettings.jsonの1行、その1行が呼び出すinject_memory.py、そのファイルが読み込む_jit_manifest.jsonを順に開いてたどるウォークスルーです。最後まで読めば、「メモリーが自動注入される」という言葉が、どのファイルのどの行で起きていることなのか、手で指し示せるようになります。

1.3.1 settings.json — すべてが始まる1行

まず結論から見ます。著者の個人PCでメモリー自動注入をオンにしているのは、settings.jsonの中のたった1つのブロックです。

{
  "hooks": {
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python ~/.claude/hooks/inject_memory.py"
          }
        ]
      }
    ]
  }
}

このブロックの意味を日本語に訳すと、こうなります。「ユーザーがプロンプトを送信するイベント（UserPromptSubmit）が起きるたびに、inject_memory.pyというPythonスクリプトを1回実行せよ」。それだけです。AIが賢くて勝手に記憶しているのではなく、入力が入ってくるたびに、人が登録しておいたスクリプトが1回ずつ割り込む構造です。

settings.jsonはClaude Codeのすべての動作を制御する中央ファイルで、2つの層に分かれています。

• ~/.claude/settings.json — グローバル。すべてのセッションに適用。チームと共有できる設定。
• ~/.claude/settings.local.json — ローカル。このPCだけに適用。個人PC特有の設定。

2つはマージされて適用されます。そのため著者は、チームで共有すべきフックや権限はsettings.jsonに、この自宅PCだけで使う絶対パスや個人ツールのパスはsettings.local.jsonに分けて置いています。コラボレーション時のgitコンフリクトを避け、個人設定がチームのリポジトリに漏れる事故を防ぐ分離です。

よく使う項目は、フックのほかにもいくつかあります。

• effortLevel — モデルの推論の深さ。low / medium / high。仕様書の設計のように深い判断が必要な作業はhighにしておきます。
• permissions — AIが承認なしに実行できるコマンドの範囲（1.3.4で詳述）。
• enabledPlugins — 有効化されたプラグインのリスト。

ここで最も重要な、たった1つの運用習慣があります。settings.jsonは、小さなタイポ1つでツール自体が起動しなくなります。JSONのカンマが1つ欠けるだけでパースが壊れます。だから変更前のバックアップが必須です。著者のPCには実際に、こんなバックアップファイルが残っています。

settings.json.bak_2026-05
settings.local.json.bak_2026-05

日付のsuffixを付けて1部とっておけば、ロールバックは1秒です。gitで管理すればさらに良いでしょう。引き出しの中の古い合鍵のように、普段は使わなくても、鍵のかかったドアの前で必ず一度必要になる瞬間が来ます。

1.3.2 inject_memory.py — フックの中で実際に起きていること

今度は、settings.jsonが呼び出したスクリプトの中に入ります。ウォークスルーの背骨です。コードは100行余りですが、核心は5つの動作です。

flowchart TD
    A["セッション: ユーザーがプロンプトを送信\n例: 'スキルのクールタイムバランスを見よう'"] --> B["UserPromptSubmitフックが発動\nsettings.jsonがinject_memory.pyを実行"]
    B --> C["_jit_manifest.jsonをロード\natom 17個のメタデータ"]
    C --> D["scoreの降順でソート\n→ atomごとにregexマッチを試行"]
    D --> E{"マッチしたatomは\nあるか?"}
    E -->|なし| Z["何も注入しない\nexit 0"]
    E -->|あり| F["上位max_matches(3)個のみ選択"]
    F --> G["合計6,000字を超えたら\ntruncate"]
    G --> H["ユーザー入力の前に\natom本文を添付"]
    H --> I["モデルがatom + プロンプトを\nまとめて受信 → 応答"]
    D -.->|どんな例外でも| Z2["例外は無条件に握りつぶす\nexit 0 (フローを止めない)"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    class A human
    class B,C,D,E,F,G,H code
    class I ai

5つの動作を順に書き下すと、こうなります。

1) manifestを読む。 スクリプトはまず~/.claude/projects/C--Users-user/memory/_jit_manifest.jsonを開きます。このファイルにはatomのメタデータ（名前・パス・マッチ用regex・スコア）が整理されています。著者の個人PCには現在17個のatomが登録されています。

2) scoreの降順でソートする。 atomごとにscore値があります。スコアの高いatomほど先にマッチを試行されます。同じキーワードに複数のatomがヒットするとき、どれが優先権を持つかをこのスコアが決めます。

3) regexでマッチする。 ユーザーの入力文字列を、各atomのregexパターンと照合します。入力に「쿨다운」（クールタイムを意味する韓国語キーワード）があれば、쿨다운|cooldown|GCDのパターンを持つatomがヒットします。大文字・小文字は区別せずに比較します。

4) 最大3個までに絞る。 マッチがどれだけ多くても、max_matches（著者の環境では3）を超えたら上位3個だけを残します。さらに、選ばれたatom本文の合計の長さが6,000字を超えたら切り詰めます（truncate）。二重の上限で、入力が肥大化するのを防ぐ安全装置です。

5) どんな例外でもexit 0で終わる。 設計の核心です。manifestが壊れていても、ファイルが消えていても、regexが間違っていても、スクリプトは例外を静かに握りつぶし、終了コード0で終わります。フックが0以外のコードで死ぬと、ユーザーのプロンプト自体がブロックされることがあるからです。「メモリー注入が失敗しても、ユーザーの作業フローは絶対に止めない」という原則が、コードのいちばん外側のtry/exceptに記録されています。

重心は4番と5番にあります。4番（上限）はメモリーがトークンを爆発させないように抑え、5番（例外の握りつぶし）はインフラが作業を妨げないように抑えます。どちらも「自動化が人の足かせにならない」という同じ哲学の2つの顔です。

1.3.3 _jit_manifest.json — atomを呼び起こすキーワード辞書

1.2では「必要な資料だけ、上位数個だけ、失敗しても静かに」というトークン節約の原則を約束し、実装のディテールをこの章に持ち越しました。そのディテールが住んでいる場所が、inject_memory.pyが読むmanifestです。JIT（Just-In-Time、必要なときだけ資料を呼び込む方式）の心臓部であり、atom 1つのエントリは次のような形をしています。

{
  "atoms": [
    {
      "name": "combat_cooldown_rule_v2",
      "path": "atoms/combat/combat_cooldown_rule_v2.md",
      "regex": "쿨다운|cooldown|GCD",
      "score": 80
    },
    {
      "name": "user_health",
      "path": "memory/user_health.md",
      "regex": "건강|복약|컨디션|약물",
      "score": 95
    }
  ],
  "config": {
    "max_matches": 3,
    "case_insensitive": true
  }
}

4つのフィールドが1つのatomを定義します。

• name — atomの固有名。
• path — マッチしたら本文を読み込むファイルパス。
• regex — どのキーワードが入力に入ってきたらこのatomを呼び起こすかを定義するパターン。
• score — ソートの優先順位。高いほど先にマッチされ、先に枠を確保します。

configブロックのmax_matches: 3は、1.3.2で見た「最大3個」上限の出どころです。manifestを手で直せば、動作は即座に変わります。

規模の感覚を1つ押さえておきます。著者の個人PCはatom 17個、manifest 1式で軽く運用されています。一方、会社の実務環境（プロジェクトA）は、2026年5月時点のバックアップでチームatom 304個、skill 48個が登録されています。Hot atomの1つはscoreが356.53まで上がっていますが（ファイル名規則を扱うview_html_filename_convention系列）、最初から高かったのではなく、繰り返し呼び出され、検証されながら積み上がった痕跡です。

個人PCの17個と会社の304個の差が語っているのは、同じJITメカニズムでも、資料が積み上がる速度と規模はプロジェクトの密度に比例するという点です。最初から304個を作る必要はありません。核心のatom 5個から始めて、毎週1〜2個ずつルール化していけば、いつの間にかmanifestは厚くなっていきます。

著者の推定(未検証): scoreがマッチ・検証の回数に応じて累積するという記述は、運用パターンに基づく解釈です。スコア算定の式自体は環境ごとのmanifest設計によって変わるため、上記の356.53のような絶対値は著者の環境の実測スナップショットにすぎず、一般的な標準ではありません。

メモリーは2つの層に分けておくという原則も、ここでもう一度押さえます。

グローバルは軽く保つほうが安全です。グローバルが重くなると、その重さがすべてのセッションにトークンコストとして積み重なるからです。オフィスにたとえれば、グローバルは机の上の名刺ホルダー（軽いほど毎日使いやすい）、プロジェクトメモリーは隣のキャビネットのフォルダー（プロジェクト単位で厚くなっても普段の負担はない）です。だから、自動ロードされるグローバルには核心だけを置き、豊富な資料はプロジェクトメモリーに蓄えたうえで、JITで必要なときだけ呼び起こします。

1.3.4 権限 — 作業の蓄積の痕跡が積み重なるホワイトリスト

いよいよ、インフラの3つ目の軸、権限です。Claude Codeはファイルを削除し、コマンドを実行し、外部APIを呼び出すことができます。強力さはリスクとともにやって来ます。権限システムがそのリスクを管理します。

権限は2種類に分かれます。人の承認なしに自動で実行されるものと、毎回承認を受けなければならないもの。どちらに何を置くかは、settings.jsonのpermissionsブロックで定義します。

{
  "permissions": {
    "allow": [
      "Bash(ls:*)",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Read(*)",
      "Grep(*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)"
    ]
  }
}

ここで視点の転換が必要です。このallowリストは単なる設定値ではなく、作業の蓄積の痕跡です。最初は読み取り・検索程度だけを自動許可にして、ほとんど空のままです。ところが1〜2か月同じ作業を繰り返していると、「このコマンド、毎回承認を押すのは面倒だな」というパターンが生まれ、それを1つずつallowに移していきます。長くなったリストは、自分がこのツールで何を繰り返してきたかの指紋そのものです。

著者の会社環境（プロジェクトA）は、約80個の自動許可パターンを持っています。20個から始まり、6か月かけて60個が増えました。その60個を逆から読むと、この半年間どんな作業を繰り返したのかが浮かび上がります。マスターデータの抽出、関係図の生成、スキーマのドキュメント化。よく使うツールが、そのままよく許可した権限なのです。

権限の運用には、4つのパターンが定着しています。

• ホワイトリストで始める — 自動許可は最小限から出発し、必要なときだけ追加します。広く開けてから狭めるのではなく、狭く閉じてから開ける方向です。
• 危険なコマンドは明示的にブロック — rm -rfやgit push --forceのように、一度の事故が致命的になるコマンドはdenyに入れます。自動許可を広げても、この2つには手を付けません。
• 定期的な掃除 — 四半期ごとにallowを見直し、使わなくなった権限を削ります。痕跡は、積もるだけならノイズになります。
• ドメインごとの分離 — グローバル権限とプロジェクト権限を分けます。自宅PCと会社PCが別のポリシーを持つように、環境ごとに許可範囲は異なります。

毎回承認ポップアップが出ると、人は疲れます。疲労を減らす仕掛けもあります。fewer-permission-promptsのようなスラッシュコマンドで頻出パターンを一括登録する、1セッションの間だけ一時許可を与える、個人作業に限って全権自動許可モードを使う、といったやり方です。ただし、最後のオプションはチーム環境ではおすすめしません。

疲労と安全のバランスは、自分で調整します。厳しすぎると作業が回らず、緩すぎると事故が起きます。緩めに始めても、四半期の掃除サイクルを備えておけば、バランスは自然に取れていきます。

1.3.5 セッションが始まるとき — メモリーと権限がともにロードされる図

ここまで見てきた3つの軸（settings・メモリー・権限）が、1つのセッションでどのように同時に働くのかを、入力1行を起点に広げてみます。以下は、「スキルのクールタイムバランスを見よう」と入力したときに実際に起きることの断面図です。

3つのレーンが、1つの入力で出会います。settings.jsonがフックを呼び起こし、フックがメモリーを選んで入力に添え、そうして作られた応答がツールを呼び出すときに、権限が最後のゲートとして働きます。ユーザーは「クールタイムを見よう」と1行打っただけなのに、3つのインフラが見えないところで順番に仕事をしています。これが、ツールが「自分のツール」だと感じられる瞬間の内部構造です。

1.3.6 初回セットアップガイド — 1時間で運用可能な状態へ

理論を見たので、手を動かします。初めてClaude Codeをインストールしたあと、1時間あれば上の図の全体を自分のPCに敷くことができます。5つの区間に分けます。

0〜10分、インストール・起動確認。 インストール後、ターミナルでClaude Codeを起動します。フォルダー1つの中で「このフォルダーに何がある？」と聞いて、応答を確認します。まず、ツールが生きているかどうかから見ます。

10〜25分、グローバルメモリー3つの作成。 自動ロードされるグローバルは、3ファイルで十分です。

• MEMORY.md（5行） — 自分のアイデンティティ1行+ほかのファイルへのポインター。
• user-profile.md（20〜30行） — 名前・役割・専門分野・連絡先。
• feedback-collaboration-style.md（20〜30行） — 言語・口調・実行優先・説明簡潔のようなコラボレーションのルール。

著者の例をそのまま写して始めても構いません。運用しながら磨いていけばよいのです。

25〜40分、settings.jsonの基本設定。 effortLevelをhighにし、権限のスターターセット（読み取り・検索は自動、書き込み・削除は承認）を入れ、バックアップを1部とります（settings.json.bak_<날짜> — <날짜>は「日付」を意味する韓国語のプレースホルダー）。バックアップは、この区間でいちばん重要な1行です。

40〜55分、最初のプロジェクトatom 5個。 自分が毎回忘れる決定、よく尋ねる情報を5個、atomにします。フォルダーは~/.claude/projects/<프로젝트>/memory/（<프로젝트>は「プロジェクト」を意味する韓国語のプレースホルダー）。形式は第5章を参照してください。5個なら、JIT manifestを今すぐ作らなくても、グローバル自動ロードだけで効果が出ます。

55〜60分、テスト1回。 新しいセッションを開き、自分の分野の質問を1つ投げます。グローバルメモリーが自動ロードされたか、応答のトーンが自分のコラボレーションルールに従っているかを確認します。

ここまでで1時間です。JIT manifestとフックは、atomが50個を超えるころ、自動ロードが重くなり始めたときに導入しても遅くありません。その時点で1.3.2のinject_memory.pyを敷けばよいのです。

1.3.7 よくある失敗と回避法

導入初期に繰り返される失敗は5つにまとまり、それぞれが同じ事故原因の上に立っています。

5つすべてを初日から回避する必要はありません。グローバルの肥大化とバックアップ漏れは、最初の1時間以内に回避パターンを作っておくのがよく、残りの3つは1か月ほど運用しながら、自分にとって事故の可能性が高い場所に回避装置をはめ込むほうが自然です。

1.3.8 第1部を終えて

1.1はツールへの距離感を縮める場所で、1.2はそのツールの最小動作メカニズムをつかむ場所で、1.3はメモリー・権限・settingsで最初のインフラを敷く場所でした。この3章が、本書の導入部にあたります。ここまで終えれば、ツールを止めずに運用するための基本骨格は据わります。

核心は、この骨格が静的な設定ではないという点です。manifestのatomは毎週増え、allowリストは作業の痕跡に沿って長くなり、scoreは検証を経ながら積み上がります。インフラは敷いた瞬間に完成するのではなく、敷かれた上でユーザーとともに育ちます。個人PCの17個が会社の304個へと開いていく差が、その成長の距離です。

第2部からは、本格的な情報アーキテクチャに入ります。第4章のYAMLフロントマター、第5章のAtom、第6章のLayer、第7章のオントロジーが順に続きます。1.3ではmanifestの1エントリとしてしか見なかったatomが、2.2では1つの章の主役になります。背骨が据わってこそ、分野別の章が同じ座標の上で自分の居場所を見つけられるのです。

本章のポイント

• メモリーの自動注入は、settings.jsonのフック1行がinject_memory.pyを呼び起こす構造です
• 権限のallowリストは設定ではなく作業の蓄積の痕跡であり、四半期ごとに掃除します
• インフラは敷いたら終わりではなく、atom・権限・scoreがともに育つ、生きた骨格です

次章のプレビュー

• 第2部の開始：第4章。YAMLフロントマター — すべての文書をデータに

やってみよう

setup 1. ~/.claude/settings.jsonを開き、変更前にsettings.json.bak_<오늘날짜>（<오늘날짜>は「今日の日付」の意）としてバックアップをとりましょう。 2. permissions.allowにRead(*)、Grep(*)、Bash(ls:*)、Bash(git status:*)を入れ、permissions.denyにBash(rm -rf:*)、Bash(git push --force:*)を入力しましょう。 3. （atomが50個以上のとき）hooks.UserPromptSubmitにpython ~/.claude/hooks/inject_memory.pyを登録し、_jit_manifest.jsonにatomエントリ（name・path・regex・score）とconfig.max_matches: 3を書きましょう。

prompt - 新しいセッションで、manifestのどれかのatomキーワードを意図的に含んだ質問を投げてみましょう。例：「クールタイムのルールを基準にスキルバランスを見よう」。

verify - 入力直後に[memory injected: N atoms]のようなシグナルが表示されるか確認しましょう。 - 意図したatomが応答に反映されたかを見てみましょう。 - わざとmanifestに壊れたJSONを入れてみて、それでもプロンプトがブロックされずに動くか（exit 0保証）を確認したうえで、元に戻しましょう。

一人ミニ版 - フックもmanifestもなしで始めましょう。グローバルのMEMORY.md1ファイルにアイデンティティ3行+コラボレーションルール3行だけを書き、権限はRead(*)・Grep(*)だけを自動許可にしておきましょう。atomが手になじんで50個に近づいたとき、そのときに1.3.2のフックを載せましょう。インフラは小さく始めて痕跡に沿って育てるものであって、最初から304個をそろえるものではありません。

第2部 · Info Architecture

2.1 YAMLフロントマター — すべてのドキュメントをデータに

マイルストーンビルドを翌日に控えた夜、システムプランナーのチームメンバーAが社内メッセンジャーで尋ねてきました。「今週、報酬カーブに手を入れたドキュメントは何件ですか？　レビューが終わっているのはどこまでですか？」私は答えを知りませんでした。ドキュメントはフォルダのどこかにあり、誰が最後に手を入れたのか、どのマイルストーンのものなのかは、各自の記憶とファイル名の取り決めの中に散らばっていました。その夜、私たちがやったのは、ドキュメントの先頭に6行を書き込むという取り決めを作ることでした。その6行が、次のマイルストーンからは、チームメンバーAの質問に、人がフォルダを開かなくても答えられるようにしてくれました。

ドキュメントの先頭、---の間に書く数行のYAML。これをフロントマターと呼びます。この取り決めが、本文を一文字も読まずに「このドキュメントが何なのか」を、人と機械の両方に同時に伝えてくれます。本章では、その1行がどのように情報アーキテクチャ全体の入口座標になるのかを、実際に動くスクリプトで追いかけていきます。

先に用語を1つだけ押さえておきます。本書は企画ドキュメントを5つのLayerに分けます（第6章で本格的に扱います）。L0=世界観・コンセプト、L1=システムルール、L2=コンテンツ、L3=データ、L4=実装座標です。上から下へ依存するのが正常な方向です。下の節に出てくるlayer: 2は「このドキュメントはコンテンツLayerにある」という座標の宣言です。

2.1.1 なぜ「ドキュメント」ではなく「データとしてのドキュメント」なのか

伝統的な企画ドキュメントは、Word、PPT、Googleドキュメントの上で生きてきました。本文は人が読むために最適化されています。ところが、ドキュメントの種類・責任・状態・位置といったメタ情報は、本文の中に溶け込んでいるか、フォルダ構造とファイル名の取り決めに依存しています。そのため「このドキュメントはどのマイルストーンのもので、誰が責任者で、最後のレビューはいつだったのか」を知るには、本文を開いてみるしかありません。

ここに2つの限界が重なります。第一に、ドキュメントが自分の正体を自分で語りません。正体は人の記憶とフォルダの取り決めの中にあり、その取り決めは時間とともに風化します。第二に、AIがコンテキストを推論する手がかりがありません。Claude Codeに「このドキュメントをレビューして」と頼むと、本文を最初から最後まで読んでトークンを浪費するうえ、責任範囲がどこまでなのかも分かりません。

YAMLフロントマターはこの2つを一度に解決します。ドキュメントの先頭にメタデータを明示的に書き込んでおけば、人も機械も本文を開かずにドキュメントを識別できます。キャビネットの引き出しの正面にラベルが貼ってあれば、引き出しを開けなくても中身が分かるのと同じです。そしてこのラベルは、単なる分類ツールにとどまりません。後で見るように、layerフィールド1つが、プロシージャル生成と自動チェックの入口座標になります。

2.1.2 実際のフロントマター — あるドキュメントの最初の14行

抽象的な例の代わりに、プロジェクトAの報酬カーブのドキュメントが実際に頭の上に載せているフロントマターをそのまま見てみます（ID・実名のみ仮名処理、構造は運用そのままです）。

---
title: "メインクエスト12章 報酬カーブ"
layer: 2
status: review
owner: teammate_a
created: 2026-04-15
updated: 2026-05-20
related:
  - quest_main_chapter12
  - reward_curve_milestone_2
affects:
  - L3_BalanceSheet_v2
ip_check: passed
---

# メインクエスト12章 報酬カーブ

(本文開始)

核心は---の上と下の分離です。上はパーサーが読むデータ、下は人が読む本文です。Markdownレンダラーは通常フロントマターを非表示にするため、読むときの邪魔にはなりません。1つのファイルがデータ（frontmatter）とコンテンツ（本文）を一緒に収め、信頼できる唯一の情報源（single source of truth）になります。

layer: 2とaffects: [L3_BalanceSheet_v2]、この2行に注目してください。「このコンテンツ（L2）のドキュメントが、データLayer（L3）のバランスシートに影響を与える」という宣言です。これだけで、ツールはL2→L3の依存関係を、本文なしにグラフとして描けます。逆に、L3のデータドキュメントがL1のシステムルールをdepends_onで参照していたら（下から上へ向かう逆方向の依存）、それは設計の臭いです。ツールがその逆参照を自動で検出します。

YAMLがJSONより手で書きやすい理由は単純です。インデントで構造を表現でき、引用符がほとんど要らず、#コメントが使えます。プランナーが自分の手で埋めるのに適しています。

2.1.3 標準はどこに住むのか — _NAMING_FRONTMATTER_STANDARD

フィールドは際限なく増やせます。増やすほど記入の負担が大きくなり、標準が崩れていきます。そこでプロジェクトAは2つの層に分けて運用しています。すべてのドキュメント共通の最小限のコアフィールドと、分野別のドメイン拡張フィールドです。

共通の最小コアフィールドは6つです。

この6つだけで、ドキュメントの鮮度・責任・位置が即座に分かります。もっと足したくなる衝動を、最初の1か月は我慢します。運用しているうちに、どのフィールドが本当に必要かは自然と見えてきます。

分野別の拡張フィールドはドメインごとに異なります。システム企画はdepends_on・affects、戦闘企画はcombat_phase・anim_target、ナラティブはworld_region・chapter、バランスはdata_sheet・formula_idをよく使います。これらの拡張フィールドが自由に散らばってよいわけではないので、ただ1つの標準ドキュメントが正式名称・許容値・例を明文化して固定します。それが_NAMING_FRONTMATTER_STANDARD.mdです。新しいフィールドを追加するには、このドキュメントを経由しなければなりません。そしてこの標準ドキュメント自体がatomとして登録されており、ドキュメント名の先頭にLayer番号を強制するルール（docs_layer_numeric_prefix_naming atom）と同じ系列で管理されています。

ここで重要な転換が起きます。標準が「人が読むドキュメント」でしかなければ、人はそれを破ります。標準を機械が読むデータにすれば、機械がそれを強制します。次の節が、その転換の実際のコードです。

2.1.4 ワークド・トランスクリプト — 標準をコードで強制する、そしてdatetimeバグが残した教訓

今度は「プロジェクトAのすべてのMarkdownドキュメントがフロントマター標準を守っているかを検査するLinter」をClaude Codeに作らせました。核心となる要求は2つでした。検査項目（必須フィールドの欠落、statusの非標準値、layerの0〜4違反、reviewのまま90日以上更新されていないドキュメント）を検出すること、そして許容値をコードにハードコーディングせず、標準ドキュメントから読み込むこと。この分離が核心です。標準を直せば、コードを直さなくても検査基準が変わります。（スクリプト全文と実際に実行する手順は、本章末尾の「やってみよう」に置いています。）

ここで1つの事件がありました。Claudeが最初に出してきたコードは、STALE検査でtoday - fm["updated"]によって日付の差を計算し、コメントに「updated: 2026-05-20のように書かれていればPyYAMLがdatetime.dateとして自動パースする」と書いていました。この説明は半分しか合っていません。実際のドキュメントに対して走らせると、一部のファイルでトレースバックが出ました。

TypeError: unsupported operand type(s) for -: 'datetime.date' and 'str'

原因は人の手にありました。ある作成者はupdated: 2026-05-20と書き（dateとしてパースされます）、別の作成者はupdated: "2026-05-20"と引用符を付けていました（文字列としてパースされます）。標準が日付の形式を確定していなかった場所で人の手が分かれ、Claudeは片方だけを仮定していたのです。私はこのコードを差し戻し、「2つの表記をどちらも安全にdateへ正規化し、updatedがない場合もはじくように」ともう一度依頼しました。Claudeは入力の型を検査して、両方をdatetime.dateに正規化するヘルパーを差し込みました（修正後のブロックも「やってみよう」を参照してください）。

本当の教訓はコードのバグではありませんでした。標準が日付の表記形式を確定していなかった場所で、人の手が分かれたということです。そこで_NAMING_FRONTMATTER_STANDARD.mdにupdated: YYYY-MM-DD (따옴표 없이)という1行を追加しました。Linterがコードで検査を回すうちに、検査対象である標準そのものの穴をあらわにしてくれた、というわけです。

修正後のスクリプトの最初の出力は、きれいなものではありませんでした。実際に出た汚い結果をそのまま載せます。

[NO-FM]   manuscript/legacy/old_combat_notes.md
[MISSING] manuscript/system/quest_flag_table.md: layer
[STATUS]  manuscript/content/town_intro.md: WIP
[LAYER]   manuscript/balance/dps_v2.md: None
[STALE]   manuscript/system/inventory_rules.md: 134d

この5行が、導入初期のチームの実際の状態でした。古いドキュメントにはフロントマターがそもそもなく（NO-FM）、あるドキュメントはlayerを落としていて、誰かはstatus: WIPという非標準値を使い、バランスのドキュメント1つはlayerをNoneのまま空けてあり、システムルールのドキュメント1つは134日間review状態のまま眠っていました。標準は最初から守られるものではありません。Linterは、その事実を毎朝あらわにするだけです。

2.1.5 frontmatterからスクリプトまで — 流れ

上のワークド・トランスクリプトを1枚の流れに圧縮すると、次のようになります。人が書いた1行が、どのように機械のチェックゲートまで流れていくかを示しています。

flowchart TD
    A["作成者: 新規ドキュメント作成
テンプレートがフロントマター6フィールドを自動挿入"] --> B["空欄だけを埋める
title / layer / status / owner ..."]
    B --> C["保存された.mdファイル
--- frontmatter --- + 本文"]
    C --> D["Linterスクリプト実行
rglob('*.md')"]
    D --> E["_NAMING_FRONTMATTER_STANDARD.md
許容値を読み込む"]
    E --> F{"検査
必須フィールド / status / layer / stale"}
    F -->|"合格"| G["関係グラフへ入力
related・affects → L座標の依存関係"]
    F -->|"違反"| H["日次レポート
責任者ownerに自動通知"]
    H --> B
    G --> I["AIへの質問が可能
'Layer2のreviewドキュメントを集めて' → 即答"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class A,B human
    class D,F code
    class C,E,G data
    class H fail
    class I ai

核心は2つです。第一に、標準（E）がスクリプト（D）から分離されています。標準を直せば、コードを直さなくても検査基準が変わります。第二に、違反（H）は行き止まりではなく、作成段階（B）へ戻るループです。人を責めるのではなく、本人のドキュメントを本人が直すように送り返します。

2.1.6 運用事例 — ある中規模チームの6か月

著者がディレクターとして運営するプロジェクトAでは、約6か月前にフロントマターを企画チーム全体（4〜5人）に導入しました。導入は一度に済んだわけではなく、4つの節目を経ました。

導入1週目の最大の拒否反応は「これを毎回手で書けというのか？」でした。新しいドキュメントのたびに6行を覚えて書くのは面倒です。解決策はテンプレートの自動挿入でした。VSCodeのスニペット、Obsidianのテンプレート、企画ポータルの「新規ドキュメント」ボタンが、空のYAMLブロックを自動で差し込んでくれます。作成者は空欄だけを埋めます。拒否反応は1週間以内に消えました。

1か月目には標準の衝突が起きました。複数のメンバーが自由にフィールドを追加するうちに、owner・responsible・authorが同時に現れたのです。同じ概念なのに表記が3つあるため、検索も自動化も壊れました。解決策は、_NAMING_FRONTMATTER_STANDARD.mdという1つのドキュメントに、すべてのフィールドの正式名称・許容値・例を整理し、新しいフィールドの追加をこのドキュメント経由でルール化したことでした。1か月以内に標準が安定しました。

3か月目には、2.1.4で見たLinterが入りました。標準があっても人は破ります。そこで、毎朝整合性レポートが自動生成され、社内メッセンジャーの共有チャンネルに落ちてくるようにしました。責任者は自分のドキュメントだけを見ればよい仕組みです。自動化の後、標準違反は目に見えて減りました（著者の推定であり、精密な測定値ではありません — 体感でおおよそ半分以下）。

6か月目には、AIとの結合が光りました。標準が安定すると、次のような質問に即答が返ってくるようになったのです。

• 「直近2週間に更新されたLayer 2のドキュメントのうち、statusがreviewのものを全部集めて」
• 「私がownerであるすべてのドキュメントの状態変化のタイムラインを描いて」
• 「この変更リクエストが影響を与える他のドキュメントの一覧を出して」 — related・affectsのグラフをたどって自動で

結局、フロントマターは人とAIの間の共通語彙になりました。人が書けばAIが理解し、AIが書けば人が検証します。どちらも同じキーを見ています。ただし、1週目の拒否反応、1か月目の衝突、3か月目のLinter、6か月目の結合 — 積み重なった6か月が作った結果であって、一度に生まれたものではありません。

2.1.7 よくある失敗と回避策

導入初期に繰り返される失敗は5つにまとめられます。すべて同じ根 — 「標準を人の意志だけに委ねた場所」 — の上に立っています。

5つの失敗を初日からすべて防ぐ必要はありません。1番と3番は導入1週目に回避パターンを押さえておき、2・4・5番は運用しながら、自分のチームが最もよくぶつかる場所から順に組み込んでいくのが自然です。

2.1.8 小さく始める — 3週間で定着させる

フロントマターの導入は、意外と軽い作業です。3週間あれば、1つのチームの中に根を下ろします。

1週目はコアの6フィールドを定義し、テンプレートを作って新規ドキュメントだけに適用し、記入の負担を最小化します。2週目はよく見る上位20件のドキュメントに手動で適用し、実際の使用の中でどのフィールドが足りないかを点検します。3週目にLinterと日次レポートを稼働させれば、そこからは標準が、人の意志ではなくツールの力で維持されます。

既存ドキュメント全体を一度にマイグレーションすることはしません。よく見るものから、新規ドキュメントから適用します。6か月もすれば、ほぼすべてのドキュメントにフロントマターが付きます。とはいえ、100%が目標ではありません。一度も開いたことのない古いドキュメントまでマイグレーションするために時間を使うのは無駄です。

やってみよう

最小の単位で、1回のサイクルを自分の手で回してみましょう。

setup - 作業フォルダに、検査対象の.mdドキュメントを2〜3個置きます。一部はわざとlayerを抜いたり、status: WIPのような非標準値を入れたりしておきます。 - 同じフォルダに、標準ドキュメントとして次の行を置きます。 status: allowed = ["draft", "review", "approved", "archived"] updated: YYYY-MM-DD (引用符なし)

prompt（Claude Codeに入力）

このフォルダ以下のすべての.mdのYAMLフロントマターを検査するPythonスクリプトを書いて。必須フィールドtitle・layer・status・ownerの欠落、statusの許容値違反（標準ドキュメントから読み込むこと）、layerの0〜4整数違反、reviewなのにupdatedが90日を超えているものを検出して。updatedが文字列で来てもdateで来ても安全に処理して、違反をファイル別に出力して。

verify - スクリプトを実行し、わざと仕込んだ違反がすべて検出されるか確認します。 - 標準ドキュメントのallowedリストにWIPを追加してからもう一度実行し、コードを1行も直していないのにstatus: WIPが合格に変わるか確認します。標準とコードが分離されている証拠です。 - updatedに引用符を付けたドキュメントと付けていないドキュメントを両方入れて、2.1.4で見たTypeErrorが出ないことを確認します。

参考: Linterスクリプト全文

2.1.4でClaudeが最初に出してきたコードです。STALE検査の行（age = (today - fm["updated"]).days）に、datetimeバグがそのまま入っています。

import sys, datetime, pathlib, re
import yaml  # PyYAML

ROOT = pathlib.Path("manuscript")
STANDARD = pathlib.Path("_NAMING_FRONTMATTER_STANDARD.md")
REQUIRED = ["title", "layer", "status", "owner"]

def load_allowed_status(standard_path):
    # 標準ドキュメントから `status` の許容値を抽出
    text = standard_path.read_text(encoding="utf-8")
    m = re.search(r"status:\s*allowed\s*=\s*\[(.*?)\]", text)
    if not m:
        return ["draft", "review", "approved", "archived"]
    return [s.strip().strip('"').strip("'") for s in m.group(1).split(",")]

def parse_frontmatter(md_path):
    text = md_path.read_text(encoding="utf-8")
    if not text.startswith("---"):
        return None
    end = text.find("---", 3)
    block = text[3:end]
    return yaml.safe_load(block)

def main():
    allowed = load_allowed_status(STANDARD)
    today = datetime.date.today()
    violations = 0
    for md in ROOT.rglob("*.md"):
        fm = parse_frontmatter(md)
        if fm is None:
            print(f"[NO-FM]   {md}")
            violations += 1
            continue
        for field in REQUIRED:
            if field not in fm:
                print(f"[MISSING] {md}: {field}")
                violations += 1
        if fm.get("status") not in allowed:
            print(f"[STATUS]  {md}: {fm.get('status')}")
            violations += 1
        if not isinstance(fm.get("layer"), int) or not (0 <= fm.get("layer") <= 4):
            print(f"[LAYER]   {md}: {fm.get('layer')}")
            violations += 1
        if fm.get("status") == "review":
            age = (today - fm["updated"]).days   # ← ここが壊れる
            if age > 90:
                print(f"[STALE]   {md}: {age}d")
                violations += 1
    sys.exit(violations)

再依頼の後に直してきた核心ブロックです。updatedが文字列で来てもdateで来ても、安全に正規化します。

def as_date(v):
    if isinstance(v, datetime.date):
        return v
    if isinstance(v, str):
        return datetime.date.fromisoformat(v.strip())
    return None

# main() 内の STALE 検査の差し替え分
if fm.get("status") == "review":
    upd = as_date(fm.get("updated"))
    if upd is None:
        print(f"[MISSING] {md}: updated")
        violations += 1
    elif (today - upd).days > 90:
        print(f"[STALE]   {md}: {(today - upd).days}d")
        violations += 1

一人ミニ版

チームがなくても大丈夫です。1人で使うメモフォルダで、コアフィールドをtitle・status・updatedの3つに減らし、Linterは「statusがreviewなのにupdatedが30日を超えたドキュメント」だけを検出するようにします。これだけでも、「レビューの途中のまま忘れてしまったドキュメント」が週に1回、水面に浮かび上がってきます。標準・テンプレート・検査の三角形は、1人の規模でもそのまま機能します。

本章のポイント

• フロントマターの数行は、本文を読まずにドキュメントを識別できる、最小のデータのレンガです
• 標準をコードから分離してドキュメントとして置けば、コードを直さずに検査基準を変えられます
• layerという1つのフィールドが、プロシージャル生成と自動チェックの入口座標になります

2.2 ページ別Atom — 1文書1決定の解剖

新人が入って最初の週、彼がチャットで尋ねてきました。「戦闘のクールタイム（クールダウン）は0.6秒で合っていますか？どのドキュメントに書いてありますか？」。私は「スキルシステムのGDD（Game Design Document、詳細仕様書）にありますよ」と答えました。彼はまた尋ねました。「そのGDDのどのセクションですか？クラス設計の次にダメージカーブ、その後ろにUI表示方式まで220行あるんですが」。ファイルを開いて直接探してあげました。137行目でした。彼は最後に尋ねました。「ところで、なぜ0.6秒なんですか？0.5ではだめだったんですか？」。その答えはどのドキュメントにもありませんでした。6か月前の会議で決めたことは覚えているのに、理由は議事録のどこかに埋もれていました。

この5分間の会話の中に、220行の統合ドキュメントが抱える3つの失敗がすべて詰まっています。位置を見つけられない（検索の失敗）、理由がない（文脈の喪失）、毎回人が仲介しなければならない（自動化の不可）。AIに同じ質問を投げると事情はさらに悪くなります。AIは220行をすべて読んだうえで、クールタイムとは無関係なダメージカーブの話まで混ぜて答えます。

本章の処方箋はシンプルです。1つのドキュメントには1つの決定だけを入れる。この原則で細かく分割した決定単位のドキュメントをatomと呼びます。220行のGDDを分割すると「クールタイムは0.6秒」が1つのatomになり、そのatomの中に位置・内容・理由・例外・関係が1か所に集まります。本章では抽象論の代わりに、実際のatom1つを最後まで解剖します。どう命名するか、どんなfrontmatterを記入するか、関係をどう明示するか、そしてその結果、AIがどうやってそのatom1つだけを正確に拾い上げるのか — そこまでを見ていきます。

2.2.1 検体を1つ選ぶ — combat_cooldown_rule_v2

解剖する検体は、プロジェクトAで実際に運用中のatom1つです。名前はcombat_cooldown_rule_v2。ファイルの全文は次のとおりです。長くはありません。1つの決定だけを入れたのですから。

---
name: combat_cooldown_rule_v2
title: "戦闘クールダウン規則 — v2"
type: rule
layer: 1
status: approved
owner: 이민수
created: 2026-03-10
updated: 2026-05-12
applies_to: [skill_system, item_system]
---

# 戦闘クールダウン規則 v2

Why (なぜ): 同時に使用可能なスキル数を制限して瞬間的な意思決定の負担を
減らし、コンボ入力の意味を保存するため。

Rule (規則): すべてのアクティブスキルはグローバルクールダウン0.6秒 + 個別
クールダウン(スキル別定義)を持つ。グローバルクールダウンの進行中は、いかなる
アクティブスキルも発動不可。

How to apply (適用):
- 新規スキル定義時に個別クールダウンを必ず明記
- L3_SkillSheetのcooldownカラムが0であれば本規則違反
- ビルド段階の整合性検査が違反を自動検出

Exceptions (例外):
- パッシブスキルは本規則の適用外
- 究極技は別途ゲージシステム (See: [[ultimate_gauge_system]])

Relations (関係):
- affects: [[combat_dps_calculation_v3]], [[balance_curve_v3]]
- derives_from: [[principle_decision_load_reduction]]
- conflicts_with: [[skill_cancel_rule_legacy_v1]]
- requires: [[combat_input_buffer_system]], [[skill_system_v2]]
- is_a: rule
- part_of: combat_system_master

このファイル1枚を、5つの部位に切り分けてみます。命名、frontmatter、単一の決定、関係、トレーサビリティ（追跡可能性）。5つの部位がすべてそろってはじめて、AIはこのatomを「単独でも意味が通る単位」として読みます。

2.2.2 部位① 命名 — 名前そのものが座標

ファイル名はcombat_cooldown_rule_v2です。なんとなく付けた名前ではなく、3つのパーツからなる構造を持っています。

combat_         cooldown_rule          _v2
└ prefix        └ 決定本文             └ バージョン
  (どのドメイン)  (何についての決定)     (何回目の改訂)

prefixのcombat_は「これは戦闘ドメインの決定」という座標です。プロジェクトAのルールatomは、prefixでドメインが分かれます。quest_（クエスト）、data_（データ運用）、docs_（ドキュメント運用）、meeting_（議事録）、portal_（企画ビューアー）。prefixを見るだけで、この決定が誰の責任領域なのか、どこから影響を受けるのかがつかめます。

命名が揺らげば、すべてが揺らぎます。同じ決定がskill-cooldown.mdとcooldown_skill_v2.mdとして二重に存在すると、検索も壊れ、後で出てくるJITマッチングも壊れます。だからプロジェクトAは、命名規則そのものを1つのatomとして先に固定しました。それがatom_naming_convention_v1で、snake_case・prefix必須・バージョンsuffixを強制します。そしてこのルールは、人の意志ではなくLinterが守ります。prefixのないファイル名がコミットされると、ビルド段階で弾かれます。

命名には、本書全体を貫くより大きな設計が敷かれています。frontmatterのlayer: 1がその2つ目の座標です。prefixが「どのドメインか」を語るなら、Layerは「どの抽象階層か」を語ります。2つの座標が組み合わさってはじめて、atomの位置が平面上の1点として確定します。ここでのLayerは座標にすぎません（0〜4の階層定義の詳細は2.3で扱います）。クールタイムルールは「生成を統制する入力ルール」なので、Layer 1に座ります。このLayer座標をドキュメント名の先頭に数字prefixとして強制するルールも別にあります — docs_layer_numeric_prefix_namingです。名前1つに、2つの座標軸が明示されているわけです。

この設計の本質は整理癖ではありません。私がチームに繰り返し言ってきた言葉があります。「プロシージャル生成のために分けたLayerだったわけで」。atomごとにドメイン座標（prefix）と階層座標（Layer）が明示されていれば、後でAIが「Layer 1のcombatルール全部を入力として受け取り、Layer 2のコンテンツを自動生成する」ことが可能になります。名前は、その自動化のアドレス体系なのです。

2.2.3 部位② frontmatter — 機械が読むラベル

本文の上、---の間にあるYAMLブロックがfrontmatterです。2.1で扱った標準をatomにそのまま適用したもので、人ではなく機械（ビルドスクリプト・JITフック・関係図ジェネレーター）が読むラベルです。

これらのラベルが記入されていれば、自動検査が可能になります。たとえばlayer: 1と宣言されたシステムルールが、本文で[[L3_SkillSheet_row_0042]]のようなデータatom（Layer 3）を直接参照していれば、それは上位階層が下位階層の具体値に縛られる逆参照（L3→L1）です。プロジェクトAはこのパターンをビルド段階で自動検出します。ルールはデータの1行ではなく、データの形式を参照すべきだからです。frontmatterのlayerという1行がなければ、この検査自体が成立しません。

status: archivedの処理もfrontmatterの仕事です。決定が変わってもatomは削除されず、status: archivedとarchived_atの日付を受け取ります。ビルドとJITはarchivedなatomを除外します。記録は残しつつ、現役からは外れるのです。プロジェクトAの6か月の運用で、廃止率は約15%でした（著者の実測）。この比率が0%に近いなら、廃止のワークフローが機能していないサインだと読みます。

2.2.4 部位③ 単一の決定 — 一文で要約できるか

atom解剖の核心は、本文が決定を1つだけ入れているかの確認です。検査法はシンプルです。このatomの決定を一文で要約してみてください。

「すべてのアクティブスキルは、グローバルクールダウン（GCD）0.6秒を持つ。」

一文で終わります。合格です。もし要約が「クールタイムは0.6秒で、コンボ中は50%短縮される」のように二文になるなら、それは2つの決定です。combat_cooldown_rule_v2（基本クールタイム）とcombat_combo_cooldown_reduction_v1（コンボ短縮）に分割します。

単一性を見る補助検査が、さらに2つあります。

独立廃止検査。このatom1つだけを廃止しても、システムが崩れないか？クールタイムルールを廃止すれば戦闘バランスは揺らぎますが、システムは回ります。単位として適切です。逆に、廃止すると別の5つが一緒に崩れるなら、その5つは実は1つの決定の5つの断片です。より大きなatomに統合すべきです。

単一参照検査。ほかの場所から[[combat_cooldown_rule_v2]]の1つだけをlinkとして張っても、意味が通るか？通るなら単位として適切です。この1行を参照するために本文のあちこちを全部読まなければならないなら、まだ分割が足りていません。

これらの検査を通過した本文は、自然と5つのセクションに整列します — Why、Rule、How、Exceptions、Relations。とくにWhyを消さないでください。冒頭で新人が最後に尋ねた「なぜ0.6秒なんですか？」の答えがここにあります — 「瞬間的な意思決定の負荷を減らし、コンボ入力の意味を保つため」。6か月後に誰かが「0.5秒に縮めよう」と提案するとき、この1行が議論の出発点になります。Whyが消えたatomは、誰も手を付けられない化石になります。

2.2.5 部位④ 関係 — 矢印が影響分析を生む

atomの一番下にあるRelationsセクションが、この検体を孤立したメモではなく、グラフの1ノードにします。核心は、単なる「関連ドキュメント」ではなく、関係の種類を明示するという点です。

flowchart TD
    P["原則: 意思決定負荷の軽減"] -->|derives_from| C["combat_cooldown_rule_v2"]
    C -->|affects| A1["combat_dps_calculation_v3"]
    C -->|affects| A2["balance_curve_v3"]
    C -->|requires| R1["combat_input_buffer"]
    C -->|requires| R2["skill_system_v2"]
    C -.->|conflicts_with| X["skill_cancel_legacy_v1
(廃止予定の衝突)"]
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class P,C,A1,A2,R1,R2 data
    class X fail

6種類の関係が、それぞれ違う仕事をします。

• derives_from: この決定がどの上位原則から派生したのか。クールタイム0.6秒は「意思決定負荷の軽減」という原則の具体化です。
• affects: このatomが変わると、何が影響を受けるのか。0.6秒を0.5秒に変えると、DPS計算とバランスカーブが揺らぎます。変更の前に、影響範囲を自動で抽出できます。
• requires: この決定が成立するには、何が先になければならないのか。先行入力（入力バッファ）システムがなければ、GCDが入力を食ってしまいます。
• conflicts_with: 何と矛盾するのか。旧バージョンのスキルキャンセルルールと衝突しており、このリンクが「どちらか一方は廃止されるべきだ」というシグナルです。
• is_a / part_of: 分類（rule）と所属（combat_system_master）。グラフの骨格です。

単純な「Related: [ドキュメントA], [ドキュメントB]」というリンクだったら、人がいちいち調べなければなりません。関係タイプがenumとして記入されていれば、機械が調べます。「このatomを変えたら影響を受けるものを全部見せて」はaffectsをたどる自動クエリになり、「いま互いに矛盾しているルールを全部探して」はconflicts_withをスキャンする自動検査になります。この6つのenumの本格的なオントロジー設計は2.4で扱い、2.2では、atom標準がそのenumを先取りして適用した形だという点だけを押さえておきます。

関係の矢印は、関係図生成ツールの入力でもあります。プロジェクトAのgen_relation_map.pyは、すべてのatomのfrontmatterのlayerとRelationsセクションを読み、Layerごとに色分けしたインタラクティブな関係図HTMLを自動で描きます。atomの1つひとつが座標（Layer）と矢印（Relations）を持っているからこそ可能なことです。

2.2.6 部位⑤ トレーサビリティ — 1つのatomが防いだ30分

5つの部位がすべてそろったatomは、トレース可能です。誰が・いつ・なぜこの決定をし、何を違反として検出するのかが1か所にあります。トレーサビリティの価値は、統計ではなく、実際に防いだ事件として見えるときにもっとも鮮明になります。

プロジェクトAのmeeting_image_caption_standardというatomは、議事録の添付画像に「どの画面か・なぜ添付したか・何の決定か」をキャプションとして必ず明記せよというルールです。このatomがなかった時代、ある議事録にスクリーンショットがキャプションなしで貼られ、1週間後にそれを見たチームメンバーが「これは何の画面？」を作成者に確認するのに30分かかりました。atomができた後、同じ漏れが再発したときは、ビルド段階のLinterがキャプションのない画像を自動で検出しました。修正まで5分。30分が5分になったのです。

もう1つの検体skill_listing_budget_wrapper_only_policyは、グローバルスラッシュコマンドのスロットを12個に制限し、本体のスキルは別のディレクトリに置き、グローバルにはwrapperを12個だけ公開せよというルールです。ルール化される前は、グローバルスラッシュコマンドが40個近くまで膨れ上がり、セッション開始のたびにトークン予算を食いつぶしていました。atomを定義してからは、自動整理ツールが毎セッション開始時に超過分を整理します。ルールが、人の記憶ではなくツールで執行されるのです。

こうしたatomが、プロジェクトAには約304個積み上がっています（著者の実測、6か月運用時点）。分布の大きな枝だけ見ると、再発防止ルール（rule）がもっとも大きな割合を占め、その次が一回限りの意思決定の固定化（decision）・ドメイン概念（concept）・コラボレーション矯正（feedback）の順です。1つのatomが防ぐ時間は分単位ですが、304個積み上がれば、累積の節約は日単位に乗ります。これが、atomを「整理」ではなく「資産」と呼ぶ理由です。

2.2.7 解剖から自動注入へ — JITの実際の動作

ここまで、atom1つを静的に解剖してきました。今度は、生きて動く瞬間を見ます。1.3のJIT（Just-In-Time）フックは、入力キーワードにマッチするatomだけを選び、その場でコンテキストに注入します。JIT manifestは、各atomにマッチング用キーワードとスコアをマッピングしたJSONです。

{
  "name": "combat_cooldown_rule_v2",
  "path": "atoms/combat/combat_cooldown_rule_v2.md",
  "regex": "쿨다운|cooldown|글로벌 쿨다운|GCD",
  "score": 75
}

実際の注入は、こう流れます。

flowchart TD
    A["ユーザー入力:
スキルのクールタイムを0.5秒に縮めたら？"] --> B["JIT hook:
manifestのregexをスキャン"]
    B --> C{"クールタイムにマッチ？"}
    C -->|"はい score=75"| D["combat_cooldown_rule_v2
全文を注入"]
    C -->|"いいえ"| E["注入しない"]
    D --> F["AIがWhy・Rule・Exceptionまで
読んで応答"]
    F --> G["回答: 0.6秒は意思決定負荷の
軽減が根拠。0.5秒に縮めるなら
affects対象のDPS・バランスカーブの
再検討が必要"]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class A human
    class B,C code
    class D data
    class F,G ai

核心は最後のマスです。AIは単に「0.6秒でした」と答えません。atomのWhyを読んだので根拠を示し、Relationsのaffectsを読んだので、変更時に揺らぐ対象（DPS計算・バランスカーブ）まで先回りして指摘します。細かく分割し、理由を書き、関係を明示しておいた5つの部位が、すべて応答の中でよみがえるのです。

ここで、1文書1決定の原則が自動化の前提であることが明らかになります。もしこのatomが220行の統合GDDだったら、「クールタイム」という1単語がマッチした瞬間に、クラス設計・ダメージカーブ・UIまで丸ごと注入されてトークン予算が削られ、AIは5つの決定のどれに答えるべきか焦点を失います。atomが小さく明確であるほど、JITの精度は上がります。細かく分割された状態は、整理の美徳ではなく自動注入の前提条件なのです。

scoreは、コンテキスト予算を守る装置です。1つの入力に複数のatomがマッチしたら、scoreの上位N個だけを注入します（デフォルトは3個）。スコア付けの基準は、運用しながら決めていきます。

• 安全・セキュリティ・健康関連のatom = 95〜99（絶対に漏らさない）
• 核心メッセージ・哲学のatom = 90〜94
• ドメインの核心ルール = 75〜89（クールタイムルールはここ、75）
• 参考用・履歴のatom = 30〜50

2.2.8 個人atomとチーム共有atom — 2つの層の分離

解剖した検体combat_cooldown_rule_v2は、status: approvedを受けたチーム共有atomです。すべてのatomが最初からこの場所に来るわけではありません。プロジェクトAは、atomを2つの層に分けています。

• 個人atom — 未確定の仮説・個人メモ・その時点の記録の固定化。本人だけが見ます。標準は緩めです。
• チーム共有atom — 検証済みのルール。チームメンバー全員が見ます。命名・構造・承認プロセスを通過しなければなりません。

分離する理由は心理的なものです。個人atomが自由であってこそ、検証前の仮説を気負わずに書き、1週間後に廃棄できます。最初からチームに公開されると、「これが間違っていたらどうしよう」と思って、そもそも書かなくなります。逆に、チーム共有atomは厳格であってこそ、全員が信頼して参照します。

combat_cooldown_rule_v2も最初は、個人atomの「クールタイム0.6秒をテストしてみよう」という1行メモだったはずです。アルファビルドで検証された後、変更リクエストの形でチーム共有に昇格し、ほかのプランナーのレビューを経てapprovedになりました。この個人→チームの昇格フローそのものが、atomシステムが時間とともに賢くなっていくself-improvingループの一軸です。

2.2.9 よくある失敗5つ

atom運用の初期に繰り返される失敗は、5つに整理できます。どれも「atomを資産ではなく使い捨てのメモとして扱った」という同じ根から生まれます。

5つを最初の月から完璧に避ける必要はありません。1番と4番は命名規則atom1つでまとめて解決し、2・3・5番は運用3か月の時点で四半期点検を一度回せば、自然に整列します。

2.2.10 次の章へ

本章では、atom1つを5つの部位に切り分けてみました。名前（座標）、frontmatter（機械のラベル）、単一の決定（一文検査）、関係（影響分析）、トレーサビリティ（防いだ30分）。そしてその5つの部位が、JITの自動注入の中で丸ごとよみがえる様子を確認しました。

名前に明示された2つの座標のうちの1つ、layer: 1を、2.2では軽く触れるにとどめました。2.3が、そのLayerを正面から扱います。atomごとにLayer座標を与えると、分野が違っても、互いの成果物がどこに座っているのかが見え始めます。そして2.4は、本章でenum名だけ借りて使った6つの関係（affects・derives_from・conflicts_with・requires・is_a・part_of）を、オントロジーとして正式化します。YAML（2.1）→ Atom（2.2）→ Layer（2.3）→ Ontology（2.4）と続く情報アーキテクチャの背骨のうち、本章はその2つ目の継ぎ目でした。

本章のポイント

• atom1つは、名前・frontmatter・単一の決定・関係・トレーサビリティという5つの部位の合計です
• 1文書1決定の原則は、整理癖ではなくJIT自動注入の前提条件です
• 名前に明示されたドメイン・Layerの2つの座標は、プロシージャル生成のアドレス体系になります

やってみよう — atomを1つ作ってJITで注入する

setup. 作業フォルダーにatoms/ディレクトリを作り、命名規則atom（atom_naming_convention_v1）を一番最初に書いてみましょう。snake_case・prefix必須・バージョンsuffixの3行だけでもかまいません。JITを使うなら、_jit_manifest.jsonに空の配列を1つ置いておきます。

prompt. 自分が毎回忘れてしまう決定を1つ選び、次のプロンプトでatomのドラフトをもらいましょう。

「次の決定をatomの標準形式で作ってください。決定：『アクティブスキルはグローバルクールダウン0.6秒を持つ』。セクションはWhy・Rule・How to apply・Exceptions・Relationsの5つ。frontmatterにはname（snake_case+prefix）、type、layer、status: draft、owner、createdを入れてください。決定が一文で要約できるかも、最後に確認してください。」

verify. 受け取ったatomを、3つの観点で検査しましょう。①決定が一文で要約できるか（できなければ分割します）。②Whyが空になっていないか。③manifestに{"name", "path", "regex", "score"}の1行を追加し、そのregexのキーワードを実際の入力として投げたとき、atomが注入されるか。3つを通過すれば、最初のatomの完成です。

一人ミニ版

チームもLinterもビルドパイプラインもない1人開発者なら、本章全体をノートアプリのフォルダー1つに縮められます。

• 命名: ファイル名をdomain_decision_v1という1つのルールで統一しましょう。Linterの代わりに、自分の目で守ります。
• 単一の決定: ノート1枚に決定1つ。タイトルを一文で書けなければ、2枚に分割します。
• Why必須: ノートの一番上の1行に「なぜこう決めたのか」を書きましょう。この1行が、6か月後の自分を救います。
• 関係: 正式なenumの代わりに、→ 영향:（影響）、↑ 근거:（根拠）、✕ 충돌:（衝突）の3つの印を書くだけでも、影響追跡の9割は生きます。
• JIT代用: manifestの代わりに、作業開始前に関連ノート1.2〜1.3を直接開いて、AIに貼り付けましょう。手動のJITです。

核心はツールではなく、5つの部位の習慣です。最初の10枚のノートがいちばん難しく、その山を越えれば、次の100枚は手が勝手に作ってくれます。

2.3 Layer設計 — ゲームシステムの抽象化

分野が3つから8つに増えつつあった四半期のことです。戦闘プランナーがスキルの射程を8mに確定しました。同じ週、レベルデザイナーはダンジョンの通路幅を6mで固定しました。どちらも自分の分野の中では完璧に合理的な決定でした。問題は3週間後のビルドで明らかになりました。範囲スキルが通路の壁を突き抜け、敵が見えもしない場所で死んでいったのです。誰のミスでもありません。二人には、互いの決定をのぞき込む窓がなかっただけです。

本章は、その窓を作る話です。各分野が自分の部屋をそのまま持ったまま、隣の部屋で何が起きているかを座標一つで分かるようにすること。その座標系をLayerと呼びます。

2.3.1 サイロ化 — 何度でもまた現れる敵

ゲーム企画は分野が細かく分化しています。システム・戦闘・ナラティブ・コンテンツ・レベル・バランス・UX・QA。各分野はそれぞれの道具・成果物・会議を持ちます。規模が大きくなるほど、それぞれが自分の領域に深く入り込み、他の分野が何をしているか分からない状態になります。これをサイロ（silo）化と呼びます。

サイロ化のコストは、時間が経ってからようやく表面化します。

• 戦闘プランナーが決めたスキルの射程が、レベルデザインの通路幅と合わない。
• ナラティブが設計したNPCの動機が、コンテンツ企画のクエスト報酬構造と衝突する。
• バランスプランナーが組んだ経済サイクルが、運営（ライブオプス）のログインボーナス日程とずれる。

実力不足が原因ではありません。それぞれが自分の分野で合理的に決定し、他分野の決定を認知する経路がなかっただけです。会議で埋めようとすれば会議が爆発的に増え、グループチャットで埋めようとすればシグナルがノイズに埋もれます。会議やグループチャットに価値がないという話ではなく、埋められる部分と埋められない部分の境界を明確にすることが核心です。

解決策は、領域を狭めずに（分野の分化は維持）、互いの流れが分かるように（統合された可視性）することです。相反して見える二つの要求は、同じ座標系の上に整列させれば同時に達成できます。その座標系がLayerです。オフィスにたとえれば、各自が自分の机を持ったまま、同じ壁掛け時計とカレンダーを見るようなものです。

2.3.2 Layerの定義 — 5階層の抽象化

本書で使うLayerは、0〜4の5階層の抽象化です。上に行くほど抽象的で変更がまれになり、下に行くほど具体的で変更が頻繁になります。

5つの階層それぞれがプロシージャル生成・自動化パイプラインで担う役割は、上の図の右側のラベルにあります。このマッピングが本章の背骨です。Layerを「よく整理されたフォルダ」としてだけ見るなら、半分しか見ていません。各階層は生成パイプラインの一段階（アンカー→ルール→本文→数値→ゲート）に正確に対応します。

この5階層はゲーム専用の概念ではありません。同じ背骨を一般のITプロダクト開発にそのまま移せます。ゲームを作ったことのない読者は、下の職務翻訳表で各階層を自分の成果物に対応させてみてください（左はゲーム企画のLayer、右はSaaS・アプリ・社内システムなどで同じ位置に置かれる成果物です）。

読み方はゲームと同じです。上に行くほど変更がまれで（プロダクトビジョンは四半期に一度）、下に行くほど頻繁です（設定値は毎日）。先ほどのサイロ事故 — 射程と通路幅が衝突したあの場面 — は、一般ITの「バックエンドのフィールド定義（L3）とフロントの画面ルール（L1）がずれてリリース直前に爆発する」事態と正確に同じ構造です。分野の名前が違うだけで、背骨は一つです。

この5階層は絶対ではありません。規模とドメインによっては4階層が適切なことも、6階層が必要なこともあります。核心は数字が5であることではなく、階層を明示的に定義するという行為そのものです。

一つの成果物が二つのLayerにまたがることもあります。「スキルシステムGDD（Game Design Document、詳細仕様書）」はシステム設計（Layer 1）と具体データ（Layer 3）を同時に含みます。この場合は文書を分割するか、主Layerを1に置いてデータセクションを別シートに分離します。どちらの方式でも、各部分がどのLayerに住んでいるかを明示します。

2.3.3 メタ原則 — 分化と統合を同時に

分野は横に広がり、Layerは縦に積み上がります。一つの分野の作業は複数のLayerにまたがります。下のマトリクスは、11の分野（横）×Layer 0〜4（縦）の分布の重心を、セルの色の濃さで表現しています。濃いセルがその分野の重心Layerです。

縦に読めば一つの分野がどのLayerにまたがるか、横に読めば一つのLayerにどの分野が集まるかが見えます。L0（ビジョン）の行はナラティブとアートディレクションが最も濃くなっています — ビジョンに最も近い二つの分野です。L3（データ）の行にはシステム・戦闘・レベル・バランス・キャラクターが濃く集まります — マスターデータの上でこれらが互いにぶつかるというシグナルです。

この分布を明示的に持っていれば、他の分野が「戦闘のLayer 2を見ればいい」と即座に位置を把握できます。サイロの壁が崩れるのではなく、壁に窓が開くのです。

マトリクス全体を一文に縮めるとこうなります。縦軸のLayerは生成を自動化するために、横軸の分野は専門性を生かすために分けました。両者が格子の一マスで出会います。

2.3.4 運営事例 — あるMMORPGプロジェクトの実測

著者がデザインディレクターとして運営しているMMORPGプロジェクトAでは、企画チーム（4〜5人）とともにLayerシステムを約6か月運用してきました（開発チーム全体は中規模、10〜50人）。具体的な事例を見てみましょう。

まず、ナラティブの5階層です。ナラティブ企画のフォルダ自体がLayerで分割されています。

ナラティブライターがLayer 2でメインストーリーの一分岐を変えると、Layer 3の台詞シートに影響が及び、すでに録音済みのLayer 4のボイスには不可逆な影響が及ぶ可能性があります。Layerを明示しているからこそ、影響範囲を即座に追跡できます。

関係図の自動生成ツールgen_relation_map.pyも併せて運用しています。マスターデータ間の外部キー関係を分析してインタラクティブなHTML関係図を作り、Layerをノードの色で表現します（赤=L1システム、黄=L2コンテンツ、緑=L3データ）。どのLayerからどのLayerへ依存が流れているかが一目で分かります。依存が逆に流れたら — L3がL1に向かって矢印を放ったら — ほぼ間違いなく設計上の欠陥です。

プロシージャルレベル生成のマスター文書は、Layer座標をfrontmatterに明示しています。

---
title: プロシージャルレベルデザインマスター v0.1
layer_inputs: [L1.World, L2.StoryLine]
layer_outputs: [L3.LevelData, L4.PlayCapture]
---

この2行で「このパイプラインはLayer 1・2を入力として受け取り、Layer 3・4を作る」と宣言され、変更時の影響範囲計算が自動化されます。L0のビジョンは明示しなくても常に入力です — どんな生成であれ、ビジョンというアンカーは毎回付いて回るからです。

文書名にLayerのprefixを強制するatomルールもあります。チーム共有atomの一つはこうです。

docs_layer_numeric_prefix_naming：マスターデータのファイル名は必ずLayer番号のprefix（L1_、L2_、L3_）を持たなければならない。prefixのないシートは整合性チェックで警告。

ルールは単純なほど強力です。名前順に並べ替えるだけでLayerごとにまとまり、AIツールもファイル名だけでLayerを把握します。人が忘れても整合性チェックが捕まえます。

2.3.5 逆参照の検出 — ワークド・トランスクリプト

前の節（2.3.4）で「L3がL1に向かって矢印を放ったら、ほぼ間違いなく設計上の欠陥」と述べました。この検出を人の目ではなくAIに任せるとどうなるでしょうか。実際に回してみた一連のやり取りを、整形せずそのまま掲載します（会社の識別情報のみ匿名化しています）。

[プロンプト全文]

添付した二つのfrontmatterを見て、Layerの依存方向が正常か確認して。
参照は高い番号→低い番号にだけ流れていれば正常。逆なら警告。

--- 文書 A (L1_combat_system.md) ---
title: 戦闘システム骨格
layer: L1
refs: [L3_skill_damage_sheet, L2_combat_flow]

--- 文書 B (L3_skill_damage_sheet.md) ---
title: スキルダメージシート
layer: L3
refs: [L1_combat_system]

[Claudeの生の出力 — 要約なしでそのまま]

二つの文書を検査しました。

文書 B (L3_skill_damage_sheet, L3):
  refs → [L1_combat_system]
  方向: L3 → L1 (具体 → 抽象)
  判定: 正常。データシートが自分の従うシステム骨格を
        参照するのは自然な方向です。

文書 A (L1_combat_system, L1):
  refs → [L3_skill_damage_sheet, L2_combat_flow]
  - L1 → L2 : 正常 (設計が下位の流れを指す)
  - L1 → L3 : ⚠ 逆方向警告
        L1のシステム骨格がL3のデータシートを直接参照して
        います。これは「設計文書が特定のデータ値に
        従属する」という意味で、データが変わるたびに設計
        文書に手を入れる結合を生みます。

勧告: 文書 A の refs から L3_skill_damage_sheet を除去。
      システム骨格が具体的な数値を知る必要があるなら、その数値を
      L1に抽象ルールとして移すか(例: 「基本ダメージは
      クラス係数 × レベル」)、L2のフロー文書を経由してください。

要約: 逆方向参照 1件 検出 (A: L1 → L3)。

[人による検証/拒否]

AIの判定は正しいです。ただし「L2のフロー文書を経由せよ」という勧告は、このケースでは行きすぎでした。L1が知るべきだったのはダメージ式の形であって、シートの特定のセルではありませんでした。そこで二つ目の勧告（抽象ルールとして引き上げる）だけを採択し、経由の提案は拒否しました。

[再依頼]

経由の提案は外して、「ダメージ公式の形だけL1に抽象ルールとして
上げる」という方向で L1_combat_system.md の修正diffだけ見せて。
refsも整理して。

この1サイクルが逆参照検出の本拠地です。AIが方向違反を捕まえ（自動）、人が勧告の適正ラインを削り（レビュー）、絞り込んだ作業だけを再び任せる（再依頼）。プロジェクトAではgen_relation_map.pyがグラフ単位で、portal_layer_change_impact_checkというatomが変更検知のタイミングで発動し、影響範囲の点検を強制します。

この突き合わせを人が手作業でやれば、二つの文書を開いてrefsを照合し、方向を判定するのに数分かかります。文書が数百に増えれば事実上不可能です。逆参照はいつも一つ二つとひそかに入り込み、ずっと後のビルドで初めて爆発します。

2.3.6 Layer分解 = プロシージャル生成・自動化の前提

Layer統合の表面的な目的は、サイロの解消と協業言語の統一です（2.3.1〜2.3.5）。本質的な目的はもう一段深いところにあります。Layer分解が定着すると、プロシージャル生成・自動化の前提条件が整います。

前の二つの節の運営事例は、人が決定し、AIが検証・注入を手伝う段階でした。その次は、分野そのものの量産をAIが候補として作り、人が採択する段階に入ります。この移行の前提がLayer分解である理由は三つです。① AIによる候補生成は「どのLayerの何を生成するか」を明示できなければなりません。② 自動整合性チェックは、Layer間の依存方向が標準化されて初めて機能します（2.3.5の逆参照検出）。③ 変更影響の自動計算は、変更がどのLayerで起きたかという座標があって初めて可能です。三つとも「Layer分解がなければ自動化そのものが詰まる」に集約されます。座標を分けた手つきの先には、最初からプロシージャル生成が置かれていたのです。

分野別の部をまだ読んでいない段階で深入りする必要はないので、適用の二段階だけ輪郭をつかんでおきましょう。保守的適用では、人が決定し、AIが整合性チェック・変更影響計算・JIT注入を自動で支えます — 2.3.4・2.3.5の運営事例がここに当たります。ツールのコストは小さく、累積効果は運用6か月目あたりで表れ、大半の中規模（10〜50人）チームが到達できます。進歩的適用はさらに一歩進み、分野の量産そのものをAIが候補として作り（ナラティブのPersona、PCGルールブック、プロシージャルレベル、バランス変更候補、アートアセットなど）、人は「どの候補を採択するか」だけを決定します。分野ごとの形とツールの成熟度は、該当する分野の部で扱います。

進歩的適用に分野共通で必要な3要素は、① Layer分離・ラベリングのインフラ（frontmatter・atom・ファイル名prefix）、② 候補の生成・評価サイクル（AIが候補をN個 → 自動評価 → 順位・根拠レポート）、③ 人によるレビューゲート（採択された結果だけが次のLayerへ）です。ただし、どの時点でも決定論コア（シミュレーション・物理・法的制約）は人と決定論的なコードが担当し、すべてのレビューは不可逆段階（録音・キャスティング・ライブ公開など）に入る前の可逆段階で完結させます — この可逆/不可逆の境界は分野共通の原則です。

最後に時点の話を一つ。保守的適用は2010年代にも部分的に可能でしたが、進歩的適用は、AIによる候補生成の表現力、自動評価の自然言語解釈、人のレビュー負担という三つの限界に阻まれていました。LLMの発展以降、三つとも実用域に入り、進歩的適用が紙の上のビジョンから実務の段階へ降りてきました。AIの発展がプロシージャル生成・自動化の実現可能性を引き上げたという、この本全体を貫くメタメッセージがここにあります。

2.3.7 分野の座標 — 本書の分野別の部が住む場所

本書の分野別の部は、各分野が主にどのLayerに分布するかを導入部で明示し、章の中でもLayer座標を頻繁に使います。先に整理しておきます（2.3.3のマトリクスの重心を表に移したものです）。

各分野は他のLayerにも触れますが、重心が分かれば協業の通路が見えます。バランス（L3）と運営（L2〜L4）はL3で出会うため常に近くで協業すべきですし、ビジョン（L0）に最も近い二つの分野はナラティブとアートディレクションです。こうした隣接関係が、座標系の上で自然に浮かび上がります。

2.3.8 小さく始めて、大きく育てる

Layerシステムを最初から完璧に導入しようとすると、スタートすら切れません。段階的に取り入れるのが正解です。

flowchart LR
    S1["第1段階
単一分野で導入
（推奨：ナラティブ）"] --> S2["第2段階
隣接分野へ拡張
（ナラティブ+コンテンツ）"]
    S2 --> S3["第3段階
全分野の標準化
（ファイル名prefix・整合性チェック）"]
    S3 --> S4["第4段階
AIツール統合
（JIT・変更影響・振り返り分類）"]
    S1 -.->|"小規模（〜10人）チーム"| E1["ここまでで十分"]
    S3 -.->|"中規模（10〜50人）チーム"| E2["ここまでを推奨"]
    S4 -.->|"大規模（100+）チーム"| E3["ここまで行ってこそ効果"]
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class S1,S2,S3,S4 human
    class E1,E2,E3 pass

• 第1段階（単一分野）：一つの分野（推奨：ナラティブ）だけを選び、フォルダをLayerで分割します。他の分野はそのままにして、1〜2か月運用しながらLayerの定義を磨きます。
• 第2段階（隣接分野へ拡張）：分化カーブが近い二つの分野（例：ナラティブ+コンテンツ）に同時に適用してLayerがかみ合うパターンを観察し、atomで整合性ルールを1〜2個作ります。
• 第3段階（全分野の標準化）：全分野にLayer座標を与え、ファイル名ルール（L1_・L2_・L3_のprefix）を導入し、関係図・整合性チェックを自動化します。
• 第4段階（AIツール統合）：JITフックでLayerメタデータを活用し、変更影響範囲を自動計算し、振り返りシステムにLayer分類を加えます。

各段階は最短でも1か月、長ければ四半期単位です。無理をすると人が疲弊します。運用負担が導入価値を超えないよう速度を調節するのがディレクターの仕事です。

小規模（〜10人）は第1〜2段階、中規模（10〜50人）は第3段階、大規模（100+）は第4段階まで行って初めて効果が出ます。小さいチームには使えないという意味ではありません。深さが違うだけで、核心的な価値は第1段階ですでに始まっています。

2.3.9 結論 — 本全体の背骨

Layerは単なるフォルダ整理の技法ではありません。分化したゲーム企画を一つの座標系で束ね、AIが推論できるようにするメタ原則であり、さらには分野別のプロシージャル生成・自動化に共通する前提条件です。

• 分化は生かす — 各分野の専門性と道具はそのまま残す。
• 統合は加える — すべての成果物が同じ座標系の上に整列する。
• AIはこの座標系を理解し、自動注入・整合性チェック・変更伝播を実行する（保守的適用）。
• 同じ座標系の上で、分野別の進歩的適用が段階的に育っていく。

本書の残りのすべての部は、本章を前提にしています。分野別の部は各分野がLayerで占める座標を導入部で明示し、プロセスの部はLayerを横断する運営システムを、運営の部はLayerシステム自体のself-improvingサイクルを扱います。

次の章（ゲームオントロジーと知識グラフ）は、Layerの上に意味の関係を加えます。Layerが座標なら、オントロジーはその座標の上の意味の矢印です。両者が合わさって初めて、AIは「この文書があの文書に影響を与える」を自律的に推論します。

はっきりさせておきたいことがあります。本章のどの自動化も、決定を代行してはいません。逆参照の検出で機械は違反候補を並べただけで、何をどこまで受け入れるかを選んだのは人の手でした。Layerは、人がより良い決定をより速く下せるよう助ける座標系であって、決定を丸投げする装置ではありません。

本章のポイント

• Layerは分野の分化を生かしたまま統合された可視性を加える座標系であり、本全体の背骨です。
• 5階層のそれぞれがプロシージャル生成の一つの役割（アンカー・ルール・本文・数値・ゲート）に対応します。
• 逆参照（L3→L1）の検出のように、AIが捕まえて人が削るのが自動化の正解の形です。

本章の核心atom（参考）

• layer_unified_design_philosophy — 本章の母体となるatom
• docs_layer_numeric_prefix_naming — ファイル名prefixの強制ルール
• dead_table_5layer_cleanup — 5階層外のシート整理ルール
• portal_layer_change_impact_check — 変更影響の自動チェック

次章のプレビュー

• 7章. ゲームオントロジーと知識グラフ — Layer座標の上に意味の矢印を加える
• 8章. Wikilinkシステム — 運営ノウハウから抽出した参照パターン

やってみよう

setup — 一つの分野（推奨：ナラティブ）のフォルダを選び、下位フォルダをLayer0_Vision/からLayer4_BuildVO/まで5つに分けてみましょう。既存のファイルを該当するLayerへ移してください。名前が曖昧なファイルは「この文書が変わる頻度」を基準に配置します（頻繁に変わるなら下のLayer）。

prompt — マスターデータのfrontmatterを二つ選び、2.3.5のプロンプト全文をそのまま貼り付けて、Layerの依存方向を判定させてみましょう。核心ルールを一行だけ正確に与えれば十分です。「参照は具体→抽象（高い番号→低い番号）へのみ流れていれば正常」。

verify — AIが逆方向の参照を捕まえたら、その勧告をそのまま受け取らず、適正ラインを自分で削りましょう（2.3.5の「人による検証/拒否」）。採択した方向だけをdiffで再依頼します。名前順に並べ替えたときにLayerが上から下へまとまって見えれば、prefixルールが根付いた証拠です。

一人ミニ版

一人で作業していてもLayerは機能します。チームがないので「分野間のサイロ」はありませんが、「時点間のサイロ」があります。3週間前の自分と今日の自分は、互いの決定を忘れます。フォルダをLayer 0〜4に分けるだけでも — ビジョン1枚、システム骨格数枚、進行フロー、マスターデータ、ビルドメモ — 過去の自分がどのマスに何を置いたか即座に見つかります。AIに「いまL2の作業中」と一行添えるだけで、無関係なLayerの資料を引っ張ってこなくなります。4階層・3階層に減らしても構いません。数字ではなく「階層を明示する」という行為が核心です。

2.4 オントロジーとwikilinkグラフ — 意味の矢印を検証する

月曜の午前、変更リクエストが1件上がってきました。戦闘チームのメンバーAが社内メッセンジャーに一行を書き込みます。「グローバルクールダウン（GCD）を0.5秒 → 0.3秒に変えます。影響を受けるところはありますか？」普段ならここから30分の会議が始まります。ダメージ計算式の担当が手を挙げ、コンボキャンセルルールの担当が割り込み、誰かが「ボスパターンにも影響があるのでは」と尋ねます。誰も全体像を頭の中にすべて持ってはいないので、会議は記憶をたどる作業で埋まっていきます。

ところが今回は違います。リクエストが上がった1秒後、ボットが自動でコメントを付けます。「このatomを変えると4個のatomが影響を受けます。skill_dps_calculation、combat_combo_cancel_v3、refgame_boss_pattern_phase2、balance_curve_v3。担当：メンバーB、メンバーA、メンバーC」。会議は開かれませんでした。4人がそれぞれ自分のatomだけを確認して終わりました（このボットは後ほど自分たちの手で作ります — 2.4.3）。

このコメントは魔法ではありません。2.3ですべてのatomにLayer座標を与え、その上に本章で意味の矢印 — どの決定がどの決定に影響を与えるのか — を加えたからです。座標は「ここに何がある」までしか語りません。「これがあれに影響を与える」「あれが先にないと成立しない」「この2つは同時に有効にしてはいけない」といった関係は、座標の上に描かれる矢印です。本章では、その矢印をどう表記し、壊れた矢印をどう自動で捕まえるかを扱います。

用語メモ - オントロジー（ontology）：概念とその間の関係を明示的に定義した体系。本書では6〜12個の関係に単純化した軽量版を使います。 - wikilink：[[atom_name]]形式の文書間リンク。Obsidian・Roamなどで使われる表記を借用しました。 - バックリンク（backlink）：「このatomを指しているatom」の一覧。順方向参照の逆方向。 - 孤立ノード（orphan）：どこからも参照されていないatom。廃止候補のシグナル。 - リンク切れ（broken link）：存在しないatomを指すwikilink。タイポ・名前変更の痕跡。

2.4.1 関係は矢印だ — wikilinkだけでは足りない理由

2.1でYAMLフロントマターとしてメタデータを付け、atomの本文にはwikilinkをちりばめました。それだけで文書はすでに網の目のようにつながります。問題は、そのつながりが何を意味するのか書かれていないという点です。

この決定は [[skill_cooldown_rule_v2]] の上で成立する。

この一行は「skill_cooldown_rule_v2に言及している」までしか語りません。なぜ言及するのでしょうか。この決定があの規則を必要とする（requires）のか、あの規則から派生した（derives_from）のか、それともあの規則と競合する（conflicts_with）のか。人は文章を読めば分かりますが、機械には分かりません。AIに「この決定を有効にすると壊れるものはあるか」と尋ねても、意味のないリンクだけでは答えられません。

そこでwikilinkに関係タイプを着せます。ゲーム企画で実際に使われる関係は意外と少ないものです。次の6つが90%以上をカバーします。

この6つをenumとして固定するatomがontology_relation_enum_v1です。新しい関係タイプを追加するには、変更リクエストのレビューを通すようにします。増えても10〜12個が適正ラインで、最初はaffects・derives_from・requiresの3つで始めても十分です。関係を書く場所はatomのYAMLフロントマターです。

---
name: combat_combo_cancel_v3
layer: 1
affects: [skill_dps_calculation, refgame_boss_pattern_phase2]
derives_from: [vision_taste_focused_combat]
requires: [combat_input_buffer_system, skill_cooldown_rule_v2]
conflicts_with: [skill_cancel_rule_legacy_v1]
---

人は順方向の1行だけを書きます。逆方向（「自分を誰がaffectsしているか」）は、ツールが全体をスキャンして計算します。affectsを両側に書くと同期の負担が2倍になり、片側だけ直してもう片側を忘れた瞬間、グラフが嘘をつき始めます。一方向だけ手で、逆方向はツールで — これが本章全体を貫く原則です。

2.4.2 ワークド・トランスクリプト — wikilinkのバックリンクとグラフ整合性を一度に検証する

ここからは、実際にあった1つのセッションを丸ごと載せます。状況はこうです。コンボキャンセル規則をv2からv3へ作り直すにあたり、skill_cancel_rule_legacy_v1を廃止することにしました。ただし廃止する前に、このatomを指している他のatomがないか（バックリンク）、そして廃止後にリンク切れや競合が残らないか（グラフ整合性）を確認しなければなりません。手でgrepすると見落とします。Claudeにやらせます。

プロンプト（全文）

添付した atom フォルダ(decisions/)には atom があり、フロントマターに関係
(affects/derives_from/requires/conflicts_with/is_a/part_of)が書かれて
いるはず。本文には wikilink もある。いま skill_cancel_rule_legacy_v1
を廃棄しようとしているが、廃棄前に3つを検査して: 1) 逆参照 2) 壊れたリンク
3) 競合。推測せず実際にファイルを読んで答えて。見つからなければ見つからないと言って。
// 逆参照=YAML 関係+本文 wikilink の両方 / 壊れたリンク=廃棄で stale・未存在になるリンク
// 競合=conflicts_with の相手のうち status: approved が生きているか

Claude出力（生のまま — 要約・整理なし）

decisions/フォルダの47個のファイルを読みました。skill_cancel_rule_legacy_v1に対する3つの検査結果です。

1. バックリンク（このatomを指しているatom）

YAML関係で指しているatom： - combat_combo_cancel_v3 — conflicts_with: [skill_cancel_rule_legacy_v1] - skill_cancel_rule_v2 — derives_from: [skill_cancel_rule_legacy_v1]

本文のwikilinkで指しているatom： - combat_combo_cancel_v3の本文：「旧バージョン[[skill_cancel_rule_legacy_v1]]の先行入力の問題を解決する」 - qa_combat_regression_checklistの本文：「リグレッション項目3番は[[skill_cancel_rule_legacy_v1]]を基準に作成」

つまり4個のatomがこのatomを参照しています（YAML 2 + 本文wikilink 2。ただしcombat_combo_cancel_v3は両方なので、実際のatom数は3個です）。

2. リンク切れ（廃止で壊れる箇所）

廃止そのものではwikilinkは「壊れ」ません — ファイルは残り、statusがdeprecatedになるだけだからです。ただし： - qa_combat_regression_checklistは廃止されたatomを基準にリグレッション項目を定義しているため、内容として無効になります。これはリンク切れではありませんが、staleリンクです。要検討。 - もしファイルを削除までされるなら、上の4個の参照がすべてリンク切れになります。

⚠️ 1つ曖昧な点があります：balance_curve_v3の本文に[[skill_cancel_rule_legacy]]（末尾に_v1がない）というリンクがあります。これがタイポで_v1を指そうとしたものなのか、それとも別のatomを意図したものなのか、ファイルだけでは確信できません。skill_cancel_rule_legacyという名前のファイルはフォルダにありません。つまり、これはすでにリンク切れである可能性が高いです。確認が必要です。

3. 競合の残存（conflicts_with相手が生きているか）

skill_cancel_rule_legacy_v1とconflicts_withで結ばれたatomはcombat_combo_cancel_v3の1つです。 - combat_combo_cancel_v3のstatus：approved（生きている）

→ 廃止対象と競合していた新規規則が正常に承認された状態です。これは正常です。旧バージョンを廃止して新バージョンが生き残る、自然な置き換えです。競合残存の警告ではありません。

---

要約：廃止は安全ですが、2つを先に処理してください。 (a) qa_combat_regression_checklistのstaleリンク — リグレッション項目3番の更新。 (b) balance_curve_v3の[[skill_cancel_rule_legacy]] — タイポの疑い。すでにリンク切れの可能性。

人による検証と拒否

ここで私は、出力をそのまま受け取りませんでした。(a)は正しい — リグレッションチェックリストは私が更新すべきものです。しかし(b)で立ち止まりました。Claudeはbalance_curve_v3の[[skill_cancel_rule_legacy]]を「タイポの疑い」としましたが、本当にリンク切れなのかは、私が直接フォルダを見る必要がありました。AIの「確信できない」は正直なシグナルであって、結論ではありません。

フォルダを開いて確認すると、skill_cancel_rule_legacyというファイルは実際にありませんでした。ところがgit logを見ると、6か月前にskill_cancel_rule_legacy → skill_cancel_rule_legacy_v1へと名前だけを変えたコミットがありました。そのときbalance_curve_v3の本文リンクを更新しそびれて、そのまま流してしまったのです。つまり、これはタイポではなくリネーム後に取り残されたリンク切れでした。Claudeの「タイポの疑い」という推測は半分だけ当たっていました。原因はタイポではなくリネーム漏れです。この違いを私が捕まえていなければ、リグレッションチェックリストだけを直して、リンク切れはそのまま埋もれていたでしょう。

再依頼（確認済みの事実を反映）

確認した。[[skill_cancel_rule_legacy]] はタイポではなく、6か月前の
rename(_legacy → _legacy_v1) のとき本文リンクを直しそびれた壊れたリンクだった。

ではこの機会にフォルダ全体から「存在しない atom を指す wikilink」を
全部探して。本文 wikilink 基準で、対象ファイルがフォルダにないもの全部。
ファイル名とその中の壊れたリンクを表で。

47個のファイルのすべての[[...]]本文wikilinkを収集し、フォルダのファイル一覧と照合しました。対象ファイルが存在しないリンク切れは3件です。

リンクを持つファイル	リンク切れのwikilink	推定原因
balance_curve_v3	[[skill_cancel_rule_legacy]]	リネーム漏れ（→ _v1）
quest_reward_table_v2	[[concept_reward_currency]]	対象atomが未作成（計画だけあってファイルなし）
refgame_boss_pattern_phase2	[[skill_global_cooldown]]	リネーム漏れ（→ skill_global_cooldown_rule）

3件のうち2件（リネーム漏れ）は、対象のatom名を_v1 / _ruleに直せば済みます。1件（concept_reward_currency）は指す先のatom自体がないため、作成するかリンクを削除する必要があります。自動では直していません — どちらを意図されたのか、確認のうえ進めてください。

3件とも事実でした。手でgrepしていたら、quest_reward_table_v2のリンク切れはほぼ確実に見逃していたでしょう。あのリンクは「まだ作っていないatomをあらかじめ指しておいた」意図された未来参照でしたが、6か月間誰もそのatomを作らず、事実上、死んだ約束になっていました。

このセッションが示すことは単純です。バックリンクの検出とリンク切れの検出は、フォルダ全体を読んで照合する作業に強いAIが担い、原因の判定と意図の確認は人が担う。AIは「ここが壊れている」まで、人は「なぜ壊れ、どう直すか」まで、です。

2.4.3 グラフに描くと見えるもの — 検証を視覚に移す

前節の検査を毎回プロンプトで回すこともできますが、同じ検査をコードに固めると、グラフの上で一目で見えるようになります。プロジェクトAでは、2.3で紹介したgen_relation_map.pyを拡張したグラフツールがR&Dとして動いています。核心は、フォルダのatomを読んでnetworkxの有向グラフとしてビルドした後、4つの検査関数を載せることです。

import networkx as nx

# build_graph(folder): atom フォルダを読んでノード(=atom)と
#   YAML 関係エッジで DiGraph を作る。(全文は「やってみよう」)

def find_cycles(G):                      # 循環依存
    return list(nx.simple_cycles(G))

def find_orphans(G):                     # インバウンド 0 = 孤立候補
    return [n for n in G.nodes if G.in_degree(n) == 0]

核心は2行です。simple_cyclesが循環依存（A requires B requires C requires A）を、in_degree(n) == 0が孤立ノードを捕まえます — 自分でDFSを書く必要はありません。残りの2つの関数も同じ調子の1行ものです。find_broken_wikilinksは本文の[[...]]を正規表現で収集してノード一覧にないものを選り分け、バックリンクはグラフを逆向きにたどれば出てきます（全文は「やってみよう」）。可視化は、ノードの色をLayerで、エッジの色を関係タイプで塗り、よく参照されるノード（インバウンドのエッジが多いノード）は大きく描いて、ハブが浮かび上がるようにします。キャビネットに色ラベルを貼って整理したフォルダのように、視野の中でパターンが先に浮かんでくるのです。

以下は、2.4.2のセッションで扱ったatomの実際の関係を写したグラフです。矢印の向きは「出発atomが到着atomへ関係を張る」という意味です。

graph LR
    combo[combat_combo_cancel_v3
L1·approved]
    legacy[skill_cancel_rule_legacy_v1
L1·deprecated]
    v2[skill_cancel_rule_v2
L1]
    dps[skill_dps_calculation
L3]
    vision[vision_taste_focused_combat
L0]
    buffer[combat_input_buffer_system
L1]
    boss[refgame_boss_pattern_phase2
L2]
    qa[qa_combat_regression_checklist
L4]
    broken[skill_cancel_rule_legacy
存在しない]

    combo -->|affects| dps
    combo -->|affects| boss
    combo -->|derives_from| vision
    combo -->|requires| buffer
    combo -->|conflicts_with| legacy
    v2 -->|derives_from| legacy
    qa -.stale.-> legacy
    balance[balance_curve_v3] -.broken.-> broken

    classDef dep fill:#eee,stroke:#999,stroke-dasharray:4
    classDef miss fill:#fff,stroke:#cc2222,stroke-dasharray:4
    class legacy dep
    class broken miss

点線で描かれた2本のエッジが、2.4.2で人による検証が捕まえた問題です。qa → legacyは廃止atom基準のstaleリンク、balance_curve_v3 → skill_cancel_rule_legacyは存在しないノードを指すリンク切れ。グラフに描けば、この2本の点線が実線の間で際立ちます。テキストだけで運用していたら、47個のファイルのどこかに埋もれて、永遠に見えなかったでしょう。

検証ゲート（Layer 4）で自動で回る規則は4つです。

• 循環依存：requiresの連鎖が自分自身に戻ってきたら警告。simple_cyclesで検出。
• 競合の同時有効化：conflicts_withで結ばれた2つのatomが両方ともstatus: approvedなら警告（2.4.2のケースは片方がdeprecatedのため通過）。
• 孤立ノード：インバウンド0で親もないatomは廃止候補として四半期ごとに点検。atom graph_orphan_detection_quarterlyがこの周期を明示しています。
• Layer逆行：L1 → L3のaffectsは正常（上位の決定が下位のデータに影響）、L3 → L1のaffectsは疑わしい。2.3の逆参照検出と同じ原理です。atom docs_layer_numeric_prefix_namingが文書名にLayer番号のprefixを強制しているため、逆行はファイル名を見るだけでも一次的にふるい落とせます。

この4つの規則がコードに固まれば、2.4.2のように毎回プロンプトを組む必要はありません。変更リクエストが上がった瞬間にボットがグラフを再ビルドし、影響を受けるatomの一覧とリンク切れ・循環・競合を自動コメントとして付けます。章の冒頭の「4個のatomが影響を受けます」というコメントがまさにこれです — このボットが、先ほど予告したあのボットです。

2.4.4 なぜLayerだったのか — プロシージャル生成のために分けた座標

ここで、2.3と2.4がなぜひとまとまりなのかを押さえておく必要があります。Layer座標と関係の矢印は別々に導入したものではなく、同じ目的の2つの面です。

表面的には、Layerはコラボレーションの言語を統一します — 「これはL1のシステム決定」「あれはL3のデータ」と呼べば、分野が違っても同じ座標を共有できます。しかし本質的な目的は別のところにあります。Layerはプロシージャル生成のために分けた座標でした。

L0のビジョンはコンテキストのアンカーです — 不変であり、AIに毎回注入されます。L1のシステムは生成の入力規則です — ルールブック・関係・タグがここに住みます。L2のコンテンツは生成された本文が積み上がる場所、L3のデータは数値・ID・関係としてシミュレーションの入力、L4のビルド・QAは検証ゲートです。関係の矢印は、この座標の上で生成の制約条件として働きます。AIが新しいコンテンツを作るとき、requiresの矢印は「これが先にないといけない」という前提になり、conflicts_withの矢印は「これは一緒に有効にしてはいけない」という禁止になります。

分野は分化しますが（戦闘・クエスト・経済がそれぞれ専門性を持つ）、すべての成果物がLayer座標を持つため互いを認知します。分化と統合が1つの座標系の上で同時に成立するのです。このグラフが十分に育てば、AIは候補を生成しながら関係の矢印を自動の制約として読み、人はレビューのゲートで違反の有無だけを確認すればよくなります。2.4.2のワークド・トランスクリプトがその縮小版です — AIがグラフを読んで制約違反（リンク切れ・競合）を見つけ、人がゲートで判定しました。

2.4.5 ドメイン概念もノードだ — 小さな語彙辞書

関係の矢印の出発点・到着点になるノードは、決定atomだけではありません。「スキル」「クエスト」「報酬」のようなドメイン概念を定義したatomも、グラフの第一級市民です。concept_skill_definition_v1はこんな形をしています。

# スキル (Skill)
Definition: キャラクターが戦闘中に発動する単位アクション。入力・クールダウン・リソース・効果を含む。
Required Properties: input / cooldown / cost / effects
Subtypes: active_skill (is_a) / passive_skill (is_a) / ultimate_skill (is_a)
Not a skill: 自動攻撃 [[concept_auto_attack]] / 変身 [[concept_transformation]]

boss_skill is_a skillと書けば、上位概念の規則が自動的に継承されます。プロジェクトAにはこうした概念定義atomが19個ほどあり、すべての決定atomがこれらを参照します。語彙が1つの辞書に統一されると、会議・文書・コードの間の翻訳負担が消えます。机ごとに別の辞書を置かず、同じ辞書を共有するようなものです。先ほどのワークド・トランスクリプトでリンク切れとして捕まったconcept_reward_currencyが、まさに「辞書に載せると決めておきながら、まだ作っていない空の項目」でした。

2.4.6 軽く保つ — 学術オントロジーの罠

ここまで読むと、「これはOWL/RDFのような正式なオントロジーではないのか」という質問が出てきます。違います。そして、わざと違うように作りました。

学術オントロジー（OWL・RDF・SKOS）は強力ですが、関係タイプが数十〜数百個あり、専用の推論エンジンが必要で、運用するにはオントロジーの専門家が付かなければなりません。検索エンジン・医療・法律のように精密な推論が生死を分ける領域では必須です。しかしゲーム企画で実際に必要な推論は「変更の影響範囲」「先行依存関係」「競合検出」だけで、すべてグラフを1マスずつたどって調べる単純探索（BFS・DFS）のレベルで済みます。networkxの1行で循環を捕まえた前節がその証拠です。正式な推論エンジンは過剰です。

基準は1つです。プランナーが手で運用できるか。YAMLの6個のenum、networkxでの処理、pyvisやD3.jsでの可視化。この線を越えた瞬間、ツールはツールであることをやめ、もう1つの負担になります。軽さは妥協ではなく、設計の意図です。

この罠を避けるうえで、繰り返される失敗が5つあります。どれも「オントロジーを強制標準として扱った場面」という同じ根から育ちます。

1・2・3番は導入1か月以内にパターンを押さえ、4・5番は3か月目の振り返りで点検すれば、自然と整っていきます。

2.4.7 小さな始まりと次章

最初のひと月は赤字です。関係を書く負担だけが積み上がり、目に見える効果はありません。だから小さく始めます。最初の週はaffects・derives_from・requiresの3つの関係だけ、2〜4週目は中核のatom 20個に適用しながら、グラフが育っていく様子を見守ります。1か月目に前節レベルのHTMLグラフビューを1つ作れば、2か月目から可視化が価値を見せ始め、3か月目には自動検証（循環・競合・孤立・リンク切れ）が会議時間を直接減らします。赤字のひと月に耐えることが、導入の成否の分岐点です。

次の第8章Wikilinkでは、本章で矢印として扱った[[...]]表記を運用の次元で深く掘ります — バックリンクパネルを毎日どう使うか、名前変更時にリンクをまとめてどう更新するか（2.4.2のリネーム漏れをそもそも防ぐ方法）、Obsidianのようなツールのグラフビューを実務にどう溶かし込むか。YAML（第4章）→ Atom（第5章）→ Layer（第6章）→ Ontology（第7章）→ Wikilink（第8章）が、情報アーキテクチャの完成された五角形です。

やってみよう

setup. atomが集まったフォルダ（例：decisions/）を決め、各atomのYAMLに関係キーを書く準備をしましょう。最初はaffects・derives_from・requiresの3つだけ。本文のリンクは[[atom_name]]形式に統一します。

prompt. 廃止・名前変更の前に、以下を投げてみましょう。

このフォルダのマークダウン atom を読んで。私が [対象_atom] を廃棄/変更しようとしているが
(1) 逆参照: この atom を YAML 関係と本文 wikilink で指す atom 全部
(2) 壊れたリンク: 変更/削除時に壊れるか stale になるリンク
(3) 競合の残存: conflicts_with の相手のうち status: approved のもの
を検査して。推測せず実際にファイルを読んで、見つからなければ見つからないと言って。

verify. AIが「タイポの疑い」「確信できない」と付けた箇所は、人が直接開いて確かめましょう。リンク切れの原因（タイポか、リネーム漏れか、未作成か）は、git logとフォルダの実物で人が判定します。自動修正はさせず、意図を確認してから自分の手で直します。

グラフツール全文（2.4.3の抜粋）

本文（2.4.3）では核心の2つの関数だけを見せました。フォルダ全体をグラフとしてビルドし、4つの検査をかける全文は次のとおりです。

import networkx as nx
import re, yaml, glob, os

REL_TYPES = ["affects", "derives_from", "requires",
             "conflicts_with", "is_a", "part_of"]
WIKILINK = re.compile(r"\[\[([a-zA-Z0-9_]+)\]\]")

def build_graph(folder):
    G = nx.DiGraph()
    files = {}
    for path in glob.glob(os.path.join(folder, "*.md")):
        name = os.path.splitext(os.path.basename(path))[0]
        text = open(path, encoding="utf-8").read()
        fm = yaml.safe_load(text.split("---")[1]) or {}
        files[name] = fm
        G.add_node(name, layer=fm.get("layer"), status=fm.get("status"))
    # YAML 関係エッジ
    for name, fm in files.items():
        for rel in REL_TYPES:
            for tgt in (fm.get(rel) or []):
                G.add_edge(name, tgt, type=rel)
    return G, files

def find_broken_wikilinks(folder, known_nodes):
    broken = []
    for path in glob.glob(os.path.join(folder, "*.md")):
        text = open(path, encoding="utf-8").read()
        for m in WIKILINK.findall(text):
            if m not in known_nodes:
                broken.append((os.path.basename(path), m))
    return broken

def find_orphans(G):
    # インバウンド 0 かつ part_of/is_a の親もないノード
    return [n for n in G.nodes if G.in_degree(n) == 0]

def find_cycles(G):
    return list(nx.simple_cycles(G))

一人ミニ版

ツールがなくても大丈夫です。atomフォルダが1つ、Claudeが1つあれば十分です。新しい決定を書くときにYAMLへrequires・affectsの2行だけ追加し、廃止・名前変更が発生するたびに上のpromptを1回回してみましょう。グラフの可視化は後回しで構いません — リンク切れと競合を変更の直前に1回ざっと見る習慣、その1回が、一人運用で最大の赤字を防ぎます。

本章のポイント

• 座標の上に意味の矢印を着せてはじめて、「何が何に影響を与えるのか」が自動で推論できる
• バックリンク・リンク切れの検出はAIが、原因の判定と意図の確認は人が担う
• 軽さは妥協ではなく設計の意図 — 手で運用できなければツールが負担になる

第3部 · System Design

3.1 システムプランナーの仕事とLayer座標

木曜日の午後4時50分。バランス担当が埋めたスキルシートが、ちょうど上がってきました。スキルは312個。各スキルはeffect_idという欄に効果番号を記入することになっており、その番号は別の効果シートにある行を指します。両者が噛み合って初めてゲームは動きます。合わなければ、クライアントが空の効果を呼び出すか、静かに落ちます。

以前の私は、これを目視でチェックしていました。スキルシートのセルを1つ見て、効果シートへジャンプし、番号を確認して、また戻る。これを312回。速くても2時間です。目がかすんでくる最後の50個で必ず1〜2個を見落とし、その1〜2個がQAビルドで火を噴きました。

本章は、その2時間がどこへ消えたのか、そしてあの整合性チェックがシステムプランナーの作業地図のどこに打たれる座標なのか、という話です。先に座標を定めないと、AIをどこに組み込むべきかを、いつまでも勘だけで決め続けることになります。

3.1.1 システムプランナーは4つのものを作る

システムプランナーは、抽象と具体のあいだを最も広く行き来する人です。ビジョンという霧を受け取り、マスターデータの最後のセルという固い数字まで引き下ろしていきます。その道のりで生まれる成果物は4種類です。

（1）ビジョンを構造に翻訳する。 ディレクターが「打撃感が生きたアクション戦闘」と言えば、システムプランナーはそれをスキル・コンボ・キャンセル・ヒットストップという骨格に置き換えます。「成長の自己決定権」はクラス・スキルツリー・装備システムになります。霧が構造物になる最初の瞬間です。

（2）システム間のインターフェースを仕様化する。 戦闘・移動・インベントリ・ショップ・クエスト・ギルドが同時に動きます。戦闘中にインベントリを開いたら無敵が付くのか？　強化の最中にPvPの申請が届いたら？　こうしたケースの答えが集まって、「よくできている」という手触りを作ります。答えが抜けた場所ごとに、ユーザーはストレスを感じます。

（3）マスターデータとそのスキーマに責任を持つ。 スキル312個の係数、数百個のアイテムの効果、数十種のモンスターの行動。値は自分で埋めるか、バランスやコンテンツの担当へ渡します。しかしシートの カラム定義（スキーマ） だけは、システムプランナーが握ります。ラベルの付いた引き出しを用意してあげる仕事です。引き出しが雑だと、人によって違う入れ方をしてしまい、整合性が壊れます。

（4）行動ロジックを設計する。 キャラクターやモンスターのAIは、ステートマシン（FSM、Finite State Machine、有限状態機械）、ビヘイビアツリー（Behavior Tree、以下BT）、決定テーブル、プロシージャル規則といった形で出てきます。この資料がプログラマーに渡り、コードになります。

この4つがすべて1人の机の上で出会う、という点が核心です。だからこそ「今日は何に時間を使うか」が、システムプランナーにとって最大の運営判断になります。

3.1.2 システムの成果物はLayer座標を持つ

2.3で私たちは、ゲームの制作物全体をL0（ビジョン）からL4（ビルド）までの座標軸に載せました。今度は3.1.1の4つの成果物を、その軸の上にそのまま打ってみます。システム企画ほど、1つの分野の成果物が複数のLayerに広く散らばる例はまれです。

次の図は、成果物がLayer上のどこに住んでいて、各座標で誰と出会うのかを1枚に描いた地図です。

この地図が語ることは2つです。第一に、システムプランナーはL0を受け取ってL4まで届かせるという長い距離に責任を持ちます。第二に、自分の手で直接作る区間はL1〜L3で、その3つのマスごとに協業相手が変わります。マスが変わるたびに協業の言語も変わるため、座標を意識しないと会議が空回りし続けます。

ただし、1人がL1〜L3をすべて触るという意味ではありません。チームが大きければ、L1〜L2の担当とL3の担当は分かれます。チームが小さければ1人で全部見ます。座標は役割分担の地図であって、1人に全部押し付けろという命令ではありません。

3.1.3 座標が決まれば、AIを組み込む場所が見える

地図が描けたので、今度は色を塗ります。どの座標がAI導入の効果が大きいのか。やみくもに「全部自動化」ではなく、座標の性質を見て選びます。

flowchart TD
    L1["L1 システムの骨格
(クラス数、戦闘モデル)"]
    L2["L2 インターフェース
(相互作用ルール)"]
    L3["L3 スキーマ + データ
(312行のシート)"]

    L1 -->|"ゲームのアイデンティティに直結
人が決定"| H1["AI = 人の決定の変形/検証を補助"]
    L2 -->|"ケースが爆発
影響範囲が大きい"| H2["AI = 変更の影響範囲を自動抽出"]
    L3 -->|"定型・反復
整合性チェック"| H3["AI = 生成・検証・変換を専任"]

    H1 --> R["人は核心の決定、
AIはディテール・整合性・反復"]
    H2 --> R
    H3 --> R

    style L3 fill:#fff8e1,stroke:#f9a825
    style H3 fill:#e8f5e9,stroke:#2e7d32
    style R fill:#e3f2fd,stroke:#1565c0

核心は、座標が下に降りるほどAIに専任させる比重が大きくなるということです。L1の「クラスをいくつにするか」はゲームのアイデンティティに直結するため、人が握るべきです。逆にL3の「312行の外部キーがすべて合っているか」は定型・反復なので、AIに丸ごと任せるべきです。L2はその中間です。決定は人がするものの、「このルールを変えたらどこまで揺れるのか」という影響範囲の抽出をAIが支えます。

この図が、3.1.4以降のすべての実習がなぜL3の近くから始まるのかを説明しています。効果が最も大きく、リスクが最も小さい場所だからです。スキーマツールが誤作動しても事故にはなりませんし、関係マップは図を描くだけですし、整合性チェックは人が拒否できます。

3.1.4 ワークド・トランスクリプト：座標L3でAIに整合性チェックを任せる

理論はここまでです。3.1の冒頭のあの木曜日に戻ります。スキルシートにある312個のeffect_idが効果シートと合っているか、AIにやらせてみます。要約せず、実際にやり取りしたままを載せます。

データ入力はschema-firstの原則に従います。つまり、人が先に仕様書シートを定義し、そこからEnumと.protoが生成され（VBA（Excelのマクロ言語）によるExport）、最後にcsvデータが埋められます。だから検証プロンプトも「スキーマから読め」で始まります。正本はスキーマドキュメントではなく 実際にexportされたJSON だという点を、先に明言しておきます（json_over_schema_doc_as_source_of_truth）。ドキュメントは嘘をつけても、exportされたJSONは嘘をつけないからです。

プロンプト（全文）

あなたは私たちのプロジェクトのデータ整合性チェッカーです。 入力は2つのexport JSONです。 1) skill.json — 各スキルオブジェクトにskill_id、name、effect_idフィールドがあります。 2) effect.json — 各効果オブジェクトにeffect_id、effect_typeがあります。

次を検査してください。 (A) skill.jsonのすべてのeffect_idがeffect.jsonに存在するか（外部キー整合性）。 (B) effect.jsonにはあるが、どのスキルからも参照されていない孤児（orphan）効果。 (C) skill.jsonの中でeffect_idが空、または0になっている行。

ルール：推測しないこと。JSONにないフィールドは「フィールドなし」と報告すること。 出力は(A)(B)(C)の3セクションに分け、違反1件ごとにskill_id（またはeffect_id）と理由を1行で。 違反がなければ、該当セクションに「違反なし」とだけ書くこと。

Claudeの生の出力（加工・美化なし）

入力のJSON 2つを受け取っていません。現在のメッセージにはファイルの内容が添付されていません。 次のいずれかの形で送り直してください。 - skill.jsonとeffect.jsonの実際の内容（貼り付けまたはファイル添付） - または2つのファイルのパス

内容を受け取ったら(A)(B)(C)の順に検査します。ファイルなしで結果をでっち上げることはしません。

ここで止まったことが、むしろ信頼のシグナルでした。入力が空なのに、もっともらしいレポートが返ってきたとしたら、その綺麗さこそ危険信号です。手ぶらで検査結果を作り出さず、「まずファイルをください」と聞き返してきたほうが信頼できます。私は2つのJSONを実際に貼り付けて再依頼しました（分量の都合で、本文には一部のみ抜粋します）。

// skill.json (抜粋)
[
  {"skill_id": 1001, "name": "強打",     "effect_id": 5001},
  {"skill_id": 1002, "name": "回転斬り", "effect_id": 5002},
  {"skill_id": 1003, "name": "盾上げ","effect_id": 0},
  {"skill_id": 1004, "name": "毒塗り", "effect_id": 5099}
]

// effect.json (抜粋)
[
  {"effect_id": 5001, "effect_type": "DAMAGE"},
  {"effect_id": 5002, "effect_type": "DAMAGE"},
  {"effect_id": 5003, "effect_type": "BUFF"}
]

Claudeの2回目の出力（実データ基準）

(A) 外部キー整合性 — 違反1件 - skill_id: 1004 → effect_id: 5099がeffect.jsonに存在しない（dangling reference）

(B) 孤児効果 — 違反1件 - effect_id: 5003 (BUFF) → どのスキルからも参照されていない

(C) 空/0のeffect_id — 違反1件 - skill_id: 1003 → effect_id: 0。意図された「効果なし」の可能性もあるため、0が有効値かどうかスキーマでの確認が必要。

人による検証と拒否

3件のうち2件は明白なバグでした。5099は、バランス担当が効果シートに行を追加する前に、スキル側へ先に書き込んでおいたものでした。作業の順序がずれた典型的なケースです。これで1つ捕まえました。

ところが(C)は拒否しました。私たちのプロジェクトでは、effect_id: 0は「パッシブスロット、効果なし」を意味する有効な約束値です。AIはそれを知らないので「確認が必要」と報告してきました。その判断自体は正しいものの、違反として数えるものではありません。そこで私は次の一手に進みました。この約束をatomとして固定化し、次のチェックからはAIが0を有効値として知っている状態を作ることです。

再依頼（ドメイン知識の注入）

追加ルール：effect_id == 0は「パッシブ、効果なし」を意味する、私たちのプロジェクトの有効な約束値です。 したがって(C)では、effect_id == 0は違反ではありません。空文字列・null・負数のみを(C)の違反として報告してください。

(C) 空/0のeffect_id — 違反なし （effect_id: 0は有効な約束値として処理。空/null/負数はなし。）

このたった1行の約束こそが、ドメイン知識の蓄積です。システム企画の決定は比較的恒久的なので、一度固定化すれば、1年後も同じチェックが同じ基準で回ります。キャビネットに決定カードが1枚積まれました。

このトランスクリプトで人がやったことは 3つだけ です。（1）スキーマから読めという入力順序の指定、（2）5099が本物のバグであることの確認、（3）0が有効値だと知っていて、AIの判断を拒否・矯正したこと。残りの、312行をセル1つずつジャンプしながら見ていた2時間は消えました。自動化されたのはジャンプと照合という労働であり、残った3行分の判断こそが核心です。

3.1.5 蓄積される資産：座標をコードとして固める

上のトランスクリプトのチェックを毎回手作業で依頼することもできますが、L3で繰り返される仕事はツールとして固めるのがシステム企画の定石です。著者が運用している2つを引用します。抽象的な「プロジェクトAのツール」ではなく、実際に机の上で回っているものです。

gen_relation_map.pyは、シートのカラム名と値を分析して外部キーの関係を自動検出し、インタラクティブなHTML関係マップを出力します。3.1.4でskill.effect_id → effect.effect_idという矢印を人が頭の中に描いたとすれば、このスクリプトはその矢印を、シート全体について図として描いてくれます。依存が逆行している場所（L3のデータがL1の骨格を逆参照する危険）が、図の上で即座に浮かび上がります。

schema-docスキルは、xlsmの $スキーマシート をパースして、Markdown（マークダウン）形式のスキーマドキュメントを自動生成します。3.1.4の(C)で「0が有効値かどうかスキーマでの確認が必要」という質問が出てきた、あのスキーマです。人がほかのファイルを漁らなくても、最新のスキーマをすぐ読めるようにします。シートが変わればドキュメントも追従して変わるため、ドキュメントと実データが食い違うという持病が減ります。

2つのツールの持ち場を座標で言い直すと、こうなります。schema-docはL3のカラム定義を守り、gen_relation_map.pyはL2〜L3のあいだの関係を守ります。AI補助プロンプト（3.1.4のような検証）は、その上で回ります。3つはバラバラに動くのではなく、同じ座標軸の異なる高さを受け持ちます。

これらのツールの実際の使い方は、3.2・3.3・3.4で手を動かしながらたどります。3.1は「どこに組み込むか」を決める地図であり、続く3つの章が、組み込む作業そのものです。

3.1.6 漸進的な導入：リスクの小さい座標から

3つのツールを一度に稼働させると、運用の負担が効果より先に届きます。著者の経験では、安全な順序はリスクの小さい座標（下側）からです。

期間は絶対的な基準ではありません。チームの規模や既存のインフラ次第で、倍かかることも、半分で終わることもあります（著者の推定、未検証）。変わらないのは順序です。リスクの大きい「決定の補助」を最後に置けば、先行する2つのツールでチームがすでに検証の習慣を身につけたあとに、最も敏感な場所へ触れることになります。

3.1.7 測定 — 正直に

数値を美化せずに記します。以下は、著者がディレクターとして運営するMMORPGプロジェクト（以下「プロジェクトA」）の企画チーム（人数4〜5人、開発チーム全体は中規模の10〜50人、運用約6か月）で観察したものです。正確な自動計測ではなく、作業ログと振り返りの記録に基づく 著者の観察 であり、方向性とおおよその比率としてだけ読むことをおすすめします。

• 整合性チェック：312行のスキル↔効果の外部キー照合は、手作業では速くても2時間でした（冒頭のあの木曜日です）。AI検証では、入力の準備を除けば数分以内に違反リストが出ました。減ったのはジャンプと照合の労働であって、判断ではありません。
• 新規プランナーのオンボーディング：関係マップのHTMLが1枚あれば、システムの依存構造を口頭で説明する会議を何度か減らせました。正確な回数は人によって異なるため、断定はしません（著者の観察）。
• 変更影響の議論：「このルールを変えたらどこが揺れるのか」を会議で手探りしていたのを、AIから影響範囲のドラフトを先に受け取り、人がレビューする方式に変えました。会議がなくなったのではなく、会議がレビューになったのです。

核心は、節約された時間が「ゲームを作らない時間」ではないという点です。その時間は、L1の骨格のような、AIに任せられない深い決定へと戻っていきます。労働を減らして判断に使うこと。それが本章のすすめる1行です。

やってみよう：座標L3で整合性チェックを1回

setup. シートを2つ（例：スキル、効果）csvでexportしましょう。余裕があればJSONに変換しておきます（ドキュメントではなくexportの成果物が正本だという原則です）。2つのシートのあいだで外部キーを1組選びます（例：skill.effect_id → effect.effect_id）。

prompt. 3.1.4のプロンプト全文をそのまま使いましょう。核心の3行を抜かさないでください。（1）「スキーマ/構造から読むこと」、（2）「推測せず、ないものは『ない』と報告すること」、（3）「違反がなければ『違反なし』とだけ書くこと」の3つです。

verify. AIが挙げた違反リストを、人が1行ずつ確認します。本物のバグは直し、ドメインの約束値（例：0 = 효과 없음、つまり「0は効果なし」）のせいで生じた誤検知は拒否して、その約束をプロンプト（またはatom）に追加します。次のチェックから同じ誤検知が消えれば、資産が1枚積まれたということです。

一人ミニ版

チームもシートもない1人開発者なら、Googleスプレッドシートのタブ2つで十分です。1つのタブは「スキル」、もう1つのタブは「効果」。effect_idカラム1本で両者をつなぎましょう。タブをcsvでダウンロードして3.1.4のプロンプトに貼り付ければ、312行ではなく30行のシートでも、まったく同じようにdangling referenceと孤児効果が捕まります。規模が違うだけで、座標は同じです。L3から始めて、手になじんだら関係マップと影響範囲へ、1段ずつ上に登っていきましょう。

本章のポイント

• システムの4つの成果物は、L1の骨格からL3のシートまでの座標を持ち、座標がそのまま協業相手になります
• 座標が下（L3）へ降りるほど、AIに専任させる比重が大きくなり、リスクは小さくなります
• 自動化されるのはジャンプと照合という労働で、バグの確認と誤検知の拒否という判断は人の役割です

3.2 スキーマファースト — $스키마はデータより先

月曜の午前、新人プランナーが埋めたスキルシート120行をcsvへビルドしたところ、クライアントのログに赤い行が28個出ました。class_idが47番を参照しているのに、クラスシートには47番が存在しません。elementの欄には、ある人はFireと書き、別の人はfireと書き、さらに1行は화염（韓国語で「炎」）とハングルで書かれています。赤い行28個を1行ずつ手でたどるうちに、午後の半分が消えていきます。

この事故の原因は、データが間違っていたからではありません。データを作る前に、そのデータが従うべき規則を明示しなかったからです。規則が頭の中にしかなければ、人が替わった瞬間に規則も変わります。本章では、規則（スキーマ）をデータより先に作るワークフローを扱います。そして、その規則を人の手ではなくツールがドキュメントとして強制する形に変えていきます。

用語メモ - スキーマ（schema）：マスターデータシートのカラム定義。名前・型・範囲・外部キー・説明。 - $스키마：Excelのマスターデータ（xlsm）の中に置く、カラム定義専用のシート。データ行ではなく、カラムの規則だけを収めます。 - FK（外部キー）：他のシートのPK（主キー）を参照するカラム。class_idがClassシートの行を指す、という形です。 - proto：Protocol Buffersの定義（.proto）。クライアントとサーバーが共有するデータ構造・Enumの契約です。 - 信頼できる唯一の情報源（single source of truth）：同じ情報を1か所だけで管理し、全員がそこを参照する運用原則です。

3.2.1 入力の順序こそがスキーマ

スキーマファーストを「カラムを事前に定義すること」とだけ理解しているなら、半分しか捉えていません。核心は何を先に入力するかという順序にあります。データを埋める手がどの順序で動くかが、整合性が守られるか崩れるかを決めます。

本書が推奨する入力順序は、4つのマスからなるパイプラインです。

flowchart LR
    A["$스키마シート
(カラム規則の定義)"] --> B["Enum / *.proto
(VBA Exportでコード契約を生成)"]
    B --> C["csvデータ
(規則の中で行を埋める)"]
    A -.->|schema-doc| D["スキーマドキュメント
(.md自動生成)"]
    C -.->|gen_relation_map.py| E["FK関係図
(HTML自動生成)"]
    D -.-> F(("AI / 人
同じ定義を読む"))
    E -.-> F
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class A,B,C,D,E data

左から右へ流れる実線が強制される入力順序です。$스키마を先に定義し、そこからEnumとprotoをVBA（Excelのマクロ言語）のExportで生成し、その契約の中でだけcsvデータを埋めます。点線は、その入力から自動的に派生する成果物（スキーマドキュメントschema-docとFK関係図gen_relation_map.py）で、人とAIはこの派生物を通じて同じ定義を見ます。

この順序が強制されている限り、本章の冒頭で見た赤い行28個の大半は、データを埋める前に塞がれます。elementがfire/ice/lightning/noneの4つのうちの1つであるという事実がprotoのEnumとして固定されていれば、Fireも화염も入力段階で弾かれます。class_idがClassシートのPKを参照するという事実が$스키마に明示されていれば、47番の欠落はビルドではなくチェックの段階で先に捕まります。

順序を逆にすると、つまりデータを先に埋めてスキーマを後で整理すると、スキーマは事後の掃除になります。1000行がすでに積み上がった場所でカラム規則に手を入れると、規則がデータを追いかける形になり、その瞬間、情報源の主従が逆転します。

3.2.2 ワークド・トランスクリプト — $스키마からcsvまで一気に

言葉で説明する代わりに、実際に1つのシートを最初から最後まで通してみます。スキルシートを新しく作るとしましょう。以下は、AIの補助を入れて進めた全記録です。要約はせず、食い違った箇所と人が拒否した箇所をそのまま残します。

ステップ1 — 人が$스키마を先に手で書く

ツールもAIもまだ呼びません。カラム規則は人が直接定義します。このステップだけは委任しません。

# Skill シート $스키마 (人が作成)
カラム           タイプ      範囲/制約              FK                  説明
skill_id       int        1000~9999            (PK)                スキル固有ID
name           string     1~30字                -                  表示名
class_id       int(FK)    -                    Class.class_id      使用可能クラス
cooldown       float      0.0~120.0            -                   再使用待機(秒)
damage_coef    float      0.0~10.0             -                   攻撃力乗算係数
element        enum       fire/ice/lightning/none  -              属性
is_passive     bool       true/false           -                  パッシブかどうか

ステップ2 — AIにproto Enumのドラフトを任せる（プロンプト全文）

$스키마のelement enumとFK構造をprotoの契約に移す作業です。形式変換なので、AIに任せられる仕事です。

プロンプト（全文）： 以下はゲームのマスターデータシートのカラム仕様である。この仕様をProtocol Buffers（proto3）のメッセージとEnumに変換せよ。規則：（1）enum型のカラムは独立したenumとして定義し、最初の値は必ず_UNSPECIFIED = 0で始める。（2）FKカラムは参照先をコメントで残す。（3）範囲制約はprotoでは表現できないため、コメントとしてのみ残す。仕様にないカラムは追加しないこと。

skill_id int PK / name string / class_id int FK→Class.class_id /
cooldown float 0~120 / damage_coef float 0~10 /
element enum{fire,ice,lightning,none} / is_passive bool

ステップ3 — Claudeの生の出力（そのまま、手を加えず）

syntax = "proto3";

// Skill シートのデータ契約
// 注意: 範囲制約(cooldown 0~120, damage_coef 0~10)は
//       protoでは強制不可。Linterで検査すること。

enum SkillElement {
  SKILL_ELEMENT_UNSPECIFIED = 0;
  SKILL_ELEMENT_FIRE = 1;
  SKILL_ELEMENT_ICE = 2;
  SKILL_ELEMENT_LIGHTNING = 3;
  SKILL_ELEMENT_NONE = 4;   // ← 人によるレビューの印
}

message Skill {
  int32 skill_id = 1;       // PK
  string name = 2;
  int32 class_id = 3;       // FK → Class.class_id
  float cooldown = 4;
  float damage_coef = 5;
  SkillElement element = 6;
  bool is_passive = 7;
}

ステップ4 — 人による検証と拒否

ここで人が1か所を拒否します。AIはnoneをSKILL_ELEMENT_NONE = 4としてenumの末尾に配置しましたが、$스키마においてnoneは「属性なし」という既定の状態です。争点はprotoの0番の値です。proto3ではenumの0番は「値が入力されなかったときに自動的に入る場所」なので、0番を_UNSPECIFIED（値未入力）として空けておくか、none（意図的な無属性）のような意味のある値で埋めるかで判断が分かれます。両者を1つの場所に統合すると、欄を空けたままにした行（ミス）と無属性をあえて選んだ行（意図）が同じ0として入ってきて、永遠に区別できなくなります。AIは_UNSPECIFIED = 0とnoneを別個に置いてはいたものの、noneを4番という末尾に送ったため、最もよく使う既定状態が検索・デバッグから遠ざかってしまいました。

人が下した決定は次のとおりです。 - _UNSPECIFIED = 0は維持します（欠落検出用）。 - noneはそのまま残しつつ、csvの作成規則に「無属性は必ずnoneを明示、空欄禁止」を追加します。空欄=0=UNSPECIFIEDは入力エラーと見なします。 - この決定を$스키마のelement行の説明に1行追加します：「無属性も明示（none）。空欄はエラー」。

AIの出力をそのまま使ったわけではありません。形式は受け取り、意味の境界線は人が引きました。

ステップ5 — VBA ExportボタンでEnum/protoをシートから生成する

検証済みのproto定義は、ExcelのExportマクロ（$스키마シートのボタン）が一貫して出力します。人がIDEで再度タイピングすることはありません。シートが唯一の情報源なので、protoはシートから生まれます。この順序は、3.3で扱う「出力が正本」（json_over_schema_doc_as_source_of_truth）原則の延長です。ドキュメントがコードを説明するのではなく、シートがコードを生むのです。

ステップ6 — ようやくcsvデータを埋める（AI補助、再リクエスト込み）

プロンプト（全文）： 上のSkill protoと$스키마を満たすcsv行を5つ作れ。制約：class_idは[1,2,3]のいずれか（現在Classシートに存在するPK）、damage_coefはパッシブ（is_passive=true）なら0.0、elementはfire/ice/lightning/noneの文字列そのまま、空欄禁止。

Claudeの最初の出力では、1行が規則から外れていました。

skill_id,name,class_id,cooldown,damage_coef,element,is_passive
1001,화염베기,1,3.5,2.4,fire,false
1002,빙결의손,2,8.0,3.1,ice,false
1003,체력회복,1,0.0,1.2,none,true     ← 拒否: パッシブなのにdamage_coef≠0
1004,번개창,3,5.0,2.8,lightning,false
1005,방어태세,2,0.0,0.0,none,true

1003行が規則違反（is_passive=trueならdamage_coef=0.0でなければならない）です。人が拒否して再リクエストしました。

再リクエスト（全文）： 1003行が規則違反。is_passive=trueなのにdamage_coefが1.2だ。パッシブは0.0でなければならない。1003だけ直してもう一度出せ。

Claudeの再出力： 1003,체력회복,1,0.0,0.0,none,true

AIが最初の試行ですべてを正しく出せないのは、欠陥ではなく、ただ普通に起きることです。重要なのは、スキーマが敷かれていたおかげで、その外れた1行を目で特定し、1行の指摘で元に戻せたという点です。スキーマがなければ、1003はビルド後のゲーム内で「パッシブなのにダメージが出る」バグとして発見されていたはずです。

このトランスクリプト全体の教訓はシンプルです。入力順序が$스키마 → proto → csvに固定されていれば、AIは形式を素早く埋め、人は意味と違反だけをレビューします。順序が崩れると、人が形式から意味まで全部を抱え込むことになります。

3.2.3 schema-doc — スキーマを人が書き写さないために

$스키마をExcelの中に置くとプランナーにとっては快適ですが、AIやgit、外部ツールにとっては閉ざされた場所です。そこで、$스키마をMarkdown（マークダウン）に自動変換するツールを運用しています。スラッシュスキルschema-docがこの仕事を担います。

動作は4ステップです。

1. Excel（xlsm）の$스키마シートをパースする（python-calamine、Rustによる高速化）
2. カラム定義の5要素を抽出する
3. Markdownの表に変換する
4. 同じフォルダーに<시트명>_schema.md（「シート名_schema.md」の意）を生成する

核心は、人がスキーマを二度書かないことです。Excelで一度定義すれば、Markdownはツールが作ります。両者が食い違うことはあり得ません。3.3で扱う「スキーマドキュメントを正本に据えると実際の出力とずれる」という落とし穴を、ここでは「Excelが正本、ドキュメントは派生」とひっくり返すことで回避します。

schema-docが生成した結果（先ほどのトランスクリプトのSkillシート基準）です。

# Skill シート スキーマ  (自動生成 — 直接修正禁止)

| カラム | タイプ | 範囲/制約 | FK | 説明 |
|---|---|---|---|---|
| skill_id | int | 1000~9999 | (PK) | スキル固有ID |
| name | string | 1~30字 | - | 表示名 |
| class_id | int(FK) | - | Class.class_id | 使用可能クラス |
| cooldown | float | 0.0~120.0 | - | 再使用待機(秒) |
| damage_coef | float | 0.0~10.0 | - | 攻撃力乗算係数 |
| element | enum | fire/ice/lightning/none | - | 属性。無属性も明示(none)、空欄はエラー |
| is_passive | bool | true/false | - | パッシブかどうか。trueならdamage_coef=0 |

_source: Skill.xlsm / generated by schema-doc_

elementとis_passiveの説明欄に、3.2.2のステップ4・6で人が引いた境界線がそのまま入り込んでいる点に注目してください。人が$스키마に1行書いただけで、ドキュメント・proto・検証のすべてが同じ規則を共有するようになりました。これが、信頼できる唯一の情報源が実際に機能している姿です。

Markdownに落ちたスキーマは、3つの場所でただちに使われます。

• AIによるデータ生成：行を作る前にこの表を読み、定義された7つのカラム・各制約・FKを守った行だけを作ります。
• 新人プランナーのオンボーディング：会議3回よりこの表1枚のほうが速いです。
• Linter：csvの各行がこの表に違反していないかを自動で照合します。

3.2.4 gen_relation_map.py — FKが生きているかをグラフで

スキーマがシートの内側の規則だとすれば、FKはシート間の規則です。class_idがClassシートを参照するという定義は$스키마に書かれていますが、その参照が今この瞬間に実際に生きているかどうかは、別途のチェックが必要です。

gen_relation_map.pyは、各マスターデータシートのFK関係を自動検出し、インタラクティブなHTML関係図として描きます。Skillのclass_id→Class、Itemのset_id→ItemSetのような矢印が1つの画面に集まると、「参照先が消えたFK」が切れた矢印として目に留まります。本章冒頭の47番欠落のような事故が、ビルドログの赤い行ではなく関係図の切れた線として、データを埋めている最中に見えるのです。

このツールの実際の使用例と可視化は3.3で本格的に扱います。本章で覚えておくべきことは1つです。$스키마がFKを明示しなければ、関係図にも整合性チェックにも、描くべきグラフがありません。FKの明示は選択肢ではなく、スキーマファーストの前提です。

3.2.5 スキーマファーストの5段階ワークフロー

3.2.2のトランスクリプトを一般化すると、5つのステップになります。各ステップの主体と成果物を分けて見ると、何を人が握り、何をツールに渡すのかが明確になります。

5つのステップを最初の月にすべてそろえる必要はありません。ステップ1・2（スキーマ設計＋自動ドキュメント化）を回すだけでも、価値の半分はつかめます。ステップ3〜5は、運用に慣れてから段階的に追加します。最初から5ステップを強制すると、書き手の負担が定着前に運用を止めてしまいます。

3.2.6 プロジェクトAで測定したこと

著者がディレクターとして運営しているあるMMORPGプロジェクト（以下「プロジェクトA」）で、約6か月間このワークフローを回しました。以下の数値のうち、マスターデータのカラム一貫性と新規シートのドラフト時間はツールのログと作業記録から集計した実測値で、FK破損の頻度はビルド失敗のイシューから逆算した著者の推定（未検証）です。

導入コストは、ツールの初期開発約3日＋運用定着約1か月です。6か月の累積効果に対して導入コストは小さかった、というのが運用上の結論です。ただし、上記の比率は1チーム・1プロジェクトの単一事例なので、他のチームにそのまま持ち込める保証はありません。

3.2.7 AIとスキーマのシナジー、そして境界

スキーマが敷かれると、AIによるデータ生成の信頼度は飛躍的に上がります。理由は、ハルシネーションの口実になる曖昧な入力範囲を、スキーマがあらかじめ塞いでくれるからです。「スキルを20個作って」というリクエストにスキーマがなければ、AIはもっともらしいカラムを発明し、手元のシートと互換性のない値を埋めます。スキーマがあれば、同じリクエストが、定義された7つのカラム・各制約・FKを守った行として返ってきます。3.2.2の1003行の事例のように違反が出ても、1行を指摘して再リクエストすれば終わりです。

その代わり、境界は明確です。バランスの値はAIに任せません。damage_coefをAIが「適当に」決めると、ゲームの意図と衝突します。形式の正しい候補を素早く並べるところまでがAIの仕事で、「このスキルの係数は2.4で正しいのか」には人が答えます。だからといって、AIがバランスに無用だという意味ではありません。曲線の滑らかさ・外れ値・範囲の統計は、AIが素早く捉えます。数字を測るのはツールに任せ、その数字が正しいかどうかは人が見極めます。

3.2.8 よくある失敗と回避策

やってみよう

setup 1. ご自身の担当分野で最も中心となるシートを1つ選んでください（スキル・アイテム・モンスターのいずれか）。 2. そのExcelファイルに$스키마という名前のシートを追加し、カラムごとに5要素（名前・型・範囲・FK・説明）を1行ずつ書いてください。このステップは人が直接行います。

prompt（proto/csvのドラフトにだけAIを使います）

以下の$스키마をproto3のメッセージとEnumに変換せよ。enumの最初の値は_UNSPECIFIED = 0。FKは参照先をコメントで。範囲制約はコメントのみ。仕様にないカラムの追加は禁止。 （ここにご自身の$스키마を貼り付け）

続けて：

上のprotoと$스키마を満たすcsv行を5つ。制約違反の行は作るな。is_passive=trueならdamage_coef=0。

verify 1. AIが出した5行を1行ずつスキーマと照合してください。違反行があれば「N行目が違反、その行だけ直して」と再リクエストします（拒否と再リクエストは正常なプロセスです）。 2. schema-doc（または同等の簡単なPythonスクリプト）で$스키마を.mdに書き出し、Excelの定義とドキュメントが一致しているか確認してください。 3. FKがあれば、参照先のPKが実際に存在するかを一度照合してください。

一人ミニ版

ツールもチームもなく一人で始めるなら、Excelファイル1つとテキストエディター1つで十分です。

1. シートの最初のタブに$스키마を作り、カラム規則を5要素で書きます（15分）。
2. その仕様をそのままコピーしてAIに「proto Enum + csv 5行」をリクエストします（10分）。
3. 返ってきたcsvをスキーマと目で照合し、違反した1行を再リクエストで直します（10分）。
4. $스키마のテキストをメモ帳でskill_schema.mdとして保存しておきます。これがあなたにとって最初の、信頼できる唯一の情報源です。

次のシートに進むときも、同じ4ステップを繰り返してください。四半期のうちに中心となるシート5〜10個が同じ順序でそろったら、そのときはじめてschema-docのような自動化を付ける価値が生まれます。

本章のポイント

• 入力順序を$스키마→Enum/proto→csvに強制すれば、違反はデータを埋める前に塞がれる
• Excelが正本・ドキュメントは派生。schema-docが両者を1つの情報源に束ね、人とAIが同じ定義を見る
• バランスの値は人が決定し、AIは形式の候補と外れ値の測定だけを担う

次章のプレビュー

• 3.3. 関係図の可視化 — gen_relation_map.pyでFKの依存関係を目で見る

3.3 関係図の可視化 — 依存関係を目で見る

新人プランナーが入社初週に私の席へやって来ました。「クエスト報酬テーブルに手を入れようと思うのですが、ここを触るとどこが壊れますか？」私はモニターを指して答えようとして、止まりました。頭の中には絵がありました。RewardTableがItemTableを参照し、ItemTableがItemEffectTableを参照し、その上でQuestTableが報酬を参照して…ところが、その絵を言葉に置き換えた瞬間、聞き手の頭の中では形が崩れていきました。ホワイトボードにボックスを7つ描きました。矢印が絡まり始めました。30分後、彼はうなずいて席に戻り、翌日まったく同じ質問を再び持ってきました。

この場面が、本章を書かせました。システムプランナーの頭の中には依存関係のグラフがあります。問題は、それが頭の中にしかないことです。人が変われば絵も消えます。絵を外部化するツールが必要で、そうして作ったのがgen_relation_map.pyです。

マスターデータが5〜10個のうちは頭の中だけで足ります。30個を超えると、人のワーキングメモリーでは抱えきれません。1つのプロジェクトのシートフォルダーは、たいていその線を早々に超えます。どこからどこへ依存しているかを文章で書き並べた表は、読んでも絵が浮かびません。本章では、外部キーの関係をインタラクティブHTMLの関係図として自動生成する過程を、ワークド・トランスクリプトとして最初から最後までたどります。

3.3.1 関係図が解決する4つの問題

ツールを作る前に、関係図がないときに実際に何が詰まるのかから押さえます。繰り返し起きたのは4つの場面でした。

新人プランナーのオンボーディング。 新しいプランナーがシステム構造を覚えるために会議を設定します。冒頭のあの場面です。言葉で伝えられた依存関係は、聞き手の頭の中で数日と持ちません。関係図1枚を一緒にクリックすれば、最初の会議で半分以上の絵が描けます。ホワイトボードの手描きと決定的に違うのは、図が消えずにその場に残ることです。

変更の影響範囲の議論。 システム変更のリクエストが上がってきます。「これ、どこに影響しますか？」会議が設定され、長々と議論しても、漏れた領域が1つ2つ出てきます。関係図があれば、変更対象のノードをクリックしてインバウンドエッジをたどるだけで、影響範囲が目に入ります。議論は「この影響が本当に正しいか」と優先順位を決めるだけで済みます。

依存の逆行の検出。 L3のマスターデータがL1のシステム文書を参照するのは正常です。逆方向（上位Layerが下位のマスターデータを直接参照する）は、ほぼ例外なく設計上の欠陥です。文章として並べたFKの一覧では、この逆行を人は捕まえられません。図であれば、Layerの色が食い違う矢印1本として即座に現れます。

孤立したシートの発見。 どこからも参照されないシートが時々見つかります。古い企画の名残か、廃棄すると決めたのにファイルだけが残ったケースです。オフィスの片隅にラベルのない箱が転がっている風景と同じです。図があってこそ、その孤島を発見できます。

4つの問題に共通するのは、どれも「構造を目で見なければ解けない」という点です。文章と表では行き詰まります。

3.3.2 ワークド・トランスクリプト：マスターデータから関係図まで

ここからは実際にたどります。入力はマスターデータが入ったフォルダー1つ、出力はブラウザーで開く1枚のインタラクティブHTMLです。その間でAIがやったことと、人が検証・却下したポイントを漏れなく記します。

3.3.2.1 全体の流れ

flowchart TD
    A[マスターデータのフォルダー
xlsm/xlsxが多数] --> B[1. スキャン：シート・カラムヘッダー収集]
    B --> C[2. FK候補の抽出
*_id / *Id / 仕様書のFK表記]
    C --> D[3. 参照先のマッチング
カラム名 → 対象シート]
    D --> E{人による検証}
    E -->|誤検出を却下| C
    E -->|通過| F[4. グラフ構築
ノード=シート、エッジ=FK]
    F --> G[5. Layerメタ付与
schema-doc出力を参照]
    G --> H[6. pyvisでHTMLレンダリング]
    H --> I[relation_map.html
ブラウザーでインタラクティブ]
    I --> J{人による診断}
    J -->|逆行・孤立・循環を発見| K[設計修正を依頼]
    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class A,I data
    class B,C,D,F,G,H code
    class E,J,K human

肝心なのは、3番と5番の間にある人による検証ループです。FK候補の抽出は機械がたたき台を敷き、人がそこから誤検出を間引きます。このループを省くと、関係図はもっともらしく見えて間違った絵になります。

3.3.2.2 FKはどこから来るのか — 入力の順序

このツールの精度は、入力をどこから引いてくるかで決まります。3.2で定めたschema-first原則がそのまま適用されます。FK情報を「正」とする優先順位は次のとおりです。

1. $스키마シート — 各マスターデータの第一の「正」です。カラムごとに型・Enum・FKの参照先が明記されています。ここにFKが書かれていれば、それが第1順位です。
2. *.proto / Enum定義 — VBA（Excelマクロ言語）のExportで吐き出されたスキーマです。仕様書が空のとき、型を補強します。
3. 実際のcsv出力 — シートが書き出した実データです。仕様書にない関係も、データのパターンから現れます（例：npc_idカラムの値がすべてNPCTableのキー範囲内に収まっていれば、事実上FKです）。

ここで1つの原則をはっきりさせておきます。スキーマ文書ではなく、実際のJSON/csv出力が「正」です。 仕様書にreward_idがFKだと書かれていても、実データでそのカラムが空だったり、見当違いの値を指していたりすれば、間違っているのは仕様書のほうです。ツールは両者が食い違うときデータ側を信頼し、食い違いそのものをレポートに残します。これが、schema-docを「正」に据えない理由です。

3.3.2.3 ステップ1 — フォルダースキャンとFK候補の抽出

ツールの最初の動作は、フォルダー内のすべてのxlsm/xlsxを開いてシート・カラムヘッダーを収集することです。このステップ自体は機械的で、面白みはありません。面白いのは、FK候補を拾うルールです。最初は単純でした。カラム名が*_idまたは*Idで終わればFK候補と見なす。ところが、このルール1つでは誤検出と漏れの両方が出ました。

ここでAIをつなぎました。カラムヘッダーの一覧を丸ごと渡し、FKの参照先シートを推論させました。以下は、実際に投げたプロンプトの全文と生の出力です。

プロンプト： 以下はゲームのマスターデータのシート名とカラムヘッダーの一覧である。各カラムが外部キー（FK）かどうか、FKの場合はどのシートのどのカラムを参照するかを推論せよ。カラム名の規則は通常<대상시트단수형>_idである。ただし、確信がなければ「不確実」と表示し、理由を書くこと。推測で埋めないこと。

QuestTable: quest_id, title, npc_id, reward_id, prev_quest_id, region_id
NPCTable: npc_id, name, region_id, faction_id
RewardTable: reward_id, item_id, count, currency_id
ItemTable: item_id, name, item_effect_id, grade
ItemEffectTable: item_effect_id, effect_type, value
RegionTable: region_id, name, parent_region_id

Claudeの生の出力（PK行は省略、FK判断のみ抜粋）：

QuestTable - npc_id → NPCTable.npc_id（クエストを与えるNPCと推定） - reward_id → RewardTable.reward_id - prev_quest_id → QuestTable.quest_id（先行クエスト、自己参照） - region_id → RegionTable.region_id

NPCTable - region_id → RegionTable.region_id - faction_id → 不確実：FactionTableが入力一覧にありません。カラム名の規則上はFactionTable.faction_idを参照すると見られますが、該当シートが提供されていないため参照先を確定できません。

RewardTable - item_id → ItemTable.item_id - currency_id → 不確実：CurrencyTableが一覧にありません。通貨の種類がEnumで管理されている可能性もあり、FKではないかもしれません。仕様書の確認が必要です。

ItemTable - item_effect_id → ItemEffectTable.item_effect_id - grade → FKではない（Enumと推定：等級の値）

ItemEffectTable - effect_type → FKではない（Enumと推定）

RegionTable - parent_region_id → RegionTable.region_id（自己参照、地域の階層構造）

注意：上記の推論はカラム名の規則に基づいたものであり、実際のデータ値は確認していません。特にcountやvalueのように_idで終わらないカラムはFK検査の対象から除外しており、隠れた参照があれば漏れます。

この出力に対して人がやったことは3つです。

• 却下1：faction_id → AIはFactionTableが存在しないとして不確実扱いにしました。正しい判断です。ただし、実際にはfaction_idはEnumでした。ファクションが6種で固定のため、別シートを作らずEnumで管理しています。AIが存在しないシートをでっち上げずに判断を止めてくれたおかげで、人が仕様書を見てEnumと確定できました。FKから除外。
• 却下2：currency_id → AIは両方の可能性を開けたままにしました。実データを見るとCurrencyTableは存在していました（入力一覧から私が漏らしていました）。FKとして確定。 AIを責められない、人間側の入力漏れでした。
• 受け入れ：prev_quest_idとparent_region_idの自己参照の検出。これは単純な正規表現ルールだったら見逃していたはずです。AIが「先行クエスト」「地域の階層」という意味付けまで添えてくれたことが、検証を速くしました。

ここで得た教訓は明確です。AIがもっとも役に立った場面は、速い推論ではなく、わからない箇所を「不確実」のまま空けておいた抑制でした。空欄を無理に埋めていたら、faction_idは見当違いのシートにつながり、その誤検出は関係図に偽の矢印として残って、新人プランナーを誤った方向へ導いていたはずです。

3.3.2.4 ステップ2 — グラフ構築とLayer付与

検証済みのFK一覧ができると、gen_relation_map.pyがグラフを作ります。シートはノード、FKは有向エッジです。インバウンドエッジ数（ほかのシートが自分をどれだけ参照しているか）を数えてノードの大きさを決めます。多く参照されるほどノードは大きく、すなわちシステムのハブです。

Layerメタデータは、schema-docスキルが作ったMarkdownのスキーマ文書から引いてきます。3.1で定義したLayer座標（L0〜L4）が各シートにラベルとして付いており、ツールはそれを読んでノードの色を塗ります。この連結が重要です。関係図がLayerを知らなければただのボックスと矢印にすぎず、Layerを知ってはじめて「逆行」を色で診断できます。

ツールの内部構造をコードの骨格で示すと、次のとおりです（中核の流れのみ抜粋）。

# gen_relation_map.py (中核の流れの抜粋)
from pyvis.network import Network

LAYER_COLORS = {          # Layer パレット — atom 1個に標準化
    "L0": "#2c3e50",      # メタ/共用
    "L1": "#2980b9",      # システム
    "L2": "#27ae60",      # コンテンツ
    "L3": "#f39c12",      # データインスタンス
    "L4": "#c0392b",      # 派生/キャッシュ
}

def build_graph(fk_list, layer_map):
    net = Network(directed=True, height="900px")
    inbound = count_inbound(fk_list)          # インバウンドエッジ集計
    for sheet in all_sheets(fk_list):
        layer = layer_map.get(sheet, "L0")
        size = 10 + inbound[sheet] * 3        # ハブほど大きいノード
        net.add_node(sheet, color=LAYER_COLORS[layer],
                     size=size, title=sheet_tooltip(sheet))
    for src, dst, col in fk_list:
        # Layer 逆行検知: 上位Layerが下位を参照したら警告色
        edge_color = "#e74c3c" if is_reverse(src, dst, layer_map) else "#888"
        net.add_edge(src, dst, title=col, color=edge_color)
    return net

is_reverseが、このツールの小さな核心です。エッジの出発シートが到着シートより上位のLayerなら（例：L1 → L3）逆行と見なし、エッジを赤く塗ります。人が図を開いたとき赤い矢印が見えたら、それはほぼ例外なく手を入れるべき場所です。

3.3.2.5 ステップ3 — HTMLレンダリングと結果の構造

最後は、pyvisがインタラクティブHTMLを吐き出すステップです。ノードをクリックすると該当シートのカラム・Layer・インバウンド数がツールチップで表示され、検索ボックスでシート名によるフィルタリングができます。静的PNGではなくHTMLでなければならない理由がここにあります — ノード数が数十を超えると、静的画像では矢印が絡まって何も見えません。マウスでドラッグして広げ、関心のある領域だけをクリックで絞り込んではじめて、パターンがつかめます。

上の例のデータで作った関係図の構造をSVGに写すと、次のとおりです。色はLayerを、赤い矢印は（この例にはありませんが）逆行の位置を意味します。

ノードの大きさを見ると、RegionTableがもっとも多く参照されています（Quest・NPCの両方が指しています）。これがハブです。ItemEffectTableは葉のノードなので小さく表示されます。新人プランナーの「このシステムを理解するにはどこから見ればいいか」という質問の答えは、ノードの大きさの順序として、図の中にすでに入っています。

3.3.3 図がもたらす診断 — Layerとの結合

3.1でLayer座標を定義しました。本章の関係図がその座標を視覚へ引き上げると、文章や表では不可能だった4つの診断が、1つの画面で可能になります。

• Layer逆行 — Layerの色が逆方向に流れる矢印（赤）。マスターデータがシステム設計へ逆向きに影響を与える、不自然な構造です。
• 孤立ノード — どのエッジともつながっていない孤島。廃棄の候補です。
• ハブの過負荷 — インバウンドエッジが異常に多い巨大ノード。1つのシートが多くの責任を負いすぎているサインで、分割を検討します。
• 循環依存 — 矢印が円を描く場所。ほぼ例外なく設計上の欠陥で、データのロード順の問題につながります。

ただし、図がすべての問題を捕まえるという意味ではありません。図が捕まえるのは構造上の欠陥です。このFKが本当に意味として正しい関係なのか（例：npc_idが本当に「クエストを与えるNPC」なのか、それとも「クエストに登場するNPC」なのか）は、図では解けません。それは人のドメイン判断の領分です。ツールは、人の判断が働く舞台を整えてくれるだけです。

3.3.4 自動更新がなければ陳腐化する

関係図は、一度作って終わりではありません。シートは毎週追加・変更されます。手動更新に任せた関係図は1〜2か月で実際の構造とずれ、ずれた地図は道を誤って案内するため、かえってないほうがましな状態になります。一度間違った図に痛い目を見たチームメンバーは、次から図を見ません — これがもっとも高くつく失敗です。

そこで、更新を自動トリガーに掛けます。

• Git pre-pushフック — マスターデータをプッシュする前に関係図を再生成します。常に最新の状態が保証されます。
• 変更リクエストの時点 — マスターデータの変更リクエストが上がってきたら、変更前後の関係図をdiffで比較してコメントに添付します。追加されたエッジは緑、消えたエッジは赤。レビュアーが影響範囲を図で見られます。
• 夜間バッチ — 毎晩新しい関係図を作り、前日とのdiffを残します。
• 手動コマンド — /relation-mapスラッシュコマンドで即時生成します。会議中にその場で表示するときに使います。

生成されたHTMLは、社内の静的ホスティング（企画ポータル）へ自動デプロイします。別途ツールのインストールなしに、ブラウザーさえあれば誰もが同じ地図を見られます。机の横に常に広げてある地図と同じです。誰に聞かれても、同じ図を一緒に指さしながら答えます。

3.3.5 よくある失敗と回避策

gen_relation_map.pyの運用でもっとも頻繁に痛い目を見たのは、3行目です。*_idルールだけを信じると、countやvalueのような隠れた参照を見逃し（3.3.2.3のAIもこの限界を自ら警告していました）、EnumであるgradeをFKと誤検出します。仕様書と実データの両方を見る検証ループが、この行の答えです。

3.3.6 一人ミニ版でまず試す

会社全体のマスターデータを一度に扱おうとすると重く、価値を見せる前に疲れてしまいます。自分の担当分野のフォルダー1つから小さく始めます。

やってみよう

setup. 1. 自分が担当するマスターデータが5〜10個入ったフォルダーを1つ選んでみましょう。 2. pip install pyvis openpyxlで依存パッケージを入れましょう（Excelの読み取りはexcel-readerスキルまたはopenpyxl）。 3. 各シートの$스키마シートにFKが明記されているか、まず確認しましょう。なければカラムヘッダーだけを集めます。

prompt. カラムヘッダーの一覧を集め、3.3.2.3のプロンプトをそのまま投げてみましょう。肝心なのは最後の1行です — 「確信がなければ不確実と表示し、推測で埋めないこと」。この一文が偽の矢印を防ぎます。

verify. 1. AIが出したFK候補を1行ずつ見ましょう。「不確実」と表示された行を、仕様書・実データで確定します。 2. Enumと疑われるカラム（gradeやeffect_typeのように_idが付かないのにFKに見えるもの）はFKから外しましょう。 3. 自己参照（prev_*_id、parent_*_id）が正しく拾えているか確認しましょう。 4. 検証済みの一覧でグラフを描き、ブラウザーで開いて、赤い矢印（逆行）と孤島（孤立）を目で探してみましょう。

一人ミニ版

ツールを作る時間がなければ、最初の週は手で描いたmermaid 1枚から始めても構いません。シート5個のFKを3.3.2.3の形式でmermaidに直接書いてみましょう。この1枚を会議に持っていき、「これがうちのシステムの依存関係です」と見せれば、その場で価値が証明されます。価値が見えれば、自動化ツールは自然と後から付いてきます。最初から動くツールを出さなければ、という負担は下ろしてしまって大丈夫です。

拡張は次の順序で自然に流れていきます — 1週目は自分のシートのmermaid手描き → 2週目はLayerの色とクリックの追加 → 1か月で自動更新（gitフックまたは夜間バッチ）→ 3か月で社内ポータルへの配備 → 6か月で全シートの統合関係図。

3.3.7 次章への接続

3.2ではシートの内側（スキーマ）を、3.3ではシートの外側（関係）を扱いました。3.4は、この上にAI補助のプロンプトパターンを載せます。スキーマと関係が固まったシステムの上で、AIが整合性チェックと影響範囲の抽出をどう補助するのか、実用パターンへと続きます。

本章のポイント

• 頭の中の依存関係グラフを外部化すれば、人が変わっても同じ図がその場に残ります。
• FK抽出の精度を作るのは、AIが敷いたたたき台から人が誤検出を間引く検証ループです。
• 自動更新のない関係図は1〜2か月で陳腐化し、信頼を失います。

次章のプレビュー

• 3.4. AI補助のシステム設計プロンプトパターン

3.4 AI補助によるシステム設計プロンプトパターン

アルファビルドを目前に控えた週のことでした。スキルのマスターデータ（シート）に新しいクラスを1行追加して保存しました。ところが、そのクラスが参照するバフIDが前日に誰かが削除した行だったことを、私は翌朝ビルドが壊れてから初めて知りました。壊れたビルドをさかのぼって原因を突き止めるのに2時間かかりました。行を1つ削除する前に「これ、消しても大丈夫？」と聞けてさえいれば、使わずに済んだ2時間です。

この章は、その質問をAIにさせる方法についてのものです。核心は、プロンプトを上手に書くコツではありません。同じ質問を毎回ゼロから書き直さずに済むよう、ルール化することです。3.2でスキーマを、3.3で関係図を敷きました。どちらもデータの骨組みでした。この章では、その骨組みの上で人間がAIに投げる質問そのものを資産として固めます。

まず1つ、くぎを刺しておきます。AIが作るのは答えではなく候補です。この章に出てくるすべてのパターンで、最後の決定の手は最後まで人間の側に残ります。

3.4.1 即興プロンプトが漏れる2か所

AIを使い始めたばかりの頃は、毎回自然言語でその場で打ち込みます。こんな具合です。

スキルシートをちょっと見て。外部キーが壊れてないか確認して、
変なのがあったら教えて。あ、あとクールダウンがマイナスのも。

このプロンプトは2か所で漏れます。

第一に、検査項目が毎回変わります。今日は「クールタイム（クールダウン）がマイナス」を思い出しても、明日は忘れます。昨日は一度検出した「PKの重複（Primary Key、主キー）」が、今日のプロンプトからは抜け落ちます。人間の記憶に頼る検査は、人間のコンディションの分だけ漏れます。

第二に、結果の形式が毎回変わります。同じ意図を「確認して」「チェックして」「ざっと見て」と違う言い方で書けば、AIはある日は表で、ある日は文章で答えます。形式がばらばらだと、その結果を再び自動処理することができません。

解決策は、プロンプトを手から離して引き出しにしまうことです。毎回手で書いていたメモを、ラベル付きのカードに変えて同じ引き出しから取り出します。そのカードが、本書で言うスラッシュコマンド（skill）でありatomです。

3.4.2 ルール化の3つの形と選ぶ基準

ルール化には3つの器があります。何をどこに収めるかは、呼び出し頻度と安定性で分かれます。

よく使い、定義が固まった作業はスラッシュコマンドへ。よく使うものの「忘れてはならない制約」はatomのJITで自動注入へ。たまにしか行わないものの規模が大きい作業はテンプレートファイルへ。そして、まだ定義が揺れている作業はルール化せず、即興のままにしておきます。3つを最初からすべてそろえる必要はありません。スラッシュコマンド1〜2個から始め、価値が見えてきたら増やします。

3.4.3 パターン① 整合性チェック — ワークド・トランスクリプト

言葉で説明する代わりに、1つのパターンを最初から最後までたどってみます。空の行を1つ削除する前に「これ、消しても大丈夫？」を自動で問うパターンです。名前は/check-sheet。中には検査項目と出力形式がルール化されて入っています。

根拠となる資産は、本書の随所に埋め込まれた実測の作業記録にあります。データ入力はschema-first原則（atom data_entry_schema_first）に従います。入力順序は$스키마シート → Enum/*.proto（VBA（Excelのマクロ言語）でのExport） → csv。そして正本はスキーマ文書ではなく、実際のJSON出力です（atom json_over_schema_doc_as_source_of_truth）。整合性チェックは、この2つの原則をそのまま検査ルールへ移したものです。

setup — ルール化されたコマンドの中身

/check-sheetを開くと、中にはこんなプロンプト本文が入っています。これが、毎回手で打たなくて済む部分です。

役割: あなたはゲームデータシートの整合性検査器だ。

検査するシート: {{sheet_name}}
参照可能なスキーマ: $스키마 シート (カラム別タイプ・範囲・FK対象)
参照可能な正本: 同じシートのexport JSON (スキーマ文書より優先)

検査項目 (この順序で):
1. 外部キー有効性 — FKカラムの値が参照対象シートに実在するか
2. 範囲違反 — $스키마に定義されたmin/maxを外れた値
3. 必須カラム欠落 — required=trueのカラムが空の行
4. 重複PK — 同じPKが2つ以上

出力形式 (必ずこの表のまま):
| # | 行 | カラム | 違反種類 | 現在値 | 修正候補 | 確信度 |

ルール:
- 修正候補は提案だけにする。絶対にシートを直接修正しない。
- 確信度は高/中/低の3つのうち1つ。推測なら低。
- 違反がなければ "違反0件" だけ出力して終える。

この本文で重要なのは、最後のルール3行です。「直接修正しない」「確信度を付ける」「推測なら低と自白する」。この3行が、AIを答えを出す席ではなく、候補を差し出す席に縛り付けます。

prompt — 人間が実際に打った1行

/check-sheet skill_table

これで終わりです。渡すのはシート名1つだけ。検査項目4つも、出力の表形式も書き直しません。それがルール化の価値です。

Claudeの生の出力

以下は、実際に実行したときに返ってきた出力です。要約はせず、曖昧だった部分やAIがためらった箇所まで、そのまま掲載します。

skill_table 整合性検査の結果です。計4件の違反を発見しました。

| # | 行  | カラム      | 違反種類     | 現在値 | 修正候補                | 確信度 |
|---|-----|------------|------------|--------|----------------------|------|
| 1 | 142 | buff_id    | 外部キー違反 | 9007   | 9070 (誤記推定、1文字)   | 中    |
| 2 | 142 | buff_id    | 外部キー違反 | 9007   | 9012 (名前"맹독"が類似)  | 低    |
| 3 | 88  | cooldown   | 範囲違反     | -1     | 0 (負数不可)            | 高    |
| 4 | 215 | combo_next | 必須欠落     | (空欄)  | 判断保留               | 低    |

注意事項をいくつか付け加えます。

- 1番と2番は同じ行(142)の同じカラムに対する互いに異なる候補です。
  9007というIDはbuffシートに存在しません。9070は数字1桁の違い
  なので誤記の可能性があり、9012は名前が"맹독"で類似しているため
  候補に挙げました。どちらも確信は低いです。人間が選ぶべきです。

- 4番(215行 combo_next 空欄)は曖昧です。$스키마にはrequired=trueと
  なっていますが、export JSONを見るとこのカラムが空の行がさらに12個
  あります。仕様書が最新でないか、「コンボ締めのスキルはcombo_nextを
  空にする」というルールがあるのに仕様書へ未反映の可能性があります。
  私には断定できないため「判断保留」としました。

- cooldown以外に範囲検査をさらに回したい場合は$스키마の他のカラムの
  min/maxを確認する必要がありますが、受け取った情報のrange_checkカラムが
  一部空のため、cast_timeカラムは検査できませんでした。

この出力が良い出力である理由は、きれいだからではなく、正直だからです。4番を「必須なのだから埋めろ」と断定せず、「仕様書が最新ではないかもしれない」と自己疑念をさらけ出しました。cast_timeを見られなかったという限界も自白しました。もしAIが4番を自信満々に「0で埋めてください」と言っていたら、それはコンボの締めスキルを壊す誤答だったかもしれません。

verify — 人間による検証と拒否

ここからは人間が1行ずつ判定します。検証が自動で同伴するというのは、この表が自動で出てくるという意味であって、人間が見ないという意味ではありません。

• 3番（cooldown -1 → 0）：採用。確信度は高で、マイナスのクールタイムは明白な入力ミスです。すぐに修正しました。
• 1・2番（buff_id 9007）：保留。どちらも確信度は低。buffシートを直接開いて、「맹독（猛毒）」系列のバフの実際のIDを確認することにしました。AIの候補はどちらも採用していません。
• 4番（combo_next空欄）：拒否。AIの疑いが当たっていました。このスキルはコンボの締め技なので、combo_nextが空であるのが正常です。違反ではありません。拒否し、これは仕様書側の問題です。

最後の4番が核心です。AIの出力をそのまま信じていたら正常なデータを壊していたはずの場所で、人間の拒否が機能しました。同時に4番は、検査ルール自体の欠陥もあらわにしました。仕様書のrequired=trueが間違っていたのです。

再リクエスト — 拒否がルールを直す

ここで終わりにはしません。拒否は、次の検査をより賢くする入力です。人間が続けて打ち込みます。

4番は違反じゃない。combo_finisher=trueのスキルはcombo_nextが空なのが
正常なんだ。この例外ルールを検査項目に入れて、今後はfinisher行の
combo_next空欄は違反として検出しないで。それと仕様書のrequired定義が
間違っていると見える項目は、別に "仕様書疑い" セクションへ分けて教えて。

理解しました。/check-sheetの検査ルールに例外を反映します。

追加されたルール:
- combo_next必須検査の際、同じ行のcombo_finisher値を先に確認。
  combo_finisher=trueならcombo_next空欄は正常として処理(違反除外)。

新設セクション:
- "仕様書疑い" — export JSONの実際の分布が$스키마定義と食い違うとき、
  データではなく仕様書を直すべき候補として分離して報告。
  (正本はJSONという原則に従い、多数のデータが仕様書に反すれば
   仕様書側を疑います。)

この変更を/check-sheetコマンド定義atomに記録しておきましょうか?

最後の1行が、このパターンの完成です。一度の拒否が一回限りの修正で終わらず、コマンド定義のatomに記録され、次の人・次の検査へと伝播していきます。これがルール化の複利です。同じ間違いを二度ふるいにかけることはありません。

3.4.4 パターン② 変更影響範囲の抽出 — ワークド・トランスクリプト

2つ目のパターンは、冒頭の場面のあの2時間をなくすものです。行1つ、決定1つを変える前に、「これはどこまで波及するのか」を先に問います。名前は/impact。3.3で作った関係図（gen_relation_map.pyが出力するFK関係のHTML）が、このパターンの燃料です。

setup — ルール化された探索経路

/impactの中には、「どこを探せば影響を漏れなく見つけられるか」が4つの経路としてルール化されています。

役割: あなたは変更影響範囲の抽出器だ。

変更対象: {{target}}  (シート名・カラム・atom_id・システム決定のいずれか)

探索経路 (4つすべて回ること):
1. 関係図インバウンド — gen_relation_map.py 出力で {{target}} を
   FKで参照するシート群 (このシートを指す矢印)
2. 本文言及 — sources/manuscript 内で {{target}} のID・名前が
   直接登場する文書
3. atom affects 関係 — {{target}} と affects で連結された atom 群
4. 逆参照 — {{target}} を [[wikilink]] で指すノート

出力形式:
| 種類 | 名前 | 連結根拠 | 影響強度 | 担当 |

ルール:
- 影響強度は直接/間接/弱の3つだ。直接FKは '直接'、本文言及は '間接'、推定は '弱'。
- 欠落が怖ければ弱としてでも載せる。漏らすよりましだ。
- 優先順位や作業指示はしない。リストだけ作る。

prompt

/impact buff_id=9012

「猛毒バフ（9012）を別の効果に差し替えたいが、どこが揺れるのか？」を1行で問います。

Claudeの生の出力

buff_id=9012(맹독)の変更影響範囲です。4つの経路をすべて探索しました。

| 種類    | 名前                | 連結根拠               | 影響強度 | 担当      |
|--------|--------------------|----------------------|---------|----------|
| シート  | skill_table         | buff_id FK 直接参照     | 直接      | teammate_a |
| シート  | monster_drop        | reward_buff FK 参照     | 直接      | teammate_b |
| シート  | set_item_effect     | proc_buff FK 参照       | 直接      | teammate_a |
| 文書    | 독계열_밸런스_노트.md  | 本文に "9012" を直接言及 | 間接      | (著者)     |
| atom    | poison_stack_rule   | affects: 9012          | 間接      | (著者)     |
| ノート  | 상태이상_설계.md       | [[맹독]] 逆参照          | 弱       | (著者)     |

いくつか付け加えます。

- skill_tableで9012を参照する行は3つです(アサシンクラスのスキル)。
  差し替えるとこの3つのスキルの実際の効果が変わります。最も強い影響です。

- monster_dropのreward_buffは、私は確信がやや弱いです。カラム名は
  reward_buffですが、一部の行はbuffではなくitemを指しているような
  値が混ざっているためです。このシートは直接一度開いて確認するようお勧めします。

- "독계열_밸런스_노트.md" は9012をテキストで言及するだけでFKではないため
  間接としました。ただしバランス意図が書かれた文書なので、実際の影響は
  強い可能性があります。強度(間接)と重要度が異なりうる点にご留意ください。

- set_item_effectはセットアイテム4種でproc_buffとして9012を使います。
  맹독を抜くとこれらのセットのコンセプトが変わります。

verify — 人間による検証と拒否

• skill_table（直接、チームメンバーA）：確認。アサシンクラスのスキル3つが直接影響。チームメンバーAへの共有が必要です。採用。
• monster_drop（直接）：AIが自ら疑った項目。シートを直接開いて確認した結果、reward_buffカラムには本当にitemのIDが混ざっていて、9012を参照する行は実際には1つだけでした。AIの「確信がやや弱い」という自白は正確でした。強度を直接→間接へ下方修正。
• set_item_effect（直接、チームメンバーA）：確認。セットアイテム4種に影響。採用。
• 상태이상_설계.md（弱）：単純な逆参照で、本文への影響はなし。リストには残しつつ、作業対象からは除外。

ここでもAIの正直さが検証を助けました。monster_dropを「直接」と断定していたら、影響が水増しされて不要な調整会議が組まれていたでしょう。AIが「直接開いて確認することをお勧めします」とボールを人間へ渡してくれたおかげで、強度を正すことができました。

再リクエスト — 抽出から共有へ

リストの検証が済んだら、次の手は、これを人に届ける仕事です。

直接影響を受ける担当者ごとにまとめて、teammate_a / teammate_b に
送る短い共有メモの草案を作って。"9012 맹독をXに差し替え検討中、
あなたのシートN行が影響" の形式で。決定はまだ出ていないので通知
ではなく意見要請のトーンで。

担当者別の共有メモ草案です。通知ではなく意見要請のトーンにしました。

[teammate_a 宛]
맹독バフ(9012)を別の効果に差し替える案を検討中です。確定では
なく、まず意見を伺いたいです。影響範囲:
- skill_table: アサシンスキル3つの行が9012を参照 (直接影響)
- set_item_effect: セットアイテム4種がproc_buffとして9012を使用
差し替えるとこれらのスキル・セットのコンセプトが変わります。反対や補完の意見が
あれば今週中に教えてください。

[teammate_b 宛]
monster_dropのreward_buffについて確認をお願いします。맹독バフ(9012)の
差し替えを検討中ですが、影響する行は1つに見えます(reward_buffカラムに
item IDが混ざっていて最初はもっと多く見えました)。実際にこの1行だけで
合っているか確認していただけますか?

2つのメモはどちらも「検討中・意見要請」とし、確定通知の表現は
入れていません。送る前に差し替え候補の効果(Xの箇所)を埋める必要があります。

冒頭の場面の2時間が、ここで消えます。変更の前に影響を問い、担当者へ前もって共有し、翌日ビルドが壊れる前に調整が終わります。そしてAIが作ったのは最後までメモの草案にすぎず、送信する指は人間のものです。

3.4.5 2つのパターンが共有する骨格

上の2つのトランスクリプトは、同じ骨格に従っています。ほかのすべてのパターンも、この骨格の上に載ります。

flowchart LR
    A[ルール化されたコマンド
検査項目・出力形式・禁止事項] --> B[人間: 1行で呼び出し
対象だけ渡す]
    B --> C[Claude: 生の出力
候補+確信度+自己疑念]
    C --> D{人間による検証}
    D -->|採用| E[反映]
    D -->|訂正| F[強度・値を修正]
    D -->|拒否| G[ルールの欠陥を発見]
    G --> H[コマンド定義atomを更新]
    H -.次回の呼び出しに反映.-> A
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class A,H data
    class B,D,F human
    class C ai
    class E pass
    class G fail

核心は右下の点線です。拒否は終わりではなく、コマンド自体を直す入力として戻っていきます。整合性チェックで拒否された4番がfinisherの例外ルールになり、そのルールがatomに記録されて次の検査へ伝播しました。このフィードバックがなければ、同じ誤答を毎週ふるいにかけ直すことになります。

人間の手が残るのは3か所です。呼び出し（対象の選択）、検証（採用・訂正・拒否）、ルール改善（拒否の還流）。AIはその間で、候補を差し出す仕事だけをします。

3.4.6 残りのパターン — 同じ骨格のバリエーション

同じ骨格を別の作業へ移せば、パターンは増えていきます。トランスクリプトなしで、位置づけだけ押さえます。どれも3.4.5の骨格をそのまま踏襲するので、作るときの核心は「ルール化された検査項目」と「人間による検証の席」を抜かさないことです。

バランス計算について、1つだけくぎを刺しておきます。曲線が数値の上ではなめらかに収まっていても、そのなめらかさがゲームの意図と合っているかは別の問題です。ボス直前の区間をあえて急勾配にしておきたかったのに、AIが「外れ値」だとして平らに削ってしまうことがあります。だからバランス計算は、曲線の検証が自動で付いていても、最後の1行は人間が意図と突き合わせてからでなければ閉じません。

3.4.7 運用の5原則と収束点

パターンが増えると、運用の規律が必要になります。次の5原則は暗記しておくルールではなく、ツール自体に入れておく設計原則です。

最後に、収束点を1つ。著者が携わったあるMMORPGプロジェクトでは、システム企画に安定的に残るスラッシュコマンドは、時間とともに12個前後へ収束しました。公開された標準ではなく、1つのプロジェクトの観察値です（著者の経験、未検証）。ただし、方向ははっきりしています。コマンドは無限に増やすものではなく、月に1〜2個を足し引きしながら、頭の中に収まる数で止めます。ラベルが100個付いた引き出しは、ラベルのない引き出しと同じです。

導入は一度に全部やりません。最初の月は、毎週繰り返す作業を1つスラッシュコマンドにルール化するだけで十分です。その1つが価値を見せれば、翌月には2つ、3つへと自然に広がっていきます。

3.4.8 Part 3を終えて

3.1でシステム企画のLayer座標を、3.2でスキーマを、3.3で関係図を敷き、3.4でその上にAI補助のプロンプトを載せました。4つの章を通過したシステムプランナーの1週間は、このように変わります。

flowchart LR
    M[月: GDD草案の合成
4h → 1h] --> T[火: 整合性チェック
半日 → 5分]
    T --> W[水: オンボーディング、関係図1枚
会議5回 → 1枚]
    W --> Th[木: 影響範囲の抽出
会議1h → 10分]
    Th --> F[金: 振り返りの自動分類
手動 → データ駆動]
    F --> R[浮いた時間を
設計・レビュー・プレイヤー体験に再投資]
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class M,T,W,Th,F ai
    class R pass

雑務の時間が減り、その時間が深い設計とプレイヤー体験の検討へ戻っていきます。浮いた時間をまた雑務で埋めないこと、それがツールを導入した本当の理由です。

次のPart 4は戦闘企画です。システム企画に最も近い兄弟であり、3.1〜3.4のツールとパターンがそのまま引き継がれます。

本章のポイント

• 即興プロンプトをスラッシュコマンド・atom・テンプレートへルール化するサイクルこそ、AI補助で最も大きな価値を回収できる場所です。
• すべてのパターンは、1行呼び出し → 生の出力 → 人間による検証・拒否 → ルール還流という同じ骨格に従います。
• AIは候補を差し出し、採用・訂正・拒否という最後の手は、最後まで人間の側に残ります。

やってみよう

setup. 毎週繰り返している検査作業を1つ選んでみましょう（例: シートの整合性）。その作業の検査項目4つと出力の表形式を書き出し、スラッシュコマンド1つにルール化します。ルール3行（「直接修正しない / 確信度を付ける / 推測は自白する」）を必ずコマンド本文に入れましょう。

prompt. 対象だけを1行で渡して呼び出しましょう。

/check-sheet skill_table

verify. 返ってきた表を1行ずつ、採用・訂正・拒否で判定しましょう。拒否が出たら、それは運ではなくルールの欠陥です。その例外をコマンド定義に追加する1行をもう一度送り、次の呼び出しが同じ間違いを二度ふるいにかけないようにしましょう。

一人ミニ版

チームもatomシステムもないなら、スラッシュコマンドの代わりに、メモアプリにテキストブロックを1つ置いてみましょう。タイトルは「シート検査プロンプト」。内容は上のsetupの検査項目4つ+ルール3行です。検査のたびにこのブロックをコピーし、シート名だけ変えてAIに貼り付けます。拒否することが出てきたら、そのメモブロックに例外を1行直接追加します。ツールがスラッシュコマンドでもメモ1枚でも、サイクル（ルール化 → 呼び出し → 検証・拒否 → ルール更新）は同じように回ります。

第4部 · Combat Design

4.1 戦闘プランナーとLayer — 打撃感はどのマスに入るのか

本章の学習目標（難易度🟡実務・前提：四則演算・表計算）：打撃感のような抽象的な形容詞を測定可能なシグナルへ分解し、戦闘プランナーの5つの成果物がLayerのどのマスに座るのかを、座標で指定できるようになります。

ビルド会議室。プログラマーが、たったいま組み込んだ新規スキルをモニターに映します。キャラクターが剣を振り、敵が後ろへ押し出されます。5人が見ています。誰かが言います。

「うーん……なんだか打撃感がちょっと弱いな」

隣の人がうなずきます。「ですよね、ちょっと物足りないですね」

プログラマーが尋ねます。「どこをどう変えればいいでしょうか？」

沈黙。会議室の5人のうち、誰もその質問に数字で答えられません。「打撃感が弱い」は5人全員が感じたのに、「ヒットストップを3フレームから5フレームに」と言える人はいません。会議は40分間、「もっとずっしりと」「インパクトが足りない」のような形容詞をやり取りした末、「ひとまず次のビルドでまた見ましょう」で終わります。

この場面が、戦闘企画のすべての問題を圧縮しています。プレイヤーが最も直接体感する分野なのに、その体感を言葉に移した瞬間、形容詞しか残りません。形容詞は測定できず、測定できなければ調整もできません。戦闘プランナーの最初の仕事は、この形容詞を数字へ引き下ろすことです。

本章は、その数字がどのマスに入るのかを定めます。戦闘プランナーが作る5つの成果物がそれぞれLayerのどこに座るのか、そしてその座標がなぜ自動化の前提条件になるのか。4.2・4.3・4.4の実戦ツールは、この座標の上で動きます。

専門外の読者のための一行。 この部で戦闘の数値やフレーム単位を覚える必要はありません。持ち帰っていただくのはただ一つ、これです — 「形容詞でやり取りされる依頼は、測定も調整もできない」。「もっとずっしりと」を「何をいくつに」へ引き下ろした瞬間に協業が回り始めるという発想は、ゲーム外のどんな職務の曖昧なフィードバックにもそのまま適用できます。4.1.1の5つの成果物は軽く流し読みして、この一点だけ手に握って先へ進んでいただいて構いません。

4.1.1 戦闘プランナーの机の上にある5つのもの

戦闘プランナーが責任を持つ成果物を一行でまとめると、「プレイヤーの入力が画面上のアクションへ変換される全過程」です。これを5つの塊に分けます。

第一に、戦闘Look & Feel仕様。 打撃感・応答性・重量感のような抽象を、測定可能な数値に翻訳した文書です。これがこの分野で最も難しい成果物であり、残りの4つを評価する基準になります。

Look & Feelは、さらに4つのシグナルへ分解されます。

• ヒットタイミング — 入力ボタンを押した時点から、視覚・聴覚の反応が画面に出るまで何msか
• ヒットストップ — 打撃が命中する瞬間、画面が何フレーム止まるか（通常1〜6フレーム）
• カメラシェイク — 振幅・持続時間・減衰曲線
• エフェクト同期 — VFX・SFX・UI反応が同じフレームでトリガーされるか

この仕様がなければ、会議室の場面が繰り返されます。仕様があれば、「ヒットストップ3→5フレーム、カメラシェイク振幅+20%」という調整指示が出ます。

第二に、スキル・コンボ・キャンセルのシステム。 入力がアクションへ変換されるルールです。

• スキル使用の流れ：入力 → 詠唱 → 発動 → 硬直（後隙）
• コンボのルール：どのスキルの後にどのスキルがつながり、そのボーナスは何か
• キャンセルのルール：どのアクションの最中に、どのアクションへキャンセルできるか
• 入力キュー（先行入力ウィンドウ）：アクション中に次の入力を受け付けるウィンドウ（ms）はいくつか

第三に、キャラクター・モンスターAI。 NPCの行動ロジック — ビヘイビアツリー（Behavior Tree、以下BT）、ステートマシン（FSM（Finite State Machine、有限状態機械）/HFSM）、デシジョンテーブル。モンスターの行動パターン、ボスのフェーズ移行、味方NPCの連携、群衆シミュレーションがここに入ります。

第四に、ダメージ・リソース・クールタイムの数式。 プレイヤーの選択が結果へ変換される数学です。ダメージ係数・防御減算・クリティカル・属性補正、リソース（MP/気力/スタミナ）の消費・回復曲線、クールタイム（クールダウン）の分布。

第五に、アニメーション制御仕様。 企画意図が実際のビルドでどう見えるかを定める図面 — アニメーショングラフ・BT・IKの接続です。これは通常プログラマー・アニメーターとの協業ですが、プランナーが意図の仕様を提供しなければ、ビルドで意図が壊れます。資材だけ渡して図面を渡さなければ、別の家が建ちます。

ここでの核心は、5つが同じ机の上で出会うという点です。コンボのルール（第二）が変わればダメージ数式（第四）のDPSが変わり、それがまたLook & Feel（第一）の体感の重さを変えます。どの成果物がどの成果物の入力なのかが明示されていなければ、一度の変更が5か所を揺らします。だから座標が必要なのです。

4.1.2 5つの成果物はLayerのどのマスに座るのか

2.3で定めたL0〜L4の座標の上に、戦闘の成果物5つを載せます。このマッピングが本章の背骨です。

flowchart TD
    L0["L0・ビジョン
'打撃感が生きているアクション戦闘'"]
    L1["L1・システム骨格
コンボ・キャンセル構造 / Look&Feel仕様 / クラス骨格"]
    L2["L2・コンテンツの流れ
チャプター別の敵集団曲線 / スキル解放順序"]
    L3["L3・マスターデータ
ダメージ係数・クールタイム値・リソース消費"]
    L4["L4・ビルド計測
実測DPS / 実際のコンボ経路 / プレイヤーフィードバック"]

    L0 -->|"受け取る"| L1
    L1 -->|"骨格が流れを規定"| L2
    L1 -->|"仕様が数値の基準"| L3
    L2 --> L3
    L3 -->|"ビルドに反映"| L4
    L4 -.->|"計測 → 仕様修正のフィードバック"| L1
    L4 -.->|"外れ値 → マスターデータ調整"| L3

    classDef vision fill:#2d3748,stroke:#1a202c,color:#fff
    classDef build fill:#c05621,stroke:#7b341e,color:#fff
    class L0 vision
    class L4 build

表に整理し直すとこうなります。

戦闘企画の特徴は、L4の比重が他分野より大きいという点です。シナリオ企画ではL1仕様がほぼそのまま最終形ですが、戦闘は違います。「打撃感が良い」は、ビルドで直接手を動かして叩いてみて、画面を見なければ分からない領域です。仕様に「ヒットストップ5フレーム」と書いても、それが実際にずっしり感じられるかどうかはL4でしか確認できません。だからこそ、シミュレーションと自動計測ツールがこの分野で最も大きな価値を生みます（4.4）。

ただし、L4が大きいからといってL1の重要度が下がるわけではありません。点線の矢印を見てください。L4の計測値はL1仕様へフィードバックされます。仕様がなければ、計測値は「比較する基準」を失います。5フレームという仕様があってこそ、「実測4フレーム、1フレーム欠落」という診断が出ます。仕様 → ビルド → 計測 → 仕様修正のサイクルが、5つのLayerをすべて通ります。戦闘プランナーはこのサイクル全体に手を載せている、一つの机で最も多くのLayerが同時に回るポジションです。

4.1.3 形容詞を数字に — 実作業のひとつの背骨

抽象論はここまでです。ここからは会議室の場面に戻り、「打撃感が弱い」を実際に数字へ引き下ろす過程を、ワークド・トランスクリプトで見ます。道具はLLM一つです。出力は整えず、人が拒否した部分もそのまま残します。

著者がディレクターとして運営しているあるMMORPGプロジェクト（以下「プロジェクトA」）の戦闘TFで、新規近接スキル一つのLook & Feelを仕様化した実際の流れを再構成します。

プロンプト（全文）

このスキルのLook & Feelを、形容詞ではなくms・フレームの数値に変えてくれ。
ヒットタイミング、ヒットストップ、カメラシェイク、エフェクト同期、硬直の5つ。
確信がないものは「このゲームで検証必要」と書いてくれ。

スキル: 大剣縦斬り (heavy_overhead_slash)
意図: 「ずっしりと振り下ろし、敵がよろめく感じ」
フレームレート: 60fps

Claudeの生の出力（要約・整理なし）

大剣縦斬りの「ずっしり感」は、主にヒットストップと硬直の長さ、そしてカメラシェイクの減衰で作られます。項目別に提示します。

1) ヒットタイミング。 重い武器ほど、入力から発動までの予備動作（発生）が長いほうが重量感が生きます。入力から最初の視覚反応（キャラクターが剣を持ち上げ始める）まで50〜80ms（3〜5フレーム）推奨。ただし、最初の視覚反応と最初の打撃反応は別物です。打撃の命中まではモーションの長さに依存するため、ここでは断定できません — このゲームのモーション長で検証が必要です。

2) ヒットストップ。 ずっしりした一撃の核心変数です。軽い攻撃が1〜2フレームなら、大剣縦斬りは4〜6フレーム（約67〜100ms）推奨。6フレームを超えると「ずっしり」が「引っかかり」へ変わり、応答性が悪くなります。

3) カメラシェイク。 振幅は画面高さの約1〜2%、持続0.2〜0.3秒、減衰は線形よりease-out（速く弱まる）。重い一撃は、最初の振動が強く、速やかに収まる曲線が自然です。

4) エフェクト同期。 VFX（ヒットエフェクト）・SFX（打撃音）・ヒットストップは必ず命中フレームに同時にトリガーされる必要があります。1〜2フレームずれただけで「物足りなさ」として体感されます。UI反応（ダメージ数字）は1〜2フレーム遅れても問題ありません。

5) 硬直。 ずっしり感の代償として硬直が長くなります。命中後、被弾可能な状態へ復帰するまで20〜30フレーム（333〜500ms）推奨。ただしこの値は、ゲーム全体の戦闘テンポ（速いアクション vs 重厚なソウルライク）によって大きく変わります — このゲームの基準テンポで検証が必要です。

まとめると、「ずっしり感 = 長い予備動作 + 4〜6フレームのヒットストップ + ease-outシェイク + 同一フレームのVFX/SFX/ストップ + 長い硬直」です。ただし上記の数字は一般的な推奨範囲であり、実際の重量感はビルドで手を動かして叩いてみて調整して初めて確定します。

人による検証・拒否・再依頼

ここでプランナーは、出力を丸ごと採用しません。2か所で立ち止まります。

拒否1 — カメラシェイク振幅「画面高さの1〜2%」。 このゲームはモバイル優先です。小さな画面では1〜2%はほとんど見えません。モバイルの画面酔いの問題もあります。プランナーはこの推奨値を拒否し、「モバイルではシェイクの代わりに、ヒットストップの強調で重さを表現する」という自前の原則を適用します。LLMは一般論を出しただけで、このゲームのプラットフォーム制約は知りません。

保留2 — ヒットストップ「4〜6フレーム」。 これは拒否ではなく保留です。範囲としては正しいものの、正確な値はビルドの手触りで決めます。仕様には「4フレームを基本値としてビルドに入れ、5・6フレームのバリエーションを作って3つを手で比較する」と書きます。

再依頼はこう出します。

モバイル優先のプロジェクトだ。カメラシェイクは最小化し、重量感を
ヒットストップ・硬直・SFXで表現する方向で仕様を書き直せ。
ヒットストップは4/5/6フレームの3バリエーションをビルド比較用に表で。

この2回目の出力でLLMは、モバイル制約を反映した仕様表を作ります。その表がビルドに入り、次のビルド会議でプランナーは形容詞の代わりに「4フレーム版は軽すぎる、5フレームを採択」と言います。40分の会議が、5分の決定に縮まります。

このトランスクリプトが見せてくれるもの

3つです。第一に、LLMは形容詞を数字の範囲へ引き下ろす一次ドラフトを上手に作ります — これが会議室の沈黙を破ります。第二に、LLMはこのゲームの制約（モバイル・テンポ・モーション長）を知りません — だから一般的な推奨値を出すだけで、拒否・調整は人の仕事です。第三に、LLM自身が「ビルドで手を動かして叩いてみて初めて確定する」と2回も釘を刺しました — 重量感の最終判断はL4の人の手にあるという事実を、道具も知っているのです。

4.1.4 AIが導入価値を回収する4つの持ち場

上のトランスクリプトは、一つの持ち場（仕様化）だけを見せました。戦闘企画全体でAIが価値を生む持ち場は4か所です。

1) シミュレーション — 最大の価値。 DPS（Damage Per Second、秒間ダメージ）曲線・コンボ経路・リソース消費を、ビルドなしで事前計算します。ビルドを作って手で計測するより圧倒的に速いです。4.4でsimulate_dpsシミュレーターを直接扱います。

2) ステートマシン・BTの自動生成。 「このボスは体力50%以下で狂暴化し、狂暴化中は3連撃パターンを使う」のような自然言語の説明を、BT/FSMダイアグラムへ変換します。正確度は高いです — ルール構造はLLMが得意とする領域です。頭の中のロジックを図へ移す時間が節約されます。

3) ビルドキャプチャーの自動分析。 プレイ映像からヒットタイミング・コンボ成功率・被害分布を自動抽出します。ただしこれは実装難易度が最も高い持ち場です（下で正直に検討します）。

4) バランス調整候補の提案。 マスターデータの各行を分析して外れ値・曲線の非平滑さを検出し、調整候補を出します。人は選ぶだけです。

この4か所のうち、ビルドキャプチャーの自動分析（3）は、「できる」と「簡単にできる」の距離が最も遠い持ち場です。書籍ではよく「AIが映像から自動で全部抽出してくれます」と書かれますが、実際はそれほど単純ではありません。映像ピクセルベースのコンピュータービジョン、既製のビジョンAPI、ゲーム内telemetryログ — 3つのキャプチャー方法の正確度・実装負担の比較は4.4を正とするので、そちらを参照してください。ここでは結論だけ押さえます。

最も現実的な道はゲーム内telemetryログです。エンジンが「フレーム1204でskill_overheadが命中、ダメージ340、コンボカウント3」のようなイベントを直接記録するようにします。これはソースデータなので正確で、ロギングコードを一度挿入すれば終わりです。LLMはそのログを読んで、自然言語レポート（「3コンボまではリソース効率が良いが、4コンボから急減する」）へ要約するのに使います。映像は、人が疑わしいケースだけ目で確認する補助として残します。

つまり「AIが映像を自動分析する」というビジョンの現実的な形は、telemetryログ + LLM要約であって、ピクセルビジョンではありません。この正直な区分が、4.4のツール選択の出発点です。

そして、4つの持ち場すべてで変わらないことが一つ。「打撃感が良い」の最終判断はAIにはできません。 それはプレイヤーの感情の領域であり、その感情に対する責任は人が引き受けます。AIはその感情判断の根拠資料を速く作ってくれるだけです。シミュレーション数値、BTダイアグラム、telemetryレポート — すべて、人が手触りで決定を下すための材料です。

4.1.5 座標を分けた本当の理由 — 自動化の前提条件

ここまでは「成果物をLayerで分ければ、協業のときに言葉が通じる」という表面的な理由でした。コンボのルールをL1に、ダメージのマスターデータをL3に置いたのは、変更頻度が違うからだと説明しました。正しい話ですが、それがすべてではありません。

座標を分けた本質的な理由は、自動化がその上でしか動かないからです。Layer分解がプロシージャル生成・自動化の前提であるという一般的な論題は2.3で扱ったので、ここではその前提が戦闘分野の3つの自動化でどう明暗を分けるのかに絞ります。

第一に、シミュレーションは「何を入力し、何を変えられるのか」が区分されていなければ回りません。 決定論的コア（物理・当たり判定 — L1骨格）と変更可能な仕様（ダメージ値・クールタイム — L3マスターデータ）が混ざっていると、シミュレーターは「変更候補空間」を定義できません。コアは固定、マスターデータは変数 — この分離があってこそ、simulate_dpsが「ダメージ係数を280から340まで20刻みで上げながらDPS曲線を描け」のような探索を行えます。

第二に、ビルドキャプチャーの自動分析は、アクションatomがラベリングされていて初めて意味を持ちます。 仕様の側で「このフレーム区間はskill_overheadのhit段階」とラベル付けされたatomがあってこそ、telemetryログから抽出したシグナルを仕様と自動照合できます。ラベルがなければ、ログは「フレーム1204で何かが命中」という、意味のない点の羅列です。

第三に、LLMによるコンボシーケンス生成は、キャンセルルール・入力キューが外部文書として分離されていて初めて動きます。 「このキャラクターのキャンセル可能ペア7個と入力キュー200msの中で、5コンボのシーケンスを10個提案せよ」のような限定依頼は、キャンセルルールがコードの中に固定されておらず、文書として切り出されているときにのみ可能です。

3つが同じ一つの文を語っています。決定論的コアが仕様と混ざれば自動化は塞がり、分離されれば自動化は開きます。 Layer分解は、協業言語の統一が表面の目的で、本質の目的は自動シミュレーション・キャプチャー分析・LLMシーケンス探索の前提条件を敷くことです。

保守的適用から進歩的適用へ

この前提が敷かれると、戦闘運営は2段階で進化します。

保守的適用 — 人が設計し、自動が検証します。 いま、大半のアクション・MMORPGの戦闘運営はここにあります。人がコンボ・キャンセル仕様を直接書き、自動がDPS・リソースをシミュレートし、telemetryでキャプチャーして「仕様 vs 計測」の比較レポートを出します。人はその差を解釈して仕様修正を決定し、再び仕様作成へとサイクルが回ります。設計は人、シミュレーション・キャプチャー・比較は自動です。

進歩的適用 — AIが候補を発議し、人は採択するだけ。 次の段階です。AIがキャンセルペアと入力キューの範囲内でシーケンスを10〜30個自動列挙し、自動が各シーケンスのDPS・リソースを並列にシミュレートし、LLMが「リソース効率1位、入力難易度は中」のように順位・解釈を付けます。人の手に残る決定は「候補のうちどのシーケンスをシグネチャーとして採択するか」一つ、そしてディレクターによるビルド反映・モーションキャプチャーの決定だけです。シーケンスをゼロから作るのと、30個の中から選ぶのとでは、作業負担の次元が違います。

進歩的適用が定着するには、3つが揃う必要があります。（1）ビルドなしで1秒以内にDPS・リソース・生存時間を計算する決定論的シミュレーションインフラ、（2）コンボ・キャンセル・入力キューが外部文書として分離・ラベリングされたアクションatom、（3）telemetryベースのキャプチャー自動分析。3つとも、上で述べたLayer分解の直接の成果物です。

モーションキャプチャーは不可逆の段階 — 決定ゲート

最後に可逆性です。戦闘プランナーのレビューサイクルには、巻き戻せる段階と巻き戻せない段階が混ざっており、その境界を知ることが重要です。

モーションキャプチャーは、戦闘で最も分厚い不可逆段階です。キャプチャースタジオのスケジュール、俳優のキャスティング、再撮影の費用、どれも大きくつきます。だからシグネチャーアクションのモーションキャプチャーは、シミュレーションとキャプチャー自動分析が十分に回り、シーケンスを確定した後にのみ進めます。保守的であれ進歩的であれ、モーションキャプチャーとライブビルドの直前を決定ゲートとして置きます。戦闘プランナーのすべてのレビューは、このゲートの左側の可逆段階で完結してこそ安全です。

4.1.6 会社での風景 — 何が減ったのか

プロジェクトAの戦闘TFが、上の座標とツールを6か月運営しながら計測した変化です。以下の数値はTF運営記録から抜き出したおおよその平均であり、精密な計測値ではなく、体感変化の方向として読むのが正確です。

数字そのものより、方向が核心です。4項目すべてが「主観の議論・手動計測・ビルドの繰り返し」から「計測値・シミュレーション・ダイアグラム自動化」へ移りました。会議室で形容詞が減り、数字が増えました。それが本章全体の言いたい一文です — 戦闘プランナーの仕事は、主観（打撃感・面白さ）から客観（数値・シミュレーション）へ渡る橋を架けることであり、AIはその橋を速く敷く道具です。橋の先で「ずっしりしている」を決める手は、依然として人のものです。

本章のポイント

• 戦闘企画は、L1仕様からL3マスターデータ、L4ビルド実測まで、一つの机で最も多くのLayerが同時に回るポジションです。
• Layer分解は、協業言語の統一が表面で、本質はシミュレーション・キャプチャー・LLM探索という自動化の前提条件です。
• 「打撃感が良い」の最終判断は人の仕事であり、AIはその判断の根拠資料を速く作ります。

やってみよう — 形容詞を数字に引き下ろす

setup. LLMが一つあれば十分です。手元のスキルを一つ選んでください（新規でも既存でも）。そのスキルの意図を形容詞一行で書きます — 「ずっしりと」「素早く」「重々しく」のように。

prompt. 下の骨格にスキル情報を埋め込んでみましょう。

君は戦闘企画の補助だ。下のスキルのLook & Feelを「測定可能な
数値仕様」に変換せよ。形容詞ではなくms・フレーム・%単位で。
確信のない項目は「このゲームで検証必要」と明記せよ。

スキル: [名前]
意図: 「[形容詞一行]」
フレームレート: [60fpsなど]
項目: 1)ヒットタイミング 2)ヒットストップ 3)カメラシェイク 4)エフェクト同期 5)硬直

verify. 出力のすべての数字に、2つの質問を投げてみましょう。（1）このゲームの制約（プラットフォーム・テンポ・モーション長）でこの値は合っていますか？ → 合わなければ、制約を伝えて再依頼してください。（2）この値はビルドで手を動かして確定すべきものですか？ → そうであれば、単一の値の代わりに2〜3個のバリエーションを仕様に書き、ビルドで比較してください。LLMが「検証が必要」と釘を刺した項目は、絶対にそのまま採択しないでください。

4.1.7 一人ミニ版

一人で作るゲームなら、5つの成果物・5つのLayerをすべて揃える必要はありません。最低限、次の2つだけ行ってください。一つ、Look & Feel仕様を1ページ — 核心アクション3〜5個について、ヒットストップ・硬直・同期だけを数字で書きます。形容詞で書かれたメモは、6か月後の自分にも読み解けません。二つ、コンボ・キャンセルをコードから分離して1ファイルに — キャンセルペアをデータとして切り出しておけば、後でLLMに「このペアで作れるコンボを5個提案」と頼めます。この2つが、1人開発でも自動化の扉を開けておく最小の座標です。

4.2 戦闘のLook & Feel — 手触りをデータで捉える

会議室のモニターの前に5人が集まっています。同じビルド、同じスキル、同じ30秒の映像が、画面で3回目のリピート再生されているところです。クライアントプログラマーが最初に口を開きます。「自分は問題ないと思いますけど」。アート担当が腕を組みます。「弱いですね。何か足りない感じ」。隣にいたプランナーが割り込みます。「エフェクトはいいんですが、手に馴染まないんですよ」。ディレクターはしばらく見てから決定を下します。「うーん……もう少しだけ重めにいきましょう」。

そして会議が終わります。「もう少しだけ重めに」が正確に何msで何フレームなのかは、誰も書き留めませんでした。次のビルドでプログラマーは自分が理解した「重さ」を実装し、アートは自分が理解した「重さ」を載せます。そして翌週、同じ会議室で同じ映像を見ながら、同じ会話が繰り返されます。

打撃感、手触り、Look & Feel。戦闘企画でもっとも頻繁に使われ、もっとも定義されていない言葉です。誰もが知っていると信じているのに頭の中の定義はバラバラで、議論が終わっても何も残りません。本章はその「感じ」を測定可能な数字に分解する作業を扱います。手触りを抽象からデータへ引きずり下ろす場です。

4.2.1 戦闘 = Look & Feel、システム = 動作

まず境界線を引いておきます。戦闘企画は大きく2つに分かれます。

• 戦闘システム：どう動作するか。ダメージ計算式、クールタイム（クールダウン）、スタックの蓄積、状態異常のルール。次章（4.3 コンボ・キャンセル、4.4 AIシミュレーション）の領域です。
• 戦闘のLook & Feel：どう感じられるか。ボタンを押してから画面がいつ反応するか、ヒットの瞬間に画面がどれだけ止まるか、エフェクトと音と振動が同じ瞬間に弾けるか。

本章は後者だけを扱います。ダメージが100でも120でも、手触りとは直接の関係がありません。その100のダメージが「入る瞬間」をプレイヤーがどう体感するかが手触りです。同じダメージ計算式でも、ヒットタイミングとヒットストップが違えば、まったく別のゲームのように感じられます。

まず正直に押さえておきたいことがあります。打撃感は3つの数字だけでは完成しません。攻撃モーション（アニメーション）の加速・減速カーブ、受け手側の反応（ヒットリアクション・硬直）、80〜90年代の日本のアクションゲームが好んで使ったデフォルメ（打撃の瞬間にキャラクターを誇張して伸ばし、つぶす残像・つぶれの表現）まで全部そろって、はじめて「当たった」というひとかたまりの感覚が立ち上がります。本章が集中して測定可能な数字に引きずり下ろすものは、そのうちの3つの軸です。モーション・リアクション・デフォルメはアニメーター・アーティストの手がより大きく関わる領域なので、続く章とアートのパートで扱い、ここではプランナーが仕様書で固定し、ビルドで検証できる3つの軸に重きを置きます。その3つの軸は、次のように分かれます。

会議室で誰かが「弱い」と言うとき、その弱さは3つのうちのどれかから来ています。反応が遅いのか（タイミング）、ヒットの手応えがないのか（ヒットストップ）、バラバラに動いているのか（同期）。3つの軸に分解して問えば、「弱い」がようやく直せる文章になります。

ただし、「弱い」の原因がつねにこの3軸だけにあるわけではありません。手触りを構成する要素を漏れなく並べ、本章がどこまで責任を持つのか、線を引いておきます。

上の4つが本章の3軸としてまとめられ、測定・仕様化の対象になります。中央の3つ（モーション・リアクション・デフォルメ）は欠かせないものの、プランナーひとりでは数字で閉じにくいアート・アニメーション領域なので、「存在する」ということだけを明確にしておきます。モーションが硬かったり、受け手側が平然と立っていたりすれば、3軸がすべて合っていても打撃感は立ちません。

4.2.2 ヒットタイミング — 入力から反応まで

3つの軸のうちタイミングを最初に扱うのには理由があります。プレイヤーが手触りを疑うとき真っ先に引っかかるのが「反応が遅い」という感覚であり、他のどこがどれだけ派手でも、入力がもたつけばその瞬間にすべてが崩れるからです。だから、タイミングから固めます。

手触りの最初の軸は時間です。ボタンを押したその瞬間（0ms）から、画面が最初に反応する瞬間まで何msかかるか。人間はこの遅延に驚くほど敏感です。60msと120msの違いを「言葉では説明できなくても、手は知っている」のです。

1回の攻撃は単純な1点ではなく、時間の上に広がる複数の事件です。通常攻撃の1段目を時間軸に載せると、こんな形になります。

この図でもっとも重要な数字は「当たり判定（ヒットボックス）が最初にオンになる100ms」です。ボタンを押してから100ms後に攻撃判定が始まるという意味です。この値が手触りの体感速度を決めます。

推奨範囲はジャンル・キャラクターごとに異なりますが、おおまかな基準線はあります。

この範囲は絶対の基準ではありません。著者の推定（未検証）であり、カジュアルモバイルは入力に寛容な方向へ±50msほど揺れ、コンソールの格闘ゲームはより厳しく締める傾向があります。数字そのものより、「うちのゲームの軽い攻撃は90msで合意した」という基準線をチームで共有することが核心です。基準線があってはじめて、ビルドを見て「合っている/間違っている」を言えるようになります。

ところが、ここにひとつ落とし穴があります。人間の目では90msと110msを区別できません。60fpsでは1フレームは約16.67msで、この20msの差は1フレーム余りです。会議室での「ちょっと遅い気がするんだけど？」という言葉が正しいのか間違っているのか、目では最後まで判定がつきません。だから測定が必要なのです。

4.2.3 ビルドからタイミングをどう取り出すか — 正直な比較

仕様書に「当たり判定100ms」と書きました。ビルドで実際に100msでオンになることをどう確認するのか。自動化の道は3つ（映像分析・既製のvisionツール・ゲーム内テレメトリー）に分かれますが、3方式の精度・難易度の比較は4.4で本格的に扱います。ここでは結論だけ押さえます。実務で最初に敷くべきものはゲーム内テレメトリーです。理由は単純です。VFXが画面に「現れたフレーム」を映像から推論するより、コードがOnHitイベントを発生させたフレームに直接[HITLOG]を1行出力するほうが、比較にならないほど正確で安上がりだからです。映像分析は入力オーバーレイのない外部映像（例：競合作の分析）にだけ使い、自分たちのビルドにはテレメトリーから敷きます。

テレメトリーログはこんな形をしています。

[HITLOG] frame=6  t_ms=100  evt=hitbox_on    skill=1001 char=warrior
[HITLOG] frame=6  t_ms=100  evt=vfx_trigger  skill=1001
[HITLOG] frame=6  t_ms=100  evt=sfx_trigger  skill=1001
[HITLOG] frame=7  t_ms=117  evt=damage_apply skill=1001 dmg=124
[HITLOG] frame=7  t_ms=117  evt=ui_dmgnum    skill=1001
[HITLOG] frame=6  t_ms=100  evt=cam_shake    skill=1001 amp=0.4

プランナーの仕事は、このログを仕様書と1行ずつ突き合わせることです。数値の換算と機械的な照合がほとんどなので、人間が目で繰り返すと疲れて間違えますが、LLMは疲れません。次の節で実際にやらせてみます。

4.2.4 ワークド・トランスクリプト — テレメトリーログを仕様書と突き合わせる

仕様のyamlとビルドのテレメトリーログを両方貼り付けて、AIに2つを突き合わせ、ズレている項目を見つけるよう指示しました。以下はプロンプトの全文とClaudeの生の出力、そして人間による検証プロセスの全体です。要約せず、そのまま載せます。

1次プロンプト

次は戦闘スキル1つの「ヒットタイミング仕様」と、実際のビルドから抜いた
telemetryログだ。仕様に対してビルドがずれている項目を表に整理して。

[仕様]
character: warrior
skill_id: 1001
fps: 60
events:
  hitbox_on:    {expect_ms: 100, tol_frame: 0}
  vfx_trigger:  {expect_ms: 100, tol_frame: 0}
  sfx_trigger:  {expect_ms: 100, tol_frame: 1}
  damage_apply: {expect_ms: 110, tol_frame: 1}
  ui_dmgnum:    {expect_ms: 100, tol_frame: 2}
  cam_shake:    {expect_ms: 100, tol_frame: 1}

[telemetryログ]
[HITLOG] frame=6  t_ms=100  evt=hitbox_on    skill=1001
[HITLOG] frame=6  t_ms=100  evt=vfx_trigger  skill=1001
[HITLOG] frame=8  t_ms=133  evt=sfx_trigger  skill=1001
[HITLOG] frame=7  t_ms=117  evt=damage_apply skill=1001
[HITLOG] frame=9  t_ms=150  evt=ui_dmgnum    skill=1001
[HITLOG] frame=6  t_ms=100  evt=cam_shake    skill=1001

60fps(1フレーム=16.67ms)。expect_msをフレームに換算してログのframeと
比較し、差がtol_frameを超えたらFAILと表示して。

Claudeの生の出力（そのまま）

まず仕様のexpect_msをフレームに換算します。60fpsではframe = round(ms / 16.67)です。

• hitbox_on: 100 / 16.67 ≈ 6.0 → frame 6
• vfx_trigger: 100 → frame 6
• sfx_trigger: 100 → frame 6
• damage_apply: 110 / 16.67 ≈ 6.6 → frame 7（四捨五入）
• ui_dmgnum: 100 → frame 6
• cam_shake: 100 → frame 6

ログの実際のframeと比較した結果です。

イベント	期待frame	実際frame	差（frame）	許容	判定
hitbox_on	6	6	0	0	PASS
vfx_trigger	6	6	0	0	PASS
sfx_trigger	6	8	+2	1	FAIL
damage_apply	7	7	0	1	PASS
ui_dmgnum	6	9	+3	2	FAIL
cam_shake	6	6	0	1	PASS

2項目が許容誤差を超えました。 - sfx_trigger：サウンドが視覚ヒットより2フレーム（約33ms）遅れています。許容1フレームを超過。プレイヤーは「音が少しずれている」と感じる可能性が高いです。 - ui_dmgnum：ダメージ数字が3フレーム（約50ms）遅れて表示されます。許容2フレームを超過。「当てたのに数字が遅れて出る」という違和感につながり得ます。

damage_applyがframe 7であるのは、仕様上のframe 7（110ms換算）と一致するので正常です。ただし、damage_applyがhitbox_on（frame 6）より1フレーム後である点は、意図された設計かどうか確認が必要です。

人間による検証 — 1か所を拒否した

出力を受け取って、すぐに全部を信じたわけではありません。検証ポイントが2つありました。

検証1（四捨五入の境界 — 通過）。damage_applyの110ms換算が疑わしく見えました。110 / 16.67 = 6.598…です。四捨五入すれば7で合っています。しかし、もし仕様の意図が「6フレーム = 100msと同じフレーム」だったとしたら？　直接確認したところ、仕様にはdamage_apply: expect_ms 110としてvfx（100）と意図的に10msの差をつけたのが正しいと分かりました。だからframe 7への換算は正確でした。AIは通過です。

検証2（最後の文 — 拒否）。AIが最後に付け足した「damage_applyがhitbox_onより1フレーム後である点は、意図された設計かどうか確認が必要です」はノイズでした。仕様にすでにexpect_ms 110として意図が明記されているのに、AIがそれを「要確認」と問い返したのです。仕様を渡したなら仕様の中で答えを閉じるべきなのに、不要な質問を作り出しました。この文は採用しませんでした。

拒否の理由を添えて、再依頼しました。

2次プロンプト（再依頼）

damage_applyは仕様に110として意図が明記されているから「確認が必要」コメントは外して。
// 仕様の中で答えが閉じている項目を問い返すなという意味
FAILの2件(sfx, ui_dmgnum)だけ残して、原因の断定の代わりに
「確認すべきコード/リソースの位置」のチェックリストにして。

Claudeの2次出力（そのまま）

FAIL 2件についての確認チェックリストです。原因は断定せず、確認すべき地点だけを整理しました。

sfx_trigger（+2フレーム遅延） - [ ] サウンドのトリガーがhitbox_onと同じイベントにバインドされているか、それとも別のアニメーション通知（Notify）に掛かっているか - [ ] オーディオアセット自体に先頭無音（leading silence）があるか — ファイル冒頭の空白区間が遅延に見えることがある - [ ] サウンド再生の呼び出しは同じフレームで入ったのに、出力レイテンシーで押し出されたのか（プラットフォームのオーディオバッファ）

ui_dmgnum（+3フレーム遅延） - [ ] ダメージ数字のUIがdamage_apply（frame 7）以降の別ティックで更新される構造か - [ ] UI更新が次フレームの末尾にまとめて処理されるのか（遅延レンダーキュー） - [ ] 数字ポップアップアニメーションの開始フレームに追加のディレイ値が入っているか

断定できること：2項目とも仕様の許容誤差を超えており、視覚ヒット（frame 6）より遅れています。断定できないこと：上記の原因のうちどれなのかは、コード/アセットを確認するまで分かりません。

この2次出力はそのまま採用しました。原因をでっち上げず、「確認すべき場所」に変えたのが、まさに求めていた形でした。このチェックリストをサウンド担当とUI担当にそのまま渡したところ、サウンドはオーディオアセットの先頭無音33msが犯人でした（チェックリストの2番目の項目）。UIは次フレーム更新の構造でした（1番目の項目）。

ここで分業の線がはっきりします。AIは仕様書とログを機械的に突き合わせてFAILを捕まえ、人間は（a）AIが作り出した不要な問い返しを拒否し、（b）FAILの本当の原因をコードで確定します。AIに原因の断定をさせると、もっともらしい嘘を作り出すので、「確認すべき場所」までにとどめるのが安全です。

4.2.5 ヒットストップ — 打撃の重さ

2つ目の軸は停止です。ヒットが命中した瞬間、ゲーム時間をごく短く止めたり遅くしたりする効果。これが「当てた」という感覚の強度を決めます。格闘ゲームとアクションRPGで、もっとも強力な手触りの道具です。長すぎればもたつき、短すぎれば重さが出ません。

推奨範囲（60fps基準）は次のとおりです。この数値はアクションゲームで通用するおおまかな慣行であり、絶対値はゲームごとに調整します。

キャラクター・スキルごとに変えて与えるべきです。全部同じにすると重さの差が出ず、結局すべての攻撃が同じトーンに収束します。これが、4.2のポイント3つのうちの1つにつながる地点です。

「誰が止まるのか」も設計上の選択です。

仕様書にはこう入力します。

character: warrior
skill_id: 1001
hit_stop:
  attacker: 2          # frames
  victim: 4
  critical_multiplier: 1.5   # クリティカル時1.5倍 (四捨五入)

ヒットストップは、仕様の数字だけでは「合っている/間違っている」を閉じられない、手触り検証がもっとも難しい軸です。テレメトリーで「実際に4フレーム止まったか」は捕まえられますが、「4フレームが適切か」は人間がビルドを直接触りながら判定しなければなりません。AIは仕様との一致を保証し、人間はその仕様値そのものの適切さを見ます。

4.2.6 エフェクト同期 — 同じフレームですべてが弾けるか

3つ目の軸は同時性です。VFX（視覚エフェクト）・SFX（音）・UI（ダメージ数字）・カメラ（シェイク）・振動（コントローラー）が同じフレームで始まると、プレイヤーの脳はそれを「1つの事件」として束ねます。1〜2フレームずれただけで「違和感がある」、3〜5フレームずれると「バグみたいだ」という反応が出ます。先のワークド・トランスクリプトでsfxが2フレーム、uiが3フレーム遅れてFAILになったのが、まさにこの軸の問題でした。

同期対象の5種と許容誤差です。

核心は、この5種がすべて仕様書に入っていなければならないということです。よくある失敗が、VFXだけ仕様書に書いて、残りの4つを「うまく合わせてくれるだろう」で済ませることです。仕様書になければビルド検証の基準もなく、テレメトリーで捕まえても比較する対象がありません。5種が全部仕様書にあってはじめて、自動比較が閉じます。

自動比較には、前節のワークド・トランスクリプトがそのまま適用されます。テレメトリーログに5種のトリガーフレームが全部記録されていれば、AIが仕様書と突き合わせて誤差超過の項目だけをレポートします。人間が100個のスキルを毎ビルドごとに目で確認する必要はありません。ただし、AIが仕様とのズレを捕まえることと、人間が「仕様は全部合っているのに、それでも感覚が立たない」領域を捕まえることは、別物として残ります。

4.2.7 仕様書から次のビルドまで — 全体ループ

ここまでの断片を1つの流れにつなぎます。このループが回り始めると、会議室の「もう少しだけ重めに」が「ヒットストップ victim 4→6フレーム」に翻訳されます。

flowchart TD
    A["仕様書の作成
(プランナー: yaml)"] --> B["ビルドの実装
(プログラマー・アーティスト)"]
    B --> C["ビルド実行 + テレメトリーログ
[HITLOG] 自動出力"]
    C --> D["AIによる自動突き合わせ
仕様yaml vs テレメトリー"]
    D --> E{"誤差超過の
FAILはあるか?"}
    E -->|あり| F["FAIL項目 + 確認チェックリスト
(AI、原因の断定は禁止)"]
    F --> G["担当者がコード・アセットで
本当の原因を確定 (人間)"]
    G --> B
    E -->|なし| H["プランナー: 「感覚」の検討
仕様は合っているが手触りは出るか (人間)"]
    H -->|要調整| A
    H -->|OK| I["次のマイルストーンの振り返りの入力として保管"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class C code;
    class D,F ai;
    class A,G,H human;
    class I pass;

このループでは、AIが受け持つマス（D、F）と人間が受け持つマス（A、G、H）がはっきり分かれます。AIは機械的な突き合わせとチェックリストの生成に強く、人間は基準線の設定・原因の確定・最終的な感覚の判定に強いのです。自動化は人間を外すのではなく、毎回半日ずつ費やしていた「目でフレームを数える」作業から人間を解放し、「感覚」だけに集中できるようにします。

ループの最後のマス（I）が重要です。この測定データは一度使って捨てるものではなく、次のマイルストーンの振り返りの入力として再び入っていきます。「先四半期の手触りFAILはsfx同期に集中していた」のようなパターンがデータとして残れば、次の四半期はオーディオパイプラインから先に手を入れます。

4.2.8 測定が議論を減らした現場 — 運用観察

著者がディレクターとして参加したあるモバイルMMORPGプロジェクト（以下「プロジェクトA」）で、上記のループを約6か月回しながら観察した変化です。以下の数値は精密な計測ではなく、議事録のタイムスタンプとビルド検証の記録に基づく著者の運用観察（推定を含む）であり、方向性と比率で読んでいただきたいものです。絶対値を引用可能なベンチマークとして使わないでください。

数字そのものより、定性的な変化が本質です。会議室で「弱いんですが」が出ると、すぐに「どの軸ですか？　タイミング？　ヒットストップ？　同期？」と問い返すようになり、答えが出なければテレメトリーを一緒に立ち上げました。測定可能な客観が議論の終着点を作ったことが、6か月でもっとも大きな変化です。「もう少し重めに」が会議室の外へ出ていくことが減りました。

4.2.9 よくある失敗と回避策

やってみよう

自分のプロジェクトに、このループを最小規模で敷いてみる手順です。

setup 1. 検証するスキルを1つ選びます（通常攻撃を推奨）。 2. コードのトリガー地点6か所（hitbox_on、vfx、sfx、damage_apply、ui_dmgnum、cam_shake）に、[HITLOG] frame=X t_ms=Y evt=... skill=...の形式でログを1行ずつ仕込みます。 3. 仕様のyamlを書きます（eventsブロックにexpect_ms + tol_frame）。本章の1次プロンプトの例をテンプレートとして使ってください。

prompt 4. ビルドを1回走らせて、テレメトリーログを集めます。 5. 仕様のyaml + テレメトリーログを一緒にAIに貼り付けて、こう指示します。「仕様書に対してビルドがずれている項目を、60fpsのフレーム換算で突き合わせてFAILだけ表にして。原因は断定せず、『確認すべき場所』のチェックリストで」（本章の2次プロンプトの形）。

verify 6. AI出力のフレーム換算を、1か所だけ自分で検算してみましょう（ms / 16.67を四捨五入）。1か所でも間違っていたら、全体を疑いましょう。 7. AIが仕様の中で閉じている項目を問い返したり、原因を断定したりしたら、拒否して再依頼しましょう。 8. FAILチェックリストを担当者に渡して、コード・アセットで本当の原因を確定してもらいましょう。

一人ミニ版

チームもテレメトリーのインフラもない個人開発者なら、こう縮めましょう。ビルドを60fpsで画面録画し、入力の瞬間が見えるようにキー入力オーバーレイをオンにします。検証するスキルを1回録画したあと、動画編集ソフトで「ボタンを押したフレーム」と「画面が最初に変わったフレーム」を自分で数えます。2つのフレーム番号と仕様の期待値をAIに渡して「60fps基準のmsに換算して仕様と比較して」と指示すれば、テレメトリーなしでも核心の1軸（ヒットタイミング）は検証できます。5種の同期までは難しいですが、「入力→反応」の1軸を押さえるだけでも、手触りの議論の半分は客観へ移ってきます。

次章は、1回のヒットからヒットの連続へ進みます。コンボ・キャンセル・入力キュー — 1つのヒットが次のヒットへ自然につながるようにするルールを扱います。

本章のポイント

• 手触りはヒットタイミング・ヒットストップ・エフェクト同期という3軸の合計であり、1軸だけいじると残りが揺らぎます。
• 映像分析よりゲーム内テレメトリーログのほうが正確で安上がりです — 自分たちのビルドにはテレメトリーから敷きます。
• AIは仕様との突き合わせでFAILを捕まえ、人間は問い返しを拒否し、原因をコードで確定します。

次章のプレビュー

• 4.3. コンボ・キャンセル・入力キュー

4.3 コンボ・キャンセル・入力キュー — 経路を列挙して検証する

バトルプランナーのチームメンバーBが、会議室のホワイトボードの前に立ってマーカーでボックスを描いていました。基本1、基本2、基本3、そして横へ抜ける強攻撃の分岐。矢印が7本ほどに増えたところで、誰かが尋ねました。「じゃあ、強攻撃の打ち上げの後に回避でキャンセルしたら、また基本1に戻れるんですか？」チームメンバーBはマーカーを止めました。ホワイトボード上のグラフには、その経路は描かれていませんでした。描けるのに描かなかったのか、ルール上不可能なのか、本人も即答できませんでした。

これがコンボ設計の本当の問題です。コンボは頭の中では「1-2-3とつながって強攻撃に分岐」のような単純な幹に見えます。ところがキャンセルと入力キューが絡むと、幹はグラフになります。ノード6個にキャンセルエッジを数本足しただけで、実際に踏める経路は数十通りに膨れ上がります。人間はその数十通りを頭の中ですべて展開できません。だから「この経路が強すぎる」というバランス事故は、ビルドに入った後になって初めて発見されるのです。

この章の目標は1つです。コンボ経路を手で描かずに自動ですべて列挙し、各経路を検証するワークフローを作ること。自然言語で書いたルールを仕様に変換し、仕様から経路を列挙し、列挙した経路をシミュレーションにかけます。その過程でAIがどこまでやってくれて、どこで嘘をつくのか、生のままお見せします。

4.3.1 コンボは表ではなくグラフである

コンボを表に書くとこうなります。「基本1の次に基本2、基本2の次に基本3」。行と列で見た目はきれいです。ところがこの表は嘘をつきます。表は直線を前提にしているからです。実際の戦闘では、プレイヤーは基本2から強攻撃へ抜け、強攻撃を回避でキャンセルし、回避の直後にまた基本1を押します。この分岐と循環は、表の行の間に隠れてしまいます。

だからコンボの本当の形は有向グラフです。アクションはノード、つながりはエッジ。各エッジには入力ウィンドウ（いつ入力を受け付けるか）と入力キーが付きます。ノードには持続フレームが、一部のノードにはボーナス条件（特定のノードを経由するとダメージ倍率が付く）が付きます。

戦士キャラクターの基本コンボ1セットをグラフに描くと、次のようになります。ノード6個、キャンセル分岐を含みます。

ホワイトボードと決定的に違う点が2つあります。第一に、各エッジに入力ウィンドウのフレーム範囲が明示されていることです。「強攻撃 6〜24f」は、基本2が始まってから6フレーム目から24フレーム目まで強攻撃の入力を受け付けるという意味です。第二に、点線で描いた回避→基本1の再進入エッジがあることです。チームメンバーBが会議室で即答できなかった、まさにあの経路です。グラフとして明示すれば、「ある/ない」がはっきりします。

このグラフを人が手で描くなら、ノード6個にエッジ7〜8本です。キャラクターが20人いて、キャラクターごとにコンボセットが3〜4個あれば、グラフは数百枚になります。手では追い切れません。だからグラフをテキスト仕様として書いておき、図と検証はそこから自動生成するのです。

4.3.2 仕様は人が読み、機械がパースする

上のグラフをYAML仕様に書き写します。核心はノード（nodes）、エッジ（edges）、ボーナス（bonuses）の3ブロックです。キャンセルルールもエッジの一種と見なします — 動作を断ち切って別のノードへ移るのも、結局はエッジだからです。

# warrior_basic_chain.yaml
character: warrior
combo_id: basic_chain

nodes:
  - { id: basic_1,  name: 基本1,   duration_frames: 21 }
  - { id: basic_2,  name: 基本2,   duration_frames: 24 }
  - { id: basic_3,  name: 基本3,   duration_frames: 30 }
  - { id: heavy,    name: 強攻撃,  duration_frames: 33 }
  - { id: launch,   name: 打ち上げ,  duration_frames: 28 }
  - { id: dodge,    name: 回避,    duration_frames: 18, cancels_recovery: true }

edges:
  - { from: basic_1, to: basic_2, input: light, window: [10, 21] }
  - { from: basic_2, to: basic_3, input: light, window: [12, 24] }
  - { from: basic_2, to: heavy,   input: heavy, window: [6, 24] }
  - { from: heavy,   to: launch,  input: heavy, window: [10, 33] }
  - { from: heavy,   to: dodge,   input: dodge, window: [0, 33], type: cancel }
  - { from: basic_3, to: dodge,   input: dodge, window: [0, 30], type: cancel }
  - { from: dodge,   to: basic_1, input: light, window: [8, 18] }   # 再進入

bonuses:
  - { on: basic_3, requires_path: [basic_1, basic_2], damage_multiplier: 1.5 }

この仕様は2種類の読者を同時に満足させます。人はwindow: [6, 24]を読んで「強攻撃は基本2の中盤から受け付けるのか」と理解し、機械は同じ行をパースしてグラフの描画と経路の列挙に使います。1つのソースから、人の理解と機械の検証が同時に得られるのです。

上のフレーム数値（21、24、[6, 24]）は実測値ではなく、この章の説明のために著者が構成した例示値（未検証）です。実際のプロジェクトでは、これらの値はアニメーターが作ったモンタージュの長さと、ビルドのノーティファイのタイミングから得られます。仕様を最初に書く時点ではプランナーの意図値を入れ、ビルドが出た後にキャプチャして実測値に補正します — この補正ループは4.4で扱います。

4.3.3 ワークド・トランスクリプト — 自然言語から仕様まで

チームメンバーBがホワイトボードに描いたルールを自然言語で渡し、仕様YAMLに変換させます。要約はせず、プロンプト全文とClaudeの生の出力、人による検証/拒否をそのまま掲載します。

プロンプト（全文）

次は戦士キャラクターのコンボルールだ。これをコンボ仕様YAMLに変換しろ。

ルール:
- 基本攻撃は1、2、3段とつながる。軽攻撃キー。
- 基本2の途中で強攻撃キーを押すと強攻撃へ抜けられる。
- 強攻撃の次に強攻撃をもう一度押すと敵を打ち上げる(打ち上げ)。
- 強攻撃はいつでも回避でキャンセル可能。
- 基本3も回避でキャンセル可能。
- 回避の直後には軽攻撃で基本1を再び始められる。
- 基本3は基本1と基本2を両方経由したときだけダメージが1.5倍。

仕様形式:
- nodes(id, name, duration_frames), edges(from, to, input, window, type),
  bonuses(on, requires_path, damage_multiplier)
- キャンセルエッジはtype: cancelで表示。
- フレーム値は、私が与えていないものはお前が決めずTODOのまま空けておけ。

最後の行が核心です。フレームを与えていないなら、でっち上げるなと明示しています。v3標準の3番（数値の正直さ）をプロンプトのレベルで強制しているのです。

Claudeの生の出力（編集なし）

仕様に変換しました。フレーム値は提供されていないためTODOのまま残しました。

```yaml
character: warrior
combo_id: basic_chain
nodes:
  - { id: basic_1, name: 基本1, duration_frames: TODO }
  - { id: basic_2, name: 基本2, duration_frames: TODO }
  - { id: basic_3, name: 基本3, duration_frames: TODO }
  - { id: heavy,   name: 強攻撃, duration_frames: TODO }
  - { id: launch,  name: 打ち上げ, duration_frames: TODO }
  - { id: dodge,   name: 回避,   duration_frames: TODO }
edges:
  - { from: basic_1, to: basic_2, input: light, window: TODO }
  - { from: basic_2, to: basic_3, input: light, window: TODO }
  - { from: basic_2, to: heavy,   input: heavy, window: TODO }
  - { from: heavy,   to: launch,  input: heavy, window: TODO }
  - { from: heavy,   to: dodge,   input: dodge, window: TODO, type: cancel }
  - { from: basic_3, to: dodge,   input: dodge, window: TODO, type: cancel }
  - { from: dodge,   to: basic_1, input: light, window: TODO }
bonuses:
  - { on: basic_3, requires_path: [basic_1, basic_2], damage_multiplier: 1.5 }
```

確認が必要な部分:
1. 「回避直後の基本1再開」をdodge -> basic_1エッジとして入れましたが、これが
   回避の硬直中に入力を受け付けるのか、回避が完全に終わった後なのか不明確です。
2. 打ち上げ(launch)の次に続く空中コンボがあるかどうかルールにありません。
   打ち上げがコンボの終端かどうか確認が必要です。
3. 回避をノードとして置くか、エッジ(キャンセル動作)としてだけ置くか曖昧です。ひとまず
   ノードとして置きました — 回避自体が持続時間を持つアクションだと見なしました。

ここで評価してみましょう。まず良い点です。フレームをでっち上げず、すべてTODOのまま空けました。プロンプトの制約を守っています。そして最後に付けた3つの質問は、どれも本当に曖昧な箇所を突いています — とくに1番（再進入の入力タイミング）は、チームメンバーBが会議室で即答できなかった、まさにあの穴です。AIが人より先に穴を見つけたのです。

一方、曖昧な点もあります。3番で回避をノードにしたのは判断が分かれるところです。回避は「キャンセル動作」であると同時に「持続時間を持つアクション」でもあるので、どちらの扱いも正しいのです。AIが片方を選んだうえで「曖昧だ」と報告したのは正直ですが、これは設計上の決定なので、人が決めてあげる必要があります。

人による検証/拒否

3つの質問に答え、一部を拒否します。

• 1番（再進入タイミング）： 回避の硬直（後隙）中（8〜18f）に入力を受け付けます。回避を最後まで見せた後ではなく、硬直キャンセルで基本1に再進入します。→ 採用、window: [8, 18]。
• 2番（打ち上げ以降）： この章の範囲では、打ち上げをコンボの終端とします。空中コンボは別セットに分離します。→ AIの判断を採用。
• 3番（回避=ノード）： ノードとして扱います。ただしcancels_recovery: true属性を追加して、「硬直を断ち切る動作」であることを明示します。→ 部分採用+属性追加。

そして1つを拒否します。AIはdodge → basic_1エッジにtype: cancelを付けませんでしたが、これは回避の硬直を断ち切って進入するものなので、性質としてはキャンセルに当たります。しかしここでは「回避後の通常進入」と見なして、一般エッジのままにします — 硬直キャンセルと通常接続の区別は、このキャラクターではゲームの手触り上の差がないからです。人がドメイン判断でAIの分類を上書きした事例です。

再リクエスト

良い。次を反映して最終仕様を出し直せ:
- dodgeにcancels_recovery: trueを追加。
- dodge -> basic_1エッジのwindowは[8, 18]。
- 残りのフレームは依然として私が与えていないのでTODO維持。ただし上のグラフ例示値
  (basic_1=21, basic_2=24, basic_3=30, heavy=33, launch=28, dodge=18)を
  使うから、その値で埋めろ。これは未検証の例示値だとコメントで明記しろ。

この再リクエストで得られた結果が、4.3.2のYAMLです。一度では完成しませんでした。プロンプト → 生の出力 → 検証/拒否 → 再リクエスト。このサイクルが仕様の信頼度を作ります。AIが曖昧な箇所に印を付け、人がドメイン知識で決定する — どちらか一方だけでは成り立ちません。

4.3.4 経路を自動で列挙する

仕様がグラフなのですから、コンボ経路の列挙はグラフ探索の問題になります。開始ノードから出発して、終端ノード（またはフィニッシャー）まで到達するすべての経路を探す深さ優先探索（DFS）です。人はこれを頭の中ではできませんが、コードは一瞬でやってのけます。

著者のチームの隔離作業スペース95_BattleTFの中には、この列挙を担当する小さなスクリプトがあります。仕様YAMLを読み込んですべての経路を抽出し、各経路がルール上可能か（エッジが存在するか）を検証します。核心のロジックだけを示すと、次のとおりです。

# 95_BattleTF/enumerate_paths.py (抜粋)
import yaml

def load_graph(path):
    spec = yaml.safe_load(open(path, encoding="utf-8"))
    adj = {}
    for e in spec["edges"]:
        adj.setdefault(e["from"], []).append(e)
    return spec, adj

def enumerate_paths(adj, start, max_depth=8):
    results = []
    def dfs(node, path, edges):
        # 終端ノード(出るエッジなし)か深さの上限なら経路を確定
        outs = adj.get(node, [])
        if not outs or len(path) >= max_depth:
            results.append((list(path), list(edges)))
            return
        for e in outs:
            if e["to"] in path:        # 循環防止: 1経路に同じノードは1回
                results.append((list(path), list(edges)))
                continue
            dfs(e["to"], path + [e["to"]], edges + [e])
    dfs(start, [start], [])
    return results

basic_1から始めて回すと、手では到底展開しきれない経路があふれ出てきます。一部だけ見ると、次のとおりです。

3番と4番が重要です。回避の再進入エッジのせいで、コンボが循環します。人がホワイトボードで見落としていたのが、まさにこうした循環経路です。DFSに循環防止（同じノードは1経路につき1回）のガードを入れないと、列挙が無限ループに陥ります — これはコードを最初に回したとき、実際に一度止まってしまって気づいた罠です。グラフに循環があるなら、列挙器には必ずガードが必要です。

列挙段階の成果物は2つです。第一に、ルール上可能なすべての経路のリスト。第二に、ルール矛盾の検出です — 仕様にdodge → basic_1エッジがあるのに、肝心のdodgeノードの定義が抜けていれば、列挙器が「未定義のノードを指すエッジ」として捕まえます。仕様を手で書くときに最もよくあるミスが、このダングリング参照です。

4.3.5 列挙した経路をシミュレーションにかける

経路のリストだけでは、「どの経路が強すぎるのか」は分かりません。各経路をDPSシミュレーターに入れる必要があります。著者のチームのsimulate_dpsがこの役割を担います — 経路（ノードのシーケンス）と各ノードのダメージ・フレーム、ボーナスルールを受け取り、総ダメージと総所要フレームを計算して、秒間ダメージ（DPS）を出します。

# 95_BattleTF/simulate_dps.py (抜粋、60fps想定)
def simulate(path_nodes, node_dmg, node_frames, bonuses):
    total_dmg = 0
    total_frames = 0
    visited = []
    for nid in path_nodes:
        dmg = node_dmg.get(nid, 0)
        # ボーナス: requires_pathを全て経由したら倍率を適用
        for b in bonuses:
            if b["on"] == nid and all(r in visited for r in b["requires_path"]):
                dmg *= b["damage_multiplier"]
        total_dmg += dmg
        total_frames += node_frames[nid]
        visited.append(nid)
    seconds = total_frames / 60.0
    return {"dmg": total_dmg, "frames": total_frames,
            "dps": round(total_dmg / seconds, 1) if seconds else 0}

4.3.4の列挙結果をここへ丸ごと流し込むと、各経路のDPSが表になって出てきます。以下は、ノードのダメージに例示値（基本打撃100、強攻撃180、打ち上げ140 — いずれも未検証の架空値）を入れて回した結果です。

この表が議論を変えます。「強攻撃の分岐のほうが正規の3段より強く見えないか？」という直感が、「強攻撃経路のDPSは294、正規の3段は280で、5%の優位」という数字に変わります。5%の優位が意図したものなら通過、そうでなければ強攻撃のフレームを伸ばしてDPSを下げます。ビルドが出る前に、仕様の段階でこの判断を行うのです。

ワークフロー全体を1枚で見ると、こうなります。

flowchart LR
    A["自然言語のルール
(teammate_b ホワイトボード)"] --> B["プロンプト → AI"]
    B --> C{"生の仕様
TODO・質問を含む"}
    C -->|人による検証/拒否| D["確定仕様YAML
warrior_basic_chain.yaml"]
    D --> E["enumerate_paths.py
全経路をDFSで列挙"]
    E --> F["ルール矛盾の検出
ダングリングエッジ・無限循環"]
    E --> G["simulate_dps.py
経路別のDPS計算"]
    G --> H["バランス判断
経路間のDPS格差"]
    F --> D
    H -->|フレーム調整| D

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class E,F,G code;
    class B,C ai;
    class H human;
    class A,D data;

仕様（D）が中心にあり、列挙（E）・検証（F）・シミュレーション（G）がそこから枝分かれします。矛盾が見つかったり、バランスがずれていたりすれば、仕様に戻って直します。ホワイトボードにはこのループがありませんでした — だからホワイトボードのコンボは、ビルドに入った後になって初めて間違いに気づいたのです。

4.3.6 キャンセルと入力キュー — 経路を増やすつまみと狭めるつまみ

ここまで、コンボグラフと経路の列挙を見てきました。キャンセルと入力キューは、このグラフを調整する2つのつまみです。向きは正反対です。

キャンセルはエッジを増やします。キャンセルルールを1つ追加するたびにグラフにエッジが増え、列挙される経路の数は掛け算で膨らみます。だからキャンセルは「寛容なほど良い」わけではありません。キャンセルを緩めるほど経路が爆発的に増え、その中に意図しない強い経路（前節の循環経路のような）が紛れ込む確率が上がります。格闘ゲームの伝統がキャンセルを厳格に保つ理由、アクションRPGが寛容にする理由がここにあります — ジャンルが「許容する経路数」を決めるのです。絶対的な正解のウィンドウ値はありません。

キャンセルを扱うときは、必ず分離して明示します。ひとまとめの「何でもキャンセル」にすると、列挙器がすべてのノード間にキャンセルエッジを作り、経路が制御不能に膨らみます。

入力キューは経路を狭めるのではなく、実際に踏めるようにします。キューがなければ、プレイヤーは各エッジの入力ウィンドウ（たとえば[12, 24]）をフレーム単位で正確に合わせなければなりません。人間の反応速度ではほぼ不可能です。キューはウィンドウが開く前に押された入力をバッファーに保存しておき、ウィンドウが開いた瞬間に自動で発動させます — いわゆる先行入力の仕組みです。つまりキューはグラフの経路を変えるのではなく、グラフの上を人が歩けるように靴を履かせてくれるのです。

input_queue:
  window_start_ratio: 0.5   # アクション進行率50%から次の入力をバッファリング
  expire_frames: 10         # バッファされた入力の有効期間
  priority: latest          # 同時多重入力時は最後を優先

3つのパラメーターのバランスが核心です。window_start_ratioが小さすぎると、アクション序盤の入力までバッファリングされて、意図しない次の動作が飛び出します。expire_framesが短すぎるとキューの意味がなくなって再び正確さを要求することになり、長すぎるとずっと前に押した入力が遅れて発動し、「なぜ急に動いたんだ」という事故が起きます。推奨の出発値はexpire_framesが5〜15、window_start_ratioが0.5前後ですが — これはジャンルとキャラクターの重量感に応じて調整する出発点であって、正解ではありません。

運用上の注意を1つ。入力キューのパラメーターをキャラクターごとに全部変えてはいけません。グローバルな既定値を1つ置き、重量感が特別に異なるキャラクター（巨大ボス型など）だけoverrideします。キャラクター20人のキュー値を別々に管理すると、どれが意図した差でどれがミスなのか、区別がつかなくなります。

最後にもう1つ押さえておくことがあります。ここまでエッジを「ある/ない」だけで扱ってきましたが、エッジがあるとしても、そのノードから次のノードへ実際にどう移るかはまた別の決定です。コンボ間の接続方式には核心の分岐が3つあり、本書の深さの範囲外なのでコードでは扱いませんが、触れずにおくと仕様が半分しか描けていないことになります。

• キャンセルノーティファイ（cancel notify）： どの時点から現在のアニメーションを断ち切って、次の入力を受け付けるか。上のエッジのウィンドウ（window: [10, 21]）が、まさにこのノーティファイの表現です。ノーティファイを前倒しするとコンボは速くなり（打撃が終わる前に次へ）、遅らせると一撃一撃が重くなります。つまりウィンドウの開始値は単なる数字ではなく、「この打撃を最後まで見せるのか、次へ素早くつなぐのか」という感覚の決定なのです。
• アニメーションブレンディング（anim blending）： 2つのノードの間を滑らかに混ぜてつなぎます。強攻撃の終わりの姿勢から打ち上げの開始姿勢へ、数フレームかけて補間します。接続は滑らかで自然ですが、ブレンディング区間には攻撃判定の空白が生まれやすく、「断ち切れるキレ」が消えます。
• フレームスキップ（frame skip）： ブレンディングなしで現在のアニメーションの残りフレームを飛ばし、次のノードを即座に始めます。接続は小気味よく反応も速いですが、姿勢がカクカクと途切れて見えることがあります。格闘・アクションゲームの「キャンセルの感触」は、おおむねこちらです。

この3つは、同じエッジを巡ってもゲームの手触りを正反対にします。仕様の段階ではエッジの存在とウィンドウだけを決め、接続方式（ブレンディングかフレームスキップか）はビルドの段階でアニメーターと一緒に決めるのが普通です。ただし仕様にtransition: blend / transition: skipのようなフィールドを1行だけ先に空けておけば、ビルド段階で「このエッジはどう移ると決めたんだっけ」と聞き直さずに済みます。接続方式は、コンボグラフの隠れた第3の軸です。

4.3.7 ビルド検証は別の仕事である（4.4の予告）

ここまでのすべての検証は、仕様の上で行われました。経路の列挙もDPSシミュレーションも矛盾の検出も、すべてYAMLを対象にしていました。ところが仕様のフレーム値はプランナーの意図値であって、ビルドの実測値ではありません。アニメーターが作ったモンタージュの実際の長さ、ビルドのノーティファイが実際に発火するフレーム、入力キューがエンジン上で実際に機能するウィンドウ — これらはビルドをキャプチャして測定しなければなりません。

ビルド映像から5つの信号（打撃の発生フレーム、硬直（後隙）、キャンセルウィンドウ、入力キュー、ヒットストップ）を自動抽出するのは実装難度が高く、現実的に最も信頼できるのはゲーム内テレメトリーです — ビルドの中に「このアクションがこのフレームでこの入力を受け付けた」というログを出させ、そのログを仕様と突き合わせます（キャプチャ方法の比較は4.4参照）。この突き合わせのループが4.4のテーマです。仕様上[12, 24]だったウィンドウがビルドで[14, 26]と測定されたら、仕様をビルドの実測値で補正するのです。

4.3.8 よくあるミスと回避策

本章のポイント

• コンボは直線ではなくグラフなので、経路は人ではなくコードで列挙します。
• キャンセルは経路を増やすつまみ、入力キューは経路を歩けるようにする靴です。
• 同じエッジでも、接続方式（キャンセルノーティファイ・アニメーションブレンディング・フレームスキップ）が手触りを正反対にします。
• 仕様の上の検証とビルドの上の検証は別の仕事であり、後者はテレメトリーが現実的です。

やってみよう — コンボ経路列挙のミニパイプライン

手を動かしてそのまま回せる、最小限の手順です。Pythonとpyyamlさえあれば大丈夫です。

setup. 作業フォルダーを1つ作り、その中に仕様ファイルとスクリプト2つを置いてください。

combo-mini/
  warrior_basic_chain.yaml   # 4.3.2の仕様
  enumerate_paths.py         # 4.3.4のDFS列挙器
  simulate_dps.py            # 4.3.5のシミュレーター

pip install pyyamlの後、仕様ファイルには4.3.2のYAMLをそのまま貼り付けてください。

prompt. 自然言語のルールを仕様に変換する段階は、AIに任せましょう。4.3.3のプロンプトをそのまま使い、最後の制約を必ず含めてください。

フレーム値は、私が与えていないものはお前が決めずTODOのまま空けておけ。
キャンセルエッジはtype: cancelで表示し、曖昧な部分は質問として別に出せ。

この2行が、AIによる数値の捏造と恣意的な判断を防ぎます。出てきた仕様のTODOと質問リストは、人が埋めます。

verify. 仕様が完成したら、2回検証してみましょう。

python enumerate_paths.py warrior_basic_chain.yaml   # 全経路 + 矛盾の出力
python simulate_dps.py    warrior_basic_chain.yaml   # 経路別のDPS表

列挙の出力では、（1）循環経路が無限に増えていないか、（2）未定義のノードを指すダングリングエッジがないかを確認してください。DPSの出力では、経路間の格差が意図した範囲内かを見てください。格差が大きければ、仕様のフレーム/ダメージを直してもう一度回してください。

一人ミニ版

ツールを別に作る時間がなければ、仕様の作成と経路の列挙を1回のAI対話で済ませましょう。自然言語のルールを渡し、「コンボ仕様YAMLに変換した後、開始ノードから可能なすべての経路を深さ優先で全部列挙し、循環は1回だけ回って打ち切ること。未定義のノードを指すエッジがあれば指摘すること」と、1つのプロンプトに詰め込んでください。AIが仕様化・列挙・矛盾検出を一度にやってくれます。DPSシミュレーションは、ノードのダメージを表で一緒に渡し、「各経路の総ダメージとフレームを計算して表にしてほしい」という後続リクエストで受け取ってください。精度は落ちますが、ホワイトボードよりはずっと遠くまで見通せます。核心は変わりません — コンボは頭の中で展開せず、列挙させて見るのです。

4.4 AI支援による戦闘シミュレーション・検証

戦闘TF（タスクフォース）のビルド#234が上がってきたばかりです。新スキルskill_thunderに初めて触れるビルドです。仕様書にはヒットタイミング150msと書いてあります。入力を入れます。指先の感覚が言います。遅い。間違いなく遅い。隣の席のチームメンバーAを呼びます。「これ、ちょっと浮いて見えませんか？」チームメンバーAが二、三回打ってみます。「うーん……そんな気もしますね。」二人とも確信が持てません。仕様は150だと言うのに、指は200くらいだと言い張ります。どちらが正しいのか。指先と紙の戦いです。次のビルドでもまた誰かが「体感では大丈夫そうですけど」と言い、その一言でビルドが一つ、また流れていきます。

この章の目標は、その戦いを終わらせることです。指先が200だと言うなら、本当に200なのかを数字で見せること。そしてビルドが上がってくる前に、仕様だけを見て「このスキルはDPSが目標より30%高い」を先に知ること。200人が関わるAAA MMORPGの戦闘を初期から固めていた時代も、感覚と数字がずれたときの途方もなさは同じでした。変わったのは、いまはそのずれを数字で決着させる道具が手元にあるということだけです。

4.2・4.3が戦闘の仕様をどう書くかを扱ったとすれば、4.4はその仕様が意図どおりに動くかを扱います。検証には二つの軸があります。一つはビルドなしで計算だけで検証するシミュレーション、もう一つは実際のビルドから測定値を取り出すキャプチャー分析です。二つの軸が一つのサイクルに束ねられると、戦闘企画の検証の往復が日単位から時間単位へ縮みます。

結論を先に明かすと、この章の核心は、仕様に書かれた数字（150ms）とビルドで測定した数字（220ms）を並べて、その差を読むことです（4.4.5）。前半の節（シミュレーター・コンボ列挙）は、その対照を可能にするための準備段階として読んでください。

4.4.1 ビルドを待つコスト

戦闘プランナーが新スキル一つを検証しようとすると、何が起きるでしょうか。

プランナーが仕様を書きます。プログラマーがデータを入れ、アーティストがモーション・エフェクトを付け、ビルドが回り、QAが一巡し、そこでようやくプランナーが手で触って確かめます。早くて2日、普通は3〜4日。サイクルの最後で「DPSが高すぎる」が見つかると、その発見は最初へ戻れという命令になります。3〜4日がもう一回。

シミュレーションは、このサイクルの最初の段階で答えをくれる道具です。仕様だけで計算してみます。答えが悪ければ仕様を直して再計算。ビルドという高価な段階に入る前に、仕様そのものが一度ふるいにかけられます。模型の車をまず風洞に入れてみるのと同じです。本物の車を道路に出す前に、疑わしい設計は机の上で脱落します。

もちろん、風洞が道路を100%予測するわけではありません。だから二つ目の軸であるキャプチャー分析が必要です。シミュレーションが理想的な答えだとすれば、キャプチャーは実際にビルドで起きた答えです。二つを並べて差を読むこと — それがこの章のすべてです。

4.4.2 simulate_dps — 実行可能なシミュレーター

抽象的な擬似コードでは何も検証されません。だから最初から動くコードを作ります。以下は、著者が戦闘TFで使っているsimulate_dps.pyの核心の骨格を、会社のデータを取り除いて本書に載せるために再構成したものです。依存関係なし、Python標準ライブラリだけで動きます（ファイル全体は「やってみよう」を参照してください）。

入力は単純です。スキル一つはdamage・cast_sec（詠唱占有時間）・cooldown_sec・resource_costを、キャラクターはリソース総量・秒間回復量・スキルリスト・優先順位ローテーションを持つdataclassです。その上で回る本体は、「その時点で使えるスキルのうち優先順位が最も高いものを使う」という単純な貪欲法（greedy）のルールだけです。実際のプレイヤーより賢くも愚かでもない、理想的上限を取るのが目的です。背骨になる部分だけを抜粋するとこうなります。

# 0.05秒ティックでタイムラインを作る。詠唱中でなければ優先順位順に最初の使用可能スキルを使う。
while t < duration_sec:
    resource = min(char.max_resource, resource + char.resource_regen * tick)
    for name in cooldowns:
        cooldowns[name] = max(0.0, cooldowns[name] - tick)
    if t >= busy_until:                     # 詠唱モーションが終わっていなければ待機
        for name in char.rotation:          # 優先順位順
            s = skill_by_name[name]
            if cooldowns[name] <= 0 and resource >= s.resource_cost:
                total_damage += s.damage
                resource -= s.resource_cost
                cooldowns[name] = s.cooldown_sec
                busy_until = t + s.cast_sec  # この時刻まで次のスキル不可
                break
    t += tick
# …(dataclass定義・warrior入力・出力ループは「やってみよう」の全体コード参照)

warriorにskill_thunder（ダメージ420・詠唱0.9s・クールタイム（クールダウン）6s）を第1優先に、skill_dash・basic_1を後ろに置いて20秒回した結果です（python simulate_dps.py）。

平均DPS: 261.0
  t=  0.0s  skill_thunder  リソース=60
  t=  0.9s  skill_dash     リソース=47
  t=  1.3s  basic_1        リソース=50
  t=  1.6s  basic_1        リソース=53
  t=  1.9s  basic_1        リソース=55
  ...

この値に何の意味があるのか。ビルドなしで、1秒以内に、warriorの理想的なDPS上限が約261だという事実が分かる、ということです。目標DPSが180だったなら、この仕様は+45%で過剰です。ビルドを待つ必要はなく、いまdamageやcooldown_secをいじればいいのです。

限界も正直に書いておきます。このシミュレーターは、プレイヤーの入力ミス、移動・回避による空白、敵の妨害を反映しません。そのため測定値は常に実際のビルドより高く出ます。これはバグではなく、上限というシミュレーターの定義そのものです。実測との差は、4.4.5でキャプチャーによって埋めます。

AI活用ノート。 上の骨格は著者が組んだものですが、新しいリソースモデル（例：怒りゲージがダメージを受けると溜まる構造）を付けるときは、Claudeに「このsimulate_dpsに被弾時怒り+5のルールを追加して。tickループの中で、既存のリソース回復とは別の変数で」のように、既存コードを引用しながら依頼します。白紙からシミュレーターを丸ごと生成させると、検証不可能なコードが出てきます。背骨は人が握り、AIには枝を伸ばさせます。

4.4.3 コンボ経路の自動列挙

DPSという数字一つでは足りません。「どのコンボが意図されたメインコンボなのか」を検証するには、可能なすべての経路を広げて見る必要があります。手でツリーを描くと、ノード7〜8個ですでに頭がパンクします。経路を漏れなく広げるのは、機械の方が人より圧倒的に得意です — ただし、人が結果をたどり直せる形で出力させる必要があります。

次は、コンボグラフを受け取ってすべての経路を列挙し、DPSでソートするコードです。combo_graphは「どのアクションの次にどのアクションへキャンセルできるか」を隣接リストで書いたもので、4.3のステートマシン仕様からそのまま抽出されます。核心は、行き止まりまで再帰で展開するall_pathsジェネレーターです。

# enumerate_combos.py — コンボグラフのすべての経路を展開しDPSでソート
combo_graph = {"start": ["A"], "A": ["B", "D"], "B": ["C", "E"], "D": ["C"], "C": [], "E": []}
action_stats = {  # (ダメージ, 所要時間 秒)
    "A": (300, 0.8), "B": (450, 1.0), "C": (450, 1.2), "D": (600, 1.4), "E": (200, 0.6),
}

def all_paths(node="start", path=None):
    path = (path or [])
    nexts = combo_graph.get(node, [])
    if not nexts:                       # 行き止まり = 完成したコンボ
        yield [n for n in path if n in action_stats]
        return
    for nxt in nexts:
        yield from all_paths(nxt, path + [nxt])

results = []
for p in all_paths():
    dmg = sum(action_stats[a][0] for a in p)
    dur = sum(action_stats[a][1] for a in p)
    results.append((p, dmg, round(dur, 1), round(dmg / dur, 1)))

for p, dmg, dur, dps in sorted(results, key=lambda r: -r[3]):
    print(f"{' → '.join(p):<18} {dmg:>5} dmg  {dur:>4}s  DPS {dps}")

実行結果です。

A → D → C            1350    3.4s  DPS 397.1
A → B → C            1200    3.0s  DPS 400.0
A → B → E             950    2.4s  DPS 395.8

ここでプランナーが読み取るべきシグナルは、単純な1位ではありません。三つの経路のDPSが396〜400でほぼ張り付いていること — これは「どのコンボを使っても効率が似ていて、メインコンボのアイデンティティがない」というシグナルです。意図が「A→D→Cがハイリスク・ハイリターンのメインであるべき」だったなら、Dのダメージを上げるか所要時間を縮めて、DPSを一段浮かせる必要があります。仕様に戻る番です。

この自動列挙が手計算を置き換える場面では、コンボノードが20個に増えても、人はソート済みの表を読むだけで済みます。

4.4.4 ビルドキャプチャー分析 — 現実的な方法はテレメトリー

いよいよ二つ目の軸です。ビルドの中で実際に何が起きたかを測定する段階です。よく「ビルド映像をAIが見て自動分析」を思い浮かべますが、ここでは正直に分岐を分けます。測定値を得る道は三つあり、三つのコスト・正確度は大きく異なります。

A案（映像のピクセル分析）は魅力的に聞こえます。入力表示、キャラクターのモーション変化、エフェクトの最初のフレーム、サウンド波形、ダメージ数字UI — 五つのシグナルを画面から自動抽出するという絵です。しかし実際に作ってみると、フレーム圧縮ノイズ、UIの遮り、モーションブラーのせいで±1〜2フレームの誤差が基本として乗ります。60fpsでは1フレームが約16.7msです。ヒットタイミングをms単位で問う検証で、±33msのノイズは致命的です。実装難易度は非常に高く、正確度はその努力に見合いません。

だから現実の答えはC案、ゲーム内テレメトリー（telemetry）ログです。エンジンは、入力の時刻、アニメーション通知（ノーティファイ）の発生時刻、VFXスポーンの時刻、ダメージ適用の時刻を、すでに内部で正確に知っています。その時刻をピクセルから推論するのではなく、1行のログとして記録させればいいのです。ピクセルから100msを復元する代わりに、エンジンが知っている100msをそのまま書き取ります。

// 戦闘アクション処理コードに1行追加 (UE C++ 疑似例)
// 入力受信 / ダメージ適用の時点で同じロガーを呼び出す
CombatTelemetry::Log("input",  SkillName, GetWorld()->GetTimeSeconds());
CombatTelemetry::Log("hit",    SkillName, GetWorld()->GetTimeSeconds());

ロガーは1行ずつJSON Linesで吐き出します。

{"event":"input","skill":"skill_thunder","t":12.340}
{"event":"hit",  "skill":"skill_thunder","t":12.560}
{"event":"input","skill":"basic_3","t":14.100}
{"event":"hit",  "skill":"basic_3","t":14.166}

inputとhitの時刻差が、そのまま測定ヒットタイミングです。12.560 − 12.340 = 0.220秒 = 220ms。ピクセル分析の±33msではなく、エンジン時刻そのままの値です。このログを取り出してきて仕様と対照するのが、次の節です。

4.4.5 ワークド・トランスクリプト：仕様150ms vs 測定220ms

いよいよ二つの軸を一か所に集めます。仕様は150msを約束し、テレメトリーは220msを測定しました。+70ms。指先が正しかったのです。この差の原因を絞り込む過程を、AIと一緒に最後まで追いかけます。要約せず、AIが最初に見当違いをする場面までそのまま載せます。

プロンプト

仕様はヒットタイミング150msなのに、測定は220msです。下のログを貼り、人が実際に打ちそうな長さで尋ねます。長々しい形式より、意図が明確な短い依頼の方が優れています — 検証方法まで書かせる一行と、断定禁止の一行が、このプロンプトの背骨です。

skill_thunderのヒットタイミングが仕様150msのところ、測定220msで+70ms超過している。下のテレメトリーから可能な原因を分け、それぞれどのログで確定/排除できるかまで書くこと。断定はせず、確実でなければ「未確認」と表記。 // 「検証方法まで」・「断定禁止」の二つが核心の意図です。残りの形式は省略しても結果は同じです。

{"event":"input","skill":"skill_thunder","t":12.340}
{"event":"anim_start","skill":"skill_thunder","clip":"cast_thunder","t":12.340}
{"event":"anim_notify","skill":"skill_thunder","notify":"HitWindow","t":12.560}
{"event":"hit","skill":"skill_thunder","t":12.560}

仕様上、cast_thunderのHitWindowノーティファイは0.150s地点。

Claudeの生の出力（1回目 — 検証前、見当違い込み）

+70ms超過の原因として、次の四つを推定します。

1. ネットワークレイテンシー。 入力がサーバーを往復する過程で70msが追加された可能性があります。マルチプレイのビルドであればRTTを確認してください。
2. フレームレート低下。 ビルドが30fpsで動いていると1フレームが33msのため、ノーティファイのタイミングがフレーム境界に丸められて遅延が蓄積します。
3. キャストモーションの長さの変更。 cast_thunderクリップが仕様より長くなり、HitWindowノーティファイが後ろへずれた可能性があります。
4. 入力バッファの遅延。 入力キューが1ティック遅れて処理された可能性があります。

最も可能性が高い原因は1番のネットワークレイテンシーです。70msは典型的なRTTの範囲です。

人による検証・拒否

ここで手を止めて、ログを読み直します。AIの第1候補の推定（ネットワーク）は、このログだけですでに排除できます。inputとanim_startが正確に同じ時刻12.340に記録されています。入力が入った瞬間にモーションが即座に始まったということであり、ネットワーク往復が割り込む隙がありません。1番は誤りです。

2番（フレームレート）も弱い推定です。30fpsなら33ms単位のばらつきが見えるはずですが、input→hitは正確に0.220で揃っています。これはフレーム境界の丸めではなく、クリップ内の固定位置の匂いです。

決定的な手がかりは別にあります。anim_notifyの時刻が、anim_start基準で+0.220です。仕様ではHitWindowはクリップ開始から0.150の位置にあるはずなのに、実際のクリップでは0.220の位置に固定されています。つまり、クリップ自体が仕様と違う形で作られたか、ノーティファイの位置が0.150から0.220へ移されたかです。原因はネットワークでもフレームレートでもなく、3番のモーション/ノーティファイのデータです。AIは正解の候補を四つの中に含めてはいましたが、順位を逆に付けていました。

再依頼プロンプト

排除の根拠を人が手で埋めて、もう一度投げます。長く説明する必要はなく、排除したものと残った事実だけを短く釘付けにします。

ネットワーク・フレームレートは排除。（根拠：input=anim_startが同一時刻のため入力→モーションの遅延なし／input→hitが0.220でフレームノイズなく一定。）残った事実：anim_notifyがanim_start +0.220、仕様は+0.150。この事実だけで原因を絞り、プログラマー・アニメーターに何を依頼するかを行動単位で。 // 核心は「行動単位で」 — 推定ではなく、誰に何を依頼するかで終わらせます。

Claudeの生の出力（2回目）

提示された根拠から、原因はアニメーションクリップcast_thunderのHitWindowノーティファイが0.150sではなく0.220sに配置されていることへ絞り込まれます。残る分岐は二つです。

• （ア）ノーティファイは0.150に合っているが、クリップ全体が遅くなった — 再生速度（play rate）が仕様より低いか、クリップ長が伸びていれば、0.150の地点が実時間では0.220に引き伸ばされます。
• （イ）ノーティファイの位置自体が0.220へ移された — クリップ長はそのままで、マーカーだけが移動。

二つの分岐を分ける確認： 1. アニメーターへ：cast_thunderのHitWindowノーティファイのフレーム番号とクリップ総フレーム数、そして仕様作成時点の値と比較した変更履歴を依頼。マーカーが移動していれば（イ）。 2. プログラマーへ：skill_thunderのmontage play rateが1.0か、キャラクターの攻撃速度ステータスがこのクリップに乗算されるかを確認。play rateが0.68（=0.150/0.220）なら（ア）。 3. anim_start→anim_notifyの間隔を、別のキャラクター攻撃速度でもう一度測定。攻撃速度によって間隔が変われば（ア）、不変なら（イ）。

推奨される対応：（イ）と確認されたら、ノーティファイを0.150へ戻すか仕様を0.220へ更新（意図された方に合わせる）。（ア）と確認されたら、play rate適用ロジックを点検。

今回の出力は採用に値します。推定を断定せず（ア）／（イ）の二つの分岐に分け、各分岐をデータで判別する方法と誰に何を依頼するかが行動単位で書かれています。特に3番の確認（攻撃速度を変えて再測定）は、人が見落としやすい決定的な分岐です。このレポートをそのまま会議に持ち込めば、会議は「原因は何だろう」を議論する場ではなく、「（ア）か（イ）かを30分以内に確定して対応を選ぶ」場になります。

このワークド・トランスクリプトが見せている核心は、AIが最初から正解をくれるわけではないという事実です。1回目の出力は、ネットワークを第1候補に挙げる見当違いでした。ログを読んで候補を排除する人の検証が挟まったとき、初めて分析は正解へ収束しました。AIは候補を広く並べ、人が絞り込む。この分業が4.4全体の方法論です。

4.4.6 二つの軸を一つのサイクルへ — 検証ループ

シミュレーション（4.4.2〜4.4.3）とキャプチャー分析（4.4.4〜4.4.5）が別々に回っているだけでは、価値は半分です。一つに束ねられたとき、次のループが生まれます。

flowchart TD
    A["仕様作成
（プランナー、4.2・4.3の様式）"] --> B["シミュレーション
simulate_dps・コンボ列挙
（自動、1秒）"]
    B -->|"DPS・コンボの異常"| A
    B -->|"仕様パス"| C["ビルド
（プログラマー・アーティスト、数日）"]
    C --> D["テレメトリーログ収集
（input・hit・anim_notify）"]
    D --> E["仕様 vs 測定の自動対照
（150ms vs 220msのような差分検出）"]
    E -->|"しきい値超過の項目"| F["AI原因推定レポート
（候補を広げる → 人が絞る）"]
    F --> G["プランナー検討 → 対応決定
（仕様更新 vs ビルド修正）"]
    G --> A
    E -->|"全項目一致"| H["次のスキルへ"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,E code;
    class F ai;
    class A,G human;
    class D data;
    class H pass;

シミュレーションがビルドの前に答えをくれるため、ビルドに入る仕様はすでに一度ふるいにかけられたものです。そのため、ビルド後に発見される問題は「仕様が間違っていた」ではなく「仕様と実装がずれた」へと性格が絞られます。4.4.5の+70msがまさにその後者でした — 仕様の150は合理的で、実装が220へずれていただけです。この区別が、会議から責任の所在をめぐる争いをなくします。

ただし、このループがすべての戦闘コンテンツをカバーするわけではありません。メインボスのシグネチャー演出のように、感触がそのままコンテンツである領域は、DPSの数字には還元されません。シミュレーションは数値ベースのコンテンツに強く、演出は依然として人の目で見る映像チェックが答えです。ループは数値の川を回り、演出の川は別に流れます。

4.4.7 6か月の運用で見えたこと

著者が運用したあるMMORPG（refgame系の操作感を目標にしたプロジェクトA）戦闘TFの、6か月の測定です。以下の数値はTF内部の記録から抜き出した実測値であり、ビルド数・時間はサイクル単位に丸めた値であることを明記しておきます（正確な分単位ではなく、サイクル・半日単位の測定です）。

数字より重要な変化は、会議の性格です。導入前の会議の半分は、「このスキルは強すぎる」対「いや、適切だ」でした。指先と指先の戦いです。導入後、その場は「測定DPSが目標+12%、測定ヒットタイミングが仕様+70ms。モーションを短縮するか、ダメージを10%下げるか」へ移りました。何が問題かを争っていた時間が、どう直すかを決める時間に変わったのです。

この転換のコストも正直に書いておきます。テレメトリーロガーを戦闘コードの全域に仕込む初期作業に約1〜2週間、仕様スキーマをキャラクター・スキルの全部で統一するのに、さらに四半期一つ分かかりました。最初の四半期は、シミュレーションとテレメトリーのどちらか一方だけ動けば十分だと判断していました。二つが一つのループとして噛み合ったのは、二つ目の四半期からです。

4.4.8 よくある失敗と回避策

繰り返されるのは五つです。

第一に、シミュレーション値を絶対的に信頼することです。simulate_dpsの261は上限であって、実測ではありません。テレメトリーと比較しなければ、常に過大評価になります。

第二に、測定をしないことです。仕様だけシミュレーションして、ビルドをテレメトリーで見なければ、4.4.5のような+70msが静かに蓄積します。テレメトリーのロギングはオプションではなく、戦闘コードの基本設備です。

第三に、レポートを会議に持ち込まないことです。自動レポートが上がっていても、会議のアジェンダになければ誰も見ません。「今回のビルドのテレメトリー対照表」をアジェンダの固定項目として入れます。

第四に、AIの推定を検証なしに採用することです。4.4.5で見たとおり、AIの1回目の推定は見当違いでした。AIは候補を広げる道具であって、結論を下す道具ではありません。ログで候補を排除する人の一段階を、決して飛ばさないことです。

第五に、スキルごとに仕様の構造が違うことです。cast_secをあるスキルではcast_time、別のスキルではcastMsと書いていると、シミュレーターも対照スクリプトも毎回壊れます。共通の仕様スキーマ一つを、すべてのスキルに強制します — これが4.4のツール全体が回る前提です。

最初の四半期で五つすべてを押さえる必要はありません。一つ二つ定着するだけでも、サイクルは目に見えて短くなります。残りはループを回しながら自然に埋まっていきます。

4.4.9 第4部を終えて

4.1〜4.4では、戦闘企画の座標・Look & Feel・コンボ・シミュレーションを順に扱ってきました。4.1は戦闘プランナーが何を測定可能な対象として見るか、4.2はヒットタイミング・ヒットストップ・エフェクト同期をどう測定・調整するか、4.3はコンボ・キャンセル・入力キューをステートマシンとしてどう記述するか、そして4.4は、そのすべての仕様が意図どおりに動くかを、ビルドなしで／ビルドの中でどう検証するかを扱いました。

第4部を終えた戦闘プランナーの一週間は、こう変わります。月曜、新スキルの仕様にsimulate_dpsの自動検証が付きます。火曜、コンボ経路の自動列挙でメインコンボのアイデンティティを点検します。水曜、ビルドが上がるとテレメトリー対照表が自動で上がってきます。木曜、データに基づく議論30分。金曜、次サイクルの仕様修正。ビルドサイクルが3〜4回から1〜2回に減り、会議は半分以下に短くなります。打撃感という抽象が、測定可能な220msへ移っていきます。

そして、ビルド#234のあの場面 — 「これ、ちょっと浮いて見えませんか？」という問いに、いまはテレメトリーログが「220msです」と代わりに答えてくれます。指先と紙の戦いは終わりました。

次の第5部はナラティブ企画です。2.3で紹介したNarrativeDocs Layer 0〜4構造の、本格的な適用事例へ進みます。

やってみよう

setup. 1. 以下のsimulate_dps.py全体をそのまま作成してください。依存関係なし、python simulate_dps.pyで即座に実行でき、4.4.2の「평균 DPS: 261.0」（平均DPS: 261.0）が再現されます。

# simulate_dps.py — ビルドなしで仕様だけからDPSを計算する
from dataclasses import dataclass

@dataclass
class Skill:
    name: str
    damage: float          # 1回の打撃ダメージ
    cast_sec: float        # 詠唱(モーション占有)時間 (秒)
    cooldown_sec: float    # 再使用待機時間 (秒)
    resource_cost: float   # リソース消費 (MP/気力)

@dataclass
class Character:
    name: str
    max_resource: float
    resource_regen: float  # 秒間リソース回復
    skills: list           # list[Skill]
    rotation: list         # 優先順位の順序 (スキル名)

def simulate_dps(char: Character, duration_sec: float, tick=0.05):
    cooldowns = {s.name: 0.0 for s in char.skills}   # 残りクールダウン
    skill_by_name = {s.name: s for s in char.skills}
    resource = char.max_resource
    total_damage = 0.0
    busy_until = 0.0          # 詠唱モーションが終わる時刻
    log = []
    t = 0.0
    while t < duration_sec:
        resource = min(char.max_resource, resource + char.resource_regen * tick)
        for name in cooldowns:
            cooldowns[name] = max(0.0, cooldowns[name] - tick)
        if t >= busy_until:   # 詠唱中でなければ次のスキルを選択
            for name in char.rotation:          # 優先順位順
                s = skill_by_name[name]
                if cooldowns[name] <= 0 and resource >= s.resource_cost:
                    total_damage += s.damage
                    resource -= s.resource_cost
                    cooldowns[name] = s.cooldown_sec
                    busy_until = t + s.cast_sec
                    log.append((round(t, 2), name, resource))
                    break
        t += tick
    return total_damage / duration_sec, log

if __name__ == "__main__":
    warrior = Character(
        name="warrior", max_resource=100, resource_regen=8,
        skills=[
            Skill("skill_thunder", damage=420, cast_sec=0.9, cooldown_sec=6, resource_cost=40),
            Skill("skill_dash",    damage=180, cast_sec=0.4, cooldown_sec=3, resource_cost=20),
            Skill("basic_1",       damage=60,  cast_sec=0.3, cooldown_sec=0, resource_cost=0),
        ],
        rotation=["skill_thunder", "skill_dash", "basic_1"],
    )
    dps, log = simulate_dps(warrior, duration_sec=20)
    print(f"平均DPS: {dps:.1f}")
    for t, name, res in log[:8]:
        print(f"  t={t:>5}s  {name:<14} リソース={res:.0f}")

1. 戦闘エンジンのコードの入力受信・ダメージ適用の箇所に、テレメトリーログを1行ずつ追加してください（4.4.4）。エンジン時刻（GetTimeSecondsなど）をそのまま記録するのが核心です。

prompt. ビルドのテレメトリーから仕様とずれた項目を一つ選び、4.4.5の様式でAIに質問してみましょう — ログの抜粋を貼り、「推測を断定せず、原因ごとの検証方法まで。確実でないものは未確認と表記」を必ず含めてください。

verify. AIの1回目の出力をそのまま採用しないでください。ログを直接読んで排除できる候補を手で消したうえで（4.4.5のネットワーク・フレームレート排除のように）、根拠を付けて再依頼してください。最終レポートが「原因推定＋誰に何を依頼するか」の行動単位で終わったら、会議に持ち込みましょう。

一人ミニ版。 テレメトリーロガーの全域設置が負担なら、検証したいスキル一つだけにinput・hitの2行を記録してください。simulate_dpsも、そのスキル一つのDPSだけを見ます。ツール全体を敷こうとせず、最も疑わしいスキル一つでループを一周回してから拡張しましょう。

本章のポイント

• シミュレーションはビルド前に仕様の理想的上限を計算し、日単位の検証を時間単位へ縮めます
• ビルドの測定は映像ではなくテレメトリーログが現実的で、エンジン時刻をそのまま書き取ります
• AIは原因候補を広げる道具であり、ログで候補を絞る検証は人の役割です

第5部 · Narrative Design

5.1 NarrativeDocs Layer 0〜4の構造

会議室に入ると、ホワイトボードにキャラクター名がひとつ、赤い丸で囲まれていました。キム某というNPCでした。あるプランナーのサイドクエストでは、彼は「主人公を幼いころに引き取って育てた養父」であり、別のプランナーのメインクエスト チャプター3では「主人公を裏切って去った昔の仲間」でした。どちらの文書も1か月前に承認され、どちらもビルドに入っていました。ボイス収録の見積もりまで取った状態でした。

誰の落ち度でもありませんでした。どちらのプランナーも世界観の文書を読み、キャラクター設定を参照していました。問題は、同じキャラクターの設定が3つの異なるファイルに散らばっていて、そのうちどれが「本物」なのか誰も断言できなかったことにありました。世界観の文書はひとかたまりの70ページのWordファイルで、検索するとキム某は11か所に登場しました。どの行が決定で、どの行がメモなのか、区別がありませんでした。

その日の会議が終わって決めたのが、NarrativeDocsを五つの層に分割することでした。本章は、その五つの層の話です。

5.1.1 もっとも抽象的な分野から始める理由

分野別のLayer分解をナラティブから先に始めるのには理由があります。

ナラティブはもっとも抽象的です。世界観、感情、トーンといったものは数字に落ちません。アートやシステムのように「スプライト数」「ダメージ係数」といった明確な単位がありません。これほど抽象的な分野がLayerにきれいに分解できるなら、より具体的な他の分野は自然と同じパターンで解けます。難しいところで先に通用するかを試すわけです。

また、ナラティブはインターフェースがもっとも多い分野です。キャラクターはアートと接し、クエストはコンテンツ・レベルと接し、セリフはUX・ローカライズと接し、報酬はシステムと接します。分野の間をもっとも多く横断する場所なので、Layer統合の価値がすぐに表れます。

最後に、自然言語の成果物の比重がもっとも高い分野です。そのため、AIの支援がもっとも大きく効く分野でもあります。ただし、すべてのゲームがナラティブ中心というわけではありません。カジュアル・アーケードのジャンルなら、本章の深さは過剰かもしれません。それでも「ひとかたまりの文書をLayerに分割し、インターフェースを狭くする」という骨格自体は、どの分野にもそのまま持ち込めます。

5.1.2 五段の引き出し

NarrativeDocsを五つの層に分解した形は次のとおりです。ビジョン（L0）が上にあり、ビルド・QA（L4）が下にあって、層の間をつなぐ通路は意図的に狭くしてあります。

フォルダーに落とすと次の形になります。各ファイル名は本書で抽象化した名前ではなく、実際にそのフォルダーに存在するファイル名です。

NarrativeDocs/
├── Layer0_Vision/
│   ├── world_premise.md          (世界観の前提 — 不変)
│   ├── narrative_pillar.md       (感情の柱3つ)
│   └── tone_manifesto.md         (トーン・禁止語彙リスト)
├── Layer1_System/
│   ├── faction_system.md
│   ├── reputation_model.md
│   ├── dialogue_branching_rule.md
│   └── lore_consistency_rule.md
├── Layer2_Content/
│   ├── main_quest/               (チャプター単位)
│   ├── side_quest/
│   ├── character_bible/
│   └── lore_codex/
├── Layer3_Data/
│   ├── quest_table.xlsx
│   ├── npc_table.xlsx
│   ├── dialogue_id_table.xlsx
│   └── reward_table.xlsx
└── Layer4_Build_QA/
    ├── narrative_qa_checklist.md
    ├── voice_review_log.md
    └── localization_status.md

五つの層を一人で抱え込まない、という点が重要です。層ごとに主担当が異なり、隣接する層の間の通路だけを標準化します。上の図の赤い矢印がその通路です。とくにL2とL3の間の通路はわざともっとも狭く（太い赤の矢印で）描いてありますが、その理由は後で見ます。

引き出しのたとえで言えば、五段の引き出しです。1段目には絶対に動かさない世界観の1行、2段目にはルールブック、3段目には本文、4段目にはシート、5段目にはレビューのログ。段の間の通路は狭く、通路の上には変更通知のベルが付いています。

5.1.3 L0 — 変わらないように小さく書く

L0は変わりません。変わるなら、それはゲームのアイデンティティが変わるということです。だから分量が小さくなければなりません。小さいからこそ変わらないのです。

合わせて約4.5枚。これがL0の重さです。重くなると変更が怖くなり、怖くなると他の層がL0を迂回し始めます。迂回が始まると、L0は死んだ文書になります。

narrative_pillar.mdの実際の骨格はこんな形です（内容は抽象化しています）。

---
title: ナラティブ感情の柱
layer: L0
status: locked
last_updated: 2026-05-18
---

## 1. 失ったものへの郷愁
- プレイヤーは毎チャプターの終わりに1つを失う。
- 失ったものは二度と戻らない (回想でのみ)。

## 2. 義務と自由の葛藤
- すべての主要NPCは2つの義務を負う。
- プレイヤーの選択は片方の義務しか生かせない。

## 3. 小さな手助けの重み
- 大きな英雄的行為より、小さな親切のほうが大きな結果を生む。

この3行の柱が、その下の数百ページの方向を決めます。status: lockedは単なるラベルではありません。L4の自動チェックのひとつがこのラベルを読み、lockedの文書がPRで修正されると、リードナラティブの承認なしにはマージがブロックされるように仕掛けてあります。

5.1.4 L1 — コードにもっとも近いナラティブ

L1は変更可能ですが、コストが大きい層です。ルールブックだからです。ルールブックの1行が変わると、そのルールに従うすべてのコンテンツが影響を受けます。

faction_system.mdの骨格は次のとおりです。

---
title: 勢力システム
layer: L1
atoms:
  - faction_relation_matrix
  - faction_membership_rule
  - faction_quest_eligibility
---

## 1. 勢力の概念
N個の勢力。各勢力は (理念、資源、領土) で定義される。

## 2. 勢力間の関係
- relation_matrix.json (-3 敵対 ~ +3 同盟)
- 関係変化トリガー: メインクエストの決定、評判のしきい値

## 3. プレイヤー所属ルール
- 同時所属は最大2つ (敵対関係は同時不可)
- 脱退ペナルティ: 評判 -2、同盟勢力 -1

frontmatterのatoms:リストに注目してください。この3つのatom名は単なるメモではなく、第7部のオントロジーと第11部の関係図が追跡する識別子です。あるクエストがfaction_quest_eligibilityを参照していれば、このルールが変わったときに、そのクエストが影響リストに自動で載ります。L1はゲームコードにもっとも近いナラティブ成果物なので、システムプランナーとペアを組んで作業します。

5.1.5 L2 — もっとも厚い層、本文が住む場所

L2はもっとも厚い層です。メインクエスト、サイドクエスト、キャラクターバイブル、ロア事典がすべてここに住んでいます。先ほど会議室で衝突した「養父vs裏切った仲間」のキム某の本当の設定も、いまはcharacter_bible/内のひとつのファイルとしてだけ存在します。そのファイルが唯一の信頼できる情報源（single source of truth）であり、クエストはそこを参照するだけです。

メインクエストのフォルダーは次の形です。

main_quest/
├── chapter_01_awakening/
│   ├── 00_chapter_overview.md
│   ├── 01_quest_a_call_to_arms.md
│   ├── 02_quest_b_first_choice.md
│   └── ...
├── chapter_02_road/
│   └── ...
└── _TEMPLATES/
    └── quest_template.md

各クエストファイルはatomの標準形式に従います。

---
title: 武器を取るとき
layer: L2
type: main_quest
atoms:
  - quest_chapter_01_awakening_a
related:
  affects: [reputation_model, faction_relation_matrix]
  derives_from: [narrative_pillar, world_premise]
  requires: [character_kim, faction_alpha]
  part_of: chapter_01_awakening
---

## 進行段階
1. ...

## 分岐
- A案選択時: ...
- B案選択時: ...

## 報酬 (L3参照)
- reward_table.xlsx → quest_001 行

核心はrelated:ブロックです。requires: [character_kim]と書いた瞬間、このクエストはキム某の設定をcharacter_bibleから取得すると宣言したことになり、もう自分のファイルの中でキム某を新たに定義することはありません。ナラティブの本文はL2に、数値の報酬はL3のシートに置きます。両方がひとつのファイルにあると、シートを1行直すたびに本文に触れることになり、そうなると翻訳キーがずれます。

5.1.6 L3 — 自然言語が1行もない層

L3はシートとIDです。自然言語の文は1行も入りません。

quest_table.xlsx
| quest_id | chapter | type | unlock_level | reward_xp | reward_gold | dialogue_set_id |
|----------|---------|------|--------------|-----------|-------------|-----------------|
| q_001    | ch01    | main | 1            | 500       | 100         | ds_001          |
| q_002    | ch01    | main | 2            | 800       | 150         | ds_002          |

セリフでさえIDでのみ参照します。本文はdialogue_id_table.xlsxに別途あり、翻訳キーと1:1でマッピングされます。L2とL3をつなぐ通路は、quest_idのたった1列で十分です。前の図でこの通路だけが太い赤の矢印だった理由がここにあります。インターフェースを1列に狭めることが、Layer分離の核心です。通路が広いと両側が互いを知りすぎてしまい、片方を直すときにもう片方がつられて壊れます。

5.1.7 L4 — 出荷ゲート

L4はレビューと出荷です。新しいコンテンツが入ってくるたびに、自動・手動のチェックが作動します。自動チェックはスクリプトで回します。下の4つは、実際にCIに掛かっているlintです。

tone_lint.pyがL0のtone_manifesto.mdを直接読む点に注目してください。最上層（不変のビジョン）と最下層（出荷ゲート）が、自動化で直接つながっています。ビジョンに書いた禁止語彙がリリース直前の本文で検出されると、ビルドがブロックされます。

自動で捕まえられないものは、人が見ます。

自動と手動の境界が明確なら、レビュー時間が予測可能になります。「今回のチャプターのレビューは何日かかりますか？」に答えられるようになります。

5.1.8 AIにLayerをやらせてみる — ワークド・トランスクリプト

ここまでが構造です。しかし、この構造が本当に働く場面は、新しいコンテンツを作るときです。すでに五つの層が敷かれたプロジェクトで、サイドクエストの1行アイデアを受け取ってLayerにばらまく作業をClaudeにやらせた、実際のセッションをそのまま載せます。要約せず、外れた部分と拒否した部分まで含めます。

送ったプロンプト（全文）：

添付したL0/L1コンテキストを絶対に破らず、うちのLayer構造で分解して。

[narrative_pillar.md 全文 — 感情の柱3つ]
[tone_manifesto.md 抜粋 — 禁止語彙: "運命", "予言", "選ばれし者"]
[character_bible/character_kim.md 抜粋 — キム: 主人公を引き取った養父、
 寡黙、語尾を濁す、感情を直接言わない]

アイデア: "キムがプレイヤーに亡くなった妻の遺品を渡す短いサイドクエスト。"

L2クエストファイル(relatedブロック込み、本文200字ほど)、L3 quest_tableの行と
dialogue_id、それからtone違反のセルフチェックまで。まずL2だけ書いて止まって。

Claudeの生の出力（L2）：

---
title: 色あせたハンカチ
layer: L2
type: side_quest
atoms:
  - quest_side_kim_keepsake
related:
  affects: [reputation_model]
  derives_from: [narrative_pillar]
  requires: [character_kim]
  part_of: chapter_02_road
---

## 進行段階
1. キムがプレイヤーを静かに呼ぶ。いつもどおり用件をすぐには言わない。
2. 古びたハンカチを差し出す。「これは…君が持っていたほうがいい気がしてな。」
3. プレイヤーが何かと尋ねると、キムは答える代わりに窓の外を見る。
4. (選択) 受け取る / 辞退する。

## 分岐
- 受け取る: キムの評判 +1。以降のチャプターでハンカチ関連の回想を1回解禁。
- 辞退する: キムはうなずき、ハンカチをまた仕舞う。評判の変化なし。
  ハンカチは永遠に再び登場しない。

## 報酬 (L3参照)
- reward_table.xlsx → quest_side_kim_keepsake 行

ここでClaudeは止まり、1行を付け加えました。

「L0の柱1番（失ったものは二度と戻らない）を反映し、『辞退する』を選ぶとハンカチが永遠に消えるようにしました。ただし、ひとつ確認が必要です。亡くなった妻という設定は、character_kim.mdの抜粋にはありませんでした。私が独自に入れたものなので、キャラクターバイブルと衝突する可能性があります。」

人による検証と拒否：

この出力はトーンが正確でした。キムの寡黙さ、語尾を濁す癖、感情を直接言わない癖が生きていました。禁止語彙もありませんでした。しかし、最後のセルフチェックが、まさに本当の問題を突いていました。キムに亡くなった妻がいるという設定は、どこにもなかったのです。AIが「遺品」という言葉から自然に亡くなった配偶者を推論したわけですが、これはバイブルに新しい事実をこっそり追加する行為です。まさにこれが、本章冒頭の会議室で起きた事故の種です。

だから拒否しました。再依頼を送りました。

再依頼：

トーンはいい。ただ"亡くなった妻"はバイブルにない新設定だから使えない。
キムの過去は"故郷を離れるとき何かを置いてきた"までしか確定していない。遺品の正体を
特定せず、"ずっと前に置いてきたもの"くらいにぼかして書き直して。
ハンカチもバイブルにないから"布切れ"くらいに落として。

再依頼後の出力（抜粋）：

2. 古びた布切れを差し出す。「ずっと前に…置いてきたものが、ひとつあってな。
   これはその切れ端だとだけ言っておこう。」
3. プレイヤーが何かと尋ねると、キムは答える代わりに窓の外を見る。

今回は受け入れました。キムの過去を新たに確定させることなく、感情の柱1番（喪失）に触れています。何を失ったのかは、最後までぼかしたまま残ります。

このひとつのセッションが見せてくれるのは2つです。第一に、Layerのコンテキスト（L0の柱+L1のトーン+L2のバイブル）を正確に注入すれば、AIは驚くほどトーンを合わせてきます。第二に、AIは空欄に出会うと、もっともらしく埋めます。その埋めた内容がバイブルにない新事実であるとき、それを捕まえるのは依然として人です。Layer構造のrequires: [character_kim]が「どこを見るべきか」を教えてくれたからこそ、検証者はどのファイルと突き合わせるべきかをすぐに判断できました。構造がなければ、70ページをまた漁っていたはずです。

5.1.9 狭い通路の上の通知ベル

五つの層に分けた本当の理由は、インターフェースを狭くするためです。そして、狭いインターフェースごとに変更検知の自動化を付けます。

たとえば、L1のfaction_system.mdで「同時所属は最大2つ」を「最大1つ」に変えるPRを上げると、関係図がfaction_quest_eligibilityを参照しているL2のクエストをなめて影響リストを作り、そのリストがPRコメントに自動で添付されます。ルールを変えた人は、「会議を2、3回設定して誰が影響を受けるか調べる」代わりに、コメントに付いたリストを見て30分の会議で終わらせます。

核心はこれです。Layerだけ分けてインターフェースが曖昧なら、仕切りが増えただけになります。Layer分離そのものより、インターフェースの自動化が本質です。

5.1.10 6か月の運用、何が変わったか

五つの層に移して6か月回した後の測定です。以下の数値は著者チームの運用記録に基づきますが、絶対値は方向・比率としてのみ書いています（著者の推定・未検証）。分離前は記憶、分離後は実測なので、同じ資料を2回測ったわけではないという限界があります。

もっともはっきり減ったのは、ローカライズ漏れです。dialogue_idがL3で翻訳キーと1:1で結ばれ、dialogue_lint.pyがマッピング漏れを防ぐようになって、「翻訳されていないセリフがビルドに入る」事故はほぼ消えました。オンボーディングが短くなったことも大きな成果でした。新しいプランナーに「70ページのWordを全部読んで」ではなく、「L0の4.5枚だけ頭に入れて、自分のクエストはL2のテンプレートを埋めて」と言えるようになりました。

ひとつ正直に付け加えると、この効果が一度に出たわけではありません。最初の四半期には自動コメント1つだけを付け、残りは手作業でした。インターフェースの自動化は、四半期ごとに1つずつ増やしました。Layerを分けることより、自動化を付けることのほうが長くかかりました。

5.1.11 より深い理由 — プロシージャル生成への道

ここまでが表面的な理由です。「分野間の協業の言語を統一する」。しかし、より本質的な理由がもうひとつあります。Layer分解は、プロシージャル生成を可能にする前提です。5つの層のそれぞれがプロシージャル生成のひとつの役割（L0アンカー → L1ルールブック → L2本文 → L3数値 → L4ゲート）に対応し、ひとかたまりに混ざると生成器がどこから読みどこに書くかを決められず崩れる、という一般論は§6.6で全体として扱いました。ここでは、その前提がナラティブの五つの層の上でどのように実際に動くのかだけを見ます。

ひとかたまりの70ページ文書の上では、生成アルゴリズムはどこから読みどこに書くかを決められません。ナラティブの五つの層は、そのまま生成パイプラインの5段階になります — L0アンカー、L1入力ルール、L2本文が積み上がる場所、L3シミュレーション入力、L4検証ゲート。

先ほどのワークド・トランスクリプトが、すでにこの5段階のミニ版でした。L0の柱とL1のトーンをコンテキストとして注入し（アンカー）、L2に本文が生成され、L3の行が続いて出てきて、toneの違反セルフチェックが検証ゲートの真似をしました。人が一度に1クエストずつやらせていたものを、同じ構造の上でgeneratorがサイドクエストを量産するように移せば、プロシージャル生成になります。

さらに先へ行くと、こう流れます — プレイヤー行動の累積 → ワールドBTノードの状態変化（Squad上位） → NPC数値の変化（評判・関心事・優先順位） → NPCのタグ+数値がそのまま発現条件 → クエストクラウドからマッチするクエストが発現。クエストをあらかじめ全部書いておくのではなく、タグが付いたまま「空中に浮かぶ雲」のように置いておき、プレイヤーの行動がNPCの数値を変えると、その数値が発現条件と合うクエストが降りてきて現れます。この進歩的なモデルは、5.3で改めて詳しく扱います（フロー図を含む）。ここで強調したいのは、このすべての流れが五つの層の分解の上でのみ動くという点です。

逆に、Layerが混ざっているチームは、プロシージャル生成へ進めません。試みた瞬間、一貫性の事故で崩れます。キム某が養父であり裏切り者でもあるというあの事故が、生成器を通じて自動で量産されると想像してみればわかります。

ただし、最初から五段の引き出しを完璧にそろえなければならないという意味ではありません。最初の四半期には、L0の1行とL1のルールブック1冊だけを分離すれば十分です。分離は段階的に、インターフェースは狭く、です。

最後に、時期に関してひとつ。Layer分解自体は、決定論的なPCG（Procedural Content Generation、プロシージャルコンテンツ生成）の時代からあった分離です。新しいのは、LLMがその分離の上で自然言語の本文・ペルソナ・物語の分岐まで処理するようになったという点です — 上のトランスクリプトでAIがキムのトーンに合わせてセリフを書いたことは、5年前のルールテーブルでは不可能でした。この時期論は5.3でさらに扱います。

次章（5.2）では、この五つの層の上でlore_consistency_ruleがどのように世界観→キャラクター→クエストの一貫性を自動で検証するのか、つまりキム某の事故を構造的に防ぐチェッカーを見ます。

やってみよう — はじめてのLayer分解

すでにひとかたまりの世界観文書がある状態から始めると想定します。

setup. NarrativeDocsフォルダーの下に、空の5フォルダーを作りましょう。Layer0_VisionからLayer4_Build_QAまでです。既存のひとかたまりの文書はそのまま置いておき、その中から「絶対に変わらない1行」だけを選んでLayer0_Vision/narrative_pillar.mdに移します。frontmatterにstatus: lockedを入力します。このひとつのファイルが4.5枚を超えないようにします。

prompt. 新しいコンテンツを作るとき、AIにこの順番でコンテキストを渡します。

[narrative_pillar.md 全文]
[tone_manifesto.md 禁止語彙]
[関連する character_bible ファイルの抜粋]

アイデア: "<1行アイデア>"

このコンテキストを破らず、L2クエストファイルから書いて。relatedブロック
(requires/derives_from/affects) を埋めて、バイブルにない新設定は
入れず、必要なら止まって質問して。

verify. 出力で2つのことを確認しましょう。（1）requires:に書かれたファイルを実際に開き、AIがそこにない事実を新たに作っていないか突き合わせます。（2）禁止語彙を本文から検索します（tone_lint.pyがあれば自動、なければ目で）。どちらか1つでも引っかかったら拒否し、何が間違っているかを明示して再依頼してください。上のトランスクリプトで「亡くなった妻」を拒否したのが、まさに（1）です。

5.1.12 一人ミニ版

チームなしで一人で作るインディー開発者なら、五つの層は過剰に見えるかもしれません。2段で十分です。

vision.md1枚（L0+L1を統合）とcontent/フォルダー1つ（L2）、それからスプレッドシート1枚（L3）を置きます。QAは別の層を設ける代わりに、contentファイルのfrontmatterにrequires:を1行だけ書く習慣で代用しましょう。新しいクエストを書くたびにrequiresに書いたファイルだけを開き直して突き合わせれば、70ページを全部漁らなくてもキム某の事故を防げます。核心は層の数ではなく、「絶対に変わらない1行を切り出して、毎回AIに先に見せる」習慣です。その1行がコンテキストアンカーであり、一人でも中規模チームでも、そこから始めます。

本章のポイント

• もっとも抽象的なナラティブがLayerで解ければ、他の分野は同じパターンで付いてきます。
• L0は小さいからこそ変わらず、変わらないからこそ生成・レビューのコンテキストアンカーになります。
• Layerを分けることより、狭いインターフェースに自動化を付けることが本質です。

5.2 世界観 → キャラクター → クエストの一貫性検証

ベータ直前、QAからバグレポートが1枚上がってきました。タイトルは「王がタメ口をきいています」。本文は短いものでした。「3.4の導入カットシーンでK_001（国王）がプレイヤーに『おい、ちょっと待て（原文：야, 잠깐만）』と発言。このキャラクターは1.1から3.3まで一貫して『そなた（原文：그대）』を使用」。

ライターに聞いてみると、意外な答えが返ってきました。「そのセリフ、私は書いていません」。追跡してみると、外注ライターがカットシーンの分岐の1行を急いで埋める際に入れたものでした。私たちのキャラクターバイブルにはvoice_profileがありましたが、その外注ライターはその文書を見たことがなかったのです。ルールは文書の中にあり、セリフは文書の外から入ってきました。

これが一貫性事故の本質です。ルールがないから起きるのではなく、ルールが本文まで付いていけないから起きるのです。そしてこの1行がカットシーンだったとなると、話はさらに怖くなります。カットシーンには通常、声優の収録が付きます。テキストの段階なら一度直せば終わりですが、録音された後に発見されると、声優の再招集・再収録・再ミキシングという不可逆のコストが付いてきます。一貫性検証の本当の目的は「録音の前に」捕まえることです。

本章では、その事故を人の目の代わりにルールブックとチェッカーで捕まえるワークフローを扱います。lore_consistency_ruleというルールブックがどのようにチェッカーの入力になるのか、voice_lintがトーンのブレをどのように疑い候補として挙げるのか、そしてなぜ最終判定だけは最後まで人の領分として残すべきなのかを、実際の成果物そのままで見ていきます。

5.2.1 一貫性事故はどこで漏れるのか

リリース済みのRPG・MMORPGのユーザーレビューを集めてみると、ナラティブの一貫性事故はいくつかのパターンに収束します。種類は違って見えても、原因はほぼ1つです。

• 世界観の矛盾：1.1で「魔法は禁止された」→ 1.3でNPCが平然と魔法を使う
• ボイスのブレ：同じNPCの口調・敬称が章ごとに変わる（先ほどの「王のタメ口」事故）
• タイムラインの衝突：死んだNPCが後半で平然と再登場する（死亡フラグの同期漏れ）
• 報酬と物語の不一致：「王から下賜された剣」という物語なのに、データ上はどこにでもあるありふれたアイテム
• 勢力関係の矛盾：A勢力への敵対を宣言した直後に、A勢力のNPCが親切な挨拶をしてくる

5つはそれぞれ別の事故に見えますが、追跡してみると同じ場所で漏れています。Layer 0（世界前提）やLayer 1（ルール）が変わったのに、その変更がLayer 2（本文）とLayer 3（マスターデータ）まで伝播していないのです。ルールは更新されたのに、本文は古いルールの上で止まっています。

手作業のチェックでこれを防ごうとするのは無理があります。1つの章にNPCが50人、セリフが2,000行、クエストが30個絡み合っているのに、ルールを1行変えたときにその影響がどこまで波及するかを人が100%追跡するのは不可能です。見落とした1行はレビュー段階では捕まらず、リリース後のユーザーレビュー欄で捕まります。

かといって、自動チェックが100%を保証するわけでもありません。核心は役割分担です。自動チェックは疑い候補を素早く挙げ、判定は人が行う。自動化の目的は人のレビュー時間を減らすことであって、人をなくすことではありません。この前提を曖昧にすると、後で扱うすべての失敗が付いてきます。

5.2.2 lore_consistency_rule — チェッカーに食わせるルールブック

プロジェクトAのL1文書の1つがlore_consistency_rule.mdです。この文書は人が読むガイドであると同時に、チェッカーがパースする入力でもあります。フロントマターのatomsとaffectsが、その2つの役割を1つの体に束ねています。

---
title: ロア一貫性ルール
layer: L1
atoms:
  - lore_check_world_rule
  - lore_check_character_voice
  - lore_check_timeline
  - lore_check_faction_relation
related:
  derives_from: [world_premise, narrative_pillar]
  affects: [main_quest/*, character_bible/*, dialogue_id_table]
---

## 1. 世界ルール (World Rule)
- 魔法は禁止された状態から始まる → 魔法使用時は（時点、使用者、正当化）の明記が必要
- 神は沈黙状態 → 直接応答の描写は禁止（夢・幻想は許容）

## 2. キャラクターボイスルール
- 各キャラクターごとに voice_profile の参照を強制
- 新規セリフ作成時は voice_profile の5項目（語彙、文長、敬称、感情表現、禁忌表現）を遵守

## 3. タイムラインルール
- すべてのNPCに status_timeline を定義（生存 / 負傷 / 死亡 / 行方不明 / 位置変更）
- セリフ・登場時点で status_timeline を自動点検

## 4. 勢力関係ルール
- faction_relation_matrix の変更時点を記録
- 変更後のセリフは新しい関係を反映

affectsの1行がチェッカーのスキャン範囲を定義します。world_premiseが変われば、チェッカーはmain_quest/*、character_bible/*、dialogue_id_tableのすべてをスキャンし直します。人が「どこまで影響が及ぶのか」を頭の中で追跡していた作業を、ルールブックに書かれた依存関係グラフが代わりに引き受けるのです。

voice_profileは、このルールブックが参照する別のL2資産です。キャラクター1人のプロファイルは、チェッカーが比較基準として使えるように、項目が数値化・列挙型で入力されています。

# character_bible/K_001_voice_profile.yaml
character_id: K_001
display_name: 国王
voice_profile:
  vocabulary_register: 고풍_격식        # 語彙の格
  avg_sentence_len: 18                   # 平均文長（字）
  honorific: "그대"                      # 二人称敬称（固定）
  emotion_expression: 절제               # 感情表出の度合い
  forbidden_terms: ["야", "잠깐만", "ㅋ"] # 禁忌表現

このyamlがあって初めて、「王がタメ口をきく」という事故が、人の直感ではなく機械が比較できる項目になります。honorificが「그대（そなた）」なのに、セリフに「야（おい）」があれば、それは意見ではなくルール違反の候補です。

5.2.3 一貫性検証のフロー

変更が発生した瞬間にチェッカーが起動します。フローは次のとおりです。

flowchart TD
    A[変更発生: L0前提 / L1ルール / L2本文] --> B{変更分類器}
    B -->|どのルールのaffectsに該当するか| C[該当チェッカーを呼び出し]
    C --> D[affects範囲のL2本文 + L3マスターデータをスキャン]
    D --> E[ルール違反/疑い候補リスト]
    E --> F[変更リクエストにコメントを自動添付]
    F --> G{人による判定}
    G -->|本当の違反| H[本文修正 → 再チェック]
    G -->|意図された変化| I[voice_profile / ルールブック更新]
    G -->|ルールが過敏| J[ルール自体を調整]
    H --> K{テキスト段階か}
    I --> K
    J --> K
    K -->|はい: 可逆| L[レビュー完結可能]
    K -->|いいえ: 録音後| M[不可逆 — 再録音コスト]
    L -.遮断線.-> M

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class B,C,D,F code;
    class G human;
    class A,E data;
    class L pass;
    class M fail;

最後の分岐が、本章の隠れた背骨です。すべての一貫性判定はテキスト段階、つまり可逆の段階で終わらせなければなりません。レビューが録音・キャスティングの後にずれ込むと、修正は不可逆になります。だからvoice_lint・timeline_lintのようなチェッカーは、「速く」回すことよりも「早く」回すことが核心です。カットシーンのセリフが録音キューに入る前に、一度は通過していなければなりません。

チェッカーは4種で、それぞれルールブックの1セクションと一対一で対応します。

• world_rule_lint.py — L1世界ルール + すべてのL2本文 → 魔法使用・神の応答などの違反候補
• voice_lint.py — voice_profile + dialogue_id_table → ボイスのブレが疑われるセリフ
• timeline_lint.py — npc status_timeline + すべてのセリフ・登場時点 → 死亡NPCの再登場などの衝突
• faction_lint.py — faction_relation_matrix + dialogue tone → 関係矛盾のセリフ

4つのチェッカーはいずれも100%正確ではありません。だから出力の名前が「違反」ではなく「疑い候補」なのです。

5.2.4 ワークド・トランスクリプト：voice_lintを一周回す

「チェッカーがある」という抽象的な話ではピンと来ません。実際に一度回してみます。先ほどの「王がタメ口をきく」事故を再現した入力です。

setup — チェック対象のセリフ2行をdialogue_id_tableから取ってきます。

dialogue_id_204  speaker=K_001  text="야, 잠깐만요. 그쪽이 먼저 말해 봐."
dialogue_id_217  speaker=K_007  text="...젠장, 또 실패야. 다시 처음부터."

prompt — チェッカー本体はルールベース（正規表現・長さ比較・禁止語マッチング）で動きます。AIは「なぜ疑わしいのか」をライターが読める自然言語で説明する場所にだけ付けます。チェック段階のLLMプロンプト全文は次のとおりです。

voice_lintが抽出した疑い候補だ。判定はせず、各候補が
どのvoice_profile項目に違反していそうかと、その根拠だけを1〜2文で説明して。
「違反だ/違反ではない」と断定せず、「〜と疑われる」までにとどめること。

[voice_profile]
K_001: honorific="그대", avg_sentence_len=18, forbidden=["야","잠깐만"]
K_007: forbidden=["젠장"]

[疑い候補]
- dialogue_id_204 (K_001): "야, 잠깐만요. 그쪽이 먼저 말해 봐."
- dialogue_id_217 (K_007): "...젠장, 또 실패야. 다시 처음부터."

Claudeの生の出力（要約・整理なしにそのまま掲載します）

[dialogue_id_204 / K_001]
このセリフはhonorific項目と衝突するものと疑われます。voice_profileは
二人称の敬称を「그대」に固定していますが、本セリフは「그쪽」を使っており、
敬称自体が現れていません。また、forbidden_termsの「야」と「잠깐만」がいずれも
登場しており、語彙の格（고풍_격식）から外れているものと疑われます。平均文長18字の
基準とは直接矛盾するようには見えませんが、語調自体がカジュアルになっている点が違反シグナルとして疑われます。

[dialogue_id_217 / K_007]
forbidden_termsの「젠장」がそのまま使用されており、禁忌表現項目の違反と疑われます。
ただし、K_007（学者）のemotion_expression項目が提示されていないため、この表現が
意図された感情の高揚なのか単純な逸脱なのかは、この情報だけでは判断が困難です。
判定にはライターのレビューが必要です。

この出力には、私たちがあえて残した2つの正直さがあります。第一に、204でAIは「平均文長の18字基準とは直接矛盾して見えない」と述べ、違反ではない項目を違反だと言い張りませんでした。第二に、217で「emotion_expression項目が提示されていないため判断が難しい」と述べ、情報不足を認めて判定を人に渡しました。AIがすべての疑いを「違反確定」として押し切っていたら、その方が危険なチェッカーです。

verify — ライターはこのコメントを変更リクエスト上でそのまま受け取ります。判定はライターが行います。

• 204：本当の違反。外注ライターがvoice_profileを見ずに入れたセリフです → 本文を修正し、再チェック
• 217：意図された違反。K_007が崩れていく3.4の感情高揚のセリフです → voice_profileにemotion_peak_exceptionフラグを追加し、217を例外として登録

2つの候補を同じチェッカーが挙げたのに、結末は正反対です。一方は本文を直し、もう一方はルールを直します。この分岐を機械が自動ではできないということが、次の節の核心です。

5.2.5 なぜ判定は人の領分なのか

チェッカーが疑いまでしか挙げず、判定を人に渡すのには3つの理由があります。

第一に、意図された違反が存在します。キャラクターが崩れたり変わったりする章では、ボイスは意図的に揺れます。先ほどの217がそうです。自動拒否型のチェッカーは、ライターの演出意図を塞いでしまいます。

第二に、ルール自体が進化します。同じ種類の疑いが続けて「意図された変化」と判定されるなら、それはルールが現実に追いついていないというシグナルです。チェック結果は本文だけを直させるのではなく、ルールブックも直させます。

第三に、新規キャラクター・勢力には学習期間が必要です。voice_profileがまだ2〜3項目しか埋まっていない新規NPCは、疑いが多めに挙がるのが正常です。この時期に自動拒否をかけると、ライターはチェッカーを敵と認識します。

自動チェックと人の判定の境界が明確であってこそ、チェッカーは生き残ります。自動拒否型にすると、1か月以内にライターたちが「これ、切りましょう」と言い出します。会社の出入口に敏感すぎる自動センサーを付けると、人が通るたびにドアが閉まり、結局誰かがセンサーを外してしまうのと同じです。チェッカーはドアを閉める装置ではなく、「ここを誰かが通った」と知らせる装置でなければなりません。

1つ但し書きを添えます。レビューはテキスト段階で完結すべきだという原則（先のフロー図の遮断線）は、人の判定にもそのまま適用されます。ライターの「意図された違反」という判定も、録音の前に終わっていなければなりません。録音後の覆しはチェッカーの問題ではなく、工程コストの問題に変わります（可逆/不可逆の境界の全体像は5.4.5）。

5.2.6 測定 — 6か月の前後比較

プロジェクトAでチェッカー4種を段階的に導入し、6か月測定しました。以下は実測ログに基づきつつ、絶対値の代わりに方向・比率に置き換えたものです（社内測定、著者の推定ではありません）。

• 章1つあたりのレビュー時間：導入前は約5日 → 導入後は約2日（半分以下）
• リリース後に発見される一貫性事故：章あたり3〜5件 → 0〜1件
• ライター1人あたりの章の産出速度：4週間 → 2.5週間
• ルールブック（L1）の更新頻度：四半期に1〜2回 → 月に1〜2回

最後の項目が一番興味深いところです。チェッカーがあれば、ルールを頻繁に変えても安全です。ルールを1行変えればその影響が自動的に可視化されるので、変更への恐れが減り、ルールがより速く進化します。一貫性ツールの本当の効果は「事故を減らした」ではなく、「ルールを恐れずに変えられるようになった」という方に近いのです。

ただし、上の数値はチェッカー4種がすべて稼働している時点の数字です。導入初期にvoice_lintの1つだけでも目に見える効果が出たという点の方が重要です。最初から4種を全部オンにする必要はありません。

5.2.7 AIをどこに置くのか

自動チェッカーの本体はルールベースが効率的です。同じ入力に同じ結果が返ってきてこそ信頼が積み上がるのですが、LLMは非決定論的なので、その場所には合いません。AIは別の4つの場所に入ります。

• ルール違反候補の検出 → ルール（正規表現・キーワード・長さ・構造チェック）。LLMではない
• 疑い候補の根拠説明 → LLM。先のワークド・トランスクリプトで見た「なぜ疑わしいのか」の自然言語説明
• 代替セリフのドラフト生成 → LLM。ライターレビュー用のドラフトであり、確定はライター
• voice_profile自動更新候補の提案 → LLM。数十章の本文からパターンを抽出して項目の補強案を提示

ルールは速くて決定論的、LLMは説明と生成に強い。この2つの役割を混ぜると、どちらも壊れます。チェックをLLMに任せると、同じセリフが昨日は通って今日は引っかかるということが起き、説明を正規表現に任せると「honorific項目違反」という機械語しか出てきません。

5.2.8 導入の順序とよくある失敗

最初からチェッカー4種を全部作ると、負担が効果より先に来ます。推奨順序は、最も安くて効果の大きいものからです。

1. voice_profile 5項目の標準化（約1か月）— character_bibleの様式から定着させます。チェッカーよりこちらが先です
2. voice_lintの最小バージョン（約1週間）— 禁止語彙のマッチングのみ。1単語塞ぐだけでも、リリース後のSNS事故が四半期に1〜2件減ります
3. timeline_lint（1〜2週間）— 死亡フラグの点検。死んだNPCの再登場を捕まえるだけでも体感が大きいです
4. world_rule_lint + faction_lint（1〜2か月）— 残りの2種
5. LLM補助（さらに1〜2か月）— 説明・ドラフト生成の統合

ステップ2（voice_lint）だけでも効果が大きいという点を強調しておきます。先ほどの「王のタメ口」事故は、まさにこのステップ1つで捕まる種類のものでした。

導入過程で繰り返される失敗も、ほぼ決まっています。

• 自動拒否型にしてしまう → 疑い候補 + 人による判定の構造に戻す
• ルールブックがライターと分離されて運用される → ルールブックの変更にはライターの合意を必須にし、ライターがルールブックの変更を要請できるようにする
• voice_profileが形だけになる → キャラクター1人で5項目を完全に埋めてから拡張する
• チェック結果がどこにあるのか分からない → 変更リクエストのコメントへの自動添付を強制する
• LLMにチェック自体をやらせる → チェックはルール、説明だけLLM
• 録音後にレビューする → レビューはテキスト段階で完結。可逆区間を越えない

最後の項目が、その前のすべての項目よりも高くつきます。ほかの失敗は時間を失いますが、この失敗は声優のスケジュールを失います。

次章（5.3）では、チェッカーの代わりにAI補助でナラティブ本文を書くフローを扱います。L0のトーンとL1のルールをコンテキストとして注入し、AIが一般的な答えではなく、私たちの世界の答えを出すようにする方法を見ていきます。

本章のポイント

• 一貫性事故はルールがないから起きるのではなく、ルールが本文まで伝播しないから起きる。
• チェッカーは疑いまでにとどめ、判定は人が行ってこそ、チェッカーは廃棄されずに生き残る。
• すべての一貫性レビューは、録音前のテキスト（可逆）段階で完結させる。

次章のプレビュー

• 5.3. AI補助によるナラティブ作成 — L0トーン・L1ルールのコンテキスト注入

やってみよう

setup — character_bibleからキャラクターを1人選び、voice_profileの5項目（語彙の格・平均文長・敬称・感情表現・禁止表現）をyamlで完全に埋めましょう。同じキャラクターの既存セリフ10行をdialogue_id_tableから抜き出し、1つのファイルにまとめます。

prompt — 先のワークド・トランスクリプトのチェック補助プロンプトをそのまま使いましょう。核心は2つの制約です。「判定するな」と「『〜と疑われる』までにとどめよ」です。入力にvoice_profileのyamlとセリフ10行を貼り付けます。

verify — 出力された疑い候補を1行ずつ自分で判定しましょう。本当の違反なら本文を直し、意図された変化ならvoice_profileに例外フラグを追加します。AIが「違反ではない項目」まで違反だと言い張っていないか、「情報不足」を認めているかも併せて確認します。AIがすべての項目を違反と断定するなら、プロンプトの「判定するな」という制約を強化しましょう。

一人ミニ版

チェッカー4種もルールブックもない1人開発なら、チェッカー本体なしで、プロンプト1つで同じ効果を出せます。キャラクターごとのvoice_profileのyamlだけを手で維持し、新しいセリフを書くたびに、そのキャラクターのyaml + 新しいセリフを先の補助プロンプトに貼り付けて「疑い候補」を受け取りましょう。自動化はありませんが、判定は人、AIは説明という核心構造はそのまま生きています。守るべきはたった1行です — 録音・音声合成に回す前に、このレビューを一度通すこと。可逆段階を越えないという原則は、チームの規模とは無関係です。

5.3 AI支援によるナラティブ執筆

新しいサイドNPCの最初のセリフを作っていた日のことです。空のチャット欄に「村の鍛冶屋NPCのセリフを5つ作って」と打ち込みました。5秒後、画面に「勇者よ、そなたの武器をわしに任せるがよい」が表示されました。どこかで見たような、ではなく、正確にどこで見たのか分かる気がする文章でした。同じプロンプトを別のチームの別のゲームに入れても、まったく同じ答えが返ってくるはずでした。その瞬間に気づいたのは、モデルが弱いということではなく、私がモデルにこちらのゲームのことを何ひとつ教えていなかったということでした。

AIは一般的なファンタジーの文章を上手に書きます。しかし、この世界の文章は書けません。違いはただ一つ、コンテキスト注入です。L0トーンとL1ルールを毎回のリクエストに添えて送れば、AIが吐き出す一行は「どこかで見たような文章」から「このゲームの文章」に変わります。本章ではその注入を4層で運用する実務を扱い、最後に同じ原理をワールドシミュレーション規模へ引き上げる進歩的な適用（ワールドBT（BehaviorTree、ビヘイビアツリー）+クエストクラウド）をRnDの最前線として押さえます。

5.3.1 コンテキストが空のときに起きること

ナラティブ分野でのAI支援は、最も早く導入され、最も早く信頼を失う領域です。失敗パターンがほとんど同じだからです。

「クエスト開始のセリフを5つ」と投げると、「勇者よ、われらの村が…」で始まる一般的なファンタジー5種が返ってきます。「このキャラクターのセリフを直して」と頼むと、ボイスが平準化されてすべてのNPCが似た口調に収束します。「チャプター1のシノプシスを書いて」と頼むと、どこかで見たことのあるRPGシノプシスの平均値が出てきます。

問題はモデルではなく、コンテキストが空だということです。モデルは学習データの平均を出力します。平均がほしくないなら、平均から遠ざかる手がかりを与えなければなりません。本章のテーマは、その手がかりをどう作り、どう注入するかです。

著者が運営するMMORPGプロジェクト（以下、プロジェクトA）では、ナラティブAI支援は4層のコンテキストを順番に積み上げます。5.1でNarrativeDocsをLayer 0〜4に分解したあの構造が、ここでそのまま注入単位として再利用されます。

4層を毎回すべて入れるわけではありません。作業タイプによって必要な層だけを取り出します。あるキャラクターの次のセリフの草案なら、A + B（トーンのみ）+ D（そのキャラクターの直近のセリフ10行）で十分です。新規サイドクエストのシノプシスならC（quest構造ルール）が加わります。分岐結果4案ならC（分岐規則）+ D（分岐直前の本文全体）が重くなります。机の上の書類棚からペルソナシート、世界観の一行、ルールブックのページ、隣接本文のひと束を、作業の大きさに合わせて選んで送るようなものです。

5.3.2 ワークド・トランスクリプト一本 — K_007の初めての感情セリフ

抽象的に説明する代わりに、実際の一つのリクエストを最後まで追いかけます。同じキャラクター（学者タイプのNPC、社内ID K_007）が初めて感情を表に出す場面のセリフ3案を作る作業です。プロンプト全文から始めます。

送信したプロンプト（Layer A + B（トーン）+ D + 作業指示 + 出力形式）:

[システム]
プロジェクトAのナラティブ作家だ。「勇者」・「選ばれし者」のようなRPG常套句は使わず、
口調は下の直前のセリフのトーンにそのまま従うこと。知らない設定はでっち上げず
「コンテキストでは判断不可」と答えること。君は草案だけ、決定は私がする。

[L0トーン — tone_manifesto 抜粋]
この世界の情緒は抑制だ。人物は感情を簡単に口にしない。
感情は爆発ではなくひび割れとして現れる。言葉の省略と短い文。

[参考 — K_007の直前5つのセリフ (時系列、原文のまま)]
1. "...それは私も初めて聞く話ですが。"
2. "記録はありますか? なければ疑うべきでしょう。"
3. "確実になるまで動かないでおきましょう。"
4. "私の意見はそれで終わりです。"
5. "...すみません。私は冷たすぎましたか。"

[状況]
仲間のNPCが傷ついたまま戻ってきた。学者は初めて感情を表に出さなければならない。

ちょうど3案だけ、各25字以内で。案ごとに末尾へ (反応タイプ: 怒り/悲しみ/否定) のラベルを付け、
説明や前置きは省くこと。

Claudeの生の出力（要約・脚色なしそのまま）:

1. "...なぜ一人で抱え込んだんですか。バカみたいに。" (反応タイプ: 悲しみ)
2. "記録を見るべきだった。私が、私が見落としたんです。" (反応タイプ: 否定)
3. "大丈夫です。全部大丈夫です。だからもう—" (反応タイプ: 否定)

ここで止まらないことが核心です。作家が3つの案を読んで検証します。1案目はトーンが合っています。直前のセリフ5番の「...죄송합니다（…すみません）」が見せたひび割れを、1案目は「바보같이（バカみたいに）」という一語で受け継ぎました。採用候補です。2案目は「제가, 제가 놓쳤어요（私が、私が見落としたんです）」の言いよどみが、学者の抑制とわずかにずれています。保留です。3案目はラベルが間違っています。「괜찮아요（大丈夫です）」を繰り返すのは否定ではなく回避に近いのですが、このプロジェクトのvoice_profileには、学者が感情を回避で処理するパターンがありません。却下です。

再リクエスト（却下理由を明記して再送）:

3案目は却下。「大丈夫です」の繰り返しはこの学者のパターンじゃない。この人物は感情を
回避ではなく「事実確認の失敗に対する自責」で処理する。1案目は採用する。
2・3案目の枠に、1案目と毛色の違う2案をもう一度。言いよどみなしで25字以内で。

Claudeの2回目の出力:

2. "記録は嘘をつきません。私が見なかったんです。" (反応タイプ: 自責)
3. "...座って。まず傷を。話はあとで。" (反応タイプ: 悲しみ)

今回は2つとも通過しました。2案目は「기록（記録）」という学者の核心語彙（直前のセリフ2番「기록이 있나요?（記録はありますか?）」）を自責の媒介として使い直し、3案目は抑制された命令形で、学者が感情を行動で押さえ込むパターンを見せました。最終採用は1案目+2案目+3案目です。この3行は5.2のvoice_lintによる自動チェックを通過したあとでL2本文に反映され、L3でdialogue_idの発行を受けます。

この一本のトランスクリプトに、本章のすべてが詰まっています。トーン注入（L0）が1案目を生かし、原文そのままの隣接本文（L2）が学者の語彙「기록（記録）」を再リクエストで再利用させ、出力形式の強制が雑談を防ぎ、作家の却下ゲートが3案目の間違ったラベルをふるい落としました。AIは一行たりとも最終決定していません。

5.3.3 Layer A — システムプロンプト、一行がすべてを左右する

いちばん上に敷かれるペルソナ定義です。一度決めたらほとんど変えません。上のトランスクリプトのシステムブロックがその実物です。5行のうち最後の1行（「草案だけを書き、決定は私がする」）が最も重要です。これが抜けると、AIは「最終版」のふりをした文章を自信満々に出してきて、作家はレビューの代わりに採点をするはめになります。そして3行目（「知らない設定はでっち上げず『コンテキストでは判断不可』と答える」）が2番目に重要です。この行がなければ、モデルは空欄をもっともらしい嘘で埋めます。ナラティブにおいて、もっともらしい嘘は数日後にロアの衝突として返ってきます。

5.3.4 Layer B — L0ビジョンとキャッシングの位置

L0は分量が少なく（5.1基準で約4.5ページ分）、ほぼ毎回全体を注入できます。韓国語基準の推定でworld_premise.mdが約2,500トークン、narrative_pillar.mdが約1,500トークン、tone_manifesto.mdが約3,000トークン、合わせて約7,000トークンです。（これらの数値は著者の推定（未検証）です。トークナイザーや文書の改訂によって変わります。）

7,000トークンを毎回のリクエストで送り直すと、コストが積み上がります。そこでプロンプトキャッシングをかけます。Anthropic・OpenAIの両方が対応している機能で、キャッシュヒット時には入力トークンのコストが大きく下がります。核心は、変わるものと変わらないものをメッセージの中で分離しておくことです。

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},
    {"role": "user", "content": [
        {"type": "text", "text": L0_FULL,      "cache_control": {"type": "ephemeral"}},
        {"type": "text", "text": L1_SELECTED,  "cache_control": {"type": "ephemeral"}},
        {"type": "text", "text": L2_ADJACENT},   # 毎回変更 — キャッシュしない
        {"type": "text", "text": TASK_INSTRUCTION},  # 毎回変更
    ]},
]

cache_controlを付けたL0とL1はキャッシュ対象で、L2の隣接本文と作業指示は毎回変わるためキャッシュしません。キャッシュブロックを常にメッセージの前方にまとめておくことがヒット率を左右します。変わるブロックが前に挟まると、その後ろのキャッシュはすべて無効化されます。この順序を間違えることが、キャッシングを有効にしてもコストが下がらない最も多い原因です。

キャッシュヒット率・コスト削減数値の詳細はPart 22（コスト）の章で扱います。ここでは「変わるものを後ろに寄せる」という原理だけ覚えておけば十分です。

5.3.5 Layer C — L1ルールを丸ごと入れない

L1ルールブックは分量が大きく、全部入れるとコンテキストがあふれ、さらに悪いことにモデルが核心を見落とします。作業に関連するルールだけを、それも_summary節だけを選びます。

メインクエストの分岐結果を作るときはdialogue_branching_ruleとfaction_relation_matrixを選びます。新規NPCのセリフならそのNPCのvoice_profileとtone_manifesto。ロア辞典の新規項目ならlore_consistency_ruleとworld_premise。サイドクエストの骨格ならquest_templateとreputation_modelです。選択は人が直接行うか、wikilinkグラフ（第7部）をたどって自動抽出しますが、自動抽出のときは適合率より再現率を優先します。ルールが1つ抜ける損害のほうが、ルールが1つ余計に入る損害よりはるかに大きいからです。

ルールブックの本文を全部入れる代わりに、ルールブックファイルの冒頭に_summary節を置き、それだけを注入します。

---
title: 分岐規則
layer: L1
---

## _summary
- 分岐はチャプターの末尾でのみ発生
- 分岐は2~3案。4案以上は禁止
- 分岐の選択は評判に +/-1 の影響、結末分岐には +/-3
- すべての分岐結果は24時間以内に結果を見せなければならない
- 分岐は取り消し不可 (セーブ分離推奨UIの表示)

## 1. 分岐発生時点の規則
(詳細説明、運営者参考用 — LLMには注入しない)
...

_summaryの5行のほうが、本文50行よりLLM出力の品質に効きます。モデルは短く断定的なルールをよりよく守ります。長い説明はモデルの注意を分散させ、分散した注意はルール違反として返ってきます。

5.3.6 Layer D — 隣接本文は要約しない

直前のセリフ、隣接クエスト、同じチャプターのシノプシス。最も変動が大きいコンテキストです。同じキャラクターの新規セリフにはそのキャラクターの直前のセリフ10行を時系列で、チャプター中盤のクエストにはチャプターシノプシスと同じチャプターのクエストの1行要約を、分岐結果の結末には分岐直前の本文全体と選択肢テキストを入れます。多く入れすぎるとLLMは平均を出力し、少なすぎると一般化された出力になります。適正な範囲はトークン1,500〜3,000の間（著者の観察基準、未検証）です。

核心ルールを一つ。隣接本文は加工も要約もせず、原文のまま入れます。上のトランスクリプトで学者の直前のセリフ5行に手を入れずそのまま入れたからこそ、モデルは再リクエストの段階で「기록（記録）」という単語を正確につまみ上げ、自責の媒介として再利用できました。もしあの5行を「学者は慎重で冷たい」と要約して入れていたら、作家の微細な選択はすべて消え、モデルはまた平均へ戻っていたでしょう。要約は情報を減らすのではなく、作家がすでに下した決定を消すのです。

5.3.7 作家によるレビューワークフロー — 廃棄率を指標として使う

AI出力は常に草案です。レビューは決められたゲートを通過します。

flowchart TD
    A[AI出力N個] --> B[1次: voice_lint自動
5.2]
    B --> C[2次: 作家1人が選択・修正
約15分]
    C --> D{採用案あり?}
    D -->|あり| E[3次: リードナラティブ合意
必要時]
    D -->|0個採用 = 全部廃棄| F[再リクエストまたは直接執筆]
    E --> G[L2本文に反映
+ L3 dialogue_id発行]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class B code;
    class A ai;
    class C,D,E human;
    class G pass;
    class F fail;

作家がN個のうち0個を選ぶケース（全部廃棄）も正常です。上のトランスクリプトで3案目が却下されたように、却下は失敗ではなく、ゲートが機能した証拠です。だからこそ、廃棄率を作家別・キャラクター別に測定し、コンテキスト注入品質の指標とします。

廃棄率が0〜20%ならコンテキストが十分な安定運用なので、そのままにします。20〜50%は一般的な運用範囲なのでモニタリングだけ行います。50〜80%に上がったら、L1ルールの選択が抜けていないか再点検します。80%を超えたら、個別ルールの問題ではなくシステムプロンプトやペルソナ自体がずれているということなので、Layer Aを書き直します。廃棄率は週1回、作家別に集計して振り返りで共有します。

ただし、廃棄率は絶対的な指標ではありません。変化の速いキャラクター（たとえば上のトランスクリプトのK_007のように、初めて感情を表に出す転換点）は、廃棄率が高くても正常です。数字は対話の始まりであって、判決ではありません。

5.3.8 セキュリティ — コンテキスト流出をどう防ぐか

L0〜L1はゲームの核心IPです。外部LLM APIにそのまま送るのが負担なら、選択肢が分かれます。外部APIを学習不使用契約のまま使う方式が最も速いものの、法務レビューが必要です。会社名・固有名詞をplaceholderに置換して送る方式は、追加の処理コストがかかり、自然さが損なわれます。セルフホスティング（オープンモデル）はデータこそ安全ですが、品質・運用の負担が大きくなります。L0は内部に置いて草案だけ外部に送るハイブリッドは、運用が複雑です。

著者のプロジェクトAは1番目の方式（外部API+学習不使用契約）を使っています。2番目の方式は試したうえでやめました。placeholder置換が「○○王国の○○学者が○○について語った」という形に本文を平準化させ、出力品質を崩してしまったからです。匿名化が品質を殺すのは本書全体で繰り返されるトレードオフです（Part 1の匿名化の章を参照）。ナラティブではその損傷がとくに大きいのです。固有名詞がそのままトーンだからです。

5.3.9 よくある失敗と処方箋

システムプロンプトなしで作業指示だけ投げると、平均が出てきます。ペルソナと禁則を先に敷きます。L0を毎回全体注入しながらキャッシングを使わないと、コストが漏れます。キャッシュブロックを前方にまとめます。L1ルールブックを丸ごと入れると、モデルが核心を見落とします。_summary節だけを抜き出します。隣接本文を要約して入れると、作家の選択が消えます。原文のまま引用します。出力形式を決めないと、回答のかなりの数が「こちらが3つの候補です:」で始まり、作家がその前置きを本文と取り違える事故までついてきます。個数・長さ・ラベルを明示します。AI出力を最終版として使うと、レビューゲートが崩れます。常に作家ゲートを通過させます。廃棄率を測らないと、ツールの健全性が人の印象に依存します。週次で集計し、振り返りで共有します。

5.3.10 保守的な適用から進歩的な適用へ

ここまでは保守的な適用でした。作家がコンテキストを丁寧に注入し、AIは一行一行の草案だけを作ります。単位は「このキャラクターの次のセリフ3案」「このクエストのシノプシス」のような小さな作業です。安定していますが、量産規模と動的な反応性には限界があります。

ここで一つ、先に押さえておきます。プロシージャル生成・ワールドシミュレーション・動的クエストは、プランナーたちが20〜30年前から紙の上に描いてきたビジョンです。決定論的なルールブックベースのPCGは、ダンジョンの部屋・武器オプション・スポーン分布のような数値領域は扱えましたが、自然言語の本文・キャラクターペルソナ・物語の分岐・NPCの会話には手が届きませんでした。企画のかなりの部分が紙の上にとどまっていたわけです。2024〜2026年のLLMと画像モデルの発展が、その領域を実装可能な場所へ引き寄せました。AIの発展の核心的な意味はモデルのスコアではなく、長く紙の上にあった企画の実現可能性が開かれたことにあります。ただし、可能性が開かれることと、運用可能なシステムとして定着することは別の問題です。

Layer分解がプロシージャル生成の前提だった

5.1のLayer 0〜4分解は、単なる整理ではなくプロシージャル生成の前提でした。5つの階層がそれぞれ生成パイプラインのどの段階（L0アンカー → L1ルールブック → L2本文 → L3数値 → L4ゲート）に対応するかは、§6.6と5.1.11で扱いました。要点は一つです — ひとかたまりの文書の上では、生成器がどこから読みどこに書くかを決められず、L0がどこにあるか分からないままコンテキストがぼやけ、L1・L2が一つのファイルの中で衝突して量産ラインが崩れます。Layer分解が先にあり、その上でプロシージャル生成が機能します。ここでは、その前提をナラティブAI支援の量産段階に適用します。

進歩的な適用の骨格 — クエストクラウド

3つの要素が束ねられます。第一に、NPC Personaがプロシージャルに生成されます。メインNPCは作家の手によりますが、サイドNPCは6.2〜6.3のgenerator・Squadパイプラインが量産します。各Personaはvoice_profileとともにタグ（職業・勢力・性向・役割）を付けます。第二に、ワールドBTがSquadの上位に位置します。Squadが一つの狩り場のNPCグループの行動を束ねるなら、ワールドBTはその上でプレイヤー行動の累積数値を受け取り、世界全体の状態を更新します。プレイヤーがどの勢力を助けたか、どの地域によく行ったか、どんな決定を下したかがワールドBTのノード状態を揺らし、揺れたノードは影響圏のNPCたちの数値（評判・関心事・優先順位）に反映されます。第三に、クエストはクラウドモデルです。メインクエストを除くすべてのクエストがプロシージャルに生成され、それぞれタグ（誰が・どこで・なぜ・いつ）と出現条件を付けたまま漂います。どのクエストも特定のNPCに固定されません。

出現は5つの段階を経ます。

flowchart TD
    P[1. プレイヤー行動の累積
勢力支援・地域訪問・決定] --> W[2. ワールドBTノードの状態変化
Squad上位の世界状態更新]
    W --> N[3. NPC数値の変化
評判・関心事・優先順位]
    N --> M[4. NPCタグ + 数値 == 出現条件
マッチングキー生成]
    M --> Q[5. クエストクラウドから
マッチするクエストが出現]
    Q -.->|作家ゲート通過後に公開| PL[プレイヤーの前に登場]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class M code;
    class P,W,N,Q data;
    class PL pass;

比喩で言えば、クエストは図書館の本棚に挿さっているのではなく、空中に漂う雲です。NPCがある状態に到達すると、自分に合った雲が降りてきて手に収まります。この構造でAIは一行を書く補助者ではなく、3つを同時に扱います。プロシージャル生成されたPersona・クエストの自然言語本文（説明・セリフ）、ワールドBTの状態がNPCに反映されるときの語彙の変動（同じvoice_profileを維持しつつ、話題はワールド状態に合わせて変動）、そして検証段階の疑義分類器（このクエストがこのNPCに出現してよいか）です。

不可逆の境界 — レビューはテキスト段階で終えなければならない

進歩的な適用でも、可逆/不可逆の境界（5.4.5）はそのまま生きています。クラウドから出現したクエストのセリフがレビューを通過しないまま音声パイプラインへ流れてしまうと、コードのロールバックでは戻せません。だからこそ、すべてのレビューゲート（voice_lint、疑義分類器、作家ゲート）を不可逆の境界の手前に置くことが、進歩的な適用の安全装置です。自動量産が加わるぶん、このゲートは保守的な適用よりもさらに固くなければなりません。

どこで止まり、なぜ止まらないのか

本書は進歩的な適用の完成形までは扱いません。別の本一冊分の分量であり、会社・プロジェクトごとにインフラの前提が異なるからです。覚えておくべきことは2つだけです。まず、保守的な適用ができないチームは進歩的な適用もできません。保守的な適用でレビューゲートが回らなければ、進歩的な適用ではクラウドが暴走します。運用が生き残るには、プロシージャル生成インフラ、ワールドBTノードの定義・テストツール、出現クエストの自動疑義分類+作家ゲート、出現率・廃棄率・プレイヤー満足度の同時トラッキング、誤って出現したクエストの自動回収・差し替えがそろっていなければなりません。5つのうち1つでも欠けると、1四半期以内に廃棄されます。一貫性の事故が爆発的に増え、人のレビューが追いつかなくなるからです。

次に、進歩的な適用は量産を増やす道具ではなく、動的な反応性を増やす道具です。量産だけを狙うと、一般的なRPGの平均がクラウドの中に満ちあふれ、プレイヤーは「より多様に見えるのに、より空っぽな」世界に出会います。とはいえ、この道が危険なだけというわけでもありません。この領域はゲーム企画RnDの最前線です。プロシージャル生成・シミュレーション・LLMが出会う場所から、本当に新しいゲーム形式が生まれる可能性が最も高いのです。すぐに会社へ導入することはまれでも、次の5〜10年の方向性の一つとして見ておく価値はあります。

5.3.11 一つの章を最後までやってみよう

本章の保守的な適用をそのまま再現する手順です。

setup. L0の3ファイル（world_premise.md・narrative_pillar.md・tone_manifesto.md）を1つのテキストに結合し、L0_FULL変数に入れてください。システムプロンプトは上のトランスクリプトの5行のとおりに書き、最後の行（「草案だけを書き、決定は作家がする」）を抜かさないでください。セリフを作るキャラクターの直前のセリフ10行を、原文のままテキストとして集めます。

prompt. メッセージを[시스템] → [L0 톤] → [참고: 직전 대사 원본] → [상황] → [출력 형식]の順に組み立ててみましょう。出力形式には「正確にN案/各案の最大文字数/ラベル/それ以外は一切禁止」を必ず明記します。L0とL1にだけcache_controlを設定し、変わるブロックはメッセージの後ろに寄せます。

verify. 受け取ったN案を1行ずつ検証してみましょう。トーンが直前のセリフとつながっているか、ラベルが実際の反応と合っているか、このキャラクターが使わないパターン（回避・言いよどみなど）が混ざっていないかを見ます。却下する案は理由を明記して再リクエストします。0個採用も正常で、廃棄率として記録してください。通過した案だけをvoice_lintに通してL2に反映し、L3でdialogue_idを発行します。

一人ミニ版. API・キャッシング・voice_lintがなくても核心は同じです。ChatGPT/Claudeのチャット画面が1つあれば十分です。キャラクターの直前のセリフ5〜10行を毎回コピペで先頭に敷き、出力形式の3行を常に付け、返ってきた答えのうち却下するものは理由を書いて再リクエストしてみましょう。キャッシングの代わりに同じ会話スレッドを維持すれば、前のコンテキストがそのまま残ります。廃棄率は紙1枚に「今週の採用12/全体30」のように手で数えて書けば十分です。道具が小さくても、4層注入とレビューゲートという骨格は一人の作家にもまったく同じように機能します。

本章のポイント

• コンテキスト4層（システム・L0・L1・隣接本文）のうち1層が抜けるだけで、出力は平均に収束します
• キャッシングは、変わらないL0・L1を前に寄せ、変わる本文を後ろへ回す分離があってこそ生きます
• レビューゲートと廃棄率が機能してはじめて、進歩的な適用（クエストクラウド）も暴走しません

次章のプレビュー

• 5.4. ダイアログ・ボイスの一貫性 — voice_profileをAIで抽出・更新し、ボイスをレビューする

5.4 セリフ・ボイスの一貫性

収録ブース。ディレクターがヘッドホンを着け、手を挙げてキューを出します。声優が学者NPCのセリフを読み上げます。「와, 진짜 대박이네요（わあ、ほんとにすごいですね）」。ディレクターの手が止まります。このキャラクターは、5つの章を通して「와（わあ）」という感嘆詞を一度も口にしたことのない人物です。罵り言葉も、現代的な感嘆詞も口にせず、最後まで語尾を濁す学者です。それなのに、台本にはその行がそのまま載っています。

ここで2つのコストが同時に発生します。第一に、その行を直せば、声優は読み直さなければなりません。出演料とスタジオの時間は、すでに時計が回っています。第二に、もっと怖いのは、ディレクターがその行を捕まえられずに通してしまう場合です。収録が終わって音源がビルドに入れば、その学者はゲームの中で永遠にそういう話し方をします。収録した音源は、テキストのように1行の修正では元に戻せません。同じ声優の同じコンディション、同じブースをもう一度押さえなければならないのです。

本章では、そのブースの手前にある点線を扱います。点線の上はテキストなので無限に直せて、点線の下は音源なので直せません。すべてのセリフのレビューは、点線の上で終わらせなければなりません。そのためには、キャラクターごとに「この人はこう話す」が頭の中ではなくファイルとして記録されていて、新規セリフが上がってくるたびにそのファイルと自動で照合される必要があります。そのファイルをvoice_profileと呼び、照合ツールをvoice_lintと呼びます。

5.4.1 ボイスが揺らぐ場所

ナラティブの一貫性事故の中でもっとも頻繁に起きるのが、キャラクターボイスの揺らぎです。リリース後になってはじめて「このNPCはなぜ急に話し方が変わったのか」という報告が届きます。原因は毎回ほぼ同じです。

ライターが交代すると、同じNPCが別人になります。ライターが変わらなくても、6か月経てば本人が自分のトーンを忘れます。新規セリフを書くときにそのキャラクターの過去のセリフを開いて見なければ、コンテキストが途切れます。ボイスの規則がライターの頭の中にしかなく、文書になっていなければ、次の人には伝わりません。そして、ここ2年でもっとも速く増えた5つ目の原因 — キャラクター情報なしでLLMに「このNPCのセリフを作って」と投げると、AIは平均的で無難な、つまり誰の声でもないセリフを返してきます。

5つ目がAI導入の副作用です。前の章（5.3）のコンテキスト注入が処方箋ですが、注入するコンテキスト自体が貧弱なら、注入するものがありません。そのコンテキストこそがvoice_profileです。本章では、このファイルを作り、自動で検査し、収録ブースの手前で終結させる1サイクルを見ていきます。

5.4.2 voice_profile — 5項目で固定された声

プロジェクトAでは、すべてのNPCが5項目からなるvoice_profileを持ちます。語彙領域（よく使う単語群／絶対に使わない単語群）、文の長さ（平均・最大文字数）、敬語体系（一人称・二人称、敬語の比率、呼称）、感情表現（直接・間接・抑制のどの方式か）、禁止表現（絶対に使わない単語・構文）。5項目すべてに具体例が付いていなければなりません。「重厚な学者」のような抽象的な描写だけでは、人によって読み方が変わります。次のライターは、その学者を自分流に想像してしまうのです。

学者NPC K_007の実際のプロファイル形式は次のとおりです。このファイルがそのままvoice_lintの入力になります。

---
title: K_007 学者 voice_profile
layer: L1
character_id: K_007
atoms:
  - voice_profile_k_007
related:
  derives_from: [character_bible/k_007.md]
  affects: [dialogue_id_table (K_007のすべてのセリフ)]
---

## 1. 語彙領域
- よく使う: "기록", "근거", "정황", "추정", "데이터", "사례"
- 絶対に使わない: "느낌", "감", "운명", "신의 뜻", "마음의 소리"

## 2. 文の長さ
- 平均: 18字
- 最大: 35字 (それ以上は2文に分割)
- 短い途切れが多い: "...아닙니다." "기록부터."

## 3. 敬語体系
- 一人称: "저"
- 二人称: 役職優先(대장님, 사령관님)。親密になった後にのみ名前。
- 敬語100% (回想シーン除く)
- 感嘆詞はほぼなし。あるときは "...아."

## 4. 感情表現
- 直接表現はほぼなし (怒り・喜び)
- 沈黙・語尾を濁すことで表現 ("...그런 식이라면.")
- 悲しみ: 話題転換で回避 ("...다른 얘기 합시다.")

## 5. 禁止表現
- 罵り言葉は一切なし
- 現代的な感嘆詞 "와", "헐", "대박"
- 3音節以上の漢字語を一文に2個以上
- "운명", "예언" など神秘主義語彙

この形式の核心は、抽象の置き場ごとに例文の行が付いているという点です。「感情を抑制する」ではなく、"...그런 식이라면."（「……そういうやり方なら。」）という実際のセリフが付きます。そうしてはじめて、次のライターも、翻訳者も、voice_lintも同じ基準を見ることができます。 5項目を翻訳・ローカライズの目で見直すと、2つのグループに分かれます。言語依存の属性（語彙領域・文の長さ・敬語体系の表層形）は翻訳先の言語ごとに決め直す必要があり、言語非依存の属性（感情を抑えるのか直接表現するのか、何を最後まで言わないのかといった態度）は、どの言語に移してもそのまま守られなければなりません。ローカライズ作業を依頼するときにこの区分を一緒に渡せば、翻訳者が表層の語彙だけを変えているうちにキャラクターの態度まで揺らしてしまう事態を防げます。

5.4.3 ワークド・トランスクリプト：本文からprofileを汲み上げる

最初からNPC 50人×5項目=250件を白紙の状態で書こうとすると、抽象に流れます。本文が1行もないまま「このキャラクターは冷たい学者」と書いても、その冷たさが何なのかは誰にも分かりません。そこで、順序を逆にします。メインNPC 5〜7人だけを最初からフルで作成し、残りは本文のセリフが20〜30行たまった後に、そのセリフからprofileを逆抽出します。

以下は、K_007のセリフが25行たまった後にprofileの草案を抽出した、実際のワークド・トランスクリプトです。要約はせず、AIが間違えた箇所までそのまま載せます。

[ライターが投げたプロンプト全文]

以下はキャラクター K_007 のセリフ25行です。

1. "기록부터 봅시다."
2. "...정황이 맞지 않습니다."
3. "추정일 뿐입니다. 근거가 없어요."
4. "그 사례는 저도 알고 있습니다."
5. "...아닙니다. 데이터가 다릅니다."
   (... 6~23番は中略なしで全体引用 ...)
24. "...그런 식이라면, 저는 빠지겠습니다."
25. "다른 얘기 합시다."

ここから、よく使う語彙(実際に出たものだけ)、平均文長、敬称・呼称のパターン、
感情表現の方式、一度も使っていない表現領域、この5つを抽出して。
項目ごとに根拠のセリフ2~3行を番号で引用し、"重厚な"・"冷たい" のような
主観的な印象は書かないで。

[Claudeの生の出力 — 未加工]

1. よく使う語彙
   - "기록" (1番), "정황" (2番), "추정/근거" (3番),
     "사례" (4番), "데이터" (5番)
   → 事実・証拠系の名詞に集中。

2. 平均文長
   - 25行平均 約14.6字。最長21字(24番)。
   → 短い単文中心。

3. 敬称・呼称
   - 一人称 "저"(3·24番)。終結語尾 "-습니다/-요" の敬語。
   - 二人称の呼称はこの25行には登場しない。
     → 呼称パターンはこの標本だけでは断定不可。(ライター確認必要)

4. 感情表現
   - 直接の感情語なし。拒否は "빠지겠습니다"(24)で、
     悲しみ/回避は話題転換 "다른 얘기 합시다"(25)で処理。
   → 抑制・間接型。

5. 一度も使っていない領域
   - 感嘆詞、罵り言葉、神秘主義語彙はすべて未出現。
   ※ ただし、"未出現"が"禁止"だという保証はない。
      標本が25行と少なく、偶然の未出現の可能性がある。

ここで2つのことを押さえておく必要があります。第一に、AIは3番の項目で立ち止まりました。「この標本だけでは断定不可」と、自分で限界線を引いたのです。呼称は25行の中に出てこなかったので、推定しなかった — これが正直な出力です。もしAIが「二人称は『대장님（隊長殿）』と推定」と埋めていたら、それはハルシネーションであり、profileに入れば汚染になります。第二に、5番の項目でAIは自分から免責を付けました。「未出現≠禁止」は核心的な警告です。感嘆詞が25行に出てこなかったのは、偶然かもしれないのです。

[ライターの検証・拒否]

ライターは1・2・4番を採用しました。3番の呼称はcharacter_bibleを開いて「隊長殿（대장님）優先、親密になった後は名前」を手動で埋めました — AIが空けておいた場所を、人が埋めるのです。5番はAIの警告どおり、「未出現」をそのまま「禁止」に昇格させませんでした。代わりにライターがキャラクター設定に照らして「現代的な感嘆詞・罵り言葉・神秘主義」だけを禁止として確定し、残りの未出現語彙は保留としました。

[ライターの再依頼]

"운명", "예언" は禁止で確定する。意味の重なる神秘主義語彙をあと10個抽出して。
ただ、K_007は学者として反証・批判の文脈では引用する可能性もあるから、その例外ケースも
1行で一緒に表示して。

この最後の再依頼が重要です。禁止を機械的に広げると、「学者が迷信を批判しながら『運命などというものは』と言う」正当なセリフまで塞がれます。そこで、禁止には例外となる文脈を一緒に定義させます。AIが候補を広げ、ライターが境界線を引く。この一周を回してはじめてvoice_profile_k_007が確定し、L1に固定されます。

根拠の引用を強制し（「番号で引用」）、主観的な形容詞を禁止すれば（「重厚な・冷たい、の禁止」）、AIのハルシネーションが減り、ライターが検証できる表面が生まれます。profileはAIが書くものではなく、AIが草案を敷き、ライターが固定するものです。

5.4.4 voice_lint — 新規セリフごとに自動で照合

voice_profileがファイルとして存在すれば、新しいセリフが上がってくるたびに自動照合が可能になります。5つの検査のうち実戦で効果が大きいのは、禁止語彙のマッチング（語彙が禁止リストに引っかかるか）と語彙領域の違反（絶対に使わない単語群に入っているか）の2つです。文の長さの逸脱・敬語の欠落・頻出語彙の比率は偽陽性（false positive）が多いため、補助としてだけ使います。回想シーンの1行が平均の長さを揺らすことまで全部拾うと、ライターが警告に鈍感になります。

voice_lintは章の新規セリフの束を受け取り、次のようなレポートを出します。

voice_lint 結果 (ch04 新規セリフ32行, profile=voice_profile_k_007)
─────────────────────────────────────────────
[위반] dialogue_id_412 — K_007
  内容: "와, 진짜 대박이네요!"
  理由: 禁止語彙 "와", "대박" (profile §5)
  → ライターレビュー必要

[의심] dialogue_id_421 — K_007
  内容: "그 운명은 받아들이기 어렵습니다."
  理由: 禁止語彙領域 "운명" (profile §5)
        ただし '反証・批判の文脈' の例外可能 — ライター判定
  → ライターレビュー必要

[정상] 30件のセリフ
─────────────────────────────────────────────
要約: 위반 1 / 의심 1 / 정상 30

違反（[위반]）は赤、疑い（[의심]）は黄色です。どちらもライターの判定を経なければ通過できません。ここに絶対原則が1つあります — voice_lintは自動では拒否しません（5.2の原則の延長です）。上のdialogue_id_421を見てください。「運命（운명）」は禁止語ですが、学者が迷信に反論する文脈なら、正当な引用かもしれません。その判断はツールにはできません。自動拒否型のlintはこの微妙な場所を全部塞いでしまい、ライターからトーンを磨く機会まで奪います。lintは疑わしい箇所を照らす懐中電灯であって、扉に鍵をかける錠ではありません。

5.4.5 レビューゲート — 可逆と不可逆の間の点線

本章の背骨は、この1枚の図です。セリフ1行がライターの手を出発して声優の口に届くまでの間、レビューゲートが段階ごとに敷かれます。そして、その流れの真ん中に太い点線があります。

flowchart TD
    A["ライターによる本文執筆（L2）"] --> B["voice_lint自動
違反・疑いレポート"]
    B --> C["ライターのセルフレビュー（15分）"]
    C --> D["ナラティブリードのサンプルレビュー
章あたり10%サンプル"]
    D --> E["L3 dialogue_id発行
+ 翻訳キーマッピング"]
    E --> F["翻訳・ローカライズレビュー"]

    F -.->|"━━━ 可逆／不可逆の境界 ━━━
この線の上はテキスト、無限に修正可能
この線の下は音源、修正不可"| G

    G["VAキャスティング"] --> H["ボイス収録（最終・不可逆）"]
    H --> I["音源のビルド反映"]

    classDef reversible fill:#e8f4ea,stroke:#3a7d44,stroke-width:1px,color:#1b3a22;
    classDef irreversible fill:#f7e3e3,stroke:#b23b3b,stroke-width:2px,color:#5a1414;
    class A,B,C,D,E,F reversible;
    class G,H,I irreversible;

緑は可逆の段階、赤は不可逆の段階です。点線の上（緑）はすべてテキストです。セリフが1行気に入らなければ、キーボードで直せば済みます。コストはライターの数分です。点線の下（赤）は音源です。声優がブースでその行を読み、音源がビルドに入った瞬間、そのセリフはアセットとして固定されます。直すには同じ声優の同じコンディション、同じスタジオをもう一度押さえる必要があり、出演料・スタジオ・ディレクターの時間が最初とまったく同じだけ、またかかります。日程が厳しければ、同じ声優の追加セッション自体が押さえられないこともあります。

だから、たった1つのルールがすべてのワークフローを支配します — すべてのレビューゲートは点線の上で終わらせる。 収録はレビューの段階ではありません。レビューがすべて終わった結果を、アセットとして固定する段階です。点線の下で「このセリフ、おかしくないか」という疑問が生まれたら、それはさらにレビューすべき場所ではなく、上流のレビューが漏れていたというシグナルです。懐中電灯は点線の上ですべて照らし切らなければなりません。ブースは、暗くてもいい場所ではなく、暗くてはいけない場所なのです。

図の真ん中で、リードのサンプルレビューが「章あたり10%サンプル」と設定されています。この比率はレビュー時間と精度のバランス点です（著者の運用値、未検証の推定）。5%を下回ると事故が漏れ、20%を超えるとリード1人がボトルネックになります。lintが違反・疑いを先に濾し取ってくれるため、サンプルはlint通過分の中から抽出します — 人の目は、ツールには捕まえられない文脈の誤り（例：正当に見える「運命」の引用が、実はキャラクター崩壊）に集中します。

5.4.6 キャラクターは変わる — profileのバージョン管理

キャラクターが最後まで同じ話し方をすると、プロットが停滞します。仲間の死を経験した学者がその前とまったく同じトーンで話したら、むしろ嘘になります。変化が意図されたものなら、voice_profileも一緒にバージョンを上げます。

---
character_id: K_007
voice_profile_versions:
  - v1: ch01~ch05 (初期 — 感情抑制、短文の学者)
  - v2: ch06~ch10 (仲間の死後 — 感情表現の頻度増加)
  - v3: ch11~ (覚醒後 — 直接話法の登場)
---

バージョンごとにprofileファイルが別にあり、voice_lintは検査対象のセリフの章番号を見て、どのバージョンを適用するかを選びます。ch07のセリフにv1の「感情抑制」ルールを当てると、まともな変化のセリフが軒並み疑いとして上がってきます。変化はバグではなく、設計です。

バージョンを上げるシグナルは3つです。ライターが意図的にトーンを揺らすなら、新規バージョンを発議してリードと合意します。voice_lintの疑い件数が1人のキャラクターでだんだん増えていくなら、それはライターが無意識のうちにトーンを移しているという — バージョン更新の時期が来たというシグナルです。character_bibleに変化イベント（死・覚醒・裏切り）が追加されたら、profile更新のalertが上がります。ただし、1人のキャラクターが章ごとに変わると一貫性が崩れるため、現実的なバージョン数はキャラクターあたり2〜4個です。

[方向標識 — ボイス空間でキャラクター間を見るなら（まだ時期尚早）] voice_lintがルールによって「1人のキャラクターの中」の一貫性を守るものだとすれば、キャラクターごとの実際のセリフの束（1人のキャラクターが話したセリフ全体）を1つの点として埋め込んだ「ボイス空間」は、「キャラクター間」が十分に離れているかを見ます — 点同士が寄り固まっていくなら、それが§5.3.1・§5.4.1の指摘したボイスの平準化・収束の直接の測定値になります。ただし距離のしきい値を絶対値で固定せず、「寄り固まりつつある」という方向標識としてだけ読むべきであり、voice_lintを置き換える判定ゲートではありません（この発想は§8.2.7の次元ベクトル圧縮と同じ位置にあり、概念の直観は付録Mに地図1枚で解説してあります — 処方箋ではなく方向標識です）。

5.4.7 多言語・VAで増える一貫性の単位

セリフが多言語に翻訳され、声優のボイスが乗ると、管理単位は掛け算式に増えます。韓国語の1行が英語・東南アジアの言語へと枝分かれし、そのそれぞれにトーンが乗ります。

翻訳の一貫性でもっともよく漏れるのは、同じ表現が章ごとに違う訳になることです（翻訳メモリの一貫性チェックで拾います）。キャラクターのvoice_profileが翻訳に反映されないこと（キャラクター別の翻訳ガイドを別途付けます）、新規語彙が用語集に未登録であること（用語集lint）がそれに続きます。翻訳ガイドはvoice_profileから自動生成します — 「このキャラクターはフォーマルな敬語100%、感嘆詞なし、神秘主義語彙は禁止」を翻訳指示書の先頭に自動で付けます。翻訳者がその学者を英語に移すとき、同じ境界線を見ることになります。

VA（Voice Actor、声優）のレビューは、点線の下に触れる直前 — テキストとして可逆な最後の段階のレビューです。トーンの一貫性（怒り・悲しみの表現の強さ）はディレクターとナラティブが、発音の正確さ（固有名詞）は用語集の担当が、呼吸・区切り（profileの「短い途切れが多い」のような指示）はディレクターが見ます。レビュー結果はvoice_review_log.md（L4）に通過・差し戻しとして記録し、次のキャラクターのキャスティング時に参照します。

差し戻しは、できる限りキャスティング・収録の直前までに終わらせます。ブースの中で見つかる台本の誤りは、その日のセッションを丸ごと崩し、次のセッションの日程まで揺らします。かといって、収録を遅らせながらレビューを引きずるのが答えでもありません。レビューがブース直前で頻繁に詰まるなら、それは上流（ライター・リード）のワークフローが遅いのであって、収録日程の問題ではないのです。

5.4.8 6か月の測定とコスト

プロジェクトAで、voice_profile+voice_lintの導入前後を6か月追跡しました。絶対件数は著者の推定（未検証）です。方向と比率だけを信頼してください。

もっとも意味のある行は、ライター1人あたりの管理NPC数です。約2.5倍というのはライターを減らしたという意味ではなく、同じライターが章あたりのNPCの多様性を増やせるという意味です。世界が、より賑わうのです。

コスト構造を見ると、導入コストよりも運用コストのほうがはるかに小さくなっています。voice_profileの作成はメイン7人にライター2週間、voice_lintツールは開発1〜2週間に保守が月1日。運用側は、章あたりライターのセルフレビュー15分、リードのサンプルレビュー約2時間（10%サンプル）、変化のある章のprofile更新がキャラクターあたり1〜2日です。運用コストが小さくなければ、システムは生き残れません。運用が重いツールは、一四半期のうちに静かに廃棄されます。

5.4.9 よくある失敗

やってみよう — voice_lint 1サイクル

新しい章のセリフが上がってきたとき、profile 1つで一周回す最小の手順です。

setup 1. 対象キャラクターのvoice_profile_<id>.mdを開きます。なければ本文のセリフを20〜30行集めます。 2. 新規セリフをid / 캐릭터 / 내용（id／キャラクター／内容）形式のプレーンテキストの束として準備します。

prompt

K_007の voice_profile §5(禁止表現)だ。
[禁止リストを貼り付け]

ch04 新規セリフ32行。
[id / 内容 の形式で貼り付け]

各セリフを [위반](禁止語彙を直接含む) / [의심](禁止領域に触れるが例外文脈の可能性)
/ [정상]に分類して。[위반]·[의심]は id·内容·理由を表に。判定は私がやるから
自動で拒否はしないで。

verify 1. まず[위반]（違反）から見てください。明白ならテキストを直します（点線の上なので無料です）。 2. [의심]（疑い）は文脈で判定します。正当な引用なら通過、そうでなければ修正します。 3. 通過分から10%をサンプルとしてリードに送り、文脈の誤りをもう一度濾します。 4. すべての判定が終わった後にのみdialogue_idを発行し、収録キューへ回してください。ブースの手前では、もう検査しません。

一人ミニ版 — ツールを作れない個人開発者なら、voice_profileをキャラクターあたり§5（禁止表現）の1項目だけ書いてください。新規セリフを書くたびにその禁止リストをプロンプトの先頭に付け、AIに「このリストに引っかかる行だけ表示して」と指示します。ツールなしでも、プロンプト1行でlintの80%が得られます。収録（またはTTS）に回す前にこの一度だけ通せば、ブース手前の点線は守られます。

本章のポイント

• ボイスの揺らぎの5つの原因のうちAIによる平準化がもっとも速く増えており、処方箋は貧弱なコンテキストではなく、実例の載ったvoice_profileです。
• voice_lintは違反・疑いを表示するだけで、拒否は人が行います。禁止には例外の文脈を一緒に定義します。
• すべてのレビューは収録ブース手前の点線の上で終わらせます — 点線の下の音源は、テキストのようには戻せません。

次章のプレビュー

• 6.1. プロシージャルコンテンツ生成とAI — どこで出会うのか

第6部 · Content Design

6.1 プロシージャルコンテンツ生成とAI — 二つの軸が交差する一マス

月曜の朝の企画会議。ホワイトボードに一行が書かれています。「リリースまでにサイドクエスト1,000本」。誰かが電卓を叩きます。ライター1人が1本に1日をかけると4年。5人がかりでも1年近くかかります。部屋の空気が重くなります。24年間この部屋に座り続けてきた私は、この数字を前に人々がいつも同じ二手に分かれることを知っています。一方は「分量を減らそう」と言い、もう一方は「ツールで量産しよう」と言います。そして決定は、ほぼ毎回その両方でした。

プロシージャルコンテンツ生成（Procedural Content Generation、以下PCG）は、その「ツールで量産しよう」側の古くからの答えです。ダンジョンの部屋配置、武器オプションの組み合わせ、敵スポーンプールは、20年前からルールブックと確率テーブルで自動化されてきました。新しいのはPCGそのものではなく、自然言語・画像・物語が入る場所にLLMと生成モデルが載ってきたという点です。

ただし本書で語ろうとしているのは、「AIをPCGに付けましょう」ではありません。それは誰でもやります。問題はどこに付けるかです。コンテンツの一かたまりを置いて、それが自動化のどの強度と、構造のどの層で出会うのかを一つのマスとして確定しないと、ツールはあるのに居場所がない状態になります。本章では、その一マスを座標として描く方法、そしてそのマスの上でコンテンツ一つが実際にパイプラインを一巡する様子を見ていきます。

6.1.1 PCGが止まっていた場所

伝統的なPCGは決定論に強い領域です。同じ入力には同じ出力が返り、検証が可能です。ダンジョンの部屋グラフ、武器オプションのprefix・suffix、敵スポーン分布は、だからこそ早くから定着しました。「炎の剣+5」は20年前にも自動で出ていました。

問題は、常にその次の場所でした。部屋は配置されても、部屋の中のNPCの名前・外見・短い背景はライターの手に残りました。「炎の剣+5」は出てきても、「王が失った最後の剣」という一行は出てきませんでした。クエストジェネレーターが目標と報酬の組み合わせを出してくれても、「なぜこのクエストをやるのか」は人が書いていました。

規模の大きいゲームでは、この場所が常にボトルネックでした。量産可能な領域と人手が必要な領域の比率はおよそ4対6で、その人手側の6が日程の大半を食っていました。量産ラインが4の側を速く作っても、6の側が追いつかなければ、サイクル全体がその速度に縛られます。

LLMと画像モデルが入ってくる場所が、まさにそこです。ルールブックが扱えなかった自然言語・物語・ビジュアルの領域まで、量産可能な範囲が広がります。だからといって、その場所を丸ごとAIに渡すのが答えではありません。AIは毎回少しずつ違う答えを出し、コンテキストが空だと「一般的なRPGの平均値」を吐き出します。だから結合点の設計が必要です。結合点は、二つの座標軸で定義されます。

6.1.2 一つ目の軸：自動化強度（L0〜L3）

縦軸は、人とルールブックとAIをどんな比率で混ぜるかです。私が働くとあるMMORPG開発会社（以下「プロジェクトA」）では、四段階に区切って使っています。

L0 — 完全手作業。 すべての文字・決定が人の手から生まれます。メインクエストの本文、シグネチャーキャラクターのセリフ、分岐エンディング。一貫性と物語の深さがゲームのアイデンティティに直結する場所です。

L1 — ルールブック自動化。 伝統的なPCGの場所です。ルールブック・確率テーブル・BSPのような決定論アルゴリズムが出力を作り、人はチェックだけを行います。ダンジョンの部屋配置、武器オプションの組み合わせ、敵スポーンが代表例です。

L2 — ルールブック+AI補助。 ルールブックが骨格を組み、AIがディテールを埋めます。サイドクエストのシノプシス、一般NPCの名前・短い背景、狩場の紹介文。人は入力メタデータと最後のレビューゲートだけに責任を持ちます。

L3 — AI優先+人によるレビュー。 AIが本文を作り、人はレビューだけに入ります。魅力的ですが、非決定性・ハルシネーション・一貫性毀損のリスクがすべてここに集まります。

核心はL2です。L1の安定性とL3の量産力を組み合わせ、二つの領域の短所は検証ゲートで防ぎます。L3は早く導入したくなる誘惑が大きいのですが、レビュー負担が膨れ上がって1〜2四半期のうちに廃棄される事例を何度も見てきました。100本のうち70本が要確認項目として上がってくるなら、人が最初から100本書くほうが安上がりです。

6.1.3 二つ目の軸：Layer構造（L0〜L4）

縦軸だけでは、量産ラインは回りません。コンテンツそのものが層に分解されていてこそ、自動化が入り込む場所が生まれます。これが第5部で扱ったLayer分解であり、コンテンツ分野における横軸です。五つの階層がそれぞれプロシージャル生成における一つの役割（アンカー・ルールブック・本文・数値・ゲート）に対応するという一般論は§2.3.6で扱ったため、ここではコンテンツ量産ラインにそのまま当てはめます。Layer 0のビジョンはトーン・世界観のアンカー（生成のたびに注入）、Layer 1のシステムは生成ルールブック（規則・確率テーブル・タグ体系）、Layer 2のコンテンツは生成結果が積み上がる本文の場所（サイドクエスト・NPCの背景・都市の紹介文）、Layer 3のデータは数値・ID・関係（報酬・スポーン・カーブ）、Layer 4のビルド・QAは検証ゲート（lint・一貫性チェック・ライターによるレビュー）です。

この二つの軸は、別の話です。縦軸は「人がどれだけ手を入れるか」、横軸は「コンテンツのどの部位か」を語ります。しかし、二つは掛け算でしか意味を持ちません。コンテンツ一つを二つの軸の交差点、すなわち一つのマスに確定したとき、初めて「これは誰が、どこを、どう作るのか」が決まります。

6.1.4 二つの軸を一枚に — 自動化×Layerマトリクス

ここまで文章でほどいてきた二つの軸を、一枚のグリッドとして重ねてみます。横はコンテンツのLayer、縦は自動化強度です。各マスに入ったラベルは、プロジェクトAで実際にそのマスを占めているコンテンツです。色が濃いマスほど、量産ラインの重心に近い場所です。

このグリッドが本章の核心です。散文として散らばっていた「メインはL0」「サイドはL2」「報酬はルールブック」といった判断が、一つの座標に集まります。会議で新しいコンテンツが議題に上がったら、「これはどのマスか」という一つの質問で済みます。マスが決まれば、そのマスの縦座標が「誰が手を入れるのか」を、横座標が「どの部位なのか」を教えてくれます。

グリッドを読んでいると、二つのことが目に入ります。第一に、重心（濃いマス）はL2行×Layer 2列にあります。サイドクエストの骨格・NPCの背景がその場所です。量産ラインの心臓部です。第二に、一つのコンテンツが一つのマスにだけあるわけではありません。サイドクエストは本文（Layer 2）がL2のマスにありますが、その報酬数値（Layer 3）はL1のマスへ下ります。同じクエストでも、部位ごとに違うマスに住んでいます。これが、二つの軸を分離しておいた理由です。

6.1.5 一つのマスの上で回るミニパイプライン

重心のマス — L2行×Layer 2列、サイドクエストの骨格 — の上で、コンテンツ一つが実際に一巡する様子を見ます。流れは次のとおりです。

flowchart TD
    A["Layer 0 ビジョン注入
(トーンアンカー: 東洋風の田舎の村)"] --> B["Layer 1 ルールブック
(目標・報酬スロットの骨格生成)"]
    B --> C["L2 AI補助
(NPCの動機・一行背景の補完)"]
    C --> D{"Layer 4 レビューゲート
(トーン・一貫性lint)"}
    D -->|合格| E["Layer 3 データ確定
(報酬数値はルールブックが算出)"]
    D -->|差し戻し| B
    E --> F["ビルド反映"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D code;
    class C ai;
    class E data;
    class F pass;

この流れを、ワークド・トランスクリプトで一度たどってみます。田舎の村のおつかいクエストを一つ作るとしましょう。

ステップ1 — Layer 1のルールブックが骨格を出します。 ルールブックは決定論です。スロットを埋めただけの形で出てきます。

[クエスト骨格 — ルールブック出力]
地域: 향촌_3
依頼人役割: 薬草採り
目標タイプ: 収集(薬材 x6)
妨害要素: 狼スポーン(夜)
報酬スロット: { gold: ?, exp: ?, item: 採集鎌 }

ステップ2 — AIにディテールを依頼します。 プロンプトの全文は次のとおりです（Layer 0のビジョンをコンテキストとして先に入力します）。

あなたは東洋ファンタジーの田舎の村を舞台にしたMMORPGのクエストライターです。トーンアンカー：「素朴だが迷信と恐れが底に流れる田舎」。以下の骨格を受け取り、依頼人の動機一行とNPCの名前、そしてプレイヤーに見える依頼文二文を書いてください。報酬数値は絶対に作らないこと（システムが決めます）。出力はJSON。 骨格：{ 地域: 향촌_3, 依頼人: 薬草採り, 目標: 薬材6個の収集, 妨害: 夜の狼, 報酬アイテム: 採集鎌 }

ステップ3 — Claudeの生の出力。（要約せず、そのまま載せます）

{
  "npc_name": "삼월 어멈",
  "motive": "夜ごとの狼の遠吠えで薬草畑が荒らされ、最後の薬材を採りに行く気力が出ない。",
  "quest_text": "夜になると狼どもが薬草畑を荒らしていくのじゃ。怖くて足がすくんでしもうて、山すその薬材六株だけ、わしの代わりに採ってきてくだされ。",
  "reward": { "gold": 120, "exp": 300 }
}

ここで立ち止まって見るべきものがあります。AIはrewardフィールドを、指示していないのに作って入れました。これこそが、1軸と2軸がなぜ分離されるべきかをそのまま見せてくれます。報酬数値（Layer 3）はL1ルールブックの場所であって、AI（L2）の場所ではありません。AIにそれを任せると、呼び出しのたびに数字が揺れて、報酬カーブが崩れます。

ステップ4 — 人による検証・拒否。 レビュー担当者は二つのことを行います。(1) rewardフィールドを削除します — これはルールブックが埋めるマスです。(2) トーンを見ます。NPC名「삼월 어멈」（サムウォル・オモム、「三月ばあさん」の意）、動機の一行、依頼文の二文は村のトーンに合っています。合格です。もしAIが「魔法使いギルドの依頼」のような世界観の外の単語を入れていたら、ここで差し戻して骨格の段階に戻します。

ステップ5 — Layer 3のデータ確定。 削除された報酬スロットを、ルールブックが埋め直します。地域レベル・目標難易度に紐づいた決定論の公式です。gold: 85, exp: 240。AIが勝手に吐いた120・300ではなく、カーブに合った値が入ります。

この一巡が、重心マスの標準サイクルです。ルールブックが骨格、AIが肉付け、人がゲート、ルールブックが再び数値。コンテンツ1,000本が、すべてこのサイクルを回ります。マスが決まっているので、毎回「これは誰が作るのか」を議論し直すことはありません。

6.1.6 マスを決めるときに投げる五つの質問

新しいコンテンツをグリッドのどのマスに置くかを決めるには、五つの質問が役に立ちます。会議で量産の議題が上がるたびに書き留めて一緒に答えてみると、マス配置の一貫性が1四半期のうちに定着します。

一つ、量産の負担はどれほどか。リリースまでにN本必要か。Nが100を超えると、L0行はほぼ不可能です。

二つ、一貫性の要求はどれほど大きいか。コンテンツ間の一貫性が体験の核心ならレビューゲート（Layer 4）が強くなければならず、多様性が核心なら、より上の行へ行く余地があります。

三つ、非決定性を許容できるか。毎回少しずつ違う結果が豊かさを生む領域なのか、同じ結果が信頼の核心である領域なのか。

四つ、レビューコストはどれほどか。コンテンツ1本あたり5分なのか30分なのかが、運用サイクルの長さを決めます。

五つ、事故が起きたときのコストはどれほどか。廃棄・書き直しが自由なのか、一度世に出たらユーザーに影響する事故に直結するのか。

サイドクエストにこの五つを投げると、答えは一方向に集まります。1,000本以上（L0不可）、一貫性はメインより低い、非決定を許容、レビューは5〜10分、事故コストは低い（個別廃棄が可能）。五つの答えが揃うので、L2行×Layer 2のマスが自然です。同じ五つをメインクエストに投げると、正反対に集まります。50本、一貫性・物語の深さは最高、非決定は不許可、レビューコストは大きい、事故コストは非常に大きい — L0のマスです。

6.1.7 よくある四つの落とし穴

グリッドを描いておいても、はまる落とし穴は似ています。四つが繰り返されます。

第一に、L3行から始めるケース。「AIが勝手に100本」という期待で出発すると、レビューが爆発的に増えます。L1のマスを先に定着させ、L2へ上がり、L3は一部にだけ慎重に。先ほどのミニパイプラインで報酬フィールドを人が消したあの一動作が、L3行がなぜ危険なのかを小さく見せてくれます。

第二に、ルールブックなしで丸ごとAIに委任するケース。「サイドクエストを100本作って」は、一般的なRPGの平均値を呼び込みます。Layer 1のルールブックが骨格を先に組み、AIがその上で肉付けをしてこそ、「私たちのゲーム」のコンテンツが生まれます。ルールブック一冊を書く仕事は、PCGで最も手間がかかり、最も面白くない作業ですが、これを飛ばすと、その上のすべての量産が平均値に沈み込みます。

第三に、レビューゲート（Layer 4）が空のケース。 AIの出力が自動でビルドに反映されると、一貫性インシデントに直結します。どのマスであれ、人のゲートは必須です。

第四に、コストだけを見てツールを決めるケース。 LLM APIのコストは四半期ごとに下がりますが、一貫性インシデントのコストは下がりません。ツールの決定は、APIコストに一貫性・レビュー時間の合計を加えて見ます。

6.1.8 測定 — 重心のマスへ移した6か月

プロジェクトAでサイドクエストをL0のマスからL2のマスへ移した後、6か月を測定しました。以下の数値のうち絶対値は著者の推定（未検証）であり、変化の方向と比率が実測で観察された部分です。

廃棄率は20%に上がりましたが、量産速度が6〜8倍なので、正味のスループットは4〜5倍に増えました。一貫性インシデントは四半期あたり5〜8件へと小幅に増えましたが、レビューゲートとルールブックの補強で、四半期のうちに正常範囲へ戻りました。

最も大きな変化は、数字ではなく人でした。最初はライターたちが「量産のレビュー係」になった気分だと言い、満足度が8から6に落ちました。これを回復するために、メインクエストとシグネチャーサイドクエスト（都市あたり1〜2本）にライターの時間を明示的に保証するポリシーを挟みました。量産ラインがライターの時間を吸い上げるのではなく、その時間をメインへ送り返すツールになるよう、はっきり決めたのです。6か月後、満足度は7に戻りました。

この測定から持ち帰るべきことは一つ。マスを移す決定は、スループット・ライターの時間配分・満足度が一緒についてこなければなりません。スループットだけを見れば量産は成功ですが、人は去っていきます。

6.1.9 Layer分解が先、PCGはその上に

Layer分解がプロシージャル生成の前提だという一般論は§2.3.6にあります。ここでは、それがPCGグリッドの上でどう現れるかだけを見ます。横軸（Layer 0〜4）が曖昧なチームでは、どのマスも安定して回りません。Layer 0のビジョンがどこにあるか分からなければ、ジェネレーターごとにトーンアンカーが空になって一般的なRPGの平均値が出てきますし、Layer 1のルールブックとLayer 2の本文が一つのファイルに混ざっていれば、規則一行を直すたびに本文の数十か所を一緒に触らなければならず、Layer 3のデータが本文に書き込まれていれば、報酬カーブの一度の調整にライターが1週間を使います — 先ほどのミニパイプラインで報酬を別のスロットとして切り離しておいた理由が、これです。

だからPCG導入の前に点検すべきは、ツールの選択ではなく、横軸が分解されているかです。5層が揃ったチームでL1のジェネレーターを付けるコストは、ライター1人の1四半期分です。5層が混ざったチームで同じ導入をすると、2四半期のうちに一貫性インシデントで廃棄されます。

最初から五つのマスが完璧である必要はありません。分離は漸進的に、インターフェースは狭く。最初の四半期にはLayer 0のトーン一行とLayer 1のルールブック一冊だけを切り離しておくだけでも、ジェネレーターが入る場所が開きます。だからといって、無限に先送りしてよいという意味ではありません。Layer 2の本文とLayer 3のデータが最後まで一かたまりのままなら、次章の具体的なツールも居場所を持てません。

6.1.10 次章のプレビュー

次章では、このグリッドの重心マスを占める具体的なツールを一つ解剖します。都市別の狩場を量産するproj_city_hunting_generatorです。入力メタデータ・ルールブックの骨格・AI本文・検証ゲートが一つのサイクルにどう束ねられるのか、本章のミニパイプラインが実際のツール規模でどう大きくなるのかを見ます。

本章のポイント

• 自動化強度（縦L0〜L3）とLayer構造（横0〜4）は、掛け算でしか意味を持ちません。
• 量産ラインの重心はL2行×Layer 2のマス、サイドクエストの骨格です。
• 横軸の分解が先で、PCGはその上の一マスでだけ回ります。

やってみよう — コンテンツ一つを一つのマスに載せる

setup. 量産候補のコンテンツを1種類選んでみましょう（例：サイドクエスト）。Layer 0のトーン一行と、Layer 1のルールブック骨格（スロット定義）を別ファイルとして切り離しておきます。報酬数値のスロットは、ルールブック側に空けておきます。

prompt. ビジョンをコンテキストとして入力した後に骨格を渡し、「報酬数値は作らないこと、出力はJSON」を明示しましょう。先ほどのステップ2のプロンプトを、そのまま変形して使えば大丈夫です。

verify. 三つを確認しましょう。(1) AIが報酬フィールドを勝手に入れていたら削除します（L3はルールブックの場所です）。(2) 世界観の外の単語があれば、骨格の段階へ差し戻します。(3) 合格分だけ、ルールブックが報酬数値を埋めてビルドに入れます。

一人ミニ版。 チームがなくても大丈夫です。自分でルールブック一冊（スロット5個）とトーン一行だけを、テキストファイルとして作ってみましょう。クエスト10本を先ほどのサイクルで回してみて、レビューで何本を差し戻すか数えてみてください。差し戻し率が30%を超えるならマスが間違っているということなので — ルールブックの骨格をより細かくするか、一つ下の行（L1）へ下げてもう一度見てみましょう。差し戻し率が安定すれば、それが自分の規模でそのマスが機能しているという合図です。

6.2 city_hunting_generator — 30の都市を4週間で作る

想定読者：コンテンツ量産を担うMMORPGプランナー（中規模（10〜50人）チーム） ソロ/趣味の読者向け縮小版：§6.2.10「一人ならここまで」

リリースまでに30の都市が必要だというスケジュール表を初めて受け取った日の計算を、いまだに覚えています。1つの都市は、紹介文5〜10行、狩り場3〜5か所、狩り場ごとに5〜10人のNPCと2〜3本のサイドクエスト、特産アイテム1〜3種、都市ボス1体で構成されます。手作業で1つの都市を作り込むと1〜2週間かかります。30都市なら、シナリオライター1人が6か月を丸ごと都市だけに費やす計算です。

ところが、その6か月はありませんでした。ライターの時間はメインクエストとシグネチャーキャラクターに割かれており、30の都市はその作業と並行して進める必要がありました。「AIに30の都市を作ってもらえばいいのではないか」という最初の衝動は、すぐに崩れました。丸ごと任せると、互いによく似たファンタジーの村が30個出てくるのです。本章では、その衝動の代わりに作ったツールcity_hunting_generatorが、入力・ルールブック・AI・検証の4段階をどのように1つのサイクルにまとめたのか、そしてそのサイクルを実際に最後まで1回回すと何が出てきて何が破棄されるのかを見ていきます。

著者の実運用メモ 本章のcity_hunting_generatorは、著者が会社のR&Dフォルダで運用している実際のツールを匿名化したものです。ファイル名・コード構造・検証項目は実際のツールを忠実に写し、都市名（silvermarkなど）・会社固有の名称は書籍用に置き換えました。出力本文は実際のセッションを再構成したものです。

6.2.1 人はメタデータと最後のレビューだけを行う

ツールの全体フローは4段階です。要は、第1段と第3段が決定論（ルールブック）で、AIなのは第2段だけだという点です。ルールブックが骨格と検証を両側から押さえていれば、間に挟まったAIが毎回少しずつ違う答えを出しても、都市間の一貫性は揺らぎません。人が関わるのは、最初の入力（メタデータ）と最後のゲート（レビュー）だけです。

flowchart TB
    A["入力: 都市メタデータyaml
(人が15〜20分/都市)
lore_seeds 3個 ・ forbidden_names 自動付与"]
    A --> B["第1段 決定論: rules.py
generate_skeleton()
狩り場数・敵分布・報酬カーブ・ボス"]
    B --> C["第2段 AI: プロンプト3種
L0ビジョンのキャッシュ + L1ルール注入
+ L2隣接都市の本文
→ 紹介文・NPC・サイドクエスト"]
    C --> D{"第3段 決定論: lint
名前重複・禁止語・ボイス
・分量・報酬範囲"}
    D -->|違反alert| E["第4段 ライターレビューゲート
(5〜10分/都市)
破棄・再生成を決定"]
    E -->|再リクエスト| C
    E -->|通過| F["ビルド反映"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D code;
    class C ai;
    class A,E human;
    class F pass;

この図で人の手が入る場所は2か所だけです。一番上でメタデータ1ページをきれいに入れる場所と、一番下でlintには拾えないトーンや物語の判断を下す場所。その間の退屈な骨格生成と本文量産は、ルールブックとAIが回します。決定的な設計は、lint（第3段）が違反を見つけても自動では破棄せず、ライターゲート（第4段）にalertを上げるだけにしている点で、その理由は§6.2.5で見ます。

6.2.2 入力 — 都市メタデータ1ページ

ライターは都市1つにつきメタデータを1ページ書きます。作成時間は15〜20分。短いですが、この1ページが続く3段階の入力のすべてです。

# city_021_silvermark.meta.yaml
city_id: city_021_silvermark
region: west
climate: cold_arid
dominant_faction: scholar_guild
cultural_tone: scholarly_strict
level_range: [25, 30]
lore_seeds:
  - 100年前に魔法封印の中心地だった
  - 封印弱体化の最初の兆候がこの都市で観測された
  - 学者ギルド本部の所在地
neighbors: [city_018, city_023]
# forbidden_names: (スクリプトが自動付与 — ライターの入力は不要)

もっとも重要なスロットはlore_seedsです。3〜5個の中核となる出来事が都市のアイデンティティを決めます（silvermarkの例では「100年前に魔法封印の中心地だった」「封印弱体化の最初の兆候がこの都市で観測された」「学者ギルド本部の所在地」の3つです）。少なすぎるとAIはありきたりなファンタジー都市を吐き出し、多すぎると出来事同士が矛盾します。著者の経験では、3個がもっとも安定していました。

forbidden_namesはライターが記入しません。既存の都市・キャラクター名のリストをスクリプトが読み込み、メタデータに自動付与します。30都市 × 平均50人のNPCが積み上がると、1,500個の名前の重複を人の頭で検査するのは不可能だからです。「他の都市のNPCと被らないようにして」と毎回手で書く必要はありません。

6.2.3 第1段ルールブック — 決定論で骨格を作る

ルールブックはメタデータを受け取り、都市の構造骨格を作ります。コードは単純です。

# city_hunting_generator/rules.py (骨格)
def generate_skeleton(meta):
    region_rules = REGION_RULES[meta.region]
    hg_count = region_rules.hunting_grounds_range.sample()
    enemy_dist = ENEMY_RULES[meta.climate][meta.dominant_faction]

    skeleton = {
        "hunting_grounds": [
            {
                "id": f"{meta.city_id}_hg_{i}",
                "level": meta.level_range[0] + i,
                "enemy_types": enemy_dist.sample(k=3),
                "reward_curve": calc_reward(meta.level_range[0] + i),
                "npc_count": region_rules.npc_per_hg,
                "sidequest_count": region_rules.sidequest_per_hg,
            }
            for i in range(hg_count)
        ],
        "boss": {
            "id": f"{meta.city_id}_boss",
            "level": meta.level_range[1] + 2,
            "pattern": BOSS_PATTERNS[meta.region],
        },
    }
    return skeleton

結果は決定論的です。同じメタデータを入れれば同じ骨格が出てきます。報酬カーブがregion・levelごとの標準範囲内にあるか、敵分布がclimate・factionのルールに合っているかがコードで保証され、リグレッションテストで捕捉できます。この段階は絶対にAIに任せません。報酬カーブをAIが呼び出しのたびに違う数字で出してきたら、都市間のバランスがその場で崩れるからです。

silvermarkのメタデータを入れると、rules.pyは狩り場4か所（city_021_silvermark_hg_0〜hg_3）、各狩り場にNPCスロット6枠・サイドクエストスロット3枠、そしてレベル32のボス1体という空の骨格を返します。まだ名前も本文もない、埋めるべき枠の表です。その枠を埋めるのが第2段AIの仕事です。

6.2.4 第2段AI — 自然言語の本文生成

ルールブックが骨格を作ったあと、AIがその上に自然言語の本文を埋めていきます。都市紹介文、NPCの名前・外見・短い背景、サイドクエストのシノプシス、特産アイテムのフレーバーテキストがここで生まれます。

呼び出しパターンは、コンテキスト注入の4層構造そのままです。L0ビジョン（world_premise + tone_manifesto）をキャッシュし、L1ルール（city_naming_rule + region_west_lore）を選択注入し、L2隣接本文（他都市のNPC名リスト）を加え、最後に作業指示を付けます。都市紹介文のプロンプトは、そのままコピーして使える形です。

[L0 コンテキスト] world_premise + narrative_pillar + tone_manifesto  (キャッシング)
[L1 コンテキスト] city_naming_rule, region_west_lore
[入力] city_021_silvermark.meta.yaml + lore_seeds 3個

この都市の紹介文を6~8行で書いて。lore_seedsの3つすべてを自然に織り込み、
「平和な村」のようなRPGの常套句は抜きで。トーンは学者的かつ厳格に、感傷は抑制。
本文のみ、前置きや解説なしで。

このプロンプトの指示内容は、「この都市の紹介文を6〜8行で書くこと。lore_seedsの3つすべてを自然に織り込み、『平和な村』のようなRPGの常套句は排すること。トーンは学者的かつ厳格に、感傷は抑制。本文のみで、前置きや解説は不要」というものです。

同じパターンが、NPC量産、サイドクエストの呼び出しにもそのまま繰り返されます。違いはコンテキストと出力形式だけです。NPCの呼び出しにはforbidden_names（他都市のNPC名との重複禁止）スロットが入り、サイドクエストの呼び出しには「依頼主のNPCは上で生成したNPCの中から選ぶこと」という制約が入ります。

では、実際に何が出てくるのか。一度最後まで回してみます。

6.2.5 1サイクルを最後まで — 出力・検証・破棄

抽象的に「AIが本文を埋める」とだけ書いたのでは、このツールが実際に何を吐き出すのかは分かりません。silvermarkという1つの都市のサイクルを、入力から破棄まで一度最後まで追いかけます。

[第2段AI出力 — 都市紹介文]（実際のセッションの再構成）

シルバーマークは封印の都市である。100年前、七人の学者が西方の魔力の氾濫を食い止めるためにこの地の地下に封印陣を築き、都市はその陣の上に石を一枚ずつ重ねて育っていった。学者ギルド本部の鐘楼は封印の脈を読む観測所であって、神に向かう尖塔ではない。ここ3年、観測記録には同じ一行が繰り返し記されている。「脈が冷えていく」。封印弱体化の最初の兆候は、ほかのどこでもない、この都市の計器盤で最初に震えた。街の学者たちはそれを大声では語らない。ただ、鐘楼の火が一晩中消えない日が増えただけである。

ここでは、lore_seedsの3つ（封印の中心地・弱体化の最初の兆候・学者ギルド本部）がすべて本文に盛り込まれ、「冒険者を歓迎する平和な村」のような常套句がなく、scholarly_strictのトーン（感傷の抑制、観測・記録の語彙）が維持されています。これが通過できる出力の姿です。

続いて、同じサイクルが狩り場hg_0のNPCスロット6枠のうち3枠を埋めます。

[第2段AI出力 — NPC 3人]（実際のセッションの再構成）

1) ドレン・ベイル（Doren Vale） — 鐘楼の観測助手。50代、片目に真鍮の拡大鏡を常時装着。封印の脈の微細な振動を記録する仕事を30年続けている。口数が少なく、数字でしか会話しない。「今日12.4。昨日12.1。上がっている。良いことじゃない」

2) ミラ・コスト（Mira Kost） — ギルド文書庫の司書。30代、指のインク染みが消えない。封印陣の設計原本を守っているが、その図面を読める学者はもう皆死んだと信じている。外部の人間への警戒心が強い。

3) グレム（Grem） — 鐘楼の下の炉番。正体不明、年齢不詳。鐘楼の火を絶やさないことが唯一の仕事で、封印について尋ねる者には「火だけ見ていればいい」とだけ答える。（あいまいフラグ — AIによる自己申告）

3人目のNPC「グレム」に、AIが自らあいまいフラグを付けた点に注目してください。良いプロンプトは、AIが「これは確信が持てません」と言えるようにします。次は、第3段のlintがこの出力一式を検査します。

[第3段lint出力]（実際の形式）

[PASS] 分量検査: 紹介文7行 (基準6~8)
[PASS] 報酬範囲: hg_0~hg_3 reward_curve 標準範囲内
[WARN] 名前重複: "Mira Kost" — city_014_riverholdの"Mira Veldt"と
       姓(Kost/Veldt)は相違だが名(Mira)が同一。forbidden_names 近接衝突。
[PASS] 禁忌語彙: tone_manifesto 違反0件
[WARN] ボイス一貫性: "グレム" の台詞 voice_lint 信頼度0.62 (しきい値0.70未達)

lintは違反を2件 — Mira Kostの名前の近接衝突（riverholdのMira Veldtとファーストネームが同一）と、グレムの台詞のボイス一貫性（voice_lint信頼度0.62、しきい値0.70未達） — 捕まえましたが、どちらも自動では破棄しませんでした。WARNとしてライターゲートに上げただけです。これが§6.2.1で予告した設計の核心です。チェッカーに自動拒否の権限まで握らせると、ライターたちは1〜2か月もしないうちにそのスイッチを切ってしまいます。機械が意図された変形まで一緒くたに殺し、その境界をライター自身が見極めてみる機会まで奪うからです。だから、疑わしい候補を拾い上げる仕事は機械に任せつつ、その候補を生かすか捨てるかの最後の判断だけは人の手に残しておきます。

[第4段 ライターレビュー — 判定と破棄]

ライターは2件のalertを次のように処理しました。

• Mira Kost → 存続。riverholdのMira Veldtと同じファーストネームだが、別の都市、別の姓で、同時に登場する可能性はない。意図的な変形として通過。（ただし、forbidden_namesのルールを「名+姓の完全一致」から「名単独の衝突もWARN」に広げるかどうかは別件としてメモ。）
• グレム → 破棄。 voice_lintの信頼度の低さがシグナルだった。読み直すと、「火だけ見ていればいい」という炉番のキャラクターはscholarly_strictな都市のトーンとずれていた。学者ギルドが支配する都市のNPCが神秘主義のトーンに流れると、都市のアイデンティティがぼやける。破棄して再リクエスト。

ライターが破棄を決めると、再リクエストが1回回ります。「グレムのスロットを破棄する。同じ狩り場の学者ギルドのトーン（観測・記録・厳格）に合う炉番のNPCとして再生成せよ。神秘主義の語彙は禁止」。AIは、鐘楼の炉の温度を記録し、火さえもデータとして見る老人を返してきて、その出力はvoice_lint 0.81で通過しました。入力→骨格→本文→検証→破棄→再生成という1つのサイクルが、ここで閉じます。

この一周が、本書全体のShowの基準です。ツールが何を吐き出し、何が引っかかり、人が何を切り捨てるのかを一度でも最後まで見なければ、「AIで量産した」という文は空虚です。

6.2.6 破棄率はツールの失敗ではなくゲートのシグナル

上のサイクルではNPCが1人破棄されました。都市全体で見ると、破棄はさらに積み上がります。レビュー時間は都市あたり平均5〜10分、破棄率はNPCが約20%、サイドクエストが約33%です。

この比率の算出根拠を正直に明らかにしておきます。破棄率は、導入初期にsilvermarkを含む5つの都市を直接レビューしながらカウントした値です。NPCはレビューした30人のうち6人を破棄（20%）、サイドクエストはレビューした15本のうち5本を破棄（33%）でした。サンプルが5都市と小さいため、精密な母集団の比率ではなく、「5つに1つ、3つに1つ」程度の方向値として読むのが正しいです。30都市すべてをレビューし終えたあとの累積比率は、これより低くなることも、狩り場の性格によって高くなることもありえます。

重要なのは、破棄率0%が目標ではないという点です。破棄0%は、レビューが形だけで流れたというシグナルに近いのです。5人のNPCのうち1人がトーンの不一致で破棄され、3本のサイドクエストのうち1本がlore_seedsと噛み合わず再生成されるとき、レビューゲートは実際に機能しています。

6.2.7 計測 — 30都市を4〜5週間で

ツール導入の前後を比較します。下の時間の数値はsilvermarkを含む初期都市群の実測平均で、「導入前」の列はツール以前の手作業期のライターによる推定です。加工した数字はありません。

表だけ見ると数字がすべてのようですが、実際の効果は別のマスから生まれました。都市の量産に縛られるはずだったライターの時間が解放されたことで、ライター1人が四半期あたりのメインクエストの産出を大きく増やせました（正確な倍率は四半期ごとに変わるため断定しません — 方向としては「メインの産出が明確に増えた」です）。量産ツールがライターの時間を吸い取るのではなく、解放するツールとして機能したのです（ライターが「レビュー機械」になったと感じるとツールが拒否される、という§6.1.8の警告がそのまま当てはまります）。

6.2.8 generatorに入れないコンテンツ

自動化の幅が広がっても、次のものはツールの外に置きます。

量産できるという事実が、量産すべきだという決定に自動的につながってはいけません。silvermarkのサイクルで見たように、ツールはNPC 6人のうち5人まではうまく量産します。しかし、その都市の「封印が冷えていく」という核心の緊張を背負うシグネチャーNPCの1人は、ライターが直接作り込みます。自動化の境界が明確であれば、量産ツールはむしろその核心領域を守るツールになります。

6.2.9 よくある5つの失敗

5つ目がもっとも見落とされがちです。silvermarkのグレムを破棄したような判断をライターが楽しんで下せるためには、ライターに量産のレビュー以外に、自分の手で作り込む時間が残されていなければなりません。処理量だけ計測してライターの時間の計測を省くと、ツールはKPI上は成功しても、人は去っていきます。

6.2.10 やってみよう — 今日できる一歩

一人ならここまで：ルールブックのコードはなくてもかまいません。自分のゲーム（または好きなゲーム）の都市・地域を1か所選び、§6.2.2の形式のメタデータを手で書き（lore_seeds 3個が核心です）、§6.2.4の紹介文プロンプトをそのまま貼り付けて一度回してみましょう。出てきたNPCの中からトーンの合わない1人を自分で選び、「このNPCは都市のトーンとずれている。破棄してやり直し」と反論してみると、レビューゲートがどんな判断の束なのかが体で分かります。

チームであれば、次の一歩から始めてみましょう。メタデータのyamlフォーマット1枚とforbidden_namesの自動付与スクリプトから作ります。ルールブックの骨格（generate_skeleton）とlintはその次です。入力フォーマットと名前の重複チェックの2つがあるだけでも、AIの本文量産が「似たような村30個」に崩れていく2つのよくある失敗を先に防げます。

6.2.11 次章の予告

6.3では、NPC Persona/Squadパイプラインを扱います。6.2のgeneratorがドレンやミラのようなNPCを個別に量産するのに対し、Persona/SquadはそのNPCたちをグループ単位で束ねます。1つの狩り場の5人のNPCが、互いに無関係な人形の集まりではなく、小さな社会として機能するようにする方法です。

本章のポイント

• 第1・3段はルールブック（決定論）、AIは第2段だけ — 人は入力とレビューゲートのみ。
• 出力・検証・破棄を一度最後まで見て初めて、「AI量産」が空虚でなくなる。
• 破棄率20・33%はツールの失敗ではなく、ゲートが機能しているシグナル。

次章のプレビュー

• 6.3. NPC Persona/Squadパイプライン

6.3 NPCのPersonaとSquad — 人形博物館から小さな社会へ

主な読者: NPC・狩り場コンテンツに責任を持つMMORPGプランナー（中規模（10〜50人）チーム） 一人・趣味の読者向けミニ版: §6.3.10「一人ならここまで」

6.2のgeneratorで一つの狩り場にNPCを5人量産し、ゲーム内に並べてみた日のことを覚えています。名前・外見・短い背景はすべて埋まっていて、座標だけ打って配置しました。ところが、実際にその狩り場を歩き回ってみると、妙に死んでいました。5人が同じ空間にいるのに、互いに一度も言及しません。2人が同じ岩の上に重なって立っていました。誰かが商人の役割を担う必要があったのに、5人全員が学者でした。ドレンもミラも、個別にはまともなNPCだったのに、束ねてみると人形の寄せ集めでした。

これが人形博物館の状態です。個々のNPCは全部作ったのに、グループとして生きていません。本章では、その5人を小さな社会として束ねるパイプラインを扱います。中心となる分解はPersonaとSquadです。オフィスにたとえると、Personaは社員個人の名刺で、Squadは一つのチームの組織図です。名刺を50枚積み上げても、組織図がなければ会社は回りません。そして本章の背骨は最後の段階、すなわち束ねたグループが「互いに知り合いのように話し、動くか」をAIと一サイクル最後まで検証する場面です。

著者による実運用メモ 本章のSquadパイプラインは、著者が会社のR&Dフォルダで運用しているNPC Persona/Squadツールを匿名化したものです。yaml構造・検証項目・voice_lintのしきい値は実際のツールを忠実に移し、都市・NPCの名前は6.2と同じく書籍用に置き換えています。出力本文は、実際のセッションを再構成したものです。

6.3.1 Personaは名刺、Squadは組織図

Personaは個々のNPCのアイデンティティです。名前・外見・voice_profile・役割を持ちます。6.2のgeneratorが作るのがPersonaです。ドレン・ベイル、ミラ・コストが、それぞれ一つのPersonaです。

Squadは、そのPersonaたちをグループとして束ねる単位です。一つの狩り場に5人がどんな役割で分布し、互いにどんな関係で、どう動くのかを定義します。

この二つを分離しないと、二つの問題が同時に詰まります。Personaだけを量産すれば人形博物館になり、Squadから作ろうとすれば埋めるPersonaがありません。分離すれば、各単位の運用がシンプルになります。ただし、分離は断絶ではありません。要は二つの単位の間に再利用・検証の経路を敷いておくことで、それが本章の本論です。

このPersona→Squad分解は、単なる整理ではなく、もっと先へ進む道を開きます。NPCグループが役割・関係・数値として定型化されていてこそ、のちにワールド状態（プレイヤー行動の蓄積）がNPCの数値を揺らし、その数値がクエストの発現条件になる動的な反応性まで進めます。本章ではその進歩的適用の入口に触れるだけにとどめ、正面からは「人がレビューする保守的な量産」までを扱います。

6.3.2 入力 — Squadメタデータ1ページ

Squadの骨格は、狩り場1か所につきメタデータ1ページから始まります。6.2の都市メタデータと同じ思想です。人は役割分布と関係の意図だけを決め、埋める仕事はルールブックとAIが担います。

# city_021_hg_3.squad.yaml
squad_id: city_021_hg_3_squad
hunting_ground: city_021_silvermark_hg_3
type: hunting_ground_residents
size: 5
roles:
  - role: quest_giver
    count: 1
    voice_traits: [authoritative, scholarly]
  - role: lore_keeper
    count: 1
    voice_traits: [scholarly, withdrawn]
  - role: merchant
    count: 1
    voice_traits: [practical, dry]
  - role: bystander
    count: 2
    voice_traits: [varied]
relationships:
  - between: [quest_giver, lore_keeper]
    type: mentor_and_former_student
  - between: [merchant, bystander_1]
    type: regular_customer
movement_pattern: stationary_with_shifts

最も重要なスロットはrelationshipsです。関係が0件なら、5人は最後まで赤の他人のままです。関係が多すぎると（5人に5件以上）、ユーザーが覚えることが増えて、かえって埋もれます。著者の経験では、5人のSquadに核心となる関係2〜3件が最も安定しています。voice_traitsは、5人が互いに異なる声を持つようにするための装置です。5人全員をscholarlyで埋めると、検証段階でvoiceの平準化として弾かれます。

6.3.3 第1段・第2段 — ルールブックの骨格とPersonaの充填

まず、ルールブックがSquad骨格の標準を決めます。狩り場のregion・typeごとに、サイズ・役割分布・関係密度・動線パターンのデフォルト値がコードに入力されています。

# npc_squad/templates.py (抜粋)
SQUAD_TEMPLATES = {
    ("west", "hunting_ground_residents"): {
        "size_range": (4, 6),
        "role_distribution": {
            "quest_giver": 1,
            "merchant": 1,
            "lore_keeper": (0, 1),
            "bystander": (1, 3),
        },
        "relationship_density": 2,        # 推奨される関係数
        "movement_pattern": "stationary_with_shifts",
    },
    ("east", "outpost_squad"): {
        "size_range": (3, 4),
        "role_distribution": {
            "commander": 1,
            "scout": 1,
            "support": (1, 2),
        },
        "relationship_density": 1,
        "movement_pattern": "patrol_loop",
    },
}

この段階は決定論です。西部の住民Squadでquest_giverだけが5人という事故は、コードのレベルで不可能です。役割分布がルールを外れれば、その場で止まります。

次に、各スロットへPersonaを埋めます。道は三つです。プールに合うPersonaがあれば再利用し（登場ウェイト+1）、なければ6.2のgeneratorで新しく作り、メインクエストの核心人物ならライターが直接書きます。silvermarkのhg_3 Squadでは、quest_giver・lore_keeperを6.2ですでに量産したミラ・ドレンで埋め、merchantとbystander 2人を新しく生成しました。ここまでは6.2のgeneratorサイクルと同じです。本章の本当の仕事はその次、束ねたグループが本当にグループとして機能するかを検証する場面です。

6.3.4 一サイクルを最後まで — 関係補強・動線・一貫性検証

抽象的に「AIが関係を補強する」とだけ書いても、このパイプラインが何を吐き出すのかは分かりません。silvermark hg_3 Squad一つの後半サイクルを、関係テキストの生成から破棄・再リクエストまで、一度最後まで追いかけます。

第3段 — AIによる関係補強

Squad骨格に入力された関係タグ（mentor_and_former_student）は抽象のままで、ゲーム内では見えません。これを一行の描写に変えてNPCのセリフ・イベントに埋め込むのが第3段です。プロンプトは、そのままコピーして使える形です。

[L0 コンテキスト] world_premise + tone_manifesto  (キャッシング)
[L1 コンテキスト] city_021_silvermark.lore (学者ギルド支配, scholarly_strict)
[Persona 1] quest_giver — ミラ・コスト、ギルド文書庫の司書、30代、インクの染み
[Persona 2] lore_keeper — ドレン・ベイル、鐘楼の観測補助、50代、数字でしか話さない
[関係タグ] mentor_and_former_student

この二人（師匠–かつての弟子）の関係を、ゲームのセリフに使う背景として1~2行だけ描写して。
ドレンは数字、ミラは文書 — 二つの口調がぶつからないように。トーンは厳格な学者風で、
神秘主義や「古い友人」のような常套句は抜いて。本文のみ。

[第3段 AI出力 — 関係の一行]（実際のセッションを再構成）

ドレンは20年前、ミラに封印陣の観測記録の表記法を教えた。今は立場が逆転し、ドレンが測定した数値を、ミラが文書庫の帳簿に書き写している。二人は毎週火曜日、観測値と帳簿が食い違う一マスをめぐって短く言い争う。

この出力は良い出来です。mentor_and_former_studentが具体化され、ドレンの「数字」とミラの「文書」が衝突せずに一つの場面（数値を帳簿へ書き写す）に束ねられ、scholarly_strictのトーンも維持されています。同じプロンプトが、merchant–bystander_1のregular_customer関係にも繰り返されます。

第4段 — 動線合成

NPCが一日中同じ場所に立っていれば、また人形に戻ります。ルールブックが動線パターンを埋めます。stationaryは1か所固定（警備・ボス）、stationary_with_shiftsは8時間ごとに位置を微調整（一般）、routine_loopは時間割ベース（住民）、event_drivenはトリガー時のみ移動（クエストNPC）。これは決定論なので、AIは呼びません。

第5段 — Squad一貫性lint（このパイプラインのゲート）

ここで、束ねた5人が本当にグループとして機能するかを叩きます。6.2のlintが個々のNPCを見たのに対し、このlintはグループの一貫性を見ます。

[第5段 Squad lint出力]（実際の形式）

[PASS] 役割分布: quest_giver 1 · lore_keeper 1 · merchant 1 · bystander 2 (ルール充足)
[PASS] 関係密度: 2件 (推奨 2, 充足)
[WARN] voice多様性: scholarly系列 3/5 — quest_giver·lore_keeper·bystander_2
       のvoice_profileコサイン類似度 0.83 (しきい値 0.80 超過)。平準化リスク。
[WARN] 動線衝突: 14:00~16:00 区間 merchant·bystander_1 座標半径 1.5m 重複
[FAIL] 関係露出: 関係2件が定義されたが、5人のセリフのどこにも他メンバーへの言及 0件。
       関係がデータにのみ存在 — ゲーム内可視性 0。

lintが3件を拾いました。3件とも自動では破棄せず、ゲートに上げます — 疑わしい候補は機械が拾い上げ、生かすか捨てるかは人が決めるという、§6.2.5と同じ設計です。

[第6段 ライターレビュー — 判定と破棄]

ライターは、alert 3件を次のように処理しました。

• voiceの平準化（WARN） → bystander_2を破棄。学者の都市とはいえ、5人全員が学者口調では狩り場が単調になります。bystander_2をpractical, dryトーンの雑用係として再生成をリクエスト（quest_giver・lore_keeperが二人とも学者なのは都市のアイデンティティなので維持）。
• 動線衝突（WARN） → ルール補正。merchantのshift開始オフセットを+2時間ずらして14:00の重複を解消。AI呼び出しなしで動線パラメーターのみ調整。
• 関係露出0（FAIL） → 最も重要な件。関係を2件も定義しておきながらゲーム内で一度も見えないなら、そのデータは死んだデータです。ライターは核心の関係1件（ドレン–ミラ）を選び、セリフに埋め込むことを決定。

3件のうち2件はルール・再生成で閉じ、最後のFAILがこのパイプラインの核心です。ライターは、ドレンの会話分岐を一行追加するようリクエストしました。

ドレンのセリフに、ミラとの関係がさりげなくにじむ一行だけ差し込んで。
説明調ではなく脇道で。学者風のトーン、セリフ一行のみ。

[再リクエストの出力]

「あの図面は文書庫にある。ミラに聞いてくれ。……20年前は私があの子に読み方を教えた側だったが、近ごろは逆でな。」

この一行が入った瞬間、二人のNPCの関係がマスターデータからゲーム画面へ移ってきます。入力（Squadメタ）→骨格→Personaの充填→関係補強→動線→一貫性検証→破棄・露出の決定という一サイクルが、ここで閉じます。

この一周が、本章のShow基準です。「SquadでNPCを社会として束ねた」という文は、関係露出0件のFAILを人が一行のセリフで閉じる場面を一度でも見なければ、空虚です。

6.3.5 Persona→Squadの全体フロー

上のサイクルを、一枚の図として載せておきます。要点は、第1・2・4・5段が決定論（ルールブック・lint）で第3段だけがAIだという点、そして人の手は最上部の入力と最下部のゲートにしか触れないという点です。

flowchart TB
    P["Personaプール
(6.2 generatorの産出)
ドレン・ミラ・..."] --> FILL
    A["入力: Squadメタデータ
(人手10〜15分/狩り場)
役割分布・関係2〜3件の意図"]
    A --> B["第1段 決定論: templates.py
役割分布・関係密度・動線の標準"]
    B --> FILL["第2段: Personaの充填
再利用 / generator / ライター直書き"]
    FILL --> C["第3段 AI: 関係の一行補強
L0キャッシング + voice_traits衝突チェック"]
    C --> D["第4段 決定論: 動線合成
shift・routine・event_driven"]
    D --> E{"第5段 決定論: Squad lint
役割分布・voice多様性
・動線衝突・関係露出"}
    E -->|"alert"| F["第6段 ライターレビューゲート
(5〜10分/狩り場)
破棄・ルール補正・関係露出の決定"]
    F -->|"再リクエスト"| C
    F -->|"通過"| G["ビルド反映"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D,E code;
    class C ai;
    class A,F human;
    class P data;
    class G pass;

人の手が触れる場所は二か所だけです。最上部で役割・関係の意図を決める場面と、最下部でlintが拾えないトーン・ナラティブを判定する場面。その間の骨格・動線・検証はルールブックが、関係の本文はAIが回します。

6.3.6 関係をゲームに見えるようにする三つの装置

第5段lintの관계 노출（関係露出）項目が、最も頻繁にFAILになります。関係がデータの中だけで生きているからです。関係をゲームの中へ引き出す装置は三つです。

第一に、セリフでの言及。§6.3.4のドレンのセリフのように、NPCが他のメンバーに一行だけ触れます。最も安く、最も効果が大きい方法です。

第二に、動線の交差。毎週火曜日にドレンとミラが文書庫に一緒にいる場面が、ゲーム内で観察されます。ユーザーが偶然見かければ「あの二人、何かあるのか」と気づきます。第4段の動線と関係が一致していれば、自然に生まれます。

第三に、分岐条件。quest_giverの頼みを断ると、lore_keeperの好感度も一緒に下がります。この第三の装置が、§6.3.1で述べた進歩的適用の入口です — 関係が単なる描写を超えて、ゲームの状態に影響を与え始める場面です。

三つの装置をすべて使う必要はありません。5人のSquadで核心の関係2〜3件だけを第一・第二の装置で露出させるだけでも、狩り場の体感は大きく変わります。やりすぎると、ユーザーが覚えることが増えます。ライターはレビュー段階で露出させる関係を選んで差し込み、残りはデータのままにしておきます。

6.3.7 測定 — 正直に

ツール導入の前後を比較します。加工した数値は使いません。時間・比率はsilvermarkを含む初期の狩り場数か所を直接レビューしながらカウントした値で、「導入前」の列は手作業時代のライターの推定です。

サンプルが狩り場数か所と小さいため、精密な母集団の比率ではなく、方向性を示す値として読むのが正しい姿勢です。最も大きな変化は、表には載りません。lintの관계 노출FAILが強制的にライターへ「この狩り場、関係が一つも見えません」を突きつけるため、量産物が人形博物館のままリリースされることが構造的に減りました。破棄0%・露出0件が目標ではないという点（§6.2.6）は、ここでも同じです。Squadが束ねる仕事の大部分を吸収しつつも、ドレンの最後のセリフ一行のような核心は、ライターが直接練り上げる時間が残っていなければなりません。

6.3.8 Personaプール — 同じ人物が複数の都市に現れたら

Squadが安定すると、自然についてくる運用がPersonaプールです。同じPersonaが複数の都市に登場できます。学者ギルド所属のNPCに都市3〜4か所で出会うのは、むしろ自然です。世界が狭く見えるのではなく、つながって見えます。

persona_pool:
  - id: persona_doren_vale
    voice_traits: [terse, numeric]
    appearance_count: 3
    appearance_cities: [city_021, city_018, city_023]
    signature: false
  - id: persona_mira_kost
    voice_traits: [scholarly, withdrawn]
    appearance_count: 2
    signature: false

再利用比率には、健全な範囲があります。

ただし、一つのNPCをあまりに多くの都市に登場させると「この人、また出てきた」になります。一つのPersonaの最大登場都市数は、5か所と上限を置きます。ボス部屋・シグネチャー人物は再利用禁止（signature: true）。同じPersonaの2回目の登場からは、視覚的なバリエーション（ライト・小道具）を強制します。この30〜50%という範囲は精密な数値ではなく、運用ガイドラインです — チーム・ゲームの規模に応じて補正が必要です。

[方向標識 — ペルソナプールを分布として見るなら（まだ時期尚早）] プールが数百NPCまで育ったチームなら、一歩先へ進む方向があります — §8.2.7の「次元ベクトル」の節と同じ位置づけの方向標識です（処方ではありません — 概念の直観は付録M）。§6.3.4のvoice_lintは、すでに二つのPersonaのコサイン類似度（0.83のような値）で「近さ」を見ています。同じ埋め込みをプール全体にかければ、マンネリ化をライターの印象ではなく分布密度で診断できます — 「学者口調が一角に群れている」状態が、その領域の点密度として見えます。そうすれば、低密度領域に「また似たような学者」を新しく置く代わりに、近い二つのPersonaの間を補間したバリエーションで多様性を埋める道が開けます。ただし、同じ呼吸で添えるべき注意点が二つあります。補間で生成したPersonaは、二つのNPCをぎこちなく混ぜた「死んだ中間値」になりやすく、結局は人がvoiceをもう一度生かし直すことになります。そして上のマンネリ化比率（30〜50%）は精密値ではなく運用ガイドラインなので、それを埋め込み距離に換算した瞬間、緩さが精密なふりをして隠れる危険があります — 距離の値はライターの判定を助ける信号であって、判定そのものではありません。

6.3.9 よくある六つの失敗

四つ目が、最も見落とされやすい失敗です。関係を定義する仕事と、関係をゲームに見えるようにする仕事は別の作業で、チェックがなければほぼ必ず後者が抜けます。silvermark hg_3でlintが関係露出0件をFAILとして突きつけなかったら、ドレンとミラはマスターデータの上でだけ師弟関係だったでしょう。

6.3.10 やってみよう — 今日できる一歩

一人ならここまで: ルールブックもlintもなくて構いません。自分のゲーム（または好きなゲーム）の一つの場所にいるNPC 3〜5人を選び、§6.3.2の形式で役割と関係2件を手で書いてみましょう。次に§6.3.4の関係補強プロンプトをそのまま貼り付けて一行の描写を受け取り、最後に自分へ問いかけてみてください — 「この関係はいま、ゲームのセリフのどこに見えているか？」。一か所もなければ、それがまさにlintの관계 노출 0 FAILです。NPC一人のセリフに他のメンバーへの一行を差し込み、そのFAILを手で閉じてみると、Squad検証が何を拾う作業なのか、体で分かります。

チームなら、次の一歩から始めましょう。Squadメタデータyamlの様式1枚と、第5段lintのうち관계 노출チェック1行から作ります（各NPCのセリフテキストに、他のメンバーの名前・役割が登場するかをgrep）。役割分布チェック・動線衝突チェックはその次です。関係露出チェックが一つあるだけでも、量産した狩り場が人形博物館のままリリースされるという最もよくある失敗を、先に防げます。

setup → prompt → verifyで要約すると — setup: Squadメタyamlに役割・関係を定義し、templates.pyで骨格を組みます。prompt: §6.3.4の形式で関係の一行を受け取りつつ、voice_traitsの衝突禁止・常套句禁止を強制します。verify: 第5段lintを回して관계 노출FAILを確認し、核心の関係1件をセリフに埋め込んで自分で閉じます。

本章のポイント

• Personaは名刺、Squadは組織図 — 分離してこそ、人形博物館が社会になります。
• 関係補強・動線・一貫性検証を一度最後まで見てこそ、「社会として束ねた」が空虚になりません。
• 관계 노출 0（関係露出0）のFAILを人が一行のセリフで閉じることが、このパイプラインの心臓です。

次章のプレビュー

• 6.4 コンテンツ量産ワークフロー — Persona・Squad・都市生成を1週間サイクルにまとめる

6.4 コンテンツ量産ワークフロー — 複数のgeneratorを1本のラインにまとめる

3つのツールをそれぞれ完成させたその週、私は一度に都市generatorを回し、NPC generatorを回し、アイテムgeneratorを回しました。3つとも、それぞれは問題なく動いていました。都市は7か所、NPCは110人、武器は60個が生成されました。ところが数日後、チェックの席に着いてようやく、同じ落とし穴を3回踏んでいたことに気づいたのです。

都市port_harmanは「没落した漁村（몰락한 어촌）」として生成されたのに、その都市に配置されたNPCたちのペルソナは「繁栄する貿易港の裕福な商人（번성하는 무역항의 부유한 상인）」でした。都市generatorとNPC generatorが、互いに異なるlore_seedsを見ていたからです。アイテムgeneratorは、その都市の推奨レベルが12〜18なのに、レベル40の伝説武器をショップに並べていました。3つのツールはそれぞれ正しく、まとめられていなかったがゆえに間違っていたのです。

本章は、ツールを1つ作る話ではありません。6.2の都市generator、6.3のNPC Squad、そしてアイテムgeneratorを1本の生産ラインにまとめる運用の話です。ツールが3つなら落とし穴も3つになる、のではありません。落とし穴はツールとツールの隙間から新たに生まれるのです。

6.4.1 生産ラインという視点

都市・NPC・アイテムのgeneratorを別々に回すと、各ツールの出力が他のツールの入力と食い違います。解決策はツールをより賢くすることではなく、共有メタデータを上流で一度確定し、その下にツールを並ばせることです。6.2 ch2の都市generatorが単一ツールの模範だとすれば、本章はそのツールをラインの1ステーションへと格下げする作業です。

ライン全体はこう流れます。

flowchart TD
    SEED[月: lore_seedsシート
region·climate·faction·level_range]:::human
    SEED --> CITY[火: 都市generator
L1ルールブック骨格 + L2 AI本文]
    CITY -->|city_manifest.json| NPC[火: NPC generator
都市のloreを継承]
    CITY -->|level_range| ITEM[火: アイテムgenerator
レベル帯・陣営を継承]
    NPC -->|persona_pool| SQUAD[火: Squad配置]
    ITEM --> SQUAD
    SQUAD --> LINT[水: 統合lint
generator間の整合性]
    LINT -->|alert| REVIEW1[水: 1次チェック
ライター本人]
    REVIEW1 --> REVIEW2[木: 2次サンプル
リードナラティブ]
    REVIEW2 --> BUILD[金: ビルド反映
+ 翌週のseed準備]
    BUILD -.回収.-> SEED

    classDef human fill:#fde68a,stroke:#b45309,color:#000;

鍵となるのはcity_manifest.jsonという矢印です。都市generatorは都市を作りながら、その都市のアイデンティティ（没落した漁村なのか、繁栄する貿易港なのか）をmanifestとして書き出し、NPC generatorとアイテムgeneratorがそのmanifestを入力として受け取ります。私があのとき踏んだ落とし穴は、この矢印がなかったことが原因です。ツールをまとめるとは、ツールとツールの間にこの1行の契約を入れることなのです。

6.4.2 ツールをまとめる1行の契約 — manifest

都市generatorが都市を1つ作るたびに一緒に吐き出すcity_manifest.jsonの実際の形はこうです。このファイルがNPC・アイテムgeneratorの入力になります。

{
  "city_id": "port_harman",
  "display_name": "ハルマン港",
  "lore_seeds": ["没落した漁村", "古い交易の残響", "塩不足"],
  "region": "南部沿岸",
  "dominant_faction": "漁民ギルド",
  "level_range": [12, 18],
  "tone": "衰退·粘り強さ",
  "forbidden_names": ["ハラン", "ハルメン"],
  "neighbors": ["salt_marsh", "old_pier"]
}

NPC generatorはlore_seedsとtoneを継承して、「没落した漁村の粘り強い人々」を作ります。アイテムgeneratorはlevel_rangeを継承して、12〜18レベルの武器だけを並べます。forbidden_namesはすでに隣の都市で使われた名前なので、双方が避けます。3つのツールが、同じ1枚の契約書を見るのです。

このmanifestを作るときに私がClaudeに与えたプロンプトは次のとおりです。量産ラインの上流をまとめる最も重要な1回の呼び出しなので、全文をそのまま載せます。

あなたはMMORPG都市generatorのmanifest作成器です。以下のライターのメタデータを受け取り、city_manifest.jsonを生成してください。

ライター入力: - city_id: port_harman - lore_seeds: 몰락한 어촌, 옛 무역의 잔향, 소금 부족 - region: 남부 연안 - level_range: 12-18

規則: 1. dominant_factionはlore_seedsから推論すること。ただし隣の都市（salt_marsh、old_pier）の陣営と重複してはならない。隣の都市の陣営は[염전 조합, 밀수단]である。 2. forbidden_namesには、すでに隣接都市で使用されたNPC名・地名を入れること。提供リスト: [하란, 하르멘]。 3. toneは2語以内。lore_seedsと矛盾しないこと。 4. 推測した値とライターが明示した値を区別して表示すること。

Claudeの生の出力はこうでした。要約せず、そのまま載せます。1か所で規則を破っています。

{
  "city_id": "port_harman",
  "display_name": "ハルマン港",
  "lore_seeds": ["没落した漁村", "古い交易の残響", "塩不足"],
  "region": "南部沿岸",
  "dominant_faction": "密輸団",   // ← 推論: 塩不足 + 古い交易 = 密貿易
  "level_range": [12, 18],
  "tone": "衰退·強欲",
  "forbidden_names": ["ハラン", "ハルメン"],
  "neighbors": ["salt_marsh", "old_pier"]
}

（推論した値: dominant_faction、tone、display_name / ライター明示: その他） 注意: dominant_factionを「밀수단」に選びましたが、規則1で隣の都市old_pierがすでに「밀수단」です。規則違反です。代替候補として「어민 길드」を提案します。

ここで重要なのは、AIが自ら規則違反を報告したという点です。「밀수단（密輸団）」はlore_seeds（塩不足・古い交易）から見れば魅力的な推論ですが、ライン全体の視点では衝突です。隣の都市がすでに密輸団なのです。私はAIの提案を受けて、dominant_factionを「어민 길드（漁民ギルド）」に、toneを「쇠락·끈질김（衰退・粘り強さ）」に修正しました。「탐욕（強欲）」は密輸団という前提から出てきた単語なので、漁民ギルドには合いませんでした。

この一度の検証・拒否・再指定が、ラインの上流を守ります。manifestが間違っていれば、その下のNPC 110人と武器60個が、すべて間違った前提の上に生成されます。上流で5分を使えば、下流で3時間を節約できるのです。

6.4.3 統合lint — ツールとツールの隙間を検査する

単一generatorのlintは、自分の出力しか見ません。都市lintは都市がルールブックを守ったかを見て、NPC lintはペルソナがvoiceの一貫性を守ったかを見ます。しかし、私が最初に踏んだ落とし穴は各ツールの中ではなく、ツールとツールの間にありました。だからラインには、単一lintの上にもう1層が必要です。都市・NPC・アイテムを一緒に読み、相互に検証する統合lintです。

統合lintが実際に捕まえる項目はこうです。

この統合lintを回したときの実際の出力の一部です。自動破棄はしません。人が判定できるように、alertを上げるだけです。

[統合lint] port_harman ライン検査 — 3 alert

ALERT-1 (ロア整合) port_harman
  city.lore_seeds = ["没落した漁村", ...]
  npc[merchant_04].persona = "繁栄する貿易港の裕福な商人"
  → 矛盾の可能性。意図された変形か確認が必要。

ALERT-2 (レベル帯整合) port_harman
  city.level_range = [12,18]
  item[blade_legend_07].required_level = 40
  → 推奨レベル帯超過 28。ショップ配置の再検討。

ALERT-3 (名前重複) — 情報
  npc[fisher_02].name = "ハラン"
  city.forbidden_names = ["ハラン", ...]
  → forbidden_namesと衝突。NPC名の再生成を推奨。

ALERT-1を見て、私は少し考え込みました。NPCが「繁栄する貿易港の裕福な商人」であることが、無条件に間違いだとは限りません。かつて栄え、いまは没落した都市なら、「かつて裕福だった、いまは貧しい商人」はむしろ良い物語です。そこで私はALERT-1を破棄ではなく「意図された変形」と判定したうえで、NPCのペルソナを「かつて栄えた貿易港の面影にすがる老いた商人」へと1行修正するよう依頼しました。ALERT-2は明白な事故なので、武器を削除しました。ALERT-3は名前だけ再生成しました。

自動lintが事故を防いだのではありません。自動lintは事故を人の目の前に引きずり出し、判定は人が下しました。これが6.1で述べたL2（ルールブック+AI補助）の核心です。AIが骨格とalertを作り、人が最後の判定をします。ALERT-1のように「間違っているように見えて、実は良い物語」を見分けることは、ルールブックにはできません。

6.4.4 1週間サイクルでラインを回す

ツールをまとめたら、次に必要なのはリズムです。ラインは1週間単位で回すのが最も安定していました。1週間という長さは、チェックが急増しない程度に短く、回収が滞らない程度に長いのです。私の机のカレンダーの1マスともかみ合います。

火曜日がラインの心臓です。都市generatorがmanifestを書き出すと、NPC generatorがそれをくわえ、アイテムgeneratorがそれをくわえ、Squadが配置まで行います。この連鎖が、ライターの介入なしにバックグラウンドで回ります。ライターはその間、メインクエスト（L0完全手作業）を書きます。ツールをまとめた本当の報酬がここにあります。ツールがばらばらなら、ライターは火曜日に3回手を入れなければなりませんが、まとまっていれば一度も触れずに済みます。

ライター1人が、1週間に都市5〜7か所、それに付随するNPC・武器まで量産します。4週間で都市20〜28か所。30か所という目標に、6週間で到達しました。

6.4.5 ラインの健全性 — 毎週見る4つの指標

ラインが健全かどうかは、印象ではなく数字で見ます。毎週自動集計される4つの指標です。

最もラインらしい指標は2つ目の、generator間の衝突件数です。単一ツールだけを使っているときには、この数字は存在しません。この数字が突然10件を超えたら、ツールが1つ壊れたのではなく、ツール間の契約（manifest）が壊れたのです。たいていは、都市generatorのmanifestスキーマを変更したのに、NPC generatorが古いスキーマを読んでいるときに起きます。この指標がなければ、その事故はリリースまで見えません。

4つの指標は毎週、四半期の振り返りへ入力されます。傾向が悪化したら、翌週の量産都市数を5〜7か所から3〜5か所に減らし、原因を調べます。

6.4.6 ラインが崩れる3つの事故

複数のツールをまとめると、単一ツールにはなかった事故が生まれます。よく見た3つを記しておきます。

第一に、契約不一致の事故。都市generatorのmanifestに新しいフィールドを追加したのに、NPC generatorがそのフィールドを知らない。generator間の衝突指標が急増します。ツールを別々に開発していると、片方だけ更新されがちです。対応は、manifestスキーマにversionフィールドを入れ、下流のgeneratorがバージョン不一致を即座にalertとして上げるようにすることです。人を責め立てるのではなく、契約を強制します。

第二に、上流汚染の事故。manifestが間違った前提で生成されると（§6.4.2の「密輸団」のように）、その下のすべてが汚染されます。人のチェックによる破棄率が30%を超えるのに、破棄された出力を見るとNPC個々の品質には問題がない。個々は問題ないのに、前提が間違っているのです。対応は、manifest生成の段階にチェックをもう1つ入れることです。下流の110個をチェックするより、上流の1個をチェックします。

第三に、モデルドリフトの事故。LLMが自動アップデートされ、出力の特性が変わります。都市・NPC・アイテムの3つのgeneratorが同時に揺らぎます。直近1週間の変更点を点検し、破棄サンプルを5個分析し、プロンプトやコンテキストを調整します。1週間のモニタリングの後、回復を確認します。

3つの事故への共通の対応は同じです。人を非難せず、契約を補強します。ライターがlore_seedsを1行しか書かなかったことが原因なら、「3行書いてください」と言う代わりに、manifest lintに強制チェックを追加します。とはいえ、人の責任がゼロという意味ではありません。システムの補強とは別に、事故のパターンは振り返りで共有します。

6.4.7 ライターの時間はどこへ行くのか

ラインをまとめる本当の目的は、ライターをなくすことではなく、ライターがシグネチャーに集中できるようにすることです。ツールがばらばらのときにライターの時間がどう散らばり、まとめた後にどう集まるのかを、1枚に描いておきます。

メインとシグネチャーに、ライターの時間の80%が集まります。ただし、この配分はひとりでに維持されるものではありません。ラインを導入すると、ライターの時間がチェックへすべて流れていく傾向があります。そこで毎月時間配分を測定し、メインが50%を下回ったら量産都市数を減らして、メインの時間を回復させます。時間配分はポリシーとして守らなければなりません。

6.4.8 ラインを他のコンテンツへ拡張する

都市・NPC・アイテムのラインが安定したら、同じ骨格をダンジョン・図鑑・ライブイベントへ拡張します。鍵は新しいパターンを作らないことです。「ダンジョンは都市と違うから、別の構造で」という誘惑が常にやってきます。しかし、ラインの骨格（共有manifest → generator連鎖 → 統合lint → 人のチェック）はまったく同じです。入力メタデータの様式と、ドメインのルールブックだけを差し替えます。

ダンジョンなら、dungeon_manifest.jsonにboss_pattern・encounter_flowのようなフィールドが追加され、ボスの動線といったドメインルールが統合lintに1行加わります。骨格は同じに、ルールだけ違うように。同じ骨格を維持すれば、ライターが新しいツールをまた覚える必要がなく、統合lintのインフラがそのまま再利用できます。ただし、ドメインの特殊性を無視しろという意味ではありません。ダンジョンには、都市にはない動線ルールが間違いなく必要です。

6.4.9 6か月稼働の結果

私のプロジェクトで、この統合ラインを6か月稼働させた結果です。都市・NPC・アイテムのgeneratorを別々に回していた時期と比較します。以下の絶対値は正確な集計ではなく著者の推定（未検証）であり、方向と比率は実測の傾向に従っています。

最も重要な変化は最後の行です。ツールが分離していたときは、上流チェックが0で、下流チェックが3時間でした。ラインをまとめてmanifestを上流でチェックするようにしたら、上流の5分が下流の2時間を消しました。事故がツールの隙間から漏れなくなったので、リリース後の整合性事故も四半期8〜12件から2〜4件に減りました。

そして、トレードオフが明示的になりました。以前は「量産は危険だ」という抽象的な論争が四半期ごとに繰り返されていました。いまは「衝突 -8件 / メイン +5本」という具体的な比較の上で意思決定しています。

6.4.10 よくある失敗7つ

1) ツールをまとめず、別々に回すケース。落とし穴はツールの中ではなく、ツールとツールの間に生まれます。

2) manifestなしでgeneratorをつなぐケース。共有の契約がなければ、下流が上流と食い違います。

3) 統合lintを単一lintで代替するケース。単一lintは、generator間の衝突を見られません。

4) サイクルを5日から3日に圧縮するケース。5日がチェックの安全マージンです。

5) 上流（manifest）をチェックせず、下流をチェックするケース。下流の110個より、上流の1個を見てください。

6) 事故を人の責任だけに帰すケース。契約の補強とルールの自動化が答えです。

7) ラインを整えた後に「使わない」ケース。1週間サイクルを強制することが、ツールと同じくらい重要です。

やってみよう

setup. 都市generator（6.2）とNPC generator（6.3）を準備しましょう。2つが共有するcity_manifest.jsonのスキーマを1つ決めます。フィールドは最低限lore_seeds·region·faction·level_range·forbidden_names·tone·versionです。

prompt. 本文のmanifest作成器プロンプトをそのまま使ってみましょう。鍵は最後の2つの規則です。「隣の都市の陣営と重複するな」（generator間衝突の防止）と、「推測した値と明示した値を区別して表示せよ」（チェック可能性）。都市を作ったらmanifestを書き出し、NPC・アイテムgeneratorがそのmanifestを入力として受け取るようにつなぎましょう。

verify. 統合lintを一度回してみましょう。ロア整合・レベル帯整合・陣営衝突・名前重複の4つを相互に検査します。alertが出たら自動破棄せず、人が判定します。「間違っているように見えて、実は良い物語」（没落した貿易港の老いた商人）を見分けるのは、人の役目です。

一人ミニ版. ツールが都市・NPCの2つだけでも、ラインは成立します。スプレッドシート1枚に都市ごとのlore_seeds・level_range・forbidden_namesを書き、NPC generatorのプロンプトにその行をまるごと貼り付けるだけで、manifestの役割を果たします。統合lintは、都市-NPCのロア整合1行だけでも、あの落とし穴を防げます。大げさなインフラがなくても、「ツールとツールの間に1行の契約を入れる」という原則1つで、ラインは始まります。

本章のポイント

• 落とし穴はツールの中ではなく、ツールとツールの間に生まれます。manifestでその隙間をまとめましょう
• 統合lintは破棄のための装置ではなく、人の目の前に事故を引きずり出す装置です
• 上流の5分のチェックが、下流の2時間のチェックを消します。上流で防ぎましょう

第7部 · Level Design

7.1 プロシージャルレベルデザインマスター

ダンジョン47番ルームの出口が塞がっていました。ビルドは通過し、QAも通過していました。ユーザーがボスルームの直前で壁を前に立ち尽くしているスクリーンショットがコミュニティに投稿されたのは、ライブ開始から3日目のことでした。そのルームは2四半期前に手作業で作ったルームをコピーして貼り付けたもので、コピーの過程で東側の通路の1本が、接続情報を持たないままビジュアルだけ残っていました。誰もそれを検証しませんでした。検証するツールがなかったのです。

この章は、その事故がビルド段階で自動的に遮断される仕組みを作る話です。核心は、空間を描く手先の器用さではなく、空間に付随するデータをルールで運用するやり方にあります。

レベルデザインの仕事場は製図室に近いものです。図面の1枚1枚は人の手から生まれますが、図面同士の一貫性・再利用・検証は、図面キャビネットの運用ルールが決めます。手で描いたダンジョン1個なら誰でも作れます。ダンジョン100個を、一貫した難易度カーブと行き止まりのないグラフで運用するのは、手先の器用さではなくシステムの問題です。

著者が企画ディレクターとして働くプロジェクトA（国内+東南アジア向けMMORPG、中規模（10〜50人）チーム、モバイル優先）で、このシステムの名前はProcedural_Level_Design_Masterという1つのドキュメントです。この章では、そのドキュメントが何を統合し、AIがどこまで手を入れ、どこで止まるのかを扱います。毎回のランごとにダンジョンが新しく生成されるモバイルローグライトRPGの企画をリードし、プロシージャルな空間をルールで運用してきた経験が、この章の土台にあります。

7.1.1 二つの分かれ道 — 空間を作るのか、空間のメタデータを運用するのか

レベル自動化は二つの方向に分かれます。一つは、空間そのものをプロシージャルに生成することです。BSP分割（Binary Space Partitioning、空間を再帰的に二分割してルームを配置する古典的手法）、wave function collapse、ドランクンウォークグリッドのような伝統的PCG（Procedural Content Generation）がここに属します。もう一つは、空間のメタデータ（ルームタグ・接続性・難易度ラベル・イベントスロット）を運用することです。

伝統的PCGは一つ目に強みがあります。ローグライクやサンドボックスのように「毎回新しいマップ」がゲーム性の核心であるジャンルでは、一つ目が正解です。しかしMMORPGは違います。ユーザーは同じダンジョンを数十回周回します。動線を覚えてしまうほど周回します。だからダンジョンは手で磨き上げた固定空間であるべきで、自動化が入る場所は空間そのものではなく、その空間を運用可能にするメタデータです。

メタデータがなぜ運用の背骨なのかは、成果物別に見れば明らかです。

メタデータのないダンジョンは、ビルドは通っても運用ができません。本は山ほどあるのに索引のない図書館のようなものです。この章が「空間メタデータの運用」に集中する理由です。

7.1.2 マスタードキュメントは何を統合するのか

Procedural_Level_Design_Masterは、四つの標準を1つのドキュメントに束ねます。ルームメタデータ様式、ルームタグ辞書、接続性ルール、検証チェックリストです。この四つが散らばっているときに何が起きるかから見てみましょう。プランナー5人がそれぞれ別のファイルで様式を参照すると、typeフィールドをある人はcombat、ある人はCombat、ある人はbattle_roomと書きます。検索が壊れ、統計が壊れ、最終的に自動化が壊れます。

この四つの標準はLayerで整理すると、それぞれの居場所がはっきりします。様式・辞書・ルールは生成を支配するルールブック（L1）に、生成されたルーム本体はコンテンツ（L2）に、シートの値はデータ（L3）に、検証はビルド・QAゲート（L4）にあります。

マスタードキュメントが四つの標準を統合するというのは、「本文を1つのファイルに詰め込む」という意味ではなく、「L1の場所にルールを集める」という意味です。だからこそ、後で出てくる自動化がLayerの境界の上に載せられるのです（分離が崩れると何が起きるかは7.1.11で扱います）。

7.1.3 ルームメタデータ様式 — 自動化が取り付く入力の場所

ルーム1つは次の様式に従います。この様式が自動化の入力インターフェースです。

room_id: dungeon_021_room_07
dungeon: dungeon_021_silvermark_library
type: combat_room          # combat / puzzle / lore / safe / boss
size: medium               # small / medium / large
difficulty_label: hard_for_level_28
tags: [scholar_theme, vertical_layout, water_hazard]
connections:
  - target_room: dungeon_021_room_06
    type: door
    direction: south
  - target_room: dungeon_021_room_08
    type: passage
    direction: east
event_slots:
  - slot: enemy_spawn_1
    constraints: [scholar_enemy, level_28]
  - slot: lore_object_1
    constraints: [scholar_lore]
movement_complexity: 4     # 1~5
estimated_clear_time_sec: 90
art_pack: scholar_library_v2

各フィールドには、1つ以上の自動化の利用先があります。typeはダンジョンプールの統計と難易度計算に、tagsは検索・再利用・アートセットマッピングに、connectionsはグラフ検証（行き止まり検査）に、event_slotsはクエスト・ボスの自動配置に使われます。利用先のないフィールドは様式に入れません。入力コストだけが増えて、価値がないからです。

7.1.4 ルームタグ辞書 — 小さく、直交に

タグはメタデータの検索キーです。無限に増殖すると検索が壊れます。引き出しにラベルが200枚も貼られていたら、何がどこにあるのか探せません。だから5カテゴリー×カテゴリーあたり約6個のenum、合わせて約30個で運用します。

1つのルームでタグ5個を超えないようにします。正常は3〜4個です。新規タグを追加するには、四段階のゲートを通過しなければなりません。四半期あたり5ルーム以上で使われる見込みがあること、既存タグの組み合わせでは表現できないこと、検索・アートセットマッピングでの活用が明確であること、運用1か月後も5ルームを維持していること。最後の条件が核心です。一時的に作ったタグが1回使われて捨てられると、辞書が汚染されます。

7.1.5 プロシージャルレベルパイプライン — ルールブックから検証まで

ここまでの標準が一つの流れとしてどうつながるのか。その接続線こそが、この章を支える骨格です。ルールブックから始まり、AI補助のバリエーションを経て、ガードレール検証で終わるパイプラインです。

flowchart TD
    A["L0 ビジョン — ダンジョンコンセプト・ペーシング意図"] --> B["L1 ルールブック\nタグ辞書・接続性ルール・スロットルール"]
    B --> C["ルーム骨格の配置\nプランナーの手作業+エディター"]
    C --> D["メタデータ自動抽出\nroom_id・connections・type・size"]
    D --> E["AI補助バリエーション\ntags抽出・art_packマッピング提案"]
    E --> F{"辞書強制チェック\n辞書外タグ？"}
    F -->|辞書外| E
    F -->|通過| G["プランナーレビュー\ntags・difficulty_label確定"]
    G --> H["L4 グラフ検証\n到達性・行き止まり・ループ・分岐"]
    H -->|違反| C
    H -->|通過| I["難易度カーブ検証\nルーム難易度ラベルの合算"]
    I --> J["アートセット整合性ゲート"]
    J -->|通過| K["ビルド — ダンジョンプール登録"]
    J -->|不一致| E

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef ai fill:#f3e8ff,stroke:#9333ea,color:#3b0764;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class B,D,F,H,I,J code;
    class E ai;
    class C,G human;
    class K pass;

このパイプラインの三つの性格を押さえておきましょう。第一に、ルールブック（L1）がすべての生成の上流にあります。第二に、AIはルールブックが定義した辞書の中だけでバリエーションを作ります。Fゲートが辞書外の出力を差し戻します。第三に、検証（H・I・J）がビルド直前のゲートとして固定されているため、違反はコードで遮断され、人の注意力には依存しません。47番ルームの事故は、Hゲートがなかったから起きたことなのです。

7.1.6 接続性ルール — グラフで検証するガードレール

ルームメタのconnectionsフィールドは、ダンジョン全体を1つの有向グラフにします。グラフになれば検証は自動です。

測定スクリプトは次の形です。標準的なグラフアルゴリズム（最長経路・平均出次数・ループカウント・最短経路）の上に、ダンジョンの語彙をかぶせた薄いラッパーです。

# level_graph_metrics.py
def measure(dungeon):
    graph = build_graph(dungeon.rooms)
    return {
        "depth":            longest_path_length(graph),
        "branching_factor": avg_out_degree(graph),
        "loop_count":       count_loops(graph),
        "dead_ends":        count_dead_ends(graph),
        "boss_reachability": shortest_path(graph.start, graph.boss),
    }

五つの指標が、他のダンジョンと比較可能な形で出力されます。ダンジョンプールの多様性指標として使います。ただし、指標が多様だからといってダンジョンが面白いという意味ではありません。指標は事故を遮断するためのものであって、面白さを保証するためのものではありません。行き止まり0件は面白さを保証しません。面白さはプランナーのインサイトから生まれ、グラフ検証はそのインサイトが事故に埋もれないよう、底を支えるだけです。

7.1.7 ワークド例題 — tags抽出をAIに任せ、却下し、再依頼する

自動化の中で、人が最も手を離したくなるのがtagsの入力です。ルーム100個にタグを付ける作業は退屈ですし、ルームのスクリーンショットだけでは人間でも迷います。繰り返しが多く、判定基準が明確なこういう仕事こそ、AIがドラフトを支えるのに向いた場所です。この節では、その作業を実際に回したワークフローを、プロンプト、却下されたAIの出力、人による再依頼まで含めて、加工なしで広げます。

1回目のプロンプト：

[入力]
- ルームのスクリーンショット: (添付)
- ルーム面積: 18m × 12m, 天井高さ 9m (垂直2層構造)
- 配置された敵: scholar_phantom × 3, water_elemental × 1
- 隣接ルームの type: lore_room(西), combat_room(東)
- ルーム内に浅い水たまりあり

このルームに合うタグを3~5個、下の辞書からだけ選んで。辞書外のタグは作らず、
タグの enum だけをカンマ区切りで。

[タグ辞書 30個]
theme: scholar_theme, ruins_theme, forest_theme, cave_theme,
       crypt_theme, swamp_theme, mechanical_theme, celestial_theme
layout: vertical_layout, horizontal_corridor, open_arena,
        maze_layout, bridge_layout
hazard: water_hazard, fire_hazard, falling_hazard,
        poison_hazard, crush_hazard, dark_hazard
interaction: puzzle_required, lever_activation, key_gate, hidden_passage
narrative: flashback_trigger, dialogue_zone, lore_object_zone,
           ambush_setup, ritual_site, vista_point, rest_anchor

Claudeの1回目の出力（生のまま）：

scholar_theme, vertical_layout, water_hazard, ambush_setup, two_story_layout

ここで二つの問題がそのまま現れています。一つは、two_story_layoutが辞書にないタグだという点です。モデルが「垂直2層構造」という入力に引きずられて、辞書外の単語を作り出しました。もう一つは、タグが5個と上限に達しているのに、vertical_layoutとtwo_story_layoutが意味的に重複している点です。layoutカテゴリーで2枠を使ってしまったわけです。

人による却下の判断。 two_story_layoutは辞書強制違反なので、自動却下の対象です（パイプラインのFゲート）。ambush_setupは判断が分かれます。敵が3体配置されてはいますが、スクリーンショット上で待ち伏せの構図なのか、単純な戦闘ルームなのか曖昧です。これはモデルが過剰解釈した可能性があります。隣接ルームが両方ともlore/combatなので、ナラティブ上の待ち伏せトリガーとしては根拠が弱い。却下です。

2回目の再依頼：

two_story_layout は辞書になく、vertical_layout と重複してる。外して。
ambush_setup も外して — 敵がいるからといって待ち伏せではない。
// (意図: narrative タグはナラティブ意図が明示されるときだけ。単純な戦闘は type で既に表現済み)
空き枠は無理に埋めなくていい。3~4個が正常。もう一度タグ付けして。

Claudeの2回目の出力：

scholar_theme, vertical_layout, water_hazard

今回は3個に減り、すべて辞書の中にあり、カテゴリーの重複もありません。人はこの結果を受け入れました。ルーム様式のtags: [scholar_theme, vertical_layout, water_hazard]は、こうして確定します。

このワークド例題の教訓は2行です。第一に、AIは入力の1つのディテール（「2層」）に過剰適合して辞書の外へ出ます。辞書強制ゲートがコードレベルでこれを捕まえなければなりません。第二に、AIは空き枠を埋めようとする傾向があります。「無理に埋めるな」と明示しないと、5枠すべてを埋めようとします。どちらの失敗もよくあるもので、どちらの処方も、プロンプトではなくルールブック（辞書+上限）で強制してこそ安定します。

7.1.8 メタデータの量産 — 誰が埋めて、誰がレビューするのか

プランナーがルーム1個のメタを手で埋めると、5〜10分かかります。ダンジョン1個（20〜30ルーム）なら2〜5時間、ダンジョン100個なら200〜500時間です（著者の推定、未検証。ルームあたり平均入力時間×ルーム数で換算した上限値）。すべて手で埋めていたら、プランナーはメタデータ入力の奴隷になります。

そこで、領域ごとに埋める主体を分けます。

プランナーが手で確定するのは、tagsのレビューとdifficulty_labelの最終承認くらいです。残りはツールが埋め、人はレビューします。自動化の目的は、プランナーを入力作業から引き上げ、ペーシング・シグネチャールーム・再利用ポリシーの判断へ戻すことです。

7.1.9 ルームの再利用とその落とし穴

マスター標準の最大の効果はルームの再利用です。タグで検索可能なルームが30個あれば、ダンジョン5〜10個を組み合わせで作れます。ところが再利用率が高くなると、ダンジョンは陳腐化します。そこで、再利用にはガードレールを併設します。

再利用はコストを下げる手段であって、目的ではありません。再利用率そのものをKPIにした瞬間、ユーザー体験は単調になります。0%（全ルーム新規）なら量産コストが爆発し、70%を超えるとダンジョン同士の区別がつかなくなります。経験上、30〜40%の区間がコストと多様性のバランスポイントです（方向性の観察であり、正確な閾値はプロジェクトごとに異なります）。

7.1.10 よくある失敗と処方

7.1.11 Layer分解はプロシージャルレベル生成の前提である

ここまでルールブック・生成・検証として解いてきた7.1.2〜7.1.6の構造そのものが、Layer分解の結果物です。Layer分解がプロシージャル生成・自動化の前提であるという一般論（L0アンカー→L1ルールブック→L2本文→L3数値→L4ゲート、ひとかたまりだと生成が崩れる）は、§6.6で扱いました。ここではそれをレベルメタデータの運用に適用します。

この分離がないと、ルーム配置・BSP・ペーシング・ナラティブトリガーが1つのファイルに混ざり、ルームを1マス動かすたびに、ペーシング意図・イベントスロット・接続性グラフが同時に壊れます。製図室・資材倉庫・検品室が1つの机に積み上がっていて、図面を1枚抜くと資材の送り状と検品表が一緒に抜けてしまう状況です。だから、7.1.7のAI補助が機能したのもLayerのおかげです。ルームID・接続性はエディター（L3自動抽出）で、タグはAI（L1辞書強制）で、difficulty_labelは合算（L3→L4）で埋まります。自動化はLayerの境界の上に載るのであって、ひとかたまりの上に載せれば、最初の四半期のうちに事故が爆増してツールそのものが廃棄されます。

ただし、最初から五段の引き出しを完璧に揃えなければならないという意味ではありません。分離は漸進的に、インターフェースは狭く、が原則です。最初の四半期は、L1ルールブック（タグ辞書+接続性ルール）とL3シート（ルームメタシート）だけ分離しても、自動化が入る場所は生まれます。L0ペーシング意図とL4検証ゲートは、四半期を重ねながら埋めていきます。標準が統一されてこそ自動化の入る場所が生まれ、自動化が進むほど、プランナーはルーム1マスの手作業ではなく、ペーシング・シグネチャー・再利用の判断に集中できるようになります。

本章のポイント

• レベル自動化の新しい持ち場は、空間そのものではなく、空間メタデータの運用にあります。
• 検証は人の注意力ではなくビルドゲートに固定してこそ、事故がライブに漏れません。
• AIのバリエーションはルールブックが定義した辞書の中だけで許可し、辞書外の出力はコードで却下します。

やってみよう

setup. ダンジョンを1つ選び、ルームごとにroom_id · type · connections · tagsの4フィールドだけを持つYAMLシートを作ってみましょう。タグは、5カテゴリー約30個のenum辞書を先に紙1枚に固定します。

prompt. ルームのスクリーンショット+面積+敵の種類+隣接ルームのtypeを入れて、「この辞書からタグを3〜5個だけ選べ、辞書外のタグは禁止、空き枠は埋めるな」と依頼してみましょう（7.1.7のプロンプトそのまま）。

verify. （1）AIの出力に辞書外のタグがあれば、却下して再依頼しましょう。（2）connectionsでグラフを作り、開始→ボスの到達性と行き止まりを検査します。違反が1つでも出たら、そのルームはビルド不可としてマークしましょう。

一人ミニ版

ツールのインフラがない1人開発者なら、マスタードキュメントを1枚のMarkdown（マークダウン）から始めてみましょう。タグ辞書30行、接続性ルール5行、検証チェックリスト5行で十分です。グラフ検証は、ルームが10個以下なら紙に矢印を描いて行き止まりだけ目で確認しても、効果の80%が得られます。核心はツールではなく、「ルームにデータを付け、そのデータをルールで検査する」という習慣そのものです。ツールは、ルームが50個を超えて手作業での検査が苦しくなったときに付ければ十分です。

次章のプレビュー

• 7.2 BehaviorTreeエディター — レベルの隣接領域であるAIのビヘイビアツリーを、ルールブック・メタデータを土台に運用する

7.2 BehaviorTreeエディター — 人とAIが共にBT jsonを編集し検証するワークド・トランスクリプト

見習い魔法使いが1体、プレイヤーに張り付いて剣を振り回していました。遠距離の魔法キャスターとして設計したNPCです。HPは紙のように薄く、近接では一発もらっただけで死ぬのに、そいつは距離を取る気配がありませんでした。ビルドログには何のエラーもありません。エディターでBehaviorTreeを開き直してみても、ノードは問題なくつながっています。1時間にらみ続けた末に、原因を見つけました。後退分岐の距離条件が5ではなく0.5になっていたのです。5メートル以内に入られたら逃げるべきところが、0.5メートル、つまりほぼ目の前まで来ないと後退分岐が発動しなかったわけです。

たった数字一つでした。グラフィカルなノードエディターでは、その数字はノード内側のパネルを開かなければ見えず、変更履歴にも残りませんでした。誰がいつその値を変えたのか、追跡する方法がなかったのです。その日以降、筆者のプロジェクトAはBehaviorTreeをグラフィカルではなくjsonで扱い始めました。本章は、そのjsonを人とAIが共に編集し、機械が自動で検証する1サイクルの記録です。

7.2.1 BT（BehaviorTree、ビヘイビアツリー）が手に負えなくなるポイント

BehaviorTreeは、敵NPCの戦闘・移動・反応を定義する事実上の標準構造です。セレクター（selector）が優先順位どおりに分岐を試行し、シーケンス（sequence）が条件とアクションを順番に束ねます。構造自体は単純です。問題は規模です。

筆者のプロジェクトAでは、敵NPC 1体のBTはおよそ50〜200個のノードで構成され、運用対象のNPCは100体を超えていました。掛け合わせると、BTノードの総量は数万単位になります。この規模になると、「この後退パターンを変えたら、どのNPCに影響が出るのか」という質問に人が答えられなくなる瞬間が来ます。机の上にノートが100冊開いてあって、1冊目の1行を直すと、残り99冊のどこに波及するのかを目で追いかけるようなものです。

筆者がグラフィカルBTからjsonへ移行するにあたって要求したことは、次の4つでした。

商用ゲームエンジンの組み込みBTエディターは、統合が楽で視覚的なデバッグに強いものです。ただし、バイナリ（binary）アセットとして保存される傾向があるため、テキストのdiffと変更影響の追跡には弱くなります。筆者のプロジェクトAは、運用BTが100体を超える運営型ゲームを前提としていたため、独自のjson BTフォーマットとエディターを自社開発する道を選びました。はっきりさせておきましょう。これはすべてのチームにとっての正解ではありません。運用BTが50体未満なら、エンジン組み込みのエディターをそのまま使うほうがほぼ常に安上がりです。自社開発の正当化については、本章の最後で改めて扱います。

7.2.2 BT json — 敵1体の行動をテキストで

まず成果物の形を見てみます。以下は、学者ギルドの遠距離支援型NPCのBTの一部です。要点は2つです。すべての行動がテキストなのでgitが1行単位で追跡できること、そして共通パターンをsubtree_refで参照していることです。

{
  "bt_id": "bt_scholar_archer_v3",
  "category": "ranged_combatant",
  "tags": ["scholar_faction", "ranged", "support"],
  "description": "学者ギルドの遠距離支援型。距離維持 + 後退優先。",
  "root": {
    "type": "selector",
    "children": [
      {
        "type": "sequence",
        "name": "low_hp_retreat",
        "children": [
          {"type": "condition", "fn": "hp_below", "param": 0.3},
          {"type": "subtree_ref", "id": "subtree_retreat_to_ally"}
        ]
      },
      {
        "type": "sequence",
        "name": "kite_pattern",
        "children": [
          {"type": "condition", "fn": "enemy_in_close_range", "param": 5},
          {"type": "action", "fn": "move_away", "param": {"distance": 8}}
        ]
      },
      {"type": "subtree_ref", "id": "subtree_ranged_attack_pattern"}
    ]
  }
}

このツリーを図に展開すると、セレクターが上から3つの分岐を順に試行する構造です。冒頭のあのバグ（enemy_in_close_rangeのparamが5か0.5か）が、jsonでは一目で見える1行になる点に注目してください。

flowchart TD
    R["selector
(上から優先順位)"]
    R --> A["sequence: low_hp_retreat"]
    R --> B["sequence: kite_pattern"]
    R --> C["subtree_ref:
subtree_ranged_attack_pattern"]
    A --> A1["condition: hp_below 0.3"]
    A --> A2["subtree_ref:
subtree_retreat_to_ally"]
    B --> B1["condition: enemy_in_close_range 5"]
    B --> B2["action: move_away dist=8"]

    style C fill:#e8f0fe,stroke:#4285f4
    style A2 fill:#e8f0fe,stroke:#4285f4
    style B1 fill:#fce8e6,stroke:#ea4335

赤く塗ったenemy_in_close_range 5が、冒頭で人の1時間を食いつぶしたあのノードです。jsonならコードレビュー一発で捕まります。

7.2.3 subtreeライブラリー — コピペの代わりに参照

100体を超える敵の行動には、繰り返し現れる塊があります。「味方の後ろへ後退」「遮蔽物へ後退」「遠距離攻撃パターン」といったものです。これをBTごとにコピーして入れてしまうと、後退ロジックを一つ直すたびに100か所を手作業で探して直すことになります。そこで共通パターンは別のsubtreeファイルとして切り出しておき、subtree_refで参照するだけにします。

subtree_library/
├── retreat_patterns/
│   ├── subtree_retreat_to_ally.json
│   ├── subtree_retreat_to_cover.json
│   └── subtree_retreat_random.json
├── attack_patterns/
│   ├── subtree_ranged_attack_pattern.json
│   ├── subtree_melee_combo.json
│   └── subtree_aoe_attack.json
└── reaction_patterns/
    ├── subtree_react_to_ally_death.json
    └── subtree_react_to_player_taunt.json

こうしておけば、「このsubtreeを直したら誰に影響が出るのか」という質問が、人の推測ではなくスクリプトの出力になります。影響トラッカーは単純です。すべてのBTを開き、該当するsubtreeを参照しているBTのbt_idを集めるだけです。

# bt_impact_tracker.py
import json, glob

def has_subtree_ref(node, target_id):
    if isinstance(node, dict):
        if node.get("type") == "subtree_ref" and node.get("id") == target_id:
            return True
        for child in node.get("children", []):
            if has_subtree_ref(child, target_id):
                return True
    return False

def find_affected_bts(subtree_id):
    affected = []
    for bt_file in glob.glob("bts/*.json"):
        bt = json.load(open(bt_file, encoding="utf-8"))
        if has_subtree_ref(bt["root"], subtree_id):
            affected.append(bt["bt_id"])
    return affected

# 使用
affected = find_affected_bts("subtree_ranged_attack_pattern")
# → ["bt_scholar_archer_v3", "bt_ranger_v2", "bt_sniper_v1", ...]

筆者のプロジェクトAでは、この関数をプルリクエスト（Pull Request）の段階に組み込んでおきました。誰かがsubtreeファイルに手を入れると、影響を受けるBTのリストが自動的にPRコメントに付きます。レビュアーは「後退パターンを1行直しただけで遠距離の敵12体が全部変わる」という事実を、マージ前に目にすることになります。

7.2.4 ワークド・トランスクリプト — AIが新しいBT草案を書く1サイクル

ここからが本章で最も重みのある部分です。新しい敵NPC「見習い魔法使い」のBT草案をAIに任せ、その出力を人が検証・却下・再依頼する1サイクルを、整えずにそのまま載せます。滑らかに刈り込まないのには理由があります。AIが最初の出力で何をどう間違えたのか、その失敗の手触りこそ、本章が伝えたいことのすべてだからです。

Step 1 — 人が投げたプロンプト（全文）

[敵NPCコンセプト]
学者ギルドの見習い魔法使い。HPが低く魔法ダメージが高い。
近接回避を優先。味方の後ろへ後退した後に魔法攻撃。

[category] ranged_combatant

[参考BT] bt_scholar_archer_v3
(構造は類似。ただし弓攻撃の代わりに魔法攻撃へ差し替え)

[定義済み関数enum]
condition: hp_below, enemy_in_close_range, ally_nearby, mana_below
action: move_away, cast_spell, retreat, wait
subtree_ref id (使用可能リスト):
- subtree_retreat_to_ally
- subtree_ranged_attack_pattern   # 弓ベース。魔法用ではない
- subtree_magic_attack_pattern

このコンセプトでBT rootノードのjsonだけ書いて。subtree_refを最大限使って直接ノードは最小に、
関数は上のenumの中だけで。コンセプトにない行動は追加しないこと。説明なしでjsonのみ。

Step 2 — Claudeの1次出力（加工なしそのまま）

{
  "bt_id": "bt_scholar_apprentice_v1",
  "category": "ranged_combatant",
  "tags": ["scholar_faction", "magic", "fragile"],
  "description": "学者ギルドの見習い魔法使い。近接回避 + 味方の後ろへ後退 + 魔法攻撃。",
  "root": {
    "type": "selector",
    "children": [
      {
        "type": "sequence",
        "name": "low_hp_retreat",
        "children": [
          {"type": "condition", "fn": "hp_below", "param": 0.4},
          {"type": "subtree_ref", "id": "subtree_retreat_to_ally"}
        ]
      },
      {
        "type": "sequence",
        "name": "avoid_melee",
        "children": [
          {"type": "condition", "fn": "enemy_in_close_range", "param": 6},
          {"type": "action", "fn": "move_away", "param": {"distance": 10}}
        ]
      },
      {
        "type": "sequence",
        "name": "mana_recover",
        "children": [
          {"type": "condition", "fn": "mana_below", "param": 0.2},
          {"type": "action", "fn": "wait", "param": {"frames": 120}}
        ]
      },
      {"type": "subtree_ref", "id": "subtree_ranged_attack_pattern"}
    ]
  }
}

Step 3 — 人による検証・却下

出力を受け取り、lint（次節で扱います）にかけ、目で読みました。3か所が引っかかりました。

1. 最後の分岐が間違っています。 subtree_ranged_attack_patternは弓ベースの攻撃パターンです。enumのコメントに「마법용 아님（魔法用ではない）」と書いておいたにもかかわらず、AIは名前が似ている弓パターンを持ってきました。見習い魔法使いはsubtree_magic_attack_patternを使うべきです。— 却下。

2. コンセプトにない行動を追加しています。 mana_recover分岐（mana_below → wait 120frame）は、コンセプトに一行も書かれていない行動です。プロンプトで「明示されていない行動の追加は禁止」と釘を刺したにもかかわらず、AIが「魔法使いならマナ管理が自然だ」と判断して差し込んだものと見られます。もっともらしいものの、仕様違反です。— 却下。

3. 後退のしきい値が疑わしいです。 hp_below 0.4は、参考BT（0.3）より早く後退を始めます。見習い魔法使いのほうが弱いのは確かなので、意図的かもしれません。ただ、AIが根拠を示したわけではないため、プランナーが決めるべき事項です。— 保留、プランナー確認。

Step 4 — 人による再依頼

3か所だけ直して。最後の分岐subtree_ranged_attack_patternは弓パターンだから
subtree_magic_attack_patternに替えて、mana_recover分岐はコンセプトにないから丸ごと削除、
hp_below 0.4は参考BT(0.3)に戻して — 0.4にする根拠があればdescriptionに1行で。
残りはそのまま、jsonのみ。

Step 5 — Claudeの2次出力（修正版）

{
  "bt_id": "bt_scholar_apprentice_v1",
  "category": "ranged_combatant",
  "tags": ["scholar_faction", "magic", "fragile"],
  "description": "学者ギルドの見習い魔法使い。近接回避 + 味方の後ろへ後退 + 魔法攻撃。HPが低いため後退しきい値0.3を維持(archerと同一)。",
  "root": {
    "type": "selector",
    "children": [
      {
        "type": "sequence",
        "name": "low_hp_retreat",
        "children": [
          {"type": "condition", "fn": "hp_below", "param": 0.3},
          {"type": "subtree_ref", "id": "subtree_retreat_to_ally"}
        ]
      },
      {
        "type": "sequence",
        "name": "avoid_melee",
        "children": [
          {"type": "condition", "fn": "enemy_in_close_range", "param": 6},
          {"type": "action", "fn": "move_away", "param": {"distance": 10}}
        ]
      },
      {"type": "subtree_ref", "id": "subtree_magic_attack_pattern"}
    ]
  }
}

2次出力はlintを通過し、プランナーによるレビューでavoid_meleeの距離6をarcherに合わせて5へ1段下げた後、シミュレーションゲートへ回しました。ここで学べることは明確です。AIはBTの骨格を素早く埋めてくれますが、「名前が似ている誤ったsubtreeを引っ張ってくる」「もっともらしい追加行動を仕様なしに差し込む」という2種類の事故をほぼ毎回起こします。この2つの事故は、人の目とlintゲートでしか捕まえられません。だからAIの出力は草案であって、最終版ではないのです。

7.2.5 自動lint — 人が見落とすものを機械が先に捕まえる

BTはユーザー体験に直結します。敵が目の前で逃げないという事故がそのままリリースされれば、レビュースコアとなって返ってきます。だからマージ前に、機械が先に検査します。

最後の項目がこのlintの特異な点です。同じranged_combatantに括られたBT 5体のシミュレーション平均応答時間が大きく開いたら、それは誰かが1体のバランスを知らないうちに壊したというシグナルです。静的検査では捕まえられない「空気」を統計で捕まえる仕掛けです。

静的lintの次はシミュレーション検証です。BTを実際のゲームビルドなしにシミュレーターで1,000回走らせ、統計を取ります。

ビルドを焼かなくても、5〜10分のうちに「このBTはあまりに早く死んでいないか」「一つの行動だけを繰り返していないか」を確認できます。異常シグナルが出たらjsonを直し、シミュレーションを回し直します。このサイクルが日単位から分単位へ縮むことこそ、json化の実質的な利益です。

flowchart LR
    P["人/AIが
BT jsonを編集"] --> L{"静的lint"}
    L -->|ブロック| P
    L -->|通過| R["プランナーによるレビュー"]
    R -->|却下| P
    R -->|承認| S{"シミュレーション1,000回"}
    S -->|異常シグナル| P
    S -->|正常| M["マージ + ビルド反映"]
    style L fill:#fef7e0,stroke:#fbbc04
    style S fill:#fef7e0,stroke:#fbbc04
    style M fill:#e6f4ea,stroke:#34a853

7.2.6 測定 — 何が減ったのか

筆者のプロジェクトAにおける導入前後を表にまとめます。絶対値はチーム規模・ゲームジャンルによって変わるため、著者の推定（未検証）です。ただし、方向と比率は実際の運用で観察したとおりです。

最も意味があるのは、最後の2行が同時に動いたという点です。普通、人員を減らせば品質は落ちます。ここではプランナーの数が減りながら、事故も減りました。人が手で追跡していた変更影響と検証を、機械が引き受けたからです。自動化の価値は「速くなる」ことよりも、この「減りながら同時に良くなる」ことにあります。

7.2.7 自社開発か、借用か

本章を読んで「うちもjson BTエディターを作ろう」と結論づけられては困ります。筆者のプロジェクトAが自社開発を選んだのは、特定の条件がかみ合ったからです。

プロジェクトAが3番を選んだ根拠は4つでした。

• diff・git追跡が必須でした — 組み込みBTはバイナリアセットのため、冒頭の「数字一つ」事故を追跡できませんでした。
• subtree参照と自動影響追跡が運用の核心でした — 標準のBTツールでは弱い機能です。
• ビルドと分離されたランタイムでシミュレーション検証を回す必要がありました。
• AIによる補助作成を前提としていました — テキスト（json）ベースは大規模言語モデル（LLM、Large Language Model）に圧倒的に親和的です。

開発コストは1〜2か月。運用BTが100〜300体に達し、運営（ライブオプス）の期間が長くて初めて回収できます。30〜50体の規模では回収できません。自社開発の投資回収（ROI、Return On Investment）は、規模と運営期間の両方が保証されるときにだけ成立するという意味です。小さなチームなら、本章からは「jsonで保存する」「subtreeで参照する」「AIの出力はlint+レビューゲートを通す」という原則だけを持ち帰り、ツールは組み込みエディターや外部ライブラリーの上に載せて使うほうが正しいのです。

7.2.8 よくある失敗

本章のポイント

• BTをjsonで保存してこそ、「数字一つ」の事故がgit diffに残り、追跡できます。
• subtree参照と自動影響追跡が、100体運用のコピペ地獄を防ぎます。
• AIはBTの骨格を素早く埋めますが、誤った参照と仕様外の行動は人が捕まえます。

やってみよう

小さなチームが今日から試せる最小サイクルです。

setup — 運用中の敵NPC 1体のBTを、手作業でjsonに書き起こしてみましょう（bt_id、category、tags、root）。共通の後退・攻撃パターンを一塊、subtree_library/に切り出してsubtree_refで参照します。

prompt — 似た系統の新しい敵1体をAIに任せてみましょう。上のワークド・トランスクリプトのプロンプト骨格（コンセプト+category+参考BT+使用可能な関数enum+「明示されていない行動の追加は禁止」+「jsonのみ」）をそのまま使えば大丈夫です。

verify — AIの出力を、（1）enum外の関数・存在しないsubtreeをはじくlint、（2）人の目、（3）シミュレーションまたはインゲームでの短い検証、この3つのゲートに通した後にだけマージしましょう。AIが「名前の似た誤ったsubtree」と「もっともらしい仕様外の行動」を差し込んでいないか、必ず確認してください。

一人ミニ版

エディターを作る余力がなければ、ツールはテキストエディターとgit、そして30行のbt_impact_tracker.pyが1つあれば十分です。組み込みエディターで組んだBTを一度jsonにエクスポートしてgitに上げ、subtreeだけを別ファイルに切り出して参照しましょう。影響追跡スクリプトをコミットフックに掛ければ、一人でも「この後退パターンを直したらどの敵が変わるのか」を、推測ではなく出力として見られます。この一つの習慣だけで、冒頭の「数字一つに1時間」はコードレビューの1行に縮みます。

次章のプレビュー

• 7.3 ダンジョン・フィールドパターンライブラリー — ルームメタデータとsubtreeパターンを組み合わせ、レベルを運用単位で束ねます。

7.3 ダンジョン・フィールドのパターンライブラリー

ダンジョンレビューの席で、新人のレベルデザイナーが自分のダンジョンを1つ画面に映しました。狭い通路、後方から追いすがる速い敵、分岐点での回避の決断。よくできたダンジョンでした。問題は、それが私たちがすでに11個の別のダンジョンで作ってきたものと微妙に違っていたという点です。敵の追跡速度、罠が作動するタイミング、分岐点が現れる時点。どれ1つとして同じではありませんでした。新人は「追跡ダンジョン」という同じ名前の体験を作ったと信じていましたが、ユーザーが受け取った感覚はダンジョンごとにばらばらでした。

その日、私たちが決めたことは単純でした。「通路追跡」という体験を一度だけ正確に定義し、その定義を固定化しておくこと。次に誰かが追跡ダンジョンを作るときは、ゼロから組むのではなく、その固定化された定義を取り出して使うこと。これがパターンライブラリーの始まりでした。

ルームが空間の単位で、BehaviorTreeが行動の単位だとすれば、パターンは空間と行動とイベントを1つに束ねた運用単位です。パターン1つが複数のダンジョンで再利用されれば量産の負担が減り、さらに重要なことに、ユーザーが受け取る体験がダンジョンの間で一貫します。

7.3.1 パターンという運用単位

料理本のレシピを思い浮かべるとぴったりです。レシピ1枚には材料、調理手順、火加減、完成写真が一緒に載っています。店が変わっても、同じレシピに従えば同じ味になります。ただし店ごとに多少のバリエーションは許容します。パターンも同じです。空間（ルーム）、行動（BT subtree）、出来事（event）、結果（報酬・難易度）、そしてデザイナーによる意図の説明が1セットで入ります。

パターンが1つ定義されると、ダンジョンごとに同じ体験を一貫して作れるようになります。一度検証されたレシピが、複数の店で同じ味を出すように。ただし同じレシピでも、店ごとに多少のバリエーションは持たせます。このバリエーションをどう管理するかが、パターン運用の半分です。後ほど扱うoverridesがその場所です。

7.3.2 パターン組み合わせのフロー

パターンライブラリーの核心は、パターンをルールブックとして固定化したうえで、それを組み合わせてダンジョンを生成するという点です。デザイナーが白紙の画面からダンジョンを組むのではなく、検証済みのパターンを選んで配置し、一部だけバリエーションを加えます。

flowchart TD
    A[ゲーム内の良い体験の瞬間を観察] --> B[空間・NPC・イベントに分解]
    B --> C[ルームテンプレート・subtreeにマッピング]
    C --> D{シミュレーション + ユーザーテスト通過?}
    D -- いいえ --> B
    D -- はい --> E[ライブラリーにパターンを登録
usage_count = 0]
    E --> F[(パターンライブラリー
5カテゴリー · 30〜50個)]
    F --> G[ダンジョンデザイン: パターンインスタンス呼び出し]
    G --> H[配置 placement + バリエーション overrides]
    H --> I{バリエーション比率20%以下?}
    I -- はい --> J[ダンジョン完成
パターン usage_count +1]
    I -- いいえ --> K[別パターンとしての分離を検討]
    K --> B
    J --> L[パターン影響追跡
パターン1つの修正 → 使用ダンジョンを自動集計]
    L --> F

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    class L code;
    class F data;
    class J pass;

このフローの左半分（観察→分解→マッピング→検証→登録）はパターンを作る過程で、右半分（呼び出し→配置・バリエーション→完成→追跡）はパターンを消費する過程です。作る仕事はまれにしか起きず、消費する仕事は頻繁に起きます。ライブラリーがうまく運用されれば、この非対称が量産効率につながります。

7.3.3 5つの基本カテゴリー

著者のプロジェクトAはアクションRPG系なので、5つのカテゴリーでパターンを分類しています。この分類はジャンルに依存します。ホラーゲームなら待ち伏せとナラティブビートの比重が違うでしょうし、パズルゲームなら環境を活用した戦闘が中心に来るでしょう。分類そのものを絶対視せず、自分のゲームの核心体験が何かをまず決めてから、カテゴリーを定めるべきです。

5つのカテゴリーの中で、パターンはおおよそ30から50個の間を維持します。この数字には理由があります。パターンが100個を超えると、デザイナーがライブラリー全体を頭の中に収められなくなります。その瞬間、ライブラリーは検索に時間のかかる倉庫になり、デザイナーはいっそ新しく組むほうを選びます。ライブラリーがそっぽを向かれ始めると、一貫性という本来の目標が崩れます。だからこそ、パターン数の上限を意識的に管理することが、カテゴリー設計と同じくらい重要です。

7.3.4 パターンを固定化するフォーマット

パターン1つはYAMLファイル1枚で固定化されます。以下はプロジェクトAで実際に使っている形式を匿名化したものです。会社固有のアセット名とダンジョン番号は伏せましたが、フィールド構造と運用方式はそのままです。

---
pattern_id: pattern_corridor_pursuit_v2
category: pursuit
description: 狭い通路で速い敵が後方から追跡、プレイヤーは分岐点で回避を決定
tags: [horizontal_corridor, scholar_theme_compatible]
rooms:
  - room_template: corridor_long
    size: medium
    connections_required: 2
  - room_template: junction_3way
    size: small
    connections_required: 3
npc_behaviors:
  - subtree_ref: subtree_aggressive_chase
    count: 2
  - subtree_ref: subtree_ranged_support
    count: 1
events:
  - type: trap_activation
    trigger: room_1_midpoint
  - type: enemy_spawn
    trigger: room_1_entry
difficulty_modifier: 1.2   # 一般ルーム比1.2倍の負担
reward_modifier: 1.3
clear_time_estimate_sec: 60
art_pack_compatible: [scholar_library, generic_dungeon]
narrative_slots:
  - slot: dialogue_during_chase
    constraints: [short_dialogue, fear_emotion]
usage_count: 12            # 12個のダンジョンで使用
last_modified: 2026-05-18
deprecated: false
---

このファイルが、12個のダンジョンの一部分ずつを同時に定義しています。usage_count: 12という1行の重みはそこから来ます。このパターンを修正すれば12個のダンジョンが一斉に影響を受けるという意味であり、だからこそパターンファイルに手を入れることは、ルーム1つを直すこととは別の重みを持ちます。

subtree_aggressive_chaseやsubtree_ranged_supportのような参照は、7.2のBehaviorTreeエディターで定義したsubtreeをそのまま指しています。パターンがBTを直接抱え込まず、参照だけするのが核心です。BTを直せば、そのBTを参照するすべてのパターンが自動的についてきます。空間（ルームテンプレート）と行動（subtree）はそれぞれのライブラリーで管理され、パターンはその2つを結ぶ組み合わせ表の役割だけを担います。clear_time_estimate_secやdifficulty_modifierのような数値は著者の環境の運用値にすぎず、普遍的な定数ではありません。自分のゲームのシミュレーションとユーザーテストで直接測定して埋めるべきです。

7.3.5 パターンをダンジョンにインスタンス化する

ダンジョンをデザインするときは、パターンをゼロから組みません。ライブラリーから呼び出し、どこに置くかを指定し、このダンジョンでだけ変える部分をoverridesで上書きします。

---
dungeon_id: dungeon_021_silvermark_library
pattern_instances:
  - instance: corridor_pursuit_1
    pattern_id: pattern_corridor_pursuit_v2
    placement:
      - room_id: dungeon_021_room_03
        as: corridor_long
      - room_id: dungeon_021_room_04
        as: junction_3way
    overrides:
      - field: npc_behaviors.0.subtree_ref
        value: subtree_scholar_chase   # 学者テーマの変種
      - field: events.0.trigger
        value: room_1_2nd_third         # トリガー位置の微調整
---

ここでダンジョン021は「通路追跡」パターンをそのまま使いつつ、追ってくる敵を一般の敵から学者テーマの変種に変え、罠が作動する位置を通路の中間から少し後ろにずらしました。パターンの80%はそのまま、20%だけバリエーションを加えています。

この比率には、運用経験から得た根拠があります。バリエーションが少なすぎると（0%に近いと）、ダンジョン同士が写し合ったようで飽きられます。バリエーションが多すぎると（50%を超えると）、それはもう同じパターンではありません。同じパターンを呼び出したと信じていても実際の体験はまったく別物という、新人が持ってきたあのダンジョンとそっくりの状況に逆戻りします。だから私たちは運用ルールを置いています。1つのインスタンスのoverridesがパターンのフィールドの半分を超えたら、それはバリエーションではなく新しいパターンの兆候です。別パターンとして分離すべきときが来たのです。

7.3.6 1行直すとどこが揺れるのか

pattern_corridor_pursuit_v2を修正すると、12個のダンジョンが影響を受けます。人がこれを手で追跡すると、必ず1つや2つは漏らします。だから、パターンとダンジョンの関係を自動で洗い出す小さなツールを置きます。

# pattern_impact.py
import json
from glob import glob

def find_dungeons_using(pattern_id):
    affected = []
    for d in glob("dungeons/*.json"):
        dungeon = json.load(open(d, encoding="utf-8"))
        for inst in dungeon.get("pattern_instances", []):
            if inst["pattern_id"] == pattern_id:
                affected.append({
                    "dungeon": dungeon["dungeon_id"],
                    "instance": inst["instance"],
                    "has_overrides": bool(inst.get("overrides")),
                })
    return affected

この関数が返すリストの核心はhas_overridesフラグです。overridesのないダンジョンはパターンをそのまま使っているので、自動更新しても安全です。overridesのあるダンジョンは、そのダンジョン固有のバリエーションがパターン修正と衝突しうるため、人による追加チェックが必要です。

修正の重みを人がいちいち感じ取る代わりに、ツールが「今回の修正でダンジョン12個が影響を受け、そのうち4個はバリエーションがあるので直接見る必要がある」と5分以内に報告するようにします。パターン変更への恐れを減らしてくれることが、このツールの本当の価値です。影響範囲が見えなければ、デザイナーはパターンをそもそも直そうとしなくなり、ライブラリーは更新されないままよどんでいきます。

7.3.7 パターンはどのように生まれるのか、そしてAIの居場所

ここで、最もよく受ける質問に正面から答えます。「パターンの作成もAIに任せればいいのではないですか？」

答えははっきりしています。だめです。パターン1つを作成する仕事は、デザイナーのインサイトが背骨です。良い追跡体験とは何か、分岐点がなぜそこでなければならないのか、罠がなぜ通路の中間ではなく2/3地点で作動してこそ緊張が生きるのか — これは、ゲームを直接触り、ユーザーの反応を見てきた人の判断です。AIにパターンをゼロから組ませると、すべてのパターンが無難で平均的な形に収束します。ライブラリーは「間違っていないパターン」で埋め尽くされますが、「記憶に残るパターン」は消えていきます。

だからといって、AIにやることがないわけではありません。パターン作成の5段階のうち2か所で、AIは強力な補助になります。

3段階目がAI補助の核心です。デザイナーが「狭い通路で速い敵が後方から追跡する」というドラフトを書いたとき、すでに数十個ずつ積み上がったルームテンプレートとsubtreeのライブラリーの中からどれがこの意図に合うかを、人が全部漁るのは非効率です。ここでAIにマッピング候補を推薦させます。以下は、実際に使っているプロンプトを匿名化したものです。

[入力]
- デザイナーのパターンドラフト yaml (下に添付)
- ルームテンプレートライブラリー (名前 + タグ + サイズの一覧)
- subtree ライブラリー (名前 + 行動要約の一覧)

このパターンを実装するルームテンプレートとsubtreeをライブラリーから選んで推薦して。
それぞれ2~3個ずつ、適合度1~5点とタグ・サイズ基準の一行の根拠を付けて。
ライブラリーにないものはでっち上げず推薦だけ、全部3点以下なら新規作成が必要だと言って。

このプロンプトにClaudeが実際に返した出力は次のとおりです。どこでためらい、どこで断言しているかがそのまま現れるよう、一文字も手を加えずに載せます。

ルームテンプレート候補:
1. corridor_long  (適合度 5)
   根拠: タグ horizontal_corridor が一致、size medium が「狭い通路」の意図に合致。
2. corridor_narrow_short  (適合度 3)
   根拠: 狭くはあるが長さが短く、追跡距離の確保が難しい。分岐点を配置する空間が不足。
3. hall_wide  (適合度 1)
   根拠: 広いホールは「狭い通路」の意図と正反対。追跡の圧迫感が生きない。

subtree 候補:
1. subtree_aggressive_chase  (適合度 5)
   根拠: 後方追跡の行動が定義済み、移動速度の重み付けあり。
2. subtree_ranged_support  (適合度 3)
   根拠: 追跡そのものではないが、圧迫の補助用に1体配置可能。
3. subtree_patrol_basic  (適合度 2)
   根拠: 巡回行動は追跡の意図と合わない。トリガー後に追跡へ切り替えるノードがない。

分岐点(junction)ルームテンプレート:
ライブラリーで 3way 分岐 + small サイズの条件を同時に満たす項目を
見つけられませんでした。junction_3way が最も近いものの size タグが空のため
適合度を確定できません。デザイナーの確認が必要です。

最後の段落が、この出力で最も価値ある部分です。AIは分岐点のルームテンプレートについて「確実ではない」と述べ、存在しない答えをでっち上げませんでした。デザイナーはこの報告を受けて、junction_3wayのsizeタグが実際に空であるという事実を発見し、まずそのメタデータから埋めました。もしAIが空のタグを無視して適合度5を付けていたら、デザイナーは誤った信頼のままそれを採用していたでしょう。

これがAI補助の正しい形です。AIは候補を広げ、不確実さを表示し、選択と責任はデザイナーに残ります。マッピングの結果、適合度がすべて低ければ、そのときは新しいテンプレートを作成する別の作業が発生し、その作成はまた人の仕事になります。

[方向標識 — パターンを「体験ベクトル」に圧縮してみるなら（まだ時期尚早）] 処方ではなく、研究動向として読んでください。§7.3.1がすでにパターンを「レシピ」と呼んでいます。1つのパターンは、ルームメタ・行動subtree・event・difficulty/reward_modifier・clear_timeが1セットになった座標値に近いものです。この束を「体験ベクトル」に圧縮すれば、適合度がすべて低いときに新規を組むという上記のフローを、いちいち漁る代わりに圧縮空間の空白領域として捉えられ、§7.3.8のdeprecated判定も、近接する重複を座標距離で補強できます。ただし3つの留保が付きます。difficulty/reward_modifierは§7.3.4のとおり著者の運用値であり、ゲームごとに軸のスケールが違うため圧縮空間をそのまま移植できないこと。補間はパターンの「生成」ではなく空白の「標識」までであること。そして、その標識の上でパターンを実際に組む仕事は依然としてデザイナーのインサイトが背骨だという、本節の原則を超えないこと。この発想は§8.2.7の次元ベクトル圧縮と同じ場所にあり、概念の直観は付録Mにあります — 土台が十分に積み上がったチームが数年後にのぞき込む領域として残しておきます。

7.3.8 使われないパターンを整理する

ライブラリーは、埋めることより空けることのほうが難しいものです。運用を1年ほど続けると、作ったままほとんど使われないパターンが溜まります。放っておくとライブラリーの検索コストが上がり、デザイナーがパターンを選ぶとき、死んだ選択肢までなめる必要が出てきます。だから定期的に整理します。

核心は、廃棄が削除ではないという点です。すでにそのパターンを使っているダンジョンはそのまま残します。ライブサービスで稼働中のダンジョンに手を入れることのほうが、新規での使用を止めることより危険だからです。deprecated: trueは「今後新しく使わない」という標識にすぎず、過去を消す命令ではありません。

机の引き出しの使わない道具を四半期に一度取り出して整理するように、ライブラリーも四半期に一度整理する日程を組んでおきます。この日程がなければライブラリーは一方向にだけ膨らみ、いつしかデザイナーがそっぽを向く倉庫になります。

7.3.9 効果を正直に測定する

著者のプロジェクトAでパターンライブラリーを1年運用して観察した変化です。下の表の時間数値は著者の環境での推定（未検証）であり、方向と相対比率だけが実際に観察されたものです。

最も印象的だった変化は、最後から2行目の新人オンボーディングです。パターンライブラリーは、意図せずデザインの教科書の役割を果たしました。新人が「このゲームの追跡体験はこう作る」をパターンファイル1枚で読んで理解できるようになり、先輩が横について説明する時間が大きく減りました。最初に新人が持ってきた、ばらばらなダンジョンの問題が、ライブラリーそのものによって解消されたわけです。

「パターン1個あたりの使用ダンジョン平均約8個」という数字は、同じパターンを8回再利用したという意味であり、これが量産効率の正直な物差しです。ただし、この8という値は著者のゲームのダンジョン規模とパターン設計に依存します。ダンジョン数が少なかったり、毎回違うコンセプトを要求されたりするゲームでは、この値はずっと小さくなります。

7.3.10 ライブラリーを作らないという決定

最後に、この章全体をひっくり返す話をしてこそ正直というものです。パターンライブラリーは万能ではありません。ライブラリーを構築・運用するコストが回収されない環境は、確かにあります。

ライブラリーのROI（Return on Investment、投資対効果）は、3つの条件がそろったときに回収されます。運営（ライブオプス）があり、デザイナーが3人以上で、ダンジョンが20個を超える場合です。運営型MMORPGが典型的な適用対象である理由はここにあります。上の表のどれかの行に自分のプロジェクトが当てはまるなら、ライブラリーを建てる前に立ち止まって考え直すべきです。ツールは問題があるときにだけ価値があり、ダンジョン5個のプロジェクトにとって、パターンライブラリーは問題よりコストのほうが大きいのです。

7.3.11 よくある失敗と処方箋

この表の2行目と4行目が、最もよく足を引っ張ります。影響追跡を自動化しなければデザイナーがパターン修正を恐れてライブラリーが固まり、作成をAIに委任すればライブラリーが平均に収束します。どちらの失敗も、ライブラリーの生命である「検証された体験の再利用」を殺してしまいます。

7.3.12 第7部を締めくくる

第7部は、レベル分野を3つの層で積み上げてきました。7.1でルームメタデータとタグと接続性の標準を立て（空間）、7.2でJSONベースのBehaviorTreeエディターとsubtreeとシミュレーションを扱い（行動）、本章でその2つをイベントとともに束ねて再利用するパターンライブラリーに到達しました（運用単位）。空間と行動を別々に扱う運用の中で、同じ場所の決定が毎週違う形で揺れていたあの問題を、パターンという束として固定化して解決したことが、第7部全体の幹です。

この流れは、Layer統合設計とそのままかみ合います。ゲーム全体の空間のトーンというビジョンが上にあり、その下にレベル生成ルールとBTルールというシステムがあり、ルームとBTとパターンライブラリーがコンテンツ層を成し、ダンジョンインスタンスとパターン使用統計がデータとして積み上がり、lintとシミュレーションとユーザーテレメトリーがビルド・QAでこれを検証します。パターンライブラリーはこの5層のうちコンテンツ層の背骨でありながら、上に向かってはシステムのルールに従い、下に向かってはデータの統計を生成する連結リングです。

本章のポイント

• パターンは空間・行動・イベントを束ねた運用単位であり、3つを別々に扱うと同じ体験が毎週違う形で揺れます
• 80%の再利用 + 20%のバリエーションが推奨比率で、バリエーションが半分を超えたら、それは新しいパターンの兆候です
• パターン作成はデザイナーのインサイトの場所であり、AIはマッピング候補の推薦とシミュレーション補助までです

次章のプレビュー

• 8.1 CombatBalance・CombatFormula運用 — バランスデザインの2文書分離

やってみよう — 追跡パターンを1つ固定化する

setup

1. 作業フォルダーにpatterns/とdungeons/の2つのディレクトリーを作ってください。
2. ルームテンプレート名の一覧とsubtree名の一覧を、それぞれ1行ずつ書いたテキストファイルとして準備してください（ライブラリーがなければ、架空の名前5個ずつで始めても構いません）。
3. 上の本文のpattern_impact.pyをそのまま保存してください。

prompt

デザイナーが自分でパターンのドラフトyamlを書きます（この部分は人の仕事です）。そのうえで、AIにはマッピングだけを任せましょう。本文のマッピングプロンプトをそのまま使い、入力に自分のドラフトと2つのライブラリー一覧を添えてください。核心となる制約の2行を落とさないでください。

- ライブラリーにない新しいテンプレートをでっち上げないでください。推薦だけにしてください。
- 適合度がすべて3以下なら、新規作成が必要だと明記してください。

verify

1. AIがライブラリーにないテンプレート名をでっち上げていないか、1行ずつ確認してください。
2. 適合度スコアにタグ・サイズ基準の根拠が付いているかを見てください。根拠のないスコアは信頼しないでください。
3. パターンをダンジョン2個以上にインスタンス化したうえでfind_dungeons_using("pattern_...")を実行し、その2つのダンジョンが正確に捕捉されるか確認してください。

一人ミニ版

一人で小さなゲームを作るなら、ライブラリーシステムは過剰です。代わりに、いちばん気に入っているダンジョン区間を1つ選び、その体験をyaml1枚に書き留めておくだけでも十分です。次のダンジョンを作るときに、その1枚を開いてコピーし、20%だけ直してみましょう。パターンライブラリーの本質 — 検証された体験の再利用 — は、ファイル1枚でも機能します。規模が大きくなったら、そのときにカテゴリーと追跡ツールを足せばよいのです。

第8部 · Balance Design

8.1 戦闘バランス公式 — 決定論というルールブックの居場所

本章の学習目標（難易度🟡実務・前提：四則演算・表計算）：戦闘バランスを公式の居場所と数値の居場所に分離し、決定論・追跡可能性という2つの性質を根拠に、どこまでAIに任せ、どこから人がルールブックでロックすべきかを区別できるようになります。

午前2時、ライブサーバーのタンク職の生存率が89%に達したというアラートが届きました。ボスを最後まで倒せないタンクはいない一方で、死なないタンクが多すぎる。誰かが手を入れた痕跡を探そうと、マスターデータを開きます。防御係数の1行が目に入ります。DEF / (DEF + 1000)。この1000という数字がいつ、誰の手で、どんな根拠で1200から1000に引き下げられたのか、シートのどこにも書かれていません。チャットログを漁り、ビルド履歴を漁り、最後は3年前に退職したバランス担当者の記憶にたどり着いてようやく終わる追跡が始まります。

この場面は、戦闘バランスの運用を経験した人なら誰でも一度は通ります。そして、この場面の本当の原因は、その1000という数字が間違っていたことではありません。その数字が公式の居場所に住んでいたのに、公式が変わった履歴がどこにもなかったことにあります。戦闘バランスの公式は、ゲームの中で最も決定論的であるべき領域であり、最も追跡可能であるべき領域です。この2つの性質がなぜ、AIをこの場所に入れてはいけない理由になるのか。それが本章の背骨です。

専門外の方のための一言。 この部で出てくるz-score・シミュレーション・曲線になじみがなくても大丈夫です。持ち帰っていただきたいのは、ただ一つです — 「同じ入力には常に同じ出力でなければならないルール（公式）には、AIを入れない」。決定論が必要な場所と探索が必要な場所を分けるこの判断は、会計規定・精算ロジック・契約条項のような「間違えてはいけないルール」を扱うあらゆる職種に、そのまま持ち込めます。数式そのものは8.1.2からゆっくり見ていただいてかまいません。

8.1.1 公式はルールブックである

ゲームデザインを長く続けていると、2種類のドキュメントが手に残ります。頻繁に変わるドキュメントと、ほとんど変わらないドキュメントです。戦闘バランスでほとんど変わらない側が公式です。「ダメージをどう計算するか」は四半期に1〜2回しか手を入れませんが、「このキャラクターの攻撃力はいくつか」は週に5〜6回手を入れます。頻度の違う2つの流れを1つのファイルに束ねると、頻繁に開け閉めする手の力で、たまにしか開け閉めしない紙のほうが破れてしまいます。

著者が運営するプロジェクトAでは、戦闘バランスは2つの居場所に分離されています。公式の居場所（ここではCombatFormulaと呼びます）と、数値の居場所（CombatBalance）です。公式の居場所に住む1行を、そのまま引用します。

final_damage = base_damage × dmg_multiplier × (1 − defense_factor) × variation

  base_damage    = skill_base × ATK × skill_coeff
  defense_factor = DEF / (DEF + 1000)
  variation      = uniform(0.95, 1.05)

この公式はルールブックです。ボードゲームのルール冊子を思い浮かべてください。ルール冊子には「サイコロを振って出た目の数だけ進む」と書いてあり、「今回は運が良ければもう少し進んでもよい」とは書いてありません。同じ入力には、常に同じ出力。これが決定論（determinism）です。攻撃力180、防御力80、スキル係数2.1を入れたら、いつどこで何回計算しても同じダメージが出なければなりません。もし同じ入力に違う出力が出るなら、それはバランスツールではなくギャンブルマシンです。

この決定論という1つの性質こそ、AIをこの場所に入れてはいけない第一の理由です。これは後ほど改めて見ます。まず、公式がルールブックらしくあるためにはどんな形であるべきかを見ていきましょう。

戦闘公式の中核領域は、ダメージの1行では終わりません。少なくとも3行が1セットで住んでいます。

# ダメージ
final_damage = base_damage × dmg_multiplier × (1 − defense_factor) × variation

# クリティカル
crit_damage  = final_damage × crit_multiplier
crit_chance  = base_crit + (LUK × 0.1)            # 上限 50%

# 回復
heal         = base_heal × healing_power × (1 − sickness_factor)

この3行を自然言語ではなくコードブロックで書くことには理由があります。自然言語は解釈の余地を残します。「防御力が高いほどダメージが減る」という文は、線形に減るのか、曲線で減るのか、どこで止まるのかを語りません。DEF / (DEF + 1000)は、ただ一通りにしか読めません。解釈の余地を0にするのがルールブックの仕事です。

8.1.2 曲線が決定論を決める

防御係数DEF / (DEF + 1000)の1行に、このゲームのバランス哲学の全体が詰まっています。この1行をグラフに描いてみると、なぜそうなのかが見えてきます。横軸が防御力、縦軸が受けるダメージを軽減する割合です。

この曲線は漸近線（asymptote）にゆっくり近づいていきます。防御力1000でダメージをちょうど半分に削り、その先はどれだけ上げても100%には届きません。無敵が不可能であることが、この1行に織り込まれています。灰色の点線のように線形だったら、防御力1000でダメージをすべて防ぎ、それ以上はマイナスダメージ（殴られるほどHPが回復する）という意味の通らない領域に突入します。だから線形は採用しませんでした。

ここで午前2時の事故に戻ってみましょう。誰かがこの1000を1200に上げたとします。曲線全体が右に押しやられます。同じ防御力で防げるダメージが減るので、ゲーム全体のタンクが弱くなり、アタッカーの時間あたりダメージが上がります。公式の定数1つがゲーム全体を揺るがします。 数値1つ（あるキャラクターの攻撃力）を変えるのとは、影響の大きさが違います。この差こそ、公式と数値を別の居場所に置くべき理由であり、公式の変更には必ず履歴が付いて回らなければならない理由です。

8.1.3 公式の変更には履歴が付いて回る

午前2時の追跡が地獄だった理由はただ一つ、変更履歴がなかったからです。プロジェクトAでは、公式の変更はコードを1行直す作業ではなく、決定1件を記録する作業です。公式の隣にはCombatFormula_Decisionsという別ドキュメントが付いて回り、そこにはこう書かれます。

## 決定 D17 (2026-04-22)
- 変更: defense_factorを DEF/(DEF+1000) → DEF/(DEF+1500)
- 事由: 高レベル帯(LV40+)でタンク生存率89%（ライブ測定）。ボス戦が間延びする原因。
- 試行 1: 800でシミュレーション → タンク死亡率が急増、ボス入場1分以内の全滅多数 → ロールバック
- 試行 2: 1200でシミュレーション → 生存率75% → 良好だが目標(60~70%)より高い
- 試行 3: 1500を採用 → シミュレーション生存率65%（目標範囲内）
- 影響 atom: combat_defense_formula, combat_tank_class_balance
- 事後測定(1週): ライブ生存率67%（シミュレーション予測65%比 +2%、範囲内）

この1件が、6か月後の「なぜこうなったのか」に答えます。さらに重要なのは、試行1と試行2が残っているという点です。800がなぜダメだったのか、1200がなぜ採用されなかったのかが記録されていれば、次の人が同じ失敗を繰り返さずに済みます。新しいバランス担当者が合流したとき、この決定ログ一式が最高のオンボーディング資料になります。

ここで正直に断っておくことが一つあります。上の試行1・2・3のシミュレーション数値（死亡率、生存率75%、65%）は、運用の流れを示すための著者の推定値（未検証）です。実際のゲームごとに曲線も目標範囲も異なります。ただし、「変更には試行が伴い、試行にはシミュレーションの根拠が伴い、採用の後には事後測定が伴う」という構造は、実際の運用そのままです。この構造のどこか1マスでも空けば、その空白が午前2時の追跡となって戻ってきます。

公式・数値・履歴という3つの居場所を一望すると、こうなります。

8.1.4 一つの公式が変わる実際の流れ

ここからは、D17がどう決定されたのかを最初からたどってみます。これが、決定論的なルールブックが実務で動く姿です。

flowchart TD
    A["ライブ測定
タンク生存率89%を検知"] --> B["原因仮説
防御係数1000が後半で過保護"]
    B --> C["変更候補の定義
1500 / 1200 / 800"]
    C --> D["Damage Simulator
候補ごとに1,000回の決定論実行"]
    D --> E["結果レポート
生存率・平均戦闘時間・勝率"]
    E --> F{"バランス担当者の判断
目標60〜70%の範囲内？"}
    F -->|"800: 死亡率が急増"| G["棄却 → ログ試行1"]
    F -->|"1200: 75%、やや高い"| H["保留 → ログ試行2"]
    F -->|"1500: 65%、範囲内"| I["採用 → 決定D17"]
    I --> J["ビルド反映（不可逆）"]
    J --> K["1週間後にライブ事後測定
67%、予測比+2%"]

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef human fill:#fde68a,stroke:#b45309,color:#000;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    classDef pass fill:#dcfce7,stroke:#16a34a,color:#14532d;
    classDef fail fill:#fee2e2,stroke:#dc2626,color:#7f1d1d;
    class D code;
    class B,C,F human;
    class A,E,K data;
    class I pass;
    class G fail;

この流れでは、シミュレーターの役割を正確に見る必要があります。Damage Simulatorは3つの候補をそれぞれ1,000回ずつ回します。ここでの1,000回は、同じ入力を1,000回繰り返すという意味ではありません。公式の中のvariation = uniform(0.95, 1.05)という±5%の乱数と、クリティカル率というもう一つの乱数のせいで、1戦1戦の結果が異なります。1,000戦を回して分布を見ます。平均生存率、最悪ケース、戦闘時間のばらつきを見るのです。

このシミュレーター自体が決定論的でなければならない、という点が重要です。同じ乱数シードを与えれば、1,000戦が一字一句違わず再現されなければなりません。そうしてはじめて、「1500で65%が出た」というD17の1行が、6か月後にもまったく同じように再現され、検証できます。シミュレーターが毎回違う結果を出すなら、決定ログは嘘になります。

著者がこのダメージシミュレーターを最初に作ったのは2008年です。当時はExcelマクロでしたが、今のプロジェクトAではbalance-simスキルとしてカプセル化されています。18年の間にツールの外側は変わりましたが、中に入っているルールブックは一度も確率的だったことがありません。これが核心です。

8.1.5 なぜ報酬曲線と公式にAIは絶対禁止なのか

いよいよ、本章が最も言いたいことにたどり着きます。AIがゲームデザインのほぼすべての場所に入り込んでいる今、ただ一つ、絶対に入れてはいけない場所があります。戦闘公式と報酬曲線という、決定論の中核です。

LLMは本質的に確率的です。同じ質問に、毎回少しずつ違う答えを返します。それが良い文章とアイデアを生み出す力の源泉ですが、ルールブックの居場所には致命的です。「防御力80のキャラクターはダメージをいくつ受けるか」をLLMに答えさせると、今日は92、明日は94と答えかねません。ボードゲームのルール冊子で、ページをめくるたびにサイコロの目の意味が変わるようなものです。

報酬曲線はさらに危険です。「レベル30から31に上がるときの必要経験値」は、一度決めれば数十万人の進行速度を同時に規定します。ここに±2%の揺らぎが入るだけで、あるユーザーは同じ狩りをしても隣の人より遅く育ちます。公平性が崩れます。決定論は公正さと同義です。だから報酬曲線は人が手で決め、シートに入力し、二度と確率には任せません。

とはいえ、バランス領域全体からAIを追い出せという話ではありません。境界こそが核心です。

線は明確です。AIは決定論コアの外側にだけ住みます。 計算しシミュレーションする内側はルールブックの領分であり、分析し、提案し、文章に起こす外側がAIの居場所です。この線を一度越えると、同じ入力に違う結果が出始め、その瞬間からバランスツールは信頼を失います。

この境界は、8.2で見る経済システムとまったく同じ構造です。経済でも、リソースの生産・消費の公式は決定論であり、インフレのパターン検知がAIの居場所です。バランス分野全体が同じ骨格で動いています。

8.1.6 もう一歩先へ — z-scoreで候補を発議する先進的適用

ここまでは、人が候補を作り、シミュレーションが検証する保守的適用でした。もう一歩進めば、候補を作る仕事までツールが代行できます。ただし、ルールブックは依然として人と決定論のものです。

異常パターン検知が出発点です。1,000戦のシミュレーション結果からキャラクターごとの勝率・生存率の分布を見て、平均から標準偏差の何倍離れているかをz-scoreで測ります。zが2を超えるキャラクターは「正常範囲外」として自動的にマークされます。午前2時のタンクも、この検知に引っかかっていたはずです。

検知を候補の発議につなげるには、あと2つ必要です。1つ目は変更空間の定義です。CombatBalanceシートにtunable_rangeのような列を設け、「この数値はどの範囲までなら触ってよいか」を明示します。2つ目はシミュレーションの並列化です。候補10個 × 1,000戦 = 10,000戦をビルドゲートの時間内に回すには、並列インフラが必要です。

この3つ（z-score検知・変更空間の定義・シミュレーション並列化）がそろえば、バランス担当者の手に残る決定は「どの候補を採用するか」の一つに絞られます。候補を0から作る仕事と、5つの中から選ぶ仕事では、負担が違います。ここでもAIが触れるのは候補の発議とレポートの解釈だけで、シミュレーション内側の演算と採用の決定は、決定論と人の居場所です。

最後に可逆性に触れておきます。シートの修正もシミュレーションの実行も可逆なので、いくらでもやり直せます。不可逆なただ一つの場所が、ビルド反映です。ライブに出た数値は、ユーザーが目にした瞬間からコミュニティの反応として残り、ロールバックしても痕跡は消えません。だから、人によるチェックはすべて、ビルド反映の直前、可逆の段階で終わらせます。

やってみよう — 公式変更1件を安全に処理する

setup. 戦闘公式を自然言語の説明から切り離し、コードブロックだけで書いたCombatFormulaドキュメントと、その隣に空のCombatFormula_Decisionsログドキュメントを作りましょう。数値は別のシート（CombatBalance）に切り出します。

prompt. 公式の変更ではなく、分析・草案にだけAIを使いましょう。たとえば、シミュレーション結果のCSVを渡して、こう依頼します。

添付した1,000回のシミュレーション結果からキャラクター別勝率のz-scoreを計算し、
z>2のキャラクターを表に整理して。各キャラクターについて
どの数値（攻撃力/防御力/スキル係数）が異常の原因である可能性が高いか、
根拠とともに推定して。数値そのものは修正しないこと — 候補のみ提案。

verify. AIが出した候補をそのまま信じてはいけません。候補の数値をCombatBalanceシートに自分で入力し、Damage Simulator（またはbalance-sim）に同じシードを与えて1,000回を回し直します。確認するのは2つです。(1)シミュレーション結果が目標範囲に収まるか。(2)同じシードでもう一度回して、一字一句違わず再現されるか。両方通れば採用し、採用したらすぐに_Decisionsへ理由・試行（棄却した候補を含む）・予測値を書きましょう。ビルド反映の1週間後、ライブの測定値をそのログに追記します。

一人ミニ版

チームもシミュレーターもない1人開発でも、骨格は同じように機能します。公式はコードのコメントか、別の.md1枚にコードブロックで記録し、そのファイルの一番下に## 변경 이력を置きましょう。公式の定数を1つでも変えたら、日付・理由・変更前の値を1行書きます。シミュレーターは30行のPythonループで十分です。乱数シードを固定し、公式にキャラクターの数値を入れて1,000回回し、平均勝率だけ出力するだけでも、「勘で変えた」から「根拠で変えた」へ進めます。AIは、その出力CSVを読んで「どのキャラクターがおかしいか」を要約することだけに使いましょう。公式の1行をLLMに計算させることだけは、規模に関係なくやめましょう。

本章のポイント

• 戦闘公式は、同じ入力に同じ出力を返すルールブックであり、その決定論が崩れた瞬間、バランスツールはギャンブルマシンになります。
• 公式の変更には、理由・試行・事後測定を収めた決定履歴が必ず付いて回らなければ、6か月後の「なぜこうなったのか」に答えられません。
• AIは決定論コアの外側（異常検知・候補の発議・レポート）にだけ住み、公式の計算と報酬曲線には決して入り込みません。

8.2 経済モデルをMachinationsへ — インフレは会議ではなくシミュレーションで捕まえる

第一想定読者：ライブ経済に責任を持つMMORPGのバランス/システムプランナー（中規模（10〜50人）チーム） 一人/趣味の読者向け縮小バージョン：§8.2.10「一人ならこれだけ」

ゴールドが漏れ始めたことに最初に気づいたのは、請求書ではなく取引所でした。リリース2か月目、強化石の相場がじわりと上がり、1か月後には2倍になりました。原因を探るために会議を設定しましたが、会議室から出てきたのはすべて「感覚」でした。ある人は新ダンジョンの報酬が過剰だと言い、ある人は狩り場の効率が上がったせいだと言い、ある人は単に高レベルユーザーが増えたからだと言いました。どれももっともらしく、だからこそ何も決まりませんでした。1時間を推測で燃やし、「ひとまず来週もっとデータを見よう」で終わりました。

問題は、リソースが1つではないことにあります。ゴールド・強化石・評判・名誉・ソウルストーンがそれぞれsource（入ってくる経路）とsink（出ていく経路）を持ち、その経路同士が互いを養い合います。強化石のボスはゴールドも落とします。ゴールドで買った装備が強化石を燃やします。リソース5種にフローが数十本も絡み合うと、頭の中の計算機では1つのリソースの1週間の収支すら正直に出せません。本章はその絡み合いをMachinationsのノードモデルへ移し、経済変更の意思決定を会議の推測ではなくシミュレーションゲートで通す方法を扱います。経済設計の一般理論は他の本に十分書かれていますから、本章はその理論をAIワークフローで回す場面だけに集中します。

著者の実運用メモ 本章の事例は、著者が会社のR&Dフォルダで運用中の経済パイロット文書（Economy_Machinations_Pilot）と経済リサーチ作業領域を匿名化したものです。リソースの種類・source/sink構造・Pilot 4段階は実際の運用を忠実に写し、会社固有の名称・実数値は書籍用に置き換えるか、比率・方向のみで記しました。AI出力の本文は実際のセッションを再構成したものです。

8.2.1 経済は「リソース5種」ではなく「フロー数十本」

経済リソースを表に書くと5行なので、単純に見えます。落とし穴はリソースではなく、リソースをつなぐフローの本数にあります。

リソースは5種ですが、source・sinkは合わせて二十数個あり、しかもリソース同士が変換されます（ゴールドで強化石を買う取引所は、ゴールドのsinkであると同時に強化石のsourceです）。フローが互いを養い合った瞬間、「ゴールドを5%多く供給したら強化石の相場はどうなるか」のような質問は、1つのリソースだけを見ても答えが出ません。これがキャラクターバランス（8.1）と経済バランスの決定的に違う点です。キャラクターバランスは数式1行で閉じますが、経済は時間とともに累積する動的システムなので、1週間の収支が0に近くても、26週を累積すると取引所が崩れます。

だから経済作業の本質は「数字をうまく選ぶこと」ではなく、「フローが時間とともにどう累積するかをシミュレーションで見ること」です。そして、そのシミュレーションモデルを手で組んで修正する作業は退屈で、やるたびに抜け漏れが生まれます。反復的で抜けやすいドラフト作業、しかしレビューは人ががっちり握るべき仕事 — この手触りの作業こそ、AIと人の分業線が最もきれいに引ける場所です。

まず、本章が扱う経済循環の骨格を1枚で載せておきます。

%%{init: {"flowchart": {"defaultRenderer": "elk"}}}%%
flowchart LR
    subgraph SRC["source (リソース生産)"]
        H["狩り場"]
        Q["クエスト"]
        B["ダンジョンボス"]
        PVP["PvP/ギルド戦"]
    end
    subgraph POOL["pool (リソース貯蔵)"]
        G(("ゴールド"))
        S(("強化石"))
    end
    subgraph SINK["sink (リソース消費)"]
        UP["装備強化"]
        RP["修理/税金"]
        SH["勢力/ギルド商店"]
    end
    H --> G
    Q --> G
    B --> S
    PVP --> SH
    G -->|取引所での変換| S
    G --> UP
    S --> UP
    G --> RP
    UP -.->|強化石需要 ↑| S
    G -.->|"純流入 > 純流出のとき
インフレが累積"| POOL

    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class G,S data;

点線が本章の核心です。強化sinkが強化石の需要を引き上げて強化石の相場を押し上げ（UP -.-> S）、ゴールドの純流入が純流出を超えると、その超過分が毎週プール（pool）に積もってインフレとして累積します。この2本の点線を手計算で追跡するのは不可能なので、モデルが必要になります。

8.2.2 Machinations — 経済をノードグラフへ移すツール

Machinationsは、経済のフローをノードグラフとして描き、その上でシミュレーションを回すツールです。§8.2.1のmermaidを、実際に回せるモデルへ移す場面です。

これらのノードで経済をモデリングし、シミュレーションを1,000回回すと、単一の結果ではなく分布が得られます。「26週後のゴールド相場の中央値+X%、上位10%のユーザーは+Y%」のような形です。ただし、Machinationsは万能ではなく、導入自体がコストです。

そのため、Machinationsは無条件で導入するツールではありません。リソース5種以上+リソース変換フロー+運営（ライブオプス）という3つの条件が重なったときに元が取れます。リソース2〜3種の単純な経済ならExcelで十分で、その場合のMachinations導入は、効果より運用負担のほうが先に届きます。

8.2.3 ［ワークド・トランスクリプト］ゴールド単一リソースのモデルをAIでドラフトする

ツールの説明だけでは、これが実際に何を吐き出すのか分かりません。ゴールド1つをMachinationsモデルへ移す1サイクルを、入力プロンプトから人による拒否まで、最後まで追いかけます。入力プロンプトはそのままコピーして使え、出力は実際のセッションを再構成しました。

ステップ1 — 入力：ゴールドのフローを機械が読める表へ

まず、ゴールドのsource・sinkをマスターデータから抜き出して表にします。新しく書くのではなく、抽出です。

# gold_flows.yaml — ゴールド単一リソースのフロー (現行データシート抜粋)
resource: gold
sources:
  - id: hunting        # 狩り場ドロップ
    trigger: per_kill
    note: レベル帯別ドロップ曲線はreward_curveルールを適用
  - id: quest_reward   # クエスト報酬
    trigger: per_complete
  - id: market_sell    # 取引所での販売
    trigger: per_trade
sinks:
  - id: gear_buy       # 装備購入
  - id: enhance        # 強化コスト
  - id: repair         # 修理
  - id: tax            # 取引所税金 (sinkでありゴールド回収の核心)
# ユーザー行動分布(時間あたり狩り回数・クエスト完了率)はまだ空 → AIが仮定したら明示させる

ステップ2 — プロンプト：モデルを作らせつつ、仮定と形式を強制する

添付のgold_flows.yamlは、ゴールド単一リソースのsource 3個・sink 4個だ。
これをMachinationsモデルへ移すノード仕様のドラフトを作れ。

ルール:
1) 各フローをノード種類(Source/Drain/Pool/Converter)に分類せよ。
2) 各ノードに「1週基準・ユーザー1人あたり期待流量」の算式を提案しつつ、
   ユーザー行動の仮定(時間あたり狩り回数・クエスト完了率など)が必要なら
   その仮定を別の行に「★仮定」と明示せよ。仮定を本文に隠すな。
3) sourceの総流入とsinkの総流出を分離し、1週の純収支(net)を計算せよ。
4) 取引所税金(tax)がゴールドを経済から永久に除去する唯一のsinkであることを
   反映し、他のsink(強化・修理)はゴールドがNPCへ移動するだけで回収では
   ないことを区別せよ。
5) 君が「確信できない」仮定は別途★を付け、人の決定に渡せ。

出力形式: 表 (ノード | 種類 | 1週流量算式 | 仮定 | 確信度)。それ以外の説明は禁止。

このプロンプトで実際に長く書かれているのは、モデルを作れという指示ではなく、仮定をどこにどう書くかというルールです。経済モデリングでAIを自由に放つと、もっともらしい数字を、仮定を隠したまま吐き出します。そうなると、モデルが間違っていてもどこが間違っているのかを指させません。ユーザー行動の仮定を本文の外へ引きずり出し、別の行に立たせること — そこにこの依頼の重みがすべて載っています。仮定が見えてこそ、検証できます。

ステップ3 — Claudeの出力（再構成、抜粋）

| ノード        | 種類      | 1週流量算式                            | 仮定             | 確信度 |
|--------------|-----------|----------------------------------------|------------------|-------|
| hunting      | Source    | 時間あたり討伐 × 平均ドロップ × 週間プレイ時間 | ★週15h、討伐80/h | 中    |
| quest_reward | Source    | デイリークエスト数 × 報酬 × 7 × 完了率   | ★完了率 0.7      | 中    |
| market_sell  | Source    | (ユーザー間の移転 — 純増ではない)        | 純経済には0寄与   | 高    |
| gear_buy     | Drain     | 購入頻度 × 平均価格                      | ★週1.2回         | 低    |
| enhance      | Drain     | 強化試行 × 1回あたりコスト               | ★週8回           | 中    |
| repair       | Drain     | 狩り時間 × 修理率                        |                  | 高    |
| tax          | Drain     | 取引額 × 税率 (★唯一の永久回収sink)      | ★税率 5%         | 高    |
| ── 純収支    | net       | Σsource − Σsink ≈ +(中活性基準で正)      | 上の仮定の合算時  | ★低   |

★仮定の警告: market_sellはユーザー↔ユーザーのゴールド移動で、経済総量には0寄与。
これをsourceとして足すとインフレを二重計上する。モデルで別途処理が必要。
★確信できない点: gear_buy頻度(週1.2回)は推測。実際の購入telemetry
なしではsinkが過小/過大に推定されうる → 人の決定が必要。

出力で最も価値があるのは表ではなく、一番下の2行、「★가정 경고」（★仮定の警告）と「★확신 못 하는 점」（★確信できない点）です。AIが自分のモデルの弱点を2か所、自ら申告しました。良いプロンプトは、AIに「この仮定は信じられません」と言わせます。

ステップ4 — 検証と拒否（人の出番）

この出力をそのままモデルに入れてはいけません。AIが申告した2つの★のうち1つが、実際にモデルを壊す欠陥でした。

market_sell（取引所での販売）を、AIは最初Sourceに分類しました。しかし、取引所での販売はユーザーAのゴールドがユーザーBへ渡る移転であって、経済にゴールドが新しく生まれるわけではありません。これをsourceの流入に足すと、インフレを二重に計上することになります。AIは★仮定の警告で自ら指摘してはいたものの、表の本文では依然としてSourceの欄に残していました — 申告はしたが、モデルからは外していない、半分だけ正しい出力です。これは、入力のyamlでmarket_sellの性格（ユーザー間の移転か新規生成か）を明示しなかった、人側のデータ欠陥でもありました。

そこで、再依頼します。

market_sellはユーザー↔ユーザーのゴールド移転であり、経済総量のsourceではない(入力
漏れの修正)。このノードをsource合算から外し、代わりに「取引所税金(tax)が
移転額の一部を永久回収するsink」としてのみモデルに反映せよ。純収支を
再計算し、market_sell除外がnetに与えた影響を1行で示せ。

AIはmarket_sellをsourceから取り除き、税金だけをsinkに残したモデルで答え直しました。その結果、純収支（net）は最初の推定より低くなりました — 取引所での販売をsourceに誤って入れていたとき、インフレを過大評価していたことが明らかになったのです。この1往復こそが核心です。人が最初から手で組めば半日かかり、ノード分類のミスを本人が見つけるのは難しいのに対し、AIドラフト+「仮定の明示」の強制+1回の拒否なら1時間以内で済み、AIが申告した★を人が判定する構造のおかげで、二重計上のような欠陥がモデルに入る前に捕まります（著者の推定 — 節約できる時間はチームやリソース数によって異なるため、絶対値よりも「手で最初から」と「ドラフト+人によるレビュー」という構造の違いとして読むのが正しいです）。

8.2.4 1リソースずつ — Pilot 4段階で導入する

ゴールドのモデルが1つ閉じたからといって、全リソースを一度にモデリングしてはいけません。著者の運用でも、全体を一度に投入しませんでした。単一リソースから始め、検証・補正を経て拡張する4段階を踏みました。

2段階目の比較検証が、この4段階の心臓です。シミュレーションと実測がずれているなら、間違っているのはゲームではなくモデルです。ずれたモデルで意思決定を下せば、その決定はライブで事故になって返ってきます。だから、拡張（4段階目）は必ず2・3段階目の検証を通過した後にだけ行います。この順序が崩れると、つまり単一リソースの検証を飛ばして5種を一度に入れると、どのリソースのモデルが間違っているのかさえ切り分けて指させなくなります。

8.2.5 シミュレーションゲート — 経済変更の意思決定に遮断壁を設ける

モデルが検証を通過したら、今度は経済に影響するすべての変更決定の前にシミュレーションゲートを立てます。会議で「感覚」によって通していた決定を、シミュレーションの通過に置き換える場面です。

ゲートが実際にどう機能するのか、§8.2.3で検証したゴールドモデルの上で、1つの決定を通してみます。

［シミュレーションゲート — イベント報酬の決定］（実際の形式を再構成）

[変更案]   週末イベント: デイリーログイン報酬 +500 ゴールド
[ゲート]   source新規追加 → シミュレーション必須
[シミュレーション1000回の結果]
  - 1週のゴールド純収支: +6,900 → +10,400 (+50%)
  - 26週累積時のゴールド相場中央値 ~+28% (インフレ警告: ±10%超過)
  - 上位10%活性ユーザー: ~+41% (segment偏差が大きい)
[判定]     FAIL — 安定範囲(±10%/長期)超過
[補正案]   イベントsourceに同時sinkを付着: イベント限定商店(ゴールド回収)
           再シミュレーション → 26週累積 +9% (PASS)

ゲートの価値は最後の2行にあります。「報酬+500を配ろう」という決定が会議の推測だったなら、「大丈夫そうだ」で通っていたでしょう。シミュレーションゲートはその決定を26週で+28%のインフレに換算して見せ、sourceを追加するならsinkを一緒に付けよという補正案まで強制します。経済変更を推測ではなく、シミュレーションの通過/失敗で判定すること — これがゲートのすべてです。

ここで、よくはまる罠を1つ指摘します。セグメントの偏差です。中アクティブユーザー基準で+28%でも、上位10%は+41%です。ゴールドを最も多く稼ぐユーザー層がインフレを最も速く累積させるため、シミュレーションは平均だけを見ずに、セグメント別に回すべきです。平均だけを見ると、高アクティブユーザー発の相場崩壊を見逃します。

8.2.6 モデルはリリース後、テレメトリーで毎月進化する

シミュレーションゲートが信頼されるには、モデルが実際のゲームとずれていてはいけません。ゲームは毎週変わるので、モデルも追いかけて補正する必要があります。リリース後は、実際のテレメトリーで毎月（変更が少ない時期には四半期ごとに）モデルを突き合わせます。

モデル補正サイクル (月間)
─────────────────────────────────
1. 実際のユーザーtelemetry 1か月分を抽出 (リソース別フロー集計)
2. segment(低/中/高活性)別のsource·sink実測流量を算出
3. Machinationsシミュレーションと項目別に比較
4. 誤差 >15% の項目 = モデルパラメータ調整 (その項目の★仮定が違っていた印)
5. 調整後に再シミュレーション → 翌月ゲートの基準モデルとして使用

核心は4番です。誤差が大きい項目は、すなわち§8.2.3でAIが★で申告した「確信できない仮定」が実際とずれていたという信号です。たとえば、AIが推測したgear_buyの頻度（週1.2回）が実測では週2回だったなら、その仮定をテレメトリーの値に置き換えます。この補正を止めるとモデルがゲームからゆっくり離れていき、どこかの四半期で、シミュレーションゲートが「通したのに実際にはインフレが来た」という事故を起こします。その瞬間、シミュレーション自体の信頼が事後的に崩れます。補正は運用の付随作業ではなく、ゲートを生かしておくための正規のサイクルです。

8.2.7 進歩的適用 — 異常パターン検知・変更空間・シミュレーション並列化

ここまでが経済モデリングの「保守的適用」です。人が変更を発議し、モデルで検証し、結果で決定します。もう一歩進むと、8.1.6で見た進歩的適用の3つの軸 — z-score検知・変更空間の定義・シミュレーション並列化 — が、経済インフラの上でも同じように開けます。

第一に、異常パターン検知。毎月の補正サイクル（§8.2.6）の誤差比較を人が目で行う代わりに、モデルと実測の偏差がしきい値を超えた項目を、コードが先に拾い上げます。強化石の相場が2倍になったことを取引所を見て知るのではなく、「強化石のsource流量がモデル比+30%乖離」というアラートが、会議の前に届きます。

第二に、変更空間の定義。「報酬を+500配る/配らない」の二分法ではなく、報酬の範囲（0〜+1000）と同時sinkの範囲を変更空間として定義しておけば、その空間の中でインフレ±10%を満たす組み合わせを探索できます。人は「どこからどこまで」を決め、その中の最適な組み合わせの探索は自動化します。

第三に、シミュレーション並列化。変更案1つを1,000回回す代わりに、変更空間の中の候補数十個を並列に1,000回ずつ回して、分布を一度に比較します。会議室で1案ずつ議論していた場が、候補マトリクスのシミュレーション結果の比較に変わります。

共通する思想は、人が変更を発議していた場を、コードが変更空間を探索する場へ移すことです。ただし、保守的適用（§8.2.3\~8.2.6）が安定して回り、モデルがテレメトリーで検証された後の話です。検証されていないモデルで変更空間を自動探索すると、間違ったモデルが間違った最適値を自信満々に出してきます。

［急進的適用 — 経済を「次元ベクトル」に圧縮して探索する］（まだ時期尚早）

進歩的適用からさらに一歩進んだ領域です。断定ではなく、研究動向として読んでください（次元ベクトル・埋め込み（エンベディング）が初めてなら、付録Mの「地図」を1枚先に見ると、以下が読みやすくなります — 本書の5つの「方向標識」は、すべてその図の上で回っています）。ここまで来た経済モデルは、リソース5種にフロー数十本が絡んだ高複雑度のシステムで、§8.2.7の変更空間の探索も、結局はその数十本のフローを1つずつパラメータに取って回す方式です。急進的な発想は、この複雑度自体を次元ベクトルに圧縮し、その圧縮空間の上で解を探すことです。

遠く見える比喩が1つ、手がかりになります。定性的で手につかみにくい領域の代表としてよく挙げられる料理レシピを、ある研究（Epicure — Radzikowski·Chen, 2026, arXiv:2605.22391 · デモ epicure.kaikaku.ai）では、11の出典のレシピ414万件から標準食材1,790種を選り出し、食材同士の関係を数百次元のベクトルに圧縮しました。核心は、「味」という定性的な対象も、食材間の関係を座標に換算すれば、似たレシピはベクトル空間で近くに集まり、その間を補間して新しい組み合わせを探索できるという点です — Epicureもこの圧縮空間で、1つの食材を特定の料理圏の方向へ回転させて対応する食材を見つける補間探索を示しています。

経済も原理は同じです。source・sink・変換フローをそれぞれ次元に取ったベクトルで経済状態を表現すれば、「インフレ±10%以内で安定した経済」が、その空間の1つの領域として捉えられます。そうなれば、変更案を1つずつシミュレーションにかける代わりに、その安定領域の中/近くで解を直接探索する道が開けます。候補を逐一回して比較していた§8.2.7の並列シミュレーションが、圧縮空間上の探索1回に絞り込まれる可能性です。

なぜ「まだ時期尚早」なのか。第一に、何を次元に取るか（どのフローが独立で、どれが従属か）を決めること自体が、ドメインの難題です。第二に、圧縮は本質的に情報を捨てる作業なので、捨てた次元でライブの事故が起きえます。第三に、これらすべては、保守的適用のテレメトリー検証（§8.2.6）が固いときにだけ意味があります — 圧縮前のモデルがゲームとずれていれば、圧縮はその誤差まできれいに圧縮するだけです。だから本節は処方ではなく、方向標識です。いまやるべきことは保守的適用を正直に回すことであり、次元ベクトルは、その土台が十分に積み上がったチームが数年後にのぞき込む研究領域として残しておきます。

8.2.8 測定 — 会議がシミュレーションに変わった場所

ツール導入の前後を比較します。以下の時間・頻度は導入初期の運用で体感した方向を写したものなので、精密な絶対値として読むのではなく、どちらへ動いたかとして読むのが正しいです。

表の数字より、最後の行の意味のほうが大きいです。会議頻度の減少は、シミュレーションが議論を置き換えたからです。「私の考えでは強化石にインフレが来そうだ」が「シミュレーション結果は26週で+28%」に変わると、推測をめぐって1時間争っていた場が、5分の結果共有で終わります。これは、著者のシステムの振り返りに固定化された概念（atom automation_signal_value_over_time_savings — 自動化の価値は時間の節約ではなくシグナルの露出）と正確に同じ場所です。シミュレーションゲートの本当の産出物は、節約された時間ではなく、会議で推測が占めていた場所を数字が占めるようにしたことです。

ただし、1つだけは正直に書いておきます。表の「四半期あたり1〜2件→0〜1件」は精密な測定値ではなく、運用の体感としての方向です。インフレ事故は定義（相場±何%を事故と見なすか）によってカウントが変わるため、絶対件数よりも「事後発見から事前遮断へ移った」という構造の変化として読むのが正しいです。

8.2.9 よくある失敗

2つ目が最も頻繁に見落とされます。§8.2.3で見た取引所の二重計上のように、AIはもっともらしいモデルを自信を持って吐き出しつつ、自分の仮定の弱点は★で申告するだけで、本文には欠陥を残しておきます。その★を人が判定しなければ、間違ったモデルが通過し、その上のすべてのシミュレーション決定が一緒に間違います。

8.2.10 やってみよう — 今日できる1ステップ

一人ならこれだけ：Machinationsもテレメトリーもなくて構いません。自分のゲーム（または好きなゲーム）のリソースを1つ選んでsource・sinkを紙に書き出し、§8.2.3のプロンプトをそのまま貼り付けて、1週間の純収支モデルのドラフトを受け取ってみましょう。AIが★で明示した仮定を1つ選んで「この仮定は信じられない。根拠をもう一度示せ」と反論してみると、経済モデルがどんな仮定の束なのか — そして、その仮定が1つ崩れると結論がどうひっくり返るのか — が体に入ってきます。

チームなら、次の1ステップから始めましょう。全リソースではなく、最も問題のあるリソース1つ（普通はゴールドか強化石）を選んで§8.2.3の単一リソースモデルだけを先に立て、経済変更の決定1種類（例：イベント報酬）に§8.2.5のシミュレーションゲートをかけてください。リソース1つ+決定1種類だけでも、会議で推測をめぐって争っていた場を、数字1行に変えられます。

setup→prompt→verifyで要約すると — setup：問題のリソース1つのsource・sinkをyamlに抽出します。prompt：§8.2.3の形式でノードモデルのドラフトを受け取りつつ、ユーザー行動の仮定を★で明示させます。verify：AIが申告した★の仮定とノード分類（特にユーザー間の移転か新規生成か）を、人が直接拒否・再依頼します。

本章のポイント

• 経済はリソース5種ではなく、時間とともに累積するフロー数十本なので、シミュレーションが必要です。
• AIモデルのドラフトには仮定の明示を強制し、その仮定を人が拒否します。
• 経済変更は会議の推測ではなく、シミュレーションゲートの通過/失敗で判定します。

次章のプレビュー

• 8.3 Damage Simulator（2008〜） — 18年生きたシミュレーションツールがAI時代にどう再利用されるか

8.3 Damage Simulator — 仕様DPSとシミュレーション値が食い違った日

2008年のある未明、私は1枚のExcelを前に、同じ数字を3回検算していました。仕様書には、ある剣キャラクターの秒間ダメージ（DPS）が847と書かれていました。ところが、その日初めて回したシミュレーターは、同じキャラクターを同じスペックで入れたのに612を吐き出しました。27%の差。どちらか一方は嘘をついていて、私はどちらが嘘なのか、まだ分かりませんでした。

仕様書のDPSは、紙の上の約束です。スキル1発のダメージに発動頻度を掛けた算数です。シミュレーターのDPSは、その約束を1,000回実際に振ってみた結果です。クールタイム（クールダウン）が重なり、発動モーションに時間を食われ、クリティカルが期待値どおりに出ない — 紙が知らない摩擦が割り込んできます。この27%の隙間こそ、バランス担当プランナーの飯のタネです。紙を信じれば、リリース後に泣くことになります。

この章は、その道具一本の物語です。2008年に作り、今まで手放さずにきたDamage Simulator。仕様と算出が食い違う正確な地点をどう追跡したのか、そして18年後、その追跡にAIをどう組み込んだのかを、1本の実際のワークド・トランスクリプトで追いかけます。

8.3.1 仕様DPSはなぜいつも嘘をつくのか

まず、あの612対847の正体を解剖してみましょう。仕様書を書いた後輩プランナー（以下、チームメンバーA）に落ち度はありませんでした。彼はスキル表に書かれたとおりに掛け算をしただけです。

仕様上のDPS計算はこういう形をしています。1人のキャラクターが持つ3つのスキルを仮定します。

チームメンバーAの仕様計算は、「各スキルをクールタイムが明けるたびに漏れなく使う」という理想的な仮定の上に立っていました。横斬りは3秒ごとに320、突きは6秒ごとに540、通常攻撃が空き時間を埋めます。算数としてはきれいに847が出ます。紙の上では、キャラクターは手が何本もあるので、発動モーションが互いを邪魔しません。

シミュレーターが612を出した理由はただ一つ、手が1本だからです。0.9秒の突きを発動している間は、横斬りのクールタイムが明けても使えません。発動モーション同士が食い合うこのGCD（グローバルクールダウン）衝突が、仕様には存在しません。紙は摩擦のない真空で、シミュレーションは摩擦のある戦場です。24年この仕事を続けて学んだ最初の真実がこれです — 仕様DPSは上限値であって、実測値ではない。そしてユーザーは、上限値ではなく実測値でゲームを遊びます。

8.3.2 ワークド・トランスクリプト — 612の出どころをAIに問いただす

2008年の私は、この27%の隙間を手作業で埋めました。シミュレーションのログを1行ずつ目で読み、どのフレームでスキルがブロックされたのかを数えました。半日かかりました。18年経った今、私は同じログをClaudeに投げます。以下は実際に行った1セッションの全文です。要約せず、外した最初の試みまでそのまま載せます — その外し方こそ、この道具の使い方の半分だからです。

私が投げたプロンプトはこうでした。

添付したのは、私たちのDamage Simulator（damage_sim/、Python）の単一キャラクター1,000ティック戦闘ログの一部です。仕様書上、このキャラクターのDPSは847ですが、シミュレーションの算出は612になります。27%のギャップの原因をログから探してください。ログのフォーマットは[tick] event skill=SKILL state=STATEです。推測ではなく、ログにある根拠だけを挙げてください。根拠が足りなければ、足りないと言ってください。

[0.0] cast skill=찌르기 state=START
[0.9] cast skill=찌르기 state=HIT dmg=540
[0.9] cast skill=횡베기 state=BLOCKED reason=GCD
[1.5] cast skill=평타 state=HIT dmg=180
[1.9] cast skill=평타 state=BLOCKED reason=GCD
[3.0] cast skill=횡베기 state=HIT dmg=320
[3.6] cast skill=평타 state=HIT dmg=180
... (994 lines omitted)
[997.2] cast skill=찌르기 state=HIT dmg=540

Claudeの生の出力はこうでした（手を加えていません）。

ログから確認できる事実：

1. state=BLOCKED reason=GCDイベントが繰り返し登場します。[0.9]では横斬りが、[1.9]では通常攻撃がGCD（グローバルクールダウン）によってブロックされています。
2. 突きのキャスト（0.0→0.9、0.9秒）が終わるまで、ほかのスキルは発動できません。キャストタイムがGCDを占有する構造に見えます。
3. したがって、仕様上の「すべてのスキルをクールタイムごとに発動する」という仮定が崩れます。実際には発動モーション同士が衝突し、一部の発動が漏れています。

ただし、提供されたログは1,000行中7行だけです。27%という正確なギャップがGCD衝突だけで説明できるかどうかは、この7行では断定できません。BLOCKEDイベントの総発生回数と、それによって漏れたダメージの総量を集計してこそ、27%が検証できます。全ログのBLOCKED集計をいただければ、定量的に確認します。

ここで止まったことが重要です。AIは原因を指摘しましたが、27%を証明することはできず、自らその限界を口にしました。紙の上だけで考えるプランナーなら「GCDのせいですね」で会議を終わらせていた場面で、この道具は「7行では分からない」と踏みとどまりました。私はその要求が正当だと判断しました — これが人による検証です。そこで、全ログのBLOCKED集計を出して投げ直しました。

全1,000ティックの集計です。BLOCKEDは計412回、うちGCD起因が388回、クールタイム未完了起因が24回。BLOCKEDで漏れた推定ダメージは横斬り換算で約19,800。総戦闘1,000ティック（=秒）の間の仕様上の期待ダメージは847,000、シミュレーション実測の累積ダメージは612,300。この数字で27%のギャップを再検討してください。

Claudeの2回目の出力です。

集計で検証します。

• 仕様上の期待累積：847,000
• シミュレーション実測累積：612,300
• ギャップ：234,700（27.7%）

このギャップの構成： - GCD衝突による直接の漏れ（388回）：推定約19,800は横斬り換算ですが、漏れたスロットにより高いダメージのスキルが入り得た機会費用まで合算する必要があります。漏れたスロットを平均ダメージで換算すると、漏れ分は19,800より大きくなります。 - ただし、234,700のすべてがBLOCKEDだけで説明されるわけではありません。仕様の847が「クリティカル期待値を平均としてすでに織り込んだ」値なのか、「クリティカルを含まない基本値」なのかによって、残りのギャップの解釈が変わります。仕様847のクリティカルの仮定を教えていただければ、残余ギャップを分解します。

また止まりました。そして、また正確な場所で止まりました。仕様の847がクリティカルをどう扱ったのか — これはログにない情報で、チームメンバーAの頭の中にしかありませんでした。AIは、自分が持つデータの境界を知っていました。私が確認したところ、仕様の847はクリティカル率20%・1.5倍を期待値として平準化して織り込んだ値で、シミュレーションはseed固定のうえで、実際のクリティカル発生回数が期待値より低く出た1回分でした。つまり27%のギャップは、GCD衝突（構造的・再現される）とクリティカルの分散（統計的・この1回の運）が混ざった値だったのです。

この分解が結論です。GCD衝突分は設計で直すべき本物の問題で、クリティカルの分散分はシードを変えて1,000回の平均を取れば消えるノイズです。二つを混ぜて「キャラクターが弱い」と上方修正をかければ、1,000回平均ではまともだったキャラクターが強くなりすぎます。紙も知らず、1回のシミュレーションも知らず、AIひとりでも分からなかったこの区分を作ったのは、ログの集計と仕様の隠れた仮定を突きつけた、人による検証でした。

8.3.3 入力1セットが出力1セットに — シミュレーターの解剖

先ほどのセッションが覗き込んだ、あの道具の入出力を1セットで広げてみましょう。シミュレーターは、結局のところ正直な関数です。同じ入力には同じ出力。入力は三つの流れから集まります。

flowchart LR
    A["マスターデータ
（スキル表・キャラクターステータス）
read-only"] --> SIM
    B["シナリオyaml
（戦闘条件・持続時間・
ターゲット構成）"] --> SIM
    C["seed=42
（乱数固定）"] --> SIM
    SIM["Damage Simulator
domain/formulas.py
run_combat() × 1000ティック"]
    SIM --> R1["実測累積ダメージ
612,300"]
    SIM --> R2["BLOCKEDログ
412回（GCD 388）"]
    SIM --> R3["クリティカル発生
実測17.2% vs 期待20%"]
    R1 --> REP["markdownレポート
仕様847 vs シミュ612
ギャップ分解：構造19% + 分散8%"]
    R2 --> REP
    R3 --> REP

    classDef code fill:#dbeafe,stroke:#2563eb,color:#0b2545;
    classDef data fill:#e2e8f0,stroke:#64748b,color:#1e293b;
    class SIM code;
    class A,B,C,R1,R2,R3,REP data;

この図の核心は、矢印が一方向だということです。マスターデータはシミュレーターに読まれるだけです。シミュレーターはデータを決して書き換えません。18年間で最も多くの事故を防いだルールが、この一本の矢印の向きでした。シミュレーターが自分の中にデータをコピーして持ち始めると、ゲームデータが変わった翌日、シミュレーターは昨日の世界をシミュレーションします。そうして出てきたレポートで会議をすれば、会議全体が昨日の世界をめぐって争うことになります。

具体的な入力1セット（シナリオyaml）はこういう形です。

# scenarios/single_dps_check.yaml
scenario: single_target_dps
duration_ticks: 1000      # 1ティック = 0.1s 仮定、100秒戦闘
seed: 42                  # 決定論 — 同じ入力に同じ出力
actor:
  char_id: K_004          # ゲームデータシートから read
  skill_rotation: optimal # GCD衝突時は最高期待ダメージ優先
target:
  defense: 1200
  hp: infinite            # DPS測定用の無限体力ダミー
report:
  compare_to_spec: 847    # 仕様DPSを入れてギャップを自動分解

そして、出力1セット（レポート抜粋）はこうです。

# Damage Simulator Report — K_004 single DPS
入力: scenarios/single_dps_check.yaml | seed=42 | data rev. 2026-06-05

## 仕様対比
- 仕様DPS:        847   (クリティカル20%·1.5x 期待値平坦化込み)
- シミュ実測DPS:  612   (このシードの1回分)
- ギャップ:      -27.7%

## ギャップ分解
- 構造的(GCD衝突、再現される):     -19.2%  ← 設計検討の対象
- 統計的(クリティカル分散、この回): -8.5%  ← 1000回平均で消える見込み

## 再現検証
- seed=42 再実行3回 → 612,300 / 612,300 / 612,300 (一致)
- seed 0~999 1000回平均DPS → 731 (クリティカル分散の消去後)

最後の行を見てください。seed 0〜999で1,000回回した平均は731でした。仕様の847と1,000回平均731のギャップ116（13.7%）こそが、GCD衝突という本物の構造問題の大きさです。1回分の612ではなく、この731が設計会議の入力にならなければいけません。紙の847でも、運の悪い1回の612でもなく、1,000回が合意した731。この数字を手にするまでが、バランス担当プランナーの仕事です。

8.3.4 2008年の手と2026年の手

この道具は18年生きてきましたが、同じコードで生きてきたわけではありません。ハンガーはそのままに、服だけを5回着せ替えました。ハンガーとは、先ほどのレポートの論理 — 仕様と実測を分けて見て、ギャップを構造と分散に分解し、再現で検証する手順です。この手順は、2008年のExcel VBA（Excelのマクロ言語）でも2026年のPythonでも、文字どおり同じです。

5回の着せ替えに耐えた秘訣は、フォルダー構造に刻まれています。

damage_sim/
├── domain/          # ハンガー — 18年そのまま
│   ├── formulas.py      # ダメージ公式·GCD衝突判定
│   └── metrics.py       # ギャップ分解ロジック
├── adapters/        # ゲームデータ read-only
│   └── excel_reader.py
├── runners/         # 服 — 技術が変わるたびに交換
│   └── cli_runner.py
└── reporters/       # 服 — レポート出力形式
    └── markdown_report.py

技術が変わったら、runners/とreporters/だけを書き直します。domain/のギャップ分解ロジックは、18年分の資産がそのまま生き残ります。2008年にExcelのセルで組んだGCD衝突の判定式が、関数シグネチャだけ変わって、今もformulas.pyの中で回っています。道具を一つの技術に釘付けにすれば、その技術と一緒に老いて死ぬ — それを私は、死んだ道具を何本も見送りながら学びました。

2025年に取り付けたLLMは、新しいハンガーではなく新しい手です。先ほどのセッションで見たとおり、AIはログを読んで仮説を立てる手であり、半日かかっていたログ追跡が数分に縮みました。しかし、ハンガーには触れさせません — ギャップが27%なのか、クリティカルが何パーセント出たのかを決定するのは、今もseed固定の決定論コアです。その場所にLLMが入った瞬間、リグレッション検証が不可能になり、道具は死にます。

8.3.5 決定論コアとその外側 — 線をどこに引くか

バランスツールに一本だけ線を引くとしたら、私は決定論コアの境界に引きます。内側は同じ入力に同じ出力が鋼のように保証されなければならず、外側は人やAIが自由に仮説を投げて構いません。

内側（決定論 — AI禁止）： - ダメージ公式、GCD衝突判定、クリティカル発生、累積集計。 - seed=42で3回回して、612,300が3回同じに出なければなりません。これが崩れると、昨日のレポートと今日のレポートを比較できません。

外側（仮説・解釈 — AI歓迎）： - 「なぜこのキャラクター構成の勝率が異常なのか」のような原因の問いかけ。 - ログからBLOCKEDパターンを探すこと、自然言語レポートのドラフト、シナリオyamlのドラフト。

先ほどのワークド・トランスクリプトは、正確にこの線の上で動いていました。AIは外側で「GCD衝突が原因」という仮説を素早く立てました。しかし、27%という数字、612という数字は最後まで決定論コアが計算した値であり、AIはその値を受け取って解釈だけをしました。そして二度も「このデータでは断定できない」と止まりました — 決定論コアには出せない情報（仕様のクリティカルの仮定）を要求しながら。この立ち止まりが、よい道具の証です。仮説を診断と取り違えないこと。

数値について、一つ正直に明かしておきます。この章の847・612・731・412回のような具体的な数字は、説明のために構成した例示値です。ただし、仕様DPSがシミュレーション実測より常に高く出るという方向、そのギャップが構造的衝突と統計的分散に分解されるという構造、seed固定がリグレッション検証の前提だという原則は、2008年から18年間、実際に運用しながら繰り返し確認してきたものです。比率の大きさはプロジェクトごとに違いますが、方向と構造は変わりませんでした。

やってみよう — 仕様とのギャップ分解を1回

setup. ゲームデータからキャラクターを1体選び、スキル表（ダメージ・クールタイム・キャストタイム）と仕様DPSを確保しましょう。シミュレーターがなければ、1,000ティックの単一ターゲット戦闘を回す最小スクリプトを書いてみましょう。核心は、seedを引数で受け取って固定できること、この一点です。

prompt. シミュレーションログ（BLOCKEDイベントを含む）と仕様DPSを一緒に投げましょう。

添付はキャラクター1体の1,000ティック戦闘ログとBLOCKED集計です。仕様DPSは[N]ですが、シミュレーションの算出は[M]です。ギャップの原因をログの根拠だけで分解してください。構造的原因（再現される衝突）と統計的原因（この回の分散）を区別してください。根拠が足りなければ足りないと言い、何がさらに必要かを指摘してください。

verify. AIが指摘した構造的原因を、シードを変えて1,000回平均で検証しましょう。平均でもギャップが残れば本物の構造問題、消えれば分散ノイズです。AIが「断定できない」と止まったら、それは失敗ではなく正常です — 止まった場所に人が入り、仕様の隠れた仮定を埋めます。

一人ミニ版

シミュレーターもMLもない一人開発者なら、Excel1枚とAIだけで同じ手順を回せます。スキル表をシートに書き、RAND()でクリティカルを振る1,000行のシミュレーションを1列に作りましょう。シード固定ができないので、F9で100回再計算して平均を目で確かめます。その平均と仕様DPSのギャップをAIに「構造原因と分散原因に分けてほしい」と投げましょう。道具は小さくても、ハンガー — 仕様とのギャップ分解、構造と分散の分離、再現検証 — は同じように立ちます。

本章のポイント

• 仕様DPSは摩擦のない上限値であり、ユーザーが体験する実測値は、シミュレーションが1,000回平均で見つけます。
• 仕様とシミュレーションのギャップは、構造的衝突と統計的分散に分けてこそ、本物の設計問題が見えます。
• 決定論コアの内側はAI禁止、仮説・解釈の外側ではAIを新しい手として歓迎します。