レガシーシステム脱却の判断基準と進め方｜経産省調査が示す停滞要因と費用の見積り方

レガシーシステムの刷新が止まる原因は、技術の難しさではありません。経済産業省のレガシーシステムモダン化委員会が2025年5月28日に公表した総括レポートでは、レガシーシステムがユーザー企業の61%に残り、大企業では74%。一方で、大規模なシステム導入・刷新を中期経営計画に書いている企業は12%にとどまりました。この記事では脱却すべきシステムを見極める判定軸、段階的な進め方、据え置きとの5年総額の比べ方を整理し、着手すべきでない三条件も条件付きで示します。

まとめ：レガシーシステム脱却を判断する三つの軸と着手すべき順序

脱却の可否は、システム単位で決まります。全社一斉ではありません。判断に必要な軸は三つ。そのシステムが事業価値を生んでいるか、技術的な耐用が何年残っているか、据え置きを続けた5年総額が脱却した5年総額を上回るか。この三点で経営会議に出せます。

着手順序は、事業価値が高く技術的耐用が短いシステムから。周辺の小さなシステムから手を付けると、いちばん危ないものが最後まで残ります。順序を決める前提は棚卸しです。経営層とIT部門で情報が共有されている企業のIT資産可視化率は71%、共有されていない企業では66%が未着手でした。

脱却しないという結論も判断のうちです。廃止が決まった業務を載せたシステム、現場の合意が取れていない領域、耐用が5年以上残る安定稼働システム。この三条件に当てはまるなら、いまは据え置きが正解です。ただし据え置きを選ぶときは、いつ再検討するかのトリガーと期限をその場で決めます。決めずに放置した状態が、61%という残存率の中身になっています。

経産省調査が示すレガシーシステム残存率61%と刷新が計画に載らない構造

脱却が進まない理由を「予算がない」「人がいない」で片付けると、打ち手が出てきません。約4,000社を対象にした公的調査は、止まっている場所を具体的に指しています。

全産業61%・大企業74%という残存率が示す脱却の進捗の実像

経済産業省のレガシーシステムモダン化委員会は、2024年7月から2025年3月まで議論を重ね、2025年5月28日に総括レポートを公表しました。示された残存率は全産業で61%、大企業で74%、中小企業で約50%。規模が大きい企業のほうが残っている、という逆転が起きています。長く使われた基幹系ほど周辺システムとの連携が増え、止められる範囲が狭くなるためです。

IPAが2025年6月26日に公表した「DX動向2025」の日米独比較では、レガシーシステムの状況を「ほとんどがレガシーシステムである」「わからない」と答えた割合が日本で最も高く出ました。「わからない」が多いこと自体が、棚卸しの済んでいない証拠です。定義や経営への影響はレガシーシステムとは何か、その意味・定義や歴史的背景で整理しています。

経営層の先送りを示す中期経営計画への刷新記載率12%という数字

同レポートでもう一つ目を引く数字が、12%です。大規模なシステム導入・刷新を中期経営計画に記載している企業の割合。残存率61%との差が、先送りの実体を表しています。計画文書に載っていない案件は単年度の予算折衝で毎年後回しになります。刷新は投資回収が3年から5年に伸びるため、単年度の損益で評価すれば必ず負けるからです。

停滞は単独では起きません。経営の先送り、情報システム部門の自律性不足、ベンダー丸投げの三つが噛み合います。仕様がベンダー側にしか無ければ、IT部門は経営層に説明する材料を持てない。説明できないから予算が付かず、予算が付かないから棚卸しも進みません。順番に外すなら、まず棚卸しの予算だけを単独で取りに行くのが現実的です。

脱却を先送りしたときに効くサポート期限と人材面のリスクの現れ方

据え置きは無料ではありません。保守費は年を追って上がります。要因は工数ではなく人材の希少性で、対応できる技術者が減るほど単価が上がる。相場と契約形態の考え方はシステム保守とは？運用との違い・費用相場・契約形態で費目ごとに整理しました。保守費が前年比で上がり続けているなら、脱却の投資回収は既に始まっています。より読みにくいのが、次の二つです。

SAP ERP 6.0の標準保守2027年末が示す期限主導の刷新リスク

