富士通メインフレーム撤退2026｜2030年販売・2035年保守終了とCOBOL移行の進め方・費用・失敗回避チェック

結論から言う。富士通メインフレームを使い続ける企業にとって、基幹システムの刷新はもはや「いつかやる課題」ではなく「期限の決まった課題」であり、しかも“早く決めた企業が有利になる椅子取りゲーム”になっている。 富士通は2022年2月14日の公式発表で、メインフレーム（GS21シリーズ）の販売を2030年度に終息し、保守サポートを2035年度末に終了すると公表した。会計・販売・生産・人事給与といった基幹業務をメインフレーム上のCOBOLで動かしている企業は、この期限までに移行を完了させなければ、保守が切れた基幹で事業を回すという極めて危険な状態に置かれる。

ただし本当の論点は「期限がいつか」ではない。期限は誰でも調べられる。差がつくのは、限られた移行ベンダーのキャパシティ・自社の人材・複数年かかる工程を、いつ・どの順で・誰の判断で押さえるかだ。この記事では、撤退スケジュールを一次情報で正確に押さえたうえで、移行方式の比較、費用と見積もりの読み方、移行を難しくする技術的な壁、そしてベンダー提案の“偏り”を見抜く第三者視点までを、失敗を避けたい意思決定者向けに整理する。

この記事の要点（先に結論）

• 富士通メインフレーム（GS21）は販売終息が2030年度、保守終了が2035年度末（＝2036年3月）。UNIXサーバ（SPARC）は販売終息2029年度・保守終了2034年度（2022年2月14日の富士通公式発表）。
• 移行方式は大きく4つ（リホスト／リライト／リビルド／パッケージ・SaaS）。「全システム一律」ではなく業務ごとに使い分けるのが現実解。
• 難所はCOBOLそのものより、文字コード・データ構造・JCL（ジョブ制御）の非互換にある。ここが費用と期間を膨らませる。
• 国内には富士通製メインフレームがまだ多数残り、移行を担えるベンダーのキャパシティは有限。期限直前に一斉に動くと、良いパートナーが取れず、価格交渉力も失う。
• リホストを勧める会社、パッケージを勧める会社、再構築を勧める会社は、それぞれ“売りたいもの”が違う。提案の偏りを見抜く第三者の目が、最初の分かれ道になる。

---

この記事を読むべき人

• 富士通メインフレーム（GS21、または旧FACOM／PRIMEFORCE系）で基幹業務を動かしている企業の経営者・役員。
• 情シス部門長、あるいは一人情シス・兼任情シスとして「移行の旗振り役」を任されそうな担当者。
• 「保守終了はまだ先」と社内で言われているが、逆算すると本当に間に合うのか不安を感じている実務決裁者。
• ベンダーから「リホストで大丈夫」「この機会にERPへ」と提案を受けているが、その言葉を鵜呑みにしていいか判断できない発注担当。

特に、社内にIT判断力が十分になく「技術的な新しさより、とにかく失敗を避けたい」という中堅・中小企業の意思決定者を想定して書いている。

---

富士通メインフレーム撤退の正確なスケジュール（一次情報で確認）

まず、数字を正確に押さえる。ここを曖昧にしたまま社内で議論すると、期限の解釈がずれて計画全体が甘くなる。富士通が2022年2月14日に公式発表した内容は次のとおりだ。

出典は富士通公式ニュース「メインフレーム／UNIXサーバの今後の方針」（2022年2月14日付）である。この発表をもって、富士通は1954年の国産初リレー式計算機からの流れをくむメインフレーム事業から段階的に退くことになり、報道では「66年の歴史に幕」（日経xTECH）とも表現された。

ここで絶対に混同してはいけないのが「販売終息」と「保守終了」の違いだ。

• 販売終息（2030年度）：新規の機器が買えなくなる。既存機で使い続けること自体は可能。
• 保守終了（2035年度末）：メーカーによる障害対応・部品供給・サポートの前提がなくなる。ここを越えて使い続けることは、事実上「壊れたら止まる基幹で事業を回す」ことを意味する。

つまり2035年度末は「最終リミット」であって「移行の目標時期」ではない。大規模なCOBOL資産（1システムで数十万〜100万ステップを超える例も珍しくない）の移行には数年単位を要するため、逆算すると多くの企業にとって「今」が着手の分水嶺になる。これは経済産業省がDXレポートで警鐘を鳴らした「2025年の崖」（レガシー放置による競争力低下・保守リスク）とも地続きの問題であり、期限が具体的な機器の保守終了として突きつけられた点で、より切迫している。

