1．はじめに

近年，「API（Application Programming Interface）」を通じて，外部企業との連携や協業を図ろうとする取組みが増えている．外部のサービスとシステムを連携するためのプログラムやインタフェースを公開することによってデータのやりとりを可能にするオープンAPIという仕組みにより，オープンAPI公開元の企業は自社製品の付加価値が向上するような拡張機能や新サービスの開発を促進することができ，ビジネスチャンスを増やすことが可能である．特に，FinTechの台頭により金融機関では，さまざまな金融サービス創出に向けた取組みが始まっている．

2017年6月2日に公布された「銀行法等の一部を改正する法律（以下，改正銀行法）」[1]は，2016年に金融審議会のワーキンググループが発表した報告書を元に法令化されたものであり，金融機関とFinTech企業のオープン・イノベーションの推進を狙いとしている．こうした動きにより，金融機関と外部企業との連携による従来にない新しい金融サービスが創出されている．＜みずほ＞はいち早くオープンAPIの開発に着手し，技術革新に貢献してきた．

＜みずほ＞とは，「みずほ銀行」「みずほフィナンシャルグループ」「みずほ情報総研」の三者を統一して表現したもので，三者で協調してオープンAPIの開発や運用に取り組んでいる． 本稿では，まず金融機関でオープンAPIが重要である理由を解説した上で，＜みずほ＞がオープンAPIにどのような方針で取り組み，また課題を克服してきたかを記述してゆく．

筆者らは＜みずほ＞の個人向け金融取引サービスのシステム開発に携わる中で，オープンAPIの実装に関する検討や設計を行ってきたメンバであり，オープンAPIの実装における金融機関側開発者としての「現場の技術知見と学び」を，今後オープンAPIに取り組む技術者に伝えるために本稿を執筆した．

2．既存FinTechアプリの課題とオープンAPIによる解決

一般的に，オープンAPI以前におけるFinTechアプリの多くは金融機関の口座情報をWebスクレイピングというWebサイトから任意の情報を抽出する技術で取得し，FinTechアプリの利用者に，サービス提供するものである．

Webスクレイピングは（FinTechアプリの）利用者からインターネット取引など，各種Webサイトの認証情報（ID・パスワード）を（FinTechアプリの）利用者から預かり，（FinTechアプリの）利用者に代わって各種Webサイトに自動ログインし，画面（HTML）上から必要な情報を取得する技術である．

Webスクレイピングでは，容易に各金融機関の情報を取得できる一方で，FinTech企業のサービス利用者が有する金融機関へのアクセス用のIDとパスワードをFinTech企業側で管理する必要がある．そのため，IDとパスワードをどのように管理するか，セキュリティ面で課題の残るものであった．

また，金融機関側のWebページの入出力画面に修正が入るたびにFinTech企業側のWebスクレイピングにも同期をとって修正を行う必要があり，常に金融機関側のWebページの入出力画面状況を確認する手間が必要であった．

オープンAPIはWeb上に公開された機能を外部から呼び出して活用する技術である．金融機関が公開するオープンAPIでは残高照会や入出金明細照会などの参照や，振替，振込などの更新，また本人認証などの機能をオープンAPI経由で呼び出すことで可能となる．

オープンAPIは，全国銀行協会（以下、全銀協）が推奨するOAuth認証（本稿ではOAuth 2.0をOAuth認証と定義）[2][3]という，認証情報にIDやパスワードではなく，暗号化されたトークンという情報を活用する認可フレームワークを採用する[4]．指定したリソース（API）へのアクセス認可されていることを示すトークンをFinTech企業側に連携する．そのため，IDとパスワードをFinTech企業側で管理する必要がなく，セキュリティ面での課題は解消される．認証方式の違いについては図1に示す．

3．＜みずほ＞オープンAPIの取組み

＜みずほ＞のオープンAPI提供の利用形態は大きく分けて，「参照系」「更新系」「本人認証」の3つがある．

