富士通のメインフレーム撤退

かつて国産コンピュータの代名詞として、日本の金融や行政システムを支えてきた富士通のメインフレーム。しかし2022年、同社はメインフレームおよびUNIXサーバーの製造・販売からの完全撤退を発表しました。このニュースは、長年安定稼働を続けてきた基幹システムを持つ多くの企業に、「移行」という重い決断を迫っています。

「保守はいつまで続くのか？」「膨大なCOBOL資産をどうすべきか？」
本記事では、富士通メインフレーム撤退の正確なスケジュールと、移行に向けた具体的な戦略、そしてオープン系への移行で直面する技術的な壁について解説します。

富士通メインフレーム撤退のスケジュールと「2035年の崖」

多くの企業にとって、基幹システムの刷新は数年単位のプロジェクトとなる一大事業です。まずは富士通が発表した公式なスケジュールを正しく把握し、自社に残された猶予期間を確認しましょう。期限は明確に設定されています。

2030年販売終了・2035年保守終了のタイムライン

富士通の発表によると、メインフレーム「GS21シリーズ」の販売は2030年度（2031年3月期）をもって終了します。しかし、より重要なのは「保守サービス」の終了時期です。販売終了後5年間のメンテナンス期間を経て、2035年度末には保守も完全に終了となります。

これを経済産業省が警鐘を鳴らす「2025年の崖」になぞらえ、「2035年の崖」と呼ぶ声も上がっています。現在2020年代中盤であることを踏まえると、残された時間は約10年です。「10年もある」と思われるかもしれませんが、要件定義から移行、テスト、並行稼働までを含めた大規模なマイグレーション計画において、この期間は決して余裕のあるものではありません。今すぐ検討を開始しなければ、期限間際になって「移行先がない」「技術者が確保できない」という事態に陥るリスクがあります。

メインフレーム撤退が意味すること（UNIXサーバーも対象）

今回の撤退発表で注意すべき点は、対象がメインフレーム（GS21シリーズ）だけではないということです。富士通はUNIXサーバー「SPARC M12」についても、2029年度下期に販売を終了し、2034年度中に保守サポートを終えるとしています。つまり、富士通製のハードウェアに依存した基幹システムは、2030年代半ばにはその全てがメーカーサポートを失うことになります。

これは富士通という企業が、ハードウェアの製造・販売を行う「モノ売り」から、クラウドやDX支援を中心とした「サービス企業」へと完全に舵を切ったことを意味します。ユーザー企業は、「いつか新しい後継機が出るだろう」という期待を捨て、クラウドやオープン系サーバーなど、全く異なるプラットフォームへの移行を前提とした計画を立てる必要があります。

なぜ撤退するのか？市場縮小と技術者不足の背景

なぜ富士通は、長年の歴史を持つメインフレーム事業からの撤退を決めたのでしょうか。最大の理由は市場環境の変化です。かつて汎用機と呼ばれ、あらゆる処理の中心だったメインフレームは、WindowsやLinuxといったオープン系サーバーの台頭（ダウンサイジング）により市場が縮小。さらに近年はクラウドサービスの普及が決定的となり、ハードウェア事業の維持が困難になっています。

また、人的リソースの問題も深刻です。メインフレームの中核言語であるCOBOLを扱えるエンジニアの高齢化が進み、新たな技術者の確保が年々難しくなっています。維持コストの高騰と技術継承の断絶。これらの課題はユーザー企業だけでなく、メーカーである富士通自身にとっても限界点に達していたと言えるでしょう。この撤退は、時代の必然的な流れであり、レガシーシステムからの脱却を促す最後通告とも捉えられます。

対策待ったなし！COBOL資産の移行パターン3選

2035年の保守終了に向け、企業は現在稼働しているCOBOL資産をどのように次世代環境へ移すべきでしょうか。選択肢は主に「リホスト」「リライト・リビルド」「パッケージ導入」の3つに大別されます。それぞれのメリット・デメリットを理解し、自社の予算やシステム重要度、将来のDX構想に合わせた最適な手法を選定することが重要です。

リホスト（現状維持でプラットフォーム変更）

「リホスト」は、既存のCOBOLプログラムやアプリケーションロジックには極力手を加えず、稼働するインフラ基盤だけをメインフレームからオープン系サーバーやクラウドへ移行する手法です。この方法の最大のメリットは、移行に伴うリスクとコストを最小限に抑えられる点にあります。業務ロジックが変わらないため、移行後のテスト工数を削減でき、ユーザーの業務手順への影響も少なく済みます。

