金融のデータ連携｜行内3層と対外3経路の切り分け・電文とAPIの併存設計【2026年版】

金融のデータ連携という言葉は、行内で勘定系から情報系へ数字を渡す話と、銀行と外部事業者をAPIでつなぐ話と、企業が銀行へ振込データを送る話を、同じ名前で呼んでいます。仕様を決める主体は3つとも別で、設計前に読む資料も別。本記事では、勘定系と情報系を分けたまま連携する受け皿の置き方、固定長電文とZEDIのXML電文とファイル伝送とオープンAPIの使い分け、監査ログと権限の要件が方式を絞り込む構造を扱います。API連携という言葉の一般的な定義とデータ連携との使い分けはAPI連携の仕組みとデータ連携との違いを整理した解説に譲り、ここでは金融機関と金融系システムを持つ企業の判断だけを扱います。

まとめ：金融のデータ連携で先に決める4項目と着手の順序

先に決めるのは4項目です。つなぐ相手が行内なのか、対外の事業者なのか、当局への報告なのかという方向。勘定系から切り出すデータの粒度と時点。方式を固定長電文・ZEDIのXML電文・ファイル伝送・APIのどれに置くか。そして監査ログと権限をどう分けるか。この4つが決まれば、見積りの前提はほぼ固まります。

方向が変われば決定権の所在も変わります。行内は自社で仕様を決められますが、対外接続では相手の金融機関が公表している接続基準が先に立ちます。銀行法は銀行に対し、電子決済等代行業者へ求める事項の基準を作成して公表するよう定めており、設計前に読む対象はこの基準です。当局向けの報告は、共同データプラットフォームによる定期的なデータ収集が令和6年度に本格開始しており、情報系側に別枠の出口が要ります。

着手の順序は、コード体系とマスタの整備、情報系の受け皿の構築、対外接続、当局向け報告の順です。この順を飛ばして対外APIから入ると、行内で名寄せできない数字を外へ出す結果になりかねません。接続本数が少なく月間件数も小さい規模なら、着手をいったん見送る判断のほうが妥当な場面もあります。

行内・対外・当局向けの3方向で変わる金融データ連携の決定権の所在

金融のデータ連携を設計するとき、最初に切るのは技術ではなく方向です。方向ごとに、仕様を決める主体と、動かせない前提が変わります。

行内で自社が仕様を決められる範囲と、勘定系から渡す粒度と時点の固定

行内の連携は、チャネル系が受け付けた取引を勘定系が確定させ、その結果を情報系が引き受けるという流れで動きます。この3層の役割分担と勘定系そのものの守備範囲は勘定系システムの三層構造と情報系との違いを整理した解説で扱っているため、ここでは連携の側だけを見ます。

行内で自社が決められるのは、勘定系から情報系へ何をどの単位で渡すかです。明細1件ごとに渡すのか、日次の集計値だけ渡すのか。渡す時点を締め処理の直後に置くのか、翌営業日の朝に置くのか。この2つを先に紙で確定させておかないと、後から粒度を上げる改修が勘定系側の負担として跳ね返ります。

対外接続は相手の基準が先に立つ：銀行が公表する接続基準を読む順序

対外接続では、自社が設計を始める前に相手側の条件が決まっています。銀行法第52条の61の11は、銀行に対し、電子決済等代行業者との契約締結にあたって求める事項の基準を作成し、インターネットの利用その他の方法により公表するよう定めています。つまり接続先の銀行のサイトには、求められるセキュリティ水準や体制の条件が先に載っているはずです。

この構造を知らずに設計から入ると、後戻りが発生します。相手の基準に「特定の認証方式に対応していること」「事故時の連絡体制を置くこと」といった条件が書かれていれば、それは要件定義の入力であって交渉の対象ではありません。同法第52条の61の10第3項は、締結した契約の内容のうち所定の事項を銀行と事業者の双方が公表するとも定めており、条件は原則として外から読めます。

当局向け報告が連携要件に加わる場面と共同データプラットフォームの位置

金融機関の場合、連携の出口は行内と対外だけではありません。金融庁と日本銀行は、モニタリングの質を上げつつ金融機関の負担を減らす目的でデータの一元化を進めており、2025年8月1日の公表によれば、令和6年度に共同データプラットフォームの構築が完了し、定期的なデータ収集が本格的に始まっています。

