「2025 年の崖という言葉は聞くが、結局いつまでに何をすればいいのか分からない」「古い基幹システムが事業の足を引っ張っているのは分かっているが、止められないし作り直すのも怖い」。経営層や情報システム部門で DX を任されると、こうした宙ぶらりんの状態に置かれがちです。本記事では、経済産業省が警鐘を鳴らしてきた 2025 年の崖とは何かを先に結論からおさらいし、放置した場合に積み上がるリスク、刷新が止まる構造的な理由、そして AI 駆動開発でレガシーを読み解き段階的に移行する具体的な進め方までを、AI 駆動開発のクリエイティブスタジオとして実際の刷新案件で使っている手順とともに整理します。

2025 年の崖とは｜DX レポートが出した結論

先に結論を書きます。2025 年の崖とは、老朽化・複雑化・ブラックボックス化した既存システムを抱えたまま放置すると、企業が新しいデジタル競争に乗れず、社会全体で最大年間 12 兆円規模の経済損失が生じうる、という経済産業省の警告です。出典は同省が 2018 年に公表した「DX レポート」で、その後の「DX レポート 2」などでも繰り返し論点が引き継がれています。

ここで言う「崖」は、ある日突然システムが落ちるという話ではありません。むしろ逆で、動き続けているからこそ手を付けられず、保守できる人がいなくなり、新しい仕組みと連携できず、気づいたときには身動きが取れなくなっている。その「じわじわ追い詰められていく構造」を崖と表現しています。

DX レポートが特に問題視したのは次の点です。多くの企業の基幹システムが構築から 20 年前後を経て老朽化していること。改修を重ねた結果、誰も全体像を把握できないブラックボックスになっていること。そして、それを支えてきた技術者が高齢化・退職し、保守人材が枯渇していくこと。2025 年という年は、こうした要因が重なって顕在化する目安として置かれた節目であり、期限そのものより「先送りするほど移行が難しくなる」というメッセージのほうが本質です。

つまり、2025 年を過ぎたからもう関係ない、という話ではありません。崖は先送りされた分だけ高くなる構造なので、いま現役で動いている古いシステムを抱える企業にとって、対策の重要性はむしろ増しています。

崖を放置すると何が起きるのか

崖を放置するコストは、一度きりの出費ではなく毎年積み上がる構造で発生します。大きく 3 つに分けて見ておきます。

まず保守・運用コストです。古い言語や基盤を扱える技術者は年々減り、扱える人ほど単価が上がります。延長サポート契約料、互換性を保つためのパッチの作り込み、属人化した保守要員の確保といった費用が毎年かかり続けます。しかもこれは延命のための出費であって、システムが新しくなるわけではありません。お金を払って現状維持しているだけ、という状態が続きます。

次に機会損失です。古いシステムは新しい連携やデータ活用を阻みます。新サービスを始めようとしても基幹側が対応できない、社内に散らばったデータを横断して見たいのに古い設計が足かせになる、といった形で、本来取れたはずの売上や効率化が取れないまま時間が過ぎます。この損失は請求書に載らないため見えにくく、だからこそ見過ごされがちです。

そして事故が起きたときの損失です。サポートが切れた環境はセキュリティ更新が止まっており、既知の脆弱性が放置されたまま動き続けます。障害や情報漏えいが起きたときの被害額と復旧費は読めず、事業停止に直結することもあります。経済産業省が示した最大年間 12 兆円という試算は、こうした損失を社会全体で積み上げた規模感です。

放置を選ぶときに見落とされがちなのは、「いまは動いているから大丈夫」という判断が、実は毎年コストを払い続ける選択だという点です。延命費用の年額に残りの使用想定年数を掛けた総額を出すと、刷新費用と並べて比べられるようになり、放置がいちばん高い選択肢だったと分かるケースは少なくありません。刷新側の費用と期間の規模別レンジは レガシー刷新の費用と期間 に実案件ベースでまとめています。判断軸の整理はシステム刷新の進め方ガイドでも詳しく扱っています。

なぜレガシー刷新は止まるのか

放置がコストだと分かっていても、刷新はなかなか始まりません。その理由はだいたい 2 つに集約されます。ブラックボックス化と属人化です。

ブラックボックス化とは、長年の改修の積み重ねで、いま動いているシステムが何をどう処理しているのかを誰も全体像として説明できない状態を指します。設計書は現存しないか、あっても実態とずれています。「この条件のときだけ違う計算をしている」「特定の取引先だけ別フローを通している」といった暗黙のルールがコードの奥に埋まっており、それを把握しないまま作り直すと業務が壊れます。だから怖くて手を出せない、という心理が働きます。

