先に結論
Cloudflare AI Gateway の今回の更新で大きいのは、複数 provider を 1 つの API 面と課金面に寄せやすくなったことです。
先に判断を短く言うとこうです。
- 既存の OpenAI SDK や Anthropic SDK を大きく壊したくない なら、かなり試しやすい更新です。
- provider API key を配る運用を減らしたい なら、Unified Billing の価値が出ます。
- ZDR を有効にしただけで全部のログが消えるわけではない ので、logging 設定は別で見る必要があります。
つまり、今回の主語はモデル比較ではありません。gateway をどこまで control plane にできるか です。
何が変わったのか
Cloudflare は 2026-05-21 に、AI Gateway を api.cloudflare.com 上の新しい REST API へ広げました。
これで OpenAI、Anthropic、Google、Workers AI の呼び出しを、Cloudflare の同じ認証面から扱えます。
使える endpoint は 4 つです。
POST /ai/runPOST /ai/v1/chat/completionsPOST /ai/v1/responsesPOST /ai/v1/messages
見るべきなのは数より役割です。
/ai/run は汎用入口です。LLM だけでなく、画像や音声を含むモデルもまとめて扱いやすい形です。
/ai/v1/chat/completions と /ai/v1/responses は OpenAI 互換です。既存の OpenAI SDK を使っているなら、まずここが一番入りやすいです。
/ai/v1/messages は Anthropic Messages API 互換です。Claude 系の既存実装を大きく変えずに gateway を挟みたい時に使いやすいです。
いちばん実務で効くのは baseURL 差し替えで済みやすいこと
今回の更新が強いのは、完全に新しい SDK を覚える話ではないことです。
Cloudflare docs では、OpenAI SDK も Anthropic SDK も baseURL を Cloudflare 側へ向ける形が案内されています。
つまり、既存のアプリや internal tool がすでに SDK を使っているなら、最初の検証は大げさになりません。
- 既存コードの model 呼び出しは大きく変えない
- 認証を Cloudflare API token に寄せる
- gateway 単位の logging、caching、rate limiting、guardrails を足す
この順で試せます。
複数 provider を横断してコスト制御まで見たいなら、Edgee AI Gateway vs OpenAI usage tiers vs Gemini spend caps vs Anthropic cost reports｜AI coding agent のコスト制御はどこで持つべきか もつながります。
Unified Billing は API key 削減より、請求面の一本化が本体
Cloudflare は Unified Billing で、third-party model の請求を Cloudflare 側へまとめられると説明しています。
このとき大事なのは 2 点です。
1つ目は、provider API key を持たなくてよい ことです。
OpenAI や Anthropic の key をアプリごとに配る代わりに、Cloudflare API token と gateway 設定で回しやすくなります。
2つ目は、Cloudflare に credits を積んで使う ことです。
Unified Billing には 5% fee があります。ただし provider の inference 単価自体には markup を載せないと docs に明記されています。
要するに、token 単価そのものが安くなる話ではありません。請求、認証、運用のまとまりに 5% を払う話 です。
この 5% が合うかは、次の条件で決まります。
- provider key の配布や rotation を減らしたいか
- spend limits を gateway 側で揃えたいか
- 複数 provider の利用を 1 つのダッシュボードに寄せたいか
Workers AI は同じ面に見えても、課金は別です
ここは見落としやすいです。
Cloudflare docs では、Workers AI モデルは @cf/... の model 名で同じ API 面から呼べます。ただし課金は Unified Billing ではなく、Workers AI pricing 側です。
つまり、OpenAI や Anthropic の third-party model と、Workers AI を「どちらも Cloudflare だから同じ請求」と考えるとズレます。
同じ control plane で扱えるのは便利ですが、課金境界は別 です。
経理や platform 側へ説明が必要な組織ほど、ここは先に分けておいたほうが安全です。
ZDR で変わることと、変わらないこと
ZDR は強い言葉ですが、効く場所は限定されています。
Cloudflare docs では、ZDR は Unified Billing のトラフィックを、provider 側で prompt や response を保持しない経路へ寄せる設定 です。
現時点で対象として明記されているのは OpenAI と Anthropic です。
一方で、変わらないものもあります。
AI Gateway logging は ZDR では消えません。
ここは docs にかなり明確に書かれています。ZDR は upstream retention の話で、Cloudflare 側の logging 設定とは別です。
そのため、機密データや社内コードを扱うなら、少なくとも次を分けて確認したほうがいいです。
- gateway の ZDR をどうするか
- gateway logging を残すか止めるか
- どの provider が ZDR 対象か
- BYOK 時に同じ前提で語っていないか
社内ネットワークや閉域寄りの設計まで含めて見たいなら、Self-hosted private network AI coding agent 比較｜社内ネットワークで動かすなら何を優先すべきか も参考になります。
request ごとの制御は想像より細かい
Cloudflare の REST API docs では、gateway ごとの設定だけでなく request header でも細かい制御ができます。
たとえば次です。
cf-aig-gateway-idで通す gateway を指定するcf-aig-cache-ttlで cache TTL を変えるcf-aig-collect-logで request ごとの logging を切り替えるcf-aig-max-attemptsやcf-aig-retry-delayで retry を調整するcf-aig-zdrで request 単位の ZDR override をかける
この設計が効くのは、同じアプリでも処理の重さや機密度が違う時です。
たとえば FAQ 応答は log を取りたいが、社内コードを含む agent 実行は log を抑えたい、という分け方がしやすくなります。
監査性まで含めて運用を考えるなら、GitHub Copilot coding agent vs Claude Code vs Codex｜監査性・安全性・レビュー運用で選ぶ も合わせて読むと整理しやすいです。
向いている人、まだ早い人
向いている人
一番向いているのは、すでに複数 provider を使い始めていて、運用面をまとめたい人 です。
たとえば次のような状況です。
- OpenAI と Anthropic を案件ごとに使い分けている
- app 内蔵 AI と internal agent で logging ルールを揃えたい
- provider key の分散管理を減らしたい
- Cloudflare をすでに edge や security の標準面として使っている
まだ早い人
一方で、1 provider を小さく試している段階 なら直叩きで十分なことも多いです。
gateway を足すと、便利になる代わりに見るべき設定も増えます。
- credits の残高管理
- spend limits
- gateway logging
- ZDR 対象範囲
- Workers AI と third-party model の課金差
この運用コストより得るものがまだ小さいなら、無理に挟まないほうが素直です。
最初にやるなら、この順が安全です
いきなり全面移行するより、次の順で見るほうが外しにくいです。
1. OpenAI SDK か Anthropic SDK の一部を baseURL 差し替えで試す
まずは 1 本の内部ツールか staging 環境で十分です。
ここで、レスポンス互換性と observability の増え方を確認します。
2. Unified Billing の fee と credits 運用を確認する
5% fee を払う代わりに、API key 管理や請求の一本化で何が減るかを見ます。
3. gateway logging と ZDR を別々に決める
ここを一緒に考えると事故りやすいです。保持を止めたい場所は ZDR だけでなく logging 側も触ります。
4. Workers AI を混ぜるなら課金説明を先に分ける
Cloudflare で統一されたように見えても、third-party と Workers AI は billing line が違います。
いま気をつけたい誤解
ZDR を付ければ全部 non-retention になる
これは違います。Cloudflare docs では、AI Gateway logging は別設定です。
Cloudflare を挟めば token 単価が安くなる
これも違います。provider 単価に markup はない一方で、Unified Billing には 5% fee があります。価値は節約ではなく運用整理です。
Workers AI も Unified Billing でまとめて請求される
Workers AI は別課金です。同じ control plane と同じ billing line は別物です。
すぐやるチェックリスト
- OpenAI か Anthropic の既存 SDK 実装で
baseURL差し替え検証を 1 本やる - credits の top-up と spend limits の運用者を決める
- gateway logging を残す request と止める request を分ける
- ZDR を使う gateway と provider を明文化する
- Workers AI を混ぜるなら、請求説明を third-party と分けて書く
Cloudflare AI Gateway の新 REST API は、単なる endpoint 追加ではありません。複数 provider を 1 つの API 面で扱い、請求と制御を寄せる入口 です。
ただし、本当に効くのは導入そのものより、どこまで統制を寄せ、どこは別で残すか を最初に切り分けた時です。