Overview
What stacked pull requests are, why they matter, and how GitHub supports them natively.
GitHub Stacked PRs

2026年4月14日、GitHubが「Stacked PRs」のプライベートプレビューを発表しました。大きなPRを小さな単位に分割し、順序立ててレビュー・マージできる仕組みです。

「コードを書くのはもはやボトルネックではない。レビューこそがボトルネックだ」。GitHub開発チームのSameen Karim氏はそう語ります。AIエージェントがコードを大量生成する時代、レビューの効率化は避けて通れない課題です。

この記事でわかること

  • Stacked PRsの仕組みと使い方
  • 大規模PRが招くレビュー品質低下の実態
  • CLIツール gh-stack の基本操作

大きなPRはなぜ問題なのか

Microsoft Researchが70万件以上のコードレビューを分析した結果、明確な傾向が見えています。

  • 小規模PR : レビュアーがメソッドの7%にコメントする
  • 大規模PR : コメント率は2〜3%に低下する
  • 1,000行超のPR : 放棄率が大幅に上昇する

約400行を超えるとマージ確率が非線形に下がります。人間が一度に把握できるコンテキストには限界があり、PRが大きくなるほどレビューの質は急落します。

開発者は往々にして、レビュー待ちの間に次の機能を実装し続けます。結果として、依存関係のある変更が1つの巨大なPRに積み上がり、レビュアーの負担はさらに増大します。

Stacked PRsとは何か

Stacked PRsは、PRを前のPRの上に積み重ねて「スタック」を構成する機能です。

具体的には、同一リポジトリ内で以下の構造を作ります。

main ← PR#1（データモデル追加） ← PR#2（APIエンドポイント実装） ← PR#3（UI実装）

各PRは独立してレビューできます。ただし、マージは下から順番に行います。PR#1がマージされれば、PR#2のベースが自動的に更新されます。

主な特徴

  • スタックマップUI : PRページ上部にスタック全体が視覚化され、各PRの状態確認と移動が可能
  • 自動リベース : 下層のPRがマージされると、上層のPRが自動でリベースされる
  • ブランチ保護の継承 : マージ要件はスタック最下部のベースブランチ（通常 main）の保護ルールが適用される
  • 3種のマージ方式 : マージコミット、スカッシュマージ、リベースマージに対応

CLIなしでUI上だけでも作成・管理できます。

CLIツール「gh-stack」の使い方

GitHub CLIの拡張として提供される gh-stack を使うと、スタックの管理を効率化できます。

インストール

gh extension install github/gh-stack

基本ワークフロー

1. スタックを開始する

gh stack init

最初のブランチが作成され、チェックアウトされます。

2. コードを書いてコミットする

git add .
git commit -m "データモデルを追加"

3. 次のレイヤーを追加する

gh stack add api-endpoints

新しいブランチが作成され、前のブランチの上に積まれます。この操作を繰り返してスタックを構築します。

4. PRをまとめて作成する

gh stack submit

スタック内の全ブランチをリモートにプッシュし、PRを一括作成します。GitHub上でスタックとして自動的にリンクされます。

主要コマンド一覧

コマンド 説明
gh stack init スタックを開始する
gh stack add <名前> レイヤーを追加する
gh stack submit PRを一括作成・更新する
gh stack push ブランチのみプッシュする（PRは作成しない）
gh stack rebase スタック全体をカスケードリベースする
gh stack sync fetch・rebase・push・PR同期をまとめて実行する
gh stack up / down スタック内で上下に移動する
gh stack top / bottom スタックの最上部・最下部に移動する

gh stack push は --force-with-lease を使用するため、他の人の変更を上書きするリスクを抑えられます。

歴史的背景｜MetaやGoogleでは10年以上前から実践

スタック型のコードレビューは新しい概念ではありません。

  • 2007年 : Facebook（現Meta）のエンジニアEvan Priestley氏が「Differential」を開発。「コードレビュー待ちに多くの時間を費やしていた」ことが動機
  • 2011年 : DifferentialはPhabricatorの一部としてオープンソース化
  • 2017年 : Metaが「ghstack」をオープンソースとして公開

Google、Meta、Uberなどの大手テック企業は10年以上にわたり、社内ツールでスタック型レビューを運用してきました。GitHubのStacked PRsは、この手法をGitHubネイティブの体験として提供するものです。

注意点

Stacked PRsには考慮すべき点もあります。

  • リベース競合の連鎖 : 最下層のPRでコンフリクトが発生すると、上層すべてに波及する可能性がある
  • 事前の設計が必要 : 「3日間書いてから後でPRを分ける」やり方は通用しない。作業前に分割方針を決める必要がある
  • 習慣の変更 : レビュアーにとってもスタックの読み方を覚える学習コストがある

自動リベース機能がこれらの負担を軽減しますが、完全には解消できません。

現在のステータスと利用方法

Stacked PRsは現在プライベートプレビュー段階です。利用するにはウェイトリストへの登録が必要です。

  • ウェイトリスト: gh.io/stacksbeta
  • 公式ドキュメント: github.github.com/gh-stack

CLIやスタック機能は、リポジトリで機能が有効化されるまで使用できません。

まとめ

Stacked PRsは「大きなPRを出すしかない」という状況を根本から変える機能です。AIによるコード生成が加速する中、レビュー効率の改善は開発チーム全体の生産性に直結します。

プライベートプレビューの段階ではありますが、ウェイトリストに登録して早めに試す価値はあります。特に、モノレポで大規模なリファクタリングを頻繁に行うチームにとっては、レビューのボトルネック解消に大きく貢献するはずです。