Cloudflare のブログに掲載され、同社の Agents Week 2026 の一環としてタグ付けされたこの記事は、Cloudflare が社内の AI コードレビューシステムをどのように構築したかを説明している。記事によれば、既製の AI レビューツールは Cloudflare ほどの規模の組織には柔軟性が足りず、生の diff を単一のプロンプトに流し込むとノイズの多い出力 — 曖昧な提案や、ハルシネーションによる存在しない構文エラー — が生じた。そこでチームは、オープンソースのコーディングエージェントである OpenCode を中心に CI ネイティブなオーケストレーションシステムを構築した。このシステムでは、各マージリクエストがまず最大 7 つの専門レビュアーエージェントによるレビューを受ける。対象はセキュリティ、パフォーマンス、コード品質、ドキュメント、リリース管理、AGENTS.md の保守、そして Cloudflare 社内の Engineering Codex への準拠である。コーディネーターエージェントがそれらの指摘の重複を取り除き、深刻度を判断して、構造化されたレビューコメントを 1 件投稿する。コーディネーターはマージを承認する、コメントする、ブロックする、のいずれも行える。
記事の大半は、CI/CD パイプラインのクリティカルパス上で LLM を運用することについてのエンジニアリング上の記録である。プラグインアーキテクチャ、OpenCode をプログラムから駆動する方法、専門エージェント向けのプロンプト設計、リスクに基づく階層分け、並行処理、プロバイダー障害への耐性、設定のコントロールプレーン、増分の再レビュー、そしてシステム稼働最初の 1 か月の数値が扱われている。これは一般的な手法ではなく一企業の社内システムについての当事者による記録であり、専門サブエージェント群をコーディネーターが統括する形で組織された エージェント型コードレビュー の一例である。
要点
- システムは組み合わせ可能なプラグインアーキテクチャの上に構築されている。プラグインは制御されたコンテキスト API を通じてレビューに寄与し — エージェント、プロバイダー、プロンプトのセクション、権限を登録する — コアのアセンブラーがその結果を OpenCode が読み込む設定ファイルへとマージする。記事によれば、これにより VCS 固有の関心事と AI プロバイダー固有の関心事が互いに分離される。
- 記事は OpenCode を選んだ理由として、チームがすでに使っていたこと、オープンソースであること（Cloudflare のエンジニアが 45 件を超えるプルリクエストをアップストリームにマージさせたと報告している）、そして何より、サーバーファーストの構造になっていることを挙げている。これによりチームは、CLI をスクリプトで操作するのではなく、SDK を通じてセッションを作成し、プロンプトを送り、並行するセッションから結果を回収できた。
- コーディネーターは OpenCode の子プロセスとして動作し、カーネルの引数長制限を避けるためにプロンプトは標準入力（stdin）で渡され、出力は JSON Lines として読み取られる。ランタイムプラグインがコーディネーターに
spawn_reviewersツールを与え、このツールが各専門エージェントをそれぞれ独立した OpenCode セッションで起動する。 - 記事は、プロンプトエンジニアリングの真の価値は、モデルに何を指摘しないかを伝えるところにあると論じている。たとえばセキュリティレビュアーには、悪用可能な問題や具体的に危険な問題だけを報告し、理論上のリスクや多層防御の提案は省くよう指示している。指摘は critical、warning、suggestion のいずれかの深刻度で構造化される。
- モデルはタスクの難易度に応じて割り当てられる — コーディネーターには最上位ティアのモデル、コード品質・セキュリティ・パフォーマンスには標準ティアのモデル、テキスト中心のレビュアーにはより軽量なモデル — そして各割り当ては設定用の Worker から実行時に上書きできる。記事によれば、これによって実行中のジョブ全体で、あるプロバイダーを丸ごと数秒以内に無効化できる。
- 各マージリクエストは、diff の大きさとセキュリティ上センシティブなパスに触れているかどうかによって、trivial、lite、full のいずれかのリスク階層に分類され、階層ごとに実行されるエージェントの数が異なる。まずロックファイル、ベンダリングされたアセットやミニファイされたアセット、生成ファイルが除外されるが、データベースのマイグレーションは生成ファイルのフィルターの対象外とされている。
spawn_reviewersツールは小さなスケジューラーとして機能し、タスクごとのタイムアウトと全体のタイムアウト、無応答の検知、Netflix の Hystrix をモデルにしたモデルティアごとのサーキットブレーカー、そして同じファミリー内の一世代前のモデルへと切り替えるフェイルバックチェーンを備える。フェイルバックが発動するのはリトライ可能な API エラーの場合だけである。- diff は各プロンプトに埋め込まれるのではなく、ファイルごとのパッチファイルと共有コンテキストファイルに書き出される。記事によれば、これにより並行するレビュアーの間でトークンコストが何倍にも膨らむことが避けられ、報告されている 85.7% というキャッシュヒット率にも寄与している。
- 人間が「break glass」とコメントすると承認を強制できる。再レビューは増分で行われ、前回の指摘とその解決状況を受け取ったうえで、それに応じてスレッドを解決済みにするか残すかを決める。
- 専用の AGENTS.md レビュアーは、テストフレームワークやパッケージマネージャーの切り替えのような重要なアーキテクチャ上の変更を行いながら、リポジトリの AGENTS.md（AGENTS.md を参照）を更新していないマージリクエストを指摘し、また水増しの内容や長すぎるファイルにはペナルティを与える。
- 最初の 30 日間について、記事は 5,169 のリポジトリにわたる 48,095 件のマージリクエストで 131,246 回のレビュー実行、レビュー時間の中央値 3 分 39 秒、レビューあたり約 1.2 件の指摘、そしてマージリクエストの 0.6% で「break glass」が使われたことを報告している — いずれも Cloudflare 自身のテレメトリーに基づく自己申告の数値である。
背景
記事は、このシステムが現在のモデルでは人間によるコードレビューの代わりにはならないと明言している。AI レビュアーが苦手とする領域として、アーキテクチャの把握、変更された API コントラクトの下流の利用者のようなシステムをまたぐ影響、微妙な並行性のバグ、そして diff の大きさに応じて増えるコストを挙げている。記事はこの取り組みを Cloudflare のより広範なエンジニアリングのレジリエンス向上の取り組みの一部として位置づけており、記事が報告する設計上の選択 — 承認への強い偏り、手動での上書き、そしてレビューあたりの指摘を意図的に少なくすること — は、自動レビュアーがエンジニアの妨げにならないようにするための、一組織としての答えである。