レガシーシステム更改とは、老朽化・ブラックボックス化した既存の基幹システムを、保守契約の満了やEOS/EOLという外部から迫る期限までに、新しい基盤へ移す取り組みです。
基幹業務を止めない移行計画を、期限から逆算して早めに整える必要があります。
- 期限：保守契約とEOS/EOLの条件
- 移行：方式選定から本番切り替えまで
- リスク：先送りの影響と更改の目的
本テーマの全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・レガシーシステム更改の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム更改の全体像と特徴
レガシーシステム更改は、メインフレームやCOBOLで構築されたレガシーシステムを対象に、保守契約の満了やOS・ミドルウェアのEOS/EOLという外部から強制される期限に向けて行う更改です。
単に古いシステムを新しくするという広い意味とは違い、対象と期限が具体的に定まっている点が特徴です。似た用語が多いため、どの領域の話かを先に押さえておくことが大切です。
対象は「レガシー化した具体的システム」
レガシーシステム更改が扱うのは、技術的負債の一般論ではなく、実際に稼働しているメインフレームやCOBOL資産、あるいは長期間改修を重ねたオンプレミスの基幹システムです。担当者の異動や退職によって仕様書とソースコードの対応関係が失われ、改修のたびに影響範囲を推測しながら手直しするような状態になったシステムが典型例です。
更改の対象は、基幹システム全体とは限りません。たとえば、周辺のバッチ処理や帳票出力の仕組みだけが古いミドルウェアに依存しているケースもあれば、中核の勘定系・生産管理系のロジックそのものが老朽化しているケースもあります。
自社のどの範囲が「レガシー化した具体的システム」に当たるのかを最初に特定しないまま検討を進めると、後工程の見積もりや体制づくりが的外れになりやすい点に注意が必要です。そのうえで、いつまでに何を決めるかという期限管理の問題として捉えることが、本テーマの出発点になります。
モダナイゼーション・刷新・システム更改との役割の違い
いずれも老朽化したシステムの見直しに関わりますが、技術・経営・契約のどの視点を中心に置くかが異なります。
- モダナイゼーション：技術的負債やブラックボックス化をどう解消するかを扱い、リホスト・リプラットフォーム・リファクタリングなどの手法（いわゆる5R）が中心です。
- 刷新：老朽化した具体的システムを対象に、経営としていつ・なぜ着手するかという意思決定や稟議・予算承認、推進体制に重心を置きます。
- システム更改：保守サポート契約満了やハードウェアリース期限、EOS/EOLといった契約・ライフサイクル起点の総論を扱います。
「レガシーシステム更改」は、これらを組み合わせた領域にあたります。
この領域では、メインフレームやCOBOLなど具体的なシステムを対象に、保守契約満了やEOS/EOLという外圧の期限を軸として捉えます。更改を先送りすると、EOLを過ぎたシステムには脆弱性への修正パッチが提供されず、障害時もベンダーの復旧支援を受けられないため、期限管理の緊急性が増していきます。
技術手法の詳細はモダナイゼーションの解説記事を、経営判断のプロセスは刷新の解説記事を、あわせて参照することをおすすめします。
更改を先送りできない理由：EOS/EOLという外圧
レガシーシステム更改が「先送りできない」性質を帯びるのは、判断の起点が自社の都合ではなく、ベンダーが定めるサポート終了時期にあるためです。
大規模なハードウェアやソフトウェアのEOS/EOLは、通常サポート終了の3〜5年前にベンダーからロードマップとともに公式に案内されるのが一般的です。
直近の年表を押さえておくだけでも、検討の緊急度を把握できます。
直近のEOS/EOL年表
OSのサポート終了は、次の例のように製品ごとに時期が異なります。
- 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の時期は「まだ先の話」ではなく、更改検討の起点として扱うことが重要です。
検討着手の目安はEOLの2〜3年前
メインフレームやCOBOL資産の更改は、現状の洗い出しからベンダー選定、予算承認までのリードタイムを含めると、実作業だけでも1年から数年を要します。そのため、EOLの通知を受けてから動くのではなく、最低でも2〜3年前には初期検討に着手することが望ましいとされています。
着手が遅れるほど、選べる選択肢は狭まります。十分なリードタイムがあれば、パッケージ移行やフルスクラッチ再構築を含めた比較検討ができますが、期限が目前に迫ると、暫定的な延命策に頼らざるを得ない可能性が高くなります。
同種の判断が必要になる「システム更改」全般でも、契約満了の1年〜1年半前、規模が大きい場合は2年前までに方針決定を終えるべきという見方が共通しており、期限管理の考え方として参考になります。そのうえで、自社のEOL時期を確認したら、そこから逆算して初期検討の開始時期を社内で共有しておくことが大切です。
レガシーシステム更改の仕組みと標準的な進め方
レガシーシステム更改は、思いつきで着手できる作業ではなく、現状把握から本番移行まで一定の順序を踏む必要があります。
工程は大きく分けると、まず現状を洗い出して要件を整理し、次にベンダー選定と契約へ進みます。そのあと、予算承認、開発・移行、本番切り替えと続きます。工程ごとに確認すべき事項も異なります。
現状棚卸しからベンダー選定までの流れ
最初に行うのは、対象システムがどの範囲の業務を担い、どのハードウェア・ミドルウェア・言語に依存しているかを洗い出すことです。ブラックボックス化が進んでいる場合は、コード解析ツールで依存関係を調べ、業務有識者にもヒアリングして、移行時に影響が出る範囲を押さえます。
この段階の精度が甘いと、後工程の見積もりが実態とかけ離れ、期限に対して致命的な遅れを招きます。洗い出した結果をもとに、パッケージ移行・クラウド移行・フルスクラッチ再構築といった選択肢の方向性を仮決めし、RFPを作成してベンダーへ提示します。
ベンダー選定では、提案内容の網羅性だけでなく、移行後の保守体制まで含めて評価することが重要です。特に、メインフレームやCOBOL資産の移行実績と、大量データを扱うバッチ処理の性能検証をどう行うかを確認します。
予算承認と経営判断のプロセス
更改には相応の投資が伴うため、情報システム部門だけでは進められません。EOLによる事業影響、延命した場合のコスト、更改した場合の投資対効果を経営層に説明し、予算承認を得る必要があります。
なぜ今なのかという期限の根拠と、更改後にどのような業務価値が得られるのかをセットで提示できるかどうかが、承認の得やすさを左右します。
承認後は、開発・移行フェーズに入ります。ここでの進め方は、パッケージ移行かフルスクラッチ再構築かによって大きく異なります。いずれの場合も、期限から逆算したスケジュールと、途中で問題が見つかった際の代替プランをあらかじめ用意しておくことが、計画倒れを防ぐうえで欠かせません。
更改を先送りした場合のリスクとコスト
「今のところ動いているから」という理由で更改を先送りすると、目に見えにくいコストとリスクが積み上がっていきます。
セキュリティ面の危険と金銭面の負担という二つの側面から整理しておくと、経営層への説明もしやすくなります。
セキュリティ脆弱性放置と障害対応不能のリスク
EOLを迎えたOSやミドルウェアは、新たに見つかった脆弱性に対する修正パッチが提供されなくなります。攻撃者はEOL製品を狙いやすいため、放置期間が長引くほど、侵入や情報漏えいのリスクは高まっていきます。障害が発生した際にも、ベンダーからの復旧支援を受けられないため、原因調査や復旧を自社だけで担わざるを得ず、業務停止が長時間化するおそれがあります。
特別保守費用の高騰とTCOで比較する視点
EOL後もベンダーが個別に提供する特別保守（延長サポート）は、通常保守費用と比べて高額になりやすく、対応範囲も限られがちです。
セキュリティインシデントが万一起きれば、フォレンジック調査費用や損害賠償、ダウンタイムによる機会損失が生じ、更改の投資を大きく上回る負担になりかねません。
そのため、延長更新を続けるか更改に踏み切るかは、目先の費用ではなく、3〜5年程度のスパンの総保有コスト（TCO）で比べるのが標準的な考え方とされています。そのうえで、累計コストが逆転する損益分岐点を経営陣に示すことが大切です。
レガシーシステム更改の主な選択肢
更改の選択肢は複数あり、時間的な余裕やリスク許容度に応じて選び分けます。当面の延命策を取る場合もあれば、抜本的な刷新に踏み切る場合もあります。
延長保守・再リース・買い取りという延命策
ハードウェアリースが満了する場合は、再リース・買い取り・入れ替えという三つの選択肢が検討対象になります。再リースは年間費用を当初の10分の1程度に抑えられる一方、故障時の修理費が全額自己負担になる点がリスクです。
買い取りは残存価値相当の一時費用で以降の月額負担がなくなりますが、修理費リスクは残ります。入れ替えは月額負担が最も高くなるものの、省電力性や最新のセキュリティ対応、メーカー保証によって、長期的なコストを抑えられる可能性があります。
いずれも時間を稼ぐ選択肢であり、根本的なレガシー解消にはならない点を踏まえて選ぶ必要があります。
パッケージ移行とフルスクラッチ再構築という抜本策
パッケージやクラウドサービスへの移行は、業務を標準機能に合わせる「Fit to Standard」が前提になるため、自社独自の業務ロジックをどこまで手放せるかが分岐点になります。一方、自社の業務ロジックが競争優位性に直結し、標準機能では代替できない場合は、フルスクラッチによる再構築が選択肢に上がります。
どちらを選ぶにせよ、期限から逆算して、ウォーターフォール型の一括移行がデッドラインに間に合うかを見極める必要があります。そのうえで、段階移行やパイロット移行によってリスクを分散すべきかも、早い段階で判断することが大切です。
具体的な選択肢の比較軸は、レガシーシステム更改の選定ポイント・選び方・種類で詳しく解説しています。
導入目的と他の関連施策との違い
レガシーシステム更改の目的は、サポート切れの回避に加えて、セキュリティ水準の維持、コスト構造の適正化、そして更改を機に業務を見直す機会を得ることにあります。
更改の目的：コスト適正化とリスク回避にとどまらない効果
オンプレミスからクラウドへ更改する場合、サーバーの調達・保守にかかる初期投資（CAPEX）から、利用量に応じた運用費用（OPEX）へとコスト構造が移ります。加えて、サーバー監視やOSアップデートといった運用の手間を減らせる可能性があります。
一般に、新システムの運用保守費用は構築費用の10〜15%程度が相場とされており、更改前後でこの比率がどう変わるかも、投資対効果を測る材料になります。
業務フローそのものも、更改のタイミングで見直せば、単なる延命ではなく、新たな価値創出の機会として活用できる場合もあります。
モダナイゼーション・刷新・システム更改との違い
改めて比べると、モダナイゼーションは技術手法（HOW）、刷新は経営判断（WHY・WHEN）、システム更改は契約・ライフサイクル起点の総論（一般的な外圧トリガー）を扱う概念です。
レガシーシステム更改は、「レガシー化した具体的システム」「EOS/EOLという外圧の具体性」「先送りした場合の期限管理の緊急性」を組み合わせた領域として位置づけられます。
自社の課題がどの視点に近いかを確認することで、参照すべき情報や相談すべき相手を絞り込みやすくなります。
レガシーシステム更改を検討する前に確認しておきたいポイント
本格的な検討に入る前に、社内で議論になりやすい論点があります。棚卸しの範囲、期限までの時間が足りない場合の対応、部分的な対応でよいかどうかは、多くの企業が同じように悩む論点です。
現行システムの棚卸しの範囲
最低限、対象システムが依存するハードウェア・OS・ミドルウェア・言語のバージョンと、それぞれのEOL時期は把握しておく必要があります。加えて、システムが担う業務範囲と外部システムとの連携箇所も押さえておきます。
ブラックボックス化が進んでいる場合は、コード解析や有識者へのヒアリングを組み合わせ、影響範囲を小さく見積もらないことが、後工程での手戻りを防ぐ助けになります。
EOLまで時間がない場合の対応
十分なリードタイムが確保できない場合は、まずEOLの緊急性が高いコア機能を先行して移行し、残りは既存環境で延命する段階移行・並行移行が現実的な選択肢になります。
あわせて、再リースや買い取りによる一時的な延命策を組み合わせ、抜本的な更改の準備期間を確保するという考え方もあります。
いずれの場合も、暫定対応であることを社内で共有し、次のEOL期限を見据えたロードマップを別途用意しておくことが望まれます。
部分的な対応の考え方
移行リスクが最も高いコア業務ロジックや他システム連携の部分に対象を絞り、影響の小さい周辺機能は既存のまま残す判断も、十分に成り立ちます。そのうえで、対象を絞る際には「移さない合理的な理由」を明文化しておく必要があります。
移行するデータも必要最小限に絞り、何を残し何を移すかの基準を関係者間で合意しておくと、後から対象範囲をめぐる認識のずれを防げます。
まとめ
レガシーシステム更改は、メインフレームやCOBOLシステムなど、レガシー化した具体的なシステムを、保守契約満了やEOS/EOLという外部から迫る期限までに新しい基盤へ移す取り組みです。
先送りすれば、セキュリティ脆弱性の放置や障害時のサポート不能、特別保守費用の高騰といったリスクとコストが積み上がるため、期限から逆算した早期の検討着手が求められます。
「レガシー」と「更改」を分けて考える視点
技術的な老朽化の解消はモダナイゼーション、経営としての意思決定は刷新、契約・ライフサイクル起点の総論はシステム更改が扱い、それぞれ役割を分担しています。本記事で扱った「レガシー×更改」の実務、つまり具体的なシステムをEOS/EOLの期限までにどう更改するかは、これらとは独立した検討軸として押さえておく必要があります。
自社のEOL時期と棚卸し状況の確認
自社のハードウェア・OS・ミドルウェアのEOL時期を確認し、そこから逆算して着手時期を決めることが最初の一歩です。あわせて、パッケージ移行で標準化できる業務と、独自の業務ロジックゆえにフルスクラッチで再構築すべき範囲を見極めます。riplaはフルスクラッチ開発の立場から、既存システムとの連携を含む更改の構築や、移行リスクの整理を支援しています。
▼全体ガイドの記事
・レガシーシステム更改の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。