「この基幹システムは20年以上使っている。そろそろ刷新した方がよいのではないか」。長期間稼働しているシステムを持つ企業では、このような議論が起こります。
一方で、現場からは「現在も安定して動いている」「大きな障害もない」「新しくすると業務が止まる方が怖い」という意見が出ることもあります。
どちらも無視できない視点です。しかし、システムの刷新時期を「何年間使ったか」だけで決めることは適切とは限りません。
経済産業省も、稼働年数や利用技術が古い場合であっても、必ずしもレガシーシステムではないと整理しています。問題となるのは、システムが老朽化・複雑化し、必要な変更や維持を適切なスピードや経済性で行えなくなっている状態です（経済産業省, 2024）。
本記事では、古さそのものではなく、事業への影響、保守性、セキュリティ、維持・変更コスト、データ連携、将来の事業要求などから、レガシーシステムの刷新を判断する考え方を整理します。
古いシステム＝レガシーシステムではない
構築から長い年月が経過していることは、確認すべき一つの情報です。ただし、年数そのものが刷新理由になるわけではありません。
例えば、古い技術で構築されていても、保守できる技術者がおり、必要なセキュリティ更新ができ、障害時に復旧でき、事業上必要な変更にも対応できるのであれば、継続利用が合理的な場合があります。
逆に、比較的新しいシステムでも、仕様がブラックボックス化し、小さな変更に長期間を要し、特定ベンダーへ強く依存しているのであれば、レガシー化の問題を抱えている可能性があります。
20年使っていても安定稼働している架空例
説明用の架空例として、ある製造業が約20年前に構築した受発注・生産関連の基幹システムを現在も利用しているとします。
日常業務は安定しており、大規模障害も頻発していません。現場の利用者は操作に慣れ、現在必要な基本機能も満たしています。
この情報だけでは、「20年使ったので全面刷新すべき」とは判断できません。
追加で確認したいのは、OS・データベース・ミドルウェアのサポート状況、ハードウェアの交換可能性、保守人材、仕様書やソースコード、テスト環境、改修に必要な期間、セキュリティ更新、バックアップと復旧、外部システムとの連携、今後必要になる機能などです。
これらに大きな問題がなく、事業の変化にも追従できるのであれば、年数だけを理由に全面刷新する優先度は低い可能性があります。
一方、現在は安定稼働していても、主要な構成要素のサポートが終了し、仕様を理解する担当者が1名しかおらず、新機能追加に長期間を要し、API連携が難しく、障害時の復旧テストも実施していないのであれば、現在の安定性とは別の将来リスクがあります。
レガシーシステムを評価する8つの視点
| 評価視点 | 主な確認事項 |
|---|---|
| 1. 業務上の重要性 | 停止時の売上、顧客、操業、法令・内部統制への影響 |
| 2. サポート継続性 | EOL・EOS、ベンダーサポート、ハードウェア・部品調達 |
| 3. 保守・変更容易性 | 仕様書、テスト、複雑性、変更に要する期間 |
| 4. 人材・依存関係 | 属人化、ベンダー依存、技術者確保、知識移転 |
| 5. セキュリティ・復旧性 | パッチ、認証、ログ、バックアップ、復旧手順 |
| 6. コスト | 保守、インフラ、ライセンス、社内運用、変更費 |
| 7. データ・連携 | API、データ出力、他システム連携、マスタ・データ品質 |
| 8. 将来の事業適合性 | 新規事業、M&A、拠点追加、データ活用、拡張性 |
重要なのは、これらを一つの独自スコアへ無理に集約しないことです。同じ技術的問題でも、そのシステムが担う業務によって事業への影響は変わります。
最初に「止まったら何が起こるか」を整理し、その上で技術・運用上の問題を見る方が、経営判断につなげやすくなります。
現在安定しているかと、将来維持できるかは別
過去数年間に大きな障害がなかったことは、重要な実績です。しかし、過去の安定稼働だけでは将来の維持可能性までは説明できません。
例えば、主要製品のサポート終了、交換部品の入手困難、担当技術者の退職、セキュリティパッチ適用不能などは、現在の稼働率にはまだ現れていないリスクです。
さらに、障害が発生していないことと、障害後に復旧できることも別です。重要システムでは、バックアップが存在するだけでなく、復元可能か、手順が更新されているか、必要な目標復旧時間・目標復旧時点に対応できるかを確認します。復旧計画を準備・テスト・改善することは、情報システムのレジリエンスにおける重要な要素です（Bartock et al., 2016）。
保守費だけでなく「変更コスト」を見る
レガシーシステムの評価では、毎年支払っている保守契約費だけを比較しがちです。
しかし、日常運用の費用が比較的低くても、新しい帳票を追加するだけで数か月かかる、法改正対応のたびに大規模なテストが必要になる、新サービスとの連携に個別開発が必要になる、といった状態では、事業変化への対応コストが蓄積します。
技術的負債は単に「古い技術を使っている」という意味ではありません。設計・実装・運用上の過去の選択によって、将来の変更や開発を難しくする負担として捉える方が実務的です（Kruchten et al., 2012）。
そのため、現行システムの評価では、保守費に加えて、変更に必要な期間、改修・テスト工数、手作業による回避策、障害対応工数なども確認します。
古いシステムがある場合は、IT資産台帳の「稼働年数」の右側に、「業務停止時の影響」「サポート終了」「変更にかかる時間」「年間維持費」「特定担当者への依存」という列を追加してみてください。「古い」という情報だけでは見えなかった刷新理由、あるいは継続できる理由を整理しやすくなります。
EOL・人材・ベンダー依存をどう評価するか
EOL（End of Life）やEOS（End of Support）は重要な確認事項ですが、サポート終了だけを理由に必ず全面刷新するわけではありません。
対象システムの事業上の重要性、延長サポートの有無、部分的なバージョンアップ、ネットワーク分離等の代替策、残存期間などを踏まえて対応を考えます。
人材面でも同様です。特定技術を扱える人が少ないだけでなく、「この担当者がいなければ仕様変更も復旧もできない」という状態になっていないかを確認します。
ベンダー依存についても、依存自体をゼロにすることが目的ではありません。どの設計・仕様・運用を自社が理解しており、どの部分をベンダーへ依存しているのかを説明できる状態にすることが重要です。
セキュリティと事業継続リスクを確認する
古いシステムでは、新しい認証方式、暗号化、ログ取得、脆弱性対応等へ対応しにくい場合があります。
ただし、「古いから危険」と一括りにせず、実際にどの脆弱性や制約があり、ネットワーク構成、アクセス制御、監視、代替策によってどこまでリスクを管理できているかを確認します。
また、サイバー攻撃だけでなく、ハードウェア故障、災害、操作ミス等から復旧できるかも確認対象です。重要な業務を支えるシステムであるほど、障害の発生可能性だけではなく、発生した場合の事業影響と復旧能力を合わせて評価します。
全面刷新だけが選択肢ではない
レガシー化の問題が見つかっても、対応策は全面刷新だけではありません。
| 選択肢 | 考え方 |
|---|---|
| 継続 | 現行システムを維持し、リスクを監視する |
| 部分改善 | セキュリティ、インフラ、文書化、テスト環境など問題箇所を改善する |
| モダナイゼーション | システムの構造や運用を段階的に改善する |
| 置換 | パッケージ、SaaS、新規システム等へ移行する |
| 廃止 | 業務や機能自体を整理し、システムを終了する |
例えば、サポート終了が問題なら基盤部分を先に更新する、データ連携が課題ならAPI層を追加する、仕様のブラックボックス化が問題なら文書化やテスト整備から進める、といった対応も考えられます。
また、クラウドへ移行することとモダナイゼーションも同義ではありません。既存構造をそのまま移せば、技術的負債や複雑な業務ロジックが残る場合があります。
刷新プロジェクト自体のリスクも評価する
現行システムを使い続けるリスクだけを整理すると、全面刷新が常に合理的に見えてしまいます。
しかし、長期間利用した基幹システムでは、文書化されていない仕様や現場独自の運用が蓄積している場合があります。
刷新プロジェクトでは、要件漏れ、データ移行、切替、並行稼働、利用者教育、コスト超過等のリスクも考慮します。現在のシステムを残すリスクと、新システムへ移行するリスクの双方を比較することが必要です。
経済産業省・IPAのモダナイゼーションに関する近年の議論でも、単に新しい技術へ置き換えるだけでなく、IT資産を可視化し、経営・事業側と情報システム部門で課題認識を共有することが重視されています（経済産業省, 2025）。
システム刷新の優先順位をどう決めるか
複数の古いシステムが存在する企業では、すべてを同時に刷新するのではなく、システムポートフォリオとして優先順位を整理します。
この図は機械的な判定表ではありません。「右上だから必ず全面刷新」と決めるのではなく、経営・事業・IT部門が優先順位を議論するための整理軸として利用します。
また、「刷新しない」という判断も記録します。なぜ継続するのか、どのリスクを受容しているのか、EOL、担当者退職、新規事業など何を契機に再評価するのかを残しておくと、数年後の判断をしやすくなります。
レガシーシステム評価チェックリスト
| 確認項目 | 確認内容 |
|---|---|
| 業務影響 | 停止した場合の業務・顧客・売上への影響を説明できるか |
| サポート | OS・DB・ミドルウェア・ハードウェアのEOL・EOSを把握しているか |
| 変更容易性 | 小規模な機能変更に必要な期間・工数を把握しているか |
| 文書・テスト | 仕様、ソース、テスト環境・手順が管理されているか |
| 人材 | 特定担当者・ベンダーだけが理解する状態になっていないか |
| セキュリティ | 必要なパッチ、認証、ログ、脆弱性対応が可能か |
| 復旧 | バックアップだけでなく復元手順を確認・テストしているか |
| コスト | 保守費だけでなく社内運用・変更費も把握しているか |
| データ | 必要なデータを取得・活用できるか |
| 連携 | 新しいシステムやサービスとの連携が事業を阻害していないか |
| 将来要求 | 今後の事業計画に必要な機能・拡張へ対応できるか |
| 刷新リスク | データ移行、切替、隠れた仕様等の移行リスクを確認したか |
| 判断理由 | 維持・改善・刷新等を選んだ理由を記録しているか |
| 再評価 | 次に判断を見直す契機を決めているか |
「2025年の崖」は刷新期限ではない
レガシーシステムを検討するとき、「2025年の崖」という言葉を目にすることがあります。
これは経済産業省が2018年のDXレポートで、複雑化・老朽化・ブラックボックス化した既存システムを放置するリスクについて警鐘を鳴らしたものです（経済産業省, 2018）。
2026年現在、「2025年を過ぎたから刷新しなければならない」という期限として捉えるものではありません。重要なのは、自社のIT資産を可視化し、現在どのシステムが事業変化を妨げているのかを具体的に把握することです。
まとめ
レガシーシステムを刷新するタイミングは、「構築から何年経ったか」だけでは決まりません。
業務上の重要性、サポート継続性、保守・変更容易性、人材・ベンダー依存、セキュリティと復旧性、維持・変更コスト、データ・連携、将来の事業要求を確認し、今後も安全・経済的・継続的に変更しながら利用できるかを判断します。
20年以上安定稼働しているシステムを、その年数だけで全面刷新する必要があるとは限りません。一方、現在動いているからといって、サポート終了、属人化、復旧困難、変更コスト等の将来リスクを無視することもできません。
対応方法も、現状維持、部分改善、段階的モダナイゼーション、置換、廃止の複数があります。現行システムを残すリスクと、刷新プロジェクトそのもののリスクを比較して選択します。
SCI総合研究所株式会社のKANAMEBAでは、レガシーシステムを古さだけで刷新対象とせず、業務上の重要性、保守性、セキュリティ、維持・変更コスト、データ・システム連携、将来の事業要求まで整理し、現状維持・部分改善・段階的モダナイゼーション・置換等の選択肢を検討します。
「20年以上使っているが安定している」「ベンダーから刷新を提案されたが妥当性を判断できない」「全面刷新と部分改修のどちらがよいか分からない」といった段階から、IT資産の評価と刷新ロードマップを整理できます。
参考文献
- 経済産業省. 2018. DXレポート～ITシステム「2025年の崖」の克服とDXの本格的な展開～.
- 経済産業省. 2025. レガシーシステムモダン化委員会総括レポート.
- Kruchten, P. et al. 2012. Technical Debt: From Metaphor to Theory and Practice. IEEE Software. Vol. 29. Issue 6. pp. 18-21. DOI: 10.1109/MS.2012.167.
- Bartock, M. et al. 2016. Guide for Cybersecurity Event Recovery. National Institute of Standards and Technology. NIST Special Publication 800-184. DOI: 10.6028/NIST.SP.800-184.