Cloudflare が Workers AI と AI Gateway を統合 — クレジットをプロバイダ横断で使えるように
Cloudflare は、自社推論の Workers AI と、外部モデルへのプロキシである AI Gateway を単一のコントロールプレーンへ統合した。Workers では1つの AI binding で両方を扱え、既存の env.AI.run() に第3引数を足すだけで可観測性が付く。課金面では1つのクレジット残高を OpenAI / Anthropic / Workers AI 横断で消費できるようになった。
ニュース原文を読む ↗要約
Cloudflare は 2026-08-07、これまで別製品だった Workers AI と AI Gateway を単一のコントロールプレーンへ統合したと発表しました。Agents Week（2026-08-03〜08-07）の最終日にあたる発表です。
Workers AI は Cloudflare 自身が提供する推論サービス、AI Gateway は OpenAI や Anthropic といった外部プロバイダへのプロキシで、可観測性・課金管理・セキュリティを担う層でした。公式は今回の統合を「これらの製品が1つの経路に収束し、任意のモデルプロバイダへ接続しつつ、可観測性・課金・セキュリティを中央で管理できる」と説明しています。
Workers 側では、単一の AI binding で両方を扱います。移行コストは小さく、既存の env.AI.run() 呼び出しに第3引数として { gateway: { id: 'default' } } を渡すだけで AI Gateway 経由となり、可観測性が自動的に付きます。
const response = await env.AI.run(
'@cf/zai-org/glm-5.2',
{ messages: [{ role: 'user', content: 'Hello!' }] },
{ gateway: { id: 'default' } }
);REST API 側は /ai/ エンドポイントが新設され、cf-aig-gateway-id ヘッダーでゲートウェイを指定します。
変更として大きいのは課金です。クレジットのウォレットに残高を積み、それを OpenAI / Anthropic / Workers AI など任意のプロバイダに対して使えるようになりました。従来は AI Gateway のクレジットを Workers AI の利用に充当できませんでした。統合課金を使う場合、Workers AI モデルのレート上限が引き上げられます。
提供は段階的です。統合 binding と default ゲートウェイの自動作成は即時利用可能。モデル起点でルーティングする model-first routing はパイロット段階で数か月内、モデルを自動選択する smart routing はその先とされています。なお、ブログには具体的なレートカードや価格表の記載はありません。
何が変わったか
- 単一の AI binding で Workers AI とサードパーティモデルの両方を呼び出せる
- 既存の
env.AI.run()に{ gateway: { id: 'default' } }を足すだけで可観測性が付く - REST API に
/ai/エンドポイントが新設され、cf-aig-gateway-idヘッダーでゲートウェイを指定する - 1つのクレジット残高を OpenAI / Anthropic / Workers AI 横断で消費できる
- 統合課金の利用時、Workers AI モデルのレート上限が引き上げられる
- default ゲートウェイが自動作成される
- model-first routing はパイロット段階、smart routing は未提供
- 具体的な価格改定・レートカードの公開はない
業務インパクト（一般企業向け）
AI を組み込んだアプリケーションを運用していると、必ずぶつかる問題があります。モデルを複数のプロバイダにまたがって使い始めた瞬間に、コストの全体像が見えなくなることです。
OpenAI の請求、Anthropic の請求、自社のインフラ費用がバラバラに届き、どの機能がいくら使っているのかを突き合わせるだけで工数が溶けます。今回の統合は、この構造そのものに手を入れています。1つのクレジット残高をプロバイダ横断で使えるということは、支払いの単位がプロバイダではなく「AI 利用全体」になるということです。
これが効くのは、コスト管理よりもむしろモデル選定の柔軟性です。従来、プロバイダを変えるという判断には、契約・請求経路・可観測性の設定をやり直すコストがついて回りました。そのため一度選んだモデルを惰性で使い続ける、という状態になりがちでした。統合後は、コード側の変更が binding のモデル指定だけになり、課金と可観測性は共通のまま残ります。「まずは安いモデルで試して、品質が足りなければ上げる」という運用が、意思決定コストの面で現実的になります。
導入判断としては、既存の Workers AI 利用者にとってリスクの低い変更です。移行が第3引数の追加だけで済み、しかも追加すると可観測性が付くという設計は、実質的にデメリットがありません。逆に、AI Gateway を使っていて Workers AI は使っていなかった組織にとっては、クレジットの充当先が広がるという純粋な利得になります。
一方で、性急に判断すべきでない点もあります。公式が価格表を出していないため、「統合すると安くなる」とは書かれていません。書かれているのは「レート上限が上がる」ことと「クレジットを横断して使える」ことだけです。コスト削減を期待して移行を進めるなら、実際の請求で確認するまで結論を保留すべきです。また、model-first routing と smart routing はまだ提供されていません。「モデルを自動で選んでくれる」ことを前提にした設計は、現時点では先走りになります。
社内で AI 基盤を整備する立場なら、今回の統合は「AI の入口を1本に絞る」という設計判断を後押しする材料になります。各チームが個別にプロバイダと契約している状態から、共通のゲートウェイを通す構成へ寄せる際、これまでは Workers AI だけ別扱いにする必要がありました。その例外がなくなります。
副業・個人活用視点
個人開発や小規模案件で AI 機能を作っている人にとって、今回の変更は実装の手間より運用の見通しに効きます。
小さく作っているうちは、OpenAI の API キーを1本持っていれば足ります。問題が出るのは、機能が増えてきたときです。この機能は安いモデルでいい、こっちは品質が要る、画像はまた別のプロバイダ、という形で分岐が増えると、どこでいくら使っているかが把握できなくなります。個人で回している場合、請求が想定を超えて初めて気づく、という事故が起きやすい領域です。統合されたゲートウェイを通しておけば、機能ごとの消費量が最初から1か所で見えます。
技術的な参入障壁も低い部類です。Workers を使っているなら、env.AI.run() に第3引数を足すだけです。これは学習コストというより、知っているかどうかの差でしかありません。
案件の観点では、「AI 機能を入れたいがコストが読めないので踏み切れない」という相談に対する具体的な回答になります。中小企業のクライアントで、AI 導入の話が止まる理由の多くはコストの不確実性です。「使った分だけ」という説明は理屈では通っても、上限が見えないと稟議が通りません。プロバイダ横断のクレジット残高という仕組みは、「この金額まで」という上限を先に決めてから始める、という進め方と相性が良い構造です。提案の際は、可観測性が自動で付くことを併せて説明すると、運用開始後の説明責任まで含めた話になります。
ただし、提案時に model-first routing や smart routing を将来機能として持ち出すのは避けた方が無難です。パイロット段階のものを前提に設計すると、提供時期がずれたときに約束を回収できなくなります。現時点で確実に言えるのは、binding が1本になったこと、クレジットが横断で使えること、レート上限が上がることの3点です。