「生成AIで設計書を自動生成し、レガシー解析の工数を大幅に圧縮した」「AIエージェントに古いコードを読ませ、仕様を復元する」——2026年に入り、こうしたモダナイゼーション事例の発表が急速に増えている。大手SIerや事業会社が相次いで「AI駆動開発によるレガシー刷新」を掲げ、これまで動かなかった基幹システムの刷新が現実味を帯びてきた、という論調が広がっている。

一方で、現場のIT部門長やDX推進責任者の実感は少し違うはずだ。ツールが進化しても、「どのシステムから手をつけるか」「どこまで作り替え、どこを残すか」「その予算をどう正当化し、誰が推進するか」という問いは何ひとつ消えていない。むしろAIによって着手のハードルが下がったからこそ、判断を誤ったまま速く走ってしまうリスクが高まっている。

本記事では、AI駆動開発を「実装を速くする道具」として正しく位置づけたうえで、レガシーモダナイゼーションを経営の意思決定とどう接続し、どう推進体制を組むかを、EA（エンタープライズアーキテクチャ）とPMOの視点から整理する。

課題：AIは「刷新できない理由」の一部しか溶かさない

経済産業省が2018年のDXレポートで警鐘を鳴らした「2025年の崖」は、老朽化・複雑化・ブラックボックス化したレガシーシステムがDXの足かせになるという問題提起だった。2025年5月に公表された「レガシーシステムモダン化委員会総括レポート」でも、産業界の脱レガシーは依然としてスピード感を欠き、レガシーが生成AIなど新技術の活用を妨げている、という現状認識が示されている。

レガシー刷新が進まない理由は、大きく分けると次のようになる。

  • 技術的な壁：仕様書が失われ、有識者も退職し、システムがブラックボックス化している
  • 費用対効果の壁：維持に予算の大半を取られ、刷新への投資余力が生まれない
  • 意思決定の壁：止められない基幹システムを、いつ・どの範囲で・どの順に刷新するか経営が決めきれない
  • 推進体制の壁：業務部門・情シス・ベンダーをまたぐ長期プロジェクトを束ねる司令塔がいない

生成AIやAI駆動開発が効くのは、主に一つ目の技術的な壁である。既存コードから仕様やデータフローを復元する、設計書のたたき台を生成する、テストを自動生成する——こうした作業の工数は確かに圧縮できる。これは大きな前進だ。

しかし、費用対効果・意思決定・推進体制の壁は、AIが自動で溶かしてくれるものではない。何を刷新対象とし、何を捨て、何を残すか。限られた投資をどこに配分するか。誰が責任を持って複数年のプロジェクトを完遂させるか。これらは従来どおり、経営とマネジメントが担う領域である。AIで着手コストが下がったいまこそ、この判断の質が刷新の成否を分ける。

背景：AI駆動開発が変えたのは「移行コストの相場」

なぜいま議論が過熱しているのか。本質は、AI駆動開発によってモダナイゼーションのコストとリスクの相場が変わったことにある。

これまで、レガシー刷新の最大のリスクは「現行仕様が分からないまま作り替えると、業務が止まる」ことだった。だからこそ多くの企業は、リスクを取って作り替えるより、塩漬けにして維持する道を選んできた。

AIによる現行資産の解析・可視化は、この「分からなさ」を部分的に埋める。何がどう動いているかを短期間で把握できれば、刷新の見積もり精度が上がり、移行の合理性を経営に説明しやすくなる。つまりAIは、実装を速くする以前に、「刷新するかどうかを判断するための情報コスト」を下げたことに大きな意味がある。

ただし注意すべきは、AIが復元するのは「いまどう動いているか（現行仕様）」であって、「これからどうあるべきか（目標像）」ではない、という点だ。目標アーキテクチャは、事業戦略から逆算して人が設計するしかない。ここを取り違えると、「AIで現行を精緻に写し取ったが、結局レガシーの構造をそのまま新環境に持ち込んだだけ」という結末になりかねない。

