ウェブ小説を翻訳可能なEPUBに変換する方法

ウェブ小説を翻訳可能なEPUBに変換するには、自分が権利を持つか、エクスポートを許可されている章から始め、その順序を固定し、テキストを正規化して、1つの正しいリフロー型EPUBとしてパッケージ化します。翻訳する前に、そのソースファイルを検証してください。動作するウェブサイトがそのままクリーンな書籍ソースになるわけではありません。ナビゲーションのラベル、広告、コメント、重複した見出し、更新通知などが、意図せず書籍の内容に混入することがあります。

実践的な手順は次のとおりです。

1. テキストをエクスポートおよび翻訳できることを確認する。
2. 章のマニフェストを作成する。
3. 章ごとに1つのソースファイルをクリーンアップする。
4. 名前、見出し、注記、画像を標準化する。
5. EPUBパッケージとナビゲーションを構築する。
6. EPUBCheckで検証する。
7. 実際のリーディングアプリで開く。
8. 検証済みのソースビルドのみを翻訳する。

このワークフローは、自分の小説、許可された原稿、または再利用が許可されているプラットフォームのエクスポートを対象としています。他人の作品をスクレイピングしたり、アクセス制御やDRMを回避したりする方法ではありません。

ウェブサイトのクロールではなく、章のマニフェストから始める

何かを変換する前に、簡単なマニフェストを作成します。意図する書籍の単位ごとに1行を割り当てます。

変化するウェブサイト上の順序だけを唯一の記録にしないでください。プラットフォームはプロローグを固定表示したり、章を分割したり、エピソードのラベルを変更したり、章の間に告知を挿入したりすることがあります。マニフェストは、その本が意図する読書順序です。

ソース版も凍結してください。エクスポートまたはローカルファイルを変更せずに保持し、日付またはハッシュを記録します。後でウェブ版を修正する場合は、翻訳作業中にテキストを黙って置き換えるのではなく、修正を記録してください。より広範な書籍ソース準備ワークフローでは、その受け入れ基準を確立する方法を説明しています。

本に含めるべきコンテンツだけをエクスポートする

プラットフォームに著者向けエクスポート機能がある場合はそれを使用してください。ない場合は、公開された章を生成した原稿ファイルから作業します。公開ページからコピーしたHTMLは、たとえ自分のページであっても、小説の一部ではない表示要素やコミュニティ要素が含まれている可能性があるため、最後の手段とすべきです。

以下を削除するか、別途分類してください：

• サイトメニュー、パンくずリスト、ページネーション、共有コントロール；
• 読者のコメント、リアクション数、推薦ウィジェット；
• 広告およびプラットフォームのプロモーション；
• 繰り返されるシリーズタイトルと章ラベル；
• 「前の章」および「次の章」へのリンク；
• 物語の外に留めるべき更新通知；
• 非表示または折りたたまれたテキスト、および
• 正規のリンクに含まれるトラッキングパラメータです。

意図的な前書き、著者による注記、脚注、挿絵、エピグラフ、コンテンツ警告は保持しつつ、それぞれをマニフェスト内で明確な位置に配置してください。著者による注記を破棄可能かどうか、クリーンアップスクリプトに判断させてはいけません。

EPUBを構築する前に章を正規化する

準備中は、1章につき1つのクリーンなソースファイルを保ちます。HTML、Markdown、または一貫したスタイルのDOCXはいずれも実行可能な入力となり得ます。有用な形式とは、ページ固有の雑多な要素なしに、見出し、段落、強調、リスト、リンク、注記、画像を明示できる形式です。

以下のルールを一貫して適用してください：