---

なぜ「まだ数年ある」が危険なのか：ベンダーキャパシティという見落とし

多くの記事は「期限まで数年、早く動こう」で終わる。だがGXOが最も重要だと考える論点は、そこではない。移行を担えるベンダーの供給量が有限だという構造問題だ。

日経xTECHの報道では、国内に稼働する富士通製メインフレームがまだ相当数残っており、業界内では「年間に撤廃・移行できる台数は限られる」との見方が示されている。富士通自身も関連会社を含めた体制で顧客の移行を支援するとしているが、残存台数に対して移行を実行できるエンジニアとプロジェクト枠は、どう見ても潤沢ではない。

これが意味するのは、次のことだ。

• 期限が近づくほど、移行案件が一斉に市場へ出る。 良いベンダー、COBOL・JCLが分かる技術者、検証環境の枠は先に埋まる。
• 後発になるほど価格交渉力を失う。 売り手市場では、相見積もりの余地も納期の融通も小さくなる。
• 「間に合わないから延命」という最悪手に追い込まれる。 期限直前で動くと、根本刷新の時間が取れず、割高な延命策しか選べなくなる。

早く動くべき本当の理由は「作業に時間がかかるから」だけではなく、「良い椅子（パートナー・人材・枠）が有限で、先に座った企業が勝つから」だ。この視点を持てるかどうかが、経営判断の質を分ける。自社の現在地と着手順序を客観的に見立てたい段階では、移行前の第三者診断で、社内で判断できる範囲と外部支援が要る範囲を切り分けておくと、後の交渉が有利になる。

---

移行が「容易ではない」本当の理由：COBOLより厄介な3つの壁

「COBOL技術者がいないから難しい」とよく言われるが、実務上さらに厄介なのは、COBOLそのものではなくメインフレーム特有の環境依存だ。ここは見積もりと期間を大きく左右するので、経営者も概念だけは知っておきたい。

1. 文字コードの壁（EBCDIC ⇔ ASCII/UTF-8）：メインフレームはEBCDICという文字コードを使う。オープン環境へ移すとソート順（並び順）が変わり、コード値でソートしていた処理の結果が変わる恐れがある。金額・日付・区分コードの並びが1つずれるだけで、帳票や締め処理が壊れる。
2. データ構造の壁（階層型・独自ファイル ⇔ リレーショナルDB）：メインフレームの順編成ファイルや階層型DBを、そのままRDBに置き換えると、アクセスの仕方が変わり性能問題（同じデータを何度も引く非効率など）が出やすい。データ移行は「入れ物を替える」だけでは終わらない。
3. JCL（ジョブ制御言語）の壁：夜間バッチの順序・条件分岐・リカバリを制御するJCLは、オープン環境のシェルスクリプトやジョブ管理ツールに“完全に等価”へ書き換えるのが難しい。ここの方針が決まらずにプロジェクトが頓挫する例は実際に起きている。

この3つは、いずれも「現行が何をしているか正確に分からない」と方針が決められない。だからこそ移行は、必ず**現行システムの棚卸し（可視化）**から始める。何が・どこで・どの順で動いているかを棚卸しできなければ、方式も費用も期間も見積もれない。棚卸しをスキップして方式を決めた案件ほど、後から追加費用と手戻りに苦しむ。棚卸しから設計・移行までを一気通貫で相談したいときは、レガシー刷新・移行の進め方を起点に整理するとよい。

---

移行方式の比較：リホスト／リライト／リビルド／パッケージ

基幹刷新のアプローチは大きく4つ。最適解は、現行資産の状態・予算・期限・将来戦略で変わる。「唯一の正解」を売り込んでくるベンダーには注意したい。

現実的には、全システムを一律にせず、業務ごとに方式を使い分ける。止められない中核はまずリホストで脱メインフレームし、周辺の定型業務はパッケージ／SaaSへ寄せ、競争力の源泉になる業務だけリビルドする、といった組み合わせだ。

リホストの「二重投資」に注意

リホストは「短期・低コスト・低リスク」と勧められやすい。だが忘れてはいけないのは、リホストは中身の複雑さをそのまま引き継ぐ延命策だという点だ。載せ替えただけでは属人化・ブラックボックスは解消せず、数年後に結局リライトやリビルドが必要になり、移行費を二度払うことになりかねない。リホストを選ぶなら、「リホスト後にどこを・いつ・どう作り替えるか」までロードマップに描いておく。ここを描かないリホスト提案は要注意だ。方式ごとの費用感やロードマップの考え方は、レガシーシステム刷新（2025年の崖以降）や、AS/400（IBM i）の段階移行ロードマップと費用感、SAPを検討する場合のSAP ERP 2027年問題とS/4HANA移行も併せて確認したい。

