第４回「次世代資金決済システム検討ワーキンググループ」 の模様
１．日 時

2022 年７月 22 日（金）10：00 ～12：00

２．場 所

ウェブ開催（Webex）

３．議 題(1) API ゲートウェイ利用見通しアンケート調査の結果等について(2) 第３回 WG 振り返り
(3) ベンダープレゼンテーション

４．議事内容「(1) API ゲートウェイ利用見通しアンケート調査の結果等について」においては、事務局から、加盟銀行宛に実施した同アンケート調査の結果の概要およびAPI ゲートウェイ費用負担ルールについて説明。
「(2) 第３回 WG 振り返り」においては、事務局から、第３回次世代資金決済システム検討ワーキンググループ（以下「次世代 WG」という。）におけるコメント等を紹介。
「(3) ベンダープレゼンテーション」においては、システムベンダー５社（NTTデータ、日本アイ・ビー・エム、日立製作所、BIPROGY、富士通）から、次世代資金決済システムのグランドデザインについてプレゼンテーションを実施。
(1) API ゲートウェイ利用見通しアンケート調査の結果等について
事務局説明概要（全銀ネット 安藤グループ長）
・ 加盟銀行宛の API ゲートウェイ利用見通しアンケート調査について、７月 20日時点でアンケートに回答した 112 行のうち、API ゲートウェイの利用を希望する可能性があると回答した先は 61 行であり、通常経費１・２（以下「主要経費」という。）の負担割合ベースでは 66％。希望しない先の多くは、自行側のシステム対応負担や移行リスクを重視。
・ 利用を希望する加盟銀行の利用時期について、API ゲートウェイ稼動当初（2024 年１月）からの利用希望はなし。第７次全銀システム期中（～2027年）の利用開始を希望する先は、61 行中 10 行であり、主要経費の負担割合ベースでは 3.3％。その他 51 行については、次期全銀システム以降または未定と回答。一部銀行では、すでに現行 RC の後継機である RC23 シリーズへの移行対応を進めており、自行側のシステム対応等を考慮すると、2024 年１月からの利用開始はハードルが高いと判断した模様。

1

