---
title: 'GitHubのStacked PRが正式提供：小さくレビューし、CIの重複を抑える設計'
url: 'https://automationse.net/github-stacked-pr-ga-ci-review-guide-2026'
markdown: 'https://automationse.net/github-stacked-pr-ga-ci-review-guide-2026.md'
date: '2026-10-10'
description: '<style> .sp-hero{padding:clamp(25px,5vw,46px);border-radius:22px;color:#fff;background:linear-gradient(125deg,#182638,#264f73 55%,#477aa3)}.sp-hero h2{color:#fff;margin:.35em 0}.sp-kicker{font-size:.79rem;font-weight:800;letter-spacing:.13em;color:#b7dbf2}.sp-grid{display:grid;grid-template-colu…'
taxonomy:
  category:
    - 開発・DevOps
  tag:
    - GitHub
    - 'Pull Request'
    - CI/CD
    - コードレビュー
---

# GitHubのStacked PRが正式提供：小さくレビューし、CIの重複を抑える設計

## [GitHubのStacked PRが正式提供：小さくレビューし、CIの重複を抑える設計](https://automationse.net/github-stacked-pr-ga-ci-review-guide-2026)

  公開日 2026.10.10 更新日 2026.10.10  [GitHub](https://automationse.net/tag:GitHub#body-wrapper) [Pull Request](https://automationse.net/tag:Pull%20Request#body-wrapper) [CI/CD](https://automationse.net/tag:CI/CD#body-wrapper) [コードレビュー](https://automationse.net/tag:%E3%82%B3%E3%83%BC%E3%83%89%E3%83%AC%E3%83%93%E3%83%A5%E3%83%BC#body-wrapper)  

 <style> .sp-hero{padding:clamp(25px,5vw,46px);border-radius:22px;color:#fff;background:linear-gradient(125deg,#182638,#264f73 55%,#477aa3)}.sp-hero h2{color:#fff;margin:.35em 0}.sp-kicker{font-size:.79rem;font-weight:800;letter-spacing:.13em;color:#b7dbf2}.sp-grid{display:grid;grid-template-columns:repeat(3,minmax(0,1fr));gap:12px;margin:20px 0}.sp-card{padding:18px;border:1px solid #c9dce9;border-radius:13px;background:#f0f6fa}.sp-card strong{display:block;color:#245479;font-size:1.2rem}.sp-stack{max-width:620px;margin:20px auto;padding:16px;border-radius:15px;background:#edf5fb}.sp-layer{padding:12px 16px;margin:7px;border-radius:9px;background:#fff;border-left:5px solid #4a80b0}.sp-layer b{color:#20517a}.sp-table{overflow-x:auto;margin:20px 0}.sp-table table{width:100%;min-width:550px;border-collapse:collapse}.sp-table th,.sp-table td{padding:11px;border:1px solid #c9dce9;text-align:left;vertical-align:top}.sp-table th{background:#e8f1f8}.sp-note{padding:17px 19px;margin:20px 0;border-left:5px solid #cb9954;border-radius:9px;background:#fff8ea}@media(max-width:760px){.sp-grid{grid-template-columns:1fr}} </style> DEVELOPMENT / REVIEW WORKFLOW

## 大きな変更を、依存関係ごとに分ける

GitHubのStacked PRが正式提供。レビューを小さくしても、CIとマージ順序の設計は必要だ。

## 3行で要約

- GitHubは**2026年10月6日**、複数の依存PRを一つの連鎖として扱う**Stacked pull requests**の一般提供を発表した。\[1\]
- 各PRは直下のブランチをbaseに持ち、差分を層ごとにレビューできる。GitHubはbase側の保護ルールとCIを各層へ適用し、下層から順にマージする。\[2\]
- CIはスタック内の**各PRで走る**ため、分割数に比例して実行量が増え得る。必須チェックを維持しつつ、重い任意ジョブの実行位置を設計したい。\[3\]

## 背景と、今回新しいこと

データベースのスキーマ変更、API、画面を一つの巨大なPRにすると、レビュー対象が広くなる。一方で依存する変更を別々のPRにすると、baseブランチの付け替えやリベースが面倒になる。Stacked PRは、前のPRを次のPRのbaseにする**依存チェーン**をGitHub上で扱う仕組みだ。\[2\]

GitHubの正式提供日は10月6日。本記事の公開は日本時間10月10日で、ニュースの発生日とは別である。直近の当サイトではGitLabのDependency FirewallやGitHubの非同期マージAPIを扱った。今回は**PRを分割してレビュー・CIを運用する方法**が主題で、機能や対象業務は異なる。

## 仕組み：下のPRに依存する上のPR

**3 / 画面** → base: APIブランチ

**2 / API** → base: スキーマブランチ

**1 / スキーマ** → base: main

**土台 / main**

各PRには、その層固有の差分だけが表示される。レビューと承認は層ごとに進められるが、依存関係は残るためマージは**下から上へ**。下層をマージすると、残る上層のブランチは自動でリベース・base変更される。GitHubはスタックの情報をPR画面で表示し、`Shift`+`J`/`Shift`+`K`で層を移動できるとしている。\[1\]\[2\]

**小さな差分**層ごとに独立してレビュー

**保護ルール**下層のbaseにある要件を各層へ適用

**自動リベース**下層マージ後に残りの層を更新

## 技術的なポイント：CIは各層で実行される

GitHubの説明では、スタック内の各PRはスタック全体のbase、たとえば`main`を対象とするかのようにGitHub Actionsのワークフローで評価される。これにより`main`向けの必須チェックは上層でも走る。一方、PRを3層にすれば同じ重いジョブが3回走り得る。**レビューしやすさとCI費用は別の指標**だ。\[2\]\[3\]

スタック運用で分けるCIの判断
| ジョブ | 実行方針の例 | 注意点 |
|---|---|---|
| 型検査・単体テストなど必須チェック | 各PRで維持 | 層ごとの品質条件を落とさない |
| 高コストの統合・性能試験 | 最上層や下から最初の未マージ層に限定を検討 | 対象外の層をマージしてよいか別途判断 |
| デプロイ | 変更の影響範囲と承認手順に応じて限定 | 上層は下層を含む状態であることを確認 |

ワークフローでは`github.event.pull_request.stack`にスタック情報が入り、`position`（1から始まる位置）と`size`（PR数）を参照できる。スタック外PRではこの値がないため、条件式では存在確認を先に入れる。公式文書には最上層だけを選ぶ条件例がある。必須チェックの省略がブランチ保護に影響する場合は、先にルールを確認する。\[3\]

## 導入手順：2層から試す

1. GitHub CLI **2.90.0以上**、Git **2.20以上**を確認し、プッシュ可能なテスト用リポジトリを用意する。`gh auth login`で認証し、`gh extension install github/gh-stack`で拡張を導入する。\[4\]
2. `gh stack init`で最初のブランチを作り、小さな土台変更をコミットする。次に`gh stack add BRANCH-NAME`で上層のブランチを作り、依存する変更をコミットする。\[4\]
3. `gh stack push`でブランチを送信し、`gh stack submit`でPRを作成・連結する。`gh stack view`で順序と状態を確認する。\[4\]
4. 最初は2層で、差分、必須チェック、承認の維持、下層マージ後のリベースを確認する。GitHubは正式提供時、変更のないコードへの承認維持や署名付きリベースコミットなどの改善を挙げたが、既存のルールセットとの組み合わせは実際のリポジトリで試したい。\[1\]

## 開発チームへの影響、リスクと限界

レビュー単位が小さくなると、土台変更と利用側の変更を担当者ごとに見やすくなる。ただし上層PRだけを見て土台の影響を見落とす危険もある。GitHubが示すプレビュー利用リポジトリのマージ量・時間の改善は**同社観測値**であり、スタック機能だけによる因果効果や全チームでの再現を保証しない。\[1\]

また同一リポジトリ内のブランチが前提で、forkをまたぐスタックやGitHub Desktopは対象外と公式文書にある。既存のCIやボットがPRのbaseを`main`と決め打ちしている場合、スタック情報への対応を確認したい。\[2\]\[3\]

今後はEnterprise Serverへの提供時期、自動マージのロールアウト完了、CI実行量とレビュー所要時間の実測を追う。最初から大きなスタックを作るより、2層でルールとCIの動きを検証する方が安全だ。

**最終確認日：2026年10月10日（日本時間）**

### 参照元

1. [GitHub Changelog：Stacked pull requests generally available](https://github.blog/changelog/2026-10-06-stacked-pull-requests-generally-available/) — 正式提供日と変更点。
2. [GitHub Docs：About stacked pull requests](https://docs.github.com/en/pull-requests/get-started/about-stacked-prs) — 依存関係、レビュー、ルール、制限。
3. [GitHub Docs：Optimizing CI for stacked pull requests](https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests) — CIの実行条件とメタデータ。
4. [GitHub Docs：Quickstart for stacked pull requests](https://docs.github.com/en/pull-requests/get-started/stacked-prs-quickstart) — CLIによる初期設定と作成手順。

  Previous Post Next Post

---

## Navigation

- Previous: [Claude Haiku 5.5は安いだけではない：10万トークン境界と小型モデルの使い分け](https://automationse.net/claude-haiku-55-cost-routing-evaluation-2026.md)