［開発者向け］Claude Codeチームのコードレビュー——AIが大半を読み、人は「判断」に集中する7層の仕組み

2026-10-18

はじめに

　Anthropicは2026年10月15日、Claude Codeチームのコードレビューの進め方を公開しました。コードの約9割をClaudeが書く環境で、人のレビュー時間を抑えつつ差し戻しを減らした仕組みです。本稿では、7層のチェック、レビュアーの改善、人が担う判断、導入手順を解説します。

参考記事

タイトル: How the Claude Code team does code review
著者: Addy Osmani、Morgan Westlee Lunt、Qing Wang
発行元: claude.dev Blog（Anthropic）
発行日: 2026年10月15日
URL: https://claude.dev/blog/solving-code-review-at-anthropic/

要点

6月から9月にかけて、Claude Codeのマージ済みPRは2倍超に増え、差し戻し（revert）の割合は40%以上減った。
レビューは最後の関門ではなく、執筆中から継続的に走る複数層のチェックとして再設計された。
人による承認の数は、分類器が判定したリスクの段階に応じて0人・1人・2人と変わる。
過去のインシデントを評価セットにし、レビュー回数に上限を設けることで、AIレビュアーの精度と収束性を高めている。
人は「作るべきか」「危険なコード」「設計」「証拠の読解」「結果への責任」の5つの判断に集中する。

詳細解説

コードレビューの目的を問い直す

　Anthropicによれば、Claude Code自身のコードの約90%はClaudeが書いています。6月から9月にかけて、Claude Codeのコードベースにマージされたプルリクエスト（PR）は2倍以上に増え、その一方で差し戻しが必要になった割合は40%以上減ったといいます。レビューをなくしたのではなく、読む作業の大半を機械に移し、人の時間と注意を最適化し、誤りをすばやく元に戻せる仕組みに投資した結果だと説明されています。

　背景には、エージェントがコードを書くと変更の数が急増するという事情があります。Anthropicのモノレポ（複数のプロジェクトを1つにまとめたリポジトリ）では、1日に取り込まれる変更が5月の約2,500件から9月には3万件超に増えました。Claude Codeは別リポジトリですが、同様の圧力を受けており、人が1行ずつ読むレビューは事実上不可能になっていたとしています。

　記事では、コードレビューには次の2つの役割があると整理しています。

出荷前に問題を見つけて直す
チーム全体でコードベースへの共通理解を育てる

　そのうえで、「人間がコードを読んだか」は、「この変更で何が起こりうるか、それを捕まえるのに適したチェックは自動か人か」を測る指標としては不正確だと述べています。この問いの立て方によって、レビューのタイミングも変わりました。以前はコードを書いてPRを出し、同僚を待つという「最後の関門」でしたが、現在は文章を書きながら動くスペルチェックのように継続的に行われます。多くの変更は、人が見る前に少なくとも一度Claudeによってレビュー・修正されています。

　「人が読んだかどうか」から「どのチェックが適切か」へ問いを移す発想は、レビューを品質保証の手段として捉え直すものと読めます。本稿としては、AIによるコード生成が増えるほど、この考え方の重要性は増していくと考えています。

限られた資源は「人の時間と注意」

　チームが守りたいのは、人にしか解けない問題のための時間と注意です。ここでいう人の時間には、レビューに使う時間と、問題のあるコードが壊したものを直す時間の両方が含まれます。前者を減らしても後者が増えれば意味がないためです。

　そこで目標は、Claude Codeのリポジトリ（CLI、デスクトップ・Webアプリ、モバイルアプリ）のほとんどのPRを、差し戻しやインシデントを増やさずに、関与する人間が最大1人（作成者本人でもよい）の状態でマージすることとされています。測定する指標は次のとおりです。

PRあたりの人による承認数（中央値と95パーセンタイル）
人によるコメント数
PRが人の対応を待つ時間
差し戻し率とインシデント率（ガードレール）

　差し戻しやインシデントが増えたなら、人の時間を節約したのではなく別の場所に移しただけだという考え方です。「レビュー時間の短縮」だけを目標にすると品質が犠牲になりやすいため、必ず安全側の指標と組で測るという設計は、AI導入の効果測定一般にも応用しやすいと思います。

変更がたどる7つの層

　エンジニアのPC（またはSlack上のClaudeセッション）から始まる典型的な変更は、複数の層のレビューを通ります。記事では、各層がそれぞれ一部の問題を捕まえ、すべてをすり抜けるものは少なく、残りは素早いロールバックで対処すると説明しています。

