レガシーシステムとは？「古い」だけでは決まらない判定基準と放置のリスク

レガシーシステムは、単に構築から年数が経過した情報システムを指す言葉ではありません。 経済産業省のレガシーシステムモダン化委員会総括レポートは、運用維持保守や機能改良が困難になり、経営や事業戦略の足かせ、または高コスト構造の原因となっているシステムと定義しています。 本記事でも、事業で使われているものの、許容できるコストとリスクで保守や変更を続けにくくなったシステムという意味で扱います。

同レポートは、古い技術で構築されていても、保守体制、仕様、データ連携、継続的な機能改良に問題がなければ、レガシーシステムではないと説明しています。 反対に、新しい基盤へ移行したシステムでも、運用維持保守に問題があれば再びレガシー化する可能性があります。 判定を分けるのは経過年数そのものではなく、保守と機能改良を継続できるか、それらの困難さが事業にどの程度影響するかです。

レガシーの本質は「安全に変更できないこと」

レガシー化には、技術と構造、知識と運用、経営と業務の要因が関わります。

どれか一つでも保守や機能改良を困難にすることがあり、複数が重なると影響範囲の調査、検証、復旧に必要な時間と費用を見積もりにくくなります。 技術が古くても、仕様を把握する人、テスト、復旧手順が揃っていれば、変更や移行を計画できます。 反対に、採用した技術が新しくても、担当者の退職後に仕様とテストが残っていなければ、改修前の解析から始めなければなりません。

ここでいう「安全に変更できない」は、コードを物理的に編集できないという意味ではありません。 影響範囲を事前に把握し、テストと切り戻しを計画し、必要な期間と費用を許容範囲で見積もることが難しい状態を指します。

技術的負債は、当時の判断や理解を反映した設計や実装が、将来の変更や保守に追加コストを生む状態を捉える比喩です。 その蓄積はレガシー化の一因になりますが、両者は同じではありません。 製品のサポート終了、保守要員の離脱、事業環境の変化でもレガシー化は起こります（技術的負債の解説）。

判定基準のチェックリスト

以下は公的な認定基準ではなく、保守と変更を難しくする兆候を棚卸しするための実務用チェックリストです。

EOLの確認では、複数製品のライフサイクル情報を集約したendoflife.dateのような一覧を、初期調査に利用できます。 ただし、同サイトは複数の情報源を集約するサービスであり、製品の公式情報そのものではありません。 EOL、EOS、保守終了といった用語の意味は提供者によって異なるため、セキュリティ更新が提供される期限を個別に確認します。 本番で動くランタイムとミドルウェアのバージョンを書き出し、期限切れを突き合わせます。 最終判断では、ベンダーや開発プロジェクトの公式ライフサイクルと、自社に適用される有償の延長サポート契約を確認します。

いくつ当てはまればレガシー、という閾値はありません。 件数だけで判定せず、各項目について対象資産、根拠、障害や変更への影響、暫定対策、対応期限、責任者を記録します。 これにより、「現場で直せる問題」と「体制や予算の意思決定が要る問題」を分けられます。

放置した場合の代表的な3つのリスク

セキュリティ

標準サポートが終了したソフトウェアには、通常のセキュリティ更新が原則として提供されなくなります。 有償の延長サポートや例外的な更新が提供される製品もあるため、実際の扱いは公式方針と契約で確認する必要があります。 NIST SP 800-40 Rev. 4は、EOLによってベンダーのサポートが終わると、脆弱性のパッチが公開されない場合があると説明しています。 同文書によれば、脆弱性が公知になると攻撃者が悪用手段を開発する可能性が高まり、一般にリスクは上昇します。 ネットワーク分離や機能の無効化は悪用可能性を下げますが、脆弱性そのものは除去しません。 更新、置換、廃止まで継続利用する場合は、代替統制と残存リスクの受容を明示して管理します。

保守体制が弱くなると、EOL以外のセキュリティ対策も滞りやすくなります。 不要な管理画面が公開されたまま、初期設定のまま運用されているといった問題はセキュリティミスコンフィグの典型です。 保守が止まった依存パッケージでは、脆弱性が見つかっても修正版が提供されず、別のパッケージへの置換が必要になる場合があります。 古いリポジトリでは、認証情報の混入を現在の検査基準で再点検する必要があります（シークレットの漏洩）。

事業

2018年に経済産業省が公表したDXレポートは、既存システムのブラックボックス化を解消できず、データ活用、保守要員の確保、セキュリティ対策などの課題を克服できない放置シナリオを示しました。 そのシナリオでは、2025年以降に最大12兆円/年（当時の約3倍）の経済損失が生じる可能性があると試算しています。 いわゆる「2025年の崖」です。 この金額は2018年時点の将来シナリオに基づく試算であり、2025年以降に実測された損失額ではありません。 日本全体の試算を個社へ単純に換算することもできません。

ただし、個社でもレガシー化が事業上の制約へ波及する経路は確認できます。 新機能の見積もりが出せない、他システムやSaaSと連携できない、データを取り出せないといった制約が、そのまま打てる施策の範囲を狭めます。 変更の調査と検証に時間がかかるほど、施策の着手から市場投入までのリードタイムも長くなります。

人材と事業継続

前述の2025年の総括レポートは、古い要素技術へ対応できる技術者が高齢化または離脱し、要員の確保が難しくなることをレガシー化の要因に挙げています。 対応できる人材が減ると、退職や委託終了の後に、障害復旧や機能改良を担う要員を補充しにくくなります。 知識が文書、テスト、復旧手順として組織に残っていなければ、担当者の離脱がサービス継続上のリスクになります。

