AIエージェントと小説を個人開発した話
AIエージェントと小説を個人開発した話 — 3ヶ月で20話をWeb公開
AIコーディングの題材は、アプリだけじゃなくてもいい。この記事では、Claude CodeやCodexといったAIエージェントと小説「さくらコード」を制作し、約3ヶ月で第1クール全20話・約34万字をWebサイトとして公開するまでにやったことを、個人開発の実録として紹介します。
作ったもの — 小説「さくらコード」
「さくらコード」は、対話型の生成AIが世に出る直前の2022年春に、東京の中小IT企業へ入社した新卒エンジニア・望月桜子の物語です。手を動かして開発の基礎を覚えた1年目、生成AIが現場を一変させる2年目、AIプロダクトの責任者、そして起業へ。「AI時代に技術者は何に責任を持つのか」を、4クール・全62話の構想で描いています。
公開サイトはこちら。第1話から無料で読めます。
Xアカウントもあります。
現時点の数字はこうなっています。
構想: 4クール・全62話
Webで公開済み: 第1クール全20話・約34万字
下書きも含めた本文の総量: 約53万字
制作期間: 約3ヶ月
マージされたPR: 73本（作成ベースでは99本）
本文も、キャラクターのビジュアルも、各話の挿絵も、読むためのWebサイトも、すべてAIエージェントとの共同制作です。そして題材は「AIと働くエンジニアの物語」。AIと一緒に、AI時代の物語を作るというメタな構造になっています。
小説を「リポジトリで」開発する
制作の中身は、普段のソフトウェア開発とほとんど同じです。物語はGitHubのモノレポで管理しています。
sakura-code/
├─ apps/web/ # 読むためのNext.jsアプリ
├─ story/ # 世界観・人物・年表などの恒久設定
├─ episodes/ # 小説本文の正本（1話1ディレクトリ）
├─ adaptations/ # 四コマ・漫画・アニメ台本などの派生
└─ docs/ # 開発・運用・戦略ドキュメント
各話のディレクトリには、本文の script.md に加えて、構成案の outline.md と作業メモの notes.md を置きます。1話がソフトウェアでいう1モジュールです。
要になっているのが、仕様書にあたる「ストーリーバイブル」です。世界観、登場人物、プロット、年表、描写のルールを正本として文書化しておき、エージェントに執筆や修正を頼むときは必ずここを参照させます。62話の長編で一貫性を保てるかどうかは、文才ではなく「設定がどれだけ言語化されているか」で決まる。これは、曖昧な要望を仕様に落とせるかでAIコーディングの成果が決まるのと、まったく同じ構造でした。
品質はレビューと公開ゲートで守る
物語をほぼAIが書くとなると、問題は品質をどう担保するかです。ここでもソフトウェア開発の道具をそのまま持ち込みました。
まず、コードレビューにあたる「評価ガイド」を文書化しました。1話単位（その話だけで読めるか、感情の入口と出口が変わっているか）、クール単位（テーマが積み上がっているか）、全体単位（作品としてぶれていないか）という3階層のレビュー観点を決めておき、エージェント自身にこの観点でレビューさせます。「AIや技術で一発解決する展開になっていないか」のような、この作品ならではの観点も入っています。
次に、リリースゲートです。Webに公開する話は許可リストで明示的に管理し、公開前には検証スクリプトを必ず通します。未公開話の混入や内部向け文言の漏れを機械的にチェックするもので、CIでも同じ検証が走ります。初稿のまま勢いで公開してしまう事故を、仕組みで防いでいます。
さらに、公開する話は毎回リライトしています。初稿から公開までの間に、曜日や時系列の矛盾を直す指示、前後の話との連続性を直す指示をプロンプトとして書き起こし、それ自体もリポジトリに残しています。
開発フローも自動化する
Gitまわりの操作は、エージェントのhooksで自動化しました。セッションを開始するとブランチが自動で切られ、終了するとcommit・push・PR作成まで自動で走ります。人間の仕事は、上がってきたPRを読んで、マージするかどうかを判断することです。3ヶ月でPRは99本になりました。
面白かったのは、途中で話数の体系を変えたときです。最初はアニメの1クール12話を意識した全48話で書き始めたのですが、小説として必要な厚みを出すため、小説版は全62話の通し番号に再編しました。全ファイルの話数参照を更新するこの作業は、データベースのスキーマ移行そのもので、移行計画と監査ドキュメントを書いてエージェントに実行させました。長編の一貫性管理は、ソフトウェアの整合性管理と同じ問題です。
タイムラインの実録
初日: リポジトリを作成。最初のコミットはストーリーバイブル
3日目: 全4クール・48話ぶんの初稿が揃う
最初の2週間: Next.jsの読書サイトとキャラクタービジュアルを整備し、話数体系を再編
その後、約2ヶ月の中断
再開後の1週間: CI・公開検証・SEOを整備し、挿絵つきで1話ずつ公開。第1クール全20話に到達
正直に書くと、「全話の初稿が3日でできた」が一番の衝撃でした。ただし、そのまま出せるかというとまったく別の話です。初稿はたたき台としては十分な出来でしたが、突き詰めて読むと、時系列の矛盾、キャラのぶれ、都合のよい展開と、直したいところだらけでした。公開済みが第1クールの20話に留まっているのは、1話ずつ評価とリライトを通しているからです。生成は一瞬、品質は長期戦。これはコードでも物語でも変わりませんでした。
やってみて分かったこと
個人開発の題材はアプリに限らない。物語もリポジトリで「開発」できる
長編の一貫性は文才ではなく仕様化で決まる。ストーリーバイブルは仕様書そのもの
AIの出力の品質は、根性ではなく仕組みで守る。レビュー観点の文書化・公開ゲート・CIは創作でも効く
初稿の速さに惑わされない。たたき台は3日、公開品質は3ヶ月
人間に残る仕事はここでもWhat/Why。何を描くか、どこまで直すか、どの話を世に出すか
AIコーディングを続けてきて、「コードを書く」部分の景色はだいぶ変わりました。今回わかったのは、その変化はコードに限らないということです。仕様化・レビュー・ゲート・デプロイという開発の型は、作りたいものが物語でもそのまま通用しました。
あなたが個人開発でいつか作りたいものの中に、アプリ以外のものはありませんか。
関連記事はこちら。
https://note.com/hampen2929/n/nb4aca781776b
https://note.com/hampen2929/n/na7455bbfebb8
次回は、ネットスーパーの買い物をAIエージェントに任せて時短した話を書く予定です。AIコーディング×個人開発の実録を発信しているので、続きが気になる方はフォローしてもらえると嬉しいです。
