Codex はドメインごとに分割され、各ドメインにオーナーがいる

Codex は、ガバナンスが行き届いたエンジニアリング標準の集合体であり、エージェントが必要に応じて取り出し、目の前のタスクに適用できます。同じ標準がコードレビュー、技術設計レビュー、障害報告レビューなど、さまざまな場面で同時に使えるようになりました。

Codex はドメインごとに区分され、各ドメインが1つのエンジニアリング領域をカバーします。アーキテクチャ関連（フロントエンド、コントロールプレーンなど）、横断的領域（セキュリティ、信頼性）、特定言語（TypeScript、Rust）、その他多数です。各ドメインにはドメインオーナーが1人おり、そのドメインのドキュメントの内容、一貫性、全体的な品質に責任を持ちます。

ルールの書き方：RFC形式、SHOULD と MUST で重要度を区別

Codex の標準は RFC 形式で記述されます。RFC はインターネット標準の世界で使われる記法です。提案が公開され意見を募り、複数回の改訂を経て、最終的に合意されたものとして採用されます。

要件には、SHOULD と MUST の2つのキーワードのみを使用します。定義は実際に存在するインターネット標準文書 RFC 2119 に直接従い、技術標準におけるこれらの言葉の厳密な意味を定義しています。

文書の先頭には front matter も必要です。どのドメインに属するか、現在の状態は何かを示す、機械が読むための小さなセクションです。

誰がルールを提案できるのか？興味があり、その分野に能力のある Cloudflare 社員であれば誰でも、所定の構造に従ってマージリクエストを提出できます。提案は複数回のフィードバックを経てレビューアが増え、最終的にドメインオーナーが承認して初めて Codex に取り込まれ、Astro 製の社内サイトに公開されます。

標準が提案からコードマージをブロックするまでの5つのステップ

ルールが書かれただけではブロックできません。提案から実際にブロックするまでには5つのステップがあります。

Cloudflare 公式ワークフロー図。左から右へ5段階：執筆、自動チェック、ガバナンス、承認済み、強制。図の副題はこの設計の要点を示しており、「RFC とその機械可読ルールは同じレビュープロセスを経る」。出典：blog.cloudflare.com。

なぜ「明示的昇格」ステップを追加するのか

Cloudflare が挙げる理由は2つあり、どちらも現実的です。1つは、チームに新しい要件を消化する時間を与えるため。もう1つは、状況によっては「実際にブロックできるようにする」こと自体に追加のエンジニアリング作業が必要な場合があるためです。

もう1つ、特筆すべき点があります。ワークフロー図の副題には「RFC とその機械可読ルールは同じレビュープロセスを経る」とあります。人が読む文書と機械が読む JSON は、一緒に書き、レビューし、マージされます。これにより、両者が互いにドリフトすることがありません。文書は更新されたが機械ルールは古いまま、誰もレビューしていないルールで機械がブロックする、といった状況も発生しません。

60以上の標準を、モデルが読める JSON に圧縮する方法

Cloudflare にはすでに60以上の RFC があり、まだ増え続けています。安直な方法は Codex 全体をそのまま大規模言語モデルに与えることですが、彼らはその結果を明確に記しています。この量はコンテキストウィンドウに大きな負荷をかけ、モデルの出力品質を損なう、と。

解決策は、専用の Agent で SHOULD と MUST ステートメントを自動抽出し、専用の JSON 構造に圧縮することです。さらに「遅延検出」とプログレッシブ開示をサポートするメタデータも追加されます。

抽出されたデータは次のようになります（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 が更新されても変わりません。

なぜこれが重要なのでしょうか？同じルールが複数のシステムから参照されるためです。コードレビューアが報告し、モニタリングが発生回数を集計し、あるチームが例外申請を行うかもしれません。ルールの番号が文書の変更で変わってしまうと、これらの参照はすべて途切れてしまいます。安定した slug があれば、システムや時間を超えて同じルールを追跡できます。

もう1つ、注目すべき進化があります。彼らは当初、より簡潔な Markdown ファイルとして抽出していましたが、その後、より構造が豊かな JSON に変更しました。変更理由は、Agent が使用するコンテンツをより精確にフィルタリングする必要があったためです。今後は、ライフサイクルのどの段階（設計、実装、実行時）にルールが適用されるかを示すなど、さらに多くのメタデータを追加する予定です。

