「富士通・NECのメインフレームのハードウェア保守が切れる」「IBM AS/400（IBM i）のサポートがいつまで続くか不安」「メインフレームの維持費が毎年膨らみ続けている」——こうした危機感を持つ経営者・情シス責任者が急増しています。メインフレームのオープン化（移行）は、費用・期間・リスクが大きいプロジェクトですが、先送りするほど費用と難易度が上がります。本記事では、移行手法3つの比較、規模別費用目安、移行先の選び方、失敗しないためのポイントを整理します。
『メインフレームの移行、どこから手をつければいいか分からない』とお悩みですか？ 25 年の経験で現実解を一緒に整理します。 無料相談 ＞メインフレーム移行の手法｜3択の結論から先に
メインフレームのオープン化には主に3つの手法があります。費用・期間・移行後の保守性が大きく異なるため、自社の状況に合った手法選定が重要です。
| 手法 | 概要 | 費用目安（150～300名） | 期間 | 向いているケース |
|---|---|---|---|---|
| リホスト | COBOLプログラムはそのままに、動作環境をLinux・クラウドへ移行。エミュレーター技術を利用することも | 3,000万～8,000万円 | 8～18ヶ月 | ハードウェア保守切れが目前・短期でコスト削減したい・COBOLコードを大きく変えたくない |
| リライト | COBOLのビジネスロジックを読み解き、Java・Python等の現代言語で書き直す | 5,000万～1.5億円 | 14～24ヶ月 | 業務ロジックに価値がある・COBOL依存を完全に解消したい・保守性の高いシステムにしたい |
| リビルド | 現行メインフレームシステムの業務要件を整理し直し、ERP等で新規構築 | 8,000万～2億円 | 18～30ヶ月 | 現行システムの業務ロジックが陳腐化・大幅な業務改善が必要・将来の拡張性を最重視 |
リホストは「問題の先送り」、リライト・リビルドは「根本解決」という位置づけです。リホストはCOBOLコードと技術者依存が続くため、COBOL技術者引退リスクは解消されません。ただし「ハードウェア保守切れが目前」の場合は、まずリホストで安定稼働を確保してから、次のステップとしてリライト・リビルドを計画するアプローチも有効です。
メインフレーム移行が急務になっている背景
背景 1：ハードウェア保守の終了期限
富士通・NEC・日立などの国産メインフレームは、ハードウェアの保守期限が順次終了しています。保守期限を過ぎると障害発生時に部品が調達できない・メーカーの修理対応が受けられないという状態になります。「まだ動いているから大丈夫」は最も危険な判断で、保守終了後の障害は業務停止に直結します。
背景 2：維持コストの急騰
メインフレームの維持費（ハードウェアリース料・保守料・COBOL技術者の人件費・ソフトウェアライセンス）は、サーバー1台あたり年間数千万円規模になることがあります。オープン系・クラウドへ移行することで、インフラコストを50～70%削減した事例も多数あります。
背景 3：COBOL技術者の引退加速
メインフレームを動かすCOBOLプログラムの保守には、COBOL技術者が不可欠です。しかし前述の通り、COBOL技術者の大量引退が2028年以降に集中します。移行を支援できる技術者が市場から消える前に着手することが、プロジェクトの成功確率を高めます。
規模別費用目安と5年TCO試算
| 企業規模（従業員数） | リホスト | リライト | リビルド（ERP） | 期間目安 |
|---|---|---|---|---|
| 50～150名 | 1,500万～5,000万円 | 3,000万～8,000万円 | 5,000万～1.2億円 | 8～18ヶ月 |
| 150～300名 | 3,000万～8,000万円 | 5,000万～1.5億円 | 8,000万～2億円 | 14～24ヶ月 |
| 300～500名 | 6,000万～1.5億円 | 1億～2.5億円 | 1.5億～3億円 | 18～30ヶ月 |
実質総費用はベンダー支払額の1.4～1.7倍と見ておいてください（メインフレーム特化案件は社内工数・データ移行・並行稼働コストが大きいため、オフコン特化の係数を適用）。また、5年TCOで見るとメインフレーム維持よりオープン化後の方が大幅に安くなるケースが多く、移行投資の回収期間は3～5年が標準的です。
移行先の選び方｜クラウド vs オンプレ vs ハイブリッド
メインフレームからの移行先は、大きく3つのパターンがあります。
移行先① オンプレLinuxサーバー
自社データセンター（または共有DC）にLinuxサーバーを設置し、移行後システムを稼働させます。データのセキュリティ要件が厳しい・インターネット接続に制限がある製造業・金融業に向いています。インフラ費用はクラウドより高い傾向がありますが、運用コストが予測しやすいのが利点です。
移行先② クラウド（AWS・Azure・GCP）
パブリッククラウドに移行します。初期投資を抑えられる・スケールアップが容易・災害対策が標準で組み込まれているのが利点です。需要変動が大きい・複数拠点で利用する企業に向いています。ただし、メインフレームで処理していた大量バッチ処理のパフォーマンス設計には注意が必要です。
移行先③ ハイブリッド（オンプレ＋クラウド）
機密性の高いデータ・基幹処理はオンプレ、サブシステム・Web連携はクラウドという構成です。段階的な移行に向いており、「まず非基幹系からクラウドへ、その後に基幹系を順次移行する」アプローチを取る中堅企業が増えています。
メインフレーム移行でよくある失敗パターン4つ
失敗 1：並行稼働期間を短く見積もった
メインフレームからオープン系への移行では、新旧システムを並行稼働させて検証する期間が必要です。この期間を「1ヶ月で十分」と見積もると、検証漏れが本番稼働後に表面化します。月次処理・年次処理を含む12ヶ月サイクルの検証を完了するために、最低6～12ヶ月の並行稼働期間を確保することをお勧めします。
失敗 2：データ変換の工数を甘く見た
メインフレームのEBCDIC文字コードをUTF-8/Shift-JISに変換する処理、固定長レコードから可変長への変換、元号・日付形式の変換など、データ変換は想定の2～3倍の工数がかかることがよくあります。変換対象データのボリューム・複雑度の事前調査を必ず実施してください。
失敗 3：バッチ処理の性能劣化を見落とした
メインフレームは大量データのバッチ処理に最適化されています。オープン系・クラウドへ移行すると、夜間バッチの処理時間が大幅に延長するケースがあります。移行前に「現行のバッチ処理量・処理時間」を正確に把握し、移行後のインフラ設計・性能チューニングの計画を立てることが重要です。
失敗 4：メインフレーム特有の業務ロジックを見落とした
メインフレームでは「メインフレームでしか動かない処理」（固定長ファイル処理・ジョブ制御言語JCL・スプール管理等）が組み込まれています。これらを洗い出さずに移行を進めると、稼働後に「この処理が動かない」という問題が多発します。移行前の「メインフレーム固有処理の棚卸し」を独立した工程として計画することが重要です。
まとめ｜メインフレーム移行は「ハードウェア保守切れ」を起点に今すぐ計画を
メインフレームの移行は、「保守切れが来てから」では対応が手遅れになります。移行プロジェクトは着手から稼働まで1～2.5年かかるため、ハードウェア保守終了の3年前から計画を開始することが理想です。
- 3手法：リホスト（短期・低コスト）→ リライト（言語移行）→ リビルド（根本刷新）
- 費用目安（150～300名）：3,000万～2億円（手法・規模次第）。実質総費用はベンダー費の1.4～1.7倍
- 移行先はクラウド・オンプレ・ハイブリッドから業務要件とセキュリティ要件で選定
- 失敗回避の鍵：並行稼働期間の確保・データ変換の事前調査・バッチ性能の設計・メインフレーム固有処理の棚卸し
COBOLシステムのリプレース・リライト・リホストの詳細比較は、COBOLリプレース vs リライト vs リホストの手法比較ガイドをご参照ください。COBOL技術者不足の問題については、COBOL技術者不足・2030年問題のガイドも合わせてご覧ください。
株式会社クオンツでは、『メインフレームの移行手法選定』『リホスト・リライト・リビルドの費用試算』『移行後のインフラ設計支援』のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社のメインフレーム規模・業務要件・予算感に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
