誰も触れない古いシステムが、事業の足かせになっている。仕様書は失われ、書いた人はもういない。作り直す予算も、止める勇気もない。多くの中小企業の基幹システムや社内ツールは、この「塩漬け」の状態で何年も放置されています。担当者が変わるたびに「触ると壊れるから触らない」が引き継がれ、改修見積もりは年単位・億単位になり、結局また見送る——その繰り返しです。
ところが、AIコーディングエージェントの実用化で、この前提が崩れ始めました。InfoQ のプレゼンテーション「Moving Mountains: Migrating Legacy Code in Weeks instead of Years」が示すのは、これまで数年がかりだった大規模移行を、AI支援で数週間〜数ヶ月に圧縮できるという実践報告です。ただし、これは「AIに丸投げすれば一瞬」という話ではありません。受託でレガシー移行を支える立場から言えば、速さの正体は「自動化できる作業」と「人が握る判断・品質担保」をきれいに分けたことにあります。本記事では、その「速いが事故らない」進め方を整理します。
なぜ、これまでレガシー移行はできなかったのか
塩漬けレガシーが動かせない理由は、技術的な難しさだけではありません。
- 仕様がコードの中にしかない。 ドキュメントは陳腐化し、唯一の真実は20年動き続けてきたコードそのもの。読み解くだけで数ヶ月かかる。
- 安全網（テスト）がない。 自動テストが存在しないため、一行変えただけで何が壊れるか分からない。だから誰も変えない。
- 影響範囲が見えない。 どの機能がどこから呼ばれているか、call graph を手で追うのが非現実的なほど絡み合っている。
- 一括書き直しの恐怖。 全部止めて作り直す「ビッグバン移行」はリスクが高すぎて、経営判断として通らない。
つまり、ボトルネックは「書く手」ではなく「読み解く時間」と「壊れない保証」でした。ここがAIで変わりつつあります。
AIで変わること、変わらないこと
AIコーディングエージェントが効くのは、これまで人手では現実的でなかった「規模の解析作業」です。逆に、変わらない——むしろ重要性が増す——のは品質を握る判断です。
| 工程 | これまで（人手） | AI支援で | 速さの源泉 |
|---|---|---|---|
| 仕様の棚卸し・解析 | 数週間〜数ヶ月 | 数時間〜数日 | コード読解・call graph 抽出を自動化 |
| テスト（安全網）生成 | 後回しになりがち | 自動生成の下書き | 入出力の網羅的キャプチャ |
| 新コードの実装 | 手書き | エージェントが下書き | パターン変換の量産 |
| 採否・移行判断 | 人 | 人（変わらない） | 自動化しない |
| 本番切り替えの責任 | 人 | 人（変わらない） | 自動化しない |
ある報告では、12年・約20万行の .NET Framework モノリスに対し、従来6〜8週間かかっていた手動解析を、エージェント実行6時間＋人によるレビュー4時間に短縮した、とされます（Augment Code）。重要なのは「人のレビュー4時間」が消えていない点です。速くなったのは解析であって、判断は人が握り続けています。「やると決めた移行」を、いつ・どこを・どう直すかの判断軸そのものは、AI時代のリファクタリング判断と技術的負債で整理した考え方と地続きです。
「速いが事故らない」進め方：4ステップ
ステップ1：棚卸しと影響範囲の可視化
まず動いているシステムの全体像をAI支援で可視化します。エントリポイント（画面・API・バッチ）を起点に call graph を辿り、「変更が集中する箇所」「他から大量に依存される箇所」「デッドコード」を洗い出す。ここで移行のスコープと順番を決めます。いきなり全部ではなく、「リスクが低く・効果が高い」スライスから着手します。
ステップ2：コードからの仕様抽出
失われた仕様を、AIにコードから逆抽出させます。ただし、抽出した仕様を「正」として鵜呑みにはしません。あくまで人がレビューするための叩き台です。バグも含めた「現状の挙動」を言語化させることがポイントで、ここで「正しい仕様」と「たまたま動いている挙動」を切り分けます。
ステップ3：テスト整備（最重要）
移行で唯一絶対に省けないのが、ここです。テストなき移行は、目隠しで爆弾処理をするのと同じです。レガシーには通常テストがないので、まず特性化テスト（Characterization Test / Golden Master）を当てます。これは「あるべき姿」ではなく「現状の挙動」をそのまま固定する手法で、Michael Feathers が広めました（Wikipedia: Characterization test）。多様な入力を流して現行の出力を「正解（Golden Master）」として保存し、移行後の新コードが同じ入力で同じ出力を返すかを照合します。
# 概念フロー：旧コードの挙動を「正解」として固定し、新コードと突き合わせる
# 1. レガシーに現実的な入力セットを流し、出力をGolden Masterとして保存
legacy-cli run --inputs ./samples/*.json --record ./golden/
# 2. AIエージェントに、旧コードの仕様抽出とテスト下書きを依頼
agent extract-spec ./legacy/billing/ --out ./spec/billing.md
agent gen-tests ./spec/billing.md --golden ./golden/ --out ./tests/
# 3. 同一入力を旧・新の両方に流し、出力を比較（parallel run）
diff-runner --old legacy-cli --new new-service \
--inputs ./samples/*.json --assert-equal
# 4. 広い入力で出力が一致したら、ルーティングを新コードへ切り替えこの「同じ入力を旧・新に流して出力を比較する（parallel run）」が、AI支援移行の安全弁です。テストの品質そのものを保証する考え方は、Mutation Testingで納品物のテスト品質を保証する受託やテスト自動化の導入支援で扱った通りです。安全網が「あるか」だけでなく「効くか」まで詰めます。
ステップ4：段階移行（Strangler Fig）
整備したテストを盾に、システムを少しずつ置き換えます。一括で作り直す「ビッグバン」ではなく、Martin Fowler が提唱したストラングラーフィグ・パターンを使います（Thoughtworks）。旧システムの前にファサード（プロキシ）を置き、移行が済んだ機能から順にリクエストを新コードへ振り向ける。旧システムは常に動いたまま、新しいコードが「絞め殺すように」覆っていきます。これにより、いつでも切り戻せて、本番を止めずに、機能単位で着実に刷新できます。
受託でこれを支える体制
弊社がこの種の案件を受ける際は、「AIが書いた量」ではなく「壊さず引き渡せた範囲」を成果物の単位にしています。illustrative な例として、ある製造業の受発注システム（伏字、稼働15年・主要言語のサポート切れ間近）では、まず2週間で棚卸しと特性化テストの土台を作り、リスクの低い帳票出力機能から段階移行を開始しました。最初の数週間は「移行スピード」よりも「いつ切り戻せるか」の設計に時間を割きます。ここを固めるほど、後半の移行が速く・安全になるためです。
体制は、AIエージェントを動かすエンジニア、出力をレビューしテストの妥当性を判断するシニア、業務仕様を顧客と詰めるPMの三層で組みます。AIは「手」を大量に提供しますが、「これで本当に同じ挙動か」「この仕様は意図か事故か」を判断するのは人です。AIを使った開発ワークフローそのものの組み方はClaude Code を使った開発ワークフローでも触れています。
向き不向き
AI支援の高速移行は万能ではありません。向き不向きを正直に整理します。
| 向いている | 向いていない／慎重に |
|---|---|
| 仕様の大半がコードに閉じている | 規制・認証で挙動の証明が厳格に要る領域 |
| 入出力が観測・再現しやすい | 外部副作用が多く再現困難な処理 |
| 段階移行できるモジュール境界がある | 密結合で切り出し単位が作れない |
| 「現状の挙動」を保ったまま移したい | 仕様自体を抜本的に作り変えたい |
「動きを変えずに基盤だけ新しくしたい」案件は最も相性が良く、逆に「ついでに仕様も全面刷新」を混ぜると、テストの基準（Golden Master）が揺らいで一気に難しくなります。刷新と機能追加は工程を分けるのが鉄則です。なお、移行を機に「使い勝手」も見直したい場合は、別工程としてレガシーシステムのUX改善と組み合わせます。
価格の考え方
レガシー移行は規模もリスクも案件ごとに大きく違うため、一律見積もりはしません。「まず小さく確かめる」入口を用意しています。
| プラン | 内容 | 目安 |
|---|---|---|
| アセスメント | 棚卸し・影響範囲可視化・移行計画・初期テスト土台 | 数週間／定額 |
| 段階移行（スプリント型） | モジュール単位で「テスト整備→移行→切替」を反復 | 月額（並走チーム） |
| 完全移行・伴走 | 全面刷新の設計・実行・運用引き渡しまで | 個別見積もり |
最初からフル移行を契約するのではなく、アセスメントで「どこから・どう・どのくらいで」を見える化してから判断いただくのが、最も事故が少ない進め方です。
落とし穴：ここで事故る
最後に、AI支援移行で最も多い失敗を挙げます。
- 丸投げ幻想。 「エージェントに食わせれば移行が終わる」と考えると、必ず破綻します。AIの出力は「下書き」であり、レビューと判断を省いた瞬間、見えないバグを本番に運びます。
- テストなき移行。 安全網を作らずに新コードへ切り替えると、何が壊れたかすら分からない。速さを取ってテストを飛ばすのは、最も高くつく近道です。
- ビッグバン誘惑。 「どうせ作り直すなら全部一気に」は、リスクが指数関数的に膨らみます。段階移行と切り戻し設計を捨ててはいけません。
- 仕様とバグの混同。 「現状の挙動」をそのまま固定すると、バグまで移植します。Golden Master を作る段階で、人が「これは意図か事故か」を仕分ける工程が要ります。
速さは、自動化できる作業を自動化した結果として後からついてくるものです。最初に削ってよいのは手作業であって、判断とテストではありません。
塩漬けのシステムは、放置するほど移行コストも事業リスクも静かに増えていきます。一方で、いきなり全面刷新に踏み切る必要もありません。まずは「いまのシステムが何をしているのか」を可視化し、リスクの低いところから安全に動かし始める——その第一歩から始めるのが現実的です。
レガシー移行に踏み出せずにいる、あるいは見積もりが大きすぎて止まっている方は、まず小さなアセスメントからご相談ください。お問い合わせはこちらから、対象システムの状況をお聞かせいただければ、移行の進め方と入口の規模感をご提案します。
Sources
- InfoQ: Moving Mountains: Migrating Legacy Code in Weeks instead of Years
- Augment Code: 15 AI-Driven Tactics to Speed Monolith-to-Microservices Migration
- Wikipedia: Characterization test（Golden Master）
- Thoughtworks: Embracing the Strangler Fig pattern for legacy modernization
- Microsoft Learn: Strangler Fig pattern
- 関連記事: AI時代のリファクタリング判断と技術的負債
- 関連記事: Mutation Testingで納品物のテスト品質を保証する受託
- 関連記事: テスト自動化の導入支援
- 関連記事: レガシーシステムのUX改善
- 関連記事: Claude Code を使った開発ワークフロー
