メインフレームとは｜脱メインフレームの現実解と、4手法・事例から見る完遂への道筋

「自社のメインフレーム、あと何年使えるのだろう」
COBOLやPL/I等の資産を抱えるメインフレームを担当されている情シス部門の責任者であれば、一度はこうした不安を抱かれた経験もあるかと思います。日立製作所は2017年にハードウェア本体の開発から撤退、2034年12月にはOS保守も終了し、富士通も2030年度末を目途にメインフレームの製造・販売を終えます。COBOL技術者の引退は進み、保守費は高止まりしたまま。「いつか」は、もう先送りできない局面に来ています。
本記事では、メインフレームの定義から、脱メインフレームが経営課題となった背景、4つの移行手法、大企業の完遂事例までを整理します。結論から申し上げると、COBOLやPL/Iなどの資産をJavaへ変換・移行する「リライト」こそ、踏み切れなかった脱メインフレームを現実的な投資打開策に変える手法と考えます。検討の材料としてご活用ください。

メインフレームとは｜基幹業務を支える大型汎用コンピュータ

メインフレームは「汎用機」「ホストコンピュータ」とも呼ばれます。本章ではまず定義と特性を整理します（呼称は以降「メインフレーム」に統一します）。

メインフレームの定義と他システムとの違い

メインフレームとは、企業や行政の中核業務を半世紀以上支えてきた大型のコンピュータを指します。身近な例を挙げれば、銀行口座の入出金を処理する勘定系、工場の生産管理、自治体の住民記録など。社会の土台となる仕組みの多くが、この上で動いてきました。現場では「汎用機」「ホスト（ホストコンピュータ）」と呼ばれることもありますが、指しているものは同じです。オープン系システムとの違いは構成の思想にあり、サーバー・OS・データベースを複数ベンダーの製品から組み合わせるオープン系に対し、メインフレームはハードウェアからOS、ミドルウェアまでを一社が設計し、まとめて提供します。この構造が高い信頼性を支える一方で、特定ベンダーへの依存と移行の難しさを生んできました（移行の難所は後段の手法・進め方で扱います）。

なぜ「基幹業務の主役」であり続けてきたのか

60年以上にわたり基幹業務で選ばれ続けてきた理由は、3つの特性に集約されます。第一に、極めて高い可用性。IBM Zは、z16で99.99999%（年間停止時間およそ3秒）、最新機z17では99.999999%といった、桁外れの可用性が調査機関などで示されています（富士通・NECは具体数値を公表していませんが、24時間365日の連続稼働を前提とした設計です。なお、実運用の可用性は構成や運用体制によって変わります）。第二に、夜間バッチで数百万件規模の取引を処理する能力。第三に、10〜20年単位の長期安定稼働です。基幹業務が求める「止まらない・大量に処理する・長持ちする」を最も高い水準で満たしてきたのが、メインフレームでした。だからこそ、簡単には手放せない。脱メインフレームの難しさは、この優秀さの裏返しでもあります。

なぜ今、脱メインフレームが経営課題なのか

その「止まらない・長持ちする」メインフレームを、なぜ手放さなければならないのか。先送りを許さない構造的な圧力を、サポート終了・人材・コストの観点から整理します。

ベンダーごとのサポート終了タイムライン

ベンダーの動向は大きく分かれています。IBMはz17（2025年6月出荷開始）などAI処理を組み込んだ最新モデルを投入し続けており、当面は事業継続が見込まれます。一方、日立製作所は2017年にハードウェア本体の開発から撤退し、後継機はIBM製ハードウェアに日立のOS「VOS3/XS」を載せる協業モデルへ移行しました。さらに2026年5月には、そのVOS3の販売を2027年11月、保守を2034年12月に終了すると発表しています。NECは事業を継続していますが、市場の縮小が進む中、長期の見通しを楽観できる状況とは言えません。まずは自社が利用するベンダーのロードマップ確認が、検討の出発点になります。同じ「メインフレーム」でも、ベンダーによって残された時間はまったく違うためです。

富士通メインフレーム事業の終了に向けた移行加速

国内最大級のユーザー基盤を持つ富士通は、2030年度末（2031年3月）にメインフレームの製造販売を終息し、2035年度末（2036年3月）に保守サポートを終了すると公表しています。日経BPの調査報道によると、2024年7月時点で国内には320社・650台が稼働しており、2025年3月には600台を下回る見込み。移行方針が確定した企業の約5割はリビルドを選択し、残りはリホストなどで対応を進めているとされます。アセスメントから本番稼働まで3〜5年かかる大規模案件であれば、保守終了の2035年度末から逆算した検討開始の期限は、すでに目前。「まだ10年ある」ではなく「あと10年しかない」と捉えるべき局面です。

