メインフレーム & レガシーシステム 2026 — IBM z17 (2025.9) / IBM i / COBOL / RPG / JCL / CICS / watsonx Code Assistant for Z 深掘りガイド

プロローグ — 死んだと言われ続けて、まだそこにある

「メインフレームは死んだ」という見出しは 1990 年代から毎年出ている。それでも 2026 年 5 月、あなたが ATM で現金を引き出し、クレジットカードを切り、航空券を予約し、税金を払い、自治体に出生届を出すその瞬間、トランザクションの最後の一行は極めて高い確率で メインフレーム上の COBOL プログラム を通過する。

• IBM Z — 2025 年 9 月に z17 発表。Telum II プロセッサ、オンチップ AI アクセラレーション。
• IBM i (旧 AS/400) — 130,000 社以上が運用中。ERP、倉庫管理、保険。
• COBOL — 推定 200~220B(2,000 億)行が本番で動く。毎日。
• RPG / JCL / CICS / Db2 z/OS / IMS / PL/I — いずれも現役。
• Fujitsu BS2000 / NEC ACOS / Unisys ClearPath — 非 IBM メインフレームの世界。

そしてこの巨大なレガシーは、2023 年以降に AI という新しい変数と出会い、再び現代化のサイクルに入る。IBM watsonx Code Assistant for Z は COBOL を Java へ変換し、GitHub Copilot は COBOL 補完を支援し、AWS Mainframe Modernization はメインフレームのワークロードをクラウドに引き上げる。

この記事は 2026 年時点のメインフレームを扱う。どうやって死ななかったのか、新しいハードウェアは何か、AI はこの巨大なレガシーをどう削っているのか、そして — もしあなたが開発者なら — なぜ今 COBOL を学ぼうとする人がいるのか。

1章 · 2026 年のメインフレーム — 死ななかった巨人

まず数字から。2026 年時点のメインフレーム・エコシステムの推定:

(出典: IBM、Forrester、Gartner の市場推定 — 正確な数字は出典により異なる。本記事の数値はいずれも 2024~2025 年の公開資料に基づく推定値。)

「なぜ置き換えないのか」は誤った問いだ。正しい問いは 「置き換えないことが合理的な理由は何か」 である。答えは三つに圧縮される。

1. 検証された信頼性 — z/OS の可用性はしばしば 99.999%(5 nine)以上と報告される。年間ダウンタイム約 5 分。新システムでこれを並ぶには年単位の時間が要る。
2. 未検証の変更リスク > 変更の価値 — 2,000 万行の保険会社の基幹を Java に書き直すとする。2 年、1 億ドル。その間、新機能は出せない。CFO はサインしない。
3. データ重力 — Db2 z/OS、IMS、VSAM に数十年蓄積されたデータがそこにある。データを動かす方がコードを動かすより難しい。

だからメインフレームは死ななかった。死ぬ代わりに、ゆっくり進化する。それがこの記事の主題だ。

2章 · IBM z17 (2025.9) — Telum II + 統合 AI

2025 年 9 月、IBM は z17 を発表した。前世代の z16 は 2022 年 4 月発売だったので、約 3 年周期だ。z17 の核は二つ。

Telum II プロセッサ

• 5nm 級プロセス(正確なノードは IBM は通常公開しない)
• 8 コア、5 GHz 帯クロック(z16 の Telum I に比べてコア性能向上)
• オンチップ AI アクセラレータ — Telum I のオンダイ AI 推論を強化。トランザクションの流れの中に不正検知などの ML 推論を 1ms 以内で挟み込める。
• L2 キャッシュ構造の改善、NUMA トポロジ最適化。

要するに、Telum II は トランザクションの中に AI 推論を埋め込める。カード決済が起きるまさにその瞬間に、同じチップ上で不正検知モデルが動く。GPU クラスタへデータを送る必要はない。

Spyre アクセラレータ (オプション)

z16 で初登場した IBM Spyre AI アクセラレータ(別途 PCIe カード)は、z17 でもオプションで提供される。Spyre はより大きなモデル(生成 AI 推論)向けの独立アクセラレータで、Telum II のオンチップ加速と併用できる。

何が変わったか (z16 比)

z17 は革命というより AI 統合の深化 だ。トランザクション + AI 推論 + セキュリティを一つのチップで完結させるという IBM のメッセージはより強くなった。

z17 を買うのは誰か

• グローバル銀行・カード会社 — 不正検知をトランザクション・インラインで。
• 大手保険会社 — クレーム処理 + リスクスコアリング。
• 政府・税務 — 大量バッチ + セキュリティ。
• 航空・物流 — 予約・在庫システムの基盤。

価格は公開されない。たいていは「数百万ドル〜」とだけ言われる。そしてその額を支払う会社は、それが合理的だと信じている。

3章 · IBM z16 — まだ現役

