仕様・ダウンロード

アプリ名：OPFファイル生成（緊デジ用）
対応環境：Mac OS 10.4〜10.8
動作チェック済環境：Mac OS 10.5（PowerPC）／Mac OS 10.6／Mac OS 10.7

※ビルド自体はMac OS 10.4までをターゲットにIntel／PowerPC両環境を対象としたユニバーサルバイナリ対応で行っていますが、当方にテスト環境がないためOS 10.4での起動チェックはできていません。おそらくOSにプリインストールされているperlのバージョンにも依存します。

※Mac OS 10.8でのチェックも出来ていないのですが、10.8には「Gatekeeper」という非登録デベロッパのアプリを実行出来なくするセキュリティ機能が搭載されているため、おそらくデフォルトの設定では起動できません。「システム環境設定」→「セキュリティとプライバシー」で「Gatekeeper」の設定をオフにすれば起動できるかと思います。将来的には対応を検討中です。

※こちらのアプリは、電書協EPUB3制作ガイド_ver1.1及び、緊デジテンプレート（2012年10月22日発表版）の仕様に沿って制作されたリフロー型EPUB3コンテンツ専用のOPFパッケージファイル作成アプリです。他の形式のEPUB3コンテンツ制作に使用していただくことは可能ですが、ファイル構成、パス指定などは異なっている可能性があり、それぞれのケースにあわせて書き換える必要があります。あらかじめご了承ください。また、こちらのアプリを利用したことによって生じた損害等に関しまして、私として一切の責任は負いかねますので、あくまで自己責任でご利用ください。

＞＞OPFファイル生成（緊デジ用）ver 1.2.3 ダウンロードはこちら

※ダウンロード先を私の所属する会社のホームページ内ダウンロードコーナーに移動しました。内容の改訂等は行っていません。

＞＞電書協EPUB3用OPFファイル生成ver 2.0 ダウンロードはこちら

※uuid自動生成、kindle用パラメータ入力（kindlegen2.8にて検証済）に対応した新バージョンです。

使い方

　画面上の各項目を入力もしくは選択し、「OPF生成」のボタンを押せばファイルの出力先を尋ねるダイアログが出ますので、保存先を指定すればそちらに「standard.opf」の名称でOPFファイルが出力されます。簡単です。なお、画像フォルダ及びXHTML文書の収納フォルダはフォルダ名を取得してパスに組み込みますので、実際にEPUB内に収納するものと同じフォルダを指定してください。CSS及びナビゲーション文書は電書協EPUB3ガイドの仕様に従ってファイル名・パス共に決め打ちで出力します。EPUB3圧縮時には、規定の場所にそれぞれのファイルを配置しておくようにしてください。

　出力後、OPFファイルをテキストエディタで開き、以下のポイントをチェック・修正してください。

1. 改行コードは「CR（Mac）」で出力されます。電書協EPUB3制作ガイドでは、パッケージ内の各文書の改行コードを統一することを推奨していますので、必要であれば修正してください。
2. 全てのXHTMLドキュメントを見開き時片ページ始まり指定で出力します。出力された「standard.opf」ファイルの「<spine>」指定内、各「<itemref〜」行末尾の「properties="page-spread-left"」（左綴じではpage-spread-right）記述部分がそれに相当します。各XHTMLドキュメントの内容を確認し、片ページ始まりが必要なければこの部分の記述を削除してください。
3. 「<itemref〜」行のファイルの並び順は、EPUB文書としてのページングの順番に相当します。ファイルの並び順を確認し、必要であれば入れ替えを行って下さい。
4. 緊デジでのコンテンツ制作以外の目的でこちらのツールを利用する場合、JP-eコードに関する部分の記述をuuid等に差し替える必要があります。JP-eコードはそれぞれの電子書籍に対して与えられるユニーク値ですので、JP-eコードを適当に入力した電子書籍を配布することは絶対に避けてください。uuidの生成に関してはこちらが参考になります。また、ヘッダ行にもJP-eコードに関する記述がありますので、記述を変える必要があります。電書協ガイドに沿ったコンテンツ制作の場合は、電書協ガイドのサンプルのヘッダ部分の記述を引き写せばOKです。
   →uuid自動生成に対応した「電書協EPUB3用OPFファイル生成 2.0」をご利用ください。

