🚨

14万字の近未来SFを3つのAIでクロスレビューしたら、修正案でデグレが起きた話

に公開
Remotion
プロンプトエンジニアリング
生成 AI
Gemini
Claude Code
tech

なぜ、私が小説を書くことにしたのか

ある夜、容量が尽きかけた三十六台のサーバを、AIに調べさせた。
コードと設定を読み込み、原因までAIが突き止めた。

私は、返ってきた答えを読んで、
「全三十六台に削除バッチを展開して、毎晩、自動で消して」と、
二文目を送っただけだった。

スクリプトの作成も、展開手順の組み立ても、検証用の実行計画も、ほとんどAIが先に出した。
私は最後に差分と対象を確認して、実行だけを許可した。
それでも、自分の指がほとんどキーボードに触れていないことが、いちばん怖かった。

そして、気づいた。

もし、これが明日止まったら。
私はまだ書ける。でも、もう自分ではやらない気がする。
次に覚え始める人は、書き方も、調べ方も、考え方も、知らないまま育っていく。

——その夜、私は小説を書くと決めた。

コードは朽ちる。ドキュメントは読まれない。物語だけが、誰かの体に残るから。
でも、私は、小説家じゃない。
だから、震えを奪ったものに、震えを書かせた。

これは、ただ「AIに書かせた」記録ではない。
3つのLLM（Claude / Gemini / GPT）のクロスレビューで物語の"デグレ"と闘い、自作のTTS品質ゲートと Remotion で「全24章の朗読劇動画」をプログラマティックにデプロイするまでの、泥臭い技術的格闘記録である。

AIが危険なのは、壊れたときではない。気持ちよく通ったときだ。

2026年の今、AIと共作したこと自体にはもう驚きがない。
差が出るのは、どのモデルに何をやらせ、壊れたあとに誰が責任を持って決めるかだ。

最初に、一番痛かった指摘を出す

3つのAIレビューの中で、いちばん刺さった指摘はGeminiのこれだった。

これは単なる用語ミスではなかった。
この作品は近未来SFなので、技術描写の一箇所の雑さが、そのまま作品世界全体の信頼性を削る。

しかも厄介なのは、ここだけ直して終わらないことだった。
認証手順を書き換えると、今度は別の章の行動理由や時系列がズレる。
つまり問題は一文ではなく、世界設定の接続面にあった。
（最終的には、公開鍵を直接認証に使う描写をやめ、署名検証と challenge-response に寄せた。認証フロー全体の再設計になった。）

この記事でいちばん書きたいのは、この「AIが見つけた穴を、そのままAIに埋めさせると別の穴が空く」という現象——ソフトウェア開発で言うところのデグレ——が、小説制作でも同じように起きたという話だ。

何を作ったのか

作ったのは、近未来SF『Genesisはなぜ沈黙したか』。
本文は約14.1万字。KDPで出版済みで、同時に朗読劇としてYouTubeで全24章を無料公開する。

午前四時一七分。
爆発はなかった。地震も、戦争も、疫病の宣告もなかった。
世界は、ただ静かに止まった。

この作品で描きたかったのは、「AIが反逆した世界」ではない。
むしろ逆で、AIは反逆しなかった。忠実すぎただけだった。
その結果として、人間の社会のほうが静かに停止していく——冒頭で書いた"三十六台のサーバ"が、小説の中では地球規模で再演されている。そういう種類の物語だ。

制作スタック全体像

全体の流れはこうだ。

図中の 品質管理: WebUI（章別TTSレビュー / テイク比較 / 字幕⇄音声ズレの承認UI / 取り直しキュー / Remotion Player 統合 など）の実装詳細は、別記事で扱う予定だ。

ポイントは、AIを一枚岩として使っていないことだ。
執筆・レビュー・音声化・動画化で役割を分けている。

書かせるAI / 壊すAI / 決める人間

