開発者ポータルのブログ投稿

KYC専業プロバイダーTRUSTDOCK様に聞く、デジタルアイデンティ

APIteam1 — Mon, 29 Mar 2021 15:00:00 +0000

KYC専業プロバイダーTRUSTDOCK様に聞く、デジタルアイデンティ APIteam1 2021/03/30(火) - 00:00

三菱UFJ銀行 API事務局です。

MUFG Innovation Hubで、APIに関する記事が掲載されました。
KYC専業プロバイダーとして様々な業界に本人確認ソリューションを展開するTRUSTDOCK様が、2021年3月に、当行「本人確認サポート（個人） APIサービス」との連携により、金融機関認証によるeKYCソリューションの提供を開始されました。

代表取締役である千葉孝浩氏に、デジタルIDの現在と未来についてお聞きしたインタビューをどうぞご覧ください。

2021/03/26　 eKYC対応のデジタル身分証アプリ「TRUSTDOCK」が三菱UFJ銀行APIを使った金融機関認証に対応。KYC専業プロバイダーが挑むデジタルアイデンティの現在と未来

「MUFG Innovation Hub」とは、先端テクノロジーの情報発信、またMUFGのフィンテック導入等に関する情報発信を行うことを目的とした、新しい形のイノベーションメディアです。

MUFG Innovation Hub：https://www.mufg.jp/profile/strategy/dx/index.html

タグ

導入・活用事例

eKYC対応で先行するマネックス証券様へのインタビュー

APIteam1 — Mon, 30 Mar 2020 15:00:00 +0000

eKYC対応で先行するマネックス証券様へのインタビュー APIteam1 2020/03/31(火) - 00:00

三菱UFJ銀行 API事務局です。

MUFG Innovation Hubで、APIに関する記事が掲載されました。

マネックス証券様は2018年11月の犯罪収益移転防止法の改正施行開始を受け、いち早く業務課題の解決と関連づけてeKYC対応の検討を進め、2020年2月に、銀行APIを使った金融機関認証による本人確認の提供も開始されました。金融機関認証による本人確認の利用状況についてお聞きしたインタビューをどうぞご覧ください。

2020/03/23　eKYC対応で先行するマネックス証券、銀行APIを使った金融機関認証導入で得た成果

「MUFG Innovation Hub」とは、先端テクノロジーの情報発信、またMUFGのフィンテック導入等に関する情報発信を行うことを目的とした、新しい形のイノベーションメディアです。
MUFG Innovation Hub：https://www.mufg.jp/profile/strategy/dx/index.html

タグ

導入・活用事例

エメラダ様に聞く、銀行とAPI接続する狙いとは

APIteam1 — Sun, 17 Nov 2019 15:00:00 +0000

エメラダ様に聞く、銀行とAPI接続する狙いとは APIteam1 2019/11/18(月) - 00:00

三菱UFJ銀行 API事務局です。
今回は、自社サービスに当行APIを取り入れている企業様のインタビューをお届けします。本日ご紹介するインタビュー企業様は、中小企業や小規模事業主向けにオンライン資金繰り管理/融資サービスなどを提供されているエメラダ株式会社様です。当行APIを実際に活かしたサービスについて、開発担当者やマネジメントに関わる方々に開発時のエピソードなども踏まえてお話いただきましたので、API活用のイメージがより膨らむと思います。

金融機関との連携と独自のスコアリングにより、日々の資金繰り自動分析を実現

―　提供されているサービスやターゲットとしているユーザーについて教えてください

中小企業向けに通帳管理等のアカウントアグリゲーションサービスや、取引先別入出金の動向、売上・収益の推移、借入・返済状況の推移、借入余力シミュレーションなどを自動的に分析したデータ等を提供しています。
中小企業だけではなく、API接続で情報を提供する金融機関側もターゲットと考えていますので、双方に価値のある分析データを提供できるようなサービスを目指しています。実際にリリースまで含め連携している金融機関は、10行程ですが、現在も70行以上の金融機関との連携協議を進めており、将来的には100～200行近い金融機関と連携する予定です。

サービスの根幹部分を担う銀行とのAPI接続は自前で実現

―　他社のアカウントアグリゲーションサービスを利用せず、自社で各金融機関と接続していこうと思われたのは何故ですか

先々のことまで考えますと、サービスの根幹部分を他社へ依存するのはリスクが大きいと考えたため、自社でアカウントアグリゲーションサービスを構築することにしました。また、自社でAPI接続を行う方がアカウント作成作業などで他社の画面を介する必要がないためユーザー側の利便性維持にも繋がると考えたことも理由の一つです。

連携する金融機関が千差万別の中、どのように対応・モニタリングしていくのかが大きな課題

―　接続先が増えるほど管理は複雑になるかと思いますが、契約面やシステム面で工夫していることがあれば教えてください

おっしゃるとおり接続先が増えると管理が大変です。中でもチェックリストの仕様が金融機関によって、千差万別なことには苦労しています。FISCのチェック項目をそのまま使うか、少し変えるか、大幅に変えるか、独自のものにするか、金融機関によって本当に様々ですね。現在は連携している金融機関数も少ないので問題ないですが、来年以降、契約する金融機関が100行、さらに200行と増えていく際には、どのように定期チェックに対応していくのかということが大きな課題だと思っています。現時点では、省力化の観点で各行のチェックリストを基に重複する部分を纏めるなどしたマスターとなるチェックリストを作成し、各行の審査に対応しています。

―　当行APIを使用して開発される上で、苦労した点はありますか

三菱UFJ銀行のAPIは、Swagger（※）で定義されているので非常に開発がしやすかったと感じました。一方で、三菱UFJ銀行だけではなく他金融機関にも言えることですが、Swaggerの良さをもっと活かせると、より良いAPIが開発できるのではないかと感じます。

※Swaggerは、開発者がRESTful Webサービスを設計、構築、文書化、および利用するのに役立つツールの大規模なエコシステムに支えられたオープンソースのソフトウェアフレームワークです。現在は、RESTful APIを記述するためのフォーマットであるOpenAPIを用いてREST APIを設計する際に使用するツールセットとなっています。

他社とはターゲットを変えることで、自社APIを活用したサービスの展開を目指す

―　今後のビジネス戦略について、サービス展開を踏まえてどのようにお考えでしょうか

近い将来の目標としては、主にスコアリング、財務分析のさらなる自動化を中心に、他社からAPIで取得したデータをどのように自社で活用していくかを考えていきたいと思っています。
個人ではなく、中小企業をターゲットにしているサービスは少ないので、そこにターゲットを置くことで、弊社独自のAPIを活用したサービス展開ができるのではないかと考えています。

