タグ: api

UberがAPIを公開―TripAdvisor、UAなど外部アプリ内からUberが呼べるようになった

先週、われわれのJosh Constineは「Uberはサードパーティーのアプリ内からUberの車を呼べるようにAPIを公開する準備をしている」という記事を書いた。今日（米国時間8/20）、Uberは11社のサードパーティーのパートナーに対してAPIを提供したことを発表した。

APIの公開はUberにとって多くの新しい潜在顧客の目に触れるチャンスを増やすことが期待できる。同社は現在50カ国の150都市でサービスを展開中だが、サービス地域でまだUberの存在を知らない人々の数は膨大だろう。多くの人々がすでにインストールしている人気アプリ内に「Uberを呼ぶ」ボタンが表示されればプロモーション効果は絶大だ。

5月にはGoogleマップ・アプリにUberが統合され、マップからUberが呼べるようになっている。しかし今回のAPIの公開は多数のサードパーティー・アプリを対象にしている点ではるかに野心的なビジョンだ。

最終的にはUberはクリエーティブな方法でUberのサービスをエンベッドしたいと望むデベロッパー全てにAPIを提供していく計画だ。ユーザーは開いているアプリを離れることなく、Uberに行き先を告げ、Uberはそれに対して料金概算と待ち時間を返す。一部のパートナーの場合、ユーザーはUberアプリを開く必要がない。

今回のAPIのローンチでパートナーとなったのは、Expensify、Hinge、Hyatt Hotels & Resorts、Momento、OpenTable、Starbucks、Tempo、Time Out、TripAdvisor、TripCase、United Airlinesの各社だ。

私の電話インタビューに対して「これはすごいことだ」とUberのビジネス担当上級副社長のEmil Michaelは繰り返した。

Michaelによれば、Uber APIを利用した新しいアプリは合計2億回程度ダウンロードされたはずという。またUberはサードパーティーのアプリからUberに新たなサインアップしたユーザーに対して30ドル分のクーポンをプレゼントしている。

パートナーによってユースケースはさまざまだ。OpenTableアプリでレストランを予約したユーザーは店までの送り迎えにUberを使うだろう。UAで飛ぶ旅行者は空港からホテルまでのUberを予約するだろう。あるいはHyattホテルを予約するとき同時にUberも予約するかもしれない。スマートカレンダーのTempoの場合、会議の時間に合わせてUberを手配しておけば遅刻せずにすむ。

170億ドルの評価額で12億ドルの資金を調達したUberはできるかぎり急速にユーザーを増やそうとしている。そのためには人々がすでに使っているアプリにUber呼び出しボタンをエンベッドさせるのがもっとも効率的だ。Uberはできるかぎり多くのアプリをパートナーとするために努力を惜しまないだろう。

[原文へ]

（翻訳：滑川海彦@Facebook Google+）


Android Wear SDKにウォッチの盤面を自由にデザインできるAPIが登場…それまでは盤面アプリを作るなとGoogleが懇願

GoogleのスマートウォッチプラットホームAndroid Wearは、すでに消費者製品もデベロッパのためのSDKもあるが、盤面のカスタム化がまだ公式にはサポートされていなかった。でも、デベロッパが相当苦労すれば独自の盤面は作れる、という状態だった。そして今日は、9to5Googleの記事によると、Googleのデベロッパヘルパー部門(Developer Advocate)のWayne PiekarskiがGoogle+で、ウォッチの盤面を容易に作るための盤面API(watchface API)がもうすぐ、WearのSDKに加わる、と発表した。

Googleのウェアラブルのプラットホームの中では、Android Wearはぼくの[好き]の一つで、中でもStar Trek LCARSにヒントを得たような思い切ったデザインの盤面がすでに作られていることが、おもしろい。レトロな、文字盤だけのデザインもある。

矩形、円、サイズいろいろ、そして電池寿命に貢献してカードによる通知を正しく行う…Piekarskiによれば、Android Wearがその境地にまで達するためには、Android Lへの移行が必要だそうだ。それは今年の終わりごろだから、盤面APIもそれまで待つのだ。

待つことを、Google自身もお願いしている。Google+の記事の中でPiekarskiは、独自の盤面アプリをGoogle Playストアに出さないでくれ、と懇願しているのだ。盤面APIの公式ローンチまでは、アルファやベータにお付き合い願いたい、と。でもこれまですでに、おもしろいのがいろいろ登場しているのだから、デベロッパたちがおとなしくGoogleの言うことを聞くとは思えないね。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


エンタープライズ向けマップサービス、Google Maps for Businessが航空写真を販売開始

Google Maps for Businessは大企業や政府、自治体向けにカスタム地図を提供するサービスだ。今日（米国時間7/16）、Googleは、「「このサービスのユーザーはGoogleから直接に航空写真を購入して公共事業のカスタム地図制作、事業の環境への影響の調査、不動産の査定などの用途に用いることができるようになった」と発表した。

Googleの航空写真に関しては、これまでもMaps for BusinessのユーザーはMaps APIを通じて利用できたが、単に表示ができるだけで、写真の画像そのものを編集することはできなかった。「大きな組織のユーザーから航空写真そのものにアクセスしたいというような要望が強かった」とGoogleの広報担当者は私に語った。

ユーザーはGoogle Maps Engineを通じて、必要な画像にアクセスできる。念のため断っておくと、この新しいプログラムが取り扱うのは航空写真のみで、衛星写真は含まれない。.

現在Google Maps for Businessで公開されているのはアメリカの大陸部分だけだ。Googleによれば「われわれのサービスのユーザーは連邦政府機関のように、航空写真を自由に利用できるようになった。高い費用をかけて自前で航空写真を撮影する必要はもはやない」という。 またMaps for Businessのインタフェースを利用して写真を入手できる。従来の航空写真の購入方法ようにいちいちファイルをDVDに焼いたりFTPでファイルを転送したりする煩わしがない。

購入ユーザーはウェブアプリのGoogle Maps JavaScript APIなどを利用して自社のデスクトップ地図システムにインポートすることができる。あるいは必要に応じてGoogle Earthにオーバーレイして表示することもできる。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


DropboxのOBらが次世代メールのプラットフォーム、Inboxを発表―Gmail APIに似ているが汎用

MIT出身で元Dropboxのエンジニアらのスタートアップ、Inboxはこれまでステルスモードで開発を続けてきたが、今朝（米国時間7/7）、次世代のメール・プラットフォームともなるべきInboxを公開した。最近発表されたGmail APIに似て、Inboxはユーザーのメールの受信トレイにアクセスする最新のテクノロジーを提供する。Gmail APIの対象がGmailに限られるのに対して、InboxはGmail、Yahoo、Microsoft Exchangeなど主要なメールサービスをサポートしているという。

またInboxはウェブサイトで「Inboxはeメール専門企業です。Googleは広告企業です。われわれはInboxにすべての力を集中しており、ある日突然サービスを廃止するようなことはありません」とGoogleに皮肉を効かせている。

Google I/Oデベロッパー・カンファレンスで発表されたGmail APIはユーザーのGoolgleアカウントのすべてアクセスする権限を必要とせず、Gmail受信トレイのメッセージ、スレッド、ラベルなど必要な部分にアクセスすることを可能にし、デベロッパーがメール・アプリケーションを開発することを助ける新しいツールだ。この狙いは、IMAPのようなメールクライアントを動作させるための古いテクノロジーに頼らず、ユーザーに対して一定時間後にメールを再表示したり、ユーザーに代わってメールを送信したりするなどの限定的な機能を提供することだ。

