APIエコシステムへの船出

高橋規生株式会社日立コンサルティング　マネージャー

2020年1月9日

１．APIエコシステムの「海図」

デジタル・トランスフォーメーション(DX)時代において、インターネットで提供される各種サービスはAPI(Application Programming Interface)の利用が常態になりつつある。APIは各種サービスをインターネットを介して提供するためのプログラムの「窓口」である。スマートフォンのアプリケーションから企業・公共機関が提供するAPIへ機械的に接続して情報を取得したり、商品の注文をするといったことが、典型的な利用方法になる。

APIが登場するまでのインターネットサービス提供は、基本的にWWW(World Wide Web)を利用してWebブラウザのクライアントからWebサーバーへリクエスト(要求)を送信し、サーバーがリクエストに応じたレスポンス(回答)を返送することで実行されてきた。例えばインターネットショッピングサービスでは、ユーザーがブラウザを用いて欲しい商品情報をサーバーからダウンロード・表示し、商品購入要求をサーバーへ送付することで、Webサーバーによる商品販売のサービスを実施してきたのである。
しかし、WWWはサーバーに蓄積されたデータ・テキスト・画像・コンテンツから、ユーザーがクライアントで必要なものを検索してダウンロード、【表示して視認】することを想定して規格化されており、あくまでも人間が情報を収集するための仕組みである。そのため、プログラム同士が情報をやり取りし自律的に動作するためには不都合な部分が多かった。サーバー・クライアント間の通信方法(HTTP)において、有効な動作が「取得(GET)」「送付(POST)」の２種類しか規定されておらず、多様な処理に耐えられるものではなかったのである。

上記のような状況でも、膨大な数量のインターネットサービスが利用・提供できてきたのは、「取得(GET)」「送付(POST)」でやりとりされるデータ本体(電文)の中に詳細なリクエスト情報(提供してもらいたいサービスの名称、そのために必要なデータなど)や結果情報(サービスの実行結果)を書き込んでいたからである。こうすることで、詳細な情報をやり取りすることができ、高度な処理が可能となっていた。

ところが、データ本体に書き込まれるサービス情報の書き方は、サービス提供者が独自に決めているため、提供されている無数のサービスの数だけ「書き方」が方言のように存在することになり、それぞれに合わせてプログラムを作成する必要が発生してしまった。特に、異なるサービス提供者のサービスを同時に利用する場合にはそれぞれに合わせたプログラムを作成する必要があるため開発負荷が高く、サービスサイト連動(マッシュアップ)や企業間連携(システム連携)の実現を阻害してきた。

APIは、上記の問題を解決すべく、サービス定義(サービスを要求するためのデータの書き方)を統一的に規定し、どんなサービスでも統一した方法で利用できるようにすることを目的とした技術である。

それでは、APIはどのような使われ方をするものなのであろうか？元々の存在理由は、プログラム同士が通信を行うための標準仕様であるので、システム間通信に利用されることが大前提となる。しかし、企業などの内部システムは基本的に企業内部の標準化方針に従っており、わざわざ技術標準を導入する必要はあまりなく、むしろ企業のルールに特化した仕様(企業内独自用語、業界用語のサポートなど)へ制限をかけるガバナンスを行う必要がある。よって、APIがその真価を発揮するのは、企業間や業界横断の通信を行う場合であり、業界標準や業界間規約を定義する手段として有効になる。

金融業界におけるAPIエコシステム

図は、金融業界におけるAPIの利用形態（=エコシステム）を示している。APIの提供者としては、銀行やクレジットカード会社、証券会社、保険会社などが存在する。それぞれがお金を扱う企業であり、顧客・消費者に向けて以下のサービスをAPIで提供することが可能である。

(1)「公開情報」:契約者でなくても閲覧できる情報
(2)「契約者取引情報」:契約者が個人的に実施した取引結果の情報
(3)「金融機能」:金融機関が提供する金融サービス

これらの機能を各企業が単独でサービス提供することが可能であるが、契約者が取引する複数の金融機関から自動的に複数のサービスをAPIにより利用することで、より効率的・効果的な金融取引が可能となる。