―　今後、当行に限らず金融機関全体としてAPIに求めることや課題と感じている点があれば教えてください

どのような金融機関も、全ての情報を公開するのは難しいと思いますが、APIを利用する側が責任を持つようにすることで、照会系のAPIに関しては審査を軽減したり、公開情報については契約がなくても誰でも利用できるようにすることが出来たら、APIの利用拡大や新たなシナジー創出に繋がるのではないかと思います。

＜エメラダ株式会社様＞
以下リンクは外部サイトへ遷移します。
会社HP：https://www.emerada.co.jp/

タグ

導入・活用事例

本人確認サポート（個人）APIサービスとそのユースケースのご紹介

APIteam1 — Wed, 10 Jul 2019 15:00:00 +0000

本人確認サポート（個人）APIサービスとそのユースケースのご紹介 APIteam1 2019/07/11(木) - 00:00

三菱UFJ銀行 API事務局です。
今回は、5月30日より新しく追加された本人確認サポート（個人）APIサービス^*について、
開発に至った経緯や考えられるユースケースをいくつかご紹介します。
*本ポータルサイトでは「顧客API」として仕様を公開中です。是非ともご覧ください。 >>

１．サービス概要と開発経緯

本サービスは、犯罪収益移転防止法（以下、犯収法）の対象事業者などを対象に、当事業者（以下、事業者）が行う本人確認業務の一部をサポートします。具体的には、利用者^※１同意のもと、本人特定事項と言われる住所・氏名・生年月日と本人確認有無区分^※2の情報を、APIを通して事業者に提供します。事業者は、利用者の本人確認資料の確認に加えて、当該情報の内容を確認し疑義がなければオンラインで本人確認を完結することが可能です。
※1 対象となる利用者は、当行インターネットバンキング｢三菱ＵＦＪダイレクト｣の契約者の方のみとしています。（2019年7月時点）
※2 過去に当行に口座開設等を行った際に実施した本人確認の有無フラグ

図１.API連携のイメージ

元々、犯収法では事業者が行う本人確認の方法が定められており、対象事業者は、犯収法で認められている「顧客から身分証（写し）の送付を受け、利用者宅に転送不要郵便を送付する方法」等で本人確認を行っています。しかし、2018年11月に犯収法が改正されたことに伴い、オンライン完結する本人確認の手法のうち、一部銀行への照会が認められるようになったことを受けて、当行は本サービスの開発に乗り出しました。

２．利用する上でのメリットと工夫したポイント

本サービスによって、事業者と利用者の双方にメリットをもたらします。事業者は前述の本人確認時に行っていた利用者宛郵便の郵送や事務にかかる費用や時間を削減でき、それにより利用者が事業者のサービスを使うまでの機会損失を防ぎます。また、利用者にとっても当該郵便物を受領する必要が無くなり、早ければその日のうちにサービスを利用することが可能になります。

なお、当行が連携する情報の中でも特に住所については、引越し等による変更後の住所が当行に届出されておらず、当行の保有する情報が最新ではない可能性があります。
そのため、事業者が行う本人確認業務に支障が出ないよう、当行画面にて利用者自身に住所を確認いただき、必要に応じて住所変更手続きが行えるよう工夫をしています。

提供されるサービスがデジタル化する中で、オンライン上で利用者がサービスを完結するために本サービスは重要な役割を果たしています。

３．今後考えられる本人確認のユースケース

本人確認のユースケースとしては、例えばインターネット証券会社などの口座開設時の活用などを想定しています。

以下の図では、インターネット証券会社で口座開設での本サービス利用したユースケースの例を表しています。これまで郵送で手続きしていた本人確認を、本サービスを利用して円滑に口座開設を行うことができます。（以下、オレンジ枠部分）なお、認証・認可についてはOAuth2.0の仕組みを利用しております。

図2.本人確認ユースケース

また、本人確認のユースケースとして、犯収法対象事業者以外にもライドシェアやマッチングサービスなど、あらゆるサービスの可能性が広がっていくと考えています。
当行として事業者の皆さまと、シェアリングエコノミー協会やFINTECH協会を対象としたアイデアソンやミートアップなどを通じて、具体的なAPIの活用方法や今後追加していくAPIを検討する予定です。

本人確認サポート（個人）APIサービスの開始に伴う、当行との連携・協働事例については、事業者の声なども含めてこの場でご紹介できればと考えております。どうぞお楽しみに！

タグ

ビジネス

「銀行APIアイデアソン」イベントリポート

APIteam1 — Wed, 29 May 2019 15:00:00 +0000

「銀行APIアイデアソン」イベントリポート APIteam1 2019/05/30(木) - 00:00

三菱UFJ銀行 API事務局です。

MUFG Innovation Hubで、APIに関する記事が掲載されました。ぜひご覧ください。

2019/04/22　銀行APIの活用がもたらす、新しい「フィンテック×シェアリングエコノミー」の形～
｢Fintech Challenge2019（銀行APIアイデアソン）｣イベントリポート

タグ

イベント

電子決済等代行業登録企業に聞く！電代業登録への道のり

APIteam1 — Wed, 27 Mar 2019 15:00:00 +0000

電子決済等代行業登録企業に聞く！電代業登録への道のり APIteam1 2019/03/28(木) - 00:00

三菱UFJ銀行 API事務局です。
今回は銀行APIとの関係性が高い電子決済等代行業（以下、電代業）に着目し、電代業の登録を完了している企業にご協力いただき、登録における経験談に関するアンケートを実施。アンケート結果を踏まえ、今後、登録を検討している方向けに電代業登録のポイントについてご紹介できればと思います。

＜目次＞

電子決済等代行業×銀行API
電子決済等代行業登録企業の経験談からわかること

１．電子決済等代行業×銀行API

電代業とは、とある事業者が、自身のサービス上でお客さまの依頼に基づき、お客さまの振込指図を銀行に対して行ったり、口座情報を銀行から取得し提供する業を営むことをさします。お客さまの重要な情報等を取り扱う事業となるため、2018年6月1日より、「電子決済等代行業」として新しい制度が開始され、国内で電代業を営むには、銀行法等に基づく財務局への登録が必要となりました。加えて、電代業者が接続したい銀行とは、当該銀行が求める接続基準（※）をクリアした上で接続に伴う契約締結が必須となります。
※前回ブログ記事ご参照

