GitHub Stacked PRs が公開プレビュー — gh stack の仕組みと、Graphiteから乗り換えるべきかの判断軸
はじめに
2026年7月30日、GitHub が Stacked Pull Requests を公開プレビューとして全リポジトリに展開開始した。4月13日の招待制プライベートプレビューから約3か月半、待機リスト不要で誰でも試せる段階に入ったことになる。Hacker News のスレッドは516ポイント・282コメントに達し、賛否が割れた。
「積み重ねPR」は Meta や Google のような大規模組織、あるいは Graphite・Aviator といったサードパーティ製品を導入したチームだけのものだった。それが GitHub 本体の標準機能になる。本記事では、この機能が実際に何を解決するのか、gh stack の具体的な操作モデル、そして見落とされがちな CI コストの罠と移行判断の軸を整理する。
Stacked PRs とは何か — 「baseをmainにしない」という一点
通常の PR は main を base にする。Stacked PRs では、1本目だけが main を base にし、2本目は1本目のブランチ、3本目は2本目のブランチ……と下から積み上げる。公式ドキュメントの用語では、この連鎖全体が「スタック」、個々の PR が「レイヤー」、最下段が向く先が「トランク」だ。
なぜこれが効くのか。GitHub 自身は「巨大な PR はレビューしづらく、マージが遅く、コンフリクトを起こしやすい。レビュアーはコンテキストを失い、フィードバックの質が落ち、チーム全体が減速する」と説明している。Microsoft の研究では、変更行数がおよそ200行を超えるとレビュー品質が急激に劣化するという結果も知られている。
従来、この問題への答えは「PR を小さく分ける」だったが、実際には分けられなかった。機能Aの土台となるリファクタリングが未マージのままでは、機能Aの PR を出しても差分にリファクタリング分が混ざってしまうからだ。結果、開発者は「レビュー待ちでブロックされる」か「全部入りの巨大 PR を出す」かの二択を迫られていた。
Stacked PRs は第三の道を提供する。土台の PR がレビュー中でも、その上に次のレイヤーを積んで作業を継続できる。レビュアー側には各レイヤー固有の差分だけが表示され、PR ヘッダーには「スタックナビゲータ」が出て、スタック内の全 PR を行き来できる。
gh stack の操作モデルと、自動リベースの正体
利用は CLI 拡張のインストールから始まる。
gh extension install github/gh-stack主要コマンドは以下の通り。
| コマンド | 役割 |
|---|---|
gh stack init | ブランチを依存順にトラッキング開始 |
gh stack add | スタックに新しいレイヤーを追加 |
gh stack submit | 全ブランチをpushし、PRを作成・リンク |
gh stack sync | fetch → rebase → push → PR状態更新を一括実行 |
gh stack rebase | 変更をスタック上方へカスケード（squash mergeにも対応） |
gh stack up/down/top/bottom | ブランチ名を覚えずにレイヤー間を移動 |
gh stack modify | レイヤーの削除・統合・挿入・並べ替え |
gh stack checkout | GitHub上のスタックをまるごとローカルに取得 |
技術的に最も重要なのは sync と rebase だ。スタック運用の最大の苦痛は、下段の PR にレビュー指摘が入って修正するたび、その上のブランチを全部手作業でリベースし直すことにあった。しかも force push はレビューの差分表示を壊す。Graphite や git-branchless が価値を持っていたのは、まさにこの再スタック（restack）を自動化していたからだ。GitHub はそれを本体側に取り込んだ。
マージ挙動も明確に定義されている。どの PR をマージしても、それより下の未マージ PR がすべて下から順に一緒にマージされる。上位レイヤーだけを先にマージすることはできない。マージ後、残った上位レイヤーは自動でリベース・リターゲットされる。ブランチ保護ルールや必須チェックはそのまま適用される。
ちなみに git --update-refs（Git 2.38以降）でも依存ブランチの追従は部分的に可能だが、これは手元の ref を更新するだけで、PR の base 付け替えやレビュー状態の同期まではやってくれない。そこが CLI 拡張との差だ。
エンジニアへの影響 — AIエージェント時代の必然と、CIコストの罠
この機能が2026年のこのタイミングで来た背景には、レビューがボトルネックになったという構造変化がある。AI コーディングエージェントの普及で生成速度は跳ね上がったが、人間のレビュー帯域は変わっていない。Codex 系の解説記事は「ボトルネックは生成からレビューへ移った。これはまさに Stacked PRs が扱う問題だ」と指摘し、コーディネータ役のエージェントがタスクを順序付きサブタスクに分解し、1ウェーブ＝1レイヤーとして積むオーケストレーションパターンを提案している。並列で作り、下から順にマージする、という形だ。実際 Vercel の Tim Neutkens 氏は「Next.js で数か月使っている。大きな機能を出しつつ個々の変更を小さくできる」とコメントしている。
一方、Hacker News で挙がった懐疑論は無視できない。最大の論点は CI コストだ。1本で済んだ PR が3本や5本になれば、それぞれがレビューを必要とし、それぞれが CI を回す。さらに悪いことに、下段をリベースすると論理的な差分が一切変わっていない上位レイヤーまで CI が再実行される。CI 課金がジョブ時間従量のチーム（GitHub Actions のコスト削減が今日のダイジェストにも上がっている通り）では、これは実費として跳ね返る。
マージキュー対応は「今後数週間かけて段階的に展開」とされており、公開プレビュー開始時点では全リポジトリで使えるわけではない。キュー投入時はスタックごと入り、下から順に個別評価され、途中で失敗した PR とその子孫だけがキューから追い出される設計になっている。
実務的な導入判断はこう整理できる。すでに Graphite や ghstack、spr を使っているチームは、機能面（自動リベース、マージ順序制御）が本体側に来たのでロックイン解消のメリットはあるが、マージキュー対応の完了を待つ価値がある。スタック運用をしたことがないチームは、まず「200行超の PR が常態化している」「レビュー待ちで手が止まる」という症状があるかを確認したい。症状がないのに導入すると、PR 本数とCI費用だけが増える。
まとめ
- GitHub が Stacked Pull Requests を公開プレビューで全リポジトリに展開（2026/7/30）
- 各 PR が「1つ下のブランチ」を base にすることで、レビュー待ちにブロックされず作業を継続できる
gh extension install github/gh-stackで導入。sync/rebaseによる自動再スタックが最大の価値- マージは常に下から。任意レイヤーのマージで下位も同時にマージされ、上位は自動リターゲット
- 懸念は CI コストの増加と、マージキュー対応が段階展開中である点
サードパーティが埋めていた穴をプラットフォーム本体が塞ぐ、という典型的な展開だ。ただし Graphite 側は Web UI やレビュー体験の作り込みで先行しており、単純な置き換えにはならない。まずは1つのリポジトリで、2〜3レイヤーの小さなスタックを試して CI 実行回数の実測を取るところから始めるのが妥当だろう。