Claude Code でレガシー改修を 5 倍速にする 4 ステップ手順

結論 — Claude Code でレガシー改修は 5 倍速になる(4 ステップ別工数比較表)

レガシー改修は「読む量に対して書く量が少ない」作業の塊で、構造把握とテスト整備のフェーズが工数の過半を占めます。Claude Code はリポジトリ全体を読ませて構造マップを出力させる作業、現行挙動を凍結するキャラクタリゼーションテストを生成する作業、機械的な置換に近い段階リファクタの作業のいずれでも、人間 1 人がゼロから書くより圧倒的に短時間で叩き台を出します(Claude Code 概要 — 公式ドキュメント)。読解と機械的書き換えの比重が高いレガシー改修ほど、新規開発以上に時短倍率が伸びます。

具体的な工数感を、フリーランス実装者と受託会社中堅実装者へのヒアリング想定値で比較します。20 ページ規模の業務システム保守で従来 80 時間かかっていた案件は、構造把握 20 時間 → 3 時間、テスト先行 25 時間 → 5 時間、段階リファクタ 25 時間 → 6 時間、退行検証 10 時間 → 2 時間で、合計 16 時間まで圧縮できます。比率にして 80% の工数削減、約 5 倍速 という計算です。

倍率は実装者ヒアリング想定値で、案件の難易度・既存テストの有無・ドキュメントの整備度で大きくぶれます。重要なのは 構造把握と退行検証で時短倍率が最大化する という偏りを最初に頭に入れ、見積もり時のフェーズ配分に反映することです。次節で「そもそもなぜレガシー改修で詰まるのか」の 4 パターンを整理してから、各ステップを掘り下げます。

レガシーコード改修で詰まる 4 つの典型パターン

レガシー改修で手が止まる詰まり方は、現場をヒアリングするとほぼ 4 つに集約されます。読者が自分の案件のどの詰まり方に該当するかを最初に特定すると、後段の 4 ステップ手順のどこを重点化すべきかが見えてきます。Claude Code の介入ポイントは詰まり方ごとに違うので、ここで切り分けを済ませておきます。

1. 構造把握不足:ディレクトリ構成・依存関係・実行経路がコードからしか読み取れず、最初の 1 ファイルを開くまでに数時間消える状態。納品から数年経った PHP / Java / VB / 古い JS の現場で多発し、コードジャンプを 100 回繰り返してようやく全体像が掴めるパターン。Claude Code の最大の介入余地はここで、ステップ 1 の構造把握プロンプトで一気に時短できます。
2. 退行恐怖:既存挙動を壊す不安で改修着手そのものが遅れる状態。本番運用中の決済処理・在庫処理・帳票出力などで「触ったら何が壊れるか分からない」と感じた瞬間に手が止まり、見積もりだけで数日経過することがあります。ステップ 2 のキャラクタリゼーションテストで現行挙動を凍結すると、この恐怖は構造的に解消できます。
3. テスト未整備:退行を検出する仕組みがそもそも存在しないか、ユニットテストだけあって結合・E2E が皆無の状態。テストがない以上「動いていることの確認」はクライアントへの目視デモに依存し、改修サイクルが遅くなります。ステップ 2 で最低限のキャラクタリゼーションテストを先に書くと、以降のサイクルが回ります。
4. 仕様逆引き不能:ドキュメントが古いか存在せず、コードからしか仕様が読み取れない状態。「この計算式の根拠は何ですか」とクライアントに聞いても「当時の担当者がもう退職していて分からない」と返ってきます。Claude Code にコードを読ませて「想定される業務要件」を逆生成させる使い方が、ステップ 1 と組み合わせて効きます。

4 パターンのうち複数が同時に発生している案件が大半で、特に「構造把握不足 + 退行恐怖 + テスト未整備」の三重苦は受託会社の保守運用案件で頻出します。この三重苦をワンパスで解消できるのが Claude Code の最大の価値で、新規開発の生産性向上以上に経済効果が大きい領域です。次節で 4 ステップの実装手順を順に見ていきます。

4 ステップ実装手順 — 構造把握から退行検証まで

ここから具体的なプロンプトとコマンドの並びを示します。Claude Code は標準でリポジトリ全体を読み込んでくれる前提で、手元のターミナルから claude コマンドを起動し、対話形式で指示を出す流れを想定します(Claude Code 入門 — 公式ドキュメント)。各ステップで実プロンプト例を 1〜2 本提示しますが、対象コードベースの言語・規模に応じて調整してください。

