コードレビューのボトルネックがついに崩壊
ソフトウェア開発における伝統的なボトルネックであったコードレビューが、劇的な変化を遂げています。例えば、Anthropicのメインモノレポでは、5月には1日あたり約2,500件だった変更が、9月のピーク時には30,000件を超えました。同時に、現在Claude Codeが書くコードの約90%をClaude自身が生成しており、人間が一行ずつ検査することは現実的ではなくなっています。
Anthropicのチームは、すべての行を人間がレビューすることを目指すのではなく、「この変更で何が問題になり得るか？」「それを検知するために、自動化または人間によるどのようなチェックが最適か？」を問いかけるようになりました。この実用的なアプローチにより、ほとんどのプルリクエスト（PR）は、作成者のみを含む最大1人の人間による関与でマージされます。Claude Codeの作成者であるBoris Cherny氏は、従来の手法では不可能なペースである1日20〜30件のPRをリリースしています。
この新しいシステムは驚くべき成果を上げています。6月から9月の間に、マージされたPRの数は2倍以上に増加しました。重要なのは、リバートが必要になったPRの割合が40%減少したことであり、これは人間によるレビューの負担軽減が必ずしも欠陥の増加を意味しないことを示しています。この転換は、大規模な環境でコード品質をどのように保証するかという根本的な再評価を浮き彫りにしています。
バグは幾重もの試練を乗り越えなければならない
バグは、人間の目に触れる前に問題を捕捉するように設計された自動チェックの試練に直面します。Claudeはまず、作成者のセッション内でテストを実行し、アプリケーションをビルドし、スクリーンショットを比較することで、自らの作業を自己検証します。その後、新しいコンテキストを持つサブエージェントが独立して差分をレビューし、作成セッションからのバイアスが初期評価に混入しないようにします。
プルリクエストが作成されると、専用のClaudeレビューア製品が引き継ぎ、複数のエージェントを展開して同時にバグを検索します。次に、別のエージェントグループがこれらの発見事項について投票を行い、十分な合意が得られた場合にのみコメントが投稿されるため、誤検知が大幅に削減されます。
システムは失敗から学習し、繰り返される問題をlintルールやCLAUDE.mdファイル内の具体的なガイダンスへと変換します。これにより、一般的なエラーが上流で対処され、再発が防止されます。逆に、レビューアが許容可能なコードを繰り返し指摘する場合は、コード所有者が記述したreview.mdファイルによって、その特定のコード領域における何が不合格の基準となるかが明確化されます。
マージの前に、独立したセキュリティレビューエージェントが脆弱性を精査し、テスト、型チェック、lintを含む標準的なCIチェックに合格する必要があります。この階層化された「スイスチーズモデル」により、たとえ一つの防御層に「穴」があっても、後続の層が欠陥を捕捉する可能性が高まり、Anthropicは安定性を犠牲にすることなくマージをスケールさせることができています。
レビューアにもレビューが必要
人間によるレビューは、階層化されているとはいえ、依然として重要なセーフガードです。ドキュメントの更新や機能フラグ付きの作業など、信頼できる作成者による低リスクの変更は、多くの場合、人間の承認をバイパスします。通常の変更や機密領域への変更には1人の人間の承認が必要であり、高リスクのパスには2人の承認が求められます。Anthropicの分類エージェントがこれらの階層を決定し、2番目のエージェントが人間によるレビュー要件を検証します。
評価は実世界への影響に焦点を当てています。インシデントに関連するバグはレビュー担当者の日次テストケースに変換され、システムが過去の失敗から確実に学習できるようにしています。過剰なノイズを発生させることなくパフォーマンスを確実に向上させるプロンプト、モデル、またはルールの変更のみが保持されます。この反復的なフィードバックループにより、自動レビュープロセスは常に洗練されています。この複雑なシステムの詳細については、「How the Claude Code team does code review」を参照してください。
しかし、エージェント同士のレビューはシステムをループに陥らせる可能性があります。過度な細かい指摘は繰り返しの編集とそれに続くレビューを引き起こし、あるPRでは50回以上のラウンドが記録されました。これに対処するため、Anthropicはレビューラウンドに上限を設け、後半のレビューは「新しい変更点」のみに焦点を当てるように変更しました。この介入により、1回のラウンドで承認されるPRは65%から78%に跳ね上がり、5回以上のラウンドを必要とするPRは9%から1.5%へと激減しました。
この記事が気に入ったら、毎朝同じようなものをメールで受け取れます。
1日1通 · 2クリックで解除 · サードパーティのトラッキングなし
チームが模倣できること、できないこと
Anthropicの劇的なスケーリングはAIネイティブなエンジニアリングの一端を垣間見せてくれますが、すべてのチームが彼らのアプローチをそのままコピー＆ペーストできるわけではありません。マージされたPRは「2倍以上」に増加し、リバート率は「40%」低下しましたが、公開された指標は、壊れた変更の「総数」が実際に減少したことを決定的に証明するものではありません。変更のボリュームが十分に増加していれば、割合が低くてもリバートの絶対数は増加している可能性があるからです。
Anthropicのマルチエージェントレビューシステムを再現するには、多大なリソースと高度に専門化された社内ツールが必要です。ほとんどの組織には、Claudeがレビュー能力を自己改善するために必要なトークン予算、計算能力、または洗練されたフィードバックループが不足しています。これは迅速な統合ではなく、根本的なアーキテクチャの転換です。
それにもかかわらず、どのチームにも適用できる実用的な教訓はあります。エージェントには「簡潔な指示」を与え、繰り返し発生するエラーは反復的に修正するのではなく、チェックを自動化してください。レビューループに上限を設けてください。Anthropicは、エージェントが50回以上のラウンドで立ち往生してしまう可能性があるという教訓を痛感しました。人間の注意は、アーキテクチャの選択やリスクの高い課金コードなど、真に「重要な決定」のために取っておくべきです。最終的に、「自分がマージしたものは、自分が責任を持つ」というルールが最も重要です。成果に対する説明責任は依然として人間にあります。
よくある質問
AnthropicはClaude Codeのすべての変更を人間がレビューしていますか？
いいえ。人間のレビューはリスクに応じて行われます。信頼性が高くリスクの低い変更は人間の承認なしにマージされることがありますが、機密性が高い、またはリスクの高い変更には1〜2人の人間の確認が必要です。
AnthropicはAIが生成したコードをどのようにレビューしていますか？
そのプロセスは、ローカルテスト、最新のコンテキストを用いたエージェントレビュー、マルチエージェントによるバグおよびセキュリティチェック、CI、リスクベースの人間のレビュー、そして本番環境の監視を組み合わせています。
Anthropicのリバート率は、本番環境に到達するバグが減少したことを証明していますか？
それ単体では証明していません。マージされたPRのうちリバートされたものの割合は40%低下しましたが、マージされたPRのボリュームは2倍以上になっており、Anthropicはその基礎となる件数を公開していません。
小規模なエンジニアリングチームはAnthropicから何を模倣できますか？
繰り返し発生するリスクには自動チェックを使用し、エージェントへの指示を絞り込み、レビューラウンドを制限し、リスクに応じて人間のレビューを割り当て、変更をマージした本人がその結果に責任を持つようにしてください。