Claude Codeチームのコードレビュー手法：7つのステップとサーキットブレーカーなし

2026年10月15日、Claude Codeチームはコードレビューの方法について自らの説明を公開した。Addy Osmani、Morgan Westlee Lunt、Qing Wangの名で発表された14分のエンジニアリング記事である。なぜ誰もがこれを検索しているのかを説明する一文は早々に現れる。ClaudeはClaude Code自身のコードの約90パーセントを書いている、というものだ。この記事はその数字を擁護するものではなく、それが耐えうるものになる前にその下に存在していなければならなかった仕組みについての説明であり、注意深く読む価値のある部分は、いまだ欠けている部分である。

ほとんどの要約は、見出しになる2つの数字で止まっている。2026年6月から9月の間に、Claude Codeのコードベースへのマージ済みプルリクエストは2倍以上になり、一方でリバートが必要になった割合は40％以上減った。どちらもチーム自身による数字であり、どちらも複数の異なる体制で生み出されうる。人々が想定している、レビューが静かに撤廃されたという体制も含めて。投稿はそうではなかったと述べている。彼らは読み取りの大部分を機械に移し、人間の時間と注意力に最適化し、間違いを素早く簡単に取り消せるようにすることに投資した。残りはすべて、その方法の詳細だ。

そもそもなぜレビューがボトルネックになったのか

そのプレッシャーは政策決定から来たものではなかった。それは量から来ていた。その投稿によると、Anthropicのモノレポでは、1日あたりに取り込まれる変更が5月の約2,500件から2026年9月には30,000件超に増えた。Claude Codeはそのモノレポとは別の独自のリポジトリにあるが、より小規模ながら同じプレッシャーにさらされている。

そのペースでは、投稿も認めているように、手作業での行ごとのレビューは極めて困難であり、不可能に近い。そこでは、すべての差分を人間が読むことが不要だと言っている人は誰もいない。彼らが主張しているのは、すべての差分を読むことはもはやスケールしないということ、そして「人間がコードを読んだか」は常に、重要な問い――この変更で何がうまくいかなくなり得るのか、そしてそれを捉えるのに適切なチェックはどれか、自動か人間か――に対する不正確な代理指標にすぎなかったということだ。

そのように言い換えると、ゲートの位置が変わります。レビューは道の終点にある扉ではなくなり、執筆中のスペルチェックに近い、継続的なものになります。ほとんどの変更は、人が目を通す前にClaudeによって読まれ、修正されています。

彼らが何を最適化の対象としたのか、そして何が失敗と見なされるのか

明示された目標は、Claude Code の各リポジトリ（投稿では CLI、デスクトップアプリと Web アプリ、モバイルアプリと説明されている）におけるほとんどのプルリクエストが、関与する人間を最大1人（作成者でもよい）としてマージされ、リバートやインシデントが増加しないことだ。第3の条項があることで、これは単なるコスト削減の取り組みではなく、真の目標になる。

チームは台帳の両側で人間の時間を測っている。レビューに費やす時間と、悪いコードが壊したものを修正する時間だ。前者を削っても、コストが後者に再び現れるなら意味がない、とチームははっきり言う。そこで追跡している数値は、プルリクエストあたりの人間による承認数（中央値と95パーセンタイルで報告）、人間によるコメント、そしてプルリクエストが人を待つ時間だ。リバート率とインシデント率は、そのすべての土台にガードレールとして位置している。それらが上がるなら、人間の時間は節約されたのではなく、移動しただけだ。

レビューコストの指標は単独では簡単に操作できる。何でも承認するレビュアーは、美しい承認時間チャートを生み出す。そのチャートが嘘をつくのを防ぐのがガードレールだ。

一つのゲートではなく、七つのステップ

その記事は、典型的な変更の道筋を7つの番号付きステップとして示している。各層はいくつかの問題を捉え、ほかの問題は見逃す。そして、より安価なチェックがより高価なものより先に実行される。

• プルリクエストが存在する前の検証。Claudeがテスト、ビルド、リンターを実行し、2体目のエージェントが新しいコンテキストで差分をレビューします。多くのエンジニアは内部スキルも実行しています。1つはバグを探し、1つは差分を簡素化し、1つは動作をエンドツーエンドで確認します。Claude Codeを開発したBoris Chernyは、Claudeに自身の作業を検証する手段を与えることが、良い結果を得るためにおそらく最も重要なことだと述べており、それによって最終的な結果が2〜3倍良くなると見積もっています。

• すべてのプルリクエストに対するAIレビュー。 Claudeによるレビューは、差分をリポジトリ全体およびプルリクエストに記載された意図と照らし合わせて読み取ります。複数のエージェントが並行してバグを探し、その後、別のグループが各指摘について投票し、十分な人数が実際に問題だと同意した場合にのみ投稿されます。スタイル、診断、クリーンアップに関する指摘は破棄されます。残った指摘は、Important、Nit、Pre-existingのタグが付いたインラインコメントとして表示されます。リサーチプレビューの開始時、実質的なレビューコメントを受け取る社内プルリクエストの割合は16パーセントから54パーセントに増加しました。管理者は各リポジトリをQuick、Standard、Deepのいずれかに設定します。

