AIに小説を書かせて分かったAIの根本的な問題

Doui Lab

2026年5月14日 17:43

ここ最近1ヶ月ほどかけて、AIを使った小説執筆に挑戦してみました。まだ継続中ですが、中間的な報告をしたいと思います。
ちなみに執筆中の小説はこちら。

https://ncode.syosetu.com/n1996mc/

理想的な世界

最初に、この取り組みのゴールとしては下記のような状態を想定しています。

自分が読みたい内容をフワッと伝えるとちゃんとした小説ができあがる
自分の想定している展開とは違う形で面白いストーリーを味わえる
気に入らない展開なら指示すれば修正してくれる
漫画やアニメ、ドラマなどの他のメディアでも楽しめる

こんな世界になると良いですよね。ハズレアニメのない世界と言えるかもです。

シンプルLLMの限界

ただ単にChatGPTに「こういう内容で小説を書いて」とお願いするとどうなるでしょうか。ある程度は書いてくれます。ただ、100pや10巻にもなるような長大な小説を書き上げるのは基本的に無理です。出力するトークン数に対する限界もあれば、その長さで整合性を保ちながら出力することが難しいからです。

一方で、実は同じ分量のプログラムなら場合によっては出力することができます。なぜかというと、プログラムは基本的に機能が分離されており、LLMはそれらの機能をただ仕様書に基づいて実装すればいいだけだからです。
人間のプログラマーであっても「これが何に使われるのか分からない」状態であっても、インプットとアウトプット、条件さえ分かれば機能を実装できますし、後からテストもできるんです。

ただ小説はそういうわけにはいきません。冒頭で触れられていた伏線を回収したり、序盤で話したことについて言及したりします。そもそも前後関係に連続性がないといけません。プログラムとは違います。そのため、例えば1章ずつ出力させていくと、2章で書いたことが1章の前提を踏まえていない、ということが起きてしまいます。2章を書くときには、適切な条件を与えて執筆しないと、小説として成り立たないのでｓ。

ということで、どうやって1章ずつ書いて貰う場合に適切な条件を与えられるのかを中心に執筆方法を構成しました。

執筆方法

ここからは実際の執筆方法について説明していきます。ツールとしてはCodexを使用しています。別にClaudeでも何でも良いとは思いますが、CLIにした方が良いです。生成物を管理する上でもCLIの方が楽です。

ディレクトリ構成

Codexは下記のようなフォルダ構成で使用しています。当初は全然違うフォルダ構成だったのと、今後も変わるかもしれませんが現状としては下記のようになっています。

assets : 画像を格納する。漫画は別のフォルダ。
- character_images : 登場キャラクターのイメージ画像
- covers : 掲載時などに使用する想定の画像。ほぼ使ってない。
docs : 設定資料集
- codex_rules : Codexを実行する上でのルール集。
- publishing : 投稿時の注意やガイドをまとめる
- story_bible : ストーリーに関する設定資料
  - world.md : 世界設定の概要
  - world_details.md : 魔法や世界の謎などに関する概要（約1300行）
  - story_overall.md : ストーリーの章構成など大まかな内容（約800行）
  - story_details.md : 各巻・章でどのような話を書くか（約1200行）
  - characters : 各キャラクターに関する設定資料
    - core_cast.md : メインとなる登場人物（5人＋5人）
    - enemy_faction.md : 敵キャラ
    - guest_cast_and_legends.md : 過去の神話などの登場人物
    - individual : 各キャラクターの設定資料をそれぞれの配置（ひとりあたり100〜200行）
- locations : 各土地・村などに関する設定資料
- music : 作中で扱う曲に関する資料。湊のギター上達計画などもここ
- plot : 実際の小説のプロット
  - volume01 : 1巻の内容
    - 0x_title.md : 各章ごとに3話ずつプロットを書く
