DeepSeek V4 Pro / Flash が Workers AI に — プラットフォーム初の 100万トークンコンテキスト

要約

2026-08-14、Cloudflare が Workers AI に DeepSeek V4 の2モデルを追加しました。

• DeepSeek V4 Pro: @cf/deepseek-ai/deepseek-v4-pro-0813
• DeepSeek V4 Flash: @cf/deepseek-ai/deepseek-v4-flash-0731

告知の中心は**コンテキストウィンドウ 1,048,576 トークン（100万トークン）**です。Cloudflare は、Workers AI プラットフォーム上でこの容量に達した最初のモデルだとしています。機能面では、複雑な問題向けの reasoning モード、多ターンのエージェントワークフロー向けの function calling、大規模なコードベースを扱うための拡張コンテキストに対応します。

Pro と Flash の関係は、Flash が Pro の「より速く、より低コストな兄弟」という位置づけです。性能面のトレードオフがあることは示唆されていますが、具体的な比較指標は本告知に含まれていません。どちらを選ぶかは、実際のタスクで両方を試して判断する必要があります。

見落としやすいのが利用条件です。Workers Paid プラン、または AI Gateway のプリペイドクレジットが要ります。Workers AI の無料枠だけでは試せません。個別の価格はモデルドキュメント側に記載されています。

何が変わったか

• Workers AI で @cf/deepseek-ai/deepseek-v4-pro-0813 と @cf/deepseek-ai/deepseek-v4-flash-0731 を指定できるようになった
• どちらもコンテキストウィンドウは 1,048,576 トークン。Workers AI 上では初
• reasoning モード（複雑な問題向け）と function calling（多ターンのエージェントワークフロー向け）に対応
• 利用には Workers Paid プラン、または AI Gateway のプリペイドクレジットが必要
• Flash は Pro より高速・低コストと位置づけられるが、性能差の具体的な数値は未公表

業務インパクト（一般企業向け）

エッジ実行と長いコンテキストが両立するようになったという点が、この更新の実質です。

これまで「大きなコンテキストを扱いたい」という要件が出たとき、選択肢は外部の大手モデル API を呼ぶことに寄っていました。Workers AI で完結できる範囲は、比較的短いコンテキストのタスクに限られていたためです。今回の追加で、リクエストの処理場所を Cloudflare のエッジに置いたまま、100万トークン級の入力を扱える構成が取れるようになります。データの経路が増えないぶん、通信先の管理や契約の本数を抑えられる組織にとっては意味があります。

一方で、容量が増えたことを「全部入れてよい」と読み替えるのは危険です。100万トークンを毎回埋めれば、当然そのぶんのコストがかかります。加えて、入力が長くなるほど関係のない情報が混ざり、出力の精度が落ちる方向に働きます。「入る」ことと「入れるべき」ことは別の判断であり、必要な情報を選んで渡す設計は、コンテキストが広がった後もそのまま必要です。むしろ広い枠を持つモデルほど、雑に使ったときのコスト差が大きく出ます。

導入判断で先に確認すべきは料金体系です。Workers Paid か AI Gateway のプリペイドクレジットが前提なので、「まず無料枠で試してから稟議を上げる」という進め方ができません。検証段階から費用が発生することを織り込んで、小さく試す範囲を決めておく必要があります。

Pro / Flash の使い分けは、他ベンダーの階層と同じ考え方で構いません。Gemini の Flash / Pro、Claude の Haiku / Sonnet / Opus と同様に、品質重視の系統と速度・コスト重視の系統が並ぶ構造です。判断の型としては、まず安い方で通るかを試し、通らないタスクだけ上位へ回す。今回は公式が性能差の数値を出していないため、この試行を自前でやる前提になります。

副業・個人活用視点

個人で触る場合も、Workers Paid が必要という点が最初のハードルです。Cloudflare の AI 機能は無料で試せるものと、有料プラン前提のものが混在しており、今回は後者にあたります。Workers AI を触ったことがある人ほど「無料枠で動くはず」と思い込みやすいので、先に確認しておくと詰まりません。

活用の切り口として現実的なのは、大きな入力をまとめて処理する系の自動化です。長い議事録、まとまった量のドキュメント、規模のあるコードベースといった対象を、Workers 上のエンドポイントで受けて処理する構成が組めます。エッジで完結するぶん、サーバーを持たずに動かせる範囲が広がります。

案件として拾うなら、「長いコンテキストをどう使うか」の設計そのものが仕事になります。100万トークン入るという事実は分かりやすいぶん、「じゃあ全部入れてください」という要望に繋がりがちです。そこで、必要な部分だけを抽出して渡す設計と、全部入れる設計のコストと精度を実測して比べてみせると、判断材料として通ります。容量の大きさを売るのではなく、使い方の設計を売る方が結果的に価値が出ます。

発信のネタとしては、Pro と Flash の実測比較が空いています。公式が性能差の数値を出していないため、同じタスクを両方に投げて出力とレイテンシとコストを並べるだけで、まだ誰も書いていない情報になります。エッジで動くモデルのコンテキスト長という切り口も、大手モデルの話に比べて記事が少ない領域です。