COBOL技術者の引退と人材不足の深刻化

メインフレームの業務アプリケーションはCOBOL・PL/I・アセンブラで書かれ、バッチ制御はJCL、データ管理はIMSやDb2（IBM系）、AIM/DB（富士通系）といった独自のDB・ファイルシステムが担っています。これらを扱える技術者の高齢化と退職は本格化しており、新規の育成はごくわずか。IPA（情報処理推進機構）が2019年に基本情報技術者試験の出題言語からCOBOLの廃止を発表したことは、その象徴と言えるでしょう。「動いてはいるが、直せる人がいない」という状態は、もはや例外ではなくなりつつあります。問題はプログラムの保守だけにとどまりません。JCLやDB設計を理解した技術者が現場を離れれば、法改正対応や障害対応すらままならなくなります。

保守費高騰とブラックボックス化のリスク

ハードウェア保守費、ソフトウェア使用料、人件費、そして属人化対策まで含めた維持コストは、年々高止まりしています。加えて、数十年にわたる継ぎ接ぎの改修で構造が複雑化し、誰も全容を把握できないブラックボックス化が進行。経営層には「コスト」、現場には「ブラックボックス化」として現れるこの2つの問題は、実は根が同じです。両方の意思決定者を動かす論点として束ねて提示することが、社内合意への近道になります。「コスト削減」だけでは現場が動かず、「ブラックボックス解消」だけでは経営層に響かない。この二正面性を意識した上申設計が要点です。

脱メインフレームの代表的な4つの手法

脱メインフレームの代表的な手法は4つあります。COBOL・PL/I・JCLといった資産をどう扱うかを軸に、理想型から現実解への順で見ていきましょう。

4手法の比較表｜コスト・期間・リスクで選ぶ

コスト・期間・リスク・メインフレーム言語からの脱却・DX推進度の5軸で整理しました。「言語からの脱却」の軸が、手法選定の分かれ目になります。社内上申の際の整理にもご活用ください。

※リホストの「△」は、COBOL等の言語資産が残存するためです。リライトのDX推進度「△」は、既存の業務ロジックを踏襲する手法であるため。DX（業務改革）はリライト完了後に段階的に進める形になります。

リビルド｜業務要件から作り直す理想型

業務要件をゼロから定義し直し、新たに作り直す理想型です。自由度とDX推進の価値は最大ですが、期間・コスト・要件定義の難度も最大。大規模なビッグバン型ほど頓挫のリスクが高く、仕様書の残っていない長期稼働システムでは、要件定義だけで数年を要することもあります。数十年かけて磨き込まれた業務ロジックをゼロから解き明かす作業は、想像以上の暗黙知の壁に阻まれるのが実情です。

リプレイス｜パッケージ・SaaSへの全面移行

自社システムを廃止し、市販のERPパッケージやSaaSへ全面移行する手法です。標準業務に寄せられる領域では有効ですが、メインフレーム上の独自業務ロジックが多いほどアドオンが肥大化し、保守困難に陥るパターンが典型的な失敗例として知られています。「業務をパッケージに合わせる」覚悟を組織として持てるかどうかが、この手法の分かれ目になります。

リホスト｜オープン系へ載せ替える低リスク手法

COBOLやPL/I等の言語をそのまま残し、業務ロジックをほぼ維持したまま、Linux・Windows・クラウドといったオープン系基盤へ載せ替える手法です。短期間・低リスクで「いったんメインフレーム依存から脱出する」には有効でしょう。ただしCOBOLやPL/I等の資産と属人化のリスクは温存されるため、技術者不足という根本課題への答えにはなりません。将来のモダナイゼーションへ進む中間ステップとしての位置づけになります。

リライト｜COBOLからJavaなどへ変換する現実解

COBOL・PL/I・JCLを自動変換ツールでJava等のオープン系言語へ書き換える手法です。業務ロジックを維持したまま、ハードウェア・OS・ミドルウェアの呪縛から脱却できます。自動変換ツールの進化と大規模案件での成功事例の蓄積により、数千万ステップ級でも現実解となってきました。変換後はJavaという標準的な言語になるため、技術者確保の選択肢も大きく広がります。リビルドと比べて費用・期間を大きく圧縮できる点も特長です。

大規模刷新で「リライトが現実解」となる3つの理由

