はじめに
「メインフレームって何ですか？」──金融系案件にアサインされた直後、そう聞けずに詰まった経験はないだろうか。
COBOLもJCLも読んだことがない。VSAMと言われてもピンとこない。そんな状態で設計書を渡されると、そこに書かれている用語が別の言語に見える。
筆者はメインフレームのモダナイゼーション（レガシー移行）を専門としており、汎用機（COBOL／IMS／VSAM／CICS）とオープン系の構造差を軸に、レガシー資産の分析・移行支援を行っている。
この記事では、Webエンジニアがメインフレームの現場に入ったとき最初に知っておくべきことを、できるだけ平易にまとめる。
1. メインフレームとは何か──3行で
メインフレームは「でかいサーバー」ではない。
一言で言えば、信頼性・可用性・スループットを極限まで追求した専用コンピュータだ。汎用サーバーとは設計思想のレベルから違う。
代表機種はIBM Z（旧称IBM System z）。OSはz/OS。この上で動くソフトウェアスタックが以下になる。
| レイヤー | 主な技術 | 一言説明 |
|---|---|---|
| OS | z/OS | メインフレーム専用OS |
| バッチ制御 | JCL | ジョブ制御言語。処理の「指示書」 |
| トランザクション | CICS | オンライン処理のミドルウェア |
| データベース | IMS DB | 階層型データベース |
| ファイル | VSAM | キー順・索引順の専用ファイル構造 |
| 言語 | COBOL / HLASM | 業務ロジック記述言語 |
この6つが頭に入っていれば、金融系の設計書の「地図」は読めるようになる。
2. Webエンジニアが最初に混乱する3つのギャップ
ギャップ① ステートレスが当たり前、ではない
Webの世界ではステートレスアーキテクチャが基本だ。しかしCICS（Customer Information Control System）はトランザクション単位でセッション状態を管理する。
画面遷移ごとにコンテキストが引き継がれ、複数画面にまたがって一つの業務処理が完結する。「1リクエスト1レスポンスで完結する」という感覚は通用しない。
イメージとしては、超巨大なAPI Gateway兼Webサーバーが、セッション状態をすべて自前で管理しながらリクエストをルーティングしている、と考えると近い。
ギャップ② ファイルはディレクトリに入っていない
LinuxやWindowsではファイルはディレクトリ構造で管理される。しかしメインフレームのVSAMファイルは、**キー順（KSDS）・相対レコード順（RRDS）・エントリ順（ESDS）**という独自の構造を持つ。
「ファイルをコピーする」「ソートする」「マージする」といった操作は、JCLのユーティリティ（SORT、IDCAMS等）を経由して行う。cpコマンドは存在しない。
RDBしか知らないエンジニアからすると、「SQLを投げられない」という点が最も違和感を覚えるかもしれない。コードのイメージで比較すると以下のようになる。
// Webエンジニアの日常（RDB）：SQLという「条件」を投げてDB側に探してもらう
User user = userRepository.findById("U100");
// 内部では SELECT * FROM users WHERE id = 'U100' が走る
* メインフレーム（VSAM）：ファイルを開き、キーを指定して直接1レコードを掴みに行く
MOVE 'U100' TO USER-KEY.
READ USER-FILE INVALID KEY DISPLAY 'NOT FOUND'.
VSAMへのアクセスは、データベースへのクエリというよりも、めちゃくちゃ高速なKey-Valueストア（Redisの超巨大版）のファイルをバイナリ直接操作している感覚に近い。
ギャップ③ デプロイはパイプラインではない
GitHub ActionsやArgoでの自動デプロイに慣れていると衝撃を受けるかもしれない。メインフレームではJCLを書いてジョブを投入するのが基本的なデプロイ手順だ。
JCLとはJob Control Languageの略で、「どのプログラムを・どのファイルを使って・どの順番で動かすか」を記述する制御言語だ。見た目は以下のようになる。
//MYJOB JOB (ACCT),'MY BATCH JOB',CLASS=A
//STEP1 EXEC PGM=MYCOBOL
//INPUT DD DSN=MY.INPUT.FILE,DISP=SHR
//OUTPUT DD DSN=MY.OUTPUT.FILE,DISP=(NEW,CATLG)
//SYSOUT DD SYSOUT=*
初見では「何を書いているのか」がわかりにくいが、構造は単純だ。//で始まる行がJCLステートメントで、JOB・EXEC・DDの3種類が基本になる。
3. なぜ今も現役なのか──数字で語る
「なぜ古い技術を使い続けるのか」はよく聞かれる問いだ。答えは感情論ではなく、数字にある。
スループットの桁が違う
IBMのZ16は1日あたり最大3,000億件のトランザクションを処理できる設計になっている。ATMネットワーク、クレジットカード決済、銀行の勘定系──これらが「止まらず動き続ける」ために必要な処理能力だ。
可用性99.999%の意味
いわゆる「ファイブナイン」と呼ばれる可用性基準は、年間ダウンタイムが約5分以内であることを意味する。クラウドサービスのSLAと比較すると、その水準の高さがわかる。
| サービス | 年間停止時間（目安） |
|---|---|
| 一般的なクラウドSLA（99.9%） | 約8.7時間 |
| 高可用性クラウド（99.99%） | 約52分 |
| メインフレーム（99.999%） | 約5分 |
移行コストの現実
「クラウドに移せばいい」という議論は正しいが、移行コストは膨大だ。日本の大手銀行の勘定系システムは数千万〜数億行規模のCOBOL/アセンブラで動いており、完全移行には10年単位の期間と数百億円規模の投資が必要になることがある。「動いているものを止めない」という判断は、合理的なリスク管理でもある。
4. 金融系案件で出てくる用語サバイバルガイド
会議や設計書でよく出てくる用語を一言で整理する。
| 用語 | 読み方 | 一言説明 |
|---|---|---|
| COBOL | コボル | 1959年生まれの業務処理言語。今も現役 |
| HLASM | エイチラズム | 高水準アセンブラ。パフォーマンス最重視の処理に使う |
| JCL | ジェーシーエル | ジョブ制御言語。バッチ処理の「レシピ」 |
| CICS | シックス（またはキックス） | オンライントランザクション処理ミドルウェア |
| IMS | アイエムエス | 階層型DB。1968年生まれ。今も主要銀行で動いている |
| VSAM | ブイサム | 高速アクセス用ファイル構造。RDBではない |
| RACF | ラクフ | セキュリティ管理ツール。Linuxのsudoより細かく制御できる |
| SMF | エスエムエフ | システム管理ファシリティ。ログ・監査証跡の中心 |
| DASD | ダズド | Direct Access Storage Device。要はHDD/SSD |
これだけ頭に入っていれば、最初の設計レビューで完全に迷子にはならない。
5. モダナイゼーションとは何をしているのか
「メインフレームの移行」と聞くと、「古いシステムを捨てて新しく作り直す」と思われがちだが、実態は違う。
「廃止」ではなく「段階的移行」
現実的なアプローチはStrangler Figパターン（絞め殺しの木）と呼ばれる手法だ。古いシステムを一度に置き換えるのではなく、機能単位で少しずつ新システムに切り出していく。
[現行] [移行後]
COBOL/CICS ──────→ Java/Spring Boot
(全機能) (新機能A)
↕ API連携
COBOL/CICS
(残存機能)
新旧が並行稼働する期間を設けることで、リスクを最小化しながら移行を進める。
変換パイプラインのイメージ
技術的には、COBOL/HLASMのソースコードを静的解析し、中間表現（IR）を経由してKotlin/Javaへ変換するパイプラインを構築するアプローチが広まっている。
COBOL/HLASM ソース
↓ 構文解析
AST（構文木）
↓ 意味解析・CFG/SSA変換
IR（中間表現）
↓ コード生成
Kotlin / Java
単純な構文変換ではなく、制御フロー・データ依存関係・状態管理の再設計が必要になるため、「コンバーター」ではなく「移行エンジニアリング」と呼ぶべき作業だ。
おわりに
メインフレームは「過去の遺物」ではなく、今この瞬間もあなたの銀行口座の残高を正確に管理しているシステムだ。
金融系案件に入るエンジニアにとって、この領域の基礎知識は「知っていて損はない」ではなく「知らないと詰まる」ものになりつつある。
なお、本記事ではWebエンジニア向けに概要をマイルドに解説したが、**「富士通・日立・IBMのOS/TP/ファイル体系の決定的な非互換性」や、「なぜアセンブラ（特に自己書き換えコードやEX命令）の静的解析は原理的に困難なのか」**といった、モダナイゼーション現場のガチの地雷原に興味がある方は、noteにて詳細な連載記事を公開している。
興味のある方は、ぜひ合わせて覗いてみてほしい。