富士通メインフレームの保守終了はいつ？2035年問題と移行の進め方を解説
富士通は、メインフレーム（GS21シリーズ）の製造・販売を2030年度末に終了し、保守を2035年度末で終える方針を公表しています。「2035年まで、まだ10年近くある」と感じるかもしれません。しかし基幹システムの移行には、現状把握から方式選定、開発、テスト、並行稼働まで数年単位の時間がかかるのが一般的。つまり2035年は「使い続けられる期限」ではなく、「移行を終えていなければならない期限」と捉えるのが現実的です。本記事では、保守終了スケジュールを整理したうえで、2035年から逆算した移行タイムライン、他社の進め方と社内の通し方、リホスト・リライト・リビルドといった手法の違い、そしてCOBOL/PL/I資産を活かす移行の考え方までを、判断材料として順に解説します。結論を先に言えば、いま計画的に動き出せば、移行は十分に間に合います。
目次
富士通メインフレームの現状：撤退・保守終了のスケジュール
富士通はすでに、メインフレームを終了する具体的なスケジュールを公表しています。あわてる必要はありませんが、先送りもできません。冷静に判断するために、まずは基礎知識と公式スケジュール、そして保守終了で実際に何が起きるのかを、順に押さえておきましょう。
富士通メインフレームとは
富士通メインフレームは、GS21シリーズに代表される、大型の基幹業務向けコンピュータです。その歴史は古く、1964年に発表された「FACOM 230シリーズ」を起源として、半世紀以上にわたり金融・公共・製造・流通といった分野の基幹業務を支えてきました。現行のGS21シリーズは、長年蓄積された業務ロジックを高い信頼性で処理し続ける、社会基盤の中核を担うプラットフォームです。
その一方で、高い安定性ゆえに「動いているものは変えない」という判断が重なりやすく、システムが長期にわたって塩漬け状態になりやすい、という側面も併せ持っています。長く使えることは大きな強みである反面、いざ移行を迫られたときに、蓄積された複雑さが重い課題としてのしかかる。この二面性を理解しておくことが、これからの判断の出発点になります。
なお、GS21シリーズには複数の機種があり、稼働しているOSやミドルウェア、データベースの構成も企業ごとに異なります。自社がどの機種・どの構成を使っているかによって、移行の難易度や取り得る手段は変わってきます。まずは「自社の足元がどうなっているか」を具体的に把握することが、その後のすべての判断の前提になります。
販売終了2030年度・保守終了2035年度末：公式スケジュール
富士通は2022年2月、メインフレームおよびUNIXサーバーの製造・販売を終了し、その後の保守サポートも段階的に終えていく方針を公表しました。メインフレームについては、2030年度末をもって製造・販売を終了し、2035年度末に保守サポートを終了する予定とされています。
これは、2030年度末以降は新規の導入や増設ができなくなり、2035年度末を過ぎるとメーカーによる保守そのものが受けられなくなる見込み、ということを意味します。あわせて、関連するOSやミドルウェア、周辺サービスにも順次終了時期が設定されているため、自社が利用している構成ごとに、正確な期限を一度棚卸ししておくことが欠かせません。「全体でいつまで」という大枠だけでなく、「自社の構成でいつまで」を押さえることが、計画の精度を左右します。
こうした関連製品が連携して一つの業務を支えている場合、どれか一つの期限に引きずられて、全体の移行スケジュールが前倒しになることもあります。関連する製品の期限をまとめて一覧にし、もっとも早い期限を基準に計画を立てておくと、後手に回りにくくなります。
保守終了で何が起きるのか
保守終了がもたらす影響は、「ある日突然システムが止まる」という単純なものではありません。むしろ、じわじわと選択肢が狭まっていく、と捉えるほうが実態に近いでしょう。まず、ハードウェアが故障した際の部品供給や修理対応が、受けられなくなる可能性があります。予備機や保守部品の確保が難しくなれば、一度の故障が長期停止に直結しかねません。
次に、セキュリティ上の脆弱性が見つかっても、修正プログラムの提供が受けられなくなるおそれがあります。法令や制度が改正された際の対応も、メーカーサポートなしに自社だけで担い続けるのは容易ではありません。こうしたリスクは、保守終了の当日に一斉に生じるのではなく、その手前から徐々に現実味を帯びていくもの。だからこそ、期限そのものより「いつまでに手を打つか」を先に考えておく必要があります。
実務的には、事業継続計画（BCP）やシステム監査の観点からも、保守が受けられない基幹システムを抱え続けることは、説明が難しくなりがちです。技術的なリスクだけでなく、対外的な説明責任という側面からも、期限を意識した対応が欠かせません。
「まだ大丈夫」は本当か：2035年から逆算する移行タイムライン
保守終了は2035年度末。ここから「まだ時間がある」と考えるか、「もう動き出す時期だ」と考えるかで、その後の選択肢は大きく変わります。まず見るべきは、移行にどれだけの期間がかかるか。そこから逆算すれば、いつ意思決定すべきかが見えてきます。不安を煽るためではなく、「今から動けば間に合う」という見通しを持つために。
移行完了までにかかる期間の目安
基幹システムの移行は、大きく分けて、現状把握（アセスメント）、移行方式の選定、設計・開発、テスト、そして並行稼働を経た本番切り替え、という工程をたどります。それぞれの工程は独立して短縮できるものではなく、前の工程の結果が次の工程を左右するため、規模の大きいシステムほど全体で数年を要することが少なくありません。
特に、長年の改修でドキュメントが失われていたり、担当者しか把握していない仕様が残っていたりする場合、現状把握だけで相応の時間がかかることもあります。後述する事例でも、資産の棚卸しやテスト工程に多くの労力が割かれています。「思い立ってすぐ完了する」性質のものではない、という前提を持っておきたいところです。
工程ごとに時間配分を見ておくと、計画が立てやすくなります。とりわけ、変換したシステムが従来とまったく同じ結果を出すかを確かめる検証の工程は、品質を左右する要であり、ここに十分な時間を確保できるかが成否を分けます。
逆算すると、いつ動き始めるべきか
移行に数年かかるとすれば、2035年度末という期限から逆算して、意思決定のリミットは思っている以上に手前にあることが分かります。たとえば、移行そのものに数年、事業者の選定や社内調整にさらに時間を見込むなら、遅くとも2030年代の前半には動き出している必要があるでしょう。
「いつまで使えるか」ではなく「いつまでに決めるか」を、具体的な日付で捉え直すこと。これが、先送りを防ぐための、もっとも実効的な第一歩になります。
先ほどの逆算をもう一歩具体化すると、方針を固めて事業者選定に入るのが2020年代の後半、実際の移行に着手するのが2030年代の前半、というイメージになります。日立の国産メインフレームも近い時期に終息へ向かうことを踏まえれば、移行を担う人材やパートナーの奪い合いは、期限が近づくほど激しくなると見ておくのが自然です。早く動くことは、単に安全なだけでなく、より良い条件で進めるための現実的な選択でもあります。
早く動くほど有利な理由：移行人材・SIerの需給
早く動くことには、期限に間に合わせる以上の意味があります。富士通のユーザーが、同じ2035年度末という期限に向けて一斉に移行へ動けば、移行を担うエンジニアやSIerの需給は、今後ますます論点になり得ます。COBOLを理解し、かつ移行を経験した人材は限られており、同時期に需要が集中すれば、後から動く企業ほど、費用・納期・選択肢のすべての面で不利になりやすい、というのが業界で指摘される傾向です。
加えて、富士通に続いて日立も国産メインフレームの終息時期を公表しており、市場全体で移行の波が重なることも見込まれます。「まだ動いていない」こと自体が、静かにリスクを積み上げている。そんな視点を持っておく必要があります。
他社はどう動いているか：移行事例と社内の通し方
大規模な移行は、試しにやってみて後から引き返す、というわけにはいきません。だからこそ、先行して移行を終えた他社の判断は、自社の意思決定を後押しする有力な材料になります。手がかりになるのが、実際の移行事例と、社内で移行を通すための説明の組み立て方です。
「あれだけの規模の企業が移行できたのなら、自社にもできるはずだ」。具体的な事例は、抽象的な説明よりもはるかに強く、判断を後押しします。以下は富士通メインフレームからの移行を実際に完遂した、代表的なケースです。
巨大なCOBOL資産を短期間で刷新した事例（ベイシアグループソリューションズ）
ワークマンやカインズを展開するベイシアグループ（システム構築を担うベイシアグループソリューションズ）の発注・在庫管理を担う基幹システムは、富士通メインフレーム上のCOBOL資産およそ600万ステップ、プログラム約2万2千本、80以上の外部システムとの連携という、巨大かつ複雑なものでした。COBOL技術者の高齢化による人材不足や、ドキュメントの欠損による属人化、そしてシステム基盤が事業成長の足かせになりかねないという危機感から、同グループは2019年にオープン化プロジェクトを本格化させました。「Xenlon～神龍 Migrator」による変換では、COBOLからJavaへ99％を超える精度で自動変換したうえで、残りを新環境向けに調整するという進め方がとられ、大規模ながら開発フェーズをおよそ1年で完了させました。移行後はLinux基盤で安定稼働し、保守開発の生産性向上にもつながったと報告されています。
このプロジェクトでは、2019年の初めにまず移行対象となるレガシー資産の棚卸しが行われ、実際には使われていないプログラムを除外することで、移行対象を大きく絞り込んでいます。そのうえで自動変換を進め、変換そのものに要した期間は延べ十数週間、ピーク時には数十人規模のエンジニアが動作検証と調整にあたったとされます。変換前と変換後で同じ結果が出るかを突き合わせる新旧比較テストに重点を置いた進め方が、大規模移行を短期間で成立させた鍵でした。自社の状況と重ねて読むと、進め方の具体像がつかみやすいはずです。
株式会社ベイシアグループソリューションズ 様（基幹システムのオープン化）の事例詳細はこちら
「撤退」を刷新の好機に変える：役員会で使える説明ロジック
ベンダーの撤退は、一見すると降ってわいた災難です。しかし見方を変えれば、長年「動いているから」という理由で後回しにされてきた基幹システムの刷新を、正面から進めるための外部要因にもなり得ます。社内で移行予算を通す際には、「やりたいから」ではなく「やらざるを得ないから」という論理のほうが、一般に受け入れられやすいといわれます。保守終了という動かせない期限は、その「やらざるを得ない理由」として、これ以上ないほど明確です。
役員会や稟議の場では、第一に保守終了によって生じる事業継続リスク、第二に移行に要する期間から逆算したスケジュール、第三に先行他社の事例、という三点をセットで示すと、「なぜ今なのか」への説得力が一気に高まります。撤退というネガティブな出来事を、塩漬けシステムを刷新する大義名分へと転換する。それが、社内を現実に動かすための、有効な進め方です。
費用の面でも、伝え方には工夫の余地があります。移行を「一度きりの大きな出費」として提示すると身構えられがちですが、保守終了後に発生し得るリスクへの備えや、移行後に見込める保守コストの低減、開発スピードの向上といった中長期の効果とあわせて示すと、投資としての妥当性が伝わりやすくなります。数字の根拠として、後述するアセスメントの結果を用いれば、説得力はさらに増します。
過去事例から見える共通パターン
過去事例では、いくつかの共通点が浮かび上がります。第一に、いずれも保守終了や人材確保といった避けられない事情を起点に、計画的に動き出している点。第二に、いきなり全面移行に着手するのではなく、まず現状の資産を棚卸しし、移行対象を見極めるところから始めている点。第三に、COBOL資産をそのまま作り直すのではなく、自動変換によって活かしながらオープン環境へ移している点です。これらは、規模や業種が異なっても応用できる、移行成功の要点といえます。
あわせて、移行を託すパートナーを見極める観点も押さえておきたいところです。富士通メインフレームやそのCOBOL資産の移行実績があるか、資産の棚卸しや移行診断、試験的な変換から相談できるか、リホスト・リライト・リビルドを比較したうえで提案してくれるか、変換前後で結果が一致するかを確かめる検証まで支援できるか、そして移行後の保守・運用まで見てもらえるか。こうしたチェックポイントを事前に整理しておくと、事業者選定の場面で判断がぶれにくくなります。
移行の選択肢と手法：リホスト・リライト・リビルド
「移行」と一口に言っても、その方法によってコスト・期間・リスク・移行後の柔軟性は大きく変わります。自社にとって何が適切かを見極めるための、基礎知識をそろえておきましょう。
オープン化・モダナイゼーションとは
「オープン化」とは、メインフレームという特定メーカーに依存した環境から、広く普及したサーバーやOS、クラウドといったオープンな環境へ、システムを移すことを指します。一方「モダナイゼーション」は、単に環境を移すだけでなく、老朽化・複雑化したシステムを、現在の技術で扱いやすい形へと刷新していく、より広い取り組みを意味します。
オープン化は、モダナイゼーションの中心的な手段の一つ、という関係で捉えると分かりやすいでしょう。目的は、環境を新しくすること自体ではなく、その先にある保守性や柔軟性、拡張性の向上にあります。手段が目的化しないよう、「何のために移行するのか」を最初に定めておくことが大切です。
近年は、移行先としてオンプレミスのサーバーだけでなく、クラウドを選ぶ企業も増えています。クラウドを活用すれば、機器の保守から解放され、必要に応じて処理能力を柔軟に増減できるといった利点が期待できます。一方で、既存の業務要件やセキュリティ要件との適合は個別の検討を要するため、「クラウドありき」ではなく、自社にとっての最適な移行先を、要件から逆算して選ぶ姿勢が求められます。
リホスト／リライト／リビルドの違い
移行の手法は、代表的な整理の一つとして、リホスト・リライト・リビルドの三つに大別できます。リホストは、既存のプログラムをできるだけそのまま、オープン環境へ載せ替える方法で、比較的短期・低リスクで移行できる一方、レガシーな構造や課題はそのまま引き継がれやすいという側面があります。リライトは、COBOLなどの既存資産を、Javaといった現代的な言語へ変換する方法で、資産を活かしつつ保守性を高めやすいのが特長です。リビルドは、業務要件から作り直す方法で、理想的な形に刷新できる反面、コストと期間、そしてリスクは最も大きくなりがちです。
どれが優れているという話ではなく、資産の規模や状態、移行後に何を実現したいかによって、適した手法は変わります。手法ごとの詳しい比較については、別記事でも解説しています。
手法は必ずしも一つに絞る必要はなく、システムの領域ごとに使い分けたり、組み合わせたりすることも可能です。たとえば、当面は動かし続けたい部分はリホストで素早く移し、将来にわたって改修が見込まれる中核部分はリライトで保守性を高める、といった判断もあり得ます。選ぶ際の軸は、資産をどれだけ活かしたいか、移行後にどれだけ手を入れたいか、そしてどこまでの期間とコストを許容できるか。この三点を自社の事情に当てはめて考えると、方向性が見えてきます。
エミュレータでの延命という選択肢とその限界
移行の手段とは別に、「エミュレータ」を用いて既存のメインフレーム資産をそのまま動かし続ける、という延命策も存在します。これは、移行までの時間を稼ぐ手段として、一定の有効性を持ちます。しかし、エミュレータはあくまで既存資産を「そのまま」動かすものであり、COBOL技術者への依存や、ドキュメント欠損による属人化といった根本的な課題は、解消されないまま残ります。あくまで一時的な橋渡しと位置づけ、その間に本格的な移行の計画を進めておくことが現実的でしょう。
COBOL/PL/I資産をどう活かすか：Xenlon～神龍 モダナイゼーションサービス
移行を進めるうえで、最大の論点となるのが「これまで積み上げてきたCOBOL/PL/I資産を、どう引き継ぐか」です。鍵は、レガシー資産を負債ではなく強みとして活かすこと。それを実現する選択肢の一つが、TISIの「Xenlon～神龍 モダナイゼーションサービス」です。
レガシー資産を「競争力」に変える考え方
長年にわたって使い込まれてきたCOBOL/PL/I資産には、その企業の業務そのものが、ロジックとして緻密に埋め込まれています。それは、保守が難しいという意味では「負債」ですが、他社がすぐには真似できない業務ノウハウの結晶という意味では、紛れもない「競争力の源泉」でもあります。
移行にあたって、この資産をゼロから作り直してしまえば、蓄積された業務知識まで失いかねません。捨てるのではなく、活かしながら新しい環境へ引き継ぐ。その発想の転換こそが、モダナイゼーションを成功させる出発点になります。
保守性を重視した自動リライト（COBOL/PL/I→Java）
COBOL/PL/I資産を活かす有力な方法が、既存のコードをJavaなどの現代的な言語へ変換する「リライト」です。自動変換と聞くと、「読めない・直せないコードが大量に生まれるのでは」という懸念を持たれることがあります。しかし、変換前と変換後の両方の言語を理解するプログラマが読み下せる、保守性を重視した変換であれば、話は変わってきます。
既存の担当者がこれまで培ってきた業務知識を、新しい環境でもそのまま活かせるため、「移行したら中身が分からなくなり、取り残される」という不安を抑えられます。人材の観点からも、COBOL技術者に限られていた保守を、より多くのJava技術者が担える体制へ移せる意義は小さくありません。COBOLという言語そのものの特性については、別記事でも詳しく解説しています。
なお、自動変換は「変換して終わり」ではありません。先に挙げた事例でも、変換前後で結果が一致するかを確かめる検証が品質確保の中心に据えられていました。変換とその後の検証までを含めて一つの手法である、と理解しておくとよいでしょう。
Xenlon～神龍 モダナイゼーションサービスとは
TISIの「Xenlon～神龍 モダナイゼーションサービス」は、独自開発のリライトツールを用いて、COBOLやPL/Iといったレガシー言語をJavaへ変換し、大規模なシステムをオープン環境へ移行することを支援するサービスです。業務ロジックをほぼ100％自動変換できる高い変換率を強みとし、一般的なリビルドによる再構築と比べて、開発の費用・期間の両面で効率化が図れるとされています。
すでに販売終了・保守終了が公表された富士通メインフレームからの移行にも対応しており、金融・公共・製造・流通といった幅広い業種での実績を重ねています。前述のベイシアグループの事例も、このサービスによって実現されたものです。
TISIは、こうした大規模移行を支えるために、多数の有識者を開発リソースとして擁し、金融をはじめとする分野で実績を積み重ねてきたとしています。COBOLに限らず、PL/Iといったレガシー言語に対応している点や、アセスメントから移行後の保守・機能改修までを一貫して手がけられる体制も、大規模で複雑なシステムを扱う企業にとっては判断材料になります。
移行前に実現性を見極める：アセスメントという第一歩
「移行すべきか、そもそも自社のシステムは移行できるのか」。その問いに答える前に必要なのが、現状を可視化するアセスメントです。アセスメントでは、対象となる資産の棚卸しを行い、プログラムやデータの規模、他システムとの連携、移行の難易度やリスクを事前に洗い出します。
これにより、「やってみないと分からない」という状態から、「調べれば、どれだけの労力で動けるかが分かる」という状態へ進むことができます。いきなり全面移行に踏み切るのではなく、まず自社の現在地を正確に知る。それが、移行を見通すうえでの確かな第一歩になります。TISIでも、富士通メインフレームの利用企業に向けたアセスメントのサービスが提供されています。
こうしたアセスメントでは、資産の量や複雑さ、他システムとの依存関係が具体的な数字として可視化されるため、経営層への説明資料としても機能します。「なんとなく大変そう」という漠然とした不安を、「これだけの資産を、この手法で、この程度の期間で移せる」という具体的な計画へと変えられること。それが、最初の一歩をアセスメントに置く最大の意義です。
よくある質問（FAQ）
富士通メインフレームの保守終了と移行を検討し始めると、次のような疑問が出てくるはずです。
Q. 富士通メインフレームはいつまで使えますか？
公表されている方針では、保守サポートは2035年度末までとされています。ただし、移行には数年単位の期間がかかることが多いため、「いつまで使えるか」という発想よりも、「いつまでに移行を決めるか」という発想で捉えておくことをおすすめします。
Q. 何もしないとどうなりますか？
保守終了後は、ハードウェア故障時の対応や、セキュリティ・法令対応のアップデートが受けられなくなる可能性があります。事業継続の観点からは、期限までに移行、あるいは代替策を用意しておくことが望ましいといえます。
Q. 移行にはどれくらいの期間・費用がかかりますか？
システムの規模や、選択する移行手法によって大きく異なるため、一律にお答えするのは難しいところです。まずはアセスメントで対象資産を棚卸しし、自社の前提に即した見積もりを立てるところから始めるのが、遠回りに見えて確実です。
Q. COBOL技術者がいなくても移行できますか？
移行の手法やパートナーの支援体制によっては、対応できる場合があります。特に、既存資産を活かす自動リライトのような方式であれば、COBOL技術者の不足による影響を抑えやすくなります。
Q. クラウドとオンプレミス、どちらに移行すべきですか？
一概にどちらが正解とはいえません。運用の手離れやスケーラビリティを重視するならクラウド、既存の要件やデータの所在に制約があるならオンプレミス、という具合に、自社の要件によって最適解は変わります。移行の検討にあたっては、手法だけでなく移行先の選定もアセスメントの対象に含めておくと、判断がぶれにくくなります。
Q. 一度にすべて移行しないと駄目ですか？
必ずしも全面を一度に移す必要はありません。システムを領域ごとに分け、優先度の高いところから段階的に移していく進め方もあります。実際の大規模事例でも、資産を棚卸ししたうえで対象を絞り込み、分割して進める手法が採られています。自社の体制や予算に合わせて、無理のない移行計画を組むことが大切です。
まとめ
富士通メインフレームは、2030年度末に製造・販売を終了し、2035年度末に保守サポートを終える方針が公表されており、「このまま使い続ける」という選択は、現実的に難しくなっています。とはいえ、残された時間から逆算し、いま計画的に動き出せば、移行は十分に間に合います。大切なのは、「撤退」というネガティブな出来事を、長年先送りにしてきたシステムを刷新する好機と捉え直すこと。そして、いきなり全面移行に踏み切るのではなく、まず現状を可視化するアセスメントから始めることです。先行する他社の事例が示すように、COBOL/PL/I資産は、活かしながら新しい環境へ引き継ぐことができます。自社にとって最適な移行の形を、今日から見極めていきましょう。
▼『Xenlon～神龍 モダナイゼーションサービス』の特徴等をご説明
▼『Xenlon～神龍 モダナイゼーションサービス』のアセスメントサービスの詳細・お問合せはこちらから
▼『Xenlon～神龍 モダナイゼーションサービス』のサービス全体を知りたい方はこちらへ