リファクタリングの頼み方：範囲指定と段階実行
AIにリファクタリングを頼むと、想定していなかった箇所まで一気に書き換えられてしまうことがあります。事故を防ぐコツは「範囲を絞る」「段階的に進める」「振る舞いを変えない」の3原則を指示に含めることです。実例のプロンプトとレビューの確認ポイントをまとめました。
リファクタリングでAIが暴走しやすい理由
安全に頼むための3原則
原則1：対象範囲を明示する
「このファイルの、この関数だけを対象にしてください」のように、触ってよい範囲と触ってはいけない範囲を先に伝えます。
原則2：段階的に実行させる
「まず1ステップ目だけ実行して、差分を見せてください。次のステップはその後に指示します」と区切ると、途中で軌道修正しやすくなります。
原則3：振る舞いを変えないことを明記する
「出力結果やAPIの挙動は変えないでください。変わる場合は先に理由を教えてください」と伝えておくと、意図しない仕様変更を防げます。テストがある場合は「全てのテストが通ることを都度確認してから次に進んでください」も有効です。テストの用意の仕方はAIとテスト駆動開発の記事を参考にしてください。
差分レビューでの確認ポイント
AIから差分が返ってきたら、次の観点で確認します。
- 依頼した範囲外のファイルが変更されていないか
- 関数名・変数名の変更が呼び出し元まで正しく反映されているか
- コミットを機能単位・範囲単位で分けられているか（差分が追いやすいか）
コードレビューの一般的な観点整理としては、Googleが公開しているエンジニアリング向けレビューガイドも参考になります。観点を指定してAIにレビューさせる依頼文の型はレビュー依頼文例集の記事にまとめています。差分を機能単位で管理する基本はバージョン管理の考え方とも重なります。
よくある質問
リファクタリングとバグ修正・機能追加の指示を同時に頼んでもいいですか？
避けたほうが安全です。振る舞いを変えない整理と、振る舞いを変える修正が同じ差分に混ざると、問題が起きたときにどちらが原因か切り分けにくくなります。依頼と差分は分けましょう。
テストがないコードでもリファクタリングを頼めますか？
頼めますが、まず現状の挙動を確認できる最低限のテストを書かせてから着手するほうが安全です。テストの書かせ方は先にテストを書かせるTDDの記事を参考にしてください。
AIに頼むと過剰に書き換えられてしまいます。防ぐ方法は？
「このファイルの、この関数だけを対象にしてください」のように対象範囲を明示し、「命名や設計思想が気に入らなくても、今回のスコープ外なら変更しないでください」と明記すると抑えやすくなります。