メインフレームのオープン化は、保守・運用コストや人材不足、メーカーのサポート終了に備え、LinuxやWindows、クラウドなどの環境へ移行する取り組みです。オープン化により人材確保や新技術との連携を進めやすくなる一方、移行方式によって費用・期間・リスクは異なります。現行資産と依存関係を把握し、事前のコスト試算や段階的な移行計画を立てることが重要です。
サポート終了や人材不足が迫るなかで重要なのは、移行方式を先に決めることではありません。現行資産、業務への影響、将来の運用体制を整理し、期限・費用・リスクのバランスが取れる移行計画をつくることです。
「このままメインフレームを使い続けて大丈夫なのか」「オープン化したいけれど、何から手をつければいいのか分からない」――そうした課題や不安を抱える情シス担当者・DX推進担当者の方は、決して少なくありません。
メインフレームは長年にわたって企業の基幹を支えてきた信頼性の高い存在です。一方で、保守コストの増大、IT人材の枯渇、メーカーサポートの終了など、現状維持そのものが経営リスクになりつつあります。
本記事では、レガシーマイグレーション（メインフレームのオープン化）について、移行を検討すべき背景、方式ごとの選び方、失敗を防ぐための実務上の確認点までを解説します。
検討の起点は「古いから」ではありません。止められない業務を、将来も安定して運用できる状態に保てるかどうかです。
経済産業省はDXレポートで、日本企業が抱えるITシステムの老朽化・複雑化・ブラックボックス化というリスクを指摘しました。既存のレガシーシステムを刷新できなかった場合、将来的に大きな経済損失が生じる可能性も示されています。
特に深刻なのは、システムを理解し、障害時に判断できる人材が社内外で減っていることです。COBOLやJCLに詳しい担当者が在籍していても、属人的な運用、口頭でのみ引き継がれた例外処理、更新されていない設計書が残っていれば、担当者の退職や委託先の変更がそのまま事業継続リスクになります。
障害対応、法改正、制度変更、周辺システムの更新に対し、誰がどれだけの期間で対応できるのかを確認します。保守要員を確保できない、改修見積もりが読めない、テスト範囲が不明確といった状態なら、移行計画の策定を急ぐべき段階です。
オープン化を検討すべき理由の一つが、メーカーの製品・保守方針です。なかでも富士通は、メインフレーム製品について2030年に生産終了、2035年にサポート終了する方針を公表しています。
ただし、サポート終了年を移行完了の期限と考えるのは危険です。基幹システムの移行は、現行調査、移行方式の比較、PoC、設計、変換・開発、総合テスト、並行稼働、本番切替まで複数の工程があります。移行対象が多い場合や周辺連携が複雑な場合には、着手から安定稼働まで数年を要することもあります。
※参照元：FUJITSU公式HP｜2025年9月調査時点 FUJITSU公式HP
「2035年までに移行する」だけでなく、いつまでに現行調査を終えるか、PoCで何を確認するか、移行失敗時にどこまで切り戻せるかを先に決めます。期限が近づくほど、対応できるベンダーや要員の確保が難しくなる点も考慮しましょう。
効果は「保守費が下がるか」だけではありません。移行後に、改修・連携・運用をどこまで自社でコントロールできるようになるかが重要です。
最適な方式は一つではありません。「どこまで業務を変えられるか」「いつまでに移行するか」「移行後に何を実現したいか」で選びます。
| 手法 | 概要 | コスト感 | 期間 | 主な判断軸 |
|---|---|---|---|---|
| リホスト | 既存プログラムを極力変えず、動作環境を移行 | 低〜中 | 比較的短期 | 業務を止めず、期限優先で基盤を変えたい |
| リライト | 既存ロジックをもとに、新言語・新技術へ書き換え | 中 | 中期 | 業務ロジックは維持しつつ、保守性を高めたい |
| リビルド | 既存仕様を参照しながら、設計・開発を再構築 | 高 | 長期 | 業務・システムの両方を見直す余力がある |
| リプレース | パッケージやクラウドサービスへ切り替え | 中〜高 | 中〜長期 | 標準機能に業務を合わせ、個別開発を減らせる |
既存のCOBOL資産や業務ロジックをできるだけ活かし、実行基盤をオープン環境やクラウド環境へ移す方法です。移行期間と業務影響を抑えやすい一方、複雑な業務ロジックやデータ構造は残りやすくなります。
既存の業務ロジックを参考に、COBOLなどで書かれたプログラムをJavaやC#などへ書き換える方法です。変換後に「読めるが直しにくいコード」が残らないか、品質・保守性・テスト方針を確認する必要があります。
既存仕様を参考にしながら、システムを再構築する方法です。業務のムダや重複を見直せますが、現行に埋もれた例外処理や暗黙知を把握できなければ、要件漏れや工数超過につながります。
ERPや業務パッケージ、SaaSへ既存システムを置き換える方法です。開発量を抑えられる可能性がありますが、パッケージに合わせて業務ルールを変える合意形成が必要になります。
「COBOLを残すか」「クラウドへ移すか」といった技術から入ると、方式が先行しやすくなります。まずは業務ごとに、廃止するもの、維持するもの、優先して刷新するものを分けてから、方式を比較しましょう。
失敗の原因は技術選定だけではありません。現行業務の理解不足、テスト不足、意思決定の遅れが移行を難しくします。
設計書にない例外処理、長年の運用で追加された個別ルール、特定担当者しか知らない復旧手順が残っていることがあります。プログラムだけでなく、帳票、外字、ジョブ、周辺連携、手作業まで含めて棚卸しすることが重要です。
監視、障害対応、バックアップ、権限管理、性能管理、夜間バッチの対応方法は、移行後に改めて必要になります。「移せるか」だけでなく、「誰がどう運用するか」までを要件に含めましょう。
基幹システムでは、通常処理だけでなく、月次・年次処理、例外処理、障害時の復旧、外部連携の失敗時まで確認する必要があります。現新照合の対象と合格基準を早い段階で決め、テストに必要なデータと現場要員を確保します。
経営層は投資対効果と期限、現場は業務停止や操作変更、情シスは品質と保守性を重視します。目的・対象範囲・変更しないこと・切り戻し条件を共有し、判断を先送りしない運営体制をつくることが必要です。
提案資料の見栄えよりも、自社の現行資産と移行リスクをどこまで具体的に質問・検証してくれるかを確認しましょう。
移行を進める際に、社内で実際に論点になりやすい質問を整理しました。
先に決めるべきなのは移行方式ではなく、いつまでに、どの業務を、どの水準で継続可能にするかです。まず現行資産を棚卸しし、サポート終了の影響を受ける対象、事業上止められない業務、代替のない周辺連携を整理します。
そのうえで、現状維持にかかるリスクとコスト、移行に必要な期間、段階移行の可否を比較します。サポート終了まで時間がない場合でも、全体を一度に刷新する必要はありません。影響が大きい業務から優先順位をつけ、リホストで期限に対応しつつ、その後に改善を進める選択肢もあります。
「移行すれば安くなる」とだけ説明すると、初期投資の大きさに議論が偏りやすくなります。移行費用、現行維持費、障害・人材・サポート終了のリスク、移行後に得られる選択肢を分けて示すことが重要です。
たとえば、現行環境の保守契約、ハードウェア更新、特定人材への依存、改修に要する期間、障害時の事業影響を可視化します。そのうえで、移行後に短縮できる改修期間、連携できるサービス、採用・外部委託の選択肢などを、確定的な効果ではなく実現可能性として整理すると、投資判断に必要な比較材料になります。
全面刷新が常に正解ではありません。業務ロジックが安定しており、変更頻度が低く、期限への対応を優先したいなら、COBOLやJCLを活かすリホストは有効な選択肢です。
一方で、改修のたびに影響範囲が読めない、担当者を確保できない、外部連携やデータ活用が制約になっている場合は、リライトやリビルドを検討する価値があります。判断は言語の新旧ではなく、その資産が事業上の強みなのか、将来の変化を妨げる負債なのかを基準に行いましょう。
現行資産の調査前に出される期間や費用は、あくまで概算です。特に、使われていないと思われていたプログラム、例外処理、帳票、外字、外部連携、手作業の運用が後から判明すると、工数は大きく変わります。
見積もりを比較する際は、金額だけでなく、調査対象、変換対象、テスト範囲、データ移行、並行稼働、教育、移行後支援が含まれているかを確認します。見積もりの前提と対象外が明文化されているかが、妥当性を見極める重要なポイントです。
画面が表示され、通常処理が動くことだけでは十分ではありません。業務結果、データ更新、帳票、バッチ処理時間、外部連携、締め処理、障害時の復旧などについて、現行環境と移行後環境の差異を確認します。
特に基幹業務では、どの処理を照合対象にするか、許容できる差異は何か、誰が合格判定を行うかを事前に決めることが重要です。テストの合格基準をベンダー任せにせず、業務部門と合意しておくことで、本番切替後の認識違いを防げます。
リホスト自体が不適切というわけではありません。ただし、なぜその方式が自社の期限・業務・予算・将来計画に合うのかを説明できるかが重要です。
「他方式と比べた場合の違い」「移行後に残る技術的負債」「将来リライトやリビルドを行う場合の選択肢」「対象外となる資産や機能」を具体的に質問しましょう。方式のメリットだけでなく、残る課題と次の打ち手まで説明できる提案であれば、意思決定に必要な材料を得やすくなります。
メインフレームのオープン化は、単なるコスト削減策ではありません。現行資産を正確に把握し、変える業務と守る業務を分け、移行後の運用まで設計することで、将来の変化に対応できる基盤を整えられます。
マイグレーションは、企業ごとに実現したい移行内容や抱える課題が異なります。
本メディアでは、移行の目的を「レガシーのオープン化」「AWSへの移行と運用」「大規模システムへの移行」の3タイプに分け、それぞれに適したマイグレーションサービス企業を紹介しています。
ここではマイグレーションサービスのプロジェクト実績が100件以上の信頼できる会社を厳選。その中で「レガシーシステムのオープン化」「AWSへの移行」「大規模システムの移行」という3つの目的別におすすめの会社を紹介します。
【選定基準】
「マイグレーションサービス」とGoogle検索し表示される10社のうち、公式HPでマイグレーションサービスの移行実績が100件以上の3社をピックアップしました。（2025年8月20日時点）
※1.2.参照元：FPTジャパンホールディングス公式HP（https://fptsoftware.jp/resource-center/connect/connect-legacy-modernization）2025年8月20日時点
※3.4.参照元：TIS公式HP（https://www.tis.jp/service_solution/aws/migration/）2025年8月20日時点
※5.参照元：日立製作所公式HP（https://www.hitachi-sis.co.jp/service/system/migration/index.html）