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

ハーバード大学法学部教授で、クリエイティブ・コモンズ代表でもあるローレンス・レッシグは、著書『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などのネットワーク業者への補償金といった間接的な形をとらざるを得ませんが、将来的にはアップロード時に内容を自動チェックしていくらかのお金が請求されるといった形に変化していくかも知れません。ただこれは著作権そのものの運用を許諾権から報酬請求権にシフトさせることが前提になりますので、すでにそれが実質的に達成されている音楽などのコンテンツはともかく、電子書籍に関してはまだこれからの法改正、インフラ整備待ちになるといったところでしょうか。

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

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

1　メディアクエリを設定してEPUBをパッケージ化

　前回同様にまずこちらの手順で作成したXHTMLデータを流し込み、FUSEeβで固定レイアウトEPUBパッケージを書き出しますが、今回は異なるデバイスでそれぞれに最適化させた表示をさせるためにCSS3のメディアクエリを利用しました。メディアクエリ（Media Queries）というのは表示環境ごとに異なったCSSを適用するための設定で、画面の縦横のピクセル数などを検知して、適用するCSSを切り替えることができます。メディアクエリの設定についてはこちらなどが参考になります。
　今回はkobo touchとkoboアプリ／iBooksでCSSを切り替えて最適な表示をさせるために、これを利用します。
　kobo touchの横幅ピクセル数は600pxですので、これを境にCSSを切り替えることとし、XHTMLのヘッダー行に以下のように記述しました。

<link href="../style/kobotouch.css" rel="stylesheet" type="text/css" media="only screen and (max-width:600px)" />
<link href="../style/koboapp_ibooks.css" rel="stylesheet" type="text/css" media="only screen and (min-width:601px)" />

　これで横幅600ピクセルを境として「kobotouch.css」と「koboapp_ibooks.css」が切り替わります。

2　FUSEeβで固定レイアウトEPUBとして書き出す

　前回同様、必要なファイルの登録を済ませた後、とりあえずEPUB3パッケージとして書き出してしまいます。前回の経験でkobo touchがEPUB3固定レイアウトに対応していないことがわかりましたので、今回は固定レイアウトに対応しているiPadのkoboアプリ及びiBooksに合わせて、幅768px、高さ1024pxの固定レイアウトEPUBとして書き出しました。iBooksに対応させるため、今回は「iBooksを有効にする」のチェックボックスをオンにしました。

　なお、第3世代iPadの解像度は幅1536px、高さ2048pxですが、ここの指定（viewportの指定値）は幅768px、高さ1024pxで問題ないようです。iPhone版でも全体がそのまま縮小表示されるところを見ると、どうも縦横比だけを見ているのではないかと思われるのですが、そのあたりは専門ではないので深くは突っ込みません^※1。

3　拡張子をEPUB→ZIPに変更してパッケージを解凍する

　前回同様に作成したファイルの拡張子をEPUB→ZIPに変更し、パッケージを一度解凍します。これにより、XHTMLなど各ファイルの修正、CSSの記述・修正が行えるようになります。

4　「fixed-layout.css」へのリンクを削除する

　各XHTMLファイルにFUSEeβが自動挿入する「fixed-layout.css」へのリンクの記述を削除します。この自動挿入される「fixed-layout.css」の内容は<body>タグのwidthとheightの指定ですが、これが原因で解像度の異なるkobo touchで表示が崩れますのでリンクを削除し、メディアクエリで振り分けられる固定レイアウト用のCSSファイル「koboapp_ibooks.css」にこちらの記述を追記します。さらに「fixed-layout.css」ファイルそのものも削除します。

5　opfファイルを編集する

　ファイルが存在していないのにopfファイル内に登録が残っていますとバリデートチェックでエラーが出ますので、パッケージファイル「content.opf」をテキストエディタで開き、さきほど削除した「fixed-layout.css」ファイルの登録行を削除します。

<item id="style.fixed-layout.css" href="style/fixed-layout.css" media-type="text/css" />

　上記の行をまるごと消します。なお今回はファイル全体を固定レイアウト指定しましたので、前回行った固定レイアウト指定関連の修正は行っていません。

6　iBooks用表示指定ファイルを修正する

