オープンAPIの理解のために知るべき「APIとは何か」

　本稿ではオープンAPIを解説するが、その理解のためには「API」を説明する必要があるだろう。

　API (Application Programming Interface) とは、あるソフトウェアが別のソフトウェアに対して公開する、入出力のための仕組みである。インターネット標準を活用してネットワーク越しにデータや機能を提供する「Web API」が広まるにつれて、近年はそのWeb APIを指して「API」と呼ぶ機会が多くなっている。

オープンAPIとは何か

　特に近年では、APIを公開してシステムの接続仕様を明らかにして、提携企業先からのアクセスを認めることで、新たなサービスを生み出すための概念「オープンAPI」が 特に金融分野で広がりを見せている。

　金融機関のAPIが公開されると、顧客はサービス事業者のアプリなど使って、APIを介し、金融機関にアクセスできるようになる。

　これにより、たとえばソーシャルメデイアやメッセージアプリから自分の口座残高を確認したり、振込したりといったことが可能になる。また、銀行口座の出入履歴から家計簿をつけたり、家計の健全さについて、他者に相談することもできるようになるだろう。

オープンAPIが注目される背景と目的

　金融機関の領域で、APIが盛り上がっている背景や目標には何があるのか。総務省が発行している平成30年度の情報通信白書から一部要約して紹介しよう。

オープンAPIへの反応

　「オープンAPI」という概念が広まり始めた当初、筆者にとって意外だったのは、人によってその言葉から連想する内容が異なるということだ。たとえば以下のような反応だ。

■ 反応その1：オープンAPIを提供すると、誰でも自由に接続できるようになってしまう。自社の情報資産の流出につながったり、サービスにただ乗りされてしまうようになるのではないか？

■ 反応その2：オープンAPIでは皆が同じサービスを提供できてしまう。その結果、自社の優位性が失われてしまうのではないか？

　こうした疑念が生ずるのも無理はない。確かに自社外への公開・提供を前提としない「クローズドAPI」では、これらの問題は起こりえない（はず）。しかし、オープンAPIの「オープン性」とは何かを考えると、上記の推察は的を射ているとは言い難い。その理由は以下の2つだ。

■ 理由その1：オープンAPIによってオープンになるのは、直接的には接続のための仕様や手続きだ。クローズドAPIの場合には、APIの存在自体が公にされないが、オープンAPIでは、存在はもとより、どのように接続するかも含めて外部に公開することが前提となる。

　着目すべきは、APIは文字どおり「界面（インターフェース）」であり、その内側にある実装、すなわち企業のコア資産やキラーサービスそのものではないということだ。

　たとえAPIを公開したとしても、それら資産やサービスが無条件に外部に流出するものではない。むしろ、価値のある資産やサービスへのアクセス方法を外部に公開し、接続可能性を示すことが、自社の強みを最大化することに結びつく。

　インターフェースを公開し、同業他社に共有してマーケットを広げ、その上で界面の裏側のサービス品質を高めて差別化するという戦略は、過去IT業界において「オープンシステム」「オープン標準」などを旗印に進められてきた。APIに関しても同様だ。

■ 理由その2：オープンAPIにおける公開相手は、単に自社の外にいるのではなく、自身の統制が及ばない先にも存在する。

　クローズドAPIでは、自社がすべてを管理可能だった。そこではどのようなAPIを提供するかだけではなく、そのAPIをどう使うかも完全にコントロールできる。たとえばクローズドAPIが社内限定であれば、どの部門がどのようにAPIを使うかは、組織共通の規程の下、提供する部門の想定する範囲内にとどまるだろう。

　一方、オープンAPIでは、利用規約や秘密保持契約などの企業間の基本的な合意はあるものの、提供するAPIを使ってAPI利用側がどのような事業を行うかまではコントロールできない。

　これは、不確定要素という意味ではリスクの増大だ。ただし、そこをコントロールしないことで、API提供側が思っても見なかったような新たなサービスが生まれる余地があると見ることもできる。

　つまり、API提供側が意図しないかたちで、API利用側との融合によるイノベーションを産むための仕組みがオープンAPIであると言える。

オープンAPIには何が必要？

　先述したとおり、オープンAPIとは、接続にかかる仕様を自社外と共有し、コントロールできない他者に接続性を提供するものだ。では、その実現には何が必要だろうか。

　1つは、業界標準への準拠だ。社内の独自仕様や暗黙知に基づくAPIをそのまま「オープンAPI」として公開してしまうと、APIを使おうとする社外の開発者からは理解されにくいだけではなく、APIを真似ようとする同業他社への訴求も弱いものとなる。その結果、APIの普及が進まないということになってしまう。

　オープンAPIの提供にあたっては、すでにAPIを提供し、多くのAPI利用者を獲得している他の事業者を研究し、彼らの採用する技術、アーキテクチャスタイル、そしてプラクティスを取り入れるべきだ。

　たとえば2018年現在、APIをめぐるキーワードとしては、JSON、REST、GraphQL、JWT、OAuth、OpenID Connect、gRPCなどが挙がるだろう。

　またAPI提供のプラクティスに関しても、開発者向けポータルの整備、テストを目的とするサンドボックスの提供、APIライフサイクルの明示などが求められる。

　これら、APIを活用してサービスを開発するエンジニアが期待する要素を具備し、かつ継続的に維持することが、自社のAPIが利用可能な局面を増やし、採用してもらえる可能性を高めることにつながるのだ。

　一方、技術的な要素と同時に必要となるのは、提供側と利用側とが相互信頼に基づきAPI連携するための枠組みだ。

　API提供側が期待どおりにサービスを提供しているかどうか、逆にAPI利用側が利用規約に従ってデータや機能を利用しているかを、相手方に対して継続的に開示する必要がある。そのためには、共通のルールを策定し、その確実な遵守を参加者に履行させるための裏付けが欠かせない。

　またオープンAPIでは、単に提供側・利用側という事業者同士の関係では完結せず、双方のサービスを利用する顧客や従業員などの「エンドユーザー」がAPI連携に関与するケースもままある。

　そのような場合にはエンドユーザーに対しても、その本人に関係するデータや機能がどのようにAPIとして事業者間で連携されるかを、適時・的確に開示するべきだ。


【次ページ】金融業界に激震！？オープンAPIの実践事例