属人化は、そのブラックボックスを「なんとなく分かっている人」が一人か二人しかいない状態です。その人が退職すれば、残るのは誰も読めないコードだけになります。逆に言えば、その人がいる間はだましだまし運用できてしまうため、刷新の優先度が上がりません。問題が深刻になるのは決まって、その人がいなくなった後です。

この 2 つが組み合わさると、「現状が分からないから移行設計ができない」「移行設計ができないから見積もりが出ない」「見積もりが出ないから経営判断ができない」という連鎖で、入り口の手前で止まります。逆に言えば、最初の「現状を読み解く」工程をどれだけ速く・正確に進められるかが、刷新を動かせるかどうかの分かれ目です。ここがまさに AI 駆動開発が効いてくるところです。

刷新の選択肢：刷新／リプレイス／塩漬けの判断軸

崖への向き合い方は「全部作り直す」一択ではありません。現実的な選択肢を、判断軸とともに整理しておきます。

選択肢主に変えるもの向く状況注意点
塩漬け・延命何も変えず維持するあと数年で役目を終える業務毎年コストが積み上がる。止血策(隔離・WAF など)はしておく
部分刷新・リプレイス老朽化した範囲を区切って作り直す中核だが一括は重い基幹システム区切り方の設計を最初に決めないと結局一括になる
全面刷新システム全体を新しく作り直す今後 5 年以上中核で使い続ける初期費用は大きいが保守費削減と開発速度回復が継続的に効く

判断の中心に置くべきは、システムの残存価値です。今後どれだけの期間、どれだけ事業の中核として使い続けるのか。あと 2、3 年で別の仕組みに置き換わる予定の業務なら、無理に刷新せず延命や部分対応で十分なことが多い。一方、今後 5 年以上中核として使うなら、刷新の初期投資は保守費の削減と開発速度の回復で回収できる可能性が高くなります。塩漬け・部分刷新・全面リプレイスをどう見極めるかは、技術的負債の観点から 技術的負債の返済戦略 でも分岐基準を整理しています。

もう 1 つの軸は、止血の緊急度です。サポート切れでセキュリティ更新が止まっているなら、刷新の前にまず外部からの接続経路を断つ、対象を隔離する、といった緩和策で当面のリスクを抑える必要があります。期限ありきで全面刷新を強行すると品質を落としてかえって事故を招くため、先に止血してから腰を据えて移行するのが安全です。サポート終了（EOL）が迫るシステムへの具体的な対応手順は EOL を迎えるシステムの移行 にまとめています。

そして全面刷新を選ぶ場合でも、進め方は一括書き直しではなく段階移行が基本になります。機能とデータを区切って少しずつ新システムへ寄せていくことで、切り替え当日にリスクが集中するのを避けられます。この原則は AI を使うかどうか以前の、移行という行為そのものの鉄則です。

AI 駆動でレガシー読み解きと段階移行を加速する

ここからが本題です。刷新が止まる最大の理由が「現状を読み解けない」ことだとすれば、その工程を圧縮できれば刷新は一気に動き出します。AI 駆動開発は、まさにこの読み解きと再実装の初動で効果を発揮します。

既存コードの読み解きを AI で短縮する

設計書がなくても、出発点は動いているコードとデータベース、そして実際の業務です。従来はベテランが何週間もかけてコードを追い、業務ルールを頭の中に再構築していました。ここに Claude Code などの AI エージェントを入れると、コードベース全体を読み込ませて「この処理は何をしているか」「どのテーブルがどう使われているか」「例外的な分岐はどこにあるか」を要約・推定させられます。人手だけで追うより短期間で全体像をつかめ、属人化していた知識を文書として外に出せます。

ただし AI の出力はあくまで仮説です。重要な業務ルールはテストと現場確認で裏取りする前提を崩してはいけません。AI が「たぶんこう動く」と言ったことを鵜呑みにすると、ブラックボックスの中の暗黙ルールを取りこぼします。AI は読み解きの初速を上げる道具であって、検証を省く道具ではありません。

再実装と段階移行を回す

読み解いた業務ルールは、新システム側にテストとして書き起こしていきます。これが効く理由は 2 つあります。第一に、テストがそのまま「生きた仕様書」になり、後任への引き継ぎ資料を兼ねること。第二に、テストがあれば AI に再実装を任せても、業務ルールを満たしているかを自動で検証できることです。AI が書いたコードを人が一行ずつ確認する代わりに、テストが通るかどうかで品質を担保できる。この「テストで縛りながら AI に書かせる」進め方が、レガシー刷新の生産性を大きく押し上げます。

