プロジェクト概要
10 年運用してきた Rails 5 + jQuery 製の業務システムを、フロントエンド (Next.js App Router) とドメイン API (Hono + Cloudflare Workers) に分割してリプレイスしました。通常見積もりでは 8 ヶ月相当の規模を、AI 駆動開発 で約 4 ヶ月に圧縮しています。
クライアントは年商 100 億規模の卸売・流通業者で、業務システムは社内 80 名のオペレーションを支える基幹システムでした。受注・在庫・出荷・請求の 4 ドメインが密結合になっており、機能追加 1 つに 2 週間以上かかるのが慢性化していました。
クライアントの課題
- 機能追加のたびにテストが書ききれず、本番反映に 2 週間 かかる
- フロントエンド技術が古く、エンジニア採用が困難
- 棚卸し済みのドキュメントが存在せず、業務ルールが属人化
- ハードウェア寿命の問題で、向こう 1 年でインフラ刷新が不可避
- 業務停止できる時間が 1 回あたり最大 4 時間に限定される (24 時間運用のため)
「リプレイスしたいが、止められないし、設計を知っている人もいない」という典型的なレガシー刷新ジレンマです。
アプローチ
1. レガシー資産の「読み解き」を AI に任せる
Claude Code に Rails のリポジトリと既存テストを読み込ませ、
- 各 Controller / Model のドメイン責務マップ
- 「触ると怖いコード」のホットスポット一覧
- 暗黙の業務ルール (バリデーション・例外条件)
- 過去 3 年の障害履歴と対象 PR の対応関係
を週次でドキュメント化。最初の 2 週間でドキュメントが 100 ページ近く揃いました。「レガシー資産は読み解く対象であって、書き直す対象ではない」 という Stage の切り分けが、AI 駆動リファクタリングの初手として重要です。
2. 段階移行のロードマップ作成
機能を 14 のドメインに切り、依存関係から「移行順序」を Claude Code に提案させ、人間が業務優先度で再ソート。これにより並列で動かせる作業が可視化されました。
flowchart LR
A[商品マスタ] --> B[在庫管理]
A --> C[受注処理]
B --> D[出荷管理]
C --> D
D --> E[請求]このフローを見ながら、「商品マスタ」と「在庫管理」を最初に刷新 → 受注処理は 2 ヶ月後 → 出荷・請求は最後 という順序にロジックを通しました。並列着手できるドメイン数を AI に提案させると、人間だけで計画を立てるより 1.5〜2 倍の並列度を引き出せます。
3. テスト先行で AI 実装
新フロント / 新 API の実装は、すべて Playwright と Vitest のテストを先に書いて、Claude Code に実装を生成させるスタイル。OpenAPI Generator で型を両端共有することで、AI が型情報を頼りに堅実なコードを書ける環境を整備しました。
このパターンは別記事 AI 駆動 TDD で深掘りしていますが、リプレイス案件では特に効果が大きい運用です。なぜなら 既存システムの仕様 = テスト という対応関係が直感的で、AI に対する指示も「既存挙動を保ったままモダンスタックに書き直して」と明確に出せるからです。
4. データ移行のスクリプトも AI で
旧 DB → 新 DB の ETL は、業務ルールを文章で渡すと SQL + TypeScript の移行スクリプトが生成され、結果差分を自動テストで検証する流れに。エッジケース (NULL 許容のカラム、半角全角の混在、SJIS 由来の文字化け) もテストで担保しました。
ETL のリハーサルは合計 23 回 実施。本番カットオーバー時には、4 時間の業務停止枠内で完全移行が完了しています。
5. 段階リリースで業務影響を最小化
14 ドメインを 5 ウェーブに分け、ウェーブごとに 2〜3 ドメインを段階リリース。Feature Flag で旧画面 / 新画面を業務ユーザーが切り替えられる状態にし、
- 1 週間: ベータユーザー 5 名で並行運用
- 2 週間: チーム全体に開放、旧画面も並行で稼働
- 3 週間目以降: 旧画面を削除
の流れで、一気停止カットオーバーを最小化しました。
工数・品質の実数値
| 指標 | 通常見積もり | 実績 | 差分 |
|---|---|---|---|
| 期間 | 8 ヶ月 | 4 ヶ月 | -50% |
| 工数 (人月) | 9 | 4.5 | -50% |
| カットオーバー後の P1 障害 | 想定 3〜5 | 1 | -75% |
| 機能リリース所要日数 (中央値) | 14 日 | 2 日 | -86% |
| 開発者満足度 (10 段階) | — | 8.7 | — |
| エンジニア採用応募数 (3 ヶ月) | 月 2 件 | 月 9 件 | +350% |
機能追加リードタイムが 14 日 → 2 日に短縮。社内では「数年前から続いた機能凍結期間」が事実上終わったと評価されています。さらに、Next.js + TypeScript のモダンスタックに刷新したことで、エンジニア採用の応募数が 4.5 倍に伸びました。
学びと再利用可能なナレッジ
1. レガシー刷新の最大の価値は「読み解き」を AI に任せること
ドキュメント化されていない既存システムも、AI が読み解き、人間が判断する協業が機能します。人間が「Spec を全部把握してから書き直す」モデルは、AI 駆動 リファクタリングでは捨てるべき です。AI に読み解かせ、業務担当者と FIXIT エンジニアが質問する形に切り替えると、棚卸しの所要工数が 1/3〜1/4 になります。
2. 完全リライトより疎結合な段階移行
リプレイスは完全リライトより 疎結合な段階移行 のほうが事故が少ないです。「全部書き直してから一気に切り替え」モデルは、業務影響と心理的負担が大きすぎます。今回のように 5 ウェーブに分けて段階リリースする戦術は、AI 駆動かどうかに関わらず推奨できます。
3. Feature Flag は業務ユーザーが操作する UI に組み込む
開発者向けの Feature Flag はよくありますが、業務ユーザー自身が UI から切り替えられる Flag にしておくと、現場主導で旧 / 新を切り替えてもらえます。これによりリリース後の混乱が目に見えて減りました。
ありがちな落とし穴
落とし穴 1. AI に Rails の挙動を「自然言語」で要約させて鵜呑みにする
Claude Code はコードを読み解く能力が高いですが、暗黙の業務ルールを 要約 しすぎると、エッジケースが落ちます。「コードと PR の両方を読ませて、要約 + 引用元の行番号を出させる」運用に切り替えると、要約の精度が劇的に上がります。
落とし穴 2. 14 ドメイン全部を一気に並列着手
並列度の最大化を狙うあまり、14 ドメインを 14 名で並列着手させると、レビュー待ちで進捗が止まります。ウェーブごとに 2〜3 ドメインに絞り、レビュアーを循環させる運用が安定します。
落とし穴 3. ETL リハーサル不足での本番事故
業務停止枠が 4 時間しかない案件で、ETL のリハーサルを 5 回程度で済ませようとすると、ほぼ確実に本番事故が起きます。今回のように 20 回以上のリハーサルが、4 時間カットオーバーの保険になります。
よくある質問
Q. レガシーシステム リプレイス案件、いくらかかりますか？
A. 規模感によりますが、本案件相当 (14 ドメイン、4.5 人月) で 1,800〜2,400 万円が目安です。コードベース行数、ドメイン数、データ移行の難易度で大きく変動します。お見積もりは お問い合わせ から要件メモを共有ください。
Q. なぜ Rails や Spring Boot のままモダン化しないんですか？
A. 「同じ言語の中で版上げ」をするケースもあります。ただし、Rails 5 → Rails 7 / Spring Boot 2 → 3 は、エコシステム互換性の問題で結局書き直し相当になるケースが多いため、フロントエンドだけでも Next.js + TypeScript に切り出すことで、採用とパフォーマンスの両方を一気に改善できます。
Q. AI が書いたコードでエンタープライズ品質を担保できますか？
A. 担保できます。ただし「テスト先行」「人間レビュー」「ドメインエキスパートの巻き込み」の 3 つを必ず併用します。今回も 80 名規模の業務システムが、カットオーバー後 P1 障害 1 件で運用に乗りました。
関連リソース
- ほかの実績は 実績・事例 を参照してください
- AI 駆動の TDD 手順は AI 駆動 TDD の記事 で詳しく扱っています
- Claude Code の組織導入は Claude Code 導入完全ガイド を併読ください
- お問い合わせは こちらの問い合わせフォーム からどうぞ