AI で 1 万行のレガシーコードをリファクタリング：1 ヶ月分の仕事を 2 週間で終えた実録

10 月初旬、緊急プロジェクトが舞い込んできました。約 1 万行のコア業務ロジックを抱える Vue 2.x の注文管理システムです。テストカバレッジは 10% 未満、状態管理が乱れてデータの流れが追えず、3 年間誰も手を出せなかった——そんな状態でした。リーダーからの期限は「2 週間でリファクタリングを終えて本番投入」。

正直、無理な話だと思いました。従来どおり手作業で進めれば、業務ロジックの把握だけで 1 週間はかかります。そこから慎重にコードを直し、テストを書き、検証するとなると 30〜40 日は見込みです。でも現場は待てません。システムが遅くなり、ユーザーからのクレームが続いていたからです。

そこで思い出したのが、知人から勧められていた Claude Code です。大規模リファクタリングを任せられると聞いていました。とはいえ、AI にコードを任せて大丈夫なのか、壊したらどうするのか——当時は不安でいっぱいでした。

選択肢はほとんどありません。試すことにしました。

2 週間後、デプロイボタンを押し、監視画面の指標がすべて正常の緑に染まったとき、胸が高鳴りました。リファクタリングは 14 日で完了。本番事故はゼロ。API の応答時間は 20% 改善し、バグ率は 40% 低下しました。

この記事では、14 日間の進め方、踏んだ落とし穴、すぐ使える知見をまとめます。技術的負債に直面している方や、AI 補助リファクタリングに興味がある方の参考になれば幸いです。

プロジェクト背景：どれほど酷い状態だったか

まずは惨状から。

会社のコア注文管理システムで、1 日平均 5,000 件の注文を処理します。注文作成、決済、物流追跡、アフターサポートなど、十数の業務フローが絡み合っています。2022 年初頭に Vue 2.x で書かれ、当時の担当者は完成後すぐ退職。以降 4 人がメンテナンスを引き継ぎましたが、全員がつぎはぎ修正を重ね、スタイルはバラバラです。

どれほど酷いか？ 2 日間かけて診断した結果、衝撃的な問題が並びました：

1. 1 万行のコアビジネスコード——1 ファイル最大 1,800 行、最も肥大化した OrderService.js には 47 個のメソッド
2. テストカバレッジ 10% 未満——簡単な単体テストが数本あるだけで、重要な業務ロジックは未カバー
3. 状態管理の混乱——Vuex、LocalStorage、SessionStorage、グローバルイベントバスが混在し、データの流れが追えない
4. 重複コードの氾濫——同じ注文ステータス判定ロジックが 23 箇所でコピペされていた
5. パフォーマンス問題——注文一覧の読み込みに 3〜4 秒かかり、ユーザーからの苦情が絶えない

いちばん頭が痛いのは、ボロボロながら本番稼働中で、毎日数千ユーザーに使われていることです。大胆に手を入れて障害が出れば、業務が止まります。

従来のリファクタリングならどれくらいかかる？

ホワイトボードに手順を書き出しました：

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

1. 業務ロジックの理解（5〜7 日）
2. テストケースの補充（7〜10 日）
3. リファクタリング対象の分解（10〜15 日）
4. モジュールごとのリファクタリングと検証（8〜12 日）
5. 統合テスト + カナリアリリース（5 日）

最短でも 35 日。手戻りは含みません。

私には 14 日しかありませんでした。

なぜ Claude Code を選んだのか

AI を使う前、正直なところ確信はありませんでした。

市場には AI プログラミングツールがたくさんあります。GitHub Copilot は日常的に使っていましたし、Cursor の評判も聞いています。Claude Code は比較的新しい顔です。なぜ Claude Code にしたのか？

小さな実験をしました

半日かけて、プロジェクト内でいちばん複雑な関数——注文ステータス更新ロジック（200 行超、境界判定・非同期呼び出し・エラー処理を含む）——を 3 つのツールにそれぞれリファクタリングさせました。

結果はこうでした：

• GitHub Copilot：提案が断片的で、コード補完ツールの延長。一行ずつ誘導が必要で、大規模リファクタリングには向きませんでした。
• Cursor：意図は理解でき、提案も妥当。ただ複雑な業務ロジックではたまに文脈を取り違え、何度も説明し直す必要がありました。
• Claude Code：ここが印象的でした。リファクタリングだけでなく、潜在的なバグを 3 件指摘し、テストを先に書くよう提案。詳細な手順まで示してくれました。

