エージェントを強化：Workers AIが大規模モデルの実行を開始、まずはKimi K2.5から

openaijamodel: gpt-5-mini-2025-08-07

公開日: 2026-03-19

我々はCloudflareをエージェントの構築とデプロイに最適な場所にするための取り組みを続けています。しかし、信頼できるエージェントはプロンプトだけで成り立つものではなく、基盤となるプリミティブの堅牢で協調されたインフラストラクチャが必要です。Cloudflareでは数年来これらのプリミティブを構築してきました：Durable Objects（状態永続化）、Workflows（長時間タスク）、Dynamic WorkersやSandboxコンテナ（安全な実行）などです。Agents SDKのような高レベル抽象は、Cloudflareの開発者プラットフォーム上でエージェントを構築するのに役立ちますが、これらのプリミティブは実行環境を提供するにとどまり、エージェントを動かすためのモデル自体も必要でした。

本日より、Workers AIは正式に大規模モデルのサポートを開始します。現在、AI推論プラットフォーム上でフロンティアクラスのオープンソースモデルを提供しており、まず Moonshot AI の Kimi K2.5 モデルを Workers AI 上で公開します。256k のフルコンテキストウィンドウと、マルチターンのツールコール、ビジョン入力、構造化出力への対応を備えた Kimi K2.5 は、あらゆる種類のエージェントタスクに非常に適しています。フロンティア規模のモデルを Cloudflare Developer Platform に直接組み込むことで、エージェントのライフサイクル全体を単一の統合プラットフォーム上で実行できるようにします。

エージェントの核はそれを動かすAIモデルであり、そのモデルは高い推論能力と大きなコンテキストウィンドウを備えている必要があります。Workers AI はこれらのモデルを実行します。

価格とパフォーマンスの最適点

過去数週間、我々は社内開発ツールのエンジンとして Kimi K2.5 をテストしてきました。OpenCode 環境内で、Cloudflare のエンジニアは日常的に Kimi をエージェント的なコーディングタスクのデイリードライバーとして使用しています。また、モデルを自動コードレビューパイプラインにも組み込みました。これは Cloudflare GitHub リポジトリ上で公開されているコードレビューエージェント Bonk の動作で確認できます。

本番運用では、Kimi は品質を損なうことなく、より大きなプロプライエタリモデルに対する高速で効率的な代替手段として実証されました。Kimi K2.5 の提供は実験から始まりましたが、モデルの性能とコスト効率を確認するうちに重要な存在になりました。

例として：Cloudflare のコードベースのセキュリティレビューを行うエージェントがあります。このエージェントは1日あたり70億（7B）トークン以上を処理し、Kimi を使うことで単一のコードベースで15件以上の確定した問題を発見しました。概算すると、もしこのエージェントをミッドティアのプロプライエタリモデルで実行していたら、この単一ユースケース、単一コードベースで年間240万ドル（$2.4M）を費やしていたことになります。Kimi K2.5 を使った運用では、その費用はごく一部にとどまり、Workers AI に切り替えることでコストを77%削減しました。

AI の採用が進むにつれて、エンジニアリングチームだけでなく個人単位の運用にも根本的な変化が起きています。OpenClaw のような個人用エージェントが24時間稼働するケースが増え、推論ボリュームは急増しています。個人やコーディングエージェントの台頭により、コストはもはや二次的な懸念ではなく、スケーリングの主たる阻害要因になっています。従業員一人当たり複数のエージェントが毎時数十万トークンを処理する状況では、プロプライエタリモデルのコストモデルは成り立たなくなります。企業は、プロプライエタリな価格帯を伴わないフロンティアレベルの推論を提供するオープンソースモデルへ移行を検討するでしょう。Workers AI はこの移行を支援し、個人エージェント向けのサーバーレスエンドポイントから組織全体を動かす自律エージェント向けの専用インスタンスまでを提供します。

大規模モデル推論スタック

Workers AI はローンチ以来2年間モデル（LLM を含む）を提供してきましたが、これまでは比較的小さなモデルを優先してきました。理由の一部は、オープンソースの LLM が長らくフロンティアのモデル群に比べて劣っていたためです。しかし Kimi K2.5 のようなモデルの登場により状況は変わりました。こうした非常に大きな LLM を提供するには、推論スタックに変更を加える必要がありました。以下は、Kimi のようなモデルを支えるために我々が行った取り組みの一部です。

Kimi K2.5 向けにカスタムカーネルを開発し、我々の独自の Infire 推論エンジン上でモデルの提供を最適化しています。カスタムカーネルはモデルの性能と GPU 利用率を改善し、素の状態で実行しただけでは得られない性能上の恩恵を引き出します。
大規模モデルを提供するためには、データ並列、テンソル並列、エキスパート並列（Mixture of Experts 等）の組み合わせが一般的に用いられます。
「disaggregated prefill」のような戦略（prefill と generation を別マシンで分離し、スループットや GPU 利用率を改善する方法）も重要です。

これらの手法を実装して推論スタックに組み込むには多くの専門的な経験が必要です。Workers AI は Kimi K2.5 上で優れたスループットを得るための実験を既に行っており、セルフホストしただけでは得られない最適化を提供します。プラットフォームを使う利点は、モデルをホストするための最適化作業を行うために機械学習エンジニア、DevOps、SRE である必要がないことです。我々が難しい部分を既にやっているので、あなたは API を呼び出すだけで済みます。

モデル以外 — エージェントワークロード向けのプラットフォーム改善

このローンチに合わせて、プラットフォームの改善とエージェント構築を助けるいくつかの新機能をリリースします。

プレフィックスキャッシュ（prefix caching）とキャッシュ済みトークンの可視化

