【連載 4/7】KDPのリリース作業では、やっぱりAIに本気で助けられた話 ～出版編～
前回は「日本語の編集は、結局ちょっと楽なだけだった」と辛口で締めました。 でも今回は、ちゃんと揺り戻します。Kindle(KDP)で出すまでの実務では、生成AIに本気で助けられました。
同じAIなのに、なぜ刺さり方がこんなに違うのか。その話です。
実は、KDPは“2度目”だった
白状すると、KDPでの出版は、私にとって初めてではありません。ずっと昔に、一度やっているんです。
ところが、これがまったくアテにならなかった。手順なんてとっくに忘れているし、何より 時代が進んで、仕様も基準も様変わりしていました。EPUBの作法も、ペーパーバックの入稿要件も、税務まわりも、あの頃とは別物。「経験者」のはずの過去の知識は、ほとんど何の役にも立たなかったわけです。
……これ、よく考えると、未来の知識を持って過去に飛ばされたのに、そのままでは戦えない私の主人公とちょっと似ているな、と書きながら苦笑しました。結局、今この瞬間の正解に、その都度アクセスし直すしかない。そこでこそ、AIが本領を発揮してくれました。
編集と出版作業で、AIの「効き目」が真逆だった
前回の編集フェーズで効かなかったのは、「この日本語はアリかナシか」という、最後は人間の感覚に依存する判断でした。 一方、KDPのリリース作業は性質がまるで違います。手順が決まっていて、調べ物が多くて、ハマりどころがある——つまり「正解にたどり着くための段取りと調査」が中心。ここはAIの独壇場でした。
具体的に助かったところ
① EPUB変換のパイプライン構築 原稿はMarkdown。そこから Pandoc でEPUBに変換するのですが、設定やコマンドの組み方を一緒に詰めてもらえたのが大きかった。
② バリデーションのトラブルシュート じつはこのフェーズ、入口は「EPUBのチェックってスマホアプリでできる?」というゆるい質問でした。返ってきたのは「スマホは閲覧向きで検証は厳しい、出版前ならPCが安心」。「Macなんだけど何がいい?」と重ねると、用途別に道具立てが整理されて出てきます。
- pagina EPUB-Checker / EPUBCheck(Homebrew経由)で仕様エラーを潰す
- Kindle Previewer 3 で実機の見え方を確認
- 日本語特有のチェック(JIS範囲外漢字・縦中横など)は 電書ラボチェッカー
「①仕様チェック → ②実機プレビュー → ③KDP入稿」という三段の流れに落とし込めたのが大きかった。エラーが出るたびに「これは何で、どう直すか」を整理してもらえて、一人で公式ドキュメントを彷徨う時間が、ごっそり消えました。
③ KDPまわりの事務作業 – W-8BEN(米国の税務書類)の理解 – 商品説明文(最大4,000字)、キーワード、カテゴリの設計 – KDP Select(独占)か、非独占かの整理 → 最終的にKDP＋なろう／カクヨムでの一部無料公開、というハイブリッドに
④ 表紙制作のワークフロー AI画像生成(Nano Banana)でベースを作り、Canva でタイポグラフィを重ねる。プロンプトの組み立てや方向性の壁打ちまで含めて、ここも伴走してもらいました。 ——ただ、この表紙に関してはAIに「助けられた」だけでは終わらず、けっこう葛藤もしたし、著作権についても真面目に考えました。それは次回、じっくり書きます。
いちばん助けられたのは、実は「紙の本」だった
電子版だけのつもりが、欲が出てペーパーバック版も作りました。そして——ここがいちばん、一人だったら心が折れていた領域でした。
- 表紙の入稿データ：KDPは表裏＋背表紙が一枚に繋がった「回り込みカバー」を、ミリ単位で要求してきます。これをPython(PIL)でゼロから組版。
- 判型ジプシー：当初は新書サイズ→横書きと相性が悪く断念→B6→最終的にA5へ。KDPの印刷コストはページ数とインクで決まると分かり、1ページの文字数を稼げるA5が結局いちばん安く収まりました。
- 謎のエラーとの格闘：本文をPandoc＋LuaLaTeXで組むと、選手名やクラブ名の長い英字が原因で行があふれる(overfull )。これを
\emergencystretchを伸ばしたり、英文ハイフネーションを有効にしたりして一つずつ潰す。 - 背表紙のテキスト設計や、裏表紙紹介文の行頭禁則(句読点が行頭に来ないようにする処理)まで。
この手の「地味で、専門的で、ハマると一晩溶ける」作業こそ、AIと並走した恩恵が桁違いでした。やりたいことは決まっているのに、作法が分からなくて進めない——その距離を一気に詰めてくれる。前回の「日本語の質」とは、まるで別物の効き方です。
ラスボスは「ページ数＝原価」だった
組版の崩れを潰し終えて、最後に立ちはだかったのが 印刷原価 です。KDPのペーパーバックは、ざっくり言えば ページ数が増えるほど高くなる。あと十数ページ削れれば原価が一段下がる——そんな、数円をめぐる最終決戦に突入しました。
行間はもう限界。これ以上詰めたら読み心地が壊れる。そこで気づいたのが、web小説スタイルの“風通しの良さ”でした。会話や描写のたびに段落を分けるあの書き方は、紙の上では 1万近い「段落と段落のすきま」 になり、その一つひとつに余白が入って、静かにページを食い荒らしていたんです。
ここで効いたのが、AIに机上で計算させず 「実際に組んで、数えて」を何度も繰り返したこと。試した結論はちょっと衝撃的で、行間を1ミリも触らず、段落間の余白を詰めるだけで、ページ数が3割以上も減りました。要は、日本の文庫が昔からやっている「字下げのみ・空行なし」の組版に寄せた、というだけの話です。判型の見直しと合わせて、当初550ページ近くあった紙の本は、最終的に210ページ台——半分以下にまで圧縮できました。
地味に大きかったのが、電子版(EPUB)と紙(PDF)で、組版のビルドを最初から分けておいたこと。おかげで、紙の原価のためにギチギチに詰めた組版が、電子版の読み心地はまったく壊さなかった。媒体が変われば、最適な組版も変わる。これは一冊出して、骨身にしみた教訓でした。
結局、AIはどこで効いてどこで効かないのか
3回・4回と書いてきて、自分なりの結論はこうです。
- 作品の核(日本語の質、創作上の判断) … 最後は人間。AIは“ちょっと楽になる”止まり。
- 核の周りの面倒ごと(段取り・調査・変換・トラブルシュート) … ここはAIが圧倒的に速い。
言い換えると、AIは「物語そのもの」より「物語を世に出すまでの道のり」で本領を発揮した。 これが、一冊出してみて一番腑に落ちた感覚でした。
次回は、その 表紙ができるまでの話。AI生成カバーならではの葛藤と、避けて通れない著作権の検討について書きます。
