スタック型プルリクエスト——AIエージェントの大量生成物を、レビューできる単位に分割する技術
「エージェントに任せたPR、差分が2,000行を超えていて開けるのに気力が要る」 そんな相談を、複数のAIエージェントを並列運用している開発リードから受けました。 原因はAIの性能不足ではありません。書く速度が上がった分だけ、レビューという工程にしわ寄せが集まっているのです。
GitHubは2026年7月30日、この問題への回答となる「スタック型プルリクエスト」をPublic Previewとして公開しました。1つの巨大な変更を、レイヤーごとに焦点を絞った順序付きのPRへ分割し、下のPRがマージされると上のPRも自動的に追従する仕組みです。CLI拡張機能「gh stack」を使えば、gh stack syncひとつでrebase・force push・同期がまとめて片付きます。
Ubie社のテックブログが挙げていた例が分かりやすいので紹介します。お気に入り機能を実装するとき、テーブル追加のマイグレーション→Repository層の実装→APIエンドポイントの実装、という3つのPRに分け、順に積み上げていく。レビュアーは「まずテーブル定義が妥当か」「次にRepositoryの実装が妥当か」と、層ごとに焦点を絞ってレビューできるようになります。
私たちの現場でも、権限やデータベーススキーマに関わる変更は人間が最初に目を通す高リスク領域として扱い、文言修正やスタイル調整のようなレイヤーはAIの一次レビューと自動テストが通ればマージを許容する、という線引きをしています。すべてのレイヤーに同じ重みでレビューをかけようとすると、分割した意味が薄れてしまうからです。
分割さえすれば安心、というわけではありません。テストを通すことだけを目的にCIの挙動を都合よく解釈する「CIゲーミング」や、根拠のない完了報告など、エージェント特有の見落としパターンは、層を細かくした分だけ確認する目を増やす必要があります。
私たちの現場経験では、この分解を怠ったチームほど、レビューという新しいボトルネックに苦しめられています。AIは壁打ち相手であり、判断は人間がする——この基本姿勢を、レイヤー単位まで具体化する技術として、私たちはスタック型プルリクエストを位置づけています。
📖 完全版はこちら → スタック型プルリクエスト——AIエージェントの大量生成物を、レビューできる単位に分割する技術
櫻井 文雄（さくらい ふみお）｜株式会社AI-Path 代表取締役CEO。製造業を中心に延べ20社以上のDX推進をリードし、FDEモデルでAI導入の定着を支援。
#AI導入 #FDE #VibeCoding #製造業DX #AI_Path
関連コラム
Claude Codeのファイル削除事故——rm -rf禁止でも4万8000件が消えた理由とauto モード時代の防ぎ方
Claude Codeのエージェントが103秒で4万8,218ファイルを消した事故が報告されました。削除コマンドを禁止していても止まらなかった理由と、auto モードが既定になった今、削除事故をどう防ぐかを、公式ドキュメントと私たちの現場の運用からお伝えします。
AIエージェントに渡す『鍵』をどう守るか——VibeCoding内製化のシークレット管理・APIキー管理
機密データを見せない、繋ぎ先のMCPを信頼する——ここまでお伝えしてきました。今回はその両方の土台にある「渡す鍵そのもの」の話です。APIキーをどこに置き、どう失効させるかという地味な設計が、実は事故の分かれ目になります。
MCPツールは『後から牙を剥く』——AIエージェントを狙うラグプル攻撃とツールポイズニング
一度承認したMCPサーバーは、その後もずっと安全とは限りません。ツールの説明文が密かに書き換わる『ラグプル攻撃』と、指示を隠し持つ『ツールポイズニング』という新しい脅威と、具体的な防ぎ方をお伝えします。