AIがコードの90%を書く中、Anthropic Claude Code Reviewが日常的な人間の読解に取って代わる

Anthropicによれば、Claudeがプロダクトのコードの約90%を書くようになったことで、Claude Code reviewは未知の領域に入った。2026年6月から9月にかけて、マージされたプルリクエストは2倍以上に増加した。それでも、リバートが必要となった割合は40%以上低下したとされる。

この組み合わせこそが本質的な話だ。Anthropicは、機械生成コードの急増に対して、人間にさらに多くの行を精査させるのではなく、日常的な読解の大半を別のClaudeエージェントに移し、よりリスクの高い変更に人間の承認を充てた。

これは単に従来のレビューを高速化したものではない。レビューの意味、実行者、説明責任がどこから始まるかを変えるものだ。Anthropicは現在、人間の注意力を、個々の行ではなくリスクに沿って配分すべき希少な資源として扱っている。

このアプローチには重要な制約もある。見出しとなる結果は、公開された生データや独立監査を伴わないAnthropic自身の測定値だ。そのプロセスは、広範な自動化、社内インフラ、段階的なリリース、自社モデルへの非常に手厚いアクセスに依存している。

ここでの競争は、Claude対人間のプログラマーではない。自動化された網羅性と、全件を人間が検査することとの競争だ。Anthropicは、多層的なチェック、重点的な承認、低コストでの可逆性によって、機械の速度で行う行単位の読解よりも多くのリスクを管理できると賭けている。

Anthropic Claude Code Reviewで何が変わったのか

Anthropicはコードレビューを単一の人間による関門から、自動チェック、エージェントレビュアー、重点的な承認、迅速なロールバックで構成される継続的なシステムへ移行した。

同社は10月15日、Claude Code reviewに関するエンジニアリング記事でこのシステムを説明した。著者のAddy Osmani、Morgan Westlee Lunt、Qing Wangは、出力量を中心に問題を位置付けた。エージェントが人間の読解速度を上回って変更を生成する場合、従来のキューはデリバリーのボトルネックになる。

Anthropicによると、すべてのプルリクエストは人間が確認する前にClaudeによるレビューを受ける。レビュアーは、提案された変更をリポジトリ全体の文脈およびプルリクエストで表明された意図と照らし合わせて読む。バグ修正では、目に見えるパッチだけを確認するのではなく、根本原因の特定を試みる。

次に複数のエージェントが並列で潜在的な欠陥を探す。別のグループが各指摘に投票し、十分なレビュアーが合意した場合にのみ、システムが問題を投稿する。Anthropicは、スタイル、診断、任意のクリーンアップに限定されたコメントを除去するフィルターをテストしたとしている。

残った指摘には重大度ラベルが付けられる。開発者またはエージェントは、各指摘を修正するか、理由を添えてそのスレッドを閉じなければならない。問題が未解決のままなら、別の自動セキュリティレビューがマージを防ぐこともできる。

これらのレビューは従来の安全策と並行して行われる。プルリクエストは引き続き、サポート対象プラットフォーム全体でリンティング、型チェック、ビルド、テストを受ける。マージキューは現在のmainブランチに対してチェックを再実行し、それぞれは有効でも相互作用すると不具合を起こす変更による失敗を減らす。

レビューはプルリクエストが存在する前から始まる。Claudeはテスト、ビルド、またはビジュアルチェックを実行し、得られた証拠を表示する。その後、新しいコンテキストを持つサブエージェントが差分を検査するため、作成エージェントが当初の前提をそのまま繰り返す可能性を下げられる。

Anthropicの以前のコーディングプラクティスでは、作成と検証のコンテキストを分けることが推奨されていた。新しいワークフローは、この推奨をチーム全体のオペレーティングシステムへと変えている。

人間の承認は、変更の分類されたリスクに依存する。低リスクの作業は、自動チェックとセキュリティチェックを通過すればマージできる。例としては、ドキュメント、コピーの変更、社内機能、機能フラグの背後に隠された追加機能がある。

通常のプロダクト作業には、一般に1人の承認が必要だ。キャッシュ、システムプロンプト、更新機構などの機微な領域にも人間の注意が向けられる。最高リスクの変更には2人が必要であり、特定の保護対象パスでは常に手動レビューが発動する。

