OpenSocialを説明することで見えてきた課題

今日は、 x.tokyoというコミュニティで「OpenSocialとは?」という話をしてきた。今まで「SNSアプリケーションって、いいですね!」という人々としか話をしてこなかった気がするのだが、今回はそうではない話がいろいろと出てきて、かなり僕的にも新鮮だった。 まず大きな話として「Activityってどうよ?」という点。例としてTwitterがあげられていたんだけど、今のTwitterは、followしている人の発言を全て無条件で見させられることになる。これについて、多くの人が「うざい」と感じていると推測できる。仮に、Followerのうちで一人でも極端にアクティブな人がいた場合、つぶやき一覧を見たときにその人の発言で埋まってしまうわけで、それについて「大好きな異性」とかでもない限り、人は違和感を覚えるだろう。それと同様に、あるSNSアプリケーションからのActivityが次々とプロフィール画面を埋め尽くしていくことを想像してみると・・・確かに「Activityってどうよ?」と思ってしまうのはごもっともだ。 この問題は「アプリケーションは、いつでもスパムエンジンになり得る」ということを示している。そこに悪意がある場合は論外だけど、アプリケーション開発者が「細かくアプリケーションの利用状況を友達に知らせてあげた方が楽しいのではないか」という考えを善意で持つことは十分に考えられる。しかし、その意識が多くの利用者の認識と離れていた場合は、アプリケーションは結局スパム認定されることになってしまう。 このような状況を未然に防ぐためには、例えば以下のような工夫が必要となる。

  • あるアプリケーションが単位時間内(例えば1日間)にActivityを作成できる数を制限する。

  • ユーザが、あるアプリケーションのActivity作成を許可しないように設定できるようにする。

  • ユーザが、あるアプリケーションのActivity Streamに対して、何らかのフィルタをかけられるようにする。 最初の2つは、すでにOpenSocial対応SNSが行っている施策だ。しかし、3つ目のフィルタについては、今回初めて出てきた意見だと思う(僕が知っている範囲でだけど)。もちろんフィルタをかけるということは、本来知るべき情報を落としてしまうかも知れないというリスクが発生するのだが、それを承知でユーザ自らが情報を選択できるようにする仕掛けを準備してあげることは、特に日本では重要なのかも知れない、と思い始めた。 すでにOpenSocial対応しているSNSの中でも、Activityについてすでにサポートを完了しているSNSは、残念ながらまだない。例えばFacebookを見てみると、全てのActivityが表示されるわけではなく、何らかのアルゴリズムで表示されるActivityが絞られている、という点を除いたとしても、基本的にはアプリケーションが作り出すActivityは次々と流れ続ける。その印象があって、僕は勝手に「海外では情報のストリームは全て流れるのが当たり前で、情報の取捨選択は閲覧者が自ら行うこと」という認識を持っていた。しかし、実は日本ではそれは文化として浸透していることはなく、何らかの仕掛けで情報の絞り込みがされることを優先するのかな、と。 フィルタ機能をSNSに期待するか、自らのスルー力を強化するか、判断が分かれるところかも知れない。もちろん、フィルタ機能を駆使しつつスルー力を身に付けることが理想なんだけど、それは誰でもできる技ではないので。。。 次に、会員情報という個人情報をどう守るか、という話。これも海外と日本では温度差があって、多くの海外のSNSを見ると「公開したくない情報はそもそもSNSに入力しない」という思想が見え隠れしているのではないか、と推測できる。そこには、友達情報も含まれているし、何よりも「○○と友達であることを公表することによる一種のステータスの確立」ということが優先されるという風にも見える。しかし、mixiを代表とする日本のSNSでは、個人情報に対して閉鎖的な考えが優先される。プライバシーの優先、と言えると思うけど、会員情報はもちろん、SNSをいつ使ったのか、といったログ情報に関しても、公開されては困る!という状況らしい。 海外の文化が適用されたSNSをベースにOpenSocialは策定されているため、一見すると日本には到底適用することができない会員情報のオープン化が求められるように感じてしまう。しかし、v0.8からはOAuthによる情報開示の範囲限定がちゃんと考えられているため、日本的な閉鎖感をシステムに持ち込むことは十分に可能だ。JavaScript APIはもちろん、RESTful APIで適用されるOAuth Consumer Requestについても、xoauth_requestor_idヘッダによるユーザ特定がOpenSocialコンテナ側で必須とすれば、情報のアクセスに関する認可について対応可能だと言えるだろう。 そして「OpenSocialに対応することはSNS運用側にとって嬉しいことはあるのか?」という話も出てきた。これについては、

  • 提供されるサービスがプラットフォーム化されることにより、利用者は独自に機能を追加拡張できるようになる。

  • 特に地域SNSに対して、(外部データベースをコンテンツのマスタにするなどして)複数の地域SNS間の連携をOpenSocialアプリケーションによって実現することができるようになる。 という回答を僕から提供した。結局のところ、サービスをそのまま受け入れられるユーザなどいないわけで、カスタマイズを開発元に依頼したり、自分で変更したいがためにOSSを選択したり、といった状況が多くの企業で見受けられる。しかし、管理されているデータベースを使って独自の機能を決まったAPIで実装し追加できる、という魅力は、多くのユーザの心を掴むのではないだろうか。すでにSalesforce.comが実証している領域だし、それが「Learn once, Write anywhere.」になるのであれば、それはSNS運営者としてもメリットとして受け入れていいのではないか、と思う。 OpenSocialは、あくまでAPIの規定に過ぎない。その先にある「個々のSNSでOpenSocial(アプリケーション)をどう考えていくか」という命題は、とても重要で、OpenSocialにとって非常に原点である。単に「SNSでゲームができて、ハイスコアを友達同士で競えます!」というレベルを超えて、OpenSocialが描くであろう大きな世界をもっともっと語れるようにならなくては、と思った今日は、僕にとって非常に有意義な日となった。

このエントリーをはてなブックマークに追加

関連記事

2023年のRemap

Remapにファームウェアビルド機能を追加しました

Google I/O 2023でのウェブ関連のトピック

2022年を振り返って

現在のRemapと今後のRemapについて