Cloudflareは社内ルールをAIに執行させ始めた｜4ヶ月で23万件の違反を検出した「Codex」の仕組み

「コーディング規約を作ったのに、誰も守らない」——多くの開発組織が抱えるこの問題に、Cloudflareが構造的な答えを出しました。

2026年8月4日、Cloudflareは「How Cloudflare enforces engineering standards using AI（CloudflareがAIを使ってエンジニアリング標準を執行する方法）」というブログ記事を公開しました。社内のエンジニアリング標準を AIエージェントが取得・適用できる形に構造化し、コードレビュー・設計レビュー・インシデントレポートの3箇所でAIに執行させる、という取り組みの報告です。

数字が具体的です。AIコードレビュアーは4ヶ月で約23万件の標準違反を検出し、そのうち約1.6万件はマージ（コードの取り込み）自体をブロックしました。設計文書のレビューは600件近く、インシデントレポートの評価は200件超。「AIにルールを守らせる」ではなく「AIでルールを守らせる」を、実運用の規模でやり切った事例です。

この記事では、Cloudflareが何を作り、どう動かし、何を学んだのかを整理したうえで、自社の開発組織に応用できる設計原則を抽出します。

紛らわしい点を先に：この仕組みの名前は「Cloudflare Codex」ですが、OpenAIのコーディングエージェント「Codex」とはまったくの別物です。Cloudflareのそれは製品ではなく、社内エンジニアリング標準を束ねた文書群の名前です。

出発点：ガイダンスがあちこちに散らばっていた

Cloudflareが最初に直面していたのは、どの組織にも心当たりのある状態です。

記事によると、開発者向けのガイダンスは「公式ドキュメント、リポジトリ内のファイル、チャットのスレッド、そして個々のエンジニアの頭の中」に散在していました。エンジニアはガイダンスを探すことに時間を使い、しかも見つけたものが今も有効なのか、自分のケースに当てはまるのかの保証がない。チームメンバーが異動すれば、その人が持っていた知識は失われる。組織が拡大するほど、プロジェクト間の不整合は広がっていきました。

ここまでは、よくある「ドキュメント整備をがんばろう」という話に見えます。Cloudflareが違ったのは、この問題を 「人間が読む文書」の整備ではなく「AIエージェントが取得して適用できる標準」の整備として解いた点です。

Codex：RFC形式で書かれ、所有者が管理する標準文書群

まず土台となるのが「Codex」と呼ばれる標準文書群です。

繰り返しになりますが、これはOpenAIのAIコーディングエージェント「Codex」とは何の関係もありません。AI製品でもツールでもなく、Cloudflareが社内のエンジニアリング標準に付けた名前——「規約集」「法典」を意味する英単語 codex そのままの命名です。実体はGitで管理された文書群であり、AIはこれを「読む側」です。

そのうえで、この文書群のポイントは3つあります。

1. RFC形式と「SHOULD / MUST」の使い分け

各標準はRFC（Request for Comments）形式で書かれ、RFC 2119のキーワード——「SHOULD（すべき）」と「MUST（しなければならない）」——で要求の強さを区別します。

これは些細な文体の話ではありません。後述するとおり、この2段階がそのままAIの挙動（勧告で済ませるか、ブロックするか）に接続されるためです。「なるべく守ってほしいこと」と「絶対に守らせること」を書き分けておくことが、自動執行の前提条件になっています。

2. ドメインオーナーによる統治

Codexはドメイン（フロントエンド、コントロールプレーン、セキュリティ、信頼性、TypeScript、Rustなど）に分割され、各ドメインにコンテンツの品質へ責任を持つオーナーが置かれています。

RFCの提案は、該当分野の知見を持つ社員なら誰でもマージリクエストで出せます。提案は段階的に広がるレビュアー群からのフィードバックを複数ラウンド受け、最終的にドメインオーナーが承認して公開されます。記事の時点で60本以上のRFCが存在し、増え続けているとのことです。

3. 「approved」と「enforced」の2段階ライフサイクル

RFCには「approved（承認済み）」と「enforced（執行中）」という2つの状態があります。

新しいRFCがいきなり全プロジェクトをブロックし始めたら、現場は反発します。この2段階は、チームが新しい要求を吸収する時間を与え、執行側の準備が整っていないケースにも対応するための緩衝です。ルールの内容と、ルールの執行強度を、別々に管理できるようになっています。

標準を「AIが引ける形」に変換する

ここがこの取り組みの技術的な核心です。

60本以上のRFC全文をそのままLLM（大規模言語モデル）に食わせる、という素朴なやり方をCloudflareは採りませんでした。記事は理由を明確に述べています。全文投入はコンテキストウィンドウ（AIが一度に扱える情報量）に大きな負荷をかけ、LLMの出力品質を悪化させるからです。

