8月5日、startuphub.aiが「GitHub's Stacked PRs Tackle AI Code Bloat」と題した記事を公開した。この記事では、AIが生成する巨大なプルリクエスト問題をGitHubのStacked PRs機能で分割・整理するワークフローについて詳しく紹介されている。
AIが生み出す「巨大PR問題」
AIコーディングアシスタントの普及に伴い、開発現場では新たな悩みが生まれている。AIに複雑な機能の実装を依頼すると、数分後には1,000行超のコードを含む単一のプルリクエストが届く——データモデル、APIルート、クライアント処理、UIコンポーネント、エラーハンドリングがすべて一塊になった状態で。
AIが生成するコードがモノリシックになりやすい背景として、元記事では「AIモデルは機能単位で完結したコードを一括出力する傾向がある」と指摘している。これはAIが「動くコードを出す」ことを優先した結果であり、人間のレビューしやすさとは必ずしも一致しない。※ただし、この傾向はモデルやプロンプト設計によっても大きく変わりうるため、すべてのAIツールに一律に当てはまるわけではない点には留意が必要だ。
レビュワーはコードの量に圧倒され、マージは遅延し、コード品質も下がる。AIによる開発速度の向上が、レビュープロセスというボトルネックで相殺されてしまうという構図だ。
GitHubはこの問題に対処するため、Stacked Pull Requests（スタック型PR）機能を提供している。
Stacked PRsとは何か・いつから使えるか
Stacked PRsとは、大きな変更を論理的な単位に分割し、依存関係を持つ複数のPRとして積み重ねる手法だ。PRをスタック（積み重ね）として管理することで、レビュワーは一度に小さく、文脈が明確な変更だけを見ればよくなる。
元記事の公開時点（2026年8月）における提供状況について、元記事では詳細なプラン制限やベータ／GA状況が明記されていない。GitHubの公式情報についてはGitHub DocsやGitHub Changelogで最新の提供状況を確認することを推奨する。利用を検討しているチームは、使用中のプランで機能が有効になっているかをGitHubの設定画面で事前に確認していただきたい。
GitHubが示す具体例として、ECサイトへの商品検索機能追加が挙げられている。この変更を単一PRで出すのではなく、以下のように分割する：
- データモデルの変更（検索インデックス用スキーマ）
- APIルートの追加
- クライアント側の接続処理
- UIコンポーネントの実装
- エラーハンドリング
各PRは前のPRに依存する形でスタックされる。レビュワーはスタックの底から順番にレビューでき、変更の意図と文脈が追いやすくなる。
AIエージェントとの組み合わせが本題
この記事が特に強調しているのは、「人間がStacked PRsを使う」ではなく、「AIエージェントにStacked PRsを生成させる」という点だ。
GitHubのブログ記事（Turn one giant AI-generated pull request to a reviewable stack）では、AIエージェントへのプロンプトを工夫することで、最初から分割されたPRスタックとして出力させるアプローチが紹介されている。
元記事が紹介するプロンプト設計の基本的な考え方は、「実装前に変更を論理単位に分解させ、各単位を個別PRとして作成させる」という二段階の指示だ。具体的には以下のような構成が有効とされている：
- 「まず、この機能追加をレビュー可能な論理的な単位に分解し、各ステップを列挙してください」
- 「次に、各ステップについて独立したブランチとPRを作成し、前のPRをベースブランチとして設定してください」
AIが生成するコードの品質そのものは変わらなくても、レビュー可能な形に整形する責任をAI自身に持たせるという発想の転換だ。プロンプトの段階で分割粒度を指示しておくことで、後工程の手戻りを減らせる。
実際の運用上のポイント
Stacked PRsを実際に機能させるには、いくつかの前提と注意点がある。
- ブランチ戦略の設計が必要。各PRが正しいベースブランチを向いていないとスタックが崩れる
- スタックの途中のPRに変更が入ると、下流のPRすべてにrebaseが波及するため、ブランチ管理のコストが増す。これを軽減するには、スタックの上流ほど変更が安定している（レビュー済みである）状態を保つことが重要だ。GitHubのUIでスタックの依存関係が可視化されているため、どのPRが未レビューかは把握しやすい
- スタックが深くなるほど、rebaseの連鎖が発生しやすくなる。実運用ではスタックの深さを5前後に抑えるのが現実的とされている（※編集部の考察）
- GitHubのUI上では、スタックの依存関係が可視化されるため、レビュワーはどのPRから見ればよいかが一目でわかる
この種の「PRを積み重ねる」手法自体は以前から存在しており、Graphiteなどのサードパーティツールが先行して提供してきた。GitHubがネイティブ機能として取り込んだことで、外部ツールなしで同様のワークフローが実現できるようになった。
まとめ：有効な手段だが、運用設計が前提
AI生成コードの「巨大PR問題」は、AIの能力が上がるほど深刻になる構造的な課題だ。Stacked PRsはその解決策の一つとして、変更の分割とレビューの効率化を両立する可能性を持つ。特にAIエージェントに分割PRを生成させるプロンプト設計という視点は、AIコーディングを本番ワークフローに組み込もうとしているチームにとって実用的な知見だ。
ただし、rebaseの波及やブランチ管理のオーバーヘッドも伴う。「導入すれば即解決」というよりは、チームのブランチ運用ルールとセットで設計することが、この機能を活かす前提条件になる。
詳細はGitHub's Stacked PRs Tackle AI Code Bloatを参照していただきたい。
