はじめに
300話を超える長編シリーズものの小説を、個人でカクヨムに連載しています。
当初、思い付きで始めて、エピソード一覧や、キャラクターDBをxmlで管理していたのですが、これがまぁ更新が手間。
それでも300話 100万文字を超えるまでは手動で管理してましたが、これも限界を迎えたことで、VSCode＋Claude Code という環境に移行しました。
世の中には「Claude CodeにAIエージェントとして小説を書かせる」系の記事はすでにいくつかありますが、この記事はそれとは方向性が違います。AIに執筆権限を渡すのではなく、各工程の判断は人間（自分）が握ったまま、Claude Codeを工程管理・一貫性維持のツールとして使う、という話です。
解きたかった課題
長編シリーズものを何十話も書き続けていると、必ずぶつかる問題があります。
- 「このキャラ同士、もう面識あったっけ？呼び方は？」
- 「この設定、前に決めたやつと矛盾してない？」
- 「話数を後から分割したら、後続の話番号が全部ズレた」
- 「AIに一発で書かせたら、前話で確定してた経緯を勝手に作り直された」
これは全部実際に起きた事故です。
Claude Codeを単なる「文章生成機」として使うと、こういう事故は減りません。むしろ長文を一気に生成できる分、事故の被害も大きくなります。
そこで、Claude Codeにやらせるのは「工程の実行」まで、「何が正しいか」の判断は必ず人間を経由させるという設計にしました。
全体アーキテクチャ
執筆は4段階に分かれていて、それぞれ担当するモード（Claude Codeの動作モード）が違います。
| 段 | モード | 単位 | 出力先 |
|---|---|---|---|
| プロット | Ask | 1話 | チャット合意 |
| 台本 | Ask | シーン単位 |
scripts/（人間が編集しながら統合） |
| 本文化 | Agent | シーン単位 |
drafts/（AIが直接書き込む） |
| レビュー | Ask | ドラフト全体 | 指摘・修正案 |
| 正本化 | Agent | 1話 | episodes/ |
ポイントは、台本は人間が最終編集するのに、本文化はAIが直接ファイルに書き込むという非対称な設計になっているところです。
台本（セリフ・内心・ト書きの骨格）は物語の根幹なので人間がコピペしながら手を入れる。
本文化（台本を実際の小説の文章に変換する作業）は文章表現の変換作業なので、AIに直接書かせて人間は結果を手直しする側に回る。
工程ごとに「どちらが最終判断者か」を明示的に分けているのがミソです。
キャラクターの関係・呼称を「正本」で管理する
長編もので一番事故りやすいのが、キャラクター同士の関係性（面識・呼び方・親密度）です。
物語が進むにつれて呼び方は変わるし（「雪杜くん」→呼び捨ての「雪杜」など）、新キャラが増えるたびに誰と誰が面識済みかも複雑になります。
これをチャットの記憶やドキュメントの要約に頼ると、必ずズレます。なので専用スクリプトで正本を引く運用にしました。
python scripts/relationship-utils.py scene <id1> <id2> <id3> ... --brief
台本を書く前に、そのシーンに実際に絡むキャラのIDを渡すと、面識・呼称・親密度が正確に返ってきます。--brief（簡易表示）をデフォルトにしているのは、フルの履歴を出すと出力が4倍近くに膨れてコンテキストを圧迫するからです（8人分のフルだと2万文字が、5千文字程度になる）。
そして、DBとテキスト本文が食い違ったときのルールも決めています。「本文が正しい」。
DBはあくまで後から作った索引なので、本文に矛盾があればそちらを正として扱い、その場でDBを直します。
ファイルIDを二重管理する（日付ID→話数ID）
もう一つの地味だけど効いている工夫が、ファイルの命名規則です。
執筆中のファイル（プロット・台本・ドラフト）には話数を使わず、日付ベースのIDを振ります。
s-CH3-H1-0101-1.md # スピンオフ・第3章・高1・1月1日起点・1本目
正本化した瞬間にはじめて話数ID（CH3EP11.txt）を付けます。
なぜこんな回りくどいことをするかというと、話数は公開順×長さで決まるが、長さは書き終わるまでわからないからです。
最初から話数で名付けると、後から1話を前後編に分割したときに、それ以降の話番号が全部ズレて、下流のファイルまでリネームが波及します。
リネームだけならまだしも、DB側のIDのリファクタリングが本当に大変でした。
日付は絶対に動かないので、執筆中は日付IDで運用し、話数は「公開単位が確定した瞬間」にだけ一度きり付ける、というルールに落ち着きました。
設定は「解釈→OK→反映」の三段ゲート
キャラクターの設定・世界観のデータベース更新も、AIに一発で「読んで反映して」とは絶対に頼みません。
- 解釈: 該当話を読んで、解釈メモだけ出す（ファイルは更新しない、根拠のない推測は書かない、迷いは明記する）
- OK: 人間が解釈メモを確認する
- 反映: OKが出たものだけ、指示通りに反映する（勝手に足さない）
この三段を踏む理由は単純で、設定は推測禁止・本文根拠のみという原則を守るためです。
AIに任せると「たぶんこうだろう」で埋めてしまいがちな部分を、必ず人間の承認を挟むことで防いでいます。
まだ話数が確定していない（＝設定DBに反映できない）段階で出てきた設定は、PENDING.md という「反映待ち置き場」に溜めておきます。
これは同時に「回収していない伏線置き場」も兼ねていて、消化したら行を消すだけの軽量な運用にしています。
まとめ
- AIに「書かせる」のではなく「工程を実行させる」、判断は人間が握る
- キャラクターの関係性は要約ドキュメントではなく、スクリプトで正本を引く
- ファイルIDは執筆中（日付ベース）と正本（話数ベース）を分離し、リネーム波及を防ぐ
- 設定変更は解釈→OK→反映の三段ゲートを必ず通す
長編シリーズものを書いている人にとって、Claude Codeは「文章を書いてくれるツール」以上に、一貫性を維持するための工程管理ツールとして使うと効果が大きい、というのがここまでの実感です。
2022年にChatGPTが登場してからはや4年。
いまやAI作家は星の数ほどいそうですが、みんな独自の執筆スタイルを持っていると思います。
この記事が未来のAI作家の一助になれば。
ちなみに、最後に作品を紹介させてください。