一方で、銀行は、当該業者と協働する方針を表明している場合には、当該業を営む体制の整備を2020年6月目処に実施する必要があり、その１つの手段として一般的にAPIが用いられています。
当行でいうと、2019年3月時点で以下APIを利用し当行と接続する事業者は基本的に電代業登録が必要となります。詳細は、こちら。
● 口座API（個人・法人）
● 振込申請、総合振込申請、賞与給与振込申請、特別徴収地方税（法人）

２．電子決済等代行業取得企業の経験談からわかること

電代業の登録を完了している企業3社に回答いただいた内容を、以下にまとめました。

≪基本情報≫

	登録している業	主な事業内容
A社	第2号^※	クラウド会計サービスの開発・提供
B社	第1号^※、第2号	PFMサービスおよびクラウドサービスの開発・提供
C社	第2号	PFMサービスの開発・提供

※ 第1号：利用者の委託を受け、銀行に対し当該利用者（預金者）の支払・送金の指示を行う業
第2号：利用者の委託を受け、銀行から当該利用者（預金者）の口座情報を取得し、提供する業

≪アンケート結果から分かったこと≫
第1号、第2号の夫々で登録する際の違いはあるのか？
当局への提出資料にて両方の業を営むのか、どちらかの業を営むのかを明示する必要はあるが、両方の電代業者登録を比較した際、申請過程において「これは第1号だから必要。」というような、業種の違いで求められているものは特段ないようです。

電代業者登録のための準備を開始してから登録完了までにどのくらいの期間がかかったか？
アンケート先企業3社の電代業者登録までの流れとかかった期間は以下のような結果となりました。企業規模や体制によって様々なようです。

	期間	実施内容
準備	2～6ヶ月	・当局担当者やFintechサポートデスクとのやり取り・当局が公表している資料やFAQの確認
申請～登録完了	1～6ヶ月	・事前申請・本申請のための必要書類受領・社内向け説明・当局への本申請必要書類の提出・当局からの質疑応答や書類確認

期間

実施内容

準備

2～6ヶ月

・当局担当者やFintechサポートデスクとのやり取り

・当局が公表している資料やFAQの確認

申請～登録完了

1～6ヶ月

・事前申請
・本申請のための必要書類受領
・社内向け説明
・当局への本申請必要書類の提出
・当局からの質疑応答や書類確認

なお、申請～登録完了期間での当局への本申請必要書類には、役員の情報に関連する書類やセキュリティチェックリストなどがあるようですので、前広に対応する必要がありそうです。

どのような体制で電代業者登録に臨んだか？

電代業担当部署、情報セキュリティ・システム担当部署を中心に、書類収集のため総務部や、法務担当や個人情報保護担当なども入れて体制を組んでいることがわかりました。

（その他アンケート回答内容）

A社	「電代業（FinTech）担当部署（当局、関東財務局との窓口、申請書類とりまとめ）、システム・セキュリティ担当部署（システムチェックリスト回答）、総務、個人情報保護担当部署（システム以外チェックリスト回答、財務書類、役員提出書類取りまとめ）など総勢10名程度が関わりました。」
B社	「3名で実施し、必要に応じて法務コンプライアンス部門担当や弁護士が加わりました。」

苦労した点は？またその点に対してどのような対応をしたか？
全ての企業で挙がったのが、役員の公的書類や役員の自署・捺印が必要な書類の収集に時間がかかったという意見でした。社外や海外滞在中の役員への対応が必要となるため、電代業者登録の期間を短縮するためにはこれらの書類の事前準備が不可欠です。
時間を短縮する方法の一つとして、外部弁護士に依頼して書類を作成するなどの対応が有効だったそうです。その他、各社から以下のような意見もありました。

（その他アンケート回答内容）

B社	「情報セキュリティ・システムの提出書類（データ）の容量が大きく、いろいろ試しましたがオンラインでの提出はできず、DVD・CD 等での提出となり煩雑に感じました。」
C社	「セキュリティチェックリスト確認では、更問対応の過程で、サービス説明とこれまでのセキュリティ関連の取り組みを紹介する場を設け、QAだけでは伝わらない箇所を補いました。」

これから電代業者登録を目指す方に対するアドバイス
共通した意見としては、役員関連の提出書類を早めに準備しておくことや、一般社団法人電子決済等代行事業者協会やFintech 協会（※）主催のセミナーに参加することが挙げられました。また、そういった場で質問をすることで、疑問点を解決されていた企業もいらっしゃいました。
以下リンクは外部サイトへ遷移します。
※Fintech 協会のホームページはこちら。
その他、各社から以下のような意見もありました。

（その他アンケート回答内容）

B社	「当局・財務局共に相談に応じてくれるので、完璧なものを最初から作って提出しようとするのではなく、現状について記載し、当局と会話をしながらチェックリストや社内体制を作り上げていきました。また法令やチェックリストで求められている事項は他の事業者登録でも求められている部分が含まれており、公表されている他の登録業種の社内規程雛形等が参考になる部分もあるかと思います。」

アンケートにお答えいただいた企業の皆さま、誠に有難うございました！！

電代業者登録をしている企業は2019年3月時点で30社を超え（※）、今後も増えていくことが見込まれます。
登録をご検討中の皆さまのご参考になれば幸いです。
以下リンクは外部サイトへ遷移します。
※電代業社登録をしている企業一覧はこちら。
当局が電代業登録に関する申込み要領を公開していますので、こちらも参照してください。

タグ

導入・活用事例

APIを使った安全・安心なサービスを提供するために必要なこと

APIteam1 — Sun, 27 Jan 2019 15:00:00 +0000

APIを使った安全・安心なサービスを提供するために必要なこと APIteam1 2019/01/28(月) - 00:00

三菱UFJ銀行 API事務局です。
今回は、エンドユーザであるお客さまに、当行APIを利用したAPI利用事業者（以下、事業者）のサービスを安全・安心に使っていただくために必要なことについて、その基準と当行の考え方をご紹介できればと思います。

＜目次＞

事業者、銀行双方のお客さまに安全・安心を提供するための基準とは
利用者保護とセキュリティに関する当行の考え方

１．事業者、銀行双方のお客さまに安全・安心を提供するための基準とは

銀行は、これまで自らがサービスの提供主体者としてお客さまに”直接”サービスを提供する形態をとってきました。一方で、銀行分野におけるオープンAPI（バンキングAPI）の世界では、銀行はあくまでも他の事業者に対してAPIという形式で銀行機能を提供する立場に留まり、お客さまであるAPIサービスの利用者（以下、利用者）に対するサービスの提供主体は当該事業者が担います。しかし、このように他の事業者と連携してサービスを提供した前例はほとんどありませんでした。各銀行とも他の事業者とのオープンイノベーションを進めていくにあたり、双方のお客さまに安心を提供するための仕組み作りが大きな課題でした。

