Cloudflare、Workers AIにKimi K2.5を投入　内部agentコスト77%削減事例を公開

XでCloudflareが示した内容

2026年3月20日、CloudflareはKimi K2.5がWorkers AIで利用可能になったと発表し、開発者がCloudflare Developer Platform上でagentをend-to-endに構築・実行できると打ち出した。投稿は同時に、内部agent workload向けにinference stackをどう最適化したかも読むよう促している。

ここで重要なのは、Cloudflareが単に新しいmodel endpointを1つ増やしたわけではないことだ。同社はWorkers AIを、Durable Objects、Workflows、Dynamic Workers、Sandboxといった既存primitivesと結びついた広いagent runtimeのmodel layerとして位置づけている。

Cloudflare blogが加えた詳細

3月19日のCloudflare blogによれば、Workers AIは大規模model層へ進み、その第一弾としてMoonshot AIのKimi K2.5を提供する。Cloudflareはこのmodelについて、256K context window、multi-turn tool calling、vision input、structured outputを備え、agent workloadに適したopen large modelだと説明している。

最も具体的なのは内部運用データだ。Cloudflareは、エンジニアがOpenCodeでagentic codingにKimiを使い、公開リポジトリ向けのBonk code review agentにも導入していると述べる。あるsecurity review use caseでは、このagentが1日あたり7B token超を処理し、単一codebaseで15件超のconfirmed issueを発見したという。同社は、このworkloadを中位のproprietary modelで回すと年間およそ240万ドルになる一方、Workers AIへ切り替えることでコストを77%下げたとしている。

加えて、agent traffic向けのplatform改善も公開した。cached tokenをusage metricとして可視化し、fresh input tokenより安価に扱う仕組みを追加したほか、prefix cache hit rateを高めるx-session-affinity headerを導入した。さらに、research agentやcode scanning agentのような耐久的 workload向けにasynchronous APIも刷新している。

なぜ重要か

より大きなシグナルは技術そのものよりeconomicsにある。チームが単発promptから、常時動くcoding・search・security agentへ進むと、model availabilityより先にinference costがスケール制約になる。Cloudflareは、大規模open modelとserving最適化を組み合わせれば、そのコスト障壁を現実的に下げられると主張している。

もしその主張が実運用でも成り立つなら、競争の中心はmodel単体の性能からinfrastructureへ移る。cache挙動、async execution、throughput tuning、そしてruntime全体との統合度がagent platformの差別化要因になるということだ。

出典: Cloudflare X投稿 · Cloudflare blog