Inboxの目的もこれに似ており、「古臭いプロトコルやフォーマットをアップグレードしてデベロッパーがメールを・アプリを開発する手助けをする」と主張している。Inboxの機能は非常に広範囲で、シンプルなメールアプリの開発に役立つのはもちろん、フル機能のメール・クライアントの開発も可能だという。

このスタートアップはMIT出身でDropboxのエンジニア、NestのデザイナーだったMichael Grinich、Ksplice （Oracleが買収）でLinuxのカーネルを開発していたChristine Spangが創業した。Inboxの開発チームの中心にはさらに数人のMIT卒業生が加わっている。またMIT CSAIL（MITコンピュータ科学およびAIラボ）の並列分散OSグループの出身者も含まれている。

GrinichはInboxを開発の狙いについて、「私はMITでメールのツールについて論文を書いたときにメール・アプリの開発がいかに難しいか気づいた。その根本的な原因は、IMAP、MIME、文字のエンコードといったインフラにあった。Inboxはそうした問題をデベロッパーに代わって解決する」と説明している。

しかしInboxの最終的な目標は単にデベロッパー向けのツールの開発にとどまらず、次世代のメールの標準を作り出すことにある。 Grinichによれば「Inboxはメール・サービスのインフラをオープンソースのパッケージで提供する」という。

「われわれのメール同期エンジンはGitHubから無料で入手できる。質問や機能の提案なども歓迎する。この同期エンジンは現在GmailとYahooメールをサポートしているが、将来はすべてのIMAPメールに拡張される。Microsoft Exchangeのエンタープライズ・ユーザーはInbox Developer Programにアクセスを求めて欲しい。こちらはActive Syncをサポートしておりプライベート・ベータテスト中だ」とGrinichは語った。

すでにInbox SDK（JavaScript版とiOS版）を利用したデモ・アプリがいくつかGitHubで公開されている。 現在デベロッパーはInboxエンジン、アカウント同期をダウンロードし、そのプラットフォームを利用してローカル環境で開発を開始することができる。将来はInboxがホスティングするサービスを提供していく計画だという。

サンフランシスコに本拠を置くInboxへの投資家は、Fuel Capital、SV Angel、CrunchFund（情報開示：TechCrunchのファウンダー、Micheal Arringtonがファウンダー）、Data Collective、Betaworksその他だ。出資額などの詳細は明らかにされていない。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


Google I/O：Androidスマートウォッチお披露目―参加者にもれなく2個プレゼント！

Googleファンの諸君、うらやめ！

今朝（米国時間6/25）開幕したGoogle I/Oデベロッパーカンファレンスの参加者はもれなく真新しいAndroid Wearベースのスマートウォッチをプレゼントしてもらえることになった。 参加者は今朝発表されたAndroid Wearウォッチのうち、Samsung Gear LiveかLG G3 Android Wearのいずれかを選ぶことができる。さらにMotorolaのMoto 360ウォッチもリリースされ次第プレゼントされる。

そう、スマートウォッチが2個もらえるのだ。ChromebookのプレゼントはなかったのでGoogleが気の毒に思ったのかもしれない。Googleは参加者が会場を出るときに段ボール（本物の段ボール、つまり貧乏人のバーチャルリアリティーだ）の記念品を配った。

さて、参加者がLGとSamsungのどちらを選ぶか見ものだ。

3月に公開されたウェアラブルデバイスのプラットフォーム、Android Wearのさまざまな機能が今朝のキーノートで紹介された。Google Nowスマートアシスタントを利用したカード式のUIもデモされた。

またAndroid Wear SDKが公開され、デベロッパーはインターフェイスやセンサー・コントロールのカスタマイズができるようになった。このSDKでは音声コマンド、スマートウォッチ間、タブレットスマートフォンとの通信も処理できる。

本日発売開始の新しいスマートウォッチにはスワイプでメッセージを非表示に、コンテキスト情報を表示する、などいくつかの新機能サポートされている。

〔日本版〕トップの画像の円形のモデルがMoto 360。2番めの画像の角型モデルの左がLG、右がSamsung。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


Amazon、 独自スマートフォンFireを発表―3Dヘッドトラッキング機能を備えて199ドルから

今朝（米国時間6/18）、Amazonの最初のスマートフォン、Fireが登場した。ジェフ・ベゾスはプレスイベントで「これはAmazonプライムの会員向けのスマートフォンだ」と述べた。

FireはAT&Tの独占販売で2年間の契約で199ドルから。今日から予約を受け付ける。またFireには無料で1年間のAmazonプライム会員となれる特典が付く。現在、プライム会費は年間99ドルなのでこれは相当に魅力的な価格だ。

一見したところではFireは現在市場に出まわっている無数のスマートフォンと変わりはないように見える。しかし、Fireにはユーザーの顔の位置を認識する秘密の機能がある。Fireの表側の四隅にはそれぞれ赤外線カメラが埋め込まれており、ユーザーの顔位置に応じて前代未聞の3D効果を生み出す。ただし3Dといっても画像が飛び出して見えるという普通の意味の立体視ではない。

ヘッドトラッキング・テクノロジーによってユーザーの顔とFireとの相対的位置関係に応じた画面が表示される。つまりFireのスクリーンという窓を通して現実の空間を眺めているようなイリュージョンが生じる。この3D効果がAmazon Fireに注意を引くための単なるギミックで終わるのか、スマートフォンの次世代UIになるのかは今後を見なければならない。

Fireは4.7インチのIPS液晶ディスプレイ、手ブレ防止、f2.0レンズ付き13メガピクセルのリアカメラ、クアドコア2.2GHzチップ、Adreno330グラフィックス、2GBのRAMを備える。最新のAndroidフラグシップモデルほどのスペックではないが、快適に利用するには十分な能力がありそうだ。

Amazonはヘッドトラッキング3DシステムをDynamic Perspectiveと呼んでいる。毎秒60フレームのスピードで3D画像が再描画される。3D表示されるレイヤーは他のレイヤーの下に表示される。ユーザーはアイコンの下に3D画像を見る。4台のカメラは極めて広角のレンズを備えている。赤外線カメラなので非常に暗い場所でも空間認識は機能する。

Dynamic Perspectiveは単に3D表示ができるだけでなく、Fireを傾けるジェスチャーによって自動的に表示をスクロールさせることもできる。

以前にわれわれが報じたとおり、Amazonはデベロッパーに対してDynamic Perspective向けのSDKを用意している。われわれが取材したAmazon社員によると、Amazonはデベロッパーがこのテクノロジーを利用してアプリを作るようになることを熱望しているという。

AmazonがFireをプライム会員のために作ったというのは文字通りの意味だ。Fire TVと同様、Fireスマートフォンもプライム会員になった際に登録したユーザー情報が予め入力された状態でユーザーに対して発送される。結局のところFireの狙いはAmazonの上得意により多くの商品を買ってもらうことだ。Kindle Fireと同様、ユーザー個人向にカスタマイズされたサポート・サービス、MaydayがFireスマートフォンにも用意される。

さらにFireにはFireflyというオリジナル機能がある。これはカメラで電話番号、映画、本、ゲーム、CD、食品などを撮影すると、その商品が何であるか認識するシステムだ。Fireスマートフォンのユーザーは現実世界で目にしたものをカメラで撮影するだけで即座にAmazonから買うことができる。AmazonにとってFireflyは非常に強力なマーケティング・ツールとなりそうだ。