manuscript : 実際の原稿
- volume01 : 1巻の原稿
  - continuity : 執筆時に確認する各章の状態確認ファイルの格納場所
  - 0x_title.md : 実際の原稿
manuscript_en : 英語の原稿
output : その他成果物置き場
scripts : その他必要となるプログラムの置き場

プロジェクト全体はGit管理されているので、.gitignoreや.envなども配置してあります。最初はこんなにファイルはありませんでしたが、執筆していくうちにこれぐらいの整理をしないと精度が極端に下がることが分かっています。

AGENTS.mdについて

AGENTS.mdにルールを書いておけば、Codexもそれを守ってくれる、となりがちなんですが、特に小説の場合はこれがめちゃくちゃ肥大化します。例えば執筆時に注意することと推敲時に注意すること、会話文での注意点や時系列に関する注意など上げればキリがなく、肥大化していくに従って生成精度が極端に低くなりました。

そのため、docs/codex_rules にルールについてまとめています。AGENTS.mdには下記のように記述しています。

- 改行、会話、視点認知、固有用語の扱いは `docs/codex_rules/` の該当ファイルに従う。
- 再発しやすい指摘を受けたら、`AGENTS.md` を肥大化させず、該当する `docs/codex_rules/` のファイルへ統合する。

こうすることで、会話に関する執筆・推敲時には会話部分のルールを確認（プロンプトへ追加）して生成するので、精度が高まります。

執筆時のルール

執筆は下記のように執筆内容をブレイクダウンして行います。

story_overall.md を生成・編集します。各巻や各章でどのような話を記述するのかを生成させます。生成物を確認して、問題無ければ次に進みますし、「もっとこういう展開が欲しい」などがあれば指摘して再生成させます。
story_details.md を生成・編集します。各話ごとにどのようなことを記述するのか整理します。ただ、今はplotがメインなのであまりこれを使っていません。
plot に詳細な記述計画を出力させます。まず、これがあって、次にこれをして、それからこれをする、みたいに全部出力させます。気に入らなければ指摘するか、自分で書き足します。
manuscript に原稿を出力させます。基本は1章ずつですが、とりあえず1巻分まるごと、みたいなこともやります。（どうせあとで変更しますが）
本文を読んでみて、適宜指摘・修正します。基本的に一部のカットや修正ぐらいなら自分で修正しますが、大幅なプロット変更の場合はplotからやり直して再生成させます。

ウォーターフォール的にこのような書き方をしましたが、実際には上流工程に戻りまくります。「このキャラ、やっぱここで出した方が良くない？」「ここでこんな感じの展開がいいんだけど、世界設定変えて貰って良い？」みたいな感じでかなりアジャイルです。

こんなに多段構成にしなくとも、例えば世界設定だけで原稿を出力させても、そこそこ上手く行きます。短編小説とかなら十分かもしれません。ただ、原稿が進むにつれて破綻していきます。「1章のあそこではこう言っていたのに、ここで違うこと言ってる」とか「このキャラ、あのときあんなこと言ったのに忘れてる」とかです。
これはもうしょうがないです。LLMは前の話なんて知らないんです。プロンプトに入れられていない話は知りようがありません。前の章を書いたのは自分であって自分でない、という感じです。なので悪気はないのです。
執筆する章より以前の全ての話をプロンプトに入れられないですし、入れたところで精度は確保できないでしょう。そのため、こういうブレイクダウンしていく方式を採っています。
もしかしたら将来的にはこのあたりも解消するかもしれませんが、現時点では不可能です。

Continuityの作成

先ほどのフォルダ構成にありましたが、執筆時の状態を保存する目的でContinuityのファイルを作成しています。これには、例えば4章を執筆する場合は4章より前がどういう状態なのかをざっくり書いてあります。
もちろん、plotに従えば状態の整合性を取れるはずなんですが、実際には細かいところでミスが目立つようになります。