解決アプローチ：EAで「刷新の地図」を描いてから走る

AI時代のモダナイゼーションで最初にやるべきは、コーディングでもツール選定でもなく、刷新対象の全体像を描くことである。ここでEA（エンタープライズアーキテクチャ）の考え方が中心的な役割を果たす。

EAは、企業の業務・アプリケーション・データ・技術基盤の関係を俯瞰し、「現行の姿（As-Is）」と「あるべき姿（To-Be）」を整理する枠組みだ。モダナイゼーションの文脈では、次の順序で使う。

  1. 現行資産の棚卸しと可視化（As-Is）：どのシステムが、どの業務を、どのデータでつないでいるか。ここでAIによる解析が効く
  2. 重要度・老朽度の評価：事業への貢献度と技術的リスクの両軸で、各システムを格付けする
  3. 目標像の設計（To-Be）：事業戦略から逆算し、どの領域を強化し、どこを標準化・共通化するかを定める
  4. 移行方針の決定：システムごとに刷新の手段（後述）と順序を決める

このステップを踏むと、「全部を一度に作り替える」のではなく、「重要度が高く老朽度も高いものから、事業インパクトの順に刷新していく」という現実的な計画に落ちる。当社でも、散在するシステムとSaaSの全体像・業務との関係・重要度を整理し、IT投資と統廃合の意思決定を可能にした支援を行っている（事例：IT投資判断に向けたシステム可視化・重要度整理支援）。

刷新手段は「作り替える」だけではない

モダナイゼーションというと全面再構築を思い浮かべがちだが、実際にはシステムごとに手段を選び分ける。代表的な選択肢を、経営判断の観点で整理すると次のようになる。

手段概要向くケース経営上の論点
維持（Retain）当面そのまま使う安定稼働し、事業影響も変化も小さい塩漬けの正当化。将来の再評価時期を決めておく
廃止（Retire）使われていない機能を止める利用実態が乏しい「使っている人がいるかも」の棚卸しが要
移設（Rehost）中身を変えずクラウド等へ移す早くコスト構造を変えたい速いが、レガシーの構造は温存される
基盤刷新（Replatform）一部を作り替えつつ移行保守性を上げたい範囲設定を誤ると中途半端になる
再構築（Rebuild/Rearchitect）あるべき姿で作り直す事業の中核で変化も大きい効果は大きいが、期間・リスク・費用も最大
置換（Replace）SaaS等の既製品に置き換える自社独自性が低い領域業務を製品に合わせる覚悟が要る

AI駆動開発は、このうち特に再構築や基盤刷新のコストを押し下げる。従来は費用対効果が合わず「移設」で妥協していた領域を、「再構築」の射程に入れられるケースが出てきた。手段の選択肢そのものが広がっている、と捉えるとよい。

なお、止められない基幹システムを一気に置き換えるのは危険が大きいため、旧システムを動かしたまま新機能を外側から段階的に置き換え、最後に旧システムを退役させる「ストラングラーフィグ（絞め殺しの木）」型の段階移行が現実解になることが多い。AIによる現行解析は、この「どこから切り出せるか」の見極めにも役立つ。

進め方：推進体制とPMOの役割

モダナイゼーションは、数ヶ月では終わらない複数年のプログラムになる。ツールが速くなっても、業務部門・情シス・複数ベンダーをまたぐ長期戦を束ねる役割は必要であり続ける。ここがPMO（プロジェクト/プログラムマネジメントオフィス）の出番だ。

AI時代の刷新プログラムで、PMOが担うべき論点は次のとおりである。

論点PMOが果たす役割
全体計画とロードマップシステムごとの刷新順序・依存関係を可視化し、複数年の計画に束ねる
投資判断のガバナンス各刷新の効果・リスクを共通の物差しで評価し、経営の投資判断を支える
ベンダーマネジメントAI活用を掲げるベンダーの提案を、成果物と責任範囲で見極める
品質・移行リスク管理AI生成物のレビュー基準を定め、テストと移行の安全性を担保する
業務部門との調整「業務を製品・新基盤に合わせる」意思決定を業務側から引き出す