代わりに、専用のエージェントがRFCからSHOULD文とMUST文だけを自動抽出し、メタデータ付きのJSONに構造化します。各ステートメントはおおよそ次の情報を持ちます。

たとえばRFC 14（コントロールプレーンサービス）には、use-quicksilver-for-edge-configuration-propagation というslugで「システムや顧客の設定をエッジへ伝播する必要がある場合はQuicksilver（Cloudflare社内の設定配信システム）を使うこと（SHOULD）」といったステートメントが入っています。

この形式は最初からあったわけではなく、当初は簡素なMarkdownファイルだったものを、エージェントの絞り込みに使いやすいリッチな構造化形式へ進化させたと記事は述べています。狙いは「lazy discovery and progressive disclosure（遅延発見と段階的開示）」——エージェントはまず軽量なステートメント一覧で関係する標準を特定し、追加の文脈が必要なときだけRFC本文を読みに行く、という2段階の読み方です。

今後はステートメントにSDLC（ソフトウェア開発ライフサイクル）のどの段階——設計・実装・実行時——に関わるかを示すメタデータも付与する計画とのことです。

執行の現場①：AIコードレビュアー——23万件の検出と1.6万件のブロック

構造化された標準を最初に執行したのが、マージリクエストを評価するAIコードレビュアーです。

動きはこうです。レビュアーはマージリクエストを複数の観点で評価し、その一つがCodex準拠です。関係するRFCのステートメント群を取得・解析し、必要になった場合のみRFC本文を追加で読み込みます。そして先述のルールに従い、approvedなRFCの違反は勧告、enforcedなRFCのMUST違反はマージのブロックとして扱います。

結果が冒頭の数字です。

• 4ヶ月で約23万件の違反を検出
• うち約1.6万件がマージのブロック（enforcedなRFCのMUST要求からの逸脱）

速度への不満と、3層の対応

ただし、順風満帆ではありませんでした。このレビュアーはコーディネーター（調整役）フレームワークとサブエージェント実行の構成のため、1回の実行に数分かかります。エンジニアからはこの待ち時間に不満が出ました。

Cloudflareの対応は、AIを速くすることではなく、検査を階層化することでした。

機械的にチェックできるものはリンターに落とし、AIは文脈の理解が必要な判断だけに使う。「AIで全部やる」のではなく、決定論的なツールとAIの分担線を引き直したわけです。なお記事によると、oxlintを開発するVoidZeroチームは最近Cloudflareが買収しています。

執行の現場②：設計レビュアー——コードになる前に標準を当てる

コードレビューは効果的ですが、実装まで進んでから設計の問題を指摘するのは手戻りが大きい。そこでCloudflareは同じパターンを設計文書（スペック）のレビューへ広げました。

このレビュアーはCloudflare自身の開発者プラットフォーム上のWorkerとして動作します。結果はD1（データベース）に保存し、モデルへのリクエストはAI Gateway経由でルーティングし、Cron Triggerで定期スキャンする——自社製品で自社の開発プロセスを監査する構成です。

設計レビューに合わせた調整も入っています。Codex全体ではなく設計に関係するドメインだけに絞り込み、言語機能や実装寄りのRFCは除外。検出した問題にはSHOULD/MUSTを加味した重大度を付け、アーキテクチャ上の助言も添えます。レビューが終わると、スペック文書に専用ダッシュボードへのリンク付きのノートが残ります。

実績は、2026年5月時点までに600件近いユニークな設計文書をレビューし、レビュー実行は3,200回超。検出結果の内訳は**major（重大）65%、minor（軽微）29%、critical（致命的）6%**でした。

執行の現場③：インシデントレポートレビュアー——「振り返りの品質」まで標準化

3つ目の適用先が意外な場所です。障害対応後のインシデントレポート（振り返り文書)。

このレビュアーは設計レビュアーと同じ開発者プラットフォーム構成で動き、レポートの記載漏れチェックに加えて、**専用のCodex RFCに照らして「何が起きたかを明確に説明しているか」「要因を特定しているか」「解決策を記録しているか」「意味のある再発防止アクションを提案しているか」**を評価します。

運用も踏み込んでいます。重大度の高いインシデントではこのレビューが中央レビュープロセスの必須工程であり、すべての指摘に対応するまでレポートは完了扱いになりません。2026年5月以降で200件超のレポートを評価し、影響の小さい社内インシデントを中心に記載の抜けを特定してきたとのことです。

障害の再発防止は「レポートを書く文化」だけでは担保できず、レポートの品質そのものを標準化・検査対象にする——ここまで含めて「標準の執行」だという思想が読み取れます。

