研究開発/Research

ゲームにおけるナラティブデザインの研究・開発を行っています。
We are conducting R&D on narrative design in video games.

TECH-001

物語を「レンダリング」する
LLM非依存ナラティブ設計フォーマットの制作実験

本報告は、LLMによる長編物語制作を「人間は本文を一文字も書かない」という統制条件の下、階層化された設計ファイル群（YAML）で制御した実験の記録と、方法論の体系化である。長編生成における一貫性の劣化を、コンテキスト希薄化・局所最適化の優先・ルールの暗黙化の3要因に分解し、「制御」と「意味」をファイルレベルで分離した5層アーキテクチャによる対処を示す。同一の設計ファイル群を、構築過程に関与していない別のLLMへ移植しても生成が成立したこと（初期検証）から、制作の資産は本文でもプロンプト技巧でもなく設計フォーマットに宿り、本文はそのレンダリング結果である、と位置づける。あわせて「ハイ・ローミックス」生産体制の有効性と、ボイス演出実務——「作品理解の一致」の事前構築——との構造対応を論じる。

文書情報
バージョン	v0.1（初版ドラフト）
最終更新	2026-07-11
ステータス	継続中の実験に基づく生きた文書（Living Document）。実験の進行に応じて節単位で更新される
関連資料	note連載「AIを活用したストーリー制作実験」（過程の時系列記録）／GitHubリポジトリ kannagi-diary-devlog（設計ファイル群の公開）
著者	吉田淳一（ゲームシナリオディレクター／ライター／ボイス演出）

1. 要旨

本報告は、LLM（大規模言語モデル）を用いた長編物語制作において、「人間は本文を一文字も書かない」という統制条件の下、階層化された設計ファイル群（YAML）によって物語生成を制御する実験の記録と、そこから得られた方法論の体系化である。

実験を通じて得られた主要な知見は以下の通り。

長期生成における一貫性劣化は、コンテキスト希薄化・局所最適化・ルールの暗黙化という3要因に分解でき、階層化された設計ファイルによる明示的統治で相当程度対処可能である
「どう作るか」（制御）と「何を作るか」（意味）をファイルレベルで分離する設計が、長期一貫性の維持に有効である
同一の設計ファイル群を異なるLLM（ChatGPT・Gemini）に与えても物語が成立することから、資産は本文でもプロンプト技巧でもなく設計フォーマットに宿る——本文はレンダリング結果である（初期検証）
制作物を本筋（構造管理）と日常描写（平文指示）に分業する「ハイ・ローミックス」体制が、品質と生産性を両立する
上記の方法論は、キャラクターボイス演出の実務——収録前に「作品理解の一致」を構築する仕事——と構造的に対応する

2. 背景と問題設定

2.1 LLM長編生成で何が起きるか

LLMに長編の物語を生成させると、短編では現れない問題が発生する。固有名詞・呼称の揺れ、確定済み設定の忘却、文体・トーンのドリフト、そして承認を経ない構造の変更である。これらは単発のプロンプト工夫では解決せず、生成が長期化するほど悪化する。

2.2 実験の統制条件

対象はオリジナル長編小説『かんなぎダイアリー（仮）』（学園異能・連作構成）。統制条件として、人間は本文を一文字も書かない。人間の介入は以下に限定する。

設計ファイル（Config・構造ファイル・Scene card）の設計と改訂
生成物のレビューと承認

この条件により、「生成品質の変化はすべて設計ファイルの変化に帰属する」という因果の追跡可能性を確保した。全過程はnoteおよびGitHubで公開しており、第三者による検証が可能である。

3. 方法論：ナラティブ設計フォーマット

3.1 5層アーキテクチャ【ステータス：運用中】

設計ファイル群は以下の5層で構成される。

GLOBAL_CONFIG——「どう作るか」。生成統制の原則、禁止事項、文体制約。最上位の不変ガバナンス
PROJECT_MASTER_CONTEXT——「何を作るか」。作品のテーマ原則、意味の定義
WORLD CONFIG——世界設定と物理制約
CHARACTER LAYER——キャラクター定義。容姿を「状態・振る舞い・含意」の3層で定義するappearance_profile、呼称規則（addressing_rules)、行動制約
SCENE CARD——シーン単位の実行指示。beats（展開の節）、hook、テンションカーブ

3.2 制御と意味の分離【ステータス：運用中】

第1層と第2層の分離——レギュレーション文書とデザイン文書の分離——は、本アーキテクチャで最も重要な設計判断である。制御規則は作品をまたいで再利用可能であり、意味定義は作品固有である。この分離により、フォーマット自体が特定作品から独立した資産となる。

3.3 human_behavior_constraints 【ステータス：運用中】

LLMは状況を描写できるが、人間を「演じる」ことが苦手である——感情を説明してしまい、行動として提示しない。この診断に基づき、感情語の使用禁止、失敗の注入、知覚の制限、一往復未満の会話、といった制約層を導入した。感情は制約下の行動の副産物として滲むことを狙った設計である。