z17 が出たからといって z16 が消えたわけではない。2022 年 4 月発表の z16 は 2026 年現在も活発に販売・導入されている。メインフレームのライフサイクルは長い — 一度入ると 10 年は使う。

z16 の特徴を整理すると:

• Telum I プロセッサ — IBM が初めてオンチップ AI 加速を導入した世代。
• 耐量子暗号 — Crypto Express 8S カードと併用。NIST 標準化された PQC アルゴリズムの一部に対応。
• Pentide (IBM Telum) キャッシュ構造 — L2 を仮想 L3/L4 として活用し、約 256 MB 級の仮想 L4 キャッシュを実現する独特の設計。
• z/OS 2.5 / 3.1 対応。

銀行が z16 を導入したばかりなら、z17 に乗り換える動機は弱い。多くは z16 + ファームウェア更新 で 2030 年代前半までは運用するだろう。

4章 · IBM i (旧 AS/400) — 130K+ 社

IBM Z ほどには有名でないが、IBM のもうひとつのメインフレーム系列がある。IBM i — 1988 年発売の AS/400 の後継だ。

名前の歴史

• System/38 (1978)
• AS/400 (1988) — Application System/400。80~90 年代中堅企業 ERP の象徴。
• eServer iSeries (2000)
• System i (2006)
• IBM i (2008~現在) — OS 名であり、プラットフォーム名でもある。

ハードウェアは IBM Power サーバの上で動く。つまり IBM i は Power Systems のハードウェア + IBM i OS の組み合わせだ。2026 年時点では Power10 上で IBM i 7.5 / 7.6 などが動いている。

なぜ未だに 130,000 社が使うのか

• 単一オブジェクトモデル — ファイル、プログラム、DB オブジェクトが同じシステムオブジェクトモデルの中にある。運用がシンプル。
• TIMI (Technology Independent Machine Interface) — ハードウェア抽象化。新しい Power チップが出てもコンパイル済みプログラムがそのまま動く。
• 内蔵 Db2 for i — DB を別途運用しなくてよい。
• 運用コストが低い — メインフレーム水準としては。1 台で ERP・倉庫・財務を全部回せる。

主要利用業界

• 米国・欧州の中堅製造業
• 日本の食品・小売・物流企業
• 韓国でも一部の中堅製造・流通が運用(サイト数は非公開のものが多い)
• 欧州の保険会社
• 小売チェーン

ERP パッケージとしては JD Edwards、Infor (旧 SSA Global)、BPCS などが IBM i 上で動く。

RPG — IBM i の主力言語

IBM i の主力プログラミング言語は RPG (Report Program Generator)。次の章で深く掘る。

5章 · COBOL — 推定 200~220B 行が本番稼働

COBOL は 1959 年にグレース・ホッパーらを含む委員会が設計した言語だ。名前の意味は COmmon Business Oriented Language。60 年以上の言語が、まだ 200B 行が動く。

なぜそれほど多いのか

• 金融基幹システム — ほぼ全ての大手銀行のコアバンキング。
• 保険のクレーム/契約処理 — 自動車・生命・損害。
• 政府の税務・福祉 — 米国 IRS、韓国国税庁の一部、英国 HMRC など。
• 航空予約 — Sabre、Amadeus のような GDS の一部基盤に COBOL が残っている。
• 小売・製造 ERP — IBM i 上で RPG と組み合わせて。

200B 行という数字は 累計 だ。毎年新規に書かれる COBOL は減るが、消されもしない。だから行数は増え続ける。

COBOL コードの形

       IDENTIFICATION DIVISION.
       PROGRAM-ID. INTEREST-CALC.
       AUTHOR. YJ.
      *
       ENVIRONMENT DIVISION.
       CONFIGURATION SECTION.
       SOURCE-COMPUTER. IBM-Z.
       OBJECT-COMPUTER. IBM-Z.
      *
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01  WS-PRINCIPAL       PIC 9(7)V99 VALUE 1000000.00.
       01  WS-RATE            PIC 9(3)V99 VALUE 3.50.
       01  WS-YEARS           PIC 9(2) VALUE 5.
       01  WS-INTEREST        PIC 9(9)V99.
       01  WS-TOTAL           PIC 9(9)V99.
      *
       PROCEDURE DIVISION.
       CALC-INTEREST.
           COMPUTE WS-INTEREST = WS-PRINCIPAL * (WS-RATE / 100) * WS-YEARS.
           COMPUTE WS-TOTAL    = WS-PRINCIPAL + WS-INTEREST.
           DISPLAY "Principal : " WS-PRINCIPAL.
           DISPLAY "Interest  : " WS-INTEREST.
           DISPLAY "Total     : " WS-TOTAL.
           STOP RUN.

COBOL の特徴:

• 自然言語のような構文 — COMPUTE, DISPLAY, STOP RUN。英文のように読める。
• 固定カラム書式 (伝統的) — 1-6 シーケンス、7 表示子、8-11 領域 A、12-72 領域 B。現代の COBOL は free-format にも対応。
• PIC 句 — データの形(picture)を定義。PIC 9(7)V99 は整数 7 桁、小数 2 桁の意味。
• DIVISION 構造 — IDENTIFICATION、ENVIRONMENT、DATA、PROCEDURE の 4 部構成。

COBOL 規格の流れ

• COBOL-60 → COBOL-68 → COBOL-74 → COBOL-85 (長らくの事実上の標準) → COBOL 2002 → COBOL 2014 → COBOL 2023。
• 現代規格は OOP、Unicode、XML/JSON 処理にも対応。

COBOL コンパイラ

• IBM Enterprise COBOL for z/OS — z/OS の正統。
• IBM COBOL for AIX / Linux on Z
• Micro Focus Visual COBOL (現在は OpenText 傘下) — Windows/Linux/メインフレーム互換。
• GnuCOBOL — オープンソース。C にトランスパイル。(後の章で詳述)

6章 · RPG / JCL / CICS / Db2 z/OS / IMS / PL/I

COBOL はメインフレーム言語の中で最も有名なだけだ。環境には他の中核技術がある。

RPG (Report Program Generator) — IBM i の主力

名前は「レポート生成器」だが、現代の RPG は汎用ビジネス言語だ。流れ:

• RPG II (1960 年代~)
• RPG III (System/38)
• RPG IV / RPG/ILE (AS/400 時代から現在)
• Free-format RPG (現代) — COBOL の free-format と同様、カラム位置に縛られない形態。

現代の free-format RPG 例:

**free
ctl-opt main(main);

dcl-proc main;
  dcl-s principal packed(9:2) inz(1000000);
  dcl-s rate     packed(5:2) inz(3.50);
  dcl-s years    packed(2:0) inz(5);
  dcl-s interest packed(11:2);
  dcl-s total    packed(11:2);

  interest = principal * (rate / 100) * years;
  total    = principal + interest;

  dsply ('Total: ' + %char(total));
end-proc;

RPG は データベースと非常に強く結合 している。SQL を RPG の中にインラインで書ける embedded SQL が標準だ。

JCL (Job Control Language)

z/OS でバッチ・ジョブを定義する言語。「不愉快な古いシェルスクリプト」と揶揄されるが、メインフレーム運用の血管だ。

//PAYROLL  JOB  (ACCT1234),'PAYROLL JOB',
//             CLASS=A,MSGCLASS=X,REGION=4M
//STEP1    EXEC PGM=PAYCALC
//STEPLIB  DD   DSN=PROD.LOADLIB,DISP=SHR
//INPUT    DD   DSN=PROD.PAYROLL.MASTER,DISP=SHR
//OUTPUT   DD   DSN=PROD.PAYROLL.NEWRUN,DISP=(NEW,CATLG,DELETE),
//              SPACE=(CYL,(10,5)),
//              DCB=(LRECL=200,BLKSIZE=27800,RECFM=FB)
//SYSPRINT DD   SYSOUT=*

JCL の特徴:

• // で始まるカラム依存の構文。
• JOB → EXEC → DD カード構造 — ジョブ → 実行ステップ → データセット。
• DSN でデータセット名、DISP で処分(SHR/MOD/NEW)、SPACE で領域確保。
• STEPLIB でライブラリ、SYSPRINT でログ出力。

JCL は運用者の資産だ。良い JCL の一行は会社を救う。悪い JCL の一行は会社を破産させる(プロダクションマスターを DISP=NEW,DELETE で消す、という永遠のジョーク)。

CICS (Customer Information Control System)

z/OS の トランザクション・モニタ。1969 年から稼働している。CICS は:

• 端末(伝統的に 3270)や Web/モバイルから来たリクエストを受け、
• トランザクション 単位でビジネスロジック(COBOL/PL/I など)を実行し、
• 結果を返す。
• 分散トランザクション(2PC)を処理し、Db2/IMS と統合される。

現代の CICS は CICS Transaction Server という名で z/OS 上で動く。REST/JSON インタフェースもサポートする。

Db2 z/OS (IBM Db2 for z/OS)

z/OS の標準リレーショナル DB。他環境の Db2 (LUW、for i) とはコードベースが別だ。2026 年時点で Db2 for z/OS V13 以降のバージョンが運用される。

Db2 z/OS のアイデンティティ:

• トランザクション処理 + データウェアハウス を一つのシステムで。
• Pentide キャッシュ + Telum オンチップ加速 + Db2 AI Query Optimizer など — メインフレーム HW と結合した性能。
• 巨大な累積データ — ペタバイト級の運用が普通。

IMS (Information Management System)

