2026.08.30 Webシステム

金融機関のシステム統合｜片寄せ・新設・連携の方式選択と移行検証の進め方

合併や経営統合が決まった金融機関で、最後まで工程表の制約になるのがシステム統合です。銀行なら勘定系、保険なら契約管理を軸に、チャネル系と情報系、外部接続まで含めると統合対象は数百の業務単位に及びます。この記事では、片寄せ・新設・データ連携という三つの方式をどの条件で選び分けるか、勘定系のデータ移行と並行稼働をどう組むか、移行リハーサルを何回どの規模で回すかを、金融庁が示す着眼点とFISC安全対策基準の改訂内容に沿って整理します。過去に大規模障害を起こした案件から逆算した検証項目と、切戻しに踏み切る判断基準まで扱う構成です。

まとめ：金融のシステム統合で先に決める方式と検証の優先順位

方式選択の分かれ目は一つしかありません。存続させる側のシステムが、消滅する側の商品性と事務フローをパラメータ設定の範囲で吸収できるかどうか。吸収できるなら片寄せが最短で、実際に三菱UFJ銀行は三菱銀行のシステムへ、三井住友銀行は住友銀行のシステムへ寄せました。商品体系が離れていて大規模改造が要るなら新設（全面再構築）に振れますが、期間は3年以上、費用は片寄せの数倍まで跳ね上がります。データ連携は統合ではなく時間稼ぎの手段で、終了期限を決めずに始めると二重運用が固定化します。

進め方で成否を分けるのは、設計の巧拙より検証の量です。移行リハーサルは本番同等データで最低3回、うち1回は切戻しまで通し、判定基準と中断条件を事前に文書化しておく。統合直後に保守要員を減らさず、旧仕様を知る人員を最低1年は残す。この2点を削った案件が、後から障害と行政処分の形で費用を払っています。金融庁の検査マニュアルは2019年に廃止済みですが、統合リスクの着眼点は別文書として残り、監督上の期待水準は下がっていません。

金融機関のシステム統合が通常のシステム移行と別物になる4つの制約

一般の基幹システム移行と同じ段取りで見積もると、金融の統合案件は破綻します。停止できない時間帯、勘定の一円単位の一致、外部の決済網との接続、監督当局への説明責任。この4点が工程と体制の形を変えます。

勘定系・情報系・チャネルに分かれる統合範囲と依存関係の見取り図

統合対象は一枚岩ではなく、性格の違う三つの層に分かれます。中核は預金・為替・融資を処理する勘定系で、ここが統合の主戦場になります。その上に営業店端末・ATM・インターネットバンキングといったチャネル系が乗り、横に情報系とリスク管理系が並ぶ構造です。層ごとの中身は勘定系システムとは？三層構造と情報系との違いで個別に整理しています。

統合計画を引くときは、この依存の向きを逆に読みます。勘定系のデータ構造が決まらないとチャネル系の画面項目が固まらず、情報系のマート定義も動かせません。勘定系を先に決め、チャネル系を後追いさせる順序を崩すと、営業店の事務手順書とマニュアルを二度作り直すことになります。

顧客番号と商品コードの重複が名寄せ工数を膨張させる典型パターン

統合工数の見積りが最も外れるのが名寄せです。旧A行とB行の顧客番号は当然重複し、同一人物が両行に口座を持てば統合後は一人として扱います。住所表記の揺れ、旧姓と現姓、法人の商号変更が絡むと、機械的な突合で一致しない件数が数万件単位で残ります。

商品コードはさらに厄介です。定期預金一つとっても、満期時の自動継続の扱い、金利の適用日、中途解約利率の刻み方が行ごとに違います。存続側にない商品性が見つかるたび、パラメータで吸収するか、既存契約だけ旧条件で塩漬けにするか、顧客に条件変更の同意を取るかの三択を迫られます。この判定は業務部門でしか下せません。システム部門だけで工程表を引けば、統合日程は必ず遅れます。

決済網や全銀システムとの接続から止められない業務を洗い出す手順

統合当日の停止可能時間を決めるのは、自社の都合ではなく外部接続先の稼働時間です。全銀システムのモアタイムシステムは24時間365日で他行宛て振込を受け付けており、CAFISやデビット、口座振替の集中処理も止められる時間帯が限られます。まず外部接続の一覧を作り、接続先ごとの停止可否と事前通知の要否を確認します。