移行は段階的に進めます。機能とデータを区切り、参照系の画面から、あるいは特定の拠点・商品カテゴリから新システムへ寄せていく。新旧のデータを同期する仕組みと、問題が起きたら即座に旧システムへ戻す手順を用意しておけば、業務を止めずに少しずつ切り替えられます。AI を使う・使わないにかかわらず、この段階移行の設計が安全な刷新の土台です。具体的な手順はシステムリプレイスの進め方ガイドに 7 ステップで整理しています。

AI 駆動でのレガシー刷新を支援するサービスの全体像はシステム刷新・リプレイス支援に、DX 全体の伴走支援はDX 推進支援にまとめています。

実例：10 年もののシステムを期間半分でリプレイス

ここまでの進め方を実際に適用した事例を紹介します。卸売・流通業界の、年商 100 億規模の企業で 10 年稼働してきた業務システムの刷新です。詳細は10 年もののレガシーシステムを通常見積もり半分でリプレイスした事例にまとめています。

このシステムは Rails 5 系で構築され、長年の改修でブラックボックス化していました。設計書は実態とずれ、業務ルールはコードの奥に埋もれている、典型的な崖の手前の状態です。私たちはまず既存システムの棚卸しから入り、コードベースを AI で読み解いて処理の全体像と業務ルールの仮説を高速に作り、それを現場ヒアリングとテストで裏取りしていきました。

そのうえで、フロントエンドを全面刷新し、API をリアーキテクチャし、データ移行を段階的に進める方針を取りました。利用したのは Claude Code、Cursor、GitHub Copilot、そして OpenAPI Generator などです。業務ルールをテストとして新システム側に書き起こしながら AI に再実装を進めさせ、区切った範囲ごとに検証して新側へ寄せていく。この回し方によって、通常見積もりで 8 か月とみていた工数を、実質 4 か月で完了しました。期間にしておよそ半分です。

ポイントは、AI が単純に速くコードを書いたから短縮できたわけではない、という点です。最も時間がかかる「現状を読み解く」工程を AI で圧縮し、テストで品質を縛ったことで、人の確認コストを下げながら前に進めた。この組み合わせが期間半減の実体です。

刷新を始める前の現状診断チェックリスト

最後に、刷新の検討を始める前に押さえておきたい現状診断の観点をまとめます。これらが埋まっていれば、見積もりも移行設計も格段に進めやすくなります。

  • 対象システムの構築時期と、使っている言語・フレームワーク・基盤のバージョン、それぞれのサポート状況を把握できているか
  • そのシステムを保守できる技術者が社内・社外に何人いるか、その人たちがいなくなったときの代替手段があるか
  • 設計書が現存するか、現存する場合に実態とどれだけ一致しているか
  • 外部システムとの連携が何本あり、それぞれどんなデータをやり取りしているか
  • 業務上クリティカルな暗黙ルール(特定条件での例外処理、手運用でカバーしている箇所)を洗い出せているか
  • 機能やデータをどの単位で区切れば、部分的に新システムへ切り替えられそうか
  • このシステムを今後何年、どれだけ事業の中核として使い続ける見込みか(残存価値)

これらが「分からない」だらけでも問題ありません。むしろ崖の手前にいる多くの企業がそうです。重要なのは、現状把握そのものをいきなり全部やろうとせず、まず現状調査の範囲だけを切り出して進めることです。そこに AI 駆動の読み解きを使えば、診断の初動を大きく短縮できます。DX 全体をどの順序で進めるかはDX 推進の進め方ガイドも参考にしてください。

まとめ

2025 年の崖は、特定の年に起きる一度きりのイベントではなく、老朽化したシステムを放置するほど移行が難しくなり、保守コストと機会損失と事故リスクが毎年積み上がっていく構造的な問題です。刷新が止まる原因はブラックボックス化と属人化にあり、その入り口である「現状を読み解く」工程を AI 駆動開発で圧縮できれば、止まっていた刷新は動き出します。全面刷新でも段階移行を前提に、業務ルールをテストとして書き起こしながら AI に再実装を進めさせれば、品質を保ったまま期間を半分程度に短縮することも現実的です。崖は先送りした分だけ高くなります。動いているいまこそ、現状診断という小さな一歩から始めるのが最も安全です。

レガシー刷新を相談したい方は、まず無料の現状診断・見積もり相談からお問い合わせください。対象システムの棚卸し範囲を切り出し、刷新／リプレイス／塩漬けのどれが最適かを含めて、AI 駆動開発のクリエイティブスタジオが一緒に整理します。