LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

メインフレーム脱却が急がれる背景——保守費の高騰と2025年の崖

メインフレーム脱却とは、汎用機（オフコンを含む大型の汎用計算機）で稼働する基幹系システムを、オープン系のサーバーやクラウド環境へ移す取り組みを指します。長年安定して稼働してきた基幹系ほど刷新が後回しにされやすく、保守を担ってきた技術者の高齢化と保守費の高騰が重なって、判断を迫られる企業が増えています。

経済産業省が2018年9月7日に公表したDXレポートは、老朽化・複雑化したレガシーシステムを抱える大企業のうち、稼働年数が21年以上に達する企業が約6割に及ぶと指摘しました^*1。同レポートは、レガシーシステムを放置してDXが実現できない場合、2025年以降に現在の約3倍にあたる12兆円/年規模の経済損失が生じる可能性があるとも述べています^*1。

IPA（独立行政法人情報処理推進機構）が2025年6月26日に公表した「DX動向2025（データ集）」でも、レガシーシステムの残存状況について日米比較のデータが示されました。システムの半分以上がレガシー化している企業の割合は、米国の22.8%に対し日本は41.2%に達すると報告されています^*2。あわせて先のDXレポートは、2025年には約43万人規模のIT人材が不足すると予測しており、保守を担う技術者の確保自体が難しくなる可能性を示しました^*1。

メインフレーム脱却の難しさは、老朽化した基盤を新しくするだけでなく、長年蓄積された業務ロジックやデータ構造をどう引き継ぐかという判断が伴う点にあります。次章では、移行方式ごとの違いを整理します。

移行方式は4つ——リホスト・リライト・リビルド・リプレースの違い

メインフレームからの移行方式は、大きく4つに分類できます。どの方式を選ぶかによって、必要な期間や費用、既存資産の活かし方が変わってきます。

リホスト——基盤だけを移し、既存資産を活かす方式

リホストは、既存プログラムのロジックにほとんど手を加えず、稼働基盤だけをメインフレームからオープン系サーバーやクラウドへ移す方式です^*3。日立製作所が公開するメインフレームリホスティング関連の解説では、COBOLやPL/I、JCL、SAM/VSAMといった既存資産をそのままオープン環境上で稼働させる仕組みが紹介されています^*3。改修範囲が狭いため費用やリスクを抑えやすい一方、オープン環境本来の柔軟性を十分に活かしにくい面もあると整理されています^*6。

リライト——現行仕様を保ちながら言語を書き直す方式

リライトは、現行のソフトウェア仕様（業務ロジックやデータの持ち方）を維持したまま、プログラミング言語をオープン系の言語に変換する方式です^*6。既存の業務仕様を継承できるため、移行後の機能追加や改善に取り組みやすくなりますが、変換後のコードの品質を確かめるテスト工程に相応の期間が必要になるとされています^*6。

リビルド——業務仕様から見直して再構築する方式

リビルドは、現行の業務仕様そのものを見直し、オープン系の環境で新たにシステムを構築する方式です^*6。要件定義からやり直すため、老朽化した業務プロセスの見直しや機能の絞り込みにまで踏み込めますが、必要な期間や費用、開発リスクは4方式のなかで大きくなりやすい点が課題として挙げられています^*6。

リプレース——パッケージやSaaSへの入れ替え

リプレースは、既存システムをパッケージソフトウェアやSaaS、あるいは新規開発したシステムへ入れ替える方式です。会計や人事給与のように業務内容を標準化しやすい領域であれば、自社で運用してきたロジックを維持するより、外部のパッケージやSaaSに合わせて業務プロセス自体を見直すほうが、移行後の運用負荷を抑えやすい場合があります。独自性の高い業務ロジックを多く抱えるシステムでは、パッケージの標準機能とのギャップをどこまで許容するかが検討の分かれ目になります。

4方式の違いを整理すると次の通りです。

COBOL/PL・I資産、JCL、階層型データ構造——メインフレーム特有の資産

メインフレームからの移行を検討する際は、資産の種類ごとに移行方針を分けて考える必要があります。基幹系の業務ロジックは主にCOBOLやPL/Iで書かれており、日立社会情報サービスが公開する移行支援サービスの説明でも、VOS3やzOS上で稼働するCOBOL85などのプログラム資産が移行対象として挙げられています^*4。

バッチ処理の実行順序やジョブの依存関係を制御しているのがJCL（Job Control Language）です。メインフレームでは複雑な機能を持つJCLで実行制御を行いますが、オープン環境ではJCLに比べて機能が単純なシェルスクリプトと、それを補う運用管理システムの組み合わせで制御することになります。JCLが担っていた機能のうち、オープン環境の仕組みだけでは対応しきれない部分は、プログラム側に組み込むか、運用管理システムに任せるかを個別に判断する必要があります。

データ構造についても、階層型やネットワーク型のデータベース、あるいは日立のXMAP2のような独自形式のファイル・データベースが使われているケースが少なくありません^*4。こうした資産はリレーショナルデータベースへそのまま置き換えられるとは限らず、データ構造そのものの見直しが必要になる場合があります。移行方式を選ぶ前に、どの資産をどこまで作り替える必要があるのかを棚卸しすることが実務上の出発点になります。

バッチ処理、EBCDIC文字コード、24/365運用——移行で見落としやすい論点

