「脱メインフレーム、約7割が失敗」の衝撃――“生成AIを使うだけ”ではむしろ泥沼化も：富士通に続き日立も撤退表明（1/2 ページ）

富士通に続き、日立製作所もメインフレーム事業からの撤退に向けて動き始めました。生成AIによる刷新への期待が高まる一方、「脱メインフレーム」の7割超が失敗するとの予測もあります。生成AIがあっても移行が簡単ではない理由と刷新のアプローチを考えます。

[雨輝ITラボ（リーフレイン）, 編集：遠藤文康，＠IT]

　メインフレームで稼働する基幹システムの刷新は、国内の多くの企業にとって長年の懸案でした。

　国内では既に富士通がメインフレームからの撤退方針を示している他、日立製作所（以下、日立）もメインフレーム向けOS「VOS3」（Virtual-storage Operating System 3）の販売、保守を順次終了すると発表しました。販売終了は2027年11月、保守終了は2034年12月です。

　こうした動きを受け、メインフレームを利用する企業にとって、既存システムを今後どう維持し、どのタイミングで、どのように移行するかは避けて通れない課題になりつつあります。

　そこで期待を集めているのが生成AIです。ブラックボックス化したプログラムの解析や仕様書の作成、古いプログラミング言語からモダンな言語への変換など、これまで人手に頼っていた作業をAIで効率化できれば、長年行き詰まってきたレガシーシステム刷新が一気に進む可能性があります。

　しかし、「AIがあるから脱メインフレームもうまくいく」と考えるのは早計かもしれません。

日立もメインフレームOS終了、脱却が「いつかの課題」ではなくなる

　メインフレームを巡る環境が変化する中、システムを提供してきたベンダー側も、従来の製品を維持するだけではなく、AIを活用したモダナイゼーション支援へと軸足を移し始めています。

「80年の知見」をAIエージェントに反映

　日立はメインフレーム向けOSの順次終了と併せて、AIエージェントを活用した基幹システムのモダナイゼーション支援を表明しました。

　2025年10月から提供する「モダナイゼーション powered by Lumada」では、現状評価や構想策定からシステム移行、業務変革、運用変革までを一貫して支援し、各工程をAIがサポートします。

　特徴的なのは、単純なコード生成だけにAIを使うわけではないことです。日立は約80年にわたるミッションクリティカルシステムの構築、運用で培った知見を、工程ごとのAIエージェントに反映したとしています。

　具体的には、ブラックボックス化した既存アプリケーションを解析して仕様書を再作成するエージェントや、レガシープログラミング言語を保守しやすいモダンな言語に変換するエージェント、データ移行や移行後のテストを自動化するエージェントなどが用意されており、既に金融分野や公共分野のモダナイゼーションで活用実績があるとのことです。

　長年積み重なったコードを読み解き、新しいシステムへ移す。生成AIは、こうしたレガシー刷新で特に負担の大きかった作業を効率化する手段として期待されています。

• 参考記事：日立がメインフレームOS終了　次の注力「AIエージェントによる基幹システム刷新」の実態は？

「生成AIがあれば移行できる」と考えるのは危険？

　ところが、生成AIの登場によって脱メインフレームが容易になるかというと、そう単純ではありません。むしろAIへの期待が先行することで、無理な刷新プロジェクトが増える可能性も指摘されています。

2026年開始の「脱メインフレーム」、Gartnerは70％超が失敗すると予測

　調査会社のGartnerは2026年6月18日（米国時間）、2026年から開始されるメインフレーム脱却プロジェクトのうち、70％以上が当初の目的を達成できずに失敗するという予測を発表しました。

　Gartnerが指摘するのは、生成AIによってモダナイゼーションの工数を劇的に減らせるというマーケティング上のうたい文句と、実際の能力との間にある大きな隔たりです。ベンダーは投資家からの圧力もあり、成果の有無にかかわらず自社製品にAI機能を組み込もうとしています。

　しかし、メインフレーム上で動くアプリケーションの多くは、長期間にわたる改修を積み重ねた巨大なミッションクリティカルシステムです。長年の改修によってコードが複雑化する一方で、システムを熟知する技術者は定年退職などによって減少しています。こうしたリスクを抱えた状態で計画不十分のまま進めれば、プロジェクトそのものが実行困難になります。

　つまり問題は、AIがコードを書けるかどうかだけではないことです。

　長年の改修によって、「どの処理が何のために存在するのか分からない」「ある機能を変更した際にどこまで影響するか把握できない」「設計書と実際のシステムが一致していない」などのレガシーシステム固有の複雑さまで含めて整理しなければ、安全に移行することはできません。

「全部移す」ことが最適解とは限らない

　Gartnerは、AIによるコード変換だけに頼らず、ワークロードごとに適切な実行基盤を判断することが重要だとしています。不十分な検討のままAI任せで移行すれば、新たな技術的負債を抱えたり、本番稼働後に重大な障害を起こしたりする恐れもあります。

　中規模のメインフレーム環境では、既存投資を生かしたモダナイゼーションを基本とし、全面的なプラットフォーム移行は必要なケースに限定すべきだというのがGartnerの見方です。生成AIについても、メインフレームから急いで脱却するためではなく、メインフレームを維持しながらモダナイズする手段として、より大きな効果を発揮する場合があるとしています。

• 参考記事：生成AIがあれば「脱メインフレームもできる」なんて気軽に言えるのは今のうち？

技術者不足だけではない――レガシー刷新を阻む「見えないシステム」

　実際、企業はモダナイゼーションのどこでつまずいているのでしょうか。

　AI駆動開発プラットフォームを提供するROUTE06が2026年4月22日に公表した「モダナイゼーションの実態調査」は、刷新を妨げているのが単純な「COBOL技術者不足」だけではないことを明らかにしています。

半数前後が「構想止まり」、複雑さと属人化がプロジェクトを止める

　基幹システムの企画・刷新に関わる管理職やエンジニアら328人を対象とした同調査によると、残存するレガシーシステムのモダナイゼーションについて「構想段階（構想止まり）」との回答が、事業会社で46.7％、SIer・ITベンダーの顧客企業で54.7％に上りました。

レガシーシステムに対するモダナイゼーションの進捗（しんちょく）状況（提供：ROUTE06）

　刷新に着手できたとしても、順調に進むとは限りません。モダナイゼーションを実施した事業会社の70.2％が「おおむね達成できた」と回答した一方、31.4％は「一部は達成できたが、課題が残った」と回答しています。

　課題が残った・失敗した理由としては、「システムの複雑化によるスケジュール超過」「属人化によるプロジェクト停滞」「コスト超過や要員不足」などが挙げられました。中には「単なる言語の書き換えレベルにとどまった」「レガシーシステムを併存せざるを得なくなった」という声もあり、単にコードを変換するだけでは刷新が完了しない実態が浮かび上がります。

　また、刷新が本格化しない理由として、事業会社では「投資対効果が不明確」（51.9％）や「移行期間やコストを見積もれない」（50.0％）を挙げ、SIer・ITベンダー側は「業務停止リスクが懸念される」（63.9％）や「言語変換の精度や品質への不安がある」（52.5％）を懸念しています。

モダナイゼーションが本格的に進んでいない理由（提供：ROUTE06）