　EPUB3パッケージデータ内「META-INF」フォルダ内の「com.apple.ibooks.display-options.xml」をテキストエディタで開いて修正します。このファイルはiBooks用の表示指定ファイルです。ここに「<option name="fixed-layout">true</option>」とあるのがEPUBファイル全体の固定レイアウト指定の指示で、パラメータがtrueかfalseかでiBooksでファイルを開いた際のリフロー表示／固定レイアウト表示が切り替わります。
　今回は2行目の「<option name="open-to-spread">true</option>」の「true」を「false」に修正しました。この設定は最初にファイルを開いた際にページを見開きで表示するか、1ページを拡大して表示するかの切り替え設定です。今回は1ページを拡大して表示させる設定にしました。こちらの参考ページを見る限りではデバイスの画面の向きをロックすることなども可能なようですが、今回は設定しませんでした。また、EPUBファイル内にjavascriptを埋め込み、iBooks内で動作させる場合などは、ここで「interactive」の設定を「true」にしておく必要があるようです。

7　CSSの記述・修正

　CSSの調整を行います。今回は2種類のCSSをメディアクエリで分岐適用しますので、それぞれの画面サイズごとに設定を順次追い込んでいきます。今回はDreamweaverを利用してデバイスをシミュレーションしながら設定し、最終的な調整はパッケージングしたEPUB3ファイルを各デバイスで開いて表示を確認しながら行いました。
　なお今回は、koboアプリ／iBooksでは2段組で一部の写真を裁ち落とし的に配置して雑誌風のレイアウトを狙い、kobo touchでは画面横幅一杯に写真が表示されるようにしています。

8　EPUB再圧縮、kobo／Readiumで確認

　EPUBデータを再圧縮し、ビューアで最終確認します。圧縮の方法などは前エントリステップ8のリンクをご参照ください。

早く読む技術、ナナメ読みの技術

　まず、視覚障がい者は健常者に比べてずっと早いスピードの音声を認識できるという話があり、これはなかなか興味深いものがありました。実際に音声の高速読み上げデモも行われたのですが、私などでは到底何を言っているのかわからない2倍速での再生でも、視覚障がい者の方は普通に聞き取れてしまうとのこと。また、ホームページ読み上げに関連したナナメ読み／要約技術のデモもあり、ぐるなび等の口コミ評価サイトの要約デモが行われていました。これは投稿レビュアーによって書き込まれた各店舗の大量のレビュー記事の中から「良い／悪い」という言葉およびそれに類する言葉を含む段落だけを自動抽出し、読み上げる技術とのことで、実際に聞いてみると確かに大づかみにその店の評価を知ることができます。
　これは視覚障がい者向けだけではなく、例えば目で文章を追いにくい運転中に使うカーナビ等と連携した利用にもニーズがありそうかなと感じました。また、現状読み上げ技術は高齢者向けなどの実装が中心で、視覚障がい者向けの速読技術はニーズが限られているために技術開発が進みにくい面があるとのこと。このあたりは今後の対応に期待がかかるところです。

クラウド・アクセシビリティ／ソーシャル・アクセシビリティ

　コンピュータによる自動認識では足りない部分を、多数のボランティアによる人間の知能で補うことで総合的に優れたサービスを実現する試みも数多く試みられているようです。例えば視覚障がい者がスマートフォンの専用アプリで撮影したものをクラウドサーバーに送って自動画像認識し、音声で読み上げるようなシステムで、認識できなかったものはクラウドサーバー経由でボランティアの元に送られて人間の目で確認、文字入力されて結果が音声で読み上げられる、といったようなソリューションのデモが行われたのですが、なかなか興味深かった点として、単純にボランティアの補正によって補完するだけではなく、認識結果はコンピュータ側に記録としてフィードバックされて自動認識エンジンの改良に使われるとのこと。これはおそらく検索エンジンの画像認識など一般ユースへのフィードバックも含んだ考え方と思われます。ただ、こうしたクラウド連携サービスは現状英語ベースのサービスがほとんどで、日本語の認識という意味では難しい面があるとのことでした。

アクセシブルな電子書籍制作の課題