「参照系」は，残高照会や入出金明細照会など（FinTechアプリの）利用者の照会情報を提供するものである．「更新系」は，振込や振替など資金移動取引を提供するものである．「本人認証」は，口座情報を元に本人であることを認証する機能を提供するものである．

2017年5月に，家計簿アプリ「Moneytree」[5]「MoneyForward」[6]へ参照系APIの提供を開始した．家計簿アプリは各金融機関へ本人に成り代わり残高照会や入出金明細を実行するアプリケーションである．これにより，個人の資産情報をひと目で把握することができ，その有用性から急速に普及してきた．

金融取引サービスとは異なるところで，2017年9月には，本人認証APIを用いた個人向け融資審査サービス「J.Score」[7]を開始した．

「J.Score」は，（FinTechアプリの）利用者のさまざまな個人情報から，（FinTechアプリの）利用者の信用力をAIでスコア化し，その信用力に応じた金利と金額を融資するサービスである．「J.Score」は，それぞれが持つ取引情報のビッグデータをAIで解析し，個人向けの融資審査に活用している．

本人認証APIは＜みずほ＞の口座情報を元に（FinTechアプリの）利用者本人がスコアリングを実行していることを証明する．

貯金アプリの「finbee」[8]と連携し，更新系APIを提供した．これにより貯金アプリ内に貯金したものを金融機関に連携することを可能にした．これらは事前にアプリケーションと金融機関を連携することで更新系APIを用いて振替や登録振込を実行することが可能である．

NTTコミュニケーションズの提供する家計簿アプリ「kakeibon」[9]への参照系API提供は2018年7月に開始している．

みずほWallet[10]は，全国のICマークのある駅・コンビニ・スーパーなどでつかえる，iPhone・Apple Watch向けチャージ式スマホ決済アプリである．みずほ銀行口座情報を登録すると口座直結でチャージできるバーチャルカード「Mizuho Suica」をアプリ内に発行し，決済ができるようになる．みずほWalletへの参照系API提供は2018年8月に開始している．

3.1　オープンAPIの開発について

2016年11月より開始された全銀協のオープンAPIのあり方に関する検討会[1]の中で，2017年7月にオープン API のあり方に関する検討会報告書に銀行とFinTech企業間におけるAPI標準仕様が策定された．

この標準仕様では，アーキテクチャ・スタイルとしては，REST（Representational State Transfer の略．ソフトウェアがデータを連携するための設計原則の1つ．）を，通信プロトコルには HTTPSの使用を推奨している[4]．

またデータ表現形式としては，JSON（JavaScript Object Notation の略．RFC7159 で規定される軽量なデータ記述言語．）を推奨，認可プロトコルとしては，OAuth2.0 認可フレームワークを推奨する[4]．

この4つが全銀協から発表されている「オープン API のあり方に関する検討会報告書」にAPI標準仕様として定められている．＜みずほ＞が参照系APIの開発を始めた2016年の当初は，開発標準などは存在せず，「Facebook」や「Microsoft Corporation」といった，インターネット業界の主要な企業が採用していたOAuth2.0の認証方式を採用した．

3.2　＜みずほ＞における参照系APIの提供

2017年5月には国内メガバンクでは初となる残高照会や入出金明細照会などの照会を実行できるAPIを提供した[11]．アプリケーションから参照系APIを呼び出すことで銀行残高や入出金明細を確認することが可能になる．参照系APIの開発に際しては，FinTech企業サービスの利用者が，当該サービスを通じて金融機関が保有する利用者自身の情報を利用可能とすることの認証・認可，（FinTechアプリの）利用者同意について，形式や範囲を検討する必要があった．

まず第一に，API-GW（APIゲートウェイ）にてアクセス元となるFinTech企業が，みずほ銀行がAPIを通じて情報提供を行う事が可能な企業であるか，クライアントIDをもって照合を行う．

API-GWはFinTech企業と金融機関システムの間に構築し，トークンなどAPIの管理を行うシステムである．API-GWの概要については第4章で後述する．

クライアントIDの照合が完了すれば，インターネット取引の認証画面（（FinTechアプリの）利用者番号入力画面）に遷移し，既存インターネット取引と同様のログインフローにより，認証を行う．

