この記事は「COBOLが古いから移行する」という判断でモダナイゼーションを推進しているすべてのプロジェクトに向けた警告です。

TL;DR

COBOLは問題ではない。言語を Java に変えても失敗する
失敗の本質は CICS の疑似会話モデルを壊すこと と VSAM を RDB に変換すること の2点
この2つを壊した瞬間、どんな言語で書き直してもシステムは成立しなくなる
構造を維持したまま移行できるのは z/OS継続・OpenFrame・MFES の3択のみ

はじめに ── なぜ「COBOLが悪い」という誤診断が広まったか

メインフレームのモダナイゼーションを推進する現場で、必ずと言っていいほど登場する言葉がある。

「COBOLは古い言語だから、Javaに移行しましょう」

しかし、実際に大規模移行プロジェクトを経験したアーキテクトの共通認識は真逆だ。

COBOLは問題ではない。
問題は CICS の疑似会話モデルを壊すことと、VSAM を RDB に変換することだ。

では、なぜ「COBOLが悪い」という誤解が組織の中で通説になるのか。

誤解の発生源	メカニズム
若手エンジニア	COBOL を知らないため「難しい＝問題のある言語」と誤認
ベンダーのマーケティング	Java 化・クラウド化を売るため COBOL を悪者にする
経営層	「古い言語＝技術的負債」という根拠なき信念
メディア	「レガシー COBOL」という言葉が否定的ニュアンスで使われ続ける

これらはすべて 技術的根拠を欠いた評価 であり、実際の失敗原因とは無関係だ。

第1章：COBOLは「基幹系に最適化された言語」である

COBOL（1959年設計）が今も基幹系で動き続けているのは「惰性」ではない。以下の特性が基幹処理の要件と完全に合致しているからだ。

COBOLの特性	基幹系での意義
固定長データ構造	バッファ管理が予測可能・高速
COPYBOOK	データ定義を一元管理し整合性を保証
COMP-3（Packed Decimal）	金融計算で丸め誤差ゼロ・ストレージ効率最大
1画面＝1トランザクション	CICS の疑似会話モデルと完全対応
バッチ処理の順序性	JCL ステップで処理順序を厳密に保証

COMP-3 が金融系で不可欠な理由

01 WS-BALANCE    PIC S9(13)V99 COMP-3.

COMP-3（Packed Decimal）は2桁の数字を1バイトに格納し、符号を末尾4ビットで表現する。IEEE 754 浮動小数点と違い、10進数を10進数のまま扱うため、金融計算で丸め誤差が発生しない。

¥1,234,567.89 の COMP-3 表現:
01 23 45 67 8C（C = 正の符号）
7バイトで表現（display形式なら11バイト必要）

Java の BigDecimal で同等の精度を確保できるが、数百万レコードを処理するバッチでのスループットは COMP-3 ネイティブに劣る。

第2章：CICS の疑似会話モデルとその強み

CICS とは何か

CICS（Customer Information Control System）は IBM が1969年に開発した OLTP ミドルウェア だ。その設計の核心が 疑似会話（Pseudo-Conversational）モデル にある。

疑似会話の動作フロー

[ユーザー操作1]
        ↓
   EXEC CICS SEND MAP('MENU01')
        ↓
CICS がトランザクションを終了 ← ★ここでサーバリソースを解放★
        ↓
  ユーザーが画面を見て入力...（数秒〜数分）
        ↓
   EXEC CICS RECEIVE MAP('MENU01')
        ↓
   COMMAREA から前回の状態を復元
        ↓
   処理実行 → 次の SEND MAP

ポイント：ユーザーが考えている間、サーバは何もしていない。

これにより、1台のメインフレームが 数万のオンライン端末 を同時にサポートできる。

CICS の主要コンポーネント

* 疑似会話の状態引き継ぎ（COMMAREA）
01 DFHCOMMAREA.
   05 CA-TRANID       PIC X(4).
   05 CA-USER-ID      PIC X(8).
   05 CA-SCREEN-DATA  PIC X(1000).

* 状態の確認と初期化
IF EIBCALEN = 0
    MOVE 'INIT' TO CA-TRANID
    PERFORM INIT-SCREEN
ELSE
    MOVE DFHCOMMAREA TO WS-COMMAREA
    PERFORM PROCESS-INPUT
END-IF.

第3章：CICS → GUI 化でなぜ壊滅するか