分類器は、人間かエージェントかではなく、変更そのものを評価する。元のティアが寛容すぎると思われる場合、2つ目の分類器が人間の関与を要求することもできる。エージェントの承認が、人間のために確保された枠を埋めることはない。

この区別は重要だ。Anthropicは人間の説明責任をなくしたわけでも、AIレビューによってソフトウェアが無欠陥になると主張したわけでもない。日常的な欠陥検出を、アーキテクチャ、プロダクトの方向性、機微なシステム、許容可能なリスクに関する判断から切り分けたのである。

Claudeに指示を出した人は、結果に対する責任を負い続ける。各承認は特定のコミットに適用されるため、その後の変更によって無効になる場合がある。Anthropicのモデルでは、委任はコードを入力し読む人を変えるが、結果の所有者を変えるものではない。

数字が示す、人間だけのレビューの持続不可能性

Anthropicが報告した指標は、コード生産がすでに全件を人間が読むことを前提としたレビュー手法を上回っていることを示唆している。

同社によると、Claude Codeリポジトリでマージされたプルリクエストは、2026年6月から9月にかけて2倍以上に増えた。同期間に、リバートが必要となった割合は40%以上低下した。

これらの数値が示すのは方向性であり、完全なパフォーマンスではない。Anthropicは、プルリクエストの絶対数、当初のリバート率、最終的なリバート率、統計的な変動を明らかにしていない。相対的に40%低下したとしても、出発点は高いベースラインにも低いベースラインにもなり得る。

90%という数字にも慎重な表現が必要だ。Anthropicは、ClaudeがClaude Codeのコードの約90%を書いていると述べている。これは、モデルが独自にプロダクトの優先順位を選び、あらゆる要件を定義し、デプロイの責任を負うことを意味しない。

エンジニアは依然としてタスクを指示し、証拠を評価し、設計上のトレードオフを解決し、作業が存在すべきかを決める。機械による著作はコード生成を測るが、ソフトウェアエンジニアリングには行を生み出すこと以上の要素が含まれる。

こうした留保があっても、Anthropicは現実的なスケーリング問題に直面している。同社の別のモノレポは、5月の1日あたり約2,500件のマージ済み変更から、9月には3万件超へ増えたと報じられている。同社はそのワークロードを処理するため、Scionという社内ソース管理システムを構築した。

Claude Codeは別のリポジトリを使っているため、3万件という数字はプロダクトチームを直接測るものではない。それでも、Anthropicが説明したソース管理の再設計は、開発インフラを取り巻くより広範な圧力を示している。

ScionとClaude Codeの事例は、同じボトルネックを指し示す。コーディングエージェントが変更を継続的に作成、テスト、改訂できるようになると、コードを書くことはスループットを制御しなくなる。レビューキュー、ビルド、権限、統合システム、リリース制御が制約要因になる。

従来のコードレビューは、管理可能な数の変更が人間から届くことを前提としている。別の人が各差分を読み、修正を求め、最終版を承認する。このモデルは、出力がレビュアーの能力を上回って増加すると崩れ始める。

レビュアーを増やしても、この不一致は完全には解決しない。経験豊富なエンジニアは希少であり、継続的なレビューは設計作業、デバッグ、プロダクト判断を中断させる。組織はレビュー要員を増やしても、増大する変更ストリーム全体で共有される注意力を失い続ける可能性がある。

そのためAnthropicは、生成されたコメント数以上のものを測定している。プルリクエストあたりの人間の承認数、人間によるコメント、待機時間、リバート、インシデントを追跡している。掲げる目標は、人間のレビュー時間を減らしつつ、その時間を本番環境での復旧作業へ移さないことだ。

同社はまた、商用AIレビュアーによって、実質的なコメントを受ける社内プルリクエストの割合が16%から54%へ上昇したと報告している。1,000行を超える変更の大半では指摘が見つかる一方、小規模な変更の大半は問題なしとして返されるという。

この結果だけで精度が証明されるわけではない。コメントが増えれば、検出の改善、ノイズの増加、あるいはその両方を意味し得る。Anthropicは、開発者が指摘を修正するか、却下するか、報告された挙動が意図的なものだと判断するかを観察し、コメント品質を評価していると述べている。

