はじめに
今年のトピックはやはり、AI Agentの登場による開発の変化でしょう。
大量のコードを短時間で生成できるようになった一方で、コードレビューの負担が増えがちだなと感じています。
この記事では、コードレビューをスムーズに回すために意識していることを整理してみます。
PRで意識していること
1. やらないことを明示的に書く
レビュワーに優しいPRを作る上で、重要なのは「やらないことを明示的に書く」ことです。
PRの説明欄に「このPRでは◯◯は行っていません」と明記することで：
- 期待値を調整できる：何をレビューすべきか、何をレビューしなくて良いかが明確になる
- 無駄な指摘を減らせる：「これは別PRでやる予定です」と書いておけば、その点について指摘されることがない
- コンテキストを共有できる：なぜその変更に留めたのか、将来の計画はどうなっているのかが分かる
特にAI Agentで大量のコードを生成できるようになった今、PRの範囲を明確にすることがより重要になっていると思います。AIは関連する変更を全部含めてしまいがちなので、「このPRでは◯◯は行わない」と明示することで、レビュワーの負担を減らせます。
2. 「小さい」ではなく「適切なサイズ」を考える
コードレビューに関するベストプラクティスとして、「PRは小さい方がいい」という考え方が広く知られています。
恥ずかしながら今まで、私は「PRは小さい方がいい」と一辺倒に信じていました。
確かに、小さなPRには多くのメリットがあります：
- 理解しやすい：変更範囲が限定的なので、レビュワーが把握しやすい
- リスクが小さい：問題があった場合の影響範囲が限定的
- マージしやすい：コンフリクトが起きにくく、マージのハードルが低い
- フィードバックが早い：レビューが完了しやすい
しかし、小さすぎると...
AI Agentで大量のコードを生成できるようになったことで、少しこの考え方が変わりました。
例えば、CRUD APIを実装する際、従来であれば1つのAPIを1つのPRにしていました。しかし、AI Agentを使うと、似たような構造のAPIを短時間で複数生成できます。この場合、各APIを個別のPRにすると：
- レビュワーのコンテキストスイッチが増える：同じようなパターンのコードを何度もレビューする必要がある
- 全体像が見えにくい：関連する変更がバラバラになり、システム全体の理解が難しくなる
- レビュー回数が増える：小さなPRが大量に作られ、レビュー依頼の数が増える
実際、同じパターンの繰り返しであれば、まとめてレビューした方が効率的な場合があります。AI Agentが生成するコードは構造が似ているため、一度に複数の変更をレビューしても理解しやすいのです。
3. 変更の性質で判断する
ではどのように「適切なサイズ」を判断すれば良いのでしょうか？
小さなPRでも、リファクタリングと機能追加が混ざっていれば、レビュワーは「何をレビューすべきか」を判断する必要があります。一方で、同じ性質の変更（例えば、同じパターンのCRUD API）であれば、まとめてレビューした方が理解しやすい場合があります。
これは、Kent BeckのTidy First?で言及されている考え方とも関連しています。Tidy First?では、リファクタリング（構造の変更）と機能追加（振る舞いの変更）は分けるべきだとされています。しかし、同じ性質の変更であれば、まとめても問題ないのです。
AI Agentの登場で、この判断をより意識的に行うようになりました。
「PRは小さい方がいい」という常識に縛られず、
変更の性質を考慮して、レビュワーに優しいPRを作ることが大切だと思います。
まとめ
コードレビューをスムーズに回すために意識していることを整理してみました。
- やらないことを明示的に書く（レビュワーの期待値と認知負荷を下げる）
- 「小さい」ではなく「適切なサイズ」を考える（同型反復はまとめる、混ざるなら割る）
- 変更の性質で判断する（構造変更と振る舞い変更を混ぜない）
AIの登場で開発速度は上がりましたが、結局効いてくるのは人・組織のコミュニケーション設計だと思います。
このあたりが形骸化しないように、テンプレや運用ルールなどを「仕組み」に落としていきたいと思います。