アプリ開発を変えるAPIアグリゲーション・サービス

現在、コンテンツの多くはアプリケーション（以下、アプリ）の形で消費されている。また、そのアプリの多くはマッシュアップ・アプリである。マッシュアップ・アプリの隆盛を支える存在として、アプリ開発者向けにAPI（Application Programming Interface）アグリゲーション・サービスを提供するプレイヤーがいる。しかし、昨今では、アプリ開発者のみならず、専らコンテンツを消費する側だったエンドユーザーが無意識的にAPIを活用して新たな価値を生み出せるスキームが登場してきている。本稿では、新局面を迎えつつあるアプリ開発について考察する。

マッシュアップ・アプリのキーとなるAPI

近年のアプリの多くは、マッシュアップという手法で作られている。マッシュアップとは、複数の要素技術を組み合わせて新しい価値を生み出すことを指す。実際、TechCrunchなどに登場するスタートアップのアプリやサービスはマッシュアップで作られたものが非常に多い。マッシュアップにおいてキーとなるのはAPIで、これが「要素技術」に該当する。アプリ開発者は様々なAPIを利用することで、各APIプロバイダの要素技術を容易に自身のアプリに組み込むことができる。典型的なマッシュアップ用のAPIとしてはGoogle Map API、FacebookのGraph API、TwitterのAPIなどが挙げられる。

しかし、これらに限らず、最近ではますます多くのプレイヤーがAPIを公開するようになっており（図1参照）、アプリ開発者（個人／法人にかかわらず）が独力で利用可能な全てのAPIの存在をキャッチアップし続けることは事実上不可能である。これは状況としては、App StoreやGoogle Playなどのアプリストアが「アプリの海」状態となっており、エンドユーザーがそこにある全てのアプリを吟味し切れないことと似ている（本誌2012年4月号「アプリの終わりの始まり」参照）。

こうした中、利用可能なAPIをアグリゲートし、コンソールを提供するということが有効なサービスとして成り立っている。

【図1】APIの公開件数推移

出典：Programmablewebが2012年11月に公開したデータに情総研にて補足

APIアグリゲーション・サービス

APIアグリゲーション・サービスは、アプリ開発者寄りのバックエンドのものと、エンドユーザー寄りのフロントエンドのものとに分類できる。前者の代表例はApigeeというプレイヤーのサービスで、Google、Facebook、Twitter、Foursquare、LinkedInなどを始めとした多数のAPIをアグリゲートし、アプリの開発・試験環境となるコンソールをアプリ開発者向けに提供している。後者の代表例としてはon{X}やIFTTTなどのサービスが挙げられる。以降では、後者のサービスにフォーカスし、それらの特長や意義について考察していく。

on{X}

on{X}はMicrosoftが2012年6月にベータ版を公開したスマートフォン向けのサービスで、ウェブサイトとAndroid用アプリが用意されている。利用料は無料。Facebookのアカウントでログインする（これ自体がFacebookのAPIを活用することで実現されている）。サービス内容は、トリガー（条件）とアクション（トリガーに連動して発動させたい動作）を定義するというもの。様々なAPIをトリガーとアクションに割り当てることにより、異なる複数のサービス同士を連動させることができる。トリガーとアクションの組み合わせは「レシピ」と呼ばれる。例えば、「気温が華氏50度以下になりそうなら、毎朝8時に天気予報を表示する」というレシピや「職場に着いたら、Wi−Fi機能をオンにする」というレシピがある。レシピはウェブサイト上のコンソールでコーディングすることで作成でき、作成したレシピはユーザー間で共有することができる。on{X}では主にデバイスAPIが利用されている。

【図2】on{X}の概要

出典：on{X}

【図3】on{X}のレシピ例

出典：on{X}

IFTTT