ここで効いてくるのは、報告用のデータが情報系の側から出るという構造です。勘定系から情報系へ渡す粒度が粗いと、報告のたびに勘定系へ問い合わせる運用が残ります。行内の粒度設計は、分析だけでなく報告の要件からも逆算しておく必要があります。

勘定系と情報系を分けたまま連携するための受け皿の置き方と更新間隔の決め方

金融の連携設計で最も費用を左右するのは、勘定系に触れるかどうかの線引きです。ここを緩めると、後続の全工程で審査と試験の負荷が上がります。

勘定系から直接読ませない原則と、情報系に複製を置くときの切り出し単位

分析用途や外部連携のために勘定系のデータベースへ直接接続する構成は、原則として採りません。勘定系は1件ごとの整合性を担保する仕組みであり、参照系の負荷が本番の応答時間に影響する構造だからです。加えて、勘定系に接続する経路が増えるほど、更改時に張り替える接続点も増えます。

実務上の形は、勘定系から切り出した複製を情報系側に置き、以降の連携をすべてその複製から始める構成です。切り出し単位は取引明細・残高・顧客属性の3系統に分けます。系統ごとに更新間隔も持ち出し可否も違うためです。

クラウド上の分析基盤へ載せる場合は、データの所在や鍵管理の設計が別の検討軸として立ち上がります。この部分はBigQueryを金融・保険で使う判断とDWH移行の範囲を整理した記事で扱っているため、本記事では複製をどこに置くかまでに留めます。

即時が要る業務と日次で足りる業務を分ける、更新間隔の決め方の基準

更新間隔を決める基準は、その業務が止まるかどうかの一点です。窓口やアプリで残高を見せる用途は即時が要りますが、収益分析や与信のモニタリングは日次で足ります。全銀システム側も、平日日中のコアタイムシステムと、平日夜間・土日祝日に対応する2018年10月稼働のモアタイムシステムに分かれており、即時入金という前提自体が時間帯で設計されています。

ここで避けたいのは、一部の業務が即時を要求するからという理由で、連携全体を即時に寄せる設計です。即時にすると再送設計・順序保証・障害時の巻き戻しがすべて重くなり、費用は日次バッチの数倍に振れます。即時が要る系統だけを切り出し、残りは日次に落とすほうが総額は下がります。

件数と金額の二重突合をどこに持たせるか：連携基盤と業務側の分担

金融の連携では、渡した件数と金額が一致していることを機械的に確かめる仕組みを必ず入れます。送信側の件数合計と受信側の件数合計、送信側の金額合計と受信側の金額合計を突き合わせ、差異が出たら止める設計です。照合という作業そのものの意味と実務についてはリコンサイルの意味と照合実務を整理した解説に整理があります。

分担の考え方はこうです。件数と金額の一致という機械的な検査は連携基盤側に持たせ、内容の妥当性を見る業務的な突合は業務システム側に残します。連携基盤に業務ロジックを持ち込むと、業務の変更のたびに基盤側の改修と再試験が必要になり、保守が止まらなくなります。その連携基盤そのものをEAI・ESB型／API管理基盤／iPaaS／内製ハブのどれで用意するかは、金融のシステム連携基盤で類型別に整理しています。

差異が出たときの扱いも先に決めます。自動で再送するのか、担当者へ通知して止めるのか。金額が絡む連携では、黙って再送する設計は二重計上の温床になります。止めて人が見る、が金融では原則です。

電文とファイル伝送とAPIが併存する金融の連携方式と使い分けの判断軸

金融の連携方式は、古い方式が消えないまま新しい方式が積み重なる構造をしています。どれか1つに寄せるのではなく、どこに何を使うかを決める作業です。

全銀フォーマットの固定長電文とEDI情報欄20桁の制限が効く業務の範囲

企業から銀行へ総合振込のデータを送る経路は、長らく固定長の電文形式が主流でした。全銀ネットの説明によれば、この従来フォーマットでは、支払金額や受取人名のほかに付加できるEDI情報が20桁までという制限があります。20桁では請求書番号を1件分入れるのが限界です。

