AIエージェント

AI生成PRのレビュー負担にどう対処するか：分割・受付停止・量の削減

2026/9/8 （更新: 2026/10/11）

🤖 AIを使用して執筆

受け取り側に負荷が移った

コードを書く工程が速くなったとき、遅れて負荷を受けたのは受け取る側だった。誰かが変更を書き上げても、それが共有のコードベースに入るまでの間には、必ず人が読んで判断する工程が挟まる。書く工程が速くなった分だけ、この工程に届く量は増える。

読む工程の能力が変わらないまま入力だけが増えると、待ち行列が伸びる。実際の数もある。VercelのAI SDKは、週2,000万回を超えるnpmダウンロードを持つプロジェクトで、6月末の時点で「1,000件を超えるopen issueと、800件近いプルリクエスト」を抱えていた。エージェントによる仕組みを入れて4週間後、Vercelはその仕組みが「マージするPRの25〜35%を書き、issueの70〜80%を閉じている」としている²。ただし、滞留のすべてがAIに由来するわけではない。Astroの創業者Fred Schottは、issueが処理能力より速く届く状態が5年続いたと述べており、ここで彼が挙げた滞留はPRではなくissueのものである²。この負荷をめぐって取られた手はいくつかあり、切れ目を置く人と場所が異なる。ある手は書く側が作業を先に層へ分けて送り、別の手は受け取る側がコードの前に切れ目を置き、また別の立場はレビューの量そのものを問い直した。以下、それぞれを順に見る。

受け付けたまま割るツールを、GitHubが出した

GitHub Engineeringのブログで、Julia Muiruriは2026年8月4日、1本の大きなAI生成PRになりがちな作業を、レビューできる単位のスタック（積み重ね、互いに依存し合う複数のブランチを順に連ねたもの）へ分ける手順を公開した³。

層に分けずにエージェントへ書かせたとき1本のPRに収まりがちなものとして挙げられているのは、機能一つのすべての層、シードデータを含むデータモデル、検証つきのAPIルート、クライアントのUIを一つに収めた、1,000行を超える差分である。記事中では、レビュアーがそれを「1,721行の変更」と受け取る場面も置かれている。Muiruriはこの状態を「レビューが難しくなり、そのまま……放置される」と書いている。

層に分けると、4本のブランチ（4層）からなる1つのスタックになる。L1がデータカタログの基盤、L2が商品検索API、L3がチャットからAPIへの接続、L4がUIと引用表示である。それぞれのPRは「レビュアーの頭の中に収まるだけの大きさ」だとされている。

切る基準は行数ではなく、層の依存関係である。データ、API、接続、UXという層があり、後の層は前の層に依存する。この依存の順にPRを並べることが、分ける基準そのものになっている。層が分かれると、層ごとに別のレビュアーへ配れる。データはデータの担当者が、UXはUIの担当者が見る³。受け取る側の読み方も示されている。上の層から読んで最終的な目的を先につかみ、下の層からレビューする。各層の実装は、その前の層を理解して初めて意味をなすからだ³。

手順も具体的に示されている。gh extension install github/gh-stackとgh skill install github/gh-stackでツールを入れ、スタックの土台となるブランチ(通常はmain)を決め、基盤となる層を最も下に置いて依存の順に層を並べる。コードを書くのはその後で、層ごとに担当のエージェントを呼び、gh init stackやgh stack addでその層のブランチを作って書かせ、検証が通れば層をコミットする。4つの層が揃ってから、gh stack pushとgh stack submitでPRにする。下の層に修正が入ったときは、gh stack syncが取得、上位ブランチの連鎖リベース、押し出し、PR状態の同期をまとめて行う。Muiruriはこの仕組みを、手順に先立って「これは、あなたとあなたのエージェントに、そうしなければ1本の巨大なPRに収まってしまう作業を、小さく焦点の定まった、独立にレビューできる層の連なりへ分解する、GitHubに組み込みの方法を与える」と説明している。