段階	層	内容
PR作成前	1. 作業の検証	Claudeがテスト・ビルド・リンターを実行し、別のエージェントが新しい文脈で差分をレビュー
すべてのPR	2. AIによるレビュー	複数のエージェントが並行してバグを探し、検証役が投票、残った指摘を重大度順に並べる
すべてのPR	3. セキュリティレビュー	独立したチェック。未解決の指摘があるとマージ不可
すべてのPR	4. 必須CI	リント、型、各プラットフォームでのテスト、ビルド。失敗でマージ不可
すべてのPR	5. リスクに応じた承認	分類器が段階（0人・1人・2人）を決定
マージ時・後	6. マージキュー・フラグ・段階的リリース	最新のmainで再検証し、社内利用を経て段階的に公開
マージ後	7. 迅速な検知とロールバック	作成者とオンコール担当が監視し、フラグの停止や差し戻しで対処

　ここからは、各層の内容を順に見ていきます。

第1層：誰かが見る前に作業を検証する

　現在、レビューの大半はPRが作られる前に行われています。Claudeには、テスト、ビルド、デザインと比較するためのスクリーンショットなど、実行できるものを与え、「完了しました」と言うのではなく出力を示すよう求めます。そのうえで、サブエージェントが新しい文脈で差分をレビューします。どちらもClaude Codeのベストプラクティスに沿った習慣です。

　PR作成前には、バグを探すスキル、差分を簡潔にするスキル、エンドツーエンドで挙動を確かめるスキルなど、社内のスキルを実行する人も多いといいます。UIの変更はデザインガイドラインとも照合されます。Claude Codeの開発者Boris Cherny氏は、Claudeに作業を検証する手段を与えることが良い結果を得るうえで「おそらく最も重要なこと」だと述べ、最終結果が2〜3倍良くなると見積もっています。

　自動レビュアーが同じ指摘を繰り返す場合は、スキルやリントルール、または次の指示ファイルを更新して、問題を根本から直します。

CLAUDE.md: プロジェクトの技術スタック、規約、目標と非目標をClaudeに伝えるファイルです。レビューのたびに読み込まれるため、大きなコードベースでは短く保ち、他の文書を参照させます。レビュアーは、この規約に反するコードや、CLAUDE.mdの記述を古くしてしまう変更も指摘します。
REVIEW.md: コードの担当者（コードオーナー）が書き、そのエリアで何が重要かをレビュアーに伝えるファイルです。良いREVIEW.mdは短く、そのリポジトリでの「失敗」の姿を示し（ドキュメントなら「嘘をつく」、設定なら「誤った経路に流す」）、細かい指摘（nit）の数に上限を設け、除外するパスを列挙し、名前からの推測ではなくファイルと行番号を根拠として求めます。また、件数から始まり、直すものがないときははっきりそう言う要約を求めます。

　検証の仕組みを先に整える考え方は、Claude Codeの検証ループをスキル化する方法とも共通しています。REVIEW.mdの書き方の指針は具体的で、自チームのレビュー基準を明文化する際の雛形として使いやすいと思います。

第2層・第3層：すべてのPRへのAIレビューとセキュリティレビュー

　すべてのPRは、人が見る前にClaudeのレビューを受けます。リポジトリ全体とPRの意図に照らして差分を読み、変更が問題を解決しているか、システムに合っているか、他を壊していないかを確認します。バグ修正では根本原因も探します。公開版の「Code Review for Claude Code」はTeamプランとEnterpriseプランで一般提供されており、/code-review コマンドでローカルでも軽量版を実行できます。

　Anthropicによれば、研究プレビューの開始時に、実質的なレビューコメントが付く社内PRの割合は16%から54%に増えました。1,000行を超えるPRの多くには指摘が付き、小さなPRの多くは問題なしで戻ってくるといいます。管理者はリポジトリごとにレビューの深さを選べます。

Quick: 軽いチェック
Standard: 標準的なチェック
Deep: 深いチェック。見逃したバグ1件のコストが、追加のレビュー時間より大きい場所で価値があるとされています。

　指摘は、人が見る前に他のエージェントによって検証されます。複数のエージェントが同時にバグを探し、別のグループが各指摘に投票して、十分な数が「本物」と同意したものだけが投稿されます。スタイルや診断、整理だけに関する指摘は除かれ、このフィルターは自社のPRでA/Bテストしたうえで採用されました。残った指摘は重大度順のインラインコメントとなり、Important（重要）、Nit（細部）、Pre-existing（既存の問題）のいずれかのタグが付きます。最後のタグにより、そのPRが持ち込んでいないバグが作成者の責任に見えないよう配慮されています。

