Cloudflare Workersとは?対応言語・無料枠・使い方・料金を最新版で総まとめ
Cloudflare Workersは、世界中のCloudflareエッジ拠点でJavaScriptなどのコードを動かすサーバーレス実行環境です。サーバーの調達もスケール設定も不要で、デプロイしたコードはユーザーに最も近い拠点で実行されます。本記事では「どの言語が使えるか」「無料枠でどこまで動かせるか」「wranglerでの実際の使い方」「料金プラン」「Pagesとの違い」を、2026年時点の仕様にそって整理します。サーバーレスやエッジコンピューティングの概念そのものを先に押さえたい場合は、Cloudflare Workersとエッジコンピューティングの基本解説を併せて参照してください。
目次
まとめ:Cloudflare Workersの要点
- 無料枠は1日10万リクエスト・1呼び出しあたりCPU時間10ミリ秒。クレジットカード登録なしで
workers.devサブドメインに公開できます。 - 標準言語はJavaScriptとTypeScript。Pythonはオープンベータで利用でき、Rust・C・C++などはWebAssembly経由で動かせます。
- 実装はESモジュール構文(
export default)が標準。旧来のaddEventListener("fetch", ...)(Service Worker構文)は非推奨になりました。 - 有料はWorkers Paidの月額5ドルから。1か月あたり1,000万リクエストと3,000万CPUミリ秒が含まれ、超過分のみ従量課金です。かつてのBundled/Unboundプランは廃止され、Standard使用モデルに一本化されました。
- KV・D1・R2・Queues・Workers AIなどの周辺サービスとバインディングで連携でき、エッジで完結するアプリを組めます。
- 静的サイト中心ならPages、汎用的なサーバーレス処理ならWorkersが基本の使い分けですが、2024年以降は機能が統合され差は縮小しています。
Cloudflare Workersの実行モデルとエッジで動く仕組み
Cloudflare Workersは、コンテナや仮想マシンではなくV8 Isolateという軽量な分離環境でコードを実行します。1つのプロセス内で多数のIsolateを切り替えるため、リクエストごとにサーバーを立ち上げる従来型のサーバーレス(AWS Lambdaなど)で問題になるコールドスタートが事実上発生しません。この実行モデルの内部はV8 Isolateの仕組みとContextとの違いで詳しく扱っています。
コードはCloudflareが世界中に持つエッジ拠点へ自動的に配置され、アクセスしてきたユーザーに最も近い拠点で実行されます。オリジンサーバーへの往復を挟まないため、APIの前段処理・リダイレクト・認証・A/Bテストといった「リクエストの途中に差し込む処理」を低遅延でさばけるのが特徴です。Cloudflareというサービス全体の位置づけはCloudflareとは?機能・メリット・デメリットの解説にまとめています。Workersで具体的に何を作れるかは、CloudflareとMCPサーバーを組み合わせたWebシステム構築のような実装例が参考になります。
Cloudflare Workersで使える対応言語
「どの言語で書けるのか」は導入前に迷いやすい点です。Workersのランタイムはオープンソースの workerd を基盤としており、ネイティブ対応と WebAssembly 経由とで扱いが分かれます。
| 言語 | 対応状況 | 実行方法 |
|---|---|---|
| JavaScript | ネイティブ対応 | V8で直接実行 |
| TypeScript | ネイティブ対応 | ビルド時にJSへトランスパイル |
| Python | オープンベータ | Pyodide(CPythonのWebAssembly版)で実行 |
| Rust / C / C++ | WebAssembly経由 | Wasmへコンパイルして読み込み |
実務での第一候補はTypeScriptです。バインディングや環境変数を型安全に扱え、型定義は wrangler types コマンドで生成するのが現行の推奨です。Pythonはオープンベータながら、KV・R2・D1・Workers AIなどの主要バインディングに最初から対応し、FastAPIやNumPyなど一部のパッケージも利用できます。ただしベータ段階のため本番投入前にはコールドスタートや対応パッケージの範囲を必ず検証してください。JavaやGoのような言語をそのまま動かすことはできず、WebAssemblyにコンパイルできる言語であれば組み込める、という整理になります。
Cloudflare Workersの使い方:wrangler導入からデプロイまで
開発からデプロイまでは公式CLIの wrangler で完結します。ここでは最小構成の手順を、現行のESモジュール構文で示します。
プロジェクト作成とwranglerのセットアップ
Node.jsが入っていれば、対話式セットアップツール C3(create-cloudflare)でひな形を生成できます。
npm create cloudflare@latest -- my-worker
cd my-worker
npx wrangler login
wrangler login でブラウザが開き、Cloudflareアカウントと紐づきます。設定は wrangler.toml(または wrangler.jsonc)に集約され、Workerの名前・互換性日付・バインディングをここで宣言します。
ESモジュール構文でのWorker実装(旧Service Worker構文との違い)
現在のWorkerは、リクエストを処理する fetch ハンドラをデフォルトエクスポートのオブジェクトとして書きます。
export default {
async fetch(request, env, ctx) {
return new Response("Hello World!");
},
};
古い解説記事で見かける次の addEventListener 形式はService Worker構文と呼ばれ、現在は非推奨です。動作はしますが、新機能が提供されない場合があり、Durable Objectsなど一部機能はESモジュール構文を前提とします。
// 非推奨(旧Service Worker構文)
addEventListener("fetch", (event) => {
event.respondWith(new Response("Hello World!"));
});
両者の実質的な違いはバインディングへのアクセス方法です。ESモジュール構文ではKVやD1などのバインディングが第2引数 env 経由で渡されるため、グローバル変数に依存せず、テストや関数分割がしやすくなります。これから書くなら export default 形式に統一してください。
ローカル開発(wrangler dev)と本番デプロイ(wrangler deploy)
実装中は wrangler dev でローカルにエッジ相当の環境を立ち上げ、ブラウザやcurlで動作確認します。本番反映は wrangler deploy 一発で、数秒のうちに世界中のエッジへ配信されます。
npx wrangler dev // ローカルでプレビュー
npx wrangler deploy // 本番エッジへ公開
独自ドメインを割り当てない場合、デプロイ先は <worker名>.<アカウント名>.workers.dev という無料サブドメインになります。これが「workers.devとは」で検索される公開先で、検証や小規模公開ならこのサブドメインのまま運用できます。
Cloudflare Workersの無料枠・料金・制限
コスト面はWorkers採用の判断を最も左右する論点です。無料枠で始めて、必要になったら有料へ移行する流れが基本になります。
無料枠でできること(1日10万リクエスト)
無料プランでは1日あたり10万リクエスト、1呼び出しあたりCPU時間10ミリ秒まで実行できます。個人開発、検証環境、アクセスの少ない社内ツールであれば、無料枠のまま本番運用できる水準です。workers.dev サブドメインへの公開も無料に含まれます。
有料プランの料金体系(Standardモデル・月額5ドル〜)
無料枠を超える場合はWorkers Paid(月額5ドル)に移行します。月額には1,000万リクエストと3,000万CPUミリ秒が含まれ、超過分は100万リクエストあたり0.30ドル、100万CPUミリ秒あたり0.02ドルの従量課金です。
| 項目 | 無料プラン | Workers Paid(月額5ドル) |
|---|---|---|
| リクエスト | 10万/日 | 1,000万/月(超過0.30ドル/100万) |
| CPU時間 | 10ミリ秒/呼び出し | 3,000万CPUミリ秒/月(超過0.02ドル/100万) |
| 独自ドメイン | 利用可 | 利用可 |
課金対象がCPU時間(コードがCPUを使った時間)である点が重要です。fetch での外部API待ちやKV読み出しの待機時間は課金されないため、I/O待ちが多いプロキシ用途では実コストが想定より低く収まります。なお、かつて存在したBundledプランとUnboundプランは2024年3月以降レガシー扱いとなり、新規には選べずStandard使用モデルに一本化されています。古い記事の「Unboundで長時間実行」という説明は、これから始める場合の現行仕様では当てはまりません。AI処理やKVなどサービスごとの料金は別建てのため、見積もり時はCloudflare Workersの基本と注意点の解説や公式の料金ページで最新の単価を確認してください。
知っておくべき制限値(CPU時間・メモリ・サブリクエスト)
無料枠の数値以外にも、設計段階で押さえるべき上限があります。代表的なものは次のとおりです(変動するため正確な値は公式のLimitsで確認してください)。
- メモリ:1 isolateあたり128MB。大きな画像処理やインメモリ集計には不向きです。
- CPU時間:無料は1呼び出しあたり10ミリ秒。有料は既定30秒で、設定により最大5分まで引き上げ可能です。
- サブリクエスト数:1リクエスト内で発行できる外部リクエストは無料50件。有料は2026年2月の改定で既定1万件、設定により最大1,000万件まで拡大しました(旧1,000件上限は撤廃)。
「Exceeded CPU Time」エラーが出る場合は、重い同期処理をループで回していないか、無料枠の10ミリ秒に収まらない計算をしていないかを疑うのが定石です。
Cloudflare Workersの周辺サービス連携(KV・D1・R2・Queues)
Workers単体は「処理」を担うだけですが、Cloudflareはデータ保存や非同期処理のためのサービスを揃えており、バインディングで呼び出せます。
| サービス | 役割 | 向いている用途 |
|---|---|---|
| Workers KV | キー・バリューストア | 設定値・セッション・キャッシュ |
| D1 | SQLite互換データベース | リレーショナルなデータ管理 |
| R2 | オブジェクトストレージ | 画像・ファイル保存(下り転送料無料) |
| Queues | メッセージキュー | 非同期ジョブ・バッチ処理 |
| Durable Objects | 状態を持つ単一インスタンス | リアルタイム協調・カウンタ |
たとえばKVからの読み出しは、ESモジュール構文なら env 経由で次のように書きます。
export default {
async fetch(request, env) {
const value = await env.MY_KV.get("setting");
return new Response(value ?? "not found");
},
};
ファイル保存にはR2が有力で、S3互換APIを持ちながら下り転送料(エグレス課金)が無料という強みがあります。詳細はCloudflare R2の特徴とオブジェクトストレージとしての選択肢で扱っています。
Cloudflare Workers AIでのエッジ推論
Workers AIを使うと、外部のAI APIを呼ばずにCloudflareのエッジ上で機械学習モデルを推論できます。LLM・画像生成・文字起こし・翻訳など複数カテゴリのモデルが提供され、env.AI バインディング経由で呼び出します。
export default {
async fetch(request, env) {
const result = await env.AI.run("@cf/meta/llama-3.1-8b-instruct", {
prompt: "Cloudflare Workersを一言で説明して",
});
return Response.json(result);
},
};
料金は実行量に応じた「Neurons」という単位での従量課金で、日次の無料枠も用意されています。OpenAIなど外部APIを叩く構成と比べ、リクエストとモデル推論を同じエッジで完結できるため、往復のレイテンシを抑えやすいのが利点です。モデルの種類や単価は更新が早いため、利用前に公式ドキュメントで最新を確認してください。
Cloudflare WorkersとPagesの違い・使い分け
「WorkersとPagesのどちらを使うべきか」は実際に多く検索される論点です。出発点の発想が異なります。
| 観点 | Cloudflare Workers | Cloudflare Pages |
|---|---|---|
| 主な対象 | 汎用サーバーレス処理 | 静的サイト・フロントエンド |
| デプロイ起点 | コード(wrangler) | Gitリポジトリ連携の自動ビルド |
| サーバー処理 | 本体がサーバー処理 | Pages Functionsで補完 |
判断の目安はこうです。ReactやAstroなどでビルドした静的サイトをGit連携で公開したいならPages、APIや動的処理が主役で柔軟に制御したいならWorkersを選びます。ただし2024年以降、WorkersにStatic Assets(静的アセット配信)が統合され、Pagesでできることの多くはWorkers側でも完結するようになりました。Cloudflare自身も新規プロジェクトはWorkersを起点にする方向を示しており、これから始めるならWorkersを基盤に据え、静的配信もWorkersでまとめる構成が将来の移行コストを抑えやすいと考えてよいでしょう。
よくある質問(FAQ)
Cloudflare Workersは無料で使えますか?
使えます。無料プランで1日10万リクエスト、1呼び出しあたりCPU時間10ミリ秒まで実行でき、workers.dev サブドメインへの公開も無料です。アクセスの少ないツールやAPIなら、無料枠のまま本番運用できる場合もあります。
Cloudflare Workersで使えるプログラミング言語は何ですか?
JavaScriptとTypeScriptがネイティブ対応で、実務ではTypeScriptが第一候補です。Pythonはオープンベータで利用でき、Rust・C・C++などはWebAssemblyにコンパイルすれば動かせます。JavaやGoをそのまま実行することはできません。
Cloudflare WorkersとPagesの違いは何ですか?
Workersは汎用的なサーバーレス処理、PagesはGit連携で静的サイトを公開するサービスです。動的処理が主役ならWorkers、ビルド済みフロントエンドの公開が主役ならPagesが基本ですが、現在は機能が統合され差は縮小しています。
BundledプランとUnboundプランの違いは?
現在、新規では区別がありません。両プランは2024年3月以降レガシー扱いとなり、新規はCPU時間で課金するStandard使用モデルに一本化されました。古い記事のBundled/Unboundという表現は、これから始める場合の現行仕様には当てはまりません。
workers.devとは何ですか?
独自ドメインを割り当てないときにWorkerが公開される無料サブドメインです。<worker名>.<アカウント名>.workers.dev の形式で、検証や小規模な公開ならこのアドレスのまま利用できます。