今回はWeb APIの抱える問題点や今後のあるべき姿について書いておこうと思います。

私自身は2008年3月までWeb API、MashupのポータルサイトであるMashupediaを運営してきました。その辺りの事情から言うと、日本においてWeb APIのあり方はなんともし難い状態になっていると言えます。理由は幾つかあるのですが、

1. ビジネスモデルがない

2. 基になるWebサービスありきである

3. 基になるWebサービスが魅力的でない

に集約されると考えています。詳細は以下にて。

1.についてはWeb APIの公開がパブリッシング目的であったり時流に乗ったケースで見られます。そのため、初期のパブリッシングが達成されてしまうと、その価値が低減し、追加開発も行われなくなります。また、Web APIだけで売上を立てることができていないため、追加開発を行うことはコスト増にしかならず、手をかけることができなくなります。ビジネスモデルありきで成功しているケースとしては、Amazon Webサービスがあります。

2.はWebサービスのデータを公開する形のWeb APIです。この場合の特徴としては、データの公開インタフェースにWeb APIを利用するのみで、データのポスト（追加、更新）インタフェースは提供されないことが多いです。これではWebサービス側の機能に比べて貧弱で、面白みも少なくなります。データを公開する＝Web APIではありません。データを公開、操作できる点がWeb APIの面白さです。

3.のケースも多いのですが、元々の利用者が少ない中でのWeb API化は面白みがありません。基になるWebサービスが魅力的だからこそ、Web APIもまた魅力的になります。これはAmazon、GoogleなどWeb APIを戦略的に利用している企業のサービスを見れば明らかかと思います。

打開策としては、まずWeb APIだけでビジネスモデルを構築する。これは乗り換え案内や、地図、ストレージサービスなどオリジナルコンテンツや技術をもった企業のサービスであれば十分に考えられます。そして、はじめは無料で、次にトラフィックに応じた形で課金するビジネスモデルを模索するのが良いと思います。トラフィックが増えるということは、Mashup側で売上が発生している可能性があり（Google Adsenseであっても）、その中の一部を利用料として徴収する形です。後は基になるWebサービスを魅力的にする、ユーザ数を増やす…などの努力になります。

Web APIを活用するという流れはいまいち本格的になっていません。かつての状況に比べるとずいぶん熱が冷めてきた感があります。その中で無理矢理盛り上げるのは難しい所ではあります。ビジネスモデルの確立したWeb APIが幾つか登場してくれば、企業主導で業界が盛り上がっていくのではないでしょうか。

Googleの場合はどうだろうか。Googleツールバー必須のままであったら面白みはあまりなかっただろう。だがWeb APIという強力な武器があれば、使える場面は多いかも知れない。例えばオリジナルのコメントシステムは止めて、Google Sidewikiに保存するようにしてしまったり、そもそもコメントシステムのないサイトでもGoogle Side Wiki APIを使えばコメントシステムが実装できるようになる。

Google Side Wiki APIは言わずと知れたGDataに則って作られているので、既に存在するGData向けクライアントライブラリが利用できるはずだ。またそれに対応しているということは、データの参照はもとより追加や削除といった操作もできるはずだ（今は参照のみで、投稿はできない）。

仕組みとしてはURLや投稿者をキーとして、そこに紐づいたデータを取得すると言う形式だ。データの取得だけであればフィードで出力されているので取り込むのはさほど難しくはない。投稿するインタフェースはないが、AuthSubなどの認証には対応している。

なお、現在はラボ用のサービスなので、将来的になくなる可能性もあるのでその点は注意が必要だ。前述の通り、同種のサービスは既に多数存在しているし、それらの状況はGoogleが知らないはずはない。そのような中リリースするということは、Web APIをはじめとした独自の施策があるはずだ。

Google Sidewiki API – Google Code
　http://code.google.com/intl/ja/apis/sidewiki/

はじめてのAmazon EC2&S3｜gihyo.jp … 技術評論社
　http://gihyo.jp/dev/serial/01/amazon_ec2/0001

はてなブックマークの方に、気になっている価格が分かりづらいと書かれていました。確かに料金体系が細かく、転送量によって金額が変わってくると不透明さが出てしまいます。

via IMG_0909 on Flickr – Photo Sharing!

そこで、MOONGIFT+αの運営実績から、だいたいの目安を出してみました。

まず絶対にかかるのがインスタンスの時間です。これは一番下のインスタンスで$0.1/時間かかります。なので一ヶ月で約$72かかります。

次に入ってきたデータに対する料金です。これは$0.1/GBです。MOONGIFTはアップロード系ではないので、これは9GB/月くらいのようです。$1.00かからないくらいです。アップロードが多いサイトはこの点は注意が必要です。

次がデータの出力系です。MOONGIFTの場合、約150GBくらいのようです。$0.18/GBらしいので、$19くらいの予定です。なお、MOONGIFTではサイトの画像を別サイト（こちらは転送量で課金されない場所）に置いているので、殆どテキストのみです。画像等は重たい場合があるので、Amazon EC2には置かない方が良いかもしれません。

最後に静的IPアドレスを割り当てていないサーバを運営している場合に$0.01/時間のコストがかかります。一ヶ月で$7.2になります。

これらを累計すると、$100/月くらいの運営コストになります。また、インスタンスを設定後やログ等をAmazon S3に保存することになると思いますが、これはバックアップ目的の場合は転送を殆ど考えなくてよく、データ量の$0.15/GBを気にするくらいです。ちなみにMOONGIFTでは$0.15/月くらいのコストです。

ご参考になれば。

Googleのホーム

もはやGoogleと読むこともできないロゴ…。本日は最初のレーザーができた記念日だそうです。

first laser – Google Search
　http://www.google.com/search?q=first+laser