• セキュリティレビュー。 もう一つ別に実行される自動パスです。どちらかのレビューで指摘がオープンになっている間は、プルリクエストをマージできません。修正するか、短い理由を添えてスレッドをクローズしてください。同じチェックは、オープンソースのセキュリティレビュー GitHub Action または /security-review コマンドとして公開されています。

• ブロックする自動チェック。Lint、型チェック、すべてのプラットフォームでのテスト、およびビルド。

• リスクに応じて段階化された人による承認。 分類器が変更を読み取り、作成者が設定するのではなく、ティアを設定します。このステップには以下で独立したセクションを設けています。というのも、興味深い設計の大半がここにあるからです。

• マージキュー、フラグ、段階的リリース。 キューは変更を適用した状態で main に対してすべてのチェックを再実行するため、それぞれ合格した2つのプルリクエストが組み合わさって main が壊れることはありません。新しい動作はまずフラグの背後で Anthropic の従業員に提供され、その後 latest チャンネルへ、stable はそれに遅れて追随します。

• 迅速な検出とロールバック。フラグはデプロイなしでオフになり、週次のオンコールローテーションがあり、インシデントレビューではどの層が問題を捉えるべきだったかを問います。それでもすり抜けるミスはあるため、最後の層はミスを防ぐことではなく、いち早く気づくことに関わります。

変更が設定するのはティアであり、作成者ではありません

ドキュメントの修正とオートアップデーターの変更は同じリスクを伴うものではないため、同じレビューが行われることもありません。記事の表は3つの階層に分かれており、それぞれがただ1つの問いに答えます。すなわち、マージ前に承認が必要な人が何人いるのか（そもそも不要な場合もある）という問いです。

低は、ドキュメント、コピー、内部専用機能、フラグで制御された追加的変更を対象とし、自動レビューとセキュリティが通過すれば、人手は不要です。中は、通常の製品変更に加え、キャッシュ、自動アップデーター、システムプロンプトなどの機密領域を対象とし、1名の対応が必要です。高は、最もリスクの高いコードと、常に2名の対応が必要な少数のパスを対象とします。

分類器は設計の半分にすぎない。2つ目の分類器は、そのティアが不要と示していても、この特定の変更に別の人間が必要かどうかを問い合わせる。ティアに関係なく常に人間を必要とするパスもある。オーナーが機密として指定したものすべてと、すべてのCIワークフローファイルだ。リポジトリの信頼リストに載っている作者、主に所有チームだけが軽いパスを利用でき、それ以外は全員2人目の人間を必要とする。エージェントの承認は人間の承認として決して数えられないため、自動レビューは低リスクの変更を通過させられても、人間を必要とする枠を埋めることはできない。変更を促した人物がその責任を負う。また、承認は1つの特定のコミットのみを対象とするため、エージェントのプッシュや手動で解決したマージを含め、新しいコミットには再び承認が必要だ。

分類器を作らないとしても、盗む価値のある詳細が2つある。階層は作者ではなく変更に由来し、信頼はその上に重なる別個の、より狭いゲートだ。そして承認はプルリクエストではなくコミットに紐づく。これにより、レビューシステムで最もよくある穴が塞がれる。つまり、ブランチの早い段階で得た緑のチェックマークが、誰も見ていないコードに使われてしまうという穴だ。

レビュアーは自分自身のインシデントに基づいてトレーニングされている

これはほとんどの解説記事が飛ばしてしまう部分であり、なぜその仕組みがずれることなく機能し続けるのかを説明してくれる。

チームは、インシデントを引き起こした過去のプルリクエストを、そのフィックスフォワードやリバートとともに収集し、そのコードを熟知したエンジニアに、各バグとそれが存在していた箇所を確認してもらった。そのコレクションは現在、評価セットになっている。レビュアーは毎日それに対して実行される。プロンプト、ツール、モデルのいずれかが変わると、その変更はセット全体で通用しなければならない。スコアが上がれば残し、上がらなければ捨てる。彼らの失敗は、彼らの失敗を捕まえるはずのもののテストスイートになった。

それは、固定されたルールセットに照らして評価されるリンターを調整するのとは異なる姿勢です。このレビュアーは、このコードベースがすでに壊れた具体的な事例に照らして評価されるため、何か問題が起きるたびに評価項目が増えていきます。私たちが読んだAnthropicの公表物のいずれにも、そのスコアは記載されておらず、投稿もこのレビュアーが完成したとは主張していません。

まだ構築されていないレイヤー

これが、この投稿を信頼できるものにする告白です。ここまでの内容はすべて、誤りを検出して取り消すシステムについて述べており、自身のエラー率が変化していることに気づくシステムについてではありません。チームにはまだ、リバートやインシデントの件数が変化したときに承認を自動的に厳格化するサーキットブレーカーがなく、そこのエンジニアたちは、より多くのコードを人的関与ゼロのマージへ移行する前にそれを導入したいと考えています。

