Cloudflare Workers AIはクラウドGPUではない。81モデルとローカルAIをつなぐ実践設計
「Cloudflareでも、クラウドGPUのように好きなモデルを動かせるのだろうか」
Workers AIを知ったとき、まず浮かびやすい疑問です。Cloudflareは世界規模のネットワークを持ち、AIモデルも多数提供しています。しかも、文章生成だけでなく、音声認識、画像生成、埋め込み、リランキングまで扱えます。そう聞くと、GPUサーバーを借りるサービスのようにも見えます。
しかし、実際の位置づけは違います。Workers AIは、GPUへ自由にログインして好きなDockerやモデルを置く場所ではありません。用意されたAIモデルを呼び出し、検索、データ保存、長時間処理、エージェント、予算管理、安全対策まで組み合わせて、AI機能を本番運用するための基盤です。
この違いを理解すると、Workers AIの価値が急に見えやすくなります。ローカルAIを捨てて全面移行する必要もありません。手元のMacで動くモデル、Cloudflare上の大規模モデル、OpenAIやAnthropicなどの外部モデルを、一つの入口から使い分ける構成も取れます。
この記事では、2026年8月4日時点のCloudflare公式資料とモデルカタログをもとに、Workers AIで何ができるのか、何ができないのか、81モデルをどう見るか、料金と制限をどう考えるか、ローカルAIとどうつなぐか、そして個人や企業がどこから始めるべきかを、実務で使える形に整理します。
Kimi and GLM are some of the best open models available. They're also some of the hardest to serve efficiently. Check out this writeup to learn how we're making them faster and cheaper without losing accuracy.https://t.co/X1ak2QsGeC
— Cloudflare Developers (@CloudflareDev) August 3, 2026
モデル数、料金、提供状態、コンテキスト長は変わります。この記事では確認日を明記し、導入時には利用するモデルカードと料金ページを再確認する前提で説明します。
Workers AIはモデルAPIではなくAIを動かす基盤
Cloudflare Workers AIは、単なる「LLMをAPIで呼ぶサービス」ではありません。Cloudflare上の関連機能を組み合わせることで、推論、モデルの振り分け、社内文書検索、エージェント、音声・画像処理、ブラウザ操作、非同期ジョブ、データ保存、安全管理、コスト統制までを一つの基盤上に構築できます。
2026年8月4日に公式モデルカタログを確認すると、81件が掲載されています。Overviewページには「50以上」とありますが、この記事では更新頻度の高い動的カタログの件数を採用します。カタログにはLLMだけでなく、埋め込み、リランキング、翻訳、音声認識、音声合成、画像生成、画像理解、物体検出、安全性分類、会話ターン検出などが含まれる。
一方、Workers AIは一般的なクラウドGPUではありません。利用者はGPUへSSH接続できず、CUDA、ComfyUI、任意のDocker、任意のGGUF・MLX・ONNX・Safetensorsモデルを自由に配置することもできない。通常のセルフサービスで可能なのは、Cloudflareのカタログモデルを呼ぶことと、対応ベースモデルへLoRAアダプターを追加することです。任意の自前モデルは、次のどちらかで扱います。
自前推論サーバーをHTTPS APIとして公開し、AI GatewayのCustom Providerへ接続する
private custom modelsの要件をCloudflareへ個別相談する
したがって、手元のMac上のLM StudioやMLXによる推論をCloudflareへアップロードするのではなく、ローカル推論を一つの外部プロバイダーとしてAI Gateway配下へ接続するのが実務的です。
文章生成から音声と画像まで一つの入口で扱える
できることを用途から見渡す
テキスト生成・推論。対応する主な機能やモデルはKimi、GLM、GPT-OSS、Qwen、Gemma、Llama、Mistral、Nemotron。主な用途は要約、分析、執筆、意思決定支援、コード生成。
Function calling。対応する主な機能やモデルは対応LLM＋Function calling。主な用途はAPI実行、DB検索、業務システム操作。
構造化出力。対応する主な機能やモデルはJSON Mode、JSON Schema。主な用途は抽出、分類、後続処理、ワークフロー制御。
埋め込み。対応する主な機能やモデルはBGE、Qwen、PLaMo、EmbeddingGemma。主な用途はRAG、意味検索、重複検出、クラスタリング。
リランキング。対応する主な機能やモデルはBGE Reranker。主な用途はRAG検索精度の改善。
音声認識。対応する主な機能やモデルはWhisper、Deepgram Nova/Flux。主な用途は会議、電話、日報、動画字幕。
音声合成。対応する主な機能やモデルはAura、MeloTTS。主な用途は音声エージェント、読み上げ、多言語案内。
会話ターン検出。対応する主な機能やモデルはSmart Turn。主な用途は音声対話で「話し終わったか」を判断。
画像理解。対応する主な機能やモデルはGemma、Llama 画像理解、Moondream、LLaVA。主な用途は画像説明、帳票理解、検品、UI解析。
物体・画像分類。対応する主な機能やモデルはDETR、ResNet。主な用途は検品、モデレーション、カテゴリ判定。
画像生成・編集。対応する主な機能やモデルはFLUX、Stable Diffusion、DreamShaper等。主な用途は広告、アイキャッチ、素材生成、inpainting。
翻訳。対応する主な機能やモデルはM2M100、IndicTrans2、LLM。主な用途は多言語化、ローカライズ。
安全性分類。対応する主な機能やモデルはLlama Guard、AI Gateway Guardrails。主な用途は有害入力・出力の検知と遮断。
大量非同期処理。対応する主な機能やモデルはバッチ API、Queues、Workflows。主な用途は数万文書の要約・埋め込み・分類。
文書変換。対応する主な機能やモデルは`AI.toMarkdown()`。主な用途はPDF、Office文書、画像、HTMLをLLM向けに正規化。
Web取得。対応する主な機能やモデルはBrowser Run `/markdown` `/json` `/scrape`。主な用途はJSサイトの調査、構造化抽出、RAG取り込み。
状態を持つエージェント。対応する主な機能やモデルはエージェントs SDK＋Durable Objects。主な用途は長期会話、定期タスク、Slack/音声エージェント。
耐障害ワークフロー。対応する主な機能やモデルはWorkflows。主な用途は再試行、承認待ち、数日間の処理。
モデル統制。対応する主な機能やモデルはAI Gateway。主な用途はログ、予算、レート制限、キャッシュ、代替処理、DLP。
既存システムから無理なく呼び出せる
Workers AIは次の経路から呼び出せる。
Workers バインドing `env.AI.run()`。向いているのはCloudflare上のアプリ、低遅延API。注意点は1 WorkerプロジェクトにつきAI バインドingは1つ。
REST API。向いているのはMac、バックエンド、バッチ、他クラウド。注意点はAPIトークン管理が必要。
OpenAI互換API。向いているのは既存OpenAI SDKやツールの移植。注意点はWorkers AI直結の対応範囲とAI Gatewayの統合APIを区別。
AI Gateway REST API。向いているのはWorkers AI＋外部モデルを一元化。注意点はログ・予算・振り分けを共通化できます。
Vercel AI SDK等。向いているのはWebアプリのstreaming、tools、structured output。注意点はSDK依存部分を薄く保つ。
Playground。向いているのはモデルの簡易比較。注意点は本番品質・料金・レート制限の検証には不十分。
Workers AI直結ではOpenAI互換のChat CompletionsとEmbeddingsを利用できます。AI Gatewayの新しい統合REST APIは、`/ai/run`、OpenAI Chat Completions、OpenAI Responses、Anthropic Messages形式を提供し、Workers AIと外部プロバイダーを同じ認証・観測層で扱います。
ローカル開発とローカル推論は別物
`wrangler dev`を使うとWorkerコード自体はlocalhostで動くが、AI推論はCloudflareへ送信される。ローカル推論ではなく、使用量は課金とレート制限の対象になる。
Mac上のコード: ローカル
Workers AIモデル: CloudflareのGPU
課金・制限: 発生するこの点は、LM StudioやMLXでモデル重みをMac上に読み込む「完全ローカル推論」とは異なります。
本番で効くのはモデル以外の機能
AIに操作を任せる前に権限を分ける
Function callingでは、モデルが直接システムを操作するわけではありません。利用可能なツール名、引数スキーマ、説明を受け取り、呼ぶべきツールと引数を返します。実際の認可、実行、結果の返却はアプリ側が担当します。
実装できる例:
D1、R2、KVから情報を取得する
CRM、会計、Slack、Google Calendar等のAPIを呼ぶ
顧客ごとに許可された業務だけ実行する
OpenAPI仕様からツールを生成する
検索→取得→要約→登録を複数ターンで行う
重要: Function callingは権限管理の代替ではない。ツール単位の認可、引数検証、承認、監査ログ、冪等性、ロールバックを別途設計します。
自然文を業務で使えるデータへ変える
JSON Modeは、人間向けの自然文ではなく、後段プログラムが確実に読める構造化データを返すために使います。
適用例:
契約書から当事者、日付、金額、解除条項を抽出
問い合わせをカテゴリ・緊急度・担当者へ分類
営業議事録から課題、決裁者、次の行動を抽出
画像から商品属性をJSON化
エージェントの次ステップを状態遷移として返す
実務では、JSON Schemaだけでなく、次も必要です。
JSONの解析検証
スキーマ検証
値域・業務ルール検証
再試行・代替処理
原文との根拠対応
人間承認が必要なフィールドの分離
大量処理は会話とは別の流れで回す
バッチ APIは、複数推論を一括送信し、`待機中`状態と`リクエスト_id`を受け取り、後から結果を取得する。即時応答が不要な大量処理に向きます。容量不足時に即時失敗させるより、最終的な処理完了を優先する設計です。1バッチの総送信データは10MB未満という制約があります。
適する処理:
既存記事・PDF数万件の埋め込み
会議録の夜間要約
商品データのカテゴリ分類
問い合わせログの感情・原因分析
多言語翻訳
画像説明の生成
評価データセットの一括推論
即時チャット、厳密な締切、順序依存の処理には、QueuesやWorkflowsと併用した方がよい。
同じ前提を何度も読ませない
対応モデルでは先頭部分のキャッシュが既定で有効になり、共通先頭部分の計算結果を再利用する。最初の文字が返るまでの時間短縮、処理量改善、キャッシュ済み入力の割引につながる。`x-session-affinity`で同じセッションを同系統の推論先へ寄せられる。
キャッシュを効かせるプロンプト構造:
1. 固定system プロンプト
2. 固定ツール定義
3. 固定の業務ルール・参照資料
4. 会話履歴
5. 動的な日時・ユーザー入力system プロンプト冒頭へ毎回変わる時刻、UUID、利用者名を入れると、そこから先の先頭部分が一致しなくなる。長時間エージェントほど設計差がコストへ響く。
自社らしさは小さな追加学習で持たせられる
Workers AIは、対応する非量子化ベースモデルに対するLoRAアダプター推論をオープンベータで提供している。公式ドキュメント上、ベータ期間中は無料。アダプターは300MB未満、指定ファイル名、rankやモデル互換性の制約があり、1アカウント最大100件をテストできます。アップロード後の資産差し替えはできず、新しいfine tuneを作る。
できること:
特定の文体・ブランドトーン
業界固有の分類
定型的なコード生成
特定フォーマットの要約
画像生成スタイル
できないこと・誤解しやすい点:
任意のフルモデルをそのままアップロードすること
Workers AI上で自由な学習ジョブを回すこと
量子化済みの任意ベースへ無条件にLoRAを適用すること
全カタログモデルにLoRAを適用すること
訓練は外部環境で行い、Workers AIは主としてアダプター付き推論を提供する。公開LoRAとしてMagicoder、毒性分類、CNN要約なども用意されている。
PDFやOffice文書をAIが読める形へ変える
`env.AI.toMarkdown()`またはREST APIで、PDF、画像、HTML、XML、Excel、DOCX、ODS、ODT等をMarkdownへ変換できます。大部分の形式変換は無料だが、画像理解等でWorkers AIモデルを使う場合はAI使用量が発生し得る。
これにより、従来は個別ライブラリが必要だった次の前処理をCloudflare側へ寄せられる。
アップロード
→ ファイル形式判定
→ Markdown化
→ セクション分割
→ 埋め込み
→ Vectorize/AI Search登録
→ RAG回答動的WebページはBrowser Run `/markdown`、特定要素は`/scrape`、指定Schemaへの抽出は`/json`を使い分ける。
文章だけでなく会話と画像も扱える
Workers AIはテキスト以外も扱います。
Whisper/DeepgramによるASR
Aura/MeloTTSによるTTS
Smart Turnによる発話終了判定
FLUX/Stable Diffusion系の画像生成・編集
Gemma/Llama/Moondream等の画像理解
DETR/ResNetによる検出・分類
したがって、音声エージェントでは次の一連をCloudflare上で組める。
音声ストリーム
→ VAD/Smart Turn
→ ASR
→ LLM + tools
→ TTS
→ WebSocketで返却ただし、リアルタイム音声はモデル単価だけでなく、WebSocket接続、音声分数、遅延、割り込み、エコー、再接続を含む端から端までの評価が必要です。
Cloudflare全体で見るとAIシステムの部品が揃う
プロンプトだけでなく、情報、ツール、状態、権限、評価まで設計対象が広がった背景は、こちらの記事で詳しく整理しています。
AI Gatewayがモデル選択と予算の司令塔になる
AI Gatewayはモデルそのものではなく、AI通信を観測し、制御するための入口です。Workers AI、OpenAI、Anthropic、Google、DeepSeek、xAI等を同じGatewayに通し、次を適用できます。
Analytics / Logs。トークン、cost、遅延、エラー、リクエスト/responseを観測。
Caching。同一リクエストの再利用。
Rate limiting。利用者・アプリ単位の過剰利用防止。
Spend limits。ドル建て予算に達したら429または安価モデルへ代替処理。
Dynamic 振り分け。条件分岐、A/B、段階展開、モデル切替。
Retries / Fallback。プロバイダー障害時の再試行・代替。
Guardrails。有害プロンプト/responseの検査。
DLP。個人情報、金融、医療等の漏洩検知。
BYOK / Unified Billing。自前キーまたはCloudflare一括請求。
Custom Provider。自社・ローカル・地域特化のHTTPSモデルAPIを統合。
Spend limitsでは、モデル、プロバイダー、利用者、チーム、アプリケーションなどの単位で予算を分けられます。上限へ達すると原則としてHTTP 429で遮断されます。動的ルーティングを組み合わせれば、より安価なモデルへ切り替える設計も可能です。ただし、反映にはわずかな遅れがあり、高い並列負荷では少額の超過が起こる可能性があります。
AI Gatewayは全プランで利用でき、ダッシュボード分析、キャッシュ、レート制限などのコア機能は無料です。永続ログの上限は、Workers Freeでは全Gateway合計10万件、Workers PaidではGatewayごとに1,000万件です。Unified Billingで購入するクレジットには5％の手数料がかかりますが、各プロバイダーの推論料金には上乗せされません。GuardrailsはWorkers AI上のLlama Guardによる推論として別途課金されます。DLPの基本スキャンは全プランで無料ですが、利用できるプロファイル範囲はZero Trust契約の有無で異なります。
状態を覚えるエージェントを作れる
エージェントs SDKはDurable Objectsを基盤とし、エージェントごとの永続ID、SQLite状態、WebSocket同期、スケジュール、RPC、長期会話を提供する。
できること:
チャット履歴と業務状態を保持
数秒後、指定日時、cron、intervalの処理
クライアント切断後も処理を継続
Slack、Web、メール、音声等のchannelへ接続
Browser Run、Sandbox、MCP、AI Searchをtoolとして利用
同じ顧客・案件の状態を一貫して保持
スケジュールはSQLiteへ保存され、エージェント再起動後も残る。
長い仕事は途中から再開できるようにする
Workflowsは、失敗しても再試行し、ステップの状態を保存し、数日間の承認待ちや外部イベント待ちを扱います。エージェントsがリアルタイム対話と状態を担い、Workflowsが長時間・多段処理を担う分業が適切です。
即時チャット、WebSocket、短いツール呼び出し。向いているのはエージェント。
30秒超、複数段、再試行、承認待ち。向いているのはエージェント + Workflow。
完全なバックグラウンド処理。向いているのはWorkflow。
大量メッセージのbuffering。向いているのはQueues。
大量推論をCloudflare側で非同期実行。向いているのはWorkers AI バッチ API。
大規模な検索基盤をそのまま真似せず、必要な正本から根拠付きで情報を運ぶ小さな検索設計は、こちらの記事で掘り下げています。
検索を任せるか自分で設計するか
社内文書などを検索して回答へ使う仕組みには、主に二つの選択肢があります。こうした仕組みはRAGと呼ばれます。
AI Search。特徴はR2/websiteの取り込み、index、検索語の書き換え、rerank、generationをマネージド化。向いているのは早く作る、運用を減らす。
Vectorize。特徴はchunk、embedding、メタデータ、検索、rerank、生成を自分で設計。向いているのは精密な権限制御、独自評価、複雑な検索。
AI Searchのモデル呼び出しはAI Gatewayを通るため、リクエスト数、トークン、費用、遅延、エラー、検索語の書き換えなどを観測できます。生成モデルを外部プロバイダーへ変更することも可能です。2026年8月4日時点ではオープンベータ中で、所定の上限内のAI Search利用料は無料ですが、Workers AIとAI Gatewayの利用料は別です。
Vectorizeではメタデータ filterを使い、`顧客領域_id`、`client_id`、`document_type`、`visibility`等で検索対象を分離する。
データの性質に合わせて保存場所を分ける
R2。AIシステム内の役割は原文書、音声、画像、生成物、大容量ログ。
D1。AIシステム内の役割はユーザー、権限、文書メタデータ、ジョブ、評価結果。
KV。AIシステム内の役割は設定、短期キャッシュ、プロンプト version、機能フラグ。
Durable Objects。AIシステム内の役割は会話・案件・部屋単位の強整合状態、WebSocket。
Queues。AIシステム内の役割は取り込み、再試行、負荷平準化、失敗メッセージの隔離。
Workflows。AIシステム内の役割は多段処理、承認待ち、復旧可能な実行。
R2、D1、KV、Durable Objectsを、とりあえず全部使う必要はありません。データの大きさ、更新頻度、整合性、読み書きの方法で選びます。
ローカルモデル連携はアップロードではなく接続
何ができて何ができないか
`wrangler dev`でローカル開発。利用できます。実際には推論はCloudflare。課金・制限あり。
Workers AIへ任意GGUF/MLXをupload。原則として利用できません。実際にはセルフサービスBYOMではない。
対応モデルへLoRA adapterをupload。条件付きで利用できます。実際には対応base、rank、容量等の制約。
Mac/自社GPUのモデルをAI Gatewayへ接続。利用できます。実際にはHTTPS API化しCustom Providerにする。
private custom modelをCloudflareでhost。個別相談が必要です。実際にはCustom Requirements Form経由。
Macの推論サーバーを安全に接続する
AI GatewayのCustom Providerには、HTTPSで到達できるベースURLが必要です。LM Studio等のOpenAI互換APIは通常localhostのHTTPであるため、そのままでは接続できない。Cloudflare Tunnel等で安全なHTTPS endpointにし、認証を付ける。
利用アプリ / Codex系ツール
|
v
Cloudflare AI Gateway
- logs
- レート・予算 limits
- 振り分け/代替処理
- DLP/Guardrails
|
+--> Workers AI
+--> OpenAI / Anthropic / Google等
+--> Custom Provider
|
Cloudflare Tunnel + Access/API認証
|
Mac mini / MacBook Pro
LM Studio / llama.cpp / MLX サーバー安全上の最低条件:
LM Studioのポートを直接インターネットへ公開しない
推論サーバーはlocalhostまたはprivate interfaceへバインド
Tunnel側にAccess Service Tokenまたは同等認証
AI Gatewayにも認証を設定
model/コンテキスト/output上限をサーバー側でも設定
利用者・プロジェクト別のrate・spend制限
リクエスト/response logへ機密情報を残す範囲を決める
Mac停止・sleep・回線断時はCloudflareモデルへ代替処理
ツール呼び出しをローカルモデルへ任せる場合も認可は別層
本番用途は常時稼働Mac mini等へ寄せ、MacBook Proは開発・検証用とする
モデル性能だけでなく、企業が何を自社資産として持つべきかを考えたい方は、モデル交換可能性と評価資産を整理した記事も参考になります。
同じモデル名でも結果は一致しない
同じモデル名・系統でも、次が異なります。
重みの版
量子化方式（FP8、AWQ、GGUF Q4等）
トークンizer/chat template
コンテキスト length
推論カーネル
Function callingのテンプレート
safety設定
license
プロバイダー patch
配信時のバッチ処理とキャッシュ
したがって「CloudflareのQwen3-30B-A3B-FP8」と「LM Studio上のQwen系GGUF」の結果を同一視しない。共通の実業務評価セットで比較する。
Macとクラウドはモデル規模で役割分担する
以下はCloudflareの公式値ではなく、Apple Siliconの統合メモリ上で量子化モデルを動かす場合の一般的な工学的目安です。KV cache、コンテキスト、実行環境、vision encoder等の余裕が別途必要で、4bit重みも「parameter数×0.5 byte」だけでは収まらない。
0.3B～3B。4bit重みの粗い下限は0.2～1.5GB。実用上の統合メモリ目安は8～16GB。Workers AI掲載系統例はEmbeddingGemma、Qwen3 Embedding、Llama 1B/3B。小さなモデルなら比較的容易です。
7B～12B。4bit重みの粗い下限は3.5～6GB。実用上の統合メモリ目安は16～24GB。Workers AI掲載系統例はMistral 7B、Llama 8B/11B 画像理解、Moondream。現実的です。
20B～32B。4bit重みの粗い下限は10～16GB。実用上の統合メモリ目安は32～64GB。Workers AI掲載系統例はGPT-OSS 20B、Mistral 24B、Qwen/DeepSeek/QwQ 32B。判定は現実的な主要候補です。
70B。4bit重みの粗い下限は約35GB以上。実用上の統合メモリ目安は64～128GB以上。Workers AI掲載系統例はLlama 70B。条件付きです。速度や扱えるコンテキストとの妥協が必要です。
120B。4bit重みの粗い下限は約60GB以上。実用上の統合メモリ目安は96～192GB以上。Workers AI掲載系統例はGPT-OSS/Nemotron 120B。多くのMacBook Proでは実用が難しい規模です。
数百B～1T級。4bit重みの粗い下限は数百GB。実用上の統合メモリ目安は複数GPU/サーバー。Workers AI掲載系統例はKimi K2.6、GLM 5.2級。Mac単体では現実的ではありません。
30B級の量子化モデルをLM Studioなどで実用速度で動かせるMacなら、20～35B級をローカル側の常用枠にし、70B、120B、巨大なMoEモデルや急な処理増加をクラウド側へ送る構成が現実的です。
ローカルに向くモデル
汎用・低コスト。候補となるモデル系統はLlama 3.2 3B、Granite Micro。理由は軽量、常駐しやすい。
標準業務。候補となるモデル系統はLlama 8B、Mistral 7B、Gemma 12B。理由は速度と品質のバランス。
高品質ローカル。候補となるモデル系統はGPT-OSS 20B、Mistral Small 24B、Gemma 26B。理由は32～64GB帯で現実的。
コーディング。候補となるモデル系統はQwen2.5 Coder 32B、Qwen系30～35B。理由は既存運用と親和性。
推論。候補となるモデル系統はDeepSeek R1 Distill Qwen 32B、QwQ 32B。理由はreasoning向け。
画像理解。候補となるモデル系統はLlama 3.2 11B 画像理解、Moondream。理由はscreenshot/帳票/画像説明。
日本語検索。候補となるモデル系統はPLaMo Embedding、BGE-M3、Qwen3 Embedding。理由はRAG用。
音声認識。候補となるモデル系統はWhisper Large v3 Turbo等。理由はMLXとの親和性が高い。
画像生成。候補となるモデル系統はSDXL、FLUX Schnell。理由はComfyUI等。ただしWorkers AIとは別実行環境。
クラウドへ送るべき仕事
低価格の高速推論。クラウド側の候補はGLM 4.7 Flash、Qwen3 30B、Gemma 4 26B。
安価で強い汎用。クラウド側の候補はGPT-OSS 20B。
より高品質・大規模。クラウド側の候補はGPT-OSS 120B、Nemotron 120B。
長文・高難度・エージェント。クラウド側の候補はKimi K2.6、Kimi K2.7 Code、GLM 5.2。
音声リアルタイム。クラウド側の候補はDeepgram Flux/Nova、Aura、Smart Turn。
急な処理増加のある画像生成。クラウド側の候補はFLUX/Stable Diffusion系。
使い道はチャットボットよりはるかに広い
業務とSaaSで使う
1。ユースケースは社内ナレッジ検索。推奨モデル/タスクはEmbedding＋Reranker＋LLM。Cloudflare構成はR2→AI Search/Vectorize→AI Gateway。主要リスクは権限漏れ、古い文書。
2。ユースケースは顧客向けFAQ。推奨モデル/タスクは小～中LLM、RAG。Cloudflare構成はエージェント＋AI Search＋DO。主要リスクは誤回答、根拠非表示。
3。ユースケースは問い合わせ分類。推奨モデル/タスクはDistilBERT/小型LLM。Cloudflare構成はWorker→D1/Queue。主要リスクは誤分類、偏り。
4。ユースケースはサポート回答下書き。推奨モデル/タスクはGPT-OSS/Qwen/Gemma。Cloudflare構成はGateway＋CRM tool。主要リスクは勝手な送信。
5。ユースケースは営業議事録分析。推奨モデル/タスクはWhisper＋LLM＋JSON。Cloudflare構成はR2→ASR→Workflow→D1。主要リスクは固有名詞、同意。
6。ユースケースは商談フォローアップ。推奨モデル/タスクはLLM＋Function calling。Cloudflare構成はエージェント→Gmail/CRM tool。主要リスクは宛先・金額・約束。
7。ユースケースはアカウントリサーチ。推奨モデル/タスクはBrowser＋LLM。Cloudflare構成はBrowser Run→エージェント→R2。主要リスクは利用規約、情報鮮度。
8。ユースケースは契約書抽出。推奨モデル/タスクはtoMarkdown＋LLM JSON。Cloudflare構成はR2→Workflow→D1。主要リスクは法的解釈、抽出漏れ。
9。ユースケースは請求書・帳票抽出。推奨モデル/タスクは画像理解＋JSON。Cloudflare構成はR2→画像理解→D1。主要リスクは金額・税・日付。
10。ユースケースは自然言語BI。推奨モデル/タスクはLLM＋Function calling。Cloudflare構成はD1/外部DB→検証→chart。主要リスクは不正SQL、数値誤り。
11。ユースケースはText-to-SQL。推奨モデル/タスクは汎用LLM。Cloudflare構成はスキーマ限定tool＋読み取り専用 DB。主要リスクはSQLCoder旧版の採用。
12。ユースケースは多言語ローカライズ。推奨モデル/タスクはM2M100/LLM。Cloudflare構成はバッチ API＋Workflow。主要リスクは用語・文化・法令。
13。ユースケースは商品説明生成。推奨モデル/タスクはLLM＋画像理解。Cloudflare構成はR2画像＋D1商品DB。主要リスクは誇大表現。
14。ユースケースはレコメンド。推奨モデル/タスクはEmbeddings。Cloudflare構成はVectorize＋D1。主要リスクは推薦の偏り。
15。ユースケースは重複・類似検出。推奨モデル/タスクはEmbeddings。Cloudflare構成はバッチ→Vectorize。主要リスクは閾値設計。
16。ユースケースはVoC分析。推奨モデル/タスクはASR/分類/LLM。Cloudflare構成はQueue→バッチ→D1。主要リスクはサンプル偏り。
17。ユースケースは評価・採点支援。推奨モデル/タスクはLLM＋JSON。Cloudflare構成はGateway＋採点基準。主要リスクは自動確定禁止。
18。ユースケースは文書一括移行。推奨モデル/タスクはtoMarkdown＋バッチ。Cloudflare構成はR2→Queue→バッチ。主要リスクはレイアウト消失。
19。ユースケースは顧客別AI機能。推奨モデル/タスクはModel 振り分け。Cloudflare構成はGateway メタデータ＋DO。主要リスクは顧客領域混線。
20。ユースケースはAI APIプロキシSaaS。推奨モデル/タスクはGateway。Cloudflare構成は認証＋spend/rate＋logs。主要リスクはキー悪用、原価超過。
開発とエージェントで使う
21。ユースケースはコード生成。構成はKimi K2.7 Code/Qwen Coder/GPT-OSS。要点はrepository accessを最小化。
22。ユースケースはコードレビュー。構成は複数モデル＋JSON findings。要点は重大度と根拠をスキーマ化。
23。ユースケースはCI失敗解析。構成はGitHub webhook→Workflow→LLM。要点はログに機密情報を含めない。
24。ユースケースはissue triage。構成は小型LLM→D1/GitHub tool。要点は自動closeは禁止。
25。ユースケースはdocs更新。構成はMarkdown for エージェントs＋LLM。要点はsource diffを保持。
26。ユースケースはブラウザQA。構成はBrowser エージェント＋画像理解。要点はCDP操作は承認付き。
27。ユースケースはフロント不具合調査。構成はBrowser Run＋console/network取得。要点は再現条件を記録。
28。ユースケースは長時間coding agent。構成はエージェント＋Workflow＋Sandbox。要点はファイルシステム隔離、途中保存。
29。ユースケースはMCP tool agent。構成はエージェントs SDK＋MCP。要点はtool permission境界。
30。ユースケースはモデル評価基盤。構成はバッチ API＋D1＋R2。要点はプロンプト/model/versionを固定。
音声とクリエイティブで使う
31。ユースケースはリアルタイム音声受付。構成はSmart Turn→ASR→LLM→TTS。注意点は割り込み、遅延、誤認識。
32。ユースケースはコール要約。構成はNova/Whisper→LLM。注意点は録音同意、個人を特定できる情報。
33。ユースケースは音声日報。構成はWhisper→JSON→D1。注意点は現場語彙辞書。
34。ユースケースは動画字幕。構成はWhisper Large v3 Turbo。注意点は時刻情報品質。
35。ユースケースは多言語音声案内。構成はASR→翻訳→TTS。注意点は言語別QA。
36。ユースケースはアイキャッチ生成。構成はFLUX/SDXL。注意点は商標・人物・著作権。
37。ユースケースは画像部分編集。構成はInpainting/img2img。注意点は元画像権利。
38。ユースケースは商品画像タグ付け。構成は画像理解/ResNet/DETR。注意点は誤検出。
39。ユースケースはUI screenshot分析。構成は画像理解 LLM。注意点は視覚だけで断定しない。
40。ユースケースは有害画像・文面の前段分類。構成はclassifier＋Guardrails。注意点は単一判定に依存しない。
調査と運用監視で使う
41。ユースケースはWebリサーチ収集。構成はBrowser `/markdown`/`json`→R2。要点はrobots/規約/引用。
42。ユースケースは競合サイト差分。構成はscheduled エージェント→Browser→diff。要点は誤検知を人が確認。
43。ユースケースは制度・価格監視。構成はエージェント schedule＋Workflow。要点は更新日時と原文保存。
44。ユースケースは毎朝レポート。構成はschedule→検索→LLM→Slack。要点は情報源別に引用。
45。ユースケースは障害一次解析。構成はLogs→LLM→runbook。要点は自動復旧の権限制限。
46。ユースケースはインシデント要約。構成はR2/D1 logs→LLM。要点は事実と仮説を分ける。
47。ユースケースはデータ品質監査。構成はバッチ＋rules＋LLM。要点は決定論的検査を先に。
48。ユースケースはセキュリティプロンプト監視。構成はGateway Guardrails/DLP。要点は遅延とstreaming影響。
49。ユースケースはコスト異常検知。構成はGateway analytics＋spend limits。要点はeventual consistency。
50。ユースケースはプロバイダー障害代替処理。構成はDynamic 振り分け。要点は出力互換性を事前検証。
料金は安いが総コストは設計で変わる
Workers AIには1日10,000 Neuronsの無料枠があります。超過分を利用するにはWorkers Paidが必要で、料金は1,000 Neuronsあたり0.011米ドルです。無料枠と各種上限は毎日00時UTCにリセットされます。モデルカードには比較しやすい単位別料金も表示されます。
2026年8月4日時点の代表例:
Qwen3 30B A3B FP8。入力/100万トークンは$0.051。出力/100万トークンは約$0.34。文脈は32,768。主用途は低価格な推論/tool。
GLM 4.7 Flash。入力/100万トークンは$0.06。出力/100万トークンは$0.40。文脈は131,072。主用途は多言語、高速推論。
Gemma 4 26B A4B。入力/100万トークンは$0.10。出力/100万トークンは$0.30。文脈は256,000。主用途は画像理解/tool/長文。
GPT-OSS 20B。入力/100万トークンは$0.20。出力/100万トークンは$0.30。文脈は128,000。主用途は汎用・ローカル対照。
GPT-OSS 120B。入力/100万トークンは$0.35。出力/100万トークンは$0.75。文脈は128,000。主用途は大規模推論。
Nemotron 3 120B A12B。入力/100万トークンは$0.50。出力/100万トークンは$1.50。文脈は256,000。主用途は高度推論・agent。
Kimi K2.7 Code。入力/100万トークンは$0.95。出力/100万トークンは$4.00。文脈は262,144。主用途はcoding agent。
GLM 5.2。入力/100万トークンは$1.40。出力/100万トークンは$4.40。文脈は262,144。主用途は高難度・長文。
Kimi K2.7 Codeはcached inputが$0.19/100万トークン、GLM 5.2は$0.26/100万トークンと各モデルカードに記載されている。Prompt cachingが効くエージェントでは差が大きい。
長文処理一回の概算
Qwen3 30B A3B。概算は$0.0085。
GLM 4.7 Flash。概算は$0.0100。
Gemma 4 26B。概算は$0.0130。
GPT-OSS 20B。概算は$0.0230。
GPT-OSS 120B。概算は$0.0425。
Nemotron 120B。概算は$0.0650。
Kimi K2.7 Code。概算は$0.1350。
GLM 5.2。概算は$0.1840。
単発単価は低いが、エージェントが同じrepository・tool定義・履歴を数十回再送すると入力トークンが増える。プロンプト caching、コンテキスト圧縮、tool結果の要約、モデル振り分けが必要です。
安さより再試行と人手修正まで見る
選定軸:
実業務成功率
JSON/ツール呼び出し validity
日本語品質
コンテキスト長
最初の文字が返るまでの時間と生成速度
cached inputの効き方
1件あたり総トークン
再試行率
ベータ/非推奨
license・データ条件
安価なモデルが再試行や人手修正を増やせば総コストは高くなる。逆に、すべてをKimi/GLM 5.2へ送るのも過剰です。
制限とデータの扱いを先に確認する
処理量には上限がある
公式のdefault task limit例:
Text generation。Default リクエストs/minuteは300。
ASR。Default リクエストs/minuteは720。
Image-to-text。Default リクエストs/minuteは720。
Text-to-image。Default リクエストs/minuteは720。
Summarization。Default リクエストs/minuteは1,500。
Text classification。Default リクエストs/minuteは2,000。
Embeddings。Default リクエストs/minuteは3,000（一部例外）。
Image classification。Default リクエストs/minuteは3,000。
Object detection。Default リクエストs/minuteは3,000。
Translation。Default リクエストs/minuteは720。
ベータや個別モデルは低い場合があります。`wrangler dev`の推論も同じlimitへ算入される。private custom modelやhigher limitsは個別相談です。
入出力は顧客コンテンツとして扱われる
公式方針では、Customer Contentは顧客が所有し、他顧客へ公開せず、明示的同意がない限りWorkers AIで提供するモデルのtrainingやサービス改善へ使わないとしている。R2等を明示的に組み合わせた場合は、そのstorageへ保存される。モデルは第三者モデルを含むため、各licenseも確認します。
ただし実務では次を別途決める。
AI Gateway logへプロンプト/responseを保存するか
保存期間
個人を特定できる情報のmask
client別gateway分離
R2/D1のregion・residency要件
data deletion
supポート担当者の閲覧権限
external プロバイダーへ代替処理する際のデータ条件
有害情報と機密漏えいは別々に守る
Guardrailsはプロンプトとresponseの有害内容をflag/blockできます。DLPは個人情報、金融情報、医療情報、custom pattern等をscanする。
注意点:
Guardrailsは追加推論なのでコストと遅延が増える
response DLPは全responseをbufferするため、streamingの最初の文字が返るまでの時間を大きく悪化させ得る
リクエスト-only DLPはstreamingへの影響が小さい
cache hitはDLPを再実行しない
顧客領域ごとにDLP policyを変えたい場合、別Gatewayが推奨される
安全性モデルも誤検知・見逃しがある
モデル廃止を前提に交換可能にする
81件には非推奨/ベータが含まれる。非推奨モデルを新規本番採用しない。model IDをコード各所に直書きせず、Gateway routeまたは設定へ集約し、versioned evaluationで移行する。
現実的な答えはハイブリッド構成
まず一つの入口を作る
Cloudflareを「すべての推論を置く場所」ではなく、「ローカル・Workers AI・外部APIを統制するAI Control P実行枠」にする。
[Web / iOS / Codex / 社内ツール]
|
Cloudflare Worker
認証 / 顧客領域 / policy / スキーマ validation
|
AI Gateway
logs / cost / rate / DLP / guardrail / 振り分け
/ | \
v v v
Local 実行枠 Workers AI External 実行枠
Mac mini Qwen/Gemma OpenAI/Anthropic/
LM Studio GPT-OSS/Kimi Google等
MLX/llama.cpp GLM/Nemotron
\ | /
+-------------+--------------+
|
エージェント / Workflow / Queue
|
R2 / D1 / Vectorize / AI Search / Durable Objects仕事の性質でモデルを振り分ける
L0。条件はdeterministic処理で解ける。Model 実行枠はLLMを使わない。
L1。条件は機密・短文・日常処理。Model 実行枠はローカルQwen。
L2。条件は安価な分類・要約・tool。Model 実行枠はQwen3/GLM Flash/Gemma/GPT-OSS 20B。
L3。条件は高品質・長文。Model 実行枠はGPT-OSS 120B/Nemotron。
L4。条件はcoding/複雑agent。Model 実行枠はKimi K2.7 Code/GLM 5.2。
L5。条件はプロバイダー障害・品質不足。Model 実行枠は外部フロンティア modelへ代替処理。
ルーティング条件:
データ機密度
予想コンテキスト量
ツール呼び出しingの必要性
deadline
顧客領域 plan
月次予算
過去の成功率
local hostの稼働状態
model outage/rate limit
顧客と案件を混ぜない
は複数クライアント案件を扱うため、最低限次を分離する。
顧客領域_id
client_id
project_id
data_classification
allowed_models
allowed_tools
monthly_budget
retention_policy
gateway_id or 振り分け policy
vector メタデータ filter
R2 先頭部分 / D1 row-level application policy単一Gatewayに全案件を詰めるより、医療・個人情報・高機密案件はGatewayとstorageを分ける方が監査しやすい。
最小実証から段階的に広げる
最初はモデルゲートウェイだけを作る
Worker 1本
AI Gateway 1つ
Workers AI 3モデル
Local LM Studio Custom Provider 1つ
リクエスト メタデータ: user/project/task
レート・予算 limit
JSON logの最小保存
代替処理
比較モデル例:
ローカルQwen 3.6-35B-A3B
Qwen3-30B-A3B-FP8
GPT-OSS-20B
Kimi K2.7 CodeまたはGLM 5.2
次に文書検索を加える
R2へ原文
`toMarkdown`
AI SearchまたはVectorize
顧客領域 メタデータ filter
回答へ引用箇所と文書version
誤回答評価
最後にエージェントと長時間処理を加える
エージェントで会話・状態
Workflowで長時間処理
toolごとの承認
idempotency key
途中保存/retry
audit log
成功条件を先に決める
実タスク成功率。合格基準例は50～100件のgold setで基準超過。
JSON valid率。合格基準例は99%以上。
Tool call成功率。合格基準例は95%以上。破壊的toolは人間承認100%。
根拠付き回答率。合格基準例は95%以上。
顧客領域混入。合格基準例は0件。
p95 遅延。合格基準例は用途別SLO以内。
cost。合格基準例は1タスク上限内。
代替処理。合格基準例はプロバイダー停止テストで成功。
log/個人を特定できる情報。合格基準例はpolicy通りにmask/非保存。
recovery。合格基準例はretry後も二重実行なし。
先に避けたい失敗パターン
非推奨モデルを安いから採用する
Cloudflare catalogのモデル名だけ見てローカル版と同じと判断する
LM Studioのポートを認証なしでインターネット公開する
全タスクを最大モデルへ送る
逆に全タスクをローカルモデルだけで処理する
Gateway logsへ機密プロンプトを無期限保存する
LLMのJSONをvalidationせずDBへ書く
Function callingを認可機構と勘違いする
エージェントの外部操作を承認なしで自動化する
RAGで顧客領域 filterをプロンプトだけに任せる
バッチ APIを即時応答に使う
DLP response scanとstreaming低遅延を同時に期待する
モデル更新後に評価せず自動切替する
無料枠だけを前提に本番原価を設計する
AI Gatewayを通しただけでデータ保護が完成したと考える
公式カタログの全モデルを用途別に確認する
カタログの読み方
ローカル○: 同系weights/model 系統を一般に自己ホスト可能。ただしCloudflare版と完全同一とは限らない
ローカル△: 系統は存在するが、正確なartifact、license、巨大要件、partner条件等を個別確認
ローカル×: 主にpartner/proprietary serviceで、通常のモデルweightsとして自己ホストする対象ではない
非推奨: 新規採用非推奨。移行前提
ベータ: SLA、limit、API、品質が変わり得る
1。モデルはaura-1。主タスクは音声合成（TTS）。Cloudflare上の状態は提供中・パートナー提供・リアルタイム/バッチ。同じ提供形態でのローカル実行はできません。Deepgram Aura。Cloudflare経由のマネージド利用。
2。モデルはaura-2-en。主タスクは英語TTS。Cloudflare上の状態は提供中・パートナー提供・リアルタイム/バッチ。同じ提供形態でのローカル実行はできません。Deepgram Aura-2 English。
3。モデルはaura-2-es。主タスクはスペイン語TTS。Cloudflare上の状態は提供中・パートナー提供・リアルタイム/バッチ。同じ提供形態でのローカル実行はできません。Deepgram Aura-2 Spanish。
4。モデルはbart-large-cnn。主タスクは要約。Cloudflare上の状態はベータ・非推奨。ローカル実行の候補になります。旧来の要約専用モデル。新規採用は避けます。
5。モデルはbge-base-en-v1.5。主タスクは埋め込み。Cloudflare上の状態は提供中・バッチ。ローカル実行の候補になります。英語中心の検索・RAG。
6。モデルはbge-large-en-v1.5。主タスクは埋め込み。Cloudflare上の状態は提供中・バッチ。ローカル実行の候補になります。高品質な英語埋め込み。
7。モデルはbge-m3。主タスクは多言語埋め込み。Cloudflare上の状態は提供中。ローカル実行の候補になります。多言語・長文検索向け。
8。モデルはbge-reranker-base。主タスクはリランキング。Cloudflare上の状態は提供中。ローカル実行の候補になります。検索候補の再順位付け。
9。モデルはbge-small-en-v1.5。主タスクは埋め込み。Cloudflare上の状態は提供中・バッチ。ローカル実行の候補になります。軽量な英語埋め込み。
10。モデルはdeepseek-r1-distill-qwen-32b。主タスクは推論LLM。Cloudflare上の状態は提供中・推論/LoRA対応。ローカル実行の候補になります。32B。ローカルは十分な統合メモリが必要。
11。モデルはdetr-resnet-50。主タスクは物体検出。Cloudflare上の状態はベータ。ローカル実行の候補になります。画像内オブジェクトの検出。
12。モデルはdistilbert-sst-2-int8。主タスクは感情分類。Cloudflare上の状態は提供中。ローカル実行の候補になります。軽量な二値感情分類。
13。モデルはdreamshaper-8-lcm。主タスクは画像生成。Cloudflare上の状態は提供中。ローカル実行は条件付きです。同系チェックポイントはローカル利用可能。ライセンス確認。
14。モデルはembeddinggemma-300m。主タスクは埋め込み。Cloudflare上の状態は提供中。ローカル実行の候補になります。軽量・多用途の埋め込み。
15。モデルはflux。主タスクは音声認識・会話ターン処理。Cloudflare上の状態は提供中・パートナー提供・リアルタイム。同じ提供形態でのローカル実行はできません。Deepgram Flux。画像生成FLUXとは別。
16。モデルはflux-1-schnell。主タスクは画像生成。Cloudflare上の状態は提供中。ローカル実行の候補になります。高速画像生成。ローカルはGPU/メモリ要件に注意。
17。モデルはflux-2-dev。主タスクは画像生成。Cloudflare上の状態は提供中・パートナー提供。ローカル実行は条件付きです。正確な配布条件・必要VRAMを個別確認。
18。モデルはflux-2-klein-4b。主タスクは画像生成。Cloudflare上の状態は提供中・パートナー提供。ローカル実行は条件付きです。4B級。Cloudflare版との完全同一性は保証されない。
19。モデルはflux-2-klein-9b。主タスクは画像生成。Cloudflare上の状態は提供中・パートナー提供。ローカル実行は条件付きです。9B級。ローカルは高負荷。
20。モデルはgemma-2b-it-lora。主タスクはテキスト生成。Cloudflare上の状態はベータ・LoRA。ローカル実行の候補になります。小型Gemma系。
21。モデルはgemma-3-12b-it。主タスクはマルチモーダルLLM。Cloudflare上の状態は非推奨。ローカル実行の候補になります。新規採用は後継モデルを優先。
22。モデルはgemma-4-26b-a4b-it。主タスクは推論・画像理解・Function calling。Cloudflare上の状態は提供中。ローカル実行の候補になります。256K文脈。ローカルは量子化前提。
23。モデルはgemma-7b-it。主タスクはテキスト生成。Cloudflare上の状態はベータ・非推奨。ローカル実行の候補になります。新規採用は避けます。
24。モデルはgemma-7b-it-lora。主タスクはテキスト生成。Cloudflare上の状態はベータ・LoRA。ローカル実行の候補になります。LoRA対応の旧Gemma系。
25。モデルはgemma-sea-lion-v4-27b-it。主タスクは東南アジア言語LLM。Cloudflare上の状態は提供中。ローカル実行は条件付きです。地域言語特化。配布条件を確認。
26。モデルはglm-4.7-flash。主タスクは推論・Function calling。Cloudflare上の状態は提供中。ローカル実行は条件付きです。低価格の高速推論。100言語超を掲示。
27。モデルはglm-5.2。主タスクは大規模推論・Function calling。Cloudflare上の状態は提供中・Paid。ローカル実行は条件付きです。262K文脈。巨大で一般的なMacローカルには不向き。
28。モデルはgpt-oss-120b。主タスクは推論・Function calling。Cloudflare上の状態は提供中。ローカル実行の候補になります。128K文脈。120Bは通常のMacBook Proには重い。
29。モデルはgpt-oss-20b。主タスクは推論・Function calling。Cloudflare上の状態は提供中。ローカル実行の候補になります。ローカル/専門用途を明示。Mac候補。
30。モデルはgranite-4.0-h-micro。主タスクはテキスト生成・Function calling。Cloudflare上の状態は提供中。ローカル実行の候補になります。小型の業務・エージェント用途。
31。モデルはhermes-2-pro-mistral-7b。主タスクはFunction calling。Cloudflare上の状態はベータ・非推奨。ローカル実行の候補になります。新規採用は避けます。
32。モデルはindictrans2-en-indic-1B。主タスクは英語→インド諸語翻訳。Cloudflare上の状態は提供中。ローカル実行の候補になります。特定言語対の翻訳。
33。モデルはkimi-k2.5。主タスクは推論・画像理解・Function calling。Cloudflare上の状態は非推奨。ローカル実行は条件付きです。後継K2.6/K2.7を優先。
34。モデルはkimi-k2.6。主タスクは大規模推論・画像理解・Function calling。Cloudflare上の状態は提供中・Paid。ローカル実行は条件付きです。262K文脈。ローカル実行は非現実的。
35。モデルはkimi-k2.7-code。主タスクはコーディング・エージェント。Cloudflare上の状態は提供中・Paid。ローカル実行は条件付きです。262K文脈。高難度コード作業向け。
36。モデルはllama-2-7b-chat-fp16。主タスクはチャットLLM。Cloudflare上の状態は非推奨。ローカル実行の候補になります。旧世代。
37。モデルはllama-2-7b-chat-hf-lora。主タスクはチャットLLM。Cloudflare上の状態はベータ・LoRA。ローカル実行の候補になります。旧世代。
38。モデルはllama-2-7b-chat-int8。主タスクはチャットLLM。Cloudflare上の状態は非推奨。ローカル実行の候補になります。旧世代。
39。モデルはllama-3-8b-instruct。主タスクはテキスト生成。Cloudflare上の状態は非推奨。ローカル実行の候補になります。後継を優先。
40。モデルはllama-3-8b-instruct-awq。主タスクは量子化LLM。Cloudflare上の状態は非推奨。ローカル実行の候補になります。後継を優先。
41。モデルはllama-3.1-70b-instruct。主タスクはテキスト生成。Cloudflare上の状態は非推奨。ローカル実行の候補になります。後継を優先。
42。モデルはllama-3.1-8b-instruct。主タスクはテキスト生成。Cloudflare上の状態は非推奨。ローカル実行の候補になります。後継/fast版を優先。
43。モデルはllama-3.1-8b-instruct-awq。主タスクは量子化LLM。Cloudflare上の状態は非推奨。ローカル実行の候補になります。後継/fast版を優先。
44。モデルはllama-3.1-8b-instruct-fast。主タスクはテキスト生成・LoRA対応。Cloudflare上の状態は提供中。ローカル実行の候補になります。小～中規模の汎用処理。
45。モデルはllama-3.1-8b-instruct-fp8。主タスクはテキスト生成。Cloudflare上の状態は提供中。ローカル実行の候補になります。Cloudflare向けFP8版。ローカルでは別量子化が一般的。
46。モデルはllama-3.2-11b-vision-instruct。主タスクは画像理解・テキスト生成。Cloudflare上の状態は提供中・LoRA対応。ローカル実行の候補になります。画像理解を含むローカル候補。
47。モデルはllama-3.2-1b-instruct。主タスクは小型LLM。Cloudflare上の状態は提供中。ローカル実行の候補になります。端末側・高速分類・簡易生成。
48。モデルはllama-3.2-3b-instruct。主タスクは小型LLM。Cloudflare上の状態は提供中。ローカル実行の候補になります。軽量ローカル候補。
49。モデルはllama-3.3-70b-instruct-fp8-fast。主タスクはFunction callingとLLM。Cloudflare上の状態は提供中・バッチ。ローカル実行の候補になります。高品質だがローカルは大容量メモリ前提。
50。モデルはllama-4-scout-17b-16e-instruct。主タスクはMoE・画像理解・Function calling。Cloudflare上の状態は提供中・バッチ。ローカル実行の候補になります。ローカル可否は量子化とメモリに依存。
51。モデルはllama-guard-3-8b。主タスクは安全性分類。Cloudflare上の状態は提供中・LoRA対応。ローカル実行の候補になります。Guardrailsにも利用。
52。モデルはllava-1.5-7b-hf。主タスクは画像→テキスト。Cloudflare上の状態はベータ。ローカル実行の候補になります。旧世代画像理解モデル。
53。モデルはlucid-origin。主タスクは画像生成。Cloudflare上の状態は提供中・パートナー提供。同じ提供形態でのローカル実行はできません。パートナーモデル。
54。モデルはm2m100-1.2b。主タスクは多言語翻訳。Cloudflare上の状態は提供中・バッチ。ローカル実行の候補になります。多数言語の翻訳。
55。モデルはmelotts。主タスクは音声合成（TTS）。Cloudflare上の状態は提供中。ローカル実行の候補になります。ローカルでも扱いやすいTTS系。
56。モデルはmeta-llama-3-8b-instruct。主タスクはテキスト生成。Cloudflare上の状態は非推奨。ローカル実行の候補になります。重複系旧識別子。新規採用は避けます。
57。モデルはmistral-7b-instruct-v0.1。主タスクはテキスト生成。Cloudflare上の状態は非推奨。ローカル実行の候補になります。旧世代。
58。モデルはmistral-7b-instruct-v0.2。主タスクはテキスト生成。Cloudflare上の状態はベータ・非推奨。ローカル実行の候補になります。旧世代。
59。モデルはmistral-7b-instruct-v0.2-lora。主タスクはテキスト生成。Cloudflare上の状態はベータ・LoRA。ローカル実行の候補になります。LoRA推論用。
60。モデルはmistral-small-3.1-24b-instruct。主タスクはFunction callingと画像理解系LLM。Cloudflare上の状態は提供中。ローカル実行の候補になります。24B級ローカル候補。
61。モデルはmoondream3.1-9B-A2B。主タスクは画像理解モデル。Cloudflare上の状態は提供中。ローカル実行の候補になります。画像理解。MoE/active parameter構成。
62。モデルはnemotron-3-120b-a12b。主タスクは推論・Function calling。Cloudflare上の状態は提供中。ローカル実行の候補になります。256K文脈。ローカルは大容量メモリ前提。
63。モデルはnova-3。主タスクは音声認識（ASR）。Cloudflare上の状態は提供中・パートナー提供・リアルタイム/バッチ。同じ提供形態でのローカル実行はできません。Deepgram Nova-3。
64。モデルはphi-2。主タスクは小型LLM。Cloudflare上の状態はベータ・非推奨。ローカル実行の候補になります。新規採用は避けます。
65。モデルはphoenix-1.0。主タスクは画像生成。Cloudflare上の状態は提供中・パートナー提供。同じ提供形態でのローカル実行はできません。パートナーモデル。
66。モデルはplamo-embedding-1b。主タスクは日本語を含む埋め込み。Cloudflare上の状態は提供中。ローカル実行の候補になります。日本語検索/RAGの有力候補。
67。モデルはqwen2.5-coder-32b-instruct。主タスクはコード生成。Cloudflare上の状態は提供中・LoRA対応。ローカル実行の候補になります。32B。ローカルは量子化前提。
68。モデルはqwen3-30b-a3b-fp8。主タスクは推論・Function calling。Cloudflare上の状態は提供中・バッチ。ローカル実行の候補になります。MoE。Cloudflare版FP8とローカル量子化は別物。
69。モデルはqwen3-embedding-0.6b。主タスクは埋め込み。Cloudflare上の状態は提供中。ローカル実行の候補になります。小型・多言語埋め込み。
70。モデルはqwq-32b。主タスクは推論LLM。Cloudflare上の状態は提供中・LoRA対応。ローカル実行の候補になります。32B reasoning。
71。モデルはresnet-50。主タスクは画像分類。Cloudflare上の状態は提供中。ローカル実行の候補になります。古典的画像分類。
72。モデルはsmart-turn-v2。主タスクは会話ターン/VAD。Cloudflare上の状態は提供中・リアルタイム/バッチ。ローカル実行は条件付きです。音声エージェントの発話終了判定。
73。モデルはsqlcoder-7b-2。主タスクはText-to-SQL。Cloudflare上の状態はベータ・非推奨。ローカル実行の候補になります。新規採用は汎用LLM＋検証層を推奨。
74。モデルはstable-diffusion-v1-5-img2img。主タスクは画像変換。Cloudflare上の状態はベータ。ローカル実行の候補になります。ローカル可。
75。モデルはstable-diffusion-v1-5-inpainting。主タスクは画像修復・部分編集。Cloudflare上の状態はベータ。ローカル実行の候補になります。ローカル可。
76。モデルはstable-diffusion-xl-base-1.0。主タスクは画像生成。Cloudflare上の状態はベータ。ローカル実行の候補になります。ローカル可。GPU/メモリ要件あり。
77。モデルはstable-diffusion-xl-lightning。主タスクは高速画像生成。Cloudflare上の状態はベータ。ローカル実行の候補になります。ローカル可。
78。モデルはuform-gen2-qwen-500m。主タスクは画像→テキスト。Cloudflare上の状態はベータ・非推奨。ローカル実行の候補になります。新規採用は避けます。
79。モデルはwhisper。主タスクは音声認識（ASR）。Cloudflare上の状態は提供中。ローカル実行の候補になります。多言語音声認識。
80。モデルはwhisper-large-v3-turbo。主タスクは音声認識（ASR）。Cloudflare上の状態は提供中・バッチ。ローカル実行の候補になります。高品質・高速寄り。
81。モデルはwhisper-tiny-en。主タスクは英語ASR。Cloudflare上の状態はベータ。ローカル実行の候補になります。軽量・英語専用。
AIへ任せる範囲と、人間が保持する評価、停止、回復、責任の境界を考えたい方は、こちらの記事で判断基準を整理しています。
Workers AIを採用する判断
Workers AIの最大価値は、Macの代替GPUになることではありません。特に重要なのは次の三点です。
大規模モデルを必要な時だけ使える
Kimi、GLM、GPT-OSS 120B、Nemotron等を、GPU購入・常時起動・serving運用なしで使える。断続利用、急な処理増加、複数モデル比較に強い。
推論以外の運用部品が揃っている
AI Gateway、エージェントs、Workflows、AI Search、Vectorize、Browser Run、R2/D1/DOを組み合わせ、PoCではなく運用システムまで作れる。
ローカルモデルも同じ管理面へつなげられる
ローカルQwenを機密・低コスト実行枠、Workers AIを大規模・急な処理増加 実行枠、外部フロンティア APIを最終代替処理にし、AI Gatewayで予算・ログ・安全・振り分けを統一できます。
したがって、推奨はWorkers AIへの全面移行ではありません。まずCloudflareを中心とする小さなモデルゲートウェイを作り、文書検索、エージェント、音声、ブラウザ処理を順番に加えることです。
企業でAI活用をモデル選びだけで終わらせず、業務設計、システム開発、評価、改善運用まで進めたい場合は、支援内容をこちらにまとめています。
出典・参考資料
いいなと思ったら応援しよう！
社会問題×マーケティングが好き / ㍿小さな一歩（前澤ファンド出資先）で養育費の未払い問題にビジネスでトライ→㍿SHIRO創業。社会問題の発見→要因分析→ビジネス考案→実行に必要な資本整備→実行・改善のサイクルが最短で回り社会問題が解決されつづけるインフラを創る。