　すべての指摘には対応が必要で、修正するか、理由を添えてスレッドを解決します。夜間にエージェントが修正を引き受け、作成者が戻ると次のレビューが済んでいることも多いといいます。

　セキュリティにも独立した自動レビューがあります。バグレビューかセキュリティレビューの指摘が1件でも未解決なら、PRはマージできません。誤検知は短い理由を添えてスレッドを閉じることで解消し、後のコミットで問題が直れば指摘は自動で消えます。同様の仕組みは、オープンソースのセキュリティレビュー用GitHub Actionか /security-review コマンドで構築できます。

　投票で誤検知を絞り込む方式は、AIレビューの最大の課題とされる「ノイズ」への実践的な対策と考えられます。他社でも、Codexのレビューに独自ルールを追加する仕組みなど、レビュー基準をファイルで明文化する動きが続いており、方向性は共通していると読めます。

第4層・第5層：必須の自動チェックとリスクに応じた承認

　第4層は、リント、型チェック、全プラットフォームでのテスト、ビルドといった一般的なCIです。典型的なCLIのPRでは、人が見る前に数十のチェックが走ることもあります。PRテンプレートでは、どうテストしたか、どう元に戻すかを記入させ、Claudeが下書きしても、変更を依頼した人が最終的に承認します。

　第5層では、ドキュメントの修正と自動アップデーターの変更ではリスクが違うため、レビューの重さを変えています。

リスク	例	必要な人の承認
低	ドキュメント、文言、社内向け機能、フラグの背後にある追加的な変更	自動レビューとセキュリティチェックが通れば不要
中	通常の製品変更、キャッシュ・自動アップデーター・システムプロンプトなどの重要領域	1人
高	最もリスクの高いコードと、常に2人を要する一部のパス	2人

　この運用には、次のルールが設けられています。

段階を決めるのは作成者ではなく変更そのもの: 分類器が変更を読んでリスク段階を選び、2つ目の分類器が「段階上は不要でも、この変更には別の人が必要か」を判断します。コードオーナーが重要と指定したパスやCIワークフローのファイルは、常に人の確認が必要です。
軽い経路を使えるのは信頼された作成者だけ: リポジトリの信頼リストに載った作成者（主にそのリポジトリを担当するチーム）だけが軽い経路を使え、それ以外は別の人の承認が必要です。エージェントの承認は人の承認として数えません。
変更を指示した人が責任を負う: エージェントが書いたPRでは、エージェントに指示した人が必要なレビュアーの1人として数えられ、自分でコードを書いた場合と同じ扱いになります。
承認は特定のコミットに対するもの: エージェントによるプッシュや手動で解決したマージなど、システムが保証できない新しいコミットが入った場合は、承認をやり直します。

　本稿としては、「エージェントの承認は人の承認に数えない」「指示した人が責任を負う」という2点が、自動化を進めても責任の所在をあいまいにしないための要になっていると受け止めています。

第6層・第7層：マージキュー、段階的リリース、迅速なロールバック

　マージキューは、変更を適用した最新のmainブランチですべてのチェックを再実行します。これにより、個別には通る2つのPRが組み合わさってmainを壊す事態を防ぎます。新しい挙動は通常、フラグの背後でまずAnthropic社員に提供され、社内での多用によって利用者より先に不具合が見つかることが多いといいます。一般公開はまずlatestチャンネルに出し、stableチャンネルはそれに遅れて追従します。

　それでもすり抜ける誤りはあるため、最後の層は早く見つけることに重点を置いています。フラグはデプロイなしで無効化でき、Claude Codeには週替わりのオンコール当番があり、インシデントの振り返りでは「どの層で捕まえるべきだったか」を問います。

　一方で、問題のあるマージに気付くのは、今も作成者とオンコール担当、差し戻し・インシデントのダッシュボードに頼っています。これらの数値が動いたときに承認を自動で厳しくする「サーキットブレーカー」はまだなく、人が関与しないマージを増やす前に導入したいという声がエンジニアから出ていると率直に記されています。ある同僚は「慎重に進めれば誤りは減るが、それは主にすべてを少ししかやらなくなるからだ」と述べたそうで、チームは遅くするより、問題に気付いて直す速さを上げる方を選んでいます。

レビュアー自体を改善するループ

　レビューの仕組みは、継続的な改善のループで良くなっています。まず、インシデントそのものが評価セット（eval）になっています。チームは、インシデントを起こした過去のPRを、その後の修正や差し戻しとあわせて集め、そのコードに詳しいエンジニアがバグとその場所を確認しました。レビュアーはこのセットに対して毎日実行され、プロンプト・ツール・モデルを変えるたびにスコアを測り、上がれば採用、下がれば取り下げます。