しかし、これはあくまで「延命措置」に近い側面があります。プログラム自体はCOBOLのままであるため、COBOL技術者の確保という課題は解決されません。また、古い設計思想がそのまま残るため、最新のデジタル技術との連携や柔軟な機能拡張には不向きです。「まずは2035年の期限を乗り越える」ことを最優先とする場合や、仕様が複雑すぎて解析困難なシステムに適した選択肢と言えるでしょう。

リライト・リビルド（言語刷新・再構築）

「リライト」は既存のロジックを解析してJavaやPythonなどの現代的な言語で書き直す手法、「リビルド」は要件定義からやり直しシステム全体を再構築する手法です。これらはシステムの「中身」を刷新するため、クラウドネイティブな技術やAI活用など、DX（デジタルトランスフォーメーション）への足掛かりとして非常に有効です。オープン系の言語になれば、若手エンジニアの確保も容易になり、将来的な保守性も向上します。

一方で、このアプローチはハイリスク・ハイリターンです。長年改修を重ねた「秘伝のタレ」のような複雑なロジックを完全に再現するのは難易度が高く、プロジェクト期間の長期化やコスト増大のリスクを伴います。特にメインフレーム特有の機能（JCLや独自のDB構造など）をオープン系でどう再現するか、あるいはどう捨てるかという高度な判断が求められます。生成AIを活用したコード変換なども登場していますが、最終的な品質保証には入念なテストが不可欠です。

パッケージ（SaaS）導入による業務プロセスの刷新

3つ目は、既存の自社開発システム（スクラッチ開発）を捨て、市場で評価されているERPパッケージやSaaS（Software as a Service）に乗り換える方法です。「Fit to Standard（標準に合わせる）」という考え方に基づき、自社の業務フローをソフトウェアの標準機能に合わせて変更します。これにより、システムの維持管理コストを大幅に削減できるだけでなく、法改正への対応や最新機能の享受がベンダー任せで可能になります。

ただし、長年メインフレームで独自に作り込んだ業務プロセスからの転換には、現場の強い抵抗が予想されます。「使い勝手が変わる」「あの機能がないと仕事ができない」といった声をどう調整し、業務改革（BPR）を断行できるかが成功の鍵です。独自性が競争力の源泉となっているコア業務は「リライト」、一般的な管理業務は「SaaS」といった具合に、領域ごとの使い分け（ハイブリッド戦略）も検討すべきでしょう。

メインフレームからオープン系へ：移行を阻む「技術的障壁」

メインフレームからの脱却が「単なるサーバーの引っ越し」で済まない最大の理由は、そのアーキテクチャ（設計思想）が、現代のオープン系サーバー（WindowsやLinux）とは根本的に異なる点にあります。まるで「昆虫」と「哺乳類」ほど系統樹が違うシステム間での移行には、予期せぬ技術的トラブルがつきものです。ここでは、プロジェクトを停滞させる代表的な3つの壁について解説します。

文字コードの壁（EBCDICとASCII/UTF-8の違い）

最も基本的かつ根深い問題が「文字コード」です。WindowsやLinuxが「ASCII」や「UTF-8」を標準とするのに対し、メインフレームは「EBCDIC（エビシディック）」という独自のコード体系を使用しています。

単なる変換ツールを通せば良いという話ではありません。例えば、EBCDICとASCIIでは英数字の並び順（ソート順）が異なります。これにより、データを並び替える処理の結果が変わってしまい、帳票の出力順が狂う、集計結果が合わないといった業務影響が出ることがあります。
さらに厄介なのが、富士通独自の日本語拡張（JEF漢字コード）や、「ゾーン10進数」と呼ばれる数値表現です。これらはオープン系では標準サポートされていないため、外字対応やバイナリレベルでのデータ変換ロジックを組み込む必要があり、文字化けやデータ長の変化による桁あふれのリスクが常に付きまといます。

ファイルシステムとDB構造の違い（KVS/階層型 vs RDB）

データの持ち方も全く異なります。オープン系のファイルシステムが「ツリー構造（フォルダ階層）」でファイルを「バイトストリーム（切れ目のないデータ）」として扱うのに対し、メインフレームは「フラット構造」で「レコード単位（固定長/可変長）」として扱います。このため、移行時には改行コードの扱いやレコード長の管理をアプリケーション側で厳密に再実装する必要があります。