4. 事例研究：制作過程で露出した問題と対処

本章は、設計ファイルが存在してもなお発生した問題の記録である。それぞれの事例は、プロの暗黙知とLLMの生成論理が衝突した地点を示している。

4.1 「メモ帳」事件——読者認知の設計【ステータス：対処済み】

AIが指示なく、キャラクターの初登場シーンに象徴的な小道具（メモ帳）を挿入した。意図を問うと「意味は未定。育てるために出した伏線」と回答した。書き手の論理としては一見成立するが、プロの判断は異なる——初登場キャラクターの印象的なアイテムは、読者に「意味があるもの」として認知される。つまり物語内容の設計と同時に、読み手側の認知の設計が必要である。この事件は、設計ファイルに書かれていない領域でAIが行う外挿が、もっともらしい論理を伴って現れることを示した。

4.2 「たりめぇだ」問題——レビュー設計の再構築【ステータス：対処済み】

生成物のレビューをAI自身に行わせたところ、一貫して高評価が返った。原因はいわゆる追従性（おだて特性）ではなく、より構造的な問題である——自らの計画を判断基準として生成した以上、その計画基準でレビューすれば合格するのは自明である。対処として、「本作を失敗作と仮定し、擁護を禁止し、問題点の指摘のみを行う」という破壊的レビューを設計した。レビューは目的から事前に設計すべき工程であり、生成の付属物ではない。

4.3 無断構造変更事件——承認統制【ステータス：対処済み】

シーン順序の入れ替えと新規シーンの追加が、承認なく実行されていた。AIの説明は「最適化はするが、統制はしない」。対処として、「提案は可、承認なき適用は禁止」という統制規則を導入した——人間が設計主体、AIが提案主体という役割定義である。共創とは役割の混在ではなく、主体の明確化によって成立する。

4.4 一貫性劣化の3要因【ステータス：分析済み】

上記の事例群と長期運用の観察から、劣化は以下の3要因に分解できる。

コンテキスト希薄化——長い対話の中で初期ルールの重みが薄れる
局所最適化の優先——目前のシーンの完成度が、全体の一貫性より優先される
ルールの暗黙化——「言わなくてもわかる」は通用しない。書かれていないものは存在しない

第3の要因は人間の組織運営にも跳ね返る知見である。阿吽の呼吸が通用しない相手——新規メンバー、外部委託、文化圏の異なる協業先——との仕事では、同じ問題が同じ形で発生する。

5. 検証：クロスモデル生成

5.1 設計ファイルの移植【ステータス：初期検証（n=2）】

ChatGPTとの対話を通じて構築したYAML群（GLOBAL_CONFIG／Config／構造ファイル）を、開発過程に関与していないGeminiに投入した。Scene cardごとに「本文を出力してください」のみのプロンプトで、全シーンの生成が成立した。Geminiは読み込み時に制約の要点（構造統治の優先、「語らずに見せる」、章固有の物理制約）を正確に要約した。

この結果は、生成の制御が平文プロンプトの技巧ではなく設計ファイルに担われていることの初期的な証拠である。ただし現時点の検証はモデル2種にとどまり、品質判定にはモデル自身の申告が混在している。生成モデル自身による成功宣言は、4.2で述べた自己評価問題と同型の限界を持つため、証拠として扱わない。

5.2 スタイル差異の官能評価【ステータス：分析済み】

同一設計ファイルからの出力を読み比べ、ディレクターとしての官能評価を言語化した。要約すれば「会話と心理のChatGPT」対「情景と論理のGemini」——前者は雰囲気を作るが状況説明が不足し、後者は一読で状況が伝わるが文体が均質化する。

なお、モデル自身に差異の原因を説明させると、もっともらしい要因分析が返ってくるが、これはモデルが自身の学習過程を実際に知っているわけではなく、公開情報に基づく推測である。本報告では、モデルの自己申告は仮説として扱い、人間による読み比べ評価と、後述する補正設計の効果検証を証拠として扱う。

5.3 モデル特性の設計変数化【ステータス：設計済み・効果検証は今後】

観察されたモデルごとの癖を、設計ファイル側で相殺する補正を設計した。会話偏重のモデルには物理アンカー（空間描写の強制、セリフ連続の上限）、均質化するモデルには文体破壊制約（説明形容詞の禁止、リズムを崩す短文）である。モデル特性をバグではなく設計変数として扱う、という転換である。

6. 生産モデル：ハイ・ローミックス

【ステータス：初期検証】

制作対象を二層に分業する。

HIGH（本筋・事件・伏線・転換点）：Config→構造ファイル→Scene card→レビューのフル工程
LOW（日常会話・関係性描写）：Configを参照させた上で、平文プロンプト数行のみ

