Cloudflare 18：Workers ― 世界中の拠点で動く、あなたの関数

一言でいうと：エッジの拠点で動く、あなたの関数

Workers を一言でいうと、「Cloudflare の世界中の拠点（エッジ）で動く、あなたの関数」です。

00号で見たとおり、Cloudflare は世界の300を超える都市に拠点を持ち、利用者のリクエストはいちばん近い拠点に届きます。Workers を使うと、その拠点であなたの書いたコードがそのまま動きます。

あなたがコードを1回デプロイすると、Cloudflare はそれを世界中の拠点に配ります。東京の利用者のリクエストは東京の拠点で、ロンドンの利用者のリクエストはロンドンの拠点で処理されます。どこで動かすかを選ぶ必要はありません。

このような「サーバーを意識しない」形をサーバーレスと呼びます。図の右の「オリジン」は、あっても無くても構いません。既存のサーバーの前に挟んで使うこともできるし、Worker だけでアプリ全体を作ることもできます。

なぜ速いのか：コンテナではなく V8 isolate

サーバーレス自体は、他のクラウドにもあります。Workers が違うのは、コードを動かす入れ物です。

多くのサーバーレスは、コードごとにコンテナや小さな仮想マシン（VM） を用意します。その中に OS の一部と、Node.js などのランタイムを入れ、その上であなたのコードを動かします。1つのコードにつき、OS とランタイムが1セットずつ要ります。

Workers は、V8 isolate という入れ物を使います。V8 は Google Chrome の JavaScript エンジンで、Chrome はタブごとに isolate を作って、あるタブのコードが別のタブのメモリを覗けないように分けています。Workers も同じ技術で、1つのプロセスとランタイムを、たくさんの利用者のコードで共有し、コードごとにはメモリの区画だけを分けます。

1つあたりが小さいので、Cloudflare はすべての拠点に、すべての利用者のコードを置いておけるのです。コンテナの方式で同じことをしようとすると、拠点の機械がいくらあっても足りません。

だから「コールドスタート」がほとんど無い

サーバーレスでよく問題になるのがコールドスタートです。しばらく呼ばれていなかった関数を呼ぶと、入れ物を起動するところから始まるので、最初の1回だけ極端に遅くなる現象です。

コンテナの方式では、OS とランタイムの起動を待つ必要があり、数百ミリ秒から、重い場合は数秒かかります。これを避けるために、わざと定期的に呼んで「温めておく」工夫をしている人もいます。

isolate の方式では、OS もランタイムも最初から動いています。新しく作るのはメモリの区画だけなので、起動は数ミリ秒で済みます。図で、左の赤い部分（毎回起動が要るもの）と、右の緑の部分（最初から温まっているもの）を比べてください。

Cloudflare は、利用者が接続を始めた段階（TLS のあいさつの途中）で、どの Worker が呼ばれそうかを見て準備を始める工夫もしています。そのため、多くの場合、利用者から見た待ち時間はほぼゼロになります。

その代わり、isolate には制約もあります。

これらは「なぜ Workers でできないことがあるのか」の答えでもあります。

書くのは fetch という関数1つ

Worker のコードは驚くほど小さく始められます。書くのは fetch という関数1つです。

export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext): Promise<Response> {
    const url = new URL(request.url);
    if (url.pathname === "/hello") {
      return new Response("こんにちは");
    }
    return Response.json({ path: url.pathname }, { status: 404 });
  },
};

引数は3つです。

返すのは Response です。Request と Response は、ブラウザの fetch API と同じものです。Workers は Node.js 独自の書き方ではなく、Web 標準の API を中心に作られているので、ブラウザの JavaScript を書いたことがあれば、多くがそのまま使えます。

TypeScript もそのまま書けます。雛形を作るとき TypeScript を選べば、Env の型は npx wrangler types で設定ファイルから自動生成できます。JavaScript のほか、Python や、WebAssembly に変換した Rust なども動かせます。

バインディング：env から他の機能を呼ぶ