　なお、電書協EPUB3制作ガイドでは、カバー、本文など各文書に用いるXHTMLのファイル名をきちんと規定しています。電書協EPUB3制作ガイドおよび緊デジテンプレートの記述の規則に従ってファイル名が付けられていた場合、こちらのアプリが自動で望ましいと思われる順番に文書を並び替えて出力します。規則から外れていたファイルについては、「<itemref〜」行末尾にシステムのソート順に従って記述されます。外字ファイルなどの命名規則もこれと同様です（緊デジテンプレートの記述規則に従います）。

　電書協EPUB3制作ガイド／緊デジテンプレートのXHTMLファイル名命名規則は現状、以下の通りです。

• カバー：p-cover.xhtml
• 前付け：p-fmatter-00x.xhtml（連番） _※1
• 本扉：p-titlepage.xhtml _※1
• 電子化注意書き（底本組方向の記述）：p-caution.xhtml _※1
• 目次：p-toc.xhtml _※1
• 本文：p-00x.xhtml（連番）
• 底本奥付：p-colophon.xhtml
• 広告：p-ad-00x.xhtml（連番）
• 電子化奥付：p-credit.xhtml
• 白紙ページ：p-white.xhtml（連番になるパターンもあり） _※2

また、特にファイル名を規定しているイメージファイルは以下の通りです。

• カバー：cover.jpg
• 底本奥付：original_credit.jpg _※1
• 外字：cid-xxxxx.png（Adobe-Japan 1のCIDコード番号を指定）_※1
• 底本奥付：i-colophon.jpg _※2
• 電子化奥付：i-credit _※2
• 本文ページ：i-xxx.jpg（連番） _※2
• 白紙ページ：i-white.jpg（連番になるパターンもあり） _※2

※1 リフロー型のみ　　※2 フィックス型のみ

パターン1　XHTML内「<meta>」行のエラー

　「File」はEPUB3パッケージ内ファイルのうち、問題のあったファイルを差しています。「Line」は問題のあった行で、「Message」はエラー内容です。正規表現を用いて書かれているので若干わかりにくいですが、この場合は、「cover.xhtml」ファイル内5行目の「<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />」のうち、「http-equiv」の属性値が不正なので修正せよと言われています。これはJBasic08の公式サンプルをそのまま使用した場合に遭遇するエラーです。
　エラー内容をそのまま適用すれば、「Default-Style」もしくは「Refresh」に修正することになりますが、最近のサンプルではこの行は「<meta charset="UTF-8" />」となっているものを多く見かけますので（電書協ガイドもこの表記）、そうした表記に変更する形で良いと思われます。また、この行そのものを記述しなくてもそう問題はないようです。

パターン2　「navigation.xhtml」内「nav.css」のリンクエラー

　オーサリングツールとしてFUSEeβを使用している時に良く遭遇するエラーです。目次ファイル「navigation.xhtml」内にスタイルシート「nav.css」へのリンクが記載されているのに、実際にはファイルが存在しないことによりエラーが出ています。これはFUSEeβのデフォルト設定のため、頻繁にこのエラーに遭遇します。
　一度EPUBパッケージを解凍して「navigation.xhtml」内の「nav.css」へのリンク行を削除するか、あるいは内容は空でも構わないので「nav.css」を作成してFUSEeβで再度EPUB3ファイルを書き出せばこのエラーは消えます。

パターン3　空の「images」フォルダがある

　電書協EPUB3ガイドの仕様では、画像を収納するフォルダ名は「image」です。しかしFUSEeβの標準仕様では画像フォルダ名は「images」で、FUSEeβ内で画像フォルダ名を「image」に変更することはできますが、何故か書き出し時に空の「images」も書き出され、このエラーが出ます。
　一度EPUBパッケージを解凍し、空の「images」フォルダを削除することでエラーは消えます。

パターン4　目次ファイル内に「<ol>」タグが連続で記述されている

　目次ファイル内に「<ol>」タグが連続で記述されているとこのエラーが出ます。FUSEeβの環境設定の「カバー・目次」の項目で、「<h1>〜<h3>タグを目次に含める」（目次に含めるタグ範囲は任意選択可能）の項目をオンにしていると、目次ファイル内に<ol>タグが連続する形でデータが書き出され、このエラーが出るようです。
　一度EPUBパッケージを解凍し、目次ファイル内の<ol>タグのうち内側のものを消すかコメントアウトすればこのエラーは消えます。

パターン5　パッケージ内にOPFファイルに記述されていない画像がある

　画像フォルダ内にOPFパッケージファイルに記述されていない画像ファイルがある場合のエラーメッセージです。FUSEeβなどのツールを使用しているとOPFファイルへのファイル名の自動登録を行ってくれるため、このエラーに遭遇することはありませんが、ハンドコーディングでEPUB3を作成している場合などに、OPFパッケージファイルに画像ファイル名を記述し忘れるとこのエラーに遭遇します。適正にパッケージファイルへの記述を行えばエラーは消えます。