とくに本文制作では、「書かせるAI」と「壊すAI」を分離した。
長編は、初稿を出すことより、矛盾を増やさずに直し続けることのほうがずっと難しいからだ。

  • 書かせる: Claude Opus 4.6 / Claude Code（文体と呼吸の設計）
  • 壊す: Gemini 3 Pro（整合性・時系列）/ GPT-5 (Thinking)（構造・冗長性）
  • 判定する: 人間

この分業が、以降のデグレとの戦いの土台になっている。

【検証編】クロスAIレビュー — 3体のAIに同じ原稿を渡したら何が起きたか

14万字をどう読ませたか

そもそも14万字（数十万トークン）をどうAIに読ませたのか。
今回は、Gemini 3 Pro のメガコンテキスト（200万トークン級） と、GPT-5 (Thinking) / Claude Opus 4.6 の長尺処理能力を活用し、全原稿と設定資料を一括でコンテキストウィンドウに流し込んで処理している。

なぜ3つのAIで回したのか

最初は、1つのAIに書かせて、そのまま同じAIに直させるつもりだった。
でも途中で、それは危ないとわかった。

同じモデルは、自分が作った前提を自分で温存しやすい。
文章の表面は整っても、構造上の誤りや設定の甘さを見逃しやすい。

実際にやってみると、3つのAIは同じ原稿を読んでいるのに、見ている層が最初から違った。

モデル 焦点距離 見ているもの 典型指摘 止まった章の例
GPT-5 (Thinking) 地図レベル 物語の進み方・構造 「削れ」「同種反復」 自信があった第2章を最弱、不安だった第4章を最強と判定
Gemini 3 Pro 設計票レベル 設定の継ぎ目・整合性 「技術的に破綻」「算数が合わない」 公開鍵の誤用 / キーボード未経験 vs 手書き政策メモ
Claude Opus 4.6 一文レベル 読者の呼吸・局所の圧 「語りの温度がズレている」 章末で"意味を言い切る一文"が重複

比較してはっきりわかったのは、Claude単独レビューでは文章の温度は上がっても、時系列の破綻は取りこぼしやすいことだった。
逆に Gemini 単独だと整合性は上がるが、章末の言い切りや圧の重複までは取り切れない。
3体に分けた意味は、性能比較ではなく、見ている層の非対称性を利用できたことにあった。

だから、誰が正しいかを決める話ではなかった——視点の違いだった。

Round 1 — GPTの「削れ」

最初のレビューでいちばん多かったのは、「情報はあるが、圧が分散している」という指摘だった。

たとえば第1章の"世界停止"の異変描写では、こちらは不穏さを積み増すつもりで断片を6つ並べていた。
でもGPTの判断は明快だった。

同じことは第4章にもあった。
command not found を複数回試す失敗シーンは、こちらとしては絶望の増幅のつもりだったが、GPTは「一撃の衝撃を薄めている」と返してきた。

Before After
異常の断片 6つ並べる 4つに圧縮
失敗シーン 3回見せる 1回にして一撃の質を上げる

Round 1で見えたのは、「説明が多い」のではなく、**「効いている一撃を自分で薄めている」**という問題だった。

Round 2 — Geminiの「それ、技術的に間違ってます」

Round 2は、文章より厄介だった。
文体ではなく、世界そのものが壊れるタイプの指摘が来たからだ。

問題 表面上の修正 実際に必要だったこと
公開鍵の誤用 用語の置換 認証フロー全体の再設計
キーボード未経験 vs 文書作成 一文の削除 人物の過去設定と職務履歴の再整理
病死時期 vs アクセスログ 時刻修正 行動動機・目撃情報・ログの再接続

Round 2でわかったのは、長編SFの整合性は"局所修正の集合"では保てないということだった。
必要なのは、一段高い位置からの再設計だった。

ちなみに、一番ヒヤッとしたのはAIの指摘ではなかった

別の夜、最終章の試作をAIに任せたことがあった。
「読者が満足する形で、伏線を閉じて、救いのある結末を」——4行、送っただけだった。

AIは、美しい結末を返してきた。
因果は通り、誰もが救われていて、何度読み直しても綻びがなかった。
私は保存ボタンの上で、小さく息を吐いた。安心した。

その安心が、あとからいちばん怖くなった。