Fireスマートフォンは側面のボリューム・コントロールの下にFirefly専用のボタンを備えている。

Fireflyは芸術作品を見るとWikipediaで情報を検索してくれる。音楽を聞くと音楽アプリを起動してその音楽を再生する。テレビ番組を見ると、Amazonでそのシーンを探し出す。ベゾスは「Fireflyは1億種類のアイテムを認識できる」と豪語した。Fireflyのデベロッパー向けSDKも公開される予定だ。

またFireのユーザーはAmazonのクラウド・ドライブに容量無制限で写真をバックアップできる。 高性能なカメラとあいまって、Amazonは写真好きなユーザーの取り込みを狙っているようだ。

またFireにはPandora、Spotify、iHeartRadioその他人気のある音楽ストリーミング・アプリがプレロードされている。ユーザーはAmazon Prime Musicの現在のところ貧弱なライブラリーに我慢する必要はないわけだ。

TechCrunchではAmazonoの独自スマートフォンについて9ヶ月前から多くの情報を得てきた。ヘッドトラッキング機能やユーザー向け独自機能についてもスクープしている。われわれは3Dヘッドトラッキング機能がOmronのOkao Vison顔認識テクノロジーを利用していることも突き止めた。またAT&Tがキャリヤとして独占販売権を手に入れたことも報じている。今回のAmazonの発表の内容の大部分はTechCrunchがすでにつかんでいたといえる。

〔日本版：「信頼を生む方法：　1. 困難なことをきちんとやり遂げる。2. それを繰り返す。」というお気に入りのモットーを説くベゾス。イベントのライブ・ブログに写真多数。〕

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


Microsoft、Azure MLを発表―クラウドベースの機械学習プラットフォームは未来を予測する

最近急速にクラウド化しているMicrosoftが、今日（米国時間6/16）、クラウドベースの機械学習プラットフォームを発表した。このAzure MLはクラウド上でビッグデータを利用することにより、単に過去を分析するのではなく、将来の事象を予測するアプリやAPIを作ることができる。

Azure MLはXboxやBingですでに使われている機械学習機能を利用している。またデベロッパーが未来予測アプリを開発するために使うテンプレートとワークフローも用意される。これによって機械学習アプリを開発するスピードは大幅に加速されるという。サービスのプロバイダはAzure MLプラットフォーム上で各種のウェブサービスを開発できるだけでなく、APIを公開することも可能になる。

Microsoftのコーポレート・バイスプレジデントでAzure MLの責任者、Joseph Sirosh（Microsoftに移る前は長年Amazonに在職）は、「このプラットフォームを利用すればユーザー、パートナーは未来を予測するビッグデータ・アプリケーションを開発することが可能になる」と述べた。

Siroshは「過去の分析ではなく未来を予測し、それを変えることができるのがAzure MLの傑出した特長だ」という。

「既存のデータ分析システムも未来の予測ができる。しかし機械学習は未来を書き換えることができる」とSiroshは説明する。 つまりビッグデータを分析してパターンを発見し、製品の需要や病気の流行を予測したり、エレベーターが故障する前にメンテナンスが必要だと教えたりする。さらには犯罪の発生を予測して防犯に役立てることもできるという。

Siroshによれば、こうしたことを可能にしてゲームのルールを変えたのはクラウド化だという。もしユーザー企業が独力で実行しようとすれば何週間も、それどころか何ヶ月もかかるような膨大な処理がクラウド上ではごく短時間で実行できる。

またSiroshは「クラウドは最後の1マイル問題も解決した」という。以前このようなサービスではまずデータ・サイエンティストがビッグデータを分析してパターンを見出し、IT部門がそれに応じてアプリケーションを開発するという手順を踏む必要があった。このプログラムのコーディングがきわめて手間のかかる作業であり、何週間、何ヶ月もかかっていた。しかしAzure MLならアプリケーション開発は数時間ですんでしまうという。

また多くのデータ・サイエンティストが利用している統計処理言語Rのオープンソース・プロジェクトから300以上のパッケージが利用できる。

またSiroshは多くのユーザーがAzure MLプラットフォーム上でアプリやAPIを公開することによって好循環が始まることを期待している。「ユーザーがデータをAzure MLに持ってきてアプリやAPIを公開する。するとさらに多くのユーザーそのアプリをAPIを利用してさら多くのデータをAzure MLに持ち込むようになる」とSiroshは説明する。

Azure MLは現在、秘密にプレビューされている。しかしMicrosoftはいくつかの実例を明かした。その一つはMirosoftのパートナー、Max451が開発しているシステムで、これは小売業者が消費者の好みを分析することによって商品の売れ行きを予測するサービスだ。小売業者はもっとも売れそうな商品の在庫を増やすなどして利益を増大できる。

またカーネギーメロン大学はキャンパスの建物でのエネルギー消費を抑えるためにAzure MLを使って学内の活動パターンの予測手法を開発中だ。

しかしこの分野を手がけているのはMicrosoftばかりではない。IBMは昨年冬、Watson人工知能をクラウド・サービス化した。また先週はErsatz Labsというスタートアップがディープラーニング人工知能のクラウドプラットフォームをローンチしている。

Azure MLは来月に公開プレビュー段階に入るという。正式リリースの日程は明らかにされていない。

写真： (c) Can Stock Photo

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


Appleはメッセージ入力中に相手のプロフィール写真を大きく表示する特許を取得していた

AppleInsiderは、Appleがアメリカ特許商標局（USPTO）から新しい特許の承認を受けていたことを見つけ出した。この特許はテキスト・メッセージを入力中に相手を間違えないようにするためのものだ。間違った相手にSMSのメッセージを送信してしまうほど最低な失敗はない。取り返しのつかない惨事を招く場合さえある。

Appleが特許を取ったシステムでは、テキストを入力に送信相手の写真を背景に大きくはっきり表示する。これならどんなにうっかりしていても今、誰に向かって送信しようとしているのか忘れる気づかいはあるまい。

グループ・チャットの場合はグリッドか横スクロールで全員の写真が表示される。さらに最後にメッセージを受けた相手をカラーで、他の相手をグレーアウトするなどのコミュニケーションを助ける機能も追加される。

相手の写真が得られない場合は男女別のシルエットが表示される。これでも多少は自分が送信しようとしている相手の属性を知る助けになる。またこの特許では、APIを通じてサードパーティーもこの機能を利用できるとしている。

テキスト・アプリの場合はDMほど間違いを犯しやすくないが、 それでも間違うことはあるし、その結果も同じくらい壊滅的だ。Appleは従来の可能な限りシンプルなUIという方針をある程度犠牲にしても、機能を優先することにしたようだ。それでもどぎついフルカラーで直接画像を表示するようなやり方は避け、透明性をコントロールするというような繊細なデザインを採用している。Appleの特許の通例で、すぐに実際の製品に採用されることはなさそうだが、Appleがユーザー体験のコアとなるような部分でも日々小さない改良を重ねていることのもうひとつの証拠といえるだろう。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


音声認識で英語が学習できるブラウザ・ゲーム、Spell UpがGoogle Chrome Experimentで登場

Googleはベータ版や一時的プロジェクトとして新たなサービスを提供するのが得意だが、今日（米国時間5/13）はChrome Experimentの一環としてSpell Upという英語学習アプリを公開した。これは音声認識と音声合成を用いてユーザーの英語の上達を助けるブラウザ・ベースのゲームだ。