• 各章の先頭に章タイトルを1つだけ使用する。
• 太字の段落を見出しとして使うのではなく、見出しレベルを意味のある形で保つ。
• スペース調整のために改行を繰り返すのではなく、実際の段落境界を使用する。
• 意味を持つ場合にのみ、斜体と強調を保持する。
• 装飾的なUnicodeスペースを通常のテキスト構造に置き換える。
• すべての画像に安定したファイル名を付け、必要に応じて有用な代替テキストを付与する。
• すべての脚注ターゲットと戻りリンクに一意の識別子を付与する。
• 場面転換を一貫させる。
• 空のブロック、重複する章タイトル、孤立したリンクを削除する。

後で構造を再構築する覚悟がない限り、すべてをプレーンテキストに平坦化しないでください。翻訳には単語が必要ですが、EPUBにはそれらの単語、章、ナビゲーションの間の信頼できる関係も必要です。

名前と用語が増殖する前に固定する

ウェブ小説では、用語が時間とともに発展することがよくあります。キャラクターが初期の章では Vale Orin と呼ばれ、後で Valé-Orin になることがあります。創作された階級の大文字小文字が変わったり、場所の綴りが2通りになったりすることもあります。コンバーターはどちらの形式が正規であるかを判断できません。

ソース側の小さな用語集を次の項目で作成します：

• 正規のキャラクター名と地名。
• 別名と意図的に却下された異形。
• 創作された単語とその意味。
• 称号と敬称。
• 繰り返し登場するインターフェース用語やシステム用語。
• 大文字・小文字の使い分けと句読点のルール、そして
• 各項目が初めて登場する章。

原文に偶発的な表記ゆれがあれば解消するか、翻訳ブリーフに記載しておきましょう。翻訳版の制作途中で、同一人物が二人の名前で登場していることに気づくより、こちらの方がはるかに低コストです。

明示的なナビゲーションを備えたリフロー型EPUBを構築する

EPUBは単にHTMLファイルの名前を変えたものではなく、パッケージです。EPUB 3.3仕様では、出版物のリソースを宣言するパッケージドキュメントと、デフォルトの閲覧順序を定めるスパインが定義されています。また、EPUBにはナビゲーションドキュメントも必要です。したがって、章のマニフェストは次の3つに直接対応させる必要があります。

1. 各章に対応するコンテンツドキュメント、
2. スパインの順序、そして
3. 正しい見出しを指す目次エントリ。

グラフィカルなワークフローを好むなら、Calibreの変換ドキュメントで、入力段階がソースを内部XHTML表現に変換してから出力処理を行う仕組みが説明されています。しかし、この便利さがあっても結果を確認する必要性はなくなりません。自動変換では、繰り返される見出しが意図的なものか、更新通知が本に含まれるべきか、章が欠落していないかを判断できません。

どのオーサリングツールを使うにしても、出版物の言語、タイトル、一意の識別子、更新日を設定し、該当する場合は著者メタデータを追加しましょう。これらは互換性のあるフィールドではありません。EPUB 3.3ではdc:title、dc:identifier、dc:language、dcterms:modifiedが必須である一方、作成者メタデータは任意です。参照されている画像、スタイルシート、フォント、その他のアセットのみを含めてください。散文小説では固定高さやページのような配置は避けましょう。読者がフォントサイズや画面幅を変更したときに、テキストはリフローされるべきです。

4章構成のフィクスチャが実際に検証したこと

このガイドのために、オリジナルの4章構成EPUBフィクスチャを作成しました。これは『The Border Archive』という短編フィクション作品であり、公開ウェブ小説を再パッケージしたものではありません。このフィクスチャには意図的に次のものを含めています。

• 順序が簡単に確認できる4つの章、
• 名前の表記ゆれVale OrinとValé-Orin、
• リフローを試す長い見出し、
• 日本語、アラビア語、ギリシャ語の混在スクリプトテキスト、そして
• ナビゲーションにならずに読みやすさを保つべきスタイル付きコールアウト。

正確な4章構成フィクスチャをダウンロードし、決定論的Pythonジェネレーターを確認し、生の検証コマンドと結果を読むことができます。そのSHA-256はc3d24e72d269577541b7937fac3beb5c40a539e0a3af71de470855c2f191e1f5です。