現時点で実現している金融機関系APIを利用したサービスとして、家計簿アプリがある。これは、契約者が取引している複数の金融機関口座の「契約者取引情報」を収集し、まとめることで資産の一元管理を可能とするものである。それ以外にも、例えばクレジットカードの決済を複数の金融機関から実施したり、証券の値動きに対して複数の金融機関口座から資金を集めて投資するなどの取引が考えられる。
APIを利用するクライアントの仕組みとしては、専用のスマホアプリを開発する方法や、利用サイトを構築してWebブラウザから利用する方法、個別業務システムから一部機能をAPI通信で利用する方法が考えられる。それぞれ、利用者のニーズに合わせて選択が可能となっている。

異なる領域のシステム連携を実現するAPI

企業間だけでなく、異なるシステム領域の連携を実現するためにAPIが用いられる。前稿で述べたとおり、クラウドをベースとしたDXシステムは役割、特性が異なる「SoE」「SoR」「SoI」というシステム領域に分類される。SoE領域のシステムは品質よりも迅速なリリースを重視する特性を持ち、SoR領域のシステムは品質の高さで正確な企業業務をサポートする特性を持つ。SoI領域のシステムは常に新しい分析手法を試行できる必要があり、分析手法の多様化に対応できるだけの大量のデータを常に保持していなくてはならない。このように全く異なるシステム間では、できるかぎり手段に依存しない、疎結合なAPIでの連携が好都合である。特に技術の変遷が速いSoE領域では、変化が少なく改修に時間がかかるSoR領域のシステムの対応が不要で、機能の一部のみを手軽に利用できるAPIはうってつけの連携手段となる。
具体的には、口座照会APIや金融取引サービスAPIを利用するアプリをオムニチャネルで展開する場合に、スマホや営業店端末など、SoEサービスシステムの刷新に合わせてSoRシステムの改修が発生してしまうと、サービスのリリースが大幅に遅延する。すると、完成した頃には新しいデバイスが流行しているため、ビジネスチャンスを大きく逃すだけでなく、せっかく完成したSoEシステムがリリース時に既に陳腐化してしまう可能性もある。

２．APIを乗り切るための「ガレー船」

それでは、APIを適用したシステムを構築するためには、どのような手段を用いればよいのだろうか？
APIはインターフェースなので、API利用システムとAPI提供システムが存在する。API利用システムは利用したいAPIに特化したクライアントプログラムを作成し、そのプログラムを呼び出すことで、インターネット上に公開されているAPIを利用することができる。API提供システムは提供したい機能を持った既存システムに、API機能を付加することで構築することができる。その機能は一般的にAPI基盤と呼ばれるソフトウエアで提供される。

(1)API基盤

APIで機能を外部提供する場合にそのシステムを新規に開発することはまれである。APIは迅速なシステム連携を実現するための機能なので、既存システムで提供すべき機能が実装されているならば、その機能を利用することが望ましい。その理念に基づき、既存機能をAPIとして外部公開するために必要な機能を提供するソフトウエアがAPI基盤である。

①: API接続機能(機能要件)
インターフェース定義言語を規定し、その言語で書かれたAPIの定義(API名、入力データ、出力データ、接続先物理名、など)を入力するとクライアントとサーバーのソースコードを自動生成する機能を提供する。APIサーバー機能を提供し、上記ソースコードを組み込んだクライアントからAPIリクエスト通信を受信し、設定された既存システムの機能を呼びだす処理を行う。
②: セキュリティ機能(非機能要件)
既存の内部システムを外部に公開する際に必要となるセキュリティを強化する機能を提供する。
標準となっているOAuth2.0の認証機能を用いて、既存システムアクセスコントロールを行う。
③: 流量管理機能(非機能要件)
外部から利用されるAPIは内部機能と異なり、流量予測がしづらく突発的な大量アクセスにさらされる場合がある。その際にアクセスを遮断し、API提供システムのダウンを回避する制御を行う機能を提供する。
④: API公開機能(機能要件)
利用者へAPIの情報を提供し、APIサービスの開始・終了を管理する機能を提供する。利用者が接続可能なAPIを検索し、接続のための情報(API定義)をダウンロード可能とする。
⑤: 課金機能(機能要件)：オプション
API利用実態に合わせて、利用者へ課金計算を実施する機能を提供する。一般的なAPI基盤の機能には含まないが、APIを有償でサービス提供する場合には必ず利用される。

(2)API内部構成

