「作った人がもう社内にいない」「仕様書はあるが5年前で止まっている」「触ると何が止まるか分からないので触れない」——レガシーシステムの刷新が動き出さない理由は、技術の新旧より先に、この分からなさにあります。結論から言うと、レガシーシステム刷新にAIエージェントを使う要点は、全体を一度に作り直すことではなく、既存システムの「解読」と、小さく切り出した範囲の「置き換え」にAIを充て、動くものを段階的に積み上げていくことです。
もうひとつの結論として、一括刷新は「業務を止めるリスク」と「要件定義が終わらないリスク」を同時に抱え込みます。だから現実的な選択肢は、新旧を並走させながら機能を少しずつ移す段階的なモダナイゼーションになります。この記事では、レガシー刷新の一般的な型（ストラングラーフィグ、API化による疎結合化）と、AIエージェントが実際に効く工程、そしてPoC止まりにせず進めるための体制を解説します。
レガシーシステム刷新（モダナイゼーション）とは？
レガシーシステム刷新とは、長年使われてきた既存システムを、いまの事業と技術に合う形へ作り替えていく取り組みの総称です。 「古いから新しくする」ではなく、変更に追随できる状態を取り戻すことが目的になります。
レガシーと呼ばれる状態は、たいてい次のどれかが重なっています。
- 仕様が人に残っていない：ドキュメントが更新されておらず、正解はコードと運用担当の記憶の中にしかない
- 変更が怖い：影響範囲が読めないため、小さな改修でも合意と検証のコストが跳ね上がる
- つながらない：外部サービスや新しいツールと連携する口（API）がなく、データが取り出せない
- 人がいない：使っている言語・基盤の担い手が減り、保守そのものが属人化している
AI活用の文脈でとくに効いてくるのが3つめです。AIエージェントに業務を任せるには、業務データを読める形で取り出せることが前提になります（この土台の考え方はAIネイティブのデータ基盤とはを参照）。レガシー刷新は、AI活用の前提条件になっていることが多い——ここが、いま刷新の優先度が上がっている理由です。
一括（ビッグバン）刷新はなぜ行き詰まる？
現行仕様が誰にも分からないまま「全部を作り直す」と決めると、要件定義が終わらなくなります。 刷新プロジェクトが止まる典型が、この入口の設計ミスです。
一括刷新には、次の3つの負担が同時にのしかかります。
| 抱え込むリスク | 何が起きるか |
|---|---|
| 業務停止リスク | 稼働中の基幹業務を一発で切り替えるため、失敗時の影響が大きく、切り戻しも重い |
| 要件定義の長期化 | 現行仕様が不明なまま全機能を定義し直すため、調査と合意だけで時間が溶ける |
| 効果が出るまでが遠い | 完成まで価値がゼロのまま。途中で予算・体制が変わると、成果物が残らない |
3つめは特に見落とされがちです。途中で止まったときに何も残らない進め方は、それ自体がリスクです。逆に言えば、途中で止まっても「移し終えた分」は残る作り方にできれば、意思決定はずっと楽になります。
「止めずに刷新する」にはどんな型がある？
答えは、新旧システムを並走させ、機能単位で少しずつ新しい側へ移していくことです。 これは新しい発想ではなく、ソフトウェア設計で広く知られた型があります。
止めずに刷新する5ステップ。1周を小さく回し、各周で「動くもの」と「読める仕様」を残していくのが要点。
ストラングラーフィグパターン
ストラングラーフィグパターンは、新旧システムを並走させながら機能を少しずつ新システムへ移し、最終的に旧システムを覆い尽くす移行の型です。 既存システムの前段に振り分けの層を置き、移し終えた機能への呼び出しだけを新しい側へ流します。
利点は、切り替え単位が小さいので後戻りできることです。1機能ずつ移すため、問題が起きても影響範囲が限定され、振り分けを戻せば原状復帰できます。一括切り替えの「一発勝負」とは、リスクの性質がまったく違います。
API化による疎結合化
API化は、内部でしか呼べなかった処理を、外から決まった形で呼べる口に変える作業です。 刷新の初手として効くのは、これが「取り出せない」問題を先に解くからです。
APIとして切り出せた機能は、新システムから呼ぶことも、AIエージェントのツールとして呼ばせることもできます（連携の型はAIエージェントの社内システム連携で詳しく解説しています）。刷新の完了を待たずにAI活用を始められるのは、この段階的な切り出しの副産物です。
AIエージェントはレガシー刷新のどこで効く？
AIエージェントがいちばん効くのは、コードを書く工程ではなく、コードを読む工程です。レガシー刷新の時間の多くは、実装ではなく「現行が何をしているかを突き止める」ことに費やされるためです。
AIコーディングエージェントを刷新に組み込むとき、現実的な使いどころは次のあたりになります。
| 工程 | AIに任せられること | 人が必ず担うこと |
|---|---|---|
| 解読・仕様復元 | コードから処理の流れ・呼び出し関係・分岐条件を整理し、読める形に起こす | 業務としての正しさの判断、例外運用の確認 |
| 移行設計 | 新旧の項目対応（マッピング）案の作成、影響範囲の洗い出し | 移す順番と範囲の決定、業務部門との合意 |
| テスト | 現行の振る舞いを確認するテスト観点・テストデータ案の列挙 | 合否基準の設定、本番相当データの扱いの判断 |
| ドキュメント | 移行手順書・運用手順書の下書き、変更点の要約 | 最終的な正の承認、引き継ぎ |
重要なのは、AIの出力はすべて「確からしい下書き」であって、正ではないという前提です。仕様書のないシステムでは、AIが出した仕様の誤りを指摘できる材料も社内に乏しくなります。だからこそ、AIの復元結果は現行システムの実際の振る舞いで突き合わせる（同じ入力で同じ結果になるか確かめる）手順を必ず挟みます。この検証の考え方はハルシネーション対策と同じ構図です。
逆に、AIに任せてはいけないのは「移す順番を決めること」です。どの機能から手を付けるかは、業務影響・繁忙期・決算期・関係部署の事情で決まります。ここは業務側と握る仕事であり、コードからは出てきません（この整理は業務棚卸しは必要かも参考になります）。
具体例：20年運用の受発注システムを止めずに刷新するなら
抽象的なので、架空の例で流れを追います（以下の数値はすべて説明用の仮の値で、実績ではありません）。
前提はこうします。20年運用の受発注システム。仕様書は5年前で更新停止、当時の開発者は在籍していない。日々の受注入力は止められない。 まず全体の作り直しは考えず、「取引先向けの注文明細PDFを出す機能」だけを最初の1機能に選びます。理由は、業務影響が読みやすく、入力と出力がはっきりしていて、正しさを現行と突き合わせやすいからです。
| 周回 | 対象 | AIの使いどころ | 止めないための工夫 |
|---|---|---|---|
| 1周目 | 注文明細PDF出力 | 該当処理の解読と、出力条件・例外分岐の一覧化 | 旧機能は残したまま、新旧の出力を同じ注文データで突き合わせる |
| 2周目 | 注文データの参照API | 項目定義の復元、新旧の項目マッピング案の作成 | 参照だけ先に開放し、更新系は旧システムのまま |
| 3周目 | 与信チェック | 分岐条件の洗い出しとテスト観点の列挙 | 一定金額以下から新側へ振り分け、超過分は旧側に残す |
たとえば計画を立てるとき、1機能あたり「解読2週間・試作2週間・本実装4週間」と仮に置くとします（これも説明用の仮の値です）。この置き方をすると、最初の1機能は約2か月で「動くもの」に到達し、そこで初めて見積の精度が上がります。一括刷新で全機能を先に定義しようとすると、この2か月では要件定義の入口までしか進みません。同じ2か月で「読める仕様」と「動くもの」が1機能ぶん残るか、資料だけが残るか——この差が、刷新が続くかどうかを分けます。
そして1周目でいちばん価値があるのは、実はPDF出力そのものではありません。1周回したことで、自社のコードに対してAIがどの程度使えるか、どこで人の確認が要るかが分かることです。2周目以降の見積は、この実測にもとづいて立てられます。
AIを使った刷新がPoC止まりにならないためには？
レガシー刷新は「大型プロジェクト化 → 要件定義倒れ」か「AIで解読してみた止まり」のどちらかに落ちやすいテーマです。どちらも、成果が業務に届く前に終わってしまう点で共通しています。
避け方は、進め方そのものを段階に区切ることです。弊社（株式会社 DeploAI）の FDE（Forward Deployed Engineer／フォワードデプロイドエンジニア）は、AI導入を①現状診断 ②AI研修 ③活用設計 ④試作 ⑤本実装 ⑥評価構築 ⑦定着支援 ⑧知識基盤 ⑨横断最適 ⑩内製化の10の工程で進めます。この区切り方は、止めずに刷新する進め方とそのまま噛み合います。
- ③活用設計：どの機能から移すか、AIをどの工程に充てるかを決める。ここで対象を絞るほど、後の周回が軽くなる
- ④試作：1機能ぶんを実際に動かし、AIの解読結果を現行の振る舞いと突き合わせる。見積の精度はここで上がる
- ⑤本実装：並走と切り替えを含めて業務に載せる。切り戻せる形で出す
- ⑧知識基盤：復元した仕様・移行手順・判断の理由を、次の周回とAIが読める形で残す
とくに⑧が刷新では効きます。レガシー化はドキュメントが人に残らなかった結果として起きるのだから、同じことを繰り返さない仕組みを刷新と同時に作る、という考え方です。FDE は「商談・顧客データ・資料・社内のやりとりまで、関わるすべてをAIが読める形式で一か所に集約する“組織の記憶レイヤー”」としての統合基盤づくりを核に置いています。刷新で復元した仕様も、次にAIが読む資産として置き場所を持てます。
プランは、エントリー（①〜③＝設計まで）、スタンダード（①〜⑥＝実装まで／推奨）、プロ（①〜⑩＝内製化まで）の3つで、上位は下位の工程をすべて含む積み上げ式です。契約後も①〜⑩から必要な工程だけを任意に積み増せます（実施済みの工程を再請求することはありません）。刷新のように「1周目の結果を見てから次を決めたい」テーマとは、この形が合います。各工程の成果物（テンプレート・基盤・ドキュメント）はすべて御社に残るため、途中で歩みを止めても、残ったものが次の周回の出発点になります。
内製化まで見据える場合の進み方はAI内製化の現実的なロードマップ、FDEという役割そのものの解説はFDE（Forward Deployed Engineer）とはをご覧ください。
まとめ
- レガシーシステム刷新の目的は「新しくすること」ではなく、変更に追随できる状態を取り戻すこと。AI活用の前提条件になっていることも多い
- 一括刷新は業務停止リスクと要件定義の長期化を同時に抱える。途中で止まると何も残らない進め方自体がリスク
- 止めずに進める型は、ストラングラーフィグパターン（新旧並走で機能を少しずつ移す）とAPI化による疎結合化
- AIエージェントがいちばん効くのは、コードを読んで仕様を復元する工程。ただし出力は下書きであり、現行の振る舞いとの突き合わせで検証する
- 移す順番を決めるのは人の仕事。小さく1周回して実測し、次の見積を立てるのが刷新を続けるコツ
- FDE の10工程のように段階を区切り、動くものと読める仕様を毎周残す進め方が、止めずに刷新するアプローチと噛み合う
レガシー刷新とAI活用をどこから始めるか迷っている方は、無料相談へどうぞ。進め方はサービス内容、工程の選び方は料金をご覧ください。関連記事：AIエージェントの社内システム連携／AI導入がPoC止まりになる理由／AIネイティブのデータ基盤とは／FDEとは。
