Claude Codeチームのコードレビュー — Anthropic社内で人の承認を減らす7つの層

Claude Codeチームは、コードの約9割をClaude自身が書いています。この量では、人が全差分を読む運用は成り立ちません。claude.dev開発者ブログのEngineeringに載った解説(2026年10月15日公開、Addy Osmani、Morgan Westlee Lunt、Qing Wang)は、この問いへのチームの答えです。6月から9月にかけて、Claude Codeリポジトリへのマージ済みPRは2倍を超えました。マージ後に取り消された変更(revert)の割合は、40%以上減っています。

背景 — 「人が読んだか」を問うのをやめた

Anthropicのモノレポでは、1日にマージされる変更が5月の約2,500件から9月には3万件を超えました。Claude Codeは別リポジトリですが、同じ圧力を受けています。この量で行単位の目視レビューを続けるのは、難しいというより不可能に近い、というのが出発点です。

ブログはコードレビューの役割を2つに分けます。1つは出荷前に問題を見つけて直すこと、もう1つはチームにコードベースの理解を広げることです。本編は前者が中心で、後者は終盤で扱われます。

見方の転換はこの一文に表れています。「人間が読んだか」は、「この変更で何が壊れうるか、どの検査(自動でも人でも)が拾うのに向いているか」の不正確な代用品だ、という考え方です。レビューの時期も変わりました。道の終わりにある関門ではなく、書きながら走るスペルチェックに近づいています。ほとんどの変更は、人が見る前にClaudeが少なくとも1回レビューして直しています。

測っているのは人の時間

希少なのは人の時間と注意だ、というのがチームの前提です。目標は「大半のPRが、著者本人でもよい人間1人以内でマージされ、取り消しやインシデントが増えないこと」です。対象はCLI、デスクトップとWebのアプリ、モバイルアプリのリポジトリです。

測る指標は、PRあたりの人の承認数(中央値と95パーセンタイル)、人のコメント数、PRが人を待った時間です。取り消し(revert)率とインシデント率は歯止めの役です。これが上がるなら、人の時間を節約したのではなく、後工程に移しただけだからです。

一つの変更が通る7つの層

ブログの図は、変更がたどる道を「PR前」「全PR」「マージ」「マージ後」の4区間に分けています。この区間の中に7つの層があります。

層1 — 検証はPRの前に終わっている

レビューの大半は、PRが存在する前に済んでいます。テスト、ビルド、デザインと比べるスクリーンショットなど、実行できるものをClaudeに渡し、「終わった」と言わせずに出力を見せさせる運用です。別のサブエージェントが、新しいコンテキストで差分をレビューする段もここに入ります。Claude Codeの作者Boris Chernyは、Claudeに作業を検証する手段を渡すことが、良い結果を得る上でおそらく最も重要だと述べています。最終結果が2〜3倍良くなるという見積もりも添えられています。

自動レビューが同じ指摘を繰り返すなら、原因を元から直します。直し先はスキルかlintルール、または指示ファイルです。ブログは2つのファイルの役割を分けています。

• CLAUDE.mdは、スタック、規約、目標と非目標を伝えます。全レビューが読み込むので、大きなリポジトリでは短く保ち、詳細は他の文書へ誘導します。規約に反するコードと、記述が古くなる変更の両方がレビューの指摘対象です
• REVIEW.mdは、コードオーナーが書き、そのコード領域で何が重要かをレビュアーに伝えます。レビュアーが実際に従っているかは、別に検査しています

層2 — 全PRにAIレビュー

すべてのPRが、人の前にClaudeのレビューを受けます。差分をリポジトリ全体とPRの意図に照らして読み、「問題を解いているか、システムに合うか、他を壊さないか」を問います。バグ修正なら根本原因を探します。

製品版のCode Reviewは、TeamとEnterpriseプランで一般提供されています。ローカルでは/code-reviewが軽量版として動きます。研究プレビューの公開後、実質的なレビューコメントが付いた社内PRの割合は16%から54%になりました。1,000行を超えるPRの大半に指摘が付き、小さなPRの大半はクリーンで返ります。

指摘は人に見せる前に検証されます。複数のエージェントが同時にバグを探し、別の一団が各指摘に投票し、十分な数が「本物」と判断したものだけが投稿されます。スタイル、診断、掃除だけの指摘は落とされます。このフィルタは、残す前に自社PRでA/Bテストしたと書かれています。