では、4手法のうち何を選ぶべきか。大規模・長期稼働のメインフレームでは、リライトが現実解として浮上しています。理由は3つです。

• ①業務ロジック維持で合意形成のハードルが低い：業務改革リスクを伴わないため、現場の合意と経営判断の両方が通しやすくなります
• ②変換ツールの実用化で完遂可能性が向上：業務ロジックの変換精度はほぼ100%に達し、工期・コストが予見可能になりました
• ③Lift→Shiftの段階的アプローチ：リライトで技術的負債を解消し（Lift）、その後クラウド・AI連携・業務改革（Shift）へ段階的に接続できます

脱メインフレームを失敗させない進め方

手法を選んだだけでは、プロジェクトは前に進みません。次は進め方です。COBOL資産の解析、JCLを含むアーキテクチャ全体の移行、業務ロジックの継承、そして性能・保守性の品質担保。メインフレーム特有の難所に向き合う4つのステップを整理します。

メインフレーム特有の棚卸し｜JCL・VSAM・帳票まで踏み込む

プログラム本数、ステップ数、JCL本数、DBテーブル数、外部連携数、そして未使用資産（デッドコード）の特定。メインフレームの棚卸しは、ここまで踏み込みます。長年運用されてきたシステムには、誰も使っていない機能やドキュメント未整備のロジックが必ず存在するもの。事前調査(アセスメント)段階で移行対象をどこまで絞り込めるかが、後工程の期間とコストを大きく左右します。後述するJFEスチール様の事例では、この棚卸しによって移行資産を約6割削減されています。同社の先行拠点では、普段使われていない画面・帳票の約9割が移行不要と判断されたといいます。「全部持っていく」前提を疑うことから、棚卸しは始まります。仕分けの判断は、システム部門だけでなく、日々その画面や帳票を使っている現場メンバーを巻き込んで進めるのが鉄則です。

手法選定とPoC｜COBOL変換率を実機で見極める

アセスメント結果を受けて、4手法から業務・機能毎に自社に合うものを選定します。重要なのは、机上検討で終わらせないことです。カタログ上の変換率と、自社の独自記述を含むコードの変換率は別物と考えてください。自社のソースコードを実際にJavaへ変換し、変換率をPoC（概念実証）で見極める工程は欠かせません。PoCで洗い出した課題には本番移行前に対策を実施し、本番で問題を発生させないこと。これが成功率を大きく左右し決めます。RFPを作成する際も、PoCの実施を前提に組み込む視点を持っておきたいところです。

現新比較テスト｜大量データで完全一致を検証する

同じインプットを旧メインフレームと新システムの両方に流し、出力（業務データ・帳票・ログ）が完全に一致するかを大量データで検証する工程です。大規模案件では、この工程が全体期間の相当な割合を占めることもあります。地味な作業ですが、本番切替後の業務影響をゼロに近づける要所。ここにどれだけ時間と体制を投じられるかが、移行品質をほぼ決めると言ってよいでしょう。月次・年次など実行頻度の低いバッチには、数カ月先を想定したテストデータの準備も必要になります。テスト計画は移行スケジュールの初期段階から織り込んでおくべき工程です。

本番切替｜リハーサルと切り戻しで一括移行をやり切る

現新比較テストを終えたら、いよいよ本番切替です。リライト型の移行では、新旧を長期に並行稼働させるのではなく、十分なリハーサルを重ねたうえで一括切替に臨むのが基本になります。移行リハーサルを本番さながらに反復し、想定外の事態を一つずつ潰し込み、万一に備えた切り戻し手順を整える。発注者とベンダーの役割分担と、強力なPMO体制。これらが揃えば、一括切替は「賭け」ではなく「検証済みの計画実行」になります。なお、新旧を長期に並行稼働させる段階移行は、一見すると安全に見えますが、中間インターフェースの新規構築やテストの重複により、かえって期間とコストが膨らむことも少なくありません。

脱メインフレーム完遂を支えるベンダー選定の3視点

PoCで自社なりの判断軸を持ったら、各社の提案を3つの視点で比較していきます。見積金額だけで決めてしまうのは「ベンダー丸投げ」への入り口です。

視点1｜大規模プロジェクトを完遂するケイパビリティ

大規模プロジェクトをやり切るPM力・動員力・経験値を見ます。最重要指標は、過去の完遂規模と件数です。数千万ステップ級のリライトを完遂した経験を持つ会社は、世界を見渡しても限られます。提案の説得力と実行力は別物ですから、PoCの結果と自社の評価軸とを突き合わせて評価してください。