次に、止まると顧客資金が動かなくなる業務を抽出します。給与振込の集中日、年金支給日、月末の口座振替日は候補から外れ、結果として大型連休が統合日の第一候補に残ります。日程を先に決めて業務を合わせにいく進め方は、この工程を飛ばすため危険です。

合併後の片寄せ・新設・データ連携という三方式の選択条件と費用構造

方式は三つあり、実務ではほとんどの案件が片寄せに落ち着きます。ただし「安いから」という理由で選ぶと、存続側の改造費が膨らんで新設と変わらない総額になります。判断軸は費用の絶対額ではなく、商品性の吸収可否と期間の確度です。

片寄せを選ぶ条件｜存続システムの拡張余地と商品差の吸収可否の見方

片寄せは、一方のシステムを存続させ、もう一方のデータを変換して寄せる方式です。開発対象が存続側の改造と移行プログラムに限られるため、三方式で最も期間が読めます。選べる条件は二つ。存続側が商品パラメータの追加で相手行の商品を表現できること、そして処理能力に統合後の取引量を吸収する余地があることです。

逆に、存続側が10年以上前の設計で商品ロジックをハードコードしている場合、片寄せは不利になります。1商品追加するたびに勘定系の中核モジュールへ手を入れる構造では、改造範囲が全体へ波及し、回帰テストの量が新設と変わらないためです。判断材料は、直近3年の商品追加案件でかかった実績工数になります。

新設（全面再構築）が正当化される規模と、期間・費用の跳ね上がり方

新設は、両行のシステムを捨てて新しい基盤を作り、双方が移行する方式です。統合を機に商品体系そのものを設計し直せるため、統合効果は最も大きくなります。反面、期間は3年以上、要員はピーク時に数百人規模まで膨らみ、途中で経営環境が変われば要件が動きます。みずほ銀行のMINORIは統合を起点とした再構築の代表例で、2019年7月の稼働まで長期を要しました。

新設を選んでよいのは、統合規模が大きく、どちらのシステムも耐用年数の終盤にあり、統合しなくても数年内に更改が必要な場合に限られます。片方が更改直後なら、その資産を捨てる合理性はありません。再構築とリプレイスの線引きはマイグレーションとリプレイス・モダナイゼーションの違いで整理しています。

データ連携で当面つなぐ判断と、二重運用が固定化してしまう失敗条件

データ連携は、両システムを残したまま中継の仕組みで相互に照会・更新できるようにする方式です。古くはリレーコンピュータと呼ばれた接続で、いまはAPIゲートウェイと連携基盤が担い、合併日にシステムが間に合わない場合の橋渡しになります。

この方式の弱点は固定化です。両システムを維持する運用費が二重にかかり、商品追加のたびに2か所へ実装し、障害時の切り分けも複雑になる。「動いているから」という理由で連携のまま数年が過ぎる例が実在します。採用するなら、連携開始時点で本統合の期日と、期日を過ぎた場合の意思決定者を文書に落としておく。期限のないデータ連携は選ばない、と決めておくほうが安全です。

三方式の比較表｜初期費用・移行期間・統合効果・障害リスクの出方

三方式を四つの軸で並べると、片寄せが中庸に位置し、新設と連携が両極に振れます。金額は案件規模で桁が変わるため、相対比較として示します。

方式	初期費用	移行期間	統合効果	主なリスク
片寄せ	中	1〜2年	大きい	商品差の吸収漏れ
新設	大	3年以上	最も大きい	期間超過と要件膨張
データ連携	小	半年〜1年	限定的	二重運用の固定化

見落としやすいのが運用費です。片寄せと新設は統合後に運用費が下がりますが、データ連携は下がりません。5年間の総費用で比べると、初期費用が最小の連携が最も高くつく、という逆転が起きます。

統合当日までに勘定系のデータ移行と並行稼働・リハーサルを重ねる順序

方式が決まったあとの工程は、移行設計・リハーサル・本番切替の三段構えになります。この章では、金融特有の判定基準が入る部分だけを扱い、移行方式そのものの一般論は別記事へ委ねます。

移行対象データの棚卸しと、口座・契約の残高突合を通過とみなす基準

