FinTech時代の銀行に求められるSoE/SoRアーキテクチャとAPI管理とは：FinTech時代、銀行系システムはどうあるべきか（3）（2/4 ページ）

本連載では、銀行系システムについて、その要件や歴史を整理しつつ、スマートフォンを使う銀行取引やブロックチェーンなど、新しい技術が及ぼす影響を考察していきます。今回は、FinTech時代に求められる銀行業務のシステム要件として、Systems of EngagementとSystems of Record、API連携基盤（API管理）に必要な機能や課題、OpenAPIの在り方などについて考察。

[鎌田美樹夫（日本アイ・ビー・エム株式会社）, 秋元毅彦（日本アイビーエム・ソリューション・サービス株式会社），＠IT ]

FinTech時代に求められる銀行システムのインタフェース（API連携基盤）とは

　FinTech時代になり、オープンなインタフェースを使用して銀行システムが持つ資源に直接アクセスする要求が高まっています。この章では、以下の観点でFinTech時代に求められる銀行システムのインタフェースについて説明します。

• システム間インタフェースのデファクトスタンダードWeb APIとは
• 銀行システム資源の外部公開におけるアーキテクチャの概要
• 銀行システム資源を外部公開するための2つの実装方法

システム間インタフェースのデファクトスタンダードWeb APIとは

　システム間連携を行うためのインタフェースでデファクトスタンダードとなったのは、Web技術を用いたAPIであるWeb APIです（以降、この記事では「API」と記述した場合はWeb APIを指します）。APIで一般的な形式は、アクセス対象の資源をURI（Uniform Resource Identifier）で表現し、資源に対する操作をHTTPのメソッドで要求すると、資源の状態を応答するものです。このアーキテクチャスタイルは、「REST（Representational State Transfer）」と呼ばれます。応答形式は、JSON（JavaScript Object Notation）が一般的に利用されています。

　例えば、銀行口座の残高照会のAPIは、図3のような形式です。

要求
GET
https://api.samplebank.com/accounts/｛口座の識別子｝/balance
 
応答
{
  "currencyCode": "JPY", 
  "availableAmount": 100000, 
  "currentAmount": 100000, 
  "recordDate": "2016-11-21" 
}
 
項目の説明
currencyCode: 通貨コード
availableAmount: 支払可能残高
currentAmount: 現在残高
recordDate: 基準日

図3　残高照会APIの例

　図3の例では、「/accounts/｛口座の識別子｝/balance」というURIで銀行口座残高という資源を一意に識別し、HTTPメソッドGETを使用して照会しています。応答形式はJSONです。

　また、APIの要求と応答の仕様記述の方法は、OpenAPI Specification（旧Swagger）で標準化が図られています。

　このようなオープンな標準に基づくインタフェースを銀行システムが持つことによって、多様なシステムとの連携が容易になり、今後、新たなサービスの創出が期待されます。

銀行システム資源の外部公開におけるアーキテクチャの概要

　FinTechアプリケーションは、利用者のニーズにタイムリーに対応し続けることを重視しています。そのため仮説検証型のアプローチである、スクラムなどアジャイル開発のメソッドを用いられ、短期間に何度も本番リリースが行われます。

　一方、勘定系に代表される既存の銀行システムは、安定稼働を継続することを重視するため、ウォーターフォール型の開発メソッドを用いて、明確化された要件に基づいて開発され、最短でも月1回程度の間隔で本番にリリースされます。

　このように、両者には開発スピードに大きな違いがあります。このため、このギャップを吸収し、既存の銀行システムが保有する資源を、セキュリティを担保した上で外部に公開するオープンなインタフェースが必要になりました。そこで「APIによる銀行システム資源へのアクセス」を可能にする、API連携基盤構築の取り組みが行われています。銀行システム資源の外部公開アーキテクチャの概要を図4に示します。

図4　銀行システム資源の外部公開アーキテクチャ概要

