リホスト
既存のCOBOL資産や業務ロジックをできるだけ活かしながら、実行基盤をオープン環境やクラウド環境へ移す方法です。
向いているケース
- 業務仕様を大きく変えずに移行したい
- 移行期間とリスクを抑えたい
- まずは保守リスクや運用コストから脱却したい
長年に渡り日本のメインフレーム市場を牽引してきた富士通。販売終了・サポート終了の発表を受け、 既存資産をどう維持し、どの方式で刷新するかを検討する企業が増えています。 ここでは、富士通メインフレーム移行の考え方と、参考になる導入事例を紹介します。
富士通のメインフレームは、企業の基幹業務システムなどで多く使用されてきました。 しかし富士通が2030年にメインフレームの販売を終了、2035年にサポートを終了することを発表。 これを受け、多くのユーザー企業が 基幹システムを維持しながら、将来的なビジネス展開に対応できる新しいオープンシステムやクラウド環境への移行・刷新 を検討しています。
「富士通マイグレーション」という言葉は、富士通メインフレーム、富士通製オフコン、NetCOBOL資産などの移行を広く指す場合があります。 本ページではその中でも、富士通メインフレーム上の既存資産を、オープン環境やクラウド環境へ移行するケースを中心に解説します。
富士通メインフレームの移行で最初に見るべきなのは、移行先の環境ではありません。 まずは、現行システムの中にどのような資産が残っているか、どこまで既存資産を活かすか、移行後も業務を安定して続けられるかを確認する必要があります。
COBOL、JCL、DB、帳票、外字、運用手順まで確認する
リホスト・リライト・リビルドのどれが現実的か比較する
保守、監視、障害対応まで支えられる体制を確認する
富士通メインフレームのマイグレーションでは、アプリケーションだけでなく、業務を動かしている周辺資産まで確認します。 移行前の棚卸しでは、少なくとも以下のような項目を見ておきたいところです。
表は横にスクロールできます
| 分類 | 主な確認対象 | 確認したいポイント |
|---|---|---|
| アプリケーション資産 | COBOL、アセンブラ、EASY、Naturalなど | 既存ロジックをどこまで活かせるか。独自仕様や非互換がないか。 |
| バッチ・ジョブ資産 | JCL、SORT、ジョブネットなど | 移行後の実行方法、スケジュール管理、異常終了時の対応をどうするか。 |
| データ資産 | AIM/NDB、AIM/RDB、ADABAS、VSAM、SAMなど | データ形式、移行先DB、データ整合性、性能面の影響をどう確認するか。 |
| 画面・帳票資産 | 画面定義体、帳票定義体、印刷機能など | Web化や帳票基盤の再構築が必要か。出力レイアウトを再現できるか。 |
| 文字コード・外字 | S-JIS、EUC、Unicode、外字など | 文字化け、桁あふれ、ソート順の違い、帳票表示崩れが起きないか。 |
| 運用・周辺連携 | 監視、バックアップ、手順書、他システム連携など | 移行後の運用体制、障害対応、データ受け渡し方法をどう設計するか。 |
この中でも、文字コード、外字、帳票、JCL、データベースは差異が出やすい部分です。 画面上では問題なく動いているように見えても、帳票の出力位置がずれたり、文字化けが起きたり、バッチ処理の結果が現行環境と一致しなかったりすることがあります。
富士通メインフレームの移行方式には、主にリホスト、リライト、リビルドがあります。 どれか一つが常に正解というわけではありません。既存資産をどこまで活かすか、業務をどこまで変えるか、どれくらいの期間とコストを許容できるかで選び方は変わります。
既存のCOBOL資産や業務ロジックをできるだけ活かしながら、実行基盤をオープン環境やクラウド環境へ移す方法です。
既存の業務ロジックを参考にしながら、Javaや.NETなど別の言語・実行基盤へ書き換える方法です。
既存システムをそのまま移すのではなく、業務プロセスやシステム構成から見直して再構築する方法です。
既存資産を活かしてメインフレームから脱却したい場合、まず検討しやすいのはリホストです。 ただし、将来の保守性や業務改革まで考えるなら、リライトやリビルドも比較しておきたいところです。 最初から方式を決め打ちせず、資産棚卸しやPoCを通じて現実的な選択肢を絞る方が安全です。
富士通メインフレームのマイグレーションは、いきなり本番移行に進むものではありません。 基幹システムは業務への影響が大きいため、現行資産の調査からテスト、本番切り替え、移行後の安定化まで段階的に進めます。
プログラム、JCL、DB、ファイル、帳票、画面、外字、運用手順、周辺システム連携を洗い出します。 使われていない資産と、移行が必要な資産を分けることで、移行範囲を明確にします。
すべてを移す必要があるとは限りません。 廃止予定の業務、他システムへ統合できる処理、長期間使われていないプログラムがないかを確認します。
リホスト、リライト、リビルドのどれが適しているかを検討します。 既存資産を活かすのか、言語や基盤を刷新するのか、業務プロセスごと見直すのかによって、必要な体制やスケジュールが変わります。
代表的なプログラムや業務処理を選び、移行後の環境で問題なく動くかを検証します。 COBOLの仕様差、文字コード、外字、DBアクセス、帳票出力など、差異が出やすい部分は早めに確認しておきます。
プログラム、JCL、データ、帳票などを移行先環境に合わせて変換します。 自動変換できる部分と、個別修正が必要な部分を分けて進めることが大切です。
現行環境と移行後環境で同じ処理を実行し、結果が一致するかを確認します。 計算結果、データ更新、帳票出力、バッチ処理時間などを比較し、差異があれば原因を調査します。
見るべきなのは「動くか」だけではありません。 現行環境と同じ結果になるか、業務に使える性能が出るかまで確認します。 特に夜間バッチや大量データ処理は、移行後の処理時間が業務スケジュールに影響しないか注意が必要です。
切り替え手順、停止時間、切り戻し方法を決めたうえで本番移行を行います。 移行後は監視、障害対応、バックアップ、保守体制を整え、安定して運用できる状態を作ります。
ここでは、富士通メインフレーム上の既存プログラムを、AWS上で動かせる形へ移行した事例を紹介します。
富士通メインフレームは、金融機関や製造業など多くの企業で利用されている基幹システムです。 堅牢性と安定性が高く評価されていましたが、独自のハードウェアとソフトウェアに依存することで、システム更新が難しくなるという問題を抱えていました。
また、富士通が2030年に生産を終了し、2035年にはサポートを終了することを発表。 運用システムの見直しや、移行を検討しなくてはならなくなりました。
既存のCOBOL、アセンブラ、JCLといったプログラムをそのままAWS上で動かすことで、 現行資産を活かしながら、クラウドの柔軟性や運用効率を取り込める点がポイントです。 ただし、資産の棚卸し、PoC、結合テスト、本番切り替えまで、段階的な進行が欠かせません。
富士通メインフレームと同様に、IBMメインフレームも老朽化やサポート終了を背景に移行ニーズが高まっています。 ここでは、IBMメインフレームを長年利用していた金融グループ企業のリホスト事例を紹介し、富士通環境にも共通する課題と解決のヒントを整理します。
リホスト方式によるマイグレーションで、既存のCOBOL資産やジョブ定義を極力変更せずにオープン環境へ移行。 プロジェクトは3年にわたり、特に初期8カ月を棚卸しやPoCに充ててリスクを低減しました。
さらに、多様な言語で構成されていた資産をCOBOLへ統合し、将来的な保守体制の確保に配慮。 移行後の新システムは安定稼働を続けており、 夜間バッチ処理時間の短縮や資産削減など、運用効率が改善しました。
富士通メインフレームの移行は、通常のシステム更改よりも確認範囲が広くなります。 相談先を選ぶ際は、クラウド移行に対応しているかだけでなく、富士通系のレガシー資産をどこまで理解しているかを見ておきましょう。
リホストは有力な選択肢ですが、すべての企業に最適とは限りません。 既存資産を活かしたいのか、将来の保守性を高めたいのか、業務プロセスまで刷新したいのかによって、選ぶべき方式は変わります。 自社の環境に近い移行実績があるか、移行前の診断から移行後の運用まで見てくれるかは、相談先を比較するときに必ず確認しておきたいところです。
富士通メインフレームのマイグレーションは、企業にとって非常に重要かつ大規模なプロジェクトです。 成功させるためには、資産を正確に棚卸して、適切なアプローチをすることが大切です。
プログラム、ジョブ、データ、周辺システムの関係を整理し、移行対象と残す対象を明確にします。
リホスト、リライト、リビルドなどの方式を、コスト・期間・リスク・将来性の観点で比較します。
本番移行前に、処理性能、バッチ時間、業務継続性、データ整合性を確認しておきます。
専門知識とリソースが必要なため、 実績豊富なITベンダーに相談することで、知見や実績をもとにスムーズな移行をサポート してもらえます。
まずは現行資産の棚卸しから始めます。 COBOL、JCL、DB、帳票、画面、外字、運用手順、周辺システム連携を整理し、移行対象と残す対象を明確にします。 移行方式や移行先を決めるのは、その後です。
リホスト方式では、既存のCOBOL資産やジョブ定義を活かせる場合があります。 ただし、移行先環境に合わせた非互換調査、変換、個別修正、現新照合テストは必要です。 使えるかどうかは、資産の状態や移行先によって変わります。
クラウド移行は選択肢の一つです。 ただし、基幹システムでは性能、可用性、セキュリティ、運用監視、バックアップ、周辺連携まで含めて検討する必要があります。 クラウドへ移すこと自体よりも、移行後に安定して運用できる設計になっているかが重要です。
既存業務を大きく変えず、短期間でメインフレームから脱却したい場合はリホストが候補になります。 将来の保守性や技術者確保を重視する場合はリライト、業務プロセスから刷新したい場合はリビルドも検討します。 まずは資産棚卸しとPoCを行い、自社に合う方式を見極めるのが安全です。
資産棚卸し、方式選定、PoC、現新照合テストという流れは近い部分があります。 ただし、対象となるOS、DB、帳票、運用ツールは環境によって異なります。 本ページでは主に富士通メインフレームの移行を扱っています。
富士通メインフレームのマイグレーションは、単なるサーバー移行ではありません。 長年使われてきたCOBOL資産、JCL、DB、帳票、外字、運用手順まで含めて、業務を支えてきた仕組み全体を見直すプロジェクトです。 まずは現行資産を棚卸しし、移行対象とリスクを見える化すること。 そのうえで、複数の方式や相談先を比較し、自社に合う進め方を選ぶことが大切です。
富士通メインフレームの移行では、「何を残すか」「どこまで変えるか」「どの順番で移すか」によって、費用・期間・リスクが大きく変わります。 まずは現行資産を棚卸しし、複数の移行方式を比較することが重要です。
本メディアでは、マイグレーションサービスの提供内容を企業ごとに徹底調査しており、 「レガシーのオープン化」「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）