Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

制作の舞台裏

馬場祐平です。

このページでは、制作の過程で起きたことを、思い出せる範囲で書いています。

プロジェクトの動機は①なぜ作ったかに書いています。こちらは、具体的にどうやって作ったか、という話です。参考になる先例がなかったため、ゼロから手探りしたプロセスをそのまま書いています。この記録が、これからAIで小説を書こうとする人の失敗回避に役立てれば、と思っています。

「日本初」の根拠については、次ページ③AIを使った長編小説の現在地にまとめました。

このページで読めること

最初の発見：「AIはセリフが苦手」

2月4日、3回目のMTG。共同制作者のK氏に最初の原稿を見せると、こんな反応でした。

K氏： キャラクターが動いてないですよね。説明している感じ。特にセリフが弱くて、誰が喋っても同じ声に聞こえる。

馬場： セリフですか。

K氏： AIってセリフが苦手なんですよね。状況説明はできるけど、「この人らしさ」が出ない。たぶんキャラクターの設定が薄いから。

「なるほど、そういうことか」と思いました。AIに「面白いキャラクター」を出力させようとしても、そのキャラクターが何者なのかをAIが分かっていなければ、誰でも言いそうなセリフしか出てこない。

そこから、各キャラクターに「OS（行動原理）」を定義することを考え始めました。翼はなぜあのように行動するのか。佐伯はどこから来て、何に傷ついてきたのか。その内部ロジックを言語化することで、「この人ならこう言うはず」をAIが推測できるようになります。

この発想が、settings/characters.mdにつながっています。

SPMモデルの原型誕生

2月12日のMTGは、プロジェクトの中でいちばん重要な検証の日でした。

この頃、設定の作り方について根本的な問題にぶつかっていました。設定を細かく書きすぎると、AIが形式を再現することに縛られて、表現が硬直する。かといって設定を緩くすると、AIは前のセッションの記憶を引き継がず、プロットが静かに崩壊する。「どこまで縛って、どこまで自由にさせるか」——その匙加減が全然掴めていませんでした。

K氏との会話の中で、これが整理されていきました。

K氏： v3もv4も、正直どっちも……「小説」じゃなくて「あらすじ」のレベル感ですよね。

馬場： v4で何が起きてたんですか？

K氏： 2話目からキャラクターが設定と全然違う動きをしてて、6話以降は完全に別の話になってました。プロットが崩壊してる。

K氏： キャラクターの行動原理と背景を最小限でシンプルに書いて、でも背景情報とは詳細に紐付ける。制約じゃなくて、「なぜそう動くか」の根拠を与える感じで。

この会話から「OSと形成背景を切り離さない」という設計原則が生まれました。制約を与えるのではなく、なぜそう動くのかの根拠を埋め込む。これが、後のSPMモデルにおけるSettings層の設計思想につながっています。

プログラマーの世界に、MVC（Model-View-Controller）というアーキテクチャーパターンがあります。Modelがデータの管理を担い、ViewとControllerがそれを使って最終プロダクトを生み出す——そういう役割分担のモデルです。このプロジェクトのSPMモデルは、MVCの概念にヒントを得て設計しました。ただし小説の場合、データ駆動型のパイプラインであり、厳密にはMVCとは構造が異なります。設定（Settings）という静的なデータから、プロット（Plots）という中間生成物を経て、最終的な原稿（Manuscripts）が生成される——という流れです。

一気生成の失敗と、シーン単位での解決策

同じ2月12日のMTGで、もう一つの問題が浮かんできました。

AIをある程度自由にさせて原稿を書かせると、一気に1万字・2万字を生成しようとするんです。問題は、量が増えるほど内容が薄くなること。全体の緊張感が落ちて、ふわっとした文章が続くようになる。そこからK氏と話し合い、シーン単位での執筆に切り替えることにしました。

K氏： AIが一度に処理できる限界として、1シーンあたり2,000〜3,000字くらいで区切りながら出力させるのが現実的だと思います。Web小説の一話分に相当する分量で、この単位で起承転結を構成させれば完結感が出る。

馬場： それを複数シーン繋げていく。

K氏： グローバルなプロットのどこに当たるかをシーン単位で明示しておかないと、AIはセクションごとに独立した話を書いてしまう。「このシーンは物語全体の『転』に当たる」という位置情報が鍵です。

この気づきから、プロットサマリーには「ビート（転換点）」や「PDCA層」という位置情報が明記されるようになっています。

プロジェクト原則の確立

AIを活用した創作方法が固まるにつれて、ルールとしての原則が必要になりました。そのファイルを別途作成し、プロジェクトプリンシプルとして明記しました。

