NECがACOS向けストレージを刷新、富士通は2035年度末で保守終了｜レガシー刷新の期限を決めているのは自社ではない

結論：自社の基幹機の提供元が「続ける側」か「畳む側」かで、動き出すべき時期が10年変わる

NECが2026年7月24日、ACOSメインフレーム用ストレージの新モデル「iStorage A5400」を発表しました。前モデルA5200と比べ、IOPS性能は約1.5倍（150万IOPS）、内部のクロスバー帯域は約2倍、ホスト接続ポートは128本から192本へ1.5倍に拡張されています。最新世代のXeon-SP 20コアCPUを搭載し、ACOS用ドライブの容量は最大1.2TB、最大装置容量は404,505GB（約404TB）に達します。報道ではレプリケーション機能の強化（セミ同期の順序保証バッファの拡大）も伝えられています。

この発表が示しているのは、NECがメインフレーム事業に投資を続けているという事実です。周辺機器の性能を上げ、信頼性の機能を追加するという行為は、その基盤を今後も使い続けてもらうという前提がなければ成立しません。

一方、同じ国内メーカーである富士通は、2022年にメインフレーム事業からの撤退を表明しています。製造・販売は2030年度末で終了、保守サポートは2035年度末で終了する方針が公表されています。UNIXサーバのSPARC M12についても、2029年度下期に販売終了、2034年度中に保守終了とされています。これがいわゆる「2035年の崖」です。日立製作所やBIPROGYは、メインフレーム事業を継続する立場とされています。

つまり、同じ「基幹業務を動かしている専用機」であっても、提供元によって残された時間がまったく違うということです。

そして、レガシー刷新の議論で最も欠けているのがこの視点です。多くの企業は「そろそろ刷新しないと」という漠然とした危機感で議論を始めます。しかし、動き出すべき時期を決めているのは自社の危機感ではなく、メーカーが公表しているサポート終了時期です。

3行サマリー（先に結論）

• NECは2026年7月24日にACOS向けストレージの新モデルを発表し、メインフレーム基盤への投資を継続。日立・BIPROGYも事業を継続する立場とされる。
• 富士通はメインフレームを2030年度末で製造・販売終了、2035年度末で保守終了。UNIXサーバも2034年度中に保守終了の方針。
• したがって最初にやるべきは、自社の基幹機のメーカーと保守終了時期を確認し、そこから逆算して「いつ動き出すか」を決めること。

要点表：メーカー別のスタンス

※各社の方針は変更される可能性があります。自社の契約機種の正確なサポート期限は、必ずメーカーの公式情報および保守契約書でご確認ください。

まずやること：自社の基幹機の「終了予定日」を確認する

驚かれるかもしれませんが、自社の基幹システムが何のハードウェアの上で動いていて、そのサポートがいつまでなのかを即答できない企業は、決して少なくありません。導入から20年以上経過している場合、当時を知る社員が誰も残っていないことも普通にあります。

確認の手順は次のとおりです。

手順1：機器を特定する 保守契約書、年次の保守請求書、資産台帳を確認します。メーカー名と機種名（型番）が分かれば十分です。現物のラベルからも確認できます。

手順2：保守契約の内容を確認する 契約書に記載された保守期間、契約更新の条件、対応レベル（オンサイト対応の有無、対応時間帯）を確認します。

手順3：メーカーの公表情報を確認する その機種のサポート終了予定時期を、メーカーの製品情報ページで確認します。分からなければ、保守を担当しているベンダーに文書で照会してください。

手順4：日付を経営カレンダーに書き込む 確認できた終了時期を、経営会議で使う年度計画表に書き込みます。ここまでやって初めて、期限が経営の議題になります。

この4手順は、合計で数日の作業です。にもかかわらず実行されていない理由は明快で、誰の担当でもないからです。情シスがいれば情シスの仕事ですが、いない企業では総務にも経理にも属さない宙ぶらりんの作業になります。経営者が指示を出さない限り、誰も動きません。

保守終了から逆算する

サポート終了時期が分かったら、そこから逆算します。基幹システムの移行は、決断から完了まで想像より長い時間を要します。

この表を、富士通のメインフレームを使っている企業に当てはめてみます。保守終了は2035年度末（2036年3月）です。移行に4年かかると見るなら、着手は2032年。現行システムの調査から始めるなら、その前年には方針を決めておく必要があります。

