Stacked PRsが解くのは構造の問題、Parryが解くのは意図の問題

2026年7月30日、GitHubがStacked Pull Requestsをパブリックプレビューに引き上げたと公式ブログで発表した。1つの大きな変更を階層化されたPRの連なりに分解する機能で、gh stackというCLI拡張、github.com、GitHubモバイル、GitHub Copilotエージェントのいずれからも操作できる。各層のPRは1つ下の層をターゲットにし、一番上の層をマージすると連なる下層もまとめてmainに入る、という仕組みが説明されている(出典)。

この発表に添えられた導入企業の証言の中に、TEDのCTO Andy Merrymanの一文がある。

AI has made TED's developers dramatically more productive, but that created a new bottleneck: PRs were growing large enough that reviewers were struggling. Stacked PRs help to solve that.

(出典)

AIによって開発速度が上がったことが、そのままレビュアー側の新しいボトルネックを生んだ、という認識である。同じ発表にはjQueryの作者John Resigの歓迎コメントも並んでおり、5つのstacked PRを一度にマージキューへ乗せられたことを喜んでいる。TEDという1社の内部事情ではなく、複数の著名な開発者が同じ詰まりを共有していたことがうかがえる。

Parryは「PRレビューが詰まっている」という前提の上に、Why(なぜこの変更か)/Risk(影響範囲)/Confidence(自信度)/Context(背景)の四軸を必須入力にすることでレビュアーの迷いを減らそうとするツールだ。その前提を、GitHub自身が公式アナウンスの中で認めた形になる。

「もう意図レビューは要らないのでは」という仮説

最初に立てた見立ては、大きな変更を機械的に小さな単位へ分解できるなら、Parryのような「なぜこの変更か」を問う層はもう不要ではないか、というものだった。レビュー可能な粒度に割ってしまえば、1つ1つのPRは自明になり、意図を別途書かせる必要も薄れるように見えた。

しかし発表内容を読み直すと、Stacked PRsが保証しているのは層の構造とマージの順序であって、「なぜこの位置で切ったか」「なぜこの順番に積んだか」という判断そのものはどこにも記録されない。各層のPR説明欄に何を書くかは、従来のPRと同じく書き手の裁量に委ねられたままだ。分解が細かくなるほど「なぜここで切ったか」を書く箇所は層の数だけ増えるのに、その記入を強制する仕組みはStacked PRs自体には備わっていない。

つまりStacked PRsが解決するのは構造の問題であり、1つの大きな変更をレビュー可能な単位に割ることに専念している。Parryが向き合っているのは別の問題で、分解された1つ1つの変更に、なぜそうしたかという意図が残っているかを問う。両者は競合する機能ではなく、層を作る道具と、層の中身を保証する道具という補完関係で並ぶ。

手元の公開作業で確かめる

このリポジトリの記事公開作業でも、似た分解を手動でやっている。8月2日、3本の記事のstatusをpublishedへ切り替える作業があったが、1つのPRにまとめず、目的ごとに3本の別々のブランチに分け、それぞれ別のPRとして送っている。

3本まとめて公開作業をした日でも、1記事=1PR=1目的の原則を崩さないために、あえて分けた。これは手動でやっているStacked PRs的な分解と言っていい。ここでParryのwhy/risk/confidence/context四軸が効いてくる。PR作成ツールは分解した単位ごとに四軸の入力を要求するため、「3本まとめて公開作業をした」という事実と、「なぜこの記事をこのタイミングで公開するか」という記事ごとの理由が、分解した後も薄まらずに残る。層を増やしても、各層に強制入力の四軸が乗っていれば、層の数だけ意図の記録も増える計算になる。

補強材料として、Ubieの鹿野壮氏が書いたgh stack syncの解説記事も同じ方向を向いている。このコマンドはorigin/mainの最新化からスタック全体のrebase、GitHub上のPR情報の同期までを自動でやってくれるという(出典)。下の層を直しただけで上の層まで自動で追従するなら、上の層のContext欄が指していた前提はどこまで有効なままなのか、という追従の問題が別途残る。この点はまだ深く検証していない。

ここまでで検証できていないこと

Stacked PRsとParryを実際に組み合わせて運用した実績はまだない。層を増やすほど各層でwhy/risk/confidence/contextを埋める回数も増えるが、それが本当にレビュー負荷を下げるのか、逆に記入疲れを招いて内容が「困る」「直す」のような最小限のトークンに収束する崩壊を早めるのかは、今のところ分からない。もしStacked PRsと四軸必須のレビューツールを併用していて、記入疲れに近い症状が出ているなら、それがどちらの層で起きているのかは聞いてみたい。