日立メインフレームOS「VOS3」販売終了へ｜販売2027年11月・保守2034年12月——国産2社の撤退期限が出揃った

結論：富士通に続き日立も期限を切った。「自社にホストはない」会社も、つながっている先の刷新の余波を受ける

日立製作所は2026年5月29日、メインフレーム向けOS 「VOS3」システムの販売を2027年11月、保守を2034年12月に終了する と公表した。VOS3/XS製品ページには同日付で「AP10000とVOS3システムの販売終了に関するお知らせ」が掲示されている。2022年2月に富士通がメインフレーム（GS21）の販売終息2030年度・保守終了2035年度末を公表しており、国産メインフレーム主要2社の「終わりの日付」がこれで出揃った。日経xTECHは「日立がメインフレーム撤退へ」「地銀勘定系も転換点」と報じている（二次情報）。

重要なのは、この発表が「日立ホストを使っている会社」だけの話ではないことだ。勘定系・基幹系がVOS3で動く銀行や大企業が2034年12月までに刷新へ動けば、そこにEDI・データ連携・帳票仕様でつながっている取引先・グループ会社には、連携仕様変更という形で必ず余波が来る。保守終了まで8年強あるが、基幹刷新は計画から本番まで数年単位を要する。「まだ先」ではなく「もう逆算が始まっている」期限である。

押さえるべき1点：保守終了2034年12月は「使い続けられる期限」ではなく「刷新を終えていなければならない期限」だ。大規模基幹の移行は数年かかるため、実務上の意思決定期限はそれよりはるかに手前にある。

国産メインフレーム撤退年表：何がいつ終わるか

日立の公式発表と、既に公表済みの富士通のスケジュールを並べると次のとおりだ。

日立の一次掲示（2026年5月29日付）の文言は「VOS3システムの販売を2027年11月、保守を2034年12月に終了します」であり、同時に、ミッションクリティカルシステムの構築・運用とAI活用のノウハウを結集した「モダナイゼーション powered by Lumada」を強化すると表明している。つまり日立自身が、VOS3ユーザーの行き先を「延命」ではなく「モダナイゼーション」に置いている。

なお日経xTECHによれば、日立はメインフレームのハードウェア製造からは既に撤退しており、2018年度以降はIBMのOEM製品を販売してきた。今回終了するのは自社開発を続けてきたOS側であり、これで 国内でメインフレームを提供し続ける主要ベンダーは実質IBMとNECに絞られる と報じられている（いずれも二次情報）。富士通側の期限と移行方式の詳細は富士通メインフレーム撤退と基幹システム刷新2026で整理している。

なぜ「自社にホストがなくても」自社事なのか

この発表を「うちはオープン系だから関係ない」と読み流すのは早い。余波は3つの経路で来る。

第一に、親システム刷新に伴う連携仕様の変更だ。 VOS3上の基幹が銀行・親会社・業界共同センターで動いている場合、その刷新プロジェクトは周辺の取引先に、全銀手順やレガシーEDIの見直し、ファイル連携・帳票フォーマットの変更、接続方式の切り替えを要求する。自社システムが古いままだと、この「受け側改修」が突発の強制イベントになる。

第二に、ベンダー・人材リソースの争奪だ。 日立系・富士通系のユーザーが同じ期限帯（2034年12月／2035年度末）に向けて一斉に動くため、メインフレーム移行を担えるエンジニアとSIerの供給は逼迫していく。後から動く企業ほど、単価・納期・選択肢のすべてで不利になる。

第三に、自社内の「小さなVOS3」だ。 ホストそのものはなくても、ホスト世代の設計思想を引き継いだ塩漬けの基幹・固定長連携・夜間バッチ群を抱える企業は多い。ベンダーが期限を切った今回のような節目は、自社のレガシー資産に同じ問い——「これは誰がいつまで保守してくれるのか」——を立てる機会である。延命かリプレースかの判断軸はレガシーシステムの延命 vs リプレース判断フローが参考になる。

今月やるべき棚卸し：5つの確認手順

