8月4日、Cloudflareが「How Cloudflare enforces engineering standards using AI」と題した記事を公開した。過去4ヶ月間で約23万件のエンジニアリング標準違反を検出し、1万6000件のマージリクエストをブロック——この数字が、同社がAIエージェントを活用して社内エンジニアリング標準を自動適用する仕組み「Cloudflare Codex」の実績を端的に示している。本記事では、その設計思想から3つのエージェントの実装詳細まで解説する。
なお、「Codex」という名称はOpenAIが開発したコード生成モデル「OpenAI Codex」と同名だが、ここで紹介するCloudflare Codexはまったく別のシステムであり、社内エンジニアリング標準を一元管理・自動適用するための独自の仕組みだ。
4ヶ月で23万件の違反を検出、1万6000件のマージをブロック
Cloudflareは過去4ヶ月間で、約23万件のエンジニアリング標準違反を検出し、1万6000件のマージリクエストをブロックした。さらに、技術設計レビューエージェントは600近くの設計ドキュメントを実装開始前に評価している。これらすべてのシステムが参照する共通の知識源が「Cloudflare Codex」だ。
Codex以前、Cloudflareの開発者ガイダンスは公式ドキュメント、リポジトリファイル、チャットスレッド、個々のエンジニアの経験知識など複数の場所に散在していた。エンジニアは問題解決よりもガイダンス探索に時間を費やし、見つけた情報が最新・権威あるものかどうかも判断しづらかった。組織が拡大するにつれ、チーム間でのナレッジ共有はさらに難しくなった。
Codexはこの問題に対し、「人間とエージェントの両方が参照できる一元管理された標準集」として設計された。
Codexの構造：RFC形式で管理される標準集
Codexはエンジニアリング領域ごとにドメインに分割されている。フロントエンド、コントロールプレーン、セキュリティ、信頼性、TypeScript、Rustなどが対象だ。各ドメインにはオーナーが存在し、ドキュメントの品質と一貫性に責任を持つ。
標準の記述形式は**RFC 2119で定義されたSHOULDとMUSTキーワード**を使ったRFC形式を採用している。任意のCloudflare社員が提案を出せるが、段階的なレビューを経てドメインオーナーが最終承認したものだけがCodexに組み込まれ、Astro製の社内サイトに公開される。
承認済みRFCは即座にエージェントによる違反検出の対象となるが、マージのブロックは「approved」から「enforced」に明示的に昇格したRFCのMUST要件のみに限られる。この2段階の仕組みにより、チームが新しい要件を吸収する時間が確保される。
LLMへの入力はコンパクト化されたJSON
60本以上に増えたRFCをそのままLLMのコンテキストウィンドウに流し込むことは現実的でない。そこでCloudflareは専用エージェントを用意し、SHOULDとMUSTの文を以下のようなJSON構造に抽出・圧縮している。
{
"rfc": 14,
"title": "Control Plane Services",
"status": "approved",
"domain": "control-plane",
"statements": [
{
"slug": "use-quicksilver-for-edge-configuration-propagation",
"section": ["Proposal", "Infrastructure"],
"level": "SHOULD",
"text": "If you need to propagate system or customer configuration to the edge, use Quicksilver via the outbox pattern",
"href": "/rfcs/014-control-plane-services/#infrastructure"
},
{
"slug": "api-schemas-must-be-documented-in-openapi-spec",
"section": ["Proposal", "API Gateway"],
"level": "MUST",
"text": "API request and response schemas MUST be documented using an OpenAPI spec",
"href": "/rfcs/014-control-plane-services/#api-gateway"
}
]
}
各ステートメントには安定したslug識別子が付与され、RFC更新時も変わらない。これにより違反の追跡、分析、例外処理が横断的に行える。当初はMarkdownへの抽出だったが、エージェントがより正確にフィルタリングできるよう構造化JSONに移行した経緯がある。
3つのCodexエージェントの実装
AIコードレビュアー
マージリクエストをCodex準拠の観点で評価するエージェント。通常数分でレビューが完了するが、CIのラウンドトリップが遅いという開発者の声を受け、2つの補完手段も用意した。
- カスタムリンター設定パッケージ：機械的に検証できるルールはリンターで対応し、ミリ秒単位でフィードバックを返す。TypeScriptでは最近Cloudflareに参加したVoidZeroチームが開発したoxlintを採用。Rust向けリンターも開発中で、Goも後続予定。
- CLIによるローカル実行：OpenCodeベースのエージェントをCI外でローカル実行可能にし、差分セットを自動判定してターミナルに結果を出力する。
スペックレビュアー
実装開始前の設計ドキュメント・技術仕様書を対象に、アーキテクチャの問題を事前に検出するエージェント。Cloudflare Worker上で動作し、D1で結果を保存、AI Gatewayでモデルリクエストをルーティング、Cron Triggerで新規スペックをスキャンするという構成で、Cloudflare自身のDeveloper Platformのプロダクト群で完結しているのが特徴だ。
2026年5月以降、600近くのスペックをレビューし、3,200回以上の実行を記録。検出された問題の重要度内訳は「major」が**65%、「minor」が29%、「critical」が6%**だった。ここで言う「critical」は即時の修正対応が求められる深刻な設計上の欠陥を指し、「major」はリリース前に対処すべき重大な問題、「minor」は改善推奨の軽微な指摘に相当する。検出全体の約6割以上がmajor以上の深刻度に分類されており、設計段階での早期検出が相当量の手戻りを防いでいると見られる。
インシデントレポートレビュアー
ポストモーテム（障害報告書）を評価するエージェント。報告書の完全性に加え、原因の明確な説明、対応策の記録、再発防止アクションの提案が含まれているかをCodexのRFCに基づいてチェックする。スペックレビュアーと同じアーキテクチャを共有しており、高重度インシデントについては全指摘事項への対応が完了するまで報告書を「完了」とみなさない運用になっている。
今後の展開
Cloudflareは今後、ソフトウェア開発ライフサイクル（SDLC）全体にわたってCodexエージェントを拡張する計画だ。長期的にはエージェントが違反を検出するだけでなく修正案も自律的に提案し、エンジニアがそれをレビュー・承認するモデルを目指している。
また、対象領域もエンジニアリングを超えて拡大しており、プロダクト、セキュリティ、コンプライアンス、トラスト＆セーフティの各チームも自チームの標準をCodexに追加し始めているという。
詳細はHow Cloudflare enforces engineering standards using AIを参照していただきたい。