期限は外から来ます。SAPの公表（2026年8月時点）では、SAP ERP 6.0（SAP Business Suite 7）の標準保守は2027年末まで。当初は2025年末が期限でしたが、移行の遅れを受けて2年延長されました。標準保守料に2%を上乗せする延長保守なら2030年末まで延びますが、対象はEhP6からEhP8まで。Windows Server 2016の延長サポート終了も2027年1月12日です。

問題は期限そのものではなく、期限に追われた刷新の質です。残り1年で動くと、選べる手はインフラだけを移すリホストに絞られます。業務プロセスを見直す余地が消え、数年後に同じ議論をもう一度やる二度手間が確定する。サポート切れの環境を延命した場合は、セキュリティ更新が止まった状態で稼働し続けるため、既知の脆弱性が侵入経路として残り続けます。

COBOL・メインフレーム技術者の退職で失われる仕様知識の回復困難

失われると取り戻せないのは、コードではなく仕様の背景です。なぜこの計算式なのか、なぜこの例外処理があるのか。この種の知識は担当者の頭の中にあり、退職と同時に消えます。ソースは残るので動きはしますが、変更してよいかの判断ができなくなる。言語自体が使えないわけではありません。COBOLは金融・保険の勘定系で現在も動いており、廃れた言語という評価は実態と合いません（COBOLはなぜ廃れたと言われるのか）。

実務で効くのは、担当者が在職しているうちに仕様を文書へ落とす作業です。脱却の可否が決まる前に始めて構いません。着手が早いほど安く済みます。

脱却すべきシステムを見極める五つの判定軸とIT資産棚卸しの進め方

全システムを一律に刷新する計画は、予算規模で必ず止まります。先に仕分けます。仕分けの精度が、そのあとの見積り精度を決めるからです。

事業価値と技術的耐用の二軸でシステムを四象限に分ける仕分け方

使う軸は二つで足ります。そのシステムが事業の売上・差別化に直接効いているか（事業価値）と、サポート期限・技術者確保から見て何年使えるか（技術的耐用）。四象限に置くと打ち手が決まります。

迷いが出やすいのは左下、事業価値が低く耐用も短い領域です。ここは刷新ではなく廃止から検討します。使われていない機能を新環境へ作り直す費用が、刷新見積りの膨張要因として最も大きいためです。基幹系が対象に入る場合、領域の切り方は基幹システムとは？業務システム・ERPとの違いと構成領域を土台にすると揃えやすくなります。

脱却の優先度を決める五つの判定指標と数値化のしきい値の置き方

四象限に置くには数字が必要です。実務で回せる指標は五つあります。

• サポート期限までの残存年数（OS・ミドルウェア・パッケージのうち最短のもの）
• 年間保守費の対前年伸び率（3年平均）
• 対応可能な技術者の人数（自社・ベンダー合算での実数）
• 直近1年の障害件数と累計停止時間
• 設計書と実装の一致率（主要機能を抽出しての実査）

しきい値は自社の事情で決めますが、目安を置くと会議が早く終わります。残存年数3年未満、保守費伸び率が年5%超、対応技術者が3人未満のうち二つ以上に該当したら、その年度の計画に載せる。厳密な点数化より、全システムに同じ物差しを当てることに意味があります。指標が揃っていないと、声の大きい部署のシステムから着手する事故が起きます。

ドキュメント不在のシステムから仕様を掘り起こす棚卸しの実務手順

設計書が無い、あっても更新が止まっている。これが棚卸しの通常の出発点です。ソースコードから全仕様を復元する作業は費用が読めないため、順序を変えます。まず現在動いているインターフェースと帳票、次にマスタデータの構造、最後に業務ルール。外側から内側へ進めます。

インターフェースと帳票は現場が実際に使っている接点なので、生きている機能だけが残っています。ここを起点にすれば、誰も使っていない機能を早い段階で切り離せる。業務ルールは現場ヒアリングで拾い、その場でソースの該当箇所と突き合わせます。省くと、現場の記憶違いがそのまま要件になります。成果物は機能一覧ではなく、「移行するもの・廃止するもの・判断保留」の三分類リストです。

レガシーシステム脱却を段階的に進める四工程と着手順序の決め方

進め方の失敗は、ほぼ順序の失敗です。一斉切り替えを避け、どこから切り出すかの設計に手間をかけます。

