はじめに
2025年にAIコーディングエージェントを使ってみて、いちばん見方が変わったのはコードレビューでした。
AIは速く書けます。だからこそ、人間があとから読む差分は大きくなりやすいです。
最初は「AIがどこまで実装できるか」を見ていました。でも、チーム開発で本当に効いてくるのは「AIが作った変更を人間がレビューできる形に保てるか」でした。
失敗したパターン
たとえば、小さなUI修正を頼んだつもりなのに、AIが周辺の命名やファイル分割まで直してくれたことがありました。
単体で見ると、悪い変更ではありません。
ただ、レビューする側から見ると困ります。
- どこまでが依頼された変更なのか分からない
- ついでの改善が混ざって差分が膨らむ
- テストで確認すべき範囲が広がる
- レビューコメントが本題からずれる
AIが親切にやった改善でも、レビュー可能性を下げるなら、チーム開発では負債になります。
先に決めるようにしたこと
そこから、実装前に次の4つを短く書くようにしました。
ここではテンプレートの完全版ではなく、レビューで実際に効いた最小限の観点だけに絞ります。
## Purpose
この変更で達成したいこと
## In scope
- 今回やること
## Out of scope
- 今回やらないこと
## Review focus
- レビューで重点的に見てほしいこと
大事なのは、長い仕様書を書くことではありません。
AIが迷ったときに、戻れる境界線を置くことです。
実際に効いたこと
一番効いたのは、Out of scope でした。
人間同士の開発でも、「ついでに直す」はよく起きます。AIの場合は、その速度と量が増えます。
そこで、たとえば次のように明示します。
## Out of scope
- 命名規則の整理
- 関連コンポーネントの分割
- UI文言の全面見直し
- テスト基盤の変更
こう書いておくと、AIに対しても、人間レビューに対しても、差分の判断基準ができます。
「この変更はよさそうだけど、今回は別PRにしよう」と言いやすくなります。
レビュー前にAIへ確認させる
実装後には、AIにセルフレビューをさせます。
このときも「ざっと見て」ではなく、観点を固定します。
次の観点でセルフレビューしてください。
- In scope 以外の変更が混ざっていないか
- 受け入れ条件を満たしているか
- テストで確認できていない前提はないか
- レビューで人間に明示すべきリスクはないか
このセルフレビューは、AIの出力を信用するためというより、人間がレビューに入る前の整理として使っています。
PRに残す情報
AIが作ったPRでも、人間が読む情報はいつも通り必要です。
- 何を変えたか
- なぜ変えたか
- 何を変えていないか
- どう確認したか
- 残っているリスクは何か
AIで実装が速くなっても、PR説明を省くとレビューは速くなりません。
むしろ、AIが作った差分ほど、意図を言語化しておく価値があります。
まとめ
2025年にAIコーディングエージェントを使ってみて、レビューの考え方が少し変わりました。
AIに任せる範囲を広げるほど、人間のレビューは「コードの正しさ」だけでは足りなくなります。
見るべきなのは、変更の境界です。
- 今回の目的に合っているか
- スコープ外の改善が混ざっていないか
- テスト観点と差分が対応しているか
- 人間が後から保守できる単位になっているか
AIに速く書かせる前に、レビューできる単位に切る。
これが、チーム開発でAIを使うときに一番効いた工夫でした。