決め手は コンテキスト理解力 です。Claude Code は 200K トークンのコンテキストウィンドウをサポートします。プロジェクトのコアコードをまとめて渡せば、単一ファイルではなくモジュール間の関連まで把握できます。

"Claude Code の 200K トークンコンテキストウィンドウは約 15 万文字のコードを収容でき、中規模プロジェクトのコア業務ロジックとモジュール間の関連を理解するのに十分です。"

リファクタリング実戦：14 日間の道のり

ここからが本題です。14 日間の具体的な手順と、踏んだ落とし穴を書きます。

準備期間：安全網を張る（Day 1-2）

リファクタリングでいちばん怖いのは、壊してしまうこと。だから最初にやるのはコードを触ることではなく、安全網を張ることです。

タスク 1：テストケースの補充

Claude Code への最初の依頼は、テストケースの生成でした。

私：これは注文モジュールのコアコードです（3000 行を貼り付け）。
主要な業務フローを分析し、完全なテストケースを生成してください。
注文作成、決済、返金、ステータス遷移などのシナリオを重点的にカバーしてください。

Claude の出来は期待以上でした。単体テストを生成するだけでなく、業務シナリオごとに分類し、各テストに目的がわかるコメントを付けてくれました。境界条件を少し直しただけで、2 日でカバレッジは 10% から 45% に上がりました。

従来のやり方なら、これだけで 1 週間はかかる作業です。

タスク 2：コード診断

テストという保険ができたら、コード全体の診断です。Claude Code に「健康診断」を依頼しました：

私：このプロジェクトのコード品質を分析してください。
重点項目：コードスメル、重複ロジック、パフォーマンスのボトルネック、潜在的なバグ。
詳細な診断レポートをください。

スキャン結果は 20 ページのレポート（印刷すると本当に 20 ページ）でした：

• 87 件のコードスメル（関数が長すぎる、ネストが深い、命名が不統一など）
• 23 箇所の重複ロジック
• 14 件の潜在的なパフォーマンス問題
• 5 件のバグの可能性（うち 2 件は後に実バグと確認）

このレポートが、そのままリファクタリングのロードマップになりました。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

リファクタリング実行：人と AI の協調（Day 3-10）

本格的に進めるうちに、Claude Code との協業リズムが見えてきました。

リズム 1：いちばん痛いところから着手

最初に手を入れたのは 800 行の processOrder 関数です。注文作成の全ロジック——パラメータ検証、在庫チェック、割引計算、決済呼び出し、通知送信——が全部詰まっており、メンテナンスは悪夢でした。

Claude への依頼はこうでした：

私：この processOrder 関数が肥大化しています。リファクタリングしてください。要件：
1. 単一責任の小さな関数に分割する
2. 各関数は 50 行以内
3. 共通ロジックをユーティリティクラスに抽出する
4. 既存機能との 100% 互換性を維持する
5. 新しい各関数に対応するテストケースを生成する

Claude は詳細なリファクタリング案を出し、800 行を 6 つの関数に分割しました：

• validateOrderParams() — パラメータ検証
• checkInventory() — 在庫チェック
• calculateDiscount() — 割引計算
• processPayment() — 決済処理
• sendNotifications() — 通知送信
• createOrder() — メインフローの制御

責務が明確になり、テストもしやすくなりました。この 1 関数だけ、従来なら 3 日かかるところを Claude Code で半日で終えました。

品質保証：省略できない検証（Day 11-13）

コードを直したら終わりではありません。検証が本番です。この 3 日間はテストに集中しました。

第 1 層：自動テスト

まずテストスイート全体を実行：

• 単体テスト：187 ケース、すべてパス
• 統合テスト：34 シナリオ、パス率 100%
• E2E テスト：コア業務フローを一通り確認

以前 Claude Code に生成させたテストが、ここで効きました。

第 2 層：コードレビュー

Claude に自動レビューを依頼。変数命名の不統一と、非同期呼び出しの例外処理漏れ——2 件を実際に指摘してくれました。

リリースと監視：いちばん緊張する瞬間（Day 14）

10 月 25 日、金曜日、午後 3 時。業務のオフピーク時間帯です。

カナリアリリース戦略を取りました：

• 3:00 — 5% のトラフィックで公開、30 分間監視
• 3:30 — 問題なし、10% に拡大
• 4:00 — 30% に拡大
• 5:00 — 全量リリース