パターン6　パッケージ内にOPFファイルに記述されている画像がない

　パターン5の逆で、パッケージファイルには画像ファイル名の記述があるのに実際にはファイルがない場合です。画像ファイルを入れ直す、（必要なければ）OPFファイル内の画像ファイルの記述を削除するなどの操作をすることでエラーは消えます。

パターン7　パッケージ内にファイル「.DS_Store」が存在する

　Macがアイコンの配置などを記録している不可視の設定ファイル「.DS_Store」がフォルダ内に存在する場合のエラーです。これは不可視ファイルですので通常Macでは見えません。ただし実際には存在するためバリデート時にエラーになってしまいます。「Ds Store Remover」などのツールを使うことで除去できます。

パターン8　パッケージ内にファイル「iTunesMetadata.plist」が存在する

　校正などの目的でiBooksなどのiOS内アプリにデータをコピーする際に、iTunesの同期機能を使うとパッケージ内にメタデータの管理ファイルを作成されてしまい、エラーが出ます。一度EPUBパッケージを解凍し、「iTunesMetadata.plist」ファイルを削除することでエラーは消えます。EPUB3ファイルの校正にiPad等を用いる際には、クラウドサービス「DropBox」経由でファイルを転送すると、この問題は起きませんので、そちらの方法をおすすめしておきます。

法、市場、規範、アーキテクチャ

ハーバード大学法学部教授で、クリエイティブ・コモンズ代表でもあるローレンス・レッシグは、著書『CODE Version 2.0』の中で、ものごとを制約する四つの条件を挙げています。「法」、「規範」、「市場」、「アーキテクチャ」がそれです。DRMについて考えるにあたって、この四つの制約条件はとてもわかりやすい指標となりますので、今回はこちらを軸にして考えてみようと思います。

　まずは、それぞれの制約条件が規制対象に及ぼす効果について簡単に説明しておきます。

「法」は説明するまでもないかとは思うのですが、法による直接的な罰則の制約です。法に背いた行為を行えば、当然罰金や禁固刑などといった形で罰を受けるリスクを背負います。このリスクが「法」の抑止効果です。

「規範」は、規制対象物に対しての社会的規範が及ぼす抑止力です。「世間の目」や「モラル」、「常識」などと言い換えることもできるでしょう。成文法が成立する以前、社会のバランスを保っていた重大なファクターは、この社会的規範による抑止効果であったように思います。特に宗教によるものが大きかったでしょう。もっともこれが行き過ぎれば魔女狩りに至るわけですから、成文法は規範の暴走を抑止する役割を帯びて登場したとも言えそうです。

「市場」は、市場コストそのものによる制約です。すべての行為は多かれ少なかれコストを伴います。ビールの価格が2倍になれば、多くの人はビールではなく別の種類のお酒を選ぶことになりそうです。ガソリンの価格が倍増すれば、移動手段に自動車ではなく電車を選択する人が増えるかも知れません。このように、市場コストは人々の行動に確実に影響を与えます。

「アーキテクチャ」は、テクノロジーやシステムの形による制約です。これは『CODE』の中に取り上げられている道路のアーキテクチャの例がわかりやすいでしょう。スピードの出しすぎを抑制するために、あえて道路に凹凸を作る。あるいは定期的に信号機を配置する。こうした物理的なアーキテクチャは、スピード違反を抑制する効果を持ちます。

　この4つの指標をもとに、各種のDRMの働きを分析してみるとどういったことになるでしょうか。

従来型のDRMは「アーキテクチャ」の強化によって規制を実現しようとするもの

　違法コピーの問題に対して、著作権者は従来、もっぱらコピー阻止技術をもって対抗しようとしてきました。複雑な暗号化を施し、通常の手段ではコピーできなくする。映像信号に特定のパターンを混ぜ、ダビング行為を阻止する。これらはすべて、「アーキテクチャ」の強化によって違法コピーを阻止する手法です。ただ、これは技術をもって技術に対抗しようとするものであり、結局いつかは破られるものと考えなければなりません。DVD-Videoのアクセスコントロール技術が、当時まだ10台の少年だったヨン・レック・ヨハンセンによって突破された事例などはとても有名です。