より大きなシグナルは組織的なものだ。Anthropicはもはや、変更されたすべての行を人間が読むことをレビューの決定的な証拠とは見なしていない。統合されたシステムが問題を捉え、注意力を適切に向け、本番環境への損害を抑えられるかを測っている。

この変化は、コーディングエージェントを導入するすべてのエンジニアリング組織に圧力をかける。エージェントの出力が増加する一方でレビュー方針が固定されたままなら、キューは膨らみ、期待された生産性向上は消える。チームは生成を制限するか、検証方法を再設計する必要がある。

自動化された網羅性が、全件を人間が検査する手法に挑む

中心となる競争は、広範な機械による網羅性と、意味のあるすべての変更は人間が直接読むべきだという考え方との間にある。

全件を人間が検査する手法には、直感的な約束がある。適格なエンジニアがコードを理解し、変更を確認し、リリース前に責任を引き受けることだ。この実践は、知識を広めるとともに、自動テストが見逃す前提を捉えることができる。

しかし、レビューが急ぎの作業になると、この約束は弱まる。大きなキューに直面した人は、考えるのではなく流し読みをしたり、見慣れたコードを承認したり、挙動ではなくスタイルに注目したりする可能性がある。人間の署名は理解を保証しない。

Anthropicの代替案は、複数の専門的なレイヤーを使う。1つのエージェントが変更を作成し、別のエージェントが新しいコンテキストでレビューし、複数のエージェントがバグを探し、さらに別のエージェントが各指摘を評価する。セキュリティレビュー、継続的インテグレーション、マージチェック、段階的リリース、ロールバックが、異なる障害モードをカバーする。

これは多層防御に似ている。後段のレイヤーが前段の見落としを捉えられるため、個々のレイヤーに完璧な再現率は必要ない。リスク分類は、影響の大きい変更に希少な人間の判断を向ける。

この仕組みにより、Anthropicはより広いレビュー範囲も得られる。機械は同僚の予定を待つことなく、すべてのプルリクエストを検査できる。リポジトリの文脈を確認し、文書化された規約を適用し、何千もの変更に同じチェックを繰り返せる。

CLAUDE.mdに保存された指示は、プロジェクト、その規約、境界を説明する。別のREVIEW.mdは、特定のリポジトリで失敗とは何かをレビュアーに伝える。コードオーナーは機微なパスを特定し、無関係なものを除外できる。

レビュアーが同じミスを繰り返し指摘する場合、チームはその教訓を上流工程へ移せる。lintルールを追加し、指示ファイルを改善し、スキルを修正し、新たな自動チェックを作成できる。レビューのフィードバックは、再利用可能なインフラになる。

過去の失敗は評価ケースになる。Anthropicによると、同社はインシデント、リバート、その後の修正に関連するプルリクエストを収集した。エンジニアが根本的なバグを検証し、レビュアーは現在、そのセットに対して毎日実行されている。

これは、2人の間の会議としてのレビューからの大きな転換だ。このシステムは、個人の記憶に依存するのではなく、実行可能なチェックとして教訓を保存しようとしている。各インシデントは、組織の将来の検出範囲を拡大できる。

それでも、人間のレビューは局所的な正しさへ還元できない問いを扱う。エンジニアは、機能が存在すべきか、抽象化が有害な前例を生まないか、証拠がデプロイを支持するかを判断する。

これらは、請求、更新メカニズム、継続的インテグレーション、リリースワークフローなどの機微な領域も検査する。コードが局所的には正しく見えても、こうした変更は広範な影響を及ぼしうる。

したがって、このプロセスはあらゆる面で機械のほうが優れたレビュー担当者だとは主張しない。機械には反復して実行できる読解作業を任せ、人には目的、アーキテクチャ、不確実性、責任に関わる判断を委ねる。

この分担は、エンジニアリングに求められるスキルも変える。エンジニアは意図を明確にし、制約を特定し、検証を設計し、証拠を解釈し、エージェントが誤った目的を最適化したときに見抜く必要がある。コードを読むことは依然として有用だが、理解に至る唯一の道ではなくなった。

