Claude Codeチームが実践するコードレビュー自動化：リスクベース承認とScion移行で3万件/日のマージを支える設計思考

はじめに：AIコード生成時代の「レビューの壁」とは何か

AIエージェントによるコード生成が日常化した今、開発チームが直面する課題の一つに「レビューのボトルネック」がある。AnthropicのClaude Codeチームでは、コードの大部分がClaude自身によって書かれていると報告されている（Anthropic公式ブログ）。この比率は、人間が手動でコードを書いていた時代とは異なる前提をチームに課している。

人間が1日あたりに書けるコード量には物理的な上限がある。一方、AIエージェントは並列で複数のファイルを同時に生成できる可能性がある。その結果、PR（プルリクエスト）の作成数が増加し、レビュー人間の処理能力がボトルネックになる懸念がある。従来の「人間がすべてのPRを逐一レビューする」モデルでは、このスケールに対応しにくくなる。

ここで重要なのは、この問題が「レビューツールが足りない」ことではなく、「レビューのプロセス自体がスケールしない」ことである。ツールを追加しても、人間が1件あたり数分かけてレビューする構造を変えなければ、PRが増加しても待ち時間は伸びる可能性がある。問題の所在を「ツール不足」と誤認すると、CIパイプラインにレビューボットを追加するだけで解決すると考え、本質的なプロセス設計を先送りすることになりかねない。

本記事で扱うのは、特定のツールの紹介ではない。Anthropicが直面したスケーラビリティ問題と、それを解決するために下した設計判断のプロセスである。3万件/日のマージを支える背景にある思考プロセスを、中小企業・スタートアップでも参考にできる形に整理する。

読者が得られるのは、大量のAI生成コードを品質を保ちつつ運用し、承認フローをどう設計すべきかという指針である。特に「どこを自動化し、どこに人間を残すか」という判断軸は、チームの規模に関わらず適用できる可能性がある。

背景：なぜClaude Codeチームはレビューの自動化を迫られたのか

Anthropicでは、Claude Codeのmonorepoにおける1日あたりのマージ数の増加が見られたと報告されている（Anthropic公式ブログ）。この増加率は、通常の開発チームでは想定しにくい規模である。

この急増の主因は、Claude Code自体の開発におけるAIコード生成比率の高さにあると推測される。人間が書くコード量には限りがある一方、AIエージェントは複数のファイル変更を並列で生成できる。PRの作成速度が人間のレビュー速度を上回る状況では、従来のワークフローでは対応しにくくなる。

従来のGitベースのワークフローでは、以下のようなボトルネックが顕在化する可能性がある。まず、ローカルでコミットを作成しpushした後に、リモートとの差分が発生するとマージ衝突が起きる。衝突の解決は人間の手作業を要する場合があり、AIが大量のファイルを同時に変更する場合は衝突箇所が多数にわたる。次に、レビュー人間の待ち時間が発生する。PRが溜まると、レビューが完了するまでのリードタイムが伸び、エージェントの次のタスク開始がブロックされる可能性がある。

Anthropicが下した判断は、単にレビューツールを追加するのではなく、バージョン管理システム自体を見直すことだったとされている。Gitから自社製のVCS「Scion」への移行が、このスケーラビリティ問題の解決につながったと報告されている（Anthropic Engineering）。次節でScionの設計判断を詳しく見るが、ここでは「なぜGitのままではスケールしにくかったのか」を整理しておく。

flowchart TD
    A["AIがコードを生成"] --> B{"VCSの方式"}
    B -->|Git 分散型| C["ローカルでコミット・push"]
    C --> D["衝突の手動解決 → レビュー待ち"]
    D --> E["人間がレビュー → マージ"]
    B -->|Scion 集中型| F["サーバーでコミット・マージ処理"]
    F --> G["リアルタイム衝突解決 → 自動レビュー"]
    G --> H["即マージ"]