この事例から抽出できる4つの設計原則

Cloudflare規模の組織でなくても、この取り組みから持ち帰れるものは多いはずです。AIコーディングエージェント（Claude CodeやCursorなど）を開発に導入している組織なら、なおさらです。

原則1：ルールは「人間が読む文書」と「AIが引くデータ」の二層で持つ

多くのチームはすでにCLAUDE.mdや.cursorrulesのようなルールファイルをAIに読ませる運用を始めています。Cloudflareの事例はその発展形を示しています。ルール全文を毎回コンテキストに流し込むのではなく、要求文を安定IDつきの構造化データに抽出し、エージェントが必要な分だけ引く。ルールが数十本規模に育ったとき、この差は出力品質に直結します。

原則2：「すべき」と「しなければならない」を書き分ける

SHOULD/MUSTの区別は、自動執行の要です。全部を「必須」と書けばブロックだらけで運用が破綻し、全部を「推奨」と書けば誰も守りません。機械が執行強度を判断できる粒度でルールを書く——これはAI以前の規約作りでは曖昧なままでも回っていた部分です。

原則3：執行はいきなり100%にしない

approved（勧告のみ）→ enforced（ブロック）の2段階ライフサイクルは、そのまま真似できる運用です。新ルールはまず「警告として出るだけ」の期間を置き、チームが適応してから昇格させる。ルールの正しさと、執行のタイミングを分離することで、現場の反発を構造的に減らせます。

原則4：AIとリンターの分担線を引く

Cloudflareのエンジニアが数分のAIレビューに不満を持ち、会社が機械判定可能な部分をリンター（ミリ秒）へ移した流れは示唆的です。決定論的に判定できるものにLLMを使うのは、遅くて高くて不安定。AIは文脈理解が必要な判断に限定し、それ以外は従来のツールに任せる、という切り分けは導入初期から意識する価値があります。

今後の方向と、残る論点

Cloudflareは今後について、エージェントをSDLCの各段階へ広げること、検出だけでなく修正案の自動提案（次第に自律性を高めながら）、そしてCodex自体をエンジニアリング以外——プロダクト、セキュリティ、コンプライアンス、トラスト&セーフティ——へ拡張することを挙げています。

一方で、記事の数字を鵜呑みにする前に押さえておきたい点もあります。

• 23万件の検出のうち、どれだけが妥当な指摘だったか（誤検知率）は公開されていません。ブロックされた1.6万件のマージがその後どう処理されたか（修正されたか、ルール側が直されたか）も不明です
• 検出結果の重大度分布（major 65%など）はAIレビュアー自身の評価であり、人間による検証結果ではありません
• この仕組みが成立する前提として、RFCを書き、レビューし、所有する人間の統治プロセスが存在します。ルール文書の整備なしにAI執行だけを導入することはできません

記事自身も、思想としては「AIが最も役立つのは、適切なガイダンスを、作業しているその場所に届けるとき」と述べています。AIを警察にするのではなく、標準を「探しに行くもの」から「向こうからやって来るもの」に変える——そこに主眼があります。

まとめ

• Cloudflareは2026年8月4日、社内エンジニアリング標準「Codex」をAIエージェントに執行させる取り組みを公開した。CodexはRFC形式・SHOULD/MUST区分・ドメインオーナー統治の標準文書群で、60本以上が存在する
• RFC全文をLLMに投入せず、要求文を安定ID付きJSONへ抽出し、エージェントが必要な分だけ段階的に読む設計を採った
• AIコードレビュアーは4ヶ月で約23万件の違反を検出し、約1.6万件のマージをブロック。速度への不満には、機械判定可能な部分をoxlintベースのリンター（ミリ秒）とローカルCLIへ分離して応えた
• 同じパターンを**設計文書レビュー（600件近く・3,200回超）とインシデントレポート評価（200件超）**へ展開。重大インシデントでは指摘への対応完了がレポート完了の条件になっている
• 応用可能な原則は4つ——ルールの二層化（人間用文書＋AI用構造化データ）、SHOULD/MUSTの書き分け、勧告→ブロックの段階執行、AIとリンターの分担
• ただし誤検知率などの検証データは未公開であり、前提として人間によるルール統治プロセスが必要である点は割り引いて読む必要がある

参考にした一次情報

• How Cloudflare enforces engineering standards using AI（Cloudflare Blog, 2026-08-04）: https://blog.cloudflare.com/engineering-standards-enforcement/

CSエージェントで顧客対応を自動化しませんか？

デモ・無料相談・資料請求を承っています。

デモをみる無料相談する資料請求する