レガシーシステム更改とは？｜考え方/特徴/仕組み/目的を解説

メインフレームやCOBOLで構築された基幹システムが老朽化しているのに、ベンダーの保守契約満了やOS・ミドルウェアのサポート終了（EOS/EOL）が迫るまで抜本的な対応に着手できていない企業は少なくありません。レガシーシステム更改とは、老朽化・ブラックボックス化した既存の基幹システムを、保守契約満了やEOS/EOLという外部から迫る期限までに新しい基盤へ移行し直す取り組みを指します。

本記事では、レガシーシステム更改の基本的な考え方と特徴、更改を先送りできない理由、標準的な仕組みと進め方、先送りした場合のリスク、更改の主な選択肢、導入目的や関連する取り組みとの違いを順に解説します。「モダナイゼーション」「刷新」「システム更改」といった似た言葉との違いに迷っている担当者の方でも、自社が今取り組むべきことを整理できるよう、実務の流れに沿って説明します。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・レガシーシステム更改の完全ガイド

レガシーシステム更改とは何か？全体像と特徴

レガシーシステム更改は、単に古いシステムを新しくするという広い意味の言葉ではなく、メインフレームやCOBOLで構築された具体的なレガシーシステムを対象に、保守契約満了やOS・ミドルウェアのEOS/EOLという外部から強制される期限に向けて実行する更改を指す点に特徴があります。似た用語が複数存在するため、まずは本記事群がどの領域を扱うのかを明確にしておきます。

レガシーシステム更改が扱うのは、抽象的な技術的負債の議論ではなく、実際に稼働しているメインフレームやCOBOL資産、あるいは長期間改修を重ねたオンプレミスの基幹システムです。担当者の異動や退職によって仕様書とソースコードの対応関係が失われ、改修のたびに影響範囲を推測しながら手直しするような状態になったシステムが典型例です。こうした具体的なシステムを前に、いつまでに何を決めるかという期限管理の問題として捉えることが、本テーマの出発点になります。

更改の対象になるのは基幹システム全体とは限りません。周辺のバッチ処理や帳票出力の仕組みだけが古いミドルウェアに依存しているケースもあれば、中核の勘定系・生産管理系のロジックそのものが老朽化しているケースもあります。自社のどの範囲が「レガシー化した具体的システム」に該当するのかを最初に特定しないまま検討を進めると、後工程の見積もりや体制づくりが的外れになりやすい点に注意が必要です。

「レガシーシステムのモダナイゼーション」は、技術的負債やブラックボックス化そのものをどう解消するか、リホスト・リプラットフォーム・リファクタリングといった手法（いわゆる5R）を中心に扱う領域です。「レガシーシステム刷新」は、老朽化した具体的システムを対象に、経営としていつ・なぜ着手するかという意思決定プロセスや稟議・予算承認、推進体制に重心を置きます。一方で「システム更改」は、保守サポート契約満了やハードウェアリース期限、EOS/EOLといった契約・ライフサイクル起点の総論を扱います。

本記事が扱う「レガシーシステム更改」は、これらの掛け合わせにあたります。すなわち、レガシー化した具体的システム（メインフレーム・COBOLシステムなど）を対象に、ベンダー保守契約満了やOS・ミドルウェアのEOS/EOLという外圧トリガーの具体性と、更改を先送りした場合のセキュリティリスク・障害時サポート不能リスクという期限管理の緊急性を軸に整理します。技術手法の詳細を知りたい場合はモダナイゼーションの解説記事を、経営判断のプロセスを詳しく知りたい場合は刷新の解説記事を、あわせて参照することをおすすめします。

更改を先送りできない理由：EOS/EOLという外圧

レガシーシステム更改が「先送りできない」性質を帯びるのは、判断の起点が自社の都合ではなく、ベンダーが定めるサポート終了時期にあるためです。大規模なハードウェアやソフトウェアのEOS/EOLは、通常サポート終了の3〜5年前にはベンダーからロードマップとともに公式アナウンスされるのが一般的で、直近の年表を押さえておくだけでも検討の緊急度を把握しやすくなります。

代表的なEOL時期としては、2023年10月10日にWindows Server 2012／2012 R2の延長サポートが終了し、2024年6月30日にCentOS 7のサポートが終了しています。さらに2025年10月14日にはWindows 10のサポートが終了しており、いわゆる「2027年問題」として知られるSAP ERP（ECC6.0）の標準保守サポート終了は2027年末に予定されています（条件によっては2030年まで延長できる場合もあります）。これらはあくまで代表例であり、自社が実際に利用している製品・バージョンごとのEOL時期は、各ベンダーの公式発表で個別に確認する必要があります。

EOLを過ぎたシステムは、新たに発見された脆弱性への修正パッチが提供されなくなり、セキュリティリスクが放置されたまま稼働を続けることになります。加えて、障害が発生した際にベンダーからの復旧支援を受けられず、長時間の業務停止に直結しかねない点も見過ごせません。EOLの時期を「まだ先の話」と捉えるのではなく、更改検討の起点として扱うことが重要です。

メインフレームやCOBOL資産の更改は、現状棚卸し、RFP作成、ベンダー選定、予算承認というリードタイムを含めると、実作業だけでも1年から数年を要します。そのため、EOLの通知を受け取ってから動き出すのではなく、最低でも2〜3年前には初期検討に着手することが望ましいとされています。同種の判断が必要になる「システム更改」全般でも、契約満了の1年〜1年半前、規模が大きい場合は2年前までに方針決定を終えるべきという見方が共通しており、期限管理の考え方として参考になります。

着手が遅れるほど選べる選択肢は狭まります。十分なリードタイムがあれば、パッケージ移行やフルスクラッチ再構築を含めた比較検討ができますが、期限が目前に迫ってからでは、暫定的な延命策に頼らざるを得なくなる可能性が高くなります。自社のEOL時期を確認したら、そこから逆算して初期検討の開始時期を社内で共有しておくことが実務上のポイントです。

レガシーシステム更改の仕組みと標準的な進め方

レガシーシステム更改は、思いつきで着手できる作業ではなく、現状把握から本番移行まで一定の順序を踏む必要があります。工程を大きく分けると、現状棚卸しと要件整理、ベンダー選定と契約、予算承認、開発・移行、本番切り替えという流れになり、それぞれの工程で確認すべき事項が異なります。

最初に行うのは、対象システムがどの範囲の業務を担い、どのハードウェア・ミドルウェア・言語に依存しているかを棚卸しすることです。ブラックボックス化が進んでいる場合は、コード解析ツールを使った依存関係の可視化や、業務有識者へのヒアリングを組み合わせて、移行時に影響が出る範囲を洗い出します。この段階の精度が甘いと、後工程の見積もりが実態とかけ離れ、期限に対して致命的な遅れを招く原因になります。

棚卸しの結果をもとに、パッケージ移行・クラウド移行・フルスクラッチ再構築といった選択肢の方向性を仮決めし、RFPを作成してベンダーへ提示します。ベンダー選定では、提案内容の網羅性だけでなく、メインフレームやCOBOL資産の移行実績、大量データを扱うバッチ処理の性能検証をどう行うか、移行後の保守体制まで含めて評価することが重要です。

更改には相応の投資が伴うため、情報システム部門だけで完結させることはできません。EOLによる事業影響、延命した場合のコスト、更改した場合の投資対効果を経営層に説明し、予算承認を得る必要があります。この際、なぜ今なのかという期限の根拠と、更改後にどのような業務価値が得られるのかをセットで提示できるかどうかが、承認の得やすさを左右します。

承認後は、開発・移行フェーズに入ります。ここでの進め方はパッケージ移行かフルスクラッチ再構築かによって大きく異なりますが、いずれの場合も、期限から逆算したスケジュールと、途中で問題が見つかった際の代替プランをあらかじめ用意しておくことが、計画倒れを防ぐうえで欠かせません。

更改を先送りした場合のリスクとコスト

「今のところ動いているから」という理由で更改を先送りすると、目に見えにくいコストとリスクが積み上がっていきます。セキュリティ面の危険と、金銭面の負担という二つの側面から整理しておくと、経営層への説明もしやすくなります。

EOLを迎えたOSやミドルウェアは、新たに発見された脆弱性に対する修正パッチが提供されなくなります。攻撃者はEOL製品を狙いやすいことを踏まえると、放置期間が長引くほど侵入や情報漏えいのリスクは高まっていきます。加えて、障害が発生した際にベンダーからの復旧支援を受けられないため、原因調査や復旧作業を自社だけで担わざるを得ず、業務停止が長時間化する可能性があります。

EOL後もベンダーが個別に提供する特別保守（延長サポート）は、通常保守費用と比べて高額になりやすく、対応範囲も限定的になりがちです。さらに、万一セキュリティインシデントが発生すれば、フォレンジック調査費用や損害賠償、ダウンタイムによる機会損失が発生し、更改にかかる投資を大きく上回る負担になりかねません。このため、「延長更新を続けるか、更改に踏み切るか」は、目先の費用比較ではなく、3〜5年程度のスパンでの総保有コスト（TCO）で比較し、累計コストが逆転する損益分岐点を経営陣に可視化して示すことが標準的なアプローチとされています。

レガシーシステム更改の主な選択肢

更改の選択肢は一つではありません。時間的な余裕やリスク許容度に応じて、当面の延命策を取る場合もあれば、抜本的な刷新に踏み切る場合もあります。ここでは代表的な選択肢を概観します。

ハードウェアリースが満了する場合、再リース・買い取り・入れ替えという三択が検討対象になります。再リースは年間費用を当初の10分の1程度に抑えられる一方、故障時の修理費が全額自己負担になる点がリスクです。買い取りは残存価値相当の一時費用で以降の月額負担がなくなりますが、修理費リスクは残ります。入れ替えは月額負担が最も高くなるものの、省電力性や最新のセキュリティ対応、メーカー保証によって潜在的なコストを抑えられる可能性があります。いずれも時間を稼ぐ選択肢であり、根本的なレガシー解消にはならない点を踏まえて選ぶ必要があります。

パッケージやクラウドサービスへの移行は、業務を標準機能に合わせる「Fit to Standard」が前提になるため、自社独自の業務ロジックをどこまで手放せるかが分岐点になります。一方、自社の業務ロジックが競争優位性に直結し、標準機能では代替できない場合は、フルスクラッチによる再構築が選択肢に上がります。どちらを選ぶにせよ、期限から逆算した際にウォーターフォール型の一括移行がデッドラインに間に合うか、段階移行やパイロット移行によってリスクを分散すべきかを、早い段階で見極めることが重要です。具体的な選択肢の比較軸は、レガシーシステム更改の選定ポイント・選び方・種類で詳しく解説しています。

導入目的と他の関連施策との違い

レガシーシステム更改の目的は、単にサポート切れを回避することだけではありません。セキュリティ水準の維持、コスト構造の適正化、そして更改を機に業務そのものを見直す機会として捉えることができます。あわせて、混同されやすい関連施策との違いも整理しておきます。

オンプレミスからクラウドへ更改する場合、サーバーの調達・保守にかかる初期投資（CAPEX）から、利用量に応じた運用費用（OPEX）へとコスト構造がシフトし、サーバー監視やOSアップデートといった運用の手間を削減できる可能性があります。一般に、新システムの運用保守費用は構築費用の10〜15%程度が相場とされており、更改前後でこの比率がどう変化するかも、投資対効果を測る材料になります。加えて、更改のタイミングで業務フローそのものを見直せば、単なる延命ではなく、新たな価値創出の機会として活用できる場合もあります。

あらためて整理すると、モダナイゼーションは技術手法（HOW）、刷新は経営判断（WHY・WHEN）、システム更改は契約・ライフサイクル起点の総論（一般的な外圧トリガー）を扱う概念です。レガシーシステム更改は、この三つの視点のうち「レガシー化した具体的システム」×「EOS/EOLという外圧トリガーの具体性」×「先送りした場合の期限管理の緊急性」を組み合わせた領域として位置づけられます。自社の課題がどの視点に近いかを確認することで、参照すべき情報や相談すべき相手を絞り込みやすくなります。

レガシーシステム更改を検討する前に確認しておきたいポイント

本格的な検討に入る前に、社内でよく議論になる論点を整理しておきます。棚卸しの範囲、期限までの時間が足りない場合の対応、部分的な対応でよいかどうかは、多くの企業が同じように悩むポイントです。

最低限、対象システムが依存するハードウェア・OS・ミドルウェア・言語のバージョンと、それぞれのEOL時期、システムが担う業務範囲、外部システムとの連携箇所は把握しておく必要があります。ブラックボックス化が進んでいる場合は、コード解析や有識者ヒアリングを組み合わせ、影響範囲を過小評価しないことが、後工程での手戻りを防ぐうえで重要です。

十分なリードタイムが確保できない場合は、まずEOLの緊急性が高いコア機能を先行して移行し、残りは既存環境で延命するという段階移行・並行移行が現実的な選択肢になります。あわせて、再リースや買い取りによる一時的な延命策を組み合わせ、抜本的な更改の準備期間を確保するという考え方もあります。いずれの場合も、暫定対応であることを社内で共有し、次のEOL期限を見据えたロードマップを別途用意しておくことが望まれます。

移行リスクが最も高いコア業務ロジックや他システム連携部分に対象を絞り込み、影響の小さい周辺機能は既存のまま残すという判断は十分に成立します。重要なのは、対象を絞る際に「移さない合理的な理由」を明文化しておくことです。あわせて、移行するデータについても必要最小限に絞り込み、何を残し何を移すのかの基準を関係者間で合意しておくと、後から対象範囲を巡る認識の食い違いを防げます。

まとめ

レガシーシステム更改は、メインフレームやCOBOLシステムなどレガシー化した具体的なシステムを対象に、ベンダー保守契約満了やOS・ミドルウェアのEOS/EOLという外部から迫る期限までに新しい基盤へ移行し直す取り組みです。先送りすればセキュリティ脆弱性の放置や障害時のサポート不能、特別保守費用の高騰といったリスクとコストが積み上がるため、期限から逆算した早期の検討着手が欠かせません。

技術的な老朽化の解消はモダナイゼーション、経営としての意思決定プロセスは刷新、契約・ライフサイクル起点の総論はシステム更改という関連領域があり、それぞれの詳しい解説へ役割分担していますが、本記事で扱った「レガシー×更改」の視点、すなわち具体的なレガシーシステムをEOS/EOLという外圧の期限までにどう更改するかという実務は、これらとは独立した検討軸として押さえておく必要があります。

自社が利用しているハードウェア・OS・ミドルウェアのEOL時期を確認し、そこから逆算して初期検討の着手時期を決めることが最初の一歩です。パッケージ移行で業務を標準化できる範囲と、独自の業務ロジックゆえにフルスクラッチで再構築すべき範囲を見極めることも欠かせません。riplaはフルスクラッチ開発の立場から、レガシー資産の棚卸しや移行リスクの整理、既存システムとの連携を含む更改の構築を支援しています。

▼全体ガイドの記事
・レガシーシステム更改の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。