自炊書籍の閲覧ソフトウェア環境として理想を述べる

今回は、僕の考えた最強の電子書籍閲覧環境について系の話である。

自分を含めて、周りではiOSやAndroidを用いて、自炊した書籍を閲覧したいという要望が強い。

たとえば自分の例では、iOSの電子書籍ストア・アプリの1つにて、コツコツと買い続けてきたものが、突然サポート終了になり、書籍データのダウンロードはできるが、アプリのダウンロードはできなくなってしまった、という体験をした。DRMのかけられたデータ・もしくは電子書籍サーバから配信されるデータは自身でコントロールできない。もう二度と電子書籍なるものを買うか、と心に決めた(が、その後も少しは電子書籍を買ってしまっている…)。

また自炊した資料を、自由に閲覧したい、という要望もある。よって、自炊した書籍を閲覧したいという要望が強い。

自炊した書籍を閲覧するにはiOS,Androidアプリを用いるのだが、いくつか問題がある。例えば、対応する画像形式に割と厳しい制限があったり、書籍データの配信や既読情報管理が面倒だ、という点だ。ちなみにこの既読情報管理という話は、異なるデバイス・タブレット上で、「どのデータを閲覧したか」「いつ閲覧したか」「その評価はどうだったか」などのメタ情報を保存したい要求のことだ。これは自分自身が欲している。

もちろん、これら複数の問題は手間をかければ面倒だが解決が可能であるが、どうにかしたい。

そこで風呂に入りながら、ボーっと理想の形態とはどのようなものか考えていた(本当は別のやらなければならないことについて考えなければならないのだが逃避した)。

理想の自炊書籍の閲覧環境

1つの解決方法は、自分で自作の自炊電子書籍管理アプリを作ることだ。全ての画像形式に対応し、既読管理・書籍データの配信は、Dropboxや自作のサーバソフトウェアなどを使うことになるだろう。ただ、この時点でiOS、Android、WP8向けにアプリを作るなど地獄だ。3タイプの開発環境を保持するなど、正気ではない。いや、自分だけで使うアプリの話だから、いいのだけれども、どうせなら、すべてのデバイスで使いたい。

話を戻して、例えば、各ベンダー向けのアプリを作るとして、配信や既読管理に自作のサーバソフトウェアを必要とするのであれば、初めからHTML5を使ったブラウザ上で閲覧できるシステムを作った方が良いのではないか、とも考えられる。HTML5を使ったシステムであれば、iOSでもAndroidでもPC上でも閲覧が可能である。商用のシステムでも、HTML5を用いて十分に実用になっているものもある。HTML5上で閲覧すると同時にメタ情報を保存する。形式の異なる画像でも、サーバ上ならライブラリを用いて容易に変換できる。配信の問題はなく、どうやってサーバ上にアップロードするのか、という課題が残るだけだが、これも簡単に解決できるだろう。操作性も問題ないだろう。

欠点は、オフライン状態での書籍の閲覧が困難だろう点(ブラウザ上のストレージには、それほど大きいデータは収納できないはず)である。

これらの検討を進めていった結果、subsonic方式が良い、と思った。

subsonic方式の自炊書籍の閲覧環境

subsonicとは、Javaで動作する音楽向けのメディアサーバソフトウェアであり、オープンソースである。Windows,Mac,Linuxに自分で入れて使う。subsonicはWebインターフェースを持ち、Web上からでも自分がアップロードした音楽を再生できる仕組みになっている。また音楽ファイルのメタ情報を解析して、曲名やジャケット画像などの表示、そこからのプレイリスト作成も可能である。

subsonicの機能の中でも最も有用だと思えるのが、APIである。このAPIを用いてiOSアプリやAndroidアプリから、音楽を読み込んで再生できる。アプリで読み込むことで音楽をキャッシュすることができ、オフライン状態でもある程度使うことができる。プレイリストはローカル側でもサーバ側でも管理することができる。音楽ファイル形式が異なる場合は、mp3に変換して配信してくれる。

ここまで考えたところで、ああ、subsonic的な自炊書籍メディアサーバが自分の理想だったのだ、ということが分かった。自分の音楽を聞く環境はiTunesからsubsonicにすべて移行してしまった。iTunesでメタ情報の管理自体は今でも行っているのだが、聞く環境についてはsubsonicに任せている。どの端末からでも、PCからでもiOSからでも自分の音楽を聴くことが出来る利便性は大きい。

