PRが2倍に増えても、リバート率は4割も下がっていた。Claude Codeチームの数字

AIが書くコードが増えるほど、人のレビューが追いつかずに不具合が増えそう、と感じていませんか？Anthropicの公式ブログによると、6月から9月にClaude Codeのリポジトリでマージ済みのPRは2倍超に増え、リバート（取り消し）になったPRの割合は40%超下がりました。ブログが示すレビューの7つの層の中身と数字の読み方、コードを書かない立場でも自分のチームに持ち帰れる観点を整理します。

原典は、2026年10月15日公開のHow the Claude Code team does code reviewです。書いたのはClaude Codeチームのアディ・オスマニさん、モーガン・ウェストリー・ラントさん、チン・ワンさんの3人です。

リバート率の4割減は、件数でなく割合の話

リバートとは、いったん本番のコードに入れた変更を取り消すことです。原文は「the share that had to be reverted」、つまり取り消しになったPRの割合が下がったと書いています。

原文は割合の分母を明記していませんが、マージされたPRに対する割合と読むのが自然です。母数のPRは2倍に増えています。仮にPRがちょうど2倍、割合がちょうど4割減なら、取り消しの件数は2×0.6で1.2倍になる計算です。良くなったと言えるのは、PR1本あたりの話なんですよね。

モノレポは、全社のコードを1か所にまとめた保管場所です。1日3万件超はClaude Codeだけの数字ではないので、2倍超の話と混ぜないほうが安全です。

原文は2倍と4割減を並べたあと、「We didn't remove review.」（レビューは減らしていない）と続けるだけです。どの層が効いたかの内訳も、母数のPRの件数も書かれていません。「AIレビューを重ねたから減った」と読むのは、原文より一歩先に出た読み方です。

人が承認する前に、AIと自動チェックがPRを止める

7つの層のうち、人の承認が条件になるのは5番目だけです。

Anthropic社内の運用では、2と3に、未解決の指摘が残るPRをマージさせない権限があります。止める力が強いぶん、指摘はエージェント同士で確かめてから出す順番です。なお、製品として提供されているCode Reviewの指摘そのものは、公式ドキュメントによるとPRの承認もブロックもしません。

原文は層とは別の節で、プロジェクトの決まりを書いたCLAUDE.mdと、コードオーナーが書くレビューで重視する点のREVIEW.mdも紹介しています。公式ドキュメントによると、REVIEW.mdを読むのはGitHub上のCode Reviewサービスで、手元で動かす/code-reviewはCLAUDE.mdしか読みません。

承認の人数は、誰が書いたかより何を変えたかで決まる

原文の言い方は「The change sets the tier, not the author.」です。変更を読んで段階を振り分けるAI（分類器）があり、別の分類器が「段階は低いが、この変更は人が見るべきか」をもう一度判断します。オーナーが注意が要ると登録したパスと、CIの設定ファイルは、段階にかかわらず人が見ます。

軽い経路を使えるのは信頼された作者（主に、そのコードを持つチーム）だけで、ほかの人は2人目の承認が要ります。エージェントの承認は人の承認に数えません。エージェントに書かせたPRでは、指示を出した人がレビュアーの1人に数えられます。

自分が注目したのは、段階を決める材料の多くがコードの外にある点です。課金に触るか、個人情報が流れるか、問い合わせが急に増える画面か。これを一番知っているのは、事業側の人だったりしますよね。

AIレビューが一晩で50回往復したとき、チームは回数に上限を置いた

エージェント同士の往復が止まらなくなった例として、ブログはCLIのPRが一晩で50回を超えるレビューと修正を繰り返し、作者が止めた件を挙げています。

繰り返し指摘された箇所をgit blame（どの行がいつ書かれたかをたどる機能）で調べると、約59%は最初のレビューの時点からあったコードでした。最初から見えていたものが、回を重ねて小出しに指摘されていたことになります。

そこで入れた決まりは次の4つです。

• 3回で上限にし、レビュアーが作者にやり方の見直しを求める
• 最初の数回のあとは、新しい差分だけを見直す
• 同じ種類のバグはまとめて指摘し、全部の箇所を直させる
• 一度出した指摘は繰り返さない

社内のPRでは、この前後で、1回のレビューと修正で通るPRは65%から78%に、5回以上かかるPRは8.9%から1.5%に、通るまでの平均回数は2.08回から1.32回になりました。前後がいつからいつかと、母数の件数は書かれていません。終わらない会議に「論点は3回まで」「前回からの差分だけ話す」と決めるのと、よく似た構造です。

自分のチームに持ち帰るなら、変更の段階表を1枚つくる

ブログは他のチーム向けの手順として、変更の影響でリスクの段階を決めることや、事故を次のレビューの試験データに変えることを挙げています。コードを書かない立場から始めるなら、次の4つを開発チームと話すのが近道だと自分は考えています。

1. 自社のサービスで壊れたら困るもの（課金、個人情報、問い合わせが急増する画面）を挙げ、高・中・低に置く
2. AIが承認したPRを、人の承認と同じに数えていないかを聞く
3. デプロイなしで機能を止められる範囲を聞く
4. リバートを件数でなく、マージしたPRに対する割合で見ているかを聞く

割り引いて考えたい条件もあります。Claude Codeは本体のコードの約90%をClaudeが書いていて、社員の利用で不具合が先に見つかりやすい環境です。同じ層を入れても、同じ数字が出るとは限りません。

ブログが伝えているのは、人が全部読むのをやめた話というより、人の注意をどの変更に置くかを決め直した話です。最初の段階表は、コードを読まない人でも書けます。