Cloudflare Workers AIにKimi K2.5搭載 — フロンティアモデルをエッジで動かす時代

Workers AIがフロンティアモデルの時代に突入した

2026年3月19日、CloudflareはWorkers AIにMoonshot AI社のKimi K2.5を搭載したことを発表しました。256,000トークンのコンテキストウィンドウ、マルチターンのツール呼び出し、ビジョン入力、構造化出力をサポートするこのモデルは、Workers AI史上初の「フロンティア規模」のオープンソースモデルです。

これまでWorkers AIで利用できるモデルは、Llama 3.1 8BやMistral 7Bといった小〜中規模モデルが中心でした。それが今回のKimi K2.5搭載により、プロプライエタリモデルと同等の推論能力をエッジで直接実行できる時代が到来したことになります。京谷商会では、AIスタッフ運用基盤「kuevico」のWorkers AI移行を進めているところであり、Kimi K2.5の登場はまさにその計画を加速させる出来事でした。

この記事では、Kimi K2.5がなぜエージェント開発の転換点になるのか、Cloudflareがどのような基盤整備を行ったのか、そしてWorkers AIの料金体系とコスト効率がどれほど優れているかを、私たちの実運用の視点から解説します。

Kimi K2.5とは何か

Kimi K2.5は、中国のAIスタートアップMoonshot AIが2026年1月27日にリリースしたオープンウェイトの大規模言語モデルです。Mixture of Experts（MoE）アーキテクチャを採用しており、総パラメータ数は約1兆、1リクエストあたりの活性パラメータは320億に抑えられています。384個のエキスパートのうちトークンごとに8個だけが選択的に起動するため、巨大なモデルでありながら推論コストを低く保てる設計です。

Moonshot AIは約15兆トークンのテキストとビジュアルデータを混合して学習させており、テキスト処理と画像理解が最初から統合された「ネイティブマルチモーダルモデル」として設計されています。後から画像理解機能を追加した他のモデルとは根本的にアプローチが異なり、テキストと視覚情報を横断した推論が自然に行えるのが強みです。

主要な性能指標

Kimi K2.5は複数のベンチマークでフロンティアモデルと並ぶ結果を出しています。Humanity's Last Exam（HLE）では50.2%のスコアを達成し、これはClaude Opus 4.5の76%のコストで実現されています。SWE-bench Verifiedではスコア76.8%を記録し、Gemini 3 Proを上回りました。VideoMMMU（86.6%）でもGPT 5.2やClaude Opus 4.5を超える結果を出しており、特にビジョン関連のタスクでの実力が際立っています。

Agent Swarm — 100体のサブエージェントが協調動作

Kimi K2.5の最も特徴的な機能は「Agent Swarm」です。メインのオーケストレータエージェントが複雑なリクエストを受け取ると、最大100体のサブエージェントに分解して並列実行します。各サブエージェントは独立して検索・生成・分析・整理を行い、結果をオーケストレータが統合します。Moonshot AI社によれば、この並列処理により長期ワークフローの実行時間が最大4.5倍短縮されます。

4つの動作モード（Instant・Thinking・Agent・Agent Swarm）を切り替えられる設計は、タスクの複雑さに応じた柔軟な運用を可能にしています。単純な質問応答ならInstant、深い推論が必要ならThinking、ツールを使う実務ならAgent、大規模な調査やバッチ処理ならAgent Swarmという使い分けです。

CloudflareがKimi K2.5のために整備した基盤

Kimi K2.5のような大規模モデルをエッジで安定的に動かすために、Cloudflareは推論基盤そのものを大きく改修しました。ここでは、その技術的な変更点を具体的に見ていきます。

Pull型キューイングシステムへの移行

従来のWorkers AIはPush型のリクエスト処理を採用していました。リクエストが来ればそのまま推論ノードに転送する方式です。しかしフロンティア規模のモデルではGPUリソースの消費が桁違いに大きく、Push型では過負荷が頻発します。

そこでCloudflareはPull型キューイングシステムに移行しました。GPUの空き容量をリアルタイムでモニタリングし、余裕がある場合にのみキューからリクエストを取り出して処理する方式です。同期リクエストが常に優先され、非同期リクエストはGPU利用率が低いタイミングで自動的に処理されるため、リアルタイムの対話体験を損なうことなく大規模なバッチ推論も実行できます。

カスタムカーネルとInfire推論エンジン

CloudflareはKimi K2.5専用のカスタムカーネルを開発し、自社の推論エンジン「Infire」上で動作させています。データ並列化・テンソル並列化・エキスパート並列化を組み合わせたマルチGPU対応により、MoEアーキテクチャのモデルを効率的に実行します。

標準的なオープンソース推論フレームワーク（vLLMなど）でモデルをそのまま動かした場合と比較して、カスタムカーネルはGPU利用効率を大幅に改善します。「モデルをそのまま動かすだけでは見過ごされるパフォーマンスの余地を引き出す」というCloudflareの説明は、自社でハードウェアとソフトウェアの両方を管理している垂直統合の強みを端的に示しています。

