コードレビューの詰まり｜大手3社と査読論文17本

2026年9月13日 21:27

止まっているレビューの「当事者」に、あなたの番ですと知らせる。Microsoftがランダム化試験で確かめたところ、予測した完了時間を過ぎても止まっているプルリクエスト（PR）の平均滞留時間が197.2時間から77.7時間へ、60.62%短くなりました。Metaでも、全変更のレビュー中の時間が6.8%短くなっています（測った物差しが違うので、効果の大きさは比べられません）。

一方で、AIのレビュー支援を試した2つのランダム化試験（Google・Meta）では、待ち時間の短縮は確認されませんでした。トルコのBekoの導入前後の比較では、全体の平均がむしろ延びています（短くなったプロジェクトもあります）。

この記事は、Google・Microsoft・Metaがコードレビューの詰まりにどう手を打ち、何を気にし、AIをどう使っているかを、査読論文17本・未査読の論文2本・各社の公開文書に分けて整理したものです。国内5社の事例も並べます。全文無料です。

先に結論を3行で。

・ランダム化試験で待ちが縮むと確かめられたのは、AIではなく「止まっているレビューの当事者に知らせる」ことでした（Microsoft・Meta）
・AIのレビュー支援だけで待ちが縮むことは、試験では確かめられませんでした。Metaの試験（未査読）では、AIの修正案をレビュアーにも見せるとレビュー中の時間が5.5%延び、書き手だけに見せた別の試験では有意な差は出ませんでした
・「変更を小さくすれば速い」はOSSの研究では弱い関係にとどまり、「レビューはバグを見つけるため」は実際のコメントの中身とずれています

エンジニア6年目のぼくが、書くのが速くなった今どこで詰まるのかを、確かめられ方の違いごとに並べます。

ちなみに、このnoteも下書きはAIが書き、別に立てたレビュー役のAIが採点する形で作っています。前回の記事では、そのレビュー役が実験の書き方の誤りを「致命的」と判定し、公開前に差し戻しました。書く工程は速くなりました。止まるのは、確かめる工程です。

先に仕分け：研究のやり方と、公表のされ方は別に見る

各社の打ち手は、証拠の強さがまったく違います。ここでは「どう確かめたか（研究のやり方）」と「どこで公表されたか（査読・未査読・会社の発表）」を分けて並べます。

・Microsoft「Nudge」（止めている当事者への通知）：期限（予測した完了時間）を過ぎたPRの平均滞留 −60.62%（群の平均の比較）／ランダム化試験・査読済み
・Meta「NudgeBot」（レビューしそうな人への通知）：レビュー中の時間 −6.8%／クラスターランダム化試験・査読済み
・Google「AutoCommenter」（AIの規範チェック）：レビューの総時間に有意差なし／A/Bテスト・査読済み
・MetaのAI修正案：レビュアーにも見せると +5.5%、書き手だけなら有意差なし／時期の違う2回のランダム化した安全性試験・未査読
・BekoのLLMレビューボット：PRが閉じるまでの平均時間が延びた／導入前後の比較・査読済み
・Googleの小さな変更と1人レビュー：変更の中央値24行、待ちの中央値4時間未満／記録の集計（記述統計）・査読済み
・Googleの「1営業日以内に応答」：会社の規範（効果は測られていない）
・MicrosoftのAI一次レビュー：完了時間が中央値10〜20%改善（「初期の実験とデータサイエンスの調査による」とだけ記載）／比較の設計は示されていない・会社の発表
・Metaの「次にレビューすべき変更の推薦」：1日あたりのレビュー行動 +17%／会社の発表

この仕分けを持ったうえで、先に「自分のチームで何から始めるか」を置き、そのあと根拠を順に見ていきます。

詰まり方別：自分のチームで最初に試す一手

