「PR が大きすぎてレビュアーが読まない」「依存する変更を待ってる間に他の作業が止まる」「機能が完成するまで PR を出せない」――受託開発・内製支援の現場で必ず聞く悩みです。
2026 年 4 月、GitHub がこの問題に正面から答える機能 Stacked PRs をプライベートプレビューで限定公開しました（gihyo.jp / Hacker News）。Graphite や Sapling など外部ツールが先行していた領域に、ついにプラットフォーム標準が乗ってきます。
本記事では、Stacked PRs の本質、受託開発における導入価値、そして現場で陥りがちなアンチパターンまでを整理します。
Stacked PRs とは何か
Stacked PRs（積み重ね PR）は、1 つの大きな機能変更を、依存関係を持つ複数の小さな PR にチェーン状に連結する開発フローです。
PR #103 (UI): フォームコンポーネント追加
↑ depends on
PR #102 (API): エンドポイント実装
↑ depends on
PR #101 (DB): スキーマ追加
↑ depends on
main各 PR は独立してレビュー可能で、下層がマージされると自動的に上層がリベースされます。GitHub の Stacked PRs では、PR ページにスタックの全体像が可視化され、依存関係のクリック移動、まとめてのマージ操作までサポートされる予定です。
既存ツールとの違い
| ツール | アプローチ | 学習コスト |
|---|---|---|
| Graphite CLI | 独自 CLI で管理、GitHub 連携 | 中（独自概念あり） |
| Sapling（Meta） | git 互換だが別 VCS | 高（チーム全員導入が必要） |
| jj (Jujutsu) | git 互換 VCS、Stacked が自然 | 高（思想の理解が必要） |
| GitHub Stacked PRs | GitHub 標準、UI 統合 | 低（GitHub 利用者そのまま） |
GitHub 標準化の最大の利点は、「導入のための合意形成コストがほぼゼロ」 です。受託開発で顧客リポジトリに新ツールを入れる稟議は重く、ここがブレークスルーになります。
受託開発で「巨大 PR」が生まれる構造的理由
そもそも、なぜレビュー困難な巨大 PR が生まれるのでしょうか。原因は 3 つに整理できます。
原因 1：依存関係を持つ変更を 1 PR に詰め込む
DB スキーマ変更 → API 実装 → UI 実装、をすべて 1 つの PR にすると 50+ ファイル変更になります。「機能完成までを 1 PR」というルールが、巨大化の最大要因です。
原因 2：レビュー待ちで仕事が止まるのを避けたい
「次の PR を出す前に前の PR がマージされる必要がある」という制約があると、エンジニアは待ち時間を埋めるために 1 PR に詰め込む動機を持ちます。Stacked PRs はこの制約を解除します。
原因 3：レビュアー側の「読む技術」が育たない
巨大 PR を細かく読み切る訓練が組織に無いと、「LGTM スタンプだけ押して通過」が常態化します。これは技術負債の温床です。Stacked PRs で1 PR あたり 200 行以下を保てると、レビュアーの負荷が劇的に下がります。
Kauche の AI レビュー自動マージ事例 で触れたように、AI レビューを併用することで巨大 PR でも一定品質は担保できますが、そもそも巨大化させない設計 が本筋です。
Stacked PRs を活かす実装パターン
パターン 1：Vertical Slicing（縦割り）
機能を縦に薄く切る古典的な手法に Stacked が乗ると最強です。
Stack 1: 「ユーザー登録機能（最小版）」
├ #201 DB: users テーブル
├ #202 API: POST /users
├ #203 UI: 登録フォーム
└ #204 E2E: 登録〜ログインまでの結合テスト各 PR は 100〜200 行程度。1〜2 日で順次マージできます。
パターン 2：Refactor Stack（リファクタ専用スタック）
機能追加と並行してリファクタを進める場合、「リファクタだけのスタック」を別系統で立てます。レビュアーの認知負荷を機能 / リファクタで分離できます。
パターン 3：Migration Stack（段階移行）
レガシーコードからの移行を 「新コード追加 → 旧コード並行運用 → 切替 → 旧コード削除」 の 4 PR で表現します。受託案件のリプレイスでよくあるパターンです。
Movable Type 脆弱性への対応と CMS 移行 のような大規模移行案件こそ、Stacked PRs の真価が発揮されます。
導入時のアンチパターン
アンチパターン 1：スタックが深すぎる（5 段以上）
スタックが深くなるほど、下層のリベース失敗が連鎖します。原則 3 段以内、最大 4 段までに抑えます。長い機能開発はスタックを区切ってマージしながら進めます。
アンチパターン 2：スタックの途中を skip マージ
途中の PR を飛ばして上層をマージすると、コンフリクトと履歴の混乱が発生します。必ず下から順番にマージするルールを徹底します。
アンチパターン 3：スタック内で大きな force-push
下層 PR の修正で git push --force を多用すると、上層との関係が壊れます。下層を修正する場合は、スタック全体を再構築するつもりで対応します。
アンチパターン 4：レビュアーへの説明不足
「PR #102 は #101 が前提」という情報を PR 説明に明記しないと、レビュアーが文脈を失います。各 PR の冒頭に依存関係を明記するテンプレートを用意しましょう。
受託開発に Stacked PRs を組み込むステップ
Step 1：チーム全員が “git rebase” を理解している状態を作る
Stacked PRs はリベース戦略の上に成り立ちます。merge 派のチームには、事前に 1 週間程度のリベース演習を入れることをおすすめします。
Step 2：CI を「PR 単位」で回す設計
各層の PR が独立してテスト通過できるように、CI を依存関係込みで設計します。下層がマージ前でも、ブランチ参照を解決して上層をテストできる構成が理想です。
Step 3：PR テンプレートに「スタック情報」を追加
## このスタックの位置
- 親 PR: #101
- 子 PR: #103
- スタック全体: #100..#104
## このPRで完結する変更
- ...
## このPRが前提とする変更
- #101 の DB スキーマStep 4：レビュアー向けに「下から読む」を周知
スタックは下層から順にレビューするのが鉄則です。上層から読むと依存先の文脈が掴めず、誤ったレビューにつながります。
Step 5：完了後の振り返りで「平均 PR サイズ」を計測
Stacked PRs の効果は 平均変更行数 / PR で見えます。導入 1 ヶ月後に「平均 800 行 → 平均 180 行」のような可視化を行うと、定着が進みます。
Claude Code でのプロジェクト管理運用 のように、AI ツールと組み合わせて PR 説明文の自動生成・依存関係抽出を行うと、運用負荷をさらに下げられます。
まとめ ― 「PR を分ける技術」は外注の品質も変える
Stacked PRs は単なる便利機能ではなく、「変更を分ける技術」を組織にインストールする ための装置です。受託開発では、この技術が次の 3 点に直結します。
- レビュー速度が上がる → リードタイム短縮 → 顧客への納品速度向上
- レビュー品質が上がる → 後戻り工数の削減 → 案件の利益率改善
- 小さくマージできる → ロールバック容易性 → 本番事故の影響範囲を最小化
弊社 GleamHub では、受託開発・内製支援において Stacked PRs を含む「現代の Git 運用フロー」の導入支援 を行っています。チーム規模 5〜30 名程度の組織で、PR レビューが詰まっている、巨大 PR が常態化している、といった課題感がある場合は、まず 2 週間のフロー診断と PR テンプレート整備からお受けしています。
