汎用機の世界で何が起きているのか

1. はじめに ― なぜ今「汎用機の世界」を語るのか

「汎用機（メインフレーム）」という言葉を聞いて、あなたはどんなイメージを持つだろうか。

「古くて時代遅れのコンピュータ」「もう使われていない過去の技術」――そう思う人がほとんどではないか。

しかし現実は真逆だ。あなたが今日、銀行で振り込みをした、保険料を払った、役所の手続きをした――その裏側では、今もメインフレームが静かに、しかし確実に動き続けている。

2025年から2035年にかけての「崩壊期」――汎用機の世界は今まさにその渦中にある。

理由は三つある。

一つ目は技術者の高齢化だ。現役の汎用機技術者の多くは50代・60代を超えており、定年退職とともにその知識が消えていく。若手が入ってこないため、世代交代が起きていない。

二つ目は移行プロジェクトの失敗の続出だ。「そろそろモダナイゼーションを」と始まった大規模なシステム移行が、技術・工数・コストのいずれかで壁に当たり、途中で頓挫するケースが後を絶たない。

三つ目は社会インフラとしての依存だ。失敗が許されない業務が今もなお汎用機上で稼働し続けており、「止める」という選択肢が現実的に取れない状況が続いている。

この記事では、汎用機の世界で今何が起きているのかを、技術的・構造的な視点から解き明かしていく。

2. 汎用機とは何か ― 一般の理解とのズレ

「古いコンピュータ」ではなく「社会インフラ」

汎用機を「古いコンピュータ」と捉えている人は、根本的な認識を改める必要がある。汎用機は「古いもの」ではなく、社会を支えるインフラだ。

具体的にどこで使われているのか。

• メガバンク・地方銀行：勘定系システム（振り込み・入出金・残高管理）

• 生命保険・損害保険：契約管理・保険料計算・給付処理

• 公共機関：年金・税務・社会保障の基幹処理

• 大企業の基幹系：在庫管理・受発注・人事給与

これらは「止まったら社会が止まる」システムだ。

1%の台数で50%の基幹処理を支える

世界中のサーバ台数から見れば、汎用機はわずか1%にも満たない。しかし日本の基幹業務処理の約50%は今もメインフレームで処理されていると言われている。

1台のメインフレームは、何千・何万のトランザクションを同時に、1秒以内に、エラーなく処理し続ける。この処理密度と信頼性は、オープン系サーバのクラスタ構成では簡単には再現できない。

なぜ"見えない存在"になっているのか

汎用機が見えない理由はシンプルだ。

壊れないからだ。

24時間365日、何年も何十年も無停止で動き続ける。障害が起きない。表に出てこない。だから人々の意識からも消える。しかし消えているのは「認識」であって、「存在」ではない。

3. 汎用機の内部構造 ― 一般エンジニアが知らない世界

汎用機の内部は、一般のエンジニアが普段触れるLinuxやWindowsの世界とは、根本的に異なる。以下にその主要な構成要素を示す。

COBOL（Common Business Oriented Language）

1959年に設計されたプログラミング言語。英語に近い文法で業務ロジックを記述する。「古い言語」と揶揄されることも多いが、日本の金融・保険・公共システムにおける現役のコードベースはCOBOLで記述されたものが圧倒的に多い。

問題は、そのコードの多くが40年以上改修を繰り返した結果、誰も全体を把握できない巨大な暗黙仕様の塊になっていることだ。

JCL（Job Control Language）

バッチジョブを制御するための言語。「どのプログラムを、どの順番で、どのデータを使って動かすか」を記述する。一見シンプルに見えるが、JCLの記述に含まれる暗黙のパラメータや実行順序の依存関係は、長年の業務要件が凝縮されており、その意味を正確に読み解ける技術者は今や希少だ。

CICS（Customer Information Control System）

オンライントランザクション処理のミドルウェア。銀行の窓口端末から送られてくるトランザクションを受け付け、処理し、応答を返す役割を担う。

CICSには「疑似会話（Pseudo-Conversational）」という独特の設計パターンがある。これはWebアプリケーションのセッション管理とは全く異なる概念であり、RESTやマイクロサービスへの単純な置き換えが困難な理由の一つになっている。

IMS（Information Management System）

