CloudflareのAIプラットフォーム：エージェント向けに設計された推論レイヤー

AIモデルは急速に進化しています：今日エージェント型コーディング（agentic coding）に最適なモデルが、3ヶ月後には全く異なるプロバイダーの別モデルになっている可能性があります。さらに、実際のユースケースでは複数のモデルを呼び出す必要があることがよくあります。カスタマーサポートエージェントは、ユーザーのメッセージを分類するために高速で低コストなモデルを使用し、行動計画を立てるために大規模な推論モデル（reasoning model）を、個々のタスクを実行するために軽量なモデルを使用するかもしれません。

つまり、単一のプロバイダーに金銭的・運用面で縛られることなく、すべてのモデルにアクセスできる環境が必要です。また、プロバイダー間でコストを監視し、いずれかのプロバイダーに障害が発生した際の信頼性を確保し、ユーザーの場所に関わらずレイテンシ（latency）を管理するための適切なシステムを整備することも不可欠です。

これらの課題はAIを活用した開発において常に存在しますが、エージェント（agents）を構築する際にはさらに緊急性が増します。シンプルなチャットボットは、ユーザーのプロンプトごとに1回の推論呼び出し（inference call）を行うだけで済みますが、エージェントは単一のタスクを完了するために10回の呼び出しをチェーンする可能性があります。すると、単一のプロバイダーの遅延が50msではなく500ms追加されることになります。1回の失敗したリクエストは単なる再試行で済むはずですが、突然、下流の障害が連鎖する事態に陥ります。

AI GatewayとWorkers AIのリリース以来、Cloudflare上でAI搭載アプリケーションを構築する開発者から素晴らしい採用実績を得ており、追いつくために高速でリリースを続けてきました！過去数ヶ月の間に、ダッシュボードを更新し、セットアップ不要のデフォルトゲートウェイ（default gateways）を追加し、アップストリーム障害時の自動リトライ機能とより細粒度なログ制御（logging controls）を導入しました。本日、Cloudflareを統一された推論レイヤー（unified inference layer）へと進化させます。あらゆるプロバイダーのAIモデルにアクセスできる単一APIであり、高速かつ信頼性の高い構築を目指しています。

1つのカタログ、1つの統一エンドポイント

今日から、すでにWorkers AIでご利用いただいている同じAI.run()バインディング（AI.run() binding）を使用して、サードパーティ製モデルを呼び出すことができます。Workersをご利用の場合、Cloudflareホスト型モデルからOpenAI、Anthropic、またはその他のプロバイダーのモデルへ切り替えるのは、1行の変更で済みます。

const response = await env.AI.run('anthropic/claude-opus-4-6',{
input: 'What is Cloudflare?',
}, {
gateway: { id: "default" },
});

Workersをご利用でない方も、今後数週間以内にREST APIサポート（REST API support）をリリースする予定です。これにより、あらゆる環境からフルモデルカタログにアクセスできるようになります。

また、12以上のプロバイダーにまたがる70以上のモデルにアクセスできるようになったことをご報告できることを嬉しく思います。これらはすべて単一APIで、モデル間の切り替えは1行のコードで、支払いには単一のクレジット体系を使用します。さらに、私たちは進行中にこれを急速に拡大しています。

ユースケースに最適なモデルをお探しの方は、Cloudflare Workers AI上でホストされているオープンソースモデル（open-source models）から、主要なモデルプロバイダーが提供する独自モデル（proprietary models）まで、当社のモデルカタログから閲覧して選定できます。Alibaba Cloud、AssemblyAI、Bytedance、Google、InWorld、MiniMax、OpenAI、Pixverse、Recraft、Runway、Viduからのモデル提供をAI Gatewayを通じて拡大できることを嬉しく思います。特筆すべきは、画像・動画・音声モデルも提供範囲に追加し、マルチモーダルアプリケーション（multimodal applications）の構築が可能になった点です。

image

1つのAPIを通じてすべてのモデルにアクセスできるということは、AIコスト（AI spend）を一元管理できることを意味します。現在、多くの企業は複数のプロバイダーから平均3.5種類のモデルを呼び出しており、どの単一プロバイダーもAI利用状況を包括的に把握することはできません。AI Gatewayを利用すれば、AIコストの監視と管理を行うための一元化されたプラットフォームが得られます。

リクエストにカスタムメタデータ（custom metadata）を含めることで、無料ユーザーと有料ユーザーの支出、個別顧客、アプリ内の特定のワークフロー（workflows）など、最も関心の高い属性に基づいたコスト内訳を取得できます。

const response = await env.AI.run('@cf/moonshotai/kimi-k2.5',

{

prompt: 'What is AI Gateway?'

},

{

metadata: { "teamId": "AI", "userId": 12345 }

}

);

image

Bring your own model

AI Gatewayは、1つのAPIを通じてすべてのプロバイダーのモデルにアクセスできる機能を提供します。ただし、独自のデータでファインチューニング（fine-tuned）されたモデルや、特定のユースケースに最適化されたモデルを実行する必要がある場合もあります。そのために、当社はユーザーが独自モデルをWorkers AIに持ち込むことができるよう開発を進めています。

当社のトラフィックの圧倒的多数は、プラットフォーム上でカスタムモデルを実行するエンタープライズ顧客（Enterprise customers）向けの専用インスタンス（dedicated instances）から発生しており、この機能をより多くの顧客に提供したいと考えています。そのために、機械学習モデルのコンテナ化（containerize）を支援するReplicateのCog技術を活用しています。

