Anthropicが明かす、エージェントのPRを人がどこまで見るかの線引き

書き手もレビュー役もエージェントだと、レビューは放っておくと終わらない。AnthropicのClaude Codeチームでは、ある変更が一晩で50回を超えるレビューと直しを繰り返した。チームは公式ブログで、こうした失敗も含めて、人がどの変更を見て、どれを機械に任せるかの線引きを詳しく明かした。あわせて、プルリクエストをAIが読む「Code Review for Claude Code」を一般提供にした。6月から9月にかけて、マージしたプルリクエストは2倍を超え、差し戻し（revert）になった割合は4割以上減ったという。数字はすべてAnthropic自身の計測で、第三者の検証はない。

誰がどの形で使えるのか

一般提供になったのは、プルリクエストごとにClaudeがレビューを書く機能だ。対象はTeamとEnterpriseのプランで、管理者はリポジトリごとにQuick、Standard、Deepの3段階から深さを選ぶ。Deepは時間がかかるが、見逃した1つのバグが高くつくところで使う、という位置づけだ。

手元では、軽い版の /code-reviewと、セキュリティを見る /security-reviewが使える。オープンソースのセキュリティレビュー用GitHub Actionもある。

指摘を出す前に絞り込む仕組み

Code Reviewは、差分をリポジトリ全体とプルリクエストの目的に照らして読む。変更が問題を解決しているか、仕組みに合っているか、ほかを壊していないかを見る。

特徴は、指摘を出す前に絞り込むことだ。複数のエージェントが同時にバグを探し、別のエージェントの集まりが指摘ごとに本物かどうかを投票する。十分な数が本物と認めたものだけが残る。見た目や後片付けだけの指摘は落とす。残った指摘は、重要、細かい点（Nit）、もともとあった問題（Pre-existing）のどれかに分けて、行ごとのコメントとして並ぶ。もともとあった問題を分けるのは、その人が持ち込んでいないバグを、その人のせいに見せないためだ。

研究プレビューを始めた時、Anthropic社内で中身のあるレビューコメントが付いたプルリクエストの割合は、16%から54%に上がった。1000行を超える大きな変更にはたいてい指摘が付き、小さな変更はたいてい何も出ない。

人が見る変更を危うさで分ける

Claude Codeのコードは、約9割をClaudeが書いている。Anthropicのモノレポでは、1日に入る変更が5月の約2500件から9月には3万件を超えた。この量を、人が1行ずつ読むのはもう無理だ、というのがClaude Codeチームのコードレビューのブログの出発点だ。

そこで人の手間を、変更の危うさで分けた。ドキュメントや文言の直し、フラグの裏に隠した追加などの低い危うさの変更は、自動のレビューとセキュリティの確認が通れば人の承認は要らない。普通の機能の変更や、キャッシュ、自動更新、システムプロンプトのような気を使う所は1人。最も危うい所は2人だ。どの段にするかは書いた人ではなく変更の中身で決め、分類器が判定する。

ただし、軽い道を通れるのは、そのリポジトリの信頼できる書き手だけだ。エージェントの承認は人の承認の代わりにならない。エージェントに書かせた変更では、指示した人がレビューする人の1人に数えられる。書いたのが誰であれ、出した変更には人が責任を持つ、という考え方だ。

一晩で50回のレビューという失敗

ブログは失敗も隠していない。書き手もレビュー役もエージェントだと、お互いにいつまでも仕事を作り合う。ある変更は、一晩で50回を超えるレビューと直しを繰り返し、書いた人が止めるまで続いた。調べると、指摘の約59%は、最初のレビューの時からあったコードへのものだった。新しいバグを見つけていたのではなく、古いバグを毎回少しずつ掘り出していたわけだ。

そこで、レビューは3回までにして、それを超えたらやり方を考え直すよう書き手に促す。数回目からは新しい差分だけを見る。同じ種類のバグはまとめて指摘し、一度出した指摘は繰り返さない、と変えた。

ブログの最後には、自分のチームで取り入れる手順がまとまっている。TeamやEnterpriseでなくても、まねできる所は多い。

• エージェントが自分で走らせられる確認（テストやビルド）を、短いCLAUDE.mdに書いておく
• レビューで繰り返し言うことをREVIEW.mdにまとめる
• プルリクエストのひな形に「どう試したか」「危うさ」「戻し方」の欄を足す
• レビューの往復に上限を決め、数回目からは新しい差分だけを見る
• 認証、課金、CIの設定、インストーラーは、必ず人が見るようにしておく

編集部の見方

Claude CodeやCodexにプルリクエストを出させている人にとって、一番効くのは手順の最後の2つかもしれない。エージェント同士のレビューは、放っておくと終わらない。往復の上限と、必ず人が見る場所を先に決めておけば、人の時間は危うい変更に集められる。数字はAnthropic自身の計測だが、線引きの考え方は小さなチームでもそのまま使える。