例えばですが、異世界転生したとき異世界は朝だったはずなのに、いつの間にか夜になっていた、とかです。また、ここにいないはずのキャラが突然喋った、なんかもあります。怪我して倒れていたはずなのに、普通に走ってるとかもあります。
そこで、Continuityファイルを作って、時間・場所・同行者・キャラの状態を記述しています。加えて、読者がここまでで知っている情報も記述しています。世界設定にある専門用語をいきなり使ったりしないようにです。こうしたContinuityファイルを作ることで小説としての連続性を保っています。

それでもエラーは多い

さて、ここまでやってもかなりミスが目立ちます。一発で合格となるような文章はほぼ出てきません。よくあるミスとしては

発話がいきなりため口になる
発話が単語だけになる
同じ話をする
良く分からない表現をする

このあたりです。これはいくらルールとして指摘しても、絶対に再現します。何故かは分かりません。
よくあるのが、キャラの発話が極端に単語調になる現象です。
「湊、行け」
「はい」
「そうだ」
「でも」
「なんだ」
みたいな感じです。なぜか長い発話が生成されません。基本的に短文で省エネ執筆しようとするみたいです。トークン節約ですかね。

同じ話を繰り返すのもあります。plotの方法でかなり減りました、それでもたまに「その会話前にも話してたが？」みたいなときがあります。

そしていつまでも直らないのが「よく分からない表現」です。
「その音は2人の間に落ちた」
とか、こういう表現が頻発します。恐らくですが、英語表現の直訳とかなのでしょうか。あんまり日本語にはない表現が頻発します。
もちろん、この手の表現があった方が小説としては豊かになりますが、これが頻発すると読んでいて意味がわからなくなってきます。
これは指摘しても全然直りません。

そもそもつまらない

plotを読んだ段階だとは面白そうだったのに、実際の小説は単調に進んでしまってつまらない、というのもよくあります。
単純な事実だけを追っていて、メリハリがなく盛り上がりにもかける、という感じです。
「湊は倒れた。そして言った。そして弾いた」
といった感じです。全然盛り上がりません。
こういうときに「ここの展開、もっと盛り上げて！」と言っても大して盛り上がりません。もっと引っ張ればいいのに、とか、逆にいきなり開示すればいいのに、とかです。
で、こういう指示をするぐらいなら、自分で書いた方が早いです。

自分で推敲する

ということで、この手のミスに対して、あまりにも多い場合はCodexに変更を指示しますが、たいていの場合は上手く行きません。逆に悪化する場合もあります。
そのため、ほとんどの場合は自分で直します。
特に台詞に関しては自分で書いてしまう方が早かったりしますし、必要無いと思った場合はバッサリカットしてから再生成させます。

つまり、基本的にそれなりに小説を読んだり書いたりできないと、AIを使って小説を書くのは難しいんじゃないか、ということです。私は小説を書けるわけではありませんが、まだ文章なら書けます。
ところが小学生なんかが理想の話を出力させようとしても上手く行かないでしょうし、どうやって直せば良いのかも分からないと思います。プログラミングなどに関してもそうですが、ある程度自分ができる範囲じゃないとAIに任せることは難しいということです。

ということで、まぁタイトル詐欺ではあるんですが、AIの根本的な問題としては「自分の能力を越えたような出力は出来ない」になります。よく言われていることですね。

AIを使うことによる利点

ネガティブな要素も多いですが、AIによる利点も当然多々あります。

書き直しが楽

小説本文の書き直しが圧倒的に楽です。例えば、ある程度まで話が進んだけれど、「これ、展開が遅すぎるから、もっと早くこの展開に持っていきたい」となった場合、LLMにそれを指示すれば簡単にやってくれます。
実際に、今の1巻（10章）の内容は2巻（20章）かけて進める予定だったんですが、実際に出来上がった小説を読んでみたら中だるみしていてつまらなかったので、「1巻10章分にまとめて」という感じで依頼しました。結局は修正にも時間がかかりましたが、思ったよりは早く軌道修正できたおと思います。