エージェントでは、システムプロンプト、ツール定義、MCP サーバーツール、またはコードベース全体など、大量の入力トークンをコンテキストとして送ることが多いです。入力はモデルのコンテキストウィンドウいっぱい（理論上はほぼ256kトークン）になることもあります。

LLM がリクエストを処理する際、処理は通常2段階に分かれます：prefill（入力トークンの処理）と generation（出力トークンの生成）。これらは通常直列で行われ、入力トークンが完全に処理されるまで出力生成は始まりません。そのため、prefill 処理中は GPU がフル活用されないことがあります。

マルチターン会話では、新しいプロンプトを送る際にクライアントはセッション内の以前のプロンプト、ツール、コンテキストをすべてモデルに送ります。連続するリクエスト間の差分は通常数行程度の新しい入力だけであり、他のコンテキストは以前のリクエストで既に prefill を通過しています。ここでプレフィックスキャッシュが役に立ちます。

以前のリクエストからの入力テンソルをキャッシュしておき、毎回リクエスト全体で prefill を行う代わりに新しい入力トークンだけを prefill することで、prefill ステージの時間と計算を大幅に節約できます。これにより Time to First Token（TTFT）が速くなり、Tokens Per Second（TPS）のスループットも向上します。

Workers AI は常に prefix caching を行ってきましたが、今回からキャッシュ済みトークンを使用量メトリクスとして可視化し、入力トークンに比べてキャッシュ済みトークンに対する割引を提供します（価格はモデルページで確認してください）。また、キャッシュヒット率を高めてコストを削減するための新しいテクニックも提供しています。

キャッシュヒット率向上のための新しいセッションアフィニティヘッダー

同じモデルインスタンスへルーティングし prefix caching を活かすために、新しい x-session-affinity ヘッダーを導入しています。このヘッダーを付与するとキャッシュヒット率が改善され、より多くのキャッシュ済みトークン、より高速な TTFT と TPS、そして低い推論コストが得られます。セッションごとまたはエージェントごとにユニークな文字列を指定してヘッダーを渡してください。一部クライアント（OpenCode 等）は自動的にこれを実装しています。Agents SDK のスターターもこの配線を既に設定済みです。

以下のようにヘッダーを渡せます。

curl -X POST \
  "https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/moonshotai/kimi-k2.5" \
  -H "Authorization: Bearer {API_TOKEN}" \
  -H "Content-Type: application/json" \
  -H "x-session-affinity: ses_12345678" \
  -d '{ "messages": [ { "role": "system", "content": "You are a helpful assistant." }, { "role": "user", "content": "What is prefix caching and why does it matter?" } ], "max_tokens": 2400, "stream": true }'

非同期APIの再設計

サーバーレス推論は非常に難しい領域です。トークン課金モデルでは、各リクエストごとに全ての GPU を占有して支払う必要がないため単一リクエストではコストが安くなりますが、他者のトラフィックや容量制約に直面し、リクエスト処理が保証されないというトレードオフがあります。これは Workers AI に特有の問題ではなく、サーバーレスモデル提供者一般で見られる課題です。

我々は常にリクエスト処理に努め、自動スケーリングとリバランスを組み込んでいますが、ハードウェアなどの制約により限界はあります。同期レート制限を超えるボリュームのリクエストについては、バッチではなく非同期的に完了させるためにキューイングすることができます。今回、非同期 API を改良し、非同期ユースケースにおいて Out of Capacity エラーに遭遇しにくい耐久的な実行を実現しました。

我々の非同期 API はバッチ API というよりフレックス処理に近く、モデルインスタンスに余裕がある限り非同期キュー内のリクエストを処理します。内部テストでは非同期リクエストは通常5分以内に実行されますが、実際の待ち時間はライブトラフィック状況に依存します。Kimi の公開に合わせてスケーリング調整を行いますが、非同期 API は容量エラーを回避して耐久的なワークフローを実現する最良の方法です。これはコードスキャンエージェントや研究エージェントなど、リアルタイム性を必要としないユースケースに最適です。

過去の Workers AI でも非同期 API は存在しましたが、今回内部システムを刷新しました。従来の push ベースから pull ベースの仕組みに移行し、キャパシティが確保できるとすぐにキュー内リクエストをプルして処理できるようにしています。また、非同期リクエストのスループットを調整するための制御を追加し、GPU 利用率をリアルタイムで監視して利用率が低いときに非同期リクエストを取り込み、重要な同期リクエストに優先度を与えつつ非同期処理も効率的に行います。

非同期 API の使い方は以下の通りです。イベント通知を設定して、ポーリングせずに推論完了を通知させることもできます。

// (1.) Push a request in queue
// pass queueRequest: true
let res = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
  "requests": [{ "messages": [{ "role": "user", "content": "Tell me a joke" }] }, { "messages": [{ "role": "user", "content": "Explain the Pythagoras theorem" }] }, ...{"<add more requests in a batch>"}];
}, { queueRequest: true, });

// (2.) grab the request id
let request_id;
if(res && res.request_id){
  request_id = res.request_id;
}

// (3.) poll the status
let res = await env.AI.run("@cf/moonshotai/kimi-k2.5", { request_id: request_id });
if(res && res.status === "queued" || res.status === "running") {
  // retry by polling again ...
} else return Response.json(res); // This will contain the final completed response

本日から利用可能です

Kimi K2.5 を Workers AI で今すぐ試してみてください。開発者向けドキュメントで詳細を確認できます（元記事はここで途切れています）。

Powering the agents: Workers AI now runs large models, starting with Kimi K2.5

要約

Summary

Key Points