GitHubがスタックプルリクエストの公式サポートを開始した。Hacker Newsで325ポイントを集め、AIコーディング時代の必需品と持ち上げる声が多い。だが冷静に見れば、これは巨大PRを生む組織の病を覆い隠す絆創膏にもなり得る。誰も言わない負の側面を、まず指摘しておく。
何が起きたか
2026年7月30日、GitHubがスタックプルリクエスト（Stacked PRs）の公式サポートをパブリックプレビューとして開始した。Hacker Newsでは325ポイント、109コメントと大きな反響を集めている。
スタックPRとは、大きな機能開発を小さなPRに分割し、依存関係を保ったまま積み重ねてレビューする仕組みだ。従来はGraphite、Sapling、gtなどのサードパーティCLIツールに頼るしかなかった運用が、GitHub本体で完結する。
これにより、1件あたりのレビュー負荷が下がり、上流PRのマージを待たずに下流の作業へ進める。特にAIコーディングエージェントが吐き出す大量のコードを人間がレビューする現代において、粒度の細かい積み重ねレビューは実務上ほぼ必須の要件だった。ようやくGitHubが公式に応えた形である。
なぜこのニュースが重要か
素直に読めば「レビュー効率の改善」だが、蛙崎の視点で言えば、これはGitHubがAIコーディングの生産物に対するレビュー基盤の主導権を奪還しに来た、というプラットフォーム戦略の話だ。
Graphiteは有料SaaSとしてスタックPR領域で急成長し、AI駆動レビュー機能で存在感を強めていた。GitHubが公式提供することで、Graphiteの差別化ポイントは急速に浸食される。企業のツール契約見直しは避けられない。1シートあたり月20〜30ドル規模の外部ツールを数百人分契約している組織なら、年間数百万円単位のコスト再検討が現実的な議題になる（推定）。
もう一つのリスク警告として、AIエージェントが生成するコードの量的爆発に、人間のレビュー体制が構造的に追いついていない現実がある。スタックPRはこのボトルネックを一時的に緩和するが、根本的には「レビュアーの認知帯域」という有限資源を食い潰す速度が上がるだけだ。ツールで細切れにしても、責任を持って読む人間の脳は増えない。
過剰評価への反論
ここが本題だ。「スタックPRはAI時代の必需品」という論調に、私は明確に異を唱える。
第一に、スタックPRが必要なほど巨大なPRを日常的に生む組織は、そもそも設計と要件分割に失敗している。健全な組織では、そもそもPRは自然に小さくなる。設計フェーズでの分割、フィーチャーフラグの活用、トランクベース開発で十分に対応できていた領域を、「スタックPRがあるから大きく作って後で分ければいい」という思考停止に置き換える危険がある。ハッカーニュースで指摘されている「巨大PRを生む組織の問題を隠す応急処置」という批判は、控えめに言っても正しい。
第二に、スタックの深さが増えると、途中のPRに指摘が入ったときのリベース地獄が発生する。CLI補助があっても、コンフリクト解消の認知コストは分割数に対して線形以上で増える。Graphite利用者のブログを読めば分かるが、スタック運用は「熟練者の技」であり、初級エンジニアに強制すると生産性はむしろ落ちる。
第三に、AIエージェントの出力を細かくレビューできる、という利点は諸刃の剣だ。粒度が細かくなることで、レビュアーは局所最適の確認に追われ、アーキテクチャ全体の一貫性チェックが疎かになる。木を見て森を見ずのレビューが常態化するリスクを、誰も語っていない。
つまりスタックPRは、優れたチームの武器にはなるが、平均的な組織にとっては新たな運用負債を生む可能性が高い。ツール導入と組織成熟度を混同してはならない。
経営者として次に取るべき動き
第一に、既存のGraphiteやSapling系ツールの契約を棚卸しし、GitHub純正版で代替可能な機能と、そうでない機能（AIレビュー、可視化ダッシュボード等）を切り分けよ。単純解約は3〜6か月後の判断で十分だが、更新契約前の交渉材料にはすぐ使える。
第二に、スタックPRを導入する前に、自社のPRサイズ分布を計測せよ。中央値が500行を超えているなら、それは設計と要件分割の問題であり、ツールで解決すべきではない。まず設計プロセスの見直しが先だ。
第三に、AIコーディングエージェントのレビュー体制を「人間レビュアーの認知帯域」という有限資源から逆算して設計せよ。スタックPRで細切れにするだけでは、レビュアーの疲弊を先送りするだけだ。アーキテクチャ観点のレビューを担う専任シニアの配置、自動化されたポリシーチェックの拡充を並行して進めるべきである。