Subscribed unsubscribe Subscribe Subscribe

Kentaro Kuribayashi's blog

Software Engineering, Management, Books, and Daily Journal.

ソーシャルグラフについて

翻訳

Web 2.0の次はこれだ!との呼び声も高いソーシャルグラフについて、LiveJournalのファウンダーであり、数々の優れたソフトウェアの作者としても名高く、また、最近ではSixApartを離れることとなった件でその去就が注目されてもいるBrad Fitzpatrick氏が、"Thoughts on the Social Graph"と題するマニフェストを発表した。さっそく一読して、これこそが、今後追求されるべき課題だという思いを、いっそう強くすることとなった。そこで、理解を深めるために、翻訳を試みた。

ここしばらく、私はソーシャルグラフについてあれこれと考えている。つまり、グラフを集約すること、分散化、社会的な関係のポータビリティ等についてだ。
最近、なんらかのカンファレンスで私を見たことがある方なら、ソーシャルグラフについて私があれこれと話すのを聞いただろう。私は、スライドや図解を用いたり、聴衆の反応や質疑応答に臨機応変に対応したりしながらプレゼンテーションするのは得意だが、多様な読者が目にするブログのような場所に、このようなことについて書くのは、非常に難しい。また、ブログに書いた結果「それ○○でできるよ。とにかく、君の考えはまったくもって間違ってる」といったコメントの嵐になってしまうかもしれない(訳注:Plaggerではできません)。しかし、そろそろ考えを述べるべき頃だろう。
現状においてどのような試作品があるのか、また、私が何を作りたいと思っているのか(どんなものが作られてほしいと思っているのか)について説明する前に、まずは、なにが問題であるのかについて述べ、また、その根底にある諸前提について述べたい。

  1. なにが問題なのか
  2. 目指していること
  3. 目指していないこと
  4. このプロジェクトの前提
  5. 開発の進捗状況
  6. 将来どうなるか
  7. 協力してくれる方へ
  8. 結論
  9. 関連するかもしれないプロジェクト

なにが問題なのか

従来型のウェブサイトのみならず、いわゆる「ソーシャルアプリケーション」がますます増えてきている。それらのアプリケーションは、「ソーシャルグラフ」を必要とするか、あるいは、ソーシャルグラフにより得られる情報を利用することで、ユーザに対してより価値あるものとなり得る。私が「ソーシャルグラフ」という言葉によりいわんとするところは、Wikipediaにある通り、また、私が後に詳述する通り、全ての者を位置づけるグローバルなマップである。残念なことに、包括的かつ脱中心化されたソーシャルグラフは、存在しない(相互に運用可能な複数のグラフについてもまた、同様である)。それどころか、信頼が置けず、また、それぞれのサービス内でしか利用できない、何百ものばらばらなソーシャルグラフがあるばかりだ。
たとえば、dopplr.comのような、友人がいつどこへ旅行にでかけるのかを知ることができるといった、ある特定の便利で魅力的な機能を提供するためにソーシャルグラフを必要とする、新しいサイトを開発する場合を考えてみよう。単に主な機能を実装するだけでは済まず、さらにずっと大きな問題に直面するだろう。ユーザ名、パスワード(願わくば、OpenIDを使いたいところだ)、友人を招待する方法、友人関係の追加や削除、まだ他にもたくさんある。たいていの場合、メールアドレスを入力してもらう必要があるし、また、そのアドレスに確認のメールを送らなくてはならない。それから、ユーザが、ユーザ名やパスワードを忘れた時に送るメールのこと、などなど。簡潔にいうと、人々は、それぞれのサイトでいちいちユーザ登録をしたり、友人関係を入力したりしなければならないことに、うんざりしている。開発者にとっても、「ソーシャルアプリケーション」の開発は、過度に労力を要する作業になってしまっている。
そのような問題に対して、Facebookは、単に全てのアプリケーションがFacebook内にあれば解決することではないかと考えているようにも見受けられる。Facebookは素晴しいプラットフォームであるし、技術的にも優れたところがあるが、Facebookが今後も良き存在であり続けること、安定してサービスが利用可能であること、オーナーが変わった時にルールが変わってしまわないこと等に依存する、隷属的な立場になってしまうことを、開発者や「ウェブ2.0」的コミュニティは躊躇している。そうしたためらいは、十分に根拠のあるものであると思われる。インターネットにとって、「ソーシャルグラフ」の全てを手にした中心的な存在は、悪である。だからといって、Facebookを排除せよといっているわけではない!まったく違う。Facebookは素晴しいし、私自身、とても好きなサイトだ。しかし、ソーシャルグラフFacebookの外にあるべきだ。MySpaceもまた、多くの良質なデータを保有している。しかし、それが全てではない。LiveJournalDiggTwitter、Zoomer、Pownce、Friendster、Plaxo、そしてまだまだ他にもあるたくさんのサイトもについても同じことがいえる。より重要なのは、それらのうちどれかひとつのサイトがデータをため込むべきではないということではなく、どのサイトもそうするべきではない、あるいは、全てのサイトにとってそれが利用可能であるべきだということだ。データは、ただ単にそこにあるだけでいい。