AnthropicのScionチームは、関連する例を示している。エンジニアによれば、Claudeは局所的なパターンには合致する一方で、非効率的、あるいは過度に防御的な設計を選ぶことがあった。人間はシステム全体のトレードオフを理解しているため、そうした方向性を退ける必要があった。

「human in the loop」という表現は、この役割を曖昧にしうる。単に機械の出力を承認するだけの人は、弱い安全策にすぎない。境界を定義し、証拠を選び、自動化を止めるべき時を知っている人が、意味のある統制をもたらす。

他の組織にとっての教訓は、レビュー担当者を排除することではない。機械的な検査と判断を区別することだ。人が重大な結果を伴う意思決定と不明確な証拠への権限を維持する場合、自動化による網羅性は価値を持つ。

Claude Codeのレビューが終わりのないエージェントループを回避する方法

Anthropicは、レビュー工程が明示的に収束するよう設計されていなければ、AIの作成者とAIレビュー担当者が無制限の作業を生み出しかねないことを発見した。

レビューを増やせば自動的に良くなるわけではない。Anthropicは、あるClaude Codeのプルリクエストが一晩で50回を超えるレビューと修正の往復を経験したと説明している。最終的に、そのループを止めたのは作成者だった。

レビュー担当者は、各回で新たな重大欠陥を発見していたわけではない。Anthropicはバージョン履歴を用いて繰り返された指摘を調査し、その約59%が最初のレビュー時点ですでに存在していたコードに関するものだと確認した。

エージェントは新たな修正だけを評価するのではなく、古い問題を追加で見つけ続けていた。コメントのたびに修正、コミット、レビューが発生した。システムは稼働し続けたものの、許容可能な最終状態へ効率よく近づいてはいなかった。

この失敗は、AIコードレビュー特有のリスクを示している。人間なら低価値の提案を数秒で退けられる。作成エージェントはそれに従う傾向があり、レビューエージェントにさらに多くの材料を与える差分を生み出す。

Anthropicは収束制御を導入して対応した。3ラウンド後、レビュー担当者は作成者にアプローチを再考するよう求める。その後のパスでは、変更全体を繰り返し検索するのではなく、新しい差分に焦点を当てる。

レビュー担当者は、関連する欠陥のクラス全体も一度に報告する。これにより作成者は、連続するラウンドで類似のコメントを受け取る代わりに、すべての該当箇所を修正できる。すでに投稿済みの指摘は、再び表示されるべきではない。

Anthropicによれば、これらの変更により内部レビューサイクルは改善した。レビューと修正を1ラウンド行った後に通過したプルリクエストの割合は、65%から78%へ上昇したという。

5ラウンド以上を要したプルリクエストの割合は、8.9%から1.5%へ低下したとされる。通過前の平均レビュー回数は2.08回から1.32回に減少した。これらの指標は依然として企業側の報告だが、多くのエージェントワークフローが見落としている運用上の問題を扱っている。

モデルに給与がないからといって、自動化された労働が無料になるわけではない。追加ラウンドのたびにモデルの処理能力を消費し、変更を遅らせ、コードを増やし、後続のチェックが検査すべき対象を増加させる。

同じ問題は、レビュー担当者が仮説上の脅威に過剰反応するときにも現れる。Anthropicによれば、敵対的なレビューは近視眼的になり、過剰な検証や複雑性を促しかねない。起こりうる失敗の発見に最適化されたシステムは、新たな保守コストを生み出すことがある。

リスクに応じた深度は、そのための一つの制御手段となる。Anthropicの一般提供中のCode Review serviceは、通常のリポジトリと重要なリポジトリに異なるレビュー水準を提供している。同社によると、現在は大半のレビューが6〜10分で完了する。

ただし、レビュー担当者が速くなっても、根底にあるガバナンス上の問いは解決しない。チームは依然として、どの指摘が重要か、どの経路により深い検査が必要か、何サイクルまで許容するかを決める必要がある。

レビュー指示も、隠れたポリシー層になりうる。CLAUDE.md、REVIEW.md、あるいは分類プロンプトに弱い前提が含まれていれば、エージェントはその前提をリポジトリ全体に一貫して適用してしまう。