Cogは非常にシンプルに設計されています。cog.yamlファイルに依存関係を記述し、Pythonファイルに推論コード（inference code）を記述するだけです。Cogは、CUDA依存関係（CUDA dependencies）、Pythonのバージョン、重み読み込み（weight loading）など、MLモデルのパッケージ化（packaging ML models）に関する複雑な処理をすべて抽象化しています。

cog.yamlファイルの例:

build:

python_version: "3.13"

python_requirements: requirements.txt

predict: "predict.py:Predictor"

predict.pyファイルの例（モデルの設定を行う関数と、推論リクエスト（予測）を受信した際に実行される関数を備えたファイル）:

from cog import BasePredictor, Path, Input

import torch

class Predictor(BasePredictor):

def setup(self):

"""複数の予測を効率的に実行するためにモデルをメモリに読み込む"""

self.net = torch.load("weights.pth")

def predict(self,

image: Path = Input(description="拡大する画像"),

scale: float = Input(description="画像を拡大する倍率", default=1.5)

) -> Path:

"""モデルに対して単一の予測を実行する"""

# ... 前処理 ...

output = self.net(input)

# ... 後処理 ...

return output

次に、cog buildコマンドを実行してコンテナイメージをビルドし、CogコンテナをWorkers AIにプッシュできます。モデルのデプロイとサービングは当社が行い、その後、通常のWorkers AI APIを通じてアクセスしていただけます。

さらに、より多くの顧客にこの機能を提供できるよう、カスタマー向けAPIやwranglerコマンド（wrangler commands）の実装、およびGPUスナップショット（GPU snapshotting）によるコールドスタートの高速化といった大規模プロジェクトに取り組んでいます。Cloudflare社内チームや、当社のビジョンを導いてくれる外部顧客数名を対象に内部テストを実施しており、もし設計パートナーとしてご興味がある場合はお気軽にお問い合わせください。まもなく、誰でもモデルをパッケージ化し、Workers AIを通じて利用できるようになります。

初回トークン到達時間の高速化

AI GatewayとWorkers AIモデルを組み合わせることは、特にリアルタイムエージェント（live agents）の構築において強力です。これはユーザーが速度を認識する基準が、完全な応答にかかる時間ではなく、初回トークン到達時間（time to first token）やエージェントが応答を始める速さに依存するためです。全体の推論に3秒かかっても、最初のトークンを50ms早く取得できれば、キビキビとしたエージェントと重たいエージェントとの違いが生じます。

世界中の330都市に展開するCloudflareのデータセンターネットワークにより、AI Gatewayはユーザーと推論エンドポイント（inference endpoints）の両方に近接した位置に配置され、ストリーミング開始前のネットワーク時間を最小限に抑えています。

Workers AIの公開カタログにはオープンソースモデル（open-source models）もホストされており、現在ではKimi K2.5やリアルタイム音声モデル（real-time voice models）など、エージェント用に特別に設計された大規模モデルが含まれています。これらのCloudflareホスト型モデルをAI Gateway経由で呼び出す場合、コードと推論が同じグローバルネットワーク上で実行されるため、パブリックインターネットを介した追加のホップが発生せず、エージェントに可能な限り低いレイテンシを提供します。

自動フェールオーバーによる信頼性の構築

エージェントを構築する際、速度がユーザーが気にする唯一の要素ではありません。信頼性も重要です。エージェントワークフローのすべてのステップは、その前のステップに依存しています。1つの呼び出しが失敗すると全体の後続チェーンに影響を与える可能性があるため、信頼性の高い推論はエージェントにとって不可欠です。

AI Gatewayを通じて、複数のプロバイダーで利用可能なモデルを呼び出している際に1つのプロバイダーがダウンした場合、独自のフェールオーバーロジック（failover logic）を記述する必要なく、自動的に他の利用可能なプロバイダーへルーティングされます。

Agents SDKを使用して長時間実行されるエージェントを構築している場合、ストリーミング推論呼び出し (streaming inference calls) も切断 (disconnects) に対して耐性があります。AI Gatewayはエージェントの存続期間とは無関係に、生成されるストリーミング応答をバッファリングします。推論中にエージェントが中断された場合、AI Gatewayに再接続して応答を取得でき、新しい推論呼び出しを行う必要も、同じ出力トークン (output tokens) に対して二度課金されることもありません。Agents SDKの組み込みチェックポイント機能 (checkpointing) と組み合わせることで、エンドユーザーはこれらの事象に気づくことなく利用できます。

Replicate

Replicateチームは正式に当社のAI Platformチームに統合され、もはや別々のチームとして区別することすらなくなりました。ReplicateとCloudflare間の統合作業に注力しており、その一環としてすべてのReplicateモデルをAI Gatewayへ移行し、ホストされているモデルをCloudflareインフラストラクチャ (Cloudflare infrastructure) 上で再プラットフォーム化しています。まもなく、Replicateで愛用していたモデルをAI Gateway経由でアクセスできるようになるだけでなく、ReplicateにデプロイしたモデルをWorkers AI上でホストすることも可能になります。

はじめる

使い始めるには、AI GatewayまたはWorkers AIのドキュメントをご覧ください。Agents SDKを通じてCloudflare上でエージェントを構築する方法について詳しく学びましょう。

Cloudflare TVで視聴