AIを活用した安全なコードリファクタリング｜既存機能を壊さず品質を向上させる方法

最終更新日：June 27, 2026

リファクタリングとは、かつては静かな午後、テストがすべてパスしている状態（グリーン）、そして丁寧な名前変更の積み重ねを意味していました。AI はその作業の速度を変えますが、背後にある規律までは変えません。モデルは数十ファイルにわたるシンボル名を数秒で変更できますが、3年前に決済のエッジケースを処理していたブランチを自信満々に削除してしまうこともあります。

これは、慎重なエンジニアが行うように AI でリファクタリングを行う実践者のためのガイドです。小さなステップ、動作の維持、すべての変更をテストで守るというアプローチです。

クイックアンサー：壊さずに AI でリファクタリングするには？

AI を疲れないチケットを一切読まない速い新人エンジニアとして扱ってください。動作の責任はあなたが負います。

まずテストで動作を固定し、次に小さな変更を一つずつ依頼し、受け入れる前に差分を確認してください。リファクタリングとは、観測可能な動作を変えずに構造を変更することを意味します。これはマーティン・ファウラーが彼の refactoring catalog で定義したものです。変更が動作を変える場合、それは書き換えまたはバグ修正であり、異なる検討が必要です。

実際の納期にも耐えられるワークフロー：

1. キャラクターテストで現在の動作を固定する。
2. AI に狭く名前付きのターゲットを与える（「この検証ロジックを純粋関数に抽出する」など）。
3. 要約だけでなく完全な差分を読む。
4. コミットする前にスイートとリンターを実行する。
5. 後でバイセクトできるように、緑色のステップごとに個別にコミットする。

変更はマージ可能に保ってください。レビューを通る 40 行のリファクタリングは、誰も検証できない 2,000 行の「クリーンアップ」よりも優れています。

リファクタリング中に AI が実際に何ができるか？

AI はリファクタリングの機械的かつパターンに依存する部分では最も強く、意図（インテント）の部分では最も弱いです。

モジュール全体での名前変更、関数の抽出、コールバックチェーンを async/await への変換、ゴッドクラスを小さな協調オブジェクトへの分割、あるフレームワークのイディオムから別のものへのファイル変換などを得意とします。一方、「正しい」構造が誰かの頭の中や 2022 年の Jira のコメントにあるビジネスルールに依存している場合、苦戦します。

有用な習慣：何か変更する前に、モデルに既存のコードを explain させることです。その要約が間違っていれば、リファクタリングも間違いになりますし、無料でそれを見逃さずに済みます。

AI がコードを書き換えている間、テストを緑に保つには？

テストは契約です。それなしで AI によるリファクタリングは、望みを込めた推測に過ぎません。

触れたいコードにカバレッジがない場合、まずキャラクターテストを書いてください。これらはコードが今何をするか（すべきことではなく）を捉えるため、動作の変更はすべて赤いテストとして表示されます。この手法は Wikipedia entry on characterization tests で説明されており、モデルにレガシーコードに触れさせる前に最も貴重な安全網となります。

テストのないモジュールでこの順序を使用してください：

1. コードパスを実行し、実際の入出力を記録する。
2. その正確な出力をアサートするテストを書く（醜いものでも）。
3. スイートが緑で、かつ合理的な速度であることを確認する。
4. AI に小さなステップでリファクタリングさせる。
5. 赤に切り替わるテストがないか監視し、見つかったらそこで停止する。

私が携わったチームには、誰も触れたがらない 600 行の請求書計算機がありました。私たちは朝を費やして本番環境のサンプルに対して 30 個のキャラクターテストを書き、その後モデルに関数を名前付きステップに分割するよう依頼しました。丸め処理で 2 つのテストが赤になりました。その赤がまさに要点でした：旧コードは明細ごとに丸めていましたが、リファクタリング版は最後に一度だけ丸めています。私たちは旧動作を維持してリリースしました。より深いテスト戦略については、以下のレビューと検証ループを使用してください。

ステップバイステップの安全な AI リファクタリングワークフロー

IDE アシスタントでも Claude Code のようなターミナルエージェントでも、同じループを使用してください。

1. スコープを定める。 明確な境界を持つリファクタリングを一つ名前付ける：「OrderService から RetryPolicy に再試行ロジックを抽出する」のようにし、「注文をクリーンアップする」のようにしない。
2. 動作を固定する。 テストが変更する行をカバーしていることを確認し、不足があれば追加する。
3. プロンプトを狭くする。 ターゲットコードと一つの制約を貼り付ける：パブリックインターフェースを維持する。
4. 差分を読む。 削除されたブランチ、変更されたデフォルト値、入れ替わった演算子、削除された null チェックに注意する。
5. 検証する。 テスト、型チェッカー、リンターを実行する。I/O が変更された場合は統合テストを再実行する。
6. 小さくコミットする。 コミットごとに緑のリファクタリングを一つ；変更した構造の名前を付ける。
7. レビュー可能な PR を開く。 差分をチームメイトが読める程度に小さく保つ。