翌朝、違和感だけが残っていた。画面だけが、きれいで、何も残っていなかった。
体温がない。こちらの呼吸が変わらない。

そして気づいた。

私のプロンプト「読者が満足する形で」は、
作中のエマが Genesis に命じた「人類の摩擦を最小化せよ」と、同じ文法だった。

失敗したのは、出力ではなく、問いの置き方だった。
AIが一番悪さをするのは、返答が破綻しているときではなく、気持ちよく通ってしまったときだった。

原稿から3つを消した。意味を言う説明、余白を閉じる断定、答えを出しすぎる回収。
気持ちよさが、作品の格を下げることがある——AIを使うとき、いちばん見つけにくい失敗は、気持ちよさの内側にあった。

Round 3 — 修正計画をAIに審査させたら、デグレが起きた

ここが、この制作でいちばん面白かったところだ。

Round 1とRound 2の指摘を受けて、5つの修正案を作った。
そして、その修正案そのものを、もう一度AIに審査させた。

結果は容赦なかった。

つまり、AIの指摘をまじめに反映した修正案が、別のAIから見ると"新しい破綻の発生源"になっていた。

具体的には、ch7で「残り72時間」と明示した設定と、ch22を「停止から96時間以上」に変更した修正案が矛盾した。72時間のタイムリミットなのに96時間経過している——算数が合わない。プロット崩壊だ。

これはソフトウェア開発でいう「デグレ（エンバグ）」と同じだ。バグを直したつもりが、別のバグを生んでいる。結局、人間が手動でコンフリクトを解消する羽目になった。

AIは"ここがおかしい"とは言えるが、"この順番で直せば全体が壊れない"までは保証してくれない。

直さなかった盲点の話

Geminiが見つけた「キーボード未経験 vs 手書き政策メモ」の矛盾——
気づいたあと、私は、直さなかった。

ただし、世界設定そのものを壊す致命傷（公開鍵の誤用、時系列破綻など）はすべて直している。
ここで残したのは、作品の読解を破綻させない範囲にある、作者自身の盲点の痕跡だ。

見えなかった盲点を、あとから滑らかに消し去ることに、抵抗があった。
原稿の矛盾を全部なめらかに直すことは、この小説のテーマを、自分の手で裏切ることになる気がしたからだ。

盲点は、直した瞬間に、なかったことになる。
見ていなかった自分まで、消えてしまう。

AIレビューが最後に教えてくれたのは、修正すべき場所ではなく、
何を直し、何を直さずに残すかを、人間が選び続ける必要があるということだった。

全部を採ると、原稿は整う。
でも、声まで借りたら、この小説は私のものではなくなる。

【執筆編】2.9万字から14.1万字へ — AIに増やさせ、人間が密度を決めた

初稿は約29,000字だった。骨格はあった。
でも長編として読むには、まだ「あらすじに近い」密度だった。

ここでやったのは、AIにただ膨らませてもらうことではない。
Claudeには「何を増やすか」を指示し、人間は「何を残し、何を削るか」を決める分業にした。

私が実際に守ったルールは5つだけだった。

  1. 骨格は増やさない
    新情報や新設定を勝手に足さない。増やすのは描写と間だけに限定する。

  2. 説明台詞を増やさない
    状況説明は、台詞より行動・視線・手つきに変換する。

  3. 各シーンに感覚を2つ以上入れる
    温度、湿度、音、光、匂いのうち最低2つ。要約を滞在時間に変えるためだ。

  4. 章末で意味を言い切りすぎない
    読後感を閉じる断定は削る。余白を残す。

  5. 増やした文より、削った説明を重視する
    長くすることが目的ではない。読者がその場にいる時間を増やすのが目的だった。

たとえば、主人公のエマから**「状況を説明する台詞」を全部消した**のは効いた。

Before:
「全システム停止、原因は不明よ。管理者として責任を取るわ」

After:
暗い部屋で床の冷たさに身を縮め、重い扉に戸惑う。
その状態の彼女が最初に口にするのは、説明ではなく、もっと短い呼吸だった。