AI活用でも差が出ます。 自動テストがなければ、AIが生成した変更による回帰の確認も手作業に依存します。 コード生成が速くなっても検証工程が短縮されないため、提供までの時間は同じ割合では縮まりません（テスト基盤の重要性）。

「2025年の崖」を過ぎた現在地

2025年という節目は過ぎましたが、この問題が終わったわけではありません。 経済産業省は2025年5月、経産省、デジタル庁、IPAを事務局とする委員会での議論をもとに、レガシーシステムモダン化委員会の総括レポートを公表しました。 同レポートは市場動向調査の分析から、経営層との情報共有やCxOの設置状況と、システム仕様の可視化や内製化の進み具合に有意な相関があることを示し、経営層の意識変革とITガバナンスの強化、情報システム部門の自律性、事業部門との連携などを対策の方向性として提示しています。 この分析は調査項目間の関連を示すものであり、CxOの設置や情報共有がモダン化を直接進めたという因果関係まで証明したものではありません。 そのうえで同レポートは、モダン化を技術部門だけに任せず、経営課題として扱うよう提言しています。

2026年5月には、IPAが同レポートの政策方針に基づき、組織連携、ITガバナンス、データ活用を可視化する3つの新指標案を公開しました。 これらは意見募集用のドラフトであり、確定した評価基準ではありません。 「2025年の崖」は特定の日に問題が発生するという予測ではなく、複数のリスクが2025年前後から高まる放置シナリオでした。 政策面の取り組みも続いています。

対応の入口

着手の順序は、判定と分類が先です。

1. 資産を棚卸しする：稼働中のシステム、構成要素、バージョン、依存関係、責任者を一覧にします。 把握されていないサーバやバッチを含め、評価対象を確定させます。
2. リスクと事業上の重要度で分類する：セキュリティ、障害、保守切れ、法令対応のリスクと、停止時の事業影響を評価します。 リスクと事業影響がともに大きい対象は優先度を上げます。 事業価値が低く維持リスクが高い対象は、依存関係とデータ保持義務を確認したうえで廃止候補にします。
3. 対応方針を選ぶ：現状維持、更新、基盤移行、構造改善、再構築、製品への置換、廃止などから方針を選びます。 方針ごとに必要な期間、体制、移行リスクが異なります。

3の選択肢の整理はモダナイゼーションで扱っています。 同じ製品を更新する場合でも、メジャーバージョンをまたぐと、機能の削除や既定値の変更への対応が必要になることがあります。

避けたいのは、順序を飛ばして「作り直すか、直し続けるか」から議論を始めることです。 対象と優先順位が定まらないうちは、どちらの案も見積もりの根拠を持てません。

関連して読める記事

レガシー対応は、現状の把握、方針の選択、移行の実行に分けて考えられます。 関連概念から確認する場合は、技術的負債の解説を参照してください。

技術的負債とは？「借金」の比喩の本来の意味と、返済の優先順位の付け方

技術的負債とは、短期には便益がある、または当時の理解では妥当だった設計や実装が、将来の変更や保守に追加コストを生む状態を捉える比喩です。Ward Cunninghamによる比喩の初出とFowlerの4象限を原典に沿って整理し、利子が変更リードタイムや障害という形で現れる構造、経営への翻訳のしかた、変更頻度×変更コストで返す場所を選ぶ優先順位の付け方、AI時代に増えやすい理解負債までを解説します。

2026年7月29日

モダナイゼーションとは？クラウド移行の7Rと選び方の基準

モダナイゼーションとは、既存のアプリケーション、インフラ、開発運用プロセスを更新し、事業や運用上の成果を改善していく取り組みです。クラウド移行との違いを整理したうえで、AWSが定義する7つの移行戦略（7R）を原典に沿って表で解説し、事業価値や変更頻度だけでは決まらない選び方の判断材料、ストラングラーフィグによる段階移行、成果指標から始める進め方と注意点までをまとめます。

2026年7月29日

リファクタリングとリライト（作り直し）の違い：分岐条件と、リライトが失敗しやすい理由

リファクタリングは外部から見た振る舞いを変えずに内部構造を改善する作業、リライトは実装を新たに作って置き換えることです。この2つはリスクの形も前提条件も違います。Joel Spolskyの古典が指摘した全面リライトの2つのリスク（暗黙の仕様の喪失・追いかけ続ける本番）、リファクタリングで足りる条件とリライトに寄る条件の分岐、ストラングラーフィグによる中間の道、どちらでも先に必要になる投資までを整理します。

2026年7月29日

CTOが今期決めるべきサプライチェーン攻撃対策——発見・抑制・ダメージコントロールの3層設計

npmのサプライチェーン攻撃は2025年以降、毎月の定常イベントになりました。悪意あるコードはCVEが付く前に正規の新バージョンとして配布されるため、脆弱性スキャンやDependabotでは防げません。抑制・発見・ダメージコントロールの3層の防衛線を、ツール購買ではなく開発標準の設計問題として、CTO・開発責任者向けに解説します。

2026年7月19日

「動けばいい」運用は、AI 駆動開発で半年もたない

AI 駆動開発で生産性が出るかどうかは、ツールでもエンジニアのスキルでもなく、自動テストが回せているかで決まります。「動けばいい」運用が AI 時代に半年でボトルネック化する構造と、CXO・VPoE が今打つべき手を整理します。

2026年6月7日