---

ベンダー提案の“偏り”を見抜く：誰が何を売りたいのか

方式選定で最初につまずくのは、技術ではなく**「相談先ごとに答えが違う」こと**だ。これは各社が悪意でやっているのではなく、得意分野＝売りたいものが違うから起きる。第三者の視点で整理すると、次の傾向がある。

どれも「間違い」ではないが、自社にとっての最適解と、ベンダーの売りたいものは一致するとは限らない。だからこそ、方式を決める前に「利害関係のない第三者の目」で自社の現状を診断し、選択肢をフラットに並べる工程が効く。GXOが発注前のシステム移行・再構築の相談で最初に行うのも、特定の方式を売り込むことではなく、現行資産に照らして「どの方式が・どの業務に・なぜ向くのか」を根拠付きで整理することだ。

---

費用と見積もりの読み方：金額の“幅”に惑わされない

基幹刷新の費用は、規模・方式・現行資産の複雑さで大きく変わり、案件差が非常に大きい。だから正直に言えば、「相場◯◯万円」と一律に断定できる領域ではない。数千万円で収まる案件もあれば、億単位に達する案件もある。重要なのは、金額そのものより「その見積もりが何を含み、どこで膨らむか」を読む力だ。

見積もりを受け取ったら、GXOは次の観点で“中身”を見ることを勧める。

• 棚卸し（現行分析）の費用が含まれているか：ここを省いた安い見積もりは、後で追加費用の温床になる。
• 文字コード・データ移行・JCL変換の扱いが明記されているか：前述の3つの壁が「別途見積もり」で外されていないか。
• 並行稼働・データ検証・切り戻しの費用が入っているか：本番切替は一発勝負にできない。検証と保険の費用が抜けていないか。
• 自動変換ツール利用の場合、変換後の可読性・保守性まで責任範囲か：機械変換しっぱなしで“読めないコード”を納品されると、以後の保守が地獄になる。
• 移行後の運用・保守・教育まで見えているか：初期費用だけでなく、走り出した後のランニングも含めて比較する。

見積もりは「合計金額の安さ」で選ぶと失敗する。含まれていない工程こそが、後の追加費用になるからだ。概算の当たりを付けたい段階では、業務システムの種類別の費用相場と予算の立て方や、委託先を見極めるシステム開発会社の選び方の判断基準が参考になる。人材・体制については、COBOLと現行業務を理解する人材が高齢化・減少し、移行を担うIT人材も不足しているため、自社だけで要員を揃えるのは現実的でない。外部パートナーとの共同体制を前提に、社内は「業務の意思決定」に集中する分担が現実解だ。

---

いつ動き出すべきか：保守終了2035年度末からの逆算

大規模な基幹刷新は、決して余裕のあるスケジュールではない。保守終了（2035年度末＝2036年3月）から逆算すると、次のようになる。

1. 現状把握（数か月〜）：現行システムの棚卸し・可視化、移行範囲の確定、現行の“生きた仕様”の掘り起こし。
2. 方式選定・計画（数か月）：4方式の適用設計、概算費用、体制設計、ベンダー選定。
3. 要件定義・設計（半年〜）：To-Be業務とシステム要件の確定、非互換（文字コード・DB・JCL）の対応方針決定。
4. 開発・移行（1〜数年）：データ移行、並行稼働、検証、切り替え。
5. 本番稼働・安定化：運用定着、現行システムの計画的廃止。

規模の大きい企業ほど、計画から本番まで数年を要する。ここに前述のベンダーキャパシティの逼迫が重なる。つまり「2035年度末に間に合わせる」逆算だけでは足りず、「良いパートナーと人材を確保できるうちに椅子を取る」逆算が要る。「保守終了はまだ先」ではなく「今動かないと選択肢が減る」と捉えるのが正しい。方式別の費用相場と段階的モダナイゼーションのロードマップを一枚で俯瞰したいなら、レガシー刷新・基幹移行の進め方（費用とロードマップ）がこの逆算の起点になる。

---

実際に起きる失敗パターン4選

期限が決まった移行案件では、同じ失敗が繰り返し起きる。事前に知っておくだけで避けられるものが多いので、代表的な4つを挙げる。