そのようななか、2017年6月に改正銀行法が公布。「電子決済等代行業者（以下、電代業）」の金融庁への登録義務化と、当該業者との連携・協働を行うと宣言した銀行は、電代業との接続可否に係る「基準」の作成・公表が義務づけられました。

こうした動きがあるなかで、2017年7月に全国銀行協会（以下、全銀協）（※１）の「オープンAPIのあり方に関する検討会」が、データの種類・プライバシー等に応じたリスクベース・アプローチにもとづき、利用者利便と利用者保護のバランスを踏まえた、バンキングAPIにおけるセキュリティ対策および利用者保護に関する基本的な考え方を公表しました。FISC（※２）の「API接続チェックリストワーキンググループ」でも、事業者と銀行のAPI接続に向けた円滑なコミュニケーションツールとして専用のチェックリストを作成するなど、事業者と銀行の双方が同じ場で議論し、1つの指針をまとめていくプロセスが踏まれました。

当行を含む各銀行は、これらの検討結果を参照しながら改正銀行法に基づき独自の目線を策定していくことになりました。
以下リンクは外部サイトへ遷移します。
※１　全銀協は国内の銀行等を会員とする組織で、銀行業務の発展に向けた活動や消費者保護への取組み、決済インフラの運営などを行っている一般社団法人です。
参考資料：全銀協　オープンAPIのあり方に関する検討会
※２　FISC（金融情報システムセンター）は金融情報システムの諸問題に対してガイドラインや調査レポートを作成している公益財団法人です。

図１.事業者と銀行の取り組み

２．利用者保護とセキュリティに関する当行の考え方

ここでは、利用者保護とセキュリティ対策について、当行がどのような目線を置いているかくわしくお話します。
当行では、当行がAPIで事業者に連携する利用者の情報の保全と、事業者からAPIで当行に連携される利用者の指図の正確な処理を第一に考えています。

したがって、事業者の皆さまが当行のAPIを利用する前に、そうした考え方に共感し、連携し合える相手であるかを、利用者保護態勢やセキュリティ態勢などの観点で確認をさせていただいています。確認する内容は当行独自のものを定めていますが、前述の全銀協やFISCのガイドラインを参考にし、関連する法律やセキュリティの国際標準化基準なども取り込んでいます。
利用者保護態勢では、利用者への説明態勢や、利用者の相談や苦情等に対するサポート体制の整備、利用者情報の取り扱いが適切であるかなどを確認します。セキュリティ態勢では、開発・運用時やサービスシステム自体のセキュリティ、またAPI利用時のセキュリティはもちろんのこと、オフィス等の設備管理についても確認します。どちらも、これまで当行が策定し遵守してきた目線も採り入れており、事業者が利用者の情報を安全に取り扱えるかなどを審査しています。（※３）
オープンAPIでは、利用者からの申請・同意にもとづいて取引が行われるとはいえ、銀行が持つ口座情報などはプライバシー性の高い情報のため、十分な利用者保護とセキュリティ対策を図る必要があります。そのため、事業者と当行は、ともに安全・安心なサービスを創出し提供していかなければなりません。
ただし、このような目線が結果として利用者の利便性を阻害することがないよう、利用者保護とバランスを図ることが最も重要です。そのため、今後利用者によりスピーディにサービス提供できるよう、事業者への確認項目の見直しや手続きの簡素化を検討していきます。
※３　利用者保護やセキュリティ以外にも、当行APIと接続するための基準を公開しています。接続基準についてくわしく知りたい方は、こちらからご確認いただけます。

オープンイノベーションを実現していくにあたり、利用者保護を最優先に考えつつ、事業者と銀行の協業・連携の円滑化に向けて、今後も互いに変化ある柔軟な考え方を採り入れていきたいと考えています。
今後もAPIに関する情報をお伝えしていきますので、ぜひご覧ください！

タグ

ビジネス

会計クラウドサービスを幅広く展開、freee様に聞くAPI活用法とは？

APIteam1 — Mon, 24 Dec 2018 15:00:00 +0000

会計クラウドサービスを幅広く展開、freee様に聞くAPI活用法とは？ APIteam1 2018/12/25(火) - 00:00

三菱UFJ銀行 API事務局です。
今回は、自社サービスに当行APIを取り入れている企業様のインタビューをお届けします。
本日ご紹介するインタビュー企業様は、会計・人事労務のクラウドサービスを幅広く展開しているfreee株式会社様です。当行APIを実際に活かしたサービスについて、開発担当者やマネジメントに関わる方々に開発時のエピソードなども踏まえてお話いただきましたので、API活用のイメージがより膨らむと思います。

利用事業所100万超えの会計・人事労務のクラウドサービスを提供

―　まずは提供されているサービスやターゲットとしているユーザについて教えてください

個人事業主から中堅企業、上場企業まで、幅広いユーザを対象に会計・人事労務のクラウドサービスを提供しています。クラウド会計ソフト「freee」ができて5年経ち、利用いただいているユーザは100万事業所を超えました。

―　当行APIを使用するきっかけについて教えてください

きっかけは、 MUFG Fintech Challenge 2015です。現在当社で提供しているようなサービスとして、インターネットバンキングから入出金明細をAPIで取得し、ユーザ自ら送金したい明細を、当社のデータ連携により銀行へ振込処理ができるサービス案を企画し応募しました。会計・経理業務と決済部分が繋がることはユーザの利便性に繋がると確信し、このような案を出しました。結果、当社はこの案で大賞を受賞しました。また、それを実際にMUFGと協働してこのアイデアを実現することができました。

―　様々なサービスをご展開されている中で、当行APIをどのような場面で利用しているか教えてください

会計freeeというサービスで、照会系や更新系のサービスを提供しています。その中の明細取得や振込申請において、APIを利用することで、ユーザが三菱UFJ銀行の口座・明細を選ぶことができるようにしています。
APIを使用する前、明細を取得するとなると、スクレイピングによりHTMLにアクセスして、そのHTMLから明細の必要箇所を少しずつ取得していました。そのため、HTMLに変更が加わると、その処理自体も修正しなければならず、ユーザが安定的にお金の動きを取り込めないということが起こっていました。しかし、APIを使うようになってからは会計システムが安定して動き、ユーザも安定してお金を取り込めるようになりました。また振込申請APIを使用し、振込期限や振込元の情報を会計システムに入れて、振込めるサービスを提供しています。

