2026.08.30 業務システム

金融システムのサーバー構成｜可用性・DR設計とクラウド移行の判断基準

金融システムのサーバーは、性能や価格よりも先に「止まらないこと」と「取り違えないこと」で仕様が決まります。社内の販売管理システムとは、設計の出発点そのものが別物です。この記事では、勘定系と情報系でサーバー要件がどう変わるか、メインフレームとオープン系をどの軸で使い分けるか、稼働率の目標値をどう年間停止時間へ翻訳するか、DRサイトをどこに置けるかを順に整理します。最後に、クラウドへ移してよい領域と自社設備に残す領域を、条件を付けて言い切ります。

まとめ：止めない設計を勘定系に、伸縮する設計を周辺系に振り分ける方針

先に結論を置きます。金融システムのサーバー基盤は一枚岩で決めるものではなく、勘定系には停止時間と整合性の要件を、情報系やチャネル系には負荷変動への追随を、それぞれ別々に割り当てるのが実務の形です。全部を同じ水準で作ると、費用が跳ね上がるわりに変更に弱い基盤ができあがります。

クラウド移行は「勘定系を含めて全面か、断念か」の二択で考えると必ず止まります。情報系・分析基盤・検証環境から先に動かし、チャネル系の前段を続け、勘定系は次回の更改時期に合わせて判断する。この順番なら、途中で方針が変わっても手戻りが小さく済みます。

設備要件はFISCの安全対策基準が土台です。2026年3月25日に第14版が公表され、耐量子計算機暗号（PQC）と生成AIに関する論点が加わりました。基盤更改の設計書は、この版を参照した記述へ更新しておく必要があります。

金融システムのサーバー基盤が一般の業務システムと異なる三つの制約

金融システムのサーバーに求められる条件は、一般的な社内システムの延長線上にはありません。稼働時間、データの正しさ、そして第三者への説明責任という三つが、設計の初期段階から効いてきます。

営業日の日中帯だけでは済まない24時間365日という稼働要求

全国銀行データ通信システムのモアタイムシステムが2018年10月に稼働して以降、参加行間の他行宛振込は24時間365日で流れるようになりました。夜間や休日に受付を止められる前提が消えた、ということです。

かつては夜間のバッチ処理時間帯をそのまま計画停止に充てられました。今はオンライン受付を止めずにバッチを回す必要があり、勘定系の前段へ受付だけを担うサーバー群を置き、後段の記帳処理と非同期に接続する構成が採られます。サーバーの台数ではなく、処理の区切り方で稼働時間を確保する発想です。

一件の記帳ミスが決済網全体へ波及するトランザクション整合性の制約

金融システムでは、一件の取引が複数の口座、複数の勘定、さらに他行や決済機関へと連鎖します。誤った残高が確定してしまうと、影響範囲を特定して巻き戻す作業そのものが数日規模の対応になります。

そのため勘定系のサーバーは、性能を落としてでも整合性を優先する設計になります。書き込みを単一の権威ノードに集約し、複製先へは確定後の状態だけを配る。分散データベースで書き込みを分散させる構成は、情報系では成立しても勘定系では採用しにくい。業界ごとの要件差については、金融・公共・流通系のシステム開発における業界特化の要件も参照してください。

金融庁の監督指針とFISC基準で説明を求められる設備と運用の証跡

三つめは説明責任です。金融機関のシステムリスク管理は監督指針の対象で、障害時には原因と再発防止策を当局へ説明する立場に置かれます。サーバーの設置場所、電源と回線の供給経路、操作権限の記録を、後から示せるかどうかが問われる部分です。ラック単位の配置図と電源系統図、変更管理の履歴は、運用開始後に作り直すと精度が落ちます。基盤設計と同時に整備するほうが安く済みます。

勘定系・情報系・チャネル系で変わるサーバー要件と配置の重み付け

金融システムは役割の異なる複数の系で構成されます。ここでは各系の定義ではなく、系ごとのサーバー要件の重み付けに絞ります。

勘定系サーバーに求める無停止性と夜間バッチの終了時刻という制約