世界設定の変更が楽

当初は音楽に関する設定はほとんど無かったんですが、「これ、異世界で使われている曲が現実世界の曲だったら面白くね？」と思って、それを依頼して世界設定から大幅に変更してもらっています。
また、AIが出してきた案などに対しても「それってどういうこと？」みたいに質問することで深掘りして、逆にこちら側から提案することで世界設定を練っていく、みたいなことができます。
「とりあえず、三すくみの状態を作ってゲームっぽくしたい」
なども伝えると適宜設定に取り込んでくれます。
このあたりの具体例は、かなりネタバレになるので、一応伏せておきます。

キャラの掘り下げに頭を使わない

ちょっとだけ出てくるキャラとかの背景設定なんかもAIならガンガン生成してくれます。こういうのを自分で考え出すと完全に横道に逸れて時間がかかりますし、かといって話に取り込んでいくと読者がついていけなくなります。
ほとんど設定を作らないのもアリですが、ある程度設定を持たせることでキャラに厚みが出る、と思っています。このあたりはもうちょっとLLMを活かしていきたい分野です。

GitHubを使った効率化

余談ですが、これらの修正は基本的にGit管理のもと行います。執筆内容が固まったらcommitして、修正を未commitとすることで修正部分の把握が楽になります。
また、PRによる編集も実施しました。例えば7章を執筆するときは下記の手順になります。

7章用のブランチを作成する（ codex/chapter-7 など）
ブランチに対して7章の内容を追加する
GitHubにPushしてPull Request（PR）を作成する
PRの差分を確認しながら気になるところにコメントを入れる
Codexにコメントを拾わせて修正させる

このようにすることで、差分がはっきり分かるのと、スマホやタブレットなんかでも確認出来るようになります。なので、ざっと出力させて出先でチェックなんかもしていました。
CodexにはGitHubと連携する機能もあるので、そのあたりを使えばPR作成やコメント反映なども楽に行えます。アカウントを分けることでまるで執筆者と編集者、というような形で執筆が可能です。執筆が終わったら commit/push しておいて、と指示しておけば勝手にやってくれますし、定期実行の機能を使えば定期的にコメントを拾って修正、なんかもできると思います。（まだそこまではやっていません）

Codexによる漫画化

せっかくAIを使ってるので、漫画化もしてもらうことにしました。これも結構試行錯誤しましたが、結果的にはネームを作成してもらって、それからページ単位で出力させるのが良さそうでした。とりあえず最初の1章だけ漫画にしてもらいました。

まずネームの出力です。これは章単位でネームを作成した方が良いと思います。そうしないと、原稿と同じで各ページ間の整合性が取れずに破綻しますし、何よりページ数分の画像生成しているとトークンがいくらあっても足りません。
注意点ですが、普通に生成させると文字が横書きになる関係から、コマ割りが左から右になります。日本の漫画になれている人は右から左へのコマ割りを指示してください。ただ、生成は結構その部分をミスします。

また、全体としてネームは作って貰いましたが、最初の1ページと見開きでのタイトルページなんかは独立して生成させました。このぐらいなら問題無いんですよね。

こんな感じです。後半に全部載せておきます。まぁ、そこそこ上手く行きます。
ただ、台詞やナレーションについては壊滅的でした。小説では記述しているがナレーションとしては不適切な部分であるとか、逆に小説に記述していないが、ナレーションが必要な部分、カットして良い部分などの取捨選択がダメです。かなり指示して、最終的にはそこそこにはなりましたが、これを全章でやるとなると大変そうです。
また、サーフして前に行ってるはずなのに横に落ちてるのも矛盾してたり、そもそもBABYMETALなのに2人はギター持ってたりします。最後に進んで行く方向も変ですね。
このあたりをちゃんと生成するには台本のような形に変換して、それからネーム化、漫画化というステップを踏む必要がある気がします。
またいつかチャレンジしてみます。