「API」と「APIエコノミー」 #1「API」の用法と活用事例

データ流通ことはじめバナー画像こんにちは。本連載では、データ流通市場に関連する用語や、業界動向を解説しています。今回のテーマは「APIエコノミー（経済圏）」です。

APIサービスが普及し、企業によるデータ流通が簡単になって、新しい経済圏を生み出しそうだと注目されています。数十年前からある技術が、簡単に使える支援サービスの普及に伴って、新ビジネスの企画・開発に便利だと思われ始めているのです。つまり、機械やひとが気軽にデータを売買できる時代の始まりです。

ふたたび集まる「API」への注目

「APIエコノミー（経済圏）」という言葉は耳慣れないという方もおられるかもしれませんが、一説には260兆円市場に成長するともいわれる分野です。米国ではAPIマネジメント企業の買収が相次ぎました。求人情報サイトindeed.comによれば、APIエンジニアの平均年収は約10.2万ドルにまで達しています。

データ産業の成長につれて対象領域は広がり、企業による大規模データ（Big Data）の第三者提供、産学官民の垣根を越えた共同研究（Open Innovation）、金融サービスの革新（FinTech）や公共機関の情報受発信（Open Government）、学術論文・図書館情報のオープン化（Data Sharing）、製造系企業のデータ流通の効率化（IoT）、エンジニア達のライフハック（Mash Up）など多岐に渡ります。機械学習（AI, 人工知能）のアルゴリズムをAPIで提供する企業も増えて来ました。

もっともシステム開発の当事者たちにとっては、さほど目新しい話題ではないようです。90年代にはすでに用例が見られます。00年代には「Web API」と言って、Webサービス企業が自社のAPIをネット上に公開することが流行しました。そして再び、北米では2010年頃、日本でも2013年頃から、新たに「APIエコノミー」と呼ばれて注目を集めているのです。何が起きているのでしょうか。どんな企業がどんなサービスを手掛け、どんな技術を持ち、どんなデータを公開しているのでしょうか？

そもそも、APIって？

API（Application Programming Interface）とは、コンピュータ・プログラムの開発者が、自作したプログラムを他の開発者に使ってもらうときの「手続き・使い方・決まり」の総称です。プログラム自体を指すことも、その開発文書のことを指すことも、プログラムの設計理念を指すこともあります。どうにも抽象的な用語ですが、スマートフォンのアプリ操作にも当たり前に使われる技術です。

「ぐるなび」や「食べログ」で行きたいお店を探すとき、所在地を確認するために、わざわざ別のブラウザで地図を検索したりはしないでしょう。グルメサイトの画面内で「地図」メニューを開けば、そこにはGoogle Mapの地図が表示されますし、現在地からの道順も簡単に検索できます。

でもこの地図、もちろんグルメサイトが作成したものではありません。地図情報はGoogleが提供しています。グルメサイトは提供されたデータを表示するだけです。このようにAPIサービスは、あるアプリが他のアプリの機能を呼び出す「代理」をしてくれます。簡単に図示しましょう。

図 1：APIを通じたサービス連携とデータ流通

あなたが端末を操作すると、それがアプリへのリクエスト（指示）になります。リクエストを受けたアプリは、前もって連携していた外部サービスのWeb APIを探し、コール（呼び出し）します。呼び出されたWeb APIはそのリクエストに応答して、保有する機能・コンテンツでレスポンス（応答）します。応答の仕方は様々で、新着情報を届けたり、データベースを検索したり、計算処理したり、受け取ったデータを蓄積したりします。HEAD、 GET、 POST、 PUT、 PATCH、 DELETEといった命令文が使われます。

一連の手続きを自動化することで、グルメサイトは自社で地図データを買い揃えずに済みます。Googleは利用者に、地図情報の表示方法をいちいち説明しなくて済みます。Googleに地図情報を販売する会社にとっても、多くの企業に自社データを売り歩く手間が省けます。そしてあなたは旅先で外出するたびに、大きくてかさばる紙の地図を買わずに済むというわけです。

分野別のAPI活用事例

APIは、開発者にとっても助かる仕組みです。たとえ有料でも出来合いのプログラムを使わせてもらったほうが、自分でいちから関連文書を読み、コードを書き、きちんと動くか確かめなくても済むのですから。

この「書かずに／読まずに済ませる」ことが、API設計の基本的な考え方です。その簡単さから、今では無数の企業・組織がAPIの設計と公開を手がけるようになりました。

オープンAPIの検索サービスProgrammable WebのCEOニコラス・シエッロは、2015年1月にズーリッチで行われたAPIカンファレンスの発表で、「2005年から2015年にかけて、同社サイトで検索できるWeb APIが1件から10,302件に増えた」とする統計資料を発表しています。