IFTTTはウェブベースのサービスで、名称は“IF This Then That”の略。利用料は無料。サービスの内容や仕組みは基本的にon{X}と同じで、トリガーとアクションを定義するというもの。on{X}と同様、トリガーとアクションの組み合わせを「レシピ」と呼ぶ。例えば、「Facebook上の写真に自分がタグ付けされたら、その写真をDropboxに保存する」というレシピや「Dropboxにファイルを追加したら、Google Driveにも同じファイルを追加する」というレシピがある。また、on{X}と同様、レシピはユーザー間で共有することができる。利用できるAPIはFacebook、Dropbox、Evernote、Instagram、Spotifyなど多数用意されている。IFTTTのレシピの作成にあたっては、各APIのロゴをクリックして選択するだけで済み、直観的かつ容易に操作できるよう設計されている。IFTTTでは主に上記のクラウドサービスのAPIが利用されている。

なお、IFTTTと同様のサービスとしてはzapierというものも存在する。

【図4】IFTTTの概要

出典：IFTTT

【図5】IFTTTのレシピ例

出典：IFTTT

【図6】zapier

出典：zapier

「便利」で「不便」なアプリ利用環境の解消

従来、エンドユーザーが何かをやろうと思ったとき、端末（最近ではその端末の多くがスマートフォンになっている）を能動的に操作し、何らかのアプリを自分で起動させる必要があった。換言すれば、アプリを活用して生活を「便利」あるいは「快適」にするためには、エンドユーザーは自分自身でのアプリ管理（ディスカバリ、試用、ダウンロード／インストール、利用、アップデート、アンインストールといった一連の作業を含む）という「不便」あるいは「面倒」を代償として甘受しなければならなかった。つまり、アプリ利用の文脈では、「便利／快適」と「不便／面倒」は表裏一体の関係にあった。

しかし、本稿で紹介したサービスはこうした関係を断ち切る方法論を示唆している。しかも、エンドユーザーが開発者のように振る舞える形で、である。重要なポイントは、アプリ管理にかかるエンドユーザーへの負担を緩和することである。そうすることにより、「不便／面倒」の部分が劇的に減少し、「便利／快適」の部分との平衡状態が解消される。on{X}やIFTTTでは、レシピの内容に従い、特定の条件が揃った段階で何らかの動作が自動的に発動する。つまり、クラウド側がエンドユーザーのコンテクストを認識／理解し、必要なサービスをプッシュしてくる。これがエンドユーザーのアプリ管理にかかる負担を軽減する効果をもたらす。

アプリ開発は開発者だけのタスクではない

on{X}やIFTTTについては、月並みな表現ではクラウドベースのAPIアグリゲーション・サービスとなるが、それら自体が多数のプレイヤーの提供するAPIのユーザーになっているとも言える点で一面的なサービスではない。つまり、これらのサービス上でレシピを考案するエンドユーザーは別の新しいサービス（価値）の開発者になっているとも言える。したがって、on{X}やIFTTTの本質は、開発者とエンドユーザーの境界を曖昧化し、ウェブサービスの「プロシューマー（prosumer）」を生み出すということにある。

純粋なアプリ開発者向けのサービスを提供するApigeeのコンソールがCUI（Character-based User Interface）的であるのに対し、特にIFTTTやzapierは高度にGUI（Graphical User Interface）的なコンソールを備えていると言える。そのため、コーディングに関する知識を全く持っていなくても、斬新なアイディアをプログラムしてサービス化することができる。実際、on{X}やIFTTTのサービス内容は、コードとしては単純だが、様々なAPIを組み合わせ、ある条件下で特定の動作が実行されるように制御するIFステートメントを書くことそのものである。高度にGUI的なコンソールによって、ユーザーにそれを意識させていないだけである。これはマッシュアップの手法でアプリを開発するプロセスに他ならない。

エンドユーザーはこれまで、市場からアプリを提供され、コンテンツを消費する一方の受動的な立場であり続けてきた。しかし、潮目は変わりつつある。今後、アプリ開発は開発者だけが担うタスクではなく、市場全体で取り組む共同プロジェクトになっていくのではないだろうか。

小川 敦