残った指摘はインラインコメントとして深刻度順に並び、Important、Nit、Pre-existingのタグが付きます。PRが持ち込んでいないバグに既存のタグを付けることで、著者の落ち度に見えないようにする作りです。指摘には必ず応答します。直すか、理由を書いてスレッドを閉じるかのどちらかです。

層3・4 — セキュリティレビューと自動チェックが門を閉じる

セキュリティも専用の自動レビューを持ちます。バグレビューかセキュリティレビューの指摘が1件でも開いている間は、マージできません。誤検知は理由を短く書いて閉じることで片付け、後続のコミットで直った指摘は自動で解消されます。同じ仕組みは、オープンソースのsecurity-reviewのGitHub Actionまたは/security-reviewコマンドで組めます。

層4は通常のCIです。リンター、型、全プラットフォームのテスト、ビルドが走り、CLIのPR1本で人が見る前に数十のチェックが動くこともあります。PRテンプレートには、どうテストしたかと、どう元に戻すかを書く欄があります。Claudeが埋めてもよいのですが、変更を依頼した人が最終的に署名します。

層5 — リスクで承認者数を決める

文書の修正と自動更新機構の変更は、リスクが違うので扱いも変わります。

階層を決めるのは著者ではなく変更そのものです。分類器が変更を読んで階層を選び、第2の分類器が「階層上は不要でも、この変更にはもう1人必要か」を判定します。オーナーが機微と指定したパスとCIワークフローのファイルは、常に人が見ます。軽い経路を使えるのは、リポジトリの信頼リストにいる著者、主に所有チームだけです。

AIの承認が人の承認の枠を埋めることはありません。エージェントが書いたPRでは、エージェントを動かした人が、必要なレビュアーの1人に数えられます。承認は特定の1コミットに対するもので、エージェントのpushや手作業で解決したマージのように、システムが保証できない新コミットが入ると、承認はやり直しになります。

層6・7 — それでも漏れる前提の後ろ側

マージキューは、変更を当てたmainに対して全チェックを再実行します。単独で通る2つのPRが、組み合わさって壊れたmainを作ることを防ぐためです。新しい挙動は多くの場合、まずAnthropicの社員向けにフラグ付きで出ます。社内の利用量が多いので、利用者より先に回帰が見つかることも多いといいます。公開リリースはlatestチャネルが先で、stableが遅れて続きます。

最後の層は、失敗を速く見つけて戻すことです。フラグはデプロイなしで切れ、Claude Codeには週替わりのオンコール当番があります。インシデントレビューでは「どの層が拾うべきだったか」を問います。ただし、悪いマージに気づく経路は、著者とオンコール、それに取り消しとインシデントのダッシュボードに頼っています。数字が動いたら承認を自動で厳しくするサーキットブレーカーは、まだありません。人の関与ゼロでのマージを増やす前に、エンジニアたちが欲しがっているものでもあります。

レビュアーを良くする循環 — インシデントを評価セットにする

運用の中で最も再現しやすいのは、この循環です。過去にインシデントを起こしたPRを集め、その修正と取り消しも含めて、コードを知るエンジニアにバグの存在と場所を確認させます。この評価セットに対し、レビュアーを毎日走らせます。レビュアーのプロンプト、ツール、モデルを変えたら、全ケースで採点し直し、スコアが上がれば残し、上がらなければ戻します。インシデントが起きるたびに、評価セットにケースが1つ増えます。

ノイズも計測します。レビュアーのコメントを、人がどう反応したか(直した、間違いだと言った、意図的な挙動だと言った、どうでもいいと判断した)で仕分けます。バグがないと分かっているPRにもレビュアーを走らせ、有害な変更につながりかねない報告がどれだけ出るかを数えます。優先順位は、実際のバグを捕まえることが先、レビューの往復を減らすことが次、と明文化されています。

収束しないレビューという落とし穴

ノイズは、著者がエージェントだと余計に高くつきます。人間なら数秒で受け流せるNitも、エージェントは直してしまい、そのぶんコミットとレビューが1周増えるからです。エージェントの著者とエージェントのレビュアーは、いつまでも互いを忙しくさせられます。CLIのPRが一晩で50回を超える往復をした例もありました。

git blameで調べると、レビュアーが指摘し続けたコードの約59%は、最初のレビューの時点からあったコードでした。新しいバグを見つけていたのではなく、古いバグを毎回少しずつ見つけていたことになります。複数回を既定にしてしまった運用も、チーム自身が悪化させた原因として認めています。