Step 1: 構造把握 — リポジトリ全体を読ませて 3 種の図を出力させる

リポジトリのルートで claude を起動し、最初に投げるのは「現行アーキテクチャ図」「主要モジュール責務一覧」「依存グラフ」の 3 種同時生成プロンプトです。たとえば「このリポジトリ全体を読み、docs/legacy-analysis/ に architecture.md(主要コンポーネント図 + 役割)、modules.md(主要モジュール責務とエントリポイント)、dependencies.md(モジュール間依存と外部 SDK)の 3 ファイルを Mermaid 図付きで出力してください」と指示すると、20 ページ規模のシステムなら 10〜15 分で叩き台が揃います。コードジャンプ 100 回が 1 プロンプトで済むのがこのステップの本質で、ステップ 2 以降の土台になります。

Step 2: テスト先行 — キャラクタリゼーションテストで現行挙動を凍結

構造把握が済んだ次のステップは、現行挙動を「正解」として固定するキャラクタリゼーションテストの整備です。Claude Code に「src/domain/billing/ 配下の主要関数に対し、現行挙動を入力 → 出力で記録するキャラクタリゼーションテストを tests/characterization/ に生成してください。境界値・null 入力・空配列・極端な数値を網羅し、現在の戻り値をそのままアサートしてください」と指示すると、テストファイルが一気に揃います。この時点で「現在の挙動 = テストの期待値」となるので、以降のリファクタで挙動が変わると即座に失敗する安全網ができます(Claude Code ベストプラクティス — 公式ドキュメント)。

Step 3: 段階リファクタ — 1 コミット 1 改善で claude-code-subagent を回す

テストが揃ったら、ようやくリファクタに着手します。原則は 1 コミット 1 改善。「変数名の改善のみ」「関数の長さ短縮のみ」「依存注入化のみ」のように 1 コミットで 1 種類だけ変更し、ステップ 2 で書いたテストが全件通ることをコミットごとに確認します。Claude Code は同時に複数種類の変更を提案しがちなので、サブエージェントを使ってタスク分割するパターンが有効です(詳細はClaude Code サブエージェント活用記事)。1 コミット 1 改善を守ると、退行が発生してもどのコミットが原因か即座に二分探索でき、ロールバックが高速化します。

Step 4: 退行検証 — スナップショット + diff レビューで二重検証

リファクタが一通り済んだら、改修前と改修後で挙動差分が生まれていないかをスナップショットテストと diff レビューの 2 系統で検証します。スナップショットテストは入出力のペアを大量に保存しておき、改修後にバイト一致を確認する手法で、Claude Code に「tests/snapshot/ 配下に 50 件分の入力サンプルを生成し、改修前 main ブランチで実行した出力を expected/ に保存してください」と指示すると整備できます。並行して claude-ralph-loop パターン(詳細はClaude Ralph Loop 解説記事)でリファクタ前後の git diff を Claude Code にレビューさせ、想定外の挙動変更がないか二重確認すると、退行リスクを限りなく 0 に近づけられます。

改修対象別の活用パターン早見表

レガシー改修案件は対象システムの種類で「効くフェーズ」「効かないフェーズ」が大きく変わります。見積もり時に時間配分を間違えないよう、4 タイプの早見表を先に置いて、次に各タイプの注意点を補足します。読者は自分の案件タイプの行に飛んで、フェーズ配分を読み替えてください。

Web 制作旧 LP のケースでは、構造把握フェーズで現行 HTML / CSS / jQuery の依存関係を Claude Code に読ませ、現代的な React / Vue / Astro 構成への移行マッピングを出力させると、移行プランの叩き台が即日揃います。デザイン再構築とブラウザ実機検証は人手必須で、ここで手抜きすると iOS Safari や旧 Edge での表示崩れに後から苦しみます。業務システム言語変更では仕様逆引きが最大の論点で、Claude Code に旧コードを読ませて「想定される業務要件 + 計算ロジックの説明」を逆生成させ、クライアントヒアリングの叩き台にする使い方が最短ルートです。API バージョン移行と CRM データ移管はパターン化しやすく、Claude Code の段階リファクタとスキーマ抽出機能が特に効きます。単価レンジは日本のフリーランス受託市場の公開単価帯(レバテック・ランサーズ等)を目安に置いていますが、案件の複雑度で 2〜3 倍ぶれる前提でクライアント交渉に臨んでください。

