Google Reader、livedoor Readerが対応

PubSubHubbubでRSSもTwitter並にリアルタイムに

2009/08/19

　「PubSubHubbub」（パブサブハブバブ）という奇妙な名前のプロトコルが注目だ。2009年8月5日にグーグルはRSSリーダーサービスのGoogle ReaderでPubSubHubbub対応を明らかにしたほか、国内ではライブドアが、同じくRSSリーダー「livedoor Reader」とブログサービスの「livedoor Blog」でPubSubHubbubに初対応したことを8月18日に発表している。まだ対応サービスは少なく、その“効能”も「ブログの更新がRSSリーダーに反映されるのが、ほぼリアルタイムになりました」というだけで小さく見えるかもしれない。しかしPubSubHubbubは、ネット全体のリアルタイムコミュニケーションプラットフォーム化を促す重要なキーとなるかもしれない。

Twitterが見せつけた“リアルタイム”のテンポの良さ

　Twitter人気が高まる理由はいくつか考えられるが、その1つが、リアルタイム性にあるのは間違いないだろう。これまでメールやIMのように基本的に1対1のコミュニケーションを除けば、ブログ、掲示板、SNSなど、そのほとんどは間欠的で自発的なユーザーのアクションに従って情報を“プル”する形で最新情報を取得する形となっていた。このため、ごくまれにチャット状態となることはあっても、基本的に数分とか数時間、場合によっては1日置きにメッセージが行き交うような準リアルタイムなコミュニケーションツールとして利用されてきた。

　これに対してTwitterは、Webページのリロードという作業は発生するが、たいてい数分以内の更新が次々と流れ込んでくる。地震や大きなニュースが発生した場合には、ほとんどタイムラグなしに、そうしたニュースが人々の間を駆けめぐる感じが手に取るように分かる。何かのテーマについて、2人または複数人で意見交換や感想を述べ合うような軽いコミュニケーションにしても、数分から数十分間にわたって発生することが多く、これはブログのトラックバックやコメントによるコミュニケーションに比べてはるかにテンポの速いものだ。

　こうしたテンポのよさに慣れてしまうと、かつては最新情報を提供・取得する有力な手段だったはずのブログやRSSですら、テンポが遅く感じられることがある。

Web Hooksでプッシュを実現

　ブログ／RSSの組み合わせでリアルタイム性が低い理由は、コンテンツ更新を購読者側に知らせる汎用的な仕組みがなかったことが大きいだろう。RSSリーダーを使うにしても、Webサイトに明示的にアクセスするにしても、そう手間や負荷の問題からそう頻繁にアクセスするわけにいかず、どうしても一定時間間隔を置いた“ポーリング”を行うことになる。

　これは、Web上に汎用的なプッシュの仕組みがないことが原因だ。サーバ、あるいはコンテンツ提供者側から購読者に向けて、コンテンツ更新を知らせる現実的な方法はメールぐらいしかない。

　Webに汎用的なプッシュの仕組みがあれば応用が広がるだろうと考えた人々が、少なくとも2008年頃から「Web Hooks」（関連ブログ）という名称で、コールバック的な仕組みを考え始めていた。これは、購読側があらかじめ自分が用意したコールバック用のエンドポイントURLをコンテンツ提供者側に登録することで、情報更新があったらそのURLをHTTP POSTで叩いてもらうというアイデアだ。

　Web Hooksは2009年1月にグーグルがプロジェクトホスティングサービスの「Google Code」で実装した例があるほか、日本では、はてなが2009年6月に、はてなブックマークで実装した例があった。Google CodeでWeb Hooksを使えば、誰かがコードをコミットした場合にその通知イベントを受け取ることができる。通知イベントを受け取るのは人間だけでなく、ビルドシステムや、バグトラッカー、プロジェクト管理ツールなどでもいい。

PubSubHubbubは、Web Hooksモデルで実現

　Web Hooksは、これまで能動的なHTTPアクセスに頼ってきたWebサービス間を、より効率的に接続するモデルとして一部の開発者が注目していた。PubSubHubbubは、このWeb Hooksと同様のモデルを使ったプロトコルだ。現在、バージョン0.1のドラフト版が公開されている。