移行データは、残高系・取引履歴系・マスタ系・帳票系の四つに分けて棚卸しします。判定が厳しいのは残高系で、口座単位の残高と利息の未収額が旧新で完全一致することが移行成功の条件です。差異1件でも許容しません。一般の移行と最も違う点で、「サンプル抽出で95%一致」といった判定は通りません。

取引履歴は保存年限で判断が分かれます。法定保存年限内のデータは移行し、それ以前は旧システムを参照専用で残すか、帳票イメージで保管する形が現実的です。この線引きを先に決めておかないと、移行プログラムの対象件数が確定せず、リハーサルの所要時間も見積もれません。

移行リハーサルを何回・どの規模で回すかを決める判断材料と回数の目安

リハーサルの回数は、移行プログラムの本数と外部接続先の数から決めます。本番同等の全件データで通すフルリハーサルを最低3回、次の組み立てが標準形になります。

1回目：全件変換の完走確認と異常データの件数把握
2回目：所要時間の短縮と、手順書どおりに他者が実行できるかの検証
3回目：本番と同じ要員・時刻・端末での通し、切戻し手順まで実施

3回目で切戻しまで通す点が肝心です。切戻し手順を机上のまま本番を迎えると、当日に判断がつかず、中断すべき局面で前進を選ぶ力学が働きます。回数を減らしたいなら移行対象を分割して統合日を複数回に分ける方法もありますが、並存期間が延びるため運用費との交換になります。分割の単位として切り出しやすい帳票基盤については金融機関の電子帳票システムの要件と移行判断で扱っています。

統合当日の切替手順と、中断判定を下すチェックポイントの置き場所

切替当日は、時刻ごとにチェックポイントを置き、そこで前進か中断かを判定します。判定者は事前に一人に決めておきます。合議にすると誰も止められません。置き場所は、旧システムの最終締め処理、データ変換の完了、突合結果の確認、外部接続の疎通確認の四か所が基本形です。

各チェックポイントには、通過条件と切戻し所要時間の両方を書いておきます。「変換完了が午前3時を過ぎたら切戻し」と時刻で機械的に決まる形にしておくと、当日の圧力に判断が引きずられません。切戻しに5時間かかるなら、営業開始の5時間前が最終判断時刻です。この逆算がない計画書は、実質的に切戻し不能です。

金融庁の着眼点とFISC第14版が求める統合リスク管理の対応範囲

統合案件では、システムの出来とは別に「態勢」を説明できるかが問われます。当局向けの資料づくりを工程外に置くと、終盤に企画部門が破綻しかねません。押さえる文書は限られているので、最初に手元へ揃えておきます。

検査マニュアル廃止後に残った着眼点と、対話型モニタリングの中身

金融庁が平成14年12月に公表した「システム統合リスク管理態勢の確認検査用チェックリスト」は、形式的・些末な指摘を助長したという評価を受け、平成31年4月以降に廃止されました。ただし観点そのものが消えたわけではありません。廃止に際して「システム統合リスク管理態勢に関する考え方・着眼点（詳細編）」（平成31年3月）が存続資料として整理され、「金融機関のITガバナンスに関する対話のための論点・プラクティスの整理」と併せて対話の土台になっています。

実務への影響は、チェックリストへの適合を示す形から、自社の判断根拠を説明する形へ変わったことです。令和元年6月21日に公表された「システム統合・更改に関するモニタリングレポート」は、複数の金融機関で共通して起きた課題事例を業態・課題・原因・対策の構造で示しており、統合計画の自己点検にそのまま使えます。経営陣が進捗をどう把握しているかを問われる前提で、報告の経路と頻度を設計しておきます。

FISC安全対策基準第14版で統合案件に効いてくる改訂項目の範囲

FISCの「金融機関等コンピュータシステムの安全対策基準・解説書」は第14版が2026年3月25日に公表されています。改訂で入ったのはAI・生成AIの安全対策、サイバーセキュリティ関連ガイドラインの反映、耐量子計算機暗号（PQC）の移行留意点と対応時期、システム障害事例です。統合案件で効いてくるのは、新基盤の暗号方式を決める場面です。

