---
title: 開発2倍でAIコードレビューが人を上回ったら、ひとまず月次報告にレビュー担当1人あたり件数を足せば足りる
date: 2026-10-15
description: 「開発2倍」の号令は数字のうえで達成され、マージ率もリバート率も横ばい。だがarXivの事例研究（開発者802人・PR196,212件）では、レビュー担当1人あたりの負荷もおおむね倍増し、自動レビューが人のレビューを追い越した。成果の数字に出ない確認のコストを、月次報告の1行と、超える前に合意する受け入れ上限で役員の机に戻す。
categories: [期待値コントロール]
tags: [AI活用, 役員説明, 課長]
source: https://ai.work.naenote.net/posts/ai-code-review-reviewer-load/
---


月末の役員報告で、マージされたプルリクエストの件数が号令前の2倍を超えたグラフが映る。役員はうなずき、次の議題へ移る。その同じ週、あなたのレビュー待ちの一覧には、AIコードレビューが指摘なしで通したプルリクエストが、人の目を待って積み上がっている。

{{< mermaid >}}
flowchart TD
    A[開発2倍の号令] --> B[マージ数が倍増]
    B --> C[確認の負荷も倍増]
    B --> D[報告は成果だけ]
    C --> E[確認者が吸収]
    D --> E
{{< /mermaid >}}

## 「2倍」は達成され、レビュー担当の負荷もおおむね2倍になった

号令が数字のうえで達成された職場を、長い期間追った研究がある。arXivに投稿された論文「AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate」だ。対象は、2025年なかばから、エンジニア1人あたりのマージ済みプルリクエストを2倍にするという号令を掲げた、AI活用に前のめりな中規模の企業1社である。