① 状態管理の崩壊

比較項目	CICS（疑似会話）	モダン GUI（REST API）
状態の保持場所	サーバ側（COMMAREA/TSQ）	クライアント側（Cookie/JWT）
状態の消失リスク	低（CICS 管理）	高（ブラウザ障害・タイムアウト）
整合性保証	CICS が保証	アプリが保証（実装依存）

Replay 社の調査によれば、移行バグの約40%が「状態の紛失（Dropped State）」によるものだ。

② トランザクション境界の消失

CICS の SYNCPOINT は VSAM・DB2・TSQ をまたぐ処理を 1件の原子的トランザクション として扱う。

* CICS での原子的処理
EXEC CICS READ
    DATASET('MASTFILE')
    INTO(WS-MASTER)
    RIDFLD(WS-KEY)
    UPDATE
END-EXEC.

MOVE WS-NEW-BALANCE TO MS-BALANCE.

EXEC CICS REWRITE
    DATASET('MASTFILE')
    FROM(WS-MASTER)
END-EXEC.

EXEC CICS SYNCPOINT  ← ★これで全部まとめてコミット★
END-EXEC.

GUI/REST に変換すると：

POST /api/read-master     ← API コール1
POST /api/update-master   ← API コール2（失敗したら？）
???                       ← 補償処理（Compensating Transaction）が必要

分散トランザクション（Saga パターン）の補償処理を正しく実装しないと、二重更新・ロストアップデート・部分コミット が本番環境で発生する。しかもこれらのバグは、通常の結合テストでは再現しない。

③ API の爆発的増加

CICS の1画面（1トランザクション）には複数の業務操作が暗黙的に内包されている。これを REST API 化すると、1画面が 数十〜数百本のエンドポイント に分解される。

この設計・実装・テストコストは当初見積もりの 3〜5倍 に膨らむことが多い。

④ スループットの壊滅

指標	CICS（疑似会話）	モダン GUI（REST）
サーバリソース占有時間	ミリ秒単位（処理時のみ）	セッション全体
ネットワーク往復回数	1往復/画面	複数往復/画面
同時接続数（同一ハード）	数万	大幅に低下

第4章：VSAM → RDB 化でなぜ性能が壊滅するか

VSAM とは何か

VSAM（Virtual Storage Access Method）は IBM が1970年代に開発した 高速アクセスメソッド だ。RDB ではなく、B+Tree をベースにした 階層型高速データストア である。

VSAM KSDS の典型的アクセスパターン

* マスタファイルの範囲スキャン
EXEC CICS STARTBR
    DATASET('MASTFILE')
    RIDFLD(WS-START-KEY)
END-EXEC.

PERFORM UNTIL END-OF-FILE
    EXEC CICS READNEXT
        DATASET('MASTFILE')
        INTO(WS-RECORD)
        RIDFLD(WS-KEY)
    END-EXEC

    IF EIBRESP = DFHRESP(ENDFILE)
        SET END-OF-FILE TO TRUE
    ELSE
        PERFORM PROCESS-RECORD
    END-IF
END-PERFORM.

EXEC CICS ENDBR
    DATASET('MASTFILE')
END-EXEC.

このコードの性能上の意味：

STARTBR：B+Tree のリーフノードに 直接ジャンプ
READNEXT：ポインタを次のリーフに進めるだけ（O(1) の操作）
ネットワーク往復なし・クエリオプティマイザなし・ロック機構が軽量

RDB に変換すると何が起きるか

-- STARTBR + READNEXT に相当するSQL（単一テーブルの場合）
DECLARE cur CURSOR FOR
  SELECT * FROM MASTFILE
  WHERE KEY >= :start_key
  ORDER BY KEY;

OPEN cur;
FETCH cur INTO :record; -- READNEXT 相当

単一テーブルなら比較的問題ないが、正規化によって複数テーブルに分割した場合：

-- 複数テーブルに分割した場合の READNEXT 相当
SELECT m.*, a.*, d.*
FROM MASTER m
JOIN ACCOUNT a ON m.MASTER_ID = a.MASTER_ID
JOIN DETAIL d  ON a.ACCOUNT_ID = d.ACCOUNT_ID
WHERE m.KEY >= :start_key
ORDER BY m.KEY, a.ACCOUNT_ID, d.SEQ_NO;