　さて、本命です。まずは電子書籍制作のコストのお話から。アクセシブルな電子書籍を制作するには、画像をスキャンしてパッケージングするだけではなく（レプリカフォーマット／緊デジフィックス型）、きちんとテキスト起こしをし、構造化する必要があるとのお話がありました。この「きちんとテキストベースで制作され、構造化された電子書籍である」ということが、実際のところ最低限のアクセシビリティの保証とほぼイコールになってくるようです。iBooksなどにはすでにEPUB3文書の合成音声読み上げ機能が実装されていますので、これは確かに頷けるところがあります。
　この構造化テキストの制作工程で特にコストがかかるのは、OCR処理されたテキストを校正する工程、構造化する工程とのことで、特に日本語は26文字しかないアルファベットに比べて圧倒的に文字数が多く、さらに縦組み／横組みの混在、多言語混植、ルビや圏点の存在など欧文書籍にはない要素が多数あるため、OCR処理の技術的ハードルがとても高いとのこと。従ってOCR処理後のテキストに必然的に間違いが多く、校正のコストが高くつくとのお話で、これは制作現場の経験からもその通りと思います。

　またこれは質疑応答の後に関係者の方に確認した話なのですが、現状日本語OCRソフトはShift_JISの範囲の文字認識がせいぜいで、Unicodeの範囲をきちんと認識できるものはおそらくないだろうとのこと。つまり、JIS第3・第4水準漢字は現状OCRでは認識できないと考えた方が良さそうです。さらに、以前のエントリーでも書かせていただいたように、印刷物の制作に使用できる文字の数はUnicodeで使用できる文字の数を上回りますので、こうしたUnicode領域外の異体字などは当然OCRでの自動テキスト化は期待できません。日本語書籍の電子化が遅々として進まないのはこうした部分にも一因があるのではないでしょうか。

　海外ではBookShareというサービスが存在し、国のサポート、ボランティアの支援によりベストセラー書籍が出版された翌日には点字／DAISYフォーマット化されて入手できるルートが整っているとのことなのですが、上記の理由により日本では同一のモデルの成立は困難だろうとのことです。こうした部分を解決するには、日本ではやはり出版社自身による紙書籍と電子書籍の同時刊行が必要になってきそうです。

校正作業のゲーム化、パスワード認証との連携

　日本語書籍に比べればまだマシとは思いますが、アルファベット圏でも過去の印刷物のテキスト化に伴う校正のコストに頭を悩ませているのは同じです。そうしたコストを削減するための海外でのさまざまな試みの紹介がありました。
　オーストラリア国立図書館の校正作業の一般開放の試み（Trove）や、フィンランド図書館の校正作業をゲーム化して一般公開する試み（Digitalkoot）などの紹介があったのですが、特に面白かったのはGoogleが買収したパスワード認証システム、reCAPTCHAについての説明です。

　ゆがんだテキストを目で確認して入力することでサイト認証を行う仕組みはすでにあちこちで目にするところなのですが、reCAPTCHAはこれを一歩進めて、パスワード認証用の画像と並べてOCRでの文字認識に失敗した画像を配置し、利用者に双方を入力してもらうことで無数のユーザーに無意識のうちに校正作業に参加してもらうというシステムで、これはすでにGoogle Booksでの書籍電子化にも利用されているとのこと。集合知によって厖大な作業量をカバーする、いかにもGoogleが好みそうなアプローチです。
　Webで調べた限りではこのreCAPTCHAの出題項目に日本語や中国語が出てくることもあるようです。これはGoogle Booksプロジェクトで電子化するためにスキャンしたテキスト画像が自動で振り分けられているものと思われます。英語文化圏の住人に日本語文書の校正入力をきちんと行える人がそう多くいるとも思えないので、あるいは国別に割り振りが行われていたりするのでしょうか。

　また、OCRの認識精度向上のために人間の入力結果を利用する試みもヨーロッパの図書館や公共研究機関を中心に盛んに行われているとのことで、これは是非、日本の研究機関や関連企業にも頑張っていただき、せめてJIS第3水準、第4水準漢字レベルの認識が可能なOCRソリューションに早く登場して欲しいと思っています。素人考えですが、一度文字レベルで自動認識させた仮テキストを、辞書と連携した熟語認識エンジンで整合性チェックする、といったような仕組みでOCR処理の精度アップが図れないものでしょうか？