入稿前に縦書きを確認!EPUBのバージョン、日本語縦書きでEPUB 3を選ぶ理由

日本語の縦書き、右開き、ルビを電子書籍のパッケージへ持たせたいなら、EPUB 3を選ぶ理由があります。重要なのは「新しい版だから」ではなく、縦書きCSS、ページ進行方向、ruby要素、ナビゲーションを一冊の構造として確認できることです。

この記事では epub バージョン の選択を、三章の縦書き標本で判断します。内部構造として確認できたことと、リーダーの見た目としてまだ確認していないことを分けます。現行Mac版が対象で、実装中のiPad機能は扱いません。

EPUB 3を選ぶ条件を先に書く

縦書き小説で必要なのは、本文を上から下へ組み、ページを右から左へ進め、ルビや日本語記号を意味のあるマークアップとして残すことです。単なるPDFのような固定画像ではなく、リーダーが本文構造を解釈する可変レイアウトを前提にします。

反対に、横書きだけで古い端末互換を最優先する本や、固定レイアウトを求める作品では判断が変わります。この記事の結論は、すべての本にEPUB 3を強制するものではありません。縦書きの要件があるときの選び方です。

合格条件は、series設定がvertical、生成物のページ進行がrtl、CSSにvertical-rlがあり、三章とrubyがパッケージへ入ることです。リーダーで美しく見えることは、別の画面確認に残します。

三章にルビを入れた標本を作る

入力は三章です。各章の「漢字」に対し、rune text ruby --file .../chapter-01.md --match 漢字 --reading かんじ --json を実行しました。第二章、第三章もファイルだけを変えています。三命令とも終了コード0です。

ルビを入れる前後の章ファイルを別の証拠として残すと、生成後にrubyが三件ある理由を説明できます。原稿に一件しかないのに生成物が三件なら、古い章や重複選択を疑うべきです。

今回の標本には !? と漢字も含めました。ただし、記号が縦中横でどの角度・位置に見えたかはCLIで測っていません。文字列がXHTMLへ入った事実と、画面上の組版結果を分けます。

verticalと右開きを生成条件へ入れる

実行したseries命令は rune epub series set --workspace /private/tmp/rune-g2c3-studio-268-b30vqxow --title "STUDIO-268 Verified Title" --author "Synthetic Author" --publisher Publisher-268 --file-name studio-268 --writing-mode vertical --language ja --json です。

巻0はversion 3.1、発行日入力 2026-10-15。三章をselectし、planで fileCount=3、chapterCount=3、全章が目次対象であることを確認しました。表紙はこの標本では指定していません。

失敗値は、writing-modeがhorizontal、章順が意図と違う、目次から章が落ちている、の三つです。planの段階で見つけたらexportへ進まず、それぞれseries設定かselectへ戻ります。

EPUB内部で縦書きの骨格を読む

生成物 studio-268-260903.120000.epub のSHA-256は e23ae6ccae06bb74cdfd1e68ad351953fd4279bfa36062cfd30dcdf717c85b6a です。inspectは valid=true を返し、entryは11件でした。

パッケージでは page_progression_direction=rtl、縦書きCSSあり、ruby_count=3です。spineはtitle、nav、三章、colophonの6項目で、画像参照は0件。三章のXHTMLに !? と漢字のマーカーが残っています。

この数値はEPUB 3を選んだ結果として、縦書き本の骨格を機械的に追えることを示します。単に拡張子が.epubであることより、要件とパッケージ値を結び付けられる点が選択理由です。

navは三件、NCXも三件で、参照先は対応しています。しかしnavラベルは全角の STUDIO-268 Chapter 1 形式、NCXは半角の STUDIO-268 Chapter 1 形式でした。そのため nav_ncx_same_labels=false です。

これは縦書き機能の失敗ではありませんが、目次の表記差として合格票に残ります。件数が同じだから同一と判断せず、KDPや対象リーダーでどちらが表示されるかを確認するか、生成前にラベルを統一します。

このように、構造検査は「成功」と「未解決」を同じ結果内に持てます。valid=trueを理由に目次差を消さないことが、入稿後の手戻りを減らします。

画面で見ていないことを断定しない

今回測ったのはCSS、rtl、ruby要素、章順、目次データです。ルビの字間、縦中横の見え方、句読点の位置、ページめくりの体感は独立して判断していません。パッケージに要素があることと、特定リーダーの表示が正しいことは別です。

KDP受理や全端末の一致も確認していません。ローカルの生成結果を販売先の保証へ広げることはできません。対象端末が決まっているなら、生成したSHAのEPUBを使って画面検査を追加します。

条件がそろう本にEPUB 3を選ぶ

縦書き、右開き、ルビを構造として保持し、生成後にそれらを検査したい本にはEPUB 3が向きます。横書きだけの文書や固定レイアウトが必須の案件では、別の形式や設定も比較してください。

Rune Studioの現行Mac版は縦書き設定とEPUB生成を同じ作業場で扱う候補です。対応範囲はRune Studioの商品ページで確認できます。三章の複製でrtl、vertical-rl、ruby件数、目次差まで読み、見た目の確認を別に残してから本番へ進めてください。