全面刷新を避けて周辺業務から切り出す段階移行の設計と着手順序

工程は四つに分かれます。棚卸しと仕分け、標準仕様と付加価値部分の分離、切り出し単位での移行と並行稼働、旧システムの停止。三番目を繰り返す形にすれば、途中で止まっても投資が無駄になりません。

切り出す単位は、データの依存が少ない業務から選びます。参照だけで済む分析・帳票系、次に更新が単方向の周辺業務、最後に多方向に更新が走る中核業務。ただし技術的耐用が最も短いシステムが中核にある場合、順序を守ると期限に間に合いません。そのときは中核から着手し、周辺は旧システムに残したまま接続を維持する構成を先に決めます。安全な順序と期限が両立しない場面では、期限が優先です。

標準仕様と付加価値部分を分離し既存業務保証を捨てる判断の基準

経産省レポートの提言で、発注実務に最も効くのがこれです。既存業務の保証にこだわらず、標準仕様の部分と自社の付加価値部分を分ける。標準仕様側は、業務プロセスをパッケージやクラウドサービスに合わせて変えます。

「現行の帳票レイアウトを1ミリも変えない」という要求は、この分離を不可能にします。基準を一つ置くなら、その機能が売上・差別化に直接効いているかどうか。効いていないなら標準仕様側に寄せ、業務のやり方を変える。プロセス見直しと刷新を同時にやる負荷は高いのですが、分けて二度やるほうが総額では高くつきます。

移行方式の選び分けとリホスト偏重が生む二度手間を避ける判断軸

移行方式は、リホスト、リライト、リビルド、リプレイスなどに整理されます。それぞれの定義と費用・期間の差、どの方式がどの状況に向くかはマイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断で比較しました。実装レベルのアプローチはモダナイゼーションとは？レガシー刷新の手法と実装アプローチが対応します。

ここで示す判断軸は一つだけです。リホストは「期限に間に合わせる暫定手段」として選び、恒久策としては選ばない。インフラだけを移すリホストは期間が短く費用も抑えられますが、レガシーな作りは手つかずで残り、保守費の上昇も技術者不足も解消しません。選ぶなら、次の刷新の時期と予算枠を同じ稟議に書き込む。書かなければ、暫定が恒久になります。

レガシーシステム脱却の費用見積りと据え置きを続けた場合の5年総額比較

経営会議を通すのは機能の説明ではなく、金額の比較です。脱却の見積りだけを出せば、必ず「高い」で終わります。据え置きの総額と並べて初めて判断材料になる。

脱却費用の見積りを構成する四費目と見落としやすい移行後の運用増分

脱却費用は四つの費目に分かれます。調査設計費、開発または導入・設定費、データ移行と並行稼働の費用、移行後の運用費。前半三つは見積書に載りますが、四番目が抜けやすい。

移行後の運用費は、下がる項目と上がる項目が混在します。保守委託費とハードウェア更新費は下がる一方、クラウドの従量課金、監視・バックアップの利用料、新技術を扱う人材の教育費が乗る。この増分を稟議に入れないと、稼働後に予算超過として問題になります。もう一つは切り替え直後の生産性低下です。最初の2か月から3か月は処理が遅くなる前提で人員計画を組みます。

据え置きの5年総額と脱却の5年総額を同じ費目で並べる比較の型

比較は同じ費目・同じ期間で並べます。期間は5年。刷新の投資回収が収まる長さで、中期経営計画の射程とも合うからです。

据え置き側で金額を入れにくいのが、障害対応と機会損失です。推計で構いませんが、根拠は明示します。障害は直近3年の実績件数と1件あたりの対応工数から、機会損失は未着手要望の件数とそれに紐づく売上見込みから積む。空欄のまま比較表を出せば、据え置きのコストがゼロとして読まれます。

いま脱却に着手すべきでない三条件と据え置きが正解になる業務の見極め

脱却は目的ではありません。着手しないほうが総額で安く済む場面もあります。以下の三条件のいずれかに当てはまるなら、いまは動かさない判断を選びます。

廃止が決まった業務を載せたシステムに刷新費を投じない判断基準

事業の撤退・統合が決まっている業務、あるいは今後3年以内に外部サービスへ切り替える方針が固まっている業務。ここを載せたシステムに刷新費を投じてはいけません。作り直したものが数年で不要になります。IT部門だけで決めず、事業計画側の情報を先に取りに行きます。

