2026.08.30 Webシステム

金融のシステム連携基盤｜EAI・ESBからAPI基盤へ移す判断と選定基準

金融機関でシステム同士をつなぐ仕組みを見直す場面では、連携そのものの設計より先に「どの基盤の上に載せるか」が決まらないまま議論が止まりがちです。十年以上動いてきたEAI製品を更改するのか、対外接続を担うAPI管理基盤を別に立てるのか、SaaS連携はクラウド型のサービスに寄せるのか。三つは併存もできる代わり、選び方を誤ると保守できる要員がいない基盤が一つ増えるだけで終わります。

この記事では、金融・保険のシステム連携基盤を四つの類型に分け、それぞれが得意とする接続先と費用構造、既存のEAI・ESBを置き換える信号と据え置いてよい信号、クラウド型を採る場合に契約と設計で確認する範囲を整理しました。電文やファイル伝送とAPIをどう併存させるかという連携方式そのものの設計は金融のデータ連携で扱っているため、ここでは基盤の選定と去就に絞ります。

まとめ：金融の連携基盤で先に決める4項目

結論を先に置きます。金融機関の連携基盤は、次の四点を決めた時点で候補が二つ程度に絞れます。

接続の本数と伸び方：現在の接続が20本未満で、今後3年に新規が数本しか見込めないなら、基盤を新設せず個別連携のまま据え置く判断が成り立ちます。40本を超えて相互に依存し始めた時点が、ハブを挟む検討の入口です。
対外接続の有無：電子決済等代行業者やフィンテック事業者を相手に外部公開するなら、行内のEAIとは別にAPI管理基盤を立てる前提で考えます。認証・流量制御・接続先ごとの監査証跡は、行内向けのハブに後付けしにくい機能です。
データを基盤に置くか通すだけか：連携基盤上に明細を保持する設計にすると、その基盤は勘定系に準じた保護対象へ格上げされ、外部委託の審査範囲も広がります。通過型に徹すれば、クラウド型サービスの選択肢が残ります。
維持する要員をどこに置くか：ノーコードで作れる基盤ほど、連携定義を書く人が現場に散り、数年後に誰も全体像を説明できない状態を招きます。定義の変更権限と棚卸しの担当を先に決めてください。

この四点のうち二つ以上が未確定なら、製品比較に入るのは早すぎます。順序としては接続の棚卸しが先で、基盤の選定はその後です。

金融の連携基盤が一般企業向け基盤と別物になる可用性・監査・配置の3条件

データ連携の考え方そのものは業種を問いません。ただ金融では、同じ「つなぐ」でも設置場所と審査の重さが変わります。一般企業向けの製品比較記事をそのまま持ち込むと、選定の後半で要件に落ちる事態が起きます。

点対点の連携が破綻する接続本数を経路数と保守費から見極める目安

システムを個別に一対一でつなぐ方式は、対象がn個あると理論上の経路数がn(n-1)/2に膨らみます。10システムなら45経路、20システムなら190経路という計算です。実際にすべてがつながるわけではないものの、勘定系・情報系・チャネル・外部の各系統に十数個ずつシステムが並ぶ規模の金融機関では、改修のたびに影響調査が数十本の経路に及ぶ状態へ容易に届きます。ハブを一つ挟めば経路はn本に落ちるという教科書どおりの効果が、この規模で初めて費用に見合ってきます。逆に接続が20本未満の信用金庫や少額短期保険の系統では、ハブの導入費と年間保守費が個別改修の費用を上回る場合が珍しくありません。

勘定系・情報系・チャネル系の境界ごとに連携基盤の置き場所を決める

銀行のシステムは勘定系システムを中核に、情報系、チャネル系という層に分かれています。連携基盤をどの層の境界に置くかで、要求される可用性がまるで変わります。勘定系と情報系の境界に置く基盤は、日次の締め処理が止まると翌営業日の業務に波及するため、停止時間の許容が数十分単位です。チャネル系と外部の境界に置く基盤では、24時間の受付を前提にした冗長構成が必要です。一つの基盤で両方を兼ねさせると、可用性の要求は高いほうに引きずられ、ライセンスも運用体制も上振れします。層ごとに基盤を分ける構成のほうが、結果として総額が収まる場合があります。

金融機関の監査と外部委託管理の要件を製品選定より先に定める理由