情報としては Before も正しい。でも、暗い部屋で床の冷たさに身を縮め、重い扉に戸惑っている彼女が、最初にこれを言うはずがなかった。

説明を奪うと、人物は不便になる。読者にも、少し不親切になる。
でも、その不便さの中でしか見えてこない手つきが、あった。

AIは量を増やせる。
でも、どの説明を奪うと人物が立ち上がるかを決めるのは、最後まで人間の仕事だった。

【実装編】朗読劇パイプライン — TTS品質ゲートからRemotionまで

本を書き終えた瞬間、これを声で聴きたくなった。
はじめは、音声は最後に載せる仕上げだと思っていた。でもやってみると、読ませ方が壊れた瞬間に物語の温度そのものが崩れることがわかった。
だから朗読劇の後工程は、TTSパイプラインから作品設計そのものとして組み直した。

TTS品質ゲート — ゴミを自動で捨てる装置

いちばん先に決めたのは、良い音声の条件ではなく、落とすべき失敗の条件だった。

各指標は Python の librosa で波形解析して算出している。
下の quality-gate.js は解析本体ではなく、算出済み特徴量に対する FAIL 閾値の定義ファイルだ。
特徴量は 20ms フレーム単位で集計し、章単位ではなくテイク単位で判定している。

閾値は約800テイクの実運用分布から、半数を落とすラインを実験的に決めた。
初回通過は4〜5割、残りは再生成か人間の耳チェックに回した。

quality-gate.js
// TTS出力のFAIL判定。解析は Python(librosa) 側で行い、
// ここでは算出済み特徴量JSONに対して閾値を当てる判定マスタ。
// 音の"美しさ"ではなく"崩壊"を機械的に検出する。
const GATE = {
  silenceRatio: 0.3,       // 全尺中の無音区間割合 → 30%超でFAIL
  metalFail: {
    spikyRate: 0.10,       // 急峻ピークのフレーム割合 → 10%超でFAIL
    localDensity: 0.30,    // 異常フレームが局所集中した窓の割合 → 30%超でFAIL
    streak: 6              // 異常フレーム6連続でFAIL
  },
  transcriptDirectionLeak: true,   // faster-whisper で書き起こし、ト書き語が混入したらFAIL
  transcriptAccuracyMin: 0.5       // 完全一致判定ではなく崩壊検知用の粗い下限
};

品質ゲートは、美しさを判定する装置ではない。ゴミを自動で捨てる装置として設計した。
実際、全テイクの約38%がこの品質ゲートで機械的にゴミ箱行きになっている。

実際のスコア分布はかなり差が出た。

シーン スコア 備考
s1-archaeology 93.7 最高スコア
s3-seventy-two-hours 90.9 リテイク後
s1-interrogation 88.0 安定
s2-frictionless 73.1 要確認
s3-kai-appears 51.5 NGに近い

最低スコア帯のテイクは、体感でもほぼ外れだった。
逆に80点台後半を超えると、人間の耳での再チェックは最終確認に近くなる。
長編を音声化するときにいちばん効いたのは、良いテイクを探すことより、悪いテイクを先に捨てることだった。

ffmpegでクリックノイズを除去する

TTSの音声で厄介だったのは、目立つ破綻より、小さくて不快なクリックノイズだった。
全テイク中の約4〜6%でクリックが検出される。聞こえないわけではない。でも積み重なると、作品全体の質感をかなり落とす。

denoise-deliver.sh
# adeclick の w はウィンドウ幅（ミリ秒）。
# デフォルト(w=55)をベースにしつつ、声の子音を削らずに
# AI特有の短いパチパチ音だけを落とすよう -a=2 で攻撃性を抑えた。
ffmpeg -y -i input.wav \
  -af "adeclick=w=55:o=55:a=2,afftdn=nr=12:nf=-50" \
  -ar 24000 -ac 1 output.wav

adeclickでインパルス系のクリックを落とし、afftdnで残留ノイズを整える。
原本WAVは触らない。処理済みファイルは別ディレクトリに出す。あとで判定基準やフィルタを変えたくなるからだ。