（FinTechアプリの）利用者はFinTechアプリが代行する参照系取引に対する（FinTechアプリの）利用者同意を行い，同意を得られている範囲の対象サービス（図3の枠で囲った個所）において必要な情報を取得できる．

参照系APIの実装にあたって，筆者らは前述の認証の仕組みに関する設計・開発に参加し，オープンAPIの基盤構築に貢献した．

3.3　＜みずほ＞における更新系APIの提供

2018年2月には振替や振込など資金移動を伴う更新系APIも国内メガバンクでは初めて提供を開始した[12]．更新系APIは，振込や振替，カードローンといった資金移動を伴う金融取引を扱うAPIである．更新系APIを開発するにあたり厳格な本人確認を実現する必要があり，実装の大きなポイントは2点である．

1点目として，振込取引についてはAPIだけでの実装にしていない．振込金額や振込先について，あらかじめ登録された口座間の取引に限定し，取引時の暗証番号を金融機関側で入力させる実装とした．振込取引におけるFinTech企業（FinTechアプリ）から金融機関（みずほ）に遷移する流れを図4に示す．

ただし，振替取引については，不正利用リスクの低さと利便性を考慮し，振替時に基本的に取引認証は実施せず，ログインパスワード認証によりAPIで取引可能とした．一方でAPI取引におけるセキュリティ上のリスクの上昇を考慮するため，インターネット取引で可能な高額取引はAPI取引では不可としており，振込限度額は少額（～10万円程度）に制限している．

2点目として，セッション情報の連携方法について次の対応を行っている．APIはその性質上，セッション情報を保持することが出来ない．インターネット取引であれば1つのセッション内に取引情報を保持することができるが，APIはセッション間をつなぐために一時発行のキーをデータベースに格納し取引間で連携をする必要があった．

更新系取引を実行する際も口座照会や更新取引の内容照会，取引結果照会など一連の取引を一意の取引として紐付ける必要があり，紐付けのためのキーを発行している．

たとえば，振込仕掛中に処理が中断したような場合のトレースについて，インターネット取引では受付番号を発行し，仕掛中の特定を行うことができたが，API取引では受付番号の引継ぎを実行することができないため，APIの個別IDを発行することで，仕掛中の特定を行う必要があった．

更新系APIの実装にあたって，筆者らはセキュリティの仕組に関する設計・開発に参加し，更新取引を実現できるAPIの基盤構築に貢献した．

4．＜みずほ＞におけるAPI-GWの提供

API-GWでは，＜みずほ＞内の部門が利用するAPI ManagerとFinTech企業が利用する開発者ポータルの機能を提供する．

本章ではAPIを運用するにあたっての業務フローと適切な粒度のAPIを設計するにあたっての方針を記載する．

4.1　API Managerと開発者ポータル

API Managerは，＜みずほ＞内の管理者・開発者が使用するAPIや（FinTechアプリの）利用者を管理するための機能を提供する．

API Manager上ではAPIの登録や更新，（FinTechアプリの）利用者取引のトランザクションを確認することが可能である．API Managerの管理体系としてカタログ，製品，プランといった三要素によって構成され，それぞれの構成要素については表1に整理する．

図5に示すように，カタログはAPIを利用する組織単位の区切りを示し，製品は各システム単位の区切りを示す．プランが最小単位の区切りであり，利用可能なAPIと流量を定義してパッケージングしたものを示す．

たとえば，カタログはみずほ銀行，みずほ信託銀行，みずほ証券，といった組織単位で区切るものである．

製品は，個人向けのインターネット取引，法人向けインターネット取引といったようにシステム単位で区切るものである．

プランは，口座取得APIや残高照会APIといった機能単位に区切るものである．

開発者ポータルは，FinTech企業がAPIの仕様確認を行うために最新版の設計書配置や，APIを利用するにあたっての必要な作業を行うための機能を提供する．