初級から上級までさまざまなレベルが用意されており、ユーザーはどのレベルから始めることもできる。このゲームの主な目的は語彙力を高めることで、Spell　Upという名前もそこから来ている。

ユーザーはブラウザが表示する単語を正しく発音しなければならない。表示された綴りから抜けているするアルファベットを推測したり、綴り変えから正しい単語を推測したりするモードもある。答えはすべてマイクに音声で入力する（私が試したところではこのアプリは英国英語の発音を好むようだ）。

このアプリははロンドンのGoogle Creative LabのXavier Barradeをリーダーとして開発された。最近のChromeの音声認識/合成テクノロジーの進歩が存分に利用されている。

昨年GoogleはChromeでWeb Speech APIを、今年はそれを利用した音声合成をそれぞれサポートした。これによってデベロッパーはユーザーが音声でデータを入力し、それに対してアプリが音声で応答するアプリを開発することができるようになった。Spell Upはこのテクノロジーを利用している。

つまりSpell Upは面白いゲームであり教育アプリであると同時に、音声認識、合成などブラウザ・ベースのテクノロジーがネーティブ・アプリの開発環境に負けず、大きく進歩していることを示すデモの役目も果たしている。またこのプロジェクトが若く、国際的なユーザー層をターゲットにしていることも興味深い。

Barradeによれば、Spell Upはゲームデザイナーと英語教育関係者の協力によって開発されたという。最近の教育アプリはデベロッパー、ゲームデザイナー、教育者の三者の連合が必須となっているようだ。このアプリは主としてデスクトップとAndroidのChrome向けに開発されており、iPhone、iPadで実行すると音声入力が無効になるのでユーザーは回答をキーボードからタイプしなければならない。

現在このアプリは英語だけが対象だが、他の言語にも拡張されれば、英語国における外国語教育にも大いに有益だろう。

Macのノートでしばらくプレイしてみたが、たいへん面白かった。ただし音声認識の反応はやや遅く、私が発音したアルファベットを完全に誤解したことも一度ならずあった。しかし私の子供は喜びそうだし、こういうアプリのためならいくらネットを使ってもらっても構わない。

下はGoogleによる紹介ビデオ。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


容量無制限のBitcasaが自分を無名のクラウドストレージインフラとして使えるAPIサービスCloudFSを提供

かつてTechCrunch Disrupt Battlefieldでデビューし、“容量無制限”*で話題になったクラウドストレージサービスBitcasaが今日（米国時間5/6）、デベロッパ向けのAPIサービスCloudFS〔クラウドファイルシステム〕を立ち上げる。これにより、デベロッパが作るアプリケーションの中から、Bitcasaというブランド名を意識することなく、クラウドストレージにアクセスできるようになる。Bitcasaによると、すでにPlexやCloudlessなどがこのAPIサービスを利用している。〔*: 今では無料（20GB）から無制限（11900円/月）まで4段階の利用プランがある。　〕

CEOのBrian Taptichによると、11月にローンチしたデベロッパ向けサービスはすでに5000名の登録ユーザがいるが、彼等からのいちばん強い要望が、自分のアプリケーションの中からBitcasaというサービスをBitcasaという名前で利用することでなく、まるで自分のアプリケーションの中に、それの機能の一環として、クラウドストレージの利用もある、すなわちサードパーティサービスのブランド名が表に出ない、という使い方だった。

このAPIセットは、いろんな機能を提供している。ファイル管理、ファイル共有、メディアのコード変換、パスワード不要の暗号化、などなど公開クラウドストレージの主機能すべてだ。しかも同社は、Bitcasaの従来の”Turn-key Drive”に加えて9つの既製のアプリケーションを提供するので、デベロッパの仕事も楽になる。しかもデベロッパは、BitcasaのCloudFS APIサービスからAWSなどそのほかのクラウドサービスにもアクセスできる。

“EvernoteやDropboxには、バックエンドのストレージを管理する機能がない。消費者向けサービスとしては、優秀だけどね”、とTaptichは説明する。彼によれば、同社は今後、次世代のデベロッパ向けのサービスに力を入れる。次世代のデベロッパとは、パブリッククラウドの構築に要するオーバヘッドや時間、労力などを自ら投じようとはしない、文字通り新人類のデベロッパたちだ。

“このAPIを使うと、デベロッパが自分だけのiCloudを簡単に作れるんだ”、と彼は言う。

CEOは、デベロッパプラットホームへの注力は同社の方向転換ではない、と念を押す。本来の消費者向けサービスはユーザ数が100万を超えており、今後も継続する。デベロッパ向けサービスの開始は、同社のプロダクトの多様化だ。今の顧客の中には（実名を挙げないが）合衆国やそのほかの国のモバイル事業者もおり、彼等は、Google(Google Drive)やApple(iCloud)に対抗して独自のクラウドストレージを提供できることに関心がある。そういう意味でデベロッパ向けのBitcasaは、各顧客が自分のクラウドストレージを築くための、無印の原料だ。

APIのドキュメンテーションは、今日からあるが、APIの非公開ベータは今月末に始まる。公開ベータは夏の予定だ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


学習管理プラットフォーム「Studyplus」がAPIを公開–外部教材アプリとの連携を強化

“IT×教育”の分野を指す「EdTech」。その中でも、教育のコンテンツではなく、プラットフォームの提供を進めるスタートアップがスタディプラスだ。

同社が提供する学習管理プラットフォーム「Studyplus」は、受験生を中心に現在約40万人の学生が利用している。Studyplusでは、ユーザーである学生が、自分の勉強の記録をつけてグラフとして可視化したり、勉強仲間を作ってコミュニケーションをしたりする機能を備えている。

ユーザーのサービス満足度は非常に高いようで、App Store、Google Playともにアプリの評価は4以上。レビューも好意的な内容が目立っている。また3月にサービスを見たときなどは、「○○大学に合格しました！」といったメッセージが並んでいるのが印象的だった。最近では、東京・渋谷にあるオフィスに併設するかたちで学習室「STUDY LOUNGE」を設立。オンラインだけでなくリアルに学びの場を提供している（ちなみに数カ月以内にもスペース運営単体での黒字化が実現しそう、とのことだった）。

そんなStudlyplusだが、5月1日よりサービス連携に向けたAPIを一般公開する。このAPIを外部の教材アプリ開発者が利用することで、そのアプリでの学習記録をStudyplusで自動的に記録できるようになる。

すでに複数の外部開発者が対応を予定しているとのことで、同社では年内100以上の教育・学習系サービスとの連携を目指す。また、これとあわせて、APIを利用した自社開発の英単語学習アプリ「ラーニングドラゴン英単語 3300」もiOS向けに提供する。

ラーニングドラゴンは、スマホ向けゲームを模した英単語学習アプリ。単語の学習、4択クイズをこなすことで、敵を倒していくというRPG風のアプリとなる。中学卒業レベルから難関大学入試（TOEIC700点程度）までの単語に対応。基本プレイは無料で200単語までの学習に対応。それ以上のコンテンツを利用する場合、月額500円がかかる。「まずは（API連携の）可能性をこのアプリで見せたい。教育カテゴリのサービスがきちんと儲かって運営できるカテゴリにならないといけないと思っている」（スタディプラス代表取締役の廣瀬高志氏）