目指していること

  1. 最終的には、全てのサイト上のデータを利用し、しかし、グラフを保有するたったひとつの企業や組織に依ることなく、ソーシャルグラフをコミュニティの財産にすること。
    1. 全てのソーシャルネットワークサイトからグラフを集め、統合し、グローバルに集約されたグラフを再配布する非営利団体を設立し、オープンソースソフトウェアを制作する(その際、著作権については、当該非営利団体が保有するものとする)。そのことにより、他のサイト(あるいはユーザ)の小規模な利用に際してはパブリックなAPIを、より大規模なユーザによる継続的な更新の必要な利用に際しては、更新内容や数々のAPIを通して、データのダウンロードを可能にする。
    2. 初期段階においては、当該非営利団体のサーバおよびデータベースが中心的な役割を果たすことになるだろうが、その他の誰もが、自らのスペースにおいてデータを共有することが可能となる仕組みを保証する。svnではなく、gitのようなものだと考えるといいだろう。どこが提供するAPIやサーバを利用するかは、利用者次第だ。あるいは、自らデータを共有するサーバを運営することもできる。
  2. 開発者にとっては、自ら未加工のデータからグラフを解析しなくて済むよう、以下に挙げる高レベルのAPIが必要である。
    1. あるノードと等価なノードを返すAPI。たとえば「LiveJournalのbrad」というような形で与えられたひとつのノードに対して、LiveJournalの"brad"、Voxの"bradfitz"、そして4caa1d6f6203d21705a00a7aca86203e82a9cf7a(私[訳注:原著者のBrad Fitzpatrick]のFOAFで利用している、メールアドレスのmbox_sha1sum)といった、同等のデータを返す。詳細については、スライドを参照してほしい
    2. あるノードにとっての、外向き/内向きのエッジ(訳注:あるノードと関係を持つノード。典型的には、友人)を返すAPI。つまり、誰を関係のある者と見なしているか、また、誰から関係のある者と見なされているかを調べる。
    3. あるノードにとって、それと等価のノードが持つ全ての友人を調べ、それら友人にとっての等価なノード全てを展開し、その上で、目的とするノードのタイプによってフィルターをかけるAPI。これは、前述のAPIを、1→2→1という順番で一度に呼び出すよう、組み合わせたものである。たとえば、LJの"brad"と等価なノードが持つ全ての友人の中から、mbox_sha1sumかTwitterのアカウントを持つものだけを取り出す、といった使い方ができる。
    4. あるサイトにおいては友人関係にあるのに、別のサイトではまだ友人関係を築いていないノードを調べるAPI。あるノードが与えられたら、それと等価なノードを全て展開し、友人を調べ、さらにそれら友人を展開し、その上で、つながりの欠けている関係をレポートする。これは、各ソーシャルネットワークサイト間での関係を同期させるためのAPIである。たとえば、Friendsterにおいて友人同士である者が、MySpaceでもそうであるかどうかを知りたい場合に利用できる。
    より一般的に、未だ我々の考えもつかない新しいアプリケーションを可能とするべく、さらに多くの開発者向けAPIが必要となるだろう。
  3. エンドユーザのために
    1. ユーザは、初めて訪れたソーシャルアプリケーション(ここではdopplr.comを例に用いる)であっても、可能ならばOpenIDによって(必須ではない)、ログインできる必要がある。その際、ユーザに対して、以下のような文言を表示する必要がある。

      公開情報に問い合わせたところ、28名の友人がdopplrを利用しています。なぜあなたの友人がここに示されているのか、また、彼らの他サイトにおけるユーザ名については、以下に示す通りです。どの友人と、このサイトにおいても友人関係を気付くか選択してください。全ての友人をこのサイトにおいても友人にするには、「全てを選択」ボタンをクリックしてください。

      また、dopplrは継続的に、サイトを利用しているユーザに対して、他のサイトで友人関係にある者もサイトを利用し始めたかどうかを知らせ、また、dopplr.comにおいても友人関係を築くよう促す。彼らは、既に他のサイトで関係性をパブリックに明示しているのだから、再度の招待や、友人関係の結び直しは必要ない。中には、その場しのぎの、あまりきれいではないやり方であるとはいえ、このような機能をすでに提供しているサービスもある。たとえば、LiveJournalにおいては、ユーザ名を入力することで、LiveJornalを使っている友人をFOAFから抜き出したり、メールアドレスで示されるユーザ名とパスワードを入力することで、アドレス帳を取得することもできる。しかし、真っ当で、包括的な方法により、それらの機能を実現しているサービスは、まだ存在しない。
    2. ユーザ自身のポリシに従い、ソーシャルネットワークサイト(外部に開かれたAPIを提供するか否かに関わらず)における関係性を管理したり、それぞれのサイトを互いに同期させたり、その他、ユーザが望むことをなんでも可能にするためのツール(おそらくは、ブラウザのアドオン)を提供する。それらのツールは、非協力的なサイトに対してもっとも価値のあるものとなるだろうが、ともあれ、その場合なにが起っているのかをユーザに対して明確にし、決して惑わせるようなことがあってはならない。この件については、後述の通りである。
    3. グラフデータを、パソコン上のドキュメントと同様、ポータブルなものにする(エンドユーザに対しては、「グラフ」という言葉は使わないにしても)。

