電子書籍 制作を調べているなら、縦書き小説を原稿、組版、目次、表紙、生成、閲覧確認の六工程に分けて受け渡します。組版、目次、表紙、奥付を同じ「完成品」の一部として一度に扱わず、各工程の入力版と確認結果を固定します。対象は五章小説、目次五項目、表紙一枚、奥付一枚です。この記事では、縦書き小説で見落としやすい確認点を工程ごとに切り分け、どこまで確認できたら次へ渡すかを固有例で説明します。販売登録、価格、宣伝、固定レイアウトは扱いません。
直接回答：原稿・組版・目次・表紙・生成・閲覧確認を六工程にして受け渡す
結論は、五章小説の原稿を固定し、縦書き組版、目次、表紙・奥付、生成、閲覧確認を順に別工程として渡すことです。六工程を分けると、縦書きの数字や記号の崩れを目次の抜け、表紙の取り違え、奥付の入力漏れ、生成物の不整合、閲覧時の読み違いと混同しません。
工程表には「入力版」「この工程だけで確認すること」「次へ渡す成果物」「不一致時の戻り先」を書きます。五章小説の固有例では、各行に版名を付け、次の工程が前の工程の確認済み成果物だけを受け取るようにします。表紙を差し替えたからといって、本文の組版を確認済みとは扱いません。これは機能の多さではなく、成果物の責任範囲を分けるための決め方です。
六工程の受け渡し条件は次の表で固定します。
| 工程 | 入力版 | 工程固有の確認 | 次へ渡す成果物 | 不一致時の戻り先 |
|---|---|---|---|---|
| 原稿 | S086-draft-v1 |
五章の本文、章ID、章題、入力文字列が正本と一致する | S086-manuscript-v1 |
原稿の正本 |
| 組版 | S086-manuscript-v1 |
縦書き、第12話、ルビ、場面区切りの表示と位置 |
S086-typeset-v1 |
原稿または組版設定 |
| 目次 | S086-typeset-v1 |
目次五項目の表記・順番・章IDリンク | S086-toc-v1 |
章順の正本または目次入力 |
| 表紙 | S086-toc-v1 |
表紙一枚のタイトル・版名と、奥付一枚の発行情報 | S086-front-v1 |
表紙画像または奥付入力 |
| 生成 | S086-front-v1 |
生成物が開き、六工程の版対応とEPUB構造が記録される | S086-epub-v1 |
生成条件または直前工程 |
| 閲覧確認 | S086-epub-v1 |
読み順、縦書き表示、目次移動、表紙・奥付の見え方 | S086-view-v1 |
該当する原稿・組版・目次・表紙・生成工程 |
この表では、奥付を表紙工程の非本文情報として確認します。生成できたことだけでは次へ渡さず、入力版と固有確認が埋まった行だけを次工程の入力にします。
五章小説を組版工程へ渡す
最初の対象は五章小説です。原稿の複製を一つ作り、章題、本文の順番、縦書きで確認したい文字を印します。固有例として、第一章に「第12話」、第三章にルビ、第五章の場面区切りを置きます。ここで見るのは、章題が意図した順番で並ぶこと、二桁数字が縦書きの中で読めること、ルビと本文の対応が崩れていないこと、場面区切りが本文の位置を変えていないことです。
この工程で「第12話」の表示が読みにくくても、目次の文言を直して済ませません。数字の向きや縦中横の扱いに関する問題なら組版工程へ戻し、本文の誤字なら原稿へ戻します。組版の確認が済んだ成果物には版名を付け、目次工程が参照する本文の章題と章順を添えます。こうして、目次の検査で本文の見た目まで再判定する必要を減らします。
目次を本文から切り離して照合する
目次五項目は、本文から自動的にできたように見えても、独立した受け渡し物として確認します。目次工程では、五つの項目数、表記、並び順、各項目が指す章を表にします。第一章から第五章までが一項目ずつあり、章題の「第12話」のような表記も本文と一致している状態が期待値です。
固有の失敗例は、本文では第三章なのに目次の三番目が第二章を指すケースです。この場合、組版の文字表示が正しくても目次工程は閉じません。本文の章IDと目次の移動先を照合し、不一致が章順に由来するなら目次の入力へ、章題の変更に由来するなら本文と目次の両方を更新対象へ戻します。目次が五項目あるという数だけで合格にしないことが重要です。
表紙と奥付を本文と別に確定する
表紙一枚は、本文の組版結果と別の入力として扱います。表紙工程では、対象作品のタイトルと版名を照合し、別作品の画像や旧版の画像を受け渡さないことを確認します。本文を修正しても表紙が変わらないなら、その事実を「表紙は変更なし」と記録します。逆に表紙を差し替えた場合も、本文や目次を再確認したことにはなりません。
奥付一枚は、発行情報の入力を本文の末尾に直接書き足しただけで完了としません。奥付工程の入力欄に、作品名、著者名、発行日など、今回記載する項目を先に並べ、空欄と旧版の値を区別します。固有例として、五章小説の本文を一字修正した回でも、奥付の発行情報が旧版のままなら、本文の組版工程ではなく奥付工程へ戻します。表紙と奥付を別工程にすると、画像の問題と文字情報の問題を同じ修正として扱わずに済みます。
六工程を一つの生成前後表でつなぐ
六工程を最後に結びます。表の行を「原稿」「組版」「目次」「表紙」「生成」「閲覧確認」とし、列を「入力版」「工程固有の確認」「次へ渡す成果物」「戻り先」にします。五章小説の章順は原稿行と組版行、目次五項目と章IDは目次行、表紙画像の版名と発行情報は表紙行、生成物の構造は生成行、読者の読み順と表示は閲覧確認行に置きます。
生成前後で確認するときも、六行を一つの曖昧な「表示確認」にまとめません。生成できたこととは別に、原稿の正本、組版の表示、目次の移動先、表紙と奥付の対象、生成物の構造、閲覧時の見え方をそれぞれ照合します。どの行にも結果が書けないなら、その成果物は次工程へ渡さず保留にします。受け渡し表があれば、五章のどこを見たか、非本文要素のどれが未確認か、どの版へ戻るかが残ります。
二周目の検査で戻し先を決める
一周目は、原稿、組版、目次五項目、表紙・奥付、生成物、閲覧確認の六工程を順に確認します。二周目は同じ順番を漫然と繰り返すのではなく、前回の不一致があった行と、その影響を受けた行だけを再確認します。第一章の「第12話」で縦書き表示に問題があったなら組版行を再確認し、目次の第三項目のリンク先が違ったなら目次行を再確認します。
二周目の固有の停止線は三つです。組版の修正で章題や章順まで変わった、目次の修正で本文にない項目が残った、表紙または奥付の差し替えで版名が混ざった、のいずれかに当たったときです。停止線に触れたら「全部を最初からやり直した」と書かず、該当する工程と受け渡し物を記録します。六工程を分けた目的は、修正の影響範囲を小さく説明することだからです。
制御された二周目：一項目だけ直して別版を比較する
五章標本の初版 S086-draft-v1 から S086-epub-v1 までを固定し、定義済み確認項目を一つだけ選びます。たとえば第一章の章題「第12話」の表記を一文字分だけ修正し、他の章、ルビ、場面区切り、目次五項目、表紙一枚、奥付一枚、設定は変えません。修正後は S086-draft-v2 から S086-epub-v2 までを別版として再生成し、初版を上書きしません。二周目の比較表では、六工程の入力版、工程固有の設定、生成物ID、章順、目次移動、表紙・奥付、閲覧結果を初版と横並びにし、差分が現れた工程と位置、戻り先を記録します。差分がない項目も差分なしと残し、一項目以外の変更を理由に採否を決めないことが制御条件です。
Rune Studioが候補になる範囲
公開機能資料では、Rune Studioの現行Mac版について「vertical-rlの縦書きプレビューと、右開き・縦中横・記号処理を含むEPUB 3出力を備える」という機能範囲が確認できます。そのため、縦書き電子書籍を原稿・組版・目次・表紙・生成・閲覧確認へ分けて受け渡す用途の候補にはなります。ただし、これは公開資料で確認した機能範囲であり、五章小説、目次五項目、表紙一枚、奥付一枚がこの工程で合格したという実測結果ではありません。
向いているかを判断するときは、公開資料にある機能の存在と、手元の六工程の検査結果を別々に記録します。販売登録、価格、宣伝、固定レイアウトや外部サービス側の受理までを、この機能範囲から推測しません。
結論：六工程の固有例を受け渡し表に残す
電子書籍 制作で持ち帰るのは、原稿、組版、目次、表紙、生成、閲覧確認を六工程に分け、五章小説の固有例を各行へ残す方法です。原稿の五章と章IDは原稿行、第一章の「第12話」・第三章のルビ・第五章の場面区切りは組版行、目次五項目と章IDは目次行、表紙の版名と発行情報は表紙行、EPUBの構造は生成行、読み順と見え方は閲覧確認行で扱います。
まず複製した標本で一周し、各工程の入力版、固有確認、次へ渡す成果物、戻り先を記録してください。二周目で問題が出たときは、原稿の文字なら原稿、数字や記号なら組版、章題や移動先なら目次、画像や発行情報なら表紙、構造なら生成、読み順や表示なら閲覧確認へ戻します。Rune Studioを試す場合も、公開機能資料の範囲と、手元の標本で確認できた事実を混ぜないことが、縦書き電子書籍を安全に見直す出発点になります。
