入稿前に縦書きを確認!電子書籍EPUBの作り方、縦書き小説向けに崩れを防ぐ設定

縦書き小説を六つの受け渡し工程でEPUBにするアイキャッチ

電子書籍EPUBの作り方を縦書き小説へ当てはめるときは、生成操作を細かく説明するより、六画面ごとに「誰が入力し、何を正本とし、誰が確認するか」を決めると迷いにくくなります。この記事の中心は、Generatorの生成手順そのものではなく、六画面で入力責任を受け渡し、生成後の構造確認と閲覧確認へつなぐ表を作ることです。第一章・第二章を各400字、合計800字にした同一試作を固定ID 154-800-v1 の主標本として、責任の抜けを見つける確認材料に使います。この主標本は途中で第三章を足したり字数を調整したりせず、六画面の責任表から生成担当、構造確認一周、閲覧確認一周へ同じ版を渡します。

画面1:作品情報の正本と確認者を決める

作品名、著者名、言語、書字方向を作品情報の正本へまとめ、入力担当と確認者を別欄にします。縦書きと右開きは一冊全体の条件として確認しますが、本文ファイルの担当者が独断で変更する欄ではありません。表紙に表示する題名と、メタデータへ入力する題名が同じかも、作品情報の確認者が照合します。

表記揺れがある場合は、画面1で未決として残します。全角空白、記号、著者名の異体字を後の画面で直すと、どの値が正しいのか分からなくなるためです。「入力済み」と「確認済み」を同じ状態にせず、確認者の名前または役割を記録します。

画面2:巻と構成単位の入力責任を分ける

単巻なら対象の一巻、複数巻なら今回作る巻を明示します。前巻の設定を複製した場合は、巻名、番号、表紙、収録章が残っていないかを、巻を選ぶ担当者が確認します。作品情報の正本との対応を一行で残し、巻の選択と本文の修正を同じ担当作業にしません。

巻の範囲が決まっていない状態で原稿を整え始めると、対象外の章を修正しやすくなります。画面2の確認者は「今回の生成対象」を確定し、前巻との連続性や長編全体の校正は別の記録へ分けます。

画面3:原稿の収録候補と正本を照合する

原稿の入力担当は、収録候補のファイル名、章名、正本の場所を一覧にします。同名の旧稿がある場合は、採用しない理由を残します。ファイル数だけを数えず、各章の先頭一文や更新日を照合すると、似た名前の原稿を取り違えにくくなります。

第一章・第二章を各400字にした主標本を使う場合も、本文、会話段落、2桁数字、記号などをどの原稿から持ってきたかを記録します。この同じ800字の標本を画面1〜6の入力責任表へ渡し、第三章を追加しないまま生成担当、構造確認一周、閲覧確認一周へ引き継ぎます。表紙画像をこの段階で用意するなら、最終デザインを確定したという意味ではなく、入力として参照する場所を決めたという意味に限定します。画像寸法や販売先の要件は、六画面の入力責任とは別に確認します。

画面4:章順と目次名の確認者を決める

ファイル名の辞書順へ任せず、第一章、第二章の順を入力担当が確定します。目次に表示する名前、収録ファイル、確認者を一対一で記録し、序章やあとがきを掲載するかも未決事項として残します。章名の入力者と、実際の順を読む確認者を分けると、入力した値をそのまま正しいと扱わずに済みます。

右開きの見た目が整っていても、目次の項目が別の章へ移るなら画面4の確認は未完了です。ここで扱うのは章順と目次の責任であり、生成後の細かな表示崩れをこの画面の担当者へ押し戻さないことが境界になります。

画面5:メタデータと任意項目の未決を分ける

作品名、著者、言語など、画面1の正本と重なる項目を再照合します。必須の入力、任意の入力、確認待ちの入力を区別し、空欄だから自動的に誤りだとは決めません。識別子や販売先固有の情報は、利用する流通先の要件を別資料で確認し、画面5の担当者が推測で埋めないようにします。

縦書き表示へ直接関係しないメタデータでも、一冊を識別する責任があります。一方、価格、税務、販売文はこの作り方の対象外です。制作側の入力責任と販売登録の責任を混ぜないことが、確認者を明確にする助けになります。

画面6:最終確認で六画面を引き継ぐ

最終確認では、画面1から5までの作品情報、巻、原稿数、章順、表紙、メタデータを六行の受け渡し表で読みます。最後の画面へ到達したことだけを完了条件にせず、各行に入力担当、正本、確認者、未決事項の状態があるかを確認します。

