10月15日、claude.devが「How the Claude Code team does code review / claude.dev Blog」と題した記事を公開した。この記事では、AIエージェントがコードの約90%を書くClaude Codeチームが、急増するPR量に対してコードレビューをどう設計・運用しているかについて詳しく紹介されている。

「人間がコードを読んだか」は問いが間違っている

Anthropicのモノレポへの1日あたりのコミット数は、今年5月の約2,500件から9月には3万件以上に急増した。Claude Codeのリポジトリは独立しているが、同様のプレッシャーにさらされている。

この規模になると、従来型の「人間がPRを開いて1行ずつ読む」レビューは現実的でなくなる。そこでチームが問い直したのが、コードレビューの本来の目的だ。

「人間がコードを読んだか」は「この変更で何が起こりうるか、それを検出するのに最適なチェックは何か」に対する不正確な代替指標に過ぎない。

レビューはPRの末尾に置かれたゲートから、コードを書きながら動くスペルチェックのような継続的なプロセスへと移行した。

成果として、6月から9月の間でClaude Codeのコードベースへのマージ済みPR数は2倍以上に増えた一方、リバートが必要だったPRの割合は40%以上減少した。

7層構造のレビューパイプライン

チームが構築したのは、以下の7層からなるチェック体制だ。ポイントは「人間のレビューは削除しない。ただし、読む作業のほとんどを機械に移した」という設計思想にある。

層1: PRを開く前の自律検証

最もユニークな工夫がここだ。PRを作成する前に、Claude自身がテスト実行・ビルド・スクリーンショット比較などで結果を検証し、さらに別のサブエージェントがdiffをレビューする。

Claude Code作者のBoris Chernyは、Claudeに検証手段を与えることを最も重要な習慣と呼び、「最終結果を2〜3倍良くする」と述べている。

重要な仕組みが2つのファイルだ：

• CLAUDE.md: プロジェクトのスタック・慣習・目標を記述。すべてのレビューがこれを読み込む。大規模コードベースでは短く保ち、詳細は別ドキュメントへのポインタを置く。
• REVIEW.md: コードオーナーが書く。そのリポジトリで「失敗がどう見えるか」（ドキュメントなら「嘘をつく」、設定ファイルなら「誤ルーティングする」）を定義し、スキップするパス、証拠として必要なファイルと行番号などを指定する。

層2: 全PRへのAIレビュー

すべてのPRに対し、人間が見る前にClaude reviewが走る。チームが内部展開した際、実質的なレビューコメントが付くPRの割合が16%から54%に増加した。1,000行超のPRのほとんどに指摘が入り、小さなPRの多くはクリーンな判定で返ってくる。

ノイズ対策として、複数のエージェントが同時にバグを探し、別のエージェントグループが各発見に投票する。過半数の同意を得たものだけがコメントとして投稿される。スタイルや診断系の指摘は除外される。この絞り込みは自分たちのPRでA/Bテストして採用した。

コメントはImportant・Nit・Pre-existingの3種類にタグ付けされる。PRが持ち込んでいないバグは「Pre-existing」として、作者の責任に見えないよう区別する。

すべての指摘には回答義務がある。修正するか、スレッドを理由付きでクローズするかのどちらかだ。エージェントが夜間に修正を行うケースも多く、作者が翌朝PRを開くと「すでに別ラウンドのレビューが完了している」状態になっていることもある。

層3〜4: セキュリティレビューと静的チェック

セキュリティレビューはブロッキングで動作し、未解決の指摘があるとマージできない。その後、lint・型チェック・全プラットフォームのテスト・ビルドが走る。CLIのPRでは、人間が確認する前に数十のチェックが実行される。

層5: リスクに応じた人間承認

ここが設計の核心だ。変更のリスクに応じて必要な人間承認数が変わる。

ティアを決めるのは変更内容であって、作者ではない。分類器が変更を読んでリスクティアを決定する。エージェントの承認は人間の承認としてカウントされない。また、エージェントが書いたPRでも、そのエージェントに指示した人間が承認者の1人としてカウントされる。

層6〜7: マージキューとロールバック

マージキューがmainへのマージ前にすべてのチェックを再実行し、「単独では通る2つのPRが組み合わさってmainを壊す」状況を防ぐ。新機能はAnthropicの社員向けにフラグで先行公開し、ヘビーな内部利用でリグレッションを検出する。

最後の砦はロールバックの速さだ。フラグはデプロイなしでオフにできる。ただし、承認数ゼロのマージが増える前に自動サーキットブレーカーが欲しいという意見がチーム内にある点も正直に記されている。

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

記事の中で最もリアルな失敗談がここだ。エージェントが書いたPRをエージェントがレビューすると、互いに延々と修正・指摘を繰り返す無限ループに陥ることがある。実際に1つのCLIのPRが一晩で50ラウンド以上のレビューと修正を繰り返した事例が紹介されている。

git blameで分析すると、レビューが繰り返し指摘していたコードの約59%は初回レビューから存在していたものだった。新しいバグを発見しているのではなく、古いバグを少しずつ追加で発見していたに過ぎない。

この問題への対処として以下を導入した：

• ラウンドキャップ: 3ラウンド後、レビュアーがアプローチ全体の見直しを促す
• 差分のみの再レビュー: 最初の数パスの後は変更箇所だけを対象にする
• バグのクラスを指摘: 1行ではなく、同種のバグ全体を修正させる
• 重複指摘の禁止: 既に投稿した指摘を繰り返さない

人間が担い続ける判断

ルーティンな確認作業を機械に渡した結果、チームの人間が集中するのは以下の領域になった：

• 「そもそも作るべきか」の判断：方向性・スコープ
• リスクの高いコード：課金処理、自動アップデーター、CIワークフロー
• 他が真似するアーキテクチャの決定
• 証拠を読む能力：テスト出力・スクリーンショット・レビュー結果。「チェックが何を見逃すか」を説明できない場合は、素早い承認ではなく本格的なレビューを求める

また、コードベースの共有知識（コードレビューのもう一つの目的）については、今も定期的なコードウォークスルーを続けている。高速な変更サイクルでは「誰もがすべてを読む」は不可能だが、「誰かがすべてを読む」が机上の話にならないよう意識的に維持している。

詳細はHow the Claude Code team does code review / claude.dev Blogを参照していただきたい。