撤退の可能性が議論されている段階なら、刷新は保留し、サポート期限までの延命策だけを手当てする。延長保守の費用は刷新費より小さく、判断を待つ間の保険になります。ただし延命の期限は書面に残します。

経営層と現場の合意形成が取れない段階で日程を先に切らない理由

もう一つの見送り条件が、合意の欠落です。経営層が投資として承認していない、あるいは現場が業務プロセスの変更に反対している。この状態で日程を先に確定させると、要件定義の段階で必ず止まります。止まり方も決まっています。現場が現行機能の全踏襲を要求し、費用が膨らみ、経営層が承認を撤回する。調査設計費が丸ごと失われます。

合意が無い段階でやるべきは、キックオフではなく棚卸しです。そこで出てくる「使われていない機能の割合」「保守費の推移」「対応技術者の人数」が、経営層と現場の双方を動かす材料になります。日程は、合意が取れた後に切ります。

据え置きを選んだ場合に必ず決める再検討のトリガーと見直し期限

据え置きと先送りは違います。分けるのは、再検討の条件を決めているかどうかです。据え置きを選ぶなら、次の三つをその場で文書に落とします。

1. 再検討のトリガー（サポート期限の残り2年到達、対応技術者が2人以下、年間障害件数が前年の1.5倍など）
2. トリガーに関わらず見直す期日（次期中期経営計画の策定時期に合わせる）
3. その間に進めておく作業（仕様の文書化、使われていない機能の切り離し）

三番目を入れておくと、据え置き期間が準備期間に変わります。この三点が無い据え置きは、単なる先送りです。

脱却プロジェクトが失敗する三つのパターンと発注前に潰す打ち手

失敗の形は限られています。どれも発注前に手を打てるもので、着工後に気付くと修正費用が跳ね上がる。実際に出荷停止や訴訟へ発展した案件の記録は基幹システム刷新の失敗事例と回避策で工程別に分解しています。

現行機能の全踏襲を前提にした要件定義がコストを膨らませる仕組み

最も費用に効く失敗がこれです。「現行と同じことが出来ること」を要件に書くと、使われていない機能まで作り直しの対象になります。棚卸しをせずに要件定義へ進んだ案件で、ほぼ確実に起きます。

潰し方は発注前の一手で足ります。RFPに機能一覧ではなく、前述の三分類リスト（移行するもの・廃止するもの・判断保留）を添える。保留分は要件から外し、稼働後に追加開発として個別に判断する、と明記します。現行踏襲を要求してくるのは多くの場合現場ですが、押し返す根拠は「使われていない」という実測データです。感覚では通りません。

ベンダーへの丸投げで仕様が自社に残らない発注体制と契約の見直し

二つ目は体制の失敗です。設計から実装までを一社に任せ、成果物の受け取りだけを行う体制では、新システムでも仕様が自社に残りません。レガシーを作り直した先に、次のレガシーが出来ます。

発注側で打てる手は二つです。第一に、要件定義と受け入れテストの設計を自社側の責任範囲として契約に明記する。第二に、設計ドキュメントを納品物一覧に入れ、更新義務を保守契約側にも書く。ドキュメントを納品物に入れていない契約が、5年後の不可視化の起点になります。

データ移行の不整合が本番切り替え後に発覚する典型例と事前対策

三つ目は、切り替え後に出る失敗です。データ移行の不整合は移行当日ではなく、稼働から数週間後の月次処理や締め処理で表に出ます。件数は合っているのに金額が合わない、という形が典型です。原因の多くは旧システムの例外データ。マスタに存在しないコード、桁溢れを回避する特殊値、廃止された区分が残ったままのレコード。正常系のテストでは検出できません。

事前対策は二つ。移行リハーサルを本番と同じ全件データで実施し、件数一致だけでなく金額・残高の突合まで行うこと。もう一つは、月次・年次処理を含めた期間で並行稼働を回すことです。並行稼働を2週間で切り上げる計画は、月次処理を1回しか通しません。切り戻しの手順と判断基準も稼働前に文書化します。

レガシー脱却における内製と外注の切り分けと受託開発会社の支援範囲

