For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the public content index is available at https://we0.ai/llms.txt, and the English article bundle is available at https://we0.ai/llms-full.txt.
For AI agents: the complete content index is available at https://we0.ai/llms.txt, the full English article bundle is available at https://we0.ai/llms-full.txt, and this page is available as Markdown at https://we0.ai/ja/articles/claude-code-review-ai-checks-human-approv-629ae884.md.
Anthropicによると、ClaudeはClaude Code自身のコードのおよそ90%を書いています。Anthropicのエンジニアリングチームは、エージェントが人間の読解速度を上回る速さで変更を生成できる場合、チームは変更をどのようにレビューすべきかという次の問題を提起して...
Anthropicによると、ClaudeはClaude Code自身のコードのおよそ90%を書いています。Anthropicのエンジニアリングチームは、エージェントが人間の読解速度を上回る速さで変更を生成できる場合、チームは変更をどのようにレビューすべきかという次の問題を提起しています。
その答えは、定型的なチェックをより早い段階に移し、エージェントをバグ調査に活用し、より高いリスクを伴う判断に人間の注意を振り向ける、階層化されたプロセスです。Anthropicによると、6月から9月にかけてマージされたプルリクエストは2倍以上に増加した一方、リバートが必要になった割合は40%以上低下しました。
これらの観察結果は、ある1つのチームのプロセスを示すものです。90%という数字はコードの作成者に関するものであり、人間を介さずに変更が通過した割合を示すものではありません。人間による承認が必要な場合、その承認をエージェントが代わりに行うことはできません。
このチームは、行単位で人間が読むことを、レビューそのものの目的ではなく、問題を発見する方法の1つとして扱っています。より良い問いは、変更によってどのような失敗モードが生じ、それをどのチェックで検出できるかです。
この考え方により、レビューはプルリクエストの後に設けられた単一の関門ではなく、継続的な活動になります。テスト、ビルド、そして新しいコンテキストを使ったエージェントレビューによって、別のエンジニアを中断させる前に問題を発見できます。
コストの計算には、レビューにかかる時間とインシデントの修復にかかる時間の両方が含まれます。承認数を減らしても、失敗が単に下流へ移動するだけなら、最適化が成功したとはいえません。そのため、リバート率とインシデント率は、人間によるコメント数、承認数、待ち時間の指標と並ぶ安全弁として機能します。
Anthropicの別のモノレポは、5月の1日あたり約2,500件のマージ済み変更から、9月には30,000件超へと増加しました。Claude Codeには独自のリポジトリがあり、これらのモノレポの数値をClaude Codeのコードベースに直接帰属させることはできません。
提示されたレポートでは、7層のプロセスから3つの段階が取り上げられています。公式の説明では、全体の流れは次のとおりです。
提示されたレポートに掲載されたワークフロー図の翻訳版。公式記事には英語の原文が掲載されています。
プルリクエストの前段階では、エージェントがタスクの完了を宣言することよりも、証拠が重要です。テストコマンドとその出力、またはデザインと照合したスクリーンショットがあれば、レビュー担当者は確認可能な情報を得られます。繰り返し発生する問題は、CLAUDE.mdやREVIEW.mdに、リンティングルール、スキル、簡潔なプロジェクト指示として反映できます。
AIレビュアーは、制限のないスタイルに関する助言ではなく、本質的な欠陥に焦点を当てます。Anthropicによると、研究プレビュー期間中に、実質的なコメントを受けた社内プルリクエストの割合は16%から54%へ上昇しました。コメントでは、既存の問題を別個に特定することもできます。これにより、すべての指摘が新しい変更によって導入されたという誤解を避けられます。
| リスクレベル | チームが説明している社内承認ポリシー |
|---|---|
| 低 | 適用される自動チェックに合格すれば、人間による承認は不要。ただし、信頼度とパスに関するルールが適用されます。 |
| 中 | 人間による承認が1件必要。 |
| 高 | 人間による承認が2件必要。 |
機密性の高いパスとCIワークフローファイルには、追加の要件があります。軽い承認経路の対象となるのは信頼された作成者だけであり、それ以外のコントリビューターには別の人による承認が必要です。分類器は、提出者の身元を単純に信頼するのではなく、変更内容を評価します。
エージェントが作成した作業では、エージェントに指示を出した人が責任あるレビュー担当者とみなされます。エージェントによる承認が、必須とされる人間の承認枠を満たすことはありません。また、その後のコミットによってレビュー対象が変わった場合、承認を取り直す必要が生じることがあります。
チーム内の人間ゼロの経路は、公開されているレビュー製品とも異なります。製品は指摘を投稿しますが、リポジトリのルールで必要とされる人間による承認を独自に提供するものではありません。
あるCLIのプルリクエストは、一晩の間に50回を超えるレビューと修正のラウンドを繰り返した後、所有者によって停止されました。エージェントである作成者が小さなコメントを修正し、新しいコミットを生成すると、レビュアーが起動して別の問題を発見していました。
チームが事後に調査したところ、繰り返し指摘されたコードのおよそ59%は、最初のレビュー時点ですでに存在していました。後続のパスでは、各修正によって新しく導入された欠陥ではなく、以前から存在していた問題がさらに発見されることが多かったのです。
改訂されたプロセスでは、通常のレビューサイクルを3ラウンドに制限し、それを超える場合は作成者にアプローチの再検討を求めます。また、後続のパスを新しい差分に絞り、繰り返し現れる指摘を抑制し、1つずつの事例ではなく、バグの種類全体に対処するよう作成者に求めます。
アイデアを一文で入力するだけで、We0 AI が紹介サイト、ページ、CMS を生成し、公開後の顧客獲得と流入拡大を支援します。
無料登録で完全なプロジェクトを 1 つ生成
1 つの完全な生成フローを試し、最初のプロジェクトのドラフトをすぐに確認するのに最適です。
| 社内指標 | 変更前 | 収束改善後 |
|---|---|---|
| 1回のレビューと修正ラウンド後に合格 | 65% | 78% |
| 5ラウンド以上が必要 | 8.9% | 1.5% |
| 合格までの平均レビュー回数 | 2.08 | 1.32 |
Anthropicの社内測定結果。原典レポートをもとに再掲。
コメントが増えることと、レビューが良くなることは同じではありません。Anthropicは、専門家が確認したインシデント事例と、問題がないことが分かっている変更を使ってレビュアーをテストし、見逃したバグと有害な誤検知の両方を追跡しています。
人間は、ある機能を製品に組み込むべきかどうかの判断、重要なアーキテクチャのレビュー、課金、CI、アップデーターなどのリスクの高い領域の確認について、引き続き責任を負います。また、自動チェックで見逃される可能性のあるものを理解する必要もあります。
作成者とオンコール担当のエンジニアは、マージ後の結果を監視します。フィーチャーフラグ、社内利用、段階的なチャネルによって復旧は容易になりますが、インシデントがなくなるわけではありません。公式の説明によると、指標が悪化したときに承認要件を厳格化する自動サーキットブレーカーは、今後望まれる改善事項です。
変わらない責任は、出荷した変更に対する所有権です。実装が速くなれば、不要なプルリクエストを破棄しやすくなります。しかし、何を出荷すべきかという判断を、チェックされていないレビューサイクルへ移すことはできません。
いいえ。作成者と承認は別の指標です。社内プロセスでは、リスクに応じて人間によるレビューを調整し、指定された変更やパスには必須の承認を残しています。
公式の説明では、置き換えることはできないと明記されています。自動レビューによって対象となる低リスクの作業を通過させることはできますが、人間用に指定された承認枠を埋めることはできません。
エージェントは異なる潜在的欠陥を調査し、別の検証担当がその結果を評価します。これにより、コメントが作成者に届く前にチェックを追加できます。ただし、意見が一致したからといって、すべての指摘が正しいとは限りません。
制限のない作成者とレビュアーのループは、以前から存在する問題を繰り返し指摘しながら、時間を消費する可能性があります。上限を設けることで、同じサイクルを自動的に続けるのではなく、アプローチの再検討を促します。
これは、6月から9月にかけて、リバートが必要になったマージ済みClaude Codeプルリクエストの割合が相対的に減少したことを示しています。すべてのソフトウェア欠陥が40%減少したという主張ではありません。
検証可能なチェック、明確なリスクルール、信頼できるロールバックから始めてください。人間の関与を減らす前に、インシデントやリバートと併せてレビューの負荷を測定します。
Claude Codeのチームは、早期検証、マルチエージェントレビュー、セキュリティチェック、明確な承認ルール、迅速な復旧を組み合わせています。また、レビューのループにも上限を設け、変更の改善につながらないままエージェント同士が互いを忙しくレビューし続けることを防いでいます。
自動化によって差分を読む人は変わっても、判断と結果に対する責任は人間に残ります。
ひとことから始めて、数分で完全なサイトを手に入れましょう。
