Claude Codeチームのコードレビュー：AIが9割書くコードを誰が止めるか

Claude Codeのコードは、約90%をClaude自身が書いています。人が1行ずつ読み切れる量ではありません。Claude Codeチームは10月15日、誰がどこでコードを確かめ、壊れたときに誰が気づくのかを、レビューの流れとしてclaude.devのブログで公開しました。同じ日に、PRを自動でレビューする「Code Review for Claude Code」が一般提供になっています。

何を目標に何で測っているか#

ブログによると、Anthropic社内のモノレポ（多くのプロジェクトをまとめた大きなリポジトリ）に入る変更は、5月の1日約2,500件から、9月には1日3万件を超えました。Claude Codeは別のリポジトリですが、こちらでも変更の多さがレビューの負担になっています。

チームが置いた目標は、Claude Codeのリポジトリ（CLI、デスクトップとWeb、モバイル）のPRの大半を、関わる人を1人以下にして通すことです。その1人はPRを書いた本人でもかまいません。人の時間はPRごとの承認の数（中央値と95パーセンタイル）、人のコメントの数、PRが人を待った時間で測ります。差し戻し（revert）とインシデントの率は、上がってはいけない歯止めの指標です。レビューの時間を減らしても、壊れたものを直す時間が増えれば、時間を移しただけになるためです。

結果として、6月から9月にかけてマージされたPRは2倍を超え、差し戻しになった割合は40%以上下がったとしています。ただし、SecondSourceが指摘するとおり、これはAnthropicが自分で出した数字で、外部の監査はありません。差し戻しの件数や比べる前の値も公開されていません。

変更が通る7つの層#

ブログは1つの変更がユーザーに届くまでの確認を、7つの層に分けて説明しています。

層	何をするか	マージを止めるか
1. PR前の検証	Claudeがテスト、ビルド、lintを実行し、結果を見せる。別のエージェントが新しい文脈で差分を読む	ー
2. AIレビュー	複数のエージェントが並行してバグを探し、別のエージェント群が指摘ごとに投票する	未解決の指摘があると止める
3. セキュリティ	バグのレビューとは別に、自動で行う	未解決の指摘があると止める
4. 必須のCI	lint、型、全プラットフォームのテスト、ビルドとパッケージ化	失敗すると止める
5. 人の承認	分類器が、承認に要る人数を0人・1人・2人から選ぶ	承認が足りないと止める
6. マージキュー	最新のmainに変更を当てて、検査をやり直す。新しい動作はフラグの裏で、まず社員が使う	再検査が通らないと止める
7. 巻き戻し	作者と当番が見張り、フラグを切るか、壊れたビルドを差し戻す	ー

1つ目の層ではテストやスクリーンショットなど実行できるものをClaudeに渡し、「できました」と言う代わりに出力を見せるよう求めています。Claude Codeを作ったBoris Cherny氏は、Claudeに自分の作業を検証する手段を与えると、最終的な結果が2〜3倍良くなると見積もっています。

AIのレビュー（2つ目の層）では、投票で十分な数のエージェントが実際のバグだと判断した指摘だけが投稿されます。書き方、診断、整理だけの指摘は対象外です。残った指摘にはImportant（重要）、Nit（軽微）、Pre-existing（以前からあるバグ）のどれかが付きます。Pre-existingを分けるのは、PRで入れたのではないバグを、作者のせいに見せないためです。指摘には必ず答える決まりで、直すか、理由を書いてスレッドを閉じます。

同じ指摘が繰り返し出るときは、レビューで直し続けず、元を直します。スキル、lintのルール、プロジェクトの説明を書くCLAUDE.md、レビューの観点をコードの持ち主が書くREVIEW.mdのどれかに書き足します。

承認の人数は変更の中身で決まる#

5つ目の層の承認は次の3段階です。

リスク	例	人の承認
低	ドキュメント、文言、社内向けの機能、フラグの裏で足すだけの変更	自動のレビューとセキュリティの検査が通れば不要
中	通常の製品の変更、キャッシュや自動更新、システムプロンプトのような繊細な部分	1人
高	最もリスクの高いコードと、常に2人が要る少数のパス	2人

分類器が変更を読んで段階を選び、別の分類器が「段階としては不要でも、この変更には人がもう1人要るか」を判断します。持ち主が繊細だと登録したパスと、CIのワークフローのファイルは、いつも人の承認が要ります。

承認にはほかにも条件があります。

• 軽い段階を使えるのは、リポジトリの信頼済みの作者（主にそのチーム）だけ。それ以外の人には2人目の承認が要る
• エージェントの承認は、人の承認として数えない
• エージェントが書いたPRでは、エージェントに指示した人が、必要なレビュアーの1人に数えられる
• 承認は特定のコミットに対するもの。エージェントのpushや人が手で競合を解消したマージなど、検査で裏付けられないコミットが入ると、承認し直しになる

AIのレビューが終わらない問題#

書くのもレビューするのもエージェントだと、やり取りが終わらなくなることがあります。Claude CodeのCLIのPRの1つは一晩でレビューと修正を50回以上往復し、作者が止めるまで続きました。人なら数秒で流す軽微な指摘も、エージェントは律儀に直し、そのたびにコミットとレビューが1回ずつ増えます。

チームが繰り返し出る指摘にgit blameをかけると、約59%は、最初のレビューの時点からあったコードでした。ブログはこの結果を、レビューが新しいバグをほとんど見つけず、古いバグを毎回少しずつ拾っていたと見ています。そこで、次の4つを入れました。

