Cloudflare のエンジニアリング標準化：統一「ルールベース」を Codex で監督、4ヶ月で1.6万件のコードマージを阻止
- Cloudflare はドキュメントやチャット履歴、古参社員の頭の中に散らばっていたエンジニアリング標準を、エージェントが直接読める構造化データに刷新。
- この4ヶ月で、AIコードレビューアは約25万件の違反を指摘し、1.6万件のマージを阻止。別のエージェントは開発着手前に約600件の設計ドキュメントをレビューした。
- 注目は2段階スイッチ。承認されただけでは通知のみで、実際にブロックするには明示的な昇格操作がもう一度必要。
- 60以上の標準を全てモデルに与えるとコンテキストが肥大化するため、専用エージェントがルールをJSONに圧縮して対応。
Codex 導入前、Cloudflare のエンジニアリング標準は4つの場所に分散
Cloudflare は8月4日、エンジニアリング標準をAIで運用する取り組みについての振り返り記事を公開しました。この4ヶ月で、同社のAIコードレビューアは約25万件の違反を指摘し、1.6万件のコードマージを阻止。もう1つのエージェントは開発着手前に約600件の技術設計をレビューしています。この記事の価値は、ドキュメント内のルールがどうマージ時に実際の関門となるか、そのプロセス全体を詳述している点です。その中には、すぐに真似できる設計があります。ルール承認後はまず通知のみ、実際にブロックするには再度の明示的な昇格が必要という仕組みです。
まず、Codex がなかった頃の状況を見てみましょう。開発ガイドラインは、正式なドキュメント、リポジトリ内のファイル、チャット履歴、そしてエンジニア個人の頭の中にある経験、という4つの場所に分散していました。
ここには2種類の異なる問題がありました。
エンジニアは本来の問題解決より、ルール探しに時間を費やしていました。
答えを見つけても、最新か、権威があるか、今の状況に適用できるかは判断できません。
組織が大きくなると限界が来ます。影響は3つ。全標準を読めるエンジニアはいません。レビューアも各要件を確実に照合できません。チーム移動で経験は失われます。ルールが継続的に注意喚起・強制されないと、プロジェクト間の進め方はバラバラになり、ドリフトが発生します。同じルールのもとでも、実践が徐々に乖離していくのです。
Codex はドメインごとに分割され、各ドメインにオーナーがいる
Codex は、ガバナンスが行き届いたエンジニアリング標準の集合体であり、エージェントが必要に応じて取り出し、目の前のタスクに適用できます。同じ標準がコードレビュー、技術設計レビュー、障害報告レビューなど、さまざまな場面で同時に使えるようになりました。
Codex はドメインごとに区分され、各ドメインが1つのエンジニアリング領域をカバーします。アーキテクチャ関連（フロントエンド、コントロールプレーンなど）、横断的領域（セキュリティ、信頼性）、特定言語（TypeScript、Rust）、その他多数です。各ドメインにはドメインオーナーが1人おり、そのドメインのドキュメントの内容、一貫性、全体的な品質に責任を持ちます。
ルールの書き方：RFC形式、SHOULD と MUST で重要度を区別
Codex の標準は RFC 形式で記述されます。RFC はインターネット標準の世界で使われる記法です。提案が公開され意見を募り、複数回の改訂を経て、最終的に合意されたものとして採用されます。
要件には、SHOULD と MUST の2つのキーワードのみを使用します。定義は実際に存在するインターネット標準文書 RFC 2119 に直接従い、技術標準におけるこれらの言葉の厳密な意味を定義しています。
MUST は絶対に守るべき必須要件です。SHOULD は通常守るべき推奨要件ですが、特定の状況下で、結果を完全に理解し比較考量した上で守らないことも許されます。後述しますが、この2つの言葉の違いが、エージェントが提案をするのか、コードをブロックするのかを直接左右します。
文書の先頭には front matter も必要です。どのドメインに属するか、現在の状態は何かを示す、機械が読むための小さなセクションです。
誰がルールを提案できるのか？興味があり、その分野に能力のある Cloudflare 社員であれば誰でも、所定の構造に従ってマージリクエストを提出できます。提案は複数回のフィードバックを経てレビューアが増え、最終的にドメインオーナーが承認して初めて Codex に取り込まれ、Astro 製の社内サイトに公開されます。
標準が提案からコードマージをブロックするまでの5つのステップ
ルールが書かれただけではブロックできません。提案から実際にブロックするまでには5つのステップがあります。
Cloudflare 公式ワークフロー図。左から右へ5段階：執筆、自動チェック、ガバナンス、承認済み、強制。図の副題はこの設計の要点を示しており、「RFC とその機械可読ルールは同じレビュープロセスを経る」。出典：blog.cloudflare.com。