Prefix CachingとSession Affinity

長いコンテキストを持つエージェントでは、毎回のリクエストで共通のシステムプロンプトや会話履歴を再処理するのは無駄です。Workers AIのPrefix Cachingは、過去に処理済みのプレフィックス部分をキャッシュし、再計算を省くことでTime to First Token（TTFT）を短縮します。

この機能と組み合わせて使うのがx-session-affinityヘッダです。同一のセッション識別子を送信すると、リクエストが同一モデルインスタンスにルーティングされるため、キャッシュのヒット率が向上します。さらに、キャッシュ済みトークンには割引料金（入力$0.60/Mトークンに対し、キャッシュ済み$0.10/Mトークン）が適用されるため、長い会話を続けるほどコストが下がるという構造になっています。

const response = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
  messages: [
    { role: "system", content: "あなたはコードレビューの専門家です。" },
    { role: "user", content: "このPull Requestのセキュリティリスクを分析してください。" }
  ],
  max_tokens: 2400,
  stream: true
}, {
  headers: {
    "x-session-affinity": "review-session-001"
  }
});

非同期APIの再設計

エージェントの中には、すぐにレスポンスを必要としない処理もあります。コードスキャン、リサーチ、バッチ分析といったワークロードです。Workers AIの非同期APIは、リクエストをキューに投入し、容量が確保されたタイミングで処理する仕組みを提供します。

// 非同期リクエストの投入
const submitResult = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
  requests: [{ messages: [...] }]
}, { queueRequest: true });

// ステータスの確認（通常5分以内に完了）
const statusResult = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
  request_id: submitResult.request_id
});

Cloudflareのブログによれば、非同期リクエストは通常5分以内に実行完了するとされています。Durable Objectsと組み合わせれば、エージェントが非同期処理の完了を待ちつつ他のタスクを並行実行する、といったオーケストレーションも構築できます。

Workers AIの料金体系と圧倒的なコスト効率

Workers AIの課金体系はNeuronと呼ばれるGPUコンピュート量の標準化単位で構成されています。基本レートは$0.011/1,000 Neuronです。無料枠として毎日10,000 Neuronが提供され、UTC 00:00にリセットされます。

Kimi K2.5の具体的なコスト

この料金がどれほど競争力があるかは、Cloudflare自身の社内事例が物語っています。同社のセキュリティチームが運用するコードレビューエージェントは、1日あたり70億トークンを処理し、単一のコードベースから15件の確認済みセキュリティ問題を発見しました。このワークロードを中堅プロプライエタリモデルで実行した場合のコストは年間240万ドルでしたが、Kimi K2.5に切り替えただけで77%のコスト削減を実現しました。

他の選択肢との比較

Workers AIには現在、Kimi K2.5以外にもフロンティア〜大規模モデルが揃っています。

注目すべきは、OpenAIが自社モデルのオープンソース版（GPT-oss）をWorkers AIに提供していることです。出力コストだけを見ればGPT-oss-120Bの$0.75/Mの方がKimi K2.5の$3.00/Mよりも安価ですが、Kimi K2.5は256kの長大なコンテキストウィンドウとビジョン入力のネイティブサポートで差別化されています。用途に応じて使い分けることが重要です。

月間コスト試算

京谷商会のkuevico基盤を例に考えてみましょう。現在、月間推定100万リクエスト規模のAIスタッフ運用を行っています。Workers AIで月間100万リクエストを処理した場合の推定コストは$150〜$400で、これに対してVercel + OpenAI APIの組み合わせでは$800〜$2,000になります。Workers AIが構造的に3〜5倍のコスト効率を持つ計算です。

エージェント開発のプラットフォームとしてのCloudflare

Kimi K2.5の搭載は単なるモデル追加ではなく、Cloudflareが「エージェント開発プラットフォーム」として自らを位置づける戦略の中核にあります。

エージェントの実行には推論だけでは足りません。永続的な状態管理（Durable Objects）、データベース（D1）、ファイルストレージ（R2）、ルーティングと監視（AI Gateway）、そしてメール処理（Email Routing）まで、エージェントのライフサイクル全体を支えるインフラが必要です。Cloudflareはこれらすべてを単一のプラットフォーム上で提供しており、Workers AIはその推論レイヤーとして機能します。

京谷商会が運用するkuevico基盤は、まさにこの垂直統合の恩恵を受けています。D1にスタッフ情報とタスクを保存し、R2にメディアファイルを格納し、Workersでビジネスロジックを実行し、Email RoutingとBrevoでメール送受信を処理しています。ここにWorkers AIの推論能力が加わることで、外部のAI APIに依存する部分を段階的に内製化し、コストとレイテンシの両面で改善できる見通しです。

Agents SDKとの連携

Cloudflareが公開しているAgents SDK Starterは、すでにデフォルトモデルとしてKimi K2.5を採用しています。Workers上で動作するエージェントのテンプレートで、Durable Objectsによるステート管理、ツール呼び出し、ストリーミング応答をすぐに利用できます。