ずっと監視ダッシュボードを見つめ、手のひらは汗ばんでいました。チーム全員がオンラインで待機し、いつでもロールバックできる状態でした。

すべての指標が緑のまま、API 応答時間が平均 450ms から 360ms に下がったのを見て、ようやく息をつけました。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

最終結果：

• 本番事故ゼロ
• API 応答時間 20% 改善
• バグ率 40% 低下
• SonarQube のコード品質スコアが C から A に
• テストカバレッジが 10% から 75% に

高効率プロンプトテンプレート集

実戦でまとめた 4 種類のテンプレートです。コピーしてプロジェクト情報を差し替えれば使えます。

テンプレート 1：コード診断

[プロジェクトタイプ] プロジェクトを持っています。技術スタックは [技術スタック] です。
以下がコアビジネスコードです：[コードを貼り付け]

全面的な診断をお願いします。重点項目：
1. コードスメル（関数が長い、ネストが深い、命名が不統一など）
2. 重複ロジックと抽出可能な共通コード
3. 潜在的なパフォーマンスのボトルネック
4. 想定されるバグとセキュリティリスク

詳細レポートを優先度順に提出してください。

テンプレート 2：リファクタリング実行

以下のコードをリファクタリングしてください：[コードを貼り付け]

要件：
1. 単一責任の小さな関数に分割し、各関数は [50] 行以内
2. 重複ロジックをユーティリティクラスに抽出
3. 命名を改善し、[チーム規約] に従う
4. 既存機能との 100% 互換性を維持
5. 新しい各関数に対応するテストケースを生成

重要な制約：
- ビジネスロジックは変えず、コード構造のみ変更
- 新しい依存パッケージは追加しない（明示的な指示がない限り）
- 用途が不明なコードは削除せず、確認用にマークする
- 既存のコードスタイルに従う：[スタイルの説明]

関連コンテキスト：
[呼び出し元コード、データ構造定義などを貼り付け]

テンプレート 3：テスト生成

[モジュール名] のコアコードです：[コードを貼り付け]

完全なテストケースを生成してください。要件：
1. [テストフレームワーク名、例：Jest/Vitest] を使用
2. 主要な業務シナリオをカバー：[重要シナリオを列挙]
3. 境界条件（空値、異常入力、極端な値など）を含める
4. 異常シナリオ（ネットワークタイムアウト、API エラーなど）を含める
5. 各テストケースに目的を説明するコメントを付ける

テストカバレッジ目標：70% 以上

テンプレート 4：コードレビュー

リファクタリングが完了しました。レビューをお願いします：

元コード：[貼り付け]
リファクタリング後：[貼り付け]

重点チェック：
1. 新たなバグやロジックエラーがないか
2. パフォーマンス問題（不要なループ、無駄な計算など）がないか
3. [チーム規約] に準拠しているか
4. セキュリティリスク（SQL インジェクション、XSS など）がないか
5. 命名とコメントが明確か
6. テストカバレッジが十分か

詳細なレビュー意見と改善提案をください。

最後に

10 月初旬にこのタスクを受けたときの不安を思い出すと、今のコードを見て肩の荷が下りた気分です。

14 日間、1 万行、スパゲッティコードの引き継ぎから無事故リリースまで——AI 補助開発への見方が大きく変わりました。

AI は万能薬ではありません。意思決定、業務理解、リスクの引き受けは人間の仕事です。ただ、経験豊富なシニアエンジニアが隣にいるような、強力なアシスタントにはなります。コードレビュー、テスト生成、問題の指摘——いつでも頼れます。

本当の効率化は、人と AI の協調から生まれます。あなたが業務理解と判断を担い、AI が実行速度とベストプラクティスを担う。この組み合わせで、1 人が 3 人分の仕事を、しかも高品質にこなせます。

同じような課題に直面しているなら、次の 4 点を意識してください：

1. 試してみる——AI ツールは十分に実用段階にあります
2. 小さく速く——小さなモジュールから始め、AI の働き方に慣れる
3. 油断しない——AI は強力ですが完璧ではありません。人による確認は必須
4. 準備を整える——テスト、監視、ロールバックの仕組みはすべて必要

技術的負債は先延ばしにしても消えません。早く返せば早く楽になります。Claude Code のようなツールがあれば、返済もそれほどつらくなく、むしろ達成感すら得られるかもしれません。