失敗1：棚卸しを飛ばして方式を先に決める。 「うちはリホストで」と方式から入ると、いざ現行を開けたときに文字コードやJCLの非互換が想定外に大きく、途中で費用が跳ね上がる。順序は必ず「棚卸し→方式」であって「方式→棚卸し」ではない。方式は現行資産を見てから決めるものだ。

失敗2：現行を語れる人が退職してから動き出す。 メインフレームの“生きた仕様”は、ドキュメントではなく人の頭の中にあることが多い。定年・異動でその人がいなくなってから移行を始めると、挙動を推測で復元するはめになり、期間もリスクも跳ね上がる。人が残っているうちに着手し、知識を移すのが最大のコスト削減策になる。

失敗3：安い見積もりに飛びついて、含まれない工程で追加請求される。 合計金額だけを見て発注すると、棚卸し・並行稼働・データ検証・切り戻し・移行後保守が「別途」で外されていて、最終的に当初の1.5倍、2倍になる。安さの正体は「含んでいないだけ」であることが多い。

失敗4：期限直前に一斉需要とぶつかり、良いパートナーが取れない。 前述のとおり移行ベンダーのキャパシティは有限だ。「まだ数年ある」と構えているうちに、実績あるベンダーの枠が埋まり、条件の悪い相手か割高な延命策しか選べなくなる。早く動く最大の理由はここにある。

これらはいずれも、着手前に「順序」と「見積もりの中身」と「タイミング」を押さえていれば避けられる。技術の問題である前に、意思決定の順序と時間配分の問題だ。

発注前チェックリスト（このまま社内会議に使える）

方式やベンダーを決める前に、以下を自社で埋められるか確認したい。埋まらない項目があるなら、それが最初に着手すべき論点だ。

• 対象となる基幹業務（会計・販売・生産・人事など）と、移行する／しない範囲を明文化しているか
• 現行COBOL資産の規模（本数・ステップ数）と、直近数年の改修頻度を把握しているか
• 現行の“生きた仕様”を語れる人が社内に何人残っているか、退職予定はいつかを確認したか
• 文字コード（EBCDIC）・データ構造・JCLの非互換に、見積もりが触れているか
• 移行方式を「1つ」に決め打ちせず、業務ごとの使い分けを検討したか
• リホストを選ぶ場合、リホスト後の作り替えロードマップまで描いているか
• 見積もりに、棚卸し・並行稼働・データ検証・切り戻し・移行後保守が含まれているか
• 提案ベンダーの「売りたいもの」と自社の最適解が一致しているか、第三者の目で検証したか
• 相見積もりを取り、金額の合計だけでなく「含まれる工程」を並べて比較したか
• 社内で判断できる範囲と、外部支援が必要な範囲を切り分けているか
• 経営会議に、期限・リスク・費用・体制を1枚で説明できる資料があるか
• 次の90日で「決めること」と「まだ決めないこと」を仕分けしているか

---

放置した場合と、早く整理した場合の違い

---

GXOの見解：勝負は「発注前の整理」で8割決まる

基幹刷新の成否は、開発会社選びの前段階、すなわち業務要件・現行資産・非互換・段階移行をどこまで整理できたかでほぼ決まる、というのがGXOの一貫した見立てだ。棚卸しと要件整理を飛ばして「まず方式・まずベンダー」と走った案件ほど、後で追加費用と手戻りに苦しむ。

GXOが重視するのは、話題性の高さよりも「自社の業務・データ・権限・予算・運用責任にどう影響するか」だ。富士通メインフレーム撤退という同じニュースでも、企業ごとに現行資産も残存人材も期限までの余裕も違う。だからこそ、担当者だけで判断を閉じず、経営・現場・情シス・外部パートナーの役割を早い段階で分け、特定ベンダーの提案に寄りかからない第三者の視点で選択肢を並べることが、最初の分かれ道になる。GXOは、現行棚卸し・要件定義・RFP設計から、リホスト／リライト／リビルドの実装、移行後の運用・保守までを、特定製品を売るためではなく「自社にとっての最適解」を組むために接続して支援する。移行と並行してデータ活用の土台を作りたい場合はデータ活用基盤の構築、レガシー刷新に特化した進め方はレガシーシステム刷新も参照してほしい。

---

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、方式やベンダーを決める前に、いちど第三者の整理を挟むことを勧める。