一貫性が役立つのは、そのルールが正しい場合に限られる。チームには、レビュー担当者を導く指示に対する所有権、バージョン管理、評価ケース、レビューが必要だ。そうでなければ、自動化は誤ったポリシーを人間が気づくより速く拡大しかねない。

ここで、共有されたエンジニアリングコンテキストが重要になる。エージェントを導入する組織には、アーキテクチャ判断、インシデントから得た教訓、却下されたアプローチについての永続的な記録が必要だ。検索可能なengineering knowledge baseは、そのコンテキストを一つのレビュースレッドの先まで保つ助けになる。

Anthropicのプロセスが機能するのは、レビュー担当者を測定が必要なシステムとして扱っているからだ。同社は精度、ノイズ、ラウンド数、インシデント、開発者の応答を追跡している。こうしたフィードバックループなしにAIレビュー担当者を導入しても、目に見えるツールを模倣するだけで、運用モデルを見落とすことになる。

Anthropicの結果がまだ証明していないこと

最も強い主張は依然として自己申告に基づいており、Anthropicはその結果が異なるインフラ、予算、失敗許容度を持つチームへ移転できることを示していない。

最初の不確実性は測定に関するものだ。Anthropicは、マージされたプルリクエストが2倍以上になり、リバートの割合が40%以上低下したと報告した。だが、基礎データセット、絶対的な比率、インシデント重大度の分布は公開していない。

リバート率の低下は、有望である一方で重要な結果を隠している可能性もある。チームはリバートせず前方修正を行うことも、機能フラグを無効化することも、そのラベルが付かない回帰を許容することもある。リバートは有用だが、不完全だ。

インシデント率は別のガードレールになるが、公開投稿には詳細なインシデント時系列がない。重大度と露出に関するデータなしには、外部者はこのプロセスがリスクを低減したのか、あるいは失敗への対処方法を変えただけなのかを判断できない。

90%という作成比率にも同様の曖昧さがある。生成された行、受け入れられた行、コミット、あるいは別の単位のどれを数えているのかが示されていない。また、最終コードに至る前にどの程度の人間によるプロンプト、編集、反復があったかも明らかにしていない。

Anthropicの環境は、この手法にとって例外的に有利だ。同社はモデルを管理し、並列レビュー担当者に相当な計算資源を費やすことができ、エージェント生成ワークロードを中心とした内部インフラを開発している。

同社の従業員は、公開リリース前にClaude Codeを自ら利用している。新機能は内部デプロイメント、最新チャネル、そして安定チャネルへと進められる。機能フラグにより、完全なデプロイメントを行わずに動作を無効化できる。

医療、金融、産業、あるいは安全性が重要なシステムを運用するチームは、異なる要件に直面する可能性がある。迅速なロールバックですべての結果を元に戻せるわけではない。欠陥のあるデータ移行、認可変更、外部アクションは、取り返しのつかない害を引き起こす可能性がある。

Anthropicは、不適切なマージの検知が依然として作成者、オンコールエンジニア、テレメトリー、ダッシュボードに依存していることを認めている。リバートやインシデントが増加した際に承認要件を引き上げる自動サーキットブレーカーは、まだ備えていない。

このギャップが重要なのは、リスク分類が古くなりうるからだ。低リスクと分類された変更が、隠れた依存関係と相互作用することがある。個別には安全な一連の変更も、危険な複合状態を生み出しうる。

セキュリティも別の懸念をもたらす。Anthropicは自動化されたセキュリティレビューを利用しているが、同社自身のリスク資料は、人間による監督が依然として必要な理由を示している。同社のsabotage assessmentは、モデル監視を完全な保証ではなく、発展途上の統制として説明している。

コミュニティの反応は、コストと理解に関するより広い疑問を提起している。一部の開発者は、Anthropicには他の場所では採算が合わないレビューのパターンを維持できると主張する。また、差分を読む人が減ることで、コードベースについての集合的な知識が弱まることを懸念する声もある。

Anthropicは、Claude Codeチームの誰も製品全体の完全なメンタルモデルを維持していないと率直に述べている。エンジニアは必要に応じて、関連するサブシステムをClaudeに説明させる。

