リファクタリングの頼み方：範囲指定と段階実行
「このコードを綺麗にして」とだけ頼むと、意図しない広範囲な変更が返ってくることがあります。リファクタリングは範囲を区切り、段階的に進めることで、安全かつ確認しやすくなります。
最終更新: 2026-07-23・読了目安 約3分
リファクタリングとは何か
リファクタリングとは、動作を変えずにコードの内部構造を整理し、読みやすく・変更しやすい状態にする作業です。新しい機能を追加するわけではないため、成果が見た目にわかりにくい一方、後の開発速度や不具合の起きにくさに大きく影響します。この定義は、リファクタリングという手法を体系化したMartin Fowler氏によるRefactoring公式サイトでも「外部からの振る舞いを変えずに内部構造を整理する規律あるテクニック」として説明されています。
AIコーディングエージェントはリファクタリングも得意な作業の一つですが、指示があいまいだと、必要以上に広い範囲まで書き換えてしまうことがあります。動作確認が難しくなるほど範囲が広がると、リファクタリング自体が新しい不具合の原因になりかねません。
範囲を指定する
リファクタリングを頼むときは、対象範囲を具体的に絞り込みましょう。
- ファイル・関数を名指しする：「〇〇ファイルの△△関数だけを対象に」と限定する
- 目的を伝える：「重複を減らしたい」「関数を短く分割したい」など、何を改善したいのかを明示する
- 変えてはいけない部分を伝える：「外部から呼び出している関数名・引数の形は変えないでください」のように、影響範囲を限定する
「動作を変えずに」という前提を毎回明示することも重要です。この前提がないと、リファクタリングのついでに機能まで変更されてしまうことがあります。
段階的に実行させる
大きなリファクタリングほど、一度に全部やらせず、段階に分けて進めましょう。
- 1段階目：重複しているコードを共通の関数にまとめる
- 2段階目：長い関数を役割ごとに分割する
- 3段階目：命名をより意図が伝わるものに変更する
各段階の後に、必ずテストを実行して動作が変わっていないことを確認してから次に進みます。この確認を怠ると、複数の変更が積み重なった状態で問題が起きたときに、どの変更が原因かを切り分けられなくなります。テストで動作を保証する考え方はAIとテスト駆動開発で扱った内容がそのまま活きます。
コミットを小さく分ける
段階ごとにコミットを分けておくと、後から見直したときにどの変更が何を目的にしていたかが追いやすくなります。もし途中の段階で意図しない不具合が入り込んでも、直前のコミットまで戻せば被害を最小限に抑えられます。履歴管理の基本はGit/GitHub入門で解説しています。
よくある失敗パターン
- 「全体を綺麗にして」とだけ頼む：範囲が広すぎて、確認しきれない変更が積み重なる。
- 動作確認をせずに次の段階に進む：問題が起きたときに原因の切り分けが困難になる。
- 機能変更とリファクタリングを同時に頼む：動作が変わったのがリファクタリングのせいか機能変更のせいか分からなくなる。
- 変えてはいけない部分を伝えない：外部から使われている関数名や引数の形まで変わってしまうことがある。
よくある質問
Q1. リファクタリングとバグ修正・機能追加を同時に頼んでもいいですか？
おすすめしません。動作が変わった原因がリファクタリングのせいか機能変更のせいか分からなくなるためです。リファクタリングは「動作を変えない」ことが前提なので、機能変更とは別の依頼として分けましょう。
Q2. リファクタリング後にテストがなくても大丈夫ですか？
テストがない状態でのリファクタリングはリスクが高くなります。最低限、変更前後で同じ入力に対して同じ出力が返ることを手動でも確認し、可能であれば先にテストを用意してから着手するのが安全です。テストの書かせ方はAIとテスト駆動開発で解説しています。
Q3. AIに「全体を綺麗にして」と頼むのはなぜ危険ですか？
範囲を指定しないと、AIは想定より広い範囲まで書き換えてしまうことがあります。確認しきれない変更が積み重なると、リファクタリング自体が新しい不具合の原因になりかねません。ファイルや関数を名指しして範囲を絞りましょう。
関連記事
依頼の伝え方の基本は目的・前提・期待出力を分けて書く型、リファクタリング中にエラーが出た場合の対処はエラーの貼り方と情報の渡し方もあわせてご覧ください。