AIで差分が膨らんだ。レビュー前に小さく切り直す勇気

Posted at 2026-07-20

「動いた。でも、このPRを出すの、ちょっと怖いな...」

AIエージェントに任せた修正が、一気に形になる。画面は直った。テストも増えた。ついでに古い関数名まで整っている。

最初は助かったと思う。ところがPR画面を開いた瞬間、手が止まる。

変更ファイルは18個。差分は1,000行超え。バグ修正、テスト追加、軽いリファクタ、不要そうな分岐の削除が、ひとつの塊になっている。

レビュー相手に「これ、どこから見ればいいですか？」と言われる場面が浮かぶ。せっかく速く作れたのに、切り直したら時間を戻すように見える。大きいまま出したら雑に見えるかもしれない。そう考えて、PR本文で長く説明したり、レビュー依頼を明日に回したりする。

でも、ここで止まったこと自体は悪くない。AIで速く作れた差分ほど、そのまま出す前に、人が小さく切れる形へ戻す必要がある。

大きい差分は、自分も説明しづらくなる

大きいPRがつらいのは、レビュー相手の負担が増えるからだけではない。出した本人も、あとから説明できなくなる。

「この関数名変更、今回必要でした？」と聞かれた時、「AIが提案したので」とは言いづらい。自分も少し良いと思った。でも今回の不具合修正に本当に必要だったかは曖昧。ここで背中が冷える。

AIの差分は、見た目がきれいなことがある。命名も自然。テスト名もそれっぽい。だからこそ、全部がひとつの完成品に見えて、戻しにくくなる。

ただ、差分を小さく切ることは、できたものを捨てることではない。採用しやすい順番へ並べ替えること だ。

DORA の 2026年4月更新レポートでも、AIでコードを速く作れることで変更の塊が大きくなり、レビューが遅くなったり安定性を下げたりしやすい、という見方が示されている。

AIで膨らんだ差分は、まず3つで見る。

退会済みユーザーを設定画面で止める。これは不具合修正。テストヘルパーの名前を読みやすくする。これは整理。不要な import を消す。これは掃除。

どれも良い変更に見える。でも目的は違う。目的が違う変更をまとめると、レビュー相手は「不具合が直っているか」「名前変更が妥当か」「掃除で副作用がないか」を同時に見ることになる。

危なさも分ける。文言修正と権限チェックは同じ重さではない。支払い、個人情報、データ削除、外部API、CI/CD設定に触るなら、できるだけ単独で見える形にした方がいい。

戻し方も見る。リリース後に問題が出た時、どこを戻すか。表示バグ修正と内部整理を同じPRに入れると、戻す時に両方巻き込まれる。これは地味に困る。

大きな差分ができたら、いきなり完璧に分割しなくていい。まず10分だけ、メモを3列で置く。

AIに「この差分を目的別に分けて」と聞いてもいい。ただし、最後にどこへ置くかは自分で決める。AIは候補を出せるが、今回の案件で本当に必要なものは、現場の文脈がいる。

PR本文も短くできる。

退会済みユーザーが古い設定リンクから入れる問題を止めるため、設定画面の入口で状態を確認するようにした。今回のPRでは、入口処理と関連テストだけを対象にしている。関数名整理は後続PRへ分ける。

このくらいで十分だ。相手が最初に探すものが減る。

ついでの変更は、悪者にしなくていい。後続PRやissueに残せばいい。今やらないことを、なかったことにしない。後で扱える形にして、今回のPRから外す。

怖い場所は隠さない。

怖いのは、退会済みユーザーと期限切れリンクが重なった時の戻し先です。ここは既存仕様との相性を厚めに見てほしいです。

未確認や不安を書くのは勇気がいる。でも、不安を大きな差分に埋める方が危ない。怖い場所を言える人は、弱い人ではない。レビュー相手が確認しやすい形へ出せる人だ🔍

AIで速く作る力と、レビューしやすく小さく切る力はセットで価値になる。まずは次のPRで、目的が違う変更を1つだけ外してみる。そこからで十分だ。