「生成AIで小説家になりました」…
こう書くと、プロンプトを数行投げて「はい、できあがり」という魔法のような話を想像されるかもしれません。
しかし、実態は全く違いました。
1文字も本文は書いていませんが、170ページ（約8万字）に迫る近未来アクション巨編を書き上げる工程は、まさに泥臭いソフトウェア開発そのものだったのです。

始まりは「不純な動機」と「哲学的な議論」
きっかけは、Geminiに課金して株やFXのスクリーニングスクリプトを書かせようとしたことでした。仮想通貨の価値についてGeminiと議論しているうちに、「この議論をテーマに小説を書いたら面白いのでは？」と思いついたのが運の尽き。
キャラ設定を固め、プロットを絶賛され、気分良く「じゃあ、これで小説書いてみて」とAntigravityに指示を出しました。
「あらすじ」と「本編」の大きな壁
期待して待っていた私に返ってきたのは、スカスカの「あらすじレベル」の文章。
Amazonで売れるような代物ではありません。
「500枚（原稿用紙）くらいの大作にして！」と指示を重ねると、途端にAIが暴走を始めました。
• 設定では「先輩」だった恋人が、いつの間にか「同級生」に。
• 可憐なヒロインが、勝手に復讐鬼に変貌し「口元を魔女のように歪める」。
なるほど、彼らはまだ人類を滅ぼすほどには進化していませんでした。
1から10まで、人間がPM（プロジェクトマネージャー）として指揮を執らなければならないことに気づいたのです。
小説執筆を「ソフトウェア開発プロセス」に落とし込む
まるで外注先にコーディングを頼むときのような感覚。
そこで私は、**ソフトウェア開発プロセスを参考にした「執筆エージェント群」**を構築することにしました。
① 構成管理と整合性チェック
ストーリーとキャラ設定が噛み合わなくなるのを防ぐため、中間成果物間の整合性を毎回必ずチェックするプロセスを導入しました。これがキモです。
② マルチエージェントによる役割分担
以下のような役割を持つエージェントを立ち上げ、私が「プロジェクトオーナー」として指示を出す体制にしました。
• 校正担当者：日本語の誤りや矛盾を指摘
• 一般読者ペルソナ：読者目線での面白さを代弁
• 編集者エージェント：全体を統括し、変更を各所に反映させる
③ プロセス改善（PDCA）の徹底
しかし、ハルシネーション（もっともらしい嘘）は止まりません。「二度と過ちは起きません」と誓ったはずのエージェントが、次の瞬間にはルールを忘れています。
さらに、Geminiのコンテキスト上限による「担当者の休職（モデルの切り替え）」が発生。別のモデルに切り替えると、これまでの経緯を忘れて「鉄の掟」が霧散します。
ここで私はブチギレました。
「お前らの仕事のやり方をUML（Mermaid）で書いてみろ！」

出てきた図はスパゲティ状態。構造化を行い、編集者を通さない勝手な成果物の変更を禁じ、変更時の発動条件（トリガー）を定義する「鬼のプロセス改善」を繰り返しました。

「感性」のパラメータ設計
構造が整ったら、次は「心」の設計です。箇条書きの文章では読者は動きません。
アドレナリン、ドーパミン、オキシトシン、コルチゾールといった脳内物質の分泌をイメージした「感情値メトリクス」を設定し、それに合わせた描写を要求しました。
まとめ：AI開発から学んだ教訓
構想3日、エージェント作成とデバッグに1週間。計10日で上梓まで漕ぎ着けました。
このプロジェクトを通して得た知見は以下の通りです。

課題	対策（ソリューション）
プロセスの不備	行き当たりばったりの指示は現場を混乱させる。IPAのESPR Ver2（ウォーターフォール）を参考に、成果物が連鎖する構造を構築。
コンテキスト不足	有限の情報を圧縮・要約して引き継ぐ仕組み。モデル切り替え時も「タスクリスト」を参照させて継続性を確保。
品質保証	複数の読者ペルソナによる「妥当性確認テスト」を実施。5回以上の議論で全員が合格を出すまでリテイク。

終わりに
長編小説におけるAIは、まだ「自動生成」の段階ではなく、**「高度なバグ埋め込みマシン」**です。
今回、あえてイニシエの知恵である「ウォーターフォール」を導入したことで、ソフトウェア開発の原理原則の重要性を再認識しました。
次は「時代小説」を設計中です。
あと2年もすれば、人間が二言三言つぶやくだけで、これくらいの小説は出来上がってしまうのかもしれませんが、今はまだ、この「AIを叱咤激励する開発プロセス」を楽しもうと思います。

今回の検証で出力された200ページの成果物は、実際にKindleで上梓しました。AIによる長編の文体や整合性が気になる方は、サンプル等で確認してみてください。

『世界が0と1に分かれても -UNPLUGGED-』