・止まったPRが、誰の番か分からず放置される → 止まっている件に「誰の番か」を付けて、その本人に知らせる（根拠：ランダム化試験・査読済み）
・AIで書く量が増え、レビューが追いつかない → AIの修正案は、まず書き手にだけ見せる。レビュアーの前に出す物は増やさない（根拠：Metaのランダム化した安全性試験・未査読。遅くならなかったという結果で、待ちが縮んだわけではありません）。提出前のAIセルフレビューは、国内企業の自己申告があるだけです
・往復が多く、揉める → 必須と任意（Nit）の指摘を分け、レビューの目的を「設計と読みやすさ」に置き直す（根拠：Googleの規範とMicrosoftの研究。この一手の効果そのものは未検証）
・承認されたのに、マージされない → 承認後に残っている件数を数える（根拠：OSSの観察研究。承認後の待ちが寿命の29〜63%を占めた例がある）

どの一手を打つ場合も、先に測っておくと、効いたかどうかが分かります。

・最初の反応までの時間
・レビュー中の時間の、遅いほう（P75）
・3日以上止まっている件数
・レビュアーが実際に見ていた時間（雑になっていないかの保護指標）

今後の実装付録の優先順位を決めるために、必要なものをA/B/Cの記号ひとつでコメントしてもらえるとうれしいです。

・A：レビュー待ちを測る4指標の定義表
・B：レビュー依頼テンプレ（記入例つき）
・C：応答の目安を決めるための合意チェックリスト

いただいた結果は、どの付録を深掘りするかの判断に使います。

通知は、2社のランダム化試験で待ちを縮めた

MicrosoftのNudgeは、PRが閉じるまでの時間を予測し、その予測を過ぎても終わらないPR（期限超過のPR）について、止めている当事者に通知する仕組みです（Maddila et al. 2023, ACM TOSEM）。

147リポジトリで、通知する・しないをランダムに割り付けて比べました。

・通知しなかった群：平均197.2時間（3,856件）
・当事者を特定して通知した群：平均77.7時間（4,383件）
・平均滞留時間は60.62%短縮。通知の73%に肯定的な反応

なお、予測だけで通知した群は平均112.6時間でした。いちばん大きく縮んだのは、止めている当事者の特定と活動の検出まで加えた版です。数字は群の平均を比べたもので、統計的な検定は報告されていません。長引いた一部のPRが平均を押し上げやすい指標でもあります。

ただし、対象は予測を過ぎて止まっているPRに絞られています。全PRの待ちが6割減るという意味ではありません。

MetaのNudgeBotも、同じ考え方を別の会社で試しています（Shan et al. 2022, ESEC/FSE）。3万人超のエンジニアを対象にしたクラスターランダム化試験の結果は、次のとおりでした。

・レビュー中の時間：−6.8%（p=0.049）
・3日を超えて止まる変更の割合：−11.89%（p=0.004）
・最初にレビュアーが反応するまでの時間：−9.9%（p=0.010）

60.62%と6.8%では、ずいぶん違って見えます。これは物差しの違いです。Nudgeは期限を過ぎたPRの平均寿命、NudgeBotは全変更のレビュー中の時間を測っています。向きは同じで、2社のランダム化試験がそろって「知らせると縮む」を示しました。ただし2本には同じ研究者が関わっていて、NudgeBotはNudgeを先行研究として参照しています。独立した追試とまでは言えません。

ぼくが面白いと思ったのは、Nudgeでは「誰がボールを持っているか」の特定と活動の検出を加えた群で、効果がいちばん大きくなったことです。2つを同時に加えた版なので、どちらが効いたのかは分けられません。それでも、通知の宛先をはっきりさせることは効いていそうです。誰の番か分からないまま放置されることが、詰まりの大きな一因だと読めます。

Googleが気にしていたのは、バグ探しより読みやすさと規範

Googleのレビューを調べた論文によると、社内のレビューは驚くほど軽量です（Sadowski et al. 2018, ICSE-SEIP）。約900万件のレビューを分析した結果、変更行数の中央値は24行、レビュアーの中央値は1人、レビュー全体の待ちの中央値は4時間未満でした。

では、Googleはレビューに何を期待しているのか。インタビューから出てきたのは、次の4つでした。

・教育（ほかの人が読めるコードを書けるようにする）
・規範の維持（書き方・設計の約束を守る）
・ゲートキーピング（誰が変更してよいかの線引き）
・事故の防止

バグ探しは、この中の一部にすぎません。