• ベンダーから提案は来ているが、「その方式で本当にいいのか」を判断できる材料が社内にない。
• 現行システムの仕様を語れる人が退職間近で、今のうちに知識を残したい。
• 「リホストで延命」と言われたが、数年後にまた作り替えるのではと不安がある。
• 相見積もりを取ったが、金額の差が大きすぎて、何が違うのか読み解けない。
• そもそも何から手をつければいいか分からず、社内で議論が止まっている。

「構想段階の相談だけ」でも問題ない。むしろ、方式を決める“前”ほど、第三者の整理が効く。

---

よくある質問（FAQ）

Q1. 富士通メインフレームの保守はいつまで使える？

2022年2月14日の富士通公式発表によれば、GS21の保守サポート終了は2035年度末（2036年3月）だ。販売終息（2030年度）とは別で、保守期間中は使い続けられる。ただし保守終了後は障害時のメーカーサポートの前提がなくなるため、それより前に移行を完了させておくのが実務上の必須条件になる。

Q2. とりあえずリホストで延命するのはあり？

期限が近く、まず脱メインフレームを優先したい場合の有力な選択肢だ。ただしリホストは業務ロジックの複雑さをそのまま持ち越す延命策であり、根本的な刷新は別途必要になる。「リホスト後にどこを・いつ・どう作り替えるか」まで描けていれば有効、描けていなければ二重投資のリスクが高い、と考えたい。

Q3. COBOL人材が社内にいなくても移行できる？

可能だが、現行業務とCOBOL資産・JCL・データ構造を理解する工程は避けて通れない。社内に人材がいない場合は、現行解析からモダナイゼーションまで担える外部パートナーと共同で進めるのが現実的だ。むしろ、現行を語れる人が社内に残っているうちに知識を移転することが、成否を分ける。

Q4. 自動変換ツールでCOBOLをJavaに変えれば安く早く済む？

ツールは工数削減に役立つが、機械変換しっぱなしだと“COBOLの構造を引きずった読めないJava”が生成され、その後の保守で苦しむことがある。変換率だけでなく「変換後のコードの可読性・保守性まで誰が責任を持つか」を、見積もり段階で必ず確認したい。

Q5. 費用はどのくらいかかる？

現行資産の規模・複雑さと移行方式によって大きく変わり、一律の相場を示すのは難しい。数千万円から億単位まで開きがある。重要なのは合計金額よりも、棚卸し・非互換対応・並行稼働・検証・移行後保守まで含んだ“総額”で比較することだ。まずは現状把握と、自社前提に沿った概算から始めたい。

Q6. UNIXサーバ（SPARC）も同じ期限？

いいえ。同じ2022年2月14日の発表で、UNIXサーバ（SPARC）は販売終息2029年度・保守終了2034年度と、メインフレームより1年早い期限になっている。UNIXサーバも併用している企業は、両方の期限を並べて計画したい。

---

まとめ：期限が決まった今こそ、棚卸しと第三者整理から

富士通メインフレーム（GS21）の販売終息は2030年度、保守終了は2035年度末。期限が確定した以上、基幹システムの刷新は先送りできない。そして本当のリスクは「作業に時間がかかる」ことだけでなく、「良いパートナー・人材・移行枠が有限で、先に動いた企業が有利になる」ことにある。判断を遅らせるほど、選択肢も交渉力も減る。

やるべき最初の一手は、派手な方式選定でもベンダー選定でもない。現行システムの棚卸しと、特定ベンダーに寄らない第三者の整理だ。ここが固まれば、方式も費用も交渉も、格段に読みやすくなる。GXOは、現行資産の可視化から移行方式の選定、COBOL資産のモダナイゼーション、移行後の運用・保守まで、自社にとっての最適解を組む立場で伴走する。「何がどこで動いているか分からない」段階からの相談を歓迎する。

---

参考情報（一次・公式ソース）

• 富士通株式会社 公式ニュース（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/
• 日経xTECH「富士通製メインフレームが残り700台の衝撃、保守期限までの撤廃に求められる策」（残存台数・移行キャパシティの課題／二次情報）：https://xtech.nikkei.com/atcl/nxt/column/18/00138/040401502/
• 経済産業省「DXレポート」（いわゆる「2025年の崖」の問題提起）：https://www.meti.go.jp/shingikai/mono_info_service/digital_transformation/20180907_report.html

関連記事

• レガシーシステムのモダナイゼーション（2025年の崖以降）
• IBM i／AS400モダナイゼーションのコストとロードマップ
• SAP ERP 2027年問題とS/4HANA移行
• システム開発会社の選び方
• 種類別のシステム開発費用と相場