API開発の基本 - 銀行APIの開発事例に学ぶ『使いやすい』のデザインプロセス

APIは多くのWebシステムにおいて、欠かすことのできない技術です。APIをどのように設計、デザインすれば、ユーザに利便性を提供できるのかを、GMOあおぞらネット銀行 CTOの矢上聡洋さんが解説します。API設計の基本、そして実際の銀行APIの設計から、“使いやすい”を生み出すためのデザインプロセスを学びます。

API開発の基本 - 銀行APIの開発事例に学ぶ『使いやすい』のデザインプロセス

さらにその中でもこれまで閉じた世界のイメージが強かった銀行業界において、ユニークだと言われる当社の銀行APIへの取り組みと、その先にある未来についてお伝えしたいと思います。

そもそもAPIとは何か?

IT業界で、API(Application Programming Interface)という言葉よく耳にします。それ自体の説明はこちらの記事がよくまとまっていますが、ごく簡単に表現すれば、APIとはアプリケーションとプログラムをつなぐ部品(インターフェース)です。たとえば、ある家計簿アプリにおいて、ボタンを押すと銀行預金の残高をスマホ上に表示する機能を実現しようとすると、

  • (A)ボタン押す→入力内容取得→内容を元に銀行サイトにログイン
  • (B)入力内容を元に銀行勘定系データベースにアクセス→目的のデータを検索および取得
  • (C)取得した結果を整形→ユーザアプリの画面に表示

こうしたロジックが必要になります。本来的にはアプリ開発者は、Bのロジックを開発する必要がありますが、銀行側がBの部分をAPIとして公開している場合、これを利用することでBのロジックを開発する必要がなくなるのです。このようにAPIは再利用性が高く、効果的に利用することでアプリケーション開発の生産性が高まります。

「良いAPI」とはどのように設計されるべきか?

APIにはいくつかの種類がありますがWebの世界でよく使われるのがWebAPIです。WebAPIはHTTP(S)プロトコルを利用し、ネットワークを介して呼び出すAPIのことです。Facebookが公開する「グラフAPI」や、Amazonが公開する「Amazon MWS」「Product Advertising API 」などはWebAPIの好例です。

綺麗なAPIを設計するには気をつけたい5つのポイント』にまとめられているように、WebAPIを設計するうえで重要な点はいくつかありますが、APIを「公開する立場」から考えた場合、とくに忘れてはならないのは「APIは多くのユーザに使われるべき存在であること」、そのために「ユーザである開発者が使いやすいAPIでなければならない」という点でしょう。そして、本稿執筆時点においては、下記3点が「使いやすさ」を生み出すうえで重要だと筆者は考えます。

  1. REST(Representational State Transfer)の設計原則に合わせること
  2. 対象リソースとアクションとを分かりやすくすること
  3. RESTの弱点である自由度を補うSwaggerなどを公開すること

以降、各項目を簡単に解説してみます。

RESTの設計原則に合わせること

RESTは2000年に提唱されたWebシステムの設計原則で、以下の4点が定められています。

・明示的に HTTP メソッドを使う
・ステートレスにする
・ディレクトリ構造に似たURIを公開する
・XML、JSON(JavaScript Object Notation)のいずれか、またはその両方を転送する

IBM Developer『RESTful Web サービスの基本』より引用

では、なぜAPI設計においてこうした原則を踏襲する必要があるのでしょうか。それは、公開APIについて開発者視点で考えた場合、独自設計されたものよりも、「世の中に流通している標準等に則っている」ものの方が学習コストが低くなり、使いやすいからです。REST以外の標準、設計原則には過去にはSOAP(Simple Object Access Protocol )や、最近ではgRPC(g Remote Procedure Calls)などがありますが、本稿執筆時点ではRESTが広く浸透しており、そのため多くのAPI設計に活用されていると考えます。

対象リソースとアクションとをわかりやすくすること

