先日、twitter上で以下の記事で触れられた電子書籍の「買いにくさ」についてちょっと盛り上がりました。
・電子書籍を買いたいと思ったのに買わなかった話 | 拝むように弾いてくれ
電子書籍については、マガジン航の以下の記事が指摘するように、購入する以前にその「探しにくさ」も問題です。
・電子書籍の「探しにくさ」について « マガジン航[kɔː]
プラットフォームが乱立していることが原因の1つであることは間違いないのですが、AmazonやAppleのような巨大プラットフォームが日本で電子書籍事業を始めると解決する、とも思えないのです。どうしたものかと以前から考えていたのですが、OPDSが話題になっているようなので、現時点における自分の考えをまとめてみました。
1. プラットフォームの機能をレイヤーごとに分けませんか
ほしい本を購入できるプラットフォームのアカウントを持っていない場合、そのアカウントの取得から始めなければなりません。
プラットフォームは主にコンテンツへのリーチ、権利保護(DRM)、コンテンツへの課金という3つの機能を保有しています。それらをユーザーのアカウントに結びつけることによって、プラットフォーム内であれば、コンテンツへのリーチから購入、そして、その後のコンテンツの権利保護までをスムーズに行えるようになっているわけです(もっとも、検索はアカウントがなくてもできることのほうが多いと思います。また、DRMはDRMフリーを売りにすることもがあるので必ずしもというわけではないです)。

特に電子書籍の場合に顕著な気がしますが、プラットフォームの大小に関係なく、プラットフォームがそれぞれで各レイヤーを用意しているケースは少なくありません(ここには、出版社が自社サイトでコンテンツを売るような場合もここに含まれます)。つまり、ユーザーは(ググれば粗く見つかることは多いとはいえ)それぞれのサイトで検索をしなければならないし、購入しようと思うとそれぞれのサイトでアカウントを取得しなければなりません。

これはユーザーにアカウントの取得という手間をとらせるだけではありません。アカウントを停止するまで1年に何回使うかもわからないIDやパスワードの管理を強いることになります。それもサイトごとに別のアカウントですから、利用するサイトが増えるほど、管理するアカウントが増えていくことになります。ユーザーはその煩雑さに避けるために、すでにアカウントを保有している巨大なプラットフォームを利用することを選択してしまうわけです。
そうなると、中小のコンテンツプロバイダは巨大なプラットフォームにますます依存しなくてはいけなくなる。これをなんとかできないかと思うのです。
そこで、ということで、ここからがようやく本題ですが、
レイヤーごとを機能をわけて横断的に使うことはできないか
と思うのです。以下のように各レイヤーを別々のしくみやプラットフォームに任せたほうがまだよいのではないかと。

レイヤーがプラットフォームを横断するイメージは以下のような感じでしょうか。AppleやAmazonなどの巨大プラットフォームはDRMレイヤーや課金レイヤーを独自に持つことを選択するでしょうし、それでもやっていける。それでも、せめてコンテンツへのリーチはなんとかレイヤーを共有できないかと考えた図です。

上では「アカウント」レイヤーを共有するイメージを挙げていますが、他のレイヤーが横断的につかえるならば必要ないんじゃいか、そんな気もします。それが以下の図です。

2. アカウント
アカウントを共有する方法として、OAuth、OpenID、最近だとOpenID Connectもあるんですね。プラットフォームを横断してアカウントを共有するしくはいろいろとありそうです。しかし、このレイヤーは他のレイヤーが機能するなら、もしかすると必要がない、もしくは課金レイヤーが兼ねるのではないかという気もします。
1つ気になるとすれば、課金を課金プラットフォームに委ねるとしても、コンテンツプロバイダとしては購入した人の情報は知っておきたいと思うかもしれません。マーケティングに生かしたい、コンテンツのアップデートなどのサポートに生かしたい等々いろいろ理由はあるかと思います。これに対して、今のところ、回答らしいものは思いつきませんが、パッケージソフトのように購入後に会員登録を求めるとか、購入と会員登録を結びつけない方法は考えられそうです。登録をしないユーザーはそのデメリットを理解して会員登録しないわけですからね。書店で匿名で本を購入することが当たり前のように、電子書籍も匿名で購入するという手段はほしいなぁと思います。
3. リーチ(検索) -OPDS-
検索エンジンは、今更いわずもがなな感じがしますので、ここではOPDS(Open Publication Distribution System)について書きます。
「リーチ(検索)」と書きましたが、つまり、如何にユーザーに「発見」されるかということです。OPDSは簡単にいえば、オープンな出版物のメタデータ配信技術、もしくはオープンな出版物のメタデータ公開技術というべきもので、普及すれば、以下の図のようなことが実現すると思われます。