既存システムに外部向けインターフェースを付加してAPIとするということは、APIが内部構成を持つということになる。一般的に外部へ直接公開されるAPIを(1)外部API、既存システムが内部的に提供するAPIを(4)内部APIと呼ぶ。さらに、業務上の単位で内部APIを連携させる(3)API連携基盤、内部APIを外部から使いやすいように纏める機能を(2)API管理基盤(マイクロサービス)が存在する。

API内部構成(例)

①: 外部API
外部の利用者から利用可能なAPI。外部利用可能な形に制限されたサービスを提供する。インターネットから直接接続可能なインターフェースであるため、API管理基盤によりセキュリティ機能や検索機能が提供される。
②: API管理基盤(マイクロサービス)
内部APIを組み合わせて、外部利用者が使いやすい単位、提供者が管理しやすい機能範囲(粒度)の外部APIを構成する機能。具体的には、本来のサービス機能と同時に顧客管理を実施したり、取引管理と口座管理を同時に実施するなど、複数内部APIを連続して呼び出すことで実現する。APIの組み合わせで構成されるAPIをマイクロサービスと呼ぶ。
また、外部APIのアクセスを管理する機能を提供する。この機能は前節におけるソフトウエア「API基盤」が提供する、セキュリティ機能、流量管理機、API公開機能、課金機能である。
③: API連携基盤
内部APIを外部APIや内部の他システムから利用可能とする基盤。組織内部のシステム間連携に利用される。内部通信形式(http,MQ,FTPなど)のインターフェースを標準APIへ変換したり、細かすぎるAPIを利用可能な単位へ束ねたり、システム間トランザクション管理を行う。
④: 内部API
内部の既存システムが提供するインターフェース。システムのアーキテクチャによりAPI標準形式でない内部通信形式(http,MQ,FTPなど)インターフェースが提供される場合がある。

３．API実現への「羅針盤」

(1)APIの要件検討

APIを活用したシステムを開発するためには、どの様な検討を行う必要があるのであろうか？
APIの設計・開発の実施に関しては、API基盤などのソフトウエア、開発環境の充実が目覚ましく、実施方法が比較的確立されている。しかし、その前工程であるAPIの企画、要件定義の実施は容易ではないと考えられる。それは、明確なニーズベースの要件がないからに他ならない。組織内のシステムであれば、既存の業務や既存システムが存在するので、それに則って要件定義を実施すれば、業務担当者に確実に利用してもらえる。ところが、APIは利用者が不特定であり、明確な利用目的があるわけではない場合が多い。要件をヒアリングしたくても利用者がスマホアプリ開発者のようなベンチャー企業であったり、APIエコシステムを検討する新規事業企画部署であったりするため、コンタクトができなかったり、明確な事業構想(ユースケース)が決まっていないことが多々ありうるのである。

では、API要件定義はどうすれば良いかと言うと、シーズベースで実施するということになる。その方法は２つある。
一つ目は、技術動向や市場分析から必要となりそうなAPI(サービス)を想定することである。サービス商品企画として、PEST分析(政策:P、経済:E、社会:S、技術:T)や、SWOT分析(強み:S、弱み:W、機会:O、脅威:T)を行い、ニーズが想定され、自組織の特長を生かしたAPIサービスを特定して、その開発を推進するという方法である。APIを有償サービスとして収益化する目的であれば、本方策を採用すべきと考えられる。
例えば、銀行が提供するAPIは全銀協(一般社団法人全国銀行協会)が定める電文仕様^※1で基本的なインターフェースが規定されている。これは銀行業務が法律で規定されており、インターネットバンキングなどで口座照会などの機能が利用されることが明確になっているからである。

※1: 銀行分野のオープンAPIに係る電文仕様標準について(第２版)

もう一つの方法は、ニーズを設定しない、もしくはニーズをつくり出す場を設ける方法である。既存システムが持つ機能を無作為にAPIとして公開し、利用者にAPIを選択させる、もしくは必要なAPIを考案させる方法である。APIエコシステムやオープンAPIと呼ばれる提供形態である。ニーズそのものが不明であったり、まだ発見されていない状況であるので、それを確定または発明する環境を整え、ハッカソンなどの利用を促進する活動を行うことにより、提供するAPIを決めていくのである。
例えば総務省が提供する「電子政府の総合窓口e-Gov」電子申請システムは各府省が所管するさまざまな行政手続きについて、インターネットを利用して自宅や会社のパソコンを使って申請・届出を行うことができるサイトである。このシステムが提供するAPIはe-Govシステムが現に備えている機能を操作するためのインターフェースをAPI化したものになっている^※2。こうすることにより、現行システムの要件をそのままAPIの要件として流用できることになる。

