そもそもEPUB内の「ページ番号」とは

　まず、そもそも「リフロー型電子書籍」は本来、固定されたページ番号を持ちません。「ページ」は各デバイスでEPUBを表示した際にEPUB内のXHTMLファイルの内容が分割されて動的に生成されます。これは鷹野凌さんも説明されている通り。画面の小さなデバイスで表示すればページ数は増えますし、画面の大きなデバイスで表示すればページ数は減るでしょう。電子書籍アプリでリフロー型の電子書籍を読むときに画面下にページ番号（ノンブル）が表示されているかも知れませんが、これは通常「そのデバイスのサイズ、文字のサイズに対応して生成されたページ番号（ノンブル）」であって、それを根拠としてその本の特定の箇所を指し示すことはできません。ちょっと専門性の高い本を読めば、割と当たり前に既存の書籍の特定ページへの参照は出てきますが、「参照されている本を電子版で所有していた場合に、参照先が不明になってしまっている」のが現状なわけです。このため、「リフロー版EPUBにも電子化元の紙の本のページ番号を入れましょう」という話になっています。

「他のEPUB内の特定の場所を指し示す電子的な技術」はまだ発展途上

　EPUBは電子データなのだから既存の本のページ数にはこだわらず、EPUB内の特定位置を指し示す技術（epub-cfiなど）を使うべきだという意見もあるようですし、それはそれで意義があることも十分分かるのですが、そちらにも簡単には解決できない問題があります。
　現在商業流通しているEPUBが個々のファイルを指し示す個別のIDで一元管理されている状況ではないこと、がそれです。もちろん各ストアごとに商品のIDは振られているでしょうが、「ストアAの商品X」と「ストアBの商品X」が同じタイトルであることの紐付けはなされていません。紐付けるためには双方のストアのデータベースを突き合わせて紐付ける作業が必要になってしまっているわけです。
　つまり、「特定のEPUBの特定の箇所」を指し示したい場合に、「特定のEPUB」の方で参照先不明になります。これを解消するには、たとえば電話番号のように全世界的な番号管理の仕組みが必要になるはずですが、これがまだどこにもありません。これは国単位での調整も必要そうな大きな話なので、解決できるとしてもかなりの時間がかかるでしょう。
　また、これが解決できたとしても、紙の本から電子書籍の特定の箇所を指し示すことはできないため、紙の本と電子書籍との間で断絶が起きてしまいます。これはもちろん良くありません。「リンクを機能させたければ電子版をあらためて買いなさい」というような話になってしまいますし、それくらいなら読者が自分でページ数を見て該当ページを開く手間があるとはいえ、ページ数そのものを情報として入れた方が現実的と言えそうです。

全てのEPUBが対象というわけではない

　さて、では全てのリフロー版EPUBに紙の本のページ番号を入れる必要があるかというと、それも当然違うかと思います。小説のようなものには普通は必要ないでしょうし、紙の本から「電子化」されていない本にも元々ないものは入れようがありません。これは、「他の本の特定の箇所を参照したり、特定の箇所を参照されたりする可能性がある、紙の本から「電子化」された本」のためのものです。具体的には新書や、学術文庫などはこれに該当するでしょう（ハードな専門書は現在PDFベースで仕組みが作られているため事情が異なるかもしれません）。ストア側のアプリの対応も、そういった類の本の販売を重視しているストアは早く対応して欲しい、ということになるかと思います。

　そういった事情なので、これを要件として記述するのは「紙の本のデータからの電子化の仕様書」として作られた「電書協EPUB3制作ガイド」の改訂で、となるのは自然かなと思います。現在、電書協EPUB3制作ガイドを日本語EPUB表示の要件として各ストアがアプリを作っている状況なので、電書協EPUB3制作ガイドの改訂は紙の本のデータからの電子化に留まらない影響が出そうではあるのですが、それは本来何を求められているのかを考えた上で、個々の対応を柔軟に行っていくしかないかなと思います。

