「2025年の崖」とは？経産省が警告する最大12兆円損失の正体と情シスが今すぐ動くべき理由
「うちの基幹システム、そろそろ限界かもしれない…」と感じながらも、リプレースの踏み出し方がわからず、現状維持を続けている情シスの方は多いのではないでしょうか。
経済産業省は2018年のDXレポートで、「2025年の崖」という衝撃的な警告を発しました。老朽化・複雑化・ブラックボックス化したレガシーシステムを放置した場合、2025年以降に最大12兆円/年の経済損失が生じる可能性があるという試算です。
本記事では、「2025年の崖」が具体的に何を意味するのか、なぜ問題なのか、そして情シス担当者として今すぐ動くべき理由と対策を、わかりやすく解説します。
目次
想定読者
本記事は、次のような方を想定しています。
- 「2025年の崖」という言葉を耳にしたが、詳細を把握していない情シス担当者
- 基幹システムの老朽化を感じているが、経営層への説明材料を探している方
- レガシーシステムのリプレースを検討しているが、優先度・タイミングを悩んでいる方
- DX推進の文脈で、自社のシステム課題を整理したい方
1. 「2025年の崖」とは何か
「2025年の崖」は、経済産業省が2018年9月に公表した「DXレポート〜ITシステム『2025年の崖』の克服とDXの本格的な展開〜」で提唱されたコンセプトです。
経産省が描いた「崖」の正体
経産省が描いたシナリオは、大まかに以下の3つの問題が重なり合うことで、2025年前後から企業のIT競争力が急激に崩壊するというものです。
問題①：基幹系システムの老朽化・複雑化・ブラックボックス化
日本企業の多くは、1990年代〜2000年代に構築した基幹システムを今なお使い続けています。長年の改修・追加・パッチ当てにより、システムは複雑に絡み合い、もはや誰も全体像を把握できない「ブラックボックス」状態になっています。
この状態では、新たな機能追加や他システムとの連携が困難になるだけでなく、障害が発生した際の原因特定・復旧にも莫大な時間とコストがかかります。
問題②：ITエンジニアの高齢化・技術継承不足
レガシーシステムを支えるCOBOL・RPG・PL/I・VB6といった旧世代の言語を扱えるエンジニアは、急速に高齢化しています。経産省の試算では、2025年には既存のIT人材の半数近くがレガシーシステムの維持・保守に費やされ、新たなDX推進に回せるリソースが枯渇する可能性があると警告しています。
問題③：サポート終了ラッシュ
2025年前後には、主要なソフトウェア・OSのサポート終了が相次ぎます。
- Windows 10：2025年10月にサポート終了
- SQL Server 2014：2024年7月にサポート終了済み
- Oracle製品の一部バージョン：2025〜2027年に順次EOS
サポートが切れたシステムをそのまま使い続けることは、セキュリティリスクの放置と同義です。
「最大12兆円/年」という試算
経産省のレポートでは、上記3つの問題が解決されないまま推移した場合、2025年以降に最大12兆円/年の経済損失が生じると試算しています。その内訳は、システム障害による損失・セキュリティインシデントによる損害・DX機会損失（競合他社に先を越される損失）などです。
この数字はあくまで試算ですが、「対応しなくても何とかなる」という楽観論がいかに危険かを示すシグナルとして、多くの経営者・情シス担当者に刺さっています。
2. 2025年を過ぎた今、「崖」はどうなったか
「2025年の崖」という言葉が生まれてから約8年。2026年の今、実際にどのような状況になっているのでしょうか。
現実：61%の企業にレガシーが残存
経産省は2025年5月に公表した最新レポートでも、依然として61%の企業にレガシーシステムが残存していることを確認しています。つまり、「崖」はまだ終わっていません。崖は「急落した崖」ではなく、今まさに立っている崖の縁なのです。
なぜ対応が進まなかったのか
多くの企業が「2025年の崖」を認識しながらも、対応できなかった理由には以下のパターンがあります。
「今動いているから、まあいい」症候群
システムが一応稼働しているうちは、リプレースの緊急性が感じにくいのが現実です。「今期の予算がない」「来年にする」という先送りが続き、気づけば10年が経過しています。
「何から手をつければいいかわからない」問題
レガシーシステムは複雑に絡み合っているため、どこから手をつければいいか見通しが立ちません。担当ベンダーに相談しても「費用がかかる」「リスクが高い」という答えが返ってくるだけで、前に進めないという声をよく聞きます。
「移行コストが高すぎる」という壁
基幹システムの移行は、規模にもよりますが数千万〜数億円の投資が必要になることがあります。経営層への説明・稟議を通すのが難しく、腰が上がらないケースも多いです。
3. 「2025年の崖」を放置すると何が起きるか
「しばらくは現状維持で」という判断が、具体的にどのようなリスクを生むのかを整理します。
リスク①：セキュリティインシデントの急増
サポートが終了したOS・ミドルウェア・データベースは、セキュリティパッチが提供されなくなります。発見された脆弱性に対して無防備な状態が続くことになり、ランサムウェアや不正アクセスの標的になりやすくなります。
製造業では、生産管理システムや在庫管理システムが攻撃を受けて生産ラインが止まる事例も実際に起きています。システム停止1日あたりの損失は、企業規模によっては数千万円に上ることもあります。
リスク②：IT人材が「守り」だけで消耗する
老朽化したシステムの保守・維持には、比例して人手がかかります。既存システムの「火消し」に追われるエンジニアは、新しいDX施策や業務効率化に割くリソースがなくなります。結果として、デジタル化で先行する競合他社との差が開いていきます。
リスク③：業務の「デジタルデット（技術的負債）」が累積
レガシーシステムに合わせて手作業・Excel運用で補っていた業務が、年々積み上がります。「この業務は〇〇さんしか知らない」「マニュアルがない」という属人化が進み、ベテラン社員の退職とともに業務ノウハウが失われるリスクが高まります。
リスク④：新しい技術・サービスとの連携ができない
クラウド・AI・IoTといった新技術と連携するには、一定のAPIやデータ形式への対応が必要です。スパゲッティ化したレガシーシステムでは、このような外部連携が非常に困難で、DX施策の足枷になります。
4. 「2025年の崖」への対応策：7Rアプローチ
では、レガシーシステムの問題にどう対処すればよいのか。グローバルで広く使われているフレームワークが「7R」です。システムの状況に応じて、7つの対応方針から最適なものを選択します。
7Rとは
| R | 方針 | 概要 |
|---|---|---|
| Retire（廃止） | 使われていないシステムを廃止する | 利用頻度が極めて低いシステムは、思い切って廃止する |
| Retain（維持） | 現状維持・当面は変更しない | 刷新の費用対効果が低いシステムは一時的に維持する |
| Rehost（再ホスト） | そのままクラウドへ移す（Lift & Shift） | アプリのコードを変えずにクラウドへ移行。最も低コスト |
| Replatform（再プラットフォーム） | 部分的に最適化してクラウドへ移す | DBをマネージドサービスに移すなど、一部を近代化 |
| Repurchase（再購入） | パッケージ・SaaSへ切り替える | 現在のシステムをSaaSやクラウドERPへ置き換える |
| Refactor（再設計） | アーキテクチャを根本から見直す | クラウドネイティブに再設計。最も効果が大きいが工数も大 |
| Rearchitect（再構築） | スクラッチで作り直す | 要件が特殊・業務フローが複雑な場合に完全スクラッチ開発 |
中小〜中堅企業に多い現実的な選択肢
大企業はRefactor・Rearchitectによる大規模刷新を選ぶケースが増えています。一方、中小〜中堅企業では、以下の段階的アプローチが現実的です。
- まず「Retire」で棚卸し：使われていないシステム・機能を特定して廃止し、保守コストを圧縮する
- 次に「Rehost」でリスク軽減：オンプレミスのサーバーをクラウドへ移すことで、ハードウェア老朽化リスクを解消する
- 段階的に「Refactor / Rearchitect」へ：コアの業務システムを順次モダナイズする
「一気にすべてを新しくする」のではなく、リスクと投資を分散しながら進めるのがポイントです。
「自社のレガシーシステムをどう整理すればいいかわからない」という方は、まずc3indexへご相談ください。現状のシステム棚卸しから、優先度の整理・移行計画の策定まで、一緒に考えます。
5. 情シスが経営層を動かすための「崖の見せ方」
「2025年の崖」への対応が必要だとわかっていても、予算・人員を動かすには経営層の理解と承認が必要です。この章では、情シス担当者が経営会議で使えるロジックを整理します。
「コスト論」より「リスク論」で話す
「システムを新しくするためにX億円かかります」という提案は通りにくいですが、「現状維持を続けた場合のリスクはこれだけある」という論法は刺さります。
具体的には以下の観点で試算を提示すると効果的です。
- セキュリティ事故が起きた場合のダウンタイムコスト（生産停止・対応工数・顧客対応）
- 現在の保守コストが毎年いくらかかっているか（既存保守費 vs 移行後の運用費の比較）
- IT人材が守りに費やしている時間の機会損失（保守工数 × 人件費単価）
「段階的な投資計画」を見せる
一括で大きな投資を求めるのではなく、「3年間でこのフェーズに分けて進めます」という計画を示すと、経営層は意思決定しやすくなります。
フェーズ1（初年度）：現状調査・棚卸し・移行方針の決定
フェーズ2（2年目）：優先度の高いシステムから段階移行開始
フェーズ3（3年目）：コアシステムの刷新・新機能開発へ移行
「競合他社はどうしているか」を添える
同業他社や競合のDX取り組みを引き合いに出すことで、「このままでは差をつけられる」という危機感を経営層に持ってもらいやすくなります。業界紙・経産省レポート・調査レポートなどを活用すると信頼性が増します。
6. 「2025年の崖」を乗り越えた先にある姿
危機感ばかりを煽るのではなく、「崖を乗り越えた企業はどうなるか」も見ておきましょう。
スピードが変わる
モダンなシステム（クラウドネイティブ・APIファースト）に移行した企業では、新機能のリリースサイクルが劇的に短縮します。以前は半年かかっていたシステム改修が、数週間でできるようになります。
データ活用が始まる
クラウドベースのシステムに統一することで、散在していたデータが一元化されます。販売データ・在庫データ・生産データをリアルタイムで分析し、経営判断に活用できるようになります。
人材が「攻め」に回れる
システムの保守・火消しに追われていたエンジニア・情シス担当者が、DX施策や業務改善に集中できるようになります。「ITはコストセンター」から「ITは競争力の源泉」へ変わる瞬間です。
よくある質問
Q. うちの会社はまだ影響を受けていないと思うのですが、本当に「崖」に近いですか？
A. 多くの企業で「今は動いているから大丈夫」と判断されがちですが、経産省の調査では2026年現在も61%の企業にレガシーが残存しています。特に、2010年以前に構築されたシステムが現役で動いている場合、サポート切れ・人材不足・保守コスト増大のリスクが累積している可能性が高いです。まずは現状の棚卸しから始めることをおすすめします。
Q. 「2025年の崖」対応で、何から着手すればよいですか？
A. まず「現在稼働しているシステムの一覧化」から始めることをおすすめします。各システムの構築年・使用ソフトウェアのバージョン・サポート終了日・現在の保守担当者を一覧にするだけで、リスクの全体像が見えてきます。次に、7Rの観点でどの方針を取るか優先度をつけていきます。
Q. 基幹システムの移行にはどのくらいの費用がかかりますか？
A. システムの規模・複雑度・移行方式によって大きく異なります。小規模なシステムの再ホスト（クラウド移行）であれば数百万円程度から、大規模な基幹システムのスクラッチ再構築では数千万〜数億円規模になることもあります。まずは現状調査と要件整理を行い、適切な見積もりを取ることが重要です。
Q. SIerへの外部委託か、内製化か、どちらがよいですか？
A. レガシーシステムの移行に関しては、多くの場合SIerへの外部委託が現実的です。理由は、（1）既存システムの調査・解析には専門的なスキルが必要、（2）移行期間中も既存業務を止められないため、並行稼働の管理が複雑になる、（3）旧言語（COBOL・RPG等）の知識が必要になるケースがある、といった点があるためです。ただし、移行後の運用・保守は内製化していく方向が理想的です。
Q. 「段階的移行」と「一括移行」、どちらが良いですか？
A. 中小〜中堅企業では段階的移行が一般的です。一括移行はリスクが高く、業務停止のリスクを最小化するために、重要度・影響度の低いシステムから順に移行を進めるアプローチを取ります。ただし、システム間の依存関係が強い場合は、順序設計が重要になります。
まとめ
本記事のポイントをまとめます。
- 「2025年の崖」は経産省が2018年に警告した、レガシーシステムの老朽化・IT人材不足・サポート終了ラッシュが重なる問題
- 放置した場合、最大12兆円/年の経済損失が発生する可能性があると試算されている
- 2026年現在も61%の企業にレガシーが残存しており、「崖」はまだ現在進行形
- 対応策は「7R」フレームワークを使い、段階的に優先度をつけて進めるのが現実的
- 経営層を動かすには「リスク論」と「段階的投資計画」の組み合わせが有効
「どこから手をつければいいかわからない」という段階から、c3indexはご一緒できます。ぜひお気軽にご相談ください。
c3index にシステム移行・モダナイズを相談する
c3index（シースリーインデックス株式会社）は、名古屋・東京を拠点に、製造業・中堅企業の基幹システム開発・保守・クラウド移行を支援するシステム会社です。
レガシーシステムの現状調査・整理から、移行計画の策定・スクラッチ開発・AWS移行まで、一貫してサポートします。「まず話を聞いてほしい」という段階から、お気軽にご相談ください。
