Cloudflareが発表した「AI Platform」は、ひとことで言うとAIモデルを使うための“統一インフラ”です。
これまでのように「OpenAIはこのAPI、Anthropicは別のAPI、社内モデルはまた別」という面倒を減らして、どのモデルも同じ入口から呼び出せるようにするのが狙いです。
しかも今回の話、ただの「便利なAPI増えました」ではありません。
AIエージェント時代を見据えた設計になっているのがポイントで、ここがかなり面白いと思いました。エージェントは1回の質問に1回返すチャットボットと違って、内部で何度もモデルを呼び分けます。だから、速さ・安定性・コスト管理が一気に重要になるんですよね。
AI.run() でCloudflare製・他社製モデルを同じ感覚で呼べる
記事の前半でCloudflareが強調しているのは、AIモデルの世界はとにかく変化が速いという点です。
たとえば、今はあるモデルがコード生成に最適でも、3か月後には別の会社の別モデルがもっと良くなっているかもしれない。
これ、AIを使う側からするとかなり悩ましい話です。なぜなら、モデル選びが固定できないからです。
しかも実際のサービスでは、1つのモデルだけで全部をこなすことは少ないです。
記事の例では、カスタマーサポートのAIエージェントが、
という使い分けを想定しています。
これ、かなり現実的です。
「AIを使う」と聞くと1発の質問応答を思い浮かべがちですが、実際の業務AIはオーケストラみたいに複数モデルを組み合わせることが多いんですよね。
そこで問題になるのが、
という、いわばAI運用の地味で重い部分です。
Cloudflareはそこを「AI Platform」でまとめて面倒みる、と言っているわけです。
今回の大きな変更点は、Workers で使っていた AI.run() から、外部プロバイダのモデルも呼べるようになったことです。
記事中の例では、Anthropicの claude-opus-4-6 をこんな感じで呼び出しています。
const response = await env.AI.run('anthropic/claude-opus-4-6',{
input: 'What is Cloudflare?',
}, {
gateway: { id: "default" },
});
これの何がうれしいかというと、Cloudflare-hosted model から OpenAI や Anthropic のモデルに切り替えるとき、コード変更がほぼ1行で済むことです。
これはかなり強いです。AIアプリ開発で一番面倒なのは、モデルを変えるたびに実装が壊れがちなことなので、ここが薄くなるのは大きい。
さらにWorkersを使っていない人向けには、REST APIも今後提供予定とのこと。
つまり「Cloudflare Workersを使っているかどうか」に関係なく、同じモデル群にアクセスできる方向です。
しかも対応モデルは70+ models across 12+ providers。
Cloudflareはここをどんどん増やしていくようで、Alibaba Cloud、AssemblyAI、Bytedance、Google、InWorld、MiniMax、OpenAI、Pixverse、Recraft、Runway、ViduなどのモデルがAI Gateway経由で使えるようになる、としています。
このラインナップ、かなり攻めています。
特に画像・動画・音声モデルまで含めると言っているのが重要で、単なるLLMの集まりではなく、マルチモーダルAIの基盤を狙っているのが見えます。
AIサービスで地味にきついのが、請求の見通しが悪いことです。
記事では「多くの企業は平均で3.5個のモデルを複数のプロバイダにまたがって使っている」としています。
こうなると、どこでどれだけ使ったかが見えづらい。
しかも、部署ごと、機能ごと、顧客ごとにコストを切り分けたいことも多いです。
Cloudflare AI Gatewayでは、カスタム metadata を付けてリクエストを送ることで、たとえば
といった形でコストを分析できるとしています。
これは実務的にはかなりありがたいはずです。
AIは「使えば使うほど価値が増える」反面、使い方を雑にすると請求が怖い。
だから、最初から可視化の仕組みがあるのは、開発者だけでなく経営側にも効きます。
Cloudflareはさらに、自分でfine-tuneしたモデルや、特定用途向けに最適化したモデルをWorkers AIに持ち込めるようにする計画も出しています。
ここで出てくるのが Replicate の Cog です。
Cogは、機械学習モデルをコンテナ化するための仕組みで、要するに「モデルを動かすための面倒ごとをかなり減らす道具」です。
記事では、
cog.yaml に依存関係を書くpredict.py に推論コードを書くcog build でコンテナイメージを作るという流れが説明されています。
たとえば、Pythonのバージョン、CUDA、モデルの重みの読み込みなど、ML運用で面倒なところをCogが吸収する、という話です。
個人的には、ここはかなり実務者向けの強い一手だと思います。AI基盤は「有名モデルが使える」だけだと差別化が難しいですが、自前モデルを持ち込めると一気に話が変わります。
さらにCloudflareは、これを将来的にもっと簡単にするために、
なども進めると言っています。
cold start は、ざっくり言うと最初の起動が遅い問題です。
GPUを使うモデルではここがネックになりやすいので、snapshotting で速くするのはかなり筋がいいと思います。
記事の中で特に共感したのが、ユーザーが感じる速さは、全体の処理時間ではなく「最初の反応が返ってくるまでの時間」で決まりやすいという指摘です。
たとえ全体で3秒かかっても、最初の1トークンが50ms早く返るだけで、体感はかなり変わります。
これ、チャットやエージェントを触ったことがある人なら感覚的にわかるはずです。
Cloudflareは世界330都市に広がるデータセンター網を持っていて、AI Gatewayをユーザーと推論先の近くに置けるのが強みです。
さらにCloudflare-hosted models は同じネットワーク上で動くので、公共インターネットをまたぐ余計な往復がない。
この「無駄な距離を減らす」思想は、いかにもCloudflareらしいですし、AI時代にもかなり相性がいいと感じます。
AIエージェントは、1回のモデル呼び出しが失敗すると、その後の処理が全部崩れます。
だから、可用性はかなり大切です。
Cloudflare AI Gatewayでは、同じモデルが複数プロバイダで使える場合、あるプロバイダが落ちたら自動で別のプロバイダに切り替えるとしています。
これを自分で実装するのは、地味に面倒です。しかもエラーケースを全部拾う必要があるので、運用もつらい。
さらに、Agents SDK と組み合わせると、長時間動くエージェントでも、ストリーミング応答を途中で切断しても再接続できるようにしています。
AI Gatewayが生成中のストリーミングレスポンスをバッファしておき、エージェントの寿命とは独立して保持するので、途中で止まっても新規の推論をやり直さずに済む。
つまり、同じ出力に二重課金されにくいというのも大きいです。
このあたりは本当に「実運用を知ってる人の設計だな」と思いました。
デモでは目立たないけれど、本番ではここが死活問題になります。
記事の最後のほうでは、ReplicateチームがCloudflareのAI Platformチームに正式に合流したことが明かされています。
CloudflareはReplicateとの統合を進めていて、
方針です。
これは単なるM&A的な話ではなく、「AIモデルの公開・配信・運用」を一体化する流れに見えます。
モデルを作る人、ホストする人、使う人の距離を縮めたいんでしょうね。
この発表は、単に「CloudflareでAIが使えるようになりました」以上の意味があります。
特に効きそうなのはこんな人たちです。
個人的には、Cloudflareがここで狙っているのは、「モデルそのもの」ではなく「モデルを安全に、速く、安く、安定して使う層」だと思います。
これはかなり賢い戦い方です。モデル競争の本丸はOpenAIやGoogleやAnthropicにあっても、その上に乗る“実行基盤”は別の勝ち筋があるからです。
CloudflareのAI Platformは、AIモデルを呼ぶための単なる便利機能ではなく、エージェント時代のための推論レイヤーとして作られています。
モデルを1つに縛らず、コストを見えやすくし、障害時には自動で逃がし、ユーザー体験としての「速さ」まで意識している。
このあたり、かなり本気度が高いです。
AI開発は、派手なモデル選びよりも、最後は運用のうまさで差がつくことが多いです。
Cloudflareはそこに真正面から踏み込んできた、という印象でした。
参考: Cloudflare’s AI Platform: an inference layer designed for agents