subsonic的な特徴を備えた自炊書籍メディアサーバを想像する

SUBSONIC的な自炊書籍メディアサーバ

上図はsubsonic的なメディアサーバがどのような関係を持つのかを示した図である。まず、Webインターフェースを持ち、PCブラウザからは簡単に閲覧できる。APIを持ち、スマートフォン・タブレットアプリはAPIを通じて書籍データにアクセスする。場合によっては、オフラインのためのキャッシュをアプリは行う。画像形式がクライアントアプリに対応していないものである場合・もしくはクライアント端末の解像度に対して大きすぎる場合は、変換を行ってから配信する。既読管理などのメタ情報はサーバと共有され、オフライン時にはクライアントアプリに保持され、再接続した際に同期される。

subsonicはそうなっていないが…基本的に多くの機能は外部アプリ向けAPIを通じて操作するように設計されるべきであり、WebインターフェースにてJavascriptやFlashでクライアントを作成する場合は、そのAPIを用いて閲覧や既読管理できる方が望ましいと考える。例えば、クライアントアプリによる書籍閲覧では端末の解像度や受け入れることのできるファイル形式をのせてリクエストAPIを叩き、Webインターフェースによる書籍閲覧ではブラウザのサイズと対応ファイル形式をのせてJavascriptからAPIリクエストを行う、という形になる。この前者と後者のAPIは共通のものであり、片方のインターフェースが出来ることは、もう片方のインターフェースでも可能になる。そうすることで、漏れのない良いシステムが出来ると思う。

subsonic的な特徴を備えた自炊書籍メディアサーバの特徴のまとめ

  • 自炊書籍メディアサーバ
    • オープンソースである
    • サーバ上で動作するメディアサーバ用のソフトウェアである
    • Webインターフェースを持ち、HTML5もしくはFlash技術を用いてPCブラウザ上で閲覧できる
      • HTML5を使用する場合は、タブレットやスマートフォンなどのデバイス上でもWeb閲覧できる
      • HTML5もしくはFlashを用いる場合、後述のAPIを通した作り方が、システムとしてシンプルである
        • Javascriptを用いてAPIにアクセスしてJSON形式の応答を解釈する、という流れ
    • APIを持つ
      • APIを用いて認証・書籍データの配信・メタ情報(既読・評価・メモ)管理できる
      • APIは仕様が公開され、iOSやAndroid、WP8等のアプリから利用できる
    • 画像形式がjpg,pngでなければ、それらの形式に再変換して配信を行う
      • 回線品質(Wi-Fi,3G)に応じて圧縮品質を変える
    • あったらいいな機能
      • Web上の好きな記事のPDFを作成して、保存しておける機能
      • デバイス紛失に対応するために、デバイスごとに有効・無効が設定できる

こうした公開API仕様が世に広く広まり、DRMなし電子書籍を購入したら自分のサーバに簡単に入れることが出来る、だとか、自分が書いた本をメディアサーバに入れて、ほかの人に公開する、だとか、自分の既読・評価・メモリストをほかの人と共有するだとか、色々なことができるようになる、予感がある。共有された情報はAPIを通じて、電子書籍アプリに配信され、本を読みながら、ほかの人のコメントが読める。

APIの作り方次第でいろいろな世界が見える。

少し別な話だが、

音楽向けのストレージサービスをしようとするのなら、サービス運営者は音楽の著作権者にお金を支払わなければならない、という判決(MYUTA事件)が過去に出た。

音楽向けのストレージサービスへのアップロードや、音楽データの配信のための複製行為の主体がサービス側にある、と判断されたからだ。よって私的な複製が成立せず、複製に対して主体であるサービス運営側はお金を支払い必要が出た、というわけだ。

それはそれで問題で、当時は憤慨した。しかし、これを回避する方法がある。それが今回のsubsonicのような利用者自身が複製の主体になるようなメディアサーバを用いることである。