勘定系サーバーの設計値は、オンラインの応答時間よりも、日次バッチが定刻までに終わるかどうかで決まることが多くあります。利息計算、他行との資金決済、帳票生成といった処理は、翌営業日の開店時刻から逆算した締切を持っています。

この締切があるため、勘定系のサーバーは平均性能ではなく最悪ケースの処理時間で規模を決めます。ピーク日の取引件数が平常日の何倍になるかを実データから拾い、その値でCPUとI/Oの上限を設計する。平常時の使用率が二割程度にとどまる構成になっても、それは過剰ではなく締切を守るための設計です。三層構造の定義と情報系との違いは、勘定系システムの三層構造とオープン化の判断で整理しています。

情報系とチャネル系のサーバーで効いてくる伸縮性と障害の隔離設計

情報系とチャネル系は要件の向きが逆です。インターネットバンキングやスマートフォンアプリの入口は、給与支給日や連休明けに負荷が数倍へ跳ねます。ここで固定台数のサーバーを構えると、ピークに合わせた分だけ平常時が遊びます。

採るのは、負荷に応じて台数が増減する構成と、勘定系との間に明確な境界を置く設計です。境界には流量制御を入れ、チャネル側が過負荷になっても勘定系へ流れ込む要求量が上限を超えないようにする。入口が重くなっても記帳は止まらない、という状態を作るのが隔離の狙いです。分析基盤も同様で、集計クエリには複製先を参照させます。

メインフレームとオープン系サーバーの使い分けを決める四つの判断軸

「メインフレームは古い」という前提で議論を始めると、判断を誤ります。どちらが新しいかではなく、処理の性質と組織の事情で決まる領域です。

メインフレームが勘定系に残り続ける処理密度とCOBOL資産の事情

勘定系がメインフレーム上に残っている理由は二つあります。一つは処理密度。大量の短いトランザクションを一台に集約して確実に捌く用途では、専用のI/O機構と長年の運用実績が効きます。もう一つは業務ロジックの蓄積で、数十年分の例外処理がCOBOLのプログラム群に埋め込まれています。

この二つめが移行の実質的な障壁です。仕様書に残っていない条件分岐が動いている場合、機械的な変換だけでは同じ結果を再現できません。移行の見積もりでは、変換作業そのものより、旧環境と新環境で同じ入力から同じ出力が出るかを突き合わせる並行稼働の期間が費用を左右します。

オープン系サーバーへ先に寄せられる処理領域と国内の勘定系パッケージ

一方で、オープン系サーバーへ移った領域は着実に広がっています。情報系、営業店端末の後段、対外接続のゲートウェイ、そして分析基盤。これらはメインフレーム上に置く必然性が薄く、要員の確保しやすさと変更速度の面でオープン系が有利になります。

勘定系そのものについても、日立製作所が提供する「OpenStage」のように、オープン系サーバー上で動く勘定系パッケージが実在します。ただし採用の判断は、パッケージの機能差よりも、自行の業務例外をどこまでパッケージ標準に寄せられるかで決まります。

調達コストと要員確保まで含めた四つの軸による比較と選定の目安

比較は「性能」の一語で済ませず、次の四軸に分けると判断しやすくなります。

判断軸	メインフレーム	オープン系サーバー
処理特性	短時間の大量取引に強い	並列・分散処理に強い
可用性の作り方	筐体内で冗長化	複数台の構成で冗長化
要員確保	COBOL要員が年々減少	市場からの調達が容易
費用構造	保守料の固定費が大きい	台数と運用工数に比例

四軸のうち、更改の意思決定で最後に効いてくるのは要員確保です。性能と費用は数値で比較できますが、五年後に保守要員を確保できるかどうかは数値化しにくく、先送りされやすい。要員の見通しが立たない領域から順にオープン系へ移すのが、無理のない進め方になります。

停止時間を分単位まで削る冗長化構成とサーバー台数・切替方式の決め方

冗長化は「二重にする」で終わる話ではありません。目標をどう数値化し、どこまで遡って単一障害点を潰すかで、費用も構成も変わります。

稼働率99.99%が年52分という目標値の意味と設計への落とし方