金融機関のシステムには、公益財団法人金融情報システムセンターが公表する安全対策基準が事実上の共通言語として存在します。第14版は2026年3月25日に公表され、AI・生成AIに関する指針の反映、サイバーセキュリティ関連の改訂、金融庁の2024年11月報告書を踏まえた耐量子計算機暗号への移行の留意点と対応時期などが盛り込まれました。連携基盤はデータの通り道であるため、暗号方式の移行やログの保全といった論点が正面から当たります。基準の全体像と対応範囲はFISC安全対策基準の解説に譲りますが、製品を選ぶ前に自組織の対応方針を決めておかないと、選定の最終段でクラウド型が丸ごと落ちるという手戻りが起こります。

連携基盤の4類型を費用構造・監査対応・得意な接続先で比較する

市場に並ぶ製品は名前も価格帯も幅がありますが、金融の文脈では次の四つに整理すると比較が進みます。API連携の基本的な仕組みを前提に、それぞれの守備範囲を見ていきます。

EAI・ESB型ハブが多様なプロトコルを1本で扱える条件と移行時の制約

固定長ファイル、全銀手順の通信、データベースへの直結、メインフレームの資源といった古い接続方式をアダプタで吸収できる点が、この類型の価値です。金融機関に残る連携の過半は今もファイルとデータベースであり、そこを扱えない基盤は候補になりません。難点は、連携定義が製品固有の形式で蓄積され、資産が数百本を超えると他製品への移行が現実的でなくなること。加えて、製品の実行基盤がオペレーティングシステムやミドルウェアの版に縛られるため、下位の更改に連動して基盤側も動かす必要が生じます。

API管理基盤が対外接続の権限・流量制御と証跡取得を担う理由

外部の事業者へインターフェースを公開するなら、この類型が担当します。接続先ごとの認証情報の発行、参照系と更新系での権限の切り分け、単位時間あたりの呼び出し回数の制御、誰がいつ何を呼んだかの証跡取得が標準機能として揃っている点が、行内向けハブとの違いです。銀行法第52条の61の11は電子決済等代行業者との接続に係る基準の作成と公表を銀行に求めており、公表した基準どおりに接続審査を運用できる仕組みが要ります。全国銀行協会が2017年7月13日に公表した検討会報告書以降に整備が進んだ領域で、参照系と更新系で審査の重さを分ける運用が定着しました。

iPaaSがSaaS連携に向く一方で金融機関では採否が割れる条件

クラウド上で提供される連携サービスは、営業支援や人事のSaaS同士をつなぐ用途で開発期間を大きく縮めます。金融でも情報系より外側、たとえば顧客管理と配信ツールの連携や、社内の申請フローの自動化では十分に候補です。一方で、連携の実行環境が事業者側にあるため、明細データが事業者の環境を通過する構成になります。ここで前述の「置くか通すか」の判断が効きます。製品ごとの機能差と選び方の一般論はAPI連携ツールの選び方にまとめてあるので、金融要件を足す前の下地としてそちらを参照してください。

内製ハブを構築できる要員条件と数年後も維持するための設計要件

メッセージキューとアプリケーションサーバを組み合わせ、自前で連携基盤を作る選択もあります。ライセンス費が不要で、要件に合わせた制御を書ける点が魅力です。成立条件は二つで、常時2名以上の設計者を維持できること、そして連携定義を設定ファイルとして外出しし、追加のたびにコードを書かなくて済む構造にしてあることです。この二つが崩れると、担当者の異動と同時に誰も触れない基盤が残ります。内製を選ぶなら、初期構築より運用引き継ぎの設計に工数を割いてください。

連携基盤4類型を初期費用・接続先・監査対応・必要要員で比較する

類型	得意な接続先	初期費用の傾向	監査証跡	必要な要員
EAI・ESB型ハブ	ファイル・DB・電文・レガシー資源	ライセンス＋構築で中規模以上	製品標準の実行ログ	製品固有の設計者
API管理基盤	外部事業者・自行アプリ	中規模、接続数で変動	接続先別に標準装備	認証・公開設計の担当
iPaaS	SaaS同士・情報系の周辺	初期は小さく月額課金	事業者の提供範囲に依存	業務側の定義作成者
内製ハブ	要件を絞った行内連携	人件費が主、可視化しにくい	自前で実装が必要	常時2名以上の設計者

四つのうち一つに寄せる必要はありません。行内の重い連携はEAI型、対外はAPI管理基盤、周辺のSaaSはiPaaSという三層構成は、金融で現実的な落とし所の一つです。

既存のEAI・ESBを移す信号と据え置く信号を費用・期限から見分ける

更改の議論は「古いから」という理由で始まりがちですが、稼働年数だけでは判断材料になりません。移すべき状態と、あと数年動かしてよい状態は、次の指標で見分けられます。

