背景：なぜ 2 つのプロダクトが 1 つになるのか

Cloudflare には当初から 2 つの AI プロダクトが存在していました。ひとつは AI Gateway — 任意のモデルプロバイダーへのリクエストをプロキシし、可観測性・ロギング・アクセス制御・セキュリティを付与する製品。もうひとつは Workers AI — Cloudflare が管理する GPU インフラ上でモデルをホストし、推論 API を提供するサービスです。

アーキテクチャは異なりますが、利用者から見れば目的は同じでした。「モデルへ安全に接続するためのコントロールプレーン」が欲しい、という点です。そこで Cloudflare は両者を 単一のパス に統合する方針を発表しました。Workers AI を含む任意のプロバイダーへ接続しつつ、可観測性・課金・セキュリティ・ロギングをひとつのコントロールプレーンで管理する姿です。

これは単なる製品発表ではなく、AI インフラの抽象化レイヤーがどこへ向かうのか を示すシグナルとして、トレンド観点で押さえる価値があります。根拠資料は Cloudflare 公式ブログ で確認できます。

Cloud architecture diagram showing unified AI control plane connecting multiple model providers Software Concept Art

変化 1：バインディングと API の統合

最初に体感できる変化は エントリーポイントの統合 です。Workers バインディング（env.AI）と REST API（/ai/）が同じ経路で AI Gateway と Workers AI を呼び出せるようになりました。「AI Gateway 用バインディング」と「Workers AI 用バインディング」が別々に存在しない、という意味です。

実務で特にありがたいのが default ゲートウェイ です。事前にゲートウェイを作成しなくても、gateway.id に 'default' を渡せば最初の認証リクエスト時に自動生成されます。

// AI Gateway 経由で Workers AI を呼び出すバインディング例
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', // 組み込みゲートウェイを使用（自動生成）
        },
      }
    );
    return new Response(JSON.stringify(response), {
      headers: { 'Content-Type': 'application/json' },
    });
  },
};

REST API も同様です。cf-aig-gateway-id ヘッダーに default を指定するだけです。

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": "フランスの首都はどこですか？"}]
  }'

この統合の実務的な意味は明確です。「どちらの製品から使い始めるべきか」という意思決定コストが消える ということ。最初から可観測性とロギングが有効な状態でスタートできます。

Developer routing AI inference requests through Cloudflare AI Gateway with token and cost tracking Programming Illustration

変化 2：統合課金とモデルファーストルーティング

自動可観測性

Workers AI の利用者は、ゲートウェイを別途作成することなく すべてのリクエストに対するロギング、トークンカウント、コスト配賦（cost attribution） を自動的に得られるようになりました。ダッシュボードではレイテンシ内訳、エラー率、実際のプロンプト／レスポンスペイロードまで確認できます。モデルの挙動をデバッグしたり、AI 出力を監査する必要があるチームにとっては、「目隠し飛行」からの大きな改善です。

AI Gateway クレジットで Workers AI を支払う

これまで AI Gateway クレジットは OpenAI や Anthropic など 外部プロバイダーにのみ 利用できました。今回のアップデートで Workers AI の利用分にも同じクレジットウォレット を使えるようになりました。ひとつのウォレットにチャージし、OpenAI・Anthropic・Workers AI のどこへでも配分できるイメージです。統合課金経路を利用すると Workers AI の レートリミットが引き上げられる インセンティブも用意されています。

予告されている機能：model-first routing と smart routing

区分従来（Provider-first）新方式（Model-first）
判断単位「どのプロバイダーを呼ぶか」「どのモデルが必要か」
障害対応アプリ側でリトライ／フォールバックを実装ゲートウェイが自動フェイルオーバー
負荷分散手動プロバイダー間で自動ロードバランシング
設定負担プロバイダーごとに管理モデル名を指定するだけ

たとえば kimi-k2.7-code を要求すると、Workers AI に余力があればマネージドインフラの恩恵を受け、なければ別プロバイダーへ透過的にロードバランシングされます。さらに smart routing では、プロンプトを分類器が読み取り（コーディング／リサーチ／要約／一般 Q&A）タスク種別と複雑度を判定し、最適なモデルを自動選択する段階まで予告されています。

# model-first routing（パイロット予定）の例
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": "この関数をレビューしてください"}]
  }'

インフラ抽象化が上へ上がっていく流れは、Azure Multicloud Interconnect が示したマルチクラウド接続戦略 とも軌を一にしています。結局「どこにあるか」よりも「いかに安全に接続するか」が競争力になる時代です。

Network topology of model-first routing with automatic failover across AI providers Algorithm Concept Visual

注意点と実務での適用ポイント

1. default ゲートウェイの落とし穴

便利ですが、すべてのリクエストがひとつのゲートウェイに集約されるとプロジェクト単位のコスト分離が難しくなります。アプリケーション単位でトラフィックを分けたい場合は、最初から名前付きゲートウェイを作成したほうが安全です。「まず default で始めて後で分離」は、ログ履歴が混在する代償を払う可能性があります。

2. model-first routing はまだパイロット段階

フェイルオーバーやロードバランシングは魅力的ですが、出力の一貫性 が重要なワークロード（例：定型 JSON レスポンスのパース）では、プロバイダーが切り替わることで微妙な出力差が生じる可能性があります。ZDR（Zero Data Retention）のようなコンプライアンス要件もプロバイダーごとに確認が必要です。

3. 日本の開発エコシステムの文脈

日本では依然として特定ベンダー（国内 LLM や社内プライベートモデル）を固定して利用するケースが多く見られます。model-first routing の真価は「複数プロバイダーを跨ぐ環境」で発揮されるため、単一プロバイダーしか使わないチームにとって当面のメリットは大きくありません。ただし 可観測性の自動化 と 統合課金 はベンダーに依存せず即効性のある機能ですので、この部分から導入することをおすすめします。

次のステップ学習の方向性

  • すでに Workers AI を使っている場合：既存の呼び出しに gateway: { id: 'default' } を追加するだけで、ロギングとトークン追跡を即座に有効化できます。
  • AI Gateway を使っている場合：クレジットウォレットに Workers AI を加え、統合課金と引き上げられたレートリミットを検証してみてください。
  • アーキテクチャ観点の場合：Santander のプラットフォームエンジニアリング事例 のように「開発者体験を抽象化レイヤーに吸収する」パターンが AI インフラでも繰り返されている点に注目する価値があります。

結局のところ、今回の統合の本質は 「モデルを呼ぶこと」から「モデルを呼ぶ方法を管理すること」へ重心が移る ということです。アプリケーションコードはそのままに、ルーティング・課金・可観測性はプラットフォームへ委譲する — この方向性が今後数年間の AI バックエンド設計のデフォルトになる可能性は高いと考えられます。

本コンテンツは、信頼性の高い情報源をもとにAIツールを活用して作成され、編集者によるレビューを経て公開されています。専門家によるアドバイスの代替となるものではありません。