Google
　http://www.google.com/webhp?rls=ig

Clickyのトップページ

その点Clickyは違う。アクセス解析結果で得られるほぼ全てのデータをWeb APIで取得することができる。Clickyに関する紹介は 4つの便利機能がお勧めのアクセス解析2.0「Clicky」[ Resident of Net ]を参考にして欲しい。

Clicky APIはアクセス解析アプリケーションという特性もあり、GETを使った取得のみのWeb APIとなっている。データはXML/PHP/JSON/CSV形式で取得できるようになっている。

Clickyのダッシュボード

サーチキーワード/サーチエンジン/流入元/流出先/ページURL/ダウンロード回数/国/都市/言語/ブラウザ/OS/解像度/ホスト名/FeedBurnerの表示数とクリック数などなど。他にも様々なデータが取得できる。

これだけのデータが取得できれば、コンテンツの下に載せたり、別なシステムと連携させたりといったことが容易にできるだろう。さらに基本情報についてはRSSフィードでも配信しているので、それを使っても情報取得が可能だ。

Clicky APIのドキュメント

データを全て解放してしまうのは競争力の減衰のように感じられるだろうか。否、これにより魅力をまし、ユーザビリティの高いフロントエンドがユーザから提供されると行った相乗効果が見込めるようになるのだ。

Help with Clicky | Clicky
　http://getclicky.com/help/api

Lighthouseの一画面

そしてLighthouse APIを使えば、Lighthouse内にあるほぼ全てのデータ取得できるようになります。

プロジェクト、チケット、変更一覧、メッセージ、マイルストーン、チケットビン（？）、ユーザといったデータが取得、追加、更新、削除できます。Lighthouse APIを使えば、Lighthouseクローンだってできそうな位充実しています。データの授受には独自のXML形式が利用されます。

Lighthouse APIの説明ページ

チケットのデータをTwitterから登録できるようにしたり、プロジェクトの状態を社内のシステムに反映したりといった相互連携が考えられます。その一つとして、Subversionのコミットログを転送する方法というのがLighthouseのヘルプの中で紹介されています。これも専用で開発すると大変ですが、Web APIを使うことで手軽で柔軟に構築することができるようになります。

Lighthouseは画面も見やすく、普通に使う分には申し分ありません。その中でさらに他のシステムと連携したい、カレンダー情報を抜き出したいと言ったようなニーズの中で利用するのは面白そうです。

Resident of Net » Blog Archive » 使いやすいプロジェクト管理「Lighthouseapp」
　http://residentof.net/2008/04/lighthouseapp/

Introduction to the Lighthouse API | Lighthouse
　http://lighthouseapp.com/api

Feng-GUIのトップページ

そうした時にユーザの視点がどこに注目しているのか分かれば、デザイン面でもそうした結果を反映したものにしていくことでよりトラフィックを誘導することが可能になります。

詳細は以下。

機械的なシミュレーションなので、精度は人並みではありません。が、目立つ場所がどこなのか、指摘してくれるのでその結果を踏まえつつシステムに反映していくのは良さそうです。

拡大した画像。バナー部分が目立っているようだ。

利用は簡単で、スクリーンショットを撮って、それをアップロードするだけです。終われば解析された線と一緒にスクリーンショットが表示されます。意図していた部分よりも目立つ場所があったとしたら、そこは改善してよりユーザを誘導できるような流れにしていく必要があります。

実際のユーザにやってもらおうとなると、相当な金額がかかるのですが、Feng-GUIを使えば無料でできるのが良いですね。

via プレゼンにも最適、ページ内のユーザーの視線をシミュレートする -Feng GUI heatmap [ コリス ]

Feng-GUI – Feng Shui for Graphic User Interfaces
　http://www.feng-gui.com/default.aspx

オフラインで編集中

オフラインモードにすると、新規の作成はできなくなります。また、画像の挿入も不可となります。また、ダウンロード機能も使えないようです。他、検索機能が使えないと言った、そうなるだろうなと思われる機能は利用できないようですが、文書の編集に関しては問題なさそうです。予め挿入してある画像は問題なく表示されます。

最初の同期処理中

完了しました。これでオフラインになっても大丈夫です。

ただ残念なのはスプレッドシートとプレゼンテーションです。スプレッドシートは、表示のみのモードになるようです。こちらは編集不可です。また、プレゼンテーションは対応していません。現状ではGoogleドキュメント専用の機能となっているようです。

オフラインで編集した文書。なお、スプレッドシートやプレゼンテーションは未対応

Webアプリケーションの弱点としてよく挙げられるオフラインでの利用ができるようになれば、Googleドキュメントの利用者ももっと増えそうですね。

Google Docs
　http://docs.google.com/

via Liveblogging Google Q1 Earnings Report—Fears Were Overblown

利益は2007年の第四四半期から7%アップの52億ドル、純収益は13億1000万ドルで8%アップだそうです。

頭脳が流出し、さらにクリック数が低下しているのにも関わらず収益が上がっていくというのは…単なる技術集団ではないということですね。株価は若干下がった様子なので、それでもなお期待したほどではなかったということでしょうか。

Google Finance

GoogleのWeb APIやオープンソースホスティングサービスなどを提供するGoogle Codeが各国言語にローカライズされました（日本語、中国語、ポルトガル語、ロシア語、スペイン語）。まだコンテンツ全てが対応した訳ではなく、表面的な一部のみではありますが。これで随分受け入れられやすくなったのではないでしょうか。

Google Codeのトップページ。日本語ローカライズされています。

Web APIの概要ページ。ここも日本語化されています。ここ以下は日本語でない場合が多いです。

Google Chart API やGoogle Maps APIは日本語化されているようです。

開発者ホーム – Google Code
　http://code.google.com/intl/ja/