結論から言う。富士通メインフレームを使い続ける企業にとって、基幹システムの刷新はもはや「いつかやる課題」ではなく「期限の決まった課題」になった。 富士通は2022年（日経xTECHが2月10日に報じ、富士通公式は2月14日に発表）、メインフレーム（GS21シリーズ）の販売を2030年度に終息し、保守サポートを2035年度末に終了すると公表した（製造・販売からの撤退として広く報じられている）。会計・人事給与・生産管理といった基幹業務をメインフレーム上のCOBOLで動かしている企業は、撤退・保守終了までに移行を完了させる必要がある。
本記事では、撤退スケジュールを正確に押さえたうえで、移行方式の比較、費用と体制、人材の手当てまでを、刷新の意思決定者向けに整理する。
この記事の要点
- 富士通メインフレームは製造・販売が2030年度、保守が2035年度末に終了（2022年2月公表）。
- UNIXサーバも販売終息が2029年度、保守終了が2034年度。
- 移行方式は大きく4つ（リホスト／リライト／リビルド／パッケージ・SaaS）。
- 期限が決まっている以上、判断を遅らせるほど選択肢と交渉力が減る。
富士通メインフレーム撤退の正確なスケジュール
富士通は、1964年発売の「FACOM 230シリーズ」に始まるメインフレーム事業から撤退する（1964年から2030年度の撤退完了まで約66年の歴史になる）。2022年2月に公表されたスケジュールは次のとおりだ。
| 対象 | 販売終息 | 保守サポートの終了 |
|---|---|---|
| メインフレーム（GS21） | 2030年度 | 2035年度末 |
| UNIXサーバ | 2029年度 | 2034年度 |
※富士通公式は「販売終息」と表現している。製造・販売からの撤退として報じられている（日経xTECH等）。
ポイントは、「製造・販売の終了」と「保守の終了」は別だということだ。製造・販売が終わっても保守期間中は使い続けられるが、保守が切れた後は、メーカーの通常保守・サポートを前提とした運用ができなくなる可能性が高い。2035年度末という保守終了は「最終的なリミット」であって、実務上はそれより前に移行を終えておく必要がある。
膨大なCOBOL資産（大規模なものでは1システムで数十万ステップを超える例もある）の移行には数年単位の期間がかかる。逆算すると、多くの企業にとって2026年は「もう動き出すべき」タイミングだ。これは経済産業省が警鐘を鳴らしてきた「2025年の崖」（レガシーシステムの放置による競争力低下・保守リスク）とも地続きの問題である。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
なぜ移行は「容易ではない」のか
メインフレーム上のアプリケーションの多くはCOBOLで書かれ、長年の改修で複雑化・属人化している。移行が難しい主な理由は次の3つだ。
- ブラックボックス化：仕様書が古く、現行の挙動を正確に把握できる人材が退職・高齢化している。
- 規模の大きさ：基幹業務は会計・販売・生産・人事など広範で、相互に連携している。
- 止められない：基幹システムは事業の根幹であり、移行中も業務を止められない。
だからこそ、移行は「現行システムの棚卸し」から始める必要がある。何が・どこで・どう動いているかを可視化しないと、移行方式も費用も見積もれない。自社の現在地は基幹システム（ERP）刷新レディネス診断やIBM i／レガシー基盤のモダナイゼーション診断で測れる。
移行方式の比較：リホスト／リライト／リビルド／パッケージ
基幹システムの刷新には、大きく4つのアプローチがある。どれが最適かは、現行資産の状態・予算・期限・将来戦略によって変わる。
| 方式 | 概要 | 向くケース | 留意点 |
|---|---|---|---|
| リホスト（移送） | COBOL資産をできるだけ活かし、オープン環境へ載せ替える | 期限が近く、まず脱メインフレームを優先したい | 中身の複雑さは残り、根本的な刷新は後回しになる |
| リライト（書き換え） | COBOLをJava等へ書き換える | 言語を刷新しつつ業務ロジックは維持したい | 大規模だと工数・コストがかさむ |
| リビルド（再構築） | 業務を見直し、新規にスクラッチ開発する | 業務プロセスごと変革したい | 期間・費用・リスクが最も大きい |
| パッケージ／SaaS | ERPパッケージやクラウドサービスへ移行する | 標準業務に寄せられる、保守負担を減らしたい | 既存業務をパッケージに合わせる必要がある |
多くの企業は、全システムを一律ではなく、業務ごとに方式を使い分けるのが現実的だ。例えば、止められない基幹はまずリホストで脱メインフレームし、周辺はパッケージ／SaaSへ寄せる、といった組み合わせである。
移行方式や費用感の考え方はレガシーシステムのモダナイゼーション（2025年の崖以降）やIBM i／AS400モダナイゼーションのコストとロードマップで詳説している。基幹の選択肢としてSAPを検討する場合はSAP ERP 2027年問題とS/4HANA移行も併せて確認したい。
費用と体制、そして人材の壁
基幹システムの刷新は、規模・移行方式・現行資産の複雑さによって費用が大きく変わり、案件差が非常に大きい。一般的な相場として断定できる金額はなく、正確な見積もりは現行資産の棚卸しと要件定義を経て初めて出せる。まずは自社の前提に沿った概算から把握したい。おおよその開発費の目安は60秒でわかる開発費の概算（見積シミュレーション）で確認できる。
費用と並んで深刻なのが人材だ。COBOLや現行業務を理解する人材は高齢化・減少しており、一方で移行を担うIT人材も全国的に不足している。自社だけで移行要員を揃えるのは難しく、外部パートナーとの共同体制が現実的になる。委託先を見極める観点はシステム開発会社の選び方が参考になる。
メインフレーム撤退、刷新の進め方を一緒に整理しませんか
GXOでは、現行システムの棚卸しから移行方式の選定、COBOL資産のモダナイゼーション、基幹刷新の設計・開発まで一貫して支援します。「何から手をつければいいか分からない」段階からのご相談を歓迎します。
※ 営業電話はしません ｜ オンライン対応可 ｜ 構想段階の相談だけでもOK
いつ動き出すべきか：逆算スケジュール
保守終了（2035年度末）から逆算すると、大規模な基幹刷新は決して余裕のあるスケジュールではない。
- 現状把握（数か月〜）：現行システムの棚卸し・可視化、移行範囲の確定。
- 方式選定・計画（数か月）：リホスト/リライト/リビルド/パッケージの選定、概算費用、体制設計。
- 要件定義・設計（半年〜）：To-Be業務とシステム要件の確定。
- 開発・移行（1〜数年）：データ移行、並行稼働、切り替え。
- 本番稼働・安定化：運用定着、現行システムの廃止。
規模の大きい企業ほど、計画から本番まで数年を要する。「保守終了はまだ先」と捉えるのではなく、逆算すると今が着手のタイミングだと考えたい。
実務判断のポイント
この記事を読むべきなのは、経営者、情シス、業務責任者、発注担当です。単に情報を把握するだけでなく、要件定義、RFP作成、見積比較、レガシー刷新、業務システム再構築の相談に進めるべきかを判断するための材料として整理する必要があります。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。富士通メインフレーム撤退と基幹システム刷新2026｜2030年度終了・COBOL移行の進め方と費用に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの見解
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、要件整理から開発、保守、段階移行ロードマップへ接続。さらに、標準ヒアリングと既存診断を使い、発注前相談から開発案件へ展開。
相談につながる進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問（FAQ）
Q1. 富士通メインフレームの保守はいつまで使える？
2022年2月の発表によれば、保守サポートの終了は2035年度末だ。製造・販売の終了（2030年度）とは別で、保守期間中は使い続けられる。ただし保守終了後は障害時のサポート保証がなくなるため、それより前の移行完了が望ましい。
Q2. とりあえずリホストで延命するのはあり？
期限が近く、まず脱メインフレームを優先したい場合の有力な選択肢だ。ただしリホストは業務ロジックの複雑さをそのまま持ち越すため、根本的な刷新は別途必要になる。将来戦略と合わせて、リホスト後の道筋まで描いておきたい。
Q3. COBOL人材がいなくても移行できる？
可能だが、現行業務とCOBOL資産を理解する工程は避けて通れない。社内に人材がいない場合は、現行解析からモダナイゼーションまでを担える外部パートナーと共同で進めるのが現実的だ。
Q4. 費用はどのくらいかかる？
現行資産の規模・複雑さと移行方式によって大きく変わり、案件差が非常に大きいため、一律の相場を示すのは難しい。まずは現状把握と、自社前提に沿った概算から始めたい。目安は見積シミュレーションで確認できる。
まとめ：期限が決まった今こそ、棚卸しから
富士通メインフレームの販売終息は2030年度、保守終了は2035年度末。期限が確定した以上、基幹システムの刷新は先送りできない。判断を遅らせるほど、選択肢も交渉力も減りやすい。まずは現行システムの棚卸しと移行方式の検討から動き出したい。
GXOは、レガシー基幹のモダナイゼーションを、現状把握から移行・本番稼働まで伴走支援している。サービスの詳細はレガシーシステム刷新・DX/システム開発の全体像・データ活用基盤構築をご覧いただきたい。
まずは現行システムの棚卸しから始めませんか
「何がどこで動いているか分からない」状態でも問題ありません。現行資産の可視化から移行方式の選定、費用感の提示まで、貴社の状況に合わせて整理します。
参考情報
- 富士通株式会社 公式ニュース（2022年2月14日付）「メインフレーム／UNIXサーバの今後の方針」：https://info.archives.global.fujitsu/jp/news/2022/02/14-1.html （メインフレーム製造・販売は2030年度、保守は2035年度末に終了。UNIXサーバは製造・販売が2029年度、保守が2034年度に終了）
- 富士通株式会社 メインフレーム（GS21）公式情報「富士通からの3つのお約束」：https://www.fujitsu.com/jp/products/computing/servers/mainframe/gs21/topics/fujitsu-3promise.html
- 日経xTECH「富士通がメインフレーム製造・販売から2030年度に完全撤退へ、66年の歴史に幕」（2022年2月の発表を報道）：https://xtech.nikkei.com/atcl/nxt/column/18/00001/06546/
- 経済産業省「DXレポート」（いわゆる「2025年の崖」に関する問題提起）：https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html