1968 年にアポロ計画のために作られた 階層型 DB + トランザクション・モニタ。リレーショナル DB(Db2)より古く、いくつかの大手銀行・航空・製造は今でも IMS DB と IMS TM を運用している。「古い = 使われていない」ではない — 古いから 検証済みで速い。

PL/I (Programming Language One)

1964 年に IBM が COBOL と Fortran を統合する野心で作った。結局両方を置き換えることはなかったが、一部の大型システム(特に欧州銀行、一部の OS コード)で今も使われる。

TEST: PROC OPTIONS(MAIN);
  DCL PRINCIPAL FIXED DEC(9,2) INIT(1000000);
  DCL RATE      FIXED DEC(5,2) INIT(3.50);
  DCL YEARS     FIXED BIN(15)  INIT(5);
  DCL INTEREST  FIXED DEC(11,2);
  DCL TOTAL     FIXED DEC(11,2);

  INTEREST = PRINCIPAL * (RATE / 100) * YEARS;
  TOTAL    = PRINCIPAL + INTEREST;

  PUT SKIP LIST('Total: ', TOTAL);
END TEST;

PL/I は COBOL より表現力は高いが学習曲線も急だ。「あるところにはあるが、新規には始まらない」。

7章 · Fujitsu BS2000 / NEC ACOS / Unisys ClearPath — 非 IBM メインフレーム

「メインフレーム = IBM」という認識はよく見るが、不正確だ。日本・欧州・米国の一部では、IBM ではないメインフレームが現在も稼働している。

Fujitsu BS2000 (日本/ドイツ)

• もとはドイツ Siemens の BS2000 OS。後に富士通が Siemens のコンピュータ事業を吸収。
• 現在は富士通の FUJITSU Server BS2000 ライン。OS は OSD/BC、BS2000/OSD などへ進化。
• 主にドイツ・オーストリア・スイスの政府・銀行・保険で運用。
• COBOL、ASSEMBLER、C/C++ をサポート。SQL DB (SESAM、UDS) もある。
• 富士通は日本国内向けのメインフレーム製品(PRIMEFORCE シリーズ等、年代によりラインアップが変動)も持つ — 最新の名称は富士通公式資料を参照。

NEC ACOS (日本)

• NEC の ACOS-4 OS 上で動くメインフレーム。日本政府・金融機関の一部基幹が ACOS で運用される。
• 日本郵政、一部の地方銀行などが運用。
• 独自の COBOL や 4GL の ADL (ACOS Data Language) などを持つ。

Unisys ClearPath

• 米国 Unisys のメインフレーム系列。OS は二系統:
  • MCP (Master Control Program) — Burroughs B5000 (1961) の後継。ALGOL ベースの OS という、OS 歴史の化石。
  • OS 2200 — Sperry UNIVAC の後継。
• ClearPath Dorado (2200 系)、ClearPath Libra (MCP 系) などのブランド名で整理されてきた。
• 近年 Unisys はメインフレーム HW を x86 サーバ上でエミュレートする ClearPath Forward モデルへ移行。
• 米国の航空、政府、一部銀行で稼働。

まとめ — 非 IBM メインフレームの共通点

8章 · AWS Mainframe Modernization

2022 年に AWS は AWS Mainframe Modernization (AWS MMA) サービスをローンチした。メインフレーム・ワークロードを AWS に持ち上げるためのマネージドサービスだ。

二つのパターン

AWS MMA が公式に推す二つの移行戦略:

1. Replatform (再プラットフォーム) — COBOL はそのまま、メインフレームの実行環境だけを別の場所(AWS のコンテナ/EC2)に移す。AWS は Micro Focus(現 OpenText)ランタイムを使うオプションを提供。
2. Refactor (再ファクタリング) — COBOL を Java に自動変換。AWS は Blu Age を買収・統合した。Blu Age は COBOL をモダンな Java/Spring/Angular に変換するツール。

Replatform の方が多い

大規模な移行のほとんどは Replatform。理由:

• コードに触らない — ビジネスロジックのリスクがない。
• メインフレーム運用コスト削減 — IBM のライセンス/MIPS 費を AWS の計算費に置き換え。
• モダンなツール統合 — CI/CD、コンテナ、オブザーバビリティ。

ただし落とし穴もある。

• データ移行 — Db2 z/OS → Aurora/RDS PostgreSQL。簡単ではない。トリガ・ストアドプロシージャ・SQL 方言差が全部出てくる。
• トランザクションモニタの再現 — CICS の挙動を厳密に再現するのは難しい。
• MIPS 価格比較 — 「節約」が常に真実ではない。同等の可用性・性能を取りに行くと似た費用になることもある。

流れ

[メインフレーム]               [AWS]
   COBOL ソース ────────▶    COBOL ソース (または Java 変換)
   JCL バッチ   ────────▶    AWS Batch / EventBridge Scheduler
   CICS         ────────▶    Mainframe Modernization Runtime
   Db2 z/OS     ────────▶    Aurora PostgreSQL / Db2 LUW
   VSAM         ────────▶    DynamoDB / S3 / Aurora
   IMS          ────────▶    個別マッピング(最難関)