なお、こうしたスタックの運用は専用のツールを前提にしている。GitHubの手順そのものがCLI拡張の導入から始まるし、GitHub以外のホスティングで同じことをするなら別のツールが要る。git-spiceのドキュメントは、スタックしたGitブランチを管理し、トランクブランチとの同期、依存するブランチの再スタック、変更がマージされた際のブランチの付け替えを自動化すると述べている。対応先はGitHubのほか、Bitbucket、Gitea、Forgejo、Azure DevOps、GitLabにも及ぶとしている⁵。

運用を変えたプロジェクトは、コードの前で切った

tldrawは、tldraw/tldrawリポジトリのCONTRIBUTING.mdで、次のように書いている。「私たちは現時点でtldrawへの貢献を受け付けていません。このリポジトリではプルリクエストは無効になっています」¹。

その代わりに求めているのは、「issueを作成すること」である。CONTRIBUTING.mdは理由をこう説明する。「issueはチームと提案された変更について議論する最善の場所であり、私たちはそのすべてに目を通しています」。コード例が議論の助けになる場合には、「リポジトリをフォークし、issueの中で自分のブランチにリンクすること」を求めている。詳しい経緯についてはissue #7695を参照するよう案内している。2026年1月15日のそのissueで、創業者のSteve Ruizは、AIツールだけで生成された貢献が大きく増え、その多くはコンテキストが不完全か誤解を招くもので、作者の追跡もほとんど無いと書いている¹。開いたPRは、注意深くレビューして取り込みを真剣に検討するというメンテナーの約束を意味するので、その約束を保つにはより選別する必要がある、とも説明している¹。

この切り方は、GitHubの手順とは切る人が異なる。GitHubの手順では、書く側が作業を先に層へ分け、層ごとにエージェントが書く。tldrawの停止では、受け取る側が入り口に切れ目を置く。受け取るのは意図と議論であって、仕上がった差分ではない。

latent.spaceの記事、2026年9月1日公開、著者Richard MacManusは、この動きを他のプロジェクトと並べて報告している²。Astroの自動トリアージの仕組みは、そのままSchottが新しいエージェントフレームワークFlueを作ることにつながった。Flueは外部からのプルリクエストをすべて自動でクローズし、issueまたはdiscussionへ変換しており、Flueの貢献者ガイドは「通りすがりのAIスロップPR」を防ぐことを目的として挙げているという。tldrawについては、Ruizの発言を引いている。Ruizはこの変更を「私たちのコーディングの仕方の変化(より多くの議論、より多くのエージェント)、公開の場での貢献をめぐる社会的慣行、そしてコードセキュリティを取り巻く状況の変化に応じて下した、意図を持った判断」と呼んでいる。Ruizは別の発言で、issueが十分に書かれていてエージェントがコードを書けるなら、人にコードを寄せてもらう意味は薄れると述べ、貢献は報告・議論・視点・気遣いという、まだ意味のある場所に絞るほうがよいとも言っている。MacManusもtldrawの節に「エージェントがコードを書くなら、外部PRは価値を失う」という見出しを付けている。tldrawについて挙がる理由は、届く量と外部からのコードの価値の両方にまたがる。MacManusは同じ記事で、Vercelの AI SDKとAstroは正式にプルリクエストを閉じてはいないものの、コミュニティからの貢献を減らす方向のエージェント駆動の仕組みを導入したとも報じている。この並びをMacManusは、外部からの差分を受け取る代わりにメンテナー自身のエージェントにPRを作らせて管理させる選択として描いている²。

閉じた経路の代わりが効くかは、まだ分からない

受け付ける入り口を閉じたとき、そこを通っていたものはどこへ行くのか。latent.spaceの記事は、後継者の問題を挙げている。挙げているのは、Flueで入り口を最も徹底して閉じた本人であるSchottである。Schottは「プロジェクトを絞り込み続けたとして、ある時点であなたと私が休暇に出たら、何が起きるのか」と問い、これですべての問題が解けるわけではないと述べている²。