この制限が実務に効くのは、入金消し込みの場面です。複数の請求をまとめて1回で振り込まれると、どの請求に対する入金かが20桁に収まらず、受取側が手作業で当てにいく運用が残ります。売掛管理の担当者が月初に数日かけて突き合わせる作業は、この桁数制限に由来します。

企業間の電子データ交換そのものの仕組みや、通信手順の移行問題はEDIの仕組みと2024年問題後の移行判断を整理した記事で扱っています。本記事では金融機関との接続に絞ります。

ZEDIのXML電文で消し込みまで届く条件と会計ソフト側に必要な対応

全銀EDIシステム（ZEDI）は、この20桁制限をXML形式の電文に置き換えることで外す仕組みです。全銀ネットは金融EDI情報の標準として、デジタルインボイス標準仕様のJP PINT／JP BISに対応した「DI-ZEDI」を制定しており、項目定義とサンプルXMLも公開しています。

ただし、ZEDIに対応すれば消し込みが自動になるわけではありません。条件は3つあります。支払企業側がZEDIに対応したXML形式で振込電文を作れること。取引金融機関がZEDIに接続していること。そして受取企業側の会計ソフトが、届いたXML形式の振込入金通知や入出金明細を読み込めること。3つが揃って初めて、請求番号が入金データまで届きます。

相手企業が対応していない場合、自社だけがZEDIに対応しても効果は出ません。導入判断では、取引先のうち何社が対応しているかを先に数えます。上位10社で入金件数の大半を占めるなら、その10社と個別に話す価値は十分です。取引先が細かく分散しているなら、消し込み側の自動化を別の手段で組んだほうが早く効きます。

ファイル伝送とインターネットバンキングで分かれる証明書と運用の負担

企業と銀行の間の経路は、大きく一括ファイル伝送とインターネットバンキングに分かれます。ZEDIの場合、一括ファイル伝送での利用にはクライアント証明書が必要になると全銀ネットが案内しており、証明書の取得・配置・更新という運用が発生します。

証明書には有効期限があるため、更新を忘れると振込が送れなくなります。担当者が1人で持っている状態は事故のもとです。期限管理を仕組みに載せ、更新作業の手順書と代替担当を置いておく。ここは技術の話ではなく運用設計の話ですが、止まったときの影響は資金繰りに直結します。

オープンAPIの参照系と更新系で審査の重さが変わる理由と登録の要否

銀行のAPIには、残高照会や入出金明細の取得といった参照系と、振込などの指示を出す更新系があります。この2つは審査の重さが別物です。更新系は資金が動くため、接続にあたって金融機関側が求める体制の条件が厚くなります。

制度面では、銀行と契約して顧客の口座情報を扱う事業を営む場合、電子決済等代行業者としての登録が必要です。金融庁の登録一覧では、2026年7月31日現在で125社が登録されており、うち関東財務局管轄が109社を占めます。最初の登録は2018年9月26日で、制度が始まってから8年ほどで100社台という水準です。

自社サービスの中で顧客の銀行口座情報を扱うなら、この登録の要否を法務と先に確認します。判定を後回しにしたまま開発を進め、リリース直前で止まる例があります。判定は設計より前に置く工程です。決済そのものを自社で組むか代行事業者に寄せるかという別軸の判断は決済システムの仕組みと決済代行との接続方式を整理した記事にまとめています。

4方式の比較：即時性と改修範囲と相手先都合と保守負担で決める使い分け

4方式を並べると、選ぶ軸が即時性だけではないことが見えます。相手先の都合で決まる部分が大きいのが金融の連携の特徴です。

読み方はこうです。改修範囲が小さい順に検討し、業務上どうしても即時が要る系統だけをAPIに寄せる。ZEDIは取引先の対応状況しだいで効果が変わるため、単独で判断せず取引先の分布とセットで見る。ツールで組むか受託開発で作るかという構築方式の分岐はAPI連携ツールとデータ連携基盤と受託開発の使い分けを整理した記事に判断軸があります。

監査ログと権限の要件が金融のデータ連携で方式を先に絞り込む理由

金融の連携設計が他業種と決定的に違うのは、誰が何を見たかを説明できる状態を保つ義務が前提にあることです。この要件は、方式の選択肢そのものを削ります。

誰がどのデータを見たかを残す粒度と、連携基盤に持たせるログの項目