　ノイズは、コメントへの人の反応で測ります。誤検知をいとわなければバグはいくらでも多く拾えるため、その歯止めが必要だからです。

指摘を受けて修正した
指摘が誤りだと答えた
意図した挙動だと答えた
重要ではないと判断した

　加えて、問題がないと分かっているPRでもレビュアーを走らせ、有害な変更を招きかねない指摘をどれだけ出すかを数えています。優先順位は「本物のバグを捕まえることが第一、レビュー回数を減らすことが第二」と明文化されています。

　ノイズは、作成者がエージェントの場合にコストが大きくなります。人なら細かい指摘を数秒で受け流せますが、エージェントはそれを修正し、新しいコミットと次のレビューが発生します。エージェント同士が際限なく作業し合うこともあり、あるCLIのPRは、作成者が止めるまでに一晩で50回以上のレビューと修正を繰り返したといいます。

　レビュアーが繰り返し指摘していた箇所をgit blame（各行の変更履歴をたどるコマンド）で調べると、約59%はレビュアーの最初のチェック時点から存在していたコードでした。つまり新しいバグはほとんどなく、毎回少しずつ古いバグを見つけていただけでした。チームは、複数回のレビューを既定にしていた自分たちの習慣も原因だったと認め、再現率（バグの捕捉率）とあわせて「合格までの回数」を追跡し、再レビューを次のように変えました。

回数の上限を設ける。3回を超えたら、レビュアーが作成者にアプローチの見直しを求める
最初の数回以降は、新しい差分だけを再レビューする
バグの「種類」を指摘し、1行ではなくすべての該当箇所を直してもらう
投稿済みの指摘を繰り返さない

　また、レビュー用のエージェントを毎晩既存のコードにも走らせ、古いバグが別の場所で表面化する前に見つけています。収束性の改善前後の結果は次のとおりです。

指標（社内PR）	改善前	改善後
1回のレビューと修正で合格	65%	78%
5回以上のレビューが必要	8.9%	1.5%
合格までの平均レビュー回数	2.08	1.32

　「AI同士のやりとりが収束しない」という問題は、エージェントを本格的に使い始めたチームが直面しやすい課題だと思います。回数の上限や差分のみの再レビューは、自チームでもすぐに取り入れられる具体的な対策と考えられます。

人が判断を担う5つの領域

　深い作業に集中しているシニアエンジニアを、よくある誤りを見つけるために呼び出すのは、自動レビューよりはるかに高くつきます。Anthropicでは、人の仕事はすべての差分を読むことから、機械が苦手な次の判断へと移りました。

そもそも作るべきか: 方向性、センス、範囲の判断です。レビューのボトルネックを解消したあるチームも、チーム外からの変更には人のレビューを残し、「本当にこれをやるべきか」を問う人を置いています。
リスクの高いコード: 課金、自動アップデーター、CIワークフローなどです。
他の人が真似するパターンになる設計
証拠を読むこと: テスト出力、実行したコマンドとその結果、スクリーンショット、レビュアーの指摘です。チェックが何を見逃しうるか説明できない場合は、簡単な承認ではなく本格的なレビューを求めるべきだとしています。
結果に責任を持つこと: 誰が入力したかにかかわらず、出荷されるすべての変更に人が責任を持ちます。

　AIの出力を全部読むのではなく、AIが提示した証拠を読んで判断するという役割の変化は、コードレビューに限らず、AIと協働するあらゆる業務に通じる考え方だと受け止めています。

チームで文脈を共有する方法

　コードレビューのもう1つの役割は、コードベースの理解を広げることでした。チームメイトの差分を読むことで、何が変わり、部品がどう組み合わさるかを学べたためです。機械が大半を読むようになると、人はどうやってコードを学ぶのかという問いが生まれます。

　記事によれば、チームにはこのための正式なプロセスはありません。Claude Code全体を頭に入れている人はおらず、その必要もないと考えています。コードベースのある部分を理解したいときは、その範囲に絞った解説をClaudeに書いてもらいます。数分で済み、現時点のコードを反映した内容になります。さらに、その部分を可視化し、本人が好む学び方で教えてくれる小さなアーティファクトをClaudeに作らせる人もいるといいます。

　1行の文言変更を読んでもほとんど学ぶことはありませんが、これから変更するモジュールの解説からは多くを学べるため、人の注意を有効に使うという点ではこちらの方が優れているとしています。また、オープンなSlackチャンネルで作業する文化も、他の人が作っているものを作業中から見られる点で役立っているそうです。

「マージした人が責任を持つ」文化