1. 自社・グループ内のVOS3／メインフレーム資産の有無を確認する。 情シスだけでなく、子会社・工場・経理部門が個別契約しているケースを含めて洗い出す。
2. 「つながっている先」を一覧化する。 銀行・親会社・共同センター・主要取引先とのEDI／ファイル連携／帳票連携を列挙し、相手側ホストの世代を保守ベンダーに照会する。
3. 連携仕様変更の通知窓口を確認する。 相手先の刷新計画が動いたとき、自社に通知が来る contractual な経路（契約・覚書・連絡体制）があるかを確かめる。
4. 自社レガシー資産の保守期限を台帳化する。 OS・ミドルウェア・パッケージ・保守契約の期限を一枚にまとめる。やり方はメインフレーム棚卸し完全ガイド2026で詳説している。
5. 刷新の意思決定期限を逆算して経営に上げる。 保守終了から、並行稼働・開発・要件定義・方式選定の所要を引き算し、「いつまでに決めるか」を日付で示す。

チェックの勘所：棚卸しの目的は「移行するかどうか」の判断材料を揃えることではない。期限が公式に確定した以上、判断すべきは「いつ・どの方式で」だ。問いの立て方を間違えると、検討だけで1年消える。

よくある質問（FAQ）

Q. 保守終了は2034年12月。8年もあるのに、なぜ今動く必要があるのか？ A. 大規模基幹の移行は、現状把握→方式選定→要件定義→開発・データ移行→並行稼働で数年単位かかるのが通例だからだ。さらに富士通ユーザーの移行需要と期限帯が重なるため、後発ほどベンダー・人材の確保が難しくなる。8年は「待てる時間」ではなく「使い切る時間」である。

Q. 自社は日立ホストを使っていない。何か対応は必要か？ A. 直接の対応義務はない。ただし取引先・親会社・利用している共同センターがVOS3で動いている場合、その刷新に伴う連携仕様変更（EDI・ファイル連携・帳票）が数年内に自社へ波及し得る。「つながっている先」の棚卸しだけは今やっておくべきだ。

Q. 移行先はどう考えればよいか？ A. 定石はリホスト（資産を活かして載せ替え）／リライト（言語変換）／リビルド（再構築）／パッケージ・SaaSの4方式で、業務ごとの使い分けが現実的だ。日立自身も移行支援の方向として「モダナイゼーション powered by Lumada」の強化を掲げており、選択肢は広がっている。方式比較は富士通メインフレーム撤退と基幹システム刷新2026を参照してほしい。

Q. 基幹パッケージ側にも同様の期限はあるのか？ A. ある。SAP ECCの2027年問題が代表で、メインフレームに限らず「ベンダーが期限を切る」動きは基幹レイヤー全体で進んでいる。SAP ECC 2027 EOL問題で詳説している。

発注・更改判断に落とすための確認観点

システム開発や基盤更改の記事を読むときは、ニュースそのものよりも自社の要件に変換できるかが重要である。確認すべきは、対象システム、利用部門、業務影響、現行保守の期限、データ移行の難易度、権限・ログ・監査要件、移行中の業務継続方法である。

特にRFPや要件定義では、製品名やベンダー名を先に書くと比較が歪む。先に書くべきなのは、処理量、可用性、権限、監査、移行制約、運用体制である。ニュースをきっかけに検討を始める場合でも、発注書には自社の制約条件を具体化して入れる必要がある。

GXOへ相談する前に整理しておくと早い情報

相談前には、現行システムの概要、利用人数、主要業務、連携先、保守期限、障害履歴、困っている改修、予算感、希望時期をまとめる。詳細な仕様書がなくても、画面・帳票・データの棚卸しから要件を復元できる。

90日で要件定義へ進めるロードマップ

最初の30日は、現行業務と現行システムの棚卸しに使う。画面、帳票、データ、連携、利用者、例外処理、障害履歴を整理し、どの業務が止まると事業影響が大きいかを確認する。古いシステムほど仕様書よりも現場の運用が正になっているため、担当者ヒアリングも必要である。

31日目から60日目は、刷新・更改の目的を決める。保守期限への対応だけなのか、業務改善、データ活用、AI導入、セキュリティ強化まで含めるのかで、要件は大きく変わる。ここで目的を広げすぎると失敗するため、必須要件と将来要件を分ける。

61日目から90日目は、RFPまたは要件定義書に落とす。機能一覧だけでなく、権限、ログ、監査、非機能、移行、テスト、保守、運用体制を含める。ニュースを見て急いで製品選定に入るより、この90日を使って発注側の物差しを整える方が、失敗コストは小さい。