RESTでは「明示的にHTTPメソッドを使う」とありますが、ここで重要なのはHTTPメソッドを正しく使い、APIを呼び出す対象となるリソースと、APIのアクションに一貫性を持たせることです。

たとえば、銀行口座に対して操作を実施するAPIの場合、以下のようなアクションが想定されます。

  • 口座一覧照会、残高照会:GETメソッドを利用(GET /balance)
  • 振込依頼:POSTメソッドを利用(POST /request)

照会系APIはリソース(口座情報や残高データ)の取得であるためGETを利用、振込についてはリソース(振込データ)の新規作成であるためPOSTを利用といった具合です。HTTPメソッドを正しく使うことで、開発者のAPIに対する期待値とAPIの内容が一致する使いやすいAPIとなります。

RESTの弱点である自由度を補うSwaggerなどを公開すること

RESTはあくまで設計原則であり、プロトコルではありません。それゆえ、設計の自由度は高くなりますが、反面、実装は開発者ごとに少しずつ、異なり統一性がありません。そのため、RESTを参照して開発したAPI(RESTful API)を公開する際は、そのAPIに即したSwagger(RESTful APIを構築するためのオープンソースのフレームワーク。OpenAPIとも言われる)などのSDK(Software Development Kit:開発キット)を合わせて公開することが、開発のしやすさの観点から極めて重要となります。

また、その他の観点では、APIをバージョンアップした際に後方互換性を持たせる、1つのリクエストで自由度を持たせすぎない(対象リソースとアクションの関係が崩れるため)なども良いAPIを設計するためのポイントと考えます。

以上、2020年8月の本稿執筆時点におけるAPIの概念、また、具体的な基礎技術と特徴について紹介しました。続いて、APIの具体的なユースケースのひとつとして、銀行業界特有のAPIに関して解説します。

銀行業界でのAPIの位置付け

銀行においてもWebAPI(以降、API)を活用する動きが加速しています。銀行が自社システムの機能やデータにアクセスできるようにするAPIを「銀行API」と呼びますが、これが公開されることで、銀行の保有するデータやサービスと外部の事業者との連携が促進され、新しい価値やビジネスの創出が期待されているのです。こうした潮流は「オープンバンキング」と呼ばれ、とくに英国での注目度は高く、さまざまな面で先行しています1

日本では2017年5月に銀行法が改正され、施行後、2年以内に銀行API公開することが努力義務となりました。また、2020年4月21日に公正取引委員会により、フィンテックを活用した金融サービスの向上に向けた競争政策上の課題についての報告書が出され、日本でもオープンバンキングの動きが加速してゆくことが予想されます2

日本の銀行で“あるべき”APIが開発しにくい理由

先に良いAPIを開発するには標準化されていることが重要であると書きました。これは銀行APIでも、もちろん同じで、オープンバンキングが先行する英国などではOBIE(Open Banking Implementation Entity:オープンバンキング制度の推進主体)が、OpenID Foundationによる標準を採用し、これに基づくAPI仕様を策定しています。しかし、2020年7月時点の日本においては銀行APIに関する標準規格は存在せず、各銀行、手探りの状況で銀行APIを開発し、公開されているのが実状です。銀行APIに接続するサービスを運営する企業からみれば、銀行ごとに異なる仕様のAPIを実装せざるを得ない、非常に使い勝手が悪い状況だと言えるでしょう。

日本の銀行業界が変革の途上にあるがゆえ、こうした状況にあると考えられます。しかし今後、(断言はできませんが)各行の取り組みとともに、銀行業務のデジタル化、いわゆるデジタルトランスフォーメーション(DX)が進み、横断的な動きが活発化することで、今後、銀行APIの標準化に何らかの変化が見えてくるのではないかと期待しています。

GMOあおぞらネット銀行でのAPI開発の舞台裏

エンジニアHubに会員登録すると
続きをお読みいただけます(無料)。
登録のメリット
  • すべての過去記事を読める
  • 過去のウェビナー動画を
    視聴できる
  • 企業やエージェントから
    スカウトが届く