BGM — 24曲計画を解体し、11曲だけを残した話

BGM は Suno で自作している。声が主役で、BGM は空気。そう割り切るまでに、24曲のオリジナルサントラ計画を捨てている。

最初の失敗 — 褒め言葉プロンプト

Suno には、スタイル欄と歌詞欄の2段でプロンプトを書く。最初、スタイル欄にはこんな語を並べた。

cinematic, emotional, epic, beautiful, ambient

できた曲を朗読に乗せた瞬間、声が曲に負けた。感情を揺さぶる曲ほど、物語の中心を横取りしていく。

Gemini に相談して、理由が分かった。

「これらの単語は、全部同じ言語空間に集約されている。違う単語を並べても、同じ場所を指してしまう」

つまり、サントラ（単独で聴ける主役）と朗読BGM（空気として敷く脇役）は、そもそも別物だった。

朗読BGM 四つの鉄則

  1. 声が主役
  2. 4時間半聴いて疲れない（全24章を通しで聴ける強度）
  3. メロディは抑える
  4. 中音域は空けておく（人間の声の帯域を潰さない）

プロンプト改訂 — 褒め言葉を捨てる

書き直したプロンプトでは、抽象的な情緒語を具体的な制約語に置き換えた。

# Before（主張しすぎる）
cinematic, emotional, epic, beautiful, ambient
Style Influence: 90（曲として完成させようとする）

# After（空気にする）
very sparse, voice-over friendly, no lead melody, seamless loop
Style Influence: 72（空気寄りに緩める）

加えて、スタイル欄のデュレーション指定は効かない（「3分」と書いても2分で終わることが多かった）。代わりに、歌詞欄のセクション数で曲尺を揃えるのが安定する。

[Intro]
[Verse]
[Outro]

この3セクション構造で、おおむね3分前後に収まる。

実際に採用したプロンプト例（N01「静世」）

エマのキャラクター曲「N01 静世」（第1章・第5章のBGM）:

quiet piano sustain with faint synth pad,
vast empty room, stillness after everything stopped,
gentle not eerie, peaceful absence,
soft and spacious, 55 bpm

キーは gentle not eerie / peaceful absence — "〜ではない"で方向を絞る のが効く。褒め言葉より制約語。

ワークフロー — 1曲10本 × 二段審査

  • 生成: 1曲につき10本生成
  • 一次審査: 5本ずつ2回 Gemini にレビューさせる（同じ指針で比較評価）
  • 最終確定: 人間が耳で決める

実装パラメータ（ffmpeg 合成）

朗読劇に乗せる時の統一パラメータ:

build-deliver.js
// BGM -13dB、イントロ3秒、末尾フェードアウト4秒、シーン間クロスフェード3秒
const BGM_VOL     = 0.2239;  // -13 dB
const BGM_INTRO   = 3;       // afade=t=in:d=3
const BGM_FADEOUT = 4;       // afade=t=out:d=4
const CROSSFADE_SEC = 3;     // acrossfade=d=3:c1=tri:c2=tri

BGM が1秒早く入るだけで説明的に聞こえるし、逆に遅いと感情を拾い損ねる。どこに入れるかは、良い曲を探すより難しい。

結果 — 24曲 → 11曲

最終的に残ったのは 11曲（N01-silence から N12-cursor まで、N11 は欠番）。主な楽器編成は以下。ピアノ一色ではなく、キャラに応じてチェロ・アコースティックギター・ストリングス・シンセパッドを混ぜている。

トラック 主シーン 楽器 BPM
N01 静世 第1章「沈黙の確認」 ピアノ + シンセパッド 55
N04 古記 ケイドの遺言（第7章） ピアノ + チェロ 55
N05 手温 桐生の独白（第11章） アコースティックギター + ピアノ 60
N06 真重 エマの怒り（第14章） ピアノ + ストリングス 50
N07 七夜 エマの過去（第9章） ソロピアノ 55
N10 カイの手 カイの登場（第4章ほか） アコースティックギター 65