一見、まだ余裕があるように見えます。しかし、次の要素を考慮すると印象が変わります。

• 技術者の確保が年々難しくなる：現行システムを理解できる技術者は減り続けます。移行を担える人材の獲得競争は、期限が近づくほど激化します。
• 同時期に多数の企業が動く：期限が同じである以上、駆け込みが発生します。ベンダーの受注枠が埋まり、価格も上がります。
• 社内の有識者が退職する：現行システムの仕様を知る社員が定年を迎えると、調査の難度が跳ね上がります。

つまり、期限ぎりぎりに動くほど、費用は上がり、選択肢は減るという構造です。逆算した着手時期より、さらに1〜2年前倒しで検討を始めるのが実務的な判断になります。

「続ける側」のメーカーでも安心はできない

NECや日立の機器を使っている企業は、期限に追われていません。これは大きな利点です。時間をかけて検討でき、駆け込み需要を避けられます。

ただし、メーカーが事業を続けることと、自社が困らないことは別です。次のリスクは、メーカーの方針とは無関係に進行します。

リスク1：技術者の高齢化 COBOLやアセンブラで書かれた業務ロジックを理解できる技術者は、社内でもベンダー側でも高齢化が進んでいます。あと何年、その人たちに頼れるのかは、メーカーの方針では決まりません。

リスク2：業務ロジックの属人化 仕様書が更新されておらず、「動いているコードだけが仕様」という状態はよくあります。その状態で担当者が退職すると、システムの変更ができなくなります。

リスク3：外部連携の要求に応えられない 取引先からのEDI（電子データ交換）の仕様変更、インボイス制度のような法改正、データ活用のためのデータ連携。外部からの要求に対して、改修に時間と費用がかかりすぎる状態が続くと、事業機会を逃します。

リスク4：改修費用の高止まり 扱える技術者が減れば、単価は上がります。同じ改修でも、10年前より高い見積もりが出てくる状況が進行します。

したがって、「続ける側」のメーカーを使っている企業がやるべきことは、期限に追われた移行ではなく、業務ロジックの可視化と、外部連携できる状態の確保です。ハードウェアを替えなくても、この2つには着手できます。

延命が正解になる条件

刷新を煽る記事が多いなかで、公平に書いておきます。次の条件が揃うなら、延命という判断は経営として合理的です。

• サポート終了まで十分な期間があり、その間の保守費用が許容範囲にある。
• 現行システムが業務上の制約になっておらず、事業成長の足を引っ張っていない。
• 数年以内に事業構造の大きな変更（M&A、事業売却、業態転換）が見込まれ、そのあとに刷新したほうが合理的。
• 移行に投じる資金を、より収益に直結する投資へ回す明確な計画がある。

ただし、延命を選ぶ場合には条件が付きます。次の3つを並行して進めることです。

1. 業務ロジックの文書化（動いているコードから仕様を起こす作業）。
2. 現行システムからデータを取り出せる経路の確保。
3. 移行の準備資金の積み立てと、着手時期の明文化。

これらをやらずに延命すると、期限が近づいたときに「調査から始めなければならない」状態になり、結局は高くつきます。延命は「何もしない」ことではありません。

移行の選択肢を、費用と期間の観点で並べる

メインフレームやオフコンからの移行には、いくつかの型があります。どれが正解かは自社の状況で決まりますが、選択肢の性質を知らないまま提案を受けると、比較ができません。

型1：ハードウェアだけ替える（リホスト）

既存のプログラムをほぼそのまま、別の基盤（オープン系サーバやクラウド）の上で動かす方式です。専用の実行環境やエミュレータを使います。

• 期間：比較的短い。
• 費用：初期費用は抑えられる傾向。
• 残る課題：業務ロジックは古いままで、扱える技術者の問題は解決しない。延命の色合いが強い。
• 向いている状況：期限が迫っており、まず基盤の制約から抜けたい場合。

型2：プログラムを機械変換する（リライト）

既存のCOBOL等のプログラムを、ツールを使って別の言語へ自動変換する方式です。

• 期間：中程度。
• 費用：本数と複雑さに比例。変換後の検証費用が大きい。
• 残る課題：変換されたコードは読みにくいことが多く、その後の保守性が改善しない場合がある。
• 向いている状況：業務ロジックを変えたくないが、基盤も言語も新しくしたい場合。

