Cloudflare Codexとは​何か​ ──社内ルールを​AIに​守らせ、​4か月で​23万件を​指摘・1.6万件の​マージを​止めた​仕組みを​解説

2026年8月4日、Cloudflareが「社内の技術ルールをAIに守らせる仕組み」の運用実績を公開した^[1]。4か月で約23万件の違反をAIが指摘し、うち約1.6万件では承認を出さず、重大なものはマージ（書いたコードを製品に取り込む操作）そのものを止めている。実装前の設計書レビューも、約600件がAIの審査を通った。

結論から言うと、この発表の面白さは「AIにレビューをさせた」ことではない。ルールをAIが読める形に書き直したことと、指摘するだけの期間と、止める期間を分けたことにある。どちらも、AIの性能とは関係のない設計の話だ。

この記事では、①何が起きたのか（数字と、その正確な意味）②なぜ社内ルールは守られないのか ③Cloudflareがルールをどう書き直したか ④60本を超えるルールをAIに渡すときの工夫 ⑤3つの使い手と「重い判定・軽い判定」の分け方 ⑥真似できるところ／できないところ、の順に見ていく。内容はすべて公式発表に基づくもので、電脳技巧集団（CAG）自身が検証したものではない。

先に2つ断っておきたい。ひとつ、ここで言う「Codex」は、OpenAIのコーディングAI「Codex」とは別物だ。Cloudflareが自社の技術標準に付けた名前である。ふたつ、これはCloudflareの社内システムであって、買える製品ではない。だから読みどころは機能ではなく、仕組みの側にある。

関連記事 ｜ OpenAI Codex（コーディングAI）側の話はこちら「良いプロンプト」の次は、「良いループ」だった ──Codex・Claude Code・GitHub・Grokが向かう、AI開発の新しい主戦場 →

01 4か月で​23万件 ──まず​何が​起きたのか

公開された数字を、原文の表現に沿って並べる^[1]。

項目	実績	期間
AIコードレビューが指摘した標準違反	約230,000件	直近4か月
うち承認保留・マージ停止に至った件数	約16,000件	同上
AIが審査した設計書（仕様書）	約600件	2026年5月〜
設計書レビューの実行回数（再実行含む）	3,200回超	同上
AIが審査した障害報告書	200件超	2026年5月〜

ここで押さえたいのは、16,000件が「機械が自分の判断で止めた」数字だということだ。人間のレビュアーが見落としたかもしれない箇所で、AIが「これは必須要件に反している」と判断し、承認を出さなかった。

設計書レビューの内訳も公開されている。指摘の重大度はmajor 65%／minor 29%／critical 6%。criticalが少ないのは健全で、裏を返せば「実装が始まる前に潰せる中規模の設計ミスが、これだけ埋まっていた」ということになる。

障害報告書のレビューでは、フォローアップ項目の欠落・時系列の不備・検知シグナルの記載漏れが見つかっている。なお、審査された報告書の93%は影響の小さい障害・社内限定・予防的な宣言によるものだったと明記されている。重大障害の報告書については、AIの指摘がすべて解消されるまで「完了」と見なさない運用になっている。

02 なぜ社内ルールは​守られないのか

Cloudflareが挙げている「Codex以前」の状態は、会社の規模を問わず、たいていの組織に当てはまる^[1]。

• 開発の指針があちこちに散らばっていた——正式なドキュメント、リポジトリの中のファイル、チャットのスレッド、そして個々のエンジニアの頭の中
• 探すのに時間がかかり、見つけても最新か・正式なものか・自分の状況に当てはまるのか判断できない
• 会社が大きくなると誰も全部は読めず、レビュアーもすべての要件を確認しきれない
• 人が異動すると知識が失われ、プロジェクト間でやり方がずれていく

これは「ルールを作っていない」問題ではない。ルールはあるのに、必要な瞬間に手元へ出てこない問題だ。だから研修を増やしても、ドキュメントを整えても、現場では同じ逸脱が繰り返される。

