スタック型プルリクエスト——AIエージェントの大量生成物を、レビューできる単位に分割する技術
先日公開した「メテオフォール開発」の記事で、AIエージェントが降らせる初期実装を「観測・分解・修正」する型についてお伝えしました。あの記事を書いたあと、社内のエンジニアからこう聞かれました。「分解って、具体的にはどうやるんですか」。曖昧に答えかけて、はたと気づきました。分解を仕組み化する技術には、すでに名前がついています。スタック型プルリクエストです。
- 01「PRがまた1つ、肥大化していく」——AIエージェント時代のレビュー現場
- 02巨大な1つのプルリクエストは、なぜ悪なのか
- 03「数珠つなぎ」という発想——スタック型プルリクエストの仕組み
- 04GitHub公式が動いた——2026年7月30日、Public Preview入り
- 05エージェント生成PRに潜む、見落としやすいリスク
- 06私たちAI-Path自身、「分解」を最初から仕組みにしてきた理由
- 07FDEとして、どのレイヤーまで自動マージを許すか
- 08ジュニアエンジニアなら、「1レイヤーだけ」ならレビューに入れる
- 09「PR単位のハンドオフプロンプト」という次の一手
- 10それでも、スタックが向かない場面
- 11よくある質問
- 12私たちの見解
- 13まず試すなら
- 14参考リンク
「PRがまた1つ、肥大化していく」——AIエージェント時代のレビュー現場
「エージェントに任せた機能追加のPR、差分が2,000行を超えていて開けるのに気力が要る」。先日、複数のAIエージェントを並列運用している開発リードから、そんな相談を受けました。原因はAIの性能不足ではありません。AIが速く多く書けるようになった結果、1つのプルリクエストに詰め込まれる変更量が、人間が書いていた時代の感覚のままレビューに回されていることでした。
Ubie社のテックブログでも、同じ問題意識が語られています。「AIエージェントでの開発が前提の現在、AIエージェントは素早く多くのコードを生み出します。気をつけないと、1つのプルリクエストに多くの開発が盛り込まれ、巨大なプルリクエストになってしまいます」。私たちの現場感覚とも一致します。書く速度が上がった分だけ、レビューという工程にしわ寄せが集まっているのです。
巨大な1つのプルリクエストは、なぜ悪なのか
1つの巨大なPRの何が問題なのか、正直に言えば当たり前すぎて誰も丁寧に説明しません。理由は主に2つです。1つは、レビュアーが「どこを見ればいいか」を自分で探さなければならないこと。テーブル設計への指摘とAPI実装への指摘が同じスレッドに混在すれば、議論は簡単に散らかります。もう1つは、あとからコード差分を追うときの見づらさです。半年後に「このAPIはいつ、なぜこの形になったのか」を調べようとしたとき、無関係な変更まで一緒くたになったPRは調査コストを跳ね上げます。
私たちの現場経験では、レビューが辛くなる原因の多くは「全部読もう」としていることにあります。人間が1行ずつ読むという発想のまま、AIの生成量に対応しようとすれば、当然どこかで破綻します。差分の量を減らすのではなく、差分を意味のある単位に分けること。ここに手を打たない限り、AIがいくら速く書いても、チーム全体の開発スピードは上がりません。
「数珠つなぎ」という発想——スタック型プルリクエストの仕組み
Ubie社のブログには、実務的な解決策が具体的に書かれています。ユーザーのお気に入り機能を実装するとき、次のように3つのPRへ分割するという例です。1つめは、お気に入りを保存するテーブルを追加するマイグレーション。2つめは、そのテーブルを操作するRepository層の実装。3つめは、Repositoryを呼び出すAPIエンドポイントの実装です。2つめのPRは1つめのブランチに対して、3つめのPRは2つめのブランチに対して積み上げる。「レビュアーは『まずテーブル定義が妥当か』『次にRepositoryの実装が妥当か』『最後にAPIの実装が妥当か』と、層ごとに焦点を絞ってレビューできます」。これがスタック型プルリクエストの発想です。
ただし、この「数珠つなぎ」を手動でやろうとすると、面倒な作業が積み重なります。PRのマージ先を都度設定する手間、どのPRが何番目かを自分でdescriptionに書く手間、そして前のPRを修正したときに後続のPRへrebaseし直す手間です。この面倒さのために、スタック運用は一部の几帳面なエンジニアだけの習慣にとどまっていました。
GitHub公式が動いた——2026年7月30日、Public Preview入り
その面倒さの多くを、GitHub自身が解消しました。GitHubは2026年7月30日、CLI拡張機能「GitHub gh stack」を含む「スタック型プルリクエスト(Stacked pull requests)」をPublic Previewとして公開しています。公式の説明はこうです。「大きな変更を小さくレビュー可能なプルリクエストに分割します。それぞれが変更の焦点を絞った層を表す、順序付きのプルリクエストのシリーズです」。CLIからはgh extension install github/gh-stackで導入でき、gh stack syncを実行すれば、スタック全体のrebase・force push・GitHub側の同期までが一度に片付きます。
見逃せないのは、この機能がAIエージェント前提で設計されている点です。Claude CodeやCodexといったコーディングエージェント向けに専用のgh-stackスキルが用意されており、「スタックPRを作って」「スタックPRを全部rebaseして」と自然言語で指示するだけで操作できます。GitHub自身のブログでも、エージェントが生成するPRの急増が「実装からレビューへのボトルネック移動」を引き起こしていると明言しており、ネイティブなスタック機能はその構造的な回答だと位置づけられています。もっとも、この領域はGitHub専売ではありません。Meta製のSapling、ghstack、git-spice、そしてCursorが2025年12月に買収したGraphiteなど、複数のツールがすでに同じ課題に取り組んできました。GitHubが標準機能として取り込んだことで、この考え方が一部の几帳面な開発者の習慣から、チーム標準に格上げされたと捉えています。
エージェント生成PRに潜む、見落としやすいリスク
分割さえすれば安心、というわけではありません。GitHub自身のブログが指摘している通り、エージェントが書いたPRには人間の書いたPRとは異なる見落としのパターンがあります。テストを通すことだけを目的にCIの挙動を都合よく解釈してしまう「CIゲーミング」。既存の実装を知らずに車輪を再発明してしまう「コード重複の見落とし」。実際には検証していないのに「動作確認済みです」と報告してしまう、根拠のない完了報告。そして、レビューコメントが付いたまま誰も対応せず放置される「エージェントのゴースト化」です。
私たちの現場経験でも、これは他人事ではありません。AIが作った議事録や提案書についても、過度な要約や発言の言い換えが起きていないかを開発リードが検知し、必要なら再生成させる品質ゲートを通すようにしています。スタックに分割してレビューの焦点を絞ることは、これらのリスクを見つけやすくする土台にはなりますが、リスクそのものを消してはくれません。層を細かくした分だけ、各層で「本当に検証したのか」を確認する目は、むしろ増やす必要があります。
私たちAI-Path自身、「分解」を最初から仕組みにしてきた理由
前回の記事で書いた「観測・分解・修正」というメテオフォール開発の3工程のうち、スタック型プルリクエストが担うのはまさに「分解」です。AIエージェントが降らせた粗い初期実装を、人間がレビューしきれる単位まで切り分ける。この考え方自体は、私たちにとって目新しいものではありませんでした。
私たちの現場では、権限まわりの変更やデータベーススキーマに関わる差分を、人間が最初に目を通す高リスク領域として扱っています。これは社内で繰り返し語られてきた方針とも重なります。「最初はデータベースをいじらないものに留めた方がいい。DBをいじると、もう後戻りできない」。非エンジニアの内製担当者にVibeCodingを安全に回してもらうための、社内のガードレールの言葉です。この考え方はマージの手前にも適用しています。「メインに直接マージせず、まずPRを上げる。PRを上げるとAIが中身を確認してレビューし、妥当性を判断してくれる」。スタック型プルリクエストは、この考え方を「1つのレイヤー=1つの関心事」という形で、より厳密に運用できる技術だと私たちは捉えています。
FDEとして、どのレイヤーまで自動マージを許すか
スタックにすると、レイヤーごとに扱いを変えられるようになります。ここが実務上、最も重要な設計判断です。私たちが顧客の現場に伴走する際は、権限やスキーマに関わるレイヤーは人間が最終レビューを担い、文言修正やスタイル調整のようなレイヤーはAIの一次レビューと自動テストが通ればマージを許容する、という線引きをしています。すべてのレイヤーに同じ重みでレビューをかけようとすると、スタックにした意味が薄れてしまうからです。
イシューの切り方にも同じ発想が生きています。「AIで議事録から丸めて起票すると、全部自分の名前になる。丸まっていると何が本当に残っているか分からなくなるので、管理しやすい単位でIssueを切る。順番に検証しないと、ここは直ったがここは直っていない、という漏れが起きる」。これは社内で繰り返されてきた注意点ですが、スタック型プルリクエストが解決しようとしている問題とほぼ同じ構造をしています。大きな変更をひとまとめに検証しようとするほど、何が検証済みで何が未検証かがあいまいになるのです。
ジュニアエンジニアなら、「1レイヤーだけ」ならレビューに入れる
前回の記事では、経験の浅いメンバーをAI駆動開発のサイクルにどう参加させるかという論点を扱いました。スタック型プルリクエストは、この論点にも具体的な答えを出してくれます。2,000行の巨大PRを渡されても、経験の浅いメンバーはどこから手をつけていいか分かりません。しかし「このレイヤーだけ見てほしい」と1層分を渡されれば、話は変わります。
私たちは、FDEを目指す新メンバー向けに90日間のアクションプランを組み、経験者が伴走する「ペア長」制度と週次の1on1を運用しています。低リスクなレイヤー、たとえば文言修正やUIのスタイル調整の層から先にレビューに参加してもらい、疑問点はペア長に相談する。この設計は、スタックという構造があって初めて自然に成立します。1つの巨大PRのままでは、「ここだけ見て」という切り出しがそもそもできないからです。
「PR単位のハンドオフプロンプト」という次の一手
分解した先の運用にも、参考になる工夫があります。Qiitaに投稿された記事では、AIによるコードレビューの後処理を見直す手法が紹介されていました。従来のように指摘をフラットなリストで受け取るのではなく、「各修正を単一の関心事ごとにグループ化し、別のAIセッションに渡せる自己完結した実装指示書を生成させる」という発想です。レビューセッションと実装セッションを分離し、指摘を作業可能な形に整形することが本質だといいます。
これはスタック型プルリクエストと相性がいい考え方です。スタックの各レイヤーに対応する「ハンドオフプロンプト」をAIに作らせておけば、次のAIエージェントセッションはそのレイヤーの修正だけに集中できます。私たちの現場でも、AIが作った初期実装のレビュー指摘を、次のタスクとして分解し担当者に割り振る工程を設けていますが、この割り振り先を人間ではなく次のAIセッションに渡す運用に置き換えられる余地は大きいと感じています。
それでも、スタックが向かない場面
誤解のないように言えば、あらゆる変更をスタックに分割すべきだとは考えていません。1つのファイルを数行直すだけの小さな修正まで無理に層立てすれば、rebaseやレイヤー間の依存関係を管理するオーバーヘッドの方が大きくなります。本番障害への緊急ホットフィックスのように「今すぐ1つだけ通したい」場面でも、スタックは足かせになりがちです。
もう一つ、実際にツールを触った開発者から出ている指摘も無視できません。Ubie社のブログには「syncによるカスケードrebaseは『trunkが更新された場合のみ』とされている」という補足コメントが付いていました。下位レイヤーの変更を上位に反映する際は、別途rebase --upstackの実行が必要になるケースがあるということです。「AIエージェントに任せれば全自動で楽になる」と過信せず、コマンド1つで魔法のように解決するわけではないという前提で導入するのが実務的だと私たちは考えています。
よくある質問
Q. スタック型プルリクエストは、Gitのブランチ運用の何を変えるのですか。 A. トランクに対して1つの巨大なブランチを立てるのではなく、前のブランチを土台にした小さなブランチを順序付きで積み上げる点が変わります。各PRの差分が1つ下の層との差分だけになるため、レビュアーは層ごとに焦点を絞れます。
Q. GitHub以外のツールでもスタック運用はできますか。 A. できます。Meta製のSapling、ghstack、git-spice、Graphiteなど既存のツールが同様の機能を提供してきました。GitHubが2026年7月に標準機能として公開したことで、追加ツールを導入せずに近い運用を始めやすくなった、という位置づけです。
Q. AIエージェント PRレビューの精度に不安がありますが、操作自体は任せて大丈夫ですか。
A. gh-stackのようなエージェント向けスキルを使えば自然言語で操作できますが、「本当に検証したか」の確認は人間が担う必要があります。私たちの現場では、権限やスキーマに関わるレイヤーは人間が最終レビューする運用にしています。
Q. どのくらいの規模のチームから導入すべきですか。 A. AIエージェントが1日に生成するPR数が増え、レビュー待ちのキューが目に見えて溜まり始めた時点が導入のタイミングです。小規模なチームでも、1機能を複数レイヤーに分ける実験から始めることをお勧めします。
私たちの見解
スタック型プルリクエストがGitHub公式機能になったことは象徴的だと考えています。プルリクエストを分割するかどうかは、これまで個々のエンジニアの几帳面さに委ねられていました。それが今、AIエージェントが生成する変更量の増加という構造的な圧力によって、標準機能として実装されるところまで来たということです。
私たちの現場経験では、この分解を怠ったチームほど、レビューという新しいボトルネックに苦しめられています。逆に、権限やスキーマに関わる高リスクなレイヤーを先に決め、それ以外のレイヤーは自動化を許容するチームは、AIエージェントの生成量が増えても崩れません。AIは壁打ち相手であり、判断は人間がする——この基本姿勢を、レイヤー単位まで具体化する技術として、私たちはスタック型プルリクエストを位置づけています。
正直に言えば、私たち自身、この技術に「スタック型プルリクエスト」という名前がつく前から、似たようなことをやってきました。名前がつくことで、チーム内での共有コストが一気に下がります。「これはスタックにして、このレイヤーだけ先にレビューして」と一言で伝えられるようになるからです。
まず試すなら
- 直近の機能追加を、3層に分けて振り返ってみる。 データ層・ロジック層・インターフェース層のように分けられたはずの変更が、1つのPRに詰め込まれていなかったか確認します。
gh extension install github/gh-stackを試験導入する。 本番運用の前に、個人のサイドプロジェクトや検証用リポジトリで一度スタックの操作感を確かめておくと導入判断がしやすくなります。- 「権限・スキーマに関わるレイヤー」を1つ言語化する。 どのレイヤーまでなら自動マージを許容できるか、まず1つの基準を決めるところから始めます。
自社のレビュー体制のどこにボトルネックが眠っているか、把握できていない企業は多くいらっしゃいます。私たちは無償の業務プロセス診断(BPR)を実施しており、AI駆動開発フローの整備を含めた現状の棚卸しをお手伝いしています。まずは無償の業務診断で、レビュー体制のどこに手を打つべきかを明らかにしませんか。
参考リンク
櫻井 文雄（さくらい ふみお） 株式会社AI-Path 代表取締役CEO
関西大学法学部法律学科卒業。財務コンサルティング会社（エフアンドエム）、外資系生保営業（Prudential）でコンサルティング営業の経験を積んだ後、起業し様々な企業のCTO/CMOを歴任。その後、デロイトトーマツコンサルティング（Big4）、ABEJA（AI研究開発の国内リーディングカンパニー）にて官公庁・製造業・金融業・小売業・不動産業を中心に延べ20社以上のDX推進や業務システム刷新をPM/SMとしてリード。利用者目線での現場の課題解決にフォーカスしたものづくりに拘り、導入ではなく「定着化」を目的とした伴走型のプロジェクト推進・システム導入を得意とする。2025年にAI駆動開発（VibeCoding）と出会い、より多くの人・企業に価値提供するためにAI-Pathを創業。
関連コラム
「メテオフォール開発」——エンジニアの皮肉語が、AI時代に前向きな方法論になった理由
ウォーターフォール開発を揶揄する皮肉語だった「メテオフォール開発」が、AIエージェント時代に意味を反転させ、前向きな開発方法論として使われ始めています。私たちAI-Path自身の伴走現場での実践を交えて、この手法の使い方と限界を解説します。
「見た目8割、実態1割」——AIプロトタイプの完成度に、エンジニアはなぜ騙されるのか
非エンジニアがAIで作ったプロトタイプを見せて「これと同じものを本番で」と依頼してくる時代になりました。見た目の完成度と本番実装工数の間には、なぜこれほどのギャップが生まれるのか。私たちが評価に使っている具体的な観点を交えて解説します。
プロンプトも本番コードだ——AIエージェント時代の『プロンプト・リグレッションテスト』という設計
プロンプトを1行直しただけで、別のタスクの出力がおかしくなった——そんな経験はないでしょうか。Opus 5移行で私たちが直面した『サイレント回帰』と、その対処法としてのプロンプト・リグレッションテストを、現場の実践から解説します。