きっとあなたも（知らないうちに）APIを利用したことがあるはずです。少し調べるだけでも、セクターごとに数々の先行事例が見つけられるでしょう。国内外の主だった事例を表にまとめてみました。APIを用いたデータ流通が、それぞれの産業界で「当たり前のこと」になりつつあるのです。

表 1：分野別のAPI活用事例（サービス連携、データ流通、標準化・他）

「API」という用語の系譜

もっとも、APIという用語は新しいものではありません。日本でも1989年には、すでにこの表現が使われています。マイクロソフトやパソコンメーカー、SIerが、32ビットパソコンの動作仕様の共通化に合意したときのことです。当時の主流OS「OS/2」とアプリケーション間のやり取りに関して、文字コード体系やかな変換方法、画面表示インターフェイス、マウスやキーボードなどの仕様が定められました。

この頃はまだ、「API」は同業者向けの「規約」として理解されていました。この伝統的な用例に従うなら、APIは例えば、「複数のアプリケーション等を接続（連携）するために必要なプログラムを定めた規約」 [高度情報通信ネットワーク社会推進戦略本部（ＩＴ総合戦略本部） , 2016]と説明されます。

システムとしての「API」

やがて90年代に入ると、外部の情報サービスと社内システムのデータ連携が盛んに行われるようになりました。例えば新聞社がデータ・プロバイダとして、ニュース記事や経済指標、企業情報などのデータベースを企業に提供し始めます。1984年にサービス開始した「日経テレコム（現：日経テレコン）」も、初めはインフォプロ、ライブラリアンら専門家を中心としたユーザ向けの検索サービスでしたが、90年代初頭から調査部門以外の利用が進みます（エンドユーザコンピューティング）。パソコンの値下がりとイントラネット普及がこれを後押しし、97年「日経テレコン21」発売時には、個々の企業は共通化された手続きに沿って、「日経テレコン」から最新のニュースクリップを自動取得し、企業内LANシステム上で自動更新できるようになりました（AutoCLIP機能）。これも、システムとしてのAPIの先駆けといえそうです。
ここでは「API」が、データ通信のための「規約」にとどまらず、第三者から提供されるコンテンツやサービス、機能そのものまで含む「システム」として理解されています。用例でいえば、「Web APIs are a system of machine-to-machine interaction over a network. Web APIs involve the transfer of data , but not a user interface」 [White House, 2012]とか、「国会会議録検索システムに登録されているデータを検索し、取得するための外部提供インターフェイス」 [国立国会図書館, 2014]といった記述が好例でしょう。

ビジネスプロセスとしての「WEB API」

00年代に入ると、さらにインターネットが普及するにつれて、APIをWebで公開する企業が脚光を浴びました。2000年にはeBayやSalesforce.comのAPIが、2003年にはAmazonのProduct Advertising APIが公開されます。そして2005年にGoogleとYahoo!が、2006年にはTwitterがAPIを公開。多くのIT企業がこの流れに続いたことで、誰もがアクセスできる「Web API」は、エンジニアたちの市民権を一挙に得ました。

企業が基本無料で自社APIを一般公開することは、インターネットの初期理念のひとつ「オープン・フリー・シェア」の考え方とも合致していたからです。口コミの自然増殖とロックイン効果、マーケティング費用の抑制を狙って、とにかく多くのユーザに自社サービスを体験させたい企業にとって、その宣伝役となりうる開発者たちに自由な遊び場を提供するのは自然なことでした。このトレンドは世界中で多くの交流を生み出しました。当時、Apigee戦略担当副社長だったサム・ラムジが、2010年に「Open API Economy Meet up」を立ち上げたことが象徴的です。

例えば、エンジニア個人が腕試しに、複数のWeb APIを組み合わせたWebサービスを作り（Mash Up）、ホームページや個人ブログで公開する。それが話題を呼び、ベンチャー企業の設立にまで至る。優秀な学生を雇用したい企業がハッカソンを主催する。API利用の手ほどきを書いた投稿記事が、開発者たちの間で人気を集める。それがきっかけになって、担当者間の付き合いが始まり、新しい企画の芽になる――。

ここに至って「API」は、情報産業における「プロセスそのもの」を指す語にまで育っています。より詳しい歴史を知るには、地図APIの料理本（と称する）「Map Scripting 101」の著者アダム・デュバンダーが、2011年に作成した「Open API Growth: a Visualization」が便利です。

用例を見ても、「企業にとってより重要な関心事項となっている、オムニチャネル・ソリューションの構築、競合企業よりも迅速なイノベーションを推進すること、モバイル型企業への転換、ハイブリッド・クラウド環境で事業を運営すること、これらの全ての施策、そしてその先を実現するための根本的な要素」 [Jensen, 2016]だとか、「important tools for providing access to data and capabilities beyond the firewall」 [IBM institute for Business Value, 2016]といった記述には、APIに寄せられた期待が溢れます。

