Google+のちょっとだけポロリしたPages APIと、そこから考えたこと

Google+のAPI、特に投稿系のAPIは非常に限定されています。僕らが自由に使える投稿系APIは、History APIくらいです。これはうまくできていて、何かMomentをPOSTしたからといって、それがすぐに他の人に閲覧されるわけではなく、自分の履歴としてストックされるだけです。ストックされたMomentを他のユーザに見せたければ、改めてGoogle+上でShareする必要があります。

まぁ、History機能自体まだβ扱いなので、今後どうなるかはわかりません。

フィードストリームの取得や検索については、かなり充実してきています。ちょっと前までは単にREST APIだったのですが、今日見たら、

” Public data API”

というように名前が付いていました。People、Activities、そしてCommentsというリソースを検索、取得することができます。そう、この名の通り、一般公開設定されたリソース、つまり「誰でも見れる情報」のみがこのAPIの対象となっています。つまり、OAuthの認証認可すら必要がない(実際はするんですけど)ことになります。

APIのみで見たら「取得だけじゃんかー、これじゃあなぁ」と思ってしまうかもしれません。もちろんそんなことはなくて、+1ボタンに代表されるPlugin系も同時に提供されています。これによって、ユーザは何らか興味を持った対象をGoogle+に投稿することができるわけです。ここから読み取れることは、とてもシンプルです。

「Google+への情報投下はユーザのアクションなしではやらせない」

これは実はとっても重要で、この制限があるためにGoogle+のフィードは荒れずに済んでいます。実名とかそういう予防策なんてちっぽけに思えるくらい、この「ユーザアクション必須」は大きく機能しています。いわゆるスパムフィードが入り込む余地はこれでほとんどなくなっているわけですね。Facebookを使っているときの感覚と、Google+を使っているときの感覚の違いは、実はこれが大きく作用しているのではないかと思っています。機械的な、何か無機質な内容って、Google+ではほとんど見ることはないですよね?

Facebookは最初からプラットフォームを目指し、情報の流れが必ずFacebook経由になるようにしたかった。そのためには様々なアプリがFacebookと連携されるようになってくれないといけなかったし、ユーザにとっても「新しいOS」並みに見えるようにしたかったんじゃないか、と。もちろん、それが成功して現在のFacebookがあるわけです。ただ、最近では多くのアプリからのスパム投稿に対してFacebookが対応策を打ち続けている日々となっています。これは絶妙なバランスをとり続けなければならない、本当にトレードオフの世界なので、ずっと続くと思ってます。

ではGoogle+はどうだったか?Google+が登場する前、Google Buzzというのがあったのを覚えていますか?懐かしいですね。このGoogle Buzzは、フィードの流れを重視したサービスでした。キーテクノロジとして、ActivityStreams、PubSubHubbub、Salmon Protocol、そしてWebFingerといった仕様が採用される予定でした。これらは「フィードの表現形式の標準化」「フィードの流れの標準化」「フィードの交換の標準化」そして「フィード投稿主の特定の標準化」と言い換えることができます。そう、Googleも最初はソーシャルメディア上を流れる情報の中継点になりたかったのではないかと考えれます。当時のGoogleがHubにフィードを投げこむように多くのサービスに連携を勧めていたことからも、この思想にいたことは正しいでしょう。

しかし、Google+は違いました。Google Buzzが狙っていたのとは全く違う方向のサービスになってます。あくまで情報を投稿するのはユーザであり、Shareという行為をとても大事に考えています。TwitterやFacebookの情報すら流し込むことを拒んでいます。おそらくGoogle Buzzの路線をそのまま行っていれば、Facebookの後追いをしていたでしょう。技術的にはとても魅力的であったとしても、ユーザからしたら、わけがわからない状況になっていたかもしれません。いろんなものが流れ込んできて、自分でも面白がって流し込んで、サードパーティもここぞとばかりにいろいろなものを流し込んで、結果カオスになってユーザは離れていく、そういった結末になっていた、かもしれません。