• 3回往復したら、レビューする側が作者に、やり方そのものを見直すよう求める
• 最初の数回が済んだら、新しい差分だけをレビューする
• 1行ではなくバグの種類を示し、作者が同じ種類の箇所をまとめて直せるようにする
• 投稿済みの指摘を繰り返さない

社内のPRで比べると、1回の往復で通るPRは65%から78%に増え、5回以上かかるPRは8.9%から1.5%に減りました。通るまでのレビューの平均回数は2.08回から1.32回です。

指摘の雑音も測定の対象です。作者が直したか、間違いだと答えたか、意図した動作だと答えたか、気にしなかったかで、全ての指摘を分け、問題がないと分かっているPRにもレビューをかけて、誤った修正につながる指摘をどれだけ出すかを数えます。過去にインシデントや差し戻しを起こしたPRは評価用の問題集にまとめ、毎日レビューの性能を採点しています。

人に残している判断#

ブログが人に残すとしているのは、機械が苦手な判断です。作るべきかどうか（方向、好み、範囲）と、課金や自動更新、CIのワークフローのような危ないコード、ほかの人が真似する設計の型は、人が決めます。テストの出力やスクリーンショット、レビューの指摘といった証拠を読むことと、出荷した変更の結果に責任を持つことも、人の仕事として挙がっています。承認する人には、検査が何を見逃すかを言えないなら、すぐ承認せずに本格的なレビューを頼むよう求めています。

まだ足りないものも書かれています。差し戻しやインシデントの数字が動いたときに、自動で承認を厳しくする仕組みはまだありません。人の承認なしのマージを広げる前に、その仕組みが欲しいという声がチーム内に上がっています。

AIで書くコードが増えたときに、確認する側の負荷がどう増えるかは、外部の論文と調査の数字を理解の負債の記事にまとめました。

公開版のCode Reviewでどこまで同じことができるか#

公開版のCode Reviewは、TeamとEnterpriseのプランで、GitHubのリポジトリに使えます。ゼロデータ保持（ZDR）やHIPAAの構成を有効にした組織と、顧客管理の暗号鍵（CMEK）を使う組織では使えません。複数のエージェントが探し、検証の段階で誤検知を除き、重さの順に並べて投稿する流れは、ブログの2つ目の層と同じです。レビューの深さはQuick、Standard（既定）、Deepから組織とリポジトリごとに選べます。

料金はレビュー1回あたりの定額ではありません。プランに含まれる利用分とは別に、トークンの使用量が利用クレジットから引かれます（料金と使用量のページ）。研究プレビューを始めたときの公式ブログは、平均で1回15〜25ドルとしていました。既定の「pushのたびにレビュー」では、pushの回数だけ費用が増えます。

ブログの流れと一番違うのは、マージを止めるかどうかです。公式ドキュメントには「レビューはPRを承認も停止もせず、チェックランは失敗で終わらない」と書かれています。チェックランの結果はneutralか、変更がないときのskippedです。社内のリポジトリのように未解決の指摘でマージを止めたいなら、自分で組みます。

• GitHubのブランチ保護の「Require conversation resolution before merging」を使う。指摘はPRの行へのコメントとして付くので、解決するまでマージできなくなる。ただし、人のコメントや軽微な指摘のスレッドも対象になる。GitHubが行へのコメントとして受け付けなかった指摘は、Files changedの注釈とチェックランの詳細にだけ出るので、この設定では止まらない
• チェックランの詳細の末尾にある、重さごとの件数の行を読む。normal（Importantの件数）が1以上ならジョブを失敗させる。この行がないときは0件ではなく「判定なし」として扱うよう、ドキュメントは求めている

ブログの「承認は特定のコミットに対するもの」には、同じブランチ保護の「Dismiss stale pull request approvals when new commits are pushed」が近い設定です。

REVIEW.mdはマージ先かデフォルトのブランチから読まれ、PRの中の変更は使われません。PRの中でREVIEW.mdを書き換えて、そのPRのレビューを甘くすることはできません。ただし、重さを下げる、パスを外す、軽微な指摘の数に上限を付ける、という指示が効くのは、デフォルトのブランチを保護しているか、PRのマージ先のブランチをrulesetで保護しているときだけです（カスタマイズのページ）。

公開版のCode Reviewは承認をしないので、リスクの段階で承認の人数を変える部分は自分で用意することになります。ブログの「取り入れ方」の節は、段階を書き出し、まず厳しく始めて、根拠が出てから緩めるよう勧めています。必ず人を通す部分（認証や課金、CIとリリースのワークフロー、インストーラー）はCODEOWNERSとブランチ保護で守り、ボットの承認を必要な人の承認の代わりにしないことも求めています。

TeamやEnterpriseでなくても、手元で使える部分はあります。/code-reviewコマンドはどのプランでも動き、自分のブランチの差分を、別の文脈のサブエージェントがレビューします（ローカルのレビュー）。費用はセッションの利用分に含まれます（使用量の見方は「Claude Codeのコスト管理：/usageの見方とエフォートの使い分け」）。こちらはCLAUDE.mdを読みますが、REVIEW.mdは読みません。両方で効かせたい指示はCLAUDE.mdに書く必要がありそうです。

効果の数字は自社の発表だけなので、目標と歯止めの指標は、自分のリポジトリで決めて測る必要がありそうです。