CloudflareがAIリクエストの管理を一本化 — コード1行追加でログ・コスト・フェイルオーバーをまとめて制御

8月7日、Cloudflareが「Unifying Workers AI and AI Gateway into a single AI control plane」と題した記事を公開した。これまで別製品として提供されていたWorkers AIとAI Gatewayを単一のAIコントロールプレーンへ統合する計画と、本日リリースされた新機能について詳しく紹介されている。

Workers AIとAI Gatewayの関係をおさらい

AI Gatewayは、OpenAIやAnthropicなど外部のモデルプロバイダーへのリクエストをプロキシしつつ、オブザーバビリティ・ログ・アクセス制御・セキュリティを提供するCloudflareのサービスだ。一方のWorkers AIは、Cloudflareが管理するGPUインフラ上でモデルをホストし、推論をAPIとして提供するサービスである。

アーキテクチャは異なるが、「ユーザーがモデルにつながるためのコントロールプレーン」という目的は同じだ。Cloudflareはこの2製品を統合し、どのモデルプロバイダー（Workers AI含む）にも単一のパスで接続しながら、オブザーバビリティ・請求・セキュリティ・ログを一元管理できる構成を目指している。

最大のポイント：設定ゼロでオブザーバビリティが手に入る

エンジニアにとって最も即効性が高いのが、Workers AIユーザーが自動でオブザーバビリティを取得できる仕組みだ。

従来のWorkers AI呼び出しは次のように書いていた：

const response = await env.AI.run('@cf/meta/llama-3-8b-instruct', {
  messages: [{ role: 'user', content: 'Hello!' }],
});

今後は第3引数にゲートウェイIDを渡すだけでよい：

const response = await env.AI.run(
  '@cf/meta/llama-3-8b-instruct',
  { messages: [{ role: 'user', content: 'Hello!' }] },
  { gateway: { id: 'default' } } // 初回リクエスト時に自動作成
);

※上記コードのモデル名はフォーマット例として一般的な表記を使用している。元記事に記載されている実際のモデル識別子については元記事を参照されたい。

id: 'default'を渡すと、AI Gatewayが存在しない場合は最初の認証済みリクエスト時に自動生成される。これ以降、Cloudflare AI Gatewayダッシュボードでリクエストごとのレイテンシ、トークン使用量、エラーレート、プロンプトと応答の全文ログが確認できる。

ゲートウェイを明示的に作成・設定する手間なくトラフィックが可視化される点は、モデルの挙動をデバッグしたいチームやAI出力を監査したいチームに直接刺さる改善だ。アプリケーションを複数プロジェクトに分割したい場合は、従来通り名前付きゲートウェイを作成してパラメータを差し替えるだけでよい。

本日リリース：AI Gatewayクレジットの統合請求

もう一つの新機能がWorkers AIへのAI Gatewayクレジット適用だ。これまでAI Gatewayのクレジット（ウォレット）はOpenAIやAnthropicなど外部プロバイダーにしか使えなかった。本日からWorkers AIの使用量にも同じクレジットを充当できる。

クレジットをウォレットにチャージしておけば、OpenAI・Anthropic・Workers AIを含むすべての対応プロバイダーを横断して自由に使える構成になる。さらに、AI Gateway統合請求を使ったユーザーはWorkers AIモデルのレートリミットが引き上げられる。具体的な数値は開発者向けChangelogを参照されたい。

なお、AI GatewayではZero Data Retention（ZDR）オプションも提供されており、プロンプトや応答をCloudflareのインフラに保存させたくないユースケースにも対応している。統合後もZDRの設定は引き続き有効で、モデルファーストルーティング（後述）においても考慮されるとしている。

近日公開：モデルファーストなルーティング

現状、モデルを呼び出すにはどのプロバイダーがそのモデルをホストしているかを把握している必要がある。そのプロバイダーがダウンしていたり、レートリミットに達していたりすると、アプリケーションが壊れる。

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": "Review this function"}]
  }'

※上記のモデル名kimi-k2.7-codeは元記事に記載されている表記をそのまま引用している。正式なモデル識別子については元記事およびWorkers AIモデルカタログで確認されたい。

例えば特定のモデルを指定した場合、Workers AIに空きがあればそちらで処理し、キャパシティ不足なら別の対応プロバイダーへ透過的にルーティングされる。アプリケーション側でリトライロジックやフォールバックを実装する必要はない。前述のZDRなどのデータ要件も考慮されるとしている。このモデルファーストルーティングは今後数ヶ月でパイロット提供予定だ。

さらにその先として、スマートルーティングも開発中だ。モデルすら指定せず、プロンプトの内容をCloudflareのインフラ上で動作するクラシファイヤーが解析し（コーディング・リサーチ・要約・一般Q&Aなどのタスク分類と複雑さを推定）、最適なモデルを自動選択する仕組みである。現在は社内パイロット中で、リリース前に数週間テストを重ねるとしている。

※スマートルーティングのクラシファイヤーが具体的にどのインフラ上で動作するかについては、元記事に詳細な記述がないため、正確な実装については元記事を参照されたい。

まとめ

今回の統合の要点は次の3点に整理できる。

バインディングとREST APIの統一：AI GatewayとWorkers AIへのエントリポイントが1本化された
自動オブザーバビリティ：gateway: { id: 'default' } を付けるだけで、既存のWorkers AIコードにログ・トークン追跡・コスト帰属が追加される
統合請求とレートリミット引き上げ：AI Gatewayクレジットが全プロバイダーで横断利用可能になり、Workers AIのレートリミットも緩和される

モデルファーストルーティングやスマートルーティングはまだパイロット段階だが、インフラ管理をコントロールプレーンに寄せていく方向性は明確だ。Workers AIやAI Gatewayを既に利用しているチームはもちろん、複数のモデルプロバイダーを使い分けているチームにとっても、今後の機能展開を注視する価値がある。

詳細はUnifying Workers AI and AI Gateway into a single AI control planeを参照していただきたい。