　PubSubHubbubを使えば、RSSのフィード側から購読側へと「コンテンツ更新」などの通知イベントを送ることができる。名前が示唆するように、フィード側と購読者側の間にハブとなるサービス（サーバ）を置くことで、既存のフィード提供者や購読者（購読サービス）の変更を最小限にしているという。PubSubHubbubを開発し、オープンソースの実装を公開したグーグルのブラッド・フィッツパトリック氏の解説（動画）によれば、既存のブログサービスなどでPubSubHubbubに対応するのは非常に簡単だという。

　PubSubHubbubを使った購読では、まず購読者がフィード提供者に対してリクエストを出すところから始まる。もしフィード提供者がすでに何らかのPubSubHubbub対応ハブサービスを利用している場合、購読者はそちらにリダイレクトされ、今後はこのハブから通知を受け取ることになる。つまり、コンテンツを提供するフィード側は、ハブに対して更新情報を通知するだけで、多数の購読者に通知が届くことになる。デモンストレーション動画を見る限り、ブログ更新からRSSリーダー上での反映まで、ほとんどライムラグがない。

　現状では、PubSubHubbubの仕組みを考案したグーグルのエンジニアらが実装したハブ・サービスがAppEngine上で動いているだけだが、PubSubHubbub自体はオープンな仕様で、誰でも実装してハブとなるサービスを立ち上げることができる。将来的には大小のハブがネット上に分散して存在して、それが通知イベントをリレーするような形でネットワークが形成されるだろうという。PubSubHubbubに含まれる「Hubbub」にはハブ（hub）の意味と、「ぺちゃくちゃしゃべる」という意味の「hubble-bubble」の二重の意味が込められているのだろう（PubSubのほうはPublish/Subscribeの略）。

将来的なPubSubHubbubのモデル。緑がフィード提供者、ピンクが購読者、黄色がハブ。3者はときに役割を入れ替わりながら、分散環境で互いにつながるという（出典：PubSubHubbubのプロジェクトページ）

単に更新の反映が速くなるだけなのか？

　短期的に見れば、PubSubHubbubの効能は、ブログ更新からRSSリーダーへの反映のタイムラグが小さくなります、というだけの控えめなものだが、今後、もしPubSubHubbubのハブがWeb上に偏在するほど普及することがあるとすれば、Webに対して大きなインパクトを与える可能性があるのではないだろうか。

　Twitterが高いリアルタイム性を実現できているのは、単に技術上の問題だけでなく、文字数を限定してコンテンツ生成サイクルを短くしたことも見逃せないだろう。Twitterに文字数制限がなかったら、intの桁あふれを起こすほど多くのメッセージがやり取りされたかどうかは疑問だ。

　だから、たとえPubSubHubbubでリアルタイム性が上げられるとしても、ブロガーやニュース提供者などのコンテンツ提供側が、それに見合ったテンポでコンテンツ更新を行うようになるとは限らない。しかし、中長期的に見れば、リアルタイム性の向上とコンテンツ（メッセージ）の断片化はコインの表裏のようなもので、今後はブログのようなコンテンツでも、細かな情報更新や、短時間で複数人の間を数往復するようなコミュニケーションが広がる可能性もあるのではないだろうか。

Twitter的コミュニケーションの可能性も

　PubSubHubbubは、Twitterの一人勝ち状態に対する代案ともなり得る。Twitterがいくら優れたサービスだったとしても、特定ベンダが提供する1サービスである以上、それはインターネット的とは言い難い。これまでにもそうした懸念から、Twitterのようなマイクロブログサービスを、分散環境で実現しようする試み、例えば「OpenMicroBlogging」のようなものは存在した。Twitterライクなサービスを立ち上げるためのOSS実装も数多い。グーグルが買収して、最終的にサービスの開発継続を断念したJaikuも2009年3月にOSSとして公開されている。

　マイクロブログサービスを分散して連携させることは、技術的には可能だったとしても、そこへ至る道のりが、ほとんど見えない。いくらTwitterライクなサービスを立ち上げたとしても、誰にもそれに参加する理由がないからだ。

　一方PubSubHubbubは、既存サービス（フィード、リーダー）の小さな改変だけで済み、リアルタイム性の向上という目に見える利便性も付加するため、普及のきっかけがある。Ajax的なUIと組み合わせれば、Web型のRSSリーダーが、Twitterのような、メッセージアグリゲーションサービスへと進化していく可能性もあるのではないだろうか。