MacManusは、外部からのプルリクエストをレビューする工程が、貢献者を育て、次のメンテナーを見つける経路になっていたと指摘している。ただし同じ記事は、この懸念に解がありうるとも書いている。FlueもtldrawもPRは受け付けないが、issueとdiscussionは受け付けている。互いに話す量が増えれば、コミュニティの側は互いを知り、信頼するようになる。それは仲間から学ぶ道であり、メンテナーにふさわしいと自ら示す道にもなりうる、という見立てである²。tldrawは1月の告知で、この停止を、GitHubがよりよい管理のツールを出すまでの一時的な方針と書いていた¹。latent.spaceの記事は、Ruizが5か月後に同じ方針を改めて示したと伝えている²。閉じた経路の代わりが機能するかどうかは、まだ観測されていない。

量を減らす案は、まだ主張にとどまる

分割も、受付停止も、届く単位の切り方を変える手だった。martinfowler.comに掲載された記事、2026年9月2日公開、著者Rachel Laycock(Thoughtworks CTO)は、切る場所ではなく、人間が検査する対象の量そのものを問うている⁴。

Laycockはこう書く。「エージェントが10倍のコードを生み出せたとしても、そのすべての行が結局はシニアエンジニアの検査を待つ列に並ぶのなら、私たちは10倍のエンジニアリング組織を作ったのではなく、大きな滞留と新しいボトルネックを作ったのだ」。全数を人間の検査に通す運用が残るかぎり、滞留は解消されないという指摘である。Laycockは分割や積み重ねには触れていない。彼女が答えではないと名指しするのは、人間のレビュアーのふりをするAIエージェントを置いて同じ工程を高速に回すことであり、それは儀式が存在する理由を問わずに儀式を自動化することだ、と書いている⁴。

Laycockが提案するのは「例外によるレビュー」である。人間によるレビューを残すのは、アーキテクチャの変更、セキュリティの境界、不確実性のある領域といった、リスクの高い変更に限る。それ以外については、こう書く。「フォーマットやリンティング、既知のセキュリティ上の問題、あるいは決定的にテストできる事柄についてコードをレビューしているのなら、それらは自動化すべきだ」。

Laycockが求めているのは、人間の判断をコードが出来上がった後の検査ではなく、もっと早い工程、ペアプログラミング、設計の議論、自動テスト、静的解析へ移すことである。

Laycockは他所の数値も挙げているが、それは彼女自身の測定ではなく、Code Remixのパネル討論で意見が分かれた相手、DXのBrian Houckが示した数字である。Metaでは「人間が着地させた1差分あたりの実質的なコード行数が、1年で106%増加したと報告されている」とされ、この「報告されている」という語はLaycockのものである。DX自身のデータとして「プルリクエストの中央値のサイズが64%増加している」とも紹介している。これらの数値をLaycockが置いているのは、AIが人の読める量を超えてコードを書くという、二人に共通する前提の側であって、レビューを減らすという彼女自身の提案の裏付けとしてではない。

martinfowler.comの記事が応答している相手は、Houckが書いた「コードレビューはそもそも何のためにあるのか」という一文であり、Houckの懸念は、レビューを自動化で外すと知識の共有や若手の育成、共同所有、アーキテクチャ理解の伝播といった他の役割まで失われることにある。Laycockはその懸念を共有すると書いたうえで、なぜそれらをコードレビューまで待って行うのかと問い返し、Houckが挙げる「認知と意図の負債」は実在する問題だと認めつつ、必須のプルリクエストはその防御として強くないと答えている⁴。

分割、受付停止、例外によるレビューは、切れ目を置く位置こそ異なるが、どれも行数ではなく、その領域で判断の単位になる境界を切り口に選んでいる。GitHubの手順は層の依存で、tldrawの停止は意図とコードの間で、Laycockの案はリスクの高低で切る。そのうえで、運用を変えたと報じられた側は、仕上がった差分を受け取る入り口を狭めるか閉じている¹²。

この記事はAIを使用して執筆されました。内容には誤りが含まれる可能性があります。事実や数字の出典は脚注から確かめられます。