この記事の範囲は、EPUB内部の構成確認から閲覧確認までです。販売先の入稿要件、ストア登録、価格、税務、販促は対象外です。epub 制作で縦書き電子書籍を仕上げるなら、原稿が書き終わった時点を完成にせず、六要素（原稿・章順・書誌・目次・表紙・出力物）を「原稿」「作品設定」「章順と目次」「生成したEPUB」「閲覧確認」の五成果物へ集約します。R2に書誌と表紙、R3に章順と目次をまとめ、各成果物の担当・確認者・戻り先を分けて残します。五章小説、表紙一枚、作品情報カード、EPUB初版・二版を主標本にし、入稿前の右開き、2桁数字、感嘆符と疑問符、ルビ、目次からの移動は1200字検査章のサブテストで先に見直します。
仕上げ工程は五つの成果物に分ける
最初に五成果物を責任地図として固定します。R1は誤字やルビの読みを直す「原稿正本」、R2は作品名・著者名・言語・縦書き・表紙を決める「作品設定」、R3は章の読む順番と目次の見出しを管理する「章順・目次一覧」、R4は入力から生成した「EPUB」、R5はそのEPUBを開いて確認した「閲覧確認記録」です。六要素のうち書誌と表紙はR2、章順と目次はR3へ集約します。各行に入力担当、正本の場所、確認者、未決事項、失敗時の戻り先を付け、五つを一冊の作業地図として区別します。
この区切りがないと、生成後に見つけた誤字をEPUB内部のXHTMLへ直接書き、次の生成で修正が消えることがあります。本文の問題は原稿へ、右開きや段落の問題は作品設定へ、章の並び違いは章順へ戻す、と修正先を先に決めておくと再生成のたびに迷いません。
六要素を五成果物へ集約する
六要素をそのまま六つの作業箱にすると、書誌と表紙、章順と目次の確認が別々になり、どちらへ戻るべきかが曖昧になります。そこでR1を原稿正本、R2を作品設定（書誌・表紙）、R3を章順・目次一覧、R4を生成EPUB、R5を閲覧確認記録とします。R1〜R5は五つの成果物ですが、R2とR3の中に二つずつの要素を受け持つ構造です。
主標本は五章小説、表紙一枚、作品情報カード、EPUB初版・二版です。初版と二版を別名で残し、どの章順、書誌、表紙、出力物を比較したかを一行で記録します。ここでいう主標本は本編へ適用する責任地図の基準であり、製品が五章を自動的に完成させるという意味ではありません。
先に1200字の検査章を作る
主標本へ進む前に、約1200字の検査章を一つ用意します。これは五章主標本を置き換えるものではなく、R1〜R5の受け渡しと検査項目を短く確認するサブテストです。本文には「12時」「!?」「佐々木」「々」「東京（とうきょう）」のように、縦書きで見え方を確認したい要素を入れ、R2の書誌・表紙、R3の章順・目次、R4の出力物、R5の閲覧確認へ同じ記録欄を渡します。
検査章で見るのは、文字が美しいかという好みではありません。2桁数字が意図したまとまりに見えるか、記号の向きが読みを妨げないか、ルビが親文字と対応しているか、ページ送りが右開きになっているか、目次の項目から正しい章へ移動できるかです。合否を五行の表にしてから本編へ広げます。
原稿・設定・生成物を同じ名前にしない
たとえば原稿を novel-source、設定記録を book-settings、生成物を book-check-01.epub とします。再生成したら末尾を02へ進め、古いEPUBを残します。同名で上書きすると、修正前の表示と比べられず、直ったと思った箇所が別ファイルだったという事故が起きます。
修正記録には「対象」「見えた問題」「戻した場所」「新しいEPUB名」の四点だけを残します。例は「12時／数字が一文字ずつ離れる／作品設定と原稿を確認／book-check-02.epub」です。担当者名や長い感想より、次の人が同じ場所へ戻れる記録を優先します。
Rune Studioで五工程を一つのワークスペースに置く
現行Mac版Rune Studioの公開機能資料では、原稿や資料をワークスペースで管理し、6ページのEPUBウィザードで作品情報、巻、原稿、章順、メタデータ、最終確認を分けて設定できます。縦書きでは右から左のページ進行と、2桁数字や記号を扱う処理をEPUB 3出力へ反映する機能が実装されています。
ここで言えるのは画面と処理が存在することまでです。検査章が合格したことや、販売先の全端末で同じ表示になることまでは意味しません。Rune Studioを使う場合も、生成後のEPUBを別の閲覧環境で開く出口確認は残してください。
構造確認と閲覧確認を混ぜない
EPUBファイルが開いたからといって、構造まで正しいとは限りません。構造確認では、作品名や著者名、収録した章、読む順番、目次項目、表紙の有無を、設定記録と照合します。閲覧確認では、実際にページを送り、目次から各章へ移動し、検査章の数字・記号・ルビを読みます。前者は「何を入れたか」、後者は「どう読めるか」の確認です。
たとえば目次に第二章が表示されても、移動先が第一章なら構造または章対応の問題です。右開きでもルビが別の語へ付いていれば原稿・変換の問題です。「表示が変」という一行でまとめず、構造と閲覧のどちらで見つけたかを残せば、修正先を絞れます。
二周の記録はR5へ集めます。一周目の構造確認ではR1〜R4のどの行を照合したか、二周目の閲覧確認ではR4の初版または二版を開き、どの検査項目を読んだかを残します。作業を中断して再開するときは、保存済みのR1〜R5責任地図と1200字サブテストの同じ見出し・記号・戻り先を開き、最後に未確認だった行から続けます。ここで確認するのは保存済みの責任地図から同じ成果物と戻り先へ再開する手順であり、アプリ終了・再起動後の復元を製品結果として扱いません。
向く人と別の方法が向く人
原稿、表紙、章順、作品情報を一つの作品単位で管理し、縦書きプレビューからEPUB生成までの受け渡しを減らしたい人にはRune Studioが候補になります。一方、すでに完成した第三者製EPUBを直接修復したい人や、固定レイアウト本を作る人は別の編集・検査手段が必要です。
したがって、この記事の完成条件は入稿ボタンを押せることではなく、六要素がR1〜R5へ集約され、五章主標本の初版・二版と1200字サブテストの検査項目をたどり直せることです。販売先ごとの要件確認と、アプリ再起動後の復元は、別の工程または対象外として扱います。
結論：本編へ広げる前に検査章を一度生成する
縦書き電子書籍のEPUB制作では、原稿完成から一気に入稿へ進みません。1200字の検査章を作り、右開き、2桁数字、記号、ルビ、目次移動を確認し、問題を原稿・設定・章順の正しい場所へ戻します。合格後に同じ条件を五章へ適用すれば、全編を作ってから基本設定の誤りに気づくやり直しを減らせます。
Rune Studioを候補にする場合は、Rune Studioの商品ページで現行Mac版の範囲を確認し、まず検査章と仮表紙だけのワークスペースから始めてください。