なお同社はこれまでストックフォト販売を手がけるアマナホールディングスやミクシィ、ベンチャーキャピタルのジャフコなどから資金調達をしているが、現在次の調達に向けての準備中とのことだ。


Facebookがトレンド情報などメディアが食いつきそうな一連の新API集合を提供開始

テレビのニュースなどのメディアソースが、これからは、Facebook上で、どんな人たちに何が人気かを、話題にすることができる。今日Facebookは、Trending、Topic Insights、Topic Feed、Hashtag Counter、などのAPIをローンチした。それはFacebookのPublic Content Solutions部門からの提供で、Facebookはこの部門の活躍により、メディアの関心を（今もっぱら彼らが集（たか）っている）Twitterから奪いたいのだ。

新しいAPIはこんなのだ:

  • Trending – Facebookで今トレンドになっている話題の一覧を個人情報ぬきで提供する。
  • Topic Insights – 特定の話題を話し合っている人たちの層特性をやはり名前などぬきで提供する。
  • Topic Feed – 特定の話題に関連する公開ポストを気になる言葉で検索し、フィードのランクを見る。
  • Hashtag Counter – 一定の時間内～期間内に特定のハッシュタグが言及された回数を数える。

たとえばテレビ番組Dancing With The Starsが、Facebookのデータを視覚化して見せたいと思ったら、どうするか。Trendingを使って、この番組がFacebook上でも人気があることを視聴者に教え、ついでに世界のニュースなども見せるだろう。Topic Insightsを使えば、この番組の人気が高いのはどの地方のどんな人たち（性別など）で、ほかにどんな関心をもっている連中かを視聴者に伝えられる。Topic Feedを使えば、Dancing With The Starsに関連するすべての公開ポストを見せられる。また、番組に出演している二つのダンスチームのハッシュタグを見せて、視聴者にどっちが好きか投票させ、その結果を比較して話題にすることもできる。

Topic Insights APIは前からあったのでは？と思った方は、それがまさに、去年ローンチしたKeyword Insights APIの進化形だからだ。メディアの連中は、Keyword Insights APIはあまりにも使い辛い、と言いつづけてきた。その話題に関連したものを何でも知りたいのに、利用者は検索するすべてのキーワードのリストを手作業で作らなければならない。これでは結果は“何でも”にならない。新しいAPIでは、利用者（メディアなど）は話題（トピック）の言葉を指定するだけでよい。関連ポストを探すのは、Facebook自身がやってくれる。たとえば”Red Sox”というチーム名のトピックをTopic Insightsで指定すれば、スタジアムのFenway Parkやチームの各選手などに関連したポストも調べられるだろう。

Facebookが、今現在のホットな話題に関するデータをテレビなどのメディアに提供するのは、なぜだろう？　ユーザがそれらをテレビで見たら、自分もまた、Facebookへ行って、そのイベントについて投稿したり、誰かとおしゃべりしたくなるからだ。すなわち、Facebookのアクティブユーザ増強策の一環であります。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


Google、地図アプリのデベロッパー向けJavaScript APIでGeoJSONをサポート

今日（米国時間3/19）、GoogleはGoogleマップのJavaScript APIにGeoJSON supportのサポートを追加すると発表した。マップを利用するデベロッパーにとっては朗報となる。

GeoJSONはオープンソースのデータフォーマットで、ここ数年急速に普及し、現在ではこの分野における非公式な標準フォーマットとなっている。

GoogleマップのJavaScript APIはKML、GeoRSSなどいくつものフォーマットをサポートしており、デベロッパーはGoogleのFusion Tablesからのデータをレンダリングすることができる。GeoJSONのサポートで、位置データをマップ上に取り込むのが一層容易になり、デベロッパーはUSGS（米国地質調査所）やGoogle Maps Engineなどのサードパーティーの情報源から簡単にデータをインポートし、地図上に表示できるようになる。このためにデベロッパーはアプリのソースコードに1行書き加えるだけでよい。

GeoJSONのサポートにともなってGoogleはAPIに新しいデータ・レイヤーを追加した。

デベロッパーはGeoJSONを用いれば単に緯度経度データだけでなく、川の流速や店舗の営業時間などさまざまな情報を付加することができる。こうした柔軟性を利用して地図の表示スタイルをカスタマイズすると、たとえば、世界地図の上に最近起きた地震の位置を示すだけでなく、地震の規模を円の直径で示すこともできる。またデベロッパーは地図のユーザーが対話的に地図を操作できる機能も容易に組み込める。

これまでGoogleが提供してきた手段に比べてはるかに簡単なので、GeoJSONの利用はデベロッパーの間に急速に普及するものと思われる。

[原文へ]

（翻訳：滑川海彦　Facebook Google+）


言語処理は学歴よりも言葉に対する実践的な能力が鍵と信ずるAylien, テキスト分析サービスをAPIで提供

テキストを扱うことは、プログラマにとって往々にして面倒な仕事だ。コードは曖昧であってはいけないが、テキストは曖昧性のかたまりであることが多い。そこでかねてから、Alchemy、Thomson Reutersといったあたりが自然言語処理(NLP)と機械学習のアルゴリズムを利用するサービスを提供して、文書からもっと容易に意味を取り出せるように、デベロッパの仕事を助けてきた。今回ご紹介するAylienも、独自のテキスト分析APIでこの競技に参戦してきたが、同社の場合それは、これから提供していく一連のデベロッパサービスの第一弾となるものだ。

サービスのファウンダはダブリン（アイルランド）のParsa Ghaffariで、Chinacceleratorが支援している。Ghaffariによると、最初にこのアクセラレータ事業に応募したときには、NLPを使って今書いている文書から有意データを自動的に取り出すプロダクト、というアイデアを抱えていた。ところが、そのために利用できる基本技術がまだ存在しないことが分かった。そこで彼は基本技術の構築から始めることにし、そのための3年の努力の末、Aylienの立ち上げにたどり着いた。

デベロッパはこのAPIを使ってドキュメントから見出しや本文を素早く取り出すことができるが、そのほかに要約機能や、エンティティとコンセプトを取り出す機能、言語や感情の検出機能などがある。私の場合、個人的なプロジェクトにこのAPIを使ってみる機会が二度あったが、一部の例外を除いては、だいたい同社の効能書きどおりの仕事をしてくれた。ただし今のところ得意なのは英語のテキストだけで、たとえば、Googleのストリートビューの最近の拡張について書いたこのドイツ語の記事を、Aylienは100%の確信をもって、スポーツのカーリングに関する記事だ、と主張した*。同社は今、英語以外の言語のサポートに関しては‘鋭意努力中’である。〔*: カーリングではなくGoogle Mapsとホッキョクグマの保護に関する記事。同趣旨の英語の本誌記事に対してAylienは、‘自然科学-地理学’とラベルした…それは‘カーリング’ほど見当外れではない（笑）。たしかにGoogle Mapsは、地理の化け物だ。〕

このサービスを試用してみたい人は、ここへ行って、AylienのAPIデモに、何らかのテキストドキュメントのURLを与えてやるとよい。

データはすべてJSONで返され、同社はMashapeを、APIの有料利用のための窓口としている。ただしAPI呼び出しが1日に1000回未満なら無料だ。それ以上だと、1日6000回までが199ドルなどと課金される。既存の同種APIに比べると、やや安いと言える。