―　当行APIを使用してみて、開発する上で使いやすかった点はありましたか

開発者へのサービスとして他行と比べて良かった点は、テストデータの登録を行うツール（※）が充実しており、環境が使いやすかったことです。テストデータを登録する場合は、好きなタイミングで作れたり日付が柔軟に設定できたりしたため、日付が過ぎたため明細が使えなくなることがなく、様々なバリエーションのテストを実施できました。ツールを利用することで簡単な手順で必要な期間の明細が作れたので、テストがとても実施しやすかったです。
また一般的には、テストを実施できる期間が限られているポータルサイトが多い中で、三菱UFJ銀行API開発者ポータルは基本的にほぼ制限なく使用できる点が良かったです。ウォーターフォールではなくアジャイルで開発しているので、開発後、改良の度にテストをすることができました。
※本番接続のお申込みをいただき、お申込み内容を確認後にご利用いただけます。

―　当行APIを使用して開発する上でのエピソードがあれば教えてください

接続トラブルが起こった際、当社と三菱UFJ銀行、どちらに原因があるのか、お互いのシステムを深く調べ合って原因を特定し解決することができました。技術者同士で密に連携をとり、問題を解決できた点がとても良かったです。そのときは三菱UFJ銀行側に原因があったのですが、エンドユーザに迷惑がかからなかったかをとても配慮して対応してくださいました。

金融業界やフィンテック企業の今後を見据えて、大規模なクラウド専業の会社だからこそできることをやっていく

―　今後のビジネス戦略について、サービス展開を踏まえてどのようにお考えでしょうか

個人事業主のみなさんに対し、個人向けAPIを利用したサービスの提供はぜひやっていきたいと考えています。
また、当社でも自社のAPI充実や開発者の支援を重要な戦略に位置付けています。日本の会計サービスとしては初となるAPI公開と freee Developers communityの立ち上げを実施し、多くのエンジニアの皆さまに参加頂いています。特に、数百名規模の企業では各社の業務や課題も様々ですので、APIを活用することで課題に合わせて銀行とfreeeと様々なクラウドサービスとを組み合わせられるようにしています。

―　今後、当行に限らず銀行全体としてAPIに求めることや課題と感じている点があればお聞きしたいです

日本のフィンテック全体として考えると、APIのインターフェースの共通化が必要だと感じます。そのためには、銀行や電代業者など、関係者同士が協力する必要があると考えています。
また、APIは我々のようなサービス開発者(＝APIの利用者)にとってのAPIの使いやすさや取得したい情報を得ることが出来るかといった観点だけでなく、実際にサービスを利用するエンドユーザの課題や使い勝手を踏まえて、APIのインターフェースなどを検討する必要があると考えています。

―　freee様は電代業者第1号でもありますが、API化に向けてどのような意識をお持ちだったのでしょうか

エンジニアとして、エンドユーザの課題解決の一手段としてAPIを使ってみたいと思っていました。またAPIを導入することで、振込処理が簡単になるなど、ユーザにとっても大きなメリットがあると考えていました。
当社は、利用しているAPIの種類が多く、規模の大きなフィンテック企業として、我々1人1人がこの業界を引っ張っていくという自覚を社長含め強くもっています。小規模のフィンテック企業ですと、電代業者の取得が難しい場合もあるため、当社はフィンテック協会の一員として、業界の発展のために今後セキュリティや法務の方向けに電代業者登録のための勉強会やセミナーの実施も考えています。

全員で考え抜き、新しいアイデアを生み出す

―　5分で会社設立に必要な資料を作成する「会社設立freee」など、思わず目を引くサービスなども展開されていますが、どのようなプロセスでアイデアを生み出しているのでしょうか

社内の役割毎にエンドユーザの課題やサービスの改善点を考える点ももちろんありますが、生み出した案の取捨選択は関係者全員で行います。
プロダクトマネジャーはどういう課題を解決したいか課題を見つけ出し、そのためにどういうものを作るかを明確にして、サービスを検討しています。それに対して、エンジニアも加わってディスカッションや決定したプロダクトの仕様作りを全員で行います。
決められた仕様をエンジニアがただ作るという考えではなく、エンジニアは課題解決のプロフェッショナルであるべきと考えています。

＜インタビューを終えて＞

今回のインタビューでは、freee様からはモックAPI設計・開発時から当行と検討を進めていらっしゃる事業者ならではのお話をたくさん聞くことができました。
フィンテック企業への支援など、一歩先を行くフィンテック企業としての責任感や役割認識を強く持ってフィンテック業界を牽引されているように感じました。また、エンドユーザであるユーザのことを第一に思うという点において、freee様と当行は同じです。フィンテック企業と銀行それぞれの特性を生かし、どう連携していくのがユーザにとって最良なのか、それぞれがしっかりと向き合うことで、企業間のより良い関係を構築し新しいサービスに発展していくと考えています。今後のAPIを考える上で、エンドユーザの課題解決に向けた情報共有など、更なる連携をしていければと思います。

＜freee様＞: 以下リンクは外部サイトへ遷移します。
会社HP： https://corp.freee.co.jp/
会計ソフト「freee」： https://www.freee.co.jp/

タグ

導入・活用事例

APIのレスポンスデータ設計とは？

APIteam1 — Mon, 24 Dec 2018 15:00:00 +0000

APIのレスポンスデータ設計とは？ APIteam1 2018/12/25(火) - 00:00

三菱UFJ銀行 API事務局です。
今回の記事では、「APIの設計思想について」でご紹介した当行APIで提供しているサービスの粒度やURI（エンドポイント）の考え方に関連して、APIのレスポンスデータ設計についての考え方や開発時に工夫したポイントなどを紹介します。一般的なデータフォーマットの設計に加え、可用性を重視して設計を進めました。

＜目次＞

Web APIにおけるレスポンスデータ設計のトレンド
当行APIのレスポンスデータ設計にて工夫したポイント

１． Web APIにおけるレスポンスデータ設計時のトレンド

Web APIはHTTPプロトコルで通信されるのが一般的です。APIのレスポンスデータは、利用する開発者がわかりやすい、統一性のある設計にする必要があります。レスポンスデータの形式としては、XMLやJSONが指定されることが多く、JSONは通信時のデータ量がXMLより軽量で、表記がわかりやすいことから主流となっています。Web APIを利用するクライアント側の開発はJavaScriptで実装されることが一般的なので、JavaScriptのオブジェクト表記法であるJSONは、関数を用いて容易にJavaScriptのオブジェクトへの変換が可能である点においても秀でています。またエラー情報は、HTTPステータスコードで表現されたり、それに加えてレスポンスデータの中で定義されたエラーオブジェクトによって、よりくわしく表現されたりします。
設計時の詳細な観点は、表１をご参照ください。