よくある失敗パターン

第一の失敗は、ニュースをきっかけに製品選定から始めることだ。製品名を先に決めると、要件定義が後付けになり、現行業務の例外や移行制約が漏れる。まず現行業務、データ、権限、帳票、連携、非機能を整理する必要がある。

第二の失敗は、移行を軽く見ることだ。新システムを作るより、現行データを正しく移し、業務を止めずに切り替え、利用者を教育する方が難しいことが多い。移行方式、並行稼働、切り戻し、移行後の照合を要件に入れない発注は危険である。

第三の失敗は、保守運用を見積もりから外すことだ。システムは公開して終わりではない。権限変更、法改正、障害、脆弱性、データ増加、連携先変更に対応する体制が必要になる。初期開発費だけで比較すると、運用で破綻する。

成果物として残すべきもの

発注前には、業務フロー、機能一覧、権限マトリクス、帳票一覧、データ一覧、連携一覧、非機能要件、移行方針、受入テスト方針を残す。完璧な仕様書でなくても、これらがあるだけで見積もりの精度とベンダー比較の質は大きく上がる。

いつGXOに相談すべきか

• ホストやレガシー基幹の 資産・連携・保守期限の棚卸しから着手したい が、社内に進め方の知見がない
• 取引先・親会社の刷新に伴う EDI・連携仕様変更の受け側改修 を、場当たりでなく自社基幹の刷新計画とセットで設計したい
• リホスト／リライト／リビルド／パッケージの 方式選定と概算費用を、特定ベンダーに依存しない立場で 比較検討したい

GXOはレガシーシステム刷新で現行資産の可視化から移行方式選定・開発・移行までを伴走し、データ活用基盤構築で脱ホスト後のデータ移行・活用設計を、DX/システム開発で周辺システムの再構築を支援している。期限が確定した今こそ、構想段階の相談から始めてほしい。→ 相談はこちら

関連記事

• 富士通メインフレーム撤退と基幹システム刷新2026｜2030年度終了・COBOL移行の進め方と費用
• メインフレーム棚卸し完全ガイド2026｜ブラックボックスを経営に説明する3ステップ
• レガシーシステムの延命 vs リプレース判断フロー｜投資判断8軸
• SAP ECC 2027 EOL問題｜S/4HANA移行の費用とタイムライン

編集部注：公開後の更新方針

本記事は速報性のある公開情報をもとに、GXOの商談領域であるシステム開発、AI導入、セキュリティ、レガシー刷新、データ基盤構築の観点へ翻訳したものである。公開後に一次情報の更新、ベンダー側の追記、制度要件の変更、悪用状況の変化が確認された場合は、本文・参考資料・CTAの導線を更新する。

読者が実務で使う場合は、記事の数値や期限を固定値として扱うのではなく、必ず一次情報と自社環境を突き合わせることが重要である。特に、契約条件、対象バージョン、制度要件、提供リージョン、価格、悪用状況は短期間で変わり得る。この記事の役割は、最新情報を自社の判断項目へ変換することであり、最終判断は一次情報と社内の対象有無確認にもとづいて行う。

参考資料

• 日立製作所「VOS3/XS」製品ページ（2026年5月29日付お知らせ「AP10000とVOS3システムの販売終了に関するお知らせ」掲載）
• 日立製作所「AIを徹底活用し、お客さまの基幹システムのモダナイゼーションを加速」（2026年5月29日。「VOS3システムの販売を2027年11月、保守を2034年12月に終了します」）
• 富士通「メインフレーム／UNIXサーバの今後の方針」（2022年2月14日）
• 日経xTECH「日立、メインフレーム向けOS開発を終了へ システム販売は2027年まで」（二次情報）
• 日経xTECH「日立がメインフレーム撤退へ、『VOS3』販売終了 地銀勘定系も転換点」（二次情報）

本記事は2026年6月12日時点の公開情報をもとに作成。日立のハードウェア製造撤退・IBM OEM・残存ベンダー状況に関する記述は日経xTECHの報道（二次情報）に基づく。販売・保守終了の時期や移行支援策は今後更新される可能性があるため、日立公式の一次情報の最新版を必ず確認すること。