【インタビュー】
「OpenSocialアプリの提供は秒読み段階に来た」――Google幹部

参加ベンダー独自拡張の問題、Facebook参加の可能性などを直撃質問

（2008年02月26日）

米国GoogleがSNS（ソーシャル・ネットワーキング・サービス）向けアプリケーションのAPIの標準化を目指す「OpenSocial」プロジェクトを立ち上げてから約4カ月が経過した（関連記事）。同プロジェクトに参加するベンダーは多数に上るが、今なお懐疑的な見方をする向きも少なくない。今回は、Googleのエンジニアリング・ディレクター、デビッド・グレーザー（David Glazer）氏にインタビューを行い、参加ベンダー独自拡張の問題や、メインプレーヤーであるFacebookの不参加など、OpenSocialに関するさまざまな疑問をぶつけてみた。

Juan Carlos Perez
IDG News Service マイアミ支局

　OpenSocialプロジェクトのねらいは、異なるSNSサイトに対応する共通API（Application Programming Interface）を開発し、開発者の負担を軽減することにある。しかし、米国のSNS市場で今、最も注目を集めているFacebookが2007年5月に立ち上げ、成功させたSNSアプリケーション開発プログラムへの対抗措置にすぎないと見る者や、OpenSocialの技術アーキテクチャでは洗練度の高いアプリケーションの開発は不可能であると指摘する者も少なくなく、OpenSocialへの風当たりは強い。

OpenSocialのサンプル・アプリケーションは、すでにOpenSocialサイトで公開されている

　それでも、（現時点でFacebookのサポートこそないものの）、OpenSocialにはすでに、MySpace、LinkedIn、Beboといった有名なSNSをはじめ、Oracle、Salesforce.comのような大手アプリケーション・ベンダーも参加を表明している。

　先ごろ、IDG News Serviceは、Googleのエンジニアリング・ディレクター、デビッド・グレーザー（David Glazer）氏にインタビューを行い、参加ベンダー各社によるプロプライエタリな拡張機能がOpenSocialを細分化させてしまう危険性や、メインプレーヤーであるFacebookの不参加についてなど、OpenSocialに関するさまざまな疑問をぶつけてみた。
　

OpenSocial APIの現行バージョンは0.7

――OpenSocialのAPIは現在バージョン0.7で、本格的なアプリケーション開発が可能な製造段階に達しているとのことだが、どのぐらい自信を持っているのか。

Glazer氏：最初に発表した際（APIバージョン0.5）、当社は、これがたたき台で、皆さんのフィードバックを待っていると話した。その後、0.6、0.7とバージョンを上げ、アプリケーション開発者からは、「これですばらしいSNS向けアプリケーションを開発できる。今後さらに改善を求めるかもしれないが、現時点で十分に高品質のアプリケーションを構築できる」とのフィードバックを得ている。

――サーバ・サイドのREST（Representational State Transfer）コンポーネントの準備はまだのようだが。

Glazer氏：GoogleはOpenSocialの発表時に、クライアント・サイド・コードを含むアプリケーション開発に必要なAPIと、サイトやサーバから情報を収集するためのアプリケーションを開発するAPIの提供を約束した。そのあと、多くの関心と注目がクライアント・サイドに集まった。「サーバ・サイドのオプションは魅力的で、完成すれば利用したいが、高品質のアプリケーション開発に必ずしも必要な要素ではない」との声が強かったのだ。したがって、現在はアプリケーション開発者がまず必要不可欠な要素と主張する、クライアント・コンポーネントの準備に注力しているわけだと。

――OpenSocialでは、新開発のセキュリティ技術「Caja JavaScript」サニタイザなどの補完技術も提供していくとのことだが、Caja JavaScriptの進捗はどうなっているのか。

Glazer氏：開発者に“点検”してもらい、フィードバックをもらう段階まで進んでいる。Cajaについては、慎重にリリース時期を決めたい。これは保護技術であり、期待されるセキュリティを備えていることを確実にしたいからだ。

――「Shindig」とは何か。

Glazer氏：Shindigは、OpenSocial APIのオープンソース・リファレンス・インプリメンテーションで、完全なApache Software Foundationプロジェクトとして統制、運営、実装されている。つまり、所属企業の許可を得てコードを提出した個人は、貢献したすべての知的財産に関するライセンスを公開しなければならない。

　Shindigのミッションは、SNSサイトにおけるOpenSocialサポートの実装を簡易化することだ。開発チームがShindigを使って数カ月単位ではなく、数時間のうちにPoC（Proof of Concept：機能検証）を行えるようにする。この目標に向けてShindigは大きく前進している。スペックの大部分はプラグインしてただちに実行できる状態にあり、作業は今後も継続していく。

　ただし、OpenSocialの実装に、Shindigは必須というわけではない。OpenSocial APIはさまざまな手法で実装できるものであり、Shindigは容易な手段の1つにすぎない。
　

参加ベンダーの独自拡張をどこまで認めるのか

――Googleは、OpenSocialに参加する企業が独自に追加する拡張機能の自由をどの程度まで認めるのか。

Glazer氏：簡単に言うと、“意味のない細分化”は避けるべきだ。OpenSocial対応サイトでも、特有の機能をアピールする拡張機能を追加するのは必要である。それと同時に、複数の異なるサイトで同じように機能するアプリケーションを開発するなら、やはり同じ手法で開発すべきだろう。

　われわれOpenSocialのパートナー企業は、「標準機構が提供されている機能をサポートする場合はその標準機構を使う」という共通認識の下、緊密に協力し合っている。標準機構がない機能をサポートすることももちろんオーケーだ。ただ、その場合にも、OpenSocialでは共通の拡張機構を用意し、開発者がわかりやすい、テストしやすい形でユニークな機能を追加できるようにしている。

――OpenSocialのパートナー企業が、機能の拡張度合いが過ぎる場合、Googleは、何らかの形でそれを縮小させたり、契約を破棄したりする権限を行使できる手だては用意しているのか。OpenSocial認定の公式な手段として。

Glazer氏：それも考えたが、今のところ、当社とパートナー各社の姿勢が非常に一致しているため、はっきりした形での制約は特に設けていない。この問題が発生して対処がなされるとき、最初に傷つくのはアプリケーション開発者だと思う。彼らから助けを求める声が上がれば、Googleは彼らとともに対策を考えていくつもりだ。だが幸いなことにそうした事態には至っていない。
　

｜1｜2｜ > 次のページへ