図の比較から見られるのは、Gitの分散型モデルでは「ローカルでの処理」がボトルネックになる一方、Scionの集中型モデルではサーバー側で処理が完結するため、衝突解決とマージがリアルタイムで行われる点である。エージェントの並列数が増加しても、処理の集中先が明確なため、ボトルネックが分散しない可能性がある。

基盤設計：3万件/日のマージを支える「オンライン前提」のVCSアーキテクチャ

Scionの核心的な設計判断は「クライアントが常にオンラインであることを前提にする」ことである（Anthropic Engineering）。Gitのようにローカルに完全なリポジトリのコピーを持ち、オフラインでもコミットやブランチ操作が可能な分散型モデルを捨て、代わりにサーバー側でコミットやマージを処理する集中型アーキテクチャを採用したとされている。

なぜ分散型モデルを捨てたのか

Gitの分散型モデルは、オフライン作業や複雑なローカルブランチ管理を可能にする強力な機能を持つ。しかし、AIエージェントが大量のPRを短時間に生成する環境では、これらの機能が障害になる可能性がある。ローカルでコミットを積み上げ、pushした時点でリモートとの差分が巨大化し、マージ衝突が頻発する。さらに、複数のAIエージェントが同時に異なるブランチで作業すると、ブランチ間の整合性を人間が管理する負荷が増大する可能性がある。

Scionはこれを「クライアントは常にオンラインで、すべてのコミットとマージをサーバーが処理する」という前提に置き換えることで解決したとされている。エージェントがコードを生成したら即座にサーバーに送信し、サーバー側で衝突検出と解決を行う。人間のローカル環境に処理負荷を掛けないため、エージェントの並列数が増加してもボトルネックが分散しない可能性がある。

トレードオフと中小企業への示唆

この設計のトレードオフは明確である。オフラインでの作業ができなくなる。ネットワークに依存するため、通信障害時に開発が止まるリスクがある。また、複雑なローカルブランチ戦略（feature branch、release branchの多層構造など）が難しくなる。Anthropicの規模ではAIエージェントが主体であり人間の手作業が補助的であるため、この制約は許容できる可能性がある。しかし、人間が日常的にローカルでコードを書くチームでは、この前提がそのまま適用できるかは検討が必要である。

中小企業・スタートアップがScionをそのまま再現するのは現実的ではない。しかし、この設計思想の核心は「処理をサーバー側に集約し、リアルタイムで衝突を解決する」ことである。既存のGitHubやGitLabのAPIをCI/CDパイプラインと連携させ、プッシュされた変更に対して自動でマージチェックと衝突解決を行う構成は、Scionの思想を既存ツールで近似する現実的なアプローチとなり得る。Gitの分散型モデルに固執せず、クラウドネイティブな集中管理型の運用を視野に入れることが、AIコード生成時代のVCS戦略において重要な判断ポイントになる可能性がある。

レビュープロセス：PR作成前の自動化と並列検証の仕組み

Scionへの移行でマージのボトルネックを解消した次に、Claude Codeチームが設計したのが「PR作成前」に品質検証を完了させるワークフローである。従来のフローでは、PRが作成された後にレビュー者が環境を構築し、テストを実行して問題を確認するという一連の手順が発生する。この待ち時間が積み重なると、レビュー者の帯域が逼迫し、マージまでのリードタイムが伸びる可能性がある。

Claude Codeの対応は、この検証工程をPR作成の前に前倒しすることだ。具体的には、Claude自身がコード生成後にテストやビルドを実行し、別エージェントが差分をレビューするという2段階の自動化が組み込まれていると報告されている（Anthropic公式ブログ）。つまり、PRが人間の目に入る時点では、ビルドが通っていることと、別エージェントによるレビューコメントが既に付与されていることが前提となる可能性がある。

ここで設計上の重要な判断が2つある。第一に、「生成」と「レビュー」を別エージェントに分離している点だ。同一のエージェントが自分の出力をレビューすると、生成時の前提や意図に引きずられて問題を見逃す傾向がある。別エージェントは生成時のコンテキストを共有しないため、第三者の視点で差分を評価できる。これは人間のコードレビューにおける「書いた本人がレビューしない」という原則の、AIエージェント版に相当する。

第二に、バグ発見には複数のエージェントが並列で検証を行うという設計だ（Anthropic公式ブログ）。単一エージェントのレビューでは、そのモデルの訓練データやプロンプトの設計に由来する系統的な盲点が残る可能性がある。複数エージェントが異なるアプローチで同一の差分を検証することで、検出の網羅性が向上する。コストは増えるが、3万件/日の規模では「見逃したバグが本番に到達するコスト」が並列検証のコストを上回るため、この投資は合理的である可能性がある。

sequenceDiagram
    participant C as Claude（生成エージェント）
    participant T as テスト/ビルド実行
    participant R as レビューエージェント（複数並列）
    participant P as PR投稿
    C->>C: コード生成
    C->>T: テスト・ビルド実行
    T-->>C: 実行結果（パス/フェイル）
    C->>R: 差分を別エージェントに送信
    par 並列検証
        R->>R: エージェントAが差分レビュー
    and
        R->>R: エージェントBが差分レビュー
    end
    R-->>P: レビューコメント付与
    P->>P: PRが人間のレビューに到達

この設計が人間のレビューに与える効果は、レビュー者が「このコードはビルドが通っているか」「明らかなバグはないか」という一次確認に時間を費やす必要がなくなる点にある。人間がレビューに割く時間は、設計意図の妥当性やアーキテクチャへの影響といった、AIエージェントが判断しにくい上位の判断に集中できる可能性がある。これが「生成→実行→レビュー」サイクルをPR作成前に完結させることの本質的な価値である。

承認フロー設計：リスク分類器とティアリングされた承認人数

PR作成前の自動化で品質の下限を担保した上で、次の問題が生まれる。すべてのPRに同じ承認プロセスを適用すると、ドキュメントの修正のような低リスク変更にも高コストなレビューが求められ、スループットが低下する。逆に、インフラ設定の変更のような高リスク変更を低コストなフローで承認すると、重大な事故のリスクが残る。

Claude Codeチームの解決策は、リスク分類器の導入だ。この分類器が各PRの変更内容を解析し、危険度を判定する。判定結果に基づいて、承認に必要な人間の数が0人、1人、2人のティアに設定されると報告されている（Anthropic公式ブログ）。0人ティアは完全な自動マージであり、1人ティアは単一のレビューで承認、2人ティアは複数名の合意が求められる。

このティアリング設計の利点は、レビューリソースの配分がリスクに比例することだ。3万件/日のPRのうち、大半が低リスクに分類されれば、人間のレビュー帯域は高リスクの少数のPRに集中される可能性がある。結果として、全体のマージスループットは維持されつつ、真に危険な変更への人的監視が強化される。

設計上の落とし穴として、リスク分類器自体の精度がボトルネックになり得る点が挙げられる。分類器が高リスクの変更を低リスクと誤判定した場合、自動マージにより未検出のバグが本番に到達する可能性がある。そのため、分類器の判定結果は監査ログに記録され、後から誤判定の傾向を分析して分類基準を改善する運用が前提となる。また、新しい変更パターン（例：新規モジュールの初回追加）に対しては、分類器が学習していないため、デフォルトで保守的なティアに振り分ける設計が安全である可能性がある。

セキュリティガバナンス：独立したパスとブロック条件

リスク分類器とティアリングが「機能性」の承認フローを最適化するのに対し、セキュリティレビューはこれとは完全に独立したパスとして設計されている。Anthropicの実装では、セキュリティレビューは通常のコードレビューとは別に行われ、オープンな発見（未解決の脆弱性）がある場合、マージがブロックされる可能性がある（Anthropic公式ブログ）。つまり、リスク分類器が低リスクと判定したPRであっても、セキュリティレビューで問題が発見されればマージは停止する。

この「分離」が設計上重要である理由は、コードの機能性評価とセキュリティリスク評価が要求する知識の領域が根本的に異なる点にある。機能性レビューは「このコードが意図した動作をするか」を判断するのに対し、セキュリティレビューは「このコードが意図しない形で悪用される可能性はないか」を判断する。前者は差分の意図とテスト結果で評価できるが、後者は依存関係の脆弱性、入力バリデーションの欠落、機密情報の取り扱いですら専門的な判断を必要とする。同一のエージェントや同一のフローに混在させると、セキュリティの視点が機能性の確認に埋没するリスクがある。

AI生成コードにこの分離が特に重要になる理由は、生成モデルが学習データからパターンを再現する際に、既知の脆弱パターンを無意識に再生成し得る点にある。例えば、依存関係の指定が緩いバージョン制約、ハードコードされた認証情報、未検証の外部入力への直接参照などは、モデルが「一般的なコードの書き方」として学習したパターンに由来する可能性がある。人間のレビューアが「見たことがあるコード」だからと素通りしてしまうようなパターンが、AI生成コードではより頻繁に出現し得る。

運用面では、自動化されたセキュリティスキャン（SASTや依存関係の脆弱性チェックなど）の結果が閾値を超えた場合、人間による手動検証へエスカレーションする仕組みが有効である。スキャン結果が閾値未満の場合は自動でパスし、閾値超の場合はセキュリティ専門のレビューアに通知して判断を求める。この閾値の設定は、誤検知率と見逃し率のトレードオフであり、チームのセキュリティポリシーに応じて調整する必要がある。重要なのは、この独立したパスがリスク分類器のティアリングに優先して機能することだ。リスク分類器が「低リスク」と判定したPRでも、セキュリティレビューのブロック条件に抵触すればマージは行われない。この優先順位が、セキュリティガバナンスの設計における最も重要な判断である。

実装と運用：Claude Codeの統合とベストプラクティス

Claude Codeはターミナル、IDE拡張機能、デスクトップアプリ、Webの4つの形態で提供されている（Claude Code公式ドキュメント）。この多様なインターフェースは、チーム内の開発スタイルの多様性を吸収するための設計判断である。ターミナル派のエンジニアはCLIから直接操作し、IDEに依存するメンバーは拡張機能からトリガーする。重要なのは、どの入口から操作しても同じエージェントロジックが実行されることで、レビュー品質が入口によって偏らない点だ。

開発環境への組み込みは、Homebrew経由で安定版のclaude-codeパッケージをインストールすることで可能になる。最新機能を試す必要がある場合はclaude-code@latestチャンネルを追跡するパッケージが用意されており、安定性と新機能の取得を分離して管理できる（公式ドキュメント）。チームでの導入時には、安定版をデフォルトにし、特定の実験的ワークフローだけlatestチャンネルを使用する、という使い分けが運用の安定性を保つ。

MCP（Model Context Protocol）は、Claude Codeが外部データソースやツールと連携するためのプロトコルである（公式ドキュメント）。レビューの文脈で言えば、コードの差分だけでなく、関連するチケット情報や過去のレビューコメント、インシデント記録などをMCP経由でエージェントに提供できる。これにより、エージェントが「コードだけを見て判断する」のではなく、「変更の背景と影響範囲を踏まえて判断する」ようになる。レビュー精度を高めるには、この文脈の付与が単なるプロンプトの改善よりも効果的である。

推奨されるワークフローは「探索」「計画」「実装」「コミット」の4フェーズで構成されている（best-practices guide）。この4フェーズをレビュープロセスと紐づける設計判断が重要だ。「探索」フェーズで収集した情報（影響範囲、既存の制約）を「計画」フェーズで明示的に文書化し、「実装」フェーズではその計画から逸脱した変更を自動的にフラグする。そうすることで、「コミット」フェーズで生成されるPRは、計画と実装の差分が明確に示された状態になる。レビューア（人間もエージェントも）が「何を変更し、なぜ変更したのか」を即座に把握できるため、レビュー時間が短縮される。

運用上の注意として、4フェーズの各段階で生成される中間成果物（計画書、影響分析）をPRの本文に自動挿入する仕組みをCI/CDパイプラインに組み込むと、レビューの再現性が向上する。エージェントが「なぜこう実装したか」を後から推測する必要がなくなり、レビューの焦点が「実装の正しさ」に集中する。

落とし穴：コンテキストウィンドウの限界と検証可能なチェック

Claudeのコンテキストウィンドウが埋まるとパフォーマンスが低下するため、検証可能なチェックを提供することが重要視されている（best-practices guide）。これは単なる「トークン数が多いと遅い」という話ではなく、エージェントの判断品質が構造的に劣化するという設計上の制約である。コンテキストに収まらない情報をエージェントに渡すと、重要度の低い情報と高い情報が混在し、判断の優先順位が崩れる。

具体的な影響をレビューの文脈で考えると、巨大なPR（数百行〜数千行の差分）を一度にエージェントに渡した場合、差分の冒頭と末尾の関連性を正しく評価できなくなる。例えば、ファイルAの関数シグネチャを変更し、ファイルZの呼び出し側を対応させるような変更は、差分が分断されると「ファイルZの変更が孤立した変更に見える」リスクがある。これがバグ検出の盲点を生む。

対策として、チーム内でPRの粒度に関する明確なルールを定義する必要がある。目安としては、1つのPRが1つの論理的な変更（1つの関数のリファクタリング、1つの機能の追加など）に収まるサイズに分割する。これは人間によるレビューでも有効な原則だが、AIエージェントがレビューを行う場合は、コンテキストウィンドウの物理的制約がその上限を決定するため、より厳格に適用する必要がある。

「検証可能なチェック」とは、エージェントがコードの正しさをテキストの理解だけで判断するのではなく、実行結果やテスト出力といった客観的なデータに基づいて判断できる状態を作ることである。例えば、PRに「この変更によりテストtest_user_authがパスしている」ことだけでなく、実際のテスト実行ログを添付する。エージェントは差分のコードを読むだけでなく、ログから期待された動作が確認できる。これにより、コンテキストウィンドウに収まる情報量が少ない場合でも、判断の根拠がコードの理解から実行結果へシフトし、精度の低下を抑制できる。

もう一つの落とし穴として、エージェントへの指示（プロンプト）の粒度が問題になる。「このPRをレビューして」という曖昧な指示では、エージェントがコンテキスト内で何を重視するかを自分で決定せざるを得ず、結果が不安定になる。一方、「この変更は認証フローのタイムアウト処理に関するもの。重点的に確認すべきは、セッションの有効期限超過時の状態遷移と、並行リクエスト時の競合条件である」という具体的な指示を付与すれば、コンテキストの使い方そのものが最適化される。チーム内でレビュー依頼時のテンプレートやチェックリストを定義しておくことが、この不安定性を軽減する現実的な手段である。

中小企業・スタートアップへの適用：現実的な導入指針とトレードオフ

Anthropicが自社製VCS「Scion」を構築し、リスク分類器を独自に実装したアプローチは、数千名のエンジニアが同時に開発を行う環境を前提としている。中小企業・スタートアップがこれをそのまま再現することは、コストと運用負荷の観点から現実的ではない。しかし、設計思想の核心である「リスクに応じた承認のティアリング」と「PR作成前の自動化」は、既存のツールで十分近似できる。

リスク分類の近似として最も実用的なのは、変更対象のファイルパターンと変更行数の2軸でルールを定義する方法である。例えば、/src/auth/配下の変更は「高リスク」、/docs/配下の変更は「低リスク」、それ以外は「中リスク」と分類し、それぞれに異なるRequired Reviewers数を設定する。GitHubのCODEOWNERSファイルとRequired Reviewsの組み合わせで、このティアリングを数日で実装できる。変更行数の閾値（例：200行超で追加レビューアを要求）は、CIのチェックとして実装し、閾値超過時に自動で通知する。

トレードオフとして認識しておくべき点は、このルールベースの分類は「変更の意図」を判定できないことである。Anthropicのリスク分類器が変更の文脈（どのコンポーネントに影響するか、過去のインシデントとの関連性など）を考慮して判定しているのに対し、ファイルパターンベースの分類は「どこを変更したか」しか見ない。そのため、/docs/配下に変更を加えたPRでも、実はビルド設定のファイルに手が入っている場合は「低リスク」と誤判定される可能性がある。この盲点を補うには、PR作成時にエージェントに「この変更が影響するモジュールを列挙する」よう指示し、その出力をリスク判定の追加入力として使う手法が有効だ。

セキュリティレビューの独立パスを実現する際は、SASTツール（コードの静的解析）と依存関係の脆弱性チェック（SBOMベース）をCIパイプラインに組み込み、結果が閾値を超えた場合にマージをブロックする設定にする。これはAnthropicの「オープンな発見がある場合マージをブロックする」設計の直接的な近似である。重要なのは、このブロックがリスク分類のティアリングよりも優先されること。ルールベースの分類が「低リスク」と判定したPRでも、SASTで高重大度の脆弱性が見つかった場合はマージを止められるよう、CIのジョブ順序とブロック条件を設計する。

まとめ：AIコード生成時代の「質」と「速度」の両立

Claude Codeチームがmonorepoへの日次マージ数を大幅に拡大させた背景には、単一のツール導入ではなく、VCSアーキテクチャの見直し（Scionへの移行）、PR作成前の自動化、リスクベースの承認ティアリング、独立したセキュリティガバナンスという複数の設計判断の組み合わせがあった。これらの判断はそれぞれ独立して機能するのではなく、「大量のマージを品質を落とさずに処理する」という一つの目標に対して、ボトルネックを段階的に解消する役割分担を持っている。

中小企業・スタートアップがこれらを適用する際の核心は、Anthropicのインフラを再現することではなく、各設計判断が解決している「問題」を正確に識別し、自チームの規模とツール環境に合った手段で同じ問題を解決することである。リスク分類器が解決しているのは「レビューリソースの最適配分」であり、Scionが解決しているのは「マージ処理のスループット」である。問題の識別が正確であれば、既存のGitHub/GitLab機能とCI/CDパイプラインの組み合わせで、スケーラビリティの向上は部分的に実現可能である。

今後の方向性として、AI生成コードの品質担保は、単なるバグ検出から、セキュリティ・パフォーマンス・保守性・アーキテクチャの整合性まで広範な領域へ拡張していく。Claude Codeのコードの多くがAIによって書かれているという事実は（Anthropicの解説記事）、「人間が書いてAIがレビューする」モデルから「AIが書いてAIがレビューし、人間がリスクに応じて承認する」モデルへの移行が既に行われていることを示している。この移行に伴う設計判断の蓄積が、今後のAIエージェントと人間の協働開発の標準となるだろう。技術リーダーが今やるべきことは、自チームのレビューフローにおけるボトルネックを特定し、リスク分類と自動化レビューの導入を、小さな単位で始めながら運用データを蓄積していくことである。

関連記事

• AI時代の「中級エンジニアの消滅」と技術的負債：エージェント活用における品質保証の設計思考
• AIコード生成ツールの盲点：Copilot Autofixが見過ごした脆弱性と、開発者が取るべき現実的な対策
• AI生成コードの信頼性：C4モデルからDSTまで、実装検証のためのリライアビリティスタック構築指南

参考

本記事は海外の技術トレンド「How the Claude Code team does code review」（Hacker News）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。