Parseが閉鎖して困ってる人、Batch + Firebaseはどうかな?

screenheader20152x-2daf8ba2

FacebookがParseを閉鎖したため、それに代わるものを探しているモバイルデベロッパーが多い。GoogleのFirebaseも、その候補のひとつだ。それはしっかりとしたバックエンドサービスで、アプリのデータを保存し、それをアプリ側と瞬時にシンクできる。ただし難点は、プッシュ通知をサポートしていないことだ。

Parseを使って、マーケティング目的などのためにプッシュ通知を送っていたデベロッパーは多い。でもFirebaseはこれまで一貫して、プッシュ通知のバックエンドの提供を避けてきた。そこでご紹介したいのがBatch、モバイルアプリのデベロッパーのためのプッシュ通知バックエンドだ。

Batchでは、ユーザーベースを分割してプッシュ通知のデリバリを最適化できる。A/Bテストやアナリティクスのツールもあるので、プッシュ通知の長期的な効果を調べることもできる。

BatchにはParseからのマイグレーションツールがあり、Parseのデータをそのままインポートできる。BatchをFirebaseに統合する詳しいやり方も説明されているから、Parseのオルターナティブ(代替品)として利用できる。

欠点は、ParseからFirebase + Batchに移行するとプラットホームへの依存性が生じてしまうこと。それでまずい場合は、別のものを探そう。

でも、これまでParseを使っていて開発とメンテをこのまま続けたい人は、そのための方法を見つけなければならない。バックエンドを自作して、DigitalOceanなどの上でクラウドとして動かす方法もある。別のサービスへ移行してもよい。あるいは、あなたの場合運良く、FirebaseとBatchの組み合わせが使えるかもしれない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa

Facebookが大金で買い上げたデベロッパープラットホームParseを閉鎖へ(一年の執行猶予つき)

parse-shuts-down

これは驚き! Facebookが2013年に伝聞価額8500万ドルで買ったデベロッパープラットホームParse閉鎖する。主にモバイルデベロッパーが対象だったこのサービスは、その後Facebookの重要なデベロッパーサービスになっていた。

851561_358064504304297_846266674_n

Parseは2017年1月28日まで運用されているので、その間にプロジェクトをほかのプラットホームへ移すことはできる。このプラットホーム上で作られたアプリは60万に達するから、移行といっても簡単ではないが。

ここまで激しい変様を強制すれば、デベロッパーの信頼が揺らぐだろう。Facebookの今後のデベロッパーサービス、たとえば最近見つかったチャットボットSDKなどに対してデベロッパーは、サポートの継続に関してお粗末な経歴をもつ企業からのプラットホームに、時間とリソースを投じることを、ためらうだろう。

ParseとそのCEOのIlya Sukharは、Facebookのデベロッパーカンファレンスのキーノートでもスターだった。しかしSukharは昨年Facebookを去り、その後消息がない。Parseとは一体何だったのか、下のビデオで再確認しよう。

Parseのもう一人の協同ファウンダーKevin Lackerが、今日の発表声明の中で言っている: “移行が簡単でないことは十分理解しており、それができるかぎり容易になるよう、努力している。完全閉鎖まで、バックエンドサービスは確実にメンテナンスしていく。また、他のサービスへのアプリケーションの移行を助けるツールも、いくつか提供したい”。

同社によると、データベースを移行するためのツールを今後いくつか提供し、またParse Serverをオープンソースにするので、デベロッパーが自前のNode.jsサーバーから自力でParse APIの多くを動かせるようになる(あるいはHerokuのようなプラットホーム上でホストしてもよい)。でも、そもそも、デベロッパーにとってParseを使うことは、サーバーを扱うことの面倒から免(まぬが)れる、ということだったのだから、このような推奨に従うユーザーが何人いるか、という疑問は残る。

2016-01-28_1407

FacebookがParseを閉鎖するという決断は、これまで何年もそれに依存してきたデベロッパーだけでなく、もっと広い世界にとって、すごい驚きだ。でも、2013年以降、状況は変化した。AmazonやGoogle、Microsoftなどなどが、今では、同じようなツールをデベロッパーに提供している。最近のParseがどれだけのユーザーを抱えていたのかは分からないが、しかしFacebookはその現状を見て、続けるに値(あたい)しないと判断したのだろう。

