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

「メインフレームは死んだ」という見出しは 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 年時点のメインフレーム・エコシステムの推定:

| 項目 | 推定規模 |

| --- | --- |

| 本番稼働中の COBOL 行数 | 200~220B 行 |

| IBM i 稼働サイト | 130,000+ 社(Forrester/IBM 推定) |

| IBM Z システム導入数 | 世界で約 10,000+ サイト |

| IBM Z の一日のビジネストランザクション処理量 | 約 300 億件 |

| Fortune 500 のメインフレーム利用率 | 約 70% |

| 世界トップ 50 行のメインフレーム利用率 | 約 92% |

| メインフレームを経由するクレジットカード取引比率 | 約 87% |

(出典: 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 比)

| 項目 | z16 (2022.4) | z17 (2025.9) |

| --- | --- | --- |

| プロセッサ | Telum I | Telum II |

| オンチップ AI | あり(1 世代目) | 強化(2 世代目) |

| Spyre アクセラレータ | オプション(後期導入) | オプション(拡張) |

| メモリ帯域 | - | 改善(詳細は IBM 資料参照) |

| セキュリティ | Crypto Express 8S、耐量子暗号対応 | 同流れ + 強化 |

| 可用性 | 99.999% 以上 | 同クラス |

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 メインフレームの共通点

| 項目 | 共通点 |

| --- | --- |

| シェア | IBM より小さいがゼロではない |

| 拠点 | 地域集中(日本・ドイツ・米国) |

| 移行圧力 | IBM Z より大きい。後継世代の保証が弱いため |

| 現代化経路 | 多くは IBM Z へ移行、または Linux/クラウドへ |

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 統合の取り組み。

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

| 銀行 | 一般的流れ(業界知識) |

| --- | --- |

| KB 国民 | メインフレーム + 自社の次世代システム。クラウド移行を積極検討。 |

| 新韓 | メインフレーム運用。AI 連携に積極的。 |

| ウリィ | 次世代システム事業進行中。 |

| ハナ | 自社次世代システム + 一部メインフレーム。 |

| IBK 企業 | メインフレーム運用。 |

| NH 農協 | IBM Z 運用。規模上、韓国国内最大級のメインフレーム利用者のひとつ。 |

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

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

- 60~70 代のベテランが基幹運用を担うケースが多い。

- 新規流入は少ない — メインフレームを教える大学がほぼない。

- そのため **報酬が上がる** — COBOL/RPG/JCL を理解し韓国語が通じる人は事実上値段を自分で決められる。

- IBM Korea の **Master the Mainframe** / **Z Xplore** 韓国プログラムが新規流入の入口となってきた。

韓国の非金融

- **公共・税務** — 一部システムでメインフレーム運用。

- **航空** — 大韓航空・アシアナなどの一部システム。

- **通信** — 一部基盤。

- **製造・流通** — IBM i 運用サイトが多数あるとされる。

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

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

3 メガバンクの一般像

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

| 銀行 | 一般的流れ(業界知識) |

| --- | --- |

| 三菱UFJ (MUFG) | メインフレーム運用。2010 年代の大規模統合後は安定運用。 |

| SMBC (三井住友) | メインフレーム + 自社次世代。 |

| みずほ | 2002・2011・2021 年のシステム障害で有名。以降は安定性確保に集中。 |

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 年代半ばまでは。

| 時期 | 出来事 |

| --- | --- |

| 2022.4 | IBM z16 発表(Telum I、耐量子暗号) |

| 2023.8 | IBM watsonx Code Assistant for Z 発表 |

| 2022 | OpenText が Micro Focus 買収(Visual COBOL の新オーナー) |

| 2022 | AWS Mainframe Modernization GA |

| 2025.9 | IBM z17 発表(Telum II) |

| 2026~ | AI 連携による現代化が本格的に広がる段階 |

全体像

- **ハードは進化** — 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 公式](https://www.ibm.com/z)

- [IBM z17 発表資料 (IBM Newsroom)](https://newsroom.ibm.com/)

- [IBM z16 — Telum プロセッサ](https://www.ibm.com/products/z16)

- [IBM i 公式](https://www.ibm.com/products/ibm-i)

- [IBM Db2 for z/OS](https://www.ibm.com/products/db2/zos)

- [IBM CICS Transaction Server](https://www.ibm.com/products/cics-transaction-server)

- [IBM IMS](https://www.ibm.com/products/ims)

- [IBM Enterprise COBOL for z/OS](https://www.ibm.com/products/enterprise-cobol-zos)

- [IBM watsonx Code Assistant for Z](https://www.ibm.com/products/watsonx-code-assistant-z)

- [IBM LinuxONE](https://www.ibm.com/linuxone)

- [IBM Cloud Hyper Protect](https://www.ibm.com/cloud/hyper-protect-services)

- [Linux on Z (IBM)](https://www.ibm.com/it-infrastructure/z/os/linux)

- [AWS Mainframe Modernization](https://aws.amazon.com/mainframe-modernization/)

- [OpenText (Micro Focus 買収)](https://www.opentext.com/)

- [Visual COBOL — OpenText](https://www.opentext.com/products/visual-cobol)

- [Fujitsu BS2000](https://www.fujitsu.com/global/products/computing/servers/mainframe/bs2000/)

- [NEC ACOS](https://jpn.nec.com/acos/)

- [Unisys ClearPath](https://www.unisys.com/solutions/clearpath-forward/)

- [GitHub Copilot](https://github.com/features/copilot)

- [Hercules emulator](https://www.hercules-390.org/)

- [GnuCOBOL](https://gnucobol.sourceforge.io/)

- [Martin Fowler — StranglerFigApplication](https://martinfowler.com/bliki/StranglerFigApplication.html)

- [Eric Evans — Domain-Driven Design (Anti-corruption Layer)](https://www.domainlanguage.com/ddd/)

- [COBOL 規格 (ISO/IEC 1989)](https://www.iso.org/standard/74527.html)

- [IBM Z Xplore / Master the Mainframe (学習プログラム)](https://www.ibm.com/community/z/)