※2: e-Gov電子申請外部連携API仕様公開

APIエコシステム基盤機能概要

図はAPIエコシステムを構築するための環境であるAPIエコシステム基盤の概要である。API公開基盤上に各種サービスを提供するAPIや便利アプリ、ゲームなどを提供するAPIがあり、利用可能となっている。APIエコシステム基盤の利用者は２種類おり、消費者と開発者である。消費者はAPI利用スマホアプリなどを介してエコシステム基盤のAPIサービスを利用する。個人やSOHOとしてデイトレーディングや不動産検索・取引などを実施する事業者や、純粋な利用者として成人男女、高齢者/子どもが消費者として挙げられる。
要件の検討で述べたとおり、開発者は重要なAPI利用者である。利用者は、API単体では既存システム・業務以上の効果をあげることはできないが、さまざまなAPIを組み合わせ、付加価値のある機能を追加し、新たな消費者へ未知なる利便性を提供することで、価値を創造し、新規事業・市場を開発することができるからである。開発者としては、ベンチャー企業やクラウドワーカーといった小規模なユーザーから、クラウドベンダーやITベンダーといった大規模ユーザーまで存在する。
開発者が新たな価値を創造するためには、開発サービスの充実が欠かせない。新規事業アイデア検討を可能とする、遠隔関係者会議システム(チャット、ビデオ通話、資料共有)などの企画機能や、設計のためのドキュメント共有システム、種類の異なるAPIサービスを組み合わせるための開発環境が必要となってくる。また、事業として成立させるためには資金調達のためのクラウドファンディング機能や、商品リリース後の運用サービス、資金回収のための決済機能が不可欠となる。これら各種サービスをAPIエコシステム基盤が提供することとなる。

APIを提供するのは既存システムを保有し、その機能をサービスとして社外へ販売可能な企業となる。金融業や製造業、小売・流通業などの企業に加えて、SaaSビジネスを実施しているIT企業などが対象である。これらの企業はAPIエコシステム基盤へ自社APIを登録し、利用されるごとに従量制で課金・回収を行う。
さらに純粋な営利目的だけでなく、産業育成、データ活用促進、行政サービスの向上のために行政機関がAPIを提供することも増えている。政府機関は政府CIOポータル^※3にて標準ガイドライン群の一部として「API導入実践ガイドブック」「APIテクニカルガイドブック」のAPI開発に関するガイドラインを提供し、その普及に努めている。

※3: 政府CIOポータル

(2)APIの設計方針

前節要件の考え方から、API提供者としてはどのように設計すればよいのであろうか？
APIの要件は未定な場合が多いため、既存システム・業務に沿った機能をAPI化して提供することになる。そのため、２章に提示した内部APIから利用可能な外部APIをつくり出すことが、APIの設計の要諦となる。

内部APIはシステムが提供するプログラムを直接呼び出せるようにすれば、問題ないと考えられる。Javaなどのオープン系のプログラム言語で作成されているシステムであれば、Java EE(Enterprise Edition)などの分散システム対応機能が提供されており、プログラム単位で外部から利用することは特に難しいことではない。ホスト上で動作するCOBOLなど、手続き型言語のプログラムに関しては、ラッパーや端末エミュレータと呼ばれる変換機能を利用することで、プログラム単位や画面単位で他言語プログラムから利用することが可能となる。

しかし、そのような内部API範囲では処理粒度が細かすぎて、利用できないことが多い。例えば、データベースにおいてテーブルの１レコードのみを更新するAPIがあったとしても、通常の業務では複数レコードの一括更新を行うことが多いため、利用できない、もしくは利用するために多くの開発工数や処理負荷が掛かってしまうことになる。この問題は、以前より「粒度設計問題」として知られている。

粒度設計問題は、「階層化」と「業務利用の観点」を用いることで解決可能と考えられる。粒度が細かすぎるのであれば、複数のAPIを組み合わせて一括利用する新たなAPIを作成することで、粒度の調節が可能である。そこには最小粒度のAPIの上位に組み合わせAPIの粒度が存在し、その「階層」は機能の範囲で幾層にも構成できることになる。ただし、利用用途がないAPIの組み合わせを作成しても意味がないため、システムが提供する「業務」の観点で意味のあるAPIを設計する必要がある。