目指していないこと

  1. このプロジェクトは、Facebookに取って代わることを目指しているわけではない。実際、私が話した人々のたいていは、Facebookをとても気に入っている。ただ、すでにパブリックなものとなっているデータに、もう少し簡単にアクセスしたい、ある特定のプラットフォームによる囲い込みに対する懸念を和らげたいと考えてもいる。このプロジェクトへの参加についてもたれた、Facebookとの初期の話し合いにおいては、非常に期待の持てる回答を得ている。
  2. このプロジェクトは、新たなソーシャルネットワーキングサイトや、その他、なにかエンドユーザにとって面白いものを作ろうとしているわけではない。そうではなく、Dopplrやその他もろもろのサイトのような、たくさんのソーシャルアプリケーションが花開くべく、本質的な機能を構築しようとしているのだ。一つのことに取り組み、それを上手にやる。小さな、孤立したソーシャルグラフたちを、ひとつの巨大なグラフに統合し、それを広めることこそが、もっとも有効なのである。
  3. このプロジェクトは、Plaxoに取って代わろうとしているわけではない。
  4. このプロジェクトは、__________に取って代わろうとしているわけではない。

このプロジェクトの前提

  1. ソーシャルグラフは、パブリックなノード、プライベートなノード、パブリックなエッジ、プライベートなエッジからなる。いまのところは、パブリックなデータに焦点を合わせている。というのも、我々がネット上で自由に提供できるのは、それが全てであるからだ。公開データにフォーカスすることによっては、問題を100%解決することはできないものの、それでもまぁ、複雑な10%をのぞいた、90%の問題を解決することができるだろう。プライベートなデータについては、おそらくはより高いレイヤにおいて、後で考慮に入れることができる。ともあれいまは、パブリックなデータのみに注力する。
  2. さらに、まず第一に、写真のようなデータ(movemydata.orgを参照のこと)、誕生日、出身地、趣味等といったものではなく、友人関係に焦点を合わせる。グラフ中に現れるデータのうち、中身のないものや、友人関係に関わらないものについても、どうモデル化するかについて計画はあるのだが、後日の課題とする。それらの問題については、次のフェイズで取り組むことになる。
  3. 協力的なサイトもあれば、非協力的なサイトもある。私がこのプロジェクトについて話した小規模サイトは、ほとんど例外なく、協力を申し出てくれた。彼らは、自身の保有するソーシャルグラフが不完全であり、また、そのことについては彼らの専門外であることも認識している。彼らはただ、自分たちのサイトの機能を提供するためだけに、ソーシャルグラフを必要としているに過ぎない。データがどこから来たかを気にかけたり、彼らの比較的小規模なデータを、グローバルに共有されたグラフをよりよいものにするために使うことを嫌がったりはしない。一方、非協力的なサイトはすでに大規模であり、彼ら自身でグラフを保有することが重要であるとみなしているか、あるいは、十分に大きいためにこのような話題に対して興味を持とうとしないようなサイトである。注意してほしいのは、「非協力的」とは「積極的に敵視している」という意味ではないということだ。ただ、単にこのプロジェクトに対する支援を考慮することもないだけに過ぎないだろう。
  4. この世界が、誰かが発案した「ソーシャルネットワークの相互運用プロトコル」に一斉に乗り換えるなんてことはないだろう。XMLの時にそうであったように。それは、単に起らない。このプロジェクトは、データの収集、変更の通知等に関するあらゆる方法をサポートするべく、努めなければならない。新しいプロトコルや、XML/YAML/JSONといったフォーマットは、協力的なサイトにとって役立つだろう(すでに、少数のサイトにより、使われ始めてている)。しかし、全般的にいって、たいていのサイトは、最初は協同しようとはしないだろう。また、たとえばMySpaceのようなサイトがサポートするなんてことはあり得ないだろう。みなが同時に、というよりもむしろ、ひとつひとつのサイトがぽつぽつと対応していくことになるだろうと思う。であるから、このプロジェクトでは、再頒布される全てのデータにおいて、オープンで標準的な仕様や、マイクロフォーマット等を用いるだろう。
  5. たいていのユーザにとって、XML、プロトコル、標準仕様、データのフォーマット、集中化対分散化、データの置き場所、囲い込み等は、どうでもいいことだ。このドキュメントを読んでいるあなたは、普通のユーザではない。普通のユーザにも興味を持ってもらうために、我々は彼らに価値あるものをもたらさねばならない。他では得られないなんらかの機能、簡単さ、見た目の派手さ、実用性等といったものを。良質なデータがユーザを増やし、ユーザがまたさらに良質なデータを生む。どのようにしてこのサイクルを発生させるかについては、たくさんのアイディアがある。このことについてはいまは述べないが、しかし、幸運にもたくさんの良質なデータが、すぐれたAPIやオープンなデータフォーマットを通して、すでに広く得られるようになっている。
  6. ブラウザのアドオンやその他の、エンドユーザがダウンロードするようなものは、さしあたって必要ない。このプロジェクトは、第一にウェブ上で機能するものだからだ。いくつかの(非協力的な)サイトに対するある種の機能を提供する場合には、ブラウザのプラグインが必要となることもあろうが、たいていの場合は、必要ないだろう。
  7. 一部の非協力的なサイトにおいて、ユーザが友人関係の追加や削除を行ったり、データを取得するのを手助けするために、ブラウザのアドオンが使われることになるだろうが、彼らのブラウザ(すなわち、IPアドレスや、UserAgent文字列)を利用して、彼らのものでないデータを集めたり、公表したりしては、決してならない。たとえば、MySpaceのようなサイトにおいて、(ユーザがそのように設定しているのであれば)彼らの友人に関する情報を収集するのは問題ないが、彼らの友達の友達をスクレイピングするのはもっての他だ。なぜなら、それは彼ら自身のデータでなないからだ。それは、彼らの友人のもの、あるいは、MySpaceのものだ。いずれにせよ、アドオンをダウンロードしたユーザのものではない。
  8. ユーザが常にソーシャルネットワークの自動的な同期を求めているわけではないことについては、すでに認識している。人々はそれぞれのサイトをそれぞれ違った風に利用しているし、また、あるサイトでの「友人」は、別のサイトでの「友人」とは全く違った意味を持つこともある。目指すところは、サイトやユーザに未加工のデータを提供することであって、あとは彼ら自身のポリシに従い、それらのデータを用いたサービスを構築すればよい。