AWS は移行の評価・分析・カットオーバーまでをマネージドで提供する。それでもメインフレームのベテランと AWS ソリューションアーキテクトの組み合わせは必要だ。

9章 · Micro Focus → OpenText (2022) → Visual COBOL

メインフレーム現代化の中心に長くいたのが Micro Focus だ。英国本社の会社で、COBOL コンパイラ/ランタイムの最大級の供給元のひとつ。

2022 年 — OpenText が買収

2022 年、カナダの情報管理企業 OpenText が Micro Focus を約 60 億ドルで買収した。買収完了に伴い、Micro Focus ブランドは段階的に OpenText ブランドへ統合中だ。

Visual COBOL — 主力製品

Micro Focus(現 OpenText)の主力は Visual COBOL。それが行うこと:

• メインフレームで動く COBOL を Windows/Linux/.NET/JVM 上でも実行可能にする。
• Visual Studio / IntelliJ / Eclipse 連携 — 現代の IDE で COBOL を編集・デバッグ・リファクタ。
• CICS 模倣 — 同等のトランザクション環境を提供し、メインフレームの CICS アプリをそのまま移行できる。
• JCL 変換 — メインフレームの JCL を非メインフレーム環境で実行可能にする。

Enterprise Server / Enterprise Developer

OpenText のメインフレーム関連ラインは概ね:

• Enterprise Developer — 開発者向け IDE + コンパイラ。
• Enterprise Server — プロダクションランタイム(CICS 互換、IMS 互換環境など)。
• AppMaster Builder, Enterprise Test Server, Modernization Workbench など補助ツール。

AWS Mainframe Modernization の Replatform オプションの一部は、この OpenText スタック上で動く。

意味

OpenText は メインフレームを殺さない。彼らはメインフレームのコードを別の環境で動かし続けることをビジネスにしている。彼らのモデルは「COBOL は 2030 年代も生きている」という前提に立っている。

10章 · IBM watsonx Code Assistant for Z (2023.8) — AI による COBOL 現代化

2023 年 8 月、IBM は watsonx Code Assistant for Z を発表した。メインフレーム COBOL を Java へ変換することを助ける AI ツールだ。

何をするのか

• COBOL → Java 変換 — 自動/半自動。ビジネスロジックをモダンな Java へ移す。
• コード理解 (Code Explanation) — 1980 年代に書かれた COBOL を LLM が説明する。「このモジュールは何をするか」のような自然言語問い合わせ。
• テスト生成 — 既存 COBOL のテストケースを生成。
• 段階的変換 — 一度に全部ではなく、モジュール単位・サービス単位で。

動作モデル

watsonx Code Assistant for Z は LLM(IBM の granite コードモデルファミリーをベースに)+ メインフレーム特化のドメイン知識の組み合わせだ。ただの ChatGPT ではなく、COBOL/JCL/CICS のパターンを学習したモデル が裏側にいる。

限界と現実

IBM のマーケティングを額面通りに受け取ってはいけない。実際には:

• 自動変換された Java はレビューが必要 — LLM 生成コードは常にそうだ。
• ビジネスロジックの細部 — COBOL の十進演算(PIC 9V99)、EBCDIC、表示子(indicator)の意味 — これらが損失なく移るとは限らない。
• データ移行は別問題 — コードを移しただけでは終わらない。

ただし 出発点 としては価値がある。ゼロから始めるのではなく、AI が作った最初のパスを人間が磨く。

2024~2025 年の流れ

• IBM は watsonx Code Assistant ラインを一般化 — Code Assistant for Java、for Ansible なども提供。
• IBM Z 版はより大きなケースに適用 — ある保険会社が 800 万行の COBOL を段階評価。
• 競合: Amazon Q Developer(旧 CodeWhisperer)のメインフレーム対応、GitHub Copilot の COBOL 対応。

11章 · GitHub Copilot の COBOL 対応

GitHub Copilot は 2021 年に GA。当初は JavaScript・Python・TypeScript で有名だった。言語サポートは時間とともに拡大し、COBOL 補完にも対応 している。

実際の体験

COBOL で Copilot はどう助けてくれるか:

• PIC 句の補完 — 変数名を入力すると PIC 9(7)V99 のような PICTURE 句を推定。
• PARAGRAPH 名と流れの提案 — 次に来る PERFORM、MOVE、COMPUTE を推定。
• JCL 生成 — 自然言語コメントから JCL スニペット。
• Db2 embedded SQL — EXEC SQL ... END-EXEC ブロックの自動補完。

限界

• 80 カラム書式の取り扱い — 伝統的なカラムベースの COBOL は LLM が扱いづらい。Free-format の方がうまく動く。
• 社内コーディング規約 — Copilot は一般的なパターンを知る。社内命名規則・標準は知らない。
• テストデータの意味 — ビジネスデータの意味を知らない。