起点がユーザの行為であることは、どんな内容であれ、そのユーザの気持ちがそこに含まれています。ソーシャルメディアの強みは情報の発信者が誰かという点とその人がどんな想いで投稿したか、この2点に尽きます。「まずはこれらのみに徹底しよう、話はそれからだ」という会話がされたかどうかは外部の人間には知ることはできませんが、やっぱりGoogle+はGoogleにとって異質に見えるプロダクトであり、開発者じゃなくユーザに向けたプロダクトだな、と思うわけです。プラットフォームドリブンではなく、あくまでサービスだということです。

いち開発者からすると、ちょっとGoogleらしくなくて残念なんですけどね。でも理解はできます。

そんな特別かつすごーくゆっくり暖めて育ててると思われるGoogle+ですが、本日こんなニュースが流れてきました。

[日本企業 5 社を含む 6 社が Google+ ページ のサードパーティ管理 ツールパートナーとして加わりました]

http://adwords-ja.blogspot.jp/2012/11/5-6-google.html

Facebook Pagesやmixiページといったソーシャルメディア上にページを作れるサービスをGoogle+も提供しています。Google+ Pagesという名前だったと思うんですけど、例えば企業がこういったページを設置して運営していくという作業は、かなり難しい部類のものになります。フォロワーを集めなければならない、情報を常に投下し続けなければならない、ユーザからのフィードバックを常に把握し続けなければならない、そもそもどんなユーザが来ていて、ユーザがどんなことに興味を持ったかを知らなければならない、こういったこと全てが高いレベルで求められるのです。もちろん、各企業が独自にページ上でやりたいことが出てきて、つまりカスタマイズしたくなってきた際に、そういったことにも答えていかなければなりません。

そもそも、そのページを荒れさせてはならない。一度荒れてしまったら、元の姿を取り戻す苦労は計り知れません。

この運営は機械的には無理なため、ソーシャルメディア側では限界があります。各企業がそれぞれのポリシーを持って取り組むべきことです。そのためには、ページ内の情報についてその企業は全てアクセスできなければなりません。もちろん情報の投稿も、削除も、できてしかるべきです。

あれ、さっきの話と違いますね。さっきは「ユーザのみができるべき」だったのに、今度は「企業は全ての操作ができるべき」です。真逆ですね。ここでソーシャルメディアが取る戦略はただ一つ、「信頼できる相手にのみ全ての操作を許可する」ということです。自分たちだけでは難しいので、いくつかのパートナーと手を組んで、ページを設置してくれる各企業のサポートをしてもらう、ということになります。そのために特別なAPIが必要になるのですが、これは一般公開せずにパートナーにのみ提供します。こういうことはどのプラットフォームもやっていることだったりします。

Google+の場合は、Pages APIと呼ばれるREST APIが提供されているようです。Google+ Platformのページにその名だけは書かれているのですが、それにアクセスすると、フォームが出てきてしまいます。

[Google+ Pages API Interest Form]

https://developers.google.com/+/api/pages-signup

「パートナーになることに興味があれば、フォームから申し込んでね」的なことです。ここに書かれている「Pages APIでできること」は以下になります。

  • circle management (create/delete circles, add/remove users from circles)

  • publishing (post text/video/images publicly and to circles)

サークルの操作をがっつりできるっぽいですね。コンテンツの投稿と書かれていますが、ユーザのフィードバックに関してもおそらく操作できるのではないかと推測します(勝手な個人的想像)。APIリファレンスくらい知りたい!と思いますが、残念ながらパートナーにならない限り無理でしょう。

他のGoogleのプロダクトと違ってGoogle+ Platformについて「全然提供してくれないじゃん!」とお思いの方がいらっしゃるのであれば、上記のような背景があってのことなんだと想像していただければ、きっと心も落ち着くことでしょう。FacebookとGoogle+の立ち位置の違いを把握した上で、どちらの戦略がどうサービスを成長させていくかを見ていくと、より面白いと思います。

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

関連記事

2023年のRemap

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

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

2022年を振り返って

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