AnthropicのClaude Codeチームによると、6月から9月にかけてマージされたプルリクエスト数は2倍超になり、差し戻された割合は40%超低下した。同チームの10月15日の説明では、Anthropicの主要なモノレポとは別のリポジトリで、リスクに応じて人による承認の要件を変える仕組みを紹介している。これらは同チーム自身の指標であり、改善の原因を立証するものではない。
開発責任者は、一般提供されるCode Reviewサービスで問題の指摘を集めつつ、独自のマージ要件を設定できる。サービスは不具合の疑いを報告し、どのチェックと誰の判断で変更をリリースできるかはチームが決める。
大きな変化
- 何が変わったか： AIによるレビューは、提案された変更と周辺コードを調べ、疑わしいバグを検証し、検証後も残った指摘を該当行のそばに示せる。エージェントがコードを生み出す中、開発チームはレビューの判断材料をもう一つ得られる。
- なぜ重要か： 一般提供のレビューサービスはコードを実行せずに読み、リリース許可は与えない。テストとリポジトリの承認ルールは別途決めるもので、開発責任者による設定が必要だ。
- 注目点： レビュー頻度は支出に影響し、予算上限によってレビューがスキップされることもある。導入チームは、完了して問題が見つからなかったレビューと、そもそも実行されなかったレビューを区別する必要がある。
社内プロセスはリスクに応じて承認を割り当てる
このClaude Codeチームの手順は、テスト、エージェントによるレビュー、セキュリティレビュー、継続的インテグレーションを組み合わせる。マージキューを経て段階的にリリースし、機能フラグとロールバックで復旧する。
信頼された作成者に対する承認方針は次のとおり。
変更のリスク | 自動チェック後に必要な人による承認 |
|---|---|
低：文言や社内限定の機能など | 不要 |
中：通常の製品変更など | 1人 |
高、およびレビュー担当者2人が指定されたパス | 2人 |
エージェントを指揮する人は必要人数に数えるが、エージェントの承認は数えない。承認は特定のコミットを対象とする。レビューを3回行った後は、担当者が作成者にアプローチの再考を求める。それ以降は新しいdiffに絞って確認する。差し戻しやインシデントを安全指標として使うが、悪化した際に承認要件を厳しくする自動制御はまだない。
一般提供のレビューサービスが行うこと
この現行のCode Reviewマニュアルは、Anthropicのインフラ上で複数のエージェントがdiffと周辺コードを読むと説明する。検証段階で提案された指摘を調べ、その後、サービスが重複を除き、重大度を順位付けし、コメントとチェック実行を投稿する。コードのビルドや実行はせずに読む。そのチェック実行はプルリクエストを失敗扱いにせず、サービスが承認やブロックをすることもない。
利用にはTeamまたはEnterpriseの組織とGitHubリポジトリが必要だ。マニュアルは、Zero Data Retention、HIPAA構成、顧客管理の暗号鍵を使う組織を対象外としている。プロプライエタリなコードをレビューに送る前に、こうした制約を確認することが重要になる。BIG CHANGEは文書を確認したもので、このワークフローを導入・テストしてはいない。
このセットアップ手順では、Claude組織のOwner、アプリをインストールして連携するためのGitHub組織の所有者、リポジトリを追加するための書き込み権限が必要だ。アプリが要求する権限は、レビュー自体で使うものより広い。管理者はQuick、Standard、Deepのレビューと、プルリクエストごとに1回、pushごと、または要求時という実行方式を選ぶ。自動レビューはドラフトとフォークを除外するが、書き込み権限のある人は手動でレビューを要求できる。
指示とルールの強制適用は役割が違う
このカスタマイズマニュアルは、2つのファイルを区別している。CLAUDE.mdはプロジェクトの文脈を提供し、REVIEW.mdはレビュー固有の優先事項と除外対象を定める。サービスはベースブランチまたはデフォルトブランチからレビュー指示を読み、提案された変更自体からは決して読まない。ローカルの/code-reviewコマンドはCLAUDE.mdを読むが、REVIEW.mdは読まない。そのため、両ツールに共通の指示はCLAUDE.mdに置く。
強制適用はリポジトリのルールが担う。GitHubのブランチ保護ドキュメントは、必須のステータスチェック、コード所有者の承認、レビューの議論の解決を説明している。レビュー済みのdiffが変わったときに承認を取り消す機能もある。通常、管理者は保護を回避できるが、ルールが管理者にも適用される場合は別だ。したがって開発責任者は、レビューのコメントに加え、実際に有効なルールとその回避権限を確認する必要がある。
文書にある一般提供のレビューサービスは、合格したアプリケーションテストも、必須の人による承認も提供しない。これらの記録を分けておけば、どの証拠に基づいてマージしたのか確認できる。
実行されたレビューを測定する
Code Reviewの課金は使用量クレジットを通じたトークン課金で、プランに含まれる使用量とは別枠だ。Anthropicはレビュー1回あたりの固定料金を公表していない。費用はレビューの深さ、変更と周辺コード、検証が必要な指摘によって変わる。pushのたびにレビューすれば、同じプルリクエストに対するレビュー回数が増える。
費用マニュアルは、限定的な試験導入、月間支出上限、リポジトリの平均費用の測定を勧める。サービス上限、組織上限、クレジット残高を使い切ると、レビューがスキップされることがある。残額が1回のレビューの予想費用に満たない場合も同様だ。スキップされると、その理由を説明するコメントが付く。
試験導入では、意図したレビューサービスが意図した変更を実際にレビューしたこと、必須のテストと人による承認が引き続き適用されること、不適切なリリースをチームが取り消せることを確認する。他の現場での効果を立証するには、導入チーム自身のレビュー、差し戻し、インシデントの記録が必要になる。BIG CHANGEが以前報じたコードの出力量と完了した仕事の記事は、これとは別の、企業を対象とした研究を扱っている。
出典と参考資料
- Claude Codeチームのコードレビュー方法（2026年10月15日）。企業による説明と社内指標。
- Code Review。現在のサービスの動作、利用条件、データ上の制約。2026年10月17日確認。
- Code Reviewのセットアップ。必要な役割、リポジトリへのアクセス、レビューの深さ、実行トリガーの制御。2026年10月17日確認。
- Code Reviewのカスタマイズ。指示ファイルとブランチ選択ルール。2026年10月17日確認。
- 保護されたブランチについて。GitHubが文書化したマージ要件と回避の動作。2026年10月17日確認。
- Code Reviewの費用と使用量。課金、試験導入の見積もり、レビューをスキップする条件。2026年10月17日確認。