連携基盤に残すログは、処理が成功したかどうかだけでは足りません。いつ、どの経路で、どの範囲のデータが、どこへ渡ったか。この4項目が揃っていないと、後から照会があったときに答えられません。処理ログと監査ログは別物として設計します。

項目としては、実行日時・実行主体・対象データの範囲を示す識別子・件数・送信先・結果コードの6つを最低線に置きます。個人を特定できる値そのものをログに書くのは避け、識別子で追える形にしておく。この設計を後から入れるのは、既存の連携定義をすべて触ることになるため高くつきます。

本番データを取り出す権限と連携定義を変える権限を分ける運用の作り方

権限は2つに分けます。本番データを取り出せる権限と、連携定義そのものを変更できる権限です。この2つを同じ人が持つと、定義を書き換えて本来渡らないはずのデータを外へ出す経路が、記録上は正規の処理として通ってしまいます。

分離の形はシンプルです。定義の変更は申請と承認を経て反映し、反映作業を行う担当者はデータの中身を見られない。データを見る担当者は定義を変えられない。開発ベンダーに定義変更を委託する場合は、本番データへの到達経路を持たせない構成にします。

銀行法第52条の61の11が求める基準の公表と、設計に入る前の確認順序

対外接続を含む案件では、相手の金融機関が公表している接続基準が要件定義の入力になります。銀行法第52条の61の11が銀行に基準の作成と公表を課している以上、その内容は設計前に読める状態にあります。読まずに設計するのは、仕様書を受け取らずに作り始めるのと同じです。

確認の順序は、接続候補の基準を読む、自社の体制で満たせない条件を洗い出す、満たすための施策と費用を見積もる、そのうえで接続先を決める、の4段です。体制条件は開発費ではなく運用費として効いてくるため、初期費用だけで比べると判断を誤ります。

ここで「基準を満たせないので接続をやめる」という結論が出るのは失敗ではありません。設計と実装に入る前に出たのなら、むしろ安く済んだ判断です。

金融のデータ連携を段階導入する順序と、着手を見送ってよい規模の線引き

最後に、どこから手を付け、どこで手を止めるかを具体的に決めます。全部を一度に組む計画は、金融では特に外れます。

着手順はマスタ整備から：コード体系をそろえる範囲と情報系の受け皿

順序の先頭はマスタとコード体系です。顧客コード・店番・勘定科目コードが系統ごとに違う状態で連携を組むと、変換表が連携定義の中に埋め込まれ、誰も触れない資産になります。変換は連携基盤の外に、更新できる表として持ちます。

次が情報系の受け皿です。勘定系から切り出した複製を置き、そこを起点に分析・報告・対外連携のすべてを組む。受け皿ができていれば、後から出口が増えても勘定系側は触りません。業種をまたいで連携の型を整理したデータ連携の6つの型と効果指標の置き方をまとめた記事では、この「分析基盤へ集約する型」を他業種の事例と並べて扱っています。

対外接続はその後です。当局向けの報告は、情報系の受け皿から出す経路として最後に設計します。この4段を守れば、途中で止めても資産は残ります。実際の金融機関がどの層から投資したかは金融DXの事例｜銀行・証券・保険の実装を4軸で分解し自社へ外挿する手順で業態別に整理しています。

見送ってよい条件：接続本数と月間件数と次期更改時期で引く3つの線

着手を見送ってよい条件を、条件付きで言い切ります。1つ目は接続本数です。つなぐ先が2本以下で、片方が月次のファイル受け渡しに収まっているなら、連携基盤を建てる費用は回収できません。表計算と手順書で運用したほうが安く済みます。

2つ目は月間件数です。手作業で転記している件数が月に数百件程度で、担当者の作業時間が月10時間に届かないなら、自動化の効果は基盤の保守費に食われます。この規模なら、連携より先に入力フォームの見直しで削れる作業を探すほうが効きます。

3つ目は次期更改時期です。勘定系や基幹系の更改が2年以内に控えているなら、現行システムに合わせた連携を作り込むのは投資として合いません。更改の要件定義に連携要件を織り込み、そこで一度に組むほうが総額は下がります。ただし更改の時期が未定のまま3年以上動いていない場合は、待たずに情報系側だけ先に建てます。

