GitHub Stacked PR（スタック型プルリクエスト）は、大きな変更を順序付きの層（layer）に分け、層ごとにレビューとチェックを回すための仕組みです。2026年7月30日に public preview として公開されました。
📑目次
製品としてまとまっている主な点:
- 1本・一部・全体のマージ
- 未マージ上位層の自動リベース／retarget
この記事ではまず、層・base・stack map のつながりを一本道で押さえます。そのうえで、AIエージェントの並列実装で差分が肥大化しやすい今、レビュー可能な単位へ落とす判断基準を、公式仕様と独立ハンズオンから整理します。
Stacked PRとは何か — 層・base・stack map
定義と base の置き方
結論から言うと、Stacked PR は同一リポジトリ内の順序付き PR チェーンです。層（layer）・base・stack map はこの順でつながります。
- 最下層は trunk（通常は main）を base にする
- 後続の PR は直下ブランチを base にする
- 各 PR は当該レイヤの差分だけを見せる
レビューは「全部まとめて1枚」ではなく「層ごとの focused diff」になります。base が直下レイヤを指すことで、上位 PR は下位の未マージ実装に乗れます。stack map は、この base チェーン全体を Web 上で俯瞰する地図です。
層を読むときの1分チェック
定義と base チェーンを押さえたら、次の4点だけを確認します。
- この PR の base は trunk（通常 main）か、直下レイヤのブランチか
- 表示 diff は当該レイヤだけか（下位実装や無関係ファイルが混ざっていないか）
- 依存は同じ層／下位に閉じているか（上位→下位の逆依存や循環がないか）
- ローカルの層順と Web の stack map が一致しているか
手元では先に gh stack view で層順を確認し、Web の stack map と突き合わせると、このあとの init / add / submit や AI 差分の分割パターンが追いやすくなります。
依存・UI・保護の要点
依存は同じ層か下位ブランチに置くのが原則です。上位層は下位の未マージ実装に乗れます。
次のような分割は、層が名目だけになります。
- 循環依存
- 「全部を UI 層に押し込む」分割
Web UI と保護まわりの要点は次です。
- スタック番号アイコンと merge box のスタックマップで層を俯瞰できる
- ブランチ保護と checks はミッドスタック PR にも最下層 base 基準で適用される整理が公式ドキュメントにある
- クロスフォークは非対応
- public preview のため、UI 文言や CLI サブコマンドは時点付きで扱う
一次情報
なぜ今か — AIエージェント時代のレビューボトルネック
巨大 PR が増える理由
エージェントの生産性が上がるほど、1000行を超える巨大 PR が増えやすくなります。
- 差分の生成は速い
- レビュー品質と CI の見通しは人間側に残る
- 手作業で PR を割ると、base の付け替え・rebase の連鎖・部分マージ後の整合確認が重い
Stacked PR が約束すること
Stacked PR が約束するのは次の三点です。
- 層ごとの focused diff
- 下位マージ後の自動カスケードリベース
- 1本／一部／全体マージ
既存の reviews・checks・merge requirements を維持したまま分解できる点が、サードパーティのスタッキング運用と並べて評価するときの軸になります。merge queue 対応は Changelog 時点で段階展開とされています。
AI 文脈での位置づけ
GitHub Engineering は、巨大な AI 生成 PR を依存順スタックへ落とす設計例として、次の縦割りを示しています。
- catalog-data
- search-api
- chat-grounding
- grounded-ui
業界報道側でも、AI 生成でレビューがボトルネックになる問題への対応として native stacking が位置づけられています。
出典:
使い方 — Web UI と gh stack CLI / skill
入口の選び方
作業場所が Web 中心かローカル／エージェント中心かで入口は分かれます。
- Web: Preview stack / Create stack から始められる
- ローカル: GitHub CLI 拡張が中心
gh extension install github/gh-stack
# エージェント向け（環境により）
gh skill install github/gh-stack
Copilot チュートリアルは gh 2.90.0 以上、拡張と skill の導入、Copilot CLI を前提に記載しています。バージョンは導入前に手元で確認してください。
基本フロー（CLI）
gh stack initで最下層ブランチ／スタックを開始する（既存ブランチ取り込みも可能な場合があります）- 実装後に
gh stack addで上層を追加する gh stack viewでローカル状態を確認するgh stack submitで push・PR 作成・base 更新・GitHub 上のスタック作成を行う（--autoで複数 PR を一括作成するデモもあります）gh stack syncで fetch / rebase / push の整合を取る（--pruneでマージ済みローカル削除の説明があります）gh stack mergeで指定 PR とその下をまとめてマージできる整理があります
編集・レビュー・マージ
編集系コマンド:
- modify
- rebase
- link
- fold
- drop
順序の入れ替えや層の挿入を検証したハンズオンもあります。
レビューと修正の型:
- read top-down / review bottom-up
- 修正は該当層に commit する
- upstack を rebase する
マージの型:
- マージは下から行う
- 部分マージ後は未マージ上位が自動で retarget / rebase される
出典:
AIエージェント並列実装をスタックに載せる分割パターン
先に依存グラフを書く
エージェント出力をそのまま1本の巨大 PR に載せると、レビュー観点が混ざります。
先に依存グラフを書き、層の契約を決めてから生成・レビューする方が公式チュートリアルの意図に沿います。
分割の判断基準
- ビルド／型／契約が下位に閉じるか
- 上位だけをリバートしても下位が意味を持つか
- CI が stack base に対して層単体で意味ある失敗を返すか
- レビュー観点（データ／API／UI／配線）が層で分離できるか
レイヤ例と読者側の翻訳
公式のレイヤ例:
- L1 catalog-data
- L2 search-api
- L3 chat-grounding
- L4 grounded-ui
読者側の翻訳例:
- schema → API → wiring → UI
Issue 単位や worktree 並列で作った差分を、後から依存順の直列スタックへ載せ替える発想が使えます。社内固有手順の丸写しより、依存グラフを先に書くことが本体です。
エージェント運用と失敗しやすい点
エージェント運用の例:
- gh-stack skill で状態確認や init/add/submit の手順を読ませる
- 自然言語でスタック操作させる
失敗しやすい点:
- 循環依存
- 層名だけの分割
- 下位未レビューのまま上位だけを急ぐ
- 保護ルール・CODEOWNERS・必須チェックの未整備
比較表と導入チェックリスト
| 観点 | 巨大1PR | 手分割PR | GitHub Stacked PR（preview） |
|---|---|---|---|
| 差分の見え方 | 全変更が一枚 | 分割できるが base 管理が手動 | 層ごとに focused diff + stack map |
| 依存の表現 | 暗黙 | ブランチ命名と説明頼み | 順序付き base チェーン |
| マージ | 一括 or 危険な部分適用 | 下から手で retarget | 1本/一部/全体 + 自動 rebase/retarget |
| CI / 保護 | 1回の巨大チェック | バラバラに設定しがち | ミッドスタックにも保護/checks 適用の公式整理 |
| AIエージェント適合 | 出力をそのまま載せやすいがレビュー破綻 | 後処理が重い | skill/CLI で層化を手順化できる |
| 主なコスト | レビュー負荷 | 運用ミス | preview 習熟・分割設計・ツール更新 |
出典: GitHub Docs / Changelog / Engineering、Classmethod、gihyo.jp、DevOps.com を横断した運用翻訳（2026年8月時点）
導入前チェックリスト
導入前に、次を staging で1回通してください。
- 直近の巨大 PR またはエージェント出力を1件選び、依存順レイヤ案（例: schema → API → wiring → UI）を4行以内で書く
- 本番ブランチ以外で
gh extension install github/gh-stackを試し、sample stack で init → add → submit まで通す - branch protection / required checks / CODEOWNERS がミッドスタック PR でどう見えるか stack map 上で確認する
- 部分マージ（下位だけ）後に上位が自動 retarget されることを観察する
- エージェントを使うなら
gh skill install github/gh-stackと「層の定義を先に書かせる」プロンプトをテンプレ化する - チーム規約に review bottom-up、修正は該当層へ、循環依存禁止 を1ページで追加する
- preview 変更に備え、Changelog / Docs の CLI 差分を定期確認する担当を決める
向き不向き
向くケース:
- 依存が明確な縦割り機能
- AI並列でファイル衝突が少ない分割
- レビュー観点を層で分けたい中〜大規模変更
向かないケース:
- 全層を同時に公開しないと意味がない切替
- フォーク運用
- trunk 戦略自体が定まっていない超小型リポジトリ
導入コストが分割利益を上回るなら、無理に本番へ広げない判断も合理的です。
関連記事:
- Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
- MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計
- エージェント向け検索の設計｜どう探させ、何を返すか
よくある質問（FAQ）
Q1. Stacked PR とただの依存ブランチ運用は何が違うのか？
どちらもブランチを積む点は似ます。GitHub native では次が製品機能としてまとまっています。
- stack map
- 層単位 diff
- 部分／全体マージと自動 rebase/retarget
- ミッドスタックへの保護/checks 適用
Q2. gh stack は必須か？ Web だけでもよいか？
Web の Create stack でも始められます。ローカルでの層追加・同期・エージェント連携は CLI / skill が中心です。チームの作業場所に合わせて選んでください。
Q3. AIエージェントの出力をそのまま1スタックにしてよいか？
まず依存順レイヤを設計し、層ごとに生成・レビューする方が公式チュートリアルの意図に沿います。巨大1差分を後から無理に切るより、最初から層の契約を決める方が安全です。
Q4. 途中の層だけ先にマージできるか？
マージは基本的に下からです。下位をマージすると上位が自動で追従します。中間だけを飛ばしてマージする前提では設計しないでください。
Q5. 既存の長い feature ブランチを後からスタックにできるか？
既存ブランチの init 取り込みや modify による順序変更に言及したハンズオンがあります。履歴の切り方次第で衝突するため、重要な系列は小さい検証リポジトリで手順確認してからにしてください。
Q6. public preview で本番に使ってよいか？
公式は preview です。保護や merge queue の段階展開もあります。重要な monorepo では staging で partial merge と required checks を検証し、チーム合意のうえ段階導入してください。
Q7. Graphite 等の外部スタッキングツールとの関係は？
既に外部ツールで運用している場合は、native 移行のメリット（保護との一体運用、skill/CLI）と移行コストを比較して決めてください。本記事は特定ベンダーを推奨しません。
まとめ — 今日の判断と次の一手
Stacked PR は「PR を小さくするテクニック」だけではありません。依存順のレビュー単位を GitHub 上の一等市民にする仕組みです。
AIエージェント時代の本体は次です。
- 分割設計
- bottom-up レビュー
CLI と skill は、それを手作業で崩さないための手段です。
最短の次アクション:
- 今週中に sample リポジトリで init / add / submit と partial merge を1回通す
- 自チームの保護ルールとの相性を見る
避けたいこと:
- 人気記事や一社ブログの手順だけで monorepo 全適用すること
裏取りの優先順位:
- 一次は GitHub 公式
- 二次は Classmethod / gihyo / Ubie / DevOps.com
最終的な権限・リリース方針は各チームで決めてください。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す