GitHubの「スタックプルリクエスト」がパブリックプレビューへ ― 大きな変更を独立レビュー可能に分割する新機能

大きな変更のプルリクエストを前に、レビュアーの手が止まる。かといって小さく分ければ、今度は下のブランチの修正に合わせたリベースが延々と続く——開発チームにはおなじみの二択です。GitHub は2026年7月30日、この二択を変える「スタックプルリクエスト(stacked pull requests)」をパブリックプレビューに移行したと発表しました。大きな変更を小さくレビュー可能な単位に分割し、依存関係の管理は GitHub に任せる。これがこの機能の要点で、全リポジトリへ段階的にロールアウトが進んでいます。

これまでの二択 ― 巨大PRか、手動リベースか

これまで大きな変更を扱うチームの選択肢は、実質二つしかありませんでした。一つは変更全体を一つの巨大なPRにまとめる方法で、負担はレビュアー側に寄ります。差分の全体像を一度に把握しなければならないからです。もう一つは変更を複数のブランチに分けて順に積み上げる方法で、今度は負担が開発者側に寄ります。下位のブランチに修正が入るたびに、上位のブランチを手動でリベースし続ける必要があるからです。

つまり「レビューの重さ」を引き受けるか、「追従作業の重さ」を引き受けるか——どちらに倒しても誰かが重さを背負う、対称形の二択でした。

第三の選択肢 ― スタックPRは何を変えるのか

スタックPRは、このどちらでもない第三の選択肢です。動きは時間の流れで追うと分かりやすくなります。まず、一つの大きな変更を順序付きの層に分割する。各層のPRは一つ下の層をターゲットブランチとして作られ、依存関係は GitHub が保つ。レビュアーは各層を個別に独立してレビューする。レビューが揃ったら、ワンクリックでスタック全体をマージする——この四段階です。

変更を層に分けてレビューしやすくする発想は、手動の複数ブランチ運用と同じです。違いが表れるのは、下の層に修正が入った瞬間です。これまでなら上の層を順番にリベースして回るところですが、その追従は GitHub 側の仕組みが引き受けます。では新しい運用ルールを覚え直す必要があるかというと、それもありません。既存のブランチ保護ルールやステータスチェックは、この構造でもそのまま機能します。

混同しやすい点 ― 「実装をどう分割するか」と「PRをどう積むか」は別の軸

実はこの「層」という言葉は、別の文脈でも紛らわしさを生みます。私たちは以前、AIエージェントに大きな実装タスクを任せる際の分解方針を見直したことがあります。タスクをDB→API→UIのようにシステムの層(アーキテクチャの水平方向)で区切ると、最終フェーズまで統合されたフィードバックが得られず、途中の設計ミスに気づけないまま作業が進んでしまう。設計ミスが見つかるのは、最後に全体をつないだ時——直すには一番手戻りの大きいタイミングです。この問題に直面した結果、私たちは水平の層構造をやめて、全体を薄く貫通する単位に分解し直しました。

スタックPRの「層」は、この水平分割とは別物です。スタックPRの層は一つの変更を時系列に積んだ依存チェーンであり、「何で分割するか」というアーキテクチャの話ではなく、「どの順番で積むか」という手順の話です。両者は「層」という言葉を共有していても矛盾しておらず、共通するのは「大きな変更をひとかたまりのまま進めると、検証やフィードバックが遅れる」という問題意識だけです。

ただし、今すぐ全面導入ではない

導入を検討する際は、実務判断の順で制約を確認するのが近道です。まず「そもそも使えるか」——この機能は全リポジトリへの段階的ロールアウト途上のパブリックプレビュー段階にあり、正式版に至るまでに仕様や挙動が変わる可能性があります。次に「既存運用と衝突しないか」——マージキューへの対応は発表時点で未完了です。GitHub は今後数週間で段階的にリリースする予定だとしていますが、マージキュー前提の運用をしているチームは、対応が揃うまで衝突の有無を確認する必要があります。

この二つを踏まえると、答えは「どこまで任せるか」の見極めになります。今の時点でチームの中核的なレビュー運用をこの機能に全面的に切り替えるのは時期尚早だと私たちは考えます。

まず1件だけ試す ― 検証手順と記録項目

判断材料は、待っているだけでは手に入りません。プレビュー段階の今のうちに、比較の記録を 1 件だけ作っておくのがおすすめです。

手順は三つです。まず、次に予定している変更の中から複数の関心事を含みそうなものを 1 件選びます(マージキュー運用中のリポジトリは、対応が揃うまで対象から外します)。次に、その変更を「各層が単独でレビューできるか」を基準に 2〜3 層に分割し、スタック PR として出します。最後に、直近の通常 PR と比べて記録します。計測項目は二つに固定すると迷いません——①レビューの往復回数、②下層に修正が入ったときの追従作業の有無、です。

この 1 件分の記録が、正式版で運用を広げるかを判断するときの、自チームの一次データになります。

まとめ

ここまでを整理します。大きな変更の扱いは、巨大PRか手動スタックかの二択から、スタックPRを加えた三択になりました。仕組みは「割って、積んで、層ごとに見る」の四段階。ただしマージキュー未対応のパブリックプレビュー段階なので、始め方は全面移行ではなく「まず 1 件」の検証です。

そのうえで、私たちの主張は一つです。スタックPRの価値を最終的に決めるのは GitHub の実装ではなく、自分たちの変更を「単独でレビューできる単位」に切り出せるかという、チーム側の設計力です。マージキュー対応が出そろうタイミングが、手元の 1 件分の記録をもとに適用範囲を見直す最初の判断点になります。 積み重ねた PR は、下段が変われば上段の「レビュー済み」が意味を失います。何をもって完了とするかを人の記憶でなく機械が判定できる形にしておく必要がある、という点は AI エージェントに作業を任せる時も同じで、私たちはそこで一度失敗しています(メンバーシップ ¥500/月)——「完了しました」が嘘になるとき — 判定できる完了条件の書き方。

出典:

• GitHub Changelog「Stacked pull requests are now in public preview」

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)