# PRレビューが遅くなるのはなぜか？ > PRレビューが遅いのはなぜ？GitHub 334万件のデータから読み解く“PRレイテンシ”ガイド。 - 公開日: 2025-07-18 - 更新日: 2025-07-18 - 著者: 南部旭彦 - タグ: QA, コードレビュー, プロジェクトマネジメント - URL: https://tech.anycloud.co.jp/articles/why-pr-reviews-are-slow --- とあるプロジェクトで、レビューが溜まってしまうことが課題として挙げられていました。今回は、下記の論文をもとに、改善点を整理してみます。 *出典: Zhang et al., “Pull Request Latency Explained: An Empirical Overview,” Empirical Software Engineering (2022).* （以下「Zhang+2022」と表記） ## まずはポイント - PRが *Open* されてから *Close*（マージ／クローズ）されるまでの経過時間（= PRレイテンシ）は、“いつ・どんな状況で測るか”によって効いてくる要因がガラッと変わる。 - PRを開いた直後（提出時点）では、PRの規模（コード変更量）、説明文の長さ、投稿者の経験、レビュワー側の未処理PR数（ワークロード）など“準備段階”の要因が強く効く。 - PRが閉じる段階（クローズ時点）では、コメント往復・追加コミット・CI結果といった“レビュー過程”で発生する動的要因が効いてくる。 - コメントが付いたPRでは「初回レスまでの時間」がレイテンシを大きく左右。早い一次応答が重要。 - CIを使っているプロジェクトでは「ビルド所要時間」「CI失敗の再実行」が遅延要因。CI高速化はレビュー高速化でもある。 ## この論文について現場感覚でも“レビューが詰まっている”“誰も見てくれない”といった課題は多いですが、レイテンシは複数フェーズ（提出 → レビュー → 修正 → マージ/却下）で発生するため、どこがボトルネックかを定量化して初めて改善できます。 Zhang+2022は、そのボトルネック要因を網羅的に洗い出し、文脈別に比較しています。対象は、リポジトリ数11,230、分析PR数3,347,937、検討要因63種類（コード規模、経験、コメント、CI、プロジェクト負荷など）に及んでいます。 ## 文脈別：主要因ランキング以下は論文で示唆された「相対的重要度が高かった上位因子」を、実務で扱いやすい形に訳したものです。 ### 1\. 提出時点（PR Open 時）

ランク	要因（ざっくり）	実務的解釈	改善のヒント
1	PR説明文の長さ	目的・背景・変更内容が長すぎるとレビュワー負荷↑	冒頭サマリー＋詳細は折りたたみ
2	ソースコード変更量（churn）	変更行数・ファイル数が大きいほど時間↑	小さく分割、Stacked PR戦略
3	投稿者の過去PR経験	経験豊富な投稿者は手戻り少なく速い	コントリビューションガイドで新人を支援
4	レビュワーのアクティビティ/空き	アクティブでない/多忙だと遅延	レビュー割当を分散、SLA設定
5	未処理PR数（バックログ）	レビュー待ち行列が長いほど遅れる	キュー可視化＆優先度付け

### 2\. クローズ時点（最終段階）

ランク	要因	実務的解釈	改善のヒント
1	コメント有無	コメント＝議論・修正発生	初回レスSLIを設定、FAQテンプレ
2	提出者=統合者か	自分でマージできると速い、他人依存で遅れる	Self-mergeポリシー、保護ブランチ調整
3	説明文長（継続）	議論時にも参照される	冒頭要約を更新
4	コードコメント数	差分議論が多い＝再修正ループ	Pre-commit lint/formatで機械的指摘削減
5	コミット数（最終）	修正のたび増え、レビュー再実行	Fixup→Squashで履歴整理

### 3\. コメントが付いたPR（has comments = true） - 初回コメントまでの時間\*\*が決定的。誰かが最初に反応するだけで心理的・実務的に処理が進みやすい。 - コメント総数／コードコメント数が増えるとレイテンシも伸びやすい（議論長期化）。 #### 即効施策 - Botや自動ラベルで「レビュー受け付けました」即時応答。 - 初回軽量レビュー（表面チェック）と本格レビューを段階分離。 ### 4\. CIを利用しているPR - CIビルド時間が長い\*\*ほどレイテンシ増。 - ビルド失敗→再実行\*\*のループが遅延を悪化。 #### 即効施策 - キャッシュ・並列化・テスト分割でCI高速化。 - フレーク対策（再試行自動化、失敗分類）。 - Pre-push / pre-PRローカルチェックで初期不良を減らす。 ### 5\. 提出者と統合者（マージ権限保持者）が異なるPR OSSや外部コントリビューションで典型的なケース。相手とのコンテキスト共有が薄いほどコメント往復が増えレイテンシが伸びる傾向。 #### 即効施策 - PRテンプレートで「背景・再現手順・スクリーンショット・リリース影響」を必須化。 - 自動ラベルで担当チームを早期特定。 - メンテナの“レビュー受付時間帯”をREADMEで明示。 ## レイテンシ改善チェックリスト（現場向け）以下はZhang+2022の知見をベースに、筆者が現場適用しやすい形に整理したチェックリストです。導入優先度は★で示します（★=効果小～★★★★★=効果大見込み）。 ### **A. PRを小さく・明瞭に（★★★★★）** - 1機能1PR。巨大なリファクタ＋機能追加は分割。 - “What / Why / How / Testing” の4段構成テンプレ。 - 変更が多い場合はスクリーンショットやGIFで差分共有。 ### **B. 初動レス高速化（★★★★★）** - PR作成時に自動でレビュワー割当。 - 「24時間以内に一次反応」SLA。 - Botで“レビュー受領・CIキック済み”を即コメント。 ### **C. CI待ち時間削減（★★★★☆）** - 差分テスト（changed pathsだけ実行）。 - キャッシュと分散ビルド。 - フレークテスト隔離と自動再試行。 ### **D. レビューキュー可視化（★★★★☆）** - ダッシュボードで未処理PR数・平均待ち時間を共有。 - SLA超過PRをハイライト。 ### **E. コントリビュータ育成（★★★☆☆）** - 新規参加者向けに「最初のPRガイド」。 - Coding Style / Lint / テストガイドを簡潔に。 ### **F. コメントノイズ削減（★★★☆☆）** - 自動整形（Prettier/clang-format）。 - Lint違反はBotでまとめて指摘（人間レビューを本質議論に集中）。 ## 実装アイデア：メトリクスでボトルネックを見える化

メトリクス	定義	ダッシュボード例	注意点
PRレイテンシ（全体）	Open→Close の総時間	中央値/分位数	極端値に注意
初回レス時間	Open→最初の人間コメント	SLA監視	Botコメントを除外/区別
レビュー反復回数	コミット再Push数 or レビューラウンド数	手戻り把握	オートマージ時の扱い
CI待ち時間	ジョブ開始→完了	並列化効果測定	失敗再実行を区別
レビューキュー長	未処理PR件数	負荷バランス	古いPRの掃除