AIは「脱メインフレーム」を促し、実は“レガシー維持”にも使える その実践例とは：JFEスチールのオープン化事例から、生成AIによる延命策まで

メインフレームやオフコンを巡る「刷新か、維持か」という判断の前提は、AIの登場によって変わりつつあります。どのように変化しているのでしょうか。その背景と実態を整理します。

[雨輝ITラボ（リーフレイン）, 編集：鳥越武史，＠IT]

　国内企業の間には、業務を長年支えてきた一方で、保守や運用に課題を抱える「レガシーシステム」の刷新ニーズが根強く存在します。レガシーシステムの代表格として捉えられることがあるメインフレームやオフィスコンピュータ（オフコン）を巡っては、ベンダー各社の製品戦略やサポート方針の変化もあり、既存システムの運用方針をあらためて検討する動きが続いています。

　もっとも「古いシステムだから即廃止すべし」という単純な話ではありません。古くても企業が求める役割を十分に果たしているシステムであれば、廃止ではなく維持を選択するのが合理的な場合もあります。近年は、生成AIを活用して保守負担の軽減を図る動きも現れています。

　「刷新か、維持か」という判断の前提が変わりつつあるメインフレームやオフコン。本稿は、その現在地を整理します。

「脱レガシー」の市場は拡大　それを促す“守り”と“攻め”の理由

　デロイト トーマツ ミック経済研究所の調査によると、国内の「レガシー＆オープンレガシーマイグレーション・モダナイゼーション」市場は2024年度に前年比126.8％の1兆3943億円を記録し、2029年度には2兆2450億円規模への拡大が見込まれています。年平均成長率は10.0％と高水準で推移しており、「レガシーシステムの見直し」が国内IT市場の主要テーマの一つになっています。

　市場全体を見ると、「UNIX」や「Java」「Visual Basic」（VB）、ERP（統合業務）パッケージなどを対象とする「オープンレガシーシステム」からの移行需要が大きな比重を占めています。それでもメインフレームを中心としたレガシーシステムからの移行市場も、2024年度に前年比129.4％の4504億円を記録しており、依然として高い伸びを示しています。

ベンダーの事業終了は“きっかけ”に過ぎない

　富士通は自社メインフレームのハードウェア事業を終了すると発表しており、これが足元の移行需要を後押しする要因の一つになっています。ただし、その需要の全てが同社の方針によって生まれたわけではないはずです。

　メインフレーム利用企業の中には、移行の必要性を認識しながらも、コストや技術的なリスクを理由に移行に踏み切れなかった企業もあると考えられます。ベンダーの事業終了方針によって新たな課題が生じたというよりも、以前から存在していた課題が顕在化したというのが実態に近いでしょう。

　移行需要を支えているのは、こうした“守り”の動機だけではありません。AIやデータの活用、デジタルトランスフォーメーション（DX）の推進といった、“攻め”の動機に基づくシステム刷新のニーズも確実にあります。企業が新たな取り組みを進める中で、「現行のシステムでは新技術を活用しにくい」といった課題を、より明確に認識するようになってきたからです。

• 参考記事：脱「レガシーシステム」が加速　UNIXやERPもピークに（＠IT）

AIやデータ活用を見据えて「脱メインフレーム」に挑んだJFEスチール

　実際に“攻め”の目的でメインフレーム刷新に踏み切った企業の一例が、鉄鋼大手のJFEスチールです。同社は全ての製鉄所／製造所で稼働する基幹システムについて、IBM製および富士通製メインフレームからオープンシステムに移行しました。総投資額は約1100億円、システム規模は約2億ステップに及びます。2020年10月に着手し、5年2カ月で完遂しました。

　JFEスチールが目指したのは、単に老朽化したシステムを刷新することではありません。蓄積したデータ資産を活用し、データサイエンスやAIによって生産性の向上や操業の安定化を実現することです。言い換えれば、今回の取り組みは技術的負債の解消だけではなく、AI活用やデータ利活用を支えるシステムの整備でもあったのです。

「捨てる」のではなく「残すものは残し、変えるべきものは変える」

　移行の進め方も興味深い点です。JFEスチールは汎用（はんよう）パッケージへの置き換えではなく、製造現場で培ってきた業務ロジックを維持、継承しながら、「COBOL」「PL/I」「アセンブラ」で記述されたメインフレーム向けプログラムをJavaベースに変換。社内クラウドインフラ「J-OSCloud」で稼働するオープンシステムに移行しました。

　このJFEスチールの事例は、「古いから捨てる」という発想ではなく、「蓄積してきた業務ノウハウを生かしながら、AIやデータ活用を見据えてシステムを刷新する」という考え方に基づく取り組みです。残すべきものは残し、変えるべきものは変える――。こうした考え方は、既存システムの見直しにおける一つの方向性を示しています。

• 参考記事：JFEスチールが「脱メインフレーム」、全製鉄所の“基幹系オープン化”を2年前倒し（＠IT）

オフコンも終わっていない　残り続ける「AS/400」

