「2025年の崖」の期限は過ぎた。しかし問題は残っている
経済産業省が2018年に公表した「DXレポート」で提唱された「2025年の崖」。レガシーシステムの放置によって、2025年以降に最大で年間12兆円の経済損失が生じるという警告は、多くの企業に衝撃を与えた。
2026年現在、その「2025年」はすでに過ぎた。しかし、レガシーシステムの問題が解消されたわけではない。JUASの「企業IT動向調査2026」によれば、中堅・中小企業の約4割が依然として10年以上前に構築された基幹システムを使い続けている。問題は先送りされただけであり、むしろ時間の経過とともに状況は悪化している。
本記事では、基幹システムの老朽化に課題を感じている経営層やDX推進担当者（山本さんのような事業責任者）、IT管理者（鈴木さんのようなマネージャー層）に向けて、レガシーシステム刷新の費用感、ROI計算の考え方、そして現実的な移行戦略を解説する。
レガシーシステム放置のコスト：見えない出血が続いている
「動いているシステムに手を入れるのはリスクだ」という声は理解できる。しかし、放置にもコストがかかっていることを認識すべきだ。
放置コスト1：保守費用の増大
レガシーシステムの保守を担える技術者は年々減少している。COBOL、VB6、古いJavaフレームワークなどの技術に精通したエンジニアは引退が進み、人材の希少性が高まっている。その結果、保守の人月単価は上昇し続けている。
10年前であれば月額50万円で契約できた保守エンジニアが、現在は80万〜100万円を要求されるケースは珍しくない。
放置コスト2：ハードウェアのEOL（End of Life）
古いシステムが稼働するサーバーやネットワーク機器も老朽化が進む。メーカーの保守サポートが終了（EOL）した機器を使い続けることは、障害発生時に部品交換ができないリスクを抱えることになる。
放置コスト3：セキュリティリスク
サポートが終了したOSやミドルウェアは、新たに発見された脆弱性へのパッチが提供されない。セキュリティインシデントが発生した場合の損害は、システム刷新費用をはるかに上回ることが多い。
放置コスト4：ビジネス機会の逸失
レガシーシステムは外部サービスとのAPI連携やデータ活用に対応できないことが多く、新規サービスの立ち上げやビジネスモデルの変革を阻害する。この「逸失利益」は定量化が難しいが、最も深刻なコストかもしれない。
放置コスト5：属人化リスク
「この処理の仕様を知っているのはAさんだけ」「このバッチ処理はBさんしかメンテできない」。こうした属人化は、担当者の退職や異動とともにシステムがブラックボックス化するリスクを意味する。
刷新の4方式：リホスト、リプラットフォーム、リファクタ、リプレイス
レガシーシステムの刷新方式は、大きく4つに分類される。それぞれの特徴、費用感、適用場面を整理する。
方式1：リホスト（Rehost）
概要： 既存のアプリケーションをほぼそのまま、新しいインフラ（主にクラウド）に移行する方式。「リフト＆シフト」とも呼ばれる。
メリット：
- 移行期間が短い（数週間〜数か月）
- アプリケーションの改修が最小限
- コストが比較的低い
デメリット：
- クラウドのメリット（スケーラビリティ、マネージドサービス活用）を十分に活かせない
- 根本的なアーキテクチャの問題は解決しない
- ランニングコストが最適化されない場合がある
費用目安（従業員100人規模の基幹システム）： 300万〜800万円
適用場面： ハードウェアのEOL対応が急務で、短期間で移行する必要がある場合
方式2：リプラットフォーム（Replatform）
概要： アプリケーションの基盤（OS、ミドルウェア、データベース）を新しいプラットフォームに移行しつつ、一部を最適化する方式。
メリット：
- リホストより効率的なクラウド利用が可能
- データベースのマネージドサービス移行などでランニングコストを最適化できる
- アプリケーションの大幅な改修は不要
デメリット：
- プラットフォーム変更に伴うテスト工数が発生する
- アプリケーションの根本的な課題（UI/UX、機能不足）は解決しない
費用目安（従業員100人規模の基幹システム）： 500万〜1,500万円
適用場面： クラウドの利点を一定程度活かしたいが、フルリプレイスの予算・期間が確保できない場合
方式3：リファクタ（Refactor）
概要： 既存のアプリケーションのアーキテクチャを再設計し、コードを書き直す方式。機能は原則として現行踏襲だが、技術基盤を刷新する。
メリット：
- クラウドネイティブなアーキテクチャに移行できる
- マイクロサービス化やAPI化で将来の拡張性が高まる
- 技術的負債を大幅に解消できる
デメリット：
- 費用・期間が大きい
- 現行システムの仕様を正確に把握する必要がある（ドキュメントがない場合は特に困難）
- 移行中の並行稼働期間が長くなる
費用目安（従業員100人規模の基幹システム）： 1,500万〜5,000万円
適用場面： 現行機能を維持しつつ、技術基盤を根本的に刷新したい場合
方式4：リプレイス（Replace）
概要： 既存システムを廃棄し、新しいシステムをゼロから構築する、またはパッケージ製品・SaaSに置き換える方式。
メリット：
- 業務プロセスの見直しを含めた抜本的な改革が可能
- 最新の技術・UI/UXを採用できる
- パッケージ/SaaS置き換えの場合、開発コストを大幅に削減できる場合がある
デメリット：
- 費用・期間が最も大きい（スクラッチ開発の場合）
- 業務プロセスの変更に伴う現場の負荷が高い
- データ移行が複雑になる
費用目安（従業員100人規模の基幹システム）：
- SaaS/パッケージ置き換え：300万〜1,000万円（初期費用）+月額利用料
- スクラッチ開発：2,000万〜8,000万円
適用場面： 現行システムの機能・業務プロセス自体を見直したい場合、または業界標準のパッケージ/SaaSで代替可能な場合
4方式の比較表
| 項目 | リホスト | リプラットフォーム | リファクタ | リプレイス |
|---|---|---|---|---|
| 費用 | 低 | 中 | 高 | 最高（スクラッチ）/中（SaaS） |
| 期間 | 短（1〜3か月） | 中（3〜6か月） | 長（6〜18か月） | 最長（12〜24か月）/中（SaaS） |
| 業務プロセス変更 | なし | 最小限 | 最小限 | 大きい |
| 技術的負債の解消 | なし | 一部 | 大幅 | 完全 |
| クラウド最適化 | 低 | 中 | 高 | 高 |
| リスク | 低 | 中 | 中〜高 | 高 |
ROI計算の考え方
レガシーシステム刷新の投資判断には、定量的なROI計算が不可欠だ。経営層を説得する材料としても重要になる。
ROI計算の基本式
メリットの定量化
1. 保守費用の削減
- 現行の年間保守費用と、刷新後の年間保守費用の差額を算出する
- 例：年間保守費用が600万円から300万円に削減→年間300万円の削減
2. 運用効率の改善
- 手作業で行っていた処理の自動化による工数削減を算出する
- 例：月20時間の手作業がゼロになる→年間240時間×時給3,000円=年間72万円の削減
3. インフラコストの最適化
- オンプレミスからクラウドへの移行による費用削減を算出する
- 例：サーバー維持費年間200万円がクラウド利用料年間120万円に→年間80万円の削減
4. セキュリティリスクの低減
- セキュリティインシデント発生時の想定損害額×発生確率で期待損害額を算出する
- 例：想定損害額5,000万円×年間発生確率5%=期待損害額250万円/年
5. ビジネス機会の創出
- 新システムで可能になる新サービス・新機能による売上増加を見積もる
- 定量化が難しい場合は、定性的なメリットとして記載する
ROI計算例
従業員100人規模の製造業が、20年稼働の生産管理システムをリプラットフォーム方式で刷新する場合。
刷新費用（初期投資）： 1,200万円
年間メリット：
| 項目 | 金額 |
|---|---|
| 保守費用の削減 | 250万円/年 |
| 運用効率の改善 | 80万円/年 |
| インフラコストの削減 | 100万円/年 |
| セキュリティリスク低減（期待値） | 150万円/年 |
| 年間メリット合計 | 580万円/年 |
この例では約2年で投資を回収できる計算になる。経営層への説明では「5年間で1,700万円のリターンが得られる投資」と表現できる。
活用可能な補助金・税制優遇
レガシーシステム刷新の費用負担を軽減できる補助金や税制優遇制度がある。
IT導入補助金
中小企業のITツール導入を支援する補助金。基幹システムの入れ替えやクラウドサービスへの移行が対象となるケースがある。
- 補助額：最大450万円（通常枠）、最大3,000万円（デジタル化基盤導入枠の一部カテゴリ）
- 補助率：1/2〜3/4
- 注意点：IT導入支援事業者として登録されたベンダーのツール・サービスが対象
事業再構築補助金
事業モデルの転換を伴うシステム刷新であれば対象になる可能性がある。
DX投資促進税制
DXに関する投資について、特別償却（30%）または税額控除（3〜5%）が適用される制度。適用にはDX認定の取得が前提となる。
各自治体の独自補助金
東京都の「DX総合支援事業補助金」をはじめ、各自治体がDX推進に関する独自の補助金を設けている場合がある。自治体の産業振興部門や中小企業支援センターに問い合わせることを推奨する。
現実的な移行戦略：段階的アプローチのすすめ
レガシーシステムの刷新を「一括置き換え」（ビッグバン方式）で行うのはリスクが高い。特に中小企業では、以下のような段階的アプローチを推奨する。
フェーズ1：現状分析と方針決定（1〜2か月）
- 現行システムの棚卸し（機能一覧、連携先、利用頻度）
- 業務フローの可視化（As-Is分析）
- 刷新方式の選定と概算費用の算出
- ROI試算と経営層への報告
フェーズ2：パイロット移行（3〜6か月）
- 影響範囲が小さいサブシステムから着手する
- 移行手順の確立とリスクの洗い出し
- 運用チームの習熟
フェーズ3：段階的な移行（6〜18か月）
- パイロットで確立した手順を基に、主要システムを段階的に移行する
- 旧システムと新システムの並行稼働期間を設ける
- 各段階で効果測定を行い、計画を調整する
フェーズ4：旧システムの廃止（1〜3か月）
- 新システムへの完全移行を確認した上で、旧システムを停止する
- データのアーカイブと廃棄ルールを決定する
刷新プロジェクトでよくある失敗とその回避策
失敗1：現行踏襲の罠
「現行システムと全く同じ機能を再現してほしい」という要件は、一見合理的に思えるが実は危険だ。現行システムには「誰も使っていない機能」「当時の制約による回避策として実装された機能」が数多く含まれている。それらをすべて再現すると費用が膨れ上がる。
回避策： 機能の利用頻度を分析し、実際に使われている機能だけを移行対象とする。
失敗2：データ移行の軽視
データ移行は刷新プロジェクトの中で最も工数が読みにくい工程だ。データ形式の不整合、欠損データの補完、マスタデータの統合など、想定外の作業が発生しやすい。
回避策： プロジェクトの早い段階でデータ移行のPoC（概念実証）を実施し、課題を洗い出す。
失敗3：現場の巻き込み不足
IT部門や経営層だけで刷新を進め、実際にシステムを使う現場の声を聞かないケース。リリース後に「使いにくい」「前の方が良かった」という不満が噴出する。
回避策： 要件定義の段階から各部門のキーパーソンをプロジェクトに参画させる。
「完璧な移行」より「着手すること」が重要
レガシーシステムの刷新は、費用も期間もかかる大きなプロジェクトだ。だからこそ先送りにされがちだが、放置するほどコストは増大し、選択肢は狭まっていく。
重要なのは、完璧な計画を立ててから始めることではなく、まず現状を正確に把握し、小さなステップから着手することだ。フェーズ1の現状分析だけでも実施すれば、自社のレガシーシステムのリスクと刷新の方向性が見えてくる。
移行診断の無料相談
レガシーシステムの現状分析から刷新方式の選定、ROI試算、補助金の活用まで、貴社の状況に合わせた移行ロードマップをご提案します。まずは現状の棚卸しからお手伝いします。
※ 営業電話はしません | オンライン対応可 | 相談だけでもOK
まとめ
「2025年の崖」の期限は過ぎたが、レガシーシステムの問題は解消されていない。放置コスト（保守費用増大、セキュリティリスク、ビジネス機会の逸失）は時間とともに積み上がり続けている。
刷新の方式はリホスト、リプラットフォーム、リファクタ、リプレイスの4つがあり、自社の状況（予算、期間、業務プロセス変革の必要性）に応じて選択する。ROI計算で投資対効果を定量化し、補助金も積極的に活用する。そして何より、段階的なアプローチで「まず着手する」ことが最も重要だ。
基幹システムの老朽化に課題を感じているなら、まずは現行システムの棚卸しから始めてほしい。現状が可視化されれば、次に取るべきアクションは自ずと見えてくる。
追加の一次情報・確認観点
この記事の内容を社内で検討する場合は、一般論だけで判断せず、次の一次情報と自社データを照合してください。特に、稟議・RFP・ベンダー選定では「何を実装するか」よりも「どのリスクをどの水準まで下げるか」を先に決めると、見積もり比較のブレを抑えられます。
| 確認領域 | 参照先 | 自社で確認すること |
|---|---|---|
| デジタル調達 | デジタル庁 | 要件定義、調達、プロジェクト管理の標準観点を確認する |
| Webアプリ品質 | OWASP ASVS | 認証、認可、入力検証、ログ、セッション管理を確認する |
| DX推進 | 経済産業省 DX | レガシー刷新、経営課題、IT投資判断の前提を確認する |
| DX推進 | IPA デジタル基盤センター | DX推進指標、IT人材、デジタル基盤の観点で現状を確認する |
| 個人情報 | 個人情報保護委員会 | 個人情報・委託先管理・利用目的・安全管理措置を確認する |
稟議・RFPで使う数値設計
投資判断では、導入前後で測れる指標を3から5個に絞ります。下表のように、現状値・目標値・測定方法・責任者をセットにしておくと、PoC後に本番化するかどうかを判断しやすくなります。
| 指標 | 現状確認 | 目標の置き方 | 失敗しやすい例 |
|---|---|---|---|
| 対象業務数 | 現状の対象業務を棚卸し | 初期は1から3業務に限定 | 対象を広げすぎて要件が固まらない |
| 月間処理件数 | 件数、担当者、例外率を確認 | 上位20%の高頻度業務から改善 | 件数が少ない業務を先に自動化する |
| 例外対応率 | 手戻り、確認待ち、属人判断を計測 | 例外の分類と承認ルールを定義 | 例外をAIやシステムだけで吸収しようとする |
| 追加要件率 | 過去案件の変更件数を確認 | 要件凍結ラインを設定 | 見積後に仕様が増え続ける |
| 障害・手戻り件数 | 問い合わせ、障害、改修履歴を確認 | 受入基準とテスト観点を定義 | テストをベンダー任せにする |
よくある失敗と回避策
| 失敗パターン | 起きる理由 | 回避策 |
|---|---|---|
| 目的が曖昧なままツール選定に入る | 比較軸が価格や機能数に寄る | 経営課題、業務課題、測定KPIを先に固定する |
| 現場確認が不足する | 例外処理や非公式運用が見落とされる | 担当者ヒアリングと実データ確認を必ず行う |
| 運用責任者が決まっていない | 導入後の改善が止まる | 業務側とIT側の責任分界をRACIで定義する |
| RFPが抽象的で見積が比較できない | 業務フロー、データ、非機能要件が不足 | 見積前に要件定義と受入条件を固める |
GXOに相談する前に整理しておく情報
初回相談では、次の情報があると診断と提案の精度が上がります。すべて揃っていなくても問題ありませんが、分かる範囲で用意しておくと、概算費用・期間・体制の見立てを早く出せます。
- 対象業務の現行フロー、利用中システム、Excel・紙・チャット運用の一覧
- 月間件数、担当人数、手戻り件数、確認待ち時間などの概算
- 個人情報、機密情報、外部委託、権限管理に関する制約
- 希望開始時期、予算レンジ、社内承認者、決裁までの流れ
- 既存システム構成、画面・帳票・データ項目、外部連携、現行ベンダー契約
GXOでは、現状整理、要件定義、RFP作成、ベンダー比較、PoC設計、本番移行計画まで一気通貫で支援できます。記事の内容を自社に当てはめたい場合は、まずは現在の課題と制約を共有してください。