公開されているGoogleのレビューガイド（Google Engineering Practices）も、同じ価値観で書かれています。応答は「1営業日」が上限で、それは翌朝いちばんを意味すると明記しています。レビューでいちばん大事なのは設計だとも書いています。完璧でなくても、コードの健全さを確かに上げる変更なら承認を優先すべきだ、という方針です。

任意の指摘には「Nit:」と付ける作法もあります。磨き上げの提案なので、直すかどうかは書き手に委ねる、という合図です。

Microsoftの研究も同じところに行き着いています。レビューに期待するものの1位は欠陥の発見でしたが、実際のコメント570件のうち欠陥の指摘は14%で、最多はコードの改善（29%）でした（Bacchelli & Bird 2013, ICSE）。

別の報告でも欠陥の指摘は約15%（Czerwonka et al. 2015, ICSE-SEIP・2ページの講演抄録）、OSSの2プロジェクトでは保守性と機能がおよそ75対25です（Beller et al. 2014, MSR）。

Googleは公平さも気にしていて、書き手の名前を隠すフィールド実験までしています。速さにも品質にも有意な差は出ず、名前を隠しても、通常のレビューでは約77%の確率で書き手を言い当てていました（readabilityの審査では4.6%。Murphy-Hill et al. 2022, IEEE TSE）。

「小さくすれば速い」は、半分だけ正しい

Googleの変更は小さい。複数の組織を比べた研究でも、変更の中央値は多くのプロジェクトで数十行と小さく、レビュアーは中央値2人に収束していました（Rigby & Bird 2013, ESEC/FSE）。ここまでは「小さくすれば速い」を支持しているように見えます。

ところが、GitHubの人気100プロジェクト、82万件超のPRを調べた研究では、PRの大きさとマージまでの時間の関係はr_s=0.26でした（Kudrjavets et al. 2022a, MSR）。関係はあるけれど弱い、という目盛りです。

著者たちの結論はこうです。小さく分けると受け入れられやすくなり、レビューもしやすくなるかもしれない。けれど、レビューやマージにかかる全体の時間は縮まらない。

同じグループの別の研究は、待ちの中身を分解しています（Kudrjavets et al. 2022b, MSR）。承認されたあと、マージされずに放置されている時間が、あるツール（Phabricator）では変更の寿命の29〜63%を占めていました。別のツール（Gerrit）では1%以下です。

どちらもOSSの観察研究なので、そのまま企業に当てはめることはできません。それでも、ぼくはこう読んでいます。小ささは速さの材料の一つにすぎず、Googleの速さは「1営業日」の規範や、担当がはっきりしている仕組みと組み合わさった結果だと。この組み合わせを検証した研究は、今回調べた範囲では見つかりませんでした。

Microsoftが911人に聞いた調査では、レビューの課題の1位が「タイムリーなフィードバックが得られない」、2位が「レビューの大きさ」でした（MacLeod et al. 2018, IEEE Software）。大きさも課題です。けれど、いちばん上に来たのは待ちでした。

AIを入れても、待ちの短縮は確かめられなかった

まず前提として、書かれるコードの量そのものが増えています。Metaの論文によると、人が取り込んだ変更1件あたりの行数は前年比+105.9%、1人あたりの変更件数は+51%でした。その増加の8割以上がエージェント型AIによるもので、同じ期間に、すぐレビューされる変更の割合は下がっていました（Adams et al. 2026・未査読の論文）。

では、AIでレビューを手伝えば解決するのか。査読やランダム化試験で確かめられた範囲では、答えは「それだけで縮むとは確かめられていない」でした。

Googleの例。AutoCommenterは、書き方の規範に反する箇所をAIが指摘する仕組みです（Vijayvergiya et al. 2024, AIware）。有用と評価される割合は54%から80%まで改善しました。

それでも全開発者の約半数で行ったA/Bテストでは、レビューの総時間にも往復の回数にも有意な差は出ませんでした。改善したのは、書く側の速さがわずかに、という程度です。

Metaの例。レビューコメントに対するAIの修正案を、ランダム化した安全性試験で確かめています（Maddila et al. 2025・未査読の論文）。修正案をレビュアーにも見せた1回目の試験では、レビュー中の時間が+5.5%（p=.029）、レビュアーが見ていた時間が+6.7%（論文の表の値・p≪.001）に延びました。