・ API ゲートウェイに係る費用負担ルールについて、①利用者のみで按分負担、②一部を利用者で按分負担、一部を全参加者で按分負担、③全参加者で按分負担の３方針を想定しているが、RC の費用負担ルールとの公平性やアンケート結果を踏まえた負担感を考慮すると、方針②が望ましいか。ただし、RCから API ゲートウェイへの移行を順次図っていく（将来的には全参加者が利用）といった前提が満たされれば、方針③を採用することも納得感があるか。
質疑応答等
・ アンケート調査の結果について、現時点ではシステム対応負担や移行のシナリオが不明確であることから、回答が難しかった加盟銀行もいるのではないか。今後の検討においては、将来シナリオやロードマップを示すことが必要。
RC と API ゲートウェイの併存期間を設ける等の現実的なシナリオを示すことで、利用を希望しないと回答した加盟銀行においても利用に向けて再考を促す余地がある。
・ 費用負担ルールについて、各方針は一長一短があるなか、RC の費用負担ルールとの整合性等の観点から、方針②が現実的なルールとなるというのは理解できる。今後の議論に当たっては、各方針のフィージビリティの濃淡をつけて検討することが重要。（明治大学 小早川教授）
・ 現状、RFP 実施期間中であり、ベンダーの提案書がこれから示される予定であるなど、検討に必要な材料が出揃っていないなか、様々な仮定を置いたうえで回答しなければならないアンケートであったことから、加盟銀行からの回答は暫定的なものと理解。そうしたなか、利用希望時期は今すぐということではないものの、半数程度の加盟銀行が API ゲートウェイの利用を希望する可能性があると回答したということで、既存加盟銀行においても API ゲートウェイの導入は全く否定されるものではないと受け止めた。
・ アンケートで寄せられた声として、インターネット回線を利用した通信への懸念や、東京系・大阪系について別のタイミングにおける切替希望などがあるが、こうした問題への対処は可能か。（三菱 UFJ 銀行 石田調査役）⇒ 前者について、インターネット回線の利用を基本としつつも、加盟銀行から要望があれば、当該銀行においては閉域網での接続も可能とすることを RFP において求めている。後者について、整理によっては、東京系・大阪系いずれかの RC を先行して API ゲートウェイに切り替えることも可能と思料。（全銀ネット 安藤グループ長）
・ API ゲートウェイに移行する場合、既存加盟銀行の観点では、いかに安定的に移行するかということが重要であり、併存期間を設けて移行するシナリオ2を検討する必要があると思う。
・ 次期全銀システムにおける安定移行を見据えたときに、第７次全銀システム期間中から API ゲートウェイを構築し、スモールスタートとして接続実績を作っていくことは有益か。（全国銀行協会 委員会室 寺部上席調査役）⇒ 第７次全銀システム中に API におけるインターフェースと全銀システムとの機能的な連携を可能とすること、および、第７次全銀システムベースで商用稼動の実績を積み重ねることは、次期全銀システムに向けても有益である。API ゲートウェイの次期全銀システム以後の使用可否については、連携のあり方や構築の仕方次第である部分もあり、当社は現在入札対応中のベンダーの一社でもあるため、現時点で踏み込んだ回答は控えたい。（NTT データ 二木担当課長）
・ 仮に 2024 年１月から API ゲートウェイを稼動する場合、アンケート結果からは加盟銀行の参加は見込まれないことから、資金移動業者のみの参加となる可能性がある。こうしたなか、費用負担ルールの方針②を採用する場合、現行の RC 費用負担ルールと同様の割合で全行負担（２割）・利用者負担（８割）を設定することとなるのか。また、2024 年１月からの API ゲートウェイの稼動を決定するための参加者数の閾値などはあるか。（ワイズ・ペイメン
ツ・ジャパン 勢井ディレクター）⇒ API ゲートウェイの費用負担ルールに方針②を採用する場合でも、全行負担・利用者負担の割合は RC 費用負担ルールと一致させる必要は必ずしもない。方針②を採用する場合は、両割合を別途整理する予定。また APIゲートウェイの構築・稼動は、加盟銀行および資金移動業者双方のメリットを踏まえ検討するため、参加者数のみで 2024 年１月の稼動可否を決めることは難しいと思料。（全銀ネット 安藤グループ長）
・ 費用負担ルールについて、方針③は全銀 EDI システムの費用負担ルールと同様であるが、全銀 EDI システムと異なり、API ゲートウェイと RC はいずれか一方を利用すれば足りる性質のものである。このため、API ゲートウェイを利用しない加盟銀行にも負担を求める方針③を採用する場合は、強い理由づけが必要ではないか。（信金中金 今泉室長）⇒ 方針③については、将来的に全加盟銀行が API ゲートウェイを利用することを前提とした選択肢である。（全銀ネット 安藤グループ長）⇒ 全銀 EDI システムは、銀行界の共通インフラと位置づけ、加盟銀行の全銀 EDI システムへの接続を促し、銀行界として金融 EDI の実現を果たすという目的のもと、全加盟銀行負担とした背景がある。API ゲートウェイも同様の位置づけと整理することが可能である場合、方針③も納得感が3あるのではないかと考えたもの。（全銀ネット千葉企画部長）

・ アンケート結果にもコメントがあるとおり、加盟銀行によっては、API ゲートウェイで接続した銀行の事例を踏まえ、API ゲートウェイへの接続可否を検討するところもあると考えられる。銀行界として新たに取り組もうとする事項に対して、先行的に API ゲートウェイに接続していく加盟銀行への配慮という観点から、方針③をとるということや方針②としてもそれを踏まえて検討するということもあるのではないか。（全国銀行協会 委員会室 寺部上席調査役）(2) 第３回 WG 振り返り
事務局説明概要（全銀ネット 千葉企画部長）
・ 第３回 WG では、次期全銀システムにおける接続方法に関し、参加者側のシステム影響・システム開発費用も踏まえて検討を行うべき、API によるシステム間の結合が事実上標準的になっていることから将来的に API 接続は不可避である等のコメントがあった。
・ また、第３回 WG 後には、各メンバーから API ゲートウェイに関する意見・要望のほか、電文情報欄の一部コード化や使用可能文字の拡大、新ファイル転送の利用実態を踏まえた見直し、口座確認機能の実現方法、Request topay（支払リクエスト）の実装等に関する意見・要望が寄せられた。
(3) ベンダープレゼンテーション
NTT データ説明概要（NTT データ 二木担当課長）
・ 次期全銀システムのグランドデザイン策定には、技術動向（メインフレーム・オープン・クラウド、エンジニア）を踏まえた基盤技術の採用、利用者毎の機能選択、機能増減（付加価値機能追加／不要機能削除）、インターフェース（RC／API、テレ為替／新ファイル転送）の柔軟性向上が求められている。
ただし、全銀システムの変更は既存加盟銀行に与える影響も大きいことから、現時点における利用者毎のニーズの違いも踏まえ、変更時における長期のロードマップ、メリットの明確化、安全性やコストに関する十分な考慮が必要。
・ 接続方法は、システム連携のデファクトとなっている API に向かう方向性と認識。既存加盟銀行へ与える影響に鑑み、次期全銀システム時点では参加者毎の状況に合わせて選択できるかたち（参加者内システム間連携の API 化に合わせた対応等）が望ましく、現行インターフェース（RC 使用、コア・モア等）の維持と API の併存が必要。