3テーブル JOIN が発生
オプティマイザが最適計画を選ばない場合、性能が桁違いに低下
複数カーソルのマージが必要になるケースでは さらに深刻（IN-COM DATA SYSTEMS）

バッチウィンドウの超過

典型的な失敗パターン：

メインフレームで 2時間 で完了するバッチ処理
        ↓ RDB 移行後
8〜12時間 かかるようになる
        ↓
深夜バッチウィンドウを超過
        ↓
翌日の業務開始に間に合わない → 障害

REDEFINES による条件型データの消失

VSAM のレコードは REDEFINES 句で同一領域を複数の型として解釈することがある。

01 MASTER-RECORD.
   05 REC-TYPE         PIC X(1).
      88 IS-CUSTOMER   VALUE 'C'.
      88 IS-ACCOUNT    VALUE 'A'.
   05 REC-DATA.
      10 CUSTOMER-DATA.
         15 CUST-NAME  PIC X(30).
         15 CUST-ADDR  PIC X(50).
      10 ACCOUNT-DATA REDEFINES CUSTOMER-DATA.
         15 ACCT-NUM   PIC 9(10).
         15 ACCT-BAL   PIC S9(13)V99 COMP-3.

この構造を RDB の正規化テーブルに変換すると、「REC-TYPE で分岐してどちらの型として読むか」という業務ロジックが消滅する。これは設計書にも書かれていない暗黙仕様であることが多く、移行後しばらくして発覚するパターンが典型的だ。

第5章：IMS DB → RDB が世界的に失敗する理由

IMS DB の階層構造

顧客（ルートセグメント）
├── 口座（子セグメント）
│   ├── 取引明細（孫セグメント）
│   └── 担保情報（孫セグメント）
└── 住所履歴（子セグメント）

IMS のナビゲーション操作

* IMS DB のアクセス（DL/I コール）
CALL 'CBLTDLI' USING DLI-GU      * Get Unique（ルートセグメント取得）
                      PCB-MASK
                      WS-CUSTOMER-SEG
                      SSA-CUSTOMER.

CALL 'CBLTDLI' USING DLI-GNP     * Get Next within Parent（子セグメント順次）
                      PCB-MASK
                      WS-ACCOUNT-SEG
                      SSA-ACCOUNT.

GU・GN・GNP はすべて ポインタ移動で実現される。SQL なし、JOIN なし。

RDB に変換すると

-- GU + GNP に相当するSQL
SELECT c.*, a.*, d.*
FROM CUSTOMER c
JOIN ACCOUNT  a ON c.CUST_ID  = a.CUST_ID
JOIN DETAIL   d ON a.ACCT_ID  = d.ACCT_ID
WHERE c.CUST_ID = :cust_id
ORDER BY c.CUST_ID, a.ACCT_ID, d.SEQ_NO;

階層の深さが増すほど JOIN が増加
世界的に見て、IMS DB → RDB の完全移行で性能を維持できたケースは極めて少ない

第6章：自動変換ツール・AI の本質的限界

2024〜2026年にかけて AI を活用した COBOL → Java 自動変換ツールが多数登場した。しかし解けない問題がある。

変換の種類	自動化の可否	理由
COBOL 構文 → Java 構文	可能	1対1の変換ルールが定義できる
CICS トランザクション境界の再現	困難	アーキテクチャの再設計が必要
VSAM READ NEXT の性能再現	困難	アクセスパターンの設計が必要
COMP-3 精度の保持	可能だが見落としやすい	変換ルールはあるが実装ミスが多い
暗黙仕様・業務ロジックの再現	不可能	AI はコードの「意味」を理解できない

「コンパイルが通り、単体テストもパスするが、本番で誤った結果を返す」
── これが Java 化 Rewrite の典型的な失敗パターンだ（Medium: COBOL Migration that Compiled Perfectly）

「構文は変換できても、アーキテクチャとセマンティクスは変換できない」

これが自動変換・AI 変換の本質的限界だ。

第7章：では何が成功するのか ── 3択の構造

構造を壊さない移行戦略のみが、性能・整合性を維持できる。

選択肢1：z/OS 継続

IBM z/OS をそのまま使い続ける。COBOL・CICS・VSAM はそのまま、ハードウェアのみ更新。

性能：最高（変化なし）
コスト：ライセンス・ハードウェアコストが高止まり
適合：超大規模金融・保険で移行リスクを取れない企業

