AIで差分が膨らんだ。レビュー前に小さく切り直す勇気
AIが一気に作った差分、出す直前に怖くなる
「動いた。でも、このPRを出すの、ちょっと怖いな…」
火曜の18時すぎ。AIエージェントに任せていた不具合修正が、思ったよりきれいにまとまった。画面は直った。テストも増えた。ついでに古い関数名まで整っている。
最初は助かったと思う。昼なら半日かかっていた調査と修正が、夕方には形になっている。AI、かなり頼もしい。
でも、PR画面を開いた瞬間に手が止まる。
変更ファイルは18個。差分は1,000行を超えている。バグ修正、テスト追加、軽いリファクタ、不要そうな分岐の削除が、ひとつの塊になっている。
レビュー相手の顔が頭に浮かぶ。
「これ、どこから見ればいいですか？」
その一言を想像しただけで、胃のあたりが少し重くなる。せっかく速く作れたのに、ここで切り直したら時間を戻すように見える。大きな差分を出したら雑に見えるかもしれない。小さく分けると言ったら、「最初からそうして」と思われるかもしれない。
この気まずさがあると、人は変な動きをする。PR本文で長く説明しようとする。未確認の不安を隠して「一旦お願いします」と投げる。あるいは、レビュー依頼を明日に回す。
でも、ここで止まったこと自体は悪くない。むしろ大事な違和感だ。AIで速く作れた差分ほど、そのまま出す前に、人が小さく切れる形へ戻す必要がある。
DORA の 2026年4月更新のレポートでは、生成AIの利用が増えると個人の生産性や満足度に良い影響がある一方、ソフトウェアを届ける速さや安定性には注意が必要だと整理されている。AIでコードを速く作れるほど変更の塊が大きくなり、レビューが遅くなったり安定性を下げたりしやすい、という見方だ。
この記事では、AIで大きくなった差分を、レビュー前にどう小さく切り直すかを整理する。
大きい差分は、レビュー相手だけでなく自分も迷わせる
大きいPRがつらいのは、レビュー相手の負担が増えるからだけではない。出した本人も、あとから説明しづらくなる。
火曜18時のPRに戻る。画面の不具合は直っている。けれど、差分の中には「今回の修正に必要な変更」と「AIがついでに整えた変更」と「気づいたら広がっていた変更」が混ざっている。
「この関数名変更、今回必要でした？」
そう聞かれた時、「AIが提案したので」とは言いづらい。自分も少し良いと思った。でも、今回の不具合修正に本当に必要だったかは曖昧だ。曖昧なまま入れた変更ほど、質問された瞬間に背中が冷える。
見た目が整っているほど、戻しにくい
AIの差分は、見た目がきれいなことがある。命名もそれっぽい。テスト名も自然。不要そうなコードも消えている。
だからこそ、戻しにくい。
人が手で雑に直した差分なら、「ここは後でやる」と切り分けやすい。でもAIがきれいにまとめると、全部がひとつの完成品に見えてくる。せっかく整ったものを壊すのがもったいなくなる。
この感覚はかなり自然だ。作ったものを崩すのは、少し痛い。しかもAIで速く作れた後ほど、「ここで時間をかけたら速さが消える」と感じやすい。
ただ、差分を小さく切ることは、できたものを捨てることではなく、採用しやすい順番へ並べ替えること だ。完成品に見える塊を、レビューできる単位へ戻す。
ついでの変更が、怖い場所をぼかす
AIに「このバグを直して」と頼むと、周辺のコードも見てくれる。これは助かる。一方で、周辺まで触った結果、本当に見てほしい怖い場所がぼける。
たとえば、本題は「退会済みユーザーが設定画面へ入れてしまう」問題だったとする。そこへ、画面コンポーネントの整理、テストヘルパーの名前変更、未使用 import の削除まで入る。
全部が悪いわけではない。でも、ひとつのPRに入ると、レビュー相手は全部を同じ重さで見ることになる。
OWASP の Secure Coding with AI Cheat Sheet では、AIエージェントが依頼範囲を超えて lockfile、CI設定、関係ないテスト、フォーマット変更などへ触れることをレビュー上の失敗モードとして扱っている。さらに、AI生成コードには人間の所有者が必要で、ツールではなく受け入れた開発者が責任を持つ、という整理もある。
つまり、「AIが広げたから仕方ない」では終われない。自分が受け入れてPRにするなら、今回残す変更と後へ回す変更を決める必要がある。
大きな差分を見ると、レビュー相手はまず警戒する。権限は大丈夫か。既存仕様とぶつかっていないか。リリース後に戻せるか。OWASP の Secure Code Review Cheat Sheet でも、PRやコミット単位のレビューでは、変更ファイル、影響する部品、既存の安全対策への影響を見ると整理されている。大きすぎる差分は、この確認をぼかしてしまう。
切り方は、目的・危なさ・戻し方の3つで見る
では、AIで膨らんだ差分をどう分ければいいのか。完璧な設計図はいらない。まずは3つで見る。
- 目的が同じか
- 危なさが同じか
- 戻し方が同じか
1. 目的が違う変更を、同じPRに入れない
最初に見るのは目的だ。
退会済みユーザーを設定画面で止める。これは不具合修正だ。テストヘルパーの名前を読みやすくする。これは整理だ。不要な import を消す。これは掃除だ。
どれも良い変更に見える。でも、目的は違う。
目的が違う変更をまとめると、レビューの問いが混ざる。「不具合が直っているか」と「名前変更が妥当か」と「掃除で副作用がないか」を同時に見ることになる。相手の頭の中で、確認のスイッチが何度も切り替わる。
火曜18時の場面なら、まず不具合修正だけを残す。関数名変更は別PRへ回す。不要 import の削除は、同じファイルで本当に必要なら残してもよいが、広く散っているなら後にする。
今回のPRで相手に判断してほしいことを1つに寄せる。 これだけで、レビューの始まり方はかなり変わる。
2. 危なさが違う変更は、確認の厚さも分ける
次に見るのは危なさだ。
見た目の文言修正と、権限チェックの変更は同じ重さではない。テスト名の整理と、支払い処理の条件分岐も同じではない。AIは同じテンポで編集できるが、人が確認する重さは違う。
危ない変更は、小さく出した方がいい。権限、支払い、個人情報、データ削除、外部API、バッチ処理、CI/CD設定。このあたりが入るなら、できるだけ単独で見える形にする。
NIST の SSDF Version 1.2 初期公開ドラフトも、安全で信頼できる開発のために、開発プロセスへ安全対策を組み込む考え方を示している。ValueGateの読者に引き寄せるなら、「危ない場所を特別扱いできる単位で出す」と言い換えられる。
AIで速く作れた時ほど、ここを雑にしない。速く作ったからこそ、危ない部分だけ厚めに見られるように切る。
3. 戻し方が違う変更は、まとめない
最後に見るのは戻し方だ。
もしリリース後に問題が起きた時、どこを戻すか。これを想像すると、PRの切り方が急に現実的になる。
たとえば、画面の表示バグ修正と、内部関数名の整理を同じPRに入れたとする。表示バグ修正に問題があって戻したい時、関数名整理まで一緒に戻る。
リリース後に焦っている時ほど、戻し方が混ざっているPRは扱いにくい。戻し方が違うなら、分ける。先に不具合修正を出す。落ち着いてから整理を出す。AIが一度に作ってくれても、出す順番まで一度にする必要はない。
PRを切る前に、10分だけ仕分ける
大きな差分ができた時、いきなり完璧に分割しようとするとしんどい。だから最初は、10分だけ仕分ける。
画面の横にメモを3列で置く。
- 今回必要
- ついでにできた
- 怖いので厚めに見る
AIに「この差分を目的別に分けて」と聞いてもいい。ただし、最後にどこへ置くかは自分で決める。今回の案件で何が本当に必要か、レビュー相手がどこを見るべきかまでは、現場の文脈がいる。
まず「今回必要」だけでPRを作れるか見る
最初に見るのは、今回の目的に直接効く変更だ。
退会済みユーザーが設定画面へ入る問題なら、入口の状態確認、戻し先、関連テスト。この3つが中心になる。これだけでPRが成立するなら、まずそこを出す。
残りの変更は、後続PRとして残してもいい。大事なのは、レビュー相手へ「今回はこの問題だけを見てください」と言える状態を作ることだ。
PR本文も短くなる。
退会済みユーザーが古い設定リンクから入れる問題を止めるため、設定画面の入口で状態を確認するようにした。今回のPRでは、入口処理と関連テストだけを対象にしている。関数名整理は後続PRへ分ける。
このくらいで十分だ。相手が最初に探すものが減る。
「ついでにできた」は、未来の自分へ送る
ついでの変更は、悪者にしなくていい。AIが見つけた整理は、後で効くことがある。ただ、今入れる必要があるかは別だ。
たとえば、テストヘルパーの名前が分かりにくい。確かに直したい。でも今回の不具合修正に入れると、レビュー相手は「この名前変更で既存テストに影響はないか」まで見ることになる。
こういう時は、後続メモにする。
- テストヘルパー名を整理する
- 設定画面の共通分岐を別関数へ寄せる
- 不要 import の削除をまとめる
後回しにすると忘れそうで怖いなら、issueやメモに残す。今やらないことを、なかったことにしない。後で扱える形にして、今回のPRから外す。
捨てるのではなく、置き場所を変えるだけ。そう考えると、切り直しが少し楽になる。
「怖い」は隠さず、PRの入口に置く
大きな差分の中で、いちばん大事なのは怖い場所だ。
権限分岐、支払い条件、データ更新、メール送信、CI/CD、外部API。ここにAIが触れているなら、PR本文で先に言う。
怖いのは、退会済みユーザーと期限切れリンクが重なった時の戻し先です。ここは既存仕様との相性を厚めに見てほしいです。
未確認や不安を書くのは、少し勇気がいる。「ちゃんと見てから出して」と思われそうで、言葉を引っ込めたくなる。でも、不安を隠したまま大きな差分へ埋める方が危ない。
怖い場所を言える人は、弱い人ではない。怖い場所を自分で見つけ、相手が確認しやすい形へ出せる人は、AI時代のレビューでかなり助かる人 だ。
小さく切る人は、仕事を遅くしているわけじゃない
AIで速く作ったあとにPRを分けると、少し遅くなった気がする。せっかく1時間でできたのに、分割で30分かかる。なんだか損した気分になる。
でも、レビューで2日止まるより、30分かけて見やすくした方が速いことは多い。
DORAのレポートでも、AIで大量のコードを速く作れるからこそ、質の高い確認の流れを強める必要があると整理されている。小さく切ることは、その流れに乗せるための準備だ。
AIで差分ができると、つい「できました」と言いたくなる。でも、現場で強いのは「できました」だけではない。
今回は退会済みユーザーの入口制御だけを直しました。関数名整理は別PRにします。怖いのは期限切れリンクとの組み合わせなので、そこを見てください。
こう言えると、相手は判断しやすい。実装の速さは価値だ。ただ、その速さをチームの前進に変えるには、差分の粒度、確認範囲、戻し方まで整える必要がある。これは、実装を採用可能な形へ変える仕事だ。
関連する話は、AIで作ったPR、「レビューお願いします」だけで投げてない？ と AIを使ったら仕事を安くしていい？ 確認の仕事を値段に入れる方法 にも書いた。
最後に
AIで大きな差分が一気にできると、うれしい。ここは素直にうれしくていい。調査も実装もテスト案も進むなら、かなり助かる。
ただ、そのままPRへ出す前に、10分だけ立ち止まりたい。
- 今回必要な変更はどれか
- ついでにできた変更はどれか
- 怖いので厚めに見てほしい変更はどれか
- 戻す時に一緒に戻って困る変更はないか
この4つを見るだけで、差分の出し方は変わる。
火曜18時の画面前で手が止まったなら、それは遅さではない。AIの速さを、チームが受け取れる大きさへ戻そうとしているサインだ。
AIで速く作る力と、レビューしやすく小さく切る力はセットで価値になる。 まずは次のPRで、目的が違う変更を1つだけ外してみる。そこからで十分だ。
AIで作った差分が毎回大きくなり、レビューや説明で詰まりがちなら、そこは一緒に整えられる。どこをAIに任せ、どこを人が切り、何を価値として伝えるか。次の案件では、その流れを一緒に言葉にしていこう✨
AIで作った差分を、採用される形へ整える
ページへ移動参考にした情報
- Google Cloud / DORA「Impact of Generative AI in Software Development」（2026年4月13日更新、2026年7月21日確認）
- OWASP「Secure Coding with AI Cheat Sheet」（2026年版、2026年7月21日確認）
- OWASP「Secure Code Review Cheat Sheet」（2026年7月21日確認）
- NIST「SP 800-218 Rev. 1, Secure Software Development Framework Version 1.2」（2025年12月17日公開、2026年7月21日確認）
