「銀行の勘定系がクラウドへ」というニュースを見て、長年「クラウドは金融には向かない」と言われてきたはずなのに、なぜ今になって方針が変わったのか不思議に感じたことはないでしょうか。
そんなとき、こう感じたことはないでしょうか。
- そもそも「勘定系」が何で、自分がATMで引き出すお金とどう関わっているのか分からない
- クラウドに乗せて大丈夫なのか、自分の預金が止まったり消えたりしないか不安
- これまで難しいとされてきた理由と、今動き出した理由の違いが整理できていない
結論から言うと、答えは「勘定系の役割」と「これまで難しかった3つの壁」を押さえることです。 この2つを理解すれば、なぜ20年動かなかった領域が今動き出したのか、ニュースの裏側まで自分で読み解けるようになります。
なぜこの2点で分かるのか。それは、金融システムの現場で「クラウド移行が進まない理由」を日々目にしてきた立場から言えば、移行の障壁はほぼこの3つに集約されるからです。本記事では中の人の視点から、勘定系とは何か・クラウド化が難しかった理由・今動き出した背景まで具体的に確認していきます。仕組みが見えてくると、銀行選びや金融ニュースに「裏側の構造」という新しい視点が加わります。
1. 「勘定系」とは何か
まず、本題の前提となる「勘定系」とは何かを整理します。
勘定系（かんじょうけい）とは、銀行の預金残高や取引履歴を管理する基幹システムのことです。
たとえば、ATMで1万円を引き出すときの動きはこうなります。
- ATMからリクエストが送られる
- 勘定系が「この口座の残高は○○円」と確認する
- 残高不足でなければ、残高を1万円減らして処理を確定させる
- ATMに「OK」を返し、現金が出てくる
この一連の処理を秒単位でさばいているのが勘定系です。給与振込・振込・引き落とし・カード決済の確定——お金の動きが伴う処理はほぼすべて勘定系を経由します。
人間で言えば心臓にあたる部分で、止まると銀行が機能しません。
2. なぜクラウド移行が「難しかった」のか
前提：勘定系システムは3段階で進化してきた
本題に入る前に、勘定系の進化を整理しておきます。「勘定系をクラウドへ」と一言で言っても、実際には大きく3段階のステップがあります。
- 第1段階：メインフレーム（ホストコンピュータ）時代 — 1970年代〜。IBM z/OS や富士通 GS など専用機の上で、COBOL や PL-I で書かれた巨大システムが動いてきた時代。国内の大手銀行（メガバンク・大手地銀）の多くは現在もこの形が中心です。
- 第2段階：オープン分散系（ダウンサイジング） — 2000年代〜。Linux/UNIX サーバと RDBMS を組み合わせた分散構成へ移行する動き。「オープン化」「ダウンサイジング」と呼ばれ、みずほ銀行の MINORI や地銀共同センター、ソニー銀行の初代勘定系などがこの段階に相当します。
- 第3段階：クラウド化 — 2015年前後〜。金融情報システムセンター（FISC）の安全対策基準が、第8版追補（2015年、クラウド利用有識者検討会報告書を反映）・第9版（2018年、リスクベースアプローチ導入）と段階的に改定されたことを受けて、パブリッククラウド（AWS〈Amazon Web Services〉や Microsoft Azure など）の活用が現実的になっていった段階。
重要なのは、ほとんどの銀行はメインフレームから一気にクラウドへ飛んでいるわけではないということです。オープン分散系で作り直したシステムをクラウドへ持っていくか、あるいはオープン系構築のタイミングでクラウドを選ぶ、という流れが実態です。メガバンクの勘定系本体は現時点でも大半がメインフレーム上で稼働しており、「周辺系から段階的にクラウド化」するアプローチが取られています。
以降では、この第2段階・第3段階の移行がなぜ難しかったのかを整理していきます。
クラウド移行を阻んだ3つの壁
勘定系は長年、自前のオンプレミスサーバー（物理的なコンピューターを自社やデータセンターで管理する方式）で動いてきました。一方のクラウドは、AWSやGoogle Cloud、Microsoft Azureといったクラウド事業者が所有する巨大データセンターの計算資源を、インターネット越しに必要な分だけ借りて使う方式です。ハードウェアを自前で持たず、利用量に応じて課金される点が従来のオンプレミスと大きく異なります。クラウドへの移行は「技術的には可能でも踏み切れない」状態が長く続きます。その理由は大きく3つあります。
理由① 24時間365日の無停止要件
銀行のシステムは、月次バッチ処理（夜間に一括処理する作業）など一部の例外を除き、ほぼ無停止で動き続けることが前提です。
クラウドは「障害が起きても自動的に切り替わる」仕組みを備えていますが、切り替えの瞬間に数秒〜数十秒のダウンが生じる場合があります。これが銀行システムでは許容されにくいのです。「自動切替の瞬間にATM取引が失敗した」では困ります。
理由② 完全整合性（トランザクションの確実性）
お金の残高に「中途半端な状態」は存在してはいけません。
1万円の振込処理を例に取ると、送金元の残高を減らし、受取先の残高を増やす——この2つは必ずセットで成立する必要があります。片方だけ成功して片方が失敗した状態（「お金が消えた」または「お金が増えた」）は絶対に起きてはいけません。
これを技術的に保証するのが「トランザクション管理」という仕組みです。ところが、大規模な分散システム上でこれを完全に担保するのは技術的な難度が高い領域でした。
クラウドは分散処理が得意な反面、分散処理と「完全整合性」はトレードオフになりやすいという性質があります。
理由③ 金融庁の規制対応
銀行のシステム変更には金融庁への報告・承認や、障害発生時の責任範囲の明確化が求められます。クラウドを使うと「事業者側で障害が起きたとき、誰が責任を取るのか」という論点が生じ、海外クラウドを使う場合はデータの保管場所が海外になる懸念も付きまといます。規制側の整備がクラウド利用に追いついていなかったことが、長年クラウド移行を阻んできた要因の一つです（この論点は3章の「慎重な理由③」でもう一段掘り下げます）。
3. クラウド移行を後押しする4つの変化と、残された慎重論
難しいと言われ続けてきたクラウド移行が、なぜここ数年で動き出したのか。背景には大きく4つの変化があります。
クラウドの信頼性・機能が大幅に向上した
1つめは、クラウド側の進化です。AWSやAzureのサービスレベルは、ここ10年で劇的に向上しました。
- データセンターの多重化・冗長化の水準が上がり、銀行業務に十分耐える可用性と耐障害性が現実的に担保できるようになった
- 金融機関向けのコンプライアンス対応機能（監査ログ・暗号化・アクセス制御）が整備された
- 前項でも触れたFISCの安全対策基準改定を通じて、金融規制の枠組みがクラウド利用を前提とした整備へと段階的に動いた
コストと開発スピードの優位性（ハード更改の「大波」が平準化される）
2つめは、コストの考え方が変わってきたことです。特に効いているのが、オンプレ特有のハードウェアEOS（End of Support：サポート終了）対応の負担です。
オンプレの物理サーバは5〜7年ほどで保守・パッチ提供が切れ、そのたびに新機種への載せ替え・OSやミドルのバージョン上げ・移行テストといった社内プロジェクトが発生します。「何も機能追加していないのに、数年ごとに多額の投資と人員を取られる」のがオンプレ運用の宿命でした。
クラウドにすれば、ハードウェアの調達・交換・廃棄は事業者側の責任になり、物理機器を単位とした更改プロジェクトそのものが消えます。もっとも、ハード費用がゼロになるわけではなくクラウド事業者の利用料金に織り込まれているので、総額比較で必ず安いとは限りません。本質的なメリットは、数年に一度まとまって発生していた数億〜数十億円規模の「大波」が、月額料金に平準化されることにあります。
加えて、延長サポートでオンプレを粘らせる逃げ道が細ってきたのも近年の変化です。古いOS・ミドルを動かし続けること自体がセキュリティ監査で通りにくくなり、「EOSを先送りして凌ぐ」手が使いづらくなった結果、相対的にクラウド有利が鮮明になっています。ただしOS・ミドル・マネージドサービスといったソフトウェア側のライフサイクル管理は、クラウドでも利用者側の責任として残ります（この論点は後述の「慎重な理由②」で改めて触れます）。
加えて、新サービスを立ち上げる際のスピードがまったく違います。オンプレミスでサーバーを調達・構築すると数ヶ月かかるところ、クラウドなら数日〜数週間で環境を用意できます。競合するフィンテック企業のスピードに対抗するには、開発のアジリティ（機動力）が不可欠です。
さらにクラウドの強みとして、必要な分だけ後から増やせるという点があります。新規サービスを導入する際は、まずスモールスタートで小さな構成から始めて、実際の利用状況を見ながら段階的にスケールアップ（CPU・メモリ・台数の増強）できます。利用が伸びなければそのまま小さい構成で運用すればよく、伸びれば増やせばよい。この柔軟性は、新サービスの将来需要が読みづらい金融商品との相性がよい特徴です。
一方オンプレミスでは、サーバを調達する時点で5年後の利用状況を見越した性能のハードウェアを購入する必要があります。しかも「途中で性能不足になれば即アウト」というプレッシャーから、見積もりは往々にして保守的（＝大きめ）になりがちです。結果として、最初の数年間は使い切れない過剰スペックのサーバを抱えることになり、「購入時点で既に過剰投資が確定している」構造から逃れられません。クラウドが選好されるのは、この将来予測リスクをクラウド事業者側に寄せられるという点も大きな理由です。
メインフレーム技術者の確保が難しくなっている
3つめは、人の問題です。銀行の勘定系を長年支えてきたメインフレームは、COBOL・PL-I・JCL といった専用の言語やジョブ制御で動いています。
現状、IT業界全体がそもそも人手不足です。そのうえで、世の中の新規システムは圧倒的にオープン分散系やクラウドで作られるようになっており、新卒〜若手世代でメインフレーム用の言語を新たに学ぶ人はほとんどいません。大学でCOBOLを教えるカリキュラムも減り、業界内でも「これから伸ばす技術スタック」からは外れているのが実態です。
その結果、現場では次のような状況が進んでいます。
- メインフレームを開発・保守できる技術者の絶対数が年々減少
- 残っている技術者はベテラン層に偏っており、定年・引退とともに人数がさらに細る
- 需給が締まる一方なので、メインフレーム要員の人件費（外部発注の単価）は上昇傾向
「システムは動いているが、それを触れる人がいない」という状態は、金融機関にとって将来の事業継続リスクそのものです。ハードウェアコスト以上に、人の手当てという意味でもメインフレームを抱え続けるリスクが無視できなくなっており、オープン分散系・クラウドへの移行を後押しする大きな要因になっています。
情報系・もともと分散のシステムは先にクラウド化が進んでいる
4つめは、銀行内のシステム全体で見たときの温度差です。
勘定系の話ばかり書いてきましたが、銀行には勘定系以外にも多くのシステムがあります。具体的には、経営管理用のデータ分析基盤、稟議ワークフロー、人事・経理などの社内システム、マーケティングやリスク管理のシステムなど、いわゆる「情報系」と呼ばれる領域です。
これらは勘定系に比べると、
- リアルタイム性への要求が比較的緩い
- 1件ずれても即座に顧客被害になるわけではない
- そもそも最初からオープン分散系で作られているものが多い
といった特性があり、勘定系をクラウド化するかどうかとは関係なく、原則クラウド化していく方針を掲げる金融グループが増えています。既に分散系で動いているシステムを、EOSのタイミングに合わせて順次クラウドへ載せ替えていく、というイメージです。
ただし、注意点もあります。同じ分散系のシステムであっても、「対顧客の取引関連システム」（スマホアプリ、インターネットバンキング、顧客情報を直接扱う基盤など）は話が別で、情報系のように割り切ってクラウド化を進められる領域ではありません。分散系であってもクラウド化には慎重な姿勢を取る金融グループが多いのが実情で、その慎重さには技術的な裏付けがあります。
慎重な理由① 「止まらない設計」思想と、クラウドの確率論的SLA
クラウドの可用性を語るときによく使われる「99.99%」という数字は、年間約52分の停止を許容する前提で設計されたSLAです。万一そのラインを超えて止まっても、クラウド事業者は利用料金の一部を返金することで責任を果たす建て付けになっています。つまり、クラウドの可用性は根本的に確率論的です。
一方の勘定系や対顧客の基幹系は、「そもそも止めないこと」を大前提に作られてきた世界です。二重化・三重化、ホットスタンバイ、オンラインのまま部品を交換できる無停止保守など、止まらない前提の決定論的な設計が徹底されています。金融庁の「金融機関のシステム障害に関する分析レポート」を見ると、ストレージ・ネットワーク機器・電源系のハード障害が勘定系停止の発端になった事例は実際に存在します。ただし、そのほとんどは「ハードが壊れたこと自体」ではなく、壊れたあとの切替設計・パッチ管理・運用手順の不備で影響が拡大したケースです。メインフレーム本体（CPU・主記憶装置など）の故障で国内主要行の勘定系が長時間止まった、という公表事例はほとんど見当たらず、ハードウェアそのものは極めて枯れて安定しているのが実態です。
この「確率論で52分許容する世界」と「決定論で止めない世界」の発想の違いが、対顧客系をクラウドへ載せることに躊躇する大きな理由になっています。
慎重な理由② バージョン・構成を利用者側でコントロールしきれない
もう一つの論点は、クラウドのマネージドサービスが、事業者主導のライフサイクルで動いていることです。データベースのマネージドサービス、コンテナ基盤のマネージド版、サーバレス、TLS証明書のルート更新、API仕様の変更など、利用者の都合に関係なく「◯年◯月までに新バージョンへ移行してください」と通告される領域が多数あります。
勘定系や対顧客の重要システムでは、枯れた構成を長期間そのまま動かし続けること自体が信頼性の根拠になってきました。リリース頻度を抑え、検証の履歴を積み上げ、何か起きても「この構成で動いていた実績」を武器にする運用文化です。そこに事業者都合のバージョンアップが割り込んでくると、その都度回帰テストと本番切替プロジェクトが発生し、信頼性の前提そのものが揺らぎかねません。
もちろん、IaaS（VMだけ借りて中身は自分で作り込む形態）にすればOS・ミドルウェアのバージョンは自分で握れますが、それではクラウドのマネージドのうまみが薄まるというジレンマもあります。
慎重な理由③ 規制対応・データの所在・説明責任
加えて、金融庁検査やFISC（金融情報システムセンター）の安全対策基準、外部委託管理のガイドラインといった規制面でも、クラウド利用時にはデータの保管場所・障害時の切り分け・監査ログの取得・ベンダー全体障害時の影響範囲などを一段厳しく問われます。3大クラウド事業者のどこか1社で大規模障害が起きると、複数の金融機関が同時に止まりかねないというシステミックリスクも、当局が気にする論点です。
これらを踏まえると、対顧客の取引系については「クラウドに載せない選択肢を技術的・規制的にまだ持っておく」という判断が、保守的ではなく合理的な判断として成立している、ということになります。
結果として銀行全体では、「情報系から先行してクラウド化、対顧客領域は慎重に評価、勘定系本体は最後」という濃淡を付けながら、クラウドへの比重を年々高めているのが実態です。
4. 実際に起きている移行の動き（公開情報より）
ここからは、実際に国内で進んでいる代表的な事例を見ていきます。
ソニー銀行のAWS全面移行（第2段階 → 第3段階）
ソニー銀行は2025年5月、勘定系を含むシステム全体をAWSへ移行完了したと公表しています。実際には2019年時点で主要システムの約8割が既にAWS上で稼働しており、最後まで残っていた勘定系本体を2025年5月の連休中に切り替え、国内の銀行として勘定系のクラウド移行を完了させた先行事例として注目されています。
ここで押さえておきたいのは、ソニー銀行のAWS移行は「メインフレームから一気にクラウドへ」ではなく、もともと UNIX サーバと RDBMS を組み合わせたオープン分散系で作られていた勘定系を、AWSへ載せ替えたという流れだということです。いわば、前項で整理した第2段階から第3段階への移行にあたります。
「インターネット専業銀行」という特性上、物理的な店舗を持たず、開業当初からオープン系を前提にシステムを組んできたことが、クラウドへの移行を後押ししたと見られます。
みんなの銀行：国内初のフルクラウド勘定系
もう一つ、ネット銀行系で象徴的なのがふくおかフィナンシャルグループの「みんなの銀行」です。2021年5月に開業した完全デジタルの銀行で、勘定系を含むシステム全体を Google Cloud 上に構築し、「日本初のフルクラウド銀行」として立ち上がった事例として広く報道されました。
ソニー銀行が「既存のオープン分散系をクラウドへ載せ替えた」第2段階→第3段階の事例だとすると、みんなの銀行は最初からクラウド前提でゼロから勘定系を組んだケースです。既存資産のしがらみがないぶん、マネージドサービスやコンテナ、CI/CDといったクラウドネイティブな作り方を素直に取り入れやすかった、という側面があります。
住信SBIネット銀行・SBI新生銀行も勘定系のクラウド移行を決定済み
既に稼働している事例に加えて、勘定系のクラウド移行が決定済み・構築中のネット銀行系も出てきています。
- 住信SBIネット銀行: 日本IBMのオープン系勘定系「NEFSS」を、2028年初頭をめどに AWS 環境へ全面移行することを公表。同行の主要システムはすべてAWS上に集約される計画で、運用コストは約30%削減の見込みとされています。3,000万口座規模のデジタルバンク向け次世代クラウド勘定系アーキテクチャとして注目されている事例です。
- SBI新生銀行: SBIグループとフューチャーアーキテクトが共同開発した AWS ベースの「次世代バンキングシステム」を採用することを公表。稼働開始は2029年度下期〜2030年度上期を予定しています。同システムは既に福島銀行・島根銀行などの地銀で稼働実績があり、SBI新生銀行はその延長線上での採用となります。
いずれも稼働自体はこれからですが、「クラウドを選ぶか」の意思決定フェーズはもう終わっているというのが、ネット銀行・新興銀行系の今の状況です。
ネット銀行がクラウドに行きやすい背景
こうして見ていくと、勘定系のクラウド移行はネット銀行で先行している構図が見えてきます。その背景には、技術的な要素以上にビジネスモデルの違いが大きく効いています。
- メガバンク: 大企業の決済（給与振込・企業間取引・国際決済など）を多数抱えており、数秒の遅延や停止が企業の事業継続に直接影響する。当局からの目線も厳しく、「1秒たりとも止められない」という要求水準が極めて高い。
- ネット銀行: 個人利用が中心で、給与振込や日常の決済こそ重要なものの、数分〜数十分のメンテナンス停止は許容されるサービス設計になっている。公式サイトにも「毎週◯曜の深夜はシステムメンテナンス」といった停止時間が最初から明示されています。
この差は、許容できるダウンタイムを「ビジネス上どこまで値引きできるか」というトレードオフそのものです。ネット銀行は多少のダウンタイムを受け入れることで、クラウドの柔軟性とコスト優位を享受できる。メガバンクは止まらないことを最優先にするぶん、クラウド移行のハードルも上がる——この違いが、進度の差として表れていると見るのが自然です。
メガバンクの勘定系はまだメインフレーム中心
一方で誤解を避けるため補足しておくと、三菱UFJ・三井住友・みずほ・りそなといった国内メガバンクの勘定系本体は、現時点でも大半がメインフレーム上で稼働しています。実態としては勘定系そのものではなく、「周辺系」（インターネットバンキング基盤、データ分析基盤、営業店端末系など）から段階的にクラウド化を進めるアプローチが主流です。「勘定系クラウド化」のニュースを読むときは、本体の移行なのか周辺系の話なのか、という視点で見ると解像度が上がります。
なお、なぜこうした移行プロジェクトが現場ではこれほど大変なのか——新規開発より作り直しのほうが難しいと言われる理由や、本番を守るという立場の重みについては、金融SEを20年やって学んだこと——本番を守る矜持と、仕事のダイナミックさにまとめています。中の人視点での補足として、よければ続けて読んでみてください。
5. クラウド化が銀行サービスの「新しい形」を生む
最後に、私たちユーザー側の視点に話を移します。
ここで一つ断っておきたいのは、よく「クラウドのおかげで実現した」と語られるサービスの中には、実際には分散系システムとAPI連携があれば実現できるものも多い、という点です。たとえば残高連動型の金利優遇や、銀行口座と証券口座のシームレスな連携は、勘定系がメインフレームのままでも連携APIを立てることで提供できますし、実際そうやって作られているサービスも多数あります。つまり「新サービスが出てきた＝クラウド化の成果」と単純に結びつけるのは正確ではありません。
一方で、クラウドだからこそ現実的になる領域も確実にあります。ここでは、個人投資家の視点から見て特に影響の大きい2つを挙げておきます。
① 大量データを活用したパーソナライズ型サービス
取引データ・残高推移・家計データを分析し、「今月の使途内訳」「おすすめの積立額」「ライフイベントに応じた資産配分」などを提案するサービスは、クラウドの拡張性が効く典型領域です。
- 数百万〜数千万口座分のデータを蓄積・分析する基盤を、オンプレで組むのは規模と俊敏性の両立が難しい
- クラウドにはマネージドのデータレイク・データウェアハウス・機械学習基盤が揃っており、必要な計算リソースを分析ジョブ単位で調達できる
- AIによる提案エンジン（目的別貯蓄、投資信託の見直し提案、家計アラートなど）を、銀行が内製で出しやすくなる
個人投資家としては、銀行アプリが「家計と投資の相談相手」に近づいていく方向です。
② 新サービスを早く出して、ダメならすぐ畳めるアジリティ
もう一つ、クラウドの恩恵として実感しやすいのが試行錯誤のしやすさです。
- 新サービスの環境をスモール構成で数日〜数週間で立ち上げられる
- 伸びればスケールアップ、伸びなければそのまま止めて撤退できる
- オンプレだとサーバを買ってしまった時点で5〜7年分の固定費が乗るため、撤退のハードルが高い
結果として、金融機関は「新しい預金プラン」「期間限定のポイント連動商品」「若年層向けの投資スタートパック」など、小さく試して当たれば伸ばすタイプの商品を出しやすくなります。従来のように「数年かけて作って数十年運用する」前提だった勘定系周辺の世界から見ると、この変化は大きいです。
個人投資家の視点では、銀行のクラウド化は「窓口で起きる変化」として表れるものではなく、裏側のデータ活用とサービス開発サイクルの速度が静かに変わっていく、というイメージで捉えるのが実態に近いと思います。
まとめ
- 勘定系とは、銀行のお金の動きをすべて管理する「心臓部」のシステム
- 勘定系の進化は「メインフレーム → オープン分散系 → クラウド」の3段階で進んでおり、一足飛びではない
- クラウド移行が難しかった理由は「無停止要件」「完全整合性」「規制対応」の3つ
- クラウドの信頼性向上・コスト優位性・規制整備により、移行が現実的になった
- コスト面ではハードウェアEOS対応の消失、人材面ではメインフレーム技術者の減少も、クラウド化を後押し
- 銀行内でも情報系は原則クラウド化が進む一方、対顧客・勘定系本体は慎重に評価
- 先行事例のソニー銀行もオープン系からクラウドへ、メガバンクの勘定系本体は今もメインフレーム中心
- 移行は現場レベルでは相当に大変なプロジェクトで、「止めずに切り替える」難しさがある
- クラウド化の先には、私たち個人が使える金融サービスの充実が期待できる
銀行のシステム更改は「古いITのお話」ではなく、私たちの預金・投資環境に直結する話でもあります。インフラが進化することで、個人の資産形成の選択肢も広がっていく——そんな視点でニュースを見ると、また少し面白くなるかもしれません。
