7月13日、Tom Smithが「GitHub's Redesigned PR Inbox Tackles the Review Bottleneck AI Created」と題した記事を公開した。AIコーディングツールの普及でPRのマージ数が98%増加した一方、レビュー時間は91%増、PRの平均サイズは154%増という深刻な非対称が生まれている。GitHubはこのレビューボトルネックに対処すべく、刷新版プルリクエストダッシュボードを正式に一般提供（GA）した。
AIがPRを量産した結果、レビューが詰まった
AIコーディングツールの普及は、コードの生成速度を上げた一方で、別の問題を生み出した。PRのレビューが追いつかなくなっているのだ。
Faros AIが1万人超の開発者を対象に行ったテレメトリ調査（※開発ツールから自動収集したログデータを分析する手法）によると、AIを積極的に活用しているチームはPRのマージ数が98%増加した。しかし同時に、PRのレビュー時間は91%増、PRの平均サイズは154%増となった。LinearBが810万件のPRを分析した2026年の調査でも同様の傾向が確認されており、開発者はAIツールで約20%速く作業できると感じているが、レビューキューを含めたエンドツーエンドのサイクルタイム（※コードを書き始めてから本番環境にマージされるまでの総所要時間）は実際には約19%遅くなっている。
コード生成が速くなっても、ボトルネックはなくならない。下流のレビュー工程に移動しただけだ。
GitHubが新ダッシュボードをGA（一般提供）開始
GitHubは2026年3月から段階的にロールアウトを進めてきた刷新版プルリクエストダッシュボードを、正式に一般提供（GA：General Availability、ベータや限定公開を経て全ユーザーへ正式提供される段階）した。github.com/pullsから全ユーザーが利用できる。なお、GitHubのプルリクエスト機能全般についてはGitHub公式ドキュメントも参照されたい。
中核となる機能はInboxだ。レビュー依頼、CIの失敗や新コメントによって対応が必要なPR、マージ待ちのPRを一画面に集約して表示する。セクションの並び替えや非表示、リポジトリや最近のアクティビティでのフィルタリングも可能で、自分のワークフローに合わせてカスタマイズできる。
もう一つの主要機能が保存ビュー（Saved Views）だ。よく使う検索クエリをビューとして保存・管理できる。ブラウザのブックマークに頼っていた運用を置き換えるものになる。デフォルトでは「自分が作成したPR」「自分にアサインされたPR」「自分が関係するPR」「レビュー依頼されたPR」の4種が用意されており、コンテンツアシストやオートコンプリートも備える。
複数Orgをまたいだ検索と、エージェントPRの帰属
複数のOrganizationにまたがってPRを管理している開発者向けに、検索構文もアップデートされた。AND/ORロジックとネストクエリをサポートし、以下のような書き方が可能になった。
(org:github AND author:@me) OR (org:dizzbot assignee:mona)
一つの検索で複数のOrganizationの結果を横断できる。
また、今回のGAで加わった変更の中で特に目を引くのが、エージェントが作成したPRの帰属への対応だ。author:@meで検索すると、開発者がGitHub Copilotに指示して開くよう依頼したPRも返ってくるようになった。AIエージェントが書いたコードが正式に"その開発者のPR"として扱われる仕組みだ。
その他のGA時点での追加機能は以下の通り。
j/kキーボードショートカットでリストを移動可能team-review-requested-userフィルター：チームとしてレビューを依頼されたPRを絞り込むreview-involvesフィルター：承認状態によらず、レビューを依頼されたPRをすべて表示
チームレビューの「誰かがやるだろう問題」に対処
ダッシュボードが地味に効いてくる点がある。「自分へのレビュー依頼」と「チームへのレビュー依頼」をセクションとして分離して表示するようになった点だ。
チームへのレビュー依頼は、全員が「誰かが対応するだろう」と思い、誰も手を付けないまま放置されがちだ。この滞留を共有キューに埋もれさせず、明示的に可視化することで、レビューの流れが変わりうる。
ダッシュボードで解決できることの限界
The Futurum Groupでソフトウェアライフサイクルエンジニアリング担当VPを務めるMitch Ashleyは次のように指摘している。
「GitHubがPRのトリアージ（※大量のタスクを緊急度・重要度で仕分けし、対応順を決める優先度分類のプロセス）サーフェスを提供したことは、レビューが今やボトルネックであることを裏付けている。キューは人間がさばけるスピードより速く積み上がっている」
「エンジニアリングリーダーは、コード生成と同じくらい意図的にレビュー処理能力を管理しなければならない。レビューがどこで詰まっているかを計測しているチームは、AIによる速度向上をリリースに変換できる。レビューをオーバーヘッドとして扱うチームは、その成果がキューの中で止まるのを見ることになる」
ダッシュボードはあくまでトリアージを助けるものだ。PRの生成速度がレビュー速度を上回っている構造的な問題は変わらない。記事では、ダッシュボードによる整理に加えて、AIによるレビュー支援ツールを組み合わせ、些細な問題を人間がPRを開く前に検出することで、レビュアーの時間を本質的な判断（抽象化が複雑さに見合うか、6ヶ月後も保守できるコードかどうか）に集中させる方向性も言及されている。
詳細はGitHub's Redesigned PR Inbox Tackles the Review Bottleneck AI Createdを参照していただきたい。
