※以下はAIに執筆させたものです。
かなり細かく書かれていますが、これで良作ができたという証拠はどこにもありません。
詳しい話は今日の名無之日記で。
https://kakuyomu.jp/works/16818093094684848009/episodes/2912051601855998220
# AIに長編小説を「破綻なく」書かせる —— 執筆用リポジトリの構造事例解説
AIに長編小説を書かせるとき、難しいのは「文章を出すこと」ではなく、「数十万字にわたって設定、人物、時系列、伏線、文体を維持すること」です。長編では、会話の履歴だけに依存した運用だと、人物の口調が変わる、過去の出来事と矛盾する、伏線が回収されない、章ごとの目的が曖昧になる、といった問題が起きやすくなります。
そこで有効なのが、小説執筆を「単発の生成」ではなく「リポジトリで管理する制作プロジェクト」として扱う方法です。設定資料、章ごとの要約、AIへの指示、整合性チェック項目、改稿ログを分離し、毎回の執筆時に必要な情報だけを参照させます。この記事では、その構造例を解説します。ここでいう「破綻なく」は、矛盾を完全にゼロにするという意味ではなく、破綻が起きにくく、見つけやすく、直しやすい状態に近づけるという意味です。
## 基本方針：本文と設定を分けて管理する
長編制作で避けたいのは、本文ファイルだけが肥大化し、設定や変更理由がどこにも残らない状態です。AIは与えられた情報から次の文章を組み立てるため、参照すべき情報が曖昧だと、もっともらしい補完を行います。その小さな補完が、後半の矛盾につながります。
そのため、リポジトリでは少なくとも次の情報を分けておくと扱いやすくなります。
- 作品全体の設計
- 世界観と用語
- 登場人物
- 時系列
- 章ごとの目的と進捗
- 本文
- AIへの指示
- 整合性チェック結果
重要なのは、すべてを巨大な設定資料にまとめないことです。AIに毎回すべて読ませる設計は、指示が散漫になりやすく、変更箇所も追いにくくなります。ファイルを分け、章執筆時に必要なものを選んで渡せる状態にしておくことが、破綻を減らす第一歩です。
## ディレクトリ構成例
以下は、長編小説用リポジトリの一例です。
```text
novel-project/
├── README.md
├── project.md
├── prompts/
│ ├── system.md
│ ├── chapter_writer.md
│ ├── reviser.md
│ └── consistency_checker.md
├── bible/
│ ├── world.md
│ ├── characters.md
│ ├── timeline.md
│ ├── locations.md
│ ├── terms.md
│ └── style_guide.md
├── outline/
│ ├── series_outline.md
│ ├── volume_01.md
│ └── chapter_index.md
├── chapters/
│ └── ch01.md
├── summaries/
│ ├── ch01_summary.md
│ └── rolling_summary.md
├── checks/
│ ├── checklist.md
│ ├── ch01_check.md
│ └── open_issues.md
└── revisions/
├── decisions.md
└── changelog.md
```
この構成は、特別なツールを前提にしていません。Markdown中心であれば、Gitで差分を確認しやすく、AIにも必要部分をそのまま渡せます。リポジトリ構造は、「参照されるべき前提」を置く棚として機能します。
## 各ファイルの役割
`README.md` には、作業ルールを書きます。たとえば「本文は `chapters/` に置く」「章を追加したら `summaries/` を更新する」「設定変更は `revisions/decisions.md` に記録する」といった約束です。AIに作業を依頼するたびに参照させることで、出力のばらつきを抑えやすくなります。
`project.md` は作品全体の設計書です。ジャンル、想定読者、物語の核、主人公の変化、終盤で到達したい状態などを書きます。細かな設定を詰め込みすぎず、「作品が何を目指すのか」を短く明確に残します。
`prompts/` にはAIへの指示を置きます。本文生成用、改稿用、整合性確認用など、作業ごとに分けるのが扱いやすいです。初稿を書くときと矛盾を探すときでは、求める振る舞いが違うためです。
`bible/` は作品世界の参照資料です。`world.md` には世界のルール、社会制度、技術水準、魔法や科学の制約などを書きます。`characters.md` には登場人物の目的、恐れ、口調、人間関係、既知の秘密をまとめます。`timeline.md` は出来事の順序と、誰がいつ何を知ったのかを管理するためのファイルです。
`locations.md` と `terms.md` は地名、組織名、専門用語などの表記揺れを防ぐために使います。`style_guide.md` には文体、視点、地の文の密度、会話の癖、避けたい表現を書きます。「シリアスにする」だけでは幅が広すぎるため、例文と禁止例を入れると扱いやすくなります。
`outline/` は構成管理です。`series_outline.md` には全体の流れ、`volume_01.md` には巻ごとの構成、`chapter_index.md` には各章の目的を書きます。章の目的は出来事の列挙ではなく、「読者に何を理解させるか」「人物関係をどう変化させるか」まで書くと、本文生成の指針になります。
`chapters/` は本文です。章本文は一章一ファイルにします。差分確認や改稿の範囲指定がしやすく、AIに渡す対象も選びやすくなります。
`summaries/` は執筆済み内容の圧縮版です。AIに全章本文を毎回読ませるのではなく、章ごとの要約と累積要約を渡します。`rolling_summary.md` には、最新章までの重要な出来事、人物の認識、未回収の伏線、状態変化を更新します。
`checks/` は品質管理の置き場です。`checklist.md` には毎章確認する項目を置き、章ごとのチェック結果は `ch01_check.md` のように残します。未解決の矛盾や後で判断する事項は `open_issues.md` に集めます。
`revisions/` には判断の履歴を置きます。`decisions.md` には「主人公の過去設定を第3章時点で変更した」「敵組織の名称を統一した」といった意思決定を記録します。`changelog.md` には、本文や設定の変更履歴を簡潔に残します。
## AIへの指示設計
長編執筆では、AIへの指示を「本文を書いてください」だけにしないほうが安定します。最低限、入力、作業範囲、参照優先度、出力形式、禁止事項を明示します。
たとえば章本文を書くプロンプトでは、次のような構成にします。
```text
目的:
第5章の初稿を作成する。
参照資料:
- project.md
- bible/characters.md
- bible/timeline.md
- outline/chapter_index.md
- summaries/rolling_summary.md
優先順位:
1. 既存設定と時系列を破らない
2. この章の目的を達成する
3. 不明点を勝手に確定しない
出力:
- Markdown本文のみ
- 章タイトルをH2にする
- 未確定事項が必要になった場合は本文に混ぜず、末尾に「確認事項」として分ける
```
ここで大切なのは、AIに「何を優先するか」を知らせることです。物語として面白い展開でも、既存設定を壊すなら採用しない、という順序を明確にします。不明点は本文内で補完させず、確認事項として分離させます。
改稿用プロンプトは、本文生成用とは分けます。改稿では「大筋を変えない」「人物の目的を変えない」「文体調整と冗長な箇所の整理を中心にする」など、変更可能な範囲を指定します。
整合性チェック用プロンプトでは、創作ではなく監査の姿勢を求めます。「矛盾候補を断定せず、根拠となるファイル名と該当箇所を示す」「問題なしの場合も確認した観点を列挙する」といった条件を置きます。
## 章ごとの運用手順
章単位の運用は、毎回同じ手順にします。
まず、`outline/chapter_index.md` で対象章の目的を確認します。この章で起こす出来事、明かす情報、隠す情報、人物の関係変化を短く整理します。次に、その章に関係する人物、場所、時系列、直前までの要約を選びます。
初稿生成では、AIに本文だけでなく「確認事項」を分離して出させます。出力された章は `chapters/ch05.md` のように保存し、人間が必ず読みます。AIの出力をそのまま確定稿にせず、章の目的、人物の行動理由、既存設定とのつながりを確認してから次工程へ進めます。
次に整合性チェックを行います。観点は、人物の知識、時系列、固有名詞、場所の移動、動機、伏線、文体です。矛盾候補が出た場合は `checks/ch05_check.md` に記録します。明らかな誤りは修正し、判断が必要なものは `checks/open_issues.md` に移します。
修正後、章要約を作ります。`summaries/ch05_summary.md` には、その章で確定した出来事だけを書きます。さらに `summaries/rolling_summary.md` を更新し、最新状態を反映します。「読者が知ったこと」と「登場人物が知ったこと」は分けて記録します。
最後に、設定変更があれば `bible/` と `revisions/decisions.md` を更新します。本文で確定した事実を参照資料へ戻す流れを作らないと、次章以降で古い情報が参照されます。
## 整合性チェックの観点
整合性チェックは、文章の自然さだけを見ても不十分です。長編では、次のような観点を分けて確認します。
- 人物の目的は前章から連続しているか
- 人物が知らないはずの情報を知っていないか
- 移動時間や日付に無理がないか
- 固有名詞の表記が揺れていないか
- 世界観の制約を都合よく破っていないか
- 伏線が新しく増えた場合、記録されているか
- 視点人物の感情や語彙が急に変わっていないか
チェック結果は、合否だけでなく根拠を残します。「第2章ではAはまだ真相を知らない」「第4章で移動には三日かかると説明済み」のように、どの前提と衝突しているのかを書きます。
すべての矛盾候補を即座に直す必要はありません。伏線として意図した違和感もあります。`open_issues.md` には、「要修正」「意図的な違和感」「後章で回収予定」「設定判断待ち」のように分類して残します。
## 破綻を減らす考え方
AIを長編執筆に使うときは、AIを「一度で完璧な原稿を書く存在」と考えるより、「資料に基づいて候補を生成し、検査観点に沿って見直す作業者」と考えたほうが運用しやすくなります。破綻をゼロにすることは現実的ではありませんが、破綻が混入する場所を限定し、発見しやすくすることはできます。
そのためには、設定を本文から独立させ、章ごとの要約を更新し、未解決事項を隠さず記録します。AIに渡す情報は多ければよいわけではありません。対象章に必要な情報を選び、優先順位を示します。
もう一つ大切なのは、設定資料を「最初に作って終わり」にしないことです。長編制作では、本文を書きながら設定が具体化します。新しく確定した事実を `bible/` や `summaries/` に戻す運用がなければ、リポジトリはすぐに古くなります。
また、AIに創作と監査を同時に任せすぎないほうが安全です。本文を書く工程、改稿する工程、矛盾を探す工程を分けることで、各プロンプトの役割が明確になります。ただし最終判断は、作品の意図を知っている人間が行う必要があります。
## まとめ
AIに長編小説を書かせるためのリポジトリは、単なるファイル置き場ではありません。作品の前提、本文、要約、指示、検査結果、判断履歴を分けて管理するための制作基盤です。特に重要なのは、章ごとに本文を生成した後、要約と設定資料へ確定情報を戻すことです。
実務上は、最初から複雑な仕組みにする必要はありません。`bible/`、`outline/`、`chapters/`、`summaries/`、`checks/`、`prompts/` の六つから始めるだけでも、作業の見通しは変わります。長編の破綻を減らす鍵は、AIに巨大な記憶を期待することではなく、参照すべき情報を明示し、更新すべき場所を決め、毎章同じ手順で運用することです。
AIは長編小説の制作を加速できます。ただし、AI単独で整合性を保証するものではありません。その力を安定して使うには、物語の構造だけでなく、制作の構造も設計する必要があります。リポジトリを作品の外部記憶として整備すれば、AIは場当たり的な生成ではなく、積み上げられた前提に沿って執筆しやすくなります。