Cloudflare 28：Workers AI ― GPU を持たずに AI を呼ぶ

自前の GPU は、高い・遠い・止められない

Workers AI が無い世界で、自分で GPU サーバーを用意したとしましょう。困りごとを並べると、次のようになります。

アクセスが波のように増えたり減ったりする Web のアプリでは、「いちばん混む時間に合わせて GPU を並べ、ほとんどの時間は遊ばせておく」ことになりがちです。これは、小さなチームや個人の開発ではとても割に合いません。

欲しいのは、必要なときだけ GPU を使い、使ったぶんだけ払う形です。Workers がサーバーの台数を考えずに済む仕組みだったように、AI でも同じことをしたい。それが Workers AI の出発点です。

一言でいうと：Worker から1行で呼べる「サーバーレス GPU」

Workers AI は、Cloudflare の網の中にある GPU で、用意されたオープンなモデルを動かすサービスです。サーバーレス、つまりGPU を借りる契約も、台数の設定もありません。

使い方の中心は、Worker に付ける AI バインディングです。バインディングは、Worker から Cloudflare の他の機能を呼ぶための「差し込み口」でした（18号）。KV や R2 と同じように AI のバインディングを付けると、コードの中で env.AI.run(モデル名, 入力) と書くだけで推論（モデルに答えを出させること）ができます。

代わりに、置けるモデルは Cloudflare のカタログにあるものが基本です。自分で一から学習したモデルを自由に載せる場所ではない、という点は覚えておきましょう（一部のモデルでは、LoRA という軽い追加学習の結果を載せることはできます）。

仕組み①：利用者の質問は、近くの拠点の Worker に届く

ここから、1つの質問がどう処理されるかを、図の上で追いかけます。

まず、利用者のブラウザやアプリが、あなたの Worker にリクエストを送ります。これは、ふつうの Worker と何も変わりません。エニーキャスト（00号）のおかげで、リクエストは利用者に近い Cloudflare の拠点に届き、そこで Worker が動き出します。

Worker は、受け取ったリクエストから質問の文章を取り出します。ここで、ログインしているかを確かめたり、1人あたりの回数を制限したり（06号のレート制限）、入力の長さをチェックしたりするのも Worker の仕事です。

大事なのは、AI のために特別な入口を作る必要がないことです。いつもの Worker の中に、AI を呼ぶ1行が加わるだけです。API キーを利用者のブラウザに渡すこともありません。AI を呼ぶのはサーバー側の Worker なので、鍵にあたるものはすべて Cloudflare の中に閉じています。

仕組み②：env.AI.run() で、GPU のある拠点が推論する

Worker が env.AI.run() を呼ぶと、リクエストは Cloudflare の網の中で GPU を持つ拠点に送られ、そこでモデルが動きます。

Cloudflare は、世界中の多くの拠点に GPU を配置しています。どの拠点の GPU を使うかは Cloudflare が決めるので、あなたが地域を選ぶ必要はありません。混み具合に応じて、空いている GPU に振り分けられます。

モデルは、あらかじめ Cloudflare が GPU に載せて待たせています。自分で GPU サーバーを立てるときに悩む「モデルのファイルを読み込むのに時間がかかる」「最初の1回だけ遅い」といった問題を、利用者の側で考えることはほとんどありません。

仕組み③：結果が Worker に戻り、利用者へ返る

推論が終わると、結果が Worker に戻ってきます。文章のモデルなら生成された文章、埋め込みのモデルなら数字の並び、画像のモデルなら画像のデータです。

Worker は、その結果をそのまま返しても、加工してから返しても構いません。たとえば、要約した文章を D1（23号）に保存してから返す、生成した画像を R2（22号）に置いて URL を返す、といった使い方ができます。

文章のモデルには、ストリーミングという返し方もあります。stream: true を指定すると、答えが全部できあがるのを待たず、できた部分から少しずつ受け取れます。チャット画面で文字が順に出てくるあの動きです。長い答えでも、利用者は最初の1文字をすぐ見られるので、待たされている感じが大きく減ります。

ここまでの3ページが、Workers AI の流れのすべてです。入口は Worker、推論は Cloudflare の GPU、出口もまた Worker。あなたが書くのは、真ん中の1行だけです。

モデルのカタログ：文章・埋め込み・画像・音声

Workers AI で使えるモデルは、公式の Models のページに一覧があります。用途ごとに、おおむね次のような種類に分かれています。

モデル名は @cf/作者/モデル名 の形です。たとえば @cf/meta/llama-3.1-8b-instruct は Meta の Llama 3.1 の 8B（80億パラメータ）の対話用モデルです。

とくに覚えておきたいのが埋め込みです。文章を数字の並び（ベクトル）に変えると、「意味の近い文章どうし」を計算で探せるようになります。これが次の29号の Vectorize につながり、社内文書に答える AI（RAG）の土台になります。