型3：作り直す（リビルド）

業務要件から見直し、新しく設計・開発する方式です。

• 期間：長い。
• 費用：最も高い。
• 得られるもの：業務の見直しと、保守しやすいシステム。
• 向いている状況：現行システムが事業の足を引っ張っており、業務ごと変えたい場合。

型4：パッケージ・SaaSに載せ替える

既製のERPパッケージやクラウドサービスへ業務を移す方式です。

• 期間：中〜長。業務変更の合意形成に時間がかかる。
• 費用：初期費用は型3より抑えられることが多いが、業務変更の負荷は大きい。
• 得られるもの：ベンダーによる継続的な機能追加とサポート。
• 向いている状況：業務を標準的なやり方に合わせられる場合。

実際の案件では、業務領域ごとに型を使い分けます。「基幹の受発注は型4でパッケージへ、独自性の高い生産管理は型3で作り直し、当面残す周辺業務は型1で延命」という組み合わせが現実的です。

選択の順序

大切なのは、型を先に決めないことです。まず現行システムに何があるかを調べ、業務ごとの重要度と独自性を評価し、その結果として型が決まります。「うちはリホストで行きます」と先に決めてから調査を始めると、調査の結果が判断に反映されません。

現行システムの調査を、どう進めるか

移行の入口は、例外なく現行調査です。資料がない状態からどう進めるかを示します。

調査1：動いているものを数える

プログラム、バッチ処理（夜間に自動で動く処理）、帳票、画面、外部との連携。それぞれの本数を数えます。この数字が、移行費用の概算の基礎になります。

調査2：使われているものを絞る

数えたもののうち、実際に使われているものを特定します。実行ログが取れれば実測で、取れなければ所管部署へのヒアリングで判断します。長年運用されたシステムでは、動いているが誰も結果を見ていない処理が相当数見つかります。

調査3：業務との対応をつける

各処理が、どの業務のどの場面で使われているかを記録します。ここは技術者だけではできず、業務を知っている人の参加が必須です。

調査4：外部との接続を洗い出す

取引先とのデータ交換、銀行との接続、他システムとの連携。移行時に相手方の対応が必要になるものは、早期に把握しておく必要があります。相手方の都合で調整に時間がかかるためです。

調査5：業務ロジックの記録

計算式、判定条件、例外処理。プログラムの中にしかない知識を文書化します。この作業が最も時間がかかり、最も価値があります。

調査にかかる期間と費用

規模によりますが、中堅企業の基幹システムで数ヶ月から1年、費用は数百万円規模になることが一般的です。「調査だけでそんなにかかるのか」と感じられるかもしれませんが、調査をせずに見積もりを取ると、見積もり側もリスクを織り込んで高くなります。結果として、調査を先行させたほうが総額は抑えられることが多いのです。

また、調査結果は複数のベンダーに同じ条件で提示できるため、比較可能な見積もりが得られます。これも調査を先行させる実利です。

人材の問題は、期限より先に来る

最後に、期限の議論とは別の時間軸について触れます。

現行システムを理解している人材の在籍年数です。多くの中堅企業で、基幹システムの仕様を把握しているのは特定の1〜2名であり、その人たちの年齢は高い傾向にあります。

確認しておくべきこと

• 現行システムの業務ロジックを説明できる社員は何名いるか。
• その人たちの定年、または退職予定はいつか。
• ベンダー側で自社の案件を担当している技術者は何名で、その体制は今後どうなるか。

もし「あと3年で主要な担当者が定年を迎える」なら、メーカーのサポート期限より、そちらのほうが先に来る期限です。この場合、移行そのものを急ぐかどうかは別として、業務ロジックの記録だけは先に着手すべきです。

記録の作業は、移行を決めていなくても価値があります。移行するときの調査費用が下がり、しない場合でも属人化のリスクが下がります。そして何より、その人が在籍しているうちにしかできません。

ベンダーに聞くべきこと

現行システムの保守を委託しているベンダーに、次を文書で照会してください。口頭ではなく文書で残すことに意味があります。