Copilot vs watsonx Code Assistant for Z

• Copilot — 汎用コーディング支援。COBOL をサポートするが特化はしていない。
• watsonx CA for Z — メインフレーム特化。コード変換・理解に最適化。

両者は競合というより 層が違う。日常コーディングは Copilot、大規模変換プロジェクトは watsonx。

12章 · zCX (z/OS コンテナ) + Linux on Z + LinuxONE

メインフレームをクラウド時代に引き寄せるもうひとつの流れが コンテナと Linux だ。

zCX (z/OS Container Extensions)

2019 年に導入された z/OS の機能。z/OS の中で Docker コンテナを実行 する。z/OS 内に Linux on Z 環境を組み込み仮想マシンとして立ち上げ、その中でコンテナを動かす。

なぜ重要か:

• メインフレームのデータ(Db2 z/OS、VSAM)に 低遅延 でアクセス可能。
• Kafka、Elastic、Grafana のようなモダン・スタックをメインフレームの隣に置ける。
• トランザクション基盤を触らずに モダンなインタフェース を被せられる。

Linux on Z

z ハードウェア上で直接 Linux を動かす モード。z/OS と同じ LPAR で分割でき、一台のメインフレームに複数環境を同居させる。

• 主なディストリビューション: RHEL on Z、SUSE on Z、Ubuntu on Z。
• メインフレームの信頼性を Linux ワークロードへ拡張。
• 単一システム内で数百〜数千の Linux VM/コンテナを運用する構成。

IBM LinuxONE

Linux 専用メインフレーム。ハードは IBM Z と同じ系列だが、z/OS は載らない。つまり「メインフレーム信頼性 + Linux 専用」。主な用途:

• 大規模決済処理(ブロックチェーン・ノードホスティング含む)。
• データ保護が重要な環境(IBM Cloud Hyper Protect と組み合わせ)。
• グリーンデータセンター(同一ワークロードで x86 より少ない電力)。

IBM Cloud Hyper Protect

IBM Cloud の Confidential Computing ライン。メインフレームのセキュリティ技術(Crypto Express、Secure Service Container)をクラウドサービスとして提供。鍵管理、信頼仮想サーバ、DB などをメインフレーム級セキュリティでホスト。

13章 · Hercules + GnuCOBOL — オープン・エミュレーション

自宅でメインフレームを触れるか? 触れる。

Hercules — System/370 / ESA/390 / z/Architecture エミュレータ

オープンソースで公開された メインフレーム・エミュレータ。一般 PC/Mac/Linux 上で z/Architecture を模倣する。ただし:

• 商用 z/OS にはライセンスが必要 — 個人が合法的に z/OS を動かすのは難しい。
• MVS 3.8j のような古い IBM OS はパブリックドメイン — 1970~80 年代のメインフレーム体験は可能。
• Linux on Z — 合法かつ無料。RHEL/SUSE/Ubuntu の s390x ビルドを Hercules 上で動かせる。

GnuCOBOL

オープンソースの COBOL コンパイラ。COBOL を C にトランスパイル し、その後通常の C コンパイラでビルドする。

# インストール(例: macOS の Homebrew)
brew install gnu-cobol

# コンパイル
cobc -x -o interest interest.cob

# 実行
./interest

• COBOL 85 / 2002 / 2014 の大きな部分をサポート。
• IBM OS 固有機能(CICS、Db2 z/OS など)はサポート外。
• 学習・教育・小規模運用に向く。

学習ルート

• COBOL を初めて学ぶなら: GnuCOBOL + VS Code(または Eclipse) から。
• メインフレーム体験が欲しいなら: Hercules + MVS 3.8j + IBM Z Trial または IBM Z 学習プログラム。
• IBM は学生/初心者向けに IBM Z Xplore、Master the Mainframe 等の無償学習プログラムを長く運営している(名称や内容は時期で変動 — IBM 公式ページで確認)。

14章 · 現代化パターン — Strangler Fig と Anti-Corruption Layer

レガシーを置き換えるパターンは、実はメインフレーム特有の話ではない。次の二つが最も有名かつ実用的だ。

Strangler Fig パターン (Martin Fowler)

名前の由来はオーストラリアのイチジク(strangler fig)— 他の木を巻きながら育ち、いずれ元の木を枯らして自分が取って代わる木。マーチン・ファウラーが 2004 年の記事でシステム刷新にこの比喩を使ったのが始まり。

戦略:

1. レガシーシステムの前に プロキシ/ファサード を置く。
2. 新しいリクエストの一部を 新システム に振る。
3. 段階的に、より多くのリクエストを新システムへ。
4. ある日、レガシーは 0% のトラフィックになる。そこで初めて撤去。