生成されたファイルを2026年9月17日にEPUBCheck 5.4.0リリースで検証しました。EPUBCheckはフィクスチャに対してEPUB 3.4ルールを選択し、致命的エラー0件、エラー0件、警告0件、情報メッセージ0件を報告しました。その後、macOSのApple Booksで同じファイルを開き、第4章が順番に表示されること、および混在スクリプトの段落が表示されることを確認しました。

重要な発見は、4章のサンプルが合格したことではない。検証、リーダーの動作、編集の一貫性は異なるテストであるということだ。EPUBCheckはキャラクター名の2つの綴りに異議を唱えなかった。どちらも有効なテキストだからである。その決定を捉えられるのは編集目録だけである。

翻訳対応ソースゲートを実行する

EPUBをアップロードまたは引き渡す前に、凍結されたソースビルドに対して以下をすべて確認する：

• 意図したすべての章が正確に1回ずつ、マニフェストの順序で現れること；
• 目次が対応する章と見出しを開くこと；
• メニュー、コメント、広告、前後のページ移動コントロールが残っていないこと。
• 前書き、特典章、注記、後書きが明示的に扱われていること。
• 画像が正しく表示され、意図したキャプションと代替テキストが付いていること。
• 人名や繰り返し登場する用語が、原稿の用語表と一致していること。
• 出版メタデータとコンテンツ言語メタデータが原語を識別していること。
• EPUBCheckに、リリースを妨げる未解決のエラーがないこと。
• 最初の章、中間の章、最後の章が実際のリーディングアプリで開けること。
• テストしたファイルそのものが、翻訳対象として指定されたファイルであること。

検証ツールのレポート、ツールのバージョン、原稿のマニフェスト、ファイルハッシュをまとめて保存しておきましょう。EPUBが変更されれば、以前の証拠は新しいビルドについて何も証明しません。

テスト済みファイルを翻訳し、構造チェックを繰り返す

原稿のEPUBがゲートを通過したら、BookTranslatorのEPUBワークフローを使ってファイル全体の翻訳ドラフトを作成します。テストしたファイルそのものをアップロードし、目的のターゲット言語を選択し、必要に応じて自動用語集を有効にしましょう。承認済みの用語表を外部レビュー用のブリーフとして翻訳のそばに置き、出力内でそれらの用語を確認します。

出力の生成が成功したことを、出版の承認と見なしてはいけません。翻訳はテキストの長さ、文字体系、句読点、フォント、言語メタデータ、時にはナビゲーションのラベルまで変化させます。EPUB翻訳QAチェックリストをターゲットファイルに適用し、電子リーダーテストマトリクスを使って、最終候補そのものを必要なリーディングシステムでテストしましょう。

少なくとも、原稿とターゲットの章の一覧を比較し、正規の登場人物名を検索し、最も長い見出しと段落を確認し、注記と内部リンクをテストし、冒頭・中間・末尾を開いてみましょう。有効な原稿のEPUBは、防げるはずの構造的な失敗を減らします。しかし、ターゲット言語での編集、完全性のレビュー、最終デバイスでの校正を置き換えるものではありません。

最終判断

あなたのウェブ小説は、ページの寄せ集めではなく、バージョン管理された書籍のソースになったとき、翻訳へと進む準備が整います。すなわち、権利処理済みのテキスト、記録された一つの章順、整った構造の章、明示的なナビゲーションとメタデータ、確定した用語の基準、クリーンな検証結果、そして実際のリーダーでのスポットチェックです。

正確な版を特定できず、含まれるすべての章を説明できず、テストしたファイルを再現できないなら、いったん止まってソースパッケージを修正しましょう。不安定な書き出しを翻訳するのは、原稿の曖昧さを多言語制作の問題に変えてしまうだけです。