納品箱に「最終版」とだけ書かれたEPUBが二冊あり、どちらが日本語設定で、どちらが英語設定なのか分からない。そんな事故を、ファイル名や担当者の記憶に頼らず解決するのがこの記事の目的です。結論から言えば、二冊をいったん未判定として隔離し、OPFの言語、目次名、奥付名、奥付の日付を内部から読むと所属先を決められます。
STUDIO-417の固定標本は、同じ日本語四章から作られた二冊です。日本語側はja / もくじ / 奥付 / 2026年9月3日、英語側はen / Table of Contents / Colophon / September 3, 2026という内部署名を持っていました。epub 言語の設定が分からない二冊を、配信箱へ振り分け直す手順として読み進めてください。
ファイル名を伏せて二冊を受領する
最初に行うのは、二冊を日本語版・英語版と決めつけないことです。検証では日本語版のSHA-256がd6d3e66a…d46638、英語版が6659aec3…73f2b1でした。実務でも受領時にSHA-256を記録し、元ファイルを読み取り用の保管場所へ置きます。後から名前を変更しても、どの内容を判定したかはSHAでたどれます。
今回の入力は「STUDIO-417 検証章1」から「検証章4」までの日本語ファイルです。各章には「これはSTUDIO-417専用の合成原稿です。」という一文があります。二冊ともZIPとして開き直せて、Runeのローカル検査はvalid=true、manifestの欠落資源は0件でした。まず壊れていない二冊だと確認してから、所属先の判定へ進みます。
受領時点では、ファイル名のjaやenを証拠欄へ転記しません。名前が取り違えられている可能性を調べる工程だからです。受領票には仮番号A・B、SHA、再open結果だけを書きます。この小さな保留が、誤ったラベルを検査表へ持ち込む連鎖を止めます。
OPFの値で所属先を決める
次に二冊のOPFを開き、dc:languageを読みます。固定標本では一方がja、もう一方がenでした。この時点で仮番号A・Bを日本語設定側、英語設定側へ割り当てられます。画面に見える章題ではなく、保存されたパッケージの値で分類するのが要点です。
OPFの値は本の主言語を表す書誌情報であり、文章を翻訳したという証明ではありません。したがって判定票の最初の欄は「パッケージ言語」とし、「本文言語」と分けます。dc:language=enを見つけても、英語原稿の納品済みとは記録しません。
もし二冊ともja、または二冊ともenなら、ここで振り分けを中止します。片方の名前だけを直して終えてはいけません。同じ入力四章へ戻り、目的の言語を設定し、既存二冊を残した新しい出力先へ再生成します。復旧後もOPFを再読込し、期待した一組になったことを確定します。
三つの生成文字列を内部署名として読む
OPFで所属先を決めたら、目次XHTMLと奥付XHTMLから三つの文字列を集めます。日本語設定側では目次見出し「もくじ」、奥付見出し「奥付」、日付「2026年9月3日」でした。英語設定側では「Table of Contents」「Colophon」「September 3, 2026」です。
英語側の奥付には「eBook」「published」「Author」「Publisher」もあり、日本語側には対応する「電子書籍」「発行」「作者」「発行所」がありました。これらは保存済みEPUBのXHTMLから読んだ値です。出力完了の応答だけを根拠にせず、受領した実ファイルの中身へ結び付けます。
この文字列群は、取り違えを検知するための署名として使えます。たとえばOPFがenなのに目次が「もくじ」なら、ファイル名を直す段階ではありません。生成設定または出力物の混在を疑い、そのファイルを不合格箱へ移し、新規出力後にOPFと三文字列をもう一度読みます。
四章同順を誤配信防止に使う
言語別の署名だけが正しくても、別作品の章が混ざっていれば配信できません。二冊はともにnavとNCXが各4項目で、章1から章4まで同じ順序でした。spineはタイトル、目次、四章、奥付の7項目です。この構造一致を、同じ原稿から派生した一組であることの照合に使います。
ここでは「英語側だから英語の章題があるはず」とは考えません。固定標本の四章は両方とも日本語であり、それが同一入力の目印です。章数4、nav 4、NCX 4、spine 7、欠落0という値を二列に並べ、片方だけ増減していないかを見ます。
章が三つしかない、順序が異なる、リンク先が欠ける、といった差があれば言語の判定が合っていても受入不可です。失敗した二冊はそのまま保持し、元の四ファイルと選択順を読み直します。足りない章だけを後からEPUBへ継ぎ足すのではなく、固定した四章から別名で作り直し、構造全体を再検査します。
本文言語は判定から切り離す
英語設定側の章XHTMLには「STUDIO-417 検証章1」という見出しと、日本語の合成原稿文が残っています。これは、この標本では失敗ではありません。設定差だけを追跡するため、原稿を同一にしたからです。epub 言語の切替はOPFや生成ラベルへ届きましたが、著者が書いた本文を英訳してはいません。
この境界を明記しないと、英語の目次名を見て「英語版の本文も完成」と誤って配信する危険があります。本番の英語版には、翻訳・校正済みの英語原稿が別途必要です。反対に、今回の証拠標本を検査する人が日本語本文を見て壊れたと判断し、勝手に差し替えるのも誤りです。
判定票では「生成領域」と「著者原稿」を別枠にします。前者はOPF、目次、奥付、日付。後者は章題と本文です。誰が次工程を担当しても、どの変化を許し、どの一致を残すべきかが一枚で分かります。
日付をreader確認キューへ送る
固定入力の日付は2026-09-03です。パッケージ内部では日本語設定側が「2026年9月3日」、英語設定側が「September 3, 2026」でした。ここまでで確認できるのは、生成された奥付XHTMLの文字列です。
Apple BooksやKindleなどのreaderが、ライブラリ画面で日付を別の順序に直すか、端末の地域設定を反映するかは今回操作していません。そのため「すべてのreaderで英語順になる」という合格印は押せません。未実測欄にreader名、版、端末地域、確認する画面を記し、端末確認担当へ回します。
reader側で想定外の表示が出ても、すぐEPUBを書き換えません。まず奥付ページそのものと、reader独自の書誌画面のどちらで起きた差かを分けます。前者なら生成設定を再点検し、後者なら端末条件を添えて記録します。異なる層の表示を一つの不具合として扱わないことが、無用な再出力を防ぎます。
日本語版・英語版の配信箱を確定する
最終判定は、二冊を比較したという感想ではなく、各ファイルの行き先です。日本語箱へ入れる条件は、対象SHAのOPFがja、生成文字列が「もくじ」「奥付」「2026年9月3日」、構造がnav 4・NCX 4・spine 7・欠落0であることです。英語箱はen、「Table of Contents」「Colophon」「September 3, 2026」、同じ構造値を求めます。
本文が日本語のままなのは固定標本の条件であり、一般の英語出版物の受入条件ではありません。今回確定できるのは、名前に頼らず二冊の内部署名を読み、言語別の行き先を復元できたことです。翻訳品質とreaderの日付表示は、別の担当・別の検査票へ引き継ぎます。
引き渡しには二つのSHA、OPF値、三つの生成文字列、四章の構造値、未実測のreader条件を書きます。これなら受取人はファイル名を信じる必要がなく、保存済みEPUBから同じ判定を再現できます。二冊の役割を内部から同定し、未確認事項だけを次工程へ送ることが、誤配信を止める実務上の結論です。