そこで修正案を書き手にだけ見せる形に変えた2回目の試験では、有意な差は出ませんでした（レビュー中の時間+0.42%・p=.86、レビュアーが見ていた時間+1.24%・p=.66）。この回、レビュアーの画面では修正案を折りたたみ、開けば見られる形でした。2回は時期が別の試験で、2つの見せ方を同じ試験の中で直接比べたものではありません。

Beko（トルコの家電メーカー）の例。LLMのレビューボットを実際に導入した研究です（Cihan et al. 2025, ICSE-SEIP）。ボットのコメントの73.8%には「対応済み」が付きました。

一方で、PRが閉じるまでの全体の平均時間は5時間52分から8時間20分へ延びています。ただし3つのプロジェクトのうち1つでは、6時間6分から3時間7分へ短くなっていました。導入の前後を比べた研究なので、ボットが原因かどうかは分けられません。

MozillaとUbisoftの例。LLMが生成したレビューコメントが実際に採用された割合は、8.1%と7.2%でした（Olewicki et al. 2026, IEEE TSE）。書き方や構造の指摘は18%台で採用された一方、機能の正しさに関する指摘は5%前後にとどまりました。

Microsoftは、AIの一次レビューを社内PRの90%超に使い、5,000リポジトリで完了時間が中央値10〜20%改善したと公表しています。ただし根拠は「初期の実験とデータサイエンスの調査による」とだけ書かれた会社のブログで、比較の設計は示されていません。査読済みの試験と同じ棚には置けない数字です。

ここで思い出すのが、前回の自分の実験です。AIが画面の移植を書き終えるのに25〜32分。元と同じか確かめる工程には約50分かかりました（AIの作業時間どうしの比較で、人手との比較ではありません）。AIがレビュアーの前に出す物を増やすと、確かめる仕事が増える。Metaの2回目の試験で、見せる相手を書き手に絞ったときに有意な差が出なかったのは、この構造と同じ向きに見えます。

Metaは、速さと一緒に「雑になっていないか」も測っていた

Metaは、レビュー時間の遅いほう（上位25%、P75）と開発者の不満に相関があることを見つけ、ここを改善の目標にしました。同時に、速さを追うとレビューが形だけになる危険も書いています。そこで、レビュアーが実際に変更を見ていた時間「Eyeball Time」を、悪化させてはいけない保護指標として置きました（Meta Engineering blog, 2022）。

NudgeBotの試験でも、こうした保護指標に有意な悪化はありませんでした。AIの修正案を試したときも、最初に「レビューを遅くしないか」を安全性試験で確かめています。

品質の側の研究もあります。OSSの3プロジェクトでは、事後の欠陥と一貫して結びついていたのは「レビューしたかどうか」より「どれだけ議論に参加したか」のほうでした（McIntosh et al. 2016, EMSE）。

Googleは、摩擦の予兆まで数えています（Egelman et al. 2020, ICSE）。往復が9回以上、レビュアーの作業が48分超、書き手の対応が112分超。3つとも当てはまった変更では、書き手が「いら立ち」を報告した割合が27%で、どれにも当てはまらない変更の1%から大きく上がりました。変更の大きさなどを考慮したオッズ比では約45倍です。

ただし、この目安に引っかかった変更の多くでは、その種類の摩擦は報告されていません（感じ方の種類ごとの適合率は6〜11%。抽出の偏りのため、全体ではもう少し高くなると著者は注記しています）。見逃しは少ないけれど空振りも多い目安で、関連であって因果でもありません。

国内5社：AIをどこに置き、何を測ったか

国内の開発ブログにも、同じ構図が出てきます。いずれも会社の自己申告です。ここでは「AIをどこに置いたか」と「何を測ったか」をそろえて並べます。