今Aylienは、ファウンダも含めて技術者3人だけの会社だが、PhD（博士号）の保有者は一人もいない。NLPのスタートアップとしては、かなり異例だ。Ghaffariは学術的学問的なNLPの世界と無縁ではないが、彼は、同社のような言葉に対する実践的なアプローチの場合、学歴はあまり役に立たない、と確信している。

同社の次のプロジェクトは、ニュース記事をフィルタするnews APIだ。またデベロッパサービスのために作ってきた技術を、いくつかの消費者向けのプロダクトに応用することにも取り組んでいる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


Zapierがデベロッパプラットホームを大幅アップデート, 誰もが自由にデータネットワークを構成できる時代へ

複数のアプリケーションを結びつけて仕事を自動化できるプラットホームZapierにはこれまで、統合化できるサードパーティサービスにやや制約があった。それが、今週発表されたデベロッパプラットホームのアップデートにより、変わった。

この変化によって何よりもまず、システムがオープンになり、どんなアプリケーションでもお互いに対話し、データを交換できるようになった。したがって、複数のアプリケーションを使って行う仕事が、ずっと楽になった。そうやってアプリケーション同士を結びつけて使うようになると、凝り固まった融通の効かないオンプレミスのテクノロジを解体できるようになり、データの取り出しや利用がこれまでになく自由に多面的に行えるようになる。

Zapierは、このところ増えてきた、‘きっかけを実際のアクションに変える’サービスの一つだ。Zapierを使うとたとえば、どこかのWebページがアップデートされた、というきっかけを、その通知を得るというアクションに変えられる。ソーシャルネットワークに写真が送られた、というきっかけを、それをDropboxに保存するというアクションに、このサービスを使って変えられる。

これからは、APIを公開しているサービスならなんでもZapierに加えられる。しかも、一つのきっかけ（トリガ, trigger）に複数のアクション、複数のきっかけに一つのアクションを結びつけられる。そこでたとえば企業は、営業、経理など複数の部課からの情報を結びつけてまとめることができるだろう。

Zapierは今、262のサービスを結びつけられる。Gmail、MailChimp、Dropbox、Salesforceなどもその中にある。昨年の夏にデベロッパプラットホームをローンチして以来、新たに141のサービスが加わった。また、デベロッパプラットホームはBackbone.jsを使って作り直したので、より高速になった。

Zapierの協同ファウンダWade Fosterによると、これまでは特定の高度な認証方法を使っているサービス（Google Docs、Twilioなど）しかZapierに加えられなかったが、今回アップデートされたデベロッパプラットホームでは、一般的によく使われている認証方式を使っているサービスなら何でもよい。これにより、Zapierを使えるサービスの数はどっと増えるだろう。デベロッパはもちろんのこと、プログラムを書けない人でも、APIのあるサービスなら何でも加えられるようになる。オンプレミスのCRMやERPシステムでも、公開的に、あるいは社内限定的に、結びつけることができる。

たとえば下の例では、EtsyをZapierのプラットホームに加えている:

ZapierのAPIの前面に座って、サービス同士を結びつける仕事をしているスクリプティングエンジンも公開される。これによりデベロッパは、複数のソースからデータを取り出せる。これまでのAPIでは、二点を結ぶことしかできなかった。しかしこれからは、複数のアプリケーションを呼び出したり、異なるサービスやデータソースから取り出した情報を返せる。

たとえば、請求データと、売り先の顧客の連絡先情報がそれぞれ別のサイロにあっても、一つのAPIから両方にアクセスできるようになる。

これまであまりにも長く、企業のITは迷路のようなデータサイロ群を抱えていた。しかし、BMC SoftwareのCTO Chris Dancyによると、Zapierにより誰もがSAPやOracleのデータを結びつけることができるので、多様な可能性が開ける。それは、SaaSの勃興と、使いやすい各種サービスの誕生によって生まれた“影のIT”のおかげだ。相対的に、従来からの表のITが無能に見えてくる。

Dancyは次のように言う。“映画のInceptionのようなITとは、アシスタントたちや、工場の工員、あちこちの平（ひら）の社員たちがAPIラッパーを使って企業の動的構造を実質的に変えているような情報ワークだ”。彼らのことを、影のITと呼ぶ。

人びとが、そのように、新しい形で結びつけるためには、あちこちに散在している互いに異質な情報を結びつける方法が必要だ。そしてZapierのデベロッパプラットホームは、これまで専門の技術者に頼って、高い費用をかけて行っていた複数のデータソースの結合を、誰もが日常的にできる情報ワークに変える、そういう方法の一つなのだ。

社内各所に、APIによって結ばれたデータのネットワークができて、それに伴って組織の構造も変わる。次のステップは、使いやすさの実現、つまり専門技術者ではない若い女子社員にでも簡単にデータ分析ができるようにデザインされたAPIだ。そうして、誰もが自分独自のリコメンデーションエンジンや、それまでデベロッパにしか作れなかった結合ネットワークを作れるようになる。インセプションITの時代にようこそ！、だ。

(画像提供: Flickrより。)

おことわり: この記事の起源は、Chris Dancyと、Wiredのライターで本誌TechCrunchの寄稿者Klint Finleyとのポッドキャストだ。そこで私たちは、サイボーグとAPIについて、話し合っている。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


Pinterest、ディズニーなど数多くのビッグネームと提携して、いよいよAPIの提供を開始

Pinterestが、長らく待望されていたAPIを開発者向けにようやくリリースした。APIを利用して、サードパーティーのサイトにてPinterestのPinを埋め込んだり、サイトの写真を簡単にPinterestに投稿できるようになる。API公開に伴って発表されたパートナーにはZappos、Walmart、Disney、Nestle、Random House、Hearstなどのビッグネームが連なっている（後述）。提携先のリストや、あるいは提携サイトなどを見れば、広告やクロス・マーケティングにおけるPinterestの可能性は否定しようのないものだとも感じる。

「来週中には、これからしばらくのうちにパートナーに対して公開するAPIの内容を発表していきたいと考えています」とブログにも書いてある。公開されるAPIはTop Pins（最もクリックされているもの、もっともre-pinされているものなどで、パートナーサイトでは既に利用されている）、Domain検索（「Men’s Boots」や「Thanksgiving recipes」あるいは「Fashion Week」といったキーワードに対して、検索でヒットする人気のコンテンツが戻される）、Most Recent（直近にPinした内容がいくつか戻される）、そしてRelated Pins（表示しているPinに関連するアイテムないしコンテンツを含む、関連しそうなPinに関する情報が戻る）などとなる。

Pinterestによれば、他にもいろいろなAPIを提供していく予定だとのこと。

こうした形で、商用利用できるAPIを提供するという話が出てきたのは数ヶ月前（あるいは1年以上も前）のことだ。実は昨日も、リリース直前ではあったものの、APIについてのアナウンスを行っていた。

Pinterestのリファラルとしての能力については、既に疑う人もいないほどだ。Shareaholicのデータによれば、Facebookに次ぐ2番めであり、かつFacebookよりも速い速度で成長中なのだそうだ。

APIの提供を開始することで、Pinterestはさらなる成長に向けての準備を整えたということが言えよう。メーカーやブランドにとって、投稿された（投稿してある）Pinを、これまで以上に活用できるようになる。また、メーカーサイトにある画像のPinも容易に行えるようになる。Pinterestで共有されているデータは、他のサイト（メーカーサイト等）と一層有機的に結びつくようになる。最近にもGettyと、画像データの共有にあたってはメタデータの提供も行うようにするという提携を行った。APIによるデータ連携は、これと同様に写真データに付随する各種情報について、Pinterest上の写真と、オリジナルの場所との間でより密な形で共有することになるわけだ。Pinterest側からも、あるいはオリジナルのデータの所有者側からも、データの管理が行い易くなるという意味もありそうだ。これにより、Pinterestのデータを活用したマーケティング活動もいろいろと考えられるようになる。

