左が事故です。

A5の1ページ目に表紙を全面で入れたつもりが、ページ上端の数ピクセルの帯になっています。右が正しく入った状態です。

やっかいなのは、DOCXの中身は完全に正しいことです。

画像のサイズ指定：148×210mm（＝A5ぴったり）
配置：中央揃え
行間：自動
セクションの余白：ゼロ

XMLをどれだけ読んでも、間違いが見つかりません。Wordで開くか、PDFに書き出して座標を測るまで、崩れていることに気づけません。

原因は、表紙とは何の関係もない1行でした。

293本組みました

Kindle用のDOCXを、いま数えたら 293本 ありました。うち、製本まで終えた完成本（final_book.docx）が 86冊 です。

数えた結果であって、感覚の話ではありません。数え方はこれだけです。

import os
n = sum(1 for dp, _, fn in os.walk("output")
        for f in fn if f.lower().endswith(".docx"))
print(n)

ただし、毎回きれいに組めたわけではありません。むしろ逆です。

この教材の中身は、正しい組み方ではなく、事故の記録です。

なぜDOCXの崩れは、気づくのが遅れるのか

理由は3つあります。

1. DOCXを見ても分からない

さきほどの表紙がそうです。XMLは正しい。プログラムでいくら検査しても通ります。崩れているのは「Wordがそれをどう解釈するか」の側なので、書き出してみるまで分かりません。

2. KDPのプレビューまで遅れる

そのままアップロードすると、KDPのプレビューで初めて気づきます。直して、また上げ直して、また待つ。1周が長い工程です。

3. 直そうとすると、別のものが壊れる

崩れを直すために原稿から作り直すと、手作業で当てた書式が全部消えます。実際に、太字36箇所がゼロになり、改ページ40箇所が3箇所になり、巻末に手で足した3ページが消えました。

事故そのものより、事故を直すときの二次被害のほうが大きいというのが、86冊の結論です。

いちばん高くついた事故

最終ページの奥付に、別のお客さんの名前と公式サイトが入ったまま、「完成しました」と報告しました。

前の案件の make_book.py を流用したときのことです。上部の定数（書名・サブタイトル・著者名）は書き換えていたので、直したつもりでいました。

奥付だけが、関数の中に直書きされていた。

報告したあとにPDFを読み直して気づきました。そのまま先方に渡していたら、別の顧客の情報を渡すという事故になっていました。

本書では、これを「気をつける」で終わらせません。成果物そのものを全文検索する手順を第10章に置いています。スクリプトも載せてあります。

この教材で扱うこと

293本のあいだに「二度とやらない」が 20個 たまりました。その20個と、それぞれの直し方を全部書き出したものが本書です。

内訳は3つです。

組む前に決める（決め方を間違えると、あとで全部やり直しになるもの）
事故カタログ（実際に出た症状と、その原因と、直し方）
出す前に確認する（KDPに入れてから気づくと戻れないもの）

必要なもの・かかる費用

本書とは別に、次のものが必要です。

Windows + Microsoft Word　— すでにお持ちのもので大丈夫です
Python（python-docx / PyMuPDF / Pillow）　— 無料
pandoc　— 無料

有料のツールは要りません。Wordは、ページ数を数えるのと、PDFへ書き出すのに使います（COM経由）。LibreOffice（soffice --headless）でも同じことができるので、その手順も併記しています。

コードは全文を本文に載せてあるので、写して実行できれば大丈夫です。プログラミングの知識は前提にしていません。

目次

【第1部】組む前に決める

第1章　pandocが吐いたDOCXは、まだ本ではない ── 足りない7項目
第2章　改ページに「改ページ文字」を入れない ── 属性で切るという考え方
第3章　間は「アキ」ではなく実際の空段落 ── 空行が空行に見えない理由
第4章　2〜3文で1かたまりにする ── 1文1段落は読みづらい

【第2部】事故カタログと、その直し方