z/OS はむしろ進化しており、LinuxOne（z/OS 上の Linux）・ハイブリッドクラウド API など、コアを変えずにオープン化する戦略が増えている。

選択肢2：OpenFrame（TmaxSoft）

CICS を OFCICS でエミュレート、VSAM を OFTSAM でエミュレート。COBOL ソースはほぼ無変更のまま Linux/クラウドに移行する。

エミュレーションレイヤー	対象
`OFCICS`	CICS API 完全エミュレーション
`OFTSAM`	VSAM（KSDS/ESDS/RRDS）完全エミュレーション
`OFHiDB`	IMS DB 完全エミュレーション
`TJES`	JES（ジョブエントリサブシステム）エミュレーション

これらは COBOL ソースの EXEC CICS コールをそのまま解釈するため、疑似会話モデルが保持される。

コスト削減：BMO Harris 銀行事例で年間コスト 66% 削減
パフォーマンス：最大 100,000 MIPS 対応
日本動向：2024年、日本ティーマックスソフトが CEC と代理店契約を締結し国内展開を加速

選択肢3：Micro Focus Enterprise Server（MFES）/ Broadcom

COBOL 実行環境ごと Linux/クラウドに移植する。

CICS API の大部分をサポート（Exec CICS 構文をそのまま実行）
VSAM ファイルをネイティブ形式でエミュレーション
AWS・Azure との統合実績あり
PAC（Performance and Availability Cluster）で HA を実現

3択の比較

比較軸	z/OS 継続	OpenFrame	MFES
CICS エミュレーション	ネイティブ	高精度	高精度
VSAM エミュレーション	ネイティブ	高精度	高精度
IMS エミュレーション	ネイティブ	高精度（OFHiDB）	限定的
コスト削減効果	なし	大（60〜70%）	中（40〜60%）
COBOL ソース変更	不要	ほぼ不要	ほぼ不要
クラウド移行	限定的	AWS/Azure 対応	AWS/Azure 対応
ベンダー依存	IBM	TmaxSoft	Broadcom

第8章：Java化・クラウドネイティブ化（Rewrite）が構造的に成立しない理由

Rewrite では以下が失われる：

CICS 疑似会話モデル
  → Java のセッション管理に置き換え
  → 状態紛失バグ（移行バグの40%）、性能低下

VSAM KSDS アクセスパターン
  → JPA/Hibernate のエンティティに置き換え
  → READ NEXT が JPA クエリになり性能激減

SYNCPOINT（2PC）
  → Spring @Transactional に置き換え
  → 分散環境では 2PC が成立せず整合性崩壊

COMMAREA
  → HTTP セッション/JWT に置き換え
  → ステートレス設計との衝突

さらに：

67% のメインフレーム移行プロジェクトが失敗（Modernization Intel 調査）
Rewrite の失敗率はこれよりさらに高い
「完成まで5年、本番カットオーバーで大障害」のパターンが繰り返される

まとめ：アーキテクトが押さえるべき判断ロジック

┌─────────────────────────────────────────────────┐
│ 問い1：CICSの疑似会話モデルを維持するか？       │
│                                                 │
│   YES → z/OS継続・OpenFrame・MFESのいずれかへ  │
│   NO  → 性能・整合性の壊滅を覚悟してRewriteへ │
└─────────────────────────────────────────────────┘
                      ↓
┌─────────────────────────────────────────────────┐
│ 問い2：VSAMのアクセスパターンを維持するか？     │
│                                                 │
│   YES → OpenFrame(OFTSAM)・MFES を選ぶ         │
│   NO  → RDB移行、バッチ性能の徹底検証が必須    │
└─────────────────────────────────────────────────┘
                      ↓
┌─────────────────────────────────────────────────┐
│ 問い3：本当にCOBOLが問題か？                    │
│                                                 │
│   問題は「言語」ではなく                        │
│   「組織」「技術者不足」「暗黙仕様」ではないか？│
└─────────────────────────────────────────────────┘

最終結論

モダナイゼーションの失敗原因は COBOL ではない。

CICS の疑似会話モデルを破壊すること

VSAM を RDB に変換すること

この2つが壊滅の本質だ。

構造を維持したままコスト削減と近代化を実現できるのは、
z/OS継続・OpenFrame・MFES の3択のみである。
Java 化・クラウドネイティブ化による完全 Rewrite は、この構造問題を解決しない限り「成功確率が極めて低い選択肢」に留まる。

参考文献