先に要点
- Cloudflare Workers は、世界中の Cloudflare エッジロケーションで JavaScript / TypeScript / WASM を実行 するサーバレス実行基盤。AWS Lambda の 「常時温まっているグローバル版」 と捉えると入りやすい。
- 中身は V8 isolates。Node.js のような OS プロセスではなく、「軽量 JS 実行コンテキスト」 を多数同時に動かす設計で、Cold start がほぼゼロ。
- D1(SQLite)・KV(key-value)・R2(S3 互換オブジェクト)・Durable Objects(状態付き)・Queues(キュー)・Pages(静的)・AI(LLM) など、Cloudflare のサービス群と1アカウント内で統合できる。「Cloudflare スタックでフルスタック」 が成立する。
- 料金は 無料枠が大きく、商用利用も可能。本格採用は Cold start ゼロ、グローバル分散、無料枠でも商用OK が刺さるユースケースで急速に拡大している。
Cloudflare Workers ってよく聞くけど、AWS Lambda と何が違うの？ 「Vercel Edge Functions とどっち選べばいいの？」 「D1 や R2 って Cloudflare の中だけで完結できるの？」 ── 2017年に登場した Cloudflare Workers は、「AWS / GCP / Azure の3大クラウドに加わる第4の選択肢」 として、特に Web 開発者から強い支持を集めています。
ざっくり言うと、Cloudflare Workers は 世界中のエッジで JavaScript を即実行する仕組み + その上に乗るデータサービス群 です。 「グローバルに近いユーザーへ素早く返す」 ことを最優先に設計されていて、「Cold start ゼロ」 「軽量 isolates」 「豊富な統合サービス」 という独自の強みを持ちます。
この記事では、2026年5月時点の Cloudflare Workers の状況をベースに、仕組み・他基盤との違い・データサービスとの統合・採用判断軸 を整理します。 価格や上限は変動するので、最終確認は 公式ドキュメント を参照してください。
Workers の中身 — V8 isolates とは
Cloudflare Workers を理解する鍵は、V8 isolates(アイソレーツ) という実行モデルです。
V8 isolates とは
Chrome / Node.js が使う JavaScript エンジン 「V8」 が持つ 軽量サンドボックスの単位。タブごと / ワーカーごとに分けられる仕組みを、サーバ側で多数走らせる発想。
Lambda との根本差
Lambda は 1リクエスト = 1 Node プロセスのコンテナ(間で 「寝てる」 状態がある)。Workers は 常時温まっている isolates のプールから即実行。Cold start が事実上ない のはこの設計のおかげ。
グローバル分散
世界 330 以上のロケーションで稼働。ユーザーから物理的に近い場所で実行されるので、「他大陸のリージョンに往復する」 待ち時間が消える。
「どこででも、常に温まったまま、瞬時に応答する」 仕組みが Workers のコアで、これに合わせた API 設計 + 周辺サービス が組まれている、というのが全体像です。
基本の書き方
最小コードを見ます。
// src/index.ts
export default {
async fetch(request: Request): Promise<Response> {
const url = new URL(request.url);
if (url.pathname === '/') {
return new Response('こんにちは Cloudflare Workers!');
}
if (url.pathname === '/json') {
return Response.json({ message: 'OK', time: Date.now() });
}
return new Response('Not Found', { status: 404 });
},
};
# wrangler.toml
name = "my-worker"
main = "src/index.ts"
compatibility_date = "2026-05-15"
# 開発
wrangler dev
# 本番デプロイ
wrangler deploy
Web 標準 API
「fetch(handler)」 が入口、「Request」 を受け取って 「Response」 を返す。「Service Worker」 と同じ構造で、ブラウザ知識がそのまま活きる。
Wrangler CLI
「wrangler dev」 で ローカルで本物の Workers ランタイムを動かして開発、「wrangler deploy」 で本番反映。「miniflare」 が組み込まれていて挙動再現も高い。
TypeScript 標準対応
テンプレ生成時から TS で始められる。「@cloudflare/workers-types」 で Worker 専用の型もそろっている。
「Web ブラウザの Service Worker を、サーバ側で動かしている」 と理解するのが、Workers をすばやく掴むコツです。
他のエッジサーバレスとの比較
Cloudflare Workers と並ぶ選択肢を整理します。
| 軸 | AWS Lambda | Vercel Edge Functions | Deno Deploy | Cloudflare Workers |
|---|---|---|---|---|
| 実行モデル | コンテナ | V8 isolates | V8 isolates | V8 isolates |
| Cold start | あり(数百ms〜) | ほぼなし | ほぼなし | ほぼなし |
| 実行場所 | 指定リージョン | 世界中の Edge | 世界中の Edge | 世界中の Edge(330+ ロケーション) |
| Node 互換 | 完全(Node 環境) | 限定的 | npm: 経由で多くを動かす | 限定的(Node 互換モードあり) |
| 統合データサービス | AWS 全サービス | Vercel Postgres / KV / Blob | KV / Queues 等 | D1 / KV / R2 / Queues / DO / AI |
| 料金感(無料枠) | あり | あり(商用不可) | あり | 大きい(商用OK) |
| 得意領域 | AWS 中心の本格運用 | Next.js / Vercel スタック | セキュアな Web 標準系 | グローバル分散 / Cloudflare スタック |
要点は 「 どのエコシステムに乗りたいか」 で選ぶ:
- AWS 全体を使う → Lambda
- Next.js + フロント中心 → Vercel
- セキュリティ + Web 標準志向 → Deno Deploy
- 無料枠で商用OK + グローバル分散 + Cloudflare スタック → Workers
「Cloudflare Workers は無料枠の大きさで頭ひとつ抜けている」 のが、個人開発・小規模 SaaS で特に強い理由になっています。
Cloudflare スタックの全体像
Workers の真価は 周辺サービスとの統合 にあります。「Cloudflare の中だけでフルスタックを作れる」 のが大きな差別化点です。
| サービス | 役割 | 典型ユースケース |
|---|---|---|
| Workers | サーバレス実行 | API、middleware、認証、ルーティング |
| Pages | 静的サイトホスティング | Next.js / Astro / Vite のサイト公開 |
| D1 | SQLite ベース RDB | 軽量な業務 DB、メタデータ管理 |
| KV | キーバリューストア | セッション、設定、軽いキャッシュ |
| R2 | オブジェクトストレージ(S3 互換) | 画像 / 動画 / ファイル保管。Egress 無料が強い |
| Durable Objects | 状態を持つ単一インスタンス | チャット、リアルタイム協調、カウンタ |
| Queues | 非同期メッセージキュー | バッチ処理、AI 非同期実行 |
| Workers AI | エッジで動く LLM / モデル | 軽量 LLM 推論、音声、画像 |
| Workers KV キャッシュ | HTTP キャッシュ層 | API レスポンス / 静的アセットキャッシュ |
特に R2 の 「Egress(下り)無料」 は競合(AWS S3 / Vercel Blob)に対して圧倒的優位です。 「画像 / 動画を世界中に配るアプリ」 で、「データ転送料金で爆死する」 リスクを構造的に避けられます。
Workers が向くユースケース
「どんな処理に向くか」 をユースケース別に整理します。
② 認証 / ルーティング / A/B
「 ユーザーの近くで素早く判断したい」 系の処理(Cookie 検査、地理判定、A/B 振り分け、JWT 検証)に最適。Lambda Edge の感覚で書ける。
③ メディア配信 + 加工
「 R2 から画像を取り出して、サイズ変換して返す」 のようなパイプライン。「Cloudflare Images」 を組み合わせると最適化済み画像を返せる。
⑤ 個人開発 / スタートアップ
無料枠が大きいので、「軌道に乗るまで実質ゼロ円で運用」 が可能。「Vercel Hobby は商用 NG」 だが Cloudflare は無料でも商用 OK。
「軽くて、多くて、グローバル」 な処理の代表例で、Workers の良さが体感できます。
Workers が向かないケース
何でも向くわけではないので、避けたほうがいい場面も整理します。
①長時間処理 / 重い計算
「 CPU 時間 / 実行時間に上限」 がある。動画エンコード、長い AI バッチ、PDF レンダリング等は別基盤に逃がす。
② 通常の RDB 直接接続
PostgreSQL / MySQL に TCP 直接接続する系のドライバは基本動かない(Hyperdrive 等で回避可能だが追加設定が必要)。「D1 / Neon HTTP / Supabase HTTP」 を使うのが素直。
③ Node 専用の重い依存
「 puppeteer」 のようなブラウザ起動系、「sharp」 のネイティブ画像処理など。「Browser Rendering」 や 「Cloudflare Images」 で代替する設計が必要。
「軽くて多い」 が得意、「重くて少ない」 は別基盤、という棲み分けを意識すると、無理な採用を避けられます。
料金の見方
Workers の料金は理解しやすい構造です。
無料プラン(Free)
1日10万リクエスト無料、CPU 時間 10ms / リクエスト。商用利用 OK。個人 / 小規模 SaaS の最初の数ヶ月はこれで足りることが多い。
有料プラン(Workers Paid)
月 $5 で、1000万リクエスト + 追加分は従量。「本格的なサービス」 のスタートラインは概ねここ。
CPU 時間ベース
「 リクエスト数」 ではなく 「CPU 実行時間(ミリ秒)」 ベースで課金される。「I/O 待ちは無料」 という設計で、「API を呼んで待つだけ」 のような処理は安く済む。
R2 の egress 無料
R2 から外への転送は無料。「S3 で月数十万円かかっていた egress 料金」 が消える、というのは個人開発から大手まで広く享受できる利点。
「まずは無料で始めて、稼働量が増えてから有料プランに上げる」 が現実的な運用です。
どこで詰まりやすいか
実務で踏みやすい注意点も整理します。
①Node 専用ライブラリの非互換
` Node 互換モード(「nodejs_compat」)」 で多くが動くようになったが、「100% 互換ではない」。ネイティブモジュールに依存するもの、ファイルシステムを直接触るものは要確認。
② Durable Objects の習熟
「 状態を持つ単一インスタンス」 という概念は最初分かりにくい。「チャット」 「カウンタ」 「リアルタイム協調」 の代表的なパターンを通じて学ぶのが早道。
③ 環境変数 / バインディング
Workers では 「process.env」 ではなく、「env」 オブジェクト(「fetch」 の引数)から取り出す。「どの DB に接続するか」 は 「wrangler.toml」 の binding 定義で結びつける。Node の感覚との差を最初に押さえる。
④ CPU 時間制限の落とし穴
「 CPU 計算時間 50ms 制限」 などをうっかり超えると、無料プランでは即停止 / 有料でも追加課金。重い処理は 「Queues」 や 「Workflows」 に逃がす設計を最初から考える。
「軽くて速い代わりに、制約も独特」 のが Workers の正直な姿で、最初の数日は慣れが必要です。
採用判断のチェックリスト
「いま Workers を選ぶか」 の判断材料です。
「新規で軽量 API、グローバル配信、コスト最適」 の3拍子を狙うなら、Workers は2026年現在もっとも合理的な選択肢の1つです。
AI 時代の Workers
AI 連携の文脈でも Workers の特徴は強く効きます。
エッジで AI 応答ストリーミング
OpenAI / Anthropic API を Workers から呼んで 「世界中のユーザーに低遅延で AI 応答」 を流す。Hono + Workers の組み合わせが事実上のデファクト構成。
Workers AI のエッジ推論
Cloudflare 自身が用意する 「Workers AI」 で、「Llama 系 / Whisper / Embeddings」 をエッジ実行できる。「OpenAI を呼ばずに完結したい」 ニーズに応える。
RAG パターンとの相性
「 Vectorize(ベクトル DB)」 + Workers AI 埋め込みモデル + LLM 呼び出し、を1スタックで組める。「AI 検索アプリ」 を Cloudflare 内だけで完結できる。
コスト最適化
AI 関連は実行回数が増えやすく、「高額請求」 が課題になりがち。無料枠 + 安価な従量課金の Workers でコストを抑えられる。
「軽量 + グローバル + 無料枠 + AI 統合」 の組み合わせは、AI 時代の個人開発と相性が抜群です。
Cloudflare Workers に関するよくある質問
Q. Workers と AWS Lambda、どちらを選ぶべきですか？
A. 用途で分けます。「 AWS 全体を使う / Node 100% 互換が必要」 なら Lambda、「 グローバル分散 / Cold start ゼロ / 無料枠商用 OK」 なら Workers。「既存スタックがどこか」 で大半が決まります。
Q. Workers で Node のパッケージは全部使えますか？
A. nodejs_compat 互換モードで多くが動きますが、100% ではありません。ネイティブモジュール、ファイルシステム直接操作、特殊な低レベル API が必要なパッケージは動かないことがあります。採用前に主要依存を試すのが鉄則です。
Q. D1 と PostgreSQL、どちらが向きますか？
A. 軽量 / SQLite で十分 / Cloudflare 完結なら D1、既存資産 / 強い RDB 機能が必要なら PostgreSQL(Neon / Supabase 経由)。「どちらも HTTP / Workers との連携」 が整っているので、技術的な障壁は小さいです。
Q. Workers でセッション管理はどうしますか？
A. KV / D1 / Durable Objects のどれかに保存します。軽い / TTL がある → KV、永続データと一緒に管理したい → D1、リアルタイム性が必要 → Durable Objects という棲み分けが現実的です。
Q. Workers Pages との関係は？
A. Pages は 静的ホスティング + 軽量関数 で、Workers は 純粋なサーバレス実行。「Next.js / Astro のサイトを置く」 のは Pages、「API サーバ専用」 は Workers、という棲み分けです。最近は両者の機能が近づいており、「Pages Functions」 として Workers と統合される方向です。
Q. デバッグ / ログはどう確認しますか？
A. wrangler tail で本番ログをライブで見られます。「console.log」 がそのまま流れてきます。「Workers Logs」 ダッシュボードでも構造化ログを確認できます。
Q. Workers の学習コストは？
A. JS / TS と Web 標準 API を知っていれば1日で書き始められます。Hono を組み合わせると、Express の感覚で書けて学習コストはさらに下がります。「独自概念(Durable Objects, バインディング)」 を覚えるのに数日、というイメージです。