富士通はメインフレーム「GS21シリーズ」の販売を2030年度に終了し、保守サービスも2035年度末に終了する予定です。移行は要件定義からテスト・並行稼働まで数年単位になることがあるため、COBOL資産やJCL、文字コード、DB構造などを早めに整理する必要があります。選択肢にはリホスト、リライト・リビルド、パッケージ導入があり、自社の予算や将来構想に合わせて検討します。
富士通が示す2035年度の保守終了は、移行を始める期限ではなく、移行と安定化を終えておきたい最終期限です。現行資産の調査、PoC、開発・変換、現新照合、並行稼働に必要な期間を差し引き、自社がいつまでに方式と予算を決めるべきかを逆算しましょう。
かつて国産コンピュータの代名詞として、日本の金融、行政、製造、流通などの基幹業務を支えてきた富士通のメインフレーム。富士通は2022年、メインフレームおよびUNIXサーバーについて、販売終息と保守終了の方針を発表しました。
長年安定稼働してきたシステムほど、業務ロジック、データ、ジョブ、帳票、運用手順が密接に結びついています。そのため、移行は単なるサーバー交換では終わりません。
「保守が終わるまで、実際にはどれくらい猶予があるのか」「膨大なCOBOL資産を残すべきか、書き換えるべきか」「移行の見積もりを、何を基準に評価すればよいのか」。本記事では、富士通の発表内容をもとに、移行方式の選び方、技術的な論点、社内で決めるべき事項を解説します。
2035年度まで保守が続くとしても、同年度まで現状維持できるとは限りません。自社が利用する機種、周辺製品、ソフトウェア、保守契約によって期限は異なります。
最初に必要なのは、移行製品を選ぶことではなく、現行資産と個別のサポート期限を棚卸しし、業務停止を避けるための移行完了時期を決めることです。
現状維持と移行、それぞれの費用・リスクを比較する
残す資産、廃止する資産、作り直す業務を分ける
本番切替から逆算し、調査・PoC・テスト期間を確保する
全社共通の「2035年」だけを見るのではなく、自社の機器・ソフトウェア・保守契約ごとの期限を確認する必要があります。
| 対象 | 販売終息 | 保守終了 | 企業側で確認すること |
|---|---|---|---|
| メインフレーム | 2030年度 | 2035年度 | 利用機種、OS、ミドルウェア、周辺装置、個別の保守契約 |
| UNIXサーバー | 2029年度 | 2034年度 | SPARC製品の型名、購入時期、オプション装置、保守終了年月 |
※各製品の販売・保守状況は変更される可能性があります。自社が使用している型名と契約条件を、富士通または保守事業者へ個別に確認してください。
基幹システムの移行には、現行資産の調査、移行方式の比較、PoC、要件定義、設計、変換・開発、テスト、データ移行、利用部門の教育、本番切替、安定化といった工程があります。
さらに、新旧システムを一定期間並行稼働させる場合や、複数の周辺システムを段階的に切り替える場合には、移行後の安定化まで数年単位になることもあります。
たとえば、本番切替後に1年間の安定化期間が必要で、その前に開発・テストで3年、調査・PoC・予算化で2年かかるなら、遅くとも保守終了の6年以上前には具体的な検討を進める必要があります。大規模システムでは、さらに長い期間を見込む場合があります。
富士通の方針は、メインフレームだけでなくUNIXサーバーにも及びます。ただし、個々のSPARC製品では型名や購入時期によって、販売終了・保守終了時期が異なります。
「UNIXサーバーは2034年度まで大丈夫」と一括りにせず、サーバー本体、CPU、メモリ、ディスク、周辺装置、OS、ミドルウェアを含めて、どこが最初に保守切れを迎えるのかを確認しましょう。
オープン系サーバーやクラウドの普及により、企業システムの選択肢は大きく変わりました。専用ハードウェアを長期間維持する事業環境が変化する一方、ユーザー企業ではCOBOL、JCL、独自データ形式などを理解する技術者の高齢化が進んでいます。
問題は「COBOLを書ける人が減ること」だけではありません。障害時の判断、月次・年次処理、例外時の復旧、関連部門との調整など、システムを業務として動かすための知識が失われることが、より大きなリスクです。
富士通メインフレームからの移行は、リホスト、リライト、リビルド、クラウド移行など、選ぶ方式によって必要な技術や外注先が変わります。
COBOL資産、JCL、文字コード、DB構造、帳票、外字などの課題が絡む場合は、単に「マイグレーション対応」と掲げる企業ではなく、自社と近い環境・規模・目的の移行実績を持つ企業を比較することが重要です。
本メディアでは、マイグレーションサービスを提供する企業を調査し、「レガシーのオープン化」「AWSへの移行と運用」「大規模システムへの移行」の3タイプ別に紹介しています。
方式は「新しい技術かどうか」ではなく、期限、業務変更の許容度、現行資産の解析状況、将来の改修計画から選びます。
| 方式 | 主な目的 | 向いている状況 | 移行後に残る課題 |
|---|---|---|---|
| リホスト | 期限と業務継続を優先して基盤を変更 | 現行ロジックを大きく変えられない | 複雑な構造やCOBOL人材への依存が残る可能性 |
| リライト・リビルド | 言語、構造、保守体制を刷新 | 将来の改修性や外部連携を重視する | 要件漏れ、品質、工期、再現テストの負担 |
| パッケージ・SaaS | 業務を標準化し、個別開発を減らす | 標準機能に合わせて業務を変更できる | 現場調整、データ移行、追加開発の抑制 |
既存のCOBOLプログラムや業務ロジックをできるだけ維持し、稼働基盤をオープン系サーバーやクラウドへ移す方法です。利用者の操作や業務フローを大きく変えずに移行しやすく、期限への対応を優先する場合に検討しやすい方式です。
リホスト後もCOBOL、JCL、独自データ構造が残る場合、その保守体制を誰が担うかを決める必要があります。リホストを最終到達点にするのか、次の刷新までの段階移行にするのかも、最初に明確にしましょう。
リライトは既存ロジックを解析し、JavaやC#などの別言語へ書き換える方法です。リビルドは現行仕様を参考にしつつ、要件や構造から再設計します。将来の改修性、クラウド連携、開発体制の変更まで視野に入れる場合の選択肢です。
変換ツールや生成AIでコードを変換できても、業務結果、性能、例外処理、運用性まで自動的に保証されるわけではありません。変換後のコードを自社や保守会社が理解・修正できるか、現新照合をどこまで実施するかをPoCで確認します。
既存のスクラッチシステムをERPやSaaSへ置き換え、標準機能に合わせて業務プロセスを変更する方法です。個別開発を減らし、製品側の更新や制度対応を活用しやすくなります。
現行業務に合わせて大量のアドオンや個別開発を行うと、導入後も複雑さが残ります。競争力に直結する業務は個別システムとして残し、一般的な管理業務は標準機能へ合わせるなど、領域ごとの使い分けも検討しましょう。
期限が迫る領域はリホスト、競争力に直結する領域はリライト・リビルド、標準化できる管理業務はSaaSというように、業務単位で方式を分ける方法もあります。その場合は、データ連携、認証、監視、障害時の責任分界を横断的に設計する必要があります。
プログラムが動くだけでは移行完了とはいえません。データ、処理結果、性能、運用まで現行と比較する必要があります。
メインフレームではEBCDIC系の文字コードや、富士通環境固有の日本語文字、外字が使用されている場合があります。オープン系ではASCIIやUTF-8などが一般的であるため、移行時にはデータ変換が必要です。
注意したいのは、文字化けだけではありません。文字の並び順、固定長データの長さ、符号付き数値、ゾーン形式・パック形式、空白や制御文字の扱いが変わると、検索、集計、突合、帳票出力の結果に影響します。
メインフレームでは、固定長・可変長のレコード形式や、業務に最適化されたデータアクセスが使用されています。これをオープン系のファイルやRDBへ単純に置き換えると、読み取り回数やSQL発行回数が増え、処理時間が延びることがあります。
特に夜間バッチでは、個々の処理が少し遅くなるだけでも、後続ジョブの開始時刻や翌朝の業務開始に影響します。機能の一致だけでなく、ピーク時のデータ量、バッチウィンドウ、同時実行数を前提に性能を確認しましょう。
JCLは、プログラムの実行順序だけでなく、データセット、実行条件、異常終了時の処理、再実行など、業務運用と密接に関係しています。そのため、COBOLプログラムを変換できても、JCLや運用設計が残っていれば本番業務は動かせません。
オープン系では、シェルスクリプト、ジョブ管理製品、クラウドサービスなどを組み合わせて置き換えます。どの製品を使うかだけでなく、ジョブの依存関係、排他制御、異常終了、途中再開、監視、通知をどう再現するかを整理する必要があります。
正常系の単純なプログラムだけでは、移行難易度を正しく判断できません。大量データ処理、外字、複雑なJCL、外部連携、異常時リカバリーなど、差異が出やすい資産を意図的に選んで検証しましょう。
DXを掲げるだけでは移行の目的が曖昧になります。移行後に何を速く、安く、安全に変えられるようにしたいのかを定義しましょう。
現行維持と移行を比較する際は、ハードウェア保守費だけでなく、ソフトウェア、設備、運用、障害対応、人材確保、将来の更改費用まで含めて整理します。
クラウドへ移行しても、常時稼働する大規模処理、データ転送、監視、バックアップ、セキュリティ対応によっては費用が増える場合があります。クラウド化そのものをコスト削減策と決めつけず、現行と移行後の条件をそろえて比較することが重要です。
オープン化によってAPI連携やデータ活用を進めやすくなる可能性があります。ただし、「AIを使えるようにする」「開発を高速化する」だけでは、投資判断に必要な目的としては不十分です。
受注情報を経営判断へ早く反映したい、顧客データを営業支援システムと連携したい、制度変更への対応期間を短縮したいなど、改善対象となる業務と測定指標を明確にしましょう。
現行システムに詳しい担当者は、設計書に残っていない業務ルールや例外処理を把握しています。一方、オープン系やクラウドに詳しい担当者は、新環境の設計や運用を担います。
どちらか一方だけで進めると、現行業務の見落としや、新環境での過剰な再現が起こりやすくなります。現行担当者、業務部門、新環境の技術者、プロジェクト責任者が、調査段階から共同で判断できる体制をつくりましょう。
ハードウェア、OS、ミドルウェア、COBOL、JCL、DB、ファイル、帳票、外字、周辺連携、運用手順を整理します。個別の販売・保守終了時期も確認します。
止められない業務、標準化できる業務、廃止できる処理、競争力に直結する機能を分けます。
初期費用だけでなく、期間、テスト、移行後の運用、人材、残存リスク、将来の改修性まで比較します。
文字コード、外字、大量バッチ、複雑なJCL、DBアクセス、帳票など、差異が発生しやすい対象を使って検証します。
一括移行だけでなく、業務単位の段階移行も比較します。本番切替の判定基準、並行稼働期間、障害時の切り戻し方法を定めます。
社内稟議、予算化、方式選定、見積もり、ベンダー比較で論点になりやすい質問をまとめました。
待てるかどうかは、メーカーの最終期限ではなく、自社の移行所要期間と現行リスクで判断します。担当者の退職、個別製品の保守終了、部品調達、周辺システムの更改が先に問題になる場合もあります。
まず、調査・予算化・PoC・開発・テスト・並行稼働に必要な期間を概算し、保守終了から逆算してください。すぐに本番移行を始めなくても、資産棚卸しと難易度調査は早期に着手する価値があります。
「古いから刷新したい」ではなく、現状維持した場合の事業リスクとして説明します。保守終了、人材不足、障害復旧、制度変更への対応期間、セキュリティ、維持費を具体化します。
そのうえで、現状維持、延命、段階移行、全面刷新の費用とリスクを比較します。移行効果も、抽象的なDXではなく、改修期間、障害対応時間、運用工数、データ提供時間など、測定できる項目に落とすと判断しやすくなります。
概算は可能ですが、調査前の見積もりには大きな不確実性があります。ソース本数だけでは、JCL、データ、帳票、外字、周辺連携、手作業、テストケースの工数を判断できません。
最初から移行全体を固定価格で依頼するのではなく、現行調査・資産棚卸しを独立したフェーズとして実施し、その結果をもとに方式と本見積もりを確定する進め方が現実的です。
変換率の定義を確認してください。コンパイルできた割合なのか、自動変換された行数なのか、業務テストまで完了した割合なのかで意味が異なります。
変換できない資産、手修正の量、変換後コードの可読性、性能、JCL・DB・帳票の対応、品質保証の責任範囲を確認します。代表的な資産を使ったPoCで、実際の修正工数とテスト結果を測ることが重要です。
目的と次の計画が明確なら、必ずしも先送りではありません。サポート終了への対応を優先して基盤を移し、その後に業務単位でリライトやSaaS化を進める段階戦略も考えられます。
ただし、リホスト後に残るCOBOL、JCL、データ構造、運用知識を誰が保守するか、次の刷新をいつ判断するかを決めずに進めると、別の環境で同じ課題を抱える可能性があります。
対象資産、移行方式、データ移行回数、テスト範囲、性能保証、並行稼働、切り戻し、教育、移行後支援をそろえます。対象外項目と追加費用が発生する条件も確認してください。
価格だけでなく、前提条件の明確さ、富士通環境の実績、調査・PoCの方法、問題発生時の責任分界、成果物の引き渡し範囲まで比較する必要があります。
富士通が示しているのは、メインフレームが2030年度に販売終息、2035年度に保守終了、UNIXサーバーが2029年度に販売終息、2034年度に保守終了という方針です。
ただし、自社の判断期限は、個別製品の保守状況、資産規模、業務重要度、移行方式によって異なります。最初に行うべきことは、製品を決めることでも、全面刷新を決断することでもありません。
現行資産とサポート期限を棚卸しし、難易度の高い箇所をPoCで確認したうえで、現状維持・段階移行・全面刷新を比較できる状態をつくることが、移行プロジェクトの出発点です。
移行方式によって、必要となる技術、体制、外部パートナーは異なります。自社の環境に近い実績があるか、現行調査やPoCから相談できるかを確認しましょう。
ここではマイグレーションサービスのプロジェクト実績が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）