IBMが開発した階層型データベース。RDB（リレーショナルデータベース）が普及する以前から使われており、「親子」「孫」という木構造でデータを管理する。RDBのテーブル設計とは根本的に異なるため、IMSのデータ構造をそのままRDBに移すことは非常に難しい。

VSAM（Virtual Storage Access Method）

汎用機上のファイル管理システム。KSDS（キー順）・ESDS（エントリ順）・RRDS（相対レコード）という複数のアクセス方式があり、それぞれのレコード順序性と主キー構造はRDBのB-treeインデックスとは異なる意味を持つ。

スプール

バッチ処理の出力（帳票・ログ）を一時的に蓄積する仕組み。オープン系のファイル出力とは異なり、スプールには独自の管理体系があり、リトライや再実行の制御もスプールを介して行われる。

TSO/ISPF

汎用機上の操作インターフェース。Linuxでいうターミナル＋ファイルマネージャのようなものだが、全く独自のUI体系を持つ。これを使いこなすだけでも相当な習熟が必要だ。

40年の暗黙仕様

上記の技術要素よりも深刻なのが「暗黙仕様」の問題だ。

何十年もかけて少しずつ改修されてきたCOBOLプログラムには、仕様書に書かれていない業務ルールが無数に埋め込まれている。「この条件のときはこの処理をスキップする」「このフラグが立っているときは別のジョブを呼ぶ」――そうした知識はコードの中にだけ存在し、書いた本人はもうこの世にいないことも珍しくない。

4. なぜ汎用機技術者が絶滅したのか

若手が入らない・教えられる人がいない

汎用機の世界に若い技術者が来ない理由は、ある意味わかりやすい。

「キャリアとして魅力がない」と見られているからだ。

求人票に「COBOL」「JCL」と書いてあっても、そのスキルが転職市場でどれだけ評価されるかが不透明に見える。結果として、若い世代は最初からオープン系・クラウド・AIの方向に流れる。

教えられる人がいなければ、入ってきた若手も育てられない。悪循環だ。

仕様書がない・企業が育成を放棄

多くの企業で、汎用機システムの正確な仕様書が存在しない。あったとしても、30年前に作られたまま更新されておらず、現状のコードとは乖離している。

育成を「コストとリスク」と判断した企業が、汎用機担当を縮小・外部委託へと移行させてきた。しかし委託先も同様に技術者不足であり、問題が先送りされているだけだ。

「古い＝価値がない」という誤解

社会全体に「新しい技術こそ価値がある」という意識が根強い。COBOLやJCLを「古い技術」として切り捨てる風潮は、エンジニアコミュニティにも企業経営にも染み込んでいる。

しかし実際には、汎用機の構造を正確に理解できる技術者は今や最も希少で、最も市場価値が高い存在だ。希少性の経済学そのものだ。

5. 移行プロジェクトで何が起きているのか

オープン系だけで移行しようとする

「いつまでもメインフレームに依存していられない」――経営の意思決定でモダナイゼーションプロジェクトが立ち上がる。しかし多くの場合、プロジェクトメンバーはオープン系（Java、.NET、クラウド）の技術者が中心で、汎用機の構造を深く知る人間がいない。

これが失敗の最大の原因だ。

IMS/VSAM → RDB が失敗する理由

「IMSのデータをRDBに移行すればいい」という発想は、表面的には正しく見える。しかし実際には大きな罠がある。

IMSの階層構造は、データ間の「親子関係の順序」に業務的な意味を持たせていることが多い。これをフラットなRDBテーブルに変換した瞬間、その順序性が失われる。結果として「移行後のデータは正しいはずなのに、業務処理の結果がおかしい」という事態が発生する。

VSAMのKSDSも同様だ。レコードの物理的な並び順が業務処理に影響しているケースでは、単純なRDBへの移行でその順序保証が崩れる。

CICSの疑似会話をRESTに置き換えられない

CICSの疑似会話は、1トランザクションを複数回の画面送受信に分割しながら、ステートレスに処理を継続する設計だ。これはHTTPのステートレス性に似ているようで、実は全く異なる業務的な「文脈の引き継ぎ方」をしている。

RESTに単純に置き換えようとすると、セッション管理・ロールバック処理・エラー時の状態復元などで予期せぬ不整合が発生する。

JCLを理解しないままバッチを移行