Cloudflareの答えは、ルールを「人が探しに行くもの」から「作業している場所にAIが持ってくるもの」へ作り替えることだった。

03 Codexの​正体 ──RFCと、​MUST／SHOULD

Cloudflare Codexは、統治された技術標準の集合である。組織の作り方が具体的で、ここがこの発表の芯にあたる^[1]。

ドメインに分けて、責任者を置く。 アーキテクチャ（フロントエンド、コントロールプレーン）、横断的な関心事（セキュリティ、信頼性）、言語別（TypeScript、Rust）などの領域に分割し、各ドメインに責任者を1人置く。その領域の内容・一貫性・品質に責任を持つ役割だ。

書式はRFC、要件はMUSTとSHOULDで書く。 インターネットの技術仕様で使われている書き方（RFC 2119^[3]）をそのまま社内に持ち込み、「必ず守る（MUST）」と「そうすべき（SHOULD）」を明確に分ける。加えて、どのドメインのものか、いまどの状態かといった情報を、文書の先頭に決まった形で持たせる。

誰でも提案できるが、通すには合議を経る。 関心と知識のある社員なら誰でも、決められた構造に沿ってRFCを提案できる。提案は段階的に広がる査読を通り、最後にドメイン責任者が承認して初めてCodexに入る。承認されたRFCは社内サイトに公開される。

つまりCodexは、置き場ではなく手続きとして設計されている。誰が決めるのか、どう変えるのか、いつから効くのかが決まっている。この前提が、次の「止める／止めない」の設計に効いてくる。

04 approved と​ enforced ──​「指摘だけの​期間」を​挟む

Codexでいちばんよくできているのは、ルールの状態を2段階に分けている点だ^[1]。

approved（承認済み）のあいだ、AIはそのルールに基づいて違反を指摘する。ただし止めない。enforced（強制）に上がると、MUST要件に反していればAIは承認を保留し、重大度によってはマージを止める。

承認から強制への昇格は、明示的な別ステップになっている。理由は2つ挙げられている。チームが新しい要件を吸収する時間を作るためと、強制するには追加の作業が必要な場合があるためだ。

新しいルールを決めた翌日から全員をブロックし始めれば、現場は「ルールのせいで仕事が止まる」と受け取る。かといって指摘のまま放置すれば、いつまでも守られない。指摘期間 → 強制という2段階は、ルールを現場へ着地させるための工夫であって、技術の話ではない。ここは自社の業務ルールにもそのまま流用できる考え方だ。

05 60本の​ルールを、​AIに​丸ごと​渡さない

技術的にいちばん面白いのがここだ。

CloudflareのRFCはすでに60本を超えている。素朴にやるなら、全部まとめてAIに読ませればいい。しかし原文はそれを明確に否定している。分量がコンテキストウィンドウ（AIが一度に読める作業机の広さ）を圧迫し、結果の質を落とすからだ^[1]。

そこで専用のエージェントを走らせ、各RFCから MUST／SHOULD の文だけを抜き出して、構造化データ（JSON）に圧縮している。1文ごとに、どのRFCの何番か、どのセクションか、MUSTかSHOULDか、原文のどこへ飛べばよいかが付く。さらに、必要になったときだけ詳細を読みに行けるようメタ情報が添えられている。

抜き出された1文には安定した識別子が振られ、元のRFCが更新されても変わらない。同じ要件を時間をまたいで追跡できるので、監視も、分析も、例外の管理もできる。

当初はJSONではなく、もっと短いMarkdownに抽出していたという。構造化された形式に移した理由は「エージェントが必要な内容をより正確に絞り込めるようにするため」だ。今後は、設計・実装・運用のどの段階に効く要件かを示す情報も足す計画だと書かれている。