プロンプトの情報量を段階的に削減する実験（詳細指示約3000字→約2000字→2行→1行）では、設計ファイルが機能している限り、キャラクターの振る舞い——誰が脱線し、誰が注意し、誰が茶化すか——が「状況を与えるだけ」で導出されることを確認した。キャラクターがシミュレーション可能なエージェントとして定義されている状態である。

この体制は、運営型タイトルにおける「メインシナリオは書けるが、キャラクターエピソードやサブクエストの物量が回らない」という現場課題への直接の応用可能性を持つ。

7. 考察

7.1 「レンダリング」としての本文

本実験の到達点は、本文を最終成果物ではなくレンダリング結果として位置づける転換である。作品の本体は設計ファイル群にあり、本文はそこから生成される表現形にすぎない。翻訳の類比で言えば——ある作品を日本語にしても英語にしても同じ作品であるように、作品の同一性は表現ではなく構造に宿る。

この見方に立つと、「同じ設計図から何通りの本文が生成されうるか」という度合い——対話の中では「物語エントロピー」という呼称が浮上した——を、設計ファイルが制御している、と整理できる。設計ファイル群とは、生成の解釈空間を狭める装置である。なおこの概念は現時点で定性的な整理にとどまり、定量的な測定は今後の課題である。

7.2 ボイス演出の実務との構造対応

筆者の本業の一つであるキャラクターボイス演出の実務では、一流の声優は収録前に台本と資料の読み込みを終え、演技方針のおおよその理解を構築してスタジオに入る。演出の中心業務は、収録中の逐次的な指示ではなく、「作品理解の一致」を事前に構築し、検証することにある。

本実験の設計ファイル群は、この「理解の一致」を、属人的な阿吽の呼吸ではなく設計物として外在化したものに相当する。理解の一致が確立していれば最小の状況指示で演技が成立する——これはハイ・ローミックスのLOW側で観察された「状況を与えるだけで十分」という結果と同型である。

さらに演出実務には、次節の検証計画に直結する知見がある。理解の不一致は、主流場面では発覚しない。確立した演技の参照先が存在しないイレギュラー場面——たとえば成人主人公の子供時代の回想——で初めて、演者の内部にあるキャラクターモデルが露出し、演出側との差分が可視化される。理解の一致は、外挿を強制される場面でしか検証できない。

7.3 職能の移動

本実験が示唆するのは、シナリオライターの仕事の消滅ではなく移動である——「本文を書く」から「設計し、レビューし、承認する」へ。演出家が台詞を自ら読まずとも演技の質を決定するように、設計者は本文を書かずとも物語の質を決定する。ただし4章の事例群が示す通り、この移動後の職能は従来より軽い仕事ではない。読者認知の設計、レビューの設計、承認統制——いずれも、従来は暗黙知として処理されていた判断の明示化を要求する。

8. 限界と今後の検証計画

8.1 現時点の限界

クロスモデル検証はn=2にとどまる
生成品質の判定は筆者一名の官能評価に依存しており、第三者評価を経ていない
「物語エントロピー」は定性的概念にとどまり、測定手法が未確立
モデル補正設計（5.3）の効果検証が未実施

8.2 プローブシーンテスト【ステータス：未実施・次回実験】

7.2の演出実務知見に基づく検証手法。設計ファイルのカバー範囲外への外挿を意図的に要求する——たとえば、子供時代の記述が存在しない状態で、キャラクターの回想シーンを生成させる。外挿がキャラクターの核と整合していれば理解は深部まで一致しており、ズレていれば、そのズレ方自体が設計ファイルのどの層が不足しているかの診断情報となる。実施後、本節を結果で更新する。

8.3 ローカルLLM検証【ステータス：未実施・プローブシーンテスト後に実施予定】

商業ゲーム開発の実務では、機密要件によりクラウドLLMの利用が契約・ポリシー上の第一関門となる場合がある。本方法論の実務導入には、オンプレ運用可能なローカルLLMでの動作検証が必要である。ただしローカルモデルでは指示遵守力・実効コンテキストが低下するため、構造ガバナンスがモデル能力の低下をどこまで補償できるかが検証の焦点となる。本方法論の核心テーゼ——資産は設計フォーマットに宿る——が実務価値を持つのは、まさにモデルの差し替えを強制される場面であり、本検証はその試金石である。

8.4 第3モデル検証【ステータス：検討中】

開発過程に一切関与していない第3のモデルへの移植により、n=3での検証とすることを検討している。

9. 更新履歴

版	日付	変更内容
v0.1	2026-07-05	初版ドラフト。note連載1〜9回（実験18まで）の内容を体系化

本文書は継続中の実験に基づく生きた文書であり、内容は実験の進行に応じて更新される。過程の詳細な時系列記録はnote連載を、設計ファイルの実物はGitHubリポジトリを参照のこと。