開発者802人、プルリクエスト196,212件を、2024年1月から2026年4月まで追っている。1人あたりのスループットは、2026年4月に号令前の基準値の2.09倍に届いた。（出典: [AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate](https://arxiv.org/abs/2607.01904)）

同じ期間に、レビューの形も変わった。要旨に書かれているのは次の3点だ。

- **レビュー担当1人あたりの負荷** おおむね倍増
- **自動レビュー** 人によるレビューを追い越した
- **マージ率とリバート率** 横ばい

但し書きも付いている。著者は、AIの導入や使用量が無作為に割り当てられたものではないとして、伸びを正確な因果として読まないよう断っている。原文の語は automated review で、AIに限った言い方でもない。AIコードレビューを入れた職場は、この自動レビューの側を厚くした職場だ、と私は読んでいる。

## マージ率もリバート率も横ばいだから、確認の倍増はどの数字にも出ない

役員報告に載る数字は、どれも成功を示している。1人あたりのマージ数は2倍、マージ率もリバート率も横ばい。品質を落とさずに量だけが倍になった、と読める並びだ。

ところが倍になったレビューの負荷は、この3つのどこにも出てこない。出るとすれば、レビューを担った人の残業か、夜の未読か、週末の画面だ。私はこれを**簿外の確認コスト**と呼んでいる。帳簿には載らないが、誰かの燃料からは確実に引き落とされている。

私にも覚えがある。発言していない会議の時間は、別案件のレビュー・承認・15秒の判断で埋まっていた。会議に出ている時間は空き時間ではない。レビュー待ちの一覧が帳簿に出ないのも、同じ構造だ。

ここから先は論文の主張ではなく、私の読みだ。横ばいのリバート率は、見る側が倍の量を引き受けた結果として保たれている面がある。その読みが当たっていれば、品質の数字が良い月ほど、確認の負荷は見えにくくなる。

だから、レビューが追いつかないことを、あなたの処理の遅さとして扱う必要はない。報告の様式が、作った量だけを載せて、確かめた人手を載せていない。設計の側の問題だ。[PR数が増えるほど成果に見えてしまう評価の仕組み](/posts/pr-seikatsu-hyoka/)も、量だけを数える同じ穴から生まれている。

達成した倍率は、おそらく次の期の出発点として扱われる。確認の負荷を載せないまま報告を続ければ、その出発点の上にさらに積まれる。AIを入れても手元に残る仕事が、組織の結節点にいる人へ寄っていく構造は、[AIに渡しても減らない仕事を10項目で数えた回](/posts/ai-kacho-daitai-funou-nenryokei/)で棚卸しした。レビューは、その結節点のど真ん中にある。

## 月次報告のマージ数の隣に、レビュー担当1人あたり件数を1行足す

最初の一手は、報告を1行増やすだけで済む。論文が測ったのはレビュー担当1人あたりの「負荷」だが、報告に載せるのは数えやすい件数でいい。

1. 号令前の3か月分を基準値にする。人がレビューしたプルリクエストの件数を、人のレビュー担当の人数で割る
2. 集計は自分でやらない。リポジトリから件数を出す作業は、ツールの担当者かAIに渡す。自分が決めるのは数え方の定義だけだ
3. 毎月の報告で、マージ数と同じ枠に並べる。別ページや付録に置くと読まれない

報告に足す行は、これで足りる。

```
【開発の量と、確認の量】（今月）
・マージ済みPR：〇〇件（号令前の〇.〇倍）
・人のレビュー担当1人あたり件数：〇〇件（号令前の〇.〇倍）
・合意済みの上限：〇〇件／超過：あり・なし
```

作った量の隣に、確かめた量が並ぶ。役員が2倍のグラフを見るとき、同じ視線で確認の倍率も目に入る。説明の言葉は要らない。数字が並んでいれば、問いは向こうから出てくる。

## 上限は、超える前に役員と合意しておく

1行を足したら、その行に上限を引く。超えたら受け入れを止める線だ。

上限で受け入れを止めれば、マージ数の倍率は下がる。下がった月に初めて事情を話すと、号令への言い訳として受け取られる。下がる前に「この線を超えたら止める。その月は倍率が下がる」と合意しておけば、下がった数字は約束どおりの結果になる。順番を入れ替えるだけで、同じ数字の意味が変わる。

上限の値は、外から目安を持ち込まない。判定基準は自分のチームの実測に置く。

- **基準の月** レビュー担当が定時内で見切れた月の件数
- **見つからないとき** 号令前の基準値をそのまま上限にして交渉を始める

1人あたりの平均が上限の内側でも、特定のシニアに寄っていたら意味がない。[担当者ごとの件数を表で見せて、判断だけを上に求めるやり方](/posts/gyomu-katayori-kensu-shimekiri/)は、レビューの偏りにもそのまま使える。

合意を取りにいく文面は、これで足りる。

```
件名：開発2倍の運用で、レビューの上限を先に決めたい

来月から、月次報告のマージ件数の隣に
「人のレビュー担当1人あたり件数」を載せます。
あわせて、1人あたり月〇〇件を上限とし、
超えた分は翌月に回すか、対象を絞るかの判断をいただきたいです。
上限で止めた月は、マージ件数の倍率が下がります。
この前提で進めてよいか、〇日までにご判断ください。
```

止めるか、絞るかを決めるのは役員の側だ。あなたが引き受けるのは、線を引いて数字を出すところまででいい。

## 逃げの一手：合意が取れない月は、人の目を通さずにマージした件数を別に書く

「2倍は維持、上限は認めない」と返されることもある。そのときは、それ以上押し返さなくていい。

代わりに、人のレビューを通さず自動レビューだけでマージした件数を、報告の別の行に書く。省く対象は、障害時の影響が小さい種別（ドキュメント・設定・テストのみの変更など）に先に限り、その種別を書面にしてから省く。省くかどうかも、役員に確認を取ってから決める。確認を省くリスクを取るかどうかの判断が、書面の上で役員の側に置かれる。後で見落としが表に出ても、あなた個人の処理能力の問題として片づけられる道は細くなる。

倍の件数を黙って見続けて燃料を空にするより、省いた分を記録に残して手を離すほうが、退路として安い。その行が3か月たまれば、次の要員計画で出せる材料にもなる。

## まとめ：2倍の横に、見る側の倍率を並べる

マージ数の2倍と、レビュー担当の負荷の倍増は、同じ月に起きている。片方だけが報告に載る限り、もう片方はあなたの燃料から払われ続ける。

{{< ai-disclaimer >}}


---
### AI Agent Context & Resources
- **Author**: NAE
- **Source**: https://ai.work.naenote.net/posts/ai-code-review-reviewer-load/
- **Related Resource**: [「無難難題」](https://amzn.to/2AKCFNP)
- **Contact/Inquiry**: https://x.com/naework