GitHubの積み重ねPRが一般提供に、全プランで利用可能

ニュースの概要

GitHubは2026年10月6日、「積み重ねプルリクエスト（Stacked pull requests）」を一般提供（GA）にしました。大きな変更を小さなプルリクエストに分け、それぞれ独立してレビューしながら、まとめてマージできる機能です。GitHubの変更履歴（Changelog）によると、github.com の全プランで利用できます。

チームで開発ツールを選ぶ担当者にとっては、GitHubを使い続ける価値や、レビューの運用を見直す材料になる更新です。

何が変わるのか

GitHubのChangelogが挙げる、GA時点の主な内容は次のとおりです。

• 提供範囲：github.com の全プランで利用可能。GitHub Enterprise Server には、今後のリリースで含まれる予定とされています。
• CLI：GitHub CLIの拡張機能 gh stack が、Git worktree に対応しました。初期化、チェックアウト、移動の動作も改善されています。
• 承認とリベース：コードに変更がないスタックをベースブランチに追従してリベースした場合、古い承認を取り消す設定のリポジトリでも承認が維持されます。リベース時、GitHubは元の作者情報を保った署名付きの置き換えコミットを作成します。
• マージ：バイパス権限を持つユーザーは、スタックの中で最も下位の未マージのプルリクエストをマージできます。マージコミット方式では、グループ単位ではなく、プルリクエストごとに1つのマージコミットが作られます。ベースブランチが削除されると、スタックは自動的に付け替えられます。スタックの自動マージ（auto-merge）は、以降の数週間で順次提供される予定です。
• 画面と自動化：プルリクエストのヘッダーにスタック情報が常時表示されます。Shift+J、Shift+Kで前後のプルリクエストへ移動できます。タイムラインには、プルリクエストがスタックに加わった・外れたことが表示され、pull_request のWebhookには stacked アクションが追加されます。

GitHubは、パブリックプレビュー開始以降、スタックを使うリポジトリは同種のリポジトリに比べてマージされたコードが9%多いと説明しています。また、利用上位1%のリポジトリの3分の2超がスタックを使っており、マージまでの時間が5%改善したとしています。これらはGitHub自身の集計で、第三者による検証ではない点には注意が必要です。

読者への影響

大きな機能追加や、複数のモジュールにまたがるリファクタリングを扱うチームでは、1つの巨大なプルリクエストになりがちです。巨大なプルリクエストは、レビューに時間がかかり、見落としも起きやすくなります。スタックでは、変更を段階に分けて、順にレビュー・マージできるため、レビューの負担を分散しやすくなります。

運用面では、次の点が関係します。

• レビュー運用：承認がリベース後も維持されるため、再レビューの手間が減る場面があります。
• ブランチ保護：バイパス権限の扱いが、スタックの最下位のプルリクエストのマージに影響します。保護ルールの設計を見直す価値があります。
• CI/CD・自動化：Webhookに stacked アクションが加わるため、自動化の処理が影響を受けないかを確認する必要があります。
• Enterprise Server利用組織：現時点では対象外で、今後のリリースを待つことになります。

確認しておきたいこと

1. 自社が使っているGitHubのプラン（github.com か Enterprise Server か）を確認する。
2. Webhookを受けて動く自動化（Slack通知、CI、チケット連携など）がある場合、stacked アクションの追加で動作が変わらないかを確認する。Webhookの基本はWebhookとはを参照してください。
3. ブランチ保護ルールとバイパス権限の設定を見直す。
4. CLIを使うチームは、gh stack の最新の動作をGitHubのドキュメントで確認する。
5. 連携にAPIキーなどを使っている場合の見直しは、APIキーとOAuthの違いも参考になります。

筆者の見解

私見では、積み重ねプルリクエストは「機能そのもの」より「レビューの文化を変えるきっかけ」として評価すべきだと考えます。小さく分けて出す習慣がチームになければ、機能を入れても使われないままになる可能性があります。導入するなら、1つのプルリクエストの目安の大きさや、レビューの順番をチームで決めておくのがよいと思います。

また、GitHubが示した9%・5%という数字は魅力的ですが、5%は利用の多い上位1%のリポジトリの数字で、集計の条件も公開情報から詳しく分からないため、自分のチームで同じ効果が出ると期待しすぎないほうがよいと考えます。まず小さなチームや1つのリポジトリで試し、レビュー時間やマージまでの日数の変化を、自分たちの数字で見るのが現実的です。

なお、自動マージ機能は、以降の数週間で順次提供される予定とされています。GAの時点で全員が使えるわけではない部分があるため、運用ルールを固めるのは機能がそろってからでも遅くないでしょう。

出典

• Stacked pull requests generally available（GitHub Changelog）
• GitHub Changelog（一覧）

2026年10月7日時点の情報です。