Claude CodeはレビューをPR前に移し、人間を高リスク判断へ絞った

Claude Codeチームは、人が変更を見る前にagentが定型的な不具合の多くを検出するworkflowを公開した。6月から9月にかけてマージ済みpull requestは2倍超に増え、revertされた変更の割合は40％超低下したという。

レビューはpull requestを作る前から始まる

Claudeはpull requestを開く前にtest、build、linterを実行する。次に別のagentが新しいcontextでdiffを確認する。その後も必須CI、複数agentによる不具合探索、独立したsecurity review、merge queueが続く。

チームによれば、ClaudeはClaude Code自身のコードの約90％を書いている。Anthropicのmonorepoでは、1日当たりの変更が5月の約2,500件から9月には30,000件超へ増えた。全行を人が読む方式は、この量では実効的な統制にならない。

人間の注意は変更が生む損害に応じて配られる

分類器は変更を3段階に分ける。文書や文言は自動検査が通れば追加の人手なしで進められ、通常の製品変更には1人、最高リスクのコードには2人が必要だ。billingやCIなどの重要領域は常に人間の承認を求める。

その結果、senior engineerの役割も変わる。定型的な不具合探しより、architecture、scope、riskを判断する仕事が中心になる。coding agentsを導入するチームにとって、これはモデル選定より重要だ。reviewは希少な人間の注意を振り分ける仕組みになる。

Anthropicの社内指標だけでは万能な手順書にならない

数字を示したのは、ツールとprocessの両方を作る当事者だ。独立した実験ではない。また、高いtest coverage、feature flags、段階的release、迅速なrollbackが前提にある。これらがなければ、人の目を減らすことは不具合をproductionへ早く送るだけになる。

自動reviewが自分で仕事を増やす問題もある。あるpull requestは50回超の修正を繰り返した。回数制限と新しいdiffだけの再reviewを導入すると、5回以上を要する割合は8.9％から1.5％へ下がった。

Revert、incident、人待ち時間が成否を決める

見るべき指標はagentのコメント数ではない。revertとincidentの推移、pull requestが人を待つ時間だ。Anthropicは人間による承認の中央値と95パーセンタイルを追跡し、過去のincidentを毎日実行するevalへ組み込んでいる。

導入するチームは1つのrepositoryから始め、リスク区分を定義し、重要領域を人間の管理下に残すべきだ。安定したproductionデータが出て初めて、注意を節約したのか、on-call engineerへ請求書を回しただけなのかが分かる。

Lilithの判定

agentがコードの90％を書くなら、人間は全行の横に立てない。分岐器の前に座り、どの変更が崖へ向かうかを見抜く仕事になる。