「PRが肥大化していく」——AIが速く書くほど、レビューが壊れる理由

「数珠つなぎ」という発想

この問題に、GitHubは2026年7月30日、公式の答えを出しました。CLI拡張機能「gh stack」を含む「スタック型プルリクエスト」がPublic Previewとして公開されたのです。1つの巨大な変更を、レイヤーごとに焦点を絞った順序付きのPRへ分割し、下のPRがマージされると上のPRも自動的に追従(リベース)する仕組みです。

Ubie社のテックブログに、実務的な例が載っていました。お気に入り機能を実装するとき、テーブル追加のマイグレーション→Repository層の実装→APIエンドポイントの実装、という3つのPRに分け、順に積み上げていく。レビュアーは「まずテーブル定義が妥当か」「次にRepositoryの実装が妥当か」「最後にAPIの実装が妥当か」と、層ごとに焦点を絞ってレビューできます。この面倒な手動作業を、gh stack syncひとつでrebase・force push・同期まで自動化した、というのが今回のPublic Preview入りの意味です。

エージェント生成PRには、独自のリスクがある

分割さえすれば安心、というわけではありません。GitHub自身のブログが指摘している通り、エージェントが書いたPRには人間の書いたPRとは異なる見落としのパターンがあります。テストを通すことだけを目的にCIの挙動を都合よく解釈してしまう「CIゲーミング」。既存の実装を知らずに車輪を再発明してしまう「コード重複の見落とし」。実際には検証していないのに「動作確認済みです」と報告してしまう、根拠のない完了報告。そして、レビューコメントが付いたまま誰も対応せず放置される「エージェントのゴースト化」です。

層を細かくした分だけ、各層で「本当に検証したのか」を確認する目は、むしろ増やす必要があります。分解はリスクを見つけやすくする土台にはなりますが、リスクそのものを消してはくれません。

私たちAI-Path自身、権限レイヤーで線引きしている理由

私たちの現場では、権限まわりの変更やデータベーススキーマに関わる差分を、人間が最初に目を通す高リスク領域として扱っています。「最初はデータベースをいじらないものに留めた方がいい。DBをいじると、もう後戻りできない」。非エンジニアの内製担当者にVibeCodingを安全に回してもらうための、社内のガードレールの言葉です。

スタックにすると、レイヤーごとに扱いを変えられるようになります。権限やスキーマに関わるレイヤーは人間が最終レビューを担い、文言修正やスタイル調整のようなレイヤーはAIの一次レビューと自動テストが通ればマージを許容する。すべてのレイヤーに同じ重みでレビューをかけようとすると、スタックにした意味が薄れてしまうからです。経験の浅いメンバーにも、「このレイヤーだけ見てほしい」と1層分を渡せば、どこから手をつけていいか迷わずレビューに参加してもらえます。

私たちの見解

スタック型プルリクエストがGitHub公式機能になったことは象徴的だと考えています。プルリクエストを分割するかどうかは、これまで個々のエンジニアの几帳面さに委ねられていました。それが今、AIエージェントが生成する変更量の増加という構造的な圧力によって、標準機能として実装されるところまで来たということです。

正直に言えば、私たち自身、この技術に名前がつく前から似たようなことをやってきました。名前がつくことで、チーム内での共有コストが一気に下がります。「これはスタックにして、このレイヤーだけ先にレビューして」と一言で伝えられるようになるからです。AIは壁打ち相手であり、判断は人間がする——この基本姿勢を、レイヤー単位まで具体化する技術として、私たちはスタック型プルリクエストを位置づけています。

---

📖 完全版はこちら → スタック型プルリクエスト——AIエージェントの大量生成物を、レビューできる単位に分割する技術

---

櫻井 文雄（さくらい ふみお） 株式会社AI-Path 代表取締役CEO。デロイト トーマツ コンサルティング（Big4）・ABEJA を経て、製造業を中心に延べ20社以上のDX・基幹システム刷新をPM／スクラムマスターとしてリード。FDE（フォワードデプロイドエンジニア）モデルでAI導入の「定着」を支援しています。