FinTech企業へ提供するAPIの管理，および金融機関側に流れるトランザクションは，図6に示すように，FinTechサービス×利用プラン単位で流量を制御することが可能である．流量が増えると銀行システムへの影響も大きくなるため適切な流量に制限を行う必要がある．

流量制限を超えたトランザクションについてはAPI-GWにて返送するため，FinTech企業側のアプリケーションにて再送要求を実装する必要がある．

4.2　API運用業務フロー

FinTech企業が＜みずほ＞APIを利用したサービスを開始する際には，いくつか工程が必要である．例として，＜みずほ＞APIを利用するにあたっての運用業務フローを図示する．図7に示す通り，以下の工程を経ることでFinTech企業は＜みずほ＞のAPI利用が可能となる．

4.3　API設計

API-GW上に登録するAPI粒度とは，金融機関の取引業務とAPIを1対1で対応させるのではなく，APIをシステムの処理上のパーツとして用意しておき，取引業務は複数のAPIを組み合わせることで実装する考え方を指している．たとえば，FinTechサービスが，オープンAPIを使って金融機関の残高照会サービスを利用する場合には，前述のOAuth認証とは別に｢口座照会API｣｢残高照会API｣の2つのAPIを組み合わせた業務実装になる．

＜みずほ＞では，APIの種別として表2に整理した構成要素を開発した．口座照会や取引結果照会といった各取引で必要な共通機能をパーツとして準備することにより，共通部品として利用可能としている．

4.3.1　トップダウン・アプローチ

トップダウン・アプローチは，対象業務をトップダウンに分析・分類し，ビジネスシナリオから対象となるサービスと操作を導くアプローチ方法である．

対象となる金融取引（預金，融資，内国為替，外国為替等）を実現するサービス（口座開設，入金，出金，残高照会，入出金明細照会等）とサービス間のインタラクションを識別し，呼び出し元の操作（照会，作成，更新，削除）をRESTの動詞（GET，POST，PUT，DELETE）にマッピングしていた．

たとえば，預金という金融取引は，対象となる口座開設，入金，出金，残高照会，入出金明細照会というサービスの中で，口座開設は作成の操作としてPOST，入金，出金は更新操作としてPUT，残高照会，入出金明細は照会操作としてGETと，それぞれRESTの動詞とマッピングを行っている．

4.3.2　ボトムアップ・アプローチ

ボトムアップ・アプローチは，すでにシステム化されているサービスを分析して，アクセス対象の資源と操作を導くアプローチである．

対象となるシステム化されたサービス（インターネット取引等）から実現できるサービスとサービス間のインタラクションを識別し，既存サービスの操作（照会，作成，更新，削除）をRESTの動詞（GET，POST，PUT，DELETE）にマッピングを行っていった．

たとえば，＜みずほ＞のインターネット取引では残高照会や入出金明細照会，振込・振替やカードローンといったサービスを持っており，残高照会や入出金明細照会の機能を実装する場合には照会サービスにあたるGETをマッピングする必要がある．

＜みずほ＞は，2つのアプローチを元に，照会操作にあたる残高照会，入出金明細照会について，照会操作のみであるため，セキュリティリスクが低く，また利用者からの高いニーズが予想されるサービスをAPI化することを決定した．インターネット取引として提供している残高照会，入出金明細照会というサービスを取り上げたのも，すでに所有しているロジックを活用することで開発の効率化が可能であると判断したからである．

また，更新操作にあたる振込・振替，カードローンについてもあらかじめ決められた口座間で資金取引可能な登録振込，同じ口座間で資金取引可能な振替・カードローンサービスをAPI化することを決定した．

セキュリティホール対策としてリスク回避の項目を詳細に検討する必要があると判断し，2017年の時点では，参照系APIのみを提供開始し，更新系APIは，セキュリティリスクへの対応を十分考慮した上で2018年に提供開始した．

みずほにおけるオープンAPIの開発では，これら2つのアプローチを併用することにより，開発期間を大幅に短縮できた．

