EPUB 翻訳ツールを自作するのが想像以上に難しい理由

先日、@cat88tw というデベロッパーが Claude Code を使って EPUB 翻訳ツールを構築しようとした体験をツイートし、大きな反響を呼びました。1,671 回も閲覧されたのは、同じことを試みたことのあるデベロッパーなら誰でも共感できる内容だったからです。

アイデア自体はシンプルに見えます。EPUB は HTML と CSS を ZIP にまとめたもの。最新の AI モデルは翻訳が得意。この 2 つを繋げれば週末で完成——のはずでした。

しかし現実は甘くありません。週末で作れるのは、フォーマットが崩れ、章が壊れ、画像が消え、実際の電子書籍リーダーでまともに表示されないプロトタイプだけです。実在する書籍を確実に処理できる翻訳ツールを構築するのは、本格的なエンジニアリングの課題です。

課題 1：EPUB の構造は見た目以上に複雑

EPUB ファイルは XHTML、CSS、画像、フォント、メタデータ、ナビゲーションシステムを含む ZIP アーカイブです。EPUB 2 と EPUB 3 の仕様がこれらの構成を定義していますが、出版社ごとの実装は大きく異なります。

章ごとにファイルを分ける書籍もあれば、すべてを 1 つの巨大な XHTML に詰め込む書籍もあります。目次は NCX ファイルの場合も、Navigation Document の場合も、その両方の場合もあります。CSS はインラインだったり外部参照だったり。フォントは埋め込みの場合もシステムフォント依存の場合もあります。

翻訳ツールはこれらすべてのバリエーションを正しく処理する必要があります。「章は必ず別ファイル」「CSS は必ず外部」といった仮定を置いた瞬間、その仮定を破る実際の書籍に出会います。

課題 2：テキストを置換しながらフォーマットを維持する

ここで大半の自作プロジェクトが頓挫します。テキストの翻訳は簡単な部分です。翻訳後にフォーマットを維持するのが本当の難題です。

HTML タグが混在する段落から翻訳可能なテキストを抽出し、翻訳後のテキストを正しいタグにマッピングし直す必要があります。しかし対象言語では語順も文構造もテキスト長も完全に変わっています。ハイパーリンク参照は翻訳してはいけません。HTML エンティティも壊してはいけません。

生の HTML をそのまま言語モデルに送ると、タグの破壊、属性値の変更、閉じタグの欠落が頻繁に起こります。HTML を先に除去してプレーンテキストを翻訳すると、フォーマットは完全に失われ、復元する方法がありません。

脚注、ルビ（振り仮名）、ドロップキャップ、引用ブロック、詩の改行、数式、結合セルを含む表……すべてが個別に対処すべき特殊ケースです。

課題 3：分割処理とコンテキストウィンドウ

一般的な書籍は 6 万〜10 万語あります。現在の言語モデルは 1 回の API コールで書籍全体を処理できないため、チャンクに分割する必要があります。

しかし分割は新たな問題を生みます：

• 文脈の喪失：チャンク境界を超えた人名・用語・代名詞の一貫性が失われる
• 分割位置の選択：段落やテーブルの途中で分割すると HTML が壊れる
• 用語の不一致：同じ単語が異なるチャンクで異なる訳語になる可能性がある

プロの翻訳ツールは用語集とチャンク間で重複するコンテキストウィンドウを維持します。これを正しく構築するには、慎重な設計が必要です。

課題 4：CSS とフォントの処理

翻訳によってテキストの長さが変わります。20 語の英文が 35 語のドイツ語や 12 文字の中国語になることもあります。これはレイアウトに連鎖的な影響を及ぼします：

• 固定幅コンテナがオーバーフローする
• CSS カラムレイアウトが崩れる
• 縦書きレイアウト（日本語書籍で一般的）は横書きとは全く異なる CSS が必要
• カスタムフォントが対象言語のグリフを含まない場合、空白の四角や代替フォントが表示される
• 行の高さや間隔は文字体系によって最適値が異なる

課題 5：CJK と RTL スクリプト

中国語・日本語・韓国語やアラビア語のサポートを追加した瞬間、複雑さは倍増します。

CJK の課題：

• 分かち書き——中国語と日本語はスペースで単語を区切らないため、分割ロジックが空白文字に依存できない
• ルビテキスト（振り仮名）——漢字の上の読み仮名を保持または再生成する必要がある
• 句読点規則の違い——中国語は全角句読点、日本語には特有の禁則処理がある
• 縦書きが多くの日本語・繁体字中国語の書籍で標準

RTL の課題：

• アラビア語とヘブライ語は右から左に流れ、テキストだけでなくページレイアウト全体に影響する
• 双方向テキスト（同じ段落に英語とアラビア語が混在）には Unicode BiDi アルゴリズムの正確な処理が必要
• アラビア文字は筆記体——文字の形が単語内の位置によって変化する。タグ境界で単語が不正に分割されるとレンダリングが壊れる

課題 6：EPUB バリデーションとリーダー互換性

すべてのリーダーアプリで正しく表示される有効な EPUB を生成するのは、驚くほど難しいことです。電子書籍リーダーはブラウザではありません。それぞれが EPUB 標準の異なるサブセットを独自の癖とともに実装しています。

Apple Books は Kindle が無視する EPUB 3 機能をレンダリングし、Kobo の CSS 処理は Google Play Books と異なり、古い Kindle デバイスは MOBI 変換が必要です。クロスリーダーテストは時間がかかり、プラットフォーム固有のバグが次々と見つかります。

課題 7：大規模なエラーハンドリング

300 ページの書籍の翻訳には 200 回以上の API コールが必要になることがあります。レート制限、タイムアウト、不正なレスポンス——各コールが失敗する可能性があります。リトライロジック、進捗追跡、出力検証、コスト見積もりなど、堅牢なインフラの構築が必要です。

専用ツールを使う理由

上記のすべての課題は解決可能です。しかし、それらを同時に解決し、EPUB 標準の進化や言語モデル API の変更に合わせて継続的に保守することは、フルタイムの仕事に相当します。

これこそ EPUBTranslator が存在する理由です。自分でパイプラインを構築・デバッグするのに何週間も費やす代わりに、ファイルをアップロードして言語を選ぶだけで、適切にフォーマットされた翻訳 EPUB が手に入ります。構造解析、フォーマット保持、チャンク管理、CSS 調整、CJK・RTL サポート、バリデーション、エラーリカバリー——すべてが処理済みです。

チャレンジを楽しむデベロッパーにとって、EPUB 翻訳ツールの自作は素晴らしい学習プロジェクトです。しかし、目的が外国語の本を読むことであれば、すでにこれらの問題を解決しているツールを使う方が遥かに効率的です。バイラルツイートの作者が身をもって学んだ教訓を、あなたは繰り返す必要はありません。