「レガシーシステムという言葉を聞くが、うちのシステムはレガシーなのか」「レガシーシステムとは具体的にどんな状態を指すのか」「レガシーシステムの何が問題なのか、経営的に整理したい」——こうした疑問を持つ経営者向けに、本記事では専門用語を使わずに レガシーシステムの定義・特徴・問題点・脱却の第一歩 を整理します。
『自社のシステムがレガシーかどうか、経営的に判断したい』とお悩みですか？ 25 年の経験で現状整理を一緒に進めます。 無料相談 ＞レガシーシステムとは何ですか？｜一言で答える
一言で言うと、レガシーシステムとは 「老朽化・複雑化・ブラックボックス化が進み、現代のビジネス要件や技術環境に対応しにくくなった結果、保守・改修・活用が難しくなったシステム」 です。
経済産業省の DX レポートでは、レガシーシステムについて、技術的老朽化、機能的老朽化、複雑化、ブラックボックス化などにより、維持・活用が困難になるシステム として説明されています（出典：経済産業省サイト）。
ポイントは 「古ければレガシー」ではない ことです。構築から年数が経っていても、適切に保守・更新されていれば「レガシー」とは呼びません。問題は 「老朽化・複雑化・ブラックボックス化の程度と、保守・改修・活用の難しさ」 です。
レガシーシステムとはどういう意味ですか？｜「レガシー」の語源
「レガシー（Legacy）」は英語で「遺産」「引き継がれたもの」を意味します。IT 分野では、過去から引き継いだシステムのうち、現代の業務要件や技術環境に合わなくなり、保守・改修・活用が難しくなったもの を指すことが多いです。
自社システムがレガシーかどうかの判断基準 5 つ
「うちのシステムはレガシーか？」を判断するための 5 つの基準を示します。
| # | 判断基準 | 具体的な状態 | 該当すれば |
|---|---|---|---|
| 1 | 技術の老朽化 | COBOL で開発されており、対応できる人材・ベンダー・ドキュメントが限られている。メインフレーム・オフコン上で動作しており、ハードウェア保守、技術者確保、外部連携に課題が出ている。サポートが終了した OS やデータベースを使用している | 🔴 要確認：レガシー化している可能性が高い |
| 2 | 機能の老朽化 | 業務が変化したのにシステムが追いつかず、Excel での補完が常態化している | 🔴 要確認：レガシー化している可能性が高い |
| 3 | 複雑化 | 長年の改修でプログラムが複雑に絡み合い、修正の影響範囲が分かりにくい | 🟡 要注意 |
| 4 | ブラックボックス化 | 「なぜそう動くのか分かる人が限られる」処理が存在する。ドキュメントがない・古い | 🟡 要注意 |
| 5 | 保守性の低下 | 対応できるベンダーが限られる・改修コストが上振れしやすい | 🟡 要注意 |
目安として、🔴 が 1 つ以上、または 🟡 が 3 つ以上に当てはまる場合は、レガシー化が進んでいる可能性があります。実際の優先度は、システムの重要度、外部接続、保守体制、業務影響によって判断する必要があります。
レガシーシステムの問題点とは？
レガシーシステムの問題点は、技術的な問題ではなく 経営問題として現れます。
問題点 1：保守・改修コストが上振れしやすい
対応できる技術者が限られ、改修時の調査工数が増えると、保守・改修費が上振れしやすくなります。年間改修費が、目安として初期構築費の 15% 前後 に達している場合は、刷新を検討するタイミングの一つです。
問題点 2：ビジネス変化に追従しにくい
新製品投入・新規事業参入・取引先からの EDI・API 連携要件など、現代のビジネス要求に対応するために「システム的に難しい」という壁が生まれることがあります。
問題点 3：担当者退職で「誰も触れない状態」に近づく
システムを熟知した担当者が退職すると、障害対応や改修の難易度・費用・期間が大きく上がる可能性 があります。「誰も触れない状態」に近づいたシステムが稼働し続けるリスクです。
問題点 4：セキュリティリスクが高まりやすい
サポートが終了した OS やミドルウェアの上で動くシステムは、セキュリティパッチが提供されない場合があります。既知の脆弱性が残ることで、サイバー攻撃や情報漏えいのリスクが高まりやすくなります。
問題点 5：IT 人材の採用・定着で不利になりやすい
古い技術環境しかない会社と見られると、若手エンジニアや IT 系人材の採用・定着で不利になりやすくなります。結果として、将来の業務改善・デジタル化への対応能力が低下する可能性があります。
レガシーシステムの代表例は？
日本の中堅企業で、レガシー化しやすいシステムの代表例 を整理します。なお、以下に該当するだけで必ず問題があるわけではなく、保守体制・ドキュメント・サポート状況・業務影響を合わせて判断する必要があります。
| システム種別 | 代表的な状態 | 典型的な問題 |
|---|---|---|
| COBOL で開発された基幹システム | 1980～1990 年代に開発、改修を繰り返して現在も稼働 | COBOL 技術者の確保難、ドキュメント不足、改修時の調査工数増加 |
| メインフレーム・オフコン上のシステム | 富士通・NEC のオフコン、IBM i（旧 AS/400）系の環境などで稼働し、ハードウェア保守期限や技術者確保が課題になっている | ハードウェア保守期限のリスク・移行技術者の確保が難しい |
| 旧バージョンの Windows Server 上のシステム | Windows Server 2008/2012 など、公式サポート期限を確認すべき旧バージョン上のシステム | セキュリティリスク・サポート状態の確認が必要 |
| Access・Excel VBA で作られた業務システム | 担当者が自作した Excel マクロ・Access が「基幹業務化」している | 担当者退職で運用困難、拡張性・同時利用・バックアップ・アクセス管理に課題が出やすい |
| スクラッチ開発の古い Web システム | 2000 年代に開発、フレームワーク・言語が現在のエンジニアに馴染みがない | 保守できるエンジニアの確保が難しくなる、セキュリティ脆弱性が残りやすい |
レガシーシステムを使い続けるとどうなる？
段階的に状況が悪化する可能性があります。
- 短期（1～3 年）：改修コストが上振れしやすくなる。小さな改修でも影響調査に時間がかかる
- 中期（3～5 年）：担当者の退職リスクが現実化し、ビジネス機会損失が積み上がる可能性
- 長期（5 年以上）：「誰も触れない状態」に近づいたシステムが稼働し続ける。移行したいと思った時点で、現行解析からやり直す必要があり、費用・期間・難易度が大きく上がるリスク
経済産業省の「2025 年の崖」が警告したのは、こうした長期放置によって、レガシーシステム問題が経営上の大きな制約になるリスクです。
レガシーシステム脱却の第一歩
レガシーシステムから脱却するための第一歩は、3 つあります。
- 自社システムの棚卸し：稼働中のシステム一覧、構築年、保守担当者の退職タイミング、年間保守費を表にまとめる。簡易棚卸しであれば、情シスと業務部門が連携して 1～2 週間程度で一覧化できる場合があります。外部費用は原則不要ですが、社内工数は発生します。システム数が多い場合や資料が不足している場合は、より長い期間や外部支援が必要になることがあります
- 判断基準 5 つでの評価：本記事の判断基準に照らし合わせ、どのシステムでレガシー化リスクが高いかを評価する
- 移行計画の初期立案：リスク、業務影響、移行難易度、費用を見ながら、どのシステムから着手するかの大枠を経営判断として整理 する
まとめ｜「動いているシステム」がレガシーでないとは限らない
- レガシーシステムとは：老朽化・複雑化・ブラックボックス化が進み、現代のビジネス要件・技術に対応しにくくなった結果、保守・改修・活用が難しくなったシステム
- 判断基準 5 つ：技術老朽化・機能老朽化・複雑化・ブラックボックス化・保守性低下。目安として、🔴 1 つ以上または 🟡 3 つ以上に該当する場合は、レガシー化が進んでいる可能性があります
- 問題点：コストの上振れ・ビジネス変化への追従の難しさ・担当者退職リスク・セキュリティリスク・人材採用の不利
- 脱却の第一歩：棚卸し → 評価 → 移行計画の大枠整理 の 3 ステップ。最初の簡易棚卸しは、外部費用をかけずに社内工数中心で始められる場合があります
株式会社クオンツでは、『自社システムのレガシー状態の整理』『棚卸しと優先度評価の支援』『レガシーシステム脱却計画の立案』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社の規模・業種・システム状況に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