「subsonicや今回の自炊メディアサーバのように自分自身が複製の主体となるシステムを構築すべきである」という、世の流れになることは悪いとは感じない。すなわち、日本においては著作権者の許可を得ずに複製するのであれば、他者に複製の主体を与えずに、利用者自身で複製のコントロールしなさい、と。そういう流れになっている。最近は、これはこれで面白い、と思っている。

subsonicのようなサービスを、簡単にサーバに入れることが出来て、自分でコントロールできる世界の方が面白い。スマートフォンのアプリのように、サーバアプリが入れ替えできるような世界。あの判決を逆手に取れる開発者なら期待できる。subsonicはWindowsにもインストール可能だが、PCに入れるのは現実的ではなく、外部のサーバを安く借りて使いたい。VPSなど安価サービスの登場のおかげでサーバの保持のための必要なお金は下がってきているので、そういった安価サーバサービス向けの簡単プラッガブルなサーバアプリができることにも、また、期待している。

こういうの書いていると作りたくなってくるな…

iPodのiTunesと今後のタブレットについて

昔、iPodの成功はiTunesだと、聞いて。

当時のmp3プレイヤーは単純にmp3ファイルをストレージにコピーすれば使えるようになるものだった。それは一見使いやすいように見える。当時、友人が使っていたウォークマンに音楽を入れるためのツール、sonicstageなるものを見せてもらったが、どのように使えばよいのか分からなかった。

iTunesはCDを入れたら勝手に起動して、インポートする、というボタンをクリックするだけで曲が名前つきでリッピングされていく。楽だ。これは、既存の音楽CDを持っていて、それを持ち歩きたい、という要求から来るものだ。

PC上でプレイリストを作って、同期することが出来る。逆に言えば、PCがなければ上手く設定することが出来ない。PCと同期しない選択肢は、MDデッキなどでCDからMDに吸い取る、というものなので、現実的ではなかった。

仮に、CDから簡単にリッピングして簡単にiPodに同期できるソフトウェアが存在することが、音楽プレイヤーとしての勝利であるのなら、タブレットに関してはどうだろうか。

一旦、picasaのそれが近い、と思った。picasaはデジタルカメラの写真を管理することに優れており、顔認識して分類することもできる。一覧して写真を見たりなどの操作がしやすく使いやすい。

しかしタブレットの皆のゴールは写真だろうか。否、書籍だ。

iPodはCDからのメディアの載せ替えだったように、書籍からタブレットへの乗せ替えはどうだろうか。書籍からスキャンした結果(自炊したもの)を上手くPC側で管理できるソフトウェアが思いつかない。

であるのなら、電子書籍を対象としたタブレットを設計するメーカーは、積極的に自炊を支援することが必要ではないか。自炊した結果を美しく管理できるソフトウェアをバンドルすべきではないか。

すなわち、現状のタブレットのビジネスにおいて、新しいメディア・電子書籍を売る、という一点に着目しすぎており、既存の書籍を電子化したいニーズを無視していると感じる。

iPodの場合は、既存のCDユーザーを取り込みライブラリを作成させ、その上でiTunes Storeの提案を行い、使い込んだライブラリの中に溶け込むように音楽を売っていった、ように見える。ライブラリを使い込んで、今後ずっとそのライブラリ(とソフトウェア)と付き合っていく覚悟が出来なければ「ひも付き」の音楽なんて買えない。

このiPodのやり方を踏襲するのであれば、まず、既存書籍のライブラリ化が必須であり、その使い込んだライブラリに次は電子書籍を入れるか、という順番でなければ乗り換える気がユーザーには起きないのではないか。一口にライブラリ化といっても、画像をきれいにしたり、文字をOCRしたり、など、様々な後処理が考えられる。工夫のしどころはある。

よって、「電子書籍ユーザー対象のタブレットの勝利を決める要因は、既存の書籍のライブラリ化を簡単に、そして美しく行える同期ソフトウェアのバンドルによって左右される」と、考えている。

という、お話でした。

自分の好きな解説記事やブログ記事を電子書籍化して他の人に渡してみたい

自分の好きな解説記事やブログ記事を電子書籍化して他の人に渡してみたい要求がある。

これを実現するシステム構成について考えているが、最後の段階で上手くいかなかった。
続きを読む 自分の好きな解説記事やブログ記事を電子書籍化して他の人に渡してみたい