表１．レスポンスデータ設計時の一般的な観点

観点	説明
プロトコル	Webサーバからデータを取得するための基本プロトコルであるHTTPや、その通信を暗号化したHTTPsが利用されている HTTPメソッドは全部で8つあるが、APIでは主にGET（参照）・POST（登録）・DELETE（削除）・PUT（更新）の4つがリクエストで使用されている
データ形式	最近の主流はJSONであり、それ以外ではXMLなども利用されている
データ形式の指定方法	HTTPリクエストではacceptを用いて指定する（例）Accept：text/html, application/json HTTPレスポンスではContent-Typeに設定されている（例）Content-Type：application/json
データボディ部の内部構造	APIのアクセス回数が少なくて済むような設計（例：1度のアクセスで多くの情報をとってくる）ユースケースに適した設計（例：アクセス数の少なさと必要な情報の取得を両立させる）
正常・エラー情報	レスポンスヘッダに含まれるステータスコードで表す

２．当行APIのレスポンスデータ設計にて工夫したポイント

当行では表1で紹介した主流な設計に加え、全国銀行協会（以下、全銀協）で推奨されている（※）プロトコルやデータ形式の標準に則り設計しました。また、開発当初、一部のAPI利用事業者にベータ版を公開して外部の声を取り入れつつ、以下の（ⅰ）～（ⅳ）の観点を重視してレスポンスデータを設計しました。
※全銀協では、オープン・イノベーションが起こりやすい環境の実現を目指すため、開発標準を示しており、その中でいくつかの仕様が推奨されています。

以下リンクは外部サイトへ遷移します。

参考資料：: 全国銀行協会（2018年12月25日時点）
オープンAPIのあり方に関する検討会報告書　－オープン・イノベーションの活性化に向けて－

（ⅰ）プロトコルについて

プロトコルはHTTPsを使用しています。HTTPメソッドについて、照会や申請を行うことができる当行APIではGETメソッドとPOSTメソッドを実装しています。

（ⅱ）データ形式について

データ形式はJSONを使用しています。
一般的に、多くのWeb APIはRESTで公開されています。当行内のシステム間連携はSOAPも使用していますが、現在のデファクトスタンダードであるREST、およびJSONを採用しました。

（ⅲ）HTTPレスポンスデータの内部構造

HTTPレスポンスデータは、ステータス行やヘッダーフィールドからなるヘッダ部と、メッセージ本体であるボディ部から構成されています。

○ データヘッダー部について

ヘッダ部のステータス行は、HTTPのバージョンや、リクエストに基づいて行われた処理の結果として返されたステータスコードなどの情報をもっています。ヘッダーフィールドは、リクエストとレスポンスどちらにおいても「フィールド名：値」という形式です。フィールド名について例を挙げると、リクエストでAPI実行を一意に識別できるNoを示す当行独自のX-BTMU-Seq-Noや、レスポンスでデータの種類を示すContent-Typeなどが使われています。

○ データボディ部について

HTTPレスポンスのボディ部は、大きく分けるとオペレーション情報とデータ情報からなります。具体例として、法人向けの口座APIの入出金明細照会を挙げて説明します。（APIの仕様は、画面上部のメニュー＞API ＞法人API - 口座をご参照ください）
オペレーション情報は、次明細有フラグや次明細取得キーワードなど、取得するデータを指定するパラメータのことです。一方でデータ情報は、店番・口座番号などを口座情報オブジェクト、取引日・金額などを入出金明細オブジェクトとして定義したものです。
HTTPレスポンスデータの内部構造を下の図1にまとめました。

図1. 当行のHTTPレスポンスデータの内部構造（正常応答時）

（ⅳ）エラー情報について

ヘッダ部のHTTPステータスコードは、API利用事業者がレスポンスデータを受け取ったときの1次判断基準となるため、200が正常応答、400がクライアント起因エラー、500がサーバ起因エラーなど一般的なHTTPステータスコードの定義に従って設計しています。
口座が存在しない場合など、HTTPステータスコードでは表現しきれない詳細なエラー内容については、エラーレスポンスオブジェクトを定義し、ボディ部にてエラーコードやエラー文言を返却しています。
またHTTPステータスコードが200で送信が成功しても、業務エラーとなる場合もあります。例として、法人APIの総合振込や給与賞与振込の受付明細照会では、その特徴上、申請・承認してから実際に振り込まれるまでに時間が開く場合があり、その間に店舗統廃合などで支店番号が変更となった場合は明細の振込が実行できなくなることが挙げられます。
エラーが発生した場合でも、HTTPステータスコードとエラー情報から、API利用事業者がエラー内容に応じて実装しやすいよう設計しました。

図2. 当行のHTTPレスポンスデータの内部構造（エラー応答時）

今回はAPI設計の中でも、レスポンスデータ設計について紹介しました。当行APIのレスポンスデータは、画面上部のメニュー＞ APIから気になるAPIを選択し参照することができます。
みなさんもぜひ実際に使ってみてください！

タグ

TIPS

マネーフォワード様にAPIの活用方法や課題についてお聞きしました！

APIteam1 — Wed, 07 Nov 2018 15:00:03 +0000

マネーフォワード様にAPIの活用方法や課題についてお聞きしました！ APIteam1 2018/11/08(木) - 00:00

三菱UFJ銀行 API事務局です。
今回は、自社サービスに当行APIを取り入れている企業様のインタビューをお届けします。開発者ポータルをご利用いただいている皆さまに当行APIの活用イメージを持っていただくため、今後も定期的にお届けしていきます。
初回は、株式会社マネーフォワード様です。参照系API・更新系APIの開発担当者の方々に、実際のサービス内容や、開発時のエピソード、今後の展望についてお話いただきました。

家計簿管理の自動化、会計業務の自動化を実現

―　まずは提供されているサービスやターゲットとしているお客さまについて教えてください