レビューのステップが最も重要です。AI が生成した差分は自信に満ちていてクリーンに見えますが、それゆえに通ってしまうのです。変更されたすべての行を読み、依頼していない削除には疑いを持たせてください。

AI でコードスメルを特定するには？

AI は匂いを命名するのは得意ですが、修正するとなると平均的です。まず検出器として使い、次にエディターとして使ってください。

ファイルを指し示して、どの関数が長すぎるか、重複がどこに隠れているか、一緒に移動すべきパラメータはどれでオブジェクトにするべきか、条件分岐がどこで茂みに成長しているかを尋ねてください。ファウラーの catalog of code smells は今でも最も明確な共通語彙であり、その用語を知るモデルはレビュアーと議論できる発見をもたらしてくれます。

一度のパスで「すべての匂いを修正する」ようにしないでください。スメルレポートは ToDo リストであり、命令ではありません。ある程度の重複は構いません。長い関数が長いのは、ドメインがそうだからです。

ツールとそれぞれの適所

ツール自体よりも、それを囲むループの方が重要です。しかしカテゴリは作業の仕方を変形させます。

• IDE 組み込みアシスタント は入力中に編集を提案し、小さくローカルなリファクタリングで輝きます。
• チャット型アシスタント は貼り付けたファイルや関数に対して「説明してから再構成する」のに適しています。
• ターミナルエージェント はテストを実行したり多数のファイルを編集でき、それは同等の力とリスクを持ちます。
• 静的解析ツールとリンター は AI が時折作り出す機械的な問題を捕捉するため、ループに組み込んでください。

どれを選んでも、バージョン管理が本当の安全装置です。始める前にコミットし、作業用にブランチを切り、各 AI ステップを独自のコミットとして保ってください。エージェントが 12 ファイル編集してアサートメントの一つが壊れた場合、クリーンな履歴があればすべてを読み直すのではなく、正確な変更点にバイセクトできます。

リファクタリング中に導入された失敗のトラブルシューティングも行う場合、同じ体系的なループはこのワークフローとよく組み合います。プロセスについて質問がありますか？FAQ で一般的なものをカバーしています。

レガシーコードを段階的に近代化するには？

大規模な書き換えはスローモーションで失敗します。段階的な近代化が勝つのは、すべてのステップがリリースされるからです。

ストラングラーパターンは実証された形です：旧経路の横に新経路を構築し、呼び出しの一部をそれ経由でルーティングし、検証してから、旧コードが死んで削除できるまで拡張します。マーティン・ファウラーはこれを strangler fig application として文書化しており、AI は戦略を変えずにスライスごとの作業を高速化します。

AI は移行全体ではなく、各スライス内で使用してください：

1. 近代化するエンドポイント、画面、またはモジュールを一つ選ぶ。
2. 現在の実装に対してテストで動作を固定する。
3. モデルにそのスライスのみ近代化版を生成するよう依頼する。
4. 旧版と新版を同じ入力で実行し、出力を差分比較する。
5. スライスを切り替え、本番環境を観察してから次に進む。

これにより影響範囲を小さく保てます。モデルがスライスを誤解した場合、システム全体ではなくスライス一つを失うだけです。

AI にリファクタリングを任せてはいけないのはいつ？

コードを完全に理解するまでは、手動で扱うべきものもあります。

以下の場合は AI を引き留めてください：

• コードが金銭、認証、権限、またはコンプライアンスが関心を持つあらゆるものを扱う場合。
• テストがなく、まだキャラクターテストを書けない場合。
• 動作が文書化されていないビジネスルールに依存している場合。
• 差分が大きすぎて誰も正直にレビューできない場合。
• ここに微妙なバグがあると、本番環境で高額または検出が困難になる場合。

それらの場合、AI を explain と plan に使い、その後小さなレビュー済みのステップで自分で編集してください。最も速いリファクタリングは、決して元に戻す必要がないものです。動作を固定し、一つのものを変更し、スイートを緑に保ち、判断はあなたが持ちながらタイピングは AI に任せましょう。

このループを取り巻くより広範なエージェントワークフローについては、AI agent automation ガイドと AI API development のノートをご覧ください。MCP model context の記事では、リファクタリングで必要になることがある外部ツールにエージェントがどのようにアクセスするかをカバーしています。

画像クレジット

この記事の画像は Pexels から出典され、安定したページレンダリングのためにプロジェクト CDN に保存されています。

---