特に重要なのが、AIが生成した成果物の品質責任を誰が負うかを最初に決めておくことだ。AIが設計書やコードのたたき台を出しても、それが業務要件を満たしているかの最終判断は人が行う。「AIが作ったから」で品質を素通りさせると、レガシーの技術的負債を、より速いスピードで新環境に再生産することになる。PMOはこのレビュー・受け入れ基準の番人になる。

よくある失敗と回避策

  • AIツール導入を目的化する：「生成AIでモダナイズ」を先に決め、対象の棚卸しを飛ばす。→ まずEAで刷新の地図を描き、AIは各工程を速くする手段と位置づける
  • 現行仕様の写経で終わる：AIで現行を精緻に復元し、そのまま新環境に移す。→ To-Be（あるべき姿）を人が設計し、復元した現行仕様は「移行のための参照情報」と割り切る
  • 一括刷新に賭ける：止められない基幹を一気に置き換えようとして頓挫する。→ 段階移行（ストラングラーフィグ型）で、事業インパクトの高い領域から小さく切り出す
  • 推進体制を後回しにする：ツールと予算だけ決め、司令塔不在で走り出す。→ 着手前にPMOを立て、投資判断・ベンダー管理・品質基準の枠組みを用意する
  • AI成果物の品質を素通りさせる：生成物のレビュー基準がなく、負債を高速に再生産する。→ 受け入れ基準とレビュー体制を先に定義する

まとめ

AI駆動開発は、レガシーモダナイゼーションの「実装コスト」と「現行を理解するための情報コスト」を確かに下げた。これは、これまで費用対効果が合わずに塩漬けにしてきた領域を、刷新の射程に入れる好機である。

しかし、AIが自動化してくれないもの——何を刷新し何を残すかの判断（EA）、投資の優先順位づけ、複数年プログラムの推進とガバナンス（PMO）——こそが、刷新の成否を分ける本質は変わらない。ツールが速くなったいまだからこそ、走り出す前に「刷新の地図」を描き、推進の司令塔を据えることの価値が上がっている。

「どこから手をつけるべきか分からない」「AI活用ベンダーの提案を評価しきれない」といった段階でこそ、EAによる現行可視化とPMOによる推進設計が効く。自社のモダナイゼーションの進め方に迷いがあれば、お問い合わせやサービス紹介もあわせてご覧いただきたい。

FAQ

Q. AI駆動開発を使えば、レガシー刷新は本当に速く・安くなりますか。 A. 実装や現行解析の工数は圧縮できます。ただし速くなるのは「作る」工程であり、「何を刷新し何を残すか」「どの順で進めるか」という判断や、業務部門との調整・移行リスク管理は従来どおり時間と体制を要します。全体のリードタイムはこれらに左右されるため、「実装が速い＝プロジェクトが速い」とは限りません。

Q. まず何から始めるべきですか。 A. コーディングやツール選定より前に、現行システムの棚卸しと可視化から始めるのが定石です。事業への重要度と技術的な老朽度で各システムを評価し、刷新の優先順位をつけます。AIはこの可視化・解析を速める手段として使うのが効果的です。

Q. 全面再構築と部分的な刷新のどちらを選ぶべきですか。 A. システムごとに異なります。事業の中核で変化も大きい領域は再構築の価値が高く、独自性の低い領域はSaaS等への置換が合理的です。止められない基幹システムは、一括置換より段階移行が安全な場合が多くなります。全体を一つの手段で括らず、地図の上で使い分けることが重要です。

Q. AIが生成した設計書やコードの品質はどう担保しますか。 A. 受け入れ基準とレビュー体制を先に定義することが要です。AIの生成物はあくまでたたき台であり、業務要件を満たすかの最終判断は人が行います。この品質責任の所在を曖昧にすると、技術的負債を高速に再生産する結果になりかねません。PMOがレビュー基準の番人を担うのが有効です。

参考資料