開発の進捗状況

2007年8月16日現在、上述したうちの大部分がすでに試作されつつある。

  1. 5つのソーシャルネットワークサイトのデータを得て、グラフにモデル化した。
  2. 上述したAPIの、実際に機能する実装も試作済みである(パフォーマンス、最適化、キャッシュ、並列処理においてまだまだ改善すべき余地があるが、まずは正しく動作することが優先される)。
    1. APIを用いて、LiveJournalとVoxにおける私のアカウントについて、つながりの欠けた友人を、他の別の場所における関係性を用いて見つけられるところまできている。
  3. MySpace上で機能するFirefoxのアドオンの開発に取りかかった。
  4. 特別な公開ノード、等価なノードについて、そして、通常捕捉され得ない関係性をユーザが公表するためのウェブサイト作成にとりかかった(そのサイトにおいては、ブラウザのアドオンのダウンロードページのみならず、ユーザがサイトを楽しめるように、興味深い統計情報やウィジェットを用意し、また、望みに応じて別々のサイトを同期させることができるようにする予定である)。
  5. ...

将来どうなるか

David Recordonは、概してこのプロジェクトのような事柄に取り組むために、Six Apartに入社することを発表した。Plaxoもまた、この点において興味深いサイトだ。そのうち、このプロジェクトによるデータを使って、Movable TypeWordPressを使っているブロガーがコメントスパムを判別するのに役立つ、信用や評判を扱うAPIのような、無料あるいは有料のサービスを提供する企業も現れるだろう(いったんOpenIDで認証されたコメントなら、APIに問い合わせることで、そのコメント主が信頼の置ける者かどうかを調べることができるというような)。
いずれにせよ、最近ではたくさんの人々がこの問題について取り組んでおり、様々なアプローチについて語り合っている。たくさんのグループが協働して取り組んだOpenIDの時のように、複数のグループがまとまってこの問題に取り組むことになりそうだ。