統合を機に新設や大規模改造を行うなら、暗号アルゴリズムの選定はPQCへの移行時期を織り込んだ判断になります。稼働から10年以上使う勘定系で移行余地のない実装を選べば、後年の改造費が跳ねる構造です。全体像と対応範囲はFISC安全対策基準の第14版の改訂点にまとめています。

顧客説明・通帳・約款の切替というシステム外側に発生する対応範囲

統合の工数はシステムだけでは終わりません。通帳やキャッシュカードの切替、約款・規定の統一、手数料体系の一本化、店番・口座番号の変更通知、口座振替先への変更連絡。これらは業務部門と広報の作業ですが、システムの切替日と連動するため工程表は一本にまとめます。

特に見落とされるのが、顧客が登録している口座振替先への通知です。公共料金やクレジットカードの引落口座が変更になると、通知漏れが引落不能を招き、顧客の信用情報に影響します。システム側の作業が完璧でも、ここで失敗すれば統合は失敗と評価されます。

過去の統合障害から逆算する検証項目と、切戻しに踏み切る判断基準

金融のシステム統合は、失敗例が公開資料として詳細に残っている珍しい領域です。行政処分の公表資料や報告書から、どの検証を省くと何が起きるかを逆算できます。

二重処理や未達を生む勘定系の再送設計と、検証で潰すべき境界条件

統合直後の障害で顧客影響が大きいのは、取引の二重処理と未達です。原因の多くは通信断やタイムアウト後の再送設計にあります。旧システムでは冪等性が業務ロジック側で担保されていたのに、統合後は連携基盤側の想定に変わり、境界がずれる。正常系のテストでは出ない類の不整合です。

潰すべき境界条件は四つあります。バッチ処理中の通信断からの再開、日付をまたぐ時刻での取引受付、月末と営業日カレンダーの境界、そして処理件数が想定上限に達したときの挙動。件数上限はテスト環境の小規模データでは再現できないため、本番同等件数のリハーサルでしか検出できません。工程別の失敗要因は基幹システム刷新の失敗事例を工程別に分解した記事で扱っています。

統合直後の障害を招く保守体制の縮小と、旧仕様の要員を残す期間の決め方

統合完了と同時に保守要員を減らす判断は、ほぼ確実に裏目に出ます。みずほ銀行は2019年7月にMINORIが稼働した後、2021年2月から9月にかけて複数回のシステム障害を起こし、2021年11月26日に金融庁から業務改善命令を受けました。処分理由には、システムのリスクと専門性の軽視、IT現場の実態の把握不足、保守運用に必要な人員と経費の削減による体制の弱体化が挙げられています。

ここから引ける基準は明確です。稼働後1年間は統合前の保守体制を維持し、旧仕様を知る要員を最低1年、勘定系の中核領域は2年残す。統合効果としてのコスト削減は、この期間が明けてから計上する計画にしておく。投資回収計画で削減の開始時期を稼働直後に置いた資料が出てきたら、そこを直すのが先です。

片寄せを見送るべき場面と、統合そのものを分割して先送りする条件

片寄せを選ばないほうがよい場面が三つあります。存続側が5年以内に更改期限を迎える場合、商品追加のたびに中核モジュールを改造する構造の場合、そして統合対象行の取引量が存続側の処理能力の半分を超える場合。いずれも改造費と性能リスクが読めず、期間の確度という利点が失われます。

統合そのものを分割して先送りする判断もあります。合併日に全システムを揃える必要はなく、勘定系は連携でつなぎ、情報系とチャネル系を先に統合し、勘定系を1年後に寄せる分割案は現実的な選択です。条件は、連携期間の終了期日と本統合の方式を合併日までに決めておくこと。方式選定から移行の実行までを外部に委ねる場合は、システムマイグレーション・リプレイスの支援で対応範囲を確認できます。

統合プロジェクトの期間と体制の目安、外部委託に出す範囲の切り分け

最後に、計画段階で要る期間・体制・費用の目安と、発注側に残す役割を整理します。数値は案件規模で幅が出ます。

合併発表から統合完了までにかかる期間と、並存期間に生じる費用の内訳

合併の発表からシステムの完全統合までは、2年前後を要する例が公表されています。きらぼし銀行は2018年5月に3行が合併し、旧行のシステムを並存させたうえで2020年5月にシステムを統合したと告知しました。並存期間はおよそ2年です。この間、旧行それぞれのシステム運用費・保守委託費・データセンター費用が並行して発生します。