代わりに存在するのは、人間による察知だ。フラグはデプロイなしでオフになり、週次のオンコール当番が見守り、インシデントレビューではどの層が問題を捕捉すべきだったかを問う。同僚のある言葉は、同様のロールアウトを計画する誰にとっても最も有用な一文だ。速度を落とせば確かにエラー率は下がるが、それは主に、あらゆることを少なくやっているからにすぎない。チームは、問題を生み出すのが遅くなるよりも、問題に気づいて修正するのが速くなることを望んでいる。

それを念頭に置いて、七つのステップをもう一度読んでください。六つは、変更を進めるかどうかを決めます。七つ目は、後から気づくための一連の習慣です。成果からゲートへ戻るフィードバックループは組み込まれておらず、システムを作った人たちもそう言っています。

レビューの第2の役割であり、この投稿では主に脇に置かれているもの

投稿は、コードレビューには2つの役割があると明言している。リリース前に問題を見つけて修正することと、チーム全体で共有されるコンテキストを築くことだ。投稿は前者に焦点を当て、その後で後者に戻り、異例なほど正直な答えを示している。それに関する正式なプロセスはなく、Claude Codeの完全なメンタルモデルを頭の中に保持している人は誰もおらず、誰にもその必要はないと考えているという。コードベースの一部を理解したい？まさにその部分の解説をClaudeに頼もう。

2つの指示ファイルが、かつてはレビュアーの頭の中にあったコンテキストを担っています。CLAUDE.md は、プロジェクトとは何か、スタック、規約、目標と非目標を Claude に伝えるもので、意図的に短く保たれています。REVIEW.md はコードオーナーによって書かれ、自分たちの担当コードで障害がどのような形で現れるか、スキップすべきパスはどれかを示し、推測ではなくファイルと行を示すよう求めます。

説明責任はそれ自体で一項目を成す。マージしたら、責任を負う。小規模または中規模の変更をマージして何か問題が起きた場合、自分で修正するのが規範だ。これが機能するのは、変更が小さく、フィーチャーフラグとリバートによってほとんどのミスを数分で取り消せるうえ、影響範囲（ブラストラディウス）が変更にどれだけのチェックを課すかの基準を定めるからだ。これは承認ルールの上に重ねられた規範であり、承認ルールに取って代わるものではない。

ルーターが適する場合と、適さない場合

上のパイプラインはモデル呼び出しのパイプラインだ。レビューエージェントがリポジトリ全体に対してdiffを読む処理、並列に動く複数のバグ探索エージェント、各指摘に対するグループ投票、セキュリティパス、そして成長し続けるevalに対して日次で再実行されるレビュアーから成る。これはレビュー問題である前にルーティング問題だ。なぜなら、あるプロバイダの調子が悪い午後だからといって、マージキューが止まってよいはずはないからだ。

OrcaRouterは、1つのキーで200以上のモデルを利用できるOpenAI互換の単一エンドポイントであり、プロバイダー間の自動フェイルオーバーとゼロマークアップ（プロバイダーの定価がそのまま適用されること）を備えています。このパイプラインの自社版を運用するチームは、請求の窓口が1つにまとまり、レビュアーによる品質評価が変わった際にモデルを切り替える場所も1つになるため、これはまさに日次評価が検出するように設計されているものです。

境界は重要です。当社はモデルをホストしています。Claude Code をホストしているわけでも、Claude Code 向け Code Review を実行しているわけでもなく、この記事が扱っているパイプラインにアクセスすることもできません。Claude Code 向け Code Review は Anthropic の製品で、Team プランと Enterprise プランで一般提供されており、軽量版は /code-review としてローカルで利用できます。求めているのがそのパイプラインなのであれば、それはそこにあります。あなたのチームのそのバージョンでは、ルーターはレビュー上の判断ではなく、配管上の判断です。

小規模なチームが実際に真似できること

レビュールールを、レビュアーが読める場所に書き留める。プロジェクト用の短いCLAUDE.mdと、領域ごとのREVIEW.mdで、失敗がどのような形で現れるかを明示し、推測ではなくファイルと行を要求する。リスク階層を文書化し、作成者ではなく変更の属性にする。厳しく始め、証拠がある場合にのみ緩める。自動レビューが承認できる範囲に上限を設け、エージェントの承認を人の承認として数えてはならない。承認をコミットに紐づける。マージキューを実行する。インシデントとリバートをテストケースに変え、レビュアーを変更するたびに再スコアリングする。測定されていないレビュアーは、マーケティングが上手いだけのリンターにすぎないからだ。

ならば、承認までの時間ではなくガードレールを見てください。チーム自身の枠組みが、検討中のあらゆるレビュー変更に対するテストを与えてくれます。リバート率とインシデント率は維持されたのか、それとも時間がレビュアーから後片付けをする人へ移っただけなのか。この問いは、ほとんどのチームがすでに持っているデータで答えられ、本当に速くなったプロセスと、四半期だけ速く見えるプロセスを区別します。