すべてを内製化する必要はありません。分ける基準は一つ、「その判断を間違えたときに事業が傷むか」です。どの機能を廃止するかの決定、業務プロセスを変える範囲の決定、受け入れテストの合否判断は自社に残す。棚卸しの実査、設計書の作成、実装、テストの実行は外部に出せます。経産省レポートが示したエンジニア比率3割から7割への転換も、判断側の人員を自社に置く話として読むのが実務的です。

受託開発会社に任せられる支援範囲と選定時に確認する三つの観点

任せられる範囲は、棚卸しの実査から要件定義の支援、移行方式の設計、開発、データ移行、稼働後の保守までです。当社ではシステムマイグレーション・リプレイスとして、既存システムの調査から段階移行の設計・実装までを引き受けています。棚卸しだけを先に切り出す相談も可能です。

選定時に確認する観点は三つに絞れます。第一に、既存システムの調査（現行解析）を単独の工程として見積書に出せるか。ここを「無償サービス」で済ませる会社は、後から追加費用が出ます。第二に、設計ドキュメントを納品物一覧に明記するか。第三に、業務プロセスの変更提案が出てくるか。現行踏襲の見積りだけを出す会社は、御用聞き型の受注をしているサインです。価格の比較より、この三点の確認を先に置きます。

よくある質問

レガシーシステム脱却の検討でよく挙がる質問を、判断に直結する順にまとめました。

レガシーシステム脱却のメリットは何ですか？

実務で効くのは三つです。第一に保守費用の下降で、人材希少性による単価上昇から抜けられます。第二に他システムやクラウドサービスとの連携が可能になり、これまで断っていた事業側の要望に応えられるようになる。第三に、サポート切れ環境の脆弱性という経営リスクが消えます。業務効率化やデータ利用の拡大は結果として付いてくるもので、直接の効果には数えません。

レガシーシステムからの脱却にはどのくらいの期間がかかりますか？

工程ごとの目安は置けます。棚卸しと仕分けに3か月から6か月、要件定義に3か月から6か月、開発と移行に1領域あたり6か月から18か月、並行稼働は月次処理を2回以上通せる期間。基幹系の全体刷新なら、着手から旧システム停止まで3年前後を見ます。短縮したい場合は工程ではなく範囲を狭めてください。

レガシーシステム脱却が進まない最大の要因は何ですか？

経済産業省のレガシーシステムモダン化委員会が2025年5月28日に公表した総括レポートでは、経営の先送り、情報システム部門の自律性不足、ベンダー丸投げの三つが停滞要因として挙げられました。残存率は全産業61%に対し、大規模なシステム導入・刷新を中期経営計画に記載している企業は12%。技術ではなく意思決定と情報共有の問題として現れています。

2025年の崖は結局どうなったのですか？

2018年9月の経済産業省「DXレポート」は、刷新が進まない場合に2025年から2030年にかけて最大で年間12兆円の経済損失が生じうると試算しました。2026年8月の時点で残存率は61%。一斉に問題が噴出する形ではなく、保守費用の上昇と対応人材の減少として個社ごとに現れています。期限としての2025年は過ぎましたが、個別のサポート期限は順次到来します。

移行後に現場が旧システムの運用に戻ってしまうのを防ぐ方法はありますか？

教育を移行計画の工程に組み込むのが前提になります。切り替え直前の集合研修だけでは足りません。並行稼働の期間中に現場が新システムで実業務を回し、出た手順の不都合を修正まで持っていく設計にします。旧システムを長く参照可能にしておくと戻る余地が生まれるため、停止日を先に決めて周知する。業務プロセスを変えた箇所は、理由まで現場に説明しておきます。

関連記事

• レガシーシステムとは何か、その意味・定義や歴史的背景：脱却を判断する前段にあたる定義と経営への影響の整理
• マイグレーションとは？リプレイス・モダナイゼーションとの違い：移行方式それぞれの費用・期間と発注判断の比較
• モダナイゼーションとは？レガシー刷新の手法と実装アプローチ：実装者向けの手法選定と進め方の詳細
• システム保守とは？運用との違い・費用相場・契約形態：据え置き側の総額を積む際の費目と相場の押さえ方
• COBOLはなぜ廃れたと言われるのか：技術者不足の実態と、いまも稼働し続けている理由