3つのAgentが同じCodexを使用：コードレビュー、設計レビュー、障害報告レビュー

ルールがデータになると、それを利用できる場所が増えます。現在、日常業務で Codex を使用している Agent は3つです。

1. AIコードレビューア

各レビューで、まず RFC を取得し、Codex statements を解析します。モデルまたはコーディネーターがより多くのコンテキストを必要とする場合にのみ、完全な RFC 本文をロードします。ほとんどの場合、ステートメントだけで違反を説明するのに十分です。

どのように反応するかは、2つの要素で決まります。要件が SHOULD か MUST か、そして RFC の状態です。

データ：Codex 導入以来、AIコードレビューアは約23万件の違反を指摘し、そのうち約1.6万件が承認の保留につながりました。つまり、強制された RFC の MUST 条項に抵触したことになります。

2. スペックレビューア：コードを書く前にアーキテクチャの誤りを検出

Cloudflare のエンジニアは実装前に設計ドキュメントと技術仕様（スペック）を書きます。これは計画書で、何を、なぜ、どのようなトレードオフで行うのかを記します。Codex のかなりの部分は、まさにこの設計とアーキテクチャに関するものです。

スペックレビューアは新しいスペックを自ら見つけ出し、関連する Codex 要件で評価します。この Agent が何で動いているかは興味深いです。すべて Cloudflare が顧客に販売している製品です。

プロセスは次の通りです。まず Codex をドメインとセクションでフィルタリングし、設計に関連するものだけを残します（言語機能や実装詳細に焦点を当てた RFC はスキップ）。数段落のプロンプトがモデルに評価方法と結果の整理方法を指示します。報告された問題は重大度でスコアリングされ、SHOULD と MUST の影響を受けます。また、一般的な品質とアーキテクチャの提案も行います。実行後、スペック文書にメモを残し、カスタムダッシュボードへのリンクを貼って詳細を確認できるようにします。

スペックレビューアのインターフェース。上部にフィルター群：最近のレビュー時間（7日／30日／90日）、重大度（Critical+／Major+／全て）、検索、チーム、解決済みかどうか。レビュー対象のスペックは「Temporal Resiliency for Platform Workflow Automation」、番号 RM-24741、「1件の違反 / 4件のメモ」、最終レビューは2026年7月25日。意見はアーキテクチャメモ（さらに ARCHITECTURE / SCALE / OPEN QUESTIONS の3段階）と Codex 違反の2つの大きなブロックに分かれます。出典：blog.cloudflare.com。

このスクリーンショットはよく見る価値があります。Agent が報告する意見が具体的にどの程度なのかという重要な問いに答えてくれているからです。

赤く表示された critical のアーキテクチャ意見は次の通りです。このスペックはマルチクラスタ展開における名前空間戦略を定義していない、そして具体的に4つの補完すべき問題を挙げています。名前空間が2つのクラスタ間で複製されるのか、各クラスタ固有なのか。特定の名前空間内のワークフローが両方のクラスタで実行できるのか。フェイルオーバー時に名前空間の分離がどう維持されるのか。同じ名前の名前空間が2つの場所にある場合、それは同じ論理名前空間なのか、それとも独立したものなのか。最後に、これがワークフロー分離、マルチテナンシー、フェイルオーバー動作に影響を与えると指摘しています。

下にある Codex 違反は、RFC-013「依存関係の障害動作が未定義」に紐づく MAJOR レベルのものです。このスペックは worker が2つのクラスタ間でフェイルオーバーできると述べていますが、クラスタ障害時のアーキテクチャ上の動作が定義されていません。欠けている5点は、worker が自分のクラスタを利用できない場合に fail-open か fail-closed か。何がフェイルオーバーをトリガーするのか（自動か手動か）。worker がどのようにしてバックアップクラスタを発見し接続するのか。フェイルオーバーが実行中のワークフローに対して透過的か、それとも再起動が必要か。クラスタが利用できない場合、処理中のワークフローはどうなるのか。また、ドキュメントページのコメントで同僚が指摘した複製遅延の懸念を引用し、「ここには明確な障害モードの設計決定が本当に必要である」ことの裏付けとしています。

各意見の右側には「Recurring」タグ（この問題が繰り返し発生している）と「Feedback」ボタンがあります。

