銀行や保険会社、官公庁などの基幹業務（ミッションクリティカル領域）を支えるメインフレーム（汎用機）は、大量のトランザクション処理と極限の信頼性を目的に設計された大型コンピュータシステムで、クラウドやオープン系サーバーが主流となった現在でも、一円の誤差もシステムの瞬断も許されない銀行の「勘定系システム（預金・為替・融資などの根幹処理）」においては、今なお中枢として稼働し続けている。
上の写真は1964年に登場した「IBM System/360」のコンソールと磁気テープ装置で、この時代に確立されたアーキテクチャの思想と互換性が、現在の銀行システムの土台となっている。
1. メインフレームの概要と技術的特徴
一般的なオープン系サーバー（x86サーバーやクラウド環境）が「汎用部品の組み合わせと分散処理」で性能や可用性を担保するのに対し、メインフレームは「1台の筐体（および密結合クラスタ）内での徹底した冗長化と入出力（I/O）の特化」によって安定性を実現している。
銀行がメインフレームを手放せない最大の理由は、「圧倒的なI/Oスループット（ストレージやサーバーが1秒間に処理（読み込み・書き込み）できる「データ転送量」のこと）」と「無停止性」にある。月末や五十日（ごとおび）、年金支給日などに全国から集中する数千万件規模の口座引き落としや振込データを、整合性を完全に保ったまま遅滞なく処理し切るアーキテクチャは、メインフレームならではの強みだ。
2. メインフレームと銀行オンラインシステムの歴史
日本の銀行におけるメインフレームの歴史は、そのまま「銀行オンラインシステムの発展史」と重なる。
・ 商用機の誕生とIBM System/360の衝撃 1950年代〜1964年
1951年のUNIVAC Iに始まり、1964年にIBMが発表した「System/360」が歴史を変えた。「ハードウェアを更新しても、既存のプログラムを書き直さずにそのまま動かせる」というアーキテクチャ概念（後方互換性）を確立し、これが現在まで続く長期稼働の礎となった。
・ 第1次オンラインシステム（単一科目のオンライン化）1965年〜1970年代前半
1965年、三井銀行（現・三井住友銀行）が日本初の普通預金オンラインシステムを稼働させた。それまで支店ごとに帳簿とソロバン・会計機で行っていた処理を本部のメインフレームと通信回線で結び、どの支店でも入出金ができるようになった。また、通商産業省（当時）の主導のもと、富士通・日立・NECなどの国産メーカーがIBM互換機路線・非互換機路線で技術力を高め、国産メインフレームの全盛期を迎える。
・ 第2次オンラインシステム（科目間連動とATM・全銀システム接続） 1970年代後半
普通預金・定期預金・貸付などの科目が連動して処理されるようになり、銀行間のオンライン決済（全銀システム）やCD/ATMの普及が本格化した。処理量が爆発的に増加し、メインフレームのマルチプロセッサ化と大規模データベース化が進んだ。
・ 第3次オンラインシステム（顧客単位管理と国際化・自由化対応） 1980年代後半〜1990年代
金融自由化に伴い、口座単位ではなく「顧客単位（名寄せ）」での総合管理や、リアルタイムでのリスク管理・収益管理が求められるようになった。この時期に各行が巨額を投じて構築した巨大なCOBOLプログラム群が、その後30年以上にわたって稼働し続ける現在の銀行基幹システムの直接の原型となっている。
・ メガバンク統合とオープン化・モダナイゼーションの波 2000年代〜現在
金融ビッグバンと都市銀行の再編（メガバンク化）により、異なるメーカーのメインフレーム間で激しいシステム統合（片寄せや共同化）が行われた。近年ではインターネットバンキングやスマホ決済、API連携などの周辺系システムから順次オープン化・クラウド化が進み、基幹のメインフレームをどう移行・刷新するかが最大の経営課題となっている。
3. なぜ今も使われ続け、何が課題となっているのか
現在、銀行のシステムは「すべてがメインフレーム」ではなく、スマホアプリやWeb画面などの顧客接点（チャネル系・情報系）はクラウドやオープン系で構築し、最後の預金元帳の書き換え（勘定系コア）だけをメインフレームや超大型サーバーで行うハイブリッド構成が一般的となっている。
それにもかかわらず、コア部分の脱メインフレーム（オープン化・クラウド化）が容易に進まない背景には、構造的なジレンマがある。
• スパゲッティ化した巨大プログラム（ブラックボックス化）
第3次オンライン以降、約40年にわたり法改正や新商品、銀行合併のたびにプログラムの継ぎ足し改修が繰り返されてきた。数千万行から億単位のステップ数に膨れ上がったCOBOLコードの全体像を正確に把握できる技術者はすでに定年退職しており、うかつに手を入れられない状態（技術的負債）に陥っている。
• 国産メーカーの撤退と維持コストの高騰
富士通が2030年度末でのメインフレーム製造・販売終了（サポートは2035年度まで）を発表し、NECも撤退方向にあるなど、ハードウェアの選択肢自体がIBM（IBM Zシリーズ）や日立製作所（APシリーズ等での継続支援）など極めて限られたものに縮小している。需要減少に伴う保守費用やライセンス費用の高騰も経営を圧迫している。
• 移行リスクの大きさと「動いているものを変える」ハードル
既存のメインフレームは極めて安定して稼働している。これを数千億円規模の投資をしてオープン系やクラウドへ全面刷新（リビルドやリライト）しようとすれば、移行時の大規模障害リスクを伴うため、経営判断として先送りされやすい構造がある。
近年では、メインフレーム上のCOBOL資産をそのままクラウド上のエミュレータで動かす「リホスト」や、生成AIを活用して古いCOBOLの仕様書を逆生成しJava等へ変換する「モダナイゼーション」、あるいは勘定系パッケージやメインフレーム共同化クラウドへの合流など、各行の体力と戦略に応じた現実的な移行アプローチが模索されているが、難航しているようだ。