毎日改稿を繰り返すにつれて、このプロジェクトプリンシプルはどんどん厚くなっていきました。同時に、毎バージョンの開始前には計画ファイルを作り、終了後には振り返りレポートを出す。このサイクルを通じて、バージョンを上げるごとに創作方法を磨き続ける。こうした方法を「プロジェクトプリンシプル」内で言語化することで、同じ失敗を繰り返さないためのアンチパターン、AIへの指示の出し方、品質の判定基準——こうした知見がすべて1つのファイルに束ねられ、バージョンをまたいで蓄積されていきました。

2月13日、ターニングポイント

2月13日のMTGで、K氏が初めて「商業レベル」という言葉を使いました。

この日は物語の構造を大きく変えた日です。主要な登場人物に、それぞれ私生活のサブストーリーを走らせること。仕事での変容と個人的な変容が相関する構造にすること。「嫌なやつ」に見えていた主人公に、過去のトラウマを通じた人間的なドラマを埋め込むこと——これらが一気に決まりました。

K氏： 今日の話はかなり大きかったと思います。ストーリーのクオリティが一段階上がった気がします。

その夜から、設定ファイルの大幅な書き直しを始めました。ここから後半戦です。

第2部以降は、K氏との壁打ちがさらに重要になっていきました。登場人物を増やして絡み合いを作り、第3部では絶望とそこからの復帰という物語設計が加わる。プロの小説家がいなければ、ここまでのストーリー設計はできなかったと思っています。

「文章のうまさはもういらない」

先にお伝えした通り、プロの小説家でもあるK氏が、あるセッションでこう言いました。

「文章のうまさはもういらない、と思い始めています。」

この経緯については繰り返しませんが、この言葉を彼が口にするまでには、相当の葛藤があったと僕は思っています。

K氏は、プロの小説家として、小説家界隈ではAIがネガティブに見られているケースが多い、と教えてくれました。AIで濫造された小説が投稿されたり、密かにAIで書いたことがバレて問題が起こったりしたケースがあったそうです（門外漢の僕はまったく知らなかったのですが）。

確かに、人生をかけて本気で手と頭を動かしながら一語ずつ物語を書いてきた人が、突然現れたAIによる小説を、そう簡単にポジティブに受け入れにくいのは分かる気がします。

ただ、エンジニアの世界ではそうした変化がすでに起こっています。世界中のテックカンパニーの代表や、技術リーダーが、「トップエンジニアは一行もコードを書かない」と公然と話すようになりました。プログラマがコードを書かない世界が、ついに現実のものとなり、もうその流れは止めることはできない、と一般的に思われています。

彼らはこれまでの人生ずっと、コードを書き続けることに誇りと喜びを持っていた人たちです。そこから離れる悲しさのようなものも、少なからずあったと思います。僕自身も、その末端の一人だったので、その感覚は想像できます。

でも、「良いものを作りたい」と本気で思っているエンジニアほど、「方法は手段である」と割り切って、感傷に流されることなく、良いものを創り出すためにあらゆるツールを活用しているように見えます。

一昔前は「小説は手書きじゃないと」と言われていた時代もありました。でも、今では若い人がスマホでサクサク小説を書くのが当たり前だと思います。AIも、そうしたツールの一つだと割り切れば、小説執筆においても味方に見えてくるのではないでしょうか。

しかも、この変化はまだ「始まりに過ぎない」のです。AIを活用して、たくさんの人が、よりおもしろい小説を書くことができるようになる。そんな世界の到来を、一人の実験者として行っている喜びを強く感じながら、日々創作し続けていました。

Gemini議事録ループという仕組み

本ページの最後に、この共創プロジェクトで欠かせなかった、AIを活用したワークフローをお伝えします。

MTG（Google Meet）
  ↓ Gemini が自動で文字起こし＋要約
議事録（Markdown）
  ↓ Claude に投入
設計ファイル更新 → 改稿

すべてのMTGをGoogle MeetでGeminiに録音させています。会議が終わると即座に自動で議事録が生成される。その議事録を次のAIセッション（Claude）に投入することで、「今日の議論の結果」を設計ファイルに反映する方法を即座にAIが提案してくれます。それにフィードバックを与えて修正し、実行ボタンを押して数時間待てば、20万字の長編小説の全文が一気に推敲されるのです。

普通なら、MTGで話したことがドキュメントに落とし込まれるまで数日かかります。でもこの仕組みだと、早ければその日に改稿が終わっています。

分かりやすい例が3月2日のMTGです。初めて部外者に読んでもらい、フィードバックをもらいました。その議事録をその日に投入し、翌3月3日にv23として完成しています。

そして、実はこのページ自体も、MTGの議事録をAIが要約・再構成して書いています。「AIが書いた、AIを使った小説の制作記録」というわけです。