今後、彼らはスペックレビューアをさらに緊密に統合する予定です。意見をスペック文書に直接コメントとして投稿し、人と Agent の対話を埋め込んでレビュー結論にフィードバックできるようにし、影響の大きい提案をハイライトして人による追加レビューに回します。

3. 障害報告レビューア

同じ方法論を障害報告（ポストモーテムとも呼ばれる、インシデント発生後に書かれる報告書：何が起きたか、なぜ起きたか、どう解決したか、今後どう防ぐか）に適用します。

報告書の完全性をチェックするだけでなく、報告書が何が起きたかを明確に説明しているか、貢献要因を指摘しているか、解決プロセスを記録しているか、有意義なフォローアップアクションを提案しているかを評価します。これらの期待事項は専用の Codex RFC に書かれており、「適切な障害報告とは何か」という定義そのものが、機械でチェック可能なルールになっています。

スペックレビューアと同じ開発者プラットフォームコンポーネントを使用しており、この共有アーキテクチャは Codex 系 Agent の一般的なパターンになりつつあります。

2026年5月以来、200以上の障害報告を評価し、見つかったギャップには、忘れられたフォローアップアクション項目、不完全なタイムライン、見逃された検知シグナルなどがあります。これらの報告書の93%は、影響が低い、内部限定、または予防的な声明でカバーされるインシデントです。高重大度のインシデントでは、このレビューアの利用が必須であり、中央レビュープロセスの一部です。全ての問題が処理されるまで、報告書は完了と見なされません。

さらに高速な2つのチェック経路：linter とローカルCLI

運用が始まると、エンジニアから遅いという不満が出始めました。

完全なAIコードレビューには通常数分かかります。コーディネーターフレームワークとサブAgentが稼働するためです。Cloudflare はここで非常に率直に書いています。このコスト（あるいはトークン）はしばしば価値があるが、エンジニアは確かに2つのことを報告している、と。1つは待ち時間。もう1つは、修正後に再実行するための往復コストです。

そこで彼らは2つの経路を追加しました。

Cloudflare の今後の計画と、一致しない数字について

彼らが示すロードマップは3つです。

私が検証した数値の不一致について

3つあります。いずれも本筋には影響しませんが、数値を引用する際には知っておくべきです。

彼ら自身による一言

Cloudflare は別の社内AIエンジニアリングスタックに関するブログ記事で、上記のどの数字よりも重みのある言葉を残しています。

これらの部品は単体で見れば珍しいものではありません。サービスカタログを持つ会社も、レビューボットを導入した会社も、エンジニアリング標準を公開している会社もたくさんあります。違いは、配線の仕方にあります。

Cloudflare「私たちの社内AIエンジニアリングスタック」、当サイト訳

同じ記事には、このシステム全体の導入データも掲載されています。開始から開発チームの93%が採用するまで、1年未満。2026年2月5日から4月15日までの間に、アクティブユーザーは3683人で、会社の60%にあたります。

開発と技術管理への3つの示唆

この仕組みを分解すると、Cloudflare という特定の状況を離れても成立する3つの教訓があります。

Codex はドメインごとに分割（フロントエンド、コントロールプレーン、セキュリティ、信頼性、TypeScript、Rust……）。各ドメインには、コンテンツと品質に責任を持つドメインオーナーが1人います。ルールは RFC 形式で記述され、要件は2つの言葉のみ。MUST は必須、SHOULD は推奨（正当な理由があれば守らなくてもよい）。定義は RFC 2119（実在するインターネット標準文書）に直接従います。

規模が次の壁です。すでに60以上のRFCがあり、増え続けています。全体をモデルに与えるとコンテキスト（モデルが一度に読み込める量）が満杯になり、出力品質が低下します。彼らの解決策は、Agent を使ってこれらのステートメントを抽出し、JSONに圧縮することです。

ルールが書かれただけでは、まだブロックできません。提案から実際にコードをブロックするまで5つのステップ。人が読む文書と機械が読むJSONは、書き、レビューし、マージするまで常に一緒なので、両者がドリフトすることはありません。

同じ Codex が現在3つのAgentに供給され、それぞれコード、設計文書、障害報告を監視します。

運用開始後、エンジニアから遅いとの不満が出たため、同じルールに対して2つのより高速なチェック方法が追加されました。

4ヶ月で、3つのAgentが生み出した量。

上記の数字は全て Cloudflare 公式ブログの自己報告によるもので、第三者による検証はありません。