APIを利用しているサイトにある画像については、たとえばショッピングや記事閲覧などを中断することなく、簡単にPin登録が行えるようにもなる。現段階で提携をアナウンスしているサービスを、以下にすべて列挙しておこう。AllRecipes、Better Homes and Garden、BuzzFeed、Disney傘下のBabbleおよびBabyZone、Elle Magazine、Mashable、ModCloth、NBC News DigitalのiVillage、Nestlé、Random House、Snapguide、Target、Walmart、Wayfair、Whole Foods、Zappos、Zulily、そしてSpoonful and Taste Bookも間もなく利用を開始するようだ。

［原文へ］

（翻訳：Maeda, H）


モバイル開発プラットホームAppceleratorが高度なAPIアグリゲータSinglyを買収, いよいよ業界の地固め期に

モバイル開発のためのSaaSプラットホームAppcelerator（開発ツールTitaniumなども提供）が、Webとモバイルのアプリケーション開発においてサードパーティサービス（各種API呼び出し）を管理するプラットホームSinglyを買収した。買収の金額条件などは公表されていない。Singlyは、同社のAppFabricサービスとDataFabricサービスをAppcelerator PlatformおよびTitaniumに統合する作業をただちに開始する。

Singlyは3年前に創業され、昨年12月に公開ベータに入った。本誌のSarah Perezは当時、Singlyは（アプリが呼び出す）サードパーティのサービスでユーザを認証したり、いろんなソーシャルネットワークやそのほかのサービスからデータ（フレンドリスト、写真、プロファイルなど）を取り込んだりするコードを、簡単にはやく書けるようにする、と紹介していた。アプリケーションの中で、ユーザが複数の異なるソーシャルネットワークで共有することも、可能にする。こういう、複数サービス横断型の総合API管理デベロッパサービスのことを、同社は“app fabric（アプリケーションの織物）”と呼んでいた。Singlyはほかにも、データのシンク、ストレージ、データの重複排除、データのクェリとフィルタリング、などの便宜をデベロッパに提供する。

SinglyのファウンダJason Cavnarは、それまでソーシャルリーダー(reader)のNsyghtにいた。Jeremie Millerは、インスタントメッセージングのオープンソースプロトコルJabber/XMPPの発明者として有名だ。そしてもう一人のファウンダが、Simon Murtha-Smithだ。

APIアナリストのKin Laneにメールでインタビューしたら、こう言った: “いろんな有力APIを利用したアプリケーションを書くとき、それらのAPIのユーザ認証とか統合といった面倒な部分を、全部Singlyが面倒見てくれる。面倒なだけでなく、各APIごとにユニークなoAuthとAPIエンドポイントをバランス良くナビゲートするのが難しい。今度の買収でSinglyのファンが増えるだけでなく、開発プラットホームとしてのAppceleratorの魅力も高まる。APIアグリゲータはほかにも数社あるが、この方面で（Singlyのファウンダ）Jeremie Millerの専門知識・技能にかなう者はいない”。

Singlyがデベロッパたちの注目を浴びているのも、その血筋の良さと、技術に対する深い理解、そしてオープンソースやコミュニティに対する情熱のためだ。その姿勢は、合衆国の主要都市を巡回して行われるAPIs&IPAsツアーにも表れている。同社のブログによると、そのイベントはミートアップでもカンファレンスでもハッカソンでもなく、とにかく、楽しい時間を過ごすことだ、という。同社は各都市の地元のテク企業とパートナーし、地元スタートアップになじみのバーを選び、テクコミュニティを惹きつけるためにイベントを宣伝する。まさに、デベロッパマーケティングの王道だ。

この二社の合体は、API管理という業界分野における一つの節目だ。これまでの数か月で、IntelがMasheryを買収、CAがLayer 7を買収、そして著名なAPIデータベースProgrammable WebをMulesoftが買収するなど、業界の再編成が激しく進んでいた。Appcelerator + Singlyは、その総仕上げだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


OpenStackをAPIレベルでAWS互換にせよ, という切実なる公開書簡

CloudscalingのCTO Randy Biasが今日（米国時間7/24）、OpenStackに宛てた公開書簡を書いた。その中で彼は、オープンなクラウドを目指す各種の取り組みは、Amazon Web Services(AWS)のデファクトスタンダード性を素直に認めて、それと互換性のあるAPIを整備しなければ勝利できない、と述べている。

彼は、AWSは事実上のリーダーだ、と主張する。だから正しい対応は: OpenStackは独自のAPIを作って自己を差別化する努力をやめて、AWSがパブリッククラウドにおける勝者であるという現実を受け入れることだ。そうすればOpenStackは、AWS的なパブリッククラウドと現代的なデータセンターが交わる“ハイブリッドな”クラウドの分野で勝てる。OpenStackが伸びる場所は、そこだ。その顧客は、それなりの伸縮自在性を持つクラウドオペレーティングシステムを必要とするが、何万何十万もの一般ユーザにサービスを提供する必要はない企業ユーザだ。

とりわけBiasは、OpenStackを使う場合の、スタンダードとなるAPIを作ることを、Rackspaceに呼びかけている。彼は、OpenStackがこれまでRackspaceのオープンクラウド寄りのAPIを作ってきた経緯を、詳しく述べている。Biasによれば、RackspacはOpenStackのAPIを自分のために作ってきた*。同社はOpenStackを利用して、自己のサービスを差別化しようとしてきた。〔*: RackspaceはOpenStackの最有力の創設メンバーの一人。〕

たしかに、それは事実だ。明らかにRackspaceは、OpenStackという公共的な性格の団体を作るという機に乗じて、自分自身をより大きくしようとした。当時の同社は、クラウドの今後の方向性について模索し迷っていた。同社は、ホスティング企業からソフトウェアデベロッパへという、重要な曲がり角にさしかかっていた。そのことを、Rackspace自身も理解していたのか？　理解していたと思う。同社はOpenSackのリーダー役を買って出ることによって、それをコントロールしようとし、自社のクラウドとそのAPIをOpenStackの“ネイティブの”APIと呼ばせようとした。

しかしRackspaceには、世界初の大規模で本格的なオープンクラウド運動の口火を切った、という功績がある。今ではそこに、250社あまりが参加し、何千ものデベロッパが120万行を超えるコードを書いている。IBMもRed HatもHPも、みなOpenStackに加わった。そしてBiasはCloudscalingの新しい市場を開拓でき、そこに対し、クラウドインフラを構築するためのシステムサービスを提供していった。

しかし、ここにきてBiasがAWSを持ち上げるのには、理由がある。それは、彼自身の利害だ。彼の会社はAWSとGoogle Compute Engineを重視している。だからAWSとOpenStackが重なるようなAPIがあれば、彼の若い会社の大きな助けになる。こういった問題に関しては、クラウドコメンテーターのBen Kepesが良い記事を書いているので、一読をおすすめしたい。