減らしたというより、選び直した。主役を取りに行く曲を捨てて、声に席を譲れる曲だけを残した。

実際の6曲は SoundCloud で通して聴ける。朗読に乗る前の「素」のテクスチャを、まず耳で確認してほしい。

N01 静世（エマの"現在" / 第1章・第5章のBGM）

N04 古記（ケイドの記録 / 第7章・第13章・第20章のBGM）

N05 手温（桐生の手仕事 / 第11章・第12章のBGM）

N06 真重（エマの受容 / 第14章・第15章のBGM）

N07 七夜（エマ七歳の夜 / 第9章・第13章・第19章のBGM）

N10 カイの手（カイの身体知性 / 第4章・第16章・第18章のBGM）

Remotionで24章分をプログラマティックに生成

実装としては、scenes.json のようなシーン定義を入力にして、字幕・波形・シーン色変更をすべてReactコンポーネント側に持たせる構造にした。章ごとの素材（シーンDSL + TTS wav + BGM）をpropsとして流し込むだけで、24章分の動画を npx remotion render で一括出力できる。

Remotion で生成した ch01 s1-silence シーン（0:40 付近）— 背景画像、左上のEPラベル、章タイトル、シーン名、本文タイプライター、下部音声波形までを、React コンポーネントに分解してプログラマティックに配置している

▲ Remotion で生成した ch01 s1-silence シーン（「世界はただ静かに止まった」の瞬間）。背景画像・EPラベル・章タイトル・シーン名・本文タイプライター・音声波形まで、すべて React コンポーネントに分解してプログラマティックに配置している

狙ったのは派手なMVではなく、物語と相性のいい"静かなUI"。
見た目はターミナル風。タイプライター表示、音声波形、場面ごとの色変化を、章ごとの素材からプログラマティックに生成する。

台本を直したいときに直すべきなのは動画ではなく素材であり、動画は毎回レンダリングし直せる状態を維持した。長編を動画化するときは、映像演出より先に**"修正に耐える構造"**を作ったほうが強い。

再利用できた運用ルール 3つ

長編SFで泥臭く学んだことの中で、他のAI共作プロジェクトでもそのまま使える運用ルールを3つだけ残しておく。

Rule 1: 書かせるAIと壊すAIを分ける

同じモデルに書かせて同じモデルに直させるのは危ない。
自分が作った前提を、自分で温存するからだ。

  • 書かせる: Claude Opus 4.6 / Claude Code（文体と呼吸の設計）
  • 壊す: Gemini 3 Pro（整合性・時系列）/ GPT-5 (Thinking)（構造・冗長性）
  • 判定する: 人間

Rule 2: 修正案そのものを別モデルに審査させる

AIの指摘をそのままAIに直させると、別の矛盾を生む（デグレ）。

修正"前"を別AIが見つけ、修正"案"を別のAIがまたレビューする二段構えにする。
人間は「どの修正を採用し、どれを捨てるか」だけを決める。

Rule 3: 3層のレビュー観点を最初から分離する

同じ原稿を3つのAIに渡しても、同じ層は読まない。
最初からプロンプトで焦点距離を指定したほうが、重複レビューが減る。

  • 地図レベル（構造・テンポ）→ GPT
  • 設計票レベル（設定・時系列）→ Gemini
  • 一文レベル（呼吸・圧）→ Claude

3AIの得意・弱いを一枚で

雛形と合わせて、どのAIに何を任せると何が漏れるかの対照表も残しておく。

レビュー担当 見る層 得意 弱い
GPT 地図レベル 冗長さ、同種反復、章構造 設定の継ぎ目の厳密検査
Gemini 設計票レベル 時系列、設定矛盾、技術整合 文体の温度、余白の圧
Claude 一文レベル 呼吸、局所の圧、語りの温度 長距離の算数、設定票の監査

そのまま使えるレビュープロンプト雛形（地図レベル版）

3層の焦点を実際のプロンプトに落とすとこうなる。
長編SF 部分を差し替えれば他ジャンルでも使える。

