「レビューが追いつかないんです。AIにコードを書かせる量は増えたのに、それを見る人間の時間は増えていなくて」——AIエージェントを開発に組み込んだチームから、最近こういう相談を受けます。コードを書く速度はAIで何倍にもなった。けれど、その変更が正しいかを確かめてマージを判断する「レビューする側」の帯域は、人間のままです。生産の蛇口だけ太くして、検査の蛇口は元のまま。結果、レビュー待ちのプルリク（PR）が詰まり、品質の確認が形骸化していく。
この問題は、オープンソースの世界ではもっと露骨な形で表面化していました。GitHubは2026年6月、書き込み権限を持たないユーザーが一つのリポジトリで同時に開けるPRの数に上限を設定できる機能を追加しました。背景にあるのは、AIが生成した玉石混交のPRがメンテナーに押し寄せ、選別しきれなくなっているという現実です。この機能は、受託開発の現場でレビュー帯域をどう守るかを考える、いい題材になります。
なぜ「PRの数を絞る」必要があったのか
GitHub上でマージされるPRは月間9千万件を超え、その伸びにはAIツールによる量産が含まれています。問題は数そのものより、価値のある貢献と、とりあえず作っただけのノイズを見分けるコストが、受け手に重くのしかかることです。とくにボランティアで支えられるオープンソースのメンテナーにとって、玉石混交のPRを一つひとつ評価する負担は限界に近づいていました。
GitHubの上限機能は、この「受け手の処理能力」を守るための仕掛けです。具体的には次のような設計になっています。
- 書き込み権限のないユーザーが同時に開けるPR数に上限を設け、上限に達したら既存のものを閉じるかマージするまで新規を作れない
- CopilotなどAIエージェントが作ったPRも、この上限のカウント対象に含まれる
- 下書き（ドラフト）状態のPRは上限にカウントしない
- 信頼できる貢献者はバイパス（適用除外）リストに載せ、フルの権限を与えずに上限だけ外せる
注目すべきは、これが「AIを禁止する」機能ではない点です。AIによる貢献を一律に締め出すのではなく、受け手が処理できる量に流入を合わせる、という発想で設計されています。
受託開発に引き写すと何が見えるか
この考え方は、オープンソースだけの話ではありません。受託開発で社内のエンジニアやAIエージェントが大量のPRを上げる構図は、まったく同じです。違うのは、外から来る無関係なPRではなく、自分たちのチームが生んだPRがレビュー帯域を圧迫する、という点です。
ここで効くのは、PRの数を物理的に絞ることより、「レビューに値する状態」になってからレビューを依頼させる設計です。GitHubがドラフトPRを上限から除外したのは示唆的で、「まだ見てもらう段階じゃないもの」と「人間の判断を求めるもの」を分けています。AIに大量に書かせるのは構わない。ただし、人間のレビュー枠を使うのは、本人（または担当者）が一度通して読み、自信を持って出せるものに限る——この線引きを仕組みにできるかが分かれ目です。
| レビュー帯域を圧迫する状態 | 帯域を守る設計 |
|---|---|
| AIの出力をそのままPRにして人に投げる | 出した本人が一度通読・自己レビューしてから依頼 |
| 全PRが等しくレビュー待ち列に並ぶ | ドラフトと正式依頼を分け、依頼は完成品だけ |
| 誰のPRも無制限に積み上がる | 信頼できる出し手とそうでない経路を区別する |
「AIが書いたから速い」の責任は誰が持つか
もう一つ、受託で外せない論点があります。AIが生成したコードのPRを、誰が責任を持ってレビューし、マージを判断するのか、です。「AIが書いたものなので中身は把握していません」というPRが流れてくると、レビュアーは事実上ゼロから他人のコードを読むことになり、レビュー負荷はむしろ増えます。AIで速くなったはずが、検査の遅さで相殺される。
だからこそ、AI生成PRには「出した人間が内容を理解し、説明できる」ことを前提条件として課す必要があります。これは技術ではなく運用とルールの問題です。AIによる自動化をどこまで受け入れ、どこから人間が責任を持つかという線引きの話は 「AIで自動化できます」の責任は誰が飲むのかを論じた記事 と地続きですし、AIで安く速く作れるという前提の実際については 2026年の受託開発の実際を扱った記事 でも触れています。
弊社があるチームのレビュー詰まりを相談されたときは、PR数の上限を機械的にかけるより先に、ドラフトと正式依頼の分離と、「正式依頼には変更の意図と確認したことを一行書く」というルールを入れました。AIの出力を貼っただけのPRは、この一行が書けない。書けないものは正式依頼に上げられないので、自然とレビュー枠が完成品に絞られます。ツールの上限機能は、こうした運用設計を補強する道具として効いてきます。
まず見るべきは「レビュー待ちの列」
自分のチームのPR一覧を開いて、レビュー待ちがどれだけ積み上がっているか、そのうちどれだけが「実は中身を出した本人も把握していない」ものかを数えてみてください。生産速度を上げる施策はもう十分にあります。次に詰めるべきは、増えた生産物を人間がさばける速度に合わせる検査側の設計です。GitHubのPR上限機能は、その必要性を制度として認めた一例として読むと、自社の運用に引き写すヒントになります。
出典: How pull request limits are cutting down the noise（The GitHub Blog） / Limit open pull requests for users without write access（GitHub Changelog）
