Anthropic AIコードレビュー、Claude Codeの90%をAIが記述
Anthropic AIコードレビューは、Claudeがほとんどを書くコードベースの関門になっています。同社によると、Claude Codeの約90%はClaudeが書いたものだと、InfoQが2026年10月29日に報じました。モノレポで1日にマージされる変更は、5月のおよそ2,500件から9月には3万件を超えたため、Anthropicはソース管理を作り直し、変更をリスクの階層に振り分けました。エンジニアリングのリーダーにとっては、AIによるコーディングでボトルネックが、コードを書くことから、レビューして出荷することへ移る様子を示す事例です。
コードレビューがAnthropicのボトルネックになった理由
Claudeがコードの大半を書くようになり、コードレビューが破綻しました。Anthropicによると、Claude Code自体の約90%はClaudeが書いており、同社のモノレポにマージされる変更は、2026年5月の1日およそ2,500件から、9月には1日3万件を超えました。
最初に壊れたのはソース管理でした。モノレポのメインブランチの履歴はほぼ100GB、圧縮した作業コピーは25GBを超え、CIは1日に2500万回ほどのチェックアウトを行います。単純に取得すれば、gitのトラフィックは1日600PBを超えるとAnthropicは述べています。ピーク時には、対処するため数百の社内gitミラーを運用していました。InfoQによると、レビューは「次に壊れるもの」でした。
Anthropicが追いつくために作ったもの
Anthropicは社内製のバージョン管理システムScionを作り、5か月でモノレポをgitから移しました。同じ期間に、Antiqueと呼ぶコードレビューの画面、コード検索、ソース管理のアクセスシステムも作りました。Scionはコミット、マージ、履歴、blameをサーバー側で実行するため、CIのジョブやエージェントは、コードをチェックアウトせずにAPI経由で質問できます。
レビューについては、Claude CodeチームがAddy Osmani、Morgan Westlee Lunt、Qing Wangによる投稿で目標を掲げました。ほとんどのプルリクエストは、「人は多くても1人で、その人が作成者でもよく、取り消しや障害を増やさずに」マージされるべきだというものです。
AIコードレビューが誰の承認を必須にするかを決める仕組み
分類器が各変更にリスクの階層を割り当て、「階層を決めるのは変更であり、作成者ではありません」。ドキュメント、文言、フラグの裏にある追加的な変更といった低リスクの変更は、人の承認なしでマージされます。キャッシュ、自動更新、システムプロンプトなどの中リスクの変更には、1人が必要です。
2つの規則が一線を守ります。エージェントの承認は人の承認として数えられず、変更を指示した人は必要なレビュー担当者の1人に数えられます。チームはまた、エージェントがレビュアーのコメントをすべて直そうとすると、ループしうることも見つけました。あるCLIのプルリクエストは、作成者が止めるまでに、夜通し50回を超えるレビューと修正を繰り返したため、チームは回数に上限を設けました。レビュアーが指摘し続けたものにgit blameをかけると、約59%は、レビュアーの最初のレビューのときからあったコードでした。
「チームの誰も、Claude Codeの完全な心的モデルを頭に持っていませんし、誰かに必要だとも考えていません。」 AnthropicのClaude Codeチーム、エンジニアがコードベースをどう理解するかについて
Anthropicが新しい仕組みで得たと述べる成果
ソース管理について、計測された成果はAnthropic自身のものです。同社は、各階層でキャッシュのヒット率が99%を超え、CPUとメモリの使用量は従来のgitミラーの200分の1になり、CIや研究ジョブのチェックアウトが2桁速くなったと報告しています。InfoQは、これらが社内のワークロードについての同社の報告であり、gitとの一般的なベンチマークではないと注記しています。
レビューの目標には、公表された成果はまだありません。チームは、取り消しや障害の数字が動いたときに承認を厳しくするサーキットブレーカーという制御が足りないと述べています。人の関与ゼロでマージするコードをさらに増やす前に、エンジニアはそれを求めています。
AIが書いたコードがエンジニアリングチームに意味すること
コーディングエージェントを導入するあらゆる企業にとっての教訓は、コードを書くことがボトルネックではなくなり、レビュー、CI、ソース管理がそうなるということです。AIのコーディングツールを使う他社も、遠からず同じ圧力を受けるとAnthropicは見ています。
実務者はこの主張を検証しました。Hacker Newsのコメント投稿者の1人は、人の心的モデルがなければ、難しいバグが現れたときに頼れる人がいないと警告しました。別の投稿者は、自社のSOC 2の審査担当者が、すべての変更を2人目の人が見ることを求めていると報告しましたが、投稿はこれに触れていません。ある開発者は、Claude Codeのリポジトリに、再現手順があるのに非アクティブとして閉じられたissueが6,000件を超えると数えました。ある投稿者は、AIレビューの費用は月に数千ドルで、人のレビューはエンジニアの時間の3分の1に達しうると述べました。
仕組みの一部は公開されています。Claude Code向けのCode Reviewは、TeamプランとEnterpriseプランで一般提供されており、セキュリティレビューはオープンソースのGitHub Actionとして動き、READMEはプロンプトインジェクションへの耐性を強化していないと記しています。
よくある質問
Claudeは本当にClaude Codeの90%を書いていますか。
Anthropicは、Claude Code自体の約90%をClaudeが書いていると述べています。この数字は同社自身のもので、レビュー工程の説明とともに公表されました。
AnthropicではAIが自分のプルリクエストを承認できますか。
ドキュメントや文言などの低リスクの変更だけが、人なしでマージされます。エージェントの承認は人の承認として数えられず、中リスクの変更には1人の人のレビュー担当者が必要です。
他の企業もAnthropicのようにgitを置き換えるべきですか。
Anthropicは、そうではないと述べています。Scionは汎用のgitの代替ではないと注意し、サーバー側のAPIやより良い取得プロトコルといった選んだ考え方を、既存のgitプラットフォームに取り入れることを勧めています。
MOZGIIの視点
私たちならこう作ります
エージェントがほとんどを書くコードベースのレビューを整えるなら、リスク分類器から始めます。各変更にどれだけの人の注意を向けるかを、それが決めるからです。低、中、高リスクに当たるものの明確な一覧が要り、エージェント向けの指示ファイルを、ドキュメントではなくコードとして扱う必要があります。エージェントが読むものを変えれば、エージェントの動作も変わりうるからです。
人の規則は単純で厳格に保ちます。エージェントの承認は決して人の承認として数えず、すべての高リスクの領域には、変更を読まなければならない担当者を定めます。Anthropicがしたようにレビューの回数にも上限を設け、エージェントが一晩中、古い指摘でループしないようにします。
弱点はサーキットブレーカーの欠如です。早い段階で作ります。ある領域で取り消しや障害が通常の水準を超えたら、人が見るまでその領域を自動でリスクの階層を1つ上げます。それがなければ、悪い週は障害の記録にしか現れません。
注視する指標は1つ、人の承認なしでマージされた変更の取り消し率を、人が承認した変更と比べることです。2つの数字が離れていくなら、分類器は寛容すぎます。次に、各変更をどの規則がマージさせたかを記録する監査の記録を加えます。多くの企業が、それをコンプライアンスの審査担当者に示す必要があるからです。
出典
この記事の事実の出典です。
- 01Anthropic Says Nobody Needs a Mental Model of Claude Code. Practitioners Are Testing That - InfoQinfoq.com
- 02Anthropic Says Nobody Needs a Mental Model of Claude Code. Practitioners Are Testing That - InfoQinfoq.com
- 03Redesigning source control at Anthropic \ Anthropicanthropic.com
- 04How Anthropic Redesigned Source Control for AI-Driven Development - InfoQinfoq.com