明日は明日のcoblog

徒然なるままに日々の由無し言をば。最近は某モバイル系IT企業で仕事中。

もう本屋が電子書籍リーダー作るの辞めません？

電子書籍

もう電子書籍の書店が電子書籍リーダーを作るの、辞めにしませんか？

 

そもそも、書店が読書方法を決めて、かつ読むための環境さえ提供することに強い違和感を感じているし。電子書籍リーダーだけで一体いくつアプリをインストールさせるんだ！と激しく言いたくもなる。

 

電子書籍リーダーアプリケーションを誰でも作ることができれば、何も書店が必死こいてUI考えなくても素晴らしいUIを備えた電子書籍リーダーが世に多く出てくるだろうし、自分のための電子書籍リーダーだって作ることができる。

 

そこで、電子書籍リーダーアプリケーションのオープン化実現のために少しだけ考えてみた。

 

一概に電子書籍フォーマットって言っても、これがホントにいろいろある。

 

国内だけで目に付くところをザッと挙げてみただけで、

 

・コミックで今なお大きなシェアを持つ.book(ドットブック)

・SHARPのXMDF

・自炊も含めて一般的な普及度ならダントツのPDF

・最近巷を賑わしているEPUB

・雑誌フォーマットとして一定の立ち位置を確保しているYappaのSpinMedia

 

これ以外にもAmazonKindleのTopazやモリサワのMCBook、青空文庫なら一般的テキストフォーマットをベースにしたものもあるし、変速的なEPUBなんてものもある。挙げ始めると本当にキリがないくらいだ。

 

詳細についてはこんなページも。

 

また、各出版社やコンテンツ毎に採用されている フォーマットがそれぞれ異なっていることと、なまじ流通していること、その他にも様々な理由のために、このマルチフォーマット事情はそうそうすぐには改善されそうにない。それは、たとえ今流行りのEPUB3に今後各社の足並みが揃ったとしても、膨大な既存コンテンツがある限り、依然マルチフォーマットリーダーエンジンのニーズは高い。まさか、既存コンテンツを金かけてEPUB化しないだろうし。つまり、日本で「使える」電子書籍リーダーを開発するためには、少なくともこれらフォーマットの大部分に対応させる必要がある。

 

だが、それらフォーマットの大部分について、その詳細な内部仕様が世間一般に公開されている訳でもないし、いくつかの主要フォーマットについては現時点において無償では利用すらできるものでもない。また、その次の段階として、仮に内部仕様が無償で使用できるようになったとしよう。これだけバラバラと存在する各フォーマットに合わせてリーダーエンジンを開発して用意するなんて、1個人に中々できることではないだろう。

 

加えて、DRMという非常に大きな存在が目の前に立ちはだかる。

 

このDRM(Digital Rights Managementについては、専らの理由がコンテンツの許諾元の版元に対するコンテンツ保護の目的のためである訳だが、この問題を解決しないことには電子書籍リーダーアプリケーション開発のオープン化を進めることはできない。

 

というよりは、現状のDRMの仕組こそが、リーダーアプリケーション開発のオープン化ができない理由そのものと言っても過言ではない。

 

また、それはDRMの仕様や実装技術が難解だとか言う問題では無く(確かに現状流通しているDRMアプリケーションの仕様の多くは読み解くのに根気を要するが)、DRMの存在意義そのものや、それに関わるモラル的な要素に端を発している。

 

無論、何もDRM仕様をオープン化することは無いし、 暗号化されたコンテンツの複合化機能のみライブラリとして隠蔽化をした上で提供し、復号化のためには購入後のダウンロードの際に書店で発行したライセ ンスKeyが必要とする方式にすれば良いの訳だが。

 

ただ、ライブラリとしてでも広く一般的に提供するということに対する、一部からの強い抵抗は確実にあるだろう。

 

たとえ一部機能のみをライブ ラリ提供するだけと言っても、やれ解読されやしないか？大丈夫か？等と必要以上の心配が指摘されることは容易に考えられる。ただ、そんなことを言えば、現状のDRM技術のほとんどが現在世に流通している様々な暗号化技術の積み上げと組み合わせに他ならないし、それこそそれなりの(とは言ってもかなり高レベルで はあるが)技術さえ有れば現在流通している電子書籍リーダーアプリケーションの挙動からさえ、ある程度の解読はできるんじゃないだろうか。

 

これらの問題については、技術的な課題を一つ一つ対応していき、それでも発生し得るだろうもしものケースに対するリスク管理をしっかり行う。また、コンテンツ許諾元である版元から理解を得るために版元への地道な説明を行なっていくことも忘れてはいけない。

 

それらを確実に行っていくことで、必ず潰していくことができるものだと考えている。

 

あと、書籍購入シーケンスを公開するのは流石にい ろいろと問題があるだろう。そこはオープン本棚の場合、本の購入はWebのストアで購入してもらい、購入した本の配信部分以降をWebAPI化すれば良い。また、書店自体が提供するリーダーでのみリーダーから電子書籍購入が可能とすれば、ちょっとした差別化をつけることも可能だ。

 

ここまでの話を纏めると、オープン化された電子書籍リーダーが提供すべき基本的な機能は、以下の3つになると考える。

 

1)購入済みの電子書籍をコンテンツ配信サーバからダウンロードする機能

2)暗号化されたコンテンツの複合化機能

3)全ての電子書籍フォーマットを再生可能なマルチフォーマットリーダーエンジン

 

つまり、簡単に言えば、1のためのWebAPIと1から3の機能の開発用ライブラリを書店側が提供する、というのが本文で言うところの「電子書籍リーダーアプリケーションのオープン化」である。まぁ、今の段階ではざっくりとした思いつきに毛が生えたレベルに近いんだろうけど、基本的な根幹はここらで良いんじゃないかと考えている。

 

最後に言っておきたいのは、何も書店がリーダーを全く開発するな、ということが言いたい訳では無い。エンジンの開発のためにもリーダーは必要であるし、一つのサンプルケースとしてもあった方が良いかもしれない。但し、書店がそこに力をかける必要はない、ということだ。

 

電子書籍リーダーを開発するということは、エンジ ンの開発だけで無く、UI設計という大きな要素を抱え込むことになる。これは想像以上にタフな要件で、そのためには社内で懸命に意見を集めたり、時にはテスターとして大量の人員を投入することもあるだろう。他社リーダーを絶えず研究しながら機能追加をしたり、日々サポート窓口に届く要望や苦情に耳を傾けて 改善を行い、デバイスに新機能が追加されたら速やかに対応する。当然各種フォーマットエンジンの開発やデバイスの基本OSのバージョンアップへの対応を行 いながら、である。

 

そして、これらのライフサイクルを維持するための体制を整備するだけで相当なコストが発生し続ける。到底書店が片手間にやるレベルではないし、効率が良いやり方とは到底考えられない。それよりも、どうせお金と労力をかけるのであれば、先日書いた記事のように書店としてやるべきことは他にたくさんある筈だ。

 

以上、今回はパパッと考えたところを半ば勢いで書きなぐってみたが、今後は(機会があればw)個々のトピックに対してより詳細に突っ込んだ内容や、電子書籍リーダーAPIオープン化のもたらす素晴らしさについても書いてみたいなぁ、と。