前回の試作から変えた値には変更理由を付けます。表紙を差し替えた、章名を修正した、巻を切り替えたという変更を一つの「更新済み」にまとめず、影響する画面へ戻します。生成前には、生成物の構造確認担当と閲覧確認担当へ渡す項目も記録します。出力後に修正が見つかった場合は、画面1〜5のどの正本へ戻すかを明示し、六画面の責任表を更新します。入力が確定したことと表示が確認済みであることを同じ状態にしないことが境界です。

画面6でも、画面3で選んだ固定ID 154-800-v1 の第一章・第二章各400字の標本を別の原稿へ差し替えず、そのまま生成担当へ渡すと明記します。標本の章名、各400字、合計800字、版名が六画面の表で同じなら、生成前の入力責任と生成後の確認結果を一つの標本として照合できます。

六画面の入力責任を表にする

受け渡し表には、画面番号、入力担当、正本のファイルまたは記録、確認者、未決事項、次の担当を置きます。たとえば画面3で原稿担当がファイルを選び、画面4で章順の確認者が並びを確定し、画面5でメタデータ担当が未入力理由を記録します。役割名だけでなく、何を見て確認したかを一行で残してください。

この表の目的は、六つの画面を通過したという事実を作ることではありません。どの値を誰が受け取り、どの正本へ戻せるかを明確にすることです。未決事項が残る画面は、任意項目なのか確認待ちなのかを分け、次の画面へ曖昧なまま渡しません。

Rune Studioで確認できる六画面

現行Mac版Rune Studioの公開機能資料には、作品情報、巻、原稿、章順、メタデータ、最終確認を扱う6ページのEPUBウィザードと、EPUB 3を生成する機能が記載されています。縦書きでは右から左のページ進行、2桁数字・記号処理を出力へ反映する範囲も資料上で確認できます。

これは資料で確認できる現行機能の範囲です。六画面の責任表が自動で完成すること、二章試作が実測で合格すること、全端末で表示が一致すること、ストア入稿が成功することは示しません。Rune Studioを候補として確認するときも、画面ごとの入力担当・正本・確認者を手元で記録し、資料上の機能範囲と作業結果を分けます。

作品情報、組み方向、ページ順、出力ファイル名を表示したEPUB出力前の確認画面
作品情報、組み方向、ページ順、出力ファイル名を表示したEPUB出力前の確認画面。

生成後の構造と閲覧確認へ引き渡す

六画面の入力が確定したら、画面3で選んだ第一章・第二章各400字の標本を含む「作品情報・巻・原稿・章順・メタデータ・最終確認」の受け渡し表を生成担当へ渡し、生成後の確認担当を別に置きます。構造確認の一周目では、EPUB内の章ファイルの並び、目次の項目と本文の対応、作品情報・著者名・言語などのメタデータを、画面4・5の正本と照合します。ここで未一致があれば、該当画面の担当へ戻します。

閲覧確認の二周目では、同じ第一章・第二章各400字の生成EPUBを対象の閲覧環境で開き、縦書きの向き、右から左のページ進行、2桁数字と記号の見え方を確認します。構造が正しくても表示が崩れることがあるため、構造確認を終えたという理由で閲覧確認を省略しません。結果は「確認項目・担当者・参照した正本・未決・戻り先」で残し、六画面へ修正を返せる状態にします。

この二周は、Rune Studioが全端末で表示成功したという実測結果ではありません。生成物を構造と閲覧に分けて確認するための受け渡し手順です。

次に行う操作:二章標本だけで章順と目次を固定する

次に行う操作は、固定ID 154-800-v1 の第一章・第二章各400字、合計800字の標本だけを対象にします。第三章や別の字数の本文は、この確認へ混ぜません。まず六画面の受け渡し表で第一章から第二章の順と目次二項目を固定し、画面4・5の正本、確認者、版名を記録します。その同じ版を構造確認の一周目、閲覧確認の二周目へ渡し、章順、目次の移動、縦書き、右から左、2桁数字・記号の結果と戻り先を記録します。不一致があれば該当画面の正本へ戻り、二章標本を変えずに再確認します。

結論:六画面ごとに正本と確認者を残す

縦書き小説のEPUB制作では、六画面を進む回数ではなく、各画面で入力責任が閉じているかを確認します。作品情報、巻、原稿、章順、メタデータ、最終確認のそれぞれに、正本、入力担当、確認者、未決事項を置きます。主標本である固定ID 154-800-v1 の第一章・第二章各400字、合計800字の同一試作を六画面の責任表から構造確認の一周目、閲覧確認の二周目へ渡し、第三章を追加せず、問題があればどの画面へ戻るべきかを表に残してください。

六画面の範囲と縦書き出力の資料上の確認事項は、Rune Studioの商品ページで照合できます。