視点2｜自社開発ツールと技術的優位性

変換ツールを自社で開発・改善し続けているかどうかは、技術力を測る分かりやすい指標になります。長期利用に耐えるコードを生成するツールの品質を、変換率・性能・保守性の3点で評価しましょう。メインフレームとオープン環境ではアーキテクチャが根本的に異なるため、コード変換の精度だけでなく、その差異を埋める技術・経験の有無も確認しておきたいポイントです。

視点3｜刷新後の保守・運用まで伴走できる体制

本番稼働後の保守・機能拡張・AI時代への対応まで、長く伴走できる体制があるか。移行して終わりではなく、Lift→Shiftで発展させ続けられるパートナーかどうかに、刷新の真価が表れます。移行後に既存・新規どちらのベンダーでも保守を継続できる品質と技術を担保できるか、という観点も忘れずに確認してください。

脱メインフレーム完遂事例2選

最後に、実際に脱メインフレームをやり遂げた2社をご覧ください。製造・電機。業界の異なる2事例は、規模も時間的制約も様々です。詳細はTISI株式会社の公式事例ページで公開されています。

JFEスチール株式会社様/JFEシステムズ株式会社様

半世紀にわたり鉄鋼の生産プロセスを支えてきたメインフレームからの脱却を、全社として完遂されたのがJFEスチール様です。東日本製鉄所（京浜地区）の対象資産は3,400万ステップ。現場メンバーが主導する業務仕分けで約6割にあたる2,000万ステップを削減してからプロジェクトに臨み、業務ロジックをほぼ100%の精度で変換したうえで、29カ月という短期間での移行をやり遂げました。仙台製造所（21カ月）で確立した進め方を次の拠点へ受け渡していく、多拠点展開の手本といえる事例です。

▶事例詳細：JFEスチール東日本製鉄所（京浜地区）、基幹システム3,400万ステップを29カ月でオープン化。成功を支えたリライト技術×現場主導のPJ推進。
▶事例詳細（仙台製造所）：JFEスチール仙台製造所の基幹システムをリライト手法でオープン化。永続性のある基盤でDXを加速し「脱炭素」の生産プロセス改革を推進する。

パナソニック インフォメーションシステムズ株式会社様

1988年、IBMメインフレーム上に生まれたパナソニックグループの人事システム。オープン化が進んだ後も一部機能がCOBOLのまま残り、気づけばメインフレームの保守終了（2023年7月）まで約1年に迫っていました。新規開発で間に合う時間はもう残されていない。そこで選ばれたのがリライトです。変換からテストまでを約7カ月で駆け抜け、保守終了と同時にメインフレームを計画どおり廃止。変換起因の障害ゼロという品質が、短期移行の価値を裏づけました。

▶事例詳細：パナソニックグループ人事システムに残存するCOBOL資産をJavaへリライト。短期に脱メインフレーム化を実現。

2事例に共通する成功要因

3,400万ステップ級の製造基幹システムから、7カ月の短期移行まで。業界も規模も異なる2事例ですが、完遂を支えた設計判断には共通点があります。大きく3つです。

• ①メインフレーム固有資産（COBOL・PL/I・JCL・VSAM・帳票・バッチ）を一気通貫で扱う移行：プログラムだけ変換しても、JCLやデータが残れば移行は完結しません
• ②移行元ベンダー（IBM・富士通等のメーカー）に依存しないリライト技術の採用：特定メーカーの製品に縛られない基盤へ移ることで、保守の担い手を選べる自由を取り戻しています
• ③アセスメントから本番稼働後まで続く伴走体制：1年がかりのPoCやユーザ企業・現行システム保守企業・移行ベンダーの3社ワンチームでの推進など、稼働後まで支える体制が完遂を支えました

裏を返せば、この3つはリライトを採用する企業がベンダー選定時に確認すべき要件でもあります。

メインフレーム刷新を「いつか」から「今」へ

ここまで、メインフレームの定義から手法・進め方・事例までを見てきました。メインフレーム刷新は、長らく「踏み切れない」テーマでした。しかし、メーカーの事業終了と技術者の引退は、先送りの猶予が尽きたことを告げています。リライトの進化と大企業2事例の蓄積は、踏み切る決断を後押しするはずです。リミットが見えている以上、検討の開始が早いほど選択肢は広がります。最初の一歩は、自社メインフレーム資産の棚卸しから。本記事がその出発点になれば幸いです。