勘定系本体を内製に残し、境界と情報系を外注に出すときの責任の分け方

外注の線引きは、勘定系本体とその外側で引きます。勘定系本体の改修を丸ごと外へ預けると、障害時の切り分けができる人が社内に残りません。一方で、情報系の受け皿・連携基盤・対外接続の実装は、金融の要件を理解している外部に任せられる領域です。

委託時に契約書へ書いておくのは、接続試験の合格条件です。件数と金額が一致すること、異常系で止まること、ログに所定の6項目が残ること。この3つを合格条件として数値と項目で書いておけば、受け入れの判断が主観になりません。一創では金融システム開発として、勘定系の外側にあたる情報系・連携基盤・対外接続部分の設計と実装を受託しています。

他業種でも、階層を分けて境界を委託する形は同じです。設備から基幹までを階層で切り分けた製造業のデータ連携における階層別インタフェース設計や、社内と企業間を分けた物流のデータ連携の二層設計は、金融の3方向の切り分けと構造が重なります。

よくある質問

金融のデータ連携について、発注前の相談で繰り返し出る質問をまとめます。

金融機関のデータ連携にかかる費用はどれくらいですか？

費用は接続本数と方式でほぼ決まります。既存の固定長電文を流用してファイル受け渡しを組むだけなら小規模に収まりますが、オープンAPIで更新系につなぐ場合は、開発費より体制整備と接続基準への対応に費用が寄ります。見積りを比べるときは、証明書の更新・ログの保存・接続基準の維持といった運用費を5年分の総額で並べてください。接続本数が増えるほど、運用費の比率が上がります。

勘定系のデータをそのまま分析基盤へ流してもよいですか？

勘定系のデータベースへ直接つなぐ構成は避けます。参照の負荷が本番の応答に影響する点と、勘定系の更改時に接続点をすべて張り替える必要がある点の2つが理由です。日次などの間隔で切り出した複製を情報系側に置き、分析基盤はその複製を読む構成にします。取引明細・残高・顧客属性の3系統に分けておくと、権限設計と持ち出し可否の判断が楽になります。

ZEDIに対応すると入金消し込みは自動になりますか？

自動になるかどうかは、取引先の対応状況で決まります。支払企業がZEDIに対応したXML形式で振込電文を作り、取引金融機関がZEDIに接続し、受取企業の会計ソフトがXML形式の入金通知を読み込める。この3つが揃って初めて請求番号が入金データまで届きます。自社だけが対応しても、支払側が固定長電文で送ってくれば20桁の制限は残ります。入金件数の上位を占める取引先が何社対応しているかを先に数えてください。

銀行のオープンAPIを使うには登録が必要ですか？

銀行と契約して顧客の口座情報を扱う事業を営む場合、電子決済等代行業者としての登録が必要になります。金融庁の登録一覧では2026年7月31日現在で125社が登録されています。自社の従業員が自社の口座を操作するだけの利用と、顧客の口座情報を預かって提供するサービスとでは扱いが変わるため、要否の判定は設計前に法務へ確認する工程として置いてください。

保険会社のデータ連携も銀行と同じ考え方でよいですか？

方向の切り分けと、基幹系に直接つながない原則は同じです。違うのは対外接続の相手で、保険では代理店システムや募集の記録が連携の中心になります。募集記録の電子化から基幹刷新までの順序は保険DXの着手順を判断基準で整理した記事にまとめています。監査ログと権限の分離という要件は、銀行と同じ水準で設計してください。

関連記事

• 勘定系システムとは？三層構造と情報系との違い・オープン化の判断を解説：連携の起点になる勘定系そのものの守備範囲と刷新判断を扱っています。
• BigQueryを金融・保険で使う判断｜規制要件と勘定系連携・DWH移行：分析基盤側のデータ所在・鍵管理・移行範囲の判断です。
• データ連携の事例：6つの型と業種別の制約・効果指標の置き方：業種をまたいだ連携の型と効果の測り方を整理しています。
• 医療のデータ連携｜院内4方式と地域連携の構成・電子カルテ更新時の移行判断【2026年版】：規格が方式を先に決める業種での切り分け方です。
• 保険DXとは？募集記録の電子化から基幹刷新までを着手順で決める判断基準【2026年】：保険側の着手順と基幹刷新の判断を扱っています。