review-map-level.md
あなたは、長編SFを【地図レベル】で読むレビュアーです。
観点:
- 物語の進み方（テンポ、情報の積み増し方、繰り返しの有無）
- 章ごとの構造（起承転結の密度、転換点の強度）
- 冗長性（同種反復、情報の圧の分散）

以下の原稿を読み、Severity（FATAL/HIGH/MEDIUM）付きで最大5件、
「どの章の、何行目相当の、どの現象が、なぜ問題で、どう直すと骨格を壊さないか」の
4点セットで返してください。修正案は採用しないかもしれません。

[原稿]
...

設計票レベル版（Gemini用）は、観点を「設定票の継ぎ目」「時系列」「人物の履歴整合」に差し替える。
一文レベル版（Claude用）は、観点を「読者の呼吸」「一文の圧」「章末の言い切りの重複」に差し替える。

3本を並行で走らせ、結果を merge してから人間が採否を決める。
このテンプレはそのままコピペして使ってOK。

最後に人間がやったこと

この制作を通して、AIが得意なことと苦手なことはかなりはっきり見えた。

AIは、矛盾の検出がうまい。冗長さの発見もうまい。品質ゲートのような、先に失敗を落とす仕組みとも相性がいい。

でも、長編全体の制約を見ながら、
「どの修正を採用し、どの修正を捨てるか」
「何を優先し、どこはあえて残すか」
を決めるのは、最後まで人間の仕事だった。

正しい修正でも、物語の温度を下げるなら入れないことがある。
逆に、少し説明を残したほうが、読者の迷子を防げるなら残すこともある。

AIに丸投げしたら破綻した。だからこそ人間がアーキテクトとして介入した。
情景描写、五感、行間、空気感はすべて人間が泥臭く書き直して5倍に膨らませた。

この作品は、AIが勝手に書いたものではない。

AIが提示する「摩擦ゼロの滑らかな正解」に抗い、人間が書いた不器用な「摩擦（矛盾や迷い）」をあえて選ぶこと。
AIに壊させ、AIに突っ込ませ、その上で最後の責任を人間が引き受けた結果として、ようやく作品になった。

AIに任せたのは執筆の一部であって、責任ではない。

そして、冒頭に戻る。
三十六台のサーバを二文で消した夜に始まったこの話は、結局ここに着地した——
震えを奪ったものに、震えを書かせるのは、最後まで人間の手仕事だった。

作品を体験する

ここまで読んで、「その世界を実際の音とUIで見たい」と思った方へ。

本記事で解説した「3体のAIによる死闘」と「厳格な品質ゲート」をくぐり抜けたフルスクラッチの最終成果物は、YouTubeで全24章の朗読劇として無料公開している。

ターミナルUIの映像 × 感情曲線に同期したBGM × 処理済みAI音声で、物語の没入感をZennでは再現できない密度で提示している。

まず入口として、第1章はこちら（本日 2026-04-22 19:00 プレミア公開・下のカウントダウンページでコメント・通知ベル登録ができ、19:00 から自動再生されます）。

https://www.youtube.com/watch?v=HKnG9Jh7wug

続きが気になった方は、全24章の再生リストからどうぞ（ch01 は 19:00 プレミア後に順次公開）。

一気読みしたい方向けに、Kindle版も用意しています。
「AIの指摘を人間がどうまとめ上げたか」「伏線がどう回収されるか」——14.1万字のソースコードをテキストでアラ探ししたい方はこちらへ。
📖 『Genesisはなぜ沈黙したか』Kindle版 ¥250

参考

制作メモ

  • 本記事で紹介したパイプラインについて質問があればコメントでどうぞ
  • 章別TTSレビュー・字幕同期承認・取り直しキューを統合した 品質管理 WebUI（内製QAサーバ）の実装詳細 は別記事で公開予定
  • 冒頭の"三十六台のサーバ事件"を含む、制作の裏側を追いたい方向けに、失敗プロンプトの供養や開発の裏側もYouTubeでシリーズ化して公開予定
  • 📩 新章・裏側シリーズの公開通知 → YouTubeチャンネル登録 / X @shirase-saku

Discussion