今の状況は、FacebookのWebゲームプラットホームでデベロッパーが苦しめられていた暗黒時代、2009年ごろを思い起こさせる。Facebookは頻繁に、前触れもなく、プラットホームの仕様やヴァイラルのシナリオに大きな変更を加えた。そうすると、デベロッパーのそれまでのアプリ/アプリケーションは動かなくなり、彼らがあてにしていたビジネス機会も失われてしまった。

このような鞭打ち刑があまりにひどくなったので、デベロッパーたちはおおっぴらに、Facebookのやり方を批判するようになった。…それは、今と似ていなくはない:

[ParseはFacebookの中ではちっぽけな存在だから、デベロッパーとの関係を良くし維持するための小額の経費、と考えれば?]
[Parseは今Twitterの上でサンフランシスコの大きなトレンドだ。ぼくが参加しているデベロッパーチャネルでも、みんな憤慨している。]

その後FacebookはOperation Developer Loveという派手なキャンペーンを立ち上げ、今後はもっと気をつけます、プラットホームの変更については十分なコミュニケーションを図るようにします、と言ってデベロッパーを慰撫しようとした。Parseを閉鎖する前にまる一年間生かしておく、という今回の決断は、そのキャンペーンの名残のようだ。

しかしそれでも、Facebookは再び、同社のデベロッパーファミリーの幸福よりも、業績を優先したようだ。

