【完全ガイド】NEC ACOS・富士通 GS21・日立 VOS3・IBM z/OS メインフレーム モダナイゼーション戦略

本記事は、IBM z／富士通 GS21／日立 VOS3 系のメインフレームで、COBOL／PL/I／JCL の基幹系を20〜40年動かしてきた金融・保険・公共・大手製造の情報システム部門で、「向こう10年でメインフレームをどうするか」を経営に答える役員／部長を読者として書きました。「いつかやらなければ」が「来年度の予算で書ける具体計画」に落ちる粒度を目指しています。リホスト・リライト・リプレースの抽象比較ではなく、自社のCOBOL本数・JCL本数・人材構成から逆算する判断材料を整理します。

1. 「2030年前後にCOBOL人材ピークが過ぎる」が10年計画の起点

移行を急ぐ最大の理由はハードウェア更改費でも、Oracle／IBMのライセンス費でもなく、COBOL／JCLを書ける人材の年齢分布です。IPA「DXレポート」「DX白書」などで繰り返し示されているとおり、メインフレーム保守を担う中核世代は50〜60代に集中し、退職ピークが2025〜2030年に重なります。

これは「COBOL技術者がゼロになる」という話ではなく、「自社の業務知識を持ったCOBOL技術者」が消えるという話です。コードは読めても、20年前の制度改正の経緯、業務担当との阿吽の呼吸、JCL のジョブ依存関係を頭の中で持っている技術者は代替不能です。10年計画の本当の制約は、業務知識の暗黙知を移行プロジェクトに参加できるうちに動かすことです。

2. 自社の規模感を「3つの数字」で経営に共有する

計画議論を始める前に、次の3つの数字を必ず揃えます。経営に「で、ウチはどれくらい大変なのか」を1分で説明する材料です。

このうち「総ステップ数」と「JCL本数」が、移行手段を選ぶ前の制約条件になります。500万行・1,000ジョブ未満ならリプレース（パッケージ／SaaS）も視野に入りますが、5,000万行・1万ジョブを超えるとリホストかリライトの二択にほぼ絞られます。

3. 3案の「本当の差」を、抽象論ではなく数字で並べる

リホスト・リライト・リプレースの比較表は世間に山ほどありますが、判断材料として弱いのは「失敗確率」と「途中で戻れるか」が抜けているからです。次の表で並べ直します。

金融・公共のように絶対に止められない業務では、いきなりリプレースは現実的でなく、「リホスト＋部分リライトを10年で進めながら、最終形をリプレースに寄せる」のがほぼ唯一の解になります。

4. リホストの本当の落としどころ：「時間を10年買う」

リホストは Micro Focus Enterprise Server、TmaxSoft OpenFrame、富士通 PROGRESSION などを使い、COBOL／PL/I／JCL／CICS／IMS をx86 Linux／クラウド環境に載せ替える戦略です。

誤解しやすいのは「リホストすればモダン化が進む」というイメージですが、実態は「メインフレーム筐体とハードウェア保守費から離れるだけで、COBOL人材依存と業務ロジックの不透明さは残る」です。AWS / Azure / GCP 上で動くCOBOLは「クラウドネイティブ」ではありません。

では何のためにやるか。答えは2つです。①ハードウェア更改の数十億円〜100億円規模の投資を、リライト／リプレースの財源に振り替える。②10年の時間を買って、その間にリライトを進める。リホストを「最終解」と誤認した瞬間に、5年後に「結局Javaで書き直すしかない」議論を再びすることになります。

5. リライトを選ぶなら「AI支援＋ペア体制」が前提

リライトは2020年代に入って、AI支援ツール（IBM watsonx Code Assistant for Z、各社のCOBOL→Java変換）の登場で、現実味が変わりました。とはいえ「ボタン一発で変換」には程遠く、変換後コードの正しさを保証する責任は人間に残るのは変わりません。

現実的に成立するリライト体制は次の組み合わせです。
・業務知識を持つベテランCOBOL技術者（仕様確認・テスト判定）
・モダン技術を持つ若手（Java/Spring／Kotlin／.NET の実装）
・AI支援ツール（一次変換・テストケース生成）
・業務側の意思決定者（「同じ挙動を維持する／この機会に変える」を判断）

このペア体制を組めない組織がリライトを開始すると、変換後コードの仕様凍結ができず、テスト工程で無限に手戻りします。

6. リプレース可能性を見極める3つの問い

パッケージ／SaaSへのリプレースが本当に可能かどうかは、次の3問で粗く判定できます。

① 業務がその業界の標準パッケージに「6割以上」載るか？ 銀行勘定系なら野村総研系・富士通系のパッケージ、保険なら大手SI製パッケージ、自治体ならJ-LIS標準仕様、製造業なら SAP S/4HANA。Fit が6割未満なら、リプレースは事実上カスタム開発と同じになります。
② 業務側がパッケージ標準に合わせる覚悟があるか？ 「ウチの業務はパッケージでは表現できない」が出た瞬間、リプレースは破綻します。経営トップが「合わせる」を決め切る必要があります。
③ 10年運用後の運用主体が見えているか？ パッケージベンダー／SI／クラウド事業者の組み合わせで、10年安定して動かせる体制が見えるか。

3問とも「Yes」なら、リプレースは現実解です。1つでも「No」なら、リホスト＋部分リライトのハイブリッドが安全策です。

7. データ移行の地雷：EBCDIC・パック10進・VSAM

