本文と目次を検査するEPUB編集アプリ―表紙付きは保留

EPUB編集アプリで本文、目次、書誌、表紙を扱えても、四つをまとめて「完成」とは判定できません。2026年8月11日の検証では、表紙なしの二章EPUBで本文順、nav、NCX、OPF書誌、spine順を確認できました。一方、同じ本文へ表紙を加えた候補は、cover.pngがパッケージ内に存在するにもかかわらず、現行CLIの検査結果がmissing/valid=falseでした。したがって採用できるのは表紙なし候補の本文・目次側だけで、表紙付き候補は保留です。

先に二つの生成物へ別の検査IDを付ける

今回の入力は、章IDと章順をそろえた二章です。出力は「表紙なし」と「表紙付き」の二つに分けます。本文が同じでも、片方の結果をもう片方へ転記しません。検査票の先頭に生成物ID、表紙条件、生成日時を書き、以後の観測値をそのIDへ結び付けます。

表紙なし候補では、本文ファイルの並び、spine、nav、NCX、OPF書誌を読む順に確認します。表紙付き候補では、まず画像資源、次にOPF内の表紙参照、最後にCLIのmissingとvalidを確認します。この順序なら「画像は入っている」と「表紙参照が有効である」を別の事実として残せます。

表紙なし候補は本文から目次へたどる

最初に二章の本文IDとspine順を照合します。続いてnavの章リンクがその二章へ向くかを確認し、NCXとOPF書誌を同じ生成物IDの行へ記録します。2026年8月11日の表紙なし候補はvalid=trueで、nav、NCX、OPF書誌、spine順を確認できました。

ここで確認したのは、表紙なし二章EPUBの構造です。章名を変更した後の再生成はまだ行っていません。本文順と目次資源が一度整合した事実を、章名変更後も維持できるという保証へ広げないことが重要です。

表紙付き候補では参照の解決まで見る

表紙付き候補にはcover.pngと表紙参照が含まれていました。しかし現行CLIの検査ではmissingが返り、valid=falseでした。資源一覧に画像が見えるだけでは、パッケージから表紙として正しく参照できるとは判定できません。

この候補は「画像なし」でも「表紙完成」でもなく、「画像資源は存在するが、検査不一致の原因が未解決」です。結果欄にはそのまま保留と書きます。表紙なし候補のvalid=trueをコピーして、表紙付き候補の有効性を補うことはできません。

採用列と保留列を一枚に並べる

現在の記録は次のように二列で読めます。

この表で表紙なし候補を採用するのは、表紙問題を軽視するためではありません。確認済み範囲だけを先へ進め、未解決範囲を成功扱いしないためです。

二列は同じ二章入力から作った生成物だけを並べます。別の成功原稿や古い表紙候補を持ち込むと、validの差が表紙条件によるものか入力差によるものか分からなくなります。生成物IDと生成日時を表の見出しへ残し、各観測値から実ファイルへ戻れるようにします。

Rune Studioについて言える範囲

Rune Studioについて台帳へ登録しているのは、本文編集、章順・目次・書誌設定と、nav・NCX・OPFを含むEPUB 3生成の機能範囲です。さらに今回の表紙なし候補では、二章の構造を実際に検査しました。この二つを分ければ、公開仕様と実測結果を混同せずに候補を評価できます。

表紙付き候補の有効性、章名変更後の再生成、外部リーダー表示、ストア受理は確認済み範囲に含めません。「本文、目次、表紙を一度に完成できた」という結論も、現時点では出しません。

次の再試験は表紙参照だけを狭く追う

次回は表紙付き候補へ新しい生成物IDを付け、表紙画像のパス、manifest項目、表紙を指す参照、CLIのmissing対象、最終valid値を順に記録します。変更した条件も併記し、表紙なし候補の行は書き換えません。章名変更後の再生成は別の試験として扱います。

現在の結論は明確です。本文・nav・NCX・OPF書誌・spine順は表紙なし候補で確認済みです。表紙付き候補はcover.pngの存在だけでは採用せず、missing/valid=falseの原因を解消して再検査するまで保留にします。

今日の一歩は、二つの生成物IDを検査票の左右へ書くことです。そこへ現在の値を転記すれば、次に調べる対象が表紙参照へ絞られます。