レビューで変わったこと
Claude Codeチームは、Claude Codeのコードベースへマージされたプルリクエストが6月から9月にかけて2倍を超え、リバートしなければならなかった割合は40パーセントを超えて下がったと報告しています。ClaudeDevsがこの数字を投稿したのは2026年10月16日です。プルリクエストの比較期間は6月から9月で、その期間の年は書かれていません。
チームはまた、Anthropicのモノレポで着地した変更が、今年5月の1日あたり約2,500件から9月には1日あたり30,000件超になったとも報告しています。この1日あたりの件数はモノレポのものです。Claude Codeはモノレポとは別の独自リポジトリにあり、チームはそのリポジトリにも大きな圧力がかかっていると述べています。チームは、この速さで変更が出ていくと、人が1行ずつ読むレビューは極めて難しく、ときには不可能だと呼んでいます。レビューにはいまも2つの仕事があるとチームは言います。出荷前に問題を捕まえることと、コードベースへの共通理解を作ることです。記事は主に出荷前に問題を捕まえるほうを追い、コードベースの共通理解には終わり近くで戻ります。
チームが問うとしている質問は、この変更で何が壊れ得るか、そして自動と人のどちらの検査がそれを捕まえるべきかです。以前のレビューは、プルリクエストが開くまで待っていました。いまは変更を書いている間に動きます。チームは、人に見るよう頼む前に、ほとんどの変更がClaudeによって少なくとも1回はレビューされ、直されていると述べています。
プルリクエストが存在する前に、Claudeは自分で実行できる検査の出力を見せなければなりません。テスト、ビルド、デザインと比較したスクリーンショットなどです。そのあと、変更を書いたセッションとは別の、新しい文脈を持つサブエージェントがdiffをレビューします。チームの多くの人は、バグを探し、diffを単純にし、振る舞いを端から端まで試す内部検査も走らせます。UIの変更はデザインガイドラインと照合します。Claude Codeを作ったBoris Chernyは、Claudeに自分の作業を検証する手段を与えることを、良い結果のためにおそらく最も重要なことと呼んでいます。彼は、これで最終結果が2倍から3倍良くなると見積もっています。彼が書く検証は、bashコマンド、テストスイート、あるいはブラウザやスマホのシミュレーター上のアプリです。記事はその倍率を彼の見積もりとして示しています。
その後、すべてのプルリクエストは人が見る前に、リポジトリ全体と書かれた意図に照らしてレビューされます。バグ修正では、レビュアーが根本原因を見ます。リサーチプレビューの時点で、チームは実質的なレビューコメントが付いた内部プルリクエストの割合が16パーセントから54パーセントになったと述べています。この数字とともにプレビューの日付も顧客側の割合も示されていません。1,000行を超えるプルリクエストの多くには指摘があり、小さいものの多くはクリーンに戻ってきます。
チームは6層の検査を積み、その下にロールバックを置き、さらに速い検知とロールバックを7番目の段階として説明しています。
- プルリクエストの前: エージェントが実行できる検査の出力を見せ、そのあと新しい文脈のサブエージェントがdiffを読みます。
- プルリクエスト上: Claudeがdiffをリポジトリと書かれた意図に照らしてレビューします。
- セキュリティレビュー: チームの規則では、未解決のバグ・レビューまたはセキュリティ・レビューの指摘がマージを止めます。
- CI: リント、型、テスト、ビルドがいまも止めます。
- 人の承認: 変更のリスクが区分を決めます。より少ない承認人数を得られるのは信頼された作者だけで、それ以外の人にはもう1人が必要です。
- リリース: マージキュー、まず従業員へ向けるフラグ、latestチャンネル、そのあとstable。
- 出荷後: デプロイなしでフラグを切り、インシデントレビューはどの層が見逃しを捕まえるべきだったかを問います。
リスク別の承認と、公開されている製品
Anthropic自身のClaude Codeリポジトリでは、作者ではなく変更が区分を決めます。分類器が変更を読み、低、中、高のいずれかを選びます。2つ目の分類器は、区分だけでは人が増えない場合でも、もう1人を求められることがあります。オーナーが敏感だと列挙したパスと、あらゆるCIワークフローのファイルには、いまも人が必要です。
表の軽い経路を使えるのは、リポジトリの信頼リストに載った作者、多くはそのリポジトリを持つチームだけです。そのリストは区分とは別の門です。それ以外の人にはもう1人が必要です。エージェントの承認が人の承認として数えられることはありません。自動レビューは低リスクの変更を通せますが、人を求める枠は埋められません。エージェントが書いたプルリクエストでは、そのエージェントを指示した人が、自分で変更を打ったときと同じように必須レビュアーとして数えます。承認1回が覆うのはコミット1つです。その後のエージェントのpushや、手で解決したマージには、承認がもう一度必要です。
その変更を作るかどうか、課金と自動アップデータとCIをどう扱うか、その変更が他の人がまねするパターンを置くか、テスト出力と指摘で足りるか、結果を誰が持つかは、いまも人が決めます。出荷されるすべての変更の責任は人に残ります。
Claude CodeのCode Reviewは、TeamとEnterpriseプランで一般提供されています。管理者はリポジトリごとにQuick、Standard、Deepを設定します。これはレビュアーがどれだけ深く見るかの深さです。チームが説明するのはDeepです。バグを1つ見逃すコストが、増えるレビュー時間より大きいところで使います。/code-reviewコマンドは、より軽い版をローカルで実行します。チームの記事は価格を記しておらず、ローカルコマンドをどのプランで実行できるかも述べていません。
複数のエージェントが同時にバグを探します。別のグループが続いて投票し、本物だと十分な数が見なしたときだけ指摘が投稿されます。何人が同意しなければならないかは公開されていません。このプルリクエストのレビュアーでは、スタイル、診断、片付けだけの指摘は落とされます。チームは、そのフィルタを自らのプルリクエストでA/Bテストしてから残したと述べています。残ったものはImportant、Nit、Pre-existingのタグが付きます。Pre-existingは、そのプルリクエストが持ち込んでいないバグです。各指摘は直すか、理由を付けてスレッドを閉じます。偽陽性はこうして消します。問題を直す後のコミットは、指摘を自ら消します。
Claude Codeチームの規則では、未解決のバグ・レビューまたはセキュリティ・レビューの指摘がマージを止めます。記事は、その阻止を望む読者に、オープンソースのsecurity review GitHub Actionと/security-reviewを示します。TeamとEnterpriseプランのCode Reviewは指摘を投稿し、承認は人に残します。この製品がチームのマージ阻止をオンにするわけではありません。Anthropic自身のリポジトリでは、オーナーがどの低リスクの変更を自動検査だけでマージするかを決め、チームはその線が動き続けていると述べています。この選択は、誰が軽い経路を得るかを決める信頼された作者の一覧とは別です。
ローカルコマンドについて、Claude Codeの変更履歴は、調整済みのレビュー設定がないモデル（Opus 5.5とSonnet 5.5を含む）ではmedium effortの/code-reviewが片付けとCLAUDE.mdの規約の指摘も報告すると述べています。プルリクエストのレビュアーでは、スタイル、診断、片付けだけの指摘は落とされます。
| リスク | 例 | 人の承認 |
|---|---|---|
| 低 | ドキュメント、文言、社内限定の機能、フラグの背後にある追加の変更 | 自動レビューとセキュリティ検査が通れば必須の人はいない |
| 中 | 通常の製品変更と、キャッシュ、自動アップデータ、システムプロンプトのような敏感な領域の変更 | 1人 |
| 高 | 最もリスクの高いコードと、常に2人が必要な少数のパス | 2人 |
同じ流れを試す
プルリクエストの前に、チームは読者へ、短いCLAUDE.mdに列挙したエージェントが実行できる検査と、フォーマッタとリンタを走らせるフックを示します。ローカルの/code-reviewと/security-review、または新しい文脈のサブエージェントも示します。CLAUDE.mdにはスタック、規約、目標、目標ではないものが入ります。すべてのレビューがこれを読むので、チームは短く保ちます。コードオーナーが書くREVIEW.mdは、その領域で失敗がどう見えるかを述べ、細かい指摘に上限を置き、飛ばすパスを列挙し、根拠としてファイルと行を求め、残り修正件数から始まる要約を求めます。同じ指摘が戻ってくるときは、チームはその修正をスキル、リント規則、またはそれらのファイルのどれかへ移します。
各プルリクエストでは、リント、型検査、テスト、ビルドがいまも止めます。テンプレートはTesting、Risk、How to revertを求めます。Claudeはその節の下書きを書けます。変更を頼んだ人が確認します。3ラウンドのあと、レビュアーは作者にアプローチを考え直すよう求めます。その後のパスは新しいdiffをレビューします。作者にはバグの一種を直すよう求め、すでに投稿された指摘は繰り返さず、レビューのエージェントは既存コードの上でも毎晩動きます。内部プルリクエストのチームのチャートのキャプションは、その収束のための変更のあと、プルリクエストあたりのレビューラウンドが減ったと述べています。キャプションに回数はありません。
承認では、区分を変更から書き、軽い経路は信頼する作者に残し、ボットが必須の人の席を埋めないようにします。CODEOWNERSとブランチ保護で、認証、課金、CI、リリースのワークフロー、インストーラーには常に人が必要になるようにします。保証できない新しいコミットが来たら、承認を破棄します。
彼らのリリース経路はマージキューを使います。キューは変更を適用したmainに対してすべての検査を再実行するので、別々に通った2つのプルリクエストが合わさって壊れたmainになることはありません。新しい振る舞いは、通常まずフラグの背後で従業員へ出ます。公開リリースはlatestチャンネルが先で、stableチャンネルがそれを追います。stableがlatestにどれだけ遅れるかは公開されていません。フラグはデプロイなしで切れます。過去のインシデントのプルリクエスト、fix-forward、リバートは、そのコードを知るエンジニアが確認し、レビュアーはその集合に対して毎日動きます。その毎日の実行のスコアは公開されていません。
まだ目標であるもの
目標は、Claude Codeのリポジトリ、つまりCLI、デスクトップとウェブのアプリ、モバイルアプリのプルリクエストのほとんどが、多くて1人の人、その人は作者でもよい状態でマージされ、リバートとインシデントは増えないことです。記事は目標を述べています。目標を達成したとは述べていません。6月から9月の根拠は量とリバートの割合です。
人の時間は、プルリクエストあたりの承認の中央値と95パーセンタイル、人のコメント、プルリクエストが人を待つ時間で追います。リバート率とインシデント率がガードレールです。それらが上がれば、チームは時間を減らしたのではなく移しただけだと言います。その中央値、コメント数、待ち時間は公開されていません。
ClaudeがClaude Codeのコードの約90パーセントを書いているという一文は、チームが以前にも言ったとしているものです。この記事には、その割合の数え方は含まれていません。
リバートやインシデントの数字が動いたときに承認を厳しくするサーキットブレーカーは、まだ入っていません。チームのエンジニアは、人の承認がないマージへより多くのコードが移る前に、それを望んでいます。出荷日は示されていません。悪いマージに気づくことは、いまも作者、週次のオンコール当番、リバートとインシデントのダッシュボードに依存します。インシデントレビューは、どの層がその問題を捕まえるべきだったかを問います。
CLIのプルリクエストの1件は、作者が止めるまで、一夜のうちにレビューと修正を50ラウンド超まわりました。チームはこれを、エージェントの作者とエージェントのレビュアーが互いを忙しくし続けた1つの事例として語っています。人は細かい指摘を数秒で消せます。エージェントはそれを直し、それは別のコミットと、もう1ラウンドのレビューを意味します。チームは、レビュアーが指摘し続けたものをgit blameで見ると、約59パーセントは最初のパスからあったコードで、レビュアーが新しいバグを見つけることはまれで、ラウンドごとに古いものを少しずつ見つけていたと述べています。投稿はその59パーセントのサンプルサイズを示していません。
チームはそのノイズを、人がコメントをどう扱うかで測ります。各コメントはプルリクエスト上の反応で分けます。直した、間違っていると言った、意図的だと言った、あるいは重要でないものとして脇に置いた、です。レビュアーはチームがクリーンだと知っているプルリクエストでも動かし、チームは、誰かに有害な変更を作らせたであろう報告をどれだけ頻繁にするかを数えます。書かれた優先順位は、本物のバグを先に捕まえ、レビューラウンドを減らすことをその次に置くことです。
共通理解に正式な手続きはありません。コードベースの必要な一部分について、人はClaudeにその部分の説明を書かせ、一部の人はClaudeにそれを教える小さな成果物を作らせます。チームは、開いたSlackチャンネルが作っている最中の作業を見せると述べています。小または中の変更では、それを着地させた人が、その後の失敗を直すのが普通です。彼らが名指しする安全装置は、小さいdiff、フラグ、リバート、段階的リリース、速い社内利用です。エージェントが開始を安くするので、記事は、チームメイトがスレッドの早い段階で方向を問い、プルリクエストを閉じることは普通だと言っています。
出典
あわせて
資料と編集方針
この記事は、2026年10月16日のClaudeDevsの投稿と、同じ日に確認したリンク先のclaude.dev記事 How the Claude Code team does code review、そして調整済みのレビュー設定がないモデル（Opus 5.5とSonnet 5.5を含む）ではmedium effortの/code-reviewが片付けとCLAUDE.mdの規約の指摘も報告する、というClaude Code変更履歴の記述に依拠します。チームの記事は価格を記しておらず、ローカルコマンドをどのプランで実行できるかも述べていません。security reviewの導入手順、ベストプラクティスのガイド、別個のCode Review発表、それより後の変更履歴は対象外です。チャートのキャプションは、収束のための変更のあと内部のレビュー回数が減ったと述べ、回数は示しません。毎日のインシデント評価は、公開されたスコアなしで説明されています。