それは、奇妙な状況でもある。OpenStackに参加している企業は、強きも弱きも、大きな市場圧力にさらされている。そしてそのプレッシャーを増幅しているのがAWSと、その疑問の余地なきイノベーションだ。OpenStackの創設から今日までの3年間で、AWSはクラウド宇宙を支配してしまった。

しかし、HP、IBM、Red Hat、AT&Tなどなど多くの企業は、AWSをそう簡単にパブリッククラウドのデファクトスタンダードとして受け入れるわけにはいかない、それぞれの事情を抱えている。彼らは、AWSに勝たせたくない。彼らから見ると、Amazonの、自分がコントロールを握ろうとするときのやり方は、あまりにも苛烈で非情だ。そのAPIはクローズドだし、いつでも勝手に変えることができる。独自の理由で、一部のサービスを一方的に切り詰めることすらありえる。

だから、Rackspaceがこれまで我が道を行くでやってきたように、誰もがそうしてきたのだ。

Biasは、OpenStackの将来性に疑問を投げかけている。最終的にそれは、誰の役に立つものになるのか、と。この、AWSのAPIとの互換性、という問題について、RedMonkのアナリストDonnie Berkholzに話を聞いてみた。彼は、結局それは将来性の問題だ、と言った。APIのプロバイダには、それを将来にわたってメンテする義務がある。そのAPIは、今後もずっと動くもの、使えるものでなければならない。その点に関しては、Amazonには疑念の余地がない。しかしOpenStackは、大きなクェスチョンマークだ。OpenStackには今すでに変種が相当多くて、統合を難しくしている。たとえば、Dreamhostはストレージに（分散並列ストレージ）Cephを使い、RackspaceはSwiftを使っている。Dellは、自社製を使っている。

OpenStackは、こういった複雑性を解消すべきである。しかし参加企業が多くてそれぞれが独自の利害を抱えているから、その課題は、言うは易く行うは難しの典型となる。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


既存のGoogle Mapsのアクセスではなく自由にカスタム地図を作れるMaps Engine APIがまず有料の企業ユーザに公開–将来は一般公開も

GoogleのMaps Engineは、主に企業が自分のデータに基づいて独自の地図を作るためのサービスで、二年前にローンチされ昨年から商用化された。今日（米国時間6/5）Googleはこのプラットホームの機能をなお一層増強すべく、Maps EngineのAPIを立ち上げた。これによりデベロッパは、独自データを使った独自の地図作りを、Maps Engineサービス上ではなく自己のアプリケーション内で行えるようになる。APIの提供に踏み切った理由をGoogleは、企業がアプリケーション内の地図作成提供機能としてGoogle Mapsよりも高度な、自己データに基づくものを要望しているからだ、と説明した。たとえば（静的なGoogle Mapsとは違って）、社員や顧客からのデータや情報を生かした地図の作成提供も可能になるのだ。

GoogleにはすでにMaps APIがあるじゃないか、と思われた方もおられると思うが、しかしMaps Engine APIのプロダクトマネージャDylan Lorimerによると、Maps APIでは主に、Google自身の地図コンテンツにアクセスできるだけである。それに対し、Maps Engine APIを使うと独自のデータを使ったカスタム地図を作れる（例: 上図）。なお、そのシステムにはGoogleの分散グローバルGPSデータベースSpannerが使われている。

このAPIはこれまで“実験段階”とされていたが、これを使うことにより、アプリケーションからの入力データ〜読み取りデータによって地図〜地図上の情報も変わる、という部分をデベロッパが容易にプログラミングできる。顧客のブランドのブランドイメージやニーズに即した地図も作れるし、またその地図をほかのデベロッパと共有することもできる。

たとえばFedExはこのAPIをしばらく試用していたが、今では同社の位置情報サービスstore locatorが完全にこれで動いている。 FedExのITマネージャPat Doyleによると、Maps Engineの利用に完全に切り換えたのは今年の1月からである。

テスターとしてのFedExからのフィードバックも、Maps Engine APIに反映されている。たとえば、指定した位置に関する結果（お店の所在など）をサーバサイドでソートするより容易な方法、などだ。このAPIを利用することによってFedExは、タッチインタフェイスの地図上の50000あまりの小売店の、営業時間のアップデートを、15分おきにできるようになった（営業時間だけでなく、一つのお店に約150項目のデータがある）。たとえば停電や天災などで急な閉店になっても、そのことがユーザにはすぐに分かるのだ。

Doyleによると、システムの信頼度は今のところ100%である。そして、アクセス分析データによると、store locatorを使ってお店を見つける人が、前よりも増えている。FedExの用例については、このビデオが参考になるだろう。

APIはまだ、Maps Engineサービスのごく一部の機能しかサポートしていない。ベーシックな場所クェリやベクタデータの操作などだ。近い将来、APIの拡張を行う、とGoogleのチームは言っている。またLorimerは、高価な企業向けのMaps Engineアカウントを持っていない一般のデベロッパでも、このようなAPIを利用できるようにしたい、これは自分個人の考えではなくGoogle自身の関心事だ、と力説した。この件に関しGoogleからの公式発表はまだないが、いずれある、と考えて間違いないだろう。


[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）


GoogleのContent Experiments APIを使えば多様なロジックでA/Bテストを展開できる

Googleが今日（米国時間6/4）、デベロッパのためのWebサイトテスト（実験）〜最適化ツールContent Experiments APIをローンチした。このAPI集合の背後にあるのはGoogle Analyticsなので、要するにAnalyticsの力を利用してさまざまな最適化努力の結果を計測できるのだ。Googleはこう説明している:“このAPIはGoogle Analyticsを本格的なA/Bテストプラットホームにするので、すべてのタイプのデベロッパがGoogle Analyticsを利用して実験を行えるようになる”。

Content Experimentsそのものは、Googleが1年前にローンチしたA/Bテストサービスで、その後も継続的に機能が追加されている。このサービスはmulti-armed bandit方式*でA/Bテストを行い、各バリエーションの成績に基づいてユーザの実験接触頻度を調節する。〔*: multi-armed bandit, モンテカルロ法のような、一種の乱数化サンプリング（ふつうスロットマシン(bandit)はアーム(arm)が一本しかないが、複数のアームのあるスロットマシンを多様な乱数生成系として比喩的にイメージする）〕。

今回のAPIでは、デベロッパが作ったバリエーション選択ロジックに基づいて、このMAB方式による実験を行える。結果の測値は、Google Analytics が出してくれる。

JavaScriptからContent Experimentsサービスを使うより、APIを直接使った方が良いと言えるのは、たとえば、ユーザをリダイレクトさせずにテスト対象の変更ができる。違うバリエーションをユーザに見せるために、よくリダイレクトが使われるが、それにはユーザ体験を損なう危険性がある。

また、テストをサーバサイドで行える。それはふつうのA/Bテストサービスにはない機能だが、Googleは、“サーバサイドで行うとリコメンデーションや検索のアルゴリズムの異なる実装のテストをやりやすい”、と言う。

さらにGoogleの主張では、小売店のキオスクのような、ノンWebの環境でもアプリケーションの異なるレイアウトやコンテンツや機能のテストをやりやすい。

A/Bテストツールは昨年あたりからホットな市場になってきて、たとえばOptimizelyは今年初めに2800万ドルを調達し、Amazonはモバイルアプリ用のテストサービスをローンチ、さらにTC Disrupt BattlefieldのファイナリストPathmappなど、数え切れないほど多くのスタートアップたちがデベロッパの関心を惹こうとねらっている。


[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）