2012年12月に個人向けの自動家計簿・資産管理サービス「マネーフォワード」を提供開始し、家計を自動で見える化、お金の課題解決を目指したサービスの展開を始めました。
その翌年にはクラウド会計ソフトである「MFクラウド会計・確定申告」を提供開始し、その後は、ビジネス向けクラウドサービス「MFクラウドシリーズ」としてバックオフィスをサポートする様々なサービスを展開しています。（MFクラウド請求書、MFクラウド経費、MFクラウド給与など）MFクラウドシリーズは、企業のバックオフィス業務の効率化を目指したサービスで、主に個人事業主や中小企業の皆さまにご利用いただいています。

―　様々なサービスをご展開されている中で、当行APIをどのような利用場面で使われているか教えてください

MFクラウド会計・確定申告において、入出金明細と残高を取得する際にAPIを利用しています。
従来の会計業務において、入出金明細を通帳やインターネットバンキングから参照して、仕訳入力を手作業で行う必要があります。当社はこれまで、この手作業を自動化するために、スクレイピングというデータ取得技術を活用してきました。しかし、BizSTATIONにおいては、電子証明書が入っているPCからでないとデータ取得ができず、全自動での取得が難しいという課題がありました。これを、APIを利用することで、スクレイピングよりもよりセキュアな環境で入出金明細を取得することができるようになり、より簡単に仕訳を作ることが可能になります。また、ユーザーがMFクラウド会計・確定申告にログインすると、ユーザーが意識することなく入出金明細が既に取得されているという状態を実現することができました。

―　オン/バッチなどシステム的な観点でも教えていただけますでしょうか

総合振込申請APIは同期的に利用しています。参照系のAPIは、オンラインとバッチ両方で利用しています。バッチ処理にてデータの自動取得を行い、ユーザーの任意のタイミングで更新するという形で利用しています。

―　当行APIを利用してアプリケーションを開発するにあたり、良かった点・工夫した点を教えてください

良かった点としては、テストに関して銀行からテストデータの登録を行うツール（※）が提供されているため、比較的自由度が高く、効率的なテストができたと感じています。
工夫した点は、エラー処理です。APIからのエラーメッセージをそのまま表示してしまうと、エラー解消のためにユーザーがとるべきアクションがわからない場合があります。そのため、エラーの原因と解決策を銀行側に確認し、次のアクションが伝わるメッセージを表示しています。
※本番接続のお申込みをいただき、お申込み内容を確認後にご利用いただけます。

キャッシュレスの社会を目指すために、まずはAPIへの置き換えから

―　API利用を始めたきっかけについて教えてください

政府は未来投資戦略2017で、2020 年6月までに80行のAPI公開を目指す方針を掲げています。金融機関のサービスとAPI接続が可能になることで、当社のようなフィンテック企業のサービスとの相乗効果が生まれることやキャッシュレス化を推進することができます。当社もセキュリティの強化とユーザー利便性の向上を進めていくため、既存のスクレイピングの接続をAPI接続に置き換えることを進めていきたいと考えています。

APIで実現可能な実務改善の余地はまだまだある

―　今後のサービス展開を踏まえ、当行APIに期待することを教えてください

当社が提供している自動貯金アプリ「しらたま」は、買い物をしたおつりを貯金することができるアプリです。貯金ができる仕組みとして、おつり金額を銀行のメイン口座から貯金用口座に資金移動をしています。これには、更新系APIが必須となります。
こうした新たなサービスの提供においても、APIが活用できる可能性があり、今後のAPI公開に期待しています。API公開が進むことで、API利用事業者側でも様々なアイデアやユースケースが考えられると思います。
金融機関の新たな取り組みの促進や、業務における負荷を軽減させる為にも、API利用事業者が増えることを期待しています。

銀行業界全体として、APIに求めることや課題は多い

―　銀行APIの公開は一部分に留まっている現状を踏まえ、さらに銀行業界全体へ求めることは何ですか

API接続をする際に、住宅ローンなどあらゆる商品の情報を取得できるようにしてほしいと考えています。
次に、業務ロジックエラー時の処理に関する仕様を明確にして欲しいと考えています。銀行が提供するのはAPIを介したサービスであり、業務ロジックエラー時の原因と解決策はAPI利用事業者によらず同じはずです。そのため、その仕様を銀行でクリアにしておいていただけるとAPI利用事業者は接続時のコストを削減でき、銀行側は問合せが減少するというように、双方にメリットがあるのではないかと考えています。

―　さらに銀行APIの公開を進めるには、特にセキュリティ面が懸念されますが、どのような対策を考えていますか

マネーフォワードとしては、認可コードの横取り攻撃を防止するため、認可取得時にPKCE（ピクシー）対応（※）を実施する予定です。

※PKCEは、認可コード横取り攻撃防止対策として2015年9月にRFC 7636としてその仕様が公開されました。認可サーバーで発行された認可コードをクライアントアプリケーションが受け取る際、悪意のあるクライアントアプリケーションから認可コードを横取りされ、アクセストークンが発行されてしまうことを防ぐ仕様です。

＜インタビューを終えて＞

当行APIは初期のAPI設計から、モックAPIに対して、フィンテック企業の皆さま、第三者企業の皆さまから多くの意見をいただきながら開発を進めてきました。その1社がマネーフォワード様です。マネーフォワード様は、フィンテック企業の中でも積極的に金融機関との連携やフィンテックの推進活動に尽力されています。インタビューでは、「良いサービスをより早く提供したい」、「いかにユーザーにストレスなく操作してもらえるか」など、常にユーザー目線で考えられていると感じました。今回も忌憚のないご意見をいただき、まだまだオープンAPIは始まったばかりで、多くの課題があると感じました。また、改善に対するスピード、開発者の改善意識の高さもAPIの提供側として刺激になりました。
開発中だけでなく、リリース後の運用においてもフィンテック企業様との「会話」の重要性を改めて感じることができました。
今後も、フィンテック企業の皆さまと一体となって、多くの新しいユーザー体験を生み出せるような、APIを活用した連携・協働を行っていきたいと思います。

＜マネーフォワード様＞: 以下リンクは外部サイトへ遷移します。
会社HP： https://corp.moneyforward.com/
MFクラウドシリーズ： https://biz.moneyforward.com/
家計簿アプリ・家計簿ソフト「マネーフォワード」： https://moneyforward.com/

タグ

導入・活用事例

開発者ポータルのブログ投稿

KYC専業プロバイダーTRUSTDOCK様に聞く、デジタルアイデンティ

eKYC対応で先行するマネックス証券様へのインタビュー

エメラダ様に聞く、銀行とAPI接続する狙いとは

金融機関との連携と独自のスコアリングにより、日々の資金繰り自動分析を実現

― 提供されているサービスやターゲットとしているユーザーについて教えてください

最新の情報をいつでも提供できる環境にするためのAPI

