GitHubがAI生成の巨大PRを分割するスタック手法を公開

GitHubは2026年8月4日、公式ブログで、AIコーディングエージェントが生み出す巨大なプルリクエストをレビュー可能なスタック型プルリクエストへ分割する手法を公開しました。記事では買い物アシスタントに商品検索機能を追加する例を用い、1721行にふくらんだ一本の差分を、データ層からUI層まで4段の依存チェーンに組み替える流れを示しています。

背景にあるのはコーディングエージェントの生産性です。Gartnerはエージェントが2028年までにソフトウェア開発の各段階で50%の生産性向上をもたらすと予測していますが、従来の書き方を学習したエージェントは新しいデータモデルとシードデータ、APIルートと検証、クライアント接続とUIの状態処理までを一本の差分に詰め込みがちだと記事は指摘します。その結果、レビューは後回しにされ、査読者は文脈を失い、マージまでの時間が伸びていきます。

解決策の柱は分解です。例の実装では、型付きカタログとシードデータ、検証、データアクセスモジュールを最下層のfeat/catalog-dataに置き、その上に検証済みの検索APIエンドポイント、チャットとAPIの接続、商品引用カードとUI状態を順に積み上げています。層が分かれることで担当エージェントも査読者も分けられ、データはデータ責任者、UIはUI責任者が見る形に整理できます。

操作はgh stack系のコマンドに集約されます。CLI拡張はgh extension install github/gh-stackで導入し、エージェント側にはgh skill install github/gh-stackでスキルを読み込ませることで、gh stack addによる層の追加からgh stack push、gh stack submitでの一括提出まで任せられます。GitHub上では各プルリクエストの先頭にスタックマップが表示され、層の間を1クリックで移動できます。

レビューの作法も変わります。記事は上から読んで下から審査する進め方を勧めており、まず最上層で完成形の狙いをつかみ、次に最下層から順に依存を確認していきます。例では最下層でCopilot Code Reviewが2件の問題を検出し、修正を反映するとGitHubがスタックの再ベース必須を表示するため、gh stack rebaseとgh stack syncで上位層まで変更を連鎖させています。

ただし注意点もあります。ブラウザ上のRebase stackボタンはGitHubのサーバー側で処理されるため、コミッターがボタンを押した人に置き換わり、生成されるコミットに署名が付きません。署名付きコミットを求めるブランチ保護を設定している場合は、手元でgh stack rebaseを実行してからgh stack pushする方が安全だと記事は助言しています。