Vivliostyle CLIの環境構築

　まず、node.jsを入れます（参考）。homebrewは入っていることが前提です。ターミナルで

これだけ。

でnodeのバージョンが表示されればOKです。

　次にVivliostyle CLIを入れます。同じくターミナルで

これだけです。

Perl経由で自動化

　これを従来同様にPerlで実行できるようにしたのが以下のコード。

　ノンブル表示、見開き指定などのための追加CSSは –style オプションを使って外部ファイルを読み込む形としました。その方が修正もしやすいし（追加CSSの参考例はVivliostyle CLIのオンラインマニュアル内にある）。「vivliostyle preview」を指定しているので、Chromiumブラウザが起動してページが表示されます。あとはこれまで通り印刷ウィンドウでPDFを保存を選択して出力するだけです。だいぶ簡単になりましたね。
　なお、その後Chrome側でバグが修正されたとのことなので今は古い方のスクリプトでも問題なくPDF生成はできるようです。

OPFのManifestに記述されていないファイルがパッケージに入っていてもエラーにならなくなった

　どうもEpubcheckのバージョンが4.2.6から5.0.0に上がる際にかなり重要な変更があったようです。具体的には4.2.6まではEPUB内のManifestに記述されていないファイルがパッケージ内にあることは許容されておらず、エラー扱いになっていましたが、5.0.0ではエラーにならなくなりました。

https://github.com/w3c/epubcheck/releases のEpubcheck v5.0.0のFeaturesにある

が関連するらしいとのこと。

　まあ5.0.0以降でもEpubcheckの実行時に-uオプションを付けることでファイルの混入をチェックすることはできるようなのですが、扱いとして「エラーではない」ことになったということです。

Epubcheckの出してくるアラートの区分

　ここであらためてEpubcheckの出すメッセージの種類を確認しておきます。以下の4種類の分類があるようです。

　このうち、Fatal ErrorおよびErrorは修正しないと流通が許されない種類のもので、Warningsは警告程度のニュアンスなので流通させること自体は問題ないはずですが、電子取次の規約を理由に修正を求められることはあるようです。まあ「非推奨」くらいの意味合いかと思いますので新規にデータを作る際には直した方が無難ではあるでしょう。Usageは単なる内部データの状況のレポートなので出ていても問題は無いはずです。とは言え今回のポイントである意図しないファイルがEPUBパッケージ内に入ったまま流通してしまうことはもちろん良くはないので、管理面でチェックしておきたくはあります。
　また、Fatal Error／Error／Warningsは「標準エラー出力」でアラートを出しているようですが、Usageは「標準出力」扱いなので、ターミナル等でepubcheckを直に使う分には問題ないですが、外部言語等でアラートの内容を取得している場合には「2>&1」のような指定を追加してメッセージをマージする必要があるようです。

-uオプションで混入自体は検出できるが･･･

　さて前述したように、

のように-uオプションを指定すればmanifestに記述されていないファイルの混入をチェックすることはできます。ただし、電書協ガイドのテンプレートに入っているstyle-check.cssに関連するレポートもたくさんUSAGE扱いで出てきてしまいます。これはEpubcheckの機能での選別はできそうにないので、USAGE扱いの中の特定のメッセージだけを出したければ後からフィルタリングするしかないことにはなります。まあstyle-check.css自体、内容確認の際にだけ有効にして使うためのものですので消しても実害はないはずですが、電子取次の内部チェッカーで引っかかって戻ってくる可能性が無いとも言えないのでできればそのままにしておきたいところです。

Epubcheckのアラートをフィルタリングして必要なものだけ出すようにしてみる

　ということでちょっとコードを書いてみました。

　ぐらいの感じでしょうか。ターミナルで

　の形で指定すれば使えます。

　これを取り込んだ「EPUB3トータルデータチェッカー2.5.0」はこちらからダウンロードできます。