これまで5回にわたりAPIの概要から利用シーンなどについて紹介しました。最終回となる今回は、API利用が近年急速に普及した経緯を振り返りながら、これからの動向について考察します。
API普及の経緯
APIを利用したサービスが急速に普及している背景には、サービスや製品の作り手から見てもAPIが使いやすくなったことが挙げられます。さまざまなサービスや製品を組み合わせればより便利になることは、前回紹介したスマートスピーカーの例でも明らかです。
一方で、近年まで一般利用者の目に見えるほどに普及しなかったことには、いくつかの理由があります。
一つ目の理由は、API提供方式の違いです。一口にAPIといっても実現する仕様、利用できる環境、制約にはさまざまな種類があります。色々な環境で利用できるように共通化しようとする動きは古くからあり、1990年代にはCORBA(Common Object Request Broker Architecture)、2000年代にはXMLを基礎としたSOAP(Simple Object Access Protocol)や WSDL(Web Services Description Language)などのさまざまな仕様が、OASISのような標準化団体により整備され利用されました。
これらの仕様は多機能で拡張性が高く、信頼性を確保できる仕様です。一方で利用するためには高価なフレームワークが必要になったり、信頼性確保のためには仕様に対する理解が必要となったりすることがあります。仕様策定に長い時間がかかる、製品ごとの実装の違いによりうまく相互利用できないなど、安定した方式を利用できるまでには課題もありました。
こういった経緯もあり、当初これらの仕様が利用されるのは信頼性や厳密性が必須要件で、十分投資できる体力のある政府や企業システムが中心でした。
一方、たとえば天気予報をスマートスピーカーに問い合わせるという利用では、さほど厳密な処理は必要ない場合がほとんどです。「東京の今日の天気は?」と問い合わせた時にうまく答えが得られなかったとしても、もう一度問い合わせれば良いだけです。
同様に、SNSや音楽再生などの一般利用者向けサービスの多くも類似しています。APIで連携した「Twitter」のツイートの投稿に失敗したとしても、再度投稿すればいいですし、投稿に失敗して気付かないままでも何か損失が出るというケースはあまり多くないでしょう。信頼性を高めるメリットがないわけではありませんが、このために利用できる機能や利用回数が制限されたり、利用費用が高額になったりすると、メリットは相殺してしまいます。
前述の利用シーンのように、2000年代中頃からは手続きの厳密性を必要としないサービスを中心として「RESTful API」と呼ばれる、よりシンプルなAPI仕様が普及しました。RESTful APIの普及時期は、OASISなどによる仕様が概ね出揃った時期と重なります。手続きがシンプルになったことでプログラム開発の敷居が比較的低くなり、また処理負荷の低さも普及の一因となって、OASISなどによる仕様とは利用シーンを棲み分ける格好で普及が進みました。信頼性、厳密性を必要とする場合にはOASISなどで定義された仕様、手軽に利用する場合にはRESTful APIといったように使い分けができ、これらを扱うための開発用ツールが整備され、さまざまな目的に合わせて開発者が選択できることは普及に大きく貢献しました。
API普及の二つ目の理由は、クラウドの普及と移行です。アプリケーションが1台のPCだけで利用するものから、クラウドサービスのようにいつでも、どこからでも利用できる環境に移り変わりました。これによりアプリケーション機能の一つだったものが、機能の一つひとつをAPIとして有償、または無償で提供できるようになり、ビジネス上の大きな意味を持つようになりました。
例えば、翻訳アプリケーションだったものがクラウドサービスの翻訳APIとして生まれ変わり、PC1台あたりいくらという方式から翻訳文字数あたりいくらというように、従量課金方式を採用する場合も増えています。従量課金制は利用者視点では初期費用が抑えられ、提供者視点では利用が進めば安定した収入を得ることができるというメリットがあります。
このように、API利用自体がより技術的にも成熟してきたことと、ビジネス視点でも利用者と提供者の双方にメリットがあり、利用が増加しました。利用者が増えれば、APIをさらに活用したロボティックプロセスオートメーション(RPA)やスマートスピーカーのような応用製品も生まれます。このような市場拡大により、いままで公開APIを提供していなかった事業者もAPIを提供する動機が生まれます。API利用を取り巻く環境は雪だるま式に増加しています。