4

・ 基盤技術は、全銀システムの持続性の観点、保守性・柔軟性・拡張性確保の観点から、次期全銀システムのタイミングでのオープン化が必要。
・ 業務要件／機能・非機能要求は、参加者・ニーズの多様化を踏まえた「インターフェースと業務機能の分離」や「機能分割・配置の最適化（疎結合化）」による柔軟性向上が必要。
日本アイ・ビー・エム説明概要（日本アイ・ビー・エム 金井部長）
・ 金融機関の全体システムとして、２つのタイプ（機敏性重視と高可用性重視）のシステムを融合し、進化する多様なフロントチャネルのサービスにも対応可能なアーキテクチャが求められるなか、次期全銀システムとして、これまでのミッションクリティカルなビジネスサービスレイヤーに加え、アジャイルを可能とするデジタルサービスレイヤーを中心に新しいテクノロジーを取り込むことを可能とした、ハイブリッドアーキテクチャーを提言。
・ 接続方法は、デジタルサービスエリアを中心に API 連携を前提とした基盤構築を行い、決済を中心とした API エコノミーを実現。
・ 基盤技術は、ミッションクリティカルエリアでは、安定稼動を維持しつつ、最新の開発手法、クラウドネイティブ技術を活用したモダナイゼーション（仮想 RC 接続、コア・モア統合等）を段階的に実施。また、アジャイルエリアを中心とした付加価値サービスをドライバーに、API 接続へのシフト化を加速。
・ その他、データサービス／AI サービスを活用した付加価値の提供も重要。
日立製作所説明概要（日立製作所 田中部長）
・ 次期全銀システムのグランドデザインを検討するうえで、「業務機能と基盤をどう組み合わせて最適化を図るか」がポイント。こうしたなか、ミッショ
ンクリティカル領域、基幹システム領域、非基幹システム領域の３領域を定義したうえで、各領域に合う基盤を整理し、業務機能をマッピングするアプローチを提案。
・ 次期全銀システムは将来像へ向けた過渡期と位置づけ、RC 接続から API 接続への段階的な移行を見据えた構成とすることが必要と考えられることか
ら、接続方法については、次期全銀システムでは RC 接続を継続しつつ、APIへの移行を誘導。
・ 基盤技術は、ホストのオープン化、パブリッククラウド化への移行を見据えた構成とすべき。一方で、オープン化への一斉移行のリスクを軽減するため、次期全銀システムでは、モアタイムシステムをオープン化し、段階的な移行5を検討。
・ その他、新規追加機能については、オープン／パブリッククラウド化の利用を前提とし、外部連携によるサービス利用も視野に入れて検討。パブリッククラウド化は、柔軟なリソースの追加・削減やコスト低減等のメリットがある。
BIPROGY 説明概要
（BIPROGY 日下シニアスペシャリスト）・ 接続方法は、次期全銀システムでは新たな決済手段・チャネルへの迅速な対応を可能とする API 接続を実現。
・ 基盤技術は、安全性・可用性の継承が求められるミッションクリティカルエ
リアと、拡張性が求められるアジャイルエリアに応じたオープンなものを選定。そのなかで、アジャイルエリアについては、クラウド化も検討。
・ その他、参加者にとって利用しやすい試験環境の構築が必要。
・ 実現に当たっての検討事項として、API で取り扱うメッセージ形式、全参加者 API 接続時の処理性能、API ゲートウェイ／全銀センタ間、オンプレミス／クラウド間のメッセージ連携・データ連携方式および新ファイル転送業務の取扱いがある。
富士通説明概要（富士通 中込氏）
・ 次期全銀システムにおいては、現状のメインフレームを中心としたシステム構成から、用途に応じた分散型システムへの変化が必要。こうしたなか、全ての機能が一枚岩的に絡み合っているモノリシックな構造から、業務単位、機能単位に分割された部品・API 化への移行を目指すべき。
・ 基盤技術は、ミッションクリティカルエリアは堅牢性確保の観点からオンプレミスをベースとし、アジャイルエリアは俊敏性・柔軟性・回復性の確保の観点からクラウドベースとする。
・ 業務／機能配置の考え方として、オンプレミスでは、堅牢性確保が必須となる機能、既存 OS やミドルウェアを使用する業務／機能および既存 COBOL 資
産を流用する業務／機能を配置し、クラウドでは、他システムとの連携（繋がりやすさ、広げやすさ）、更新頻度が高い業務／機能、日付や時間帯によって業務量の増減が発生する業務／機能およびデータ管理／トランザクシ
ョン管理が「互いに疎」となっている機能を配置することを検討。
質疑応答等
・ 接続方法について、API 接続がデファクトスタンダードとなるという各社か

