アプリケーション・プログラミング・インターフェース、またはAPIは、システムやプログラムが互いにやり取りをする方法のひとつである。システムが違えば、データの保存やプロセスの方法も違う。それを、データの入手において、誰もが利用できる指示書のついたAPIを使うことで、このデータやサービスが元となる、他のシステムとの共同運用性や将来性が格段に高くなる。

我々のビジネスが、有料APIを通したサービスであるということを受け、日本の休暇であるこの期間を利用して、APIマーケットに関して調査し、考えたことをここに記したい。

APIの歴史

APIには、とても 長い歴史がある。

“APIの概念というのは、Webは言うまでもなく、PCよりも以前でさえ、存在していました。 とても古い時代からあるのです！ 誰もが見つけられる「入口」となるべく詳細な記述が、あるアプリケーションが他のシステ ムと相互に作用するという定義は、ユーティリティ・データ・プロセッシングの時代より、ソフトウェアの開発における必要不可欠なポイントであったからです。 しかしながら、世に出たシステムやWEBそのものは、この重要性や同じ基本概念を持ったユーティリティが劇的に増加するのを目のあたりにすることとなったのです。” ーマーティン・バートレット¹

APIは、多数の違ったデータやサービスを混ぜて併せて、さらに有効な製品を作り出し、自らの利用者へのサービスに集中できるよう、開発者を活力付ける、革新の源なのだ。

至る所でPCやインターネットを使い、この技術を使える多くの開発者の存在により、標準WEBプロトコルや開発ツールで使うことのできるAPIを通じたデータやサービスの共有は、今やさらに簡単になっている、と言えるだろう。

APIの成長

2000年2月7日 IDG デモカンファレンスにて、Salesforce.com が完全公開APIをリリース これが、ウェブAPI市場の引き金となった。

アート・アンソニーは、”ブログ：API経済の成長を追って” ² で、2006年には、取るに足らなかった公用APIの数が、2016年には15,000になったとしている。 今日、ProgrammableWebでは、17,000を超える、APIが利用可能だ。

サーバー側のWebAPIだけではない。ブラウザ・エクステンション・プラグイン等のような、クライアントサイドのAPIも同様だ。

今や、あなたの想像の数だけ、データやサービスタイプのAPIが存在する。幾つか例を上げてみよう。

ソーシャル系

2003年に設立された、Del.icio.us は、ウェブ上でブックマークをシェアできるサービスである。これは、ウェブ上で情報を求める標準的な方法をどのようにして、情報取得のためのシンプルにプログラムできるインターフェースへとつないでいくかという良い一例だ。

もちろん、Facebookも忘れてはならない。Facebookは開発者用プラットフォームを2006年8月にリリースした。これは、XMLレスポンスを含むREstウェブAPIで、当時良く用いられていたウェブAPIのパターンに準じている。

マップ系

Google Mapは、地図上に情報を表示するサービスに投機を行っていたアプリに、半ば押されるような形で、2006年6月に始まった。このAPIでは開発者が自分のウェブサイト上で、特定のデータを地図上に表示して載せることができる。

エンタメ系

Netflixでは自社APIでひと月あたり200億にも昇るリクエストを処理している。³このAPIは、コンテンツを楽しむプラットフォームに紐付いた全てのデバイスに対応している。開発者の観点から言うと、Netflixがいかにして自社APIへの需要量と、増加を続ける負荷に対応できるような調整を行っているのか、研究の価値ありだと思う。

サービスとしてのインフラープラットフォーム

2007年、Twilioは開発者が電話をかけたり受けたり出来る、製品としてのAPI プラットフォームを開始した。2008年にはAPIがスタート⁴ 、2010年にはTwilioがテキストメッセージ（SMS）機能を追加した。

AmazonのAWSは、言わずと知れた、巨大インフラプラットフォームである。構成要素の中には、S3（ストレージ・プラットフォーム）やEC2（コンピューティング・プラットフォーム）がある。ウェブインターフェースの公開以前でも、APIを通じてその機能へアクセスができた。S3に関して言えば、Amazonは、開発者へAPIを通じたファイルの持ち込みを可能とし、保管したデータ量のみをひと月ごとに課金する。現在我々が「クラウド・コンピューティング」とするものを、Amazonは2006年にS3と新型課金スタイルとして打ち出していたのだ。

アプリづくりに必要なサービスやデータを提供する、千にも万にも昇るAPIは、開発者の目指すところへの道のりを助けるための、ありあまる選択肢となっている。