[クライアント] ──▶ [ファサード/プロキシ] ──▶ [レガシー メインフレーム]
                       │
                       └──────────────────▶ [新マイクロサービス]
                                            (徐々にルーティング増)

長所:

• ビッグバン移行のリスクなし — 一度に 100% 移さない。
• ロールバック可能 — 新システムが壊れたらルーティングを戻す。
• 段階的な学習 — トラフィックを増やしながら運用ノウハウを積む。

短所:

• 何年もかかる — 即答ではない。
• 二重運用コスト — 移行期間中は両方回す必要。
• データ同期 — 両方が同じデータを見る期間、同期コストがかかる。

Anti-corruption Layer (Eric Evans, DDD)

ドメイン駆動設計(DDD)のパターンのひとつ。レガシーと新システムの間に 翻訳レイヤ を挟む。

[新ドメインモデル]  ──▶  [Anti-corruption Layer]  ──▶  [レガシー モデル]
   (きれいなモデル)         (変換/マッピング/隔離)        (古いモデル)

目的:

• レガシーの妙な概念(60 年分のビジネス前提)を新システムに 染み出させない。
• 新システムは自分自身のきれいなモデルを持つ。
• 翻訳コストを一箇所に集める。

Strangler Fig と Anti-corruption Layer は セットで使う。Strangler はルーティング・パターン、Anti-corruption はその裏側のドメインモデル保護装置。

実戦 — どこから始めるか

1. 箱を描く — メインフレーム上のモジュールをドメイン単位でグループ化。
2. 変更頻度 + リスク で優先順位 — よく変わる/リスクの高い部分から分離。
3. 読み取りから分離 — 参照トラフィックを新 DB(リードレプリカ)に移すのが最も簡単。
4. 書き込みは慎重に — デュアルライト(レガシー + 新)を経て、最後に新システムのみへ。
5. モニタリングと観測 — 両システムの応答を比較(シャドー・トラフィック)。
6. ロールバック計画 — 常に。

15章 · 韓国金融機関 — KB / 新韓 / ウリィ / ハナ / 企業銀行 / 農協のメインフレーム

韓国金融機関のメインフレーム運用は一部公開・一部推定だ。2024~2025 年の公開情報と業界推定に基づく一般像:

(以下は公知の業界知識に基づく整理であり、各銀行の正確なシステム構成は非公開が多い。推定が含まれる。)

大きな絵

• 5 大市中銀行 + NH 農協 + IBK 企業銀行 — 多くは IBM Z(またはその前世代)を次世代基盤と併用して運用してきた。
• 次世代プロジェクト — 2000 年代後半から 2010 年代に大規模な次世代事業が複数回行われ、メインフレーム依存を減らす方向と維持する方向が共存。
• 2020 年代の流れ — クラウド移行検討、一部システムの段階的ダウンサイジング、AI 統合の取り組み。

銀行別の一般的流れ(公開報道・業界知識ベースの一般論)

(注: 上記は公知の業界知識に基づく整理で、各銀行の正確な構成は非公開が多い。推定が含まれる。)

韓国のメインフレーム人材市場

• 60~70 代のベテランが基幹運用を担うケースが多い。
• 新規流入は少ない — メインフレームを教える大学がほぼない。
• そのため 報酬が上がる — COBOL/RPG/JCL を理解し韓国語が通じる人は事実上値段を自分で決められる。
• IBM Korea の Master the Mainframe / Z Xplore 韓国プログラムが新規流入の入口となってきた。

韓国の非金融

• 公共・税務 — 一部システムでメインフレーム運用。
• 航空 — 大韓航空・アシアナなどの一部システム。
• 通信 — 一部基盤。
• 製造・流通 — IBM i 運用サイトが多数あるとされる。

16章 · 日本 — 三菱UFJ / SMBC / みずほ / NTT データ / Fujitsu BS2000

日本はメインフレームのもうひとつの拠点だ。そして韓国と異なり、日本自身のメインフレーム産業 がある(富士通、NEC、日立)。これが日本特有の事情を作る。

3 メガバンクの一般像

(公開資料・業界知識に基づく一般的な整理。正確なシステム構成は非公開が多い。)

NTT データ

日本 SI 市場の中核。公共・金融基幹システムの構築・運用パートナー。NTT データはメインフレーム移行・運用受託を大規模に行う。

富士通 — 自社メインフレームを持つ

• FUJITSU BS2000 — ドイツ発のメインフレーム。欧州 + 日本の一部で運用。
• 日本国内向けメインフレームのラインアップ(年代によって名称・構成は変動 — 最新は富士通公式資料参照)。
• 富士通は 2020 年代にメインフレーム事業の一部整理を発表 — 新規メインフレーム開発の停止、x86 ベースの GS / PRIMERGY ラインへの移行などが報じられた(正確な日程・範囲は富士通の公式発表ベース)。
• この流れは日本のメインフレーム市場に相当の影響を与える。

