AI駆動開発のレビューを変えるStacked PRと高速DBテスト

AIエージェントの変更、なぜレビューが詰まるのか

CodexやClaude Codeにタスクを渡すと、1回の実行でマイグレーション、API変更、テストが一括りに返ってくる。人間なら数日かけて分割するはずの変更が、1つの巨大diffとして届く。レビュアーは全体を頭に入れてから差分を追う羽目になり、レビューの質が落ちる。

統合テストも同じ問題を抱える。変更が大きいほど「本当にこの部分だけ壊れていないか」を確かめたくなるが、DBを絡めたテストはセットアップだけで時間を食う。レビュー単位の分割と検証の高速化は、AI駆動開発において別々の課題ではなく、同じボトルネックの両面だ。

Stacked PRで変更を「積み重ねて」検証する

GitHubが2026年7月30日に公開したStacked pull requestsは、この分割問題への回答になる。Stacked PRs are now live on GitHubによれば、大きな変更を順序付きの複数レイヤーに分け、各PRが直下のレイヤーだけを対象にする。

各PRは独立してレビュー・チェックでき、スタックマップで全体の位置関係が見える。下位レイヤーを1つマージすると、上位PRは開いたまま自動的にリベースされ、対象先も更新される。既存のブランチ保護や必須チェックはそのまま適用され、最新の準備完了PRをマージすれば下位の未マージ分もまとめて取り込まれる。

操作はGitHub.com、CLI、モバイルアプリ、GitHub Copilotのgh-stackスキルのいずれからでも可能で、CLI拡張は「gh extension install github/gh-stack」で導入できる。AIエージェントに「1機能=1PR」で段階的にコミットさせ、そのままスタックとして積む運用が現実的になった。

pgtestdbで統合テストを高速化する

PRを小さく分けても、統合テストのDBセットアップが遅ければ検証サイクルは回らない。Peter Downs氏が開発したGo向けパッケージpgtestdbは、Postgresのテンプレートデータベース複製機能を使う。Pgtestdb's template cloning approach to testing is fastが実測値を示している。

「CREATE DATABASE dbname TEMPLATE template_to_copy;」の一文で、リレーションのヒープ・インデックス・カタログを8KB単位のページごとコピーする。Riverのテストスイートでの計測では、pgtestdb複製が466回の試行で平均98.4ミリ秒（p95は299.5ミリ秒）だった。対してスキーマ作成・マイグレーションは81回の試行で平均99.4ミリ秒（p95は209.0ミリ秒）。個々の所要時間はほぼ互角だった。

ところがテストスイート全体では差が開く。pgtestdb複製方式は51.07秒、スキーマ作成・マイグレーション方式は14.54秒。試行回数の違いを踏まえてもなお、Riverチームはスキーマを使い回す設計を選んだ。テスト終了後のスキーマをプールし、必要なバージョンと一致するものがあれば新規作成せず再利用する。「速いDB複製」だけでなく「複製を減らす設計」まで踏み込んで初めて、テストスイート全体が速くなる。

導入判断、小規模チームでどこまでやるか

Stacked PRとpgtestdb型の高速検証は、噛み合わせると強い。AIエージェントに機能を段階分割させ、各段階をスタックのレイヤーとして積む。各レイヤーごとにDBを複製してマイグレーション込みの統合テストを回し、レビューが通ったレイヤーから順にマージしていく。

向いているのは、Postgresを使い1リポジトリでスキーマ変更が頻発するチーム。AIに複数ファイル・複数コミットのタスクを任せる運用なら、PR単位の分割がそのままレビュー負荷の軽減になる。

逆に、DB層の変更がほとんどない静的なフロントエンド中心のプロジェクトや、PRが常に1〜2ファイル程度で完結するチームには過剰装備になる。Stacked PRのマージキュー対応も数週間かけて段階展開中の機能であり、チームのCI基盤がスタック運用の頻繁なリベースに耐えられるかを先に確認したい。

まとめ

AIエージェントの出力が大きくなるほど、分割と高速検証はセットで効いてくる。Stacked PRでレビュー単位を機械的に小さく保ち、テンプレートDB複製とスキーマ再利用でテストの待ち時間を削る。まずは1つの機能追加をスタック運用で試し、DBを絡めた統合テストの所要時間を計測するところから始めるのが現実的だ。