「EPUBは作れたのに、KDPへ入稿するとtoc.xhtmlで止まるのはなぜだろう」と悩む方は少なくありません。
このエラーは見た目では分かりにくい一方で、目次リンク、本文のID、content.opfの宣言が少しでもずれると発生しやすい問題です。
ただし、原因の多くは整理できます。
確認する順番をtoc.xhtml→本文HTML→content.opf→Kindle Previewerに固定すると、修正はかなり安定します。
Zero出版でも、Word変換EPUBやAI補助制作の案件で同様の相談を多数受けてきました。
過去の検証では、toc.xhtmlエラーの大半が本文側IDの不一致か、nav文書の登録漏れで説明できました。
この記事では、Amazon KDPの公式ガイドに沿って、KDP toc.xhtml エラーの原因と直し方を実務目線で整理します。
変換後のEPUBを未検証のまま再入稿し続けるのは危険です。
構造のどこが壊れているかを切り分ければ、無駄な差し戻しを減らし、安全に出版作業を進めやすくなります。
- ✅ KDPのtoc.xhtmlエラーが起こる代表的な原因
- ✅ toc.xhtml・本文HTML・content.opfを確認する実践手順
- ✅ 再入稿前に目次エラーを減らす検証のコツ
KDPのtoc.xhtmlエラーは構造不整合を直せば解消しやすいです
KDP toc.xhtml エラーの結論は、目次文書そのものだけでなく、リンク先IDとナビゲーション宣言を含むEPUB全体の整合性を直すことです。
Amazon KDPの公式ヘルプでは、Kindle Previewerのエラーコードに対応する形で、目次リンク先が解決できないケースの確認手順が案内されています。
特に代表例が、Kindle Previewer E24010です。
これはtoc.xhtmlやnav.xhtml内のリンク先が、本文HTMLの実在するIDに一致していない場合に起こりやすいとされています。
そのため、toc.xhtmlだけを開いて修正しても解決しないことがあります。
本文側のid属性、content.opfでのnav登録、古いパスの残存まで一緒に点検する必要があります。
エラーの本質は目次ファイル単体ではなく接続関係にあります
toc.xhtmlとnav.xhtmlは目次の中核です
KDPでは、EPUB 3の目次は通常
ファイル名はtoc.xhtmlまたはnav.xhtmlであることが多いですが、重要なのは名前よりも目次文書として正しく機能しているかです。
公式ガイドでも、<nav epub:type="toc">を用い、各章や節へのリンクを並べる構造が示されています。
つまり、KDP toc.xhtml エラーとは、単なるファイル名の問題ではなく、目次としての役割が正しく接続されていない状態と考えると理解しやすいです。
最も多い原因はリンク先IDの不一致です
もっとも優先して確認したいのは、toc.xhtml内のhrefと本文HTML内のidが一致しているかです。
たとえば、目次側がchapter1.xhtml#ch1を参照しているのに、本文側がid="chapter1"になっていればリンクは解決されません。
この不一致は、Word原稿をEPUB化した後に章名を変更した場合や、AI補助でHTMLを後編集した場合に起こりやすいです。
Zero出版の検証でも、SigilやCalibreで再編集したEPUBにおいて、目次更新前の古いIDが残っていたケースが繰り返し確認されました。
bodyに付いたIDは要注意です
KDPの公式修正例では、リンク先IDがbodyに付いているケースへの注意が示されています。
環境によっては、body id="ch1"のような指定が期待通りに解釈されず、子要素のdivやh1へIDを移したほうが安定する場合があります。
目次リンクの着地点は、本文の先頭見出しやラッパーdivに置くのが実務上は安全です。
これはKDP変換時の挙動差を吸収しやすいためです。
content.opfのnav宣言不足でも失敗します
EPUB 3では、目次文書をcontent.opfのmanifestに登録し、properties="nav"を付けることが重要です。
この宣言がないと、nav.xhtmlが存在していてもKDP側で正しいナビゲーション文書として認識されない可能性があります。
さらに、spineの並びと本文ファイルの順序がずれていると、変換後の目次表示や遷移に違和感が出ることがあります。
古いEPUB 2形式ではtoc.ncxとの整合性も必要になるため、古いテンプレート流用時は特に注意が必要です。
修正は4点確認で進めるのが最短です
1. toc.xhtmlのhrefを確認する
最初に、目次ファイル内の各リンクを確認します。
チェックするのは、ファイル名、相対パス、ハッシュ以降のIDです。
- リンク先ファイル名が実在するか確認する
#以降のID名が本文と完全一致するか確認する- 不要な全角文字、空白、古い章名が残っていないか確認する
見た目が同じでも、大文字小文字やハイフンの有無で別IDとして扱われることがあります。
目視だけで再入稿するのは危険です。
2. 本文HTMLのid属性を確認する
次に、リンク先として指定された本文ファイルを開きます。
目次で参照しているIDが、実際に本文内へ一度だけ存在するか確認してください。
id="ch1"のような指定が本文にあるか探す- 同じIDが複数回使われていないか確認する
bodyに付いている場合はdivやh1へ移すことを検討する
同一IDの重複は、KDP変換で予期しない遷移不良の原因になります。
Word由来のEPUBでは、自動生成されたアンカー名が章見出し変更後も残ることがあるため、特に慎重な確認が必要です。
3. content.opfのmanifestとspineを確認する
その後、content.opfを開いてnav文書の登録を確認します。
- nav.xhtmlまたはtoc.xhtmlがmanifestに含まれているか確認する
- 該当itemに
properties="nav"が付いているか確認する - spineの順序が本文構成と目次順に沿っているか確認する
外部記事でも、目次不具合はnav.xhtml単体ではなく、OPFとの接続不良で起こると広く共有されています。
Zero出版では、KDP入稿前チェックリストにこの工程を必須化してから、目次系の差し戻し率が大きく下がりました。
Wordから書き出したEPUBをKDPへ入れたところ、toc.xhtml関連のエラーが消えません。目次は表示されているのに、なぜ審査で止まるのでしょうか。
このケースでは、見た目で目次が表示されていても、内部リンク先のIDやOPF宣言が壊れている可能性があります。
特にWord変換EPUBは、章タイトルを後から直すと、旧IDが残ることがあります。toc.xhtmlのhref、本文のid、content.opfのnav登録を3点セットで確認すると原因を切り分けやすいです。
再入稿前には、Kindle PreviewerとEPUBCheckの両方で検証するのが安全です。
どちらか一方だけでは見落とす不整合があるため、出版作業の標準手順にしておくと再発防止につながります。
4. Kindle PreviewerでE24010などの詳細を確認する
最後にKindle Previewerへ読み込み、エラーコードを確認します。
最近のKDP公式ヘルプでは、Previewerのコードと修正方法が対応づけて説明されています。
とくにE24010は、目次ハイパーリンクが解決されない場合の代表例です。
この段階でエラー箇所のファイル名や行番号が分かれば、再修正の精度が上がります。
修正後は必ずPreviewerを再実行し、エラーが消えたことを確認してからKDPへ再入稿するのが正解でしょう。
よくある修正パターンを具体例で確認します
リンク先IDが本文に存在しないケース
たとえば、toc.xhtmlにhref="chapter02.xhtml#part2"と書かれているのに、本文側がid="chapter2"になっているケースです。
この場合は、目次側または本文側のどちらかへ統一します。
実務上は、章見出しの命名規則を先に固定し、すべてch01、ch02のように揃えると管理しやすいです。
body idを子要素へ移すケース
本文が<body id="ch3">となっている場合、KDP公式の考え方に沿って、以下のように移すと安定しやすくなります。
<body><div id="ch3">...</div></body>
Zero出版での検証でも、この修正でPreviewer上の目次リンク不良が解消した例が複数ありました。
特に複数ツールを経由したEPUBでは有効なことが多いです。
content.opfにnav登録がないケース
nav.xhtmlが存在していても、manifestに登録されていなければ不完全です。
EPUB 3では、nav文書にproperties="nav"を付ける必要があります。
テンプレート流用時にこの属性だけ落ちていることがあり、見落としやすい箇所です。
古いtoc.ncxやパスが残っているケース
EPUB 2からEPUB 3へ移行したファイルでは、古いtoc.ncx参照や旧フォルダパスが残っていることがあります。
この場合、実際の表示はできても内部構造が不整合になり、KDP変換時に問題化する可能性があります。
本文ファイルの移動後は、目次側の相対パスも必ず再確認してください。
再発防止には変換後検証を標準化することが重要です
WordやAI補助制作ほど変換後チェックが必要です
Word原稿からのEPUB化や、AIを使ったHTML補助生成では、見た目が整っていても内部構造が乱れることがあります。
特に自動変換では、不要なアンカー、重複ID、古い章リンクが残りやすい傾向があります。
変換ツールの出力をそのまま正しいとみなすのは避けたほうがよいです。
安全な入稿プロトコルを作ると安定します
Zero出版では、過去のアカウント凍結危機をきっかけに、AI出版でも構造検証を省略しない運用へ切り替えました。
その結果、入稿前に行うべき確認は次の順序で固定するのが最も安定しました。
- EPUBCheckで基本構造を確認する
- toc.xhtmlと本文HTMLのID対応を確認する
- content.opfのnav登録とspine順を確認する
- Kindle Previewerで実機想定の表示を確認する
- KDPへ再入稿する
この流れを毎回同じにすると、修正漏れが減ります。
担当者が変わっても品質を保ちやすいため、チーム制作にも向いています。
迷ったら目次・本文・OPFの3点セットで見直しましょう
KDP toc.xhtml エラーは、目次ファイルだけの問題に見えて、実際にはEPUB全体の接続不良で起こることが多いです。
特に重要なのは、目次リンク先IDの一致、body idの適切な配置、content.opfでのnav宣言です。
Kindle Previewer E24010が出た場合は、まずtoc.xhtmlのhrefと本文HTMLのidを照合してください。
そのうえで、content.opfのmanifestとspineを確認すれば、多くのケースは原因にたどり着けます。
見た目だけで判断せず、変換後のEPUBを検証することが、もっとも確実な再発防止策と考えられます。
もし今まさに入稿前で不安があるなら、まずは1冊分だけでも確認手順を固定してみてください。
構造チェックを習慣化すると、KDPの差し戻し対応は確実に楽になります。
焦って再入稿を繰り返すより、目次・本文・OPFを順番に見直すほうが、結果として早く安全に出版へ進めるはずです。