業務観点によるAPI粒度

上図に示したのは、コンピューターシステムの販売業務の一部である。その中で見積システムが「実務作業」列に示した機能を提供しているとすると、それが業務上最小単位のAPIとなる。しかし、「ハードウエア構成作成」といった単発のAPI利用だけでは十分な業務を提供するアプリケーションになるとは言い難い。単独の業務として成り立つには「実務機能」である「見積作成」の単位でAPIを提供することが必要となる。これらの「利用可能な単位」の機能提供のことを「マイクロサービス」と呼ぶことが多い。

マイクロサービスであれば、最小単位のAPIを組み合わせたものであるので、一部新規したAPIを追加したり、既存のAPIと置換したりすることで、新たな付加価値を追加したり、新事業領域へ展開することが容易となる。

API粒度の調整

APIを提供するシステムとしては、最小単位のAPIと、それらを業務単位で組み合わせた単位のAPIを提供することが妥当と考えられる。上の図は機能を外部提供する際の機能配置を示したものである。API(L1)が「最小単位のAPI」を示し、API(L2)が「業務単位で組み合わせた単位のAPI」となる。マイクロサービスを形成するためには処理性能が要求されるため、あらかじめAPI(L2)をシステム機能として提供しておくことが必要となる。業務として利用されている単位であるので、ロジックはシステム内に実装されていることが想定され、そのインターフェースのみをAPIとして提供すればよいので、容易に提供可能と考えられる。

実際のAPI設計作業においては、「最小単位のAPI」「業務単位で組み合わせた単位のAPI」といった単位を判定し、それに従った設計活動を実施する必要がある。そのためには、粒度判定の基準となる「階層化基準」を規定し、その活用を手順に組み込んだ設計プロセスを規定する必要がある。その内容を「API設計ガイド」として整備し、利用してもらえる単位でAPIを開発していくことが肝要となる。

4．今後の展開

現在APIの提供が盛んに行われており、今後も増加していく傾向にあると考えられるが、その際に課題となることがいくつか考えられる。

(1): API検索方法の標準化とカタログサイト
現在、さまざまなサイトでAPIが公開されており、各種基準も開示されている。前述の政府CIOポータルにおいても、実践的なガイドラインが公開されており、API設計・開発の標準化・容易化に貢献している。しかし、多くのサイトにおいて、APIの通信基準や電文(メッセージ)形式の標準化に偏っており、APIの目的や具体的な使い方、利用基準・制約などのAPI機能説明の公開方法を提示しているところは少ない。
このような情報がない、もしくは標準化されていないと、利用者が本当に具体のAPIを利用可能かどうか判断することができず、使ってみてから理解するという致命的な事態が発生してしまう。試行錯誤を繰り返すことにより品質向上が望めるが、避けられる隘路はなるべく避ける工夫をする必要があると考えられる。そのため、ネーミングサービスなどのAPI検索形式の標準化や、その総合的なカタログサイトの登場が待たれることと思われる。
(2): APIエコシステムの確立
API利用の普及スピードが上がらない最大の原因として、エコシステムが確立できていないこと、誰がお金を出してAPIを利用するのかというビジネスモデルが不明確な点が挙げられる。本文中で論じたとおり、APIの要件は未定であることが多い。裏を返すとどのように利用するかが決まっていないという事になる。APIを公開しても利用者がいなければビジネスとして成り立たないのは自明と考えられる。FinTech企業の一部は、APIによる口座連携を実現し、「家計簿アプリ」として提供を行っている。このような事例を多く集め、新たなアイデアを募ってAPIの利用方法、マネタイジングを実施していくことが、API普及の鍵となると考えられる。
APIの特長として標準化されているという点がある。その利点を最大限享受するためには、今まで業種間の商慣習の壁により成立しなかったビジネスや、技術的なハードルが高すぎて接続できなかった機器・システム、公開されていなかったデータや分析エンジンなどを、APIにより組み合わせることが必要なのではないかと考えられる。APIエコシステム基盤の発展などで、上記課題が克服されることを期待したい。

以上

次ページへ

本コラム執筆コンサルタント

本コラムへの感想などはこちらから