上の図のようなことが実現すると以下のようなことが可能になると思われます。
- これまでプラットフォームごとに検索する必要があった電子書籍をOPDSカタログを集約したサーバーを持つ検索エンジンによって横断的に検索できるようになります。
- プラットフォーム間のメタデータの交換といったB2Bな用途に使えます(実際にやるかどうかはともかく。どのプラットフォームでも検索だけは横断でできるようになる?)。
- プラットフォームを利用せずに独自に電子書籍を販売する出版社のコンテンツも1で集約されるので、読者により発見されやすくなります。
- 個人や企業、機関が自サイトに掲載するEPUBやPDFなど(「非商用電子書籍」)も1で集約されるので、検索できるようになります。
- 図書館は電子出版物のメタデータの収集(及び条件が許せばコンテンツ)を自動的に行えるようになります。
「リーチ(検索)」レイヤーの機能は主に1、3,4に該当します。Web上で無料で公開されているPDF形式のコンテンツなどが他の電子書籍と一緒に検索できるようになるとかなり面白いことになりそうですね。
【OPDSと関連しての】Linked Open Data
リーチとは直接、関係はないのですが、OPDSはせっかくWeb上でメタデータを公開することを前提としていますので、Linked Open Dataを絡ませてみたら非常に面白いのではないかと思います。しかし、とはいってもOPDSはAtomがベースとなっているフォーマットです。リソースに対する識別子があり、Linked Opend Dataに配慮された語彙を借用するならばどうであろうか。そもそもRDF形式でなくてもならないのでしょうか。可能なのでしょうか。
これは要検討、というよりも要勉強です。
4.DRM
DRMはほとんど調べていませんので、ここでは保留ということで、今回は飛ばします。
5.課金
最後に課金レイヤーですが、ここはPayPalのようなところなのかなぁとイメージしています。オーム社はPDF形式の電子書籍を自社のサイトで販売していますが、アカウントを取得せずともPayPalのアカウントだけでも購入できる選択肢を用意しています。何度もつかっていますが、すこぶる便利です。
もちろん楽天でもYahoo!でもいいですし、クレジットカード会社でもいいですし、携帯電話会社でもよいのです。レイヤーごとに機能を分断するのであれば、むしろ競争相手は多いほうが望ましい。しかし、マイクロ化が進むデジタルコンテンツの販売に対応できるマイクロペイメントサービスの展開が重要になってきます。クレジットカードや日本で課金代行サービスはまだまだ手数料が高く、マイクロコンテンツ向きではないように思います。少なくとも、いや、この場合は高くとも100円弱の課金でコンテンツプロバイダが利益を出せる手数料を提示できるか鍵になるのではないかと思います。
課金レイヤーは、オープンな技術や仕様等々の話は無縁かなぁと思っていたのですが、昨年にはW3CにはWeb上の決済の標準化を検討するCommutiy Groupが立ち上がったそうです。オープンで安全なマイクロペイメントのWeb標準を志向しているそうで、仕様化されるかどうかはわかりませんが、そこで行われる議論だけでも価値は十分あります。
・Webでの課金の仕様を検討するW3CのWeb Payments Community Group
どこかのプラットフォームに依存しないで、Web標準な仕様で課金が実現できるなら、それがあるべき姿だと思います。期待したいところです。
6. まとめ
こうして改めて書いてみると、私の関心は一環してコンテンツをプラットフォームの束縛から解放するところに集中しているのだなあと改めて感じました。まだ、深く掘り下げられていませんので、どんどん深く掘っていきたいところです。
とくにほとんど手つかずのDRMは大きな問題ですので、機会があれば調べてみたいと思います。