共通語としての「API」

すでに各業界や国際団体で、API文書の記述仕様を標準化する動きがあります。使いやすいAPIは、読みやすい書式で書かれます。関係者が各々独自のやり方を押し通していたら、せっかくAPIを提供しても、お互いに扱いづらいばかりか、得てしてまともに使われないからです。

よく知られた例では、Swagger、API BlueprintなどのAPI文書の作成ツール・コミュニティが標準仕様の開発を進めており、2016年11月には、Linux Foundationが中心となり、Microsoft、 Google、 IBMらが参加して、RESTful APIの書き方を標準化する団体Open API Initiativeが立ち上がりました。Swaggerを改称したもので、公的性質の色濃い団体となることへの期待と不安が語られています。

業界別にみても、Webサービスやデータベース、ECサイトなどが先行していましたが、スマートハウス関連データ（HEMSデータ利活用事業者間API標準仕様書）、VR端末（クロノス・グループ）、電子カルテ（日医標準レセプトソフトAPI）、生体認証（FIDO2.0）など各分野でもAPI仕様標準化の動きがあり、多くの仕様書がウェブ技術の標準化団体W3Cに提案されています。

成長著しいFinTech（情報技術による金融業の刷新）の分野でも、金融機関の口座情報に関するAPI仕様や認証システムの標準化がいよいよ始まりました。日本IBMが金融機関向けに「Fintech共通API」の提供を始めたほか、野村総合研究所「IT Solution Frontier」所収「金融分野のAPIエコノミー -オープンAPIが生み出す革新的なサービス-」 [遠藤圭介・高橋寛, 2016] によると、米国「FS-ISAC」が「Durable Data API」の開発に取り組み始めました。日本でも同所等が運営する「OpenIDファウンデーション・ジャパン」が「Financial API Working Group」を設け、検討を始めているとのこと。また金融庁では、2016年7月28日からフィンテックの法整備へ向けた金融審議会「金融制度ワーキング・グループ」を開催。同審議会では「決済高度化のためのアクションプラン」を提示し、「決済における中間的業者」の取扱いをめぐってオープンAPIをめぐる状況と課題を検討。これを受けて全国銀行協会が10月28日に「オープンAPIのあり方に関する検討会」を設置。正会員向けのアンケート調査など国内事業者の対応状況を踏まえて、仕様の標準化、セキュリティ原則、利用者保護原則、法制度面での課題などを検討したうえで、2016年度中に取りまとめを行うとしています。

国家戦略としての「API」

こうした動きは、国内外で産学官民を問わず加速しています。先進各国の政府が、データの国際流通を活発にしようと、様々な障壁を取り除こうと働きかけているためです。米国政府が、2012年3月23日に発表した電子政府戦略「Digital Government: Building A 21st Century Platform to Better Serve the American People」*1を読んでみましょう。そこでは次の4原則が掲げられています。

情報本位（Information-Centric）
共有の場（Shared Platform）
顧客本位（Customer-Centric）
安全と安心（Security and Privacy）

このうち「情報本位（Information-Centric）」の章では次の通り明言され、実際にGSA(General Services Administration米連邦政府一般調達局)が、政府機関のAPI対応を支援しています。 [White House, 2012]

Make Open Data, Content, and Web APIs the New Default
Make Existing High-Value Data and Content Available through Web APIs

日本では内閣府IT情報戦略室が、「世界最先端IT国家創造宣言」を作成し、データ流通基盤の普及や利活用に向けた方針と工程表を年次で改定しています(2013年6月14日決定、2016年5月20日改定)。2016年には「情報銀行」などへの言及が話題になりましたが、当初は「手段」として言及されたAPIの「活用」に着目した記述が増えていることにも注目です。

行政分野ではさらに、データの「構造」も共通化しようとの流れがあります。「共通語彙基盤整備事業」といって、行政機関が用いる「語彙」（データに使われる用語の意味内容や項目、構造など）を統一する事業が展開され、無料の変換ツールの開発も進んでいます（2017年度に公開予定）。その成果は経済産業省「法人ポータル(β版)」*2や総務省「統計LOD」、京都市、北海道森町などの自治体に採用されており、新たに作成するデータを県や近隣自治体のグループなどの単位などで統一する試みもスタートしています。

米国でも越境交流が盛んです。飲食店の口コミサービス「Yelp」は2012年に、行政機関が持つ飲食店の衛生検査データを自社サイトに集約しようと、オープンデータ標準「LIVES」を開発しました。「Code for America」の支援を受けて開発が進められ、米国各地から17の地方自治体が参加しています（2016年9月現在）。またYelp自身も、クラウド事業者Socrataが主宰する「Open Data Network」に参加して、LIVESのデータを他の参加者に開放しています。