1. 当社が使用している機種のサポート終了予定時期はいつか。ハードウェア、OS、ミドルウェアそれぞれについて。
2. サポート終了後の延長保守の提供有無、提供される場合の条件と費用。
3. 現行システムの構成資料（プログラム一覧、ジョブ一覧、データ項目定義）は提供可能か。
4. 現行システムを理解している技術者は現在何名で、今後の体制はどうなる見込みか。
5. 移行を検討する場合、貴社としてどのような選択肢を提示できるか。

3番目と4番目が特に重要です。資料がない、技術者が減っているという回答が返ってきたなら、それ自体が「早く動くべき」という強いシグナルです。

なお、5番目の回答は参考程度に扱ってください。現行ベンダーは、自社が対応できる移行方式を提案する傾向があります。それが自社にとって最適とは限りません。移行方式の選定は、複数の視点で検討すべき領域です。

FAQ

Q1. 自社の機器がどのメーカーか分かりません。 A. 保守請求書の宛名か、機器本体のラベルで分かります。それでも不明なら、経理に保守費用の支払先を確認してください。そこが起点になります。

Q2. オフコンやAS/400も同じ考え方でよいですか。 A. はい。メーカーの製品ロードマップとサポート終了時期を確認し、そこから逆算する手順は共通です。IBM系（IBM i）については、別途ハードウェアの世代ごとのサポート終了時期があるため、そちらも確認が必要です。

Q3. 移行にはどのくらいの費用がかかりますか。 A. 規模と方式で大きく異なるため、一般論では示せません。ただし、現行システムの調査（棚卸し）だけを先行して行い、その結果を持って見積もりを取ると、金額の精度が上がります。

Q4. 全面刷新以外の選択肢はありますか。 A. あります。既存の資産を変換して新しい環境へ移す方式、既存システムは残しつつ外部からデータ連携できるようにする方式、業務単位で段階的に切り出す方式など複数あります。どれが適するかは、現行システムの状態と事業の優先度で決まります。

Q5. 技術者がいない状態で移行を進められますか。 A. 外部の支援が前提になります。ただし、業務の仕様を判断できる社内の人は必要です。「何をどう処理しているか」の判断を全て外部に委ねると、移行後に業務が回らなくなります。

Q6. まだ先の話なので、来年考えればよいですか。 A. 逆算表に自社の期限を当てはめてみてください。それで余裕があるなら、来年でも構いません。ただし、現行システムの資料の有無と、有識者の在籍年数だけは今年のうちに確認しておくべきです。

Q7. メーカーの方針は変わりませんか。 A. 変わる可能性はあります。延長される場合も、逆に前倒しされる場合もあります。だからこそ、方針の変更を待つのではなく、自社の計画を持っておくことが重要です。

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

次のいずれかに当てはまるなら、期限に追われる前の整理をおすすめします。

• 自社の基幹システムのサポート終了時期を把握できていない。
• 刷新すべきか延命すべきか、判断の材料が揃っていない。
• 現行ベンダーからの提案しか受けておらず、他の選択肢を知りたい。
• 現行システムの仕様を知る社員が退職を控えている。

GXOは特定のハードウェア・パッケージを販売する立場ではないため、現行ベンダーの提案を含めて第三者の目で比較できます。現行システムの棚卸しと移行計画の立案、移行方式の比較検討はシステム開発・DXの相談、移行後を見据えたデータ活用の設計はデータ基盤・データ活用の相談、投資判断そのものの整理はAI導入診断、現状の全体把握から始めたい場合はDX成熟度診断が入口です。サポート期限の確認と逆算表づくりからでもお受けします。ご用命はお問い合わせまで。

レガシー刷新は、決断が遅れるほど選択肢が減り、費用が上がる種類の投資です。期限を決めているのが自社でない以上、まず確認すべきはその期限がいつなのか、という一点です。

参考文献

• IT Leaders「NEC、ACOSメインフレーム用ストレージ新モデル『iStorage A5400』」（二次・報道）: https://it.impress.co.jp/articles/-/29621
• 富士通「富士通メインフレームに関するお客様へのお約束」（一次・メーカー公式）: https://www.fujitsu.com/jp/products/computing/servers/mainframe/gs21/topics/fujitsu-3promise.html

※各メーカーの製品ロードマップおよびサポート終了時期は、今後変更される可能性があります。自社の契約機種については、メーカーの公式情報と保守契約書を一次情報としてご確認ください。執筆時点は2026年7月24日で、以降の発表は反映していません。