KDPのepubでルビが崩れるのはなぜ？原因と修正手順

「EPUBで作ったのに、KDPへ入れるとルビだけ崩れるのはなぜだろう」と悩む方は少なくありません。

実際には、ルビ単体のミスというより、EPUB構造・変換処理・表示環境の差が重なって起きるケースが多いです。

Zero出版でも、Word直入稿では問題が見えず、Previewerや実機確認で初めてルビずれが発覚した事例を何度も確認してきました。

そのため、入稿前にEPUBを検証し、Previewerで複数パターンを確認する運用が安全です。

この記事では、KDP向けEPUBでルビが崩れる主な原因と、実務で再現しやすい修正手順を整理して解説します。

「どこを直せばよいのか分からない」という状態から、確認ポイントを順番に絞り込めるようになるはずです。

KDPのルビ崩れはEPUB構造の確認で改善しやすいです

KDP epub ルビ 崩れる問題の結論は明確です。

まず疑うべきはEPUB内部の構造劣化であり、次に縦書き設定・CSS・表示環境差を切り分けることです。

KDPでは、Word原稿や他ツールから変換したデータがそのまま理想通りに表示されるとは限りません。

特にルビは、本文テキストよりも構造依存が強いため、変換過程の影響を受けやすい要素です。

近年の実務では、Wordを直接アップロードして終えるよりも、EPUB Checkで検証し、Kindle Previewerで表示確認し、必要に応じてHTML/CSSを手修正する流れが重視されています。

Word直入稿だけで問題なしと判断するのは危険です。

入稿後や販売後に読者さんの端末で崩れる可能性があるためです。

ルビが崩れる理由は単純ではありません

変換時にruby構造が劣化するためです

EPUBのルビは通常、<ruby>要素を中心に表現されます。

ところが、Wordや一部の変換ツールを経由すると、不要なタグやスタイルが混ざり、ルビ周辺の構造が壊れることがあります。

Zero出版の検証でも、元原稿では正常でも、変換後のXHTMLを見ると余分なタグや改行がruby内に混入していた例がありました。

この状態では、Previewerでルビ位置がずれたり、行間だけ不自然に広がったりしやすくなります。

縦書きでは表示差が出やすいためです

ルビ崩れは、横書きよりも縦書きで起きやすい傾向があります。

理由は、縦書きではルビに加えて縦中横や句読点処理も絡み、レイアウト計算が複雑になるためです。

特に、漢数字・英数字・記号が混ざる行では、同じEPUBでも端末やアプリで見え方が変わることがあります。

そのため、縦書き作品ほどPreviewerだけでなく実機確認まで行うのが安全でしょう。

不要な改行や空白がルビ位置を乱すためです

リフロー型EPUBでは、画面サイズや文字サイズ変更に応じて本文が再配置されます。

この仕組み上、見た目を整えるための手動改行や全角空白の多用は、あとで崩れの原因になりやすいです。

ルビ付き語句の直前直後に不要な空白や改行コードがあると、行分割の位置が変わり、結果としてルビが不自然に見えることがあります。

紙の組版感覚で空白を入れて微調整する方法は、Kindleでは逆効果になりやすいです。

フォント置換で行間や位置が変わるためです

Kindleでは、端末側の設定や環境によってフォントが置き換わる場合があります。

すると、本文とルビの相対位置、行高、文字幅が変化し、制作者側の想定と異なる表示になることがあります。

特に固定的なpx指定や過度な行間指定を併用していると、フォント差の影響を受けやすくなります。

画像や複雑なCSSが本文フローを壊すためです

本文中に固定幅画像、複雑な回り込み、過剰な余白指定があると、テキストフロー全体が不安定になることがあります。

その影響がルビ行に及ぶと、ルビそのものに問題がなくても、周辺レイアウトの崩れとして現れます。

ルビだけを見て修正しても直らない場合は、前後の段落構造や画像ブロックも確認すべきです。

よくある失敗パターンを先に知っておくと修正が早いです

Word原稿のルビをそのまま信頼してしまうケース

Word上で見えているルビが、そのままKDPで再現されるとは限りません。

Wordは編集画面としては便利ですが、EPUB変換時に不要な書式情報を抱え込みやすいです。

Zero出版で相談を受けた案件でも、Wordでは正常、変換後EPUBではルビが消失、Previewerでは一部だけ行間拡大という段階的な崩れ方がありました。

この場合、Word表示ではなく、変換後のXHTMLを基準に確認する必要があります。

rubyタグの前後に余計なタグが入るケース