　こうしたいたちごっこに終止符を打つべく、ハリウッドなどに多くの著作権者を抱えるアメリカで1998年に成立したのが「デジタルミレニアム著作権法（DMCA）」です。これは、DRMの解除を法的に禁止し、技術的手段などの公表も禁じる強力な条項を含む法律です。つまり、「アーキテクチャ」の強化でカバーしきれない部分を「法」によって補強しようとしたと言えます。日本でも2012年10月1日から改正著作権法が施行され、映像・音楽作品のDRMを解除する行為（リッピング）が違法となりました。このままこの流れが進めば、電子書籍に関しても同様の制限が適用されることになりそうです。

　ただ、DRMの解除を違法化することは、著作権者が私的に定めた著作権者の権利領域とユーザーの権利領域の境界線を、実質的に公的な境界線として追認してしまうことでもあります。従来は法の解釈次第だったグレーのエリアを完全にブラックにしてしまう。例えばCCCDの機能によって楽曲がiPodで聴けなくなるといったような例がわかりやすいでしょう。これは著作権者による一方的な「私的複製の制限」にあたります。また、そもそもストアに依存する堅牢なDRMは、特定の再生機器・再生環境をユーザーに強制することになり、結果的に市場を細分化してしまう問題点も含んでいます。
　電子書籍でもこれは同じで、現在特定のストアで購入した電子書籍は、例え複数のストアで共通のファイル形式を採用していたとしても、基本的に購入したストアのアプリや端末でしか閲覧することができません。こうしたユーザビリティの不自由さは、電子書籍そのものの魅力をシュリンクしてしまうことになりかねません。

IDPFのLCPは、ごく軽いDRMをかけて「法」による制約効果を狙うもの

　上述したような従来型のDRMの問題に対して、解決策のひとつとして現在提案されているのが、先日のセミナーで説明のあったIDPFのLCP（EPUB Lightweight Content Protection）です。これはまだ提案の段階であり今後どうなるのかわからない部分はあるのですが、現在出ている情報から判断すると、どうやらストアに依存しないごく軽いDRMだけをかけておき、現実的な違法コピーの抑止効果は「法」に依存するというモデルのようです。
　DRMがかかっていさえすれば法による抑止効果は期待できるのですから、ユーザーの利便性を損なう可能性の高い堅牢な従来型のDRMではなく、軽いDRMに止めるという考え方は理解できます。ただ、これが実質的な効果を発揮するには、アメリカ以外の国でも広範に法による著作権保護技術の解除禁止が定められる必要はありそうです。つまり、IDPFのLCPはアメリカの知財戦略と歩調を合わせての普及を考えているのではないかと思われます。

「規範」に加えて「法」によって違法コピーの抑止を狙うソーシャルDRM

　これに対して、「アーキテクチャ」による違法コピーの抑止を考えず、もっぱら「規範」のみに依存して違法コピーの問題に対処しようとするのが「DRMフリー」モデルです。オライリー・ジャパンなどはこのモデルを採用しているようです。これはユーザーの利便性を損なわないこと、複雑なDRM管理システムを必要としないことによるコストカットの効果などが期待できますが、違法コピー大量流通によるビジネスモデル崩壊の懸念を考えますと、これを躊躇無く採用できる出版社はやはりごく一部にとどまるでしょう。オライリーがこのモデルを採用できたのは、同社の販売している書籍が技術系の専門書であることに由来するように思います。

　そこで、コンテンツそのものに購入者の個人情報を埋め込んでおき（電子透かし）、違法コピーが流通した際の損害賠償訴訟などの法的なリスクを絡めることで「アーキテクチャ」を用いることなしに違法コピーを抑制しようとする考えが出てきます。これが「ソーシャルDRM」で、「規範」プラス「法」による抑止効果を狙うものと言えるでしょう。
　ただし、このモデルの成功には教育による「規範」の強化が不可欠で、物理的な本に比べて価値を感じにくい電子書籍などの情報コンテンツの不正入手を良しとしない「モラル」の育成が必要になるようには思います。

　あるいは忠実なファンを数多く抱えるコンテンツであれば、現状でもそれほど違法コピーによる売り上げ減を気にせずにこのモデルを導入できそうです。このわかりやすい例がハリー・ポッターシリーズの著者、J.K.ローリングが自ら運営する電子書籍版ハリー・ポッターの直販サイト「Pottermore」でのソーシャルDRMの採用でしょう。

「アーキテクチャ」によって違法コピーを抑止するブラウザ閲覧型電子書籍サービス

