縦書き小説のEPUB制作ソフトをすでに決めているなら、章を追加・差し替えた後に必要なのはソフトの再比較ではありません。変更した章を「作品設定票」と照合し、数字、記号、ルビの書き方が既存章からずれていないかを見つけ、縦書き方向と右開きを一冊全体の設定へ戻すことです。崩れを見つけたら、生成済みEPUBを手直しせず、原稿または作品設定へ戻して直します。
この記事では、安定している第1章を基準に、差し替えた第2章と新しく加えた第4章だけを監査する例を使います。複数のEPUBエディターを比べたり、複数リーダーの表示を採点したりはしません。選定後の一冊で、変更により設定が少しずつ漂う「設定ドリフト」を止めるための記事です。
作品設定票を、一冊の戻り先にする
作品設定票には、見た目の好みだけでなく「どこを直せば一冊へ反映されるか」を書きます。数字、記号、ルビは主に原稿側で管理し、縦書き方向と右開きは作品全体の設定として管理する、というように所有場所を分けます。章ごとに同じ判断をやり直すのではなく、迷ったときに戻る一つの基準にします。
数字の欄には、二桁数字を縦中横で見せる場面と漢数字を使う場面を、作品内の短い代表例と一緒に記録します。記号の欄には、ダッシュ、三点リーダー、括弧など、表記揺れが起きやすい文字の採用形を置きます。ルビの欄には、どの語へルビを付けるかだけでなく、原稿内で使う表現方法も記録します。
縦書き方向と右開きは、章ごとの好みではありません。一冊を通した読み方向に関わるため、作品設定票では「全体設定」と明記します。新しい章の原稿に似た設定らしき記述があっても、その場で採用せず、全体設定との関係を確認します。
追加章と差し替え章だけを変更集合に入れる
毎回すべての章を最初から読み直すと、変更箇所と既存の表記癖が混ざります。そこで今回触った章だけを「変更集合」にします。例では、安定章をC01、差し替え章をC02-R2、追加章をC04と呼びます。C01は修正対象ではなく、作品設定票どおりの実例を探す比較基準です。
C02-R2とC04について、変更理由と取り込み元を記録します。差し替え章なら、旧版から本文を直したのか、別ファイルを丸ごと受け取ったのかを分けます。追加章なら、別作品のひな型や以前の設定を含んでいないかを確認します。設定ドリフトは、内容を改稿したときより、外部の原稿を取り込んだときに見つけやすいからです。
この段階ではEPUBを出力しません。まず原稿と作品設定票の差を片付けます。生成物を先に見ると、表示上の違いをその場で直したくなり、どの正本へ戻すべきかが曖昧になります。
数字・記号・ルビを章ごとに照合する
数字は、変更章から二桁数字、年月日、話数などを拾い、作品設定票の代表例と比べます。C01では二桁数字を縦中横にする方針なのに、C04だけ漢数字へ直しているなら、意味上の意図があるかを確認します。理由がなければC04の原稿を設定票へ合わせます。どちらが一般的に正しいかではなく、この一冊で決めた方針に戻すのが目的です。
記号は文字の見た目だけで判断しません。似て見えるダッシュや括弧が別の文字として入っていないか、C02-R2とC04の使用箇所をC01の代表例と照合します。意図的な例外なら、例外の理由を作品設定票へ追加します。理由のない差は原稿側で修復します。
ルビは、付いているかどうかと、原稿内での表現方法を分けて確認します。差し替え時にルビが落ちた、追加章だけ別の表現方法になった、対象語の範囲が変わった、という差を探します。作品設定票の代表語を一つ選び、変更章で同じ種類の語が同じ方針になっているかを見ると、全文を漫然と眺めるより差を拾いやすくなります。
「一致・意図的な例外・要修復」に分ける
見つけた差をすべて誤りにはしません。作品設定票と一致するもの、物語上の理由がある意図的な例外、根拠がなく要修復のものに分けます。意図的な例外は原稿へ残し、理由を設定票へ追記します。要修復は変更章の原稿へ戻して直します。「今回は見た目がよいから」という理由だけで例外を増やすと、次の章追加で基準がなくなります。
縦書き方向と右開きは一冊全体で戻す
数字・記号・ルビは章内で差が出ますが、縦書き方向と右開きは一冊の設定として確認します。変更章を追加した後、作品全体の設定がvertical-rlと右開きの方針から外れていないかを見ます。章ファイルだけを見て「縦に見えるから合格」とせず、作品設定票に書いた全体設定を基準にします。
ここで変更章ごとの右開きを採点する必要はありません。右開きは章ごとに競わせる項目ではなく、一冊の進行方向です。もし取り込み元の設定が作品全体へ影響していたら、追加章を個別に飾るのではなく、作品設定へ戻して直します。
修復は生成済みEPUBではなく正本へ戻す
差を見つけたら、数字・記号・ルビは原稿へ、縦書き方向と右開きは作品設定へ戻します。生成済みEPUBの中身だけを直接直すと、次に章を差し替えたとき同じ差が復活します。今回の修復が次回にも残る場所を選ぶことが、設定ドリフト対策の中心です。
修復後は変更集合をもう一度照合します。C02-R2とC04の「要修復」がなくなり、意図的な例外に理由が付いたら、そこで初めてプレビューやEPUB出力へ進みます。安定章C01は変更せず、変更章が既存の作品方針へ戻ったかを確認します。
業界標準、製品対応、Rune固有の処理を分ける
vertical-rlはCSS Writing Modesで定義される縦書きの値で、EPUB 3はW3Cが定めるデジタル出版物の配布・交換形式です。どちらもRune Studio独自の規格ではありません。
Rune Studioの機能資料には、vertical-rlを使う縦書きプレビューと、右開き、縦中横・記号処理を扱うEPUB 3出力が記載されています。これは既存の標準・記法を扱う製品対応の文書根拠です。資料に記載された縦書きプレビュー画面とEPUB出力処理そのものは、Rune Studio固有の画面・処理候補として別に扱います。
いずれもStage 1の文書記載であり、現行版の実画面、操作完遂、出力成功を確認した証拠ではありません。この範囲は、作品設定票へ戻した原稿と設定をプレビューや出力で確認する候補にだけ関係します。
一方、章間の設定ドリフトを自動で発見し、作品設定票へ自動で戻す機能を確認したわけではありません。本記事の変更集合監査は、人が作品設定票と変更章を照合する一般的な方法です。また、本記事には命令、入力、終了コード、生成物まで追試できるEPUB出力結果がないため、特定の二章出力が成功したとは断定しません。C02-R2とC04を使った数字・記号・ルビのドリフト修復も未実施です。
したがって、業界標準の存在や文書化されたRune Studioの対応・処理範囲を、特定出力の成功、すべての変更章が合格した実測結果、全リーダーの表示保証へ広げません。実際の作品では、変更集合を直した後に必要な表示確認を行います。
複数エディターの選定はSTUDIO-080へ譲る
同じ日本語組版標本を複数のEPUBエディターへ渡し、複数のリーダーで比較して候補を選ぶ作業はSTUDIO-080の役割です。この記事では環境はすでに決まっています。候補AとBの採点も、リーダーごとの15セル比較も行いません。
ここでの合格は、変更した章が作品設定票へ戻り、根拠のない数字・記号・ルビの差がなく、縦書き方向と右開きが一冊の設定として保たれたことです。ソフト選定の合格とは別の仕事です。
結論：変更章を設定票へ戻してから出力する
縦書き小説で章を追加・差し替えたら、安定章を一つ残し、変更章だけを変更集合へ入れます。数字・記号・ルビは作品設定票の代表例と比べ、根拠のない差を原稿へ戻して修復します。縦書き方向と右開きは章別ではなく、一冊全体の設定として戻します。
修復先は生成済みEPUBではなく、次回も使う原稿と作品設定です。変更集合の要修復がなくなってからプレビューと出力へ進めば、章を増やすたびに設定が漂うのを防げます。