　小・中規模の変更をマージして問題が起きた場合、通常はその人が直すことがチームの規範になっています。これがうまく機能するよう、次の条件が整えられています。

変更は小さく保つ: レビュー、デバッグ、差し戻しが容易になります。
すべてを元に戻せる: フラグ、差し戻し、段階的リリースで、多くの誤りは数分で取り消せます。
影響範囲が基準を決める: 影響の大きいコードには、より多くの人とチェックを充てます。
不具合はすぐに表面化する: テレメトリー（利用状況データ）と社内利用で早く見つかります。
責任追及ではない: 修正を担うのは最も文脈を知っているからであり、インシデントの振り返りでは個人ではなく仕組みを見ます。

　責任は共有されてもいます。チームの多くはオープンなチャンネルで作業しており、誰でも他の人の作業を見て、スレッドを引き取ったり、Claudeに抜けを埋めさせたりでき、コードの担当者以外からもフィードバックが届きます。こうした開かれた環境が、すべての行に関門を置かずに品質を保つ大きな要因だとしています。

方向転換するとき

　エージェントによって物事を始めるコストが下がったため、マージすべきでない作業も生まれます。通常はチャンネルの誰かが理由を尋ねたり、過去の決定を指摘したり、より簡単な方法を提案したりして、作成者がPRを閉じるか作り直します。

　コードを書くのが速かった分、PRを閉じても損失とは感じにくいといいます。大切なのは、完成したPRへの差し止めコメントではなく、スレッドの早い段階で別の方向性を示すことだとしています。書く手間が小さくなった環境では、作ったものを捨てる判断を早めにする方が全体の無駄が少ないという考え方と読めます。

自チームへの導入手順

　記事では、必要な部品の大半はすでにそろっているとして、段階ごとの導入方法を示しています。

PR作成前

エージェントが実行できるチェックを短いCLAUDE.mdに列挙し、フォーマッターやリンターを動かすフックを用意する
ローカルで /code-review と /security-review を実行するか、新しい文脈のサブエージェントにレビューさせる
REVIEW.mdを追加し、繰り返し出るレビューコメントをそこに移す

すべてのPR

CIを必須にし、PRテンプレートに「テスト方法」「リスク」「元に戻す方法」の項目を追加する
AIレビュアー（Code Review for Claude CodeまたはClaude Code GitHub Action）をまず1つのリポジトリに導入し、数週間REVIEW.mdを調整してから広げる
自動のセキュリティレビューを追加し、マージ前にすべてのレビュースレッドの解決を必須にする
レビューの深さをリスクに合わせる（通常の変更はQuick、見逃しが高くつく場所はDeep）
レビュー回数に上限を設け、数回以降は新しい差分だけを再レビューする

承認

リスク段階を文書化し、作成者ではなく変更の内容で決める。最初は厳しく設定し、根拠をもって緩める
軽い承認経路は信頼できる作成者に限る
CODEOWNERSとブランチ保護を使い、認証、課金、CI・リリースのワークフロー、インストーラーには常に人の確認を必須にする
ボットの承認で必須の人の承認を代替させず、新しいコミットが入ったら承認を取り消す

マージ後

マージキュー、フィーチャーフラグ、社内での先行利用、段階的リリース、1操作でのロールバックを用意する
インシデントと差し戻しを評価セットにし、レビュアーのプロンプト・ツール・モデルを変えるたびに再評価する
人の時間を測り、差し戻し率とインシデント率をガードレールにする

　すべてを一度に導入する必要はなく、「1つのリポジトリで試し、数週間調整してから広げる」「最初は厳しく、根拠をもって緩める」という進め方が明記されている点は、小規模なチームでも参考にしやすいと思います。特に、PRテンプレートへの項目追加やREVIEW.mdの作成は、AIレビューを導入していない段階でも始められる工夫と考えられます。

今後の方向性

　Code Reviewの製品発表では、PRの承認は依然として人が決めるものであり、製品は指摘を出すだけで承認はしないとされていました。一方、Claude Codeチーム自身のリポジトリではさらに進み、どの低リスクの変更を自動チェックだけでマージするかをオーナーが決められるようにしており、その線は今も動き続けているといいます。

　レビューで見逃しがあれば、モデルの手元に何がなかったのかを問い、CLAUDE.md、スキル、新しいチェックに修正を反映します。目標は変わらず、「変更あたりの人の時間を減らし、差し戻しは以前より増やさない」ことだとしています。記事は、エージェントにPRを作らせているチームに向けて、どのチェックを自動化し、どれに人が必要で、自分たちの考えのどこが間違っていると思うかを聞かせてほしいと呼びかけて締めくくられています。