メインフレームは深夜のバッチウィンドウに日次・月次の集計処理をまとめて流す運用が一般的です。オープン環境へ移行するとジョブの並列度やスケジューラの仕組みが変わるため、バッチウィンドウ内に処理を収められるかどうかを事前に検証しておく必要があります。

文字コードも見落とされやすい論点の一つです。メインフレームの多くはEBCDIC（拡張二進化十進コード）という文字コード体系を採用しており、オープン環境で標準的なUTF-8などとの間で変換が必要になります。日立製作所が公開するコード変換に関する解説でも、異なるプラットフォーム間でプログラムコードを相互に変換する機能が課題として整理されており、Unicode・EUC・SJISなど複数のコード体系への対応や、古いコード体系の文字対応をユーザー側で定義するマッピング機能の必要性が示されています^*5。変換テーブルの設計を誤ると、半角カナや外字が正しく表示されない不具合につながる恐れがあります。

加えて基幹系システムの多くは24時間365日の稼働を前提としています。移行作業そのものを止めずに進めるか、切替のために許容できる停止時間をどう確保するかも、方式選定と並んで早い段階で合意しておくべき事項です。

移行方式をどう選ぶか——業務要件と資産量、許容できる期間で判断する

4方式のどれを選ぶかは、単純な優劣では決まりません。業務ロジックの独自性が高く、既存の仕様を維持する必要性が強い場合は、リホストやリライトのように資産を活かす方式が検討の起点になります。一方、業務プロセス自体を標準化したい、あるいは老朽化した仕様そのものを見直したい場合は、リビルドやリプレースが選択肢です。

判断材料としては、対象システムの規模（プログラム本数・JCL数）、許容できる移行期間、確保できる予算、そして移行後にどこまで機能を拡張したいかが挙げられます。稼働中の基幹系を止められる時間が限られている企業ほど、まずリホストで基盤を切り替え、そのあと段階的にリライトやリビルドへ進む二段階のアプローチを検討する価値があります。

いずれの方式でも、現行資産の棚卸しと影響範囲の調査を怠ると、移行後に想定外の不具合が発覚するリスクが残ります。着手前の調査工程に十分な時間を確保できるかどうかも、方式選定と同じくらい重要な判断材料になります。

内製と外注の分かれ目——委託先に確認すべきこと

メインフレームの移行を内製で進めるには、COBOL・PL/Iなどの言語知識に加え、JCLの実行制御、階層型データ構造、EBCDIC文字コードの変換ルールなど、複数領域の専門知識が求められます。長年その基幹系を保守してきた技術者が退職や高齢化で減っている企業ほど、内製だけで移行を完結させるのは難しくなります。

外注を検討する場合は、現行資産の棚卸しから移行方式の提案、移行後の検証、切替作業までを一括して依頼できるかどうかが分かれ目になります。JCLやバッチジョブの依存関係は資料が残っていないことも多く、委託先が実際のジョブログやソースコードを解析できる体制を持っているかを確認しておくことが欠かせません。

元請（プライムベンダー）が移行方式の提案から実装、24/365運用を前提とした切替計画までを一貫して担えるか、あるいは工程ごとに複数の会社と個別に契約する必要があるかによって、プロジェクト全体の管理負荷も変わってきます。委託先を選ぶ際は、自社の基幹系の規模や許容できる移行期間を踏まえたうえで、対応範囲を具体的に確認することが実務的な進め方です。

まとめ：メインフレーム脱却で押さえる判断軸

本稿ではメインフレーム脱却における移行方式の選び方を、公的情報や各社の公開資料をもとに整理しました。要点は3つに集約できます。第一に、移行方式はリホスト・リライト・リビルド・リプレースの4つに分かれ、既存資産をどこまで活かすかによって費用や期間が大きく変わります^*3*6。第二に、COBOL/PL・I資産、JCL、階層型のデータ構造、EBCDIC文字コードといったメインフレーム特有の論点は、方式選定と外注範囲の切り分けの両方に影響します^*4*5。第三に、経済産業省のDXレポートが指摘する保守費の高騰やIT人材不足の見通しを踏まえると^*1、資産の棚卸しと調査工程に十分な時間を確保できる委託先を選ぶことが実務上の判断軸になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：経済産業省「DXレポート～ITシステム『2025年の崖』の克服とDXの本格的な展開～」（2018年9月7日）
2. *2　出典：IPA（独立行政法人情報処理推進機構）「DX動向2025（データ集）」（2025年6月26日）（https://www.ipa.go.jp/digital/chousa/dx-trend/tbl5kb0000001mn2-att/dx-trend-data-collection-2025.pdf）
3. *3　出典：日立製作所「メインフレームリホスティングソリューション」（金融ソリューション）（https://www.hitachi.co.jp/products/it/finance/solutions/platform/environment/rehosting/index.html）
4. *4　出典：株式会社日立社会情報サービス「オープン化移行支援サービス」（https://www.hitachi-sis.co.jp/service/system/migration/open.html）
5. *5　出典：日立製作所「日立コード変換」（https://www.hitachi.co.jp/Prod/comp/soft1/codecnv/info/concept/index.html）
6. *6　出典：株式会社システムズ「マイグレーション技術コラム（マイグレーション手法・移行方式の解説）」（https://tech.systems-inc.com/column/category/migration/）

Tweet