Claude Code のコードレビュー：進化と新たな仕組み

Anthropic の最新記事に基づき、Claude Code チームにおけるコードレビューの現状、目的、そして具体的な実装方法を整理しました。

はじめに：レビュー体制の進化

以前は Claude が約 90% のコード生成を担い、大量のコードに対するレビューの仕組みが問われていました。現在は以下の成果が達成されています。

• プルリクエスト（PR）数の増加: 6 月以降 9 月の間にマージされた PR は 倍以上に増加。
• 安定性の向上: ロールバック（取り消し）が必要なものの割合は 40% 以上減少。
• アプローチの変遷: 「人間がコードを読んだか」という問いを、「この変更で何が起きうるか」という自動検知への焦点へシフト。
• 継続的レビュー: レビューを最終段階のゲート（門番）から、記述中の「スペルチェック」のようなプロセスへ移行。多くのミスは人間が目を通す前に AI が修正済みです。

コードレビューの目的と課題

高速なリリースペースにおいて、手動での行単位のレビューは困難です。現在の目標は以下の 2 つのバランスです。

1. 主要目的：問題の発見と修正

• 変更量の急増: Anthropic の一元管理リポジトリで、日ごとのマージ数は約 2,500 から 30,000 を超えました。
• 自動化の最大化: 人間の時間を「解決不可能な課題」に集中させ、残りを自動化チェックで処理。
• ロールバック防止: 多くの PR が少なくとも一人の人間（オーサー含む）の関与下でマージされ、インシデントが発生しない状態を維持します。

2. 副次的目的：コンテキスト共有と理解

• チーム全体のコードベースへの理解を構築します。
• AI が大部分を読み取る場合でも、重要な決定は人間が行います。
  • ビルドすべきか？
  • 方向性は適切か？
  • 影響範囲（Blast Radius）の評価
  • テスト出力やエラーログの解釈

多層的な防御ライン：レビューの仕組み

変更は以下の 7 つのレイヤーを通過します。各層が特定のリスクを取り扱います。

レイヤー 1: 他者が目を通す前の検証（自動）

• 内部スキル: バグハンティング、差分の簡素化、E2E テストなどが PR オープン前に行われます。
• AI の指示:

  CLAUDE.md

  （プロジェクトコンテキスト）、

  REVIEW.md

  （重要度や避けるべき点）を読み込みます。
• 検証の重要性: Boris Cherny は「検証手段を与えること」が成果を 2〜3 倍に改善できると述べています。

レイヤー 2: AI による全 PR レビュー

• プロセス: すべての PR に対して Claude がレビューし、「問題を解決しているか」「システム適合性」を確認します。
• チーム構成: Quick（高速）、Standard（標準）、Deep（深い）の 3 モードを選択可能。
• 厳格な判断: エージェントによる発見事項は、複数のエージェントで投票し、「真実である」と合意したのみ公開されます。
  • 重要度タグ:

    Important

    （重要）、

    Nit

    （微細点）、

    Pre-existing

    （既存）の分類があります。

レイヤー 3: セキュリティレビュー

• ブロック機能: 脆弱性が発見され解決するまでマージは不可能です。
• 自動クリア: 後続のコミットで問題が修正されると、自動的にステータスが更新されます。

レイヤー 4: 自動チェック（リンタ・テスト）

• 通常動作: リンター、型チェック、プラットフォームごとのテスト、ビルド実行。
• CI スケーリング: 数十のチェックを実行する体制を整えています。

レイヤー 5: リスクに応じた人間承認

変更の内容によって必要とされる人間の関与度を変更します。

リスクレベル	対象例	承認要件
Low（低）	ドキュメント、コピー、機能フラグ化	自動化レビューのみ（人間不要）
Medium（中）	製品変更、キャッシュ、システムプロンプト	1 人の人間承認必須
High（高）	重要なコードパス、機密データ	2 名の人間承認必須

• 責任の所在: エージェントが記述したコードでも、指示を出した人間はレビュー担当者としてカウントされます。
• スロット制: リポジトリの信頼リスト外や新規コミットは、再承認が必要です。

レイヤー 6: マージキューと段階的リリース

