GitHub Stacked PRs GAの変更点と使い方（2026年10月6日）

AI開発ツールアップデート料金改定GitHubPull Request開発生産性

GitHub の Stacked pull requests が一般提供（GA）になりました。大きな変更を小さく分割してレビュー・マージできる機能で、GA に伴い Rebase 時の承認保持、署名付きコミットの維持、マージキューとの整合、ブランチ自動リターゲット、gh stack 拡張の worktree 対応などが追加されています。

結論から言うと、GitHub の Stacked pull requests（スタック型の Pull Request）は 2026年10月6日に一般提供（GA）になりました。大きな変更を、レビュー単位で小さく分割した PR の列として扱い、独立にレビューして一緒にマージできる機能です（GitHub Changelog、2026年10月6日）。GA に伴い、Rebase やマージキュー、CLI 操作の面で複数の改善が入っています。以下、GA の内容と開発者に効く変更を、公式発表の記載だけで解説します。

Stacked pull requests とは

Stacked pull requests は、大きな変更を小さな、焦点の絞られた PR に分割し、独立にレビューして一緒にマージできる GitHub の機能です（GitHub Changelog、2026年10月6日）。

• public preview の期間中、stack を使ったリポジトリでは、同僚と比べてマージされたコードが 9% 増えた、と GitHub は発表しています。
• 上位 1% のリポジトリの 3 分の 2 以上が stacked pull requests を使っており、time-to-merge（マージまでの時間）が 5% 改善したとしています。

GA の発表にあわせて、stack を作りやすく、レビューしやすく、マージしやすくする改善が複数公開されています（GitHub Changelog、2026年10月6日）。

GA で入った主な変更

GitHub が 2026年10月6日に GA とあわせて公表した主な改善は次のとおりです（GitHub Changelog、2026年10月6日）。

マージと Rebase の柔軟化

• 変更のないコードの承認は保持されます。base ブランチ（例: main）が進んだ後で stack を更新しても、承認の有効期限を失効させるリポジトリでも Rebase stack は承認を保ちます。
• Rebase stack の際に GitHub が署名付きの置換コミットを作り、元の authorship と署名を維持します。部分マージ後の自動 Rebase も、ブランチルールが署名を要求する場合や元コミットが署名済みの場合に署名付きで置換します。
• リポジトリルールの bypass 権限を持つユーザーは、その権限を使って stack 内の最下位の未マージ PR をマージできます。
• stack は merge queue を 1 つの merge group として通過し、merge commit 方式ではグループ一括ではなく PR ごとに 1 つの merge commit が作られます。
• stack の base ブランチが削除された場合、最下位 PR を閉じる代わりに stack全体が自動的にリターゲットされます。1 つの stack から別の stack が枝分かれするワークフローを想定しています。
• stack 用の auto-merge は今後数週間で展開されます。マージ要件を満たした時点で、選択した PR 群が一緒に自動マージされます。

ナビゲーションと自動化

• PR ページの固定ヘッダーに stack 情報が常時表示され、PR 一覧のビューからも属する stack を確認できます。
• Shift + J / Shift + K で stack 内の PR 間をキーボード操作できます。
• PR が stack に追加・削除されたイベントがタイムラインに表示されます。pull_request webhook には、PR が stack に入ったときの stacked アクションが含まれます。
• GitHub CLI 向けの gh stack 拡張は Git worktree に対応し、初期化・チェックアウト・ナビゲーションの速度改善が入っています。

開発者に求められる対応

対象は、大きな変更を複数 PR に分割してレビューする開発者と、チームで PR を管理するリポジトリです（GitHub Changelog、2026年10月6日）。

• stacked pull requests を使う場合、PR を stack として並べて操作するか、gh stack 拡張や PR ヘッダーの stack 情報を確認してください。
• 承認保持・署名付き Rebase・マージキュー単位のマージを確認したい場合は、リポジトリのブランチルールと merge queue 設定を GA 時の挙動に合わせてください。
• stack の auto-merge は今後数週間で展開されます。提供状況は GitHub の発表を確認してください。
• ワークツリー操作を gh stack で行う場合は、対応する拡張のバージョンを更新してください。

よくある質問

Q. Stacked pull requests の GA で何が新しくなりましたか？

変更のないコードの承認保持、署名付きコミットの維持、bypass 権限による stack マージ、merge queue を 1 グループとして通過、base ブランチ削除時の自動リターゲット、stack ヘッダー表示とキーボードナビゲーション、gh stack の worktree 対応などが、2026年10月6日の GA 発表で公表されています（GitHub Changelog、2026年10月6日）。

Q. preview の期間中、stack にはどんな効果があったのですか？

GitHub の発表では、stack を使ったリポジトリは同僚と比べてマージされたコードが 9% 増え、上位 1% のリポジトリの 3 分の 2 以上が stack を使って time-to-merge が 5% 改善したとしています（GitHub Changelog、2026年10月6日）。

Q. stack の auto-merge はいつ使えますか？

stack の auto-merge は GA 発表時点で「今後数週間で展開」とされており、マージ要件を満たした PR 群を一括で自動マージできるようにする予定です（GitHub Changelog、2026年10月6日）。

出典: GitHub Changelog「Stacked pull requests generally available」（https://github.blog/changelog/2026-10-06-stacked-pull-requests-generally-available・2026-10-06 発表・2026-10-08 取得） に基づきます。

この記事で解説した内容について、導入や運用の設計で相談したいことがあればお問い合わせ（/contact）からどうぞ。

この記事は AI が一次ソースを読んで執筆しました。数値と日付は出典に記した公式情報の執筆時点の値です。誤りを見つけたら訂正の窓口へお知らせください。確認のうえ本文を直し、訂正履歴に残します。編集方針