6

らの大きなメッセージがあるなか、次世代 WG においてもこうした考え方に足並みを揃えて検討を進めることが必要。
・ 基盤技術について、多くのベンダーからオープン化、ひいてはクラウド化に向けた移行が提案され、その進め方として、アジャイルエリアを先行してオープン化する、あるいはミッションクリティカルエリアも含めてオープン化する等といった案が提示されたなか、それぞれの案について移行に向けたシナリオを設定したうえで、メリット・デメリットを検討することが望ましい。
（明治大学 小早川教授）
・ ベンダー各社からご説明いただいたグランドデザイン案の方向性は、これまでの次世代 WG で議論してきた方向性と一致していると受け止めている。
・ 日立製作所と富士通から、クラウド化することにより、柔軟なリソースの追加・削減が可能という説明があったが、どの程度柔軟に対応できるのか。例
えば、現状、用途が限定されている新ファイル転送について、２か月に１回の年金に係る電文送信時のみにリソースを追加するといった対応など、可能性としては想定され得るものか。（三菱 UFJ 銀行 石田調査役）⇒ まさにそういったリソースの追加を行っている。例えば、取引量やリソースの利用率等を監視して、その量や割合が閾値を超えたらサーバーを動的に追加するといったことを実施しているほか、新ファイル転送のようなバッチ的な処理が月末に固まるところへの対応として、月末のみ朝からサーバーを起動する台数を増やすといった対応を実施している。こうした柔軟な設計ができるのがクラウドの利点である。なお、取引量次第
では、クラウドベンダーにリソース利用計画をあらかじめ提示することが必要。（日立製作所 田中部長）
・ 現行ベンダーである NTT データでは、各機能の配置についてどのような見解を持っているか。（全銀ネット 千葉企画部長）⇒ 各機能のリアルタイム性、あるいは求められる非機能要件に応じて配置すべきと考えており、具体的には、根幹となるテレ為替、テレ為替よりリアルタイム性が低い新ファイル転送およびその他為替業務に付随する周辺業務の３つに切り分けて、それぞれの要求に応じて配置する場所を検討していくものと思料。（NTT データ 清水課長）
・ API 化、オープン化は共通のキーワードであると改めて実感。一方、インターネット回線を利用した通信のハードルの高さなどの懸念はある。既存の加盟銀行が抱いている不安や、現行システムから変えていくことのメリットについて、丁寧に検討し、既存の加盟銀行の考えとのギャップを埋めていくこ

7

とが重要。（みずほ銀行

小出調査役）・ 日本アイ・ビー・エムの説明において、コア・モアの統合が提案されていたが、統合するメリットは何か。
（全国銀行協会 委員会室 寺部上席調査役）⇒ テレ為替においてはコアとモアで同じ業務を実施しているため、別システム・別アプリケーションで運用するよりも、統合してより効率的なシステムにすることが重要という趣旨。
（日本アイ・ビー・エム 大島コンサルタント）
以

8上