並存期間の費用は、統合予算で最も見落とされる項目です。開発費だけを予算化し、並存中の重複運用費を織り込まないと、期間が半年延びるたびに予算超過が表面化します。開発費と並存運用費を分けて管理し、期間延伸1か月あたりの追加費用を先に算出しておくと、遅延の判断が金額で議論できます。

発注側に残しておく役割と、ベンダーへ委託する範囲を分ける線引き

ベンダーに委ねられるのは、移行プログラムの開発、変換ロジックの実装、リハーサルの実行支援、切替作業の実施です。委ねられないのは三つ。商品性の差異をどう吸収するかの業務判断、移行成功の判定基準の決定、そして中断・切戻しの意思決定です。この三つを外部に委ねた案件は、判断が必要な局面で誰も決められません。

体制としては、業務部門から商品・事務の意思決定者を専任で出し、システム部門に全体を横断する管理者を置きます。兼任で回すと日常業務が優先され、判断が滞ります。人員を出せないなら、統合の時期そのものを見直すほうが安全です。

保険会社のシステム統合で銀行と前提が変わる論点と、対応の優先順位

保険会社の合併では、統合対象の中心が勘定系ではなく契約管理系になります。銀行と違って残高の即時性は問われません。代わりに、契約が数十年続く点が制約になります。50年前に販売した商品の契約者が現存する以上、旧商品の計算ロジックを新システムへ移すか、旧システムを参照専用で残すかの判断が全商品について発生します。

優先順位は、契約・当事者・商品・イベントというデータモデルの統合方針を先に決め、収納と保険金支払の処理を次に、代理店手数料の計算を後に置く順です。責任準備金の計算方式が旧新で変われば決算数値に影響するため、経理部門と監査法人の合意を移行設計の前段に置きます。保険側の基幹構造は保険基幹システムの業務領域とデータモデルで個別に整理しました。

よくある質問

金融機関のシステム統合について、計画段階で相談の多い質問をまとめました。

金融機関のシステム統合にはどのくらいの期間がかかりますか？

片寄せで1〜2年、新設（全面再構築）なら3年以上が目安です。きらぼし銀行は2018年5月の合併から2020年5月のシステム統合まで約2年、旧行システムを並存させました。期間を左右するのは開発規模より、商品性の差異をいくつ吸収するかと、リハーサルに割ける時間です。合併日とシステム統合日を同一にする必要はありません。

片寄せと新設のどちらを選ぶべきですか？

存続側のシステムが相手行の商品をパラメータ設定の範囲で表現でき、統合後の取引量を処理できるなら片寄せです。どちらのシステムも耐用年数の終盤にあり、統合しなくても数年内に更改が必要なら新設を検討します。1商品の追加に中核モジュールの改造が要る構造なら、片寄せの改造費は見積りより大きく膨らみます。

統合期間中に旧システムを並存させても問題はありませんか？

合併日にシステムが間に合わない場合の現実的な選択肢です。ただし並存中は両システムの運用費が二重にかかり、商品追加も2か所への実装になります。並存を選ぶなら、本統合の期日と、期日を過ぎた場合の意思決定者を開始時点で文書化してください。期限を切らない連携は数年単位で固定化し、5年総額では片寄せより高くつきます。

システム統合で金融庁への届出や検査対応は必要ですか？

合併・経営統合そのものに認可手続きがあり、システム統合の進捗も監督上の関心事項です。平成14年公表の確認検査用チェックリストは平成31年4月以降に廃止されましたが、「システム統合リスク管理態勢に関する考え方・着眼点（詳細編）」が存続資料として残り、対話型のモニタリングで用いられます。令和元年6月21日公表のモニタリングレポートは、自己点検の枠組みとして使えます。

保険会社の合併でも銀行と同じ進め方でよいですか？

工程の骨格は同じですが、統合の中心が契約管理系に移る点が異なります。保険契約は数十年続くため、旧商品の計算ロジックを移行するか旧システムを参照専用で残すかを商品ごとに判断する作業が発生します。責任準備金の計算方式が変わると決算数値に影響するので、経理部門と監査法人の合意を移行設計の前に取り付けてください。