「2025 年の崖、結局どうなったのか？」——2025 年を過ぎた現在、経営者からよく寄せられる質問の一つです。経済産業省が 2018 年に公表した『DX レポート』で警鐘を鳴らした、ITシステムにおける『2025 年の崖』は、節目の年を越えた今も解消されたわけではありません。むしろ、技術者引退・サポート期限・取引先要求が重なり、『崖を越えた後の現実』に直面する企業が増えています。本記事では、2025 年の崖の意味・経済産業省 DX レポートの本質、2025 年を過ぎた現在の状況、刷新の進め方・費用・モデルケース・失敗パターン・判断チェックリストまで、25 年の現場経験で経営者向けに整理します。
『崖を越えた後、何から手をつければ？』 とお感じですか？ 25 年の経験で現実的な対応策を一緒に整理します。 無料相談 ＞2025 年の崖の現状認識｜『節目を過ぎても、崖は消えていない』
2025 年の崖は、経済産業省が 2018 年 9 月公表の『DX レポート』で示した警告です。要旨は次の通り：日本企業の多くが 20～30 年使い続けてきた基幹システム（レガシーシステム）の 老朽化・複雑化・ブラックボックス化 が限界に達し、刷新できなければ 2025 年以降に最大 12 兆円／年の経済損失 が発生する可能性が示されました。
DX レポートが指摘した課題を経営者向けに 3 つに整理
DX レポートが指摘した課題を、本記事では経営者向けに次の 3 つに整理します。
| # | 構造課題 | 具体的な状況 |
|---|---|---|
| 1 | レガシーシステムの老朽化 | 20～30 年使い続けたメインフレーム・オフコン・古いパッケージが業務の中核に残存 |
| 2 | システムのブラックボックス化 | 長年の改修で複雑化／設計書・ドキュメントが現存せず／読める技術者が限られる |
| 3 | IT 人材の引退と不足 | COBOL・RPG・古い VB を担う技術者の高齢化／2030 年には IT 人材が最大約 79 万人不足するという試算もある |
これら 3 つの課題が解消されない場合、日本企業全体で 最大 12 兆円規模／年 の経済損失が発生する可能性がある——これが『2025 年の崖』の中身です。
2025 年を過ぎた現在、現場で起きていること
節目の 2025 年は通過しました。しかし、現場で起きているのは『崖を越えて安全になった』ではなく、技術者引退・サポート期限・法制度対応・取引先要求といった課題が、時間差で顕在化し始めている状態 です。経済産業省も DX レポート 2.x（2020～2022 年）で『崖は引き続き存在し、対策の遅れが顕著』と継続的に警告を発しています。
- 技術者引退の進行：COBOL・RPG・汎用機を担ってきた世代の退職・再雇用・外部委託への移行が 2025～2030 年で進む
- ベンダーのサポート期限：汎用機・オフコン・古いパッケージは、製品・契約によってサポート期限や保守条件が異なるが、2020 年代後半にかけて保守更新・延長保守・移行判断を迫られるケースが増えている
- 法制度・取引先要求の連続：電子帳簿保存法、インボイス制度、電子取引データ保存対応、取引先 EDI 強化、トレーサビリティ要求などが続く
- 改修費の高騰：レガシー基盤では、小さく見える改修でも、調査・影響分析・テスト範囲が広がり、数百万円～数千万円規模になることがある
- データ活用の遅れ：経営判断に必要なデータが取り出しにくく、競合との差が広がりやすい
中堅企業（年商 30～300 億円）でも、こうした『崖を越えた後の現実』に直面する企業は少なくありません。
なぜ今、レガシー脱却を進めるべきか｜2025 年を越えた現在の 4 つの圧力
2025 年の崖は『節目の年が来た／過ぎた』で終わるテーマではありません。節目を過ぎた今こそ、4 つの圧力が同時に押し寄せる『正念場』 に入っています。
圧力 1：IT 人材引退の進行（2025～2030 年）
経済産業省・情報処理推進機構（IPA）の試算では、IT 人材不足は 2030 年に最大約 79 万人 に達する見込みです。COBOL・RPG・古い VB・Access を担う技術者は高齢化が進んでおり、2025～2030 年にかけて退職・再雇用・外部委託への移行が進むと見込まれます。中堅企業では、社内でレガシー基盤を読める人が数名に限られ、退職によって実質的にゼロになるリスク が現実化しています。
圧力 2：ベンダーサポート期限と保守費の上昇
汎用機・オフコン・古いパッケージでは、製品・契約によってサポート期限や保守条件が異なります。2020 年代後半にかけて保守更新・延長保守・移行判断を迫られるケースが増えており、各ベンダーの製品・契約ごとに、保守期限、延長保守条件、後継基盤への移行方針を確認する必要があります。
当社経験上、延長保守や個別保守に移行すると、保守費が従来より大きく上がるケース があります。費用増の幅は製品・契約・保守範囲によって異なります。サポート切れ後の障害発生は、部品調達難・OS パッチ提供停止などで復旧時間が伸びる可能性があります。
圧力 3：法制度・取引先のデジタル化要求
電子帳簿保存法、インボイス制度、電子取引データ保存対応、取引先 EDI 強化、トレーサビリティ要求、API 連携など、業務システムに影響する制度・取引要件が続いています。古いシステムで個別対応を続けると、改修のたびに調査・影響分析・テストの負荷が増え、保守性が低下しやすくなります。
圧力 4：データ活用・経営判断スピードの要求
経営層の「販売データを分析したい」「在庫の最適化を進めたい」「拠点別の損益をリアルタイムで見たい」といった要求が増加しています。古いシステムからのデータ取り出し・API 公開が困難 なため、データ活用がボトルネック化しやすく、競合との経営判断スピードの差が業績に直結する時代に入っています。
2025 年の崖を越える進め方｜3 つのアプローチ
レガシー脱却には主に 3 つのアプローチがあります。自社の業務独自性・予算・刷新の緊急度・既存資産の活用度合いで選びます。
アプローチ 1：リホスト（環境を載せ替え、ソースは概ね維持）
既存のソースコード（COBOL・RPG など）をできるだけ維持し、稼働環境を クラウド IaaS、仮想化基盤、互換実行環境 などへ移す方式です。業務ロジックは大きく変えず、実行基盤を切り替えます。
| メリット | 業務影響が比較的小さい／期間が短い／投資額が比較的小さい／既存業務知識を活かせる |
|---|---|
| デメリット | レガシー資産はそのまま残るため、技術者問題は将来的に再発する可能性／業務改革効果は限定的 |
| 適合ケース | サポート期限が近い／業務改革は後回しで延命したい／業務独自性が極めて高い |
| 費用／期間（当社想定） | 主要サブシステムを対象とした概算として 2,000 万～5,000 万円／8～12 ヶ月程度 |
アプローチ 2：リライト（Java・C# 等へ書き換え）
レガシー資産を Java・C#・Python・モダン Web フレームワーク へ書き換える方式です。業務ロジックは原則維持しつつ、技術基盤を現代化します。
| メリット | 技術者問題が解消しやすい／オープン技術スタックで運用人材を確保しやすい／API 連携・データ活用がしやすくなる |
|---|---|
| デメリット | 投資額が大／期間が長い／変換後の保守性は元の構造に依存する場合あり |
| 適合ケース | 業務ロジックは資産として残したい／パッケージで吸収できない業務独自性がある |
| 費用／期間（当社想定） | 主要基幹システム対象として 8,000 万～2 億円／18～24 ヶ月程度 |
アプローチ 3：ERP・業務パッケージへの移行（業務をパッケージに合わせる判断）
レガシー資産で組まれた業務独自仕様を 業界特化型 ERP・業務パッケージの標準機能に寄せる 方式です。Fit to Standard を経営判断で明示し、独自仕様は『資産か負債か』の視点で取捨選択します。
| メリット | 業界ベストプラクティスを取り込みやすい／長期的な運用コストを下げやすい／業務改革効果が大きい |
|---|---|
| デメリット | 業務をパッケージに合わせる経営判断が必要／一部の独自仕様は捨てる必要あり |
| 適合ケース | 業務独自性が業界平均的／業務改革を伴う刷新を進めたい中堅企業では有力な選択肢 |
| 費用／期間（当社想定） | 主要基幹システム対象として 3,000 万～8,000 万円／10～14 ヶ月程度 |
3 つのアプローチは『どれが正解』ではなく、『自社のレガシー資産が業界差別化に寄与しているか／単に過去の事情で複雑化しているだけか』 という経営判断で選びます。中堅企業では、短期的にリホストで時間を確保し、その間に ERP・パッケージ移行や本格刷新を検討する段階戦略 も現実的な選択肢です。
2025 年の崖『損失試算』と刷新投資の経済合理性
経済産業省試算：年最大 12 兆円の経済損失
DX レポート（2018 年） の試算では、レガシーシステムを刷新せず放置した場合、2025 年以降に日本企業全体で最大年 12 兆円の経済損失 が発生する可能性が示されました。本記事では、この損失を、保守費の高騰、取引機会・データ活用機会の喪失、障害対応コスト、人材確保コストの上昇として捉えています。
中堅企業 1 社あたりの『放置コスト』モデル試算（当社想定）
以下は、年商 50 億円規模の企業がレガシー基幹システムを抱えている場合の 当社想定のモデル試算 です。実際の損失額は、業種・取引形態・現行システム・保守契約・データ活用状況によって大きく変動します。損失額そのものを断定するものではなく、保守費・改修費・業務工数・機会損失を含めて考えるためのモデルとしてご覧ください。
| 項目 | 年商 50 億円規模での想定モデル試算 |
|---|---|
| 保守費の上昇（延長保守・改修費） | 2,000～5,000 万円 |
| 法制度対応の都度改修 | 500～2,000 万円 |
| 取引機会の喪失（EDI 非対応・新規取引機会の逸失） | 1,000～3,000 万円 |
| 業務効率化機会の損失（属人化・Excel 補完） | 1,000～2,500 万円 |
| データ活用の遅れによる経営判断ロス | 500～1,500 万円 |
| 年間 放置コスト 合計（モデル試算） | 5,000 万～1.4 億円 |
規模別・方式別の刷新投資（当社想定）
| 規模の目安 | リホスト | リライト | ERP・パッケージ移行 |
|---|---|---|---|
| 50～150 名規模 | 2,000～4,000 万円 | 6,000 万～1.2 億円 | 2,500～5,000 万円 |
| 150～300 名規模 | 3,000～6,000 万円 | 8,000 万～1.8 億円 | 5,000 万～1 億円 |
| 300～500 名規模 | 4,000 万～8,000 万円 | 1.2～2.5 億円 | 8,000 万～1.5 億円 |
これはベンダー支払額のみの目安です。当社経験上の目安として、社内工数・並行運用・データ移行・教育費まで含めると、実質総費用はベンダー支払額の 1.3～1.5 倍程度 で見ておくと安全です。レガシー度合いが高く、現行解析やデータ移行が重い場合は、さらに上振れすることがあります。
放置コストと刷新投資を比較すると、前提条件によっては 2～3 年で投資回収の見通しが立つ場合があります。保守費削減だけでなく、法制度対応コストの抑制、業務効率化、データ活用、取引機会の維持まで含めて比較することが重要です。
期間
検討フェーズ（経営判断・現行解析・RFP・ベンダー選定）3～6 ヶ月＋移行設計・実装・テスト 10～18 ヶ月＋稼働後 90 日定着化を含めると、経営判断から成果獲得まで 15～27 ヶ月 が現実的なスケジュールです。2026 年時点で検討を始める場合でも、稼働は 2027 年後半～2028 年以降になる可能性があります。
レガシー脱却のモデルケース（中堅企業）
以下は、特定企業の実績事例ではなく、当社の実務経験をもとに業種別によく見られる状況を抽象化したモデルケース です。企業名・数値・成果は説明用に再構成しています。
ケース 1：製造業 A 社（汎用機の生産・販売管理を ERP 移行）
| 規模 | 年商 90 億円／従業員 220 名（部品製造） |
|---|---|
| 刷新前 | 汎用機上の COBOL 基幹（28 年稼働）／保守費の高止まり／サポート期限到来 |
| 方式 | 製造業特化 ERP（Fit to Standard 7 割） |
| 期間／投資額（当社想定） | 14 ヶ月／8,500 万円 |
| 想定効果 | 保守費の圧縮余地、原価把握の早期化、利益率改善余地の創出 |
ケース 2：卸売業 B 社（オフコンの販売管理をリホスト先行＋段階刷新）
| 規模 | 年商 120 億円／従業員 200 名（食品卸） |
|---|---|
| 刷新前 | IBM i 上の COBOL／RPG 販売管理（30 年稼働）／取引先 EDI 強化要求への対応が困難 |
| 方式 | 第 1 段階：互換実行環境へリホスト／第 2 段階：食品卸業界特化 ERP へ移行（計画的に検討） |
| 期間／投資額（当社想定） | 第 1 段階 11 ヶ月／4,200 万円 |
| 想定効果 | 第 1 段階のリホストでサポート切れリスクを一時的に抑え、本格刷新に向けた検討期間を確保 |
ケース 3：建設業 C 社（古い VB／Access 業務システムを Web 系へリライト）
| 規模 | 年商 60 億円／従業員 150 名（中堅ゼネコン） |
|---|---|
| 刷新前 | VB6＋Access の工事案件管理（20 年稼働）／Excel 補完業務が肥大化／OS 更新困難 |
| 方式 | Java／モダン Web 系へリライト＋クラウド移行 |
| 期間／投資額（当社想定） | 20 ヶ月／1.3 億円 |
| 想定効果 | Excel 補完業務の削減、工事原価の可視化、スマホでの現場入力対応、属人化リスクの低減 |
2025 年の崖対応の『失敗パターン』
失敗 1：『DX』『新技術』を目的化する
AI・IoT・ブロックチェーンといった『新技術の導入』そのものを目的化すると、業務改革の本質を見失いやすくなります。レガシー脱却は『技術の更新』ではなく『業務の整理』。経営層が『何を解決したいのか』を明示することが、投資効果を最大化する起点です。
失敗 2：『現行を 100% 再現』を要件にする
20～30 年の改修で積み重なった独自仕様を、新システムでそのまま再現する要件にすると、開発費・期間が大きく膨らむ場合があります。『資産か負債か』を経営判断で切り分けるプロセスを、要件定義の最初に置いてください。
失敗 3：『崖は来ない／越えた』と判断停止する
2025 年を過ぎた今、『結局 崖は来なかった』と判断停止する経営層が出始めています。実態は『崖を越えた瞬間から、影響が顕在化し始めた』。技術者引退・サポート期限・取引先要求は むしろこれから本格化 する可能性があります。判断停止は、最も大きなリスクの一つです。
失敗 4：『予算がないから 1 年後』と先送りする
刷新の検討開始から成果獲得まで 15～27 ヶ月かかります。予算化を 1 年先送りすると、稼働は 2 年遅れ。その間の放置コスト（モデル試算で年 5,000 万～1.4 億円）は積み上がり続けます。検討フェーズだけ先に始めることで、予算化のタイミングと整合させやすくなります。
失敗 5：補助金の枠だけで方式を決める
IT 導入補助金・事業再構築補助金などを活用する経営判断は妥当ですが、補助金の条件に合うアプローチに無理やり寄せる と、業務との適合度が崩れます。補助金は『追い風』であって『推進力』ではありません。業務適合度 → 方式選定 → 補助金活用、の順序 を崩さないことが重要です。
2025 年の崖対応の『判断チェックリスト』
経営者が現場で確認すべき 10 項目を整理します。目安として 3 つ以上当てはまる場合は、本格的なレガシー脱却検討を始めるタイミング です。
- ☐ 基幹システムを 15 年以上、改修を重ねて使い続けている
- ☐ 自社で基幹システムを読み書きできる技術者が 1～2 名、いずれも 55 歳以上である
- ☐ 汎用機・オフコン・古いパッケージのサポート期限またはリース更新時期が 2～3 年以内にある
- ☐ 年間保守費・改修費が、目安として初期構築費の 15% 前後を超えている
- ☐ 設計書・業務ドキュメントが現存せず、ソースコードだけが手掛かりになっている
- ☐ 法制度対応（電子帳簿保存法・インボイス等）の改修費が都度数百万～数千万円かかっている
- ☐ 大手取引先から EDI・API 連携・トレーサビリティの要求が来ている
- ☐ 経営層が分析したいデータを、システムから取り出せていない
- ☐ 業務部門が Excel ツールで日常業務を補完している
- ☐ 中期経営計画で『業務効率化』『データ活用』『新規事業』を掲げているが、システム制約で進まない
まとめ｜2025 年の崖は『過ぎた』のではなく『今から本格化』する
経済産業省 DX レポートが警告した 2025 年の崖は、節目を過ぎても解消されていません。むしろ、技術者引退・サポート期限・取引先要求が同時に押し寄せる『正念場』 に、いま中堅企業の多くが入りつつあります。崖の手前で立ち止まる時期は終わり、『崖を越えて、次の地面にどう着地するか』を考える段階に入りました。
着地の選択肢は、リホスト・リライト・ERP 移行の 3 つ。どれを選ぶかは、自社のレガシー資産が業界差別化に寄与しているか／単に過去の事情で複雑化しているだけかという経営判断です。検討フェーズだけでも 3～6 ヶ月、稼働まで含めれば 15～27 ヶ月——『今から動いても、稼働は 2027～2028 年』という時間軸を踏まえ、まずは 3 ヶ月以内に現状整理と方針検討を始めること で、選択肢の幅を確保しやすくなります。
株式会社クオンツでは、『自社のレガシー資産の現状診断』『3 方式（リホスト／リライト／ERP 移行）の経済合理性比較』『放置コストと刷新投資の比較整理』『現実的な移行ロードマップ設計』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社の業種・規模・基盤状況に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
