AI長編小説の創作モデル
馬場祐平です。
このページでは、制作の技術的な仕組みを書いています。
AI小説の作り方に興味がある方、特に「どうやって一貫性を保つのか」という疑問を持っている方に向けています。制作の経緯が気になる方は先に②制作の舞台裏を読んでいただくと、なぜこういう設計になったかが分かりやすいと思います。
SPMモデルとは
この小説の制作は、ソフトウェア開発の**MVC（Model-View-Controller）**の概念にヒントを得た、データ駆動型のパイプラインとして設計しています。設定（S）→プロット（P）→原稿（M）という順方向の生成パイプラインです。それを小説制作用に命名したのが SPMモデル（Settings → Plots → Manuscripts） です。
| S: Settings（設計図） storyline / os_theory / characters 等 → 物語の憲法。Single Source of Truth |
| ↓ |
| P: Plots（中間生成物） シーンサマリー・伏線マップ → Sを具体化する中間言語 |
| ↓ |
| M: Manuscripts（原稿） 各章の原稿ファイル（1シーン1ファイル） → 読者が目にする最終アウトプット |
上の層が変わると下の層を生成し直します。S → P → M の順に情報の解像度が上がります。推敲フェーズでは逆方向にも伝播し、M層の矛盾をP→Sへ遡って修正します。これを23回繰り返しました。
S: Settings（設計図）
設定ファイルは5つです。SPMファイル実物にすべて公開しています。
通常の小説に必須の3要素:
| ファイル | 役割 |
|---|---|
| storyline.md | 作品コンセプト・核心メッセージ・全体構成 |
| characters.md | 各キャラクターのOS・形成背景・変容プロセス |
| style_guide.md | 文体ルール・NG表現・キャラクター別口調設計 |
ビジネス小説特有の2要素:
| ファイル | 役割 |
|---|---|
| os_theory.md | OS理論の体系（自分本位↔他者本位、思考型↔行動型の4象限） |
| app_design.md | 学習フレームワーク（PDCA・GROW等）の埋め込み設計 |
読み順:
storyline.md → os_theory.md → characters.md → style_guide.md → app_design.md
設計の核心: storyline.md をS層に置く決断が最大の肝です。ストーリーラインを「静的な仕様」として固定することで、物語の背骨がAIに振り回されるのを防いでいます。
いちばん苦労したのはcharacters.mdです
設定ファイルの中で、設計に最も時間がかかったのがcharacters.mdです。
初期バージョン（v3〜v4）で学んだのは、「キャラクターの行動原理（OS）だけ書いても機能しない」という事実でした。登場人物が原理に基づいて、具体的にどんな行動を起こすのかが、AIに分からないんです。
そこで「OSと形成背景を必ず結びつける」設計にしました。たとえば主人公の行動原理のひとつは、高校サッカーで「覚悟のある者に負けた経験」を「身体能力のせい」と合理化してきた歴史から来ています。この背景をファイルに書き込んで初めて、AIがセリフや行動の「なぜ」を推測できるようになりました。
P: Plots（中間生成物）
plots/ フォルダに、全シーンのサマリーを置いています。P層は内部でさらに3段階の粒度に分かれます。
| 粒度 | 内容 | 例 |
|---|---|---|
| Scenario | 作品全体または部単位の大まかな流れとテーマ | scenario.md、scenario_part1.md |
| Chapters | 章単位の構成・登場人物・転換点 | chapter_01.md |
| Scenes | シーン単位のビート・PDCA層・伏線 | scene_summaries_part1.md |
各シーンのサマリー形式はこんな感じです。
## Scene XX_XX: シーン名
### あらすじ（3-5文）
### 登場人物
### 時系列
### ビート（シーンの転換点） ← 全体構成における位置情報
### PDCA層 ← 学習フレームワークのどの段階か
### 伏線・接続 ← 前後のシーンとの関係
「ビート」と「PDCA層」という位置情報が重要で、これがないとAIは毎シーン独立した起承転結を書いてしまいます。「このシーンは物語全体の『転』に当たる」という地図情報が、プロットの崩壊を防いでいます。
plots層はほぼ完全にAI自動生成です。characters.mdとstoryline.mdを投入し、Claudeにシーン設計を生成させました。その後、K氏とのMTGで「このシーンは弱い」「この伏線は前の章で張るべき」というフィードバックを重ねながら精緻化しています。
M: Manuscripts（原稿）
原稿は1シーン1ファイルで管理しています（例：03_manuscripts/01_01_四月の営業フロア.md）。
コーチングシーン（[L]シーン）の8ステップ構造
佐伯が翼にコーチングを行う場面は特に重要で、内容的に機能するように8ステップの構造が定義されています。
| # | ステップ | 内容 |
|---|---|---|
| ① | 切実な問題 | 翼が直面している具体的な壁 |
| ② | 問いかけ | 佐伯が核心に向かう質問を投げる |
| ③ | 間違い・反発 | 翼が的外れな回答や抵抗を示す（読者の典型的誤解を代弁） |
| ④ | What | 概念の正体を提示する |
| ⑤ | Why | なぜそれが重要か、構造的に説明する |
| ⑥ | How | どうすれば実践できるか |
| ⑦ | 実践・失敗 | 翼が試してうまくいかない |
| ⑧ | 統合 | 気づきが定着し、次の壁へ向かう |
詳細はアプリ設計書に書いています。
推敲フロー（バックプロパゲーション）
S → P → M の順方向だけでなく、推敲フェーズでは逆方向にも伝播します。
M層で矛盾・品質問題を発見
↓
P層（シーンサマリー）を修正
↓
S層（設定）まで影響するか判断
↓
S層修正 → P層再生成 → M層再生成
この「上位レイヤーへの遡り → 下位への伝播」をソフトウェア開発のリファクタリングと同じように運用し、23バージョンにわたって繰り返しました。
コンテクストウィンドウという制約
AIには「コンテクストウィンドウ」と呼ばれる短期記憶の上限があります。Claude の場合、128K トークンが上限です。日本語は英語より文字あたりのトークン消費が大きいため、実用的には設定ファイルだけで数万字を超え、小説本文を1部まるごと読み込ませることはできません。
この制約が、AI長編小説の創作モデルの設計理由の一つです。
- **Layer 1（settings）**は変わらない設計図なので、AIは毎回全体を読む必要がある
- **Layer 2（plots）**は粒度を分けて管理する——物語全体・部単位・章単位・シーン単位のプロットを別々のファイルにしておき、あるシーンを書くときは「そのシーンに必要な情報だけ」を渡す
- **Layer 3（manuscripts）**は1シーン1ファイルにして、AIが一度に処理する量を絞る
こうすることで、コンテクストウィンドウをできるだけ消費せず、AIに「今書くべきシーン」に集中させられます。変更があった場合は、AIが関連するプロットファイル自体も更新する、という方法で一貫性を保っています。
23回書き直した理由
なぜ23回も、という疑問があるかもしれません。
1回のイテレーションは「設定変更 → サマリー更新 → 原稿再生成 → フィードバック」のサイクルです。v1が2月初旬、v23が3月3日。約1ヶ月で23回。平均すると1〜2日に1バージョンです。
失敗したバージョンも消していません。OLD/ フォルダに全部残してあります。「これが機能しなかった」という実験記録が、次の設計判断の根拠になるからです。
AIを使う側に回ることで判断は速くなります。ただ、それは「AIに任せる」ということではなく、「何が機能して何が機能しないかを、繰り返し判断し続ける」ということです。この設計全体の前提です。
1日の作業サイクル
このプロジェクトを28日間続けられたのは、日々のサイクルが確立できていたからだと思っています。
早朝（20時就寝、3時起床）
↓ 前夜のAI出力を確認・軽くフィードバック
朝のMTG
↓ Gemini議事録が数分後に生成される
即座に議事録をMarkdownに変換してClaudeに投入
↓ 設計ファイル更新・改稿の指示を出す
日中はAIに作業してもらう（VS Code Agentモード）
↓
夕方（仕事上がり前）に進捗確認・方向修正
↓
夜就寝後もAIが作業を続ける
↓
翌朝、出来上がったものを確認して次のサイクルへ
ポイントは2点あります。
プランをしっかり立てる。VS Code のAgentモードは、計画が曖昧だと意図しない方向に作業が進んで、数時間後に「全部やり直し」になる。改稿の規模・対象・制約をMarkdownのプランとして明示してからAIに渡すことが、時間ロスを避ける最大のポイントです。
確認タイミングを絞る。毎回の出力を都度確認しようとすると、AI小説制作は著者の作業時間で詰まります。朝と夕方の2回を「編集確認タイム」と決めて、その間は基本的にAIに動いてもらう。この設計が、日中は通常の仕事を進めながら、28日間で23バージョンを回せた理由の一つです。
- ①なぜ作ったか — プロジェクトの動機と経緯
- ②制作の舞台裏 — MTGの記録と試行錯誤のプロセス
- ③AIを使った長編小説の現在地 — 「日本初」の根拠について
- ⑤フォークして参加する — GitHubでの参加方法
- SPMファイル実物 — 実際に使用した設定・プロットファイルの一覧