Claude実践大全第10章:レガシーコードを安全にリファクタリングする──「見えないバグ」を本番前に捕まえる技術

本記事は、『Claude実践大全:Chat・Cowork・Codeで「動くAI」を仕事に組み込む技術』を1章ずつ紹介するシリーズの第10回です。各記事では1つの章のエッセンスをダイジェストでお届けします。

「AIにリファクタリングを任せたら一瞬で終わった。でも、本当に大丈夫だろうか?」――この不安は正しいものです。第10章は、その不安を「規律」に変える章です。熟練エンジニアが数時間かけるモジュールの改修を、Claude Codeは数分でやってのけます。けれど、ミスを防いでくれる深い習熟までは持っていません。効率は絶大、しかし見えにくいバグが潜むリスクは現実のもの。だからこそ、避けるのではなく「捕まえる」発想が要になります。

すぐにエラーにならないからこそ怖い

AIリファクタリングで最も危険なミスは、すぐにエラーを起こさないものです。本書では、ぞっとするような実例が語られます。たとえば「静かなる認可バイパス」。冗長に見えたパーミッションチェックをAIが取り除いたところ、それは実は安全網でした。普段は問題なく動き、別サービスで競合状態が起きた瞬間に本番でセキュリティ侵害へ――。

あるいは「暗黙の契約を壊す者」。nullは『見つからない』、undefinedは『取得エラー』という文書化されていない区別を、AIが両方nullへ統合してしまう。呼び出し側の脆いロジックが、原因不明のエラーとして牙をむきます。共通するのは、リファクタリング後のコードが「より洗練され、より整っている」のにバグが見えにくいこと。ハッピーパスのテストは、平然と突破してしまうのです。

まず「特性テスト」で現状を写し取る

答えの一つが特性テスト(characterization test)です。これは「コードが正しいこと」を検証するテストではありません。エッジケースもエラー条件も実装上の癖も含めて、今のコードの実際の挙動をそのまま写し取るテストです。リファクタリング前に基準線として用意しておき、改修後に再実行する。挙動がわずかにでも変われば、テストが失敗して教えてくれます。

💡 ポイント: 特性テストは「あるべき姿」ではなく「今の姿」を固定します。だからこそ、意図しない挙動変化という、最も見つけにくい事故を確実に検知できるのです。

一度にやらない。小さく刻んで検証する

モジュール全体を一気に任せるのではなく、段階的に進めます。検証ロジック、エラー処理、ログ出力――と小さく焦点を絞って依頼し、各ステップのあとに特性テストを実行してコミットする。こうしておけば、もしテストが壊れても、コミット履歴を見れば原因の変更が一目でわかります。大きな変更が壊れたあとに犯人探しをするより、はるかに効率的です。

AIが生成したPRは「別のスキル」でレビューする

AI生成コードのレビューは、人間が書いたコードのそれとは別物です。スタイルの好みを探すのではなく、見えにくい挙動変化・セキュリティ問題・アーキテクチャ違反を探します。本書は系統立ったチェックリストを示します。変更範囲は依頼通りか、勝手な依存追加はないか、エラー経路は保持されているか、こっそり消されたコードはないか――。

⚠ 注意: AIは存在しないAPIメソッドを自信たっぷりにでっち上げることがあります(ハルシネーション)。外部API・ライブラリ関数・組み込み関数が実在するか、ドキュメントや型定義で必ず裏取りを。SQLの文字列連結やハードコードされたシークレットも要警戒です。