変更の中身は4点です。3回のレビューを終えたら、方針そのものを見直すよう著者に促すラウンド上限。最初の数回の後は差分だけの再レビュー。バグの種類を指摘して全箇所を直させること。すでに投稿した指摘を繰り返さないこと。既存コードに対しては、夜間にレビュー用エージェントを走らせ、古いバグが別の場所で顔を出す前に拾っています。

人が残る場所と、理解を広げる方法

人が担当するのは、機械が苦手な判断です。

もう一つの役割、理解の共有には、正式な仕組みはありません。コードの一部を知りたい人が、Claudeにその部分の解説を書かせます。数分で済み、今のコードを反映します。Claudeにその部分を可視化する小さな成果物を作らせ、自分の好む学び方に合わせる人もいます。1行の文言修正の差分を読んでも得るものは少なく、これから触るモジュールの解説なら多くを学べる、という立場です。

「マージした人が持ち主」という規範も、仕組みの一部です。小〜中規模の変更で何か起きたら、マージした人が直すのが通例で、責める話ではありません。変更が小さく、フラグ、取り消し、段階的リリースで数分で戻せることが前提です。影響範囲が広いコードほど、人もチェックも増えます。方向転換も早い段階のスレッドで提起し、完成したPRへのブロックコメントにしない、というコツが挙げられています。

Code Review単体はマージを止めない — 強制力はGitHub側の設定で持たせる

ここまでの内容を、既存のドキュメントと並べると気づくことがあります。Code Reviewのドキュメントには、レビューはPRを承認もブロックもしないと書かれています。チェックランも失敗では終わらない、とあります。ブログは「未解決の指摘がある間はマージできない」と書きます。Code Review単体はマージを止めないので、この「マージできない」は、チーム側のマージ条件が担っていると考えるのが自然です。採用手順の節にも「マージ前に全レビュースレッドの解決を必須にする」とあります。社内でどの仕組みで止めているかまでは、ブログに書かれていません。

つまり、Claudeのレビューに強制力を持たせるかどうかは、各チームがGitHub側で決めることです。指摘を解消しないと再カウントされる仕様と組み合わせると、「直すか、理由を書いて閉じる」というブログの運用が、そのまま設定として成立します。

レビューの深さは3段階(Quick、Standard、Deep)で選べます。ドキュメントでは、レベルを上げるほど時間と費用が増すと説明されています。見逃した1件が高くつくリポジトリにはDeepを充てる、という使い分けがブログに示されています。実行経路ごとの違いは4つの実行経路の使い分けにまとめてあります。

取り入れるなら、どこから始めるか

採用手順は、リスクの低い順に並んでいます。

REVIEW.mdの良い例の特徴は、短いこと、そのリポジトリでの失敗の姿を言葉にすること、Nitに上限を付けること、見ないパスを列挙すること、推測ではなくファイルと行番号を証拠に求めること、要約を件数から始めて指摘がなければそう書くこと、です。次の例は、この特徴を当てはめた一例です(ブログに載っている原文ではありません)。

# REVIEW.md(docs/ 配下の例)
 
## 失敗の定義
このディレクトリでは「事実と違うこと」が失敗。サンプルコードが
動かない、手順が現行の挙動と食い違う、を最優先で指摘する。
 
## 指摘のルール
- Nitは最大3件まで
- 指摘には必ずファイルパスと行番号を添える。名前からの推測は不可
- 要約は「指摘N件」から始める。指摘がなければ「指摘なし」と書く
 
## 見ないパス
- docs/changelog/ 配下(自動生成)

CLAUDE.md側の書き分けは、CLAUDE.mdの書き方と、REVIEW.mdのカスタマイズに詳しく載っています。チームの導入手順全体はClaude Codeチーム導入ガイドが扱います。

まとめ

この運用の要は、層の数よりも、各層が「人が読んだか」の代わりに何を保証するかを決めていることです。検証、AIレビュー、セキュリティ、CI、リスク別承認、マージキュー、巻き戻しのどれも、単独では漏れます。重なりと、漏れたときに戻せることで品質を保っています。

数字の読み方には注意が必要です。マージ数の増加と取り消し割合の減少は、いずれもClaude Codeチーム自身の6月〜9月の記録で、他のチームの再現値ではありません。また、サーキットブレーカーがまだ無いこと、収束しないレビューを自分たちで悪化させたことは、ブログ自身が認めている弱点です。自分のチームに持ち込むなら、まず1リポジトリでAIレビューを走らせ、評価セットの元になるインシデント記録を残すところが、最小の一歩です。