レガシーシステムという言葉は「古いシステム」の言い換えとして使われがちですが、公的な定義はそう決めていません。経済産業省が2025年5月28日に公開した「DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会 総括レポート」（委員会の事務局は経済産業省・デジタル庁・IPA）は、古い技術で作られていること自体をレガシーの条件から外し、運用維持保守や機能改良が困難な状態に陥っているかどうかで線を引いています。この記事では、その定義と5つの要因を判定基準として使えるかたちに整理し、企業にどれだけ残っているかの実測値、刷新に踏み切るタイミングまでを扱います。
まとめ
レガシーシステムとは、技術の老朽化・肥大化・ブラックボックス化・IT投資の不足・古い制度としがらみという5つの要因によって、運用維持保守や機能改良が困難になり、経営や事業戦略の足枷・高コスト構造の原因となっているシステムを指します。判定の軸は年式ではなく状態です。メインフレームやCOBOLで作られていても、体制が整いデータ連携ができ仕様が明確なら該当せず、逆にメインフレームから脱却済みでも運用維持保守に問題があれば再びレガシー化します。
総括レポートの市場動向調査（約4,000社へ実施・回答799社・2024年12月17日から2025年2月14日）では、ユーザー企業の61％がレガシーシステムを保有し、大企業に限ると74％でした（前者は産業分野別の集計でn=516、後者は企業規模別の集計でn=402）。メインフレームを持っていた企業の52％は他方式へ移行済みですが、移行先の形態が決まっていない企業が過半数を占めます。「2025年の崖」を過ぎてなお、脱却は道半ばというのが現在地です。以下では、自社のシステムがどの要因に当てはまるかを見極め、刷新の要否とタイミングを判断するための材料を順に見ていきます。
レガシーシステムの定義：年式ではなく状態で決まる
経産省・IPAが引いた線と、そこに入らない条件
総括レポートは、レガシーシステムを「以下の要因により、運用維持保守や機能改良が困難な状態に陥り、経営・事業戦略上の足枷、高コスト構造の原因となっているシステム」と定義しています。引用中の「以下の要因」は、次章で扱う技術3つ・経営2つの5要因を指します。ここに「何年前に作られたか」「どの言語で書かれたか」という条件は入っていません。
むしろレポートは踏み込んで、現行システムがメインフレーム等の古い技術や開発手法で構築されたものであっても、開発・運用維持保守体制が整備され、デジタル技術の活用やデータ連携が可能で、仕様が明確で継続的な機能改良が可能な適切な作りであれば、レガシーシステムではないと言える、と明記しています。この一文は実務上の意味が大きく、「メインフレームだから移行しなければならない」という論法をそのままでは使えなくします。刷新の必要性は、稼働している基盤の名前ではなく、5要因のうちいくつに該当するかで説明することになります。
IT以外で使う「レガシー」との意味の違い
レガシー（legacy）はもともと遺産・引き継がれたものを意味する語で、ビジネス文脈では肯定的にも否定的にも使われます。レガシー産業、レガシーメディアといった使い方は「従来型の・既存の」という中立の意味に近く、必ずしも問題があることを含みません。
一方、ITでレガシーシステム、レガシー資産、レガシー言語と言うときは、上記の定義どおり「維持と改良が困難になっている」という否定的な評価が含まれます。COBOLやPL/Iを指して使われるレガシー言語も同様で、言語そのものが劣っているという意味ではありません。この点はCOBOLがなぜ廃れたと言われるのかで詳しく扱いました。同じ「レガシー」でも、機器やソフトウェアの旧版を指すレガシーモード・レガシー版のような製品用語は、単に後継が出た旧仕様という意味で、経営課題としてのレガシーシステムとは別の話です。
レガシーかどうかを分ける5つの要因
技術観点の3要因：老朽化・肥大化・ブラックボックス化
総括レポートは要因を技術観点3つ・経営観点2つに分けています。1つ目が技術の老朽化です。古い要素技術やパッケージでシステムが構成されており、それらに対応できる技術者が高齢化・離脱して要員の確保が難しい状態、ハードウェアが故障すると代替が利かない状態を指します。
2つ目がシステムの肥大化・複雑化で、巨大・複雑になって機能の追加・変更が困難になり、補完機能やカスタマイズ箇所が増えて人手で運用をカバーしなければならない状態です。3つ目がブラックボックス化で、仕様や設計のドキュメントが整備されておらず移行や再構築時に支障が出る、運用維持保守が属人的になっている、障害発生時に原因がすぐに特定できない、という症状が挙げられています。
| 観点 | 要因 | 判定の目安 |
|---|---|---|
| 技術 | 技術の老朽化 | 担い手の確保、代替部材 |
| 技術 | 肥大化・複雑化 | 改修の可否、人手運用 |
| 技術 | ブラックボックス化 | 仕様書、障害の原因特定 |
| 経営 | IT投資がされていない | 予算区分、応急措置の常態化 |
| 経営 | 古い制度としがらみ | 業務プロセス、現場の抵抗 |
自社の状況を説明するときは、この5行のどこに当てはまるかを具体的な事象とともに書き出すと、経営層に伝わる形になります。
経営観点の2要因：システムの外側にある要因
4つ目のIT投資がされていないは、ITシステムを投資対象ではなくコストとみなして十分な予算が確保されていない状態、障害発生時に必要最低限の応急措置しか取らずその場凌ぎの対応に留まっている状態を指します。5つ目の古い制度としがらみは、古い企業文化や企業風土が長年変化せず昔ながらの業務プロセスや制度に縛られている状態、現行システムを変えることへの現場の根強い抵抗感、経営層がそれをトップダウンで変えようとしない状態です。
この2つはコードやインフラをいくら調べても出てこないため、技術部門の調査だけで評価すると過小評価になります。移行の予算が毎年見送られている、業務部門が現行画面と同じ操作性を要求して譲らない、といった事象が続いているなら、技術要因が軽くても脱却は難航します。
脱メインフレーム後に再レガシー化する条件
総括レポートは、既にメインフレーム等から脱却済であっても運用維持保守に問題があれば再レガシー化する可能性がある、と述べています。クラウドへ移したこと自体はゴールではないという指摘です。
ここは断言しておきます。移行プロジェクトの完了時点でドキュメントを更新せず、運用を特定の担当者やベンダーに預けたままにすれば、新しい基盤の上で同じブラックボックス化が数年で再発します。移行の成否は稼働の可否ではなく、稼働後に仕様を把握し続けられる体制が残ったかどうかで判断してください。リホストのように現行仕様をそのまま移す方式ほど、この落とし穴に近づきます。方式ごとの違いはモダナイゼーションの手法と実装アプローチで整理しています。
レガシーシステムの代表例と残っている割合
メインフレーム・オフコン・COBOL資産という代表例
実務でレガシーシステムと呼ばれるものの多くは、メインフレームやオフコン（富士通の2031年3月提供終了と移行方式）の上で動く基幹系です。金融の勘定系、製造業の生産管理、流通の販売管理など、止められない業務を長期にわたって支えてきた領域が中心になります。IBM iのように2025年4月18日にIBM i 7.6が提供開始されるなど現在も新版が出ている環境もあり、この場合は環境の古さではなくサポート期限と移行方式の判断が論点になります。
アプリケーション側では、COBOLやPL/Iで書かれ、仕様書が現物と一致しなくなった業務プログラムが典型です。ほかに、社内で継ぎ足されてきたExcelマクロや個別開発のクライアントサーバ型アプリ、レガシーEDIとWeb EDIの違いで扱ったような、取引先との接続仕様に引きずられて更新できないインタフェースも同じ問題を抱えます。これらは基幹システムの構成領域のどこに位置するかを押さえると、刷新の順序を決めやすくなります。
調査時点（2024年12月〜2025年2月）の残存率は全体61％・大企業74％
総括レポートの市場動向調査は、約4,000社のユーザー企業およびベンダー企業に対して2024年12月17日から2025年2月14日にアンケートを実施し、799社から回答を得たものです。この調査で、ユーザー企業の61％がレガシーシステムを保有していると報告されています（産業分野別チャートの「全産業分野」、n=516）。企業規模別の集計（n=402）では大企業が74％で、中小企業より高い保有率でした。
ただし、移行の中身までは決まっていません。メインフレームのシステムを有していたユーザー企業のうち、メインフレーム以外へ移行しているのは52％です（n=333）。一方、同じ調査で移行先システムの形態が未だ決定していない企業が過半数を占めます（移行前システム別の集計。52％とは切り口が異なる集計です）。基盤を離れることと、移行先の形態を決めることが別の課題として残っている点は共通しています。
レガシーシステムが残り続ける背景
ベンダー依存と「低位安定」の産業構造
再構築が必要だとわかっていても着手されない理由を、総括レポートは個社の怠慢ではなく産業構造の問題として説明しています。ユーザー企業は既存業務の効率化を目指してデジタル投資を委託し、ベンダー企業は受託による低リスク・長期安定ビジネスを享受してきた結果、双方がデジタル競争を勝ち抜きにくい「低位安定」の関係に長らく固定されてきた、という整理です。
その帰結として、IT人材が過度にベンダー企業に偏り、ユーザー企業のITに対する自律性が低下します。自社システムの仕様を把握していない状態が常態化すれば、刷新の見積も評価も外部に依存することになり、意思決定はさらに遅れます。ブラックボックス化の背後には、この委託構造があります。
経営計画に刷新を書いている企業は12％
意思決定の層でも数字が出ています。総括レポートは、中期経営計画に大規模システムの導入・刷新を記載するユーザー企業は12％に留まり、大半の企業が自社のシステムに関する企業方針を社外に説明できていないと指摘します（出典はBCG作成資料）。
情報システム部門が運用維持保守にかかりきりで事業戦略を踏まえたIT投資の検討が十分になされていないこと、システムをコストと捉える経営層から情報システム部門の立場が下に見られ、システムの課題が経営課題として取り上げられないことも併せて挙げられています。5要因のうち4つ目のIT投資がされていない・5つ目の古い制度としがらみが、この12％という数字に表れています。
「2025年の崖」の現在地
レガシーシステムの文脈で必ず登場する「2025年の崖」は、経済産業省が2018年9月7日に公開したDXレポートで示された警告です。既存システムの複雑化・ブラックボックス化という課題を克服できない場合に、2025年以降で最大12兆円／年（当時の約3倍）の経済損失が生じる可能性がある、としたものでした。
注目すべきは、崖の年を越えた2025年5月の総括レポートが、この金額の予測を再掲していないことです。同レポートは「2025年の崖」を「既存システムの問題が足枷となり日本企業がDXを推進できずに経営改革が遅れると、デジタル競争の敗者となり経済損失が発生」と注記するに留め、本文では、崖を迎える中で産業界のDXおよびレガシーシステム脱却の進捗は依然としてスピード感に欠ける、と現状評価に置き換えています。金額の予測を根拠に社内を動かす段階は終わっており、いまは自社の残存状況と移行先の未決定という具体的な事実で説明したほうが通ります。
放置した場合のリスクと刷新に踏み切るタイミング
保守期限と技術者離脱で顕在化するリスク
レガシーシステムのリスクは、平時には見えず期限が来たときに一度に顕在化します。総括レポートは、企業が先送りにしている既存システムの保守切れ対応やシステム移行のタイミングで各所で問題が続発している、と現状を記述しています。ハードウェアやミドルウェアの保守期限、対応できる技術者の離脱、故障時に代替が利かない構成が重なる点が、技術の老朽化という要因の実害です。
加えて、既存のレガシーシステムが足枷となり、生成AI等の最新のデジタル技術を活用したくても連携や組み込みがスムーズに進められない問題が発生している、とも指摘されています。データの形式が古く疎結合になっていないシステムは、新しいツールを導入しても接続できません。刷新を見送るコストは、障害リスクだけでなく、新技術を使えない機会損失として毎年積み上がります。
刷新の判断材料：5要因の該当数と保守期限の交点
「いつ刷新すべきか」に一律の答えはありませんが、判断材料は絞れます。総括レポートの調査（n=325、複数回答あり）では、モダン化を決断する契機は大規模なシステム障害や運用維持保守要員の離脱といった受動的な要因が上位を占め、外部環境の変化を予見して自律的に決断する企業はまだ少ないとされています。障害が起きてからでは選択肢が減るため、平時に次の2点を見ておくことになります。
第一に、5要因のうち技術観点の3つにいくつ該当するか。とくにブラックボックス化が進んでいる場合は、移行の見積そのものが立たなくなるため、着手が遅れるほど費用と期間が膨らみます。第二に、基盤の保守期限までの残り年数。大規模システムのモダン化は数年計画に及び、着手後に計画が見直されるとさらに長期化するため、期限の直前に動き出す前提では間に合いません。
刷新のメリットを説明するときは、コスト削減だけを掲げないほうがうまくいきます。移行直後は運用が二重になり、費用はむしろ増えるためです。訴求すべきは、機能追加や制度改正への対応にかかる期間の短縮、障害時の原因特定の早さ、データを他システムやSaaSと連携できるようになることです。総括レポートも、モダン化された状態を「システムが疎結合で、データの形式が統一されており、様々なツールやサービスと容易にデータ連携ができる」状態として説明しています。
脱却の進め方でつまずく箇所
移行先の決め方と「モダンな技術」の条件
移行先を決められない企業が過半数という状況に対して、総括レポートは選定の考え方を示しています。モダンな技術は必ずしも最新・最先端である必要はなく、一定の市場シェアがある技術を採用することで将来的な調達コストや運用コストの低減が見込める、という指摘です。話題性の高い技術を選ぶことと、モダン化することは同じではありません。
形態の選択については、現状の業務プロセスを見直したうえで、投資対効果の許容可能な範囲内で標準的なパッケージやSaaSへ移行できるかを最優先で検討すべきとしています。とくに、大企業に比べて経営資源の制約の大きい中堅・中小企業は、オーダーメイドのスクラッチ開発は避け、パッケージやSaaSを原則とすべきである、と明言しています。リホスト・リライト・リビルドの呼び分けと、発注時にどこで線を引くかはマイグレーションとリプレイス・モダナイゼーションの違いにまとめました。
モダン化の障壁は複雑さ31％・現行機能保証24％
実際に着手した企業がどこで止まるかも、同調査に出ています。モダン化の障壁として最も多かったのは、既存システムが複雑でモダン化が技術的に困難（データ移行やシステムの相互依存性の課題など）で31％、次いで現行機能保証や、機能踏襲の制約が大きいが24％でした（n=59）。自由記述には、独自開発した機能が多く標準仕様への適合に苦慮した、構成管理が不十分で既存システムの仕様の理解に苦慮した、といった声が挙がっています。
レポートの答えは明快です。DXの阻害要因となる現行機能保証や現行踏襲の拘りは棄て、あるべき業務の姿から検討する。これを大原則に置いたうえで、標準的な仕様に寄せる部分と付加価値を作り込む部分を明確に分けるよう求めます。現場に標準化の検討を丸投げすると現行踏襲の問題が残存するため、経営層が検討プロセスに関与することも条件です。刷新が破綻した実例は基幹システム刷新の失敗事例を参照してください。
全面刷新の前段としての連携・統合と可視化
すべてを一度に置き換える必要はありません。レガシーシステムを残したまま外部とデータをやり取りする連携・統合は、業務停止のリスクを抑えつつデータ活用を先に進める手段になります。同レポートの自由記述でも、システム間連携の可視化は組織的な取り組みなしには平時から把握できないとされています。ただし、連携基盤を挟んだだけでは中の複雑さは減らないため、あくまで時間を買う施策として位置づけ、恒久策と混同しないでください。
前段として効くのがIT資産の可視化です。総括レポートはこれを、システム群と構成技術要素であるすべてのIT資産、およびそれらの相互関係を明確に把握・管理することと定義しています。可視化によって、老朽化したシステムや保守期限が間近なソフトウェアといった潜在的なリスクを特定でき、モダン化や統廃合の対象の絞り込みと優先度付けが可能になります。移行先が決まらない状態の多くは、決断力ではなく判断材料の不足に起因します。
よくある質問
レガシーシステムとは何ですか？
技術の老朽化、肥大化・複雑化、ブラックボックス化、IT投資の不足、古い制度としがらみという要因によって、運用維持保守や機能改良が困難な状態に陥り、経営・事業戦略上の足枷や高コスト構造の原因となっているシステムです。経済産業省が2025年5月28日に公開した総括レポートによる定義で、古い技術で作られていること自体は条件に含まれません。
レガシーシステムの代表例は何ですか？
メインフレームやオフコン上で稼働する勘定系・生産管理・販売管理などの基幹系、COBOLやPL/Iで書かれ仕様書が現物と一致しなくなった業務プログラムが代表例です。ほかに、社内で継ぎ足されてきたクライアントサーバ型アプリや、取引先との接続仕様に縛られて更新できないEDIのインタフェースも同じ問題を抱えます。
ITで言う「レガシー」と、レガシー産業などの「レガシー」は同じ意味ですか？
違います。レガシー産業やレガシーメディアの「レガシー」は従来型・既存のという中立の意味で使われますが、ITでレガシーシステムやレガシー資産と言う場合は、維持と改良が困難になっているという否定的な評価を含みます。製品名に付くレガシーモード・レガシー版は単に後継が出た旧仕様を指すもので、これも経営課題としてのレガシーシステムとは別の用法です。
レガシーシステムの刷新はどのタイミングで判断すればよいですか？
技術観点の3要因への該当数と、基盤の保守期限までの残り年数の交点で判断します。大規模システムのモダン化は数年計画に及び、着手後に問題化や停滞で計画が見直されるとさらに長期化するため、保守期限の直前に着手する前提では間に合いません。ブラックボックス化が進んでいる場合は移行の見積自体が立たなくなるので、優先度を上げてください。
レガシーシステムを刷新するメリットは何ですか？
機能追加や制度改正への対応期間の短縮、障害時の原因特定の早さ、他システムやSaaSとのデータ連携が可能になることです。総括レポートはモダン化された状態を、システムが疎結合でデータの形式が統一され、様々なツールやサービスと容易にデータ連携ができる状態としています。一方、移行直後は運用が二重になり費用は増えるため、短期のコスト削減をメリットとして掲げると社内の期待とずれます。
