原稿をEPUBに変換するときは、ファイルが生成されたことだけで終えず、本文4章、目次4リンク、表紙参照、書誌情報、読む順番を生成物から直接確認します。今回の四章EPUBでは、navの「序章→展開→転換→結び」、OPFの作品名・作者・出版社・言語・日付・識別子、表紙画像参照、cover→title→nav→4章→colophonの順を読み取れました。別のリーダーでの見え方は、この構造確認とは別の試験にします。
変換前に入力カードを一枚作る
書誌情報は、出力画面を開いてから考えると表記が揺れます。たとえば次のような作品カードを先に用意します。
| 項目 | 入力例 |
|---|---|
| 作品名 | 雨の標本 |
| 作者名 | 佐藤葵 |
| 出版社名 | 青灯舎 |
| 言語 | 日本語（ja） |
| 組み方向 | 横書き |
| 版 | 1.0 |
| 発行日 | 2026-09-01 |
| 表紙 | images/cover.png |
この値は読者が手順を追うための公開例です。構造確認に使った仮タイトル・作者名・出版社名そのものではありません。大切なのは、入力した値と、EPUBのパッケージ文書に入った値を同じカードで比べることです。
生成された目次4リンクと書誌値を読む
原稿は chapters/C01.md からC04.mdまでの4ファイルです。今回の専用原稿の章題は「序章」「展開」「転換」「結び」でした。
目次は次の4項目を同じ順に並べます。
- 序章
- 展開
- 転換
- 結び
EPUBでは、画面に見える目次だけでなく、ナビゲーション文書と読む順番の情報が別の役割を持ちます。生成されたnavを直接取り出すと、4リンクは「序章→展開→転換→結び」の順でした。本文XHTMLもp001〜p004としてspineに同じ順で入りました。目次の有無だけでなく、リンク名と本文順を具体的に照合できた形です。
同じ出力のOPFでは、作品名 四章書誌検証、作者 Rune 著者018、出版社 Rune 出版018、言語 ja、日付 2026-09-01T12:00:00+09:00、空でないUUID識別子を読み取りました。入力カードと生成値を一字ずつ比べるという最終確認を、設定画面の値だけでなく出力側まで進めています。
表紙参照と読む順番を直接照合する
表紙ファイルを選んだら、登録先の値が images/cover.png になっているか確認します。本文画像が0枚の作品でも、表紙を入れればパッケージ内の画像数は1枚になります。
今回の出力では、cover.xhtml が ../Images/cover.png を参照し、その画像資源が実際に存在すること、manifestでcover-imageとして指定されていることを確認しました。収録画像は1枚、欠落画像は0件です。spineはcover、title、nav、p001、p002、p003、p004、colophonの8項目でした。
構造検査の emptyPages には cover.xhtml が残りました。これは画像だけの表紙ページに本文テキストがないためです。表紙参照と画像資源は直接確認できましたが、リーダー上で表紙がどう見えるかまでは示しません。画像参照の成立と表示結果を分けて扱います。
出力後に見る具体的な値
今回の横書きEPUBで得られた構造値は次のとおりです。
| 確認項目 | 結果 |
|---|---|
| 元原稿 | 4ファイル・4章 |
| 本文画像 | 0枚 |
| 収録画像 | 1枚（表紙） |
| 欠落画像 | 0件 |
| ナビゲーション文書 | あり |
| navの4リンク | 序章、展開、転換、結び |
| NCX | あり |
| OPF書誌 | 作品名、作者、出版社、言語、日付、識別子を確認 |
| 表紙 | cover.xhtmlから画像参照あり、cover-image資源あり |
| 読む順番 | 表紙、表題、目次、本文4章、奥付 |
| spine項目数 | 8 |
| ローカル構造判定 | valid=true、issues 0件 |
ここでの valid=true は、ローカルの構成確認で問題が返らなかったという意味です。販売先の審査合格や、すべてのリーダーで同じ表示になる保証ではありません。
読む順番は、目次の見た目だけでは判断できません。表紙、表題、目次の後にC01〜C04が並び、最後が奥付であることを一行ずつ照合します。spineが8項目なら、その8項目の内訳を作品カードの横へ書き、本文4章のどれかが抜けていないか、同じ章が二度入っていないかを見ます。章ファイル名と見出し名を対にすると、今回のC03.mdが「転換」へ対応していることも確認できます。
書誌情報は、表紙画像のように目で見える項目だけではありません。作品名、作者名、出版社、言語、日付、識別子を入力カードと一字ずつ比べます。今回の出力では具体値まで読み取れました。全角・半角の空白、作者名の区切り、日付形式が変わると、同じ作品でも別の表記として残ることがあります。シリーズ物なら巻番号も加え、前巻と表記方法をそろえます。
別リーダーで試す段階では、表紙が最初に出る、目次4項目が各章へ移動する、縦または横の組み方向が予定どおり、奥付まで進める、の四点に絞ります。構造確認を通過した後に表示だけを見ることで、問題がEPUBの構成要素の不足なのか、リーダー固有の表示なのかを切り分けやすくなります。
Rune Studioでの設定と確認範囲
Rune Studioの現行Mac版の公開機能説明では、6ページのEPUBウィザードで作品情報、巻、原稿選択、順序ともくじ掲載、版・発行日・表紙、最終確認を設定し、nav.xhtml、NCX、OPFを含むEPUB 3を生成すると案内されています。
今回実際に行ったのは、横書き・日本語・版1.0・発行日2026-09-01の設定、表紙パスの登録、C01〜C04の選択と順序設定、出力、nav・OPF・cover.xhtml・manifest・spineの直接照合です。別のリーダーで開く操作、目次リンクのクリック、表紙・書誌の画面表示は行っていません。KDP審査、販売登録、全リーダーの表示一致も対象外です。
結論：本文、目次、表紙、書誌、順序を別々に見る
EPUB変換の最終確認は、一つの「出力成功」表示にまとめません。今回のように、OPFの具体値、navの4リンク、本文4章の順序、cover.xhtmlの画像参照、cover-image資源、欠落0件を個別に照合します。その構造を通過した後に、必要なら別リーダーで表紙・目次・本文を目視する、という順番が安全です。
EPUB 3出力を備えた現行Mac版は、Rune Studio公式サイトで確認できます。