JCLで記述されたバッチジョブには、「このジョブが失敗したら次のジョブはスキップ」「このDDNAMEは前のジョブの出力を引き継ぐ」といった依存関係が複雑に絡み合っている。

これを読み解かずに「ジョブの処理内容だけ」をPythonやシェルスクリプトに移植しようとすると、依存関係の再現に失敗し、バッチが途中で止まったり、データが二重処理されたりする。

暗黙仕様が消えて業務が破綻

最も深刻な失敗パターンがこれだ。

移行前はCOBOLコードの中に「暗黙の業務ルール」として生き続けていたロジックが、移行後のコードには存在しない。テストで発見できない微妙な業務条件での誤動作が、本番稼働後に顕在化する。

6. なぜ移行は失敗するのか ― 構造的原因

技術の問題ではなく「構造の問題」

移行の失敗は、ツールや言語の問題ではない。人・組織・認識の構造的な問題だ。

汎用機を知る人がいない：プロジェクトに汎用機の深い知識を持つ人間がいない。または「わかる人」が1人いても、その人の発言が軽視される。

オープン系技術者が中心：モダナイゼーションはオープン系の仕事と見なされ、汎用機側の知識がプロジェクト設計に反映されない。

経営層が汎用機を軽視：「古い技術の話はわからないが、早く移行してほしい」という経営判断が、技術的な現実を無視したスケジュール設定につながる。

ベンダーが「できます」と言ってしまう：受注のために「できます」と言ったベンダーが、実際に着手してから深刻な問題に気づく。しかし後戻りできない。

仕様がブラックボックス：誰も全体を把握していないコードベースを、不完全な仕様書だけを手がかりに移行しようとする無謀さ。

データ構造が特殊：EBCDICエンコーディング、COMP-3（パック10進数）の符号特性、REDEFINESによる同一メモリ領域の多重解釈、そしてバイト数で厳密に制御された固定長・可変長（VB形式）レコード。オープン系のようなカンマや改行によるデリミタ区切りではなく、バイト数でデータを区切る構造は根本的に異なる。さらにゾーン10進数やパック10進数における符号ビットの保持形式は、JavaやPythonの数値型への単純マッピングを阻む。これらは一般のエンジニアが「知らなくて当然」の領域だが、知らないと致命的なデータ変換ミスや桁落ちが起きる。

7. 正しい移行とは何か

RDBへの単純移行ではなく、構造に合ったデータストアへ

「移行＝RDB化」という固定観念を捨てることが出発点だ。

IMSのように階層構造を持つデータは、階層型DB・KVS（キーバリューストア）・GraphDBへの移行の方が、構造的整合性を保ちやすい場合がある。「モダンなデータベース＝RDB」という思い込みが、移行を難しくしている一因だ。

IMSの階層構造をどう扱うか

IMSのセグメント構造をそのままDocumentDB（MongoDBなど）に写像する手法は、一定の有効性がある。ただし、業務処理がその階層の「順序」に依存しているケースでは、アプリケーション層での順序制御が必要になる。この設計判断には、IMSの構造を理解した上でのアーキテクチャ選択が不可欠だ。

VSAMの順序性をどう再現するか

VSAMのKDSS（キー順データセット）が持つ「物理的な挿入順の保証」は、RDBでは通常の手段では再現できない。シーケンス番号カラムの追加や、アプリケーション層での挿入順管理が必要になる。この問題を移行設計の段階で認識しているかどうかで、プロジェクトの命運が分かれる。

CICSの疑似会話をどう設計するか

疑似会話の「状態をサーバ側に持たず、クライアントとの往復で業務を完結させる」という設計思想は、実はモダンなRESTfulアーキテクチャと相性が悪くない。ただし、CICSの疑似会話が暗黙に保持していた「業務フローの状態」をどこで管理するかの設計が必須だ。セッション管理・エラーリカバリ・タイムアウト制御を明示的に設計しなければ、業務上の整合性が崩れる。

IR/CFG/SSAによる構造解析の重要性

COBOLプログラムの移行において、「コードを読んで理解する」だけでは限界がある。

コンパイラ理論で使われる IR（中間表現）・CFG（制御フローグラフ）・SSA（静的単一代入）を活用した構造解析を行うことで、暗黙仕様の可視化・依存関係の抽出・移行対象の特定が格段に精度を増す。

