Workers AI

解決する課題

• 機械学習モデルを動かすためにGPUサーバーの調達・維持・スケーリングを自前で行うのは運用負荷が高い
• 推論エンドポイントをアプリケーションの近く（利用者に近い場所）に置き、レイテンシを抑えて応答したい
• 生成AIやレコメンド機能を既存のWebアプリに組み込みたいが、別途AI基盤を構築するコストや専門知識をかけたくない
• テキスト生成、埋め込み生成、画像分類、音声認識など複数種類のタスクを、統一されたインターフェースで扱いたい

主要概念と用語

• モデル: テキスト生成、埋め込み、画像分類、音声認識、翻訳など、タスクごとに用意された学習済みモデル群。オープンウェイトモデルを中心にカタログとして提供される
• 推論（Inference）: 学習済みモデルに入力を与えて出力を得る処理そのもの。Workers AIが担うのはこの推論部分であり、モデルの学習は対象外
• バインディング（AI Binding）: WorkersのコードからWorkers AIのモデルを呼び出すための連携設定。wrangler.toml/wrangler.jsonc に定義し、コード内から関数呼び出しのように利用できる
• REST API: Workersを介さず、HTTP経由で直接モデルを呼び出す方法。他言語・他環境からの利用に向く
• 埋め込み（Embeddings）: テキストなどを数値ベクトルに変換したもの。類似検索やレコメンドの基盤になり、Vectorizeとの組み合わせで使われることが多い
• ストリーミング応答: テキスト生成モデルの出力を、生成され次第逐次返す方式。チャットUIなどで体感速度を高めるために使う
• AI Gateway: Workers AIを含む各種AIプロバイダーへの呼び出しをキャッシュ・ログ・レート制御などの観点で一元管理する仕組み（Workers AIとあわせて使われることが多い別サービス）

仕様・制限・クォータ

• 提供されるモデルはテキスト生成（LLM）、テキスト埋め込み、画像分類、物体検出、音声認識（文字起こし）、翻訳、画像生成など多岐にわたるカテゴリに分かれる
• 各モデルには入力トークン数や画像サイズなど、モデル固有の上限が設定されている。上限はモデルごとに異なるため、利用前に対象モデルの仕様を確認する必要がある
• 大規模言語モデルの応答時間はモデルサイズや入力の長さに依存し、リアルタイム性が強く求められる用途では小型モデルの選定やストリーミング応答の活用が有効
• 呼び出し回数やレート制限は利用プランに応じて設定されており、大量呼び出しを行う場合は上限を踏まえた設計が必要

内部の仕組み

Workers AIは、Cloudflareのネットワーク上に分散配置されたGPUを持つ実行基盤で、あらかじめ用意された学習済みモデルへの推論リクエストを処理します。開発者はWorkersのコードからバインディングを通じてモデルを呼び出すか、REST API経由で直接リクエストを送信します。リクエストは、利用者に近い場所で処理されるよう、Cloudflareのネットワーク内でルーティングされます。

Workersバインディングを使う場合、アプリケーションコードとAI推論の呼び出しが同じ実行環境の中で完結するため、別途SDKの初期化や認証トークンの受け渡しを個別に組む必要がありません。生成された埋め込みベクトルをVectorizeに保存して類似検索に使ったり、生成したテキストをそのままレスポンスとして返したりと、他のCloudflare製品とパイプラインとして連携させやすい構成になっています。

設計パターン / ベストプラクティス

• 軽量モデルの優先: リアルタイム応答が必要な用途では、精度と応答速度のバランスを見て、必要以上に大きなモデルを選ばない
• ストリーミングの活用: チャットボットなど対話的なUIでは、テキスト生成をストリーミングで受け取り、逐次表示することで体感速度を上げる
• 埋め込み＋ベクトル検索の組み合わせ: 文書やFAQの埋め込みを事前に生成してVectorizeに格納し、検索時にクエリの埋め込みと突き合わせるRAG（検索拡張生成）構成が定番
• フォールバック設計: 特定モデルが利用不可・レート制限に達した場合に備え、別モデルや外部APIへのフォールバックを用意する
• AI Gatewayでの一元管理: 複数のAIプロバイダーやモデルを併用する場合、AI Gatewayを介してログ・キャッシュ・コスト管理を一箇所にまとめる

運用・監視

• ダッシュボードから、モデルごとの呼び出し回数やエラー状況を確認できる
• AI Gatewayを併用している場合は、リクエスト単位のログやレイテンシ、キャッシュヒット率などより詳細な可観測性が得られる
• Workersからの呼び出しであれば、Workers Logsやwranglerのtail機能を使って、AI呼び出しを含むリクエスト全体の挙動を追跡できる
• モデルの応答内容やレイテンシの傾向を定期的に確認し、モデル入れ替えや設定変更が必要かどうかを判断する

コスト

• 利用したモデルの種類と処理量（トークン数や画像枚数など、モデルの特性に応じた単位）に基づく従量課金が基本
• GPUインスタンスを自前で確保する場合と異なり、アイドル時間に対する固定費は発生しない
• 無料枠が用意されている場合があるが、内容や上限は変更されうるため、正確な見積もりは公式の料金ページで確認することが望ましい
• AI Gatewayのキャッシュを活用すると、同一内容の呼び出しに対する重複課金を避けられる場合がある

セキュリティ

• Workersバインディング経由での呼び出しは、Cloudflareの認証基盤の中で完結するため、追加のAPIキー管理が不要になる
• REST API経由で直接呼び出す場合は、APIトークンをシークレットとして安全に管理し、必要最小限の権限に絞る
• 利用者からの入力をそのままプロンプトに埋め込む場合、プロンプトインジェクションのリスクを考慮し、入力のサニタイズや出力の検証を行う
• 生成された内容を外部に公開する用途では、モデルの出力に対するフィルタリングやモデレーションの仕組みをあわせて検討する

関連サービス・比較

Workers AIは、AWSにおけるBedrockのように、複数の学習済みモデルをマネージドな推論エンドポイントとして提供するサービスに近い位置づけです。両者とも自前でGPUインフラを持たずにモデルを呼び出せる点は共通していますが、Workers AIはCloudflareのエッジ実行環境（Workers）との統合を前提としている点が特徴です。

ハンズオン / CLI例

# Workers AIを使うプロジェクトのひな形を作成
npm create cloudflare@latest my-ai-app

# wrangler.jsonc / wrangler.toml にAIバインディングを追加した後、
# ローカルでモデル呼び出しを含む動作を確認
npx wrangler dev

# 利用可能なモデルの一覧を確認
npx wrangler ai models

# 本番環境へデプロイ
npx wrangler deploy

# デプロイ後のログをリアルタイムで確認
npx wrangler tail