4作品・61章。AIと長編を書いて分かったこと

2110 Labでは、4作品・全61章の長編小説をAIと共作した。CG挿絵150枚、キャラクター立ち絵39枚。それなりの規模だ。

AIに小説を書かせること自体は珍しくない。短編なら驚くほど上手くいく。問題は、その先だ。章が10を超えたあたりから、前の章で死んだはずのキャラが会話に参加する。伏線が消える。口調が変わる。設定資料に「記憶喪失」と書いてあるのに、普通に過去を語り始める。

この記事では、破綻を防ぐために試行錯誤した末にたどり着いたワークフローを紹介する。失敗談も包み隠さず書く。

なぜAIは長編で破綻するのか

根本原因は、AIのコンテキストウィンドウが有限であること。長編小説は1章だけで数千字。10章分を丸ごと渡すことは現実的ではない。

「設定資料を渡せばいいのでは」と思うかもしれない。自分も最初はそう考えた。だが設定資料には「第3章でキャラAがキャラBに言ったセリフの具体的なニュアンス」は書かれていない。物語の連続性は、そういう細部の積み重ねで成り立っている。

核心: 前の章の実際に書かれたテキストを読まないと、次の章との繋がりが破綻する。設定資料やプロットだけでは、物語の「手触り」は引き継げない。

最大の失敗: 並列執筆という誘惑

正直に書く。最大の失敗は、速度を求めて複数の章を同時に書かせたことだ。プロットは既にあるのだから、序盤・中盤・終盤を別々のAIエージェントに同時に書かせれば3倍速になるのでは、と考えた。

結果は惨憺たるものだった。

教訓: 速度の誘惑が品質を崩壊させた。物語は本質的に逐次的。前のシーンの結果が次の前提になる。この因果関係を無視して並列化はできない。

現在のワークフロー: ストーリーステート方式

並列執筆の失敗を経て構築したのが「ストーリーステート方式」。ゲームに例えるなら、物語のセーブデータを章ごとに保存していく仕組みだ。

ストーリーステートの中身

各シーン完了時に以下を更新する:

執筆の流れ

1シーン = 1つのAIエージェント。前シーンの全文とストーリーステートを渡して書かせる。書き上がったら別のAIエージェントが検証。人物の位置、呼称の一貫性、伏線の整合性をチェックし、問題があれば次に進まず修正する。

ポイント: 「書く人」と「検証する人」を分ける。ソフトウェア開発のコードレビューと同じ発想だ。書いた本人は自分の矛盾に気づきにくい。

モデル選び: なぜClaude Opus 4.6か

長編執筆のメインモデルにはClaude Opus 4.6を使っている。理由は明快だ。

設定資料の作成やプロット設計など、物語本文に影響しない作業は他モデルで並列化している。本文だけは妥協しない、という使い分けだ。

検証で見つかった具体的な矛盾例

実際に発生した矛盾をいくつか紹介する。

1つ1つは小さく見えるが、読者は敏感だ。口調の一貫性が崩れると没入感が一気に損なわれる。検証ステップが、これらを本番テキストに残さない最後の砦になっている。

まだ残る課題

まとめ: 「メタ認知」を外付けする

AI単体には、自分が何を書いたかを振り返る力がない。前の章の伏線も、キャラの感情変化も、「覚えている」のではなく「毎回教えてもらう」必要がある。

ストーリーステートは、AIにメタ認知を外付けする仕組みだ。ワークフローがAIの弱点を補い、人間の検証が暴走を防ぐ。速度の誘惑に負けなければ、高品質な長編はAIで書ける。61章を書き切った経験から言えるのは、「仕組みで品質を担保する」という発想が不可欠だということだ。

CG挿絵 - Crown
CG挿絵 - Crown
CG挿絵 - Crown

実際の作品は 小説ライブラリ で読めます。4作品・61章・CG挿絵150枚。ストーリーステート方式で書き上げた長編小説の成果を、ぜひ確かめてみてください。

小説を読む →