EAI・ESBを移す判断につながる保守期限・改修待ち・費用の3つの信号

一つ目は、実行基盤のサポート期限です。連携基盤が載るオペレーティングシステムやデータベースの保守期限が2年以内に来るなら、基盤側の移行も同じ計画に載せたほうが総額は下がります。二つ目は、改修の待ち行列です。連携定義の追加や変更で3か月待ちが常態化しているなら、製品の制約ではなく設計者不足が原因であり、扱える人が多い方式へ寄せる価値が出ます。三つ目は、年間保守費に対する接続本数です。1接続あたりの年額が数十万円規模に膨らんでいるなら、費用対効果の説明が難しくなります。この三つのうち二つが当たれば、更改を計画に載せる段階と判断できます。

既存のEAI・ESBを据え置いてよい状態を接続数と更改時期で見分ける

反対に、次のいずれもが当てはまるなら、今回は据え置きが合理的です。接続本数がこの3年で増えていない。連携している基幹側が3年以内に更改を控えていて、そこで連携要件が作り直しになる。年に数回しか定義を変更していない。基幹側の更改とタイミングを合わせれば、連携基盤の移行費は基幹の移行計画に吸収でき、二度の並行稼働を避けられます。単独で先に基盤だけ入れ替えると、基幹更改のときに新基盤の定義をもう一度書き直す羽目になります。

全面置換を避けて新規分だけ寄せる二重運用で終了期限を設計する方法

既存の定義を数百本まとめて移すのは費用も検証も重くなります。実務では、既存はそのまま動かし、新規の連携だけ新基盤で作るという分割が採られます。この方式の落とし穴は、期限を切らないと二重運用が固定化する点です。両基盤の保守費が積み上がり、どちらに定義があるか分からない状態が生まれます。分割を選ぶなら、旧基盤に残す定義の本数を年ごとに減らす目標値と、旧基盤を止める期日、そして期日を延ばす場合の決裁者を、開始時点で文書に残してください。合併・再編に伴う統合で連携方式を選ぶ場合の考え方は金融機関のシステム統合で扱っています。

クラウド型の連携基盤を金融で採用するときに契約と設計で確認する範囲

クラウド型を頭から除外する必要はありません。ただ確認の順序を間違えると、選定の後半で覆ります。契約と設計の両面で見る点を挙げます。

クラウド連携基盤が通過型か蓄積型かによって委託先審査が変わる理由

連携サービスの環境に明細データが残るかどうかが分岐点です。処理の途中でメモリ上を通過するだけで、再送用の保持もしない構成なら、預けるデータの範囲は限定的だと説明できます。一方、エラー時の再送や突合のために数日分のデータを事業者側に保持する構成にすると、その基盤は保護対象のデータを扱う外部委託先として審査されます。後者を選ぶなら、暗号化の方式、鍵の管理主体、保持期間、削除の証明方法を仕様として押さえてください。前者に寄せると再送設計を自組織側で持つことになるため、運用の手間との交換になります。

クラウド連携基盤の委託先管理で確認する再委託・監査権・終了時の条項

クラウド型のサービスは、事業者がさらに基盤事業者を使う多段構造になっています。契約では、再委託先の開示、監査に応じる範囲、障害時の報告義務と時限、サービス終了時のデータ返還と削除の手順を確認します。監査については、個社での立入監査に応じる事業者は限られるため、第三者による保証報告書の提出で代替する運用が一般的です。どの保証報告書をもって自組織の点検が完了したとみなすかを、情報システム部門とリスク管理部門で先に合意しておくと、選定の終盤で止まりません。

クラウド連携基盤の可用性を連携先の締め時刻から逆算して決める方法

サービス水準の数値だけを見比べても、金融の要件には答えられません。見るべきは、連携が止まって困る時刻がいつかという点です。日次の勘定処理へ受け渡すファイルに締め時刻があるなら、その前後の時間帯に復旧できる体制かどうかが判断材料になります。年間の稼働率が高くても、復旧の連絡が翌営業日になる契約では締めに間に合いません。事業者の窓口が日本語で当日中に応答するか、障害時の一次切り分けを誰が担うかまで含めて、締め時刻から逆算して確認してください。

接続の棚卸しから着手し連携基盤の導入を見送る条件まで判断する手順

ここからは、発注側の判断としてどう進めるかを言い切ります。製品選定から入る進め方は、金融ではまず失敗します。

連携基盤の着手順を接続の棚卸し・方式の標準化・製品選定で組み立てる