稼働率の目標は、年間の停止分数へ換算してから設計に落とします。1年を365日＝525,600分として計算すると、99.9%で約525分（8時間45分）、99.99%で約52分、99.999%で約5分になります。

この換算をすると議論が具体になります。年52分という枠に計画停止を含めるのか。含めるなら、月次のセキュリティ更新をどう適用するのか。実際には、計画停止を枠外として扱い、無停止で更新を適用できる構成を別に用意する形が現実的です。目標値と計画停止の扱いを先に合意しておくと、後段の設計がぶれません。

待機系を持つ構成と両系稼働の構成を切り替え時間で選び分ける基準

冗長化の形は、待機系を用意して障害時に切り替える構成と、複数系を同時に稼働させて負荷を分ける構成に大別できます。選び分けの基準は切り替えに許される時間です。

数分を許容できるなら、待機系を持つ構成で足ります。構成が単純で、動作確認もしやすい。切り替え時間を秒単位に抑える必要がある場合は、両系を同時に動かし、片方が落ちても残りが処理を継続する構成を採ります。ただし後者は、書き込みの整合性を保つ仕組みが必須になり、設計と試験の工数が増えます。勘定系の記帳部分では、権威ノードを一つに保ったまま切り替えを速くする方向で組むのが一般的な形です。

電源・回線・ストレージまで遡って洗い出す単一障害点の点検手順

サーバーを二台にしても、その二台が同じ電源系統と同じスイッチにつながっていれば、冗長化にはなりません。単一障害点の洗い出しは、上流へ遡る順で行います。

サーバー筐体：電源ユニット、ネットワークインターフェース、内蔵ディスク
ラック内：電源分岐、スイッチ、配線経路
建物設備：受電系統、非常用発電機、空調
共有基盤：ストレージ装置、名前解決、認証、時刻同期
対外接続：回線事業者、経路、接続先の拠点

実務でよく残るのは4段目です。サーバーとネットワークを丁寧に二重化したのに、認証サーバーや時刻同期の参照先が一系統のままだった、という構成は珍しくありません。点検は必ず、この共有基盤まで降りて確認してください。

RPOとRTOから逆算するDRサイトとバックアップの設計手順

災害対策の構成は、復旧の目標値から逆算します。どこまでのデータ損失を許すか（RPO）と、どれだけの時間で復旧するか（RTO）。この二つが決まらないと、DRサイトの場所も方式も決められません。

RPOを0秒に置く場合と数分を許す場合のレプリケーション方式の選択

RPOを0秒に置くなら、主サイトへの書き込みが副サイトへ届いたことを確認してから完了を返す同期レプリケーションが必要です。データは失われませんが、書き込みの応答時間に副サイトとの往復が丸ごと乗ります。

数分の幅を許せるなら、非同期レプリケーションで足ります。主サイト側は副サイトの応答を待たずに完了を返すため、応答時間への影響がほぼありません。その代わり、災害発生の瞬間に転送し切れていない分は失われます。勘定系の記帳データは同期、情報系や分析用の複製は非同期、という使い分けが現実的な落としどころです。

同期レプリケーションの限界を決めるサイト間距離と往復遅延の関係

同期レプリケーションを選ぶと、DRサイトを遠くに置けなくなります。理由は物理です。光ファイバ中の光の伝搬速度は真空中の約3分の2、およそ20万km/sで、片道100kmにつき約0.5ミリ秒、往復では約1ミリ秒の遅延が生じます。装置の処理遅延を加えると、実測はこれより大きくなります。

1件の書き込みに数ミリ秒が上乗せされる影響は、単発では気になりません。問題は、1件の取引が数十回の書き込みを伴う場合です。往復遅延が積み上がり、バッチの終了時刻に効いてきます。

ランサムウェア被害を想定した世代管理と改変不可バックアップの併用

レプリケーションはバックアップの代わりになりません。誤った書き込みも暗号化された状態も、そのまま副サイトへ複製されるからです。世代を持ったバックアップを別に用意する必要があります。

