「システムは問題なく動いています」「ソースコードはGitに残っています」。そう報告されていたのに、担当者が退職し、小さな改修を頼んだ途端、仕様の調査から大きな費用がかかる。レガシーシステムの問題は、業務が止まる前から進んでいることがあります。
レガシーシステムとは、古い技術や複雑な構成、仕様の不明確さなどによって、保守・変更が難しくなり、事業の足かせになっているシステムです。単に年数が経っているという意味ではありません。
刷新には予算も時間もかかります。しかし、クラウドに移したり、新しい製品に入れ替えたりするだけでは、同じ問題を繰り返しかねません。この記事では、定義・具体例・調査結果から脱却方法を整理したうえで、日々の導入・改修の判断が、将来の変更しやすさをどう左右するかを考えます。
レガシーシステムとは？古いだけではなく、保守・変更が難しい状態
英語のlegacyには「遺産」という意味があります。ITでは、以前から使い続けているシステムを指す場合がありますが、経営課題として重要なのは、今後も維持・改良できるかです。
経済産業省・デジタル庁・IPAによる2025年の総括レポートも、運用維持保守や機能改良が難しくなり、経営・事業戦略の制約や高コストにつながっている状態として整理しています。
受発注・販売管理・会計など、身近なシステムにもある
代表例としては、大型コンピューターのメインフレームや、オフコンと呼ばれる業務用コンピューターで動く基幹システムが挙げられます。ただ、対象はそれだけではありません。次は仕組みを理解するための例です。
| システムの例 | レガシー化した状態 | 事業への影響 |
|---|---|---|
| 受発注システム | 取引先別の例外処理が増え、どこを直すと何が変わるか分からない | 新しい販売チャネルと連携するまでに調査・改修が膨らむ |
| 会計・販売管理パッケージ | 独自改修が多く、標準の更新を適用しにくい | 法改正やサービス変更への対応が重くなる |
| 生産管理システム | 古い機器の交換部品や保守要員を確保しにくい | 故障時の復旧期間を見通せない |
| 複数部門の業務システム | データの意味や接続関係を特定の人しか説明できない | 異動・退職のたびに変更や障害対応が難しくなる |
共通するのは、今日の仕事は回せても、明日の変更や復旧を引き受けにくいことです。
COBOLやオンプレミスなら、必ずレガシーなのか
COBOLは業務システムで長く使われてきたプログラミング言語です。オンプレミスは、自社の施設などに機器を設置して運用する形態を指します。
どちらも、それだけで問題があるわけではありません。仕様が明確で、保守する人がいて、必要な変更やデータ連携を続けられるなら、古い技術でも事業を支えられます。反対に、最近作ったクラウド上のシステムでも、一人しか理解できず、更新の影響を追えなければ、将来同じ制約を抱えます。
レガシーシステムの問題点と、脱却が進まない原因
2025年5月の総括レポートでは、ユーザー企業の61％がレガシーシステムを保有していると報告されました。この集計の対象は516社です。調査全体は2024年12月〜2025年2月に実施され、ユーザー企業・ベンダー企業の計799社が回答しています。
さらに、刷新の障壁を尋ねた集計では、次の項目が上位でした。
| 刷新を難しくする障壁 | 回答割合 |
|---|---|
| データ移行やシステム間の依存関係など、既存システムの複雑さ | 31％ |
| 現行機能を保証・踏襲する制約 | 24％ |
出典：総括レポートPDF16・26ページ。障壁の集計は59社で、保有率の集計とは対象が異なります。
つまり、予算さえ確保すれば製品を交換して終わる、という問題ではありません。移行元の仕組みを理解することと、今までの仕事をどこまで変えるかが、費用や期間を左右します。
小さな改修が、他の業務を巻き込む
例えば、顧客番号の形式を変えるだけでも、販売管理、請求、倉庫への出荷指示で同じ番号を使っていれば、影響は一つの画面に収まりません。どこで変換・転記されているか不明なら、その確認から始まります。
障害の際も同様です。バックアップのデータがあっても、起動順序や外部接続、夜間処理の設定が分からなければ、業務として元に戻すまでには別の作業が残ります。
今の機能をすべて再現すると、次のシステムも複雑になる
取引先ごとの締め日、独自の承認、特別な値引き。現場にとっては必要な機能でも、それらをすべて新製品に再現すれば、標準機能から離れて改修費や保守負担が増えます。
一方、機能を廃止すれば、業務や取引条件を変える調整が生じます。現場が単に変化を嫌っているとは限りません。変更後の仕事まで引き受けられるかが見えないため、今の機能を残してほしいという判断にもなります。
このため、脱却の難しさは技術の古さだけでなく、システムに埋め込まれた業務の複雑さにもあります。総括レポートの自由記述にも、独自機能の整理や既存仕様の理解に苦慮した状況が紹介されています。
クラウド移行やGit管理だけで、レガシーシステムから脱却できる？
クラウドへの移行で、古い機器の保守や調達の問題を軽減できる場合があります。Gitでソースコードと変更履歴を管理することも、引き継ぎの重要な土台です。
ただし、稼働場所とコードの保管先を整えることと、別の人が理解して変更できることは別です。
コードがあっても、業務の意味と接続関係が分からない
Gitは、ファイルの変更履歴を管理する仕組みです。コードだけでなく設計書や環境設定を一緒に管理することもできます。問題はGitの限界というより、実際に何を残しているかです。
例えば、プログラムに「月末に請求データを出力する」と書かれていても、出力先がどこで、どの会社が取り込み、失敗時に誰が再送するかまで分かるとは限りません。修正履歴があっても、その変更が特定の取引先との合意によるものなのか、過去の不具合への暫定対応なのかは、理由を残していなければ読み解きにくくなります。
図は架空の構成例です。コードのある範囲と、業務を成立させるために把握したい範囲が一致するとは限らないことを示しています。
非エンジニアの責任者に、すべてのコードを読むことは現実的ではありません。それでも、受注情報がどこで生まれ、何を経由して請求に使われるかが分かれば、変更がどの業務に関わるかを話し合いやすくなります。
データの流れを示す図、データを蓄積するDB（データベース）の項目や関連を説明する設計書、外部接続・実行手順、仕様変更の理由などは、そのための材料です。書類を一式作ることよりも、実物と一致し、変更時に更新され、次の担当者が利用できることに意味があります。
クラウド上へ、ブラックボックスを持ち込むこともある
クラウドへ載せ替えても、複雑な例外処理や属人化した運用がそのままなら、改修の難しさは残ります。移行先の設定や権限まで一人しか分からなければ、理解すべき対象が増えることもあります。
「クラウドに移したので完了」という説明より、何の問題が解消し、何が残ったかを見るほうが、脱却の実態を捉えやすくなります。
レガシー化は、導入・改修時の合理的な選択の積み重ねでも起きる
レガシー化の原因を、怠慢や知識不足だけで説明するのは十分ではありません。納期を守る、開発費を抑える、現場の仕事を止めない。こうした目的で選んだ方法が、将来の変更を難しくする場合もあります。
「外注先が作りやすい」と「自社が維持しやすい」は一致しない
AmazonのクラウドサービスであるAWSから、Google Cloudへの移行提案を検討した際、理由として挙げられたのは、GoogleのAI製品などと連携しやすいという説明でした。
同じ目的をAWSで実現する場合との違いを確認すると、具体的な比較は示されず、外注先がGoogle Cloudを使っていて、そちらのほうが進めやすいという事情でした。
これはGoogle Cloudの良し悪しの話ではありません。外注先が慣れた環境なら、開発期間や費用を抑えられることもあります。しかし、それが自社の移行費、検証、運用変更、次の委託先への引き継ぎまで含めて有利なのかは、別の判断です。
提案者は今回の開発をうまく進めようとしていても、見ている範囲と時間軸が会社全体の判断より狭いことがあります。今回の作業効率を得る代わりに、誰が、いつまで、どんな負担を引き受けるのかが説明されていなければ、技術的に実現できるというだけでは承認の根拠が足りません。
外注の活用そのものを否定する話ではありません。DXの内製・外注の判断でも扱ったように、自社の人材や管理できる範囲を踏まえたうえで、外部の力を使う考え方が重要になります。
必要な機能が同じなら、扱える人が多い選択肢にも価値がある
身近な例は、企業サイトのCMSです。CMSは、Webページや記事を管理・更新するためのツールです。
営業・マーケティングとの連携や運用支援を目的に、HubSpotやferret Oneなどを選ぶ判断には理由があります。一方、必要なことがWordPressでも満たせるなら、現在・将来の担当者や委託先を確保しやすいかも、比較する価値があります。
導入時の価格が安くても、改修を頼める会社が限られ、乗り換えるとコンテンツを移せないなら、その後の選択は狭まります。逆に、社内で扱える人がいて、特有の機能を十分使うなら、一般的な普及度だけで選び直す理由は弱くなります。
広く使われる製品でも、独自改修を重ねれば引き継ぎにくくなります。選ぶ製品と、選んだ後の作り方・残し方の両方が、将来に影響します。
レガシーシステムの脱却方法｜刷新と再発防止を一緒に考える
既存システムを抱えている場合にも、全面的な作り直しだけが選択肢ではありません。どの制約を解消したいかによって、手を入れる場所が変わります。SaaSは、ソフトウェアをクラウド経由で利用するサービスです。
| 方法 | 主に解消したい問題 | そのままでは残りやすい問題 |
|---|---|---|
| 稼働環境を移す（リホスト） | 古い機器の保守・調達など | プログラムの複雑さ、業務の例外処理 |
| 内部構造を整理する（リファクタリング） | コードの読みづらさ、変更のしにくさ | 業務自体の複雑さや不要な機能 |
| 標準パッケージ・SaaSへ置き換える | 独自システムの保守負担 | 業務の変更、データ移行、標準機能で足りない部分 |
| 必要な領域から段階的に刷新する | 一括移行の負担と業務停止リスク | 新旧が併存する期間の接続・整合性管理 |
例えば機器の保守期限が迫っているなら、先に稼働環境を移して時間を確保する判断もあります。一方、主な問題が複雑な仕様なら、環境の移行だけでは期待した改修費削減につながりにくいでしょう。
どこへ投資するかは、導入する製品名より、解消したい事業上の制約から考えるほうが整理しやすくなります。DX投資の優先順位では、この出発点を詳しく扱っています。
AIで刷新費用を抑えられる範囲と、人に残る判断
AIでコードを読み、仕様書のたたき台を作り、変換やテスト作成を支援する方法も出てきています。例えばAWS Transformは、メインフレームのコード分析、業務ロジックの抽出、変換、テスト計画などを支援する機能を提供しています。
こうした支援は、調査や実装の負担を減らす選択肢になります。ただし、「現行のどの機能を残すか」「新しい業務で何を正しい結果とするか」まで、コードの変換だけで決まるわけではありません。実際の業務と照らした確認や、移行後の運用を引き受ける人は残ります。
そのため、検討したいのはコードを書く時間の短縮だけでなく、調査・検証・引き継ぎを含む全体の負担です。AI活用の目的を業務から整理する考え方は、AI導入を何から始めるかにもつながります。
新しいシステムでも、次の担当者が分からなければ繰り返す
最新の技術で作り直しても、仕様変更の理由や外部接続が担当者の頭の中にしか残らなければ、再び同じ問題に近づきます。AI駆動開発も、作成速度だけでなく、レビューや障害対応、保守を誰が担えるかまで含めると、導入の評価が変わります。
すべてを標準化したり、特殊な技術を避けたりすることが正解とは限りません。競争力に直結する独自機能なら、保守の負担を引き受けてでも作る理由があります。その理由と、将来の維持に使う資源を、会社として理解して選んでいるかが分かれ目になります。
レガシーシステムについてよくある質問
何年使ったらレガシーシステムになりますか？
一律の年数では決まりません。年数は機器や製品の保守状況を調べるきっかけになりますが、仕様が明確で、必要な改修と保守を続けられるかが重要です。最近作ったものでも、変更できる人や情報が失われれば問題を抱えます。
「2025年の崖」は2025年に解消したのですか？
年が過ぎれば解消する問題ではありません。「2025年の崖」は、既存システムや人材の問題がDXを妨げるリスクへの警鐘として使われた言葉です。実際にどれだけ損失が生じたかという実績値とは区別して読む必要があります。
非エンジニアの責任者は、何を把握すればよいですか？
コードの詳細よりも、システムが支える業務、他との接続、止まった際の影響、維持・改修を担う人の関係が分かると、話し合いの土台になります。「資料があります」という報告だけでなく、担当者が変わってもその資料を使って変更や復旧ができるかという実態まで見えると、判断材料が増えます。
今回の便利さと、将来の変更しやすさを一緒に見る
システムの選定や実装は、基本的には専門性のあるメンバーに任せるものです。経営者が個々の技術をすべて理解し、毎回判断し直すことは現実的ではありません。
ただ、正常に稼働しているという報告だけでは、将来も維持・変更できるとは分かりません。問題が表面化してから予算を確保しても、必要な知識を持つ人がすでにいなければ、調査から時間がかかります。
レガシー化は、悪い提案だけで起きるものではありません。今回の納期や費用を優先した善意の判断が積み重なり、会社の選択肢を狭めることもあります。万能のチェックリストで防げるわけではありませんが、「今回、誰にとって何が良くなり、その代わりに自社は将来何を引き受けるのか」という問いには意味があります。
今動くものを作ることと、将来も別の人が理解し、直し、引き継げること。その両方を見ることが、次のレガシーシステムを作らないための出発点になるのではないでしょうか。
参考資料
- 経済産業省・デジタル庁・IPA：レガシーシステムモダン化委員会総括レポート（2025年5月28日、PDF）：定義はPDF7ページ、調査概要15ページ、保有状況16ページ、刷新の障壁26ページ。PDFページと資料内の表示ページは一致しています。
- IPA：ITシステムのモダン化とは？：古い技術との区別、仕様の可視化、標準化と継続的な更新。
- デジタル庁ニュース：企業のDXを阻むレガシーシステムとは（2025年8月27日）：データ・仕様の把握とユーザー企業の課題。
- IPA：重要情報を扱うシステムの要求策定ガイド・活用の手引き：標準仕様や将来の移行性を考える視点。
- AWS：AWS Transformのメインフレーム変革機能：コード分析、文書生成、業務ロジック抽出などの提供機能。
- AWS：メインフレームのモダナイゼーション工程：設計確認、専門家の知識、テストなどを含む工程。
本記事の文章・表・図解・グラフは、Skill Business Architecture Labが独自に編集・作成しています。引用・紹介する場合は、引用箇所が分かる形で、記事名・サイト名・記事URLをご記載ください。
コメント