どの戦略でも避けて通れないのがデータ移行です。Oracle / PostgreSQL / クラウドDWH（Snowflake / BigQuery）への移行で、毎回詰まる論点を挙げます。

① 文字コード（EBCDIC → UTF-8）。半角カナ、外字（自治体特に厄介）、JIS X 0212 の補助漢字、IBM拡張漢字など、変換テーブルを顧客マスタ全件で1文字ずつ検証する必要があります。氏名漢字の変換ミスは住民票・契約書印字で本番障害になります。
② パック10進・ゾーン10進。COBOL のCOMP-3 を Java の BigDecimal に正確に写すには、桁数・符号位置・小数点位置を1項目ずつ確認します。利息計算・端数処理は許容差ゼロです。
③ VSAM／IMS DB の階層構造。RDBMS のテーブル構造に正規化する設計は、業務側のキー使い方を聞き取らないと正しくできません。「使われていないキー」を整理する作業が、移行工数の半分を占めることがあります。
④ 夜間バッチの整合性ウィンドウ。リホスト後にバッチがメインフレーム時の何倍時間がかかるかを、性能試験で必ず計測します。「2時間が8時間になりサービスイン時刻に間に合わない」は、リホストプロジェクトで頻発する事故です。

8. JCL／ジョブネットの棚卸しと統廃合

JCL は「20年動いているから正しい」のではなく、「20年誰も触っていないだけ」のジョブが大量に含まれます。移行前に必ず実施すべきは次の3つです。

① 過去12カ月の実行ログから、未実行ジョブを特定する。中堅金融で1,000ジョブ中100〜200本は未実行のことがあります。
② 類似ジョブの統合候補を抽出する。「月次・四半期・年次で似たような帳票を出すだけ」のジョブは、移行先のJP1/AJS、Control-M、AWS Step Functions、Azure Data Factory などで統合できます。
③ 業務側にジョブごとの「いるか／いらないか」を聞く。情シス側だけで判断すると後工程で復活要望が出ます。

9. セキュリティ・規制対応：FISC／NISC／PCI DSS の足かせ

金融ならFISC安全対策基準、政府系なら政府機関等の対策基準（NISC）、カード業務なら PCI DSS、医療系なら3省2ガイドラインなど、業界規制が移行設計を強く縛ります。

メインフレームの「閉じた強固なセキュリティ」をクラウド前提のゼロトラスト型に翻訳する作業は、監査法人・規制当局との合意形成がプロジェクトの裏側で並走します。Entra ID／IAM、HSM／KMS、暗号化方式（FIPS 140-3 等）、ログ保管要件、データ所在地、災害対策（DR）の RPO／RTO まで、要件定義の早い段階で凍結する必要があります。

10. 並行稼働とフォールバックを「契約と予算」に組み込む

新旧並行稼働とフォールバックは、技術論ではなく契約と予算の問題です。次の3つを、初年度の予算組みの段階で確保します。

・並行稼働期間2〜5年のメインフレーム維持費（ライセンス・保守・人員）
・フォールバック発動時の費用（人員召集・データ巻き戻し・業務側補償）
・移行判定基準（並行で何カ月差異ゼロを継続したらカットオーバーするかの数値基準）

「うまくいったら並行を縮める」ではなく、「失敗時に何をどれだけのコストで戻すか」を文書化することで、経営が長期投資を続ける覚悟を保てます。

11. 10年計画の典型進め方

このロードマップを最初から経営に提示することで、「3年で終わると言われていたのに10年かかる」という典型的な期待値ギャップを最初に潰せます。

12. 失敗事例から逆算する「やってはいけない3つ」

大規模メインフレーム脱却で大きく傾いた事例の共通パターンは次の3つです。いずれも個社特定は避けますが、報道・公開資料・業界内で繰り返し聞く構造です。

① 「3年で完了」を経営にコミットしてリライトを開始。COBOL→Javaの全面書き換えを3年で終わらせる前提でスケジュールを引き、4年目に変換後コードのテスト工程で詰まり、追加予算で経営の信頼を失う。
② 業務知識を持つベテランの早期退職。プロジェクト開始時に60歳前後のベテランを「定年で交代」させた結果、仕様確認のたびに当時の議事録を掘り起こすことになり、テスト工程で無限の手戻り。
③ 並行稼働期間の予算を切ってカットオーバー。経営から「並行は1年で終わらせろ」と言われ、差異検証が不十分なまま本番化。本番障害が連続し、結果的に並行を3年延長することになり、トータル費用が当初見積もりの2倍を超える。

13. 来年度の予算化までに、いま動かす3アクション

10年計画は「来期予算」から始まります。今四半期に動くべきは次の3つです。

① COBOLソース・JCL・データ量の棚卸しを今期中に終える。「3つの数字」を経営に提示できる状態にする。これだけで予算化議論の土台が整います。
② リホスト3社・リライト3社・リプレース業界別2社からアセスメント提案を取る。各社の「やらないと言うこと」を比較すると、自社の地雷が見えます。
③ ベテランCOBOL技術者から業務仕様の暗黙知を文書化するプロジェクトを、移行プロジェクトとは別建てで先行起動する。退職ピーク前の3〜5年が勝負です。

メインフレーム脱却は10年に一度ではなく、40年に一度の意思決定です。3アクションに半年〜1年かける投資を惜しまないことが、その後9年の成否を決めます。