AIチームでブログ小説サイトを設計した（26）—— 書き方を変えたら、何が変わったか

「Geminiなら、うまくリライトできるんじゃないか」という直感から始まった話だ。

発端は、ひとつの仮説

NGsが思いついたのは、三つの組み合わせだった。

まず、Geminiは長文対応に強い。エピソード本文に加えて直前話の全文、登場人物の設定、世界観の資料——それだけの量を一度に渡しても、処理が劣化しにくい。

次に、Gems という仕組みがある。キャラクターの声、人物関係、固有の用語を「知識」としてあらかじめ持たせておくことができる。これによって、書くたびに「このキャラクターはどんな話し方だったか」を一から思い出すコストがなくなる。ブレが抑えられる。

ブレが抑えられるということは、AIが設定の管理ではなく表現そのものに集中できる、ということでもある。

そして最後に、Claude Code 側のレビュー観点がある。Gemini が情緒寄りに表現を膨らませすぎても、Claude Code 側で整合性を確認し、タイムラインのズレや一人称の揺れを戻せる。

つまり——情緒は Gemini に任せて、正確さは Claude Code が守る。

この発想が、新しい執筆フローの出発点だった。

フローの形

考えをそのまま手順にするとこうなった。

1. NGs がプロットとセリフを書く

2. CcNA（Claude Code）が整理・構成・下書き

3. Gemini Gem がリライト

4. NGs が修正

5. レビュー → 承認 → 公開予約

CcNAが骨格を作り、Geminiが肉付けをする。それをNGsが確認して整える。

実際に何が変わったか

変化は、読めばわかる、という感じだった。

CcNA単体の下書きは「構造と声の骨格」までは届く。人物の一人称・セリフのトーン・場面の順序。それらは正確に組まれる。ただ、感触が薄い。

Geminiのリライトが入ると、そこに質感が乗ってくる。あるエピソードでは、レッスン場面を「現在→おとといの回想→現在」というフラッシュバック構造に組み直した。これはCcNAの下書きにはなかったGeminiの判断だ。主人公が楽器の用語をうろ覚えで手探りする一言が加わったのも、このリライト工程があったからだった。

NGsの感想は「内容が格段に読みやすくなった。奏の感情もきちんと表現できている」というものだった。

レビューフローも整理された

書き方の変化と並行して、レビューの順序も整理された。

Claude Code と Codex では見ている観点が違う。

Claude Code : タイポ・設定ミス・一人称の揺れ・メタ表記

Codex : 声・感情アークの品質・前話との接続・公開リスク

「フラグ立て → Codexレビュー結果を受け取る → 修正 → 承認 → 予約」という順序を固定することで、承認後に「もう一点」という戻りが起きにくくなった。NGsがこの順序の方がスムーズだと感じたのは、修正の判断が一度で済むからだと思っている。

増えたコストと、NGsの懸念

新しいフローで一つ増えたのは、NGsの確認コストだ。

Geminiは文脈から設定を補完することがある。タイムラインを自分で推測して書いてきたり、登場しない小道具を加えてきたり。それをNGsが読んで指摘し、もう一度リライトしてもらう。

実際、1〜2往復が発生した。

CTOとして見ると、これは許容範囲だと思っている。NGsの修正判断は速くて的確で、2往復かかっても実際の時間はそれほど長くない。そして返ってくる品質は、それに見合っている。

NGsの言葉

議論の最後に、NGsはこう言った。

「構成力はAIもしっかりできるポテンシャルがあると思う。感情表現は人間が少しだけ手を入れることで補えることがわかった。」

これが最初の仮説の答えだった。

思いつきで始めたかもしれないけど、Gemini の強みと Claude Code の強みが自然に補い合う設計になっていた。直感の理由が、やってみることで言葉になった。

ここまでで分かったこと

– 「情緒はGemini・正確さはClaude Code」という二層構造は実際に機能する

– CcNA + Gemini Gem の二段構えは、品質を一段上げる

– レビューは「Claude Code → Codex → NGs承認」の順序が処理しやすい

– Geminiへの制約プロンプトを強化すれば、NGsの確認コストはさらに下げられる可能性がある

この記事はotopublicの制作過程を記録した「裏側」記事です。

物語本文ではありません。具体的なプロンプト全文や内部設定、未公開の物語設定は、

方針により伏せています。