設計の要点は二つ。一つは世代数と保持期間を、異常に気づくまでの時間から決めること。検知に一週間かかる可能性があるなら、一週間より前の状態へ戻せる世代を残します。もう一つは、バックアップ自体を書き換えられない状態に置くこと。復旧手順は年に一度、実際にリストアして所要時間を測ってください。手順書の記載と実測値がずれている例が多くあります。

FISC安全対策基準第14版がサーバー設備に求める要件の読み方

金融機関のシステム設計で参照されるのが、公益財団法人金融情報システムセンター（FISC）の「金融機関等コンピュータシステムの安全対策基準・解説書」です。法令ではなく業界の自主基準ですが、当局の検査や委託先の選定で事実上の物差しとして機能します。

設備・運用・技術という三つの分野のうち設備基準が扱う対象の範囲

安全対策基準は、建物や設備に関する項目、運用体制に関する項目、技術的な対策に関する項目にわたって構成されています。サーバー基盤の設計で最初に確認するのは設備側の項目で、コンピュータ室の立地と構造、受電と非常用電源、空調、入退室の管理、消火設備といった要素が対象になります。ここが効いてくるのは、自社のコンピュータ室を使い続けるか、データセンター事業者へ預けるかを比較するときです。設備項目を自前で満たし続ける費用と外部データセンターの利用料を並べると、規模によっては後者が明確に安くなります。基準の全文は有償頒布のため、設計にあたっては最新版を入手して該当項目を直接確認してください。基準そのものの位置づけと、どの項目までを自社の対応範囲とするかの決め方はFISC安全対策基準の対応範囲と第14版の改訂点で整理しています。

第14版で入った耐量子計算機暗号と生成AIの論点の受け止め方

FISCは2026年3月25日に第14版のPDF版を公表しました。第13版が2025年3月、第12版が2024年3月の発行で、おおむね年次で改訂されています。第14版の改訂点として挙げられているのは、AI・生成AIに関するガイドライン等の反映、サイバーセキュリティ対策、耐量子計算機暗号（PQC）への対応、システム障害事例の反映という四点です。

このうち基盤設計に直結するのがPQCです。金融庁が2024年11月に公表した「預金取扱金融機関の耐量子計算機暗号への対応に関する検討会報告書」を踏まえ、移行の留意点と対応時期が反映されました。実務への落とし込みとしては、今すぐ全面的に暗号を入れ替えるのではなく、これから調達するサーバー・HSM・通信機器について、暗号方式を後から差し替えられる構造になっているかを調達要件に加えるところから始めます。更改サイクルが五年から十年に及ぶ金融システムでは、今回の更改で選んだ機器がPQC移行の時期と重なります。

クラウドへ移せる領域と自社設備に残す領域を分ける五つの判断基準

ここからは判断を言い切ります。金融システムのクラウド移行は、全面移行か現状維持かの二択ではありません。領域ごとに切り分ければ、大半の金融機関は今日から動かせる部分を持っています。

情報系と検証環境から動かすというクラウド移行の初手とその根拠

最初に動かすのは検証環境と情報系です。検証環境は、本番データを持たず、負荷が断続的で、使わない時間に停止できる。クラウドの従量課金と相性が良く、失敗しても業務影響がありません。情報系の分析基盤も同様で、月末に負荷が集中する処理を固定台数で構えている場合、費用面の改善が出やすい領域です。

この初手には、費用削減以外の狙いもあります。クラウド上での権限設計、監査ログの取得、委託先管理の手続きを、業務影響のない場所で先に確立できる点です。勘定系の議論に入る前にこの経験を積んでおくかどうかで、その後の検討速度が変わります。導入形態そのものの比較は、オンプレミス型とクラウド型の基幹システムの選定ポイントにまとめています。

自社設備に残すと判断する条件と移行そのものを見送るべき三つの場面

次は残す側の条件です。以下に当てはまる場合、勘定系のクラウド移行は今回の更改では見送ってください。

メインフレーム上のCOBOL資産について、仕様書と実装の乖離が棚卸しできていない
次回の機器更改まで三年以上あり、移行費用を二重に負担する期間が長くなる
クラウド側の運用を担う要員が一人もおらず、委託先も未選定

