情報技術 / クラウドインフラ
Cloudflare：社内標準に基づくAIによるコードと設計文書のレビュー
- 企業
- Cloudflare
- 国
- 米国
- 導入状況
- 運用中
- 資料公開
- 日付の基準
- 資料が公開された時点。導入を開始した日とは異なる場合がある。
- 根拠の確認方法
- 原文の本文を閲覧
業務課題
Cloudflareは、エンジニアリング標準をCodexという名前のRFC群として管理している。要件はRFC 2119が定めるSHOULDとMUSTのキーワードで記す。原文は、すでにRFCが60を超えて増え続けているため、Codex全体をそのまま大規模言語モデルに入れるとコンテキストウィンドウへの負荷が大きく、結果が悪くなると記している。すべてのmerge requestと設計文書から人が標準違反を見つけ出すことも、量の多さから難しかった。
使った技術とデータ
同社はCodexを丸ごと入れるのではなく、レビュー対象に合うRFCだけを選んで使う仕組みを作った。AIコードレビューはmerge requestを読んで標準違反を指摘するが、承認済みRFCの指摘は妨げずに知らせるだけで、強制されたRFCのMUST違反は承認を保留させる。TypeScriptが最初にCodex linterの対応を受け、実行速度のためoxlintに統一した。Rustは開発中で、Goがその次である。設計文書のレビューはDeveloper Platform上で動く。Cloudflare Workerとして実行し、結果と状態をD1に保存し、モデル要求をAI Gatewayへ渡し、新しい文書の走査はCron Triggerで始める。インシデント報告のレビューは、後続対応の抜け、不完全な時系列、欠落した検知シグナルといった不備を探す。開発者はOpenCodeベースのツールでCLIから同じレビューを自分の環境でも実行できる。
成果
同社は、今年初めにCodexを始めて以降、AIコードレビューが標準違反を23万件近く指摘し、そのうち1万6,000件近くが承認保留につながったと述べた。設計文書のレビューは2026年5月初めから、異なる公開設計文書を600件近くレビューし、文書の変更や要求に応じた再実行まで含めるとレビュー実行は3,200回を超えたと説明した。指摘の深刻度はmajorが65%、minorが29%で、criticalは6%と最も少なかったと述べた。インシデント報告のレビューは2026年5月から報告を200件以上確認し、そのうち93%は影響が小さいか、社内にとどまるか、あらかじめ宣言されたインシデントだったと述べた。
限界と残る課題
指摘した違反の件数と保留の件数は示されているが、誤って指摘した比率や、開発者が指摘を受け入れた比率は示されていない。レビューツールの導入後にインシデント件数がどう変わったかも数値で示されていない。
出典
- How Cloudflare enforces engineering standards using AIblog.cloudflare.com, 確認
公開資料をまとめた事例です。ATF Works導入企業の成果ではありません。