AI時代のコードレビュー：巨大PRを解体する「スタック」戦略

深夜2時、CIが落ちた通知で叩き起こされ、1,700行を超える巨大なプルリクエスト（PR）を前に呆然とした経験はないだろうか。レビュー依頼が飛んできたものの、どこから手を付ければいいのか分からず、結局「LGTM」と打って逃げ出したくなるあの感覚。我々エンジニアにとって、巨大なPRは単なるコードの塊ではなく、レビューという名の「デッドロック」そのものだ。GitHubが今回提示した「Stacked Pull Requests（スタックされたプルリクエスト）」という概念は、単なるワークフローの改善ではない。AIがコードを生成するスピードが人間のレビュー能力を遥かに凌駕し始めた今、我々が直面している「レビューのボトルネック」に対する、極めて現実的かつ生存戦略的な回答である。

Gartnerの予測によれば、AIエージェントは2028年までにSDLC（ソフトウェア開発ライフサイクル）のあらゆるステージで50%の生産性向上をもたらすとされている。しかし、この「生産性」の裏側で、AIは平気で1,000行を超える巨大なdiffを吐き出す。AIは文脈を理解しているつもりでも、人間がレビューする際の「認知負荷」までは考慮してくれない。結果として、レビューが滞り、マージが遅れ、最終的には「とりあえず動くから」という理由で、不完全なコードがメインブランチに混入する。これは、かつて我々が手作業で苦労していた「スパゲッティコード」の生成を、AIが高速化しているに過ぎないのではないか。この悪循環を断ち切るために、GitHubは「分解（Decomposition）」という古くて新しいアプローチを、CLIツールとUIの統合によって現代的に再定義したのである。

GitHubが提唱するスタック構造の核心は、機能単位ではなく「関心事の分離」に基づいたレイヤー化にある。例えば、ショッピングアシスタントに検索機能を追加する場合、従来であれば「データモデル」「API」「UI」「クライアント wiring」を一つのPRに詰め込んでいた。しかし、スタック構造ではこれらを論理的な依存関係に基づいて積み上げる。具体的には、L1（データ層）をベースとし、その上にL2（API層）、L3（チャット連携）、L4（UI層）を積み重ねる。これにより、データモデルの専門家はL1を、UIの専門家はL4を、それぞれのコンテキストでレビューすることが可能になる。これは、マイクロサービスアーキテクチャをPRの粒度にまで落とし込んだようなものだ。

以下に、GitHubが推奨するスタックの構成例を示す。この構造化により、各レイヤーが独立したレビュー対象となり、CIも各層で個別に評価されるため、問題の切り分けが劇的に容易になる。

このアプローチの真骨頂は、AIエージェントとの協調にある。`gh-stack` CLIツールを導入し、AIエージェントに「スタックの作法」を学習させることで、エージェントは自律的に小さなPRを連鎖的に生成するようになる。これは、人間が「巨大なPRを分割せよ」と指示するのではなく、AIが「レビュー可能な単位で出力する」という、開発プロセスの根本的なパラダイムシフトを意味している。我々エンジニアは、AIが生成した巨大な塊を解体する作業から解放され、各レイヤーの論理的な整合性を確認するという、より高次な設計レビューに集中できるようになるのだ。

スタックされたPRを運用する上で、最も注意すべきは「リベースの連鎖」である。レビューの結果、L1（最下層）に修正が入った場合、L2以降のすべてのレイヤーでコンフリクトが発生する可能性がある。GitHubのUI上には「Rebase stack」ボタンが用意されているが、シニアエンジニアとして警告しておきたい。Webベースのボタンによるリベースは、コミット署名が失われるリスクがあり、ブランチ保護ルールが厳格な環境では致命的な障害になり得る。安全を期すならば、ターミナルから `gh stack rebase` を実行し、ローカル環境でコンフリクトを解消した上で `gh stack push` を行うのが、プロフェッショナルなエンジニアの作法である。ツールが便利になればなるほど、その裏側で何が起きているのかを理解しておく必要がある。

結局のところ、スタックされたPRは「レビューの質」を向上させるための手段に過ぎない。重要なのは、我々が「なぜこのコードを分割するのか」という設計思想をAIに教え込めるか、そして、AIが生成したコードに対して「これは本当にレビュー可能な粒度か？」と問い続けられるかである。AIが生成したコードをそのままマージする時代は終わった。これからのエンジニアに求められるのは、AIを「コードを書く奴隷」として使うのではなく、「スタックを管理するパートナー」として制御する能力だ。

最後に、読者諸氏に問いたい。あなたのチームのPRは、今もなお「巨大なブラックボックス」になっていないだろうか？もしそうなら、明日からでも `gh extension install github/gh-stack` を実行し、AIエージェントに「スタック単位での出力」を強制するワークフローを構築してみてほしい。そして、レビューの時間が短縮された分、その時間を「本当に価値のある設計」や「技術的負債の解消」に充てる覚悟はあるか？AIに仕事を奪われることを恐れる前に、AIを使いこなすための「開発の作法」をアップデートすることこそが、我々エンジニアが明日から取るべき唯一の生存戦略である。