　オフコンを利用する企業の間でも、技術者不足や製品ライフサイクルの変化を背景に、システムの将来を見直す動きが続いています。特に存在感が大きいのが、IBM製のオフコン「AS/400」（現「IBM i」）です。

　1988年の登場から30年以上がたった2026年時点でも、AS/400は製造や金融、流通など幅広い業種で稼働しています。システム開発を手掛けるオーエムネットワークの調査によると、基幹業務にAS/400を利用する国内企業は約2万社に上ります。

RPG技術者が高年齢化　「移行したくてもできない」現実

　AS/400を維持する企業が直面する課題の中で、特に深刻なのが「RPG」技術者の不足です。オーエムネットワークの推計によると、AS/400向けのプログラミング言語であるRPGの技術者は平均年齢が50歳を超えており、人材の高年齢化と属人化が進んでいます。

　RPGは若手エンジニアが業務で触れる機会が限られることに加えて、習得には特有の知識や経験が求められることから、新たな技術者を育成しにくいといわれています。その結果、移行の必要性を認識しながらも実行できなかったり、システムを維持したくても保守担当者を確保できなかったりする企業があります。外部委託への依存が進めば、保守コストが増大しかねません。

生成AIは“レガシー維持”にも使われ始めた

　生成AIは、こうした課題の解決策になる可能性があります。生成AIというと、新しい業務やシステムへの活用が注目されがちです。実は既存システムを維持するための手段としても、生成AIを活用しようとする動きがあります。

「1週間弱かかっていた作業」が生成AIで「4時間」に

　オーエムネットワークは、Anthropicの生成AIツール「Claude Code」をRPGプログラム開発に活用する検証に取り組んでいます。銀行マスター保守プログラム（約700行）の開発を対象とした検証によると、従来は合計4〜6日を要していた作業が、Claude Codeの活用によって約4時間で完了したといいます（図）。

図　従来の人手作業と生成AIによる開発効率の比較（出典：オーエムネットワークのプレスリリース）《クリックで拡大》

　内訳を見ると、2〜3日かかっていた初期コーディングは約30分に、1〜2日を要していたデバッグや調整は2〜3時間に縮まりました。半日〜1日かかっていたドキュメント作成も数分で完了したとのことです。

AIは“万能薬”ではなく、可能性を広げる手段に

　オーエムネットワークは、生成AI活用の限界についても指摘しています。同社によると、最終的な検証や調整には人による確認が欠かせず、システムごとの固有の事情への対処や機密情報の取り扱いにも十分な配慮が必要です。

　生成AIなどのAIが、既存システムの維持に関する全ての課題を解決するわけではありません。それでも人材不足や保守負担の軽減に有効なのであれば、企業が取り得る選択肢が広がる可能性があります。AIはメインフレームやオフコンからの刷新を促す技術であると同時に、その維持を支援する技術にもなり得るのです。

• 参考記事：RPG技術者不足で「AS/400レガシーに触れない」――生成AIで解決できるか、その検証結果（＠IT）

“古いから悪”ではない　適切なシステムは「目的ベース」で考える

　以上を踏まえると、メインフレームやオフコンを巡る「刷新か、維持か」という判断の前提は、AI活用の広がりによって変わりつつあります。企業はシステムの特性や目的に応じて最適な選択を模索することが求められています。

　企業がAI活用やDXを推進する上で、オープンシステムが有力な選択肢であることに変わりはありません。オープンシステムはクラウドサービスとの連携や新技術の活用がしやすく、人材を確保しやすい利点があります。JFEスチールのように、AIやデータの活用を見据えてオープンシステムへの移行に取り組む企業も現れています。こうした移行ニーズは、今後も続くと考えるのが自然です。

　だからといって、あらゆるメインフレームやオフコンが即座にレガシーシステムになり、廃止対象になるという単純な話ではありません。IBMはメインフレームの開発を続けており、「Linux on IBM Z」のようにオープン技術との親和性を高める取り組みも進めています。

　特にメインフレームについては、信頼性や可用性、セキュリティを重視する重要なシステムにおいて、依然として有力な選択肢です。適切な運用や保守を継続でき、業務要件を満たしているのであれば、使い続けること自体が否定されるべきではないのです。

　メインフレームやオフコンを使い続ける場合には、システムをどう維持し続けるかが重要になります。その際に目指すべきなのは、単なる延命ではありません。必要に応じて生成AIなどの新しい技術を取り込みながら、業務の変化に応じて進化し続ける「生きたシステム」として維持することです。

　重要なのは、判断の軸です。「古いシステムか否か」ではなく、「自社が実現したいことに対して、現在のシステムが障壁になっていないかどうか」という視点で考える必要があります。新技術の活用が現行のシステムによって制約を受けていたり、保守人材の不足によってセキュリティやコストの問題が深刻化していたりする場合は、現在のシステムが適切かどうかをあらためて検討する必要があるでしょう。

　AI時代において、既存システムを見直す上での評価軸は変わりつつあります。「古いから悪い」でも「安定しているから問題ない」でもなく、「何を実現したいか」を起点に判断する。その実践が、今まさにIT部門に問われています。