AI駆動開発でPRを小さく保つ方法｜レビュー待ちを増やさない分割術

Claude CodeやCodexへ機能単位で依頼すると、関連箇所を探索し、実装、テスト、周辺の整理まで一度に進めることがあります。生成が速いほど、作業者には一続きの変更に見えます。しかし、レビュー担当者が同時に判断できるとは限りません。振る舞いを変える妥当性と、既存構造を整理する妥当性では、確認する観点が違うからです。

では、何行なら小さいのでしょうか。固定の行数だけでは決められません。GoogleのEngineering Practicesは、適切な大きさを「自己完結した一つの変更」とし、小ささを概念上の焦点として捉えています。同資料には行数の目安もありますが、最終的にはレビュー担当者の判断であり、ファイル数も大きさに影響すると明記されています。行数は警告にはなっても、分割線にはなりません。

分割線は、PRを読んだ人が答える問いで引きます。「既存動作を固定するテストとして妥当か」「この名前変更に振る舞いの変更が混ざっていないか」「新しい入力を受け付ける仕様でよいか」。問いを一文で表せず、接続詞で複数の判断をつないでいるなら、まだ分ける余地があります。

AIへ最初から完成機能を委ね、出力後に巨大な差分を分けると、変更同士が絡みます。後から切り離す際にテストがどちらへ属するか迷い、依存している修正を落とす危険も増えます。先に完成条件を列挙し、それぞれを誰が何について判断するPRなのかへ変換します。AIへの依頼も、その単位を越えない範囲にします。

一つの受け入れ条件と、その条件を確かめる変更を同じPRに置きます。作業一覧を細切れにしただけでは、判断可能な単位になりません。たとえば新しい分岐を実装したのにテストだけ後続へ送ると、最初のPRでは判断材料が欠けます。Googleの指針も、ロジックを追加・変更する差分には新規または更新した関連テストを伴わせるとしています。

一方、既存動作を記録するテストは先行PRにできます。挙動を変えずに現状を固定する判断がそこで閉じ、後続の整理や実装が既存動作を壊していないか比較できるからです。同じ「テスト」でも、どの判断を成立させるかによって置き場所が変わります。

フロントエンド、API、データ層というファイル群だけで分けると、各PRが未使用の部品や動かない途中状態になりがちです。すべての層を一つへ入れれば、今度は仕様判断と実装詳細が膨らみます。上の分類を機械的に選ばず、各段階で閉じる判断を基準に組み合わせます。

分割後の各差分で人が見る境界はAI生成コードのレビュー観点、変更に対応する検証の層はAI駆動開発のテスト戦略で確認できます。レビューの問いと検証方法を同じ単位へそろえます。

この並びは万能のテンプレートではありません。新しいAPIだけを先に置いても使い方が分からないなら、最小の利用箇所まで同じPRへ含めます。Googleの指針も、新APIはその含意を理解できるよう使用例を同じ変更へ含め、未使用APIを入れない考え方を示しています。小さいことより、単独で意味を判断できることが優先です。

自動生成された大量の整形や機械的変更も、機能差分とは分離します。機械的かどうかを確認するレビューと、動作が正しいかを確認するレビューを混ぜないためです。自動生成という理由だけで安全とは扱わず、生成手段、再生成方法、手編集の有無、必要な検証結果を説明へ残します。

PRを小さくすると件数は増えます。すべてを一件ずつマージしてから次を作れば、レビュー待ちはそのまま開発待ちになります。そこで、依存関係を先に描き、土台から上へ積みます。Googleの指針も、小さな変更をレビューへ送り、その変更を基に次の変更を進める方法を挙げています。

順序は「既存動作を守る検証」「振る舞いを変えない整理」「契約や境界」「機能実装」「利用範囲の拡張」が基本になります。後続PRは先行PRとの差分だけでレビューできるようにし、説明欄に依存先と推奨レビュー順を示します。独立した変更は別の枝として並行に出せます。

ただし、依存PRを重ねれば自動的に速くなるわけではありません。先頭の設計が変わると後続すべてに修正が波及します。迷いが大きい判断ほど手前で小さく提示し、合意後の機械的な展開を後ろへ置きます。不確実な判断の滞留を後続作業から切り離すと、レビュー待ちを減らせます。

AIの出力を最後にまとめて検証すると、最初の誤解を抱えたまま関連コードが増えます。完成後のテスト失敗だけを直しても、要求の取り違えや不要な抽象化は残るかもしれません。上の区切りで生成を止め、差分と検証結果を人が確認すれば、目的外の変更が育つ前に修正できます。

GitHubの公式ドキュメントでは、PRのConversationに説明やレビュー、Commitsに履歴、Checksに自動テストやビルド、Files changedにレビュー対象の差分がまとまると説明されています。検証結果と未確認事項をPRへ集めれば、レビュー担当者はコードを読む前に判断の範囲をつかめます。ツールが通った事実と、仕様が正しいという判断は分けて記述します。

途中段階を共有したいだけならDraft PRを使えます。GitHubではDraft PRはマージできず、準備ができたらレビュー可能な状態へ変更できます。ただし、未整理の差分をDraftという名前でレビュー担当者へ預けるのは避けます。早期相談で決めたい問いと、まだ検証していない範囲を明示して初めて、待ち時間を合意形成へ変えられます。

小さいPRでも、差分だけから目的を推測させればレビューは止まります。説明欄には、上の項目を使って判断に必要な文脈を短く揃えます。作業内容に加え、なぜこの境界なのか、何をしないのか、何で確かめたかまで分かれば、レビュー担当者は調査を省いて判断から始められます。

この情報で問いが閉じないなら、PRの分け過ぎも疑います。前のPR、口頭説明、未提出の後続コードがなければ意味を理解できない差分は、単独のレビュー単位になっていません。小ささを目的にせず、レビュー担当者が現在のコードベースとPR内の情報から結論を出せる境界へ戻します。

AI駆動開発でPRを小さく保つとは、生成されたコードを一定行数で切ることではありません。一つの受け入れ条件、その実装、関連する検証をまとめ、レビュー担当者が一つの判断を完了できる形にすることです。整理と機能変更を離し、不確実な判断を依存順の手前へ置けば、後続作業はレビュー待ちと並行して進められます。

冒頭で残した条件は、各PRが自己完結し、途中でもコードベースを健全に保つことでした。生成前に対象外を決め、生成途中に差分を止めて検証し、新APIには理解できる最小の利用箇所を、ロジック変更には関連テストを添える。これなら、小分けによって壊れた中間状態や文脈不足を作りません。PR数や生成量を成果にせず、判断可能な変更が滞りなく流れるかをチームで見てください。