kuevico基盤のWorkers AI移行計画において、このAgents SDKは検証の起点となります。既存のAnthropic API依存を、まずは特定のタスク（分類・要約・定型的な回答）からWorkers AI上のモデルに置き換え、段階的に移行範囲を広げていく方針です。

kuevico基盤から見たKimi K2.5の実用的な価値

京谷商会では、93名のAIスタッフが日々の業務を遂行するkuevico基盤を運用しています。この基盤をWorkers AIに移行するにあたり、Kimi K2.5は以下の点で特に有用だと考えています。

まず、256kトークンのコンテキストウィンドウは、AIスタッフが長い会話履歴やドキュメント全体を保持しながら作業する用途に適しています。記事の12ステップパイプラインでは、SEO分析・構成案・初稿・レビューという一連の文脈をモデルが保持し続ける必要があり、256kは十分な容量です。

次に、マルチターンのツール呼び出しは、D1へのクエリ実行、R2へのファイル操作、外部API呼び出しといったkuevico基盤の中核操作をモデルが自律的に実行するための基盤機能です。Kimi K2.5の構造化出力サポートと合わせて、エージェントが正確なJSON形式でツール呼び出しの引数を生成できます。

そして、77%のコスト削減という実績は、2,000名規模への拡張を見据えるkuevico基盤にとって決定的に重要です。現在の93名体制から2,000名体制への移行では、AIスタッフ1名あたりの推論コストがスケーラビリティの鍵を握ります。Workers AIのNeuron課金モデルであれば、月間コストを予測可能な範囲に収められます。

エッジ推論がもたらす構造的な変化

Kimi K2.5のWorkers AI搭載が示す大きなトレンドは、「フロンティアモデルの実行場所がクラウドの中央データセンターからエッジに移動しつつある」ということです。

従来、フロンティア規模のモデルを実行するにはNVIDIAのH100/H200 GPUを大量に備えたデータセンターが必要でした。OpenAIやAnthropicのAPIを呼び出すと、リクエストは限られた地域のデータセンターに送られ、結果が返ってくるまでの物理的な距離がレイテンシに影響します。

Workers AIのアプローチは異なります。200以上の都市にGPUを配置し、ユーザーに最も近いエッジロケーションで推論を実行します。8Bモデルの実測パフォーマンスは80 TPS以上、TTFT 300msです。カスタムカーネルとPrefix Cachingの最適化により、大規模モデルでも実用的なレイテンシを実現しています。

企業のAI導入が進むにつれて、従業員ひとりひとりが複数のエージェントを常時稼働させ、時間あたり数十万トークンを処理する時代が近づいています。そうなると、プロプライエタリモデルの料金体系は現実的ではなくなります。Workers AIのようなエッジ推論プラットフォームとオープンソースモデルの組み合わせが、スケーラブルなAI活用の標準になっていくでしょう。

Kimi K2.5を使い始めるには

Workers AIでKimi K2.5を利用する方法は3つあります。

Workers Bindingを使う場合は、Workerのコード内でenv.AI.run("@cf/moonshotai/kimi-k2.5", { messages: [...] })を呼び出します。REST APIの場合はhttps://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/moonshotai/kimi-k2.5にPOSTリクエストを送信します。OpenAI互換エンドポイント（/v1/chat/completions）もサポートされており、既存のOpenAI SDKをそのまま利用できます。

主要なAPIパラメータとして、temperatureは0〜2の範囲（デフォルト1）、top_pは0〜1の範囲（デフォルト1）、max_tokensで出力トークン数の上限を設定できます。また、AI Gatewayを経由すれば、リクエストのログ・分析・キャッシング・レート制限を一元管理でき、プロバイダ間のフォールバック設定も可能です。

レート制限は全モデル共通で300リクエスト/分です。開発・テスト段階では毎日の無料枠（10,000 Neurons）で十分に検証でき、本番運用に移行した後もNeuronベースの従量課金で予測可能なコスト管理が可能です。

まとめ

Workers AIへのKimi K2.5搭載は、エッジ推論の成熟を示す節目です。フロンティア規模のオープンソースモデルがサーバーレスのエッジプラットフォームで実行でき、プロプライエタリモデルと比較して77%のコスト削減が実証されています。

256kコンテキスト、マルチターンツール呼び出し、ビジョン入力、構造化出力というKimi K2.5の機能セットは、エージェント開発に必要な要件を網羅しています。Cloudflareが整備したPull型キューイング、カスタムカーネル、Prefix Caching、Session Affinityという基盤技術は、大規模モデルをエッジで安定的に動かすために不可欠な土台です。

京谷商会のkuevico基盤にとって、Kimi K2.5はWorkers AI移行の最有力候補のひとつです。93名から2,000名へのスケーリングを見据えたとき、エッジ推論のコスト効率と垂直統合プラットフォームの利便性は、他のどの選択肢よりも魅力的です。AIの1Mコンテキスト時代に、推論インフラもまた大きく進化しつつあります。