はじめに：2つのプロダクトが1つになる理由
Cloudflareはもともと AI Gateway と Workers AI を別々のプロダクトとして提供していました。AI Gatewayは外部モデルプロバイダー（OpenAI、Anthropicなど）へのプロキシとして可観測性・ロギング・セキュリティを担い、Workers AIはCloudflareが管理するGPUインフラ上でモデルをホスティングし、推論APIを提供していました。
しかし時間が経つにつれ、ユーザーのニーズは1つに収束していきました。アーキテクチャは違えど、目的は同じ「モデルに接続し、可観測性と制御を一箇所で行いたい」という点です。そこで今回、両プロダクトを単一のパスへ統合する計画が発表されました。
💡 ポイント: Workers AIでも外部モデルでも、単一のコントロールプレーンから可観測性・課金・セキュリティ・ロギングを管理できるようになります。
本記事では、この統合の実務的な意味と、今後予定されているモデルファーストルーティング、スマートルーティングまでを整理します。根拠資料はCloudflare公式ブログで確認できます。
統合バインディングとAPI：コードで見る変化
最も実感しやすい変化は、エントリーポイントが統一される点です。従来はWorkers AIバインディングとAI Gatewayバインディングが概念的に分かれていましたが、今後は env.AI.run() ひとつで両方を呼び出せます。
バインディング呼び出しの例
// Workers AIをAI Gateway経由で呼び出す例
export default {
async fetch(request, env) {
const response = await env.AI.run(
'@cf/zai-org/glm-5.2',
{
messages: [
{ role: 'user', content: 'フランスの首都はどこですか？' },
],
},
{
gateway: {
id: 'default', // 内蔵ゲートウェイを使う場合は 'default' を指定
},
}
);
return new Response(JSON.stringify(response), {
headers: { 'Content-Type': 'application/json' },
});
},
};
REST API呼び出しの例
# 統合された /ai/ エンドポイントでWorkers AIをAI Gateway経由で呼び出す
curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/run/@cf/zai-org/glm-5.2" \
-H "Authorization: Bearer {api_token}" \
-H "Content-Type: application/json" \
-H "cf-aig-gateway-id: default" \
-d '{
"messages": [{"role": "user", "content": "フランスの首都はどこですか？"}],
}'
ポイントは gateway: { id: 'default' } またはヘッダー cf-aig-gateway-id: default を1つ追加するだけで済むことです。既存コードをほぼ変更せずに可観測性とロギングを獲得できます。
自動可観測性、統合課金、そして今後のルーティング革新
1. デフォルトゲートウェイの自動作成
今回の統合で最も即効性のあるメリットは、AI Gatewayを事前に作成しなくてよい点です。default をゲートウェイIDとして渡すと、初回の認証リクエスト時に自動生成されます。以降、すべてのリクエストはリクエスト・レスポンスのペイロード全体と共にロギングされ、モデルごとのトークン数とコスト配賦がダッシュボード設定なしで自動追跡されます。
後でカスタムキャッシュルールが必要になったり、アプリケーションごとにトラフィックを分離したくなった場合は、名前付きゲートウェイを作成し、パラメータを1つ変えるだけで対応できます。
2. Workers AIでもAI Gatewayクレジットが利用可能に
従来、AI GatewayクレジットはOpenAIやAnthropicなどの外部プロバイダーにのみ使用できましたが、今回から Workers AIの利用分にも適用できるようになりました。ウォレットにクレジットをチャージし、OpenAI、Anthropic、Workers AIのどこにでも使える統合課金構造です。さらにこの経路を利用すると、Workers AIモデルのレートリミットが引き上げられるとのことです。
3. モデルファーストルーティング（近日提供）
現状、モデルを呼び出すには「どのプロバイダーがそのモデルをホストしているか」を知る必要があります。プロバイダーがダウンしたりレートリミットに達すると、アプリケーションは破綻します。Cloudflareが準備中の モデルファーストルーティング はこれを反転させます。モデルだけを指定すれば、ゲートウェイがプロバイダー選択・フェイルオーバー・ロードバランシングを処理します。
# モデルだけを指定すれば、プロバイダーはゲートウェイが自動選択
curl -X POST "https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/v1/chat/completions" \
-H "Authorization: Bearer {api_token}" \
-H "cf-aig-gateway-id: my-gateway" \
-H "Content-Type: application/json" \
-d '{
"model": "kimi-k2.7-code",
"messages": [{"role": "user", "content": "この関数をレビューして"}]
}'
Workers AIに余力があればマネージドインフラの利点を、なければ別プロバイダーへ透過的にロードバランシングされます。ZDR（Zero Data Retention）などの要件も尊重されるとのことです。
4. スマートルーティング（Next）
さらに スマートルーティング ではモデル指定すら不要になります。Workers AI上で動作する分類器がプロンプトを読み、タスク種別（コーディング、リサーチ、要約、一般Q&A）、複雑度、コンテキストの重要度を予測し、ヒューリスティックスコアラーがキュレーションされたプールから最適モデルをマッピングします。ゼロコンフィグで経済性と性能を両立する方向性です。
⚠️ 注意点と限界
- デフォルトゲートウェイは便利ですが、プロジェクトが大きくなったら名前付きゲートウェイへの分離を推奨します。コスト配賦とキャッシュポリシーを細かく制御する必要があるためです。
- モデルファースト／スマートルーティングはまだパイロット段階です。本番依存はGA以降に検討してください。
- プロバイダー間でモデルの重みが同一でも 微妙な出力差 が生じる可能性があるため、厳密な再現性が求められるワークロードは単一プロバイダー固定が安全です。
まとめ：今すぐ始める方法
今回の統合は「AIインフラを自前で管理せずとも可観測性と制御を確保する」というCloudflareの方向性を明確に示しています。実務では次の順序でアプローチするとよいでしょう。
- 既存のWorkers AI呼び出しに
gateway: { id: 'default' }を1行追加 → 即座にロギング・トークン追跡・コスト配賦を確保 - トラフィックが増えたら名前付きゲートウェイへ分離 → アプリ別のキャッシュ・セキュリティポリシーを適用
- 統合課金ウォレットの導入 → 複数プロバイダーをまたいでクレジット管理
- モデルファーストルーティングのGA情報を注視 → マルチプロバイダーのレジリエンス確保
📚 次のステップ学習方向
- Cloudflare Workersバインディングパターンと環境変数管理
- AI Gatewayのキャッシュ・レートリミットポリシーのドキュメント精読
- マルチプロバイダーのフェイルオーバーアーキテクチャ設計