NEC ACOS

• 日本政府の一部、自治体、一部の銀行が運用。
• NEC もメインフレーム事業の段階的変換を進める。

日立

• かつての日本メインフレームの一角。現在はメインフレームそのものより システム統合・運用サービス が中心。

日本の人材市場

• 韓国と同様、ベテラン依存 + 新規流入不足。
• 日本は NTT データ・富士通・NEC・日立・日本 IBM のような大型 SI が人材を吸収する構造のため、人材プールが企業単位で循環する。

17章 · COBOL を学ぶべき人は誰か — 金融 / 保険 / 政府 / 学術

2026 年に新しい言語を学ぶとして、COBOL は第一候補ではないだろう。だが 特定の人にとっては第一候補になり得る。誰がなぜ。

良い候補

• 金融機関への就職を考えている人 — 銀行 IT、保険 IT はメインフレーム運用を知っている人を強く重んじる。代替が効かない。
• 公共・税務・福祉 IT — 韓国・日本・米国はいずれも政府系システムの一部に COBOL を抱える。
• 情報システム・コンサルティング — 移行プロジェクトは今後 10~20 年の市場。
• 学術的関心 — 60 年の言語がどう生き延びてきたかは、それ自体がコンピュータ科学のケーススタディ。
• 報酬を最大化したい人 — 単位時間あたり単価が非常に高いことがある(供給が少ないため)。

あまり向かない候補

• 2026 年に最初のプログラミング言語を選ぶ人 — Python/JavaScript/Go の方が良い。
• 起業家 — 新規プロダクトを COBOL で作る人はいない。
• AI/ML エンジニア — その領域は Python が握っている。

現実的な学習ルート

1. GnuCOBOL を入れる — ローカルで COBOL をコンパイル・実行。
2. COBOL の基礎 — IDENTIFICATION / ENVIRONMENT / DATA / PROCEDURE DIVISION。PIC 句。PERFORM。
3. ファイル処理 — 順次・索引・相対ファイル。
4. DB 連携 — Embedded SQL。
5. JCL — メインフレーム環境でジョブをどう回すか。
6. CICS の基礎 — トランザクション処理。
7. メインフレーム環境の体験 — IBM Z Xplore / Master the Mainframe(名称・運営形態は時期により変動 — IBM 公式ページ確認)。
8. 現代化ツール — Visual COBOL、watsonx Code Assistant for Z の体験/評価版。

時間投資

• 基礎 COBOL — 100~200 時間。
• 実戦的なメインフレーム運用(JCL/CICS/Db2 z/OS)— 1~2 年の現場経験。

言語そのものは難しくない。環境 が難しい。それが参入障壁であり、同時に機会だ。

エピローグ — 巨人はゆっくり、非常にゆっくり動く

メインフレームは死なない。少なくとも 2030 年代半ばまでは。

全体像

• ハードは進化 — Telum II がオンチップ AI を強化。z17 は z16 の自然な後継。
• ソフトは保存 — 200B 行の COBOL は消えない。動かされるだけだ。
• AI は加速器 — watsonx、Copilot、Amazon Q が現代化作業を人手だけの時代より速くする。
• クラウドは選択肢 — AWS MMA、IBM Cloud Hyper Protect、Linux on Z、LinuxONE。
• 運用はやはり人 — 良いメインフレーム運用者は会社を救う。

次回予告

候補:

• JCL 実戦 — 最初の一行から SYSPRINT まで
• COBOL → Java 変換ハンズオン — watsonx Code Assistant for Z のデモを追う
• Db2 z/OS と PostgreSQL の違い — 移行が難しい本当の理由

「古いコードはどこかで生きている。私たちはそれを殺すのではなく、隣にゆっくり育てた新しい木がいつか場所を引き継ぐようにする」— Strangler Fig という比喩そのものに従って。

— メインフレーム 2026、了。

参考 / References

• IBM Z 公式
• IBM z17 発表資料 (IBM Newsroom)
• IBM z16 — Telum プロセッサ
• IBM i 公式
• IBM Db2 for z/OS
• IBM CICS Transaction Server
• IBM IMS
• IBM Enterprise COBOL for z/OS
• IBM watsonx Code Assistant for Z
• IBM LinuxONE
• IBM Cloud Hyper Protect
• Linux on Z (IBM)
• AWS Mainframe Modernization
• OpenText (Micro Focus 買収)
• Visual COBOL — OpenText
• Fujitsu BS2000
• NEC ACOS
• Unisys ClearPath
• GitHub Copilot
• Hercules emulator
• GnuCOBOL
• Martin Fowler — StranglerFigApplication
• Eric Evans — Domain-Driven Design (Anti-corruption Layer)
• COBOL 規格 (ISO/IEC 1989)
• IBM Z Xplore / Master the Mainframe (学習プログラム)