はじめに
「メインフレームはレガシーだから、クラウドに移行するべきだ」
この一文を、何度聞いただろうか。会議室で、設計書のレビューで、採用面接で。
しかし「レガシー」という言葉を使う人に、こう問い返したことがある。「IBM Z16が毎秒処理できるトランザクション数を知っていますか？」──答えられた人は、ほとんどいなかった。
批判は数字で行うべきだ。感情や印象で語られる「レガシー」という言葉の罠を、この記事で解体する。
1. 「レガシー」という言葉の罠
定義が曖昧なまま使われている
「レガシーシステム」という言葉に、明確な定義はない。
IT業界で慣用的に使われる意味は、おおむね以下のどれかだ。
- 古い技術で構築されたシステム
- メンテナンスが困難になったシステム
- 現代の開発手法と相容れないシステム
問題は、これらがまったく異なる性質の問題であるにもかかわらず、「レガシー」という一語に混ぜ込まれていることだ。
「古い技術」と「メンテナンスが困難」は別の話だ。Linuxカーネルは1991年生まれだが、誰もレガシーとは呼ばない。Cは1972年生まれだが、今もOSやファームウェアの中核を担っている。
「古い＝劣っている」という誤った前提
メインフレームが「レガシー」と呼ばれるとき、その背後には「古い＝劣っている」という暗黙の前提がある。
しかしこれは、特定の評価軸においてのみ成立する主張だ。
- 開発者の採用しやすさ：クラウドネイティブ技術が優位
- 機能リリースの速度：マイクロサービスが優位
- トランザクション単価の処理コスト：要件次第
- スループット・可用性・10進演算精度：メインフレームが優位
「レガシー」という言葉は、特定の軸での劣位を全軸の劣位であるかのように見せる修辞だ。
メインフレームを正しく形容する言葉
メインフレームを正確に表現するなら、「ミッションクリティカル専用機」だ。
汎用性を犠牲にして、信頼性・可用性・スループットの3点において他の追随を許さない設計になっている。これは欠点ではなく、設計上の意図だ。
2. 数字で比較する──処理能力の現実
IBM Z16 vs クラウドの処理能力
感情論を排し、数字で比較する。
| 指標 | IBM Z16 | AWS（単一システム） |
|---|---|---|
| 最大スループット | 1日3,000億件（秒間約350万TPS）※単一DBのACID特性を維持 | 分散時のネットワーク遅延がボトルネック |
| 可用性 | 99.999%（年間約5分停止） | 99.99%（年間約52分停止・主要SLA） |
| 障害耐性アーキテクチャ | ハードウェアによる完全二重化（ロックステップ実行・RAIMメモリ） | ソフトウェアによる冗長化（マルチAZ・マルチリージョン分散） |
| 10進演算（金額計算） | ハードウェアネイティブ（DFUにより丸め誤差をハードウェアで完全回避） | ソフトウェアエミュレーション（ライブラリ処理による速度低下） |
タイトルの「毎秒350万件」は、3,000億件÷86,400秒から導いた数字だ。これが1台・単一データストア・ACID特性を完全維持した状態で出るスループットだということを、改めて強調したい。
クラウドで同等のトランザクション数を捌こうとすると、必然的に分散トランザクションが必要になり、そのオーバーヘッドとネットワーク遅延がボトルネックになる。「分散せずに一元管理したまま捌く能力」──これがメインフレームの本質的な強みだ。
可用性99.999%の実態
「ファイブナイン」と呼ばれる可用性基準の意味を、時間に換算する。
| 可用性 | 年間停止時間 | 代表的なシステム |
|---|---|---|
| 99.9%（スリーナイン） | 約8.7時間 | 一般的なWebサービス |
| 99.99%（フォーナイン） | 約52分 | AWSの主要SLA |
| 99.999%（ファイブナイン） | 約5分 | メインフレーム |
| 99.9999%（シックスナイン） | 約31秒 | 一部の金融系メインフレーム |
銀行のATMネットワークが「年間52分止まっても許容範囲」という設計にはできない。その要件を満たせる唯一の選択肢が、今もメインフレームだ。
「クラウドに移せばいい」が成立しない領域
クラウドは優れたプラットフォームだ。しかし以下の要件が重なる領域では、現時点でメインフレームの代替になっていない。
- 1日数億〜数千億件のトランザクション処理（単一DBのACID特性を維持したまま）
- 1円単位の誤差が許されない金額計算
- 年間5分以内のダウンタイム要件
- 1システムでの暗号化・認証・監査証跡の一元管理
これらが重なるのが、銀行の勘定系・証券の清算系・公共の社会保障系だ。
3. なぜクラウドは追いつけないのか──アーキテクチャの根本差
設計思想が異なる
クラウドとメインフレームは、可用性の担保方法が根本から違う。
【クラウド（分散型）の可用性設計】
サーバーA ─┐
サーバーB ─┼─► ロードバランサー ──► ユーザー
サーバーC ─┘
どれかが落ちても他が補う。「障害を前提とした設計」。
【メインフレーム（集中型）の可用性設計】
┌──────────────────────────────────┐
│ IBM Z16 │
│ ┌────────────┐ ┌────────────┐ │
│ │ロックステップ │ │RAIMメモリ │ │
│ │ (CPU二重化) │ │(メモリRAID)│ │
│ └────────────┘ └────────────┘ │
│ ┌──────────────────────────┐ │
│ │ チャネルI/O（専用回路） │ │
│ └──────────────────────────┘ │
└──────────────────────────────────┘
ハードウェアレベルで障害を「発生させない」設計。
クラウドは「障害は起きる、だから複数で補え」という哲学。メインフレームは「障害を起こすな」という哲学だ。どちらが優れているではなく、要件に応じて使い分けるべき異なるアプローチだ。
チャネルI/OとSysplex
メインフレームの高スループットを支える技術の一つがチャネルI/Oだ。
一般的なサーバーではCPUがI/O処理を管理する。メインフレームでは**専用のI/Oプロセッサ（チャネル）**がI/Oを担当し、CPUは演算に専念できる。これにより、I/Oボトルネックなしに大量の並行トランザクションを処理できる。
さらにSysplex（システム・コンプレックス）を使えば、複数のメインフレームを論理的に1つのシステムとして動作させながら、フェイルオーバーをミリ秒単位で完了できる。
ロックステップ実行とRAIMメモリ──ECCを超えた次元
よくある誤解を先に潰しておく。現代のx86サーバー（AWSのEC2ホスト含む）も、当然ハードウェアレベルでECCメモリを採用している。「メインフレームだけがECCを使っている」という話ではない。
メインフレームの信頼性が格の違う理由は、ECCを超えた2つの仕組みにある。
① ロックステップ実行（Lockstep Execution）
2つのCPUコアがまったく同じ命令を同時に実行し、1ビットの演算結果の不一致も即座に検出してマスクする。x86サーバーではソフトウェアの冗長化（アプリ層での再試行）で対処するところを、メインフレームはCPU命令レベルの二重化で封じる。
② RAIM（Redundant Array of Independent Memory）
メモリをRAIDのように冗長化する仕組みだ。DRAMチップ1枚が完全に故障しても、データを復元しながら無停止で稼働を継続できる。ECCが「1ビットの誤りを訂正する」のに対し、RAIMは「チップ全体の故障を吸収する」。
加えて、通電状態でのアクティブ保守（部品交換・マイクロコードアップグレードを無停止で実施）が標準機能として備わっている。
信頼性の担保が「ソフトウェアの分散」か「ハードウェアの絶対性」かという差は、1円のズレも許されないミッションクリティカルな用途では決定的になる。
4. 「レガシー」と呼ばれる本当の理由
スキル不足による「わからない＝古い」の誤認
現場で観察してきた事実を言う。「メインフレームはレガシー」と声高に主張する人の多くは、COBOLもJCLも読んだことがない。
わからないシステムを「古い」と形容することで、理解していないという事実を隠す。これは技術的な評価ではなく、認識論的な防衛反応だ。
「読んだことがないが批判している」と「読んで理解した上で課題を指摘している」は、まったく異なる。後者には技術的な敬意が払われるべきだ。
ベンダーのクラウド移行ビジネスの文脈
「メインフレームはレガシー、クラウドへ移行を」という言説が強化される背景には、ビジネス上の動機もある。
クラウドベンダーにとって、大規模メインフレームからの移行は巨大な商機だ。メインフレームのライセンスコストが高いことは事実だが、「移行すれば必ずコストが下がる」という主張は、移行コスト・リアーキテクチャコスト・運用コストを意図的に小さく見せることで成立しているケースがある。
判断は数字で行うべきだ。移行後のTCO（総保有コスト）を、10年単位で比較した試算を持っているか否かが、議論の質を分ける。
技術的負債と業務知識の蓄積を混同している
「メインフレームの50年分のCOBOL」を技術的負債と呼ぶ人がいる。しかしその中身は2種類だ。
| 種類 | 内容 | 対処方針 |
|---|---|---|
| 真の技術的負債 | 誰も理解していない重複ロジック、テストのないデッドコード | 整理・削除の対象 |
| 業務知識の蓄積 | 金融規制変更の履歴、特例処理、障害対応の痕跡 | 読み解いて引き継ぐ対象 |
この2つを区別せず「全部レガシー」と括ることは、何十年分もの業務知識を廃棄しようとしていることに等しい。
5. では何と呼ぶべきか──正しい評価軸
ミッションクリティカル専用機としての再定義
メインフレームを正しく評価するための軸は3つだ。
① 処理要件に対する適合性
1日に何件のトランザクションを、どの精度で、どの可用性で処理するか。この要件を定量的に示した上で、メインフレームとクラウドを比較する。
② 移行の実現可能性
対象コードの規模、業務知識の属人度、移行期間中の並行稼働コスト、本番切り替えリスク。これを定量的に評価した上で移行の是非を判断する。
③ 長期的なTCO
ライセンスコストだけでなく、移行コスト・再開発コスト・運用コスト・リスクコストを含めた10年以上のスパンで比較する。
モダナイゼーションの正しい目的
モダナイゼーション（近代化）とは、メインフレームを「廃止」することではない。
業務ロジックを読み解き、現代の技術スタックで再構築可能な部分を段階的に移行しながら、ミッションクリティカルな核心部分はメインフレームに残す──これが現実的なアプローチだ。
Strangler Figパターン（絞め殺しの木）と呼ばれる段階的移行戦略は、まさにこの「共存」を前提としている。
[現行] [移行後イメージ]
メインフレーム メインフレーム
├─ 勘定系コア → ├─ 勘定系コア（維持）
├─ バッチ処理 → ├─ バッチ処理（維持）
├─ 照会系 → │
└─ 外部連携 → │
クラウド/モダン環境
├─ 照会系API（移行済）
└─ 外部連携（移行済）
↕ API連携
「全部クラウドへ」でも「何も変えない」でもなく、要件に応じた最適な共存が、現場で機能するアーキテクチャだ。
エンジニアとして持つべき視点
技術に「レガシー」と「最新」という二項対立を持ち込むことは、エンジニアとして損だ。
評価すべきは技術の年齢ではなく、要件への適合性だ。COBOLが1959年生まれであることは、銀行の勘定系における信頼性の根拠にはなっても、否定の根拠にはならない。
「読んだことがない技術を批判しない」「数字なき評価をしない」──この2つを守るだけで、技術的な議論の質は大きく変わる。
おわりに
メインフレームは「レガシー」ではない。要件定義の精度が問われる、ミッションクリティカル専用機だ。
批判するなら数字で。評価するなら軸を明確にして。「よくわからないから古い」という論法は、エンジニアとして一番避けるべき思考だ。
今日もあなたの給与を正確に計算し、ATMのトランザクションを処理し、証券の清算を間違いなく完了させているシステムに対して、せめて「なぜ動き続けているのか」を問う姿勢は持っていたい。
本記事ではメインフレームの処理能力と設計思想を中心に論じたが、「では実際に何が起きているのか」という現場の現実については、noteにて連載記事を公開している。
2024年の富士通メインフレーム新規販売終了が意味するもの、2030年保守終了・2035年製造終了という二重のタイムライン、富士通・日立・IBM・NECの四社体制の歴史的経緯と棲み分け、そして移行技術者の枯渇が引き起こす「キャパシティ・クランチ」──これらを第0章として整理した。
「動き続けること」が最大のリスクになる時代に、何をどの順番で判断すべきか。レガシーモダナイゼーションの現場のリアルに興味がある方は、ぜひ合わせて読んでほしい。
日本の汎用機はどこへ行くのか：2035年問題の深淵（note連載）