2026/3/12

    メインフレームとは|仕組み・利用業界・ベンダー撤退後の3つの選択肢

    【1分でわかるこの記事の要約】

    • メインフレームの現状: 世界の基幹インフラを支える一方で、国内主要ベンダー(富士通・NEC・日立)が相次いで撤退を発表しており、既存ユーザーは「時間制限付き」の決断を迫られている。

    • 経営リスクの顕在化: 富士通の2035年サポート終了を筆頭に、保守費の高騰や技術者不足が加速しており、レガシーシステムの「ブラックボックス化」がDX推進の最大の足かせとなっている。

    • 今後とるべき3つの戦略: 「クラウド等への全面移行」「段階的なハイブリッド運用」「IBM製への継続利用」の3択から、自社の資産可視化を起点とした早期のロードマップ策定が不可欠である。

    メインフレームとは、大量のトランザクション処理を高い信頼性で実行するために設計された大型コンピュータだ。銀行のATM、航空会社の予約システム、年金の支給処理——日常生活のインフラの大半が、今もメインフレーム上で動いている。 IBMの公開データによれば、世界73カ国・28業種でメインフレームが利用されており、グローバル市場は2024年の33.4億ドルから2033年に66.3億ドルへ拡大する見通しだ。

    だが、日本ではメインフレームを取り巻く環境が急変している。富士通は2030年に生産終了、2035年にサポート終了を発表した。NECは2025年度末に販売を終了し、日立は2023年にハードウェア販売を終了済みだ。国産ベンダーの相次ぐ撤退は、約320社に及ぶ富士通ユーザーだけでなく、日本のIT基盤全体に波及する。本記事では、メインフレームの基本から、利用業界の実態、ベンダー動向、今後の3つの選択肢までを整理する。

    メインフレームとは — 定義と3つの技術的特徴

    メインフレーム(mainframe)は、企業や行政機関の基幹業務を処理するために開発された大型コンピュータだ。1960年代にIBMのSystem/360が登場して以来、60年以上にわたってミッションクリティカルな業務の中核を担ってきた。

    特徴1: 大量トランザクション処理の性能

    メインフレームの最大の強みは、大量のトランザクションを同時並行で処理する能力にある。IBMの最新機種IBM z16(2022年発表)は、1日あたり最大3,000億件の推論処理を、1ミリ秒未満のレイテンシーで実行できる。

    この処理性能は、1秒間に数千〜数万件の取引が発生する金融機関の勘定系システムや、数百万件の給与計算をバッチ処理する大企業の基幹システムに不可欠だ。オープン系サーバーやクラウドでも同等の処理は技術的に可能だが、メインフレームは「ハードウェアレベルで最適化された」処理効率を持つ点が異なる。

    特徴2: 99.999%の可用性(Five Nines)

    メインフレームは「Five Nines」と呼ばれる99.999%の可用性を設計目標としている。年間のダウンタイムに換算すると、わずか約5分だ。

    この高可用性は、冗長化されたプロセッサ、メモリ、I/Oチャネルの多重化によって実現されている。単一障害点(SPOF)を排除した設計により、ハードウェアの一部が故障しても業務は止まらない。24時間365日の無停止運用が求められる金融・行政のシステムにとって、この信頼性こそがメインフレームを選ぶ最大の理由になっている。

    特徴3: 垂直統合アーキテクチャ

    メインフレームはハードウェア、OS、ミドルウェアが一体設計されている。IBMのz/OS、富士通のXSP(旧MSP/XSP)、日立のVOS3——各ベンダーが独自のOSとミドルウェアを提供し、ハードウェアとの親和性を最適化してきた。

    この垂直統合が高い安定性と処理効率を生む一方で、特定ベンダーの技術に依存する「ベンダーロックイン」の原因にもなる。メインフレームが抱える課題の根本は、この垂直統合構造にある。

    オープン系・クラウドとの比較

    項目

    メインフレーム

    オープン系サーバー

    クラウド

    処理性能

    大量バッチ処理に最適

    スケールアウトで対応

    弾力的にスケール

    可用性

    99.999%(設計目標)

    冗長構成で99.99%

    SLAで99.95〜99.99%

    初期費用

    数千万〜数億円

    数百万〜数千万円

    従量課金(初期費用小)

    運用費

    高い(保守契約必須)

    中程度

    使用量に応じて変動

    柔軟性

    低い(変更に時間)

    中程度

    高い(即座にスケール)

    ベンダー依存

    高い

    中〜低

    中程度(クラウドロックイン)

    メインフレームが動いている3つの業界

    メインフレームは「一部の大企業だけが使う特殊な機械」ではない。社会インフラの根幹を支えている存在だ。

    金融業界: 勘定系の中核

    メインフレームが最も深く根を張っているのが金融だ。メガバンク・地方銀行の勘定系システム、生命保険の契約管理、損害保険の支払処理、証券の約定管理——いずれもメインフレーム上で稼働している。

    勘定系システムは歴史的経緯と業務の重要性、そしてトランザクション量の巨大さから、ほぼメインフレームで構成されてきた。一部の地方銀行やネット銀行がオープン系への移行を進めているものの、メガバンクの勘定系がメインフレームを離れるにはまだ相当な時間がかかる。

    製造業: 生産管理・受発注の基盤

    大手製造業の生産管理システム、受発注システム、在庫管理システムにもメインフレームが使われている。自動車、電機、鉄鋼などの大規模製造業では、数十万件の部品データ管理や日次バッチ処理にメインフレームの処理能力が活用されてきた。

    SAP等のERPパッケージへの移行が進みつつあるが、独自の生産管理ロジックをERPの標準機能に完全に置き換えられないケースは珍しくない。メインフレーム上の独自システムが並行稼働し続けている企業は、製造業に限っても相当数に上る。

    行政・公共: 年金・税務・社会保障

    年金の支給管理、国税の申告処理、社会保障の給付管理——行政の基幹系にもメインフレームは広く浸透している。住民基本台帳や固定資産税の計算など、自治体レベルでもメインフレームを利用している団体がある。

    行政のメインフレームは、法改正への対応で数十年にわたり改修が累積しており、レガシーシステムのブラックボックス化が特に深刻な領域だ。仕様書が残っていない、当時の担当者はすでに退職している——こうした状況は行政に限らず、メインフレームを長年使い続けてきた組織に共通する課題でもある。

    日本のメインフレーム — ベンダー動向と「撤退」の実態

    日本のメインフレーム市場は、世界でも特異な構造を持っていた。IBM、富士通、NEC、日立の4ベンダーが競合する「4社体制」は、日本だけの状況だった。

    富士通: 2030年生産終了→2035年サポート終了

    2024年時点で約320社・650台が稼働する富士通のメインフレームは、2030年に生産を終了し、2035年にサポートを終了する。「2035年の崖」とも呼ばれるこの問題は、富士通ユーザーに10年以内の移行を迫っている。

    320社の業種は金融、製造、流通、公共と多岐にわたる。いずれの企業も、数年単位の移行プロジェクトを計画・実行しなければならない。

    NEC: 2025年度末に販売終了

    NECはメインフレームの新規販売を2025年度末で終了する。既存ユーザーへのサポートは一定期間継続されるが、新規導入の選択肢は事実上消えた。

    日立: 2023年にハードウェア販売終了

    日立は2023年にメインフレームのハードウェア販売を終了した。ソフトウェアのサポートは継続しているが、ハードウェアの更改はできない状態だ。

    IBM: z16で進化継続

    国産ベンダーが撤退する中、IBMはメインフレームの進化を続けている。2022年発表のIBM z16はAI推論エンジンを内蔵し、トランザクション処理中にリアルタイムでAI分析を実行できる。IBMのメインフレームは「消える技術」ではなく、クラウドとの統合(ハイブリッドクラウド)やAI連携を通じて、新たな価値を提示し続けている。

    ただし、日本市場においてIBMメインフレームへのプラットフォーム移行は、富士通やNECのユーザーにとって「ベンダーロックインの乗り換え」になるリスクもある。慎重な判断が欠かせない。

    メインフレームの今後 — 3つの選択肢

    国産ベンダーの撤退を受けて、メインフレームユーザーには3つの選択肢がある。

    選択肢1: 脱メインフレーム(オープン系/クラウドへ全面移行)

    メインフレーム上のシステムを、リホスト・リライト・リビルドのいずれかの方式でオープン系やクラウドに全面移行するアプローチだ。保守費の削減、技術者確保の容易化、モダン技術との連携が可能になる。

    メインフレーム移行で詳述した通り、方式ごとにコスト・期間・リスクが大きく異なる。大規模システムの全面移行には3〜5年以上を要するケースが一般的で、移行プロジェクト自体のリスク管理が成功の鍵を握る。

    選択肢2: 段階的モダナイゼーション(ハイブリッド運用)

    メインフレームをすぐに廃止せず、API連携やデータ連携基盤を介してクラウドやオープン系と「つなぐ」アプローチだ。コアのバッチ処理はメインフレームのまま維持し、フロントエンドやデータ分析基盤にモダン技術を採用する。

    キンドリルの2025年調査でも、企業のメインフレームモダナイゼーション戦略が「一括移行型」から「段階的アプローチ」へシフトしている傾向が確認されている。メインフレームのオープン化と組み合わせて、段階的に依存度を下げていく方法だ。

    選択肢3: IBMメインフレームへの移行継続

    富士通やNECのユーザーが、IBMのメインフレーム(z系)に移行して継続利用する選択肢だ。メインフレームの処理特性をそのまま活かせるが、IBMへの新たなベンダーロックインが発生する。

    IBMは進化を続けているとはいえ、日本国内でのIBMメインフレーム技術者の確保やIBM独自のOS(z/OS)への習熟が新たに必要になる。長期的にオープン系やクラウドへの移行が避けられないのであれば、中間ステップとしてのIBM移行にどれだけの投資が正当化されるか、冷静な見極めが求められる。

    どの選択肢を選ぶべきか

    選択は一律ではない。自社のシステム規模、メインフレーム上の業務の重要度、保守契約の残存期間、技術者の確保状況、そしてDX戦略との整合性——これらを総合的に判断する必要がある。

    いずれの選択肢を取る場合でも、最初のステップは現行システムの可視化だ。メインフレーム上で何が動いているのか、どのプログラムがどの業務に対応し、どのようなデータが流れているのかを正確に把握しなければ、移行計画もモダナイゼーション計画も立てられない。

    まとめ — メインフレームは「過去」ではなく「現在」の課題

    ポイント

    内容

    定義

    大量トランザクション処理に特化した大型コンピュータ

    3つの特徴

    大量処理性能・99.999%可用性・垂直統合アーキテクチャ

    利用業界

    金融(勘定系)・製造業(生産管理)・行政(年金・税務)

    ベンダー動向

    富士通2035年撤退、NEC・日立は販売終了、IBMのみ進化継続

    今後の選択肢

    全面移行・段階的ハイブリッド・IBM継続の3択

    メインフレームは「過去の遺物」ではない。今この瞬間も銀行の送金を処理し、年金を支給し、生産ラインを動かしている「現在の基盤」だ。だが、国産ベンダーの撤退という現実は、メインフレームユーザーに時間制限付きの判断を迫っている。富士通の2035年サポート終了まで残された時間は9年。大規模移行プロジェクトに必要な期間を考えれば、判断を先延ばしにできる猶予は想像以上に短い。


    メインフレーム上のシステム、仕様を可視化できていますか?

    エイジレスでは、独自AI「ARIADNE」がメインフレームのソースコード(COBOL、PL/I、アセンブラ等)から処理内容・依存関係を自動解析し、移行やモダナイゼーション計画の土台となるドキュメントを生成します。

    ASIS解析の資料をダウンロード


    よくある質問

    Q: メインフレームとサーバーの違いは何ですか?

    A: メインフレームは大量トランザクションの集中処理に特化し、ハードウェアレベルで高可用性(99.999%)を実現する設計だ。一般的なサーバー(x86サーバー等)はスケールアウト(台数を増やして対応)で処理能力を拡張するのに対し、メインフレームはスケールアップ(1台の性能を上げて対応)で大量処理をこなす。また、メインフレームは独自のOS(z/OS、XSP等)で動作し、垂直統合設計による安定性が強みだが、汎用サーバーに比べてコストが高く、専門技術者が必要になる。

    Q: メインフレームはいつまで使えますか?

    A: ベンダーごとに異なる。富士通は2030年生産終了・2035年サポート終了。NECは2025年度末に新規販売終了。日立は2023年にハードウェア販売を終了済み。IBMは進化を続けており、現時点で撤退の予定はない。ただし、「使える」と「使い続けるべき」は別の判断だ。技術者の確保難や保守コストの上昇を考えると、サポート終了を待たずに移行やモダナイゼーションを計画するのが合理的といえる。

    Q: メインフレームからの移行にはどれくらいの期間が必要ですか?

    A: システムの規模と複雑さ、選択する移行方式によって大きく異なる。数千万ステップ規模の大規模システムでは3〜5年以上が一般的だ。リホスト(そのまま移す)なら比較的短期間で済むが、リビルド(作り直す)なら長期になる。移行そのものの期間に加えて、事前のシステム可視化、テスト、並行運用期間も必要だ。富士通の2035年サポート終了から逆算すると、2027〜2028年頃には移行プロジェクトを開始する必要がある。