三つめが最も見落とされます。移行そのものは委託できても、移行後の権限管理と費用監視は自社側に残る作業です。運用の受け皿がないまま移すと、設定変更の判断ができず、旧構成をそのままクラウドへ写しただけの高い基盤ができあがります。この状態になるくらいなら、自社設備で更改して次の五年で体制を作るほうが合理的です。

三年を目安に区切る段階移行の順序と各段階で確認する運用の到達点

段階移行は、期限を区切らないと最初の段階で止まります。三年を目安に、次の順で進めます。

初年度：検証環境と開発環境を移し、権限設計と監査ログ取得の型を作る
二年目：情報系・分析基盤を移し、費用監視と障害対応の運用を回す
三年目：チャネル系の前段を移し、勘定系との境界に流量制御を置く
次回更改：勘定系の方式を、実績と要員の状況をもとに決める

各段階の到達点は「移し終えたこと」ではなく「運用が回っていること」に置いてください。夜間に障害が起きたとき、当番が自力で切り分けられるか。月次の費用が予算内に収まり、超過の原因を説明できるか。この二点を満たせない段階で次へ進むと、後段でまとめて破綻します。

サーバー基盤の更改でつまずく典型パターンと委託先に確認する条件

基盤更改で頻出する失敗は、現行構成の把握が不十分なまま移行先の設計に入ることです。稼働中のサーバーのうちどれが実際に業務で使われているかを、台帳ではなく通信の実測から確認していないと、移行後に想定外の依存が表面化します。移行計画を立てる前に、数週間分の通信ログを取って依存関係を実測してください。

委託先の選定では、金融向けの実績よりも先に確認したい条件が三つあります。設計の根拠を文書で残す体制があるか、当局対応で必要になる資料の作成を支援できるか、移行後の運用を自社側へ引き継ぐ計画を提示できるか。当社ではAWS・Google Cloud・Azureのインフラ構築として、要件定義から移行、運用設計までを担当しています。現行構成の棚卸しから相談いただければ、移す領域と残す領域の切り分けから一緒に整理できます。

よくある質問

サーバー基盤の検討時に寄せられる質問をまとめます。

金融システムのサーバーはクラウドに置いてよいのですか？

領域によります。検証環境、情報系、分析基盤はクラウドへ移して問題が生じにくく、費用と伸縮性の両面で利点が出る領域です。勘定系については、業務ロジックの棚卸し状況、機器更改の時期、運用要員の有無で判断が分かれます。委託先管理や監査ログの取得といった手続きは、クラウドを使う場合も自社の責任として残る点に注意してください。

勘定系サーバーにメインフレームが多いのはなぜですか？

短時間に大量の取引を確実に処理する用途で実績があること、そして数十年分の業務例外がCOBOLプログラムに蓄積されていることの二つが理由です。特に後者は、仕様書に残っていない条件分岐が動いている場合があり、移行時は旧環境と新環境で同じ出力が出るかを突き合わせる並行稼働が必要になります。この検証工数が移行判断を左右します。

金融システムのサーバー冗長化はどこまで行えばよいのですか？

稼働率の目標を年間停止分数へ換算し、その枠に収まる構成を選びます。99.99%なら年約52分です。サーバー本体だけでなく、電源系統、ネットワーク経路、ストレージ、名前解決、認証、時刻同期まで遡って単一障害点を洗い出してください。共有基盤が一系統のまま残っている構成が、実務では最も多く見つかります。

FISC安全対策基準は法律ですか？守らないと罰則がありますか？

法律ではなく、金融情報システムセンターが定める業界の自主基準です。直接の罰則はありません。ただし当局の検査や金融機関による委託先選定で参照されるため、実務上は満たすべき水準として扱われます。最新版は2026年3月25日公表の第14版で、PDF版が有償で頒布されています。

DRサイトは同じ都市圏に置いても問題ないのですか？

同期レプリケーションを使う場合は、距離を離すと往復遅延が書き込み性能に直接効くため、同一都市圏に置く判断に合理性があります。ただし広域災害では両サイトが同時に被災する構図です。同一都市圏に同期の副サイトを置き、さらに遠隔地へ非同期で複製する第三サイトを持つ三拠点構成が、性能と広域リスクの折り合いをつける形になります。