　一方、「アーキテクチャ」によって、いわゆるDRMとは違った方法で違法コピーの流通を阻止しようとするモデルもあります。これは、例えば動画で言えば「ストリーミング視聴」といったような方法で、インターネットに繋げてサービスインしている状態でのみコンテンツを閲覧できるタイプのものです。電子書籍ストアではボイジャーが展開しているブラウザベースの電子書籍サービス「BinB Store」や、同社のシステムを採用した「Yahoo！ ブックストア」などが上げられます。また、有斐閣が展開している法律書の定額読み放題サービス「YDC1000」も、このカテゴリに属するのではないかと思います。

　ボイジャーがこのタイプのストアサービスを選択した理由は、各OSごとに別々のアプリを開発するコストの問題があり、HTML5ベースのブラウザアプリならばプラットフォームの違いを比較的考慮しないでマルチに展開できるといった側面が大きかったようですが、そもそもインターネットでサーバーに接続している状態でしかコンテンツを閲覧できない性格を持つために、このタイプのサービスは必然的に違法コピーの抑止効果が高くなります。また、そもそも「情報提供サービス」としての色合いが濃いため、「アーキテクチャ」によって違法コピーの流通を阻止している点では従来型のDRMと同じであっても、比較的ユーザーの反発を受けにくい点は指摘できるかと思います。
　また、もし将来的に角川書店がBookWalkerで9月26日から開始した「ちょく読みforスマートフォン」のような一般ユーザー向けの「定額読み放題」電子書籍サービスが定着するとしたら、サービスの形態は最終的にこのブラウザ閲覧型に収斂していくのではないかと思っています。

補償金によって「市場」の抑止力を取り戻す考え方もある

　これまで上げたようなさまざまなタイプの違法コピー阻止の試みは、そもそもなぜ必要とされているのでしょうか？　これは、従来存在していた「市場」の抑止力が消滅したからではないかと思います。書籍を例にとっても、以前紙の書籍1冊分を複製するコピー代は、新刊書籍を購入する価格と変わらないか、下手をすればより高くつきました。また、コピーした紙の分厚い束はお世辞にも読みやすいものとは言えませんでした。従って自然と書籍をコピーするのではなく書店で購入するインセンティブが守られていました。書籍が電子化され、パソコンのハードディスク内にひとかたまりのデータとして格納されれば、それこそドラッグ＆ドロップで簡単に複製を作れてしまいます。かかる費用はほぼゼロです。すなわち、「市場」の抑止力が弱まったからこそ違法コピーの問題が起きてきているとも言えます。流通に関してもこれは同様で、かつては違法大量複製、大量流通は資金力の裏付けが必要な組織的犯罪でしたが、現在はP2Pネットワークなどの普及で、個人でもほとんど無料で違法コピーデータをばらまくことができてしまいます。

　こうした状況に対して、「市場」そのものの抑止力を取り戻すことで対処しようという考え方があります。すなわちインターネットへのアップロード行為そのものに関しては合法とし、その代わりに一定額の補償金を請求するといった考え方です。現状ではこれはYoutubeなどのネットワーク業者への補償金といった間接的な形をとらざるを得ませんが、将来的にはアップロード時に内容を自動チェックしていくらかのお金が請求されるといった形に変化していくかも知れません。ただこれは著作権そのものの運用を許諾権から報酬請求権にシフトさせることが前提になりますので、すでにそれが実質的に達成されている音楽などのコンテンツはともかく、電子書籍に関してはまだこれからの法改正、インフラ整備待ちになるといったところでしょうか。

　現状、書籍の著作権は個々の著作権者がバラバラに許諾権を有している形ですので、利用に際していちいち著作権者に連絡を取り、許諾を得る形になります。これではタイムラグや許認可の手間の問題でネット上での広範な著作物の利用はとても見込めません。この問題を解決するためには、少なくとも電子書籍に関しては権利処理を特定の管理団体に集中させ、そこに定められた金額を支払うだけで著作物を利用できるといった形に変化させる必要はあるでしょう。現状、許認可の手間が書籍の電子化の壁になっている状況を考えても、著作権運用の報酬請求権化は補償金制度に限らず、将来的に電子書籍を広く普及させることに関わってくるとても重要なファクターであるように思います。

　ただもちろんこのあたりの法整備は個人情報保護との兼ね合いもあり、きちんと時間をかけてきっちり議論をした上で構築すべきと思いますので、仕組みができあがるにはまだまだ時間がかかると見た方が良いと考えています。今回の改正著作権法におけるダウンロード刑事罰化法案のような拙速な立法プロセスはくれぐれも避けていただきたいところです。