レガシー改修案件を取りに行く営業フロー — 4 フェーズ見積もりとリスク提示

ここまでで実装手順は揃いました。最後に、レガシー改修案件を新規受注 + リピート受注する営業フローを整理します。Claude Code の時短分を発注側に開示しない単価維持の語彙と、退行リスクを契約前に共有するヒアリングシート、段階納品でリピートに繋ぐ流れの 3 点が肝です。短縮分をそのまま値下げ転嫁すると単価が崩壊するので、「品質と退行 0 を保証する代わりに工数は非開示」のスタンスを徹底してください。

4 フェーズ建て見積もりで Claude Code の短縮分を開示しない

レガシー改修の見積もりは、本記事の 4 ステップに沿って「現行調査フェーズ」「キャラクタリゼーションテストフェーズ」「段階リファクタフェーズ」「退行検証フェーズ」の 4 フェーズ建てで提示します。各フェーズに固定額を割り当て、合計額をクライアントに提示する形式です。Claude Code 併用で実工数が圧縮されても提示額は据え置きで、短縮分を「品質保証バッファ」と「退行リスク保険」として内部留保します。発注側からすると「フェーズごとに納品物が見える」ので透明性が高く、こちらは単価を守れる Win-Win 構造です(Claude Code セキュリティ — 公式ドキュメントも参考に、API キー管理の説明資料を作っておくと信頼度が上がります)。

リスクヒアリングシートで想定外の退行リスクを契約前に共有

レガシー改修で最も怖いのは「契約後に発覚する想定外の退行リスク」です。これを防ぐため、契約前に必ずリスクヒアリングシートを 1 枚提出してもらいます。質問項目は「現行コードのテストカバレッジ」「過去 1 年の本番障害件数と原因」「ドキュメントの整備度(API 仕様書・運用手順書・テスト仕様書の有無)」「現行コードに触れる権限を持つ人数」「過去 3 か月以内に発生した既知の不具合一覧」の 5 項目を最低限。回答内容によって見積もりに「リスクバッファ」を 20〜50% 上乗せし、その根拠をクライアントに開示します。契約後に新規発覚した重大リスクは別フェーズとして追加見積もりする旨も合意書に明記すると、契約後トラブルが激減します。

段階納品とリピート提案 — 1 スプリント = 1 ステップで信頼を積む

最後にリピート受注の組み立てです。4 フェーズをそれぞれ 1 スプリント(2 週間)で納品し、各スプリント終了時にテストパス証跡(スナップショット件数・通過率・diff サマリ)をレポートとして提示します。クライアントは「目に見える進捗 + テスト裏付け」を毎スプリント受け取れるので、追加スプリントの提案が通りやすくなります。納品後 1 か月以内に「次フェーズ提案書」と「保守運用提案書」を 1 枚ずつ出すと、6 割前後の確率で次案件に繋がる経験則があります(Claude Code のコスト最適化はClaude Code コスト最適化記事も併読推奨)。レガシー改修は単発で終わらせず、保守運用 + 機能追加 + 言語移行の 3 サイクルで 1〜2 年のリピート関係に育てるのが最大の経済価値です。

まとめと次のアクション

Claude Code は新規開発向けという思い込みを外し、レガシー改修の構造把握・テスト先行・段階リファクタ・退行検証の 4 ステップに当てはめれば、20 ページ規模の業務システム保守で約 5 倍速の時短が見込めます。詰まりの典型 4 パターン(構造把握不足・退行恐怖・テスト未整備・仕様逆引き不能)はいずれも Claude Code の介入で構造的に解消でき、特に三重苦が同時発生する受託保守案件で経済効果が最大化します。営業面では 4 フェーズ建て見積もり + リスクヒアリングシート + 段階納品の 3 点セットで単価維持とリピート受注を両立し、短縮分の値下げ転嫁による単価崩壊を構造的に防いでください。Claude Code の入門から知りたい方はClaude Code 完全ガイドを併読推奨です。

出典

• Claude Code 概要 — 公式ドキュメント
• Claude Code 入門 — 公式ドキュメント
• Claude Code ベストプラクティス — 公式ドキュメント
• Claude Code セキュリティ — 公式ドキュメント
• Claude Code 完全ガイド — Clauder Navi
• Claude Code サブエージェント活用 — Clauder Navi
• Claude Ralph Loop 解説 — Clauder Navi
• Claude Code コスト最適化 — Clauder Navi