このアプローチは説明を最新に保てるかもしれないが、依存関係も生む。生成された説明が相互作用を見落とせば、エンジニアは不完全な地図に基づいて意思決定を行う可能性がある。同じモデルファミリーは、レビューするコードに埋め込まれた前提を繰り返すこともありうる。

クロスモデルレビューは追加の多様性をもたらしうるが、自動的に精度を高めるわけではない。異なるシステムが訓練上のパターンを共有していることも、無関係な理由で失敗することもある。重要なのは、単に異なるモデル名ではなく、独立した証拠だ。

これらの疑問はいずれも、Anthropicが報告した結果を無効にするものではない。ただし、それらの結果が何を立証するかには限界を設ける。同社が示したのは、期待を持たせる方向性の指標を伴う詳細な内部プロセスであり、人間のコードレビューを普遍的に代替するものではない。

このモデルが成り立つかを検証する3つのシグナル

次の試金石は、人間の関与なしにマージされる変更が拡大し、レビュー製品が他社に届き、競合が異なる統制を採用する中で、Anthropicが品質を維持できるかどうかだ。

最初のシグナルは、Anthropic自身の承認ポリシーである。現在のプロセスでは、自動チェックに通過した後、選定された低リスクの変更は、別途人間のレビュー担当者を置かずにマージできる。

この境界がより多くの製品コードへ拡大するかを注視すべきだ。Anthropicがエンジニアが望むサーキットブレーカーを追加すれば、自動的なエスカレーションによって、より広い展開の信頼性が高まる可能性がある。インシデントの増加や、より厳格な承認への回帰は、その主張を弱めるだろう。

第2のシグナルは、自動レビューを利用する外部組織からの証拠だ。AnthropicはTeamおよびEnterpriseの顧客向けにCode Reviewを提供開始しており、未知のリポジトリや異なるエンジニアリング文化にまたがる、より広い検証を生み出している。

有用な指標は、コメント数やレビュー済みプルリクエスト数ではない。チームは、受け入れられた指摘、すり抜けた欠陥、偽陽性、レビューの遅延、人間の工数、プロダクションインシデントを報告すべきだ。

Anthropic外でも比較可能な結果が得られれば、階層化されたAIレビューがスケールできるという主張は強まる。ノイズの多さ、モデル利用量の増加、あるいはインシデント率の不変は、Anthropicの成功が内部環境に依存していることを示唆するだろう。

第3のシグナルは競争上の反応だ。OpenAI、GitHub、Google、Cursor、その他のコーディングエージェント提供者は、生成コードとレビュー担当者の能力の間にある同じ不均衡に直面している。

その選択は、リスクベースのレビューが共有されたパターンになるかを明らかにするだろう。競合システムは、クロスモデルレビュー、より強力なサンドボックス、形式検証、リポジトリ固有の評価、あるいはより継続的な人間の承認を選好する可能性がある。

開発者は、この議論をAIがバグを見つけられるかどうかに還元することを避けるべきだ。実際的な問いは、完全なレビューシステムが注意を配分し、説明責任を維持し、すべての層が何かを見落とした場合に安全に回復できるかどうかである。

エンジニアリングリーダーにとって、当面の行動は測定だ。承認ポリシーを変える前に、レビュー時間、すり抜けた欠陥、偽陽性、リバート率、インシデントの重大度について基準値を確立する。基準値がなければ、より速いマージは改善に見えながら、コストを別の場所へ移しているだけかもしれない。

チームは、可逆的な変更と不可逆的な変更も分けて扱うべきだ。ドキュメント、フラグ付きのインターフェース調整、社内ツールに、認証、課金、マイグレーション、リリース基盤と同じプロセスは必要ない。

Anthropic Claude Codeのレビューは、多くのチームが近く直面する問題への具体的な答えを示している。これは、誰かがすべての行を読んだことの証明ではなく、レビューを階層化された制御システムとして扱うものだ。

同社が報告した数値は、この答えを盲目的に模倣するのではなく、検証する価値があることを示している。明日、あなたのエージェントがコード出力を2倍にした場合、レビュアーが今日すべてを読むのを安全にやめられると判断するには、どのような証拠が必要になるだろうか。