ここには、規模を問わず一般化できる知見がある。AIに大量の規約を守らせたいなら、規約そのものを渡すのではなく、判定できる単位の文に分解してから渡す。 実際、AIコードレビューはふだんこの抽出済みの文だけで判断し、RFC本文の全体を読み込むのは、追加の文脈が必要なときだけにしている。

06 3つの​使い手と、​重い判定・軽い​判定の​分け方

Codexを使っているエージェントは3つある^[1]。

AIコードレビューは、変更内容を複数の観点で評価する。approvedのRFCからの指摘は推奨にとどまり、enforcedのMUST違反は承認保留またはブロックになる。

仕様レビューは、実装が始まる前に設計書をCodexに照らして審査する。設計に関係するドメインだけにCodexを絞り込んでから評価し、結果はダッシュボードにまとまり、設計書の側にはリンク付きのメモが残る。実装後ではなく実装前に、建築上の誤りを捕まえるのが狙いだ。

障害報告レビューは、報告書が揃っているかに加えて、何が起きたか・何が要因か・どう解決したか・意味のある再発防止策が書けているかを評価する。この期待値そのものが、Codexの1本のRFCとして定義されている。

そして、この記事でいちばん実務的な学びが、「重い判定と軽い判定を分けた」という判断だ。

AIコードレビューは1回に数分かかる。エンジニアからは待ち時間と往復の手間について声が上がった。そこでCloudflareは2つ足している。

ひとつは、機械的に判定できる要件をlinterへ落とすこと（linter＝コードの書き方を自動でチェックする道具）。Codexの内容に合わせた設定を配り、ミリ秒で結果を返す。TypeScriptが最初に対応し、Rustは開発中、Goが続く予定だという。もうひとつは、AIレビューを手元でも実行できるようにしたこと。自動検査の工程を待たずに、同じエージェントを自分の環境で走らせられる。

「全部AIに聞く」でも「全部ルールで縛る」でもない。判定できるものは機械に、判断が要るものはAIに。当たり前に見えて、運用の現場ではここが崩れやすい。

07 真似できる​ところ／できない​ところ

冒頭に書いたとおり、Cloudflare Codexは社内システムであって、明日から導入できる製品ではない。持ち帰れるのは仕組みの側になる。

私たち電脳技巧集団（AI職人ギルド）も、規模はまったく違うが同じ形をやっている。プロジェクトごとに前提と規約を書いたファイルを置き、AIエージェントの作法と、過去にハマった罠を1件1ファイルの索引付きで残している。索引だけを常に読ませ、症状が一致したときだけ本文を読ませる——これはCloudflareが言う「必要になったときだけ詳細へ」と同じ発想だ。記事制作の手順そのものも、失敗するたびに手順書へ書き戻している。

その経験から言えるのは、効くのは「ルールを書くこと」ではなく「ルールを守らせる経路を作ること」だという一点だ。読まれない規約は、AIにとっても読まれない。

	ルールを"置く"だけの組織	ルールをAIに"守らせる"組織
置き場所	ドキュメント・チャット・個人の記憶に分散	統治された1か所（責任者つき）
書き方	散文。守るべき度合いが曖昧	1文単位。必須と推奨を明示
適用	レビュアーの記憶と気力に依存	作業している場所にAIが提示
新ルールの導入	周知して終わり（浸透は運）	指摘期間 → 強制、の2段階
変更の追跡	どこが変わったか分からない	1文ごとの安定した識別子で追える
AIへの渡し方	規約を丸ごと投げる	判定できる単位に分解して渡す

自社で始めるなら、この順でいい

• いま口頭で伝えている決まりを5つ、「必ず守る」と「そうすべき」に分けて書く
• AIが読むファイル（プロジェクト直下の規約ファイル等）に置き、作業のたびに読ませる
• しばらくは指摘だけさせる。止めない
• 守れることが分かったものから、止める対象に上げる

Cloudflareが4か月で23万件を積み上げた仕組みも、骨格はこれだけだ。AIに任せられる量は、AIが読める形にした量で決まる。