変換ツールによっては、rubyの中や前後にspan、em、strongなどが複雑に入り込みます。

見た目には小さな差でも、Kindle変換では解釈差が出ることがあります。

もしルビ付き語句だけ崩れるなら、その箇所のHTMLを抜き出して、最小構成で再確認すると原因を特定しやすいです。

縦書きと縦中横が同時に入るケース

章番号、日付、年齢表記などで数字が混ざると、縦中横とルビが干渉することがあります。

たとえば短い数字列の近くにルビを置いた際、行送りが不自然になることがあります。

この場合は、ルビ対象語句と数字表記を分離できないか見直すと改善する可能性があります。

修正は検証の順番を守ると失敗しにくいです

まずEPUB Checkで構造エラーを洗い出します

最初に行うべきは、EPUBファイルの妥当性確認です。

構文エラーや参照不整合がある状態では、表示崩れの原因が複数重なり、切り分けが難しくなります。

チェック結果にエラーや警告が出たら、先にそこを整理してください。

ルビ崩れに見えても、実際には別のXHTMLやCSS不整合が影響している場合があります。

次にKindle Previewerで複数表示を確認します

公式・実務の両面で、Kindle Previewerによる事前確認は重要です。

確認時は、単に1ページを見るだけでは不十分です。

1. 横書き・縦書きの該当章を開く
2. 文字サイズを複数段階で切り替える
3. ルビ付き語句の前後数行を確認する
4. 画像や改ページ直後の箇所も見る

Zero出版では、少なくとも3段階以上の文字サイズで確認し、ルビ付き本文が連続する章を重点的に見ています。

1サイズだけ正常でも、サイズ変更で崩れる例があるためです。

問題箇所のHTMLを最小構成にします

崩れる箇所が特定できたら、その周辺HTMLを簡素化します。

理想は、ruby要素の周囲に不要な装飾タグを置かないことです。

CSSも、本文全体に強い指定をかけるより、必要最小限に留めた方が安定しやすいです。

複雑な見た目を足すより、構造を減らす方向で修正するのが基本です。

実機でも確認して最終判断します

Previewerで問題がなくても、実機アプリで差が出ることがあります。

特にiPhone、Androidタブレット、Kindle端末では、フォントや描画条件が異なる可能性があります。

可能であれば複数環境で確認し、最低でも自分が想定読者に近い端末で最終チェックを行うと安心です。

実務で使いやすい修正チェックリスト

入稿前に確認したい5項目です

• ルビは正しいruby構造で記述されているか
• Word由来の不要な空白や改行が残っていないか
• 縦書き箇所で数字や記号との干渉がないか
• 固定px指定の画像や余白が周辺にないか
• EPUB CheckとKindle Previewerの両方で確認したか

この5項目だけでも、原因の大半は絞り込みやすくなります。

とくに「構造確認をせず、見た目だけCSSで直す」流れは再発しやすいため注意が必要です。

修正しても直らないときの考え方

どうしても直らない場合は、ルビ表現そのものを見直す判断も必要です。

作品性に直結しない補助的なルビであれば、対象語を減らすことで安定する場合があります。

すべての語にルビを振るより、読者理解に必要な箇所へ絞る方が、表示安定性と可読性の両立につながることがあります。

これは妥協ではなく、リフロー型電子書籍に合わせた設計最適化と考えられます。

入稿前の一手間が販売後のトラブルを防ぎます

KDP epub ルビ 崩れる問題は、運が悪かっただけで起きるものではありません。

多くは、変換工程の見落とし、縦書き特有の癖、表示環境差への未対応が積み重なって発生します。

そのため、対策も単純です。

EPUBを検証し、Previewerで確認し、必要ならHTML/CSSを最小限で整えることが最も確実です。

Zero出版では、過去の入稿トラブル検証から、Word直入稿よりもEPUBを一度分解して確認する方が、後戻りコストを大きく減らせると判断しています。

販売開始後に読者さんの環境で崩れが見つかると、レビューや信頼にも影響する可能性があります。

だからこそ、入稿前の確認工程を省かないことが重要です。

迷ったらルビではなく構造から見直してください

ルビ崩れが起きると、ついその文字だけを直したくなります。

しかし実際には、原因が周辺段落、画像、改行、フォント指定にあることも珍しくありません。

もし今つまずいているなら、ルビ設定を何度も触る前に、EPUB全体の構造を一段階上から見直すことをおすすめします。

その視点に切り替えるだけで、修正の迷いはかなり減るはずです。