縦書きで崩さない！KDPの縦書き、ルビ・縦中横・記号処理

KDP向けの縦書き原稿は、全章を一度に直す前に、一章だけを標本にしてルビ、2桁の縦中横、!?、ダッシュの四種類を確認します。標本で採用する表記規則を決め、その規則だけを全章へ広げるのがこの記事の答えです。縦書きという理由だけで、すべての数字や記号を同じ置換へかけてはいけません。

例では第一章から、ルビ6件、2桁数字10件、!?8件、ダッシュ4件を拾います。件数は完成条件ではなく、取りこぼしを発見するための標本台帳です。章順、表紙、作品情報、全章の出力工程は扱いません。生成EPUB内部のCSSやpackageを診断する記事でもありません。

一章標本に四種類の所在を記録する

第一章の複製を作り、各対象へ種類と通し番号を付けます。ルビはR01からR06、2桁数字はT01からT10、!?はP01からP08、ダッシュはD01からD04です。原稿の段落番号と前後十文字も記録すると、表示後に同じ箇所へ戻れます。

対象は見た目だけで選びません。ルビなら親文字と読みの組、数字なら桁数、記号なら実際の文字値を確かめます。半角のハイフン、長音、全角ダッシュは似て見えても別物です。ひとつの置換規則にまとめる前に、作者がその文字を何のために使ったかを分けます。

一章に対象が足りない場合、別章から文を移して件数を作りません。実在する件数を記録し、不足する種類は短い検証用複製で補います。本文へ検証用文を残さないよう、標本と採用原稿の名前を分けます。

ルビは親文字と読みの対で追う

ルビ6件は、親文字、読み、原稿記法、縦書き表示の四点を一行にします。「星霜」に「せいそう」を付ける例なら、親文字が途中で切れていないか、読みが次の語へ離れていないか、前後の句読点がルビ範囲へ入っていないかを見ます。

同じ漢字が再登場しても、自動的に同じ読みとは限りません。固有名詞と一般語、熟字訓と一字ルビを別の採用規則にします。ルビが表示されたというだけで読みの正誤は確認できないため、台帳の親文字と読みを声に出さず文字単位で往復します。

直すときは表示側へ読みだけを足さず、原稿の親文字とルビ記法へ戻ります。読みが孤立したまま見た目だけを合わせると、別の端末や再生成で関係が失われます。

2桁だけを縦中横の候補にする

2桁数字10件では、10、24、99のような二文字の範囲を確認します。期待する状態は、縦一列の中で二桁が一つの横組み単位として収まり、前後の文字の行送りを不自然に広げないことです。

100や2026を先頭二桁だけ縦中横にしないでください。三桁以上、年号、章番号、時刻は意味ごとに表記方針を決めます。たとえば時刻の10:30は、10と30だけを処理するのか、漢数字へ直すのか、コロンを含めた別表記にするのかを作品規則へ書きます。

標本では十件それぞれについて、元の桁数、期待するまとまり、表示結果を記録します。自動処理の候補になっても、作者の意図した表記と同じとは限りません。2桁という形と文章上の役割を両方確認します。

!?は対としての向きと占有幅を見る

!?8件は、感嘆と疑問を組み合わせた一つの表現として扱うのか、二つの記号として続けるのかを先に決めます。縦書き表示では、対が不自然に横倒しにならないか、一文字相当の範囲にまとまるか、直後の閉じ括弧やルビと衝突しないかを見ます。

?!や全角の！？が混在するなら別種類です。検索で!だけを数えると対の向きや順番を失うため、実際の連続文字で拾います。P01からP08まで期待形を記録し、混在を作品上許す場合は意図も添えます。

端末差をゼロにするとは断定しません。一章標本で確認するのは、採用した原稿記法と縦書き候補の関係です。KDPの受理や全Kindle端末での同一表示は別の確認です。

ダッシュは連続性と縦方向の見え方を目視する

ダッシュ4件は、会話の間、語尾の引き延ばし、場面転換など用途を分けます。縦書きでは線が縦方向に連続して見えるか、二本を使う箇所で不自然な隙間が出ないか、長音や罫線へ置き換わっていないかを目視します。

ここではRune Studioがダッシュを必ず自動変換すると主張しません。公開資料に明示された2桁数字や!?の自動処理と、作者が目で判断するダッシュ確認を分けます。線の長さや接続はフォントや表示環境にも関係するため、一種類の見た目を万能な正解にしません。

D01からD04の実文字値を記録し、必要なら採用文字へ統一します。ハイフンをダッシュに見立てて残す、画像化して固定する、すべてを同じ文字へ機械置換する、といった近道は標本の意味を失わせます。

標本で採用規則を決めてから全章へ広げる

四種類の確認後、作品規則を種類ごとに一文で確定します。ルビは親文字と読みの組を保持する。縦中横は意味を確認した2桁だけ。!?は採用した順序と幅で統一する。ダッシュは採用文字と本数を用途別に保つ、という具合です。

全章へ広げるときは、まず検索結果の件数だけを保存します。その後に種類別に一括候補を確認し、再検索で残件を数えます。一括置換後の件数ゼロだけでは、三桁数字の一部や固有名詞のルビを誤って変えたことを検出できません。変更前後の該当箇所を比較します。

全章展開後も第一章標本を再び開き、R06、T10、P08、D04の最後の項目まで到達できるかを確認します。最初の一件だけの成功を全件成功として扱わないためです。

Rune Studioで確認できる範囲を限定する

Rune Studioの現行Mac版の公開説明では、縦書きプレビューはvertical-rl相当の縦組み表示を行い、縦書き時には2桁数字、!?、文字幅を自動処理します。表記法の挿入からルビ記法を入れる機能も説明されています。

2026年8月14日の複製した標本での動作確認では、ルビ記法の挿入、縦書きEPUB内部での2桁数字と!?の処理、縦書きタブ状態の保存と再読込を確認しました。これは生成物構造とタブ状態の実機確認結果です。

縦書きプレビューの実画面、例の6件・10件・8件・4件、ダッシュの見た目、全章展開は未確認です。したがって各件数と視覚結果は標本の期待状態であり、Rune Studioで完遂済みの測定結果ではありません。KDP受理と全Kindle端末の同一表示も対象外です。

製品プレビューは原稿段階の確認場所です。生成後のXHTMLでwriting-modeや縦中横の要素構造を調べる作業は、内部構造を扱う「生成EPUBの縦書き内部構造確認」へ渡します。

KDP入稿用の原稿整理とは判断の中心を分ける

本記事と「KDP入稿用の縦書き原稿整理」は、同じ縦書きKDP原稿を扱っても中心が異なります。

作品全体の章順・表紙・書誌は縦書き小説全体の制作手順、生成後のwriting-modeや縦中横要素はEPUB内部構造の確認で扱います。本記事は生成前の第一章で四種類の採用規則を確定するところまでです。

結論：四種類を数え、意味を保った規則だけ広げる

第一章でルビ6件、2桁数字10件、!?8件、ダッシュ4件を別々に記録します。ルビは親文字との対、2桁は意味と範囲、!?は順序と幅、ダッシュは実文字と連続性を確認し、採用規則を種類ごとに確定してから全章へ広げます。

最初の行動は、第一章のルビをR01から番号付けし、親文字と読みを二列で記録することです。Rune Studioを候補にする場合は、Rune Studioの商品ページで縦書きプレビュー、2桁数字・!?の処理、ルビ入力の現行範囲を確認できます。