・ラクス：AIに12機能を実装させたら、変更ファイルが700を超え、サーバー側のレビューだけで5営業日かかった。層の中の責任分担を事前に決めていなかったため、同じ指摘を機能の数だけ受けた（2026年9月。測ったもの：レビューにかかった営業日数。改善後の再測定はなし）
・LINEヤフー：レビューが2人に集中する「レビュー渋滞」に対し、AIが変更の要約と論点を先に出す運用を導入。ワークショップ前後の社内アンケートで、AI活用率は45.0%から68.5%に（2025年11月。測ったもの：アンケート。レビュー時間は「明らかに短縮」との記述のみで数値なし）
・SmartHR：レビューの前にAIでセルフレビューし、人のレビューの負担を下げる。1ストーリーポイントあたりの作業時間は約2時間から1時間未満に（2026年6月。測ったもの：全体の作業時間で、レビューだけの時間ではない）
・サイバーエージェント：AI導入でコミット数が約2倍になった中、ガイドラインとテストの強化、複数のAIレビューを組み合わせた（2025年12月。測ったもの：コミット数とテスト比率。レビュー時間の数値はなし）
・freee：自前のAIレビューはコストとノイズで行き詰まり、商用ツールに切り替えて約500人が利用（2025年12月。測ったもの：利用人数。レビュー時間短縮の数値はなし）

5社とも、レビュー時間そのものの変化は数値で示していません。AIの置き場所でいえば、SmartHRのセルフレビューは、レビュアーでなく書き手の側にAIを置くという点で、Metaの試験と同じ向きです（Metaが試したのは提出後の修正案、SmartHRは提出前のセルフレビューという違いはあります）。

この記事の限界

・企業での実証は、そもそも薄いです。レビューの成果を測った研究48件のうち、85.4%はOSSのデータで、企業のデータは10.4%でした（Davila & Nunes 2021, JSS）
・強い証拠は、実験の仕組みを持つ大企業の自社研究に偏っています。うまくいった施策ほど公表されやすい、という偏りも考えられます
・Metaの2本（AIの修正案、書く量の増加）は未査読の論文です。採択されたとする情報はありますが、ここでは未査読として扱いました
・会社のブログや国内事例の数字は自己申告で、比較の設計が示されていません
・書き手自身の制作体験は、導入の実感として書いたもので、証拠には含めていません

おわりに

「働き方×科学」のシリーズとして、職場の悩みを査読論文で確かめる記事を続けています。フォローしてもらえると、次の記事がすぐ届きます。

記事の途中で聞いたA/B/Cへのコメントも、次の記事づくりに使わせてもらいます。

参考文献

査読論文（17本）