Worker 単体では、状態を覚えておくことができません（isolate は毎回まっさらだと思ってください）。データを保存したり、AI を呼んだりするには、Cloudflare の他の機能とつなぎます。このつなぎ方をバインディングと呼びます。

バインディングは、設定ファイルに「この名前で、この KV（や R2 や D1）を使う」と書くだけです。するとコードの env に、その名前でつながった道具が入ってきます。

export default {
  async fetch(request, env) {
    const hit = await env.KV.get("greeting");        // KV（20号）
    const file = await env.BUCKET.get("logo.png");   // R2（22号）
    const { results } = await env.DB.prepare("SELECT * FROM posts").all(); // D1（23号）
    return Response.json({ hit, results, hasLogo: file !== null });
  },
};

普通のサーバーなら、データベースの接続文字列やパスワード、アクセスキーをどこかに置いて、コードから読み込みます。バインディングではそれが要りません。Cloudflare が「この Worker はこの KV を使ってよい」と知っているので、鍵を持ち回る必要がないのです。鍵が漏れる心配も、鍵を定期的に取り替える手間も減ります。

図の上の段が、データを置く・処理を任せる機能です。下の段の右2つ、環境変数（vars） と秘密の値（secret） も、同じ env から読みます。

導入：雛形を作り、手元で試し、配る

Workers を始めるのに必要なのは、Cloudflare のアカウントと Node.js だけです。ドメインは要りません。

wrangler は、Workers を作る・試す・配るための公式のコマンドラインの道具です（34号で詳しく扱います）。

wrangler dev は、手元のパソコンで、本番とほぼ同じ実行環境（workerd という、Workers の実行部分をオープンソースにしたもの）を立ち上げます。KV や D1 なども手元の模擬版につながるので、本番のデータを汚さずに試せます。

wrangler deploy を実行すると、数秒で世界中の拠点に行き渡ります。デプロイのたびに版（バージョン） が記録されるので、問題があれば管理画面やコマンドで前の版に戻せます。

コマンドを使わず、管理画面の「Workers & Pages」から雛形を選んで作り、ブラウザの中でコードを書き換えることもできます。また、GitHub などのリポジトリをつなぐと、push のたびに自動でビルドとデプロイが走り、ブランチごとに試し用の URL も作られます（Workers Builds）。

設定は wrangler.jsonc に、秘密は secret に

Worker の設定は、プロジェクトの一番上にある wrangler.jsonc（または wrangler.toml）に書きます。

{
  "name": "my-worker",
  "main": "src/index.ts",
  "compatibility_date": "2026-09-01",
  "vars": { "GREETING": "こんにちは" },
  "kv_namespaces": [{ "binding": "KV", "id": "<KV の ID>" }],
  "r2_buckets": [{ "binding": "BUCKET", "bucket_name": "my-bucket" }]
}

compatibility_date（互換日） は Workers らしい仕組みです。Cloudflare は実行環境を毎週のように更新しますが、挙動が変わる修正は「この日付以降を指定した Worker にだけ」効くようにしています。日付を固定しておけば、ある日突然あなたの Worker の動きが変わることはありません。

パスワードや API キーは、vars に書いてはいけません。設定ファイルは git に入るからです。代わりに次のコマンドで登録します。

$ npx wrangler secret put API_KEY

値は暗号化して保存され、管理画面でも中身は見えません。コードからは env.API_KEY で読めます。手元で試すときは、.dev.vars というファイル（git には入れない）に書いておきます。

公開の住所は3通り：workers.dev・ルート・カスタムドメイン

デプロイした Worker には、どの住所でアクセスできるのでしょうか。3つの方法があります。

workers.dev は、アカウントごとに付くサブドメインです。ドメインを持っていなくても、デプロイした瞬間に世界中から使えます。本番では使わないなら、設定で無効にできます。

