数万字にも及ぶ、血の通った詳細な【プロット資料】。

執筆（実装）フェーズにおける唯一絶対の憲法であり、物語の全てが記された「設計図」が、ついに完成しました。

しかし、実装を始める前にもう一つ、用意すべき武器があります。

それは、完成品の品質を統一するための【執筆ガイドライン】、いわば「製造マニュアル」です。

そして、このガイドラインは、作者の好みだけで作るものではありません。

【Deep Researchで鍛え上げる「勝利のための文体」】

私はまず、Deep Researchを使い、ターゲットとする読者が集まるプラットフォーム（私の場合はカクヨム）と、執筆するジャンルで成功を収めている多数の作品を徹底的に分析させます。

・読者が最もストレスなく読める、スマホ画面での最適な段落の長さは？

・地の文と会話文の理想的な比率は？

・読者の没入感を高めるための、効果的な改行のタイミングは？

・プラットフォームで標準的に使われているルビの記法は？

DeepResearchは、これらの問いに対して、データに基づいた最適解を提示してくれます。この分析結果を元に、私は自らの作品のための、データドリブンな執筆ガイドラインを構築するのです。

これは、感覚ではなく、論理で「読みやすさ」を追求する、まさにエンジニアリング的なアプローチです。

さて、これで作戦に必要な二つの武器、「プロット」と「ガイドライン」が揃いました。

いよいよ、物語に命を吹き込む「実装」のフェーズです。

【執筆は「指示」と「修正」の黄金サイクル】

私の執筆プロセスは、全50話であれば50回繰り返される、非常に単純なサイクルで構成されています。

最近流行りのプログラミングスタイルである「バイブコーディング（Vibe Coding）」という言葉をご存じでしょうか。厳密な仕様書を一行ずつコードに落とすのではなく、AIに「こんな感じでよろしく」と雰囲気（Vibe）で実装させ、いい感じなら採用し、ズレていれば修正していく手法です。

まさに、私たちの執筆（実装）は、これに近い感覚で行われます。

ステップ1：AIへの執筆指示

まず、Geminiにこう指示を出します。

これから小説の第〇話を執筆します。

以下の二つの資料をインプットとして、最高の文章を出力してください。

#インプット1：プロット資料（全体資料と、第〇話 抜粋）

（ここで、プロット全体資料――キャラ設定、世界設定などと、該当話数に書き込んだプロット――あらすじ、展開、心理描写、監督指示などを全て貼り付けます）

#インプット2：執筆ガイドライン

（ここで、先ほどDeepResearchで作成したフォーマットのルールを貼り付けます）

ここで最も重要なポイントは、毎回「その話のプロットだけを抜粋して貼り付ける」ことです。数万字のプロット全文を読み込ませると、AIは解釈を間違えたり、文脈を忘れたりする「プロット違反バグ」を頻発させます。AIに「今、集中すべきはここだ」と明確に示すことで、このバグは劇的に軽減します。

ステップ2：人間によるレビューと「デバッグ（修正）」

AIは、指示に極めて忠実な初稿を出力してくれます。プロットが詳細なので、物語が破綻することは基本的にありません。

しかし、これはあくまで「完璧な素材」です。おそらく、満足するレベルのものにはなっていないでしょう。

ここからが、監督である私たちにとって、最も時間のかかる、そして最も重要な「デバッグ（修正）作業」の始まりです。

Geminiは驚異的に優秀ですが、彼（彼女？）には特有の「クセ」、すなわち修正必須の「バグ」が存在します。私がこれまでの執筆で頻繁に遭遇してきた代表的なバグと、その具体的な修正方法をご紹介しましょう。

バグ1：否定強調バグ

・AIの出力例：

彼の表情は、喜びではなかった。それは、深い悲しみだった。

・何が問題か：

回りくどく、学術論文のような印象を与えます。物語のテンポを著しく損ない、感情のインパクトを弱めてしまいます。「喜びではない」と一度思考を中断させるため、読者がキャラクターの感情に没入するのを妨げます。

・修正後：

彼の表情に、深い悲しみの色が浮かんだ。

（修正方針：より直接的で、情景が目に浮かぶような表現に書き換える）

バグ2：説明描写バグ（「語るな、見せろ」違反）

・AIの出力例：

彼女は彼の言葉に怒りを感じたので、部屋を出て行った。

・何が問題か：

キャラクターの感情を「怒り」という言葉で説明してしまっています。これは小説作法における最大の禁忌の一つ、「語るな、見せろ（Show, don't tell）」の原則に違反しています。読者は「彼女は怒ったんだな」と理解はできますが、その怒りを肌で感じることはできません。

・修正後：

彼女は奥歯をぐっと噛み締めると、何も言わずに椅子を蹴立て、乱暴に扉を開けて出て行った。

（修正方針：感情そのものではなく、感情によって引き起こされる「行動」や「表情」「仕草」を描写することで、読者に感情を推測させ、共感させる）

バグ3：メタ表現バグ

・AIの出力例：

彼が何気なく手にしたその古いコインは、後の展開で重要な役割を果たすことになるのだが、この時の彼は知る由もなかった。

・何が問題か：

物語の世界（フィクション）と、作者のいる現実世界（メタ）の境界線を破壊してしまっています。これは「天の声」や「ナレーション」に近く、読者の没入感を一瞬で破壊します。物語の登場人物ではなく、作者が読者に向かって「これは伏線ですよ」と解説しているようなもので、物語が安っぽく感じられてしまいます。

・修正後：

彼は、指先に触れた冷たい感触に、ふと足を止めた。道端に落ちていたのは、見慣れない紋様が刻まれた古いコインだった。彼は特に理由もなく、それを懐にしまい込んだ。

（修正方針：作者の解説を完全に削除し、キャラクターの行動として淡々と描写する。そのアイテムが重要かどうかは、後の展開で読者自身が気づくべき）

バグ4：継続性・整合性バグ

長編になればなるほど、AIは前の文脈を忘れてしまいがちです。

・キャラクターの口調変化：丁寧な口調だったはずのキャラクターが、突然友人相手のように馴れ馴れしく話始める。

・設定の矛盾：「魔法が使えない」という設定のキャラクターが、戦闘シーンで平然と魔法を使い始める。

これらのバグは、詳細なプロットとキャラクターシートをAIが読み飛ばすことで発生します。執筆前の指示で該当箇所のプロットを抜粋して貼り付けることで軽減はできますが、完全には防げません。最終的には、作者が「このキャラはこんなこと言わない」と、手動で修正する必要があります。

正直に言って、この修正作業は、かなり時間がかかります。しんどい作業です。

しかし、断言できます。

この全ての苦労を含めてもなお、ゼロから1話ずつ自分の手で執筆するより、圧倒的に速いのです。

私たちは、物語を「生み出す」という最も創造的な苦しみに集中し、文章を「整える」という作業的、しかし重要な苦しみをAIに肩代わりさせている。そう考えるのが、最も事実に近いのかもしれません。

さて、全話の原稿が完成したら、いよいよ最終工程です。

作品を読者の元へ届けるための、最後の品質保証。

次回は【校正】、ソフトウェア開発で言うところの最終「テスト」についてお話しします。