TITLE

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

投稿日：2026.07.30

スタックPRとは何か ― 層構造のPRを独立してレビューする

スタックPRは、一つの大きな変更を「順序付けられた層構造のPR」に分割する仕組みです。各層(PR)は自分の一つ下の層をターゲットブランチとして作られ、上に乗る変更ほど下の変更に依存します。この層構造そのものは複数ブランチによるリレー的な開発でも再現できますが、スタックPRの特徴は各層を個別に独立してレビューできる点と、レビューが揃った段階で「ワンクリックでスタック全体をマージ」できる点にあります。既存のブランチ保護ルールやステータスチェックはこの構造でもそのまま機能するため、レビュー運用のルール自体を作り直す必要はありません。

既存ワークフローとの違い ― 巨大PRか、手動リベースか

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

スタックPRは、この二択のどちらでもない第三の選択肢です。変更を層に分けてレビューしやすくする発想は手動の複数ブランチ運用と同じですが、依存関係の維持とマージの実行をGitHub側の仕組みに任せられる点が異なります。レビュアー側から見ると、小さな層を一つずつ確認できる分だけ差分把握の負担は小さくなり、開発者側から見ると、手動リベースの追従作業が軽くなるという二つの効果が同時に得られる設計です。

現状の制約 ― マージキュー未対応、段階的ロールアウト中

この機能を検討する際に押さえておくべき制約が二つあります。一つは、マージキューへの対応がまだ完了していないことです。GitHub はマージキュー対応を今後数週間で段階的にリリースする予定だとしていますが、発表時点では未対応です。マージキューを前提にした運用をしているチームは、この対応が揃うまで既存の運用と衝突しないかを確認する必要があります。

もう一つは、この機能自体が全リポジトリへの段階的ロールアウトの途上にあるパブリックプレビュー段階だということです。プレビュー段階の機能は、正式版に至るまでに仕様や挙動が変わる可能性があります。今の時点でチームの中核的なレビュー運用をこの機能に全面的に切り替えるのは時期尚早です。

チームが検討する際の視点

私たちは以前、AIエージェントに大きな実装タスクを任せる際の分解方針を見直したことがあります。タスクをDB→API→UIのようにシステムの層(アーキテクチャの水平方向)で区切ると、最終フェーズまで統合されたフィードバックが得られず、途中の設計ミスに気づけないまま作業が進んでしまうという問題に直面したためです。その結果、この水平の層構造をやめて、全体を薄く貫通する単位に分解し直し、各単位を早い段階で検証できるようにしました。

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

この点を踏まえると、チームがスタックPRを検討する際に確認すべきことが見えてきます。既存のブランチ保護・ステータスチェックがそのまま機能する点は導入のハードルを下げますが、マージキューを使っているかどうか、そしてプレビュー段階の機能をどこまで本番運用に持ち込むかは、チームごとに判断が分かれる部分です。まずは影響範囲の小さい変更で層構造のレビューを試し、レビュアーの負担がどう変わるかを実際に確認してから、適用範囲を広げるかどうかは決まります。

まとめ

マージキュー対応が出そろうタイミングこそ、今回の検証結果をもとに適用範囲を見直す最初の判断点になります。GitHub のスタックPRは、大きな変更を独立してレビューできる単位に分ける運用を公式機能として提供しましたが、マージキュー未対応とプレビュー段階という制約がある以上、レビュー運用の中核をすぐに置き換えるべきではありません。まずは小さく試し、レビュアーの負担と手動リベースの手間がどう変わるかを見てから、適用範囲を広げるかどうかを決めるのが実務的な進め方です。

出典: