エンジニアがMRを作成すると、数分後に構造化されたコードレビューが自動投稿される——コード品質からセキュリティ脆弱性、コンプライアンス違反まで、複数の専門視点から精査されて。
これがCloudflareが2026年3月から全社展開しているAIコードレビューシステムの実態だ。1ヶ月で131,246件のレビューを実行し、48,095のMRをカバー。中央値3分39秒、1レビュー平均$1.19という数字は、現時点で最も詳細に公開されたマルチエージェントCIシステムの実運用データのひとつだ。
2026年4月に公開されたCloudflare公式ブログ「Orchestrating AI Code Review at scale」は、設計哲学から実装の細部、prompt injection対策、トークン最適化に至るまで、技術的な詳細を包み隠さず開示している。本稿はその内容を整理し、独自のマルチエージェントシステムを構築・評価する際の参考になるポイントを解説する。
単一モデルではなくマルチエージェントを選んだ設計思想
コードレビューにAIを活用する方法は大きく2つある。汎用的な大きなプロンプトに「すべてのレビューをやれ」と指示するか、専門家を複数立てて並列に動かすか——だ。
Cloudflareが選んだのは後者だ。理由は明快で、「巨大で汎用的なプロンプトよりも、焦点を絞った専門家の方が精度が出る」という設計思想に基づく。セキュリティレビューに専念するエージェントは、コード品質や文書の正確さを同時に考慮する必要がなく、指摘の質が上がる。コード品質に集中するエージェントは、セキュリティ知識がなくても深く掘り下げられる。
システムの基盤として採用されたのがOpenCode——オープンソースのコーディングエージェントだ。Cloudflareはこれをラップし、CIネイティブなオーケストレーション層を構築した。
アーキテクチャの核心はプラグイン設計で、各プラグインがReviewPluginインターフェースを実装する。プラグインはライフサイクルの3フェーズで動く：
// ReviewPlugin インターフェースの3フェーズ
interface ReviewPlugin {
// Bootstrap: 並列実行、失敗は致命的でない（リモート設定の取得など）
bootstrap(context: ReviewContext): Promise<void>;
// Configure: 順次実行、失敗は致命的（必須の設定処理）
configure(context: ReviewContext): Promise<void>;
// postConfigure: 非同期処理（フォールバック設定の反映など）
postConfigure(context: ReviewContext): Promise<void>;
}
各プラグインが最終的にopencode.jsonファイルを生成し、OpenCodeがそれを読み込む設計だ。VCS（GitLab）固有の処理やAIプロバイダーとの結合はプラグインに閉じ込め、コア部分は薄く保たれている。
この設計の重要な利点はテスト可能性だ。各プラグインを独立してテストでき、本番と同じopencode.jsonをローカルで再現して動作確認できる。プラグインが増えても、既存のテストが壊れない。
AIエージェントフレームワーク比較2026で解説したように、マルチエージェントシステムの設計では「責任の分離」と「結果の統合」がトレードオフになる。Cloudflareはコーディネーターエージェントがこのボトルネックを一手に引き受ける構造を選んだ。単一のコーディネーターが全専門家の出力を受け取り、整合性のある単一のレビューコメントとして統合する。
エンジニアが受け取るのは「7つのエージェントがバラバラに書いた7件のコメント」ではなく、「コーディネーターが統合した1件の構造化コメント」だ。これがユーザー体験の品質を保つ核心的な設計判断だ。
7つの専門エージェントとコーディネーターの役割
MRが作成されると、コーディネーターはまずMRを分析してリスクティアを判定し、起動すべきエージェントを決定する。最大で7つのエージェントが同時並列に実行される。
| エージェント | 専門領域 | 1ヶ月の指摘数 | criticalの割合 |
|---|---|---|---|
| コード品質レビュワー | ロジックエラー、構造的問題 | 74,898件（47%） | 8.6% |
| セキュリティレビュワー | 脆弱性、インジェクション、認証バイパス | 11,985件 | 4%（最高比率） |
| パフォーマンスレビュワー | パフォーマンス劣化の特定 | 14,615件 | — |
| ドキュメントレビュワー | 文書の完全性・正確性 | 26,432件 | — |
| リリース管理レビュワー | リリース関連変更の検証 | 745件 | — |
| コンプライアンスレビュワー | 社内Engineering Codex準拠 | 9,654件 | — |
| AGENTS.mdレビュワー | AI指示ファイルの更新確認 | 6,878件 | — |
各エージェントは結果をXMLの構造化フォーマットで出力する。重大度はcritical、warning、suggestionの3段階で、コーディネーターはこの出力をもとに「判定パス」を実行する：
- 重複除去（Deduplication）: 複数エージェントが同じ問題を別の角度から指摘した場合に統合する
- 再分類（Re-categorization）: 過剰にcriticalとされた問題をwarningに降格するなど、適切なレベルに調整する
- 妥当性フィルタリング（Reasonableness filtering）: 投機的な問題、偽陽性、「理論上は問題だが実際には起こりえない」ケースを除去する
コーディネーターはこの分析をもとに、MRの状態を5つのカテゴリで評価する：
| MRの状態 | コーディネーターのアクション |
|---|---|
| 全指摘がsuggestionまたはそれ以下 | Approve（承認） |
| suggestionレベルのみ存在 | Approve with comments（コメント付き承認） |
| warningが存在するが本番リスクなし | Approve with comments（コメント付き承認） |
| 複数のwarningがリスクパターンを形成 | minor_issues（軽微な問題あり） |
| criticalまたは安全リスクあり | Requested changes（マージブロック） |
この承認ルービックが公開・明示されているため、エンジニアはAIの判定の根拠を理解できる。「なぜブロックされたのか」が分からないAIレビューは信頼されない。明確な基準の開示は、人間とAIの協働において不可欠な要素だ。
コーディネーターが「merge blocked」判定を下した場合でも、エンジニアはMRのコメント欄にbreak glassと入力することで強制承認できる緊急回避機能がある。1ヶ月間でこの機能が使用されたのは288件（全MRの0.6%）——AIが過剰にブロックしている問題は起きていない。使用はテレメトリーで記録・追跡される。
（Opus 4.7）" participant Agents as "専門エージェント群
（最大7並列）" participant MR as "MRコメント" Dev->>CI: MR作成 / 新コミット push CI->>Coord: レビュー要求（MR情報） Coord->>Coord: リスクティア判定 Coord->>Agents: 対応するエージェントを並列起動 Agents-->>Coord: XML構造化結果（critical/warning/suggestion） Coord->>Coord: 重複除去・再分類・妥当性フィルタリング Coord->>MR: 統合レビューコメント投稿 alt criticalあり MR-->>Dev: マージブロック Dev-->>MR: break glass（緊急回避） else suggestionのみ MR-->>Dev: コメント付き承認 end
コスト最適化の設計——リスクティア分類、モデル選定、トークン最適化
リスクティア分類でコストを3段階にコントロール
全MRに最高精度のフルレビューを実施すれば費用が爆発する。Cloudflareはこの問題をリスクティア分類で解決した。
| ティア | 変更行数 | 変更ファイル数 | 起動エージェント数 | 平均コスト |
|---|---|---|---|---|
| Trivial（軽微） | ≤10行 | ≤20ファイル | 2 | $0.20 |
| Lite（通常） | ≤100行 | ≤20ファイル | 4 | $0.67 |
| Full（フル） | >100行 or >50ファイル | 制限なし | 7以上 | $1.68 |
ただし、セキュリティセンシティブなファイル（認証ロジック、暗号化処理、アクセス制御など）は変更規模に関わらず常にFullレビューが実行される。1行の変更であっても、セキュリティに関わる変更なら7エージェントが動く。
差分フィルタリングも実装されており、以下はレビュー対象から除外される：
- ロックファイル（
bun.lock、package-lock.json、Cargo.lockなど） - ミニファイ済みアセット（
.min.js、.min.css、.mapファイル） - 生成ファイル（
// @generatedマーカー付き、ただしマイグレーションファイルは除く）
3層のモデル選定——タスク複雑度に応じた最適割り当て
モデルの割り当てはタスクの複雑度に応じて3層に分かれている：
# モデル割り当ての設計（Cloudflare Worker制御）
coordinator:
tier: "top"
models: ["claude-opus-4-7", "gpt-5.4"]
fallback: "claude-opus-4-6"
# 全専門家の結果を統合する最難関タスク
standard_reviewers:
tier: "standard"
reviewers: ["code-quality", "security", "performance"]
models: ["claude-sonnet-4-6", "gpt-5.3-codex"]
fallback: "claude-sonnet-4-5"
# 深い技術理解が必要なレビュー
lightweight_reviewers:
tier: "lightweight"
reviewers: ["documentation", "release", "agents-md"]
models: ["kimi-k2.5"] # Workers AI経由（追加コストなし）
fallback: null
Kimi K2.5をWorkers AI経由で使用するため、軽量レビュワー3種のAPIコストは実質$0——これが$1.19という平均コストを実現するカギの一つだ。ドキュメントレビュワーは月間82億7,500万トークンという最大の入力処理量を誇るが、そのコストは軽微だ。
Cloudflare WorkerとWorkers KVで構成されたControl Planeにより、モデル割り当てはコード変更なしで動的に切り替えられる。プロバイダーの障害が発生した場合、管理画面からの操作でプロバイダーを無効化できる。新モデルのリリースにも即座に対応できる設計だ。
サーキットブレーカーによる耐障害性
LLMとは？2026完全ガイドで解説したように、フロンティアモデルは定期的に更新・変更される。Cloudflareはモデル障害時のフォールバック連鎖を実装している：
"claude-opus-4-7" → "claude-opus-4-6" → null（失敗として処理）
"claude-sonnet-4-6" → "claude-sonnet-4-5" → null（失敗として処理）
重要な設計判断として、リトライ対象は429（レート制限）と503（サービス不可）のみ。認証エラーやコンテキスト超過はリトライしない——無駄なコストを発生させないためだ。コーディネーター自体もホットスワップで別モデルに切り替えられる。
7倍のトークン削減——shared context戦略
最も印象的な最適化の一つが「共有コンテキスト」設計だ。従来の「全エージェントに同じコンテキストを埋め込む」方式と比べ、最大7倍のトークン削減を実現している：
# 差分はper-fileパッチとしてdiff_directoryに書き出す
diff_directory/
├── src_auth_handler.patch # 認証ハンドラーの差分
├── tests_auth_test.patch # テストファイルの差分
└── shared-mr-context.txt # 全エージェントが共有するMRメタデータ
MRのメタデータ（タイトル・説明・変更概要）をshared-mr-context.txtとして一度だけ書き出し、7つの全エージェントが参照する。完全な差分をプロンプトに埋め込む代わりに、diff_directoryにper-fileパッチとして保存し、エージェントが必要なファイルだけを読む設計だ。
この最適化の結果として実現されたのが85.7%のキャッシュヒット率。同一の基本プロンプトが全レビューで共有されるため、プロンプトキャッシュが高効率で動作し、月間5桁（$10,000以上）のコスト削減を実現している。
Bun.spawnとstdin経由の実装
コーディネーターはOpenCodeを子プロセスとしてBun.spawnで起動する。注目すべきは引数の渡し方だ——コマンドライン引数ではなくstdin経由でMR情報を渡している。理由はLinuxのARG_MAX制限：巨大なMRの説明文がコマンドライン引数の上限サイズを超えるケースがあるためだ。
出力はJSONL（JSON Lines）形式でstdoutにストリームされる。完全なJSONドキュメントを一度に出力するのではなく、イベントごとにJSON行を書き出すことで、バッファリングなしにリアルタイム処理できる。大規模なレビューでもメモリ消費を一定に保てる設計だ。
タイムアウト設計
各エージェントには5分（コード品質のみ10分）のタスクタイムアウトが設定され、全体の上限は25分だ。リトライには最低2分が残っている必要があるというバジェット設計で、タイムアウト直前の無駄なリトライを防いでいる。
プロンプトエンジニアリング——「指摘しないこと」の明示が精度を決める
AIコードレビューで最も難しい問題の一つがノイズだ。理論的には正しいが実用的でない指摘、防御的すぎるセキュリティ警告、文脈を無視したパフォーマンス提案——これらがエンジニアの信頼を損なう。
レビュワーが「すべての潜在的な問題を指摘しよう」と最適化されると、偽陽性が増え、エンジニアはすべての指摘を無視するようになる。これはレビューシステムとして完全な失敗だ。
Cloudflareの解決策は、プロンプトに「指摘してはいけないこと（What NOT to Flag）」セクションを明示的に設けることだ。セキュリティレビュワーのプロンプトには以下のような除外ルールが含まれる：
## セキュリティレビュワー：指摘してはいけないこと
- 発生確率が極めて低い前提条件が必要な理論的リスク
- 一次防御が適切な場合の多層防御の提案
- 既存パターンと一致するコード（コードベース全体の変更が必要なケース）
- コードレビューの範囲外の設定・インフラ問題
- すでにフレームワーク・ライブラリが対処している既知の問題
LLMは「何をすべきか」の指示と同等か、それ以上に「何をしてはいけないか」の制約に強く反応する。特に汎用モデルにドメイン特化タスクをさせる際、除外ルールの明示は過剰指摘（偽陽性）を大幅に削減する。Cloudflareのケースでは、このアプローチにより「エンジニアが無視するコメント」の割合が低下した。
プロンプトはビルド時に構築される。エージェント固有のMarkdownファイルと、全エージェント共通のルールが連結されて最終プロンプトが生成される。コーディネーターが唯一「エージェント全員の出力を受け取り統合する」特別な役割を持つ。
プロンプトインジェクション対策
ユーザー制御のコンテンツ（MRの説明文・コミットメッセージ）はプロンプトに直接埋め込まれる。悪意ある開発者が<mr_body>のような境界XMLタグをMR本文に書き込めば、プロンプト構造を破壊できる。これがプロンプトインジェクション攻撃だ。
Cloudflareの対策はシンプルかつ効果的だ：
// プロンプト組み立て前にユーザー入力をサニタイズ
function sanitizeUserContent(content: string): string {
// 境界XMLタグを除去してプロンプトインジェクションを防止
// 例: <mr_body>... や </instructions> などを無害化
return content.replace(
/<\/?(?:mr_body|system|instructions?|context)[^>]*>/gi,
''
);
}
ユーザー入力からシステムプロンプトの構造タグを除去することで、プロンプト境界への注入を防いでいる。GitHub ActionsセキュリティガイドCI/CDセキュリティでも触れているように、CI環境にAIエージェントを組み込む際はこの種の入力検証が不可欠だ。
再レビュー（インクリメンタルレビュー）の仕組み
新コミットがプッシュされた場合、システムは「インクリメンタル再レビュー」を実行する。エージェントには以下の情報が渡される：
- 前回レビューコメントの全文
- 解決済み/未解決のDiffNoteリスト（GitLabのインラインコメント）
- 開発者の返信内容
エージェントへの指示は明確だ：「修正済みの指摘は省略する」「未修正のものは再掲する」「開発者が解決済みとマークしたものは尊重する」。さらに、1MRにつき1件、軽いジョークや質問を許可するルールがある——エンジニアとの対話を完全に機械的にしないための工夫だ。
平均2.7レビュー/MRという数字は、この再レビュー機能が活発に使われていることを示している。修正→再レビュー→修正というフィードバックループが、実際にコードの品質改善に機能していることがうかがえる。
1ヶ月131,246レビューの実績データ分析
2026年3月10日〜4月9日の1ヶ月間に収集されたデータを詳しく見る。
レビュー量と時間
131,246レビュー実行、48,095 MR、5,169リポジトリをカバー
MR1件あたり平均2.7回のレビュー（初回＋再レビュー）が実行されている。
所要時間の分布：
| パーセンタイル | 所要時間 |
|---|---|
| 中央値（P50） | 3分39秒 |
| P90 | 6分27秒 |
| P95 | 7分29秒 |
| P99 | 10分21秒 |
99%のMRが10分21秒以内に完了している。人間のコードレビューが数時間〜数日かかることを考えると、実用的なターンアラウンドタイムだ。
コスト分布の詳細
| パーセンタイル | コスト |
|---|---|
| 中央値（P50） | $0.98 |
| 平均 | $1.19 |
| P90 | $2.36 |
| P95 | $2.93 |
| P99 | $4.45 |
平均が中央値より高いのは、大規模MRが少数存在してコスト分布の右裾が長い（right-skewed）からだ。99%のMRは$4.45以下で完了している。
指摘内訳——計159,103件
コード品質: 74,898件（47%） うちcritical 6,460件
ドキュメント: 26,432件（17%）
パフォーマンス: 14,615件（9%）
コンプライアンス: 9,654件（6%）
AGENTS.md: 6,878件（4%）
セキュリティ: 11,985件（8%） うちcritical 479件（4%）
リリース: 745件（0.5%）
コード品質レビュワーが74,898件（47%）で最多。注目すべきはセキュリティレビュワーで、指摘数は11,985件と少ないが、criticalの割合が4%と全レビュワー中最高だ——セキュリティ問題の重大度が他の問題より高いことを示している。
トークン使用量とコスト構造
月間処理トークン総計: 約1,200億
キャッシュヒット率: 85.7%
推定節約額: 5桁（$10,000以上）/月
コスト内訳:
最上位モデル（Opus 4.7等）: 51.8%
標準モデル（Sonnet 4.6等）: 46.2%
Kimi K2.5 (Workers AI): 0.0%
コーディネーターが最も多くのトークンを出力（10億5,700万トークン/月）する一方、ドキュメントレビュワーが最も多くのトークンを入力として処理（82億7,500万トークン/月）している。ドキュメントレビュワーは大量のコードとコメントを読む必要があるため、入力コストが高い——だからこそKimi K2.5という軽量モデルを割り当てる設計が理にかなっている。
デプロイ方法
GitLab CIへの統合は1行の追記から始まる：
# .gitlab-ci.yml への追加
include:
- component: $CI_SERVER_FQDN/ci/ai/opencode@~latest
リポジトリルートにAGENTS.mdを置けば、チーム固有のコーディング規約・禁止パターン・レビュー優先事項をエージェントに伝えられる。テンプレートURLを指定すれば組織全体にルールを配布できる。
CIだけでなく、
@opencode-reviewer/localプラグインを使えばOpenCodeのTUIで/fullreviewコマンドをローカル実行できる。プッシュ前の最終確認や、CI設定なしの小規模チームでの活用にも対応している。
AIコードレビューが解決できないこと——限界と運用知見
Cloudflareはブログ記事の中でシステムの限界を率直に認めている。この正直な自己評価は、実際に大規模運用した上での知見として重要だ。
4つの本質的な限界
1. アーキテクチャの意図を理解できない
コードの「なぜ」をAIは知らない。「この設計はパフォーマンスのためにトレードオフを取っている」という判断は、設計の文脈を知るエンジニアにしかできない。AIは「このコードは遅い」とは指摘できるが、「それが意図的な選択かどうか」は判断できない。誤った改善提案を生む温床になりうる。
2. クロスシステム影響の検証
下流のサービスやコンシューマーへの影響を確認できない。APIの型変更が別サービスを壊すかどうかを判断するには、依存関係グラフと実行時の動作情報が必要で、静的なコードレビューの範囲を超える。
3. 微妙な並行性バグの検出
競合状態やデッドロックを静的解析で完全に検出することは困難だ。コンテキストスイッチのタイミング依存の問題は、動的解析や形式検証が必要で、コードレビューによるアプローチでは限界がある。
4. コストのスケール問題
500ファイルの大規模リファクタリングを7つのフロンティアモデルでレビューすると費用が大幅に増加する。Fullティアの$1.68は中央値であり、巨大なMRはこれを大きく超える可能性がある。
Cloudflareのシステムも、人間のコードレビューを廃止するものではない。AIが「このコードは動く」と判断しても、「この設計はチームの方針に合っているか」「長期的な保守性はどうか」「他チームへの影響は」の判断は人間が担う。アーキテクチャレベルの意思決定とビジネスロジックの妥当性評価は、今のところAIには任せられない。
運用で明らかになった設計上の知見
Cloudflareの公開情報から、実際の運用で明らかになった設計課題と解決策を整理する：
セッション完了検出の複雑さ: OpenCodeのsession.idleイベントだけでは不十分で、3秒ポーリングと60秒非アクティブ検出を組み合わせてようやく安定した検出を実現した。「エージェントが処理を終えたかどうか」を確実に判定することが、思いのほか難しい問題だった。
構造化ログの必要性: JSONLフォーマットのリアルタイムストリーミングにより、巨大なドキュメントをバッファリングせずに処理できる。単純なJSONでは全レビューを1ファイルに収めようとするためメモリ消費が増大し、大規模運用に耐えられない。
テレメトリーなしではチューニング不可能: break glass使用数（0.6%）・コスト分布・キャッシュヒット率・モデル別のコスト比率といったデータなしに、システムの問題点や改善ポイントを特定することは不可能だ。TrackerClientは2秒タイムアウトでPrometheusメトリクスを非同期に送信し、50エントリを超えるとキューをプルーニングする——信頼性より可観測性を優先した設計だ。
prompt injection対策は後付けでは難しい: ユーザー入力のサニタイズは設計の初期段階から組み込む必要がある。後から追加しようとすると、入力が組み立てられる箇所が多数あり、見落としが生じやすい。
AI自動化ツール完全ガイドで解説したCI/CD自動化と同様、AIコードレビューシステムも「人間のループをどこに組み込むか」が長期的な信頼性の鍵を握る。Cloudflareの設計は、完全な自動化ではなく「AIが下書きし、人間が最終判断する」ループを保っている。
このシステムから学べること
Cloudflareの実装が示す最も重要な設計原則をまとめると：
- 専門化によるノイズ削減: 汎用プロンプトより専門エージェントが精度を上げる
- コスト最適化は分類設計が核心: 全MRを均一に扱わず、リスクに応じた比例コストが持続可能性を生む
- 「指摘しないこと」の明示がユーザー信頼を保つ: 偽陽性の削減はシステムの信頼性維持に不可欠
- Control Planeの分離が運用を楽にする: コード変更なしでモデルを切り替えられる設計は、フロンティアAIの急速な変化に対応できる
- テレメトリーは設計と同格の重要性を持つ: 実績データなしに大規模AIシステムの改善はできない
マルチエージェントシステムの設計を考える際、AIエージェントフレームワーク比較2026で紹介した理論的フレームワークと合わせて、このCloudflareの実装事例は「本番環境で何が機能し、何が難しかったか」を示す貴重な実証データだ。