[原文へ]。
(翻訳:iwatani(a.k.a. hiwa)。

今年のf8でFacebookがローンチしたもののすべて…そしてその背景

今年のf8には、ステージでMark Zuckerbergのパロディを演ずるコメディアンのAndy Sandbergはいなかった。そして、それは賢明だった。今やFacebookは何百万人ものデベロッパの生活を支えているソーシャルネットワークだから、おふざけは似合わない。その代わり今度のf8は、Facebookのプラットホームがデベロッパに対して敵対的で勝手にコロコロ変わるというイメージを払拭し、彼らのアプリケーションの成長と収益に貢献する新しい方法を提供する、という方向に集中した。

それは、一般大衆にとっては、おもしろくなかったかもしれない。Zuckのキーノートには、Timelineが発表された2011年のときのような輝きと情熱がなかった。しかしデベロッパのためのカンファレンスを消費者製品のローンチで濁(にご)すことなく、メッセージは明快だった。Facebookは大人になり、デベロッパに頼りにされる存在でなければならない。

Zuckerbergによると、Facebookは“クロスプラットホームなプラットホーム”になりたいのだそうだ。iOS、Android、Windows Phone、Webなど、すべてのプラットホームを横断する、という意味だ。AppleやGoogleと違って、Facebookは自分自身がモバイルのオペレーティングシステムを持っていないから、このように構えるのが便利である。

しかしFacebookはあくまでもソーシャルのレイヤ(層)にすぎないから、f8で行われた数々の発表も、現実的で自分の立場をよくわきまえている。その多くは、Facebookの目的をデベロッパの目的と合わせる、という努力に関連している。デベロッパの成長を助け、良質なアプリケーションの開発に貢献するものを提供していけば、彼らの信頼と愛着を獲得でき、News Feedのコンテンツや、広告収入という形でFacebookへの大きな貢献が返ってくる。だからこの記事でFacebookがデベロッパの成長を助ける云々と言うときも、それは単純な博愛精神という意味ではない。

今年のf8を取り上げた記事の総覧はここにあるが、ここではf8でローンチされたもの*の概要と、それらのFacebookにとっての意味を見ていこう。〔*: 各プロダクト名は英語の名前のままとします。〕

広告とeコマース

Audience Network(オーディエンス(の)ネットワーク)

広告主がFacebookの個人データを利用して、サードパーティのパブリッシャーのアプリケーション上で、標準のバナー広告でもカスタムのネイティブ広告でもターゲティングができる。Facebookは広告収入の一部を取るが、残りはデベロッパへ行くので、デベロッパは自分のアプリケーション上の広告が収入源になる。

Why? 収入の増大のため。Facebook自身のサイトやアプリケーションをこれ以上広告で混雑させるのではなく、ユーザが自発的に提供している個人データや活動データのデータベースを、ほかのところに出る広告で収益に結びつける。

Autofill With Facebook(Facebookから自動記入)

Facebookは、前にテストしていたAutofillプロダクトを、Ecwidのプラットホームを使ってeコマースのサイトを構築している45万の商業者に対し展開した。Autofillは、ユーザがどこかのeコマースで買い物をしたとき、決済のためのクレジットカード情報などをFacebook上の自分のデータから供給して、はやく買い物ができる、という仕組みだ。

Why? Facebookはマージンを取らないが、Autofillから決済データが行くと、商業者から見て、広告媒体としてのFacebookの価値が上がるのだ。

プラットホームとしてのFacebook

Anonymous Login(匿名ログイン)

“試してから買う”ための方法。Anonymous Login(匿名ログイン)によりユーザは、違うユーザ名やパスワードを作ることなく、また自分の個人データを明け渡すことなく、アプリケーションのデモなどを試せる。そのときの活動はFacebookが記録するから、完全に匿名ではない。またデベロッパは‘匿名優先(anonymous-first)’というタイプのアプリケーションを作れる。それはSecretのクローンのように、ユーザの名前は使わないが、そのユーザの過去の投稿やハイスコア、進捗段階(今どこまで来ているか)などのデータは記録し更新する。

Why? ユーザが新しいアプリケーションを試したいだけのときには、もっと気軽にログインできるようにする。あとでそのユーザが名前や共有許可を与えるとFacebookはそのコンテンツを収益源にでき、フィードにシェアできる。どちらの場合も、デベロッパの利益にもなる。Facebook自身も、アプリケーションを‘匿名優先(anonymous-first)’にできる。

友だちのデータを取り出せないようにする

デベロッパはユーザの友だちのデータ、すなわち顔写真、誕生日、ステータスアップデート、チェックインなどを勝手に取り出せないようになる。

Why? 当人の許可なく個人データを利用できる、という状態は、つねにヤバい。Facebookはプライバシー保護がいいかげん、という世評がますます高まる。でもデベロッパは、アルバム閲覧、検索エンジン、カレンダー、位置マップなど、Facebook自身のプロダクトと競合するようなアプリケーションを作れなくなる。

モバイルのプライバシー許可の選別制

これまでの個人データの共有許可は、‘すべてのデータ’を意味した。今度からデベロッパは、自分が利用したいデータのチェックリストを提出して、許可を求める(友だちリスト、いいね!、メールアドレス、News Feedにポストできる能力、など)。

Why? ユーザがサードパーティのアプリケーションにデータを与えるときの、プライバシー保護と透明性とユーザサイドのコントロールを強化する。Facebookでログインすると安全だ、という信頼感を持っていただく。

中核的APIの2年間安定保証

今回のf8のテーマは”Stable Mobile Platform”(安定したモバイルプラットホーム)になり、スローガンはそれまでの”Move Fast And Break Things”(快足イノベーション)から”Move Fast With Stable Infra”(安定したインフラで快足を)に変わった。コアAPIを変えたり廃止したりするときは、2年以上前に伝達する。

Why? デベロッパが安心してFacebookのAPIでアプリケーションを作れるため。前のように、知らない間に変わっていた、なくなっていた、ということがないように。

Graph API 2.0

アプリケーションスコープのユーザIDによりセキュリティを強化
アプリケーションを試験するためのフレームワーク
Social Context APIによりユーザの友だちの活動にアプリケーション内でアクセス
Tagged Places APIでユーザの位置(場所)を利用、タグの改良、ストーリー中の招待。

Why? より強力なアプリケーションの構築。

FbStart

新人デベロッパにFacebookや11社のサードパーティ企業(UserTesting.comなど)のサービスの3万ドルぶんの無料利用を提供。それらのサービスは、A/Bテスト、デバッグ、Adobe Creative Cloudによるクリエイティブなプロジェクトのためのクラウドストレージ。

Why? Facebookがアプリケーションを始動させることにより、今後の広告収入やコンテンツなどで3万ドルは十分取り返せる。

モバイルのいいね!ボタン

モバイルアプリに埋め込めるいいね!ボタンにより、ユーザはNews Feedでコンテンツを友だちと容易にシェアできる。

Why? Facebookが広告収入を得られるコンテンツを、より多くシェアできるようにする。それと同時にアプリのオーディエンスを増やす。

Send to Mobile

Webアプリケーションのデベロッパがユーザにプッシュ通知で関連のモバイルアプリをダウンロードするよう、おすすめする。

Why? アプリのオーディエンスの増。

Message Dialog

デベロッパがモバイルアプリにこのダイアログを埋め込んでおくと、ユーザは友だちにプライベートでFacebook Messageして、アプリ内コンテンツやアプリそのもののリンクを知らせる。

Why? Messengerのエンゲージメントを強化し、アプリの成長を助ける。

AppLinks

このオープンソースの技術により、デベロッパはアプリ内にクロスプラットホームでほかのコンテンツやアプリへのリンクを張れる。そのリンク(“ディープリンク”)はリンク対象のアプリやコンテンツをブラウザのウィンドウではなくデバイスのスクリーン上に開く。

Why? ディープリンクが普及すると、それを広告内で使用して広告のエンゲージメント、ひいては広告収入を増やせる。たとえばHotelTonightのサイトを訪れなくても、直接、ニューヨークのホテルのディスカウントを利用できるだろう。

メディアのための視覚化API

テレビ番組などのメディアが、Facebook上の最新トレンドなどを視覚化して表示できる。トレンドは個人データを抜いて集計され、またそのトレンドの中心となっている層の特性(例: 10代の女性)も教える。また、特定の話題が言及されている公開ポストや、ハッシュタグの言及を集計できる。

Why? Facebookはメディアに、もっと自分のことを話題~ニュースソースにしてもらいたい。そうすれば、Facebookへのビジターが一層増えることだろう。

Parse

料金の変更

段階的な料金体系をやめて、一律の無料制を導入し、デベロッパが多く使ったぶんは後から請求がいく。無料の範囲内では、毎秒のAPIリクエストが30まで、ファイルストレージは20GB、データベースストレージも20GB、ファイル転送1TB、プッシュ通知は100万まで。

Why? Parseを多くのデベロッパに使ってもらうために、無料化。デベロッパたちを、このモバイルバックエンドサービスのとりこにしたい。

アクセス分析オフラインストレージ

Parseは分析プロダクトをアップデートして、デベロッパがオーディエンスやユーザ維持率に関してより深いインサイトを持てるようにした。オフラインストレージは、デベロッパがアプリケーションのデータをローカルに保存でき、インターネット接続がない状態でもアプリケーションを動かせる。

Why? Parseをよりロバストにして、安心して有料で利用するデベロッパを増やす。

Internet.orgとオープンソース

Internet.org Innovation Lab

FacebookとEricssonが今回初めてその実装を披露したInternet.orgプロジェクトは、地球上の50億の取り残された人びと全員をインターネットに接続できるようにする。デベロッパは、途上国に多い、遅くて途切れがちな接続の上でも使えるアプリを作れるために、そんなシミュレーション環境でアプリを試験できる。

Why? Internet.orgを、単なるお話で終わらせないこと。Facebookの無人機や衛星などが提供する安価なインターネット接続の上で、自分のアプリがまともに使えることを、デベロッパはテストし、必要なデバッグを行うことができる。

DisplayNode

Facebookが近く提供するオープンソースツールDisplay Nodeは、Paperアプリも使っており、アニメーションのレンダリングがよりスムースにできる。

Why? Facebookのモバイル技術の優秀性を見せつけて、優秀な人材を確保。デベロッパのアプリの改良と成長を支援。DisplayNodeの今後の開発を進めるコミュニティの育成。

今回のローンチの数々に感動しなかった人も、もっとビッグなアップデートを経験するために長く待つ必要はない。これまで、任意の間隔で行われていたf8が、これからは例年行事になる。

毎年恒例の行事になれば、打ち上げパーティーも簡素化され、これまでのように3時間ということはなくなるだろう。今回は、派手なライティングを浴びて真打ちのDiploが登場したころには、彼のDJに合わせて踊る、最後まで残った人びとは、Facebookの社員とボランティアの人たちばかりだった。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Facebookの傘の下に入ったParseが初のデベロッパカンファレンスを開催

【抄訳】

モバイルアプリやWebアプリケーションのバックエンドをいっさい面倒見るというParseが今日(米国時間9/5)、同社初のデベロッパカンファレンスDeveloper Dayを開催して、新しい機能をいくつか発表した。それらは、JavaScriptのタスクをバックグラウンドで動かす、ゲームエンジンUnityとの本格的な提携、画像やユーザセッションの管理方法の改良、Webアプリケーションのサポートをモバイル並に向上、などなどだ。オーナーとして登場したFacebook CEO Mark Zuckerbergは、“いやぁ、あのころParseがあると良かったんだけどねぇ”、と2004年の創業時の苦労を回顧した。

Parseは、モバイルとWeb向けのBaaS(backend-as-a-service)で、4月にFacebookが、同社のプラットホームサービスを強化するために買収した。Parseのサービスは、ユーザ(==デベロッパ)のアプリケーションのデータをクラウドに保存する、認証とログインを扱う、プッシュ通知をアプリに届ける、ユーザのコードをクラウドから展開する、といった基本的なバックエンドジョブだ。ParseはFacebook初の有料B2Bサービスになった。

Facebookが買収した時点では、Parseは6万本のユーザアプリを動かしていた。Facebookが換骨奪胎してしまうのではないか、という 懸念も一部にはあったが、しかし買収後のParseは急成長し、ユーザ数は買収直後の9.4倍になった。アプリの本数は5月に8万、6月に10万となった。モバイル専業でスタートしたParseはその間にWebアプリケーションのホスティングもローンチし、Webアプリケーション単独は言うまでもなく、Webとモバイルアプリの両面展開をしているデベロッパは、データの共有などが非常にやりやすくなった。

ParseのDeveloper Dayはシンプルが売り

Zuckerbergがカンファレンスのキックオフを務め、Facebookの創業時のお話をした。

“親が学費のためにたくわえていた8000ドルが、資金のすべてだった。サーバとルータを酷使するようなものを、作りたかった。誰かが、ルータは中古を買えば安い、と言った。eBayで買ったそいつは、運良く動いた。なんとか、サーバを全部自分で管理できるところまではこぎつけたが、でもバックエンドの面倒な雑務が多すぎて、ソーシャルネットワーキングのイノベーションの足を引っ張った。”

アプリのメインのロジックをやりながら、同時にバックエンドもいじる、という軋轢ないし‘引き裂かれ状態’はParseによってなくなる、と彼は期待を述べた。そして誰もが、“優れたユーザ体験の構築だけに集中できるのだ”。彼によれば、ParseとFacebookの協働により、ユーザのアプリケーション/アプリの構築と成長を助けるツールを作っていきたい、と。

そのあとステージに立ったParseのCEO Ilya Sukharは、今やParseは“数十億のAPI呼び出しと数十億のプッシュ通知を処理し、Parseに接続するデバイスは数億台を数える”、と現況を述べた。

それから彼は、Parseの新機能を紹介した。

  • アクセス分析 – デベロッパは自分のアプリの成長ぶりや、プッシュ通知の有効性、アプリの安定性などの計測値をParseからもらえる。自分でユーザのログインデータなどを分析したり、別途分析サービス(Google Analyticsなど)を利用しなくてもよい。.
  • バックグラウンドジョブ – デベロッパはJavaScriptで小さなコードを書き、瀕用するタスク(メールの送付など)をスケジューリングし、Parseにやらせられる。そのために自分のサーバは必要ないし、Parseの巨大サーバを使った方が速い。
  • Unityとの提携 – Unityゲームエンジンは、iOSとAndroidとWindowsのゲームのグラフィクスの実現のために200万あまりのデベロッパが利用している。提携によって作られたParse Unity SDKにより、デベロッパはUnityによるゲーム構築がより容易になる。
  • ユーザセッションモジュール – 改良されたユーザセッションモジュールにより、ユーザのログイン/ログアウト管理がモバイルアプリとWebアプリケーションで同等となり、とくにWebアプリケーション側での格差が解消した。
  • 画像モジュール – アプリ内の画像処理をParseのクラウド上の最小限のコードで行える。画像をユーザのカメラロールから単に取り出すだけでなく、Parseにトリミングや色調整などをやってもらえる。

【中略】

なぜParseはFacebookにとって重要か

Parseがデベロッパに代わってバックエンドの面倒を引き受けるだけでなく、これからはFacebookにあるソーシャル機能を自分のアプリに組み入れてユーザを増やすことができる(すでにParseはソーシャルログインや共有機能などを統合)。そういう、ParseのFacebook的利用は、Facebookにとってもメリットだ。FacebookにとってParseが世話をしているウン十万というアプリ/アプリケーションは、重要な広告収入源でもある。

Parseのメインはモバイルアプリのバックエンド提供なので、Facebookにとってはアプリ内購入も(その鞘取りが)収入源になる。一方Parse側は、バックエンドのホスティングに加えて、(Facebook自身の)アクセス分析やソーシャルの統合、広告などが、これまでの‘各オペレーティングシステムの低レベル機能だけ’に加えて、新たなサービス資源となる。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Facebookに買収されたParseがモバイルデベロッパ向けのWebホスティングを提供開始

モバイルデベロッパのためのバックエンドサービスParseは、最近Facebookに買収されて、Facebookのデベロッパ向けサービスを担うことになった。そのParseが、このほどホスティングサービスを立ち上げた。それは主に、モバイルデベロッパのWeb進出を助けるためである。買収によってParseの事業は拡大し、同社がホストしているアプリの数は買収の発表以降30%アップの8万となった。

“Parseはモバイルアプリの構築に利用されているが、でもユーザがWeb進出や“.com”URLのランディングページが欲しくなったときには、これまでは、ログインはParseからでもWebサイトはほかのサービス、たとえばHerokuやApp Engineなどからサーブされていた”、Parseの協同ファウンダIlya Sukharはこう説明する。“そこでうち自身が、完全な機能のあるWebホスティングプラットホームを立ち上げることにしたのだ”。

Sukharによると、そのプロジェクトの開発にはこれまでの4ないし6週間を要した。Facebookとの交渉が進んでいるときも、手を休めなかった。

ParseのホスティングでWebページをサーブすると、ページ上に表示されるユーザデータをParseのDataプロダクトから簡単に取り出せる。だからたとえば、モバイル上のゲームのハイスコア表をWebページに表示する、なんてことも容易にできる。

ParseのHostingは、これまでParseが提供していたData, Social, Push(プッシュ通知), Cloud Codeなどのプロダクト群の一環となる〔ParseのWebページ上ではHostingがいちばん最初に紹介される〕。

Sukharによると、Facebookによる買収はデベロッパたちの嫌気や退社を喚起しなかった(買収額は8500万ドル+社員引き留めボーナスと言われている)。Facebookによる買収の発表時には6万だったアプリも、今では8万に増えている。“ユーザや社員がParse離れをする、という説も一部にはあったが、それはなく、今ではすべての数字が上向きだ”、と彼は言う。

Pareseには、Apple、Yahoo、Dropboxなども関心を示していたが、最終的にはFacebookが競り合いに勝った。Facebookにとっては、初めてのB2Bの収益源ができたことになる。またInstagramの場合と同様に、買収企業のチームには最大限の自律性(Facebookからの無干渉)を与え、彼らのプロダクトの成長を期待している。Facebookは、ParseのSaaS方式の収益モデルにも干渉していない*。〔*余計な訳注: SaaSというよりも、むしろPaaS。Parseという社名は、その駄洒落だと思う。何らかのパーサを提供しているわけではないから。〕

Parseはまだ、お祝いパーティーなどをやっていない。“ほかにやるべきことが山のようにあるからね”、と彼は言う。

〔Parse過去記事。〕

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


今、起こりつつあるAPIエコノミーとか何か?

何という2週間だったろうか。しばらくの間くすぶって何かが起こった。API市場が爆発したのだ。IntelはMasheryを1.8億ドル以上で買収し、CAはLayer 7を買収した。3ScaleJavelin Venturesから450万ドルの資金を新たに調達した。MulesoftはProgrammable Webを買収した。そしてついにFacebookもこれに加わりParseを買った。

これらの買収や出資は、アプリケーション界に広がるAPIの遍在によって、ある市場が成熟しつつあることを暗示している。それは決して新しい市場ではない。この分野は過去数年間に構築されたAPIをてこにしてきた企業に埋めつくされている。むしろこれは、変曲点というべきだ。主要APIディレクトリーのProgrammable Webによると、現在APIは3万種以上ある。Javelin Venturesのマネージング・ディレクター、Noah Doyleは私のインタビューに答えて、アナリストらはAPI市場が今後5年間で5~10倍に伸びると予測していると語った。

こうしたAPIの規模拡大によって、魅力あるアプリとAPIを作るデベロッパーにとって好循環が生まれる。APIは分散データネットワークの一部となることによってアプリのリーチを広げる。そのAPIを使う人が多くなるほど、アプリ開発者はより多くのデータを生み出す。データの利用範囲が広がればそのサービスはAPIになる可能性が高まる。

Facebookは、新たなデジタル製品を送り出し続けるために新しいデータの流れを必要としている。Parseのような〈サービスとしてのバックエンド〉プロバイダーは、デベロッパーが基本データタイプや位置情報、写真などを保存するインフラストラクチャーにアクセスするSDKとAPIを提供する。どうやってFacebookがこのデータを利用するかは未だに疑問だ。しかしそれでも、ParseはParseプラットフォーム上でAPIを使用するアプリに育まれた活気ある安定データ源としての役目を果たす。今後このデータをどのようにパッケージ化、セグメント化し、その10億ユーザに対して効果的な広告を送り出すかを決めるのはFacebookだ。

APIは接着剤のようなもの

APIはインターネットの接着剤になる、とProgrammable Webのファウンダー、John Musserは言う。Musserは、Doyleと同じくこれを、モバイル端末の需要から生まれ様々な面で新しいクライアント・サーバーの役割を演じる新しい世代のAPIとして期待している。それらのアプリは、クラウドサービスでホスティングされ、モバイル端末に配信されデータを読み書きし、情報を送受し、API経由で互いにつながりあう。

第一世代では、MasheryやApigeeなどの会社がAPI管理分野の先陣を切った。Twitterをはじめとするウェブ企業が第2世代を形成した。第3の波では、IntelやCAといったエンタープライズ企業がこの大きな動きを察知し、ハードウェアとソフトウェアシステムをつなぐべく市場に参入した。

今やAPIの動きはアプリケーションや機械レベルの下方に向かっているとDoyleは言う。それは〈物体のインターネット〉が出現するレベルにまで来ている。あらゆるものがプログラム可能になり、データの送受信、統合、そして動作のトリガーが可能になる。

3Scaleが提供するAPI管理システムでは、デベロッパーがその上にロジックを作ることできるとDoyleは言う。これを使うとデベロッパーは、あれこれ手を加えることなく、APIにそのままデータセットやサービスを追加できる。

APIエコノミー

この動きの高まりは、Apigeeの戦略担当副社長、Sam Ramjiが提唱に一役買った用語、〈APIエコノミー〉を象徴している。Ramjiは、APIとAPIインフラに注目する人々の数はこの一週間で2倍になったかもしれないとメールに書いた。「APIを持っていない会社のCIOやCTOがニュースを読めば、こう自問するはずだ、『わが社もやらねば』と」

そして、彼らにとってAPIを構築するならMashapeWebshellなどのサービスを使う方が簡単だ。Doyleは、自ら立ち上げたKeyholeが買収された後の3年間をGoogleで過ごした。Googleでは、Google EarthとGoogle Mapsの開発に関わった。

「われわれは地図を軽量なJavaScriptとして公開した」とDoyleは言った。「一種の埋め込みコードのようなものだと考えた。クールですばらしいと思っていたが、あまりの普及の早さにショックを受けた。」

Google Mapsを広く利用されたのは、使いやすかったからだとDoyleは言った。デベロッパーが洗練されたアプリを簡単に作るしくみを組み込んでおくことは、今や最良の慣行だ。

複雑さは避けられない

しかし何もかもが簡単とはいかない。開発が複数のAPIにわたるにつれ複雑さが待ち構えている。MuleSoftはこの穴を、同社のAPIhubで埋めようと考えている。

先週私が書いたように、MuleSoftにとってProgrammable Webとの提携は、同社が〈APIのためのGithub〉と呼ぶAPIhubをProgrammable WebのAPIデータベースと統合し、関連市場でメディアの注目を集めるための好機だ。Programmable Webにとっては、同社のAPIデータベースをMuleSoft APIhubプラットフォームを使ってアプリを開発するコミュニティーへと広げ安定した環境を作り出すことができる。この統合プラットフォームによって、APIの組み込みを容易にしコミュニティーでの協業を促進できると同社は期待している。

アプリケーション・ライフサイクル管理(ALM)のインテグレーター、Tasktop Technologiesは、ソフトウェアのライフサイクル管理プロセスの中で異質なツール群を結び付ける、Software Lifecycle Integration(SLI)というオープンソースの取り組みを開始した。このプロジェクトはオープンソース・プロジェクトのEclipse-Mylynの一部となりM4と呼ばれている。

TasktopのCEO・共同ファウンダー、Mik KerstenはSLIについて、異なるツール間でのリアルタイム同期を可能にする汎用データメッセージバスとして機能し、コードに問題が発生した時にはすぐに対応できる、と評価している。APIエコノミーの発展と共に生まれてくるのが、下支えとなるこうした統合プラットフォームだ。過去2週間にわたる数々の買収と出資は、モバイル機器だけでなくわれわれの生活にある物事ともつながるアプリの開発を真に簡単にするためには、この複雑さを解決する必要があることを示唆している。

[原文へ]

(翻訳:Nob Takahashi)