ルートは、Cloudflare で管理しているドメイン（01号）の「ある道」にだけ Worker を挟む方法です。たとえば example.com/api/* をルートにすると、/api/ で始まるリクエストだけが Worker に届き、それ以外は今までどおりオリジンへ行きます。既存のサイトを少しずつ Workers に移すときに便利です。Worker の中から fetch(request) を呼べば、オリジンへの取り次ぎもできます。

カスタムドメインは、api.example.com のようなホスト名を丸ごと Worker に割り当てる方法です。オリジンが無いことが前提で、DNS の行と SSL 証明書（03号）を Cloudflare が自動で用意してくれます。Worker だけでアプリを作るなら、ふつうはこちらを使います。

静的ファイルも Node.js の部品も、同じ Worker で

Web アプリには、コードで作る応答（API）のほかに、HTML・CSS・画像などの静的ファイルがあります。以前は、静的ファイルは Pages（19号）に、API は Workers に、と分けるのが普通でした。今は Workers だけで両方を配れます。これが静的アセットです。

{
  "assets": {
    "directory": "./dist",
    "not_found_handling": "single-page-application"
  }
}

directory に置いたファイルは、Worker のコードを通らずにそのまま返されます。ファイルが無い道だけが Worker の fetch に届くので、「画面は静的ファイル、/api/ はコード」という構成が1つの Worker でできます。not_found_handling を single-page-application にすると、React などで作った SPA の画面遷移にも対応できます。

もう1つ、よく必要になるのが Node.js 互換です。Workers は Web 標準の API が基本ですが、npm のパッケージには Node.js の機能（Buffer・crypto・process.env など）を前提にしたものがたくさんあります。設定に次の1行を足すと、それらの多くが使えるようになります。

{ "compatibility_flags": ["nodejs_compat"] }

ただし、すべてではありません。前のページで見たとおり、isolate は OS を共有しているので、ローカルのファイルを読み書きする処理や、子プロセスを起動する処理は動きません。使いたいパッケージがあるときは、まず手元の wrangler dev で動くか確かめましょう。

料金と制限：数えるのは「回数」と「CPU 時間」

Workers の料金は、リクエストの回数と CPU 時間で決まります。2026年9月時点の主な数字は次のとおりです。料金・上限は変わるので、必ず公式の Pricing と Limits のページで確かめてください。

大事なのは、CPU 時間は「実際に計算していた時間」だけを数えることです。外部の API やデータベースの返事を待っている時間は含まれません。1回の処理に3秒かかっても、そのほとんどが待ち時間なら、CPU 時間は数ミリ秒で済みます。一般的なサーバーレスの「動いていた時間」で課金する方式とは、ここが違います。

Free の10ミリ秒は短く見えますが、JSON を組み立てて返す、KV から値を読んで返す、といった普通の API なら十分に収まることが多いです。画像の変換や大きなデータの圧縮のような重い計算は、上限にぶつかりやすいので注意します。

ほかにも、メモリの上限、1回のリクエストから外へ出せるリクエストの数（サブリクエスト）、Worker のコードの大きさなどに上限があります。無料枠を超えたとき、Free では超えた分のリクエストがエラーになり、Paid では従量で課金されます。

よくある落とし穴

Workers を使い始めた人がよくつまずく点をまとめます。

特に1つ目は、普通のサーバーの感覚で書くと必ずはまります。「カウンターをグローバル変数で数える」コードは、手元の wrangler dev では動いているように見えても、本番では世界中の別々の isolate がそれぞれ数えるので、でたらめな値になります。

Worker は「毎回まっさらで、どこで動くか分からない」と思って書くのが安全です。状態を1か所で正しく数えたいときの答えが、21号の Durable Objects です。

他の号とのつながり：Workers は開発者向け機能の中心

このマガジンの18号から31号までは、ほとんどが「Worker から使うもの」です。Workers は、Cloudflare の開発者向け機能の中心にあります。

どれも、前に見たバインディングでつながり、env.名前 で呼び出します。つまり、この号の fetch 関数とバインディングの考え方が分かれば、残りの号は「新しい道具が1つ増える」だけです。

設定ファイルやデプロイをチームで管理する方法は、34号（Wrangler と Terraform）で扱います。