また、データベースの構造も大きな課題です。メインフレームでは「階層型（HDB）」や「ネットワーク型（NDB）」と呼ばれるデータベースが主流で、プログラムは「次へ、次へ」とポインタを辿ってデータを処理します。これをオープン系の主流である「リレーショナルデータベース（RDB）」の「SQL（集合処理）」にそのまま置き換えると、処理効率が劇的に低下するケースが多発します。
例えば、単純なデータ抽出でも、アクセス方式の違いからSQLの発行回数が膨大になり（N+1問題）、メインフレーム時代には数秒で終わっていたバッチ処理が、オープン系では数時間経っても終わらないというパフォーマンス問題を引き起こす原因となります。

JCL（ジョブ制御）とバッチ処理の置き換え問題

メインフレームの運用を支えているのが「JCL（Job Control Language）」です。JCLは単なる実行スクリプトではなく、CPUやメモリのリソース管理、物理ファイルと論理ファイルのマッピング（DD文）などを一手に担う強力な制御言語です。

オープン系でこれに相当するのはシェルスクリプト（Bashなど）ですが、JCLが持つ機能のすべてをシェルだけで再現するのは困難です。例えば、JCLにおける排他制御や、異常終了時のリカバリー手順などをオープン系で実現するには、高機能なジョブ管理ツール（JP1など）を導入するか、コンテナ技術を用いた高度なオーケストレーション基盤を構築する必要があります。「COBOLのソースコードは変換できたが、JCLの移行方針が決まらずプロジェクトが頓挫する」というのは、非常によくある失敗パターンです。

「撤退」を「転機」に。レガシー脱却で実現するDX

富士通のメインフレーム撤退は、多くの企業にとって「寝耳に水」のバッドニュースだったかもしれません。しかし、視点を変えれば、長年手を付けられなかった「岩盤規制」のようなレガシーシステムを刷新する、またとないチャンスでもあります。この強制的な移行イベントを、単なるコストと捉えず、企業の競争力を高めるDX（デジタルトランスフォーメーション）の起爆剤にする視点が重要です。

技術的負債の解消とランニングコストの適正化

メインフレームは「安定性」という最大のメリットの代償として、高額なハードウェア保守費や、COBOL技術者への依存といった「技術的負債」を抱え続けてきました。
オープン系やクラウドへ移行することで、これらのブラックボックス化していた維持コストを可視化し、最適化することが可能になります。特にクラウド（AWS、Azure、Google Cloudなど）を活用すれば、必要なリソースを必要な分だけ利用する従量課金モデルへとシフトでき、固定費の大幅な削減が期待できます。浮いた予算を「守り」の保守から、「攻め」の新規開発やAI活用へと投資配分を変えることができるのです。

クラウドネイティブ化によるビジネススピードの向上

現代のビジネス環境は変化のスピードが極めて速く、システムには柔軟性が求められます。「要件定義からリリースまで数年かかる」メインフレームのウォーターフォール型開発では、市場の変化に追随できません。
システムをモダナイゼーション（近代化）し、マイクロサービス化やAPI連携が容易な構造に作り変えることで、開発サイクルを劇的に短縮できます。例えば、基幹システムのデータをリアルタイムでBIツールに連携して経営判断に活かしたり、最新のSaaSと連携して顧客体験を向上させたりといった施策が、スピーディーに実現可能になります。

移行プロジェクトを成功させるための体制づくり

レガシー脱却を成功させるためには、ツールや技術の選定以上に「体制」が重要です。メインフレームを知るベテラン社員と、オープン系・クラウド技術に明るい若手・中堅社員が協力し合うチームビルディングが不可欠です。
また、社内リソースだけで完結しようとせず、マイグレーション実績が豊富な外部ベンダーやコンサルティングファームを早期に巻き込むことも重要です。富士通自身も移行支援サービスを提供していますが、ベンダーロックインを避ける意味でも、セカンドオピニオンを含めた多角的なパートナー選定を行うべきでしょう。

まとめ：2035年は遠くない。今すぐロードマップの策定を

富士通製メインフレームおよびUNIXサーバーからの撤退スケジュールは、以下の通り確定しています。

• 2030年度：販売終了
• 2035年度：保守サービス完全終了

「まだ10年ある」ではなく、「あと10年しかない」というのがシステム担当者の偽らざる実感ではないでしょうか。移行先システムの選定、PoC（概念実証）、要件定義、開発、そして並行稼働テストには、想像以上の時間を要します。特に、世界中で同様の移行プロジェクトが走るため、優秀なエンジニアの争奪戦が起きることも予想されます。

今すべきことは、社内の現状把握と、経営層へのリスク共有です。「塩漬け」という選択肢はもはや存在しません。この不可避な変化を前向きに捉え、2035年のその先もビジネスを成長させ続けるためのロードマップを、今日から描き始めましょう。