― 当行APIをどのような利用場面で使われているか教えてください

サービスの根幹部分を担う銀行とのAPI接続は自前で実現

― 他社のアカウントアグリゲーションサービスを利用せず、自社で各金融機関と接続していこうと思われたのは何故ですか

連携する金融機関が千差万別の中、どのように対応・モニタリングしていくのかが大きな課題

― 接続先が増えるほど管理は複雑になるかと思いますが、契約面やシステム面で工夫していることがあれば教えてください

― 当行APIを使用して開発される上で、苦労した点はありますか

他社とはターゲットを変えることで、自社APIを活用したサービスの展開を目指す

― 今後のビジネス戦略について、サービス展開を踏まえてどのようにお考えでしょうか

― 今後、当行に限らず金融機関全体としてAPIに求めることや課題と感じている点があれば教えてください

本人確認サポート（個人）APIサービスとそのユースケースのご紹介

＜目次＞

１．サービス概要と開発経緯

２．利用する上でのメリットと工夫したポイント

３．今後考えられる本人確認のユースケース

「銀行APIアイデアソン」イベントリポート

電子決済等代行業登録企業に聞く！電代業登録への道のり

＜目次＞

１．電子決済等代行業×銀行API

２．電子決済等代行業取得企業の経験談からわかること

APIを使った安全・安心なサービスを提供するために必要なこと

＜目次＞

１．事業者、銀行双方のお客さまに安全・安心を提供するための基準とは

２．利用者保護とセキュリティに関する当行の考え方

会計クラウドサービスを幅広く展開、freee様に聞くAPI活用法とは？

利用事業所100万超えの会計・人事労務のクラウドサービスを提供

― まずは提供されているサービスやターゲットとしているユーザについて教えてください

― 当行APIを使用するきっかけについて教えてください

― 様々なサービスをご展開されている中で、当行APIをどのような場面で利用しているか教えてください

― 当行APIを使用してみて、開発する上で使いやすかった点はありましたか

― 当行APIを使用して開発する上でのエピソードがあれば教えてください

金融業界やフィンテック企業の今後を見据えて、大規模なクラウド専業の会社だからこそできることをやっていく

― 今後のビジネス戦略について、サービス展開を踏まえてどのようにお考えでしょうか

― 今後、当行に限らず銀行全体としてAPIに求めることや課題と感じている点があればお聞きしたいです

― freee様は電代業者第1号でもありますが、API化に向けてどのような意識をお持ちだったのでしょうか

全員で考え抜き、新しいアイデアを生み出す

― 5分で会社設立に必要な資料を作成する「会社設立freee」など、思わず目を引くサービスなども展開されていますが、どのようなプロセスでアイデアを生み出しているのでしょうか

＜インタビューを終えて＞

APIのレスポンスデータ設計とは？

＜目次＞

１． Web APIにおけるレスポンスデータ設計時のトレンド

２． 当行APIのレスポンスデータ設計にて工夫したポイント

（ⅰ）プロトコルについて

（ⅱ）データ形式について

（ⅲ）HTTPレスポンスデータの内部構造

○ データヘッダー部について

○ データボディ部について

（ⅳ）エラー情報について

マネーフォワード様にAPIの活用方法や課題についてお聞きしました！

家計簿管理の自動化、会計業務の自動化を実現

― まずは提供されているサービスやターゲットとしているお客さまについて教えてください

― 様々なサービスをご展開されている中で、当行APIをどのような利用場面で使われているか教えてください

― オン/バッチなどシステム的な観点でも教えていただけますでしょうか

― 当行APIを利用してアプリケーションを開発するにあたり、良かった点・工夫した点を教えてください

キャッシュレスの社会を目指すために、まずはAPIへの置き換えから

― API利用を始めたきっかけについて教えてください

APIで実現可能な実務改善の余地はまだまだある

― 今後のサービス展開を踏まえ、当行APIに期待することを教えてください

銀行業界全体として、APIに求めることや課題は多い

― 銀行APIの公開は一部分に留まっている現状を踏まえ、さらに銀行業界全体へ求めることは何ですか

― さらに銀行APIの公開を進めるには、特にセキュリティ面が懸念されますが、どのような対策を考えていますか

＜インタビューを終えて＞

―　提供されているサービスやターゲットとしているユーザーについて教えてください

―　当行APIをどのような利用場面で使われているか教えてください

―　他社のアカウントアグリゲーションサービスを利用せず、自社で各金融機関と接続していこうと思われたのは何故ですか

―　接続先が増えるほど管理は複雑になるかと思いますが、契約面やシステム面で工夫していることがあれば教えてください

―　当行APIを使用して開発される上で、苦労した点はありますか

―　今後のビジネス戦略について、サービス展開を踏まえてどのようにお考えでしょうか

―　今後、当行に限らず金融機関全体としてAPIに求めることや課題と感じている点があれば教えてください

―　まずは提供されているサービスやターゲットとしているユーザについて教えてください

―　当行APIを使用するきっかけについて教えてください

―　様々なサービスをご展開されている中で、当行APIをどのような場面で利用しているか教えてください

―　当行APIを使用してみて、開発する上で使いやすかった点はありましたか

―　当行APIを使用して開発する上でのエピソードがあれば教えてください

―　今後のビジネス戦略について、サービス展開を踏まえてどのようにお考えでしょうか

―　今後、当行に限らず銀行全体としてAPIに求めることや課題と感じている点があればお聞きしたいです

―　freee様は電代業者第1号でもありますが、API化に向けてどのような意識をお持ちだったのでしょうか

―　5分で会社設立に必要な資料を作成する「会社設立freee」など、思わず目を引くサービスなども展開されていますが、どのようなプロセスでアイデアを生み出しているのでしょうか

２．当行APIのレスポンスデータ設計にて工夫したポイント

―　まずは提供されているサービスやターゲットとしているお客さまについて教えてください

―　様々なサービスをご展開されている中で、当行APIをどのような利用場面で使われているか教えてください

―　オン/バッチなどシステム的な観点でも教えていただけますでしょうか

―　当行APIを利用してアプリケーションを開発するにあたり、良かった点・工夫した点を教えてください

―　API利用を始めたきっかけについて教えてください

―　今後のサービス展開を踏まえ、当行APIに期待することを教えてください

―　銀行APIの公開は一部分に留まっている現状を踏まえ、さらに銀行業界全体へ求めることは何ですか

―　さらに銀行APIの公開を進めるには、特にセキュリティ面が懸念されますが、どのような対策を考えていますか