Claudeのコードチームはどのようにコードレビューを行っているか

Claude Codeチームはどのようにコードレビューを行っているか AIが生成するコードの量でコードレビューをどのように行いますか？ Claude Codeチームでは、高いカバレッジと深いレビューを行った後、リバートやインシデントにつながらない最小限の人間によるレビュー時間で最適化を開始しました。 著者Addy Osmani、Morgan Westlee Lunt、Qing Wang カテゴリエンジニアリング 公開日2026年10月15日 読書時間14分 以前にも述べたように、ClaudeはClaude Code自身のコードの約90パーセントを生成しています。では、その生成量でコードレビューをどのように行っているのでしょうか？ 誰かがコードを読むのでしょうか？ そして、何かが壊れた場合、誰がそれを検知するのでしょうか？ この記事では、Claude Codeチームのコードレビューフローと、その進化について説明します。6月から9月にかけて、Claude Codeのコードベースへのマージされたプルリクエストは倍増し、リバートする必要があったものの割合は40パーセント以上減少しました。レビューをなくしたわけではありません。しかし、ほとんどの読み取りを機械に移し、人間の時間と注意力を最適化し、間違いを元に戻すことを迅速かつ容易にするために多額の投資を行いました。 コードレビューの目的を再考する エージェントがコードを書くと、変更の数は急速に増加します。Anthropicのモノレポでは、1日あたりの変更数は、今年の5月には約2,500件でしたが、9月には30,000件を超えました。Claude Codeはモノレポとは別の独自のレポジトリにありますが、こちらもかなりのプレッシャーを受けています。これほど速いペースでリリースする場合、手動での行ごとのコードレビューは不可能ではないにしても、非常に困難です。コードレビューは2つの役割を果たします。 出荷前に問題を見つけて修正する チーム全体で共有コンテキストとコードベースの理解を構築する この記事は主に問題の発見と修正に焦点を当てていますが、2番目の役割については最後に触れます。「人間がコードを読んだか？」という問いは、「この変更で何が起こりうるか、そしてそれを検知するために適切なチェック（自動または人間）はどれか？」という問いの不正確な代理です。その問いを立てることは、レビューが行われるタイミングも変えました。以前は、レビューは道の終点にあるゲートでした。コードを書き、PRを開き、同僚を待ちます。今では、レビューは継続的に実行され、書いている間のスペルチェックのようなものです。ほとんどの変更は、人間が確認を求められる前に、少なくとも一度Claudeによってレビューされ、修正されています。これにより、ほとんどの日常的な間違いが捕捉され、チームの注意力をより高レベルの質問や精査に振り向けることができます。 希少なリソース：人間の時間と注意力 人間だけが解決できる問題のために人間の時間と注意力を温存し、残りは自動チェックで捕捉されるようにしたいと考えています。現在の変更ペースでは、人間がやるべき仕事は依然として膨大であり、私たちのチームはほぼ毎日新しい、前例のない課題に直面しています。人間の時間は、レビューに費やす時間と、悪いコードが引き起こす問題を修正する時間の両方のコストをカバーします。最初の時間を削減しても、その時間が2番目の時間として現れるだけでは役に立ちません。したがって、目標は、Claude Codeレポ（CLI、デスクトップおよびWebアプリ、モバイルアプリ）のほとんどのプルリクエストが、リバートやインシデントの増加なしに、最大1人の人間（著者自身である場合もある）が関与してマージされることです。人間の時間を測定するために、PRごとの人間の承認数（中央値と95パーセンタイル）、人間のコメント数、PRが人に保留されている時間を追跡します。リバート率とインシデント率はガードレールです。もしこれらが上昇すれば、人間の時間を節約したのではなく、単に時間を移動させただけです。 変更のライフサイクル エンジニアのラップトップ（またはSlackでのClaudeセッション）からの典型的な変更は、複数のコードレビューレイヤーを通過します。 FIG A: ほとんどのパスは自動化されており、リスクの高い場所に人間の注意力が向けられます。 レイヤーごとのチェック FIG B: 各レイヤーは一部の問題を捕捉し、一部は見逃します。すべてを通過するものは少なく、ロールバックが残りを処理します。 1. 誰かが確認する前に作業が検証される ほとんどのレビューは、PRが存在する前に行われます。Claudeに、テスト、ビルド、またはデザインと比較するためのスクリーンショットなど、実行できるものを与え、完了したと言う代わりにその出力を表示するように依頼します。次に、サブエージェントが新鮮なコンテキストで差分をレビューします。これらの習慣はどちらも、私たちのベストプラクティスガイドから来ています。PRを開く前に、私たちの多くはいくつかの内部スキルを実行します。1つはバグを探し、1つは差分を単純化し、1つはエンドツーエンドの動作をチェックします。UIの変更は、デザインガイドラインに対してもチェックされます。Claude Codeを作成したBoris Chernyは、Claudeに自身の作業を検証させることは、良い結果を得るために最も重要なことだと呼んでいます。彼は、それが最終結果を2〜3倍良くすると推定し、「検証はドメインごとに異なります。単純なbashコマンドの実行、テストスイートの実行、ブラウザや電話シミュレーターでのアプリのテストなどです。」と書いています。自動レビュー担当者が同じことを繰り返しフラグを立てる場合、ソースで修正します。スキル、リンタルール、または次のような指示ファイルへの更新によって行います。 CLAUDE.mdはClaudeにプロジェクトが何であるか、スタック、規約、目標、非目標を伝えます。すべてのレビューでロードされるため、大規模なコードベースでは短く保ち、そこから他のドキュメントを指します。レビュー担当者は、それに違反するコードや、それを古くする変更をフラグ付けします。 REVIEW.mdはコードオーナーによって書かれ、レビュー担当者にそのコードの部分で何が重要かを伝えます。レビュー担当者が実際にそれに従っているかどうかを別途チェックします。良いものは短いです。それらは、そのリポジトリで失敗がどのように見えるか（ドキュメントの場合は「嘘をつく」、設定の場合は「誤ルーティングする」）、ニッツを制限し、スキップするパスをリストし、名前からの推測ではなく証拠としてファイルと行を要求します。また、カウントで始まり、修正するものが何もない場合は明確に述べる要約を要求します。 2. すべてのプルリクエストに対するAIレビュー すべてのプルリクエストは、人間が確認する前にClaudeのレビューを受けます。