はじめに#

Cloudflare Workers は Cloudflare のエッジネットワーク上でコードを実行できるサーバーレス環境です。世界 300 以上の都市に配置されたデータセンターで、ユーザーに最も近い拠点から関数が応答します。

「AWS Lambda のエッジ版」と紹介されることが多いですが、ランタイムモデルと起動オーバーヘッドが根本的に異なります。この記事では Workers の仕組みを入門レベルで整理します。

Pages との使い分けを先に知りたい方は Cloudflare Pages と Workers の違いと使い分け を、Pages 単体の入門は Cloudflare Pages とは何か を参照してください。

V8 Isolate モデル#

Workers は Node.js でも Deno でもなく、Chrome と同じ V8 JavaScript エンジンの Isolate という単位で動きます。Isolate は V8 が提供する軽量なサンドボックスで、1 つのプロセス内に数千個を同居させられます。

AWS Lambda が「リクエストごとに専用のコンテナを起動する」のに対し、Workers は「1 つのプロセスの中で Isolate を切り替える」方式です。結果として以下の特性が生まれます。

Lambda の「15 分」は wall-clock（実時間）の上限ですが、Workers の「30 秒 / 5 分」は CPU を実際に使った時間 の上限です。HTTP リクエストの wall-clock 自体はクライアント接続中は制限なく、fetch のネットワーク待ちはカウントされません。軸が違う点に注意してください。

Isolate の起動が数ミリ秒で済むため、Workers には実質的なコールドスタートが存在しません。常に「新しい Isolate を立ち上げる」コストで済み、事前ウォームアップが不要です。

リクエストライフサイクル#

Workers のコードは fetch ハンドラを export するのが基本形です。

1
export default {
2
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
3
    const url = new URL(request.url);
4
    return new Response(`Hello from ${url.pathname}`);
5
  },
6
};

引数は 3 つです。

• request: 標準の Request オブジェクト
• env: バインド（後述）経由で注入される外部リソース
• ctx: waitUntil で非同期処理をレスポンス後に継続させるためのコンテキスト

Node.js の http モジュールや Express のような独自 API はありません。すべて Web 標準の Fetch API です。フロントエンドで fetch() を使っている感覚のまま、サーバー側も書けます。

1
ctx.waitUntil(sendAnalytics(request));
2
return new Response("ok");

Bindings で外部リソースを注入する#

Workers から他の Cloudflare リソースを使うには バインド を設定します。環境変数のリソース版だと捉えてください。

wrangler.toml（または wrangler.jsonc）で宣言します。

1
name = "my-worker"
2
main = "src/index.ts"
3

4
[[kv_namespaces]]
5
binding = "CACHE"
6
id = "xxxxxxxxxxxx"
7

8
[[d1_databases]]
9
binding = "DB"
10
database_name = "my-db"
11
database_id = "yyyyyyyyyyyy"

コード側は env.CACHE や env.DB として型付きで参照できます。

1
export default {
2
  async fetch(request, env) {
3
    const cached = await env.CACHE.get("key");
4
    if (cached) return new Response(cached);
5
    const { results } = await env.DB.prepare("SELECT name FROM users").all();
6
    await env.CACHE.put("key", JSON.stringify(results), { expirationTtl: 60 });
7
    return Response.json(results);
8
  },
9
};

主要なバインド先は以下の通りです。

実行時間とリソース制限#

Workers の無料枠では CPU 時間が 1 リクエストあたり 10 ms までです。Paid プラン（$5/月〜）では既定で 30 秒、wrangler.toml の [limits] cpu_ms を設定すれば最大 5 分（300,000 ms）まで引き上げられます。ここで言う CPU 時間は「実際に CPU を使った時間」で、fetch の待ち時間（ネットワーク I/O）は含まれません。

1
[limits]
2
cpu_ms = 60000  # 60 秒まで許可

メモリは 128 MB 固定です。重い画像処理や機械学習モデルのロードには向かず、そうした処理は R2 や Workers AI に委ねる構成が推奨されます。

Cron Triggers と Scheduled Workers

scheduled ハンドラを export すると、cron 式で定期実行される Worker が作れます。Pages Functions では使えない機能で、バッチ処理や外部 API のポーリングは Workers 単体で組む必要があります。

デプロイ#

デプロイは Wrangler CLI で行います。

$ pnpm create cloudflare@latest my-worker
$ cd my-worker
$ pnpm run deploy

wrangler deploy は TypeScript のコンパイル、バンドル、Cloudflare への配信までを一気に行います。デプロイから世界中のエッジに反映されるまで数秒です。

開発中は wrangler dev でローカル実行できます。V8 Isolate を Miniflare で模倣しており、バインドされた KV や D1 もローカルのエミュレータで動きます。

Node.js と何が違うか#

Workers は Web 標準 API が中心で、Node.js 固有 API（fs、net など）は使えません。代わりに以下の対応があります。

• ファイル I/O: R2 や KV に置き換える
• TCP / UDP: connect() API（TCP のみ、制限あり）
• Crypto: Web Crypto API 標準
• 環境変数: env 経由

Node.js 互換性が必要なら nodejs_compat フラグを有効にすると、主要な Node.js API のポリフィル が使えます。ただし全 API が揃っているわけではなく、express のような「プロセス前提」のフレームワークは動きません。Hono のように Web 標準だけで書かれたフレームワークを選ぶのが安全です。

まとめ#

• Workers は V8 Isolate で動くエッジ実行環境で、コールドスタートがほぼゼロ
• fetch ハンドラを export するだけで始められ、API は Web 標準の Fetch API
• バインド経由で KV / R2 / D1 / Queues などを型安全に扱える
• Node.js 互換 API は限定的。Hono などの Web 標準ベースのフレームワークと相性が良い

次は具体的なユースケースとして API Proxy の構築例を書きます。静的サイトとの組み合わせは Pages と Workers の使い分け を、無料枠の全体像は Cloudflare 無料枠運用ガイド を参照してください。