• マージキュー: メインブランチへの適用前に全チェックを再実行し、壊れた状態を防ぎます。
• フラグ化: 新機能は内部利用から始まり、安定性が確認された後に公開されます。

レイヤー 7: 迅速な検出と復旧

• インシデント対応: 周回コール（on-call）体制で、どのレイヤーが漏らしたかを分析します。
• サーキットブレイカー: エラー率上昇に応じて承認ハードルを動的に引き上げる仕組みを検討中ですが、現状はエンジニアの判断に委ねられています。

レビュー品質の向上：継続的改善

AI と人間のレビュー円環（Feedback Loop）において、以下の改善が行われています。

• 評価基準の構築: 過去のインシデント・ロールバックをデータ化し、毎日実行されるテストケースとして蓄積。
• 「ノイズ」の管理: 誤検知を防ぎつつ、実際のバグを見逃さないよう調整します。
  • AI は修正を実行するため、微細な指摘が追加コミット（別レビューラウンド）を招くコストが高くなります。
• レビューラウンドの削減:
  • ラウンドキャップ: 3 ラウンドを超えた場合はオーサーに方針見直しを促します。
  • 対象差分の絞り込み: 最初の数回後から、新規差分のみを対象として再レビューします。
  • バグクラス化: 「全インスタンス修正」や「既知の欠陥」タグなどで曖昧さを排除。

人間が留まることがべき場所

自動化では対応できない「判断と責任」は人間が行います。

• アーキテクチャ決定: パターン設計、方向性の選定。
• 複雑な問題の解決: エビデンス（ログ、スクリーンショット）からの解釈。
• 最終責任: 誰がコードを入力しても、マージされた変更に対して人間が責任を持ちます。
  • 「小さく分けてマージし、誤りがあれば直ぐに修正・ロールバックする」という文化が責任共有を促進しています。

チームへの導入方法：ステップバイステップ

これらのプロセスを導入するための具体的なアクションは以下の通りです。

PR 作成前（Pre-PR）

• 指示書の準備:

  CLAUDE.md

  にチェックリストを記載し、フォーマッターやリンタのフックを追加。
• ローカルレビュー:

  /code-review

  または

  /security-review

  コマンドを実行。サブエージェントで差分を確認。
• レビューガイドの作成:

  REVIEW.md

  に重要事項をまとめ、AI に提示。

PR 作成中（During PR）

• CI/CD の必須化: テストとリスク評価テンプレートを PR テンプレートに追加。
• AI レビューの実装: Code Review for Claude Code を導入し、

  REVIEW.md

  でチューニング。
• セキュリティの強制: 脆弱性のスレッドが解決されるまでマージロックを維持。
• レビューラウンドの制限: 初回以降は新規差分のみを対象とさせ、再レビューのコストを減らす。

承認プロセス（Approval）

• リスクティアの設定: 自動化チェックだけで OK な低リスク変更を定義し、人間承認を厳格から緩和へ適用。
• 責任者の明確化:

  CODEOWNERS

  やブランチ保護機能で、認証・ビリング・CI ワークフローは必ず人間の関与を必要とさせる。
  • ボットが代替することは禁止し、新規コミット時にも承認を再発行させる。

公開後（Post-Merge）

• 段階的ロールバック: マージキューや機能フラグを使用し、即座に元に戻せる体制を整える。
• 継続的な評価: インシデントデータを評価セットとして使い、プロンプトやモデルの更新に合わせてスコアリングを再計算。

今後の展望と課題

• 自動化の限界: PR を承認することは依然として人間の判断ですが、製品自体は発見事項を投稿するだけで承認を行わない場合もあります。
• リポジトリの成熟度: オーナーがどの低リスク変更を自動化チェックのみでマージさせられるかを定義し続けています。
• ミスの学習: レビューで見落としたものはモデルへのフィードバック（CLAUDE.md 更新、スキル追加、新規チェック導入）に活かします。

ゴールは明確です：

「変更あたりの人間の時間は減少し、以前のロールバック数以上にならないこと。」

あなたのチームも同様の自動化と人間性のバランスを追求されることを推奨します。