最初にやるのは接続一覧の作成です。送信元、受信先、データの種類、方式、頻度、件数、締め時刻、障害時の連絡先を1行ずつ埋めます。この作業だけで、想定の1.5倍から2倍の接続が出てくるのが通例で、その差分こそが基盤の要件を決める材料です。次に、洗い出した接続を方式ごとにまとめ、「日次ファイルはこの形式」「参照系APIはこの認証」といった標準を数本に絞ります。標準が決まって初めて、製品がその標準を素直に実装できるかという観点で比較ができます。棚卸しを飛ばして製品を決めると、選定後に「その方式は追加ライセンス」という話が出る結果です。業種横断の連携パターンの型はデータ連携の事例に整理してあります。

連携基盤を見送る条件を接続本数・処理件数・基幹更改時期で判定する

次の三条件がすべて当てはまるなら、今回は基盤を導入せず、個別連携の整理にとどめる判断を推奨します。第一に、現行の接続が20本未満で、今後3年の新規が5本以内であること。第二に、日次の連携件数が最大でも数万件規模で、処理時間が締め時刻に対して余裕を持っていること。第三に、連携相手の基幹システムが3年以内に更改を控えていること。この状態で基盤を入れても、削減できる改修工数より年間保守費のほうが大きくなりやすく、しかも更改時に定義を書き直します。代わりに、接続一覧の整備とファイル形式の統一だけ先に済ませておけば、更改の際にそのまま基盤の要件定義として使えます。

連携基盤の発注側に残す権限と外部へ委託する実装・運用範囲を分ける

連携基盤は作って終わりではなく、定義が増え続ける資産です。発注側に残すべきは、接続一覧の維持、方式の標準を決める権限、そして連携定義の変更を承認する役割の三つ。ここを外に出すと、数年後に自組織の連携全体を説明できる人がいなくなります。委託に向くのは、基盤の設計と構築、既存定義の移行、監視と障害一次対応、そして標準に沿った新規定義の実装です。金融の連携は相手先の都合で仕様が動くため、要件の窓口を発注側に残したまま実装を外に出す形が続けやすい構成になります。既存のEAI資産を抱えたままAPI基盤を並走させる構成の設計や、勘定系・情報系の境界に置く連携の構築については、API開発・システム連携で相談を受け付けています。

保険会社の連携基盤で銀行と前提が変わる契約期間・接続先・即時性

保険では、連携の中心が入出金ではなく契約と保全の情報に移ります。契約は数十年続くため、旧商品を扱う古い契約管理システムが現役で残り、そこからの連携は参照専用のファイル出力だけという構成が珍しくありません。代理店やチャネルとの接続本数が銀行より多くなる一方、即時性の要求は相対的に緩く、日次バッチで足りる領域が広い点も違いです。結果として、対外向けのAPI管理基盤より、多数の代理店とのファイル授受を捌けるEAI型の比重が高くなる傾向があります。基盤を選ぶ前に、代理店との接続本数と授受の頻度を数えてください。

よくある質問

連携基盤の導入にはどれくらいの期間がかかりますか？

接続一覧の棚卸しに1か月から2か月、方式の標準化と製品選定に2か月から3か月、基盤の構築と最初の数本の移行に3か月から6か月というのが、接続数十本規模での目安になります。既存定義を数百本まとめて移す場合は、移行だけで1年を超えることもあります。期間を短くしたいなら、対象を新規連携に絞る分割が現実的です。

EAI製品とiPaaSはどちらを選ぶべきですか？

つなぐ相手で決めます。固定長ファイル、データベース直結、電文といった行内の古い方式が半数以上を占めるならEAI型です。相手がSaaS中心で、扱うデータに明細が含まれないならiPaaSが向きます。判断に迷う場合は、接続一覧を方式別に集計し、多いほうへ寄せてください。両方が3割ずつなら、無理に一本化せず併存させる構成のほうが総額は収まります。

クラウド型の連携サービスは金融機関でも使えますか？

使えます。ただし、預けるデータの範囲と保持の有無で審査の重さが変わります。明細を事業者側に残さない通過型なら説明の負担は軽く、再送用に保持する構成なら外部委託先としての点検が必要です。第三者の保証報告書で監査を代替できるか、再委託先の開示に応じるかを、契約の段階で確認してください。

連携基盤を入れると開発費はどのくらい下がりますか？

接続本数と改修頻度に依存するため、一律の数値は出せません。判断材料としては、直近3年の連携関連の改修費を集計し、基盤の年間保守費と比べる方法が分かりやすい方式です。改修費の3割程度が影響調査と個別の作り込みに消えているなら、ハブ化の効果が見込めます。改修が年に数件しかないなら、費用の回収は難しくなります。