・Sadowski, C., Söderberg, E., Church, L., Sipko, M., & Bacchelli, A. (2018). Modern Code Review: A Case Study at Google. ICSE-SEIP 2018, 181–190. DOI: 10.1145/3183519.3183525
・Egelman, C. D., Murphy-Hill, E., et al. (2020). Predicting Developers' Negative Feelings about Code Review. ICSE 2020. DOI: 10.1145/3377811.3380414
・Murphy-Hill, E., Dicker, J., et al. (2022). Engineering Impacts of Anonymous Author Code Review: A Field Experiment. IEEE Transactions on Software Engineering, 48(7), 2495–2509. DOI: 10.1109/TSE.2021.3061527
・Vijayvergiya, M., Salawa, M., et al. (2024). AI-Assisted Assessment of Coding Practices in Modern Code Review. AIware 2024. DOI: 10.1145/3664646.3665664
・Bacchelli, A., & Bird, C. (2013). Expectations, Outcomes, and Challenges of Modern Code Review. ICSE 2013, 712–721. DOI: 10.1109/ICSE.2013.6606617
・Czerwonka, J., Greiler, M., & Tilford, J. (2015). Code Reviews Do Not Find Bugs: How the Current Code Review Best Practice Slows Us Down. ICSE 2015 (SEIP), 27–28. DOI: 10.1109/ICSE.2015.131
・Maddila, C., Upadrasta, S. S., Bansal, C., Nagappan, N., Gousios, G., & van Deursen, A. (2023). Nudge: Accelerating Overdue Pull Requests toward Completion. ACM TOSEM, 32(2), 1–30. DOI: 10.1145/3544791
・MacLeod, L., Greiler, M., Storey, M.-A., Bird, C., & Czerwonka, J. (2018). Code Reviewing in the Trenches: Challenges and Best Practices. IEEE Software, 35(4), 34–42. DOI: 10.1109/MS.2017.265100500
・Shan, Q., Sukhdeo, D., et al. (2022). Using Nudges to Accelerate Code Reviews at Scale. ESEC/FSE 2022, 472–482. DOI: 10.1145/3540250.3549104
・Rigby, P. C., & Bird, C. (2013). Convergent Contemporary Software Peer Review Practices. ESEC/FSE 2013, 202–212. DOI: 10.1145/2491411.2491444
・Kudrjavets, G., Nagappan, N., & Rastogi, A. (2022a). Do Small Code Changes Merge Faster? A Multi-Language Empirical Investigation. MSR 2022, 537–548. DOI: 10.1145/3524842.3528448
・Kudrjavets, G., Kumar, A., Nagappan, N., & Rastogi, A. (2022b). Mining Code Review Data to Understand Waiting Times Between Acceptance and Merging: An Empirical Analysis. MSR 2022. DOI: 10.1145/3524842.3528432
・McIntosh, S., Kamei, Y., Adams, B., & Hassan, A. E. (2016). An Empirical Study of the Impact of Modern Code Review Practices on Software Quality. Empirical Software Engineering, 21(5), 2146–2189. DOI: 10.1007/s10664-015-9381-9
・Davila, N., & Nunes, I. (2021). A Systematic Literature Review and Taxonomy of Modern Code Review. Journal of Systems and Software, 177, 110951. DOI: 10.1016/j.jss.2021.110951
・Beller, M., Bacchelli, A., Zaidman, A., & Juergens, E. (2014). Modern Code Reviews in Open-Source Projects: Which Problems Do They Fix? MSR 2014, 202–211. DOI: 10.1145/2597073.2597082
・Cihan, U., Haratian, V., et al. (2025). Automated Code Review in Practice. ICSE-SEIP 2025, 425–436. DOI: 10.1109/ICSE-SEIP66354.2025.00043
・Olewicki, D., Da Silva, L., et al. (2026). Impact of an LLM-based Review Assistant in Practice: A Mixed Open-/Closed-source Case Study. IEEE Transactions on Software Engineering (Early Access). DOI: 10.1109/TSE.2026.3663093

未査読の論文（2本）

・Maddila, C., Ghorbani, N., et al. (2025). AI-Assisted Fixes to Code Review Comments at Scale. arXiv:2507.13499
・Adams, C., Banga, A. S., et al. (2026). Automating Low-Risk Code Review at Meta: RADAR, Risk Calibration, and Review Efficiency. arXiv:2605.30208

会社の公開文書（自己申告・規範）

Google Engineering Practices「The Speed of Code Reviews」:
https://google.github.io/eng-practices/review/reviewer/speed.html

Google Engineering Practices「The Standard of Code Review」:
https://google.github.io/eng-practices/review/reviewer/standard.html

Google Engineering Practices「What to look for in a code review」:
https://google.github.io/eng-practices/review/reviewer/looking-for.html

Microsoft「Enhancing Code Quality at Scale with AI-Powered Code Reviews」（2025-07-14）:
https://devblogs.microsoft.com/engineering-at-microsoft/enhancing-code-quality-at-scale-with-ai-powered-code-reviews/

Meta「Move faster, wait less: Improving code review time at Meta」（2022-11-16）:
https://engineering.fb.com/2022/11/16/culture/meta-code-review-time-improving/

ラクス「AIに12機能を書かせたら、レビューに5営業日かかった」（2026-09-11）:
https://tech-blog.rakus.co.jp/entry/202260911/ai

LINEヤフー「AIで"レビュー渋滞"を解消する」（2025-11-27）:
https://techblog.lycorp.co.jp/ja/20251127c

SmartHR「生成AI時代における開発プロセスの現在地」（2026-06-09）:
https://tech.smarthr.jp/entry/2026/06/09/102216

サイバーエージェント「コミット数2倍でもレビュー品質を維持！AI時代のコードレビューフロー再設計」（2025-12-18）:
https://developers.cyberagent.co.jp/blog/archives/60882/

freee「数字で振り返る freee の AI 駆動開発 - 後編」（2025-12-25）:
https://developers.freee.co.jp/entry/ai-driven-development-2025-report