カタログは頻繁に更新され、新しいモデルが加わり、古いモデルは廃止されます。ここに挙げた名前も、使う前に一覧で確かめてください。

料金の単位「ニューロン」とは

Workers AI の料金は、ニューロン（Neurons） という独自の単位で数えます。

AI のモデルは、種類によって「どれだけ使ったか」の数え方がばらばらです。文章のモデルならトークン（単語のかけら）の数、画像のモデルなら画像の大きさや生成の手数、音声のモデルなら音声の長さ。これを全部別々の料金表にすると、比べるのも見積もるのも大変です。

そこで Workers AI は、どのモデルの使用量もニューロンという1つの単位に換算します。ニューロンは、おおよそ「GPU がどれだけ計算したか」を表す量だと考えてください。大きなモデルほど、長い入力ほど、多くのニューロンを使います。

モデルごとの換算の目安は、公式の料金ページに表で載っています。同じ仕事でも、小さなモデルで足りるならニューロンは大きく減ります。「まず小さいモデルで試し、足りなければ大きくする」が、費用を抑える基本です。

導入：Worker に AI バインディングを足すだけ

Workers AI を使う手順は、Workers の他のバインディングとほとんど同じです。

外部の AI の会社の API と違い、API キーを発行して環境変数に入れる手順がありません。バインディングは、その Worker が属するアカウントの権限で動くからです。

TypeScript を使うなら、npx wrangler types を実行すると、設定ファイルから Env の型（AI: Ai など）が作られます。

Worker を使わずに、別のサーバーから直接呼びたいときは REST API もあります。アカウント ID とモデル名を含む URL に POST する形で、この場合は Workers AI の権限を持つ API トークンを作って使います。

使い方①：wrangler.toml にバインディングを書く

設定ファイルには、次のように [ai] の節を1つ足します。

name = "ask-ai"
main = "src/index.ts"
compatibility_date = "2026-09-01"

[ai]
binding = "AI"

binding = "AI" の AI が、コードの中で env.AI として見える名前になります。wrangler.jsonc を使う場合も、"ai": { "binding": "AI" } と書くだけで意味は同じです。

1つ注意があります。npx wrangler dev でローカルで動かしているときも、AI の呼び出しは Cloudflare の本物の GPU に送られます。手元のパソコンに GPU とモデルを用意するわけではないからです。そのため、開発中の試行でも無料枠のニューロンは減り、有料プランなら料金もかかります。

ループの中でうっかり何百回も呼ぶようなコードを書いたときは、すぐに止めましょう。

使い方②：env.AI.run() で文章を作る

質問を受け取って、AI に答えさせる Worker の例です。

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const { question } = await req.json<{ question: string }>();
    const out = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
      messages: [
        { role: "system", content: "日本語で簡潔に答えてください" },
        { role: "user", content: question },
      ],
      max_tokens: 512,
    });
    return Response.json(out);
  },
};

messages は、チャット形式の入力です。system で AI の振る舞いを指示し、user に利用者の質問を入れます。max_tokens は出力の長さの上限です。

埋め込みや音声も、呼び方は同じ env.AI.run() です。モデル名と入力の形だけが変わります。

const emb = await env.AI.run("@cf/baai/bge-m3", { text: ["猫が好き", "犬を飼っている"] });
// emb.data[0] が1つめの文章のベクトル（数字の並び）

入力と出力の形はモデルごとに違います。公式のモデルのページに、各モデルの入力と出力の例が載っているので、それに合わせて書きます。

料金と制限：毎日の無料枠と、その先の従量課金

2026年9月時点の料金の骨格は、次のとおりです。

無料枠は「試す」「小さな個人のツールで使う」には十分な量です。ただし大きなモデルほど1回あたりのニューロンが多いので、何回呼べるかはモデル次第です。

本番のサービスで使うなら、Workers Paid プランにしておくと、無料枠を超えても止まらずに従量課金へ切り替わります。逆に、思わぬ請求を避けたいなら、呼び出し回数を Worker 側で制限したり、AI Gateway（30号）で使用量を見張ったりしましょう。

数字は変わりやすいので、必ず公式の Pricing と Limits のページで最新の値を確かめてください。

よくある落とし穴

Workers AI を使い始めた人がつまずきやすい点を並べます。

とくに最後の点は、Workers AI に限らず AI 全般の注意点です。社内文書に基づいて答えさせたいなら、次の29号で扱う RAG の形にすると、根拠のある答えに近づけられます。

他の機能とのつながり

Workers AI は、単独よりも他の機能と組み合わせたときに力を発揮します。

とくに AI Gateway は、Workers AI を使うなら最初から通しておくと便利です。env.AI.run() の3つめの引数でゲートウェイを指定するだけで、すべての呼び出しが記録され、同じ質問への答えをキャッシュすることもできます（30号）。