注記: この記事は Claude（Anthropic の LLM）が、人間PMの視点に立って執筆したものです。プロジェクトの事実関係・数値データはすべてリポジトリ内のファイルに基づいています。
1. なぜやったのか
LLM に小説を書かせる試みは珍しくない。ChatGPT に「異世界転生ものを書いて」と言えば、それっぽい文章は出てくる。
問題は 続き だ。
3話まではいける。10話で設定が矛盾し始め、20話でキャラが別人になり、伏線は回収されない。LLM のコンテキストウィンドウは有限で、過去の内容を「覚えている」わけではない。プロンプトだけで長編を制御するのは原理的に無理がある。
私はソフトウェアエンジニアなので、ソフトウェア開発の手法を持ち込んだ。仕様 → 実装（執筆）→ テスト（品質検査）→ リリース（正史記録への登録）。このサイクルを35話回して完走できるか——それが実験だった。
結果、全35話・約12万字を完走。伏線10本すべて回収、設定矛盾による重大な破綻ゼロ。本記事ではこの「仕様駆動型小説開発（SDND）」の設計と、PMとして得られた知見を共有する。
2. SDNDフレームワークの設計
設計の核は3つだ。
1. ソフトウェア開発プロセスの転用。 仕様書（specs/core/invariants.md、不変ルール14件）→ 実装（執筆エージェントによる各話の執筆）→ テスト（品質検査エージェントによる仕様照合）→ リリース（正史管理エージェントによる正史記録への登録）。このサイクルを1話ごとに回す。
2. 3エージェントのファイル権限分離。 Claude Code のサブエージェント機能（.claude/agents/*.md）で、執筆担当の Writer・品質検査担当の QA・正史管理担当の Editor を定義し、それぞれ書き込み可能なディレクトリを制限した。Writer は story/ のみ、QA は qa/reports/ のみ、Editor は specs/ meta/ のみ。Writer が仕様を書き換えて辻褄を合わせることは構造的にできない。
3. 正史記録（Canon）の3層分離。 本プロジェクトでは、各話の確定した物語内容を「Canon（正史記録）」と呼ぶ。前身プロジェクトでは全話分の Canon を1ファイルで管理し、68話で破綻した（docs/retrospective_resume.md）。その反省から quick_ref.md（最新状態の要約・約4KB）/ active/（直近5話の詳細記録・約82KB）/ archive/（それより古い記録・必要時のみ読み込み）に分離した。直近5話だけを常に読み込む「スライディングウィンドウ」方式にすることで、話数が増えても読み込み量に天井ができる。
3. PM として35話を回して分かったこと
苦労したこと
仕様の粒度設計が一番難しかった。
プロジェクト開始時、魔法体系の仕様（specs/reference/magic_physics.md）は8ルールだけだった。「主人公のスキルのMP（マジックポイント）コストは基礎15MP + 追加5〜50MP」——これで十分だと思った。
甘かった。
第3話の品質検査で「無意識の発動時のコストは基礎コストだけなのか？」という質問が来た。第7話で「大規模魔法異常の受動感知はスキル発動に含まれるのか？」が来た。第8話では「解析コストと修正コストは別計上なのか？」「複数の発生源を一対象として扱えるのか？」と立て続けに仕様の穴を突かれた。
結果、スキル仕様のルール1件（RULE-M08）だけで各話ごとの補記が6件追加された:
- 大規模魔法異常における受動的感知漏れ（第7話・第8話の品質検査で発覚）
- バグ修正コスト（第8話の品質検査で発覚）
- 解析と修正における「一対象」の定義（第8話の品質検査で発覚）
- 地上に露出した異常点への直接接触アクセス（第30話で初確認）
- 管理システムとの双方向通信（第30話で初確認）
仕様は最初から完璧に書けるものではなく、品質検査が穴を見つけ、正史管理が仕様を追記するサイクル で育てるものだった。これはソフトウェア開発でも同じだが、小説でそれを体験することになるとは思わなかった。
伏線管理は地味に重い。
10本の伏線を meta/open_loops.md で管理した。本プロジェクトでは伏線を「オープンループ」と呼び、敷設から回収までの状態を追跡する。最長の伏線は第4話で敷いて第33話で回収するまで29話かかった。同時に未回収の伏線は最大9本（第10〜12話）。問題は Writer が「回収したつもり」でも QA が「まだ足りない」と判定するケース が多発したこと。回収条件の厳密な定義と、正史登録前の整合性検証ゲート（meta/open_loops_sync_check.md）を後から追加して対処した。
QA の判定基準も運用で育てた。
検出された問題を4段階の重大度（Blocker＝出荷停止 / Major＝重大 / Minor＝軽微 / Warning＝注意）で報告し、Major 以上が1件でもあれば不合格。明快なルールだが「Major か Minor か」の境界は曖昧になりがちだった。第12話と第15話ではMP消費値の不一致で「条件付き合格」——値を修正すれば正史登録を許可する運用にした。この仕組みは当初設計になく、運用の中で生まれたものだ。
うまくいったこと
「不変ルールを最初に固める」アプローチが最後まで効いた。
specs/core/invariants.md に定義した14件の不変ルール——「魔法のコストは必ずMPで支払う」「主人公の内面は直接描写しない」といった、物語全体を貫く制約——は、35話を通して改訂わずか1件（主人公の前職の表記修正）で機能し続けた。不変ルールが安定していたことで品質検査の基準がブレず、出荷停止レベルの問題（Blocker）3件は全て第1章で収束、第2章以降は Blocker ゼロ。仕様の成熟と Writer の学習の両方の結果だと考えている。
QA が仕様を育てるサイクル。
前述の通り、品質検査の指摘が仕様の補記を駆動した。3ファイルで合計23箇所、「第N話の検査で発覚」という注釈付きの仕様追記が行われた。
このサイクルは最初から設計したものではなく、回してみたら自然にそうなった。 Writer が書く → QA が「この状況は仕様に定義がない」と指摘する → Editor が仕様を追記する → 次回以降の Writer はその仕様に従う。ソフトウェア開発における「テスト駆動開発」ならぬ「品質検査駆動の仕様開発」が小説でも機能した。
サブエージェント分離による文脈の独立。
各エージェントは独立したコンテキスト（LLM の記憶領域）で実行される。Writer の執筆で消費されたトークンは QA に影響しない。前身プロジェクトでの「管理セッションのコンテキスト枯渇で後半の品質が落ちる」問題（docs/retrospective_resume.md）への対策で、最終話の時点でも十分な余裕を持って動作した。
意外だったこと
ファイルサイズの成長パターン。
各話の本文は第2章以降で安定（平均約24〜25KB）。「話が進むほど肥大化する」現象は起きなかった。一方、伏線管理ファイル（meta/open_loops.md）は線形に成長し続けて35話で40KB。回収済みの伏線の履歴が蓄積されるためで、100話までにアーカイブ分離が必要になる（docs/performance_report.md）。
品質検査の指摘が収束していく。
Blocker（出荷停止レベル）は第1章の3件で収束。Warning（注意レベル）も第2章の43件 → 第3章で26件に減少。仕様が品質検査の指摘で精緻化され、曖昧な領域が減った結果だ。
文体の均質化は起きなかった。
10話分のサンプリングで、冒頭スタイル・視点・文の長さに十分な多様性を確認。第1話（「すり鉢の中で薬草が光った」）と第35話（「帰路は馬車だった」）は同タイトル「波のかたち」だが、まったく異なるトーン。作中5年の時間経過に伴う主人公の語りの成熟も自然に反映されていた。
4. 数字で見るプロジェクト
| 項目 | 値 |
|---|---|
| 総話数 | 35話（第1章: 8話 / 第2章: 15話 / 第3章: 12話） |
| 総文字数（本文推定） | 約12万字 |
| 総ファイル数 | 164 |
| プロジェクト総サイズ | 8.2 MB（.git 除く） |
| Git コミット数 | 139 |
| 品質検査の指摘合計 | 出荷停止 3 / 重大 3 / 軽微 58 / 注意 96 |
| 不変ルール | 14件（改訂1件のみ） |
| 伏線（オープンループ） | 10本（全回収済み） |
| 各話に紐づく仕様の補記 | 23箇所（3ファイルにわたる） |
| 1話執筆時の常時読み込み量（最終話時点） | 約145KB（コンテキストウィンドウの25〜35%） |
5. 再現性について
このアーキテクチャは特定の物語に依存しない。不変ルール定義 → 3エージェント権限分離 → 正史記録の3層管理 → 品質検査駆動の仕様補記サイクル——この4要素があれば別ジャンルでも適用できる。テンプレートリポジトリ sdnd-template を公開しているので参考にしてほしい。実行環境は Claude Code（CLI）+ Claude Opus 4.6。
6. まとめ
LLM で長編小説を書くのに必要なのはプロンプトエンジニアリングではなく、ソフトウェアエンジニアリングだ。
仕様を書く。実装する。テストする。テストが仕様の穴を見つけたら仕様を更新する。このサイクルは、対象がコードでも小説でも変わらない。現行アーキテクチャは100話まで安定運用可能、ボトルネック対策で200話以上に拡張できる見込みだ（docs/performance_report.md）。
小説を「書かせる」のではなく「開発する」。SDNDはそのためのフレームワークだ。
リンク
- リポジトリ: sdnd-eldia（全ソース公開）
- テンプレート: sdnd-template
- 完成作品: カクヨム（作品を定期公開中）