トップダウン方式の長所は，業務の実現に必要なAPIを抜け漏れなく設計と実装を有効に行えることであり，ボトムアップ方式の長所は既存のシステム実装の利活用を効率的に検討できることである．どちらか片方だけでなく2つの方式で検討を行う事は，筆者らの経験上，オープンAPIにおける開発の効率性の向上に大きな効果が認められた．

4.3.3　API種別機能

上記のアプローチを元に開発した＜みずほ＞の各API種別の機能について，詳細を表3に記載する．

5．APIプラットフォームにおける現状の課題と展望

オープンAPIが広く認知され多業種でのAPI化が進む一方で，現在公開されているAPIは開発設計者の自由裁量で製作されていて，統一規格などの共通ルールが存在せず，また公開したAPIについても広く認知されるための仕組みは存在しない．

筆者らは，今後においてオープンAPIがより一層の普及と発展を遂げてゆくためには，｢API標準化の推進｣，｢APIの信頼性を客観的に評価する仕組みの導入｣など，FinTech企業と利用者の負担を減らし，安心して使えるサービス提供の担保が不可欠だと考えている．

またオープンAPIに率先的に取り組む担い手の役割は，今後さらに重要になるため，筆者らの所属する＜みずほ＞もAPIプラットフォームの担い手として，金融機関という枠を越えて，ビジネスの中心に存在できるように努めていく必要があるだろう．

＜みずほ＞におけるAPIプラットフォームの1つの特徴は，図8に示すように，開発したAPI-GWと他サービスや他組織が連携できる基盤作りを行うことで，1つのプラットフォーム上でAPIサービスを取り揃えることができるスキームを採用している点にある．プラットフォーム化を行うことで，API開発を統制することが可能であり，新規にオープンAPIを開発する金融機関としては基盤初期構築費用の削減や開発ノウハウを連携することが可能になるメリットがある．

APIのプラットフォーム化によりAPIエコノミーは飛躍的に広がっていくことが予想される．ただし，APIのビジネス利用において，プラットフォームの整備やAPIの啓蒙活動に注力する担い手が存在しなければ，認知のスピードも変わってくるのも事実であり，今後のAPIを発展させていくにあたっては，使いやすいプラットフォーム基盤を構築する必要がある．

＜みずほ＞はプラットフォームの担い手として，今後金融機関という枠を越えて，ビジネスの中心に存在できるよう努めていく必要がある．

また，プラットフォーム化された世界では，ますます他業種，FinTech企業との連携が重要となる．業種や企業間の企業風土や考え方の違いについても配慮が必要である．

長年，金融機関は，従来の開発手法であるウォーターフォール型の開発を手がけてきた．一方で，昨今のFinTech企業では，早期から開発物を確認でき，開発物の柔軟な変更が可能なアジャイル型の開発スタイルをとっており，金融機関側としては，要件定義などの工程を積み上げずにプロトタイプ開発に移るFinTech企業の手法に当初は不安感を持つこともあった．逆にFinTech企業側も金融機関の意思決定のスピードに戸惑いを感じていたと思われる．

開発環境にて品質を担保した開発物を構築した後，本番昇格を行う金融機関システムとは逆に，本番環境において，検証と更新を繰返す開発スタイルとのギャップが発生した．

FinTech企業の開発スタイルとの調和を検討する上では，お互いの開発スタイルを尊重し，お互いのインタフェースについて，FinTech企業側から受領する項目，金融機関側から応答する項目を認識合わせしておくことが重要である．金融機関側のインタフェースに合わせて，FinTech企業のアプリケーションを開発することで，多様なサービスを提供可能とし，また，金融機関側のAPI機能の更新を頻繁に行わないようにする必要がある．

6．おわりに

APIはあくまでもデータ連携の手段の1つである．我々の最大の目的はAPIを活用したイノベーションを生み出すための基盤を提供することであり，新しい価値の提供と（FinTechアプリの）利用者の生活を豊かにすることにある．

APIを中心としたビジネスが拡大し，個人や企業にとって大きなチャンスを提供されるであろう未来に備え，本稿が今後のAPIの発展に少しでも寄与できれば幸いである．