具体的には、COBOLコードをIRに変換してCFGを生成し、データフローをSSA形式で表現することで、「このデータがどこで書き換えられ、どのパスで何の業務判定に使われるか」を機械的に追跡できる。こうした静的解析ツールや自動コードアナライザーの導入が、属人的なコードリーディングの限界を超える鍵になる。さらに近年では、このような構造解析の結果をLLMと組み合わせるアプローチも現実的になりつつある。CFGやデータフロー情報を文脈としてLLMに与えることで、暗黙仕様の自然言語化・移行コードの生成精度向上が期待できる。

「読める人が読む」という属人的なアプローチから、「構造的に解析して理解する」というエンジニアリングアプローチへの転換が、正しいモダナイゼーションの鍵だ。

8. 汎用機の未来 ― 2030〜2035年の世界

技術者の完全枯渇

2030年代に入ると、現役の汎用機技術者の多くが定年を迎える。後継者の育成は追いついておらず、「汎用機を知っている人間がいなくなる」という事態が現実になる。

移行失敗の増加

技術者不足が深刻化するほど、移行プロジェクトはさらに困難になる。「わかる人がいないまま移行しなければならない」状況が増え、失敗率はさらに上昇するだろう。

AIによる変換の限界

「AIがCOBOLコードを自動変換してくれる」という期待を持つ人もいる。確かにAIによるコード変換は一部有効だ。しかしAIが苦手とするのはまさに「暗黙仕様」だ。コードに書かれていない業務ルール、仕様書と現実のコードのズレ、データ構造の業務的な意味――これらを正確に解釈してAIが自動変換することは、現状では不可能に近い。

「読める人」の価値が爆上がりする

希少性は価値を生む。汎用機を深く理解できる技術者の絶対数が減る中で、その人材の価値は爆発的に上昇する。これはすでに始まっている現象だ。

汎用機は消えないが、扱える人がいなくなる

最終的なシナリオはこうだ。汎用機は社会インフラとして存在し続ける。しかしそれを正確に理解し、保守・移行できる人間がいなくなる。

これは単なる技術問題ではなく、社会リスクだ。

9. これから必要とされる人材

「汎用機 × オープン系」を橋渡しできる人

今後最も希少かつ価値のある技術者像は、汎用機の内部構造を理解しつつ、オープン系の現代的な設計・開発もできる「橋渡し人材」だ。

具体的に言えば：

• COBOL・JCL・IMS・VSAMの構造理解：コードを読めるだけでなく、業務的な意味を解釈できること

• IR/CFG/SSAを使った構造解析：コンパイラ理論に基づく静的解析で暗黙仕様を可視化できること

• モダナイゼーションの設計：適切なデータストアの選択・API設計・移行戦略の立案ができること

• 業務ドメイン知識：金融・保険・公共など、汎用機が使われている業界の業務フローを理解していること

「構造を理解できる人」が時代を救う

移行の成否を分けるのは、最新技術の知識ではない。汎用機の構造を正確に理解し、それをモダンなアーキテクチャにどう写像するかを設計できる知性だ。

COBOLやJCLを「レガシーの残骸」と見るか、「40年の業務知識が凝縮された資産」と見るか。この視点の差が、移行プロジェクトの成否を決める。

10. おわりに ― 汎用機の真実を伝えたい

汎用機の世界は、見えない。壊れないから、報道されない。動き続けるから、問題として浮かび上がらない。

しかし今、その世界は静かに崩壊の危機に近づいている。

技術者が消える。仕様が消える。そして、誰も正確にわからないシステムが社会インフラとして動き続ける。

この記事を書いた目的はひとつだ。

汎用機の真実を、正しく伝えること。

「古い技術」でも「消えていく存在」でもない。今もこの瞬間、あなたの生活を支えているインフラが、深刻な危機に直面していることを、より多くの人に知ってほしい。

そして、汎用機の構造を理解しようとする若い技術者が一人でも増えてほしい。

汎用機は今日も動いている。誰かが守らなければならない。

免責・制作情報

本記事は Copilot・Gemini・Claude など複数の AI ツールの協力を得て作成したものです。文章構成や表現の一部に AI の生成結果を含みますが、著作権上問題のない形で編集・再構成しています。記載された内容は筆者個人の見解を含まず、AI による情報整理・要約が中心です。