収益体系

有料公開APIは、珍しくない。大きく分けて、APIがビジネスの収益となる得る、4つのタイプの収益体系がある。⁵

無料タイプ

例えばFacebookの開発者用プラットフォームは、無料のAPIだ。APIへのアクセス、使用が無料となっていて、Facebookへより多くのコンテンツを追加することができる。Facebook側では、そのコンテンツの増加により、より多くのプラットフォーム・ユーザーを獲得し広告料を得る仕組みだ。

開発者課金タイプ

このモデルは、APIを使うユーザーが支払うという、とても率直なタイプだ。Xoxzoのクラウド・テレフォニー・プラットフォームや、AmazonのAWS APIが例に挙げられる。ペイパルも、APIを利用し売上が上がった時にその一部が収益となるという点で、このモデルに入るといえるだろう。

開発者収益タイプ

Google AdSenseやAmazon アフィリエイツなどが、このモデルの例である。Amazonでの商品を販売しているビジネスや、AdSenseの場合であれば広告主が、それぞれの収入源から収益を上げるている傍ら、開発者も収益を上げるのだ。収益の割合などは多くの場合設定されている。

Expediaはビジネスの90%がAPIを通じたものであるというが、年間約20億ドルのビジネスはアフィリエイトネットワークによるものだという。

間接タイプ

eBayのオープンプラットフォームに作られた第三者アプリケーションや、第３者ツイッタークライアントが間接モデルの例に挙げられる。この２つの例は、ビジネスがコンテンツを獲得していく方法であり、主たるビジネスにおいて、より良いユーザーエクスペリエンスへとつながる。

ニューヨーク・タイムズではコンテンツ・シンジケーションにAPIを用いているので、訪問者を主たるサイトへと牽引し、自社の購読料という広告収入を得ることが出来る。

この間接タイプと先述の無料タイプの境目は紙一重かと思う。というのも、どちらも基本的にユーザーにとっては「無料」で使えるからだ。自らのビジネスのために、自分が持っている根底にある収益体系次第、ということだと思う。この場合、APIは、本流のビジネスへと流れ込む、追加ファネルのように考えられるだろう。

日本では…

日本では、ITRによると2015年のAPI市場の収益は前年2014年を80%上回ったとし、2015年から2020年までのAPI市場の成長見通しを、平均で41%増、2020年の収益は2015年を大きく上回り、5.6倍になるだろうと発表している。⁶

ITRはこの増加の理由として大企業による迅速な運営という後押しがある、と指摘している。しかし、日本市場に限ってみると、ここで言うAPIは公開のものではなく、パートナー限定公開のAPIのようだ。

日本での居住経験が長く、Tech Industryへもコメントしている、テリーロイド（Terrie Lloyd）は違った考えのようだ。APIが広く利用されている海外の国々と違い、中小企業におけるテクノロジーへの壁については言うまでもなく、国内ビジネスや、企業の関係、内部データを統括する独特の性質により、APIの公開の広がりは、他の国々ほどの速度は見込めないだろうと考えている。⁷

私自身は、日本の企業が開発者向けにアクセス可能な公開APIを提供するのも、時間の問題だと思っている。ビジネスモデルと言う観点から言うと、開発者に直接、利用した量の課金を行うTwilioの例とは違ったものになるだろうが、ビジネスそのものが関係をコントロールできるだけの強さがあれば、間接的であったり、パートナー契約等になるだろうと考えている。

まとめ

API経済と市場は、クラウドコンピューティングの手軽なリソースとして、より多くの「リアルタイム」データを必要とするモバイル・デバイスの増加、そしてウェブテクノロジーを使い働くエンジニアの増加等に誘引され、今後も成長を続けるだろう。さらなる効率性、市場へ出すまでの時間短縮の必要性もまた、APIの成長を後押しする要因となるだろう。

ビッグデータ処理や人工知能と言った新規産業は、こういった機能からデータをとる必要があり、また、そのデータは公開APIにより取得可能となるのだ。

APIによるビジネスモデルは、とても率直で、（XoxzoやExpediaがそうであるように）主要な収益を打ち出していったり、（eBayのように）間接的なところで、コンテンツを入手するようになり得る。どちらの場合も、APIのビジネス面では、具体的かつ包括的な戦略がまだ必要であるし、「副業」のようにできるものではない。

しかし、APIには終わりはない。成長すれば、実際に使われているデータを使う人や、使われ方により、より精巧に扱える基盤が必要となるのだ。⁸