第5章　事故①表紙がページ上端の細い帯になる（原因は3つあり、本命は3つ目）
第6章　事故②表紙ページにノンブルの「1」が出る
第7章　事故③画像が版面をはみ出す／一部の画像だけ縮まない
第8章　事故④「・」は2種類ある ── 行頭の「・」と、左余白の「・」
第9章　事故⑤原稿側の3つのバグ ── 1文1段落・太字の素通し・**の流出
第10章　事故⑥前の案件の情報が奥付に残る
第11章　事故⑦中扉と目次が二重になる／Wordで開いたままにする
第12章　事故⑧日本語のパスと、ファイルサイズ

【第3部】出す前に

第13章　PDFに書き出して実測する ── 崩れを見つける唯一の方法
第14章　直すときは再ビルドしない ── その場編集と、zip内メディア置換
第15章　出す前の検算15項目
第16章　逆引き表 ── この症状が出たら、この章へ

分量

本文：約19,000字（コードとテンプレートを除いた、読む文章の分量です）
コードとテンプレートを含めた総量：約61,000字
画像：5枚（実際の崩れと、その修正後）

数え方は、記号や空白を除いた文字数です。Pythonで数えました。コードを含む字数を「本文」として出すと実物とずれるので、分けて書いています。

図解のための図解は入れていません。全部、実際に組んだDOCXとその修正過程です。

付いてくるもの

全部、記事の中に入っています。別のサイトへ移動したり、登録したり、アクセス権を申請したりする必要はありません。購入した瞬間に、そのまま読めて、そのままコピーできます。

Pythonツール全7本（全文をそのまま掲載）
製本の本体（判型・見出し・前付け・奥付を一括で当てる）
pandoc変換（日本語パスを回避する一時ディレクトリ経由）
章末に漫画を挿し込む
表紙が潰れていないかをPDFで実測する検査
製本後の検算（15項目を自動で見る）
再ビルドせずに、その場で2〜3文かたまりに直す
書式を壊さずに画像だけ差し替える（zip内メディア置換）
ChatGPT用テンプレート全5枚（入力欄にそのまま貼れる文章）
T1 原稿の構造を整えさせる（見出し階層と画像タグ）
T2 症状から原因を切り分ける
T3 検算の出力を読ませる
T4 前の案件の固有名詞を洗い出させる
T5 KDPに上げる前の最終確認
A5製本の既定値表（判型・余白・フォント・行間・見出しサイズ）

買わないほうがいい人

次に当てはまる方には、おすすめしません。

Wordで直接、手で組んでいる方

それで完成しているなら、本書の内容は不要です。本書は「同じ体裁を何十冊も繰り返す」ための作りになっています。

1冊だけ出す方

1冊なら、崩れを手で直したほうが早いです。本書が効いてくるのは、同じ工程を繰り返す場合です。

リフロー型だけで出す予定の方

判型やページ余白の設定は、リフローでは効きません。ただし見出しスタイルと改ページ属性は効くので、第2章と第9章だけは役に立つと思います。

最初の1冊が通るまで

読み終える必要はありません。この順で進めれば動きます。

第1章の既定値表を見て、自分の本の判型と余白を決める（5分）
第13章の検査スクリプトを、いま手元にあるDOCXにかけてみる（10分）
出た症状を、第16章の逆引き表で引く（3分）
該当する章の手順で直す（症状によって10分〜1時間）

ここまでで30分ほどです。手元のDOCXが1冊でもあれば、2で何か1つは見つかると思います。

第1部（決め方の話）は、あとから読んでも損はありません。

免責事項

本書に記載した各ソフトウェアの仕様・挙動は2026年8月時点のものです。Word・pandoc・python-docxのバージョンにより、記載と異なる場合があります。
本書のスクリプトは、ご自身の環境で必ずバックアップを取ってからお使いください。既存のDOCXを上書きする操作を含みます。
KDPの入稿要件・審査基準は変わります。最新のものをAmazonのヘルプでご確認ください。
販売部数・売上・審査結果について、いかなる成果も保証するものではありません。
本書の内容およびテンプレート・コードの再配布・転売は禁止します。ご自身の制作にはご自由にお使いください。