Claude Code チームが公開した、AI が書いたコードをレビューする具体的なワークフロー
Claude Code チームはレビューを開発プロセス全体に組み込み、機械にミスを検知させ、人間はリスクに応じて確認する体制を構築。AI同士のレビューが発散しないための収束ルールも導入した。
Claude Code チームによると、Claude Code 自身のコードの約90%は Claude によって書かれている。変更の量が爆発的に増えるにつれ、エンジニアがすべてのコミットを1行ずつ読み通すことは現実的ではなくなった。
6月から9月にかけて、Claude Code のコードベースにマージされた PR（プルリクエスト）の数は2倍以上に増加した一方、ロールバックが必要となった割合は40%以上減少した。（PR：Pull Request の略。コードベースへのレビューとマージを目的として提出される一連の変更。ロールバック：すでにマージされた変更を取り消すこと）
これほど大きな割合のコード作成を AI が担うようになると、人間が1行ずつレビューする従来のやり方は追いつかなくなり、開発プロセスのボトルネックとなってしまう。コードレビューのあり方も、開発の最終段階に置かれた最後の関門から、開発プロセス全体を貫く継続的なチェックへとシフトし始めた。Claude Code チームは、AI が書いたコードをレビューする具体的なワークフローを公開した。
このワークフローの核心は、コードを読む作業の大半を機械に委ね、エンジニアの時間と注意力を人間の判断が不可欠な重大リスクに集中させることにある。同時に、ミスがより早く発見され、より容易に取り消せる（ロールバックできる）仕組みを整えている。
コード変更が急増する中、コードレビューの目的を再考する
コードレビューは通常、2つの役割を担っている：
- マージ前に問題を発見し修正すること。
- チーム内でコードに対する理解と合意を形成すること。
従来、これら2つの要求は同一のステップに紐づけられていた。すなわち、コードを書き、PR を提出し、同僚が1行ずつレビューしてくれるのを待つ、という流れである。
レビューに費やされる人間の工数には2つの要素がある。本番リリース前にチェックにかける時間と、見逃された問題が発生した後に修正にかける時間である。前者を減らした結果として後者が大幅に増えてしまえば、トータルの時間は一切節約できない。
チームの狙いは、大半の PR をマージする際、関与する人間を高々1人（作成者本人でもよい）に抑えることにある。人的負荷が実際に軽減されているかを判断するため、チームは PR ごとの人間の承認回数、人間のコメント数、そして人間の対応を待つ待ち時間を追跡している。承認回数については、一般的な状況だけでなく、より多くの人的関与を要したケースを把握するために、中央値と95パーセンタイル（P95）の両方を注視している。
これらの指標は、機械によるレビュー往復回数とは性質が異なる。自動チェックが一瞬で完了したとしても、PR は人間が対応するのを待ってキューに留まり続けることがあるからだ。また、承認の手間を減らした結果として本番リリース後の障害や修正作業が増えてしまっては、人的コストを後工程に先送りしたに過ぎない。そのため、ロールバック率とインシデント（障害）発生率は、この最適化において決して譲れない防衛ラインとなっている。
ここでいう Claude はモデルとしての機能を提供し、エージェントはモデルと各種ツールを用いて具体的なタスクを実行する自律型 AI エージェントを指す。このワークフローでは、コードの作成、検証の実行、変更内容のレビューをそれぞれ異なるエージェントに分担させることができる。以降では、コードレビューを担当する側を「レビューエージェント」または「レビュアー」と呼ぶ。
エージェントが大量のコードを書くようになると変更の件数が爆発的に増え、事後的に人間がチェックする従来のゲートウェイはボトルネックになりやすい。「人間がコードを読んだかどうか」は、「その変更によってどんな問題が起こり得るか」と必ずしも正確に対応しないからだ。
そのため、レビューの根本的な発想は、より実践的な問いへとシフトした。「この変更によってどんなエラーが起こり得るか、そしてそれを検出するのに最も適した自動チェックや人間の判断はどれか？」
この発想の転換は、レビューが行われるタイミングをも変えた。レビューはもはや最後に人間の承認を待つだけの関門ではなく、コードを書きながらバックグラウンドで動き続けるスペルチェッカーに近い存在となった。大半の一般的なミスは、人間の視界に入る前に、すでに自動チェックと自動修正によって一通り処理されている。
仮にチームが CLI（コマンドライン）ツールに --retry-timeout という名前のパラメータを導入し、ネットワーク切断時のリトライ所要時間を制御してメッセージを出力させると想定してみよう。このような変更も、もはや同僚が1行ずつ読んでくれるのを列に並んで待つのではなく、目的に応じた多層の自動検証と段階的な処理をまず通過することになる。
多層防御：1つの変更がローカル検証から本番稼働後に至るまで
急速に増加する変更量に対して、単一の人的レビューでは見落としが生じやすく、負荷にも耐えきれない。Anthropic は実際のワークフローにおいて複数の検査レイヤーを組み合わせている。それぞれの検査レイヤーには検出が得意な問題がある一方で、それぞれに見逃しの可能性もある。すべての検査をすり抜けてしまったごく一部の問題については、マージ後の迅速なロールバックとフィーチャーフラグ（機能スイッチ）によって安全を担保する。
1. コミット前の検証：他人がレビューする前にコード自身に正しさを証明させる
ごく一般的なミスの大部分は、PR を作成する前に解消されているべきである。エージェントに対して単に完了したかどうかを尋ねるよりも、実際にコードを実行させて結果を提示させる方がはるかに信頼性が高い：
- 実行して結果を提示させる：テストスイートの実行、ビルドの実行、CLI コマンドの出力、あるいはブラウザやシミュレータでの UI スクリーンショット比較など、モデルに実際に実行可能な環境とコマンドを与え、実際の実行ログをエビデンス（証拠）として提示させる。
- 新しいコンテキストでの再レビュー：レビューを担当する別のサブエージェントを個別に起動し、コード作成時の対話コンテキストを引き継がせることなく、プロジェクト資料をゼロから読み直させて今回のコード差分（Diff）を検証させる。これにより、作成時の思い込みや既存の思考の流れがレビューに与える影響を減らせる。
- エンジニアリング規約の内面化：簡潔な
CLAUDE.mdにプロジェクトの技術スタック、規約、目標、明確に「やらないこと」を記述し、より詳細なドキュメントへのリンクを設ける。レビュアーはコードがこれらの規約に違反していないかをチェックするだけでなく、今回の変更によってファイル内の記述が陳腐化していないかもチェックする。
多くのエンジニアは、コミット前にいくつかの社内スキル（内部ツール）を実行し、バグの検出、コード差分の簡素化、エンドツーエンド（E2E）動作の検証を個別に行っている。UI の変更であれば、デザイン仕様との照合も行う。テストが通ることと、実際の利用フロー全体が正しく動くことは、それぞれ個別に確認すべき2種類のエビデンスである。
各モジュールの責任者が作成する REVIEW.md は、レビュアーに対して「この領域において、どのような問題を報告する価値があるか」を指示する。具体的な不合格の定義に加え、些細な指摘を抑制し、スキップしてよいファイルパスを列挙し、関数名からの推測ではなく具体的なファイル名と行番号をエビデンスとして提示することを義務付ける。さらに、結果の要約では最初に検出された問題の件数を述べ、修正すべき問題がなければ「ない」と明記させる。チームはレビュアーがこれらの要件を実際に遵守しているかどうかも別途検証している。
たとえば、本稿のリトライパラメータの例に合わせて架空のガイドラインルールを記述するとこうなる：「リトライ処理が設定された総所要時間を遵守しているか確認せよ。超過する場合は関連ファイル、行番号、発生条件を提示せよ。単なる変数名の好みを理由に変更を提案してはならない。問題が発見されなかった場合はその旨を明記せよ。」このように、探すべきエラーと求められるエビデンスを明示することで、単に「コードを注意深くレビューせよ」と指示するよりもはるかに確実に実行できるようになる。繰り返し発生する問題はガイドファイルやスキル、静的解析ルールへとフィードバックされ、次回の開発時に早い段階で回避されるようになる。
--retry-timeout の例で言えば、エージェントはローカル環境でタイムアウトのシナリオを網羅したテストを実際に実行し、実際の所要時間とログを含めた出力を提示しなければならない。パラメータ名のスペルミスや型の不一致があれば、同僚のレビューを待つまでもなくローカルの段階で露呈する。
2. 継続的インテグレーション（CI）チェック
コードがリモートにプッシュされると、クロスプラットフォームでのコードスタイルチェック、型チェック、ユニットテスト、ビルドパッケージングが一括して実行される。CI で失敗（赤信号）が発生した場合、コードのマージは即座にブロックされる。
3. すべての PR がまず AI によるレビューを受ける
すべての PR は、人間が目を通す前にまず自動レビューを通過する。このレビュー機能の公開プロダクト版は「Code Review for Claude Code」と呼ばれている。具体的なアプローチは以下の通りである：
- リポジトリ全体のコンテキストと意図の統合：モデルはリポジトリ全体のコードと PR の説明文に記載された意図を結びつけ、変更が目的の問題を解決しているか、既存のシステムと整合しているか、他のモジュールを破壊していないかを評価する。この機能のリサーチプレビュー（research preview）公開後、実質的なレビュー指摘を得られた社内 PR の割合は 16% から 54% に上昇した。これは、より多くの PR が中身のあるフィードバックを得られるようになったことを示すものであり、既知の脆弱性の 54% が検出されたという意味ではない。
- 欠陥の探索と検証の分離：複数のエージェントがバックグラウンドで並行して潜在的な欠陥を探索し、続いて別のエージェント群が各指摘に対して投票を行う。十分な合意が得られた場合にのみコメントとして投稿することで、単なるコードスタイルの好みや些細な揚げ足取りをフィルタリングする。
- 重要度分類と対応の義務付け：残された指摘は「重要」「軽微」「既存コードの課題」などに分類される。PR の作成者は修正を行うか、または理由を提示してスレッドをクローズしなければならず、無視して素通りすることはできない。
4. 独立した自動セキュリティレビュー
セキュリティレビューは独立したチェックとして実行される。セキュリティレビューまたはコードレビューに未解決の問題が残っている場合、マージはブロックされる。リトライパラメータの例で言えば、ログ出力にマスキングされていない認証情報が誤って含まれていた場合、セキュリティレビューでそれを検知した場合は、マージを阻止する。作成者が問題を修正するか、あるいは誤検知である理由を説明して初めてブロックが解除される。
5. リスクに応じた段階的な人的承認
変更内容によって潜在的な影響力は異なる。ドキュメントの修正、通常の機能開発、自動アップデート処理の変更では、それぞれ抱えるリスクが全く異なる。システムは変更そのもののリスクレベルに基づいて、必要な承認者の人数を決定する。
6. マージキューと社内ドッグフーディング
マージキューは最新のメインブランチ上で全チェックを再実行し、単体ではパスした2つの PR が同時にマージされた際にメインブランチを破損させる事態を防ぐ。フィーチャーフラグは「コードがすでにマージされていること」と「機能がユーザーに公開されていること」を切り離す。コードはまずメインブランチにマージされ、その後に段階的に機能が有効化される。新機能は基本的にフラグの背後に配置され、Anthropic 社内の従業員が日常業務で先行利用（ドッグフーディング）することで、外部ユーザーに届く前にデグレ（回帰バグ）を発見することが多い。一般リリースの際は、新バージョンがまず latest（最新リリース）チャンネルに配信され、その後 stable（安定版）チャンネルへと順次展開される。
7. 迅速な検知と迅速な取り消し：ミスのコストを最小化する
どれほど多層の検査を重ねても、問題が本番環境へ流出する可能性はゼロにはならない。したがって、迅速な対応が鍵を握る：
- フィーチャーフラグはオンラインで即座に無効化でき、再ビルドや再リリースの完了を待つ必要がない。チームによると、フラグ、ロールバック、段階的ロールアウトの組み合わせにより、大半のミスは数分以内に取り消すことができるという。
- チームには週替わりのオンコール（待機当番）体制があり、作成者と当番エンジニアは実行テレメトリ、社内からの利用フィードバック、ダッシュボードを組み合わせてデグレを検知し、ロールバックやインシデントの状況を追跡する。インシデントのポストモーテム（振り返り）はシステムの脆弱性に焦点を当て、本来どの検査層が防ぐべきだったのかを検証し、個人への責任追及は行わない。
この流れを再び --retry-timeout の想定に当てはめてみよう。エージェントはまずローカルでタイムアウトテストを実行し、その後に PR を提出してクロスプラットフォーム CI、コードレビュー、セキュリティレビューを受ける。指摘事項への対応を終えて所定の人的承認要件を満たすと、変更はマージキューに入り、最新のメインブランチ上で再検証される。マージ後はまずフラグを通じて社内メンバーが先行利用し、その後にユーザーへと段階的に公開される。仮に実際のネットワーク環境と他機能との組み合わせによってテストで網羅しきれなかった不具合が発生した場合は、モニタリング結果に基づいてフラグをオフにし、修正するかロールバックを行う。前段の検査によってエラーを極力減らし、後段の施策によって見逃しによる影響を最小化するのである。
リスクに応じた人的承認の割り振りと責任の所在
レビュープロセスにおいて承認人数を減らす前提となるのは、より厳格な自動化の制約と明確な責任の帰属であり、誰もチェックしないまま放置することではない。
変更そのものの性質によってリスクレベルを決定する
Claude Code のコードベースでは、必要な承認者の人数は変更の性質によって決まる：
- 低リスク：ドキュメント、文言の修正、社内専用機能、フラグで保護された段階的変更など。信頼済み作成者などの簡素化条件を満たし、自動チェックを通過していれば、人的承認を免除できる。
- 中リスク：一般的なプロダクト機能のほか、キャッシュ、自動アップデータ、システムプロンプトなどの機微な領域に関わる変更。1人の承認が必要となる。エージェントが作成した PR の場合、そのエージェントに指示を出した作成者本人がその承認者を務めることができる。
- 高リスク：最もリスクの高いコード、およびあらかじめ定められた一部の固定パス。2人の承認が必要となる。
リスク分類はコードを分析する分類器によって決定され、さらに第2の分類器によって、その変更に追加の人的レビューを課す必要があるかどうかが再確認される。また、CI ワークフローのファイルや、コードオーナーによって機微（センシティブ）と明示されたパスについては、例外なく最低1人の人的承認が必要となる。
まず変更のリスクを確認し、次に追加条件の有無を確認する
以下は想定シナリオです。事前設定された分類結果はルールの説明を目的としており、実際の動的なリスク判定器ではありません。
ここではCIが通過し、コードレビューおよびセキュリティレビューの指摘がすべて修正されたか、理由を説明した上でクローズされたと仮定します。
低リスク、信頼済み作成者、追加の人的レビュー要件なし、という条件が揃った場合のみこのパスを適用できます。
最新のメインブランチに変更を適用して再検証することで、単独ではパスしても統合時に衝突する問題を検出できます。
不変のルール：エージェントの承認は人間の枠にカウントできない。エージェントに指示を出した人間が変更の最終責任を負う。承認は特定のコミットに紐づくため、システムが担保できない後続の変更が生じた場合は再承認が必要となる。
承認の境界とホワイトリストの仕組み
- 信頼済み作成者リスト：緩和された承認パスが適用されるのは、リポジトリの信頼済み作成者リストに登録されたメンバー（主にそのリポジトリを保守するチームメンバー）に限られる。それ以外の作成者が提出したコードについては、作成者以外の別の人間による承認が必要となる。
- エージェントは人間の承認枠の代わりにはならない：自動レビューによって低リスクの場面で人的承認を免除することは可能だが、特定のレベルで人間の関与が求められている場合、エージェントによる合格判定を人間の枠にカウントすることはできない。
- 新たなコミットには再検証が必要：人間による承認は特定のコミットに対してのみ有効となる。その後、システムが安全を担保できない新たなコミット（エージェントが新たにプッシュしたパッチや、人間が手動で解消したマージコンフリクトなど）が追加された場合、元の承認は無効となり再承認が必要となる。
変更の作成者が最後まで責任を負う
責任の所在について、エージェントに指示を出してコードを書かせたエンジニアは、自身が手作業でコードを書いた場合と全く同様に、マージされた変更に対して責任を負う。軽度または中規模の変更が本番リリース後に不具合を起こした場合、通常はその作成者が修正を担当する。その変更に関して最も完全なコンテキストを把握しているのは作成者だからである。
この責任ルールが機能する背景には、変更自体が十分に小さく保たれているという前提がある。変更が小さければ問題発生時に原因箇所を特定しやすく、修正やロールバックも容易になる。チームはフィーチャーフラグ、段階的リリース、迅速なロールバックを組み合わせることで大半のエラーを即座に取り消せるようにし、さらに実行テレメトリと社内での高頻度利用によって異常をいち早くあぶり出す。影響範囲が広くミスの代償が大きい変更に対しては、より多くの人間と検査を配置する。
したがって、「マージした者が責任を持つ」という規約の背景には、修正の難易度を下げるための緻密なエンジニアリング設計が存在しており、個人がすべての責任を孤立して背負い込むことを意味しているわけではない。チームのポストモーテムはシステムや仕組みの欠陥に目を向け、個人を非難することはない。また、コードの所有権はチーム全体で共有されており、エンジニアはオープンなチャンネルで協調しながら作業を進めるため、誰でも他のメンバーが構築している内容を確認してフィードバックを送ることができる。
このような役割分担のもとで、エンジニアの工数は日常的な差分を1行ずつ通読する作業から、機械が苦手とする5つの重要判断へとシフトした：
- その要求をそもそも実装すべきか：方針の妥当性、ビジネス上の判断、および要件のスコープ。
- 高リスクコードのゲートキーピング：課金、自動アップデータ、CI ワークフローなどの極めて重要な領域。
- アーキテクチャと設計パターン：新たに導入されたパターンが、今後の変更で広く模倣されるに値するかどうか。
- 客観的エビデンスの精読：テスト出力、コマンド実行結果、UI スクリーンショット、レビュアーのレポートを精査し、自動検査が見落とした可能性のある問題を判断する。自動化が何を見落とすか判断がつかない場合は、安易にパスさせるのではなく本格的な人的レビューを実施すべきである。
- デリバリーの成果に対する責任：コードをキーボードで打ち込んだのが誰であれ、最終的に本番リリースされるすべての変更の背後には、具体的な人間が責任を負う。
エージェントがエージェントをレビューする時：なぜやり取りが収束しないのか、いかに制約を設けるか
コードの作成をエージェントに任せ、第1段階のレビューもエージェントに委ねた結果、エンジニアリングチームはレビューと修正のやり取りがいつまでも収束しないという問題に直面した。
ここでは、些細な指摘が極めて大きなコストを生み出してしまう。人間であれば取るに足らない提案を見ても数秒で「修正しない」と判断できるが、コードを書くエージェントは律儀に指示に従って修正し、新たなコミットを生成し、それが次のレビューをトリガーしてしまう。その結果、価値の薄い1件の指摘が「提案→修正→コミット→再レビュー」という丸々1回の作業サイクルへと膨れ上がってしまうのである。
初期の実践例では、エージェントが作成した CLI の変更に対して、夜間に50回以上のレビューと修正が繰り返され、作成者が手動で止めるまで終わりが見えなかったこともあった。コード作成エージェントがレビュー指摘を1項目ずつ修正して新しいコードをコミットし、レビューエージェントが新しいコンテキストのもとでまた新たな提案を投げかけることで、往復回数が雪だるま式に膨らんでいったのである。
往復回数が膨らむ原因：指摘コードの59%は初回のレビュー時点ですでに存在していた
チームが git blame を用いてレビュアーから繰り返し指摘された箇所を追跡したところ、指摘されたコードの約59%は、レビュアーによる第1ラウンドのレビュー時点ですでに存在していたことが判明した。
これは、後続ラウンドでの指摘の多くが、新しいコミットによって持ち込まれた欠陥ではなく、初回レビューの時点で存在していたコードから少しずつ見つけられていたことを示している。第1ラウンドのレビューですでに存在していた問題を一度に報告しきれず、修正のたびに新たなレビューがトリガーされるため、終わりのない往復から抜け出せなくなっていたのだ。加えて、チームが初期に多往復のレビューパターンに慣れ親しんでいたことも影響していた。このアプローチは一部の高リスク領域では有用だが、すべての PR に一律で適用すると不要なオーバーヘッドをもたらしてしまう。
レビューを収束させるための4つの調整
レビューを効果的に収束させるため、チームは実際の欠陥をどれだけ検出できたか（再現率）を追跡するだけでなく、「合格までに要したレビュー往復回数」の監視も開始した。問題を見つけ出すことと、無用な往復を避けることの両立を図ったのである。そのために導入された具体的な変更は以下の4点である：
- 往復回数の上限設定：3回のレビューを経た後、レビュアーは局所的な微調整を繰り返すのではなく、作成者に対して一歩引いて実装方針そのものを再検討するよう促す。
- 初期ラウンド以降は差分のみを再レビュー：最初の数ラウンドを終えた後の再レビューは、最新コミットによって追加された差分のみ（Diff-only）を対象とし、既存コードをいつまでも掘り返し続けるのを防ぐ。
- 同種の欠陥パターンとして提示：レビュアーは欠陥の種類ごとにまとめて問題を指摘し、作成者が1行ずつの対症療法ではなく、同種の問題を一括して処理できるように促す。
- 既存のコメントを重複して出さない：すでに投稿した指摘については、言い回しを変えて重複投稿しないようにする。
ここでもリトライパラメータを想定例としてみよう。複数のリトライパスにおいて総所要時間の制限が正しく行われていない場合、そのうちの1行だけを指摘すると、作成者はその1箇所だけを修正し、次のラウンドで別の箇所を指摘される羽目になる。「同種の欠陥パターンとして提示する」アプローチでは、この共通の構造的課題を明確に伝えることで、作成者が関連するすべてのパスを一度に確認して修正できるように促す。そして最初の数ラウンドのチェックを経た後は、新しいパッチによって生じた差分のみに着目し、その修正が新たな問題を引き起こしていないかの確認に集中する。ラウンドごとに既存コード全体を読み直し、細かな問題を少しずつ指摘し続けることはしない。
だからといって既存の問題が放置されるわけではない。レビューエージェントは夜間に既存コードベースのスキャンを別途実行し、過去の問題を洗い出すための専用ルートを確保している。また、3往復後に実装方針の再検討を求めることは、3往復に達した瞬間に自動で合格・マージされることを意味するわけではない。
平均往復回数の減少とともに、長期化していた一部のリクエストにも着目する
収束に向けた施策の導入後、Anthropic 社内の PR におけるレビュー往復回数の指標には明確な変化が現れた：
レビュー収束に向けた調整の前後比較
Anthropic 社内 PR における前後比較。バーのグループごとに共通のスケールを使用しており、グループ間で指標の単位は異なります。
1回のレビューと修正で合格
より多くのリクエストが1往復で完了するようになった（コードの修正が一切不要だったことを意味するわけではない）。
5往復以上が必要
何度も往復を繰り返すリクエストが大幅に減少（ゼロになったわけではない）。このグループのフルスケールは10%。
合格までに要した平均レビュー往復回数
全体として往復が減少。このグループのフルスケールは2.5往復（往復回数は所要時間と直接イコールではない）。
第1グループのフルスケールは100%。元図にはサンプルサイズおよび具体的な集計期間が示されていません。これらの数値はレビューの往復回数を示すものであり、脆弱性の検出率ではありません。
原文図 D：レビュー往復回数のデータを表示
1回のレビューと修正で合格した割合は 65% から 78% へと増加した。これは、より多くのリクエストが1回の往復で完了できるようになったことを示しており、修正が一切不要だったという意味ではない。
これらの指標は社内の PR データに基づくものであり、サンプルサイズや具体的な集計期間は明記されていない。平均往復回数が 2.08 回から 1.32 回へと減少したと同時に、より顕著な変化として現れたのは、5回以上の往復を要していたロングテールの割合が 8.9% から 1.5% へと大幅に抑え込まれた点である。不毛な往復を繰り返していたリクエストが明確に減少したことを示しているが、これによって実際にどれだけの時間が節約されたかについては、別途計測が必要である。
レビュアー自身もテストを受ける：実際のインシデントを用いたキャリブレーション
過去に障害を引き起こしたりロールバックに至ったりした PR を収集し、業務に精通したエンジニアが欠陥の内容と発生箇所を特定する。過去の PR を「問題」とし、対応する修正やロールバックの記録を「模範解答」とすることで、現実に即したリスクを反映した評価データセット（Eval）が完成する。評価の際は、レビュアーにそれらの欠陥を含む変更を改めて検査させ、報告された問題とエンジニアが確認済みの欠陥とを突き合わせて、真の問題が正しく検出できているかを検証する。
この事例集は一度作成して固定されるものではなく、新たなインシデントが発生するたびに継続して拡充される。見逃しが判明した際、チームは「その時点でモデルにはどんな情報が不足していたのか？」を掘り下げる。その結果得られた改善策は、CLAUDE.md や特定のスキル、あるいは新たな検査項目へと反映される。
チームは毎日レビュアーの評価テストを実行している。プロンプト、ツール、モデルに変更を加えるたびに、事例集全体を用いたフルテストを実施し、評価結果の改善が確認された場合にのみ変更を採用する。このようにして継続的なプロセスが構築されている。すなわち、実際のインシデントをエンジニアが確認して事例集に追加し、見逃しに対して情報補足や検査の見直しを行い、すべての事例でバックテストを実施して新バージョンを採用すべきかを判断する。直近で起きた問題を捉えられるようにすると同時に、以前は検出できていた問題を再び見逃していないかも検証する。
ただし、手当たり次第に問題を指摘すれば検出率（再現率）自体は見かけ上向上するため、誤検知（フォールスポジティブ）のチェックも欠かせない。チームは各指摘がその後「修正されたか」「誤りと判断されたか」「意図的な実装と認められたか」「重要ではないとみなされたか」を追跡している。さらに、問題のないクリーンな PR をレビュアーに検査させ、かえって有害となるような修正提案を出していないかも統計的に検証している。
チームは明確に「真の欠陥を捉えること」を第1優先とし、「レビュー往復回数を減らすこと」を第2優先と位置づけている。そうでなければ、すべてのコードをノーチェックで素通しするレビュアーであっても、往復回数の数字だけは極めて優秀に見えてしまうからである。
コードを読む量が減る中、チームはいかにシステム全体を把握するのか
コードレビューが担ってきたもう1つの伝統的な機能は、チーム内へのコード理解の共有である。コードを読む作業の大半を機械に任せるようになった場合、チームはいかにしてシステムに対する共通認識を維持するのだろうか。
Claude Code チームによると、チームはこの点について現在、形式的なプロセスを特に設けていないという。チーム内にコードベース全体の完全なメンタルモデルを頭の中に保持している人間は誰もおらず、またそうする必要もないと考えている。
エンジニアが見慣れないモジュールを理解したり変更を加えたりする必要があるときは、通常、Claude に対して該当モジュールの現在のコードスライスに基づいた解説の生成を直接指示するか、モデルに視覚的な図解を生成させて理解を助けている。
こうしたオンデマンドの解説は、必要なすべてのコード読解を代替できるわけではないが、日常的な細かな変更に向き合う際、無関係な差分を通読することによるエネルギー消費を抑えてくれる。同時に、チームは原則としてオープンな Slack チャンネルで業務を行っており、エンジニアは他のメンバーが何を作っているかをリアルタイムで把握できるため、オープンチャンネルでの議論や協調作業を通じてシステムの変化をキャッチアップし続けている。
一般的な開発チームがこのワークフローを導入するには
エンジニアリングチームがこのレビュー体制を参考にする場合、まずは一般公開されているツールと社内固有の仕組みとの違いを明確に区別しておく必要がある。
Team および Enterprise ユーザー向けのホスト型 Code Review 機能、ローカルで実行される /code-review CLI コマンド、そしてオープンソースの GitHub Action は、異なる利用シナリオに向けられた個別のツール形態であり、単一で不可分な固定パッケージではない。このうち、ホスト型 Code Review が担当するのはコードの分析と指摘コメントの投稿のみである。マージの承認やブロックを行うことはなく、ビルドテストの実行や修正コードのプッシュを代行することも一切ない。
Anthropic 社内において一部の低リスクな変更を人間の承認なしでマージできているのは、チーム自身が構築した CI チェック、セキュリティフィルタ、マージキュー、そして迅速なロールバック体制という土台があってこそである。
一般的なチームにとって、より堅実な導入アプローチは、いきなり「承認者ゼロ」を真似るのではなく、基礎的な制約から段階的に移行していくことである：
- まずエージェントにセルフチェックさせる：簡潔な
CLAUDE.mdに検証コマンドを記載し、hooks を使ってフォーマットやリントを自動実行する。コミット前に/code-reviewや/security-reviewを実行させるか、新しいコンテキストを持つサブエージェントに再レビューを行わせる。モジュール責任者が記述したREVIEW.mdを整備し、そのモジュールにおいて真に報告すべき問題を明確にしておく。 - まずは1つのリポジトリで試験導入する：CI テストの通過をマージの必須要件とする。PR テンプレートに「テスト方法（Testing）」「リスク（Risk）」「ロールバック手順（How to revert）」の項目を追加し、作成者に確認させる。AI レビューを導入した後は、現場からの実際のフィードバックに基づいて
REVIEW.mdを数週間チューニングしてから、他のリポジトリへと展開していく。 - レビューの指摘をマージ制約に連携させる：コードレビューとセキュリティレビューが問題を見つけ、リポジトリのルールが「チェックを通過し、すべての指摘スレッドが処理されるまでマージ不可」という制約を執行する。日常的な変更には高速チェックを用い、見逃しの代償が大きい変更には深層チェックを適用する。ホスト型 Code Review では、リポジトリごとに Quick、Standard、Deep から選択可能である。問題を報告することと、実際にマージをブロックすることは、別々に設定すべき2つの事項である。
- 人的承認のルールを明文化し、無駄な往復を抑制する：変更リスクに応じて段階分けを行い、簡素化されたパスは信頼済み作成者にのみ適用する。
CODEOWNERSを用いて機微なパスの責任者を指定し、ブランチ保護機能を通じて所定の人的承認を義務付ける。認証、課金、CI、リリースパイプライン、インストーラなどのパスには必ず人間が目を光らせる。ボットは必要な人間の承認枠を代替できず、新たなコミットが追加された場合は再承認を必須とする。同時に再レビューの往復回数を制限し、最初の数ラウンド以降は新規差分のみを対象とする。 - リリースとリカバリのルートをセットで用意する：マージキュー、フィーチャーフラグ、社内先行利用、段階的リリースを導入し、ワンステップでロールバックできる手段を整える。問題のあった PR や修正・ロールバックの記録を収集して評価データセットに追加し続け、レビュアーのプロンプト、ツール、モデルが変更されるたびに、真の欠陥と誤検知の両面から再検証を行う。
- データに基づいて承認の緩和を段階的に判断する：変更のリスク階層を明確に定義し、重要パスや CI ワークフローは人間の確認を厳格に維持する。実運用の中で人間の承認にかかる所要時間を継続的に追跡しつつ、ロールバック率とインシデント発生率を安全基準として監視し続ける。自動チェック、フィーチャーフラグ、取り消し手段が成熟し、ロールバック率が低水準を維持できるようになった段階で、チームの状況に応じて一部の低リスクな変更に対する承認ハードルを徐々に緩和していく。初期段階からこの選択肢を完全に排除する必要はない。
未導入の自動サーキットブレーカーとデリバリーの品質管理
Anthropic 社内においても、指標が悪化した際の自動サーキットブレーカー（自動遮断機構）はまだ構築されていない。インシデント発生率やロールバック率が上昇した際に承認要件を自動で厳格化する仕組みはなく、依然としてオンコール当番のエンジニアがダッシュボード上で目視監視を行っている状況である。チームのエンジニアたちも、承認者ゼロの適用範囲を本格的に広げる前に、まずはこの自動サーキットブレーカーを確立させたいと考えている。
また、エージェントはコードを書くハードルを劇的に引き下げたが、それは書かれたすべてのコードがメインブランチにマージされるべきであることを意味しない。ある機能要求について「そもそも実装すべきかどうか」は、コードを書き上げて PR を提出した後に差し止めるのではなく、早い段階でオープンなディスカッションチャンネルで合意形成しておく方が適切である。コードを生成するコストが極めて低くなった今、方向性にズレが生じた場合には速やかに PR をクローズする方が合理的であり、単に「せっかくコードが書けたから」という理由だけで無理にマージする必要はない。