目次項目を一度で確認!EPUBのデータ編集、目次・表紙・奥付を整える手順

目次・表紙・奥付の編集の確認工程を、白い原稿用紙と紫色の半透明装置で抽象的に示したアイキャッチ

EPUBのデータを編集するときは、完成したEPUBを直接直すのではなく、本文、目次への掲載設定、表紙、奥付の元データへ戻って再生成します。今回の標本は四章の随筆、表紙1枚、奥付用ファイル1件です。第二章の見出しをESSAY377-02からESSAY377-02-改へ1件だけ変更し、同じ入力一覧から作り直したところ、変更前後ともローカル構造検査はvalid=trueでした。

ただし、想定していた本文4項目だけでなく、実測のnavとNCXは各5項目でした。奥付用ファイルも目次対象に入ったためです。したがって、この記事の答えは「再生成が成功したら完了」ではありません。本文の修正が反映され、表紙と奥付が残り、目次項目数まで意図と一致したときに編集完了とします。

答え:EPUBデータは四つの戻し先で直してから再生成する

一般的なEPUB編集では、直したい内容ごとに戻り先を分けます。本文や章見出しは原稿、読む順番と論理目次は章順・目次設定、表紙は画像と表紙指定、著者名や発行日は書誌・巻情報または奥付の元データです。生成済みのnav.xhtmlやcontent.opfだけを手で直すと、次回出力で変更が消えたり、元原稿と生成物のどちらが正しいか分からなくなったりします。

今回の編集対象は第二章見出し1件だけです。表紙画像、著者名「朝凪遥」、出版社「Evidence Press」、発行日2026-08-31、四章と奥付用ファイルの並びは固定しました。変更を1件に絞ることで、再生成後の差が見出し修正によるものかを追えます。

標本と開始値:四章、表紙1枚、奥付1件を固定する

専用の複製ワークスペースにはchapters/01.mdから04.mdまでの四章、chapters/99-colophon.md、images/cover.pngを用意しました。作品名は「四章随筆 STUDIO-377」、ファイル名はstudio-377、横書き、日本語、単巻0、版1.0です。タイトルページ位置0、目次ページ位置1を指定し、原稿5ファイルを01、02、03、04、99-colophonの順に選びました。

開始時に残すべき値は、原稿5ファイルの順番、表紙パス、著者名、出版社、発行日、第二章の旧見出しです。目次は「本文4項目になるはず」と記憶で決めず、生成後のnavとNCXから件数とリンク先を読み取ります。ここが、表紙・奥付付きの新規EPUBを初めて作るSTUDIO-407や、KDP原稿の修正履歴を管理するSTUDIO-481との違いです。

実際の操作:第二章だけを直し、同じ条件で二度出力する

最初に作品情報、巻情報、表紙、原稿選択、タイトル・目次位置を設定し、出力計画を確認してから1回目のEPUBを生成・検査しました。次に第二章の原稿でESSAY377-02をESSAY377-02-改へ置換しました。表紙と原稿一覧を同じ値で再設定し、同じ固定日時で計画、出力、検査を繰り返しています。

Rune Studioの画面で行う場合も対応は同じです。EPUBウィザードの「シリーズ情報」「巻選択」「ファイル選択」「チャプター順」「メタデータ」「確認と出力」を順に見ます。第二章の見出しは原稿へ戻って直し、目次項目を直したいときはチャプター順の目次掲載、表紙はメタデータ、著者名や発行日はシリーズ・巻の入力へ戻します。架空の「EPUB直接編集」画面を前提にしません。

実測:spine 9、nav 5、NCX 5で再生成できた

記事固有の検証はstatus=passed、command_count=16でした。変更前後ともvalid=trueで、変更後のspineはcover.xhtml、title.xhtml、nav.xhtml、p001.xhtml〜p005.xhtml、colophon.xhtmlの9件です。画像は1件、欠落画像は0件、navとNCXはいずれも存在しました。navのリンク先はp001.xhtml〜p005.xhtml、NCXのリンク先はText/p001.xhtml〜Text/p005.xhtmlで、各5項目です。

第二章見出しの置換は1件だけ行われ、1回目のEPUBもvalid=true、再生成後はEPUBのSHA-256が変化しました。なお、二回分のplan_chapter_countsはどちらもnullだったため、計画要約の章数を推測で補わず、inspect後のspineとnav/NCXを根拠にしています。これにより「原稿の変更を再生成物へ反映できた」ことは確認できます。一方、四章に対して目次が5項目だったため、「目次四項目が意図どおり」という判定には使えません。本文4章だけを目次へ出したい場合は、奥付用ファイルの目次掲載を外してから再出力するのが戻し先です。

別の共通Stage 4では、3章、横書き、版1.7、spine 7、画像1、欠落0、nav・NCXあり、valid=trueも9操作で確認されています。これは基本的な生成経路の証拠ですが、今回の四章・見出し修正1件の判断には、上記16操作の結果を優先します。

限界:valid=trueでも販売先や全リーダーの合格ではない

今回確認したのは、専用複製から生成したローカルEPUBの内部構造です。valid=trueはKDPの審査通過、販売登録の成功、Kindle Previewerでの見え方、すべての読書アプリでの表示一致を意味しません。表紙の見た目やリンクを実機で開いた結果も、今回の画像対象外・外部対象外の検証には含まれていません。

また、目次5項目という観測値を「仕様上必ず奥付が入る」と一般化できません。この標本では奥付用ファイルを5番目の入力として選び、目次除外を指定しなかった結果です。別の本では、入力一覧と目次掲載設定をその本の正本として確認してください。

Rune Studioで確認できる製品範囲

現行Mac版Rune Studioの公開資料では、6ページのEPUBウィザードで作品情報、巻、原稿、チャプター順、目次掲載、表紙、発行日を設定し、EPUB 3を生成できます。生成内容にはXHTML本文、タイトルページ、目次、奥付、表紙、nav.xhtml、旧リーダー互換用NCX、content.opfのmetadata・manifest・spineが含まれます。これは公開機能として確認したStage 3の範囲です。

EPUB 3.3仕様が定めるナビゲーション文書、パッケージ文書、spineは一般規格の役割です。Rune Studio独自の規格ではありません。Rune Studioはその構成を生成する選択肢であり、今回のStage 4は特定の複製標本で開始から結果まで操作した記録です。製品の現行範囲はRune Studioの商品ページでも確認できます。

結論:見出し修正後は目次件数まで照合する

EPUBのデータ編集では、第二章の見出しは第二章の原稿へ、目次の過不足は目次掲載設定へ、表紙は表紙指定へ、奥付情報はその元データへ戻します。今回の四章標本では、見出し1件の変更後もspine 9、画像1、欠落0、nav・NCX各5項目、valid=trueで再生成され、EPUBのハッシュも変わりました。

最初の一手は、編集前の原稿一覧と設定値を控えた複製を作ることです。生成後に目次が想定の4項目ではなく5項目なら、完成ファイルを直接直さず、奥付の目次掲載設定へ戻ります。この「変更内容ごとの戻し先」と「再生成後の具体値」がそろって初めて、目次・表紙・奥付を保ったEPUBデータ編集と判断できます。