　API連携基盤には、どのような機能が必要なのでしょうか。

　まず、銀行システムが持つ既存のインタフェースをAPIに変換するAPIアダプタを加えます。APIアダプタが提供するAPIを、「銀行内で使用可能なAPI」という意味で「内部API」と呼びます。

　次にFinTechアプリケーションなど「銀行外部から、APIゲートウェイ経由で内部APIを使用するための手段」として使用可能なAPIを「外部API」と呼びます。APIゲートウェイは「外部APIによるアクセスに対応した内部API」を呼び出す機能を持ちます。加えて、アクセス制御、アプリケーション認証や流量管理など、安全に外部APIを公開するための機能を持ちます。

　このように、既存インタフェースを内部APIに変換する「APIアダプタ」と、銀行外部からのAPIアクセスを可能にする「APIゲートウェイ」をAPI連携基盤の機能とすることで、銀行システム資源の外部公開が可能になります。

銀行システム資源を外部公開するための2つの実装方法

　銀行システム資源にAPIでアクセス可能とする方法には2つあります。1つは、インターネットバンキングにAPIアダプタを構築する方法です。もう1つは、勘定系をはじめとした銀行システム全体を対象にAPIアダプタを構築する方法です。2つの方法の特徴を図5に示します。

図5　銀行システムAPI化の2つの方法

1.インターネットバンキングにAPIアダプタを構築する

　インターネットバンキングは、ご存じの通りインターネットに接続できるPCやスマートフォンなどから残高照会、入出金明細照会、振込などの取引を行うために銀行が提供しているサービスです。従来、インターネットバンキングはインターネット経由で銀行システムにアクセスできる唯一の手段でした。FinTechアプリケーションの代表例である個人資産管理（Personal Financial Management：PFM）でも、インターネットバンキングを利用して残高や入出金明細を取得しています。

　ただ現状は、APIによる情報取得ではなく、Webスクレイピング（WebページのHTMLを解析して、データを抽出する技術）による情報取得が一般的です。

　インターネット経由でアクセスできるインターネットバンキングにAPIアダプタを構築することについては、既存のユーザー認証基盤を再利用可能であることなどから、短期間で行えると考えられます。しかし、インターネットバンキングでサービス可能な取引でしかAPI公開はできません。また現実には、銀行の口座保有者全てがインターネットバンキングの会員というわけではなく、口座保有者の10％に満たない銀行もあるようです。

　このように、インターネットバンキングにAPIでアクセス可能にする方法は開発規模を抑えて早期に実現可能ですが、サービス可能なAPIや利用者が限られてしまう課題があります。

2.銀行システム全体を対象にAPIアダプタを構築する

　新たなアプローチとして、インターネットバンキングに限らず、銀行システム全体を対象にAPIでアクセス可能にすることが考えられます。これにより、勘定系取引全般をAPIで公開できるだけではなく、情報系システムやCRM（Customer Relationship Management）／SFA（Sales Force Automation）などもAPIで連携可能になります。このことは、銀行システムの開発の効率化につながり、API使用の効果がより大きくなるといえるでしょう。

　しかし、口座保有者全てを対象とした新たなユーザー認証基盤の構築に加えて、「本人以外の口座をAPIのパラメータに指定していないか」などのチェック機能が必要になるなど、開発規模が大きくなります。

　以上のように利用者や機能が限定されていても、早期にAPIによるアクセスを可能にするのであれば、インターネットバンキングにAPIアダプタを構築する方法を採用し、銀行システム全体をAPIで連携機能の強化を図るなら、銀行システム全体を対象としたAPIアダプタの構築となるでしょう。

　中長期的に考えればAPI連携基盤が銀行チャネルの1つとなる可能性があり、銀行システム全体を対象としたAPIアダプタを構築する流れとなるでしょう。

　次章では、API連携基盤（API管理）に必要な機能や課題を整理しておきます。