協力してくれる方へ

ソーシャルネットワーキングサイトを運営していて、ノード/エッジ(ユーザ/友人)のデータを持っている方、あるいは、APIのベータテスタとして協力したい方は、本プロジェクトのGoogleグループに参加して、連絡していただきたい。
エンドユーザ向けのウェブサイトやツールを試してみたい方は、ちょっと待ってほしい :) 後日、制限つきのベータテストについてアナウンスがあるだろう。

結論

このプロジェクトは非常にエキサイティングだ。あなた方にも、このプロジェクトをどのように利用できるかを考えてほしい。きっと、クールなものになるよ。

関連するかもしれないプロジェクト

  • http://adactio.com/journal/1328 - Jeremy Keithも、おそらくはわずかにことなるアプローチをとりつつも、この種のプロジェクトにすっかり夢中みたいだ。素晴しいことだ。このプロジェクトは、様々な観点から検討される必要があるのだから。
  • http://microformats.org/wiki/social-network-portability - これは、人々の考えをひとまとめにしたWikiだ。マイクロフォーマットにフォーカスした内容に見えるかも知れないが、そうではない。これは私の強い信念なのだが、ある特定のフォーマットやAPIの採用をしたってうまくいくわけがない。私は、単にギークのためのものを作りたいわけではなく、全てのユーザのためのもの、今日のポピュラーなサイトで機能するものを作りたいのだ。
  • http://movemydata.org/ - 写真をダウンロードし、他のサービスのそれと同期するためのデスクトップソフトウェア等を提供している。このプロジェクトに比べると、よりデスクトップやコンテンツにフォーカスしたサービスだ。
  • http://www.wired.com/software/webservices/news/2007/08/open_social_net - Wiredですら、ただ情報を貯めこむだけのサイトにうんざりしている。

コメントしたいことがあるなら

brad's life - Thoughts on the Social Graphによろしく。あるいは、Davidが作成した本プロジェクトのGoogleグループに参加してもらいたい