Cloudflare Workersとは?エッジで動くサーバーレス

《 Cloudflare完全ガイド 目次へ 》

ここから第5章「開発プラットフォーム」に入ります。第4章までのCloudflareは、すでにあるサーバーを守ったり、速くしたり、つないだりする存在でした。あくまで主役は自分のサーバーで、Cloudflareはその手前に立つ通り道です。

この章で扱うのは、その前提が変わる世界です。Cloudflare Workersを使うと、自分のサーバーを1台も持たないまま、Cloudflareのネットワーク上で自分の書いたプログラムを動かせます。世界300以上の都市にあるCloudflareの拠点そのものが、あなたのアプリケーションの実行環境になります。

このページで分かること

  • サーバーレスとは何か、従来のサーバー運用と何が違うのか
  • Cloudflare Workersがどこでどう動くのか(エッジで動くとはどういうことか)
  • なぜWorkersは起動が速いのか(V8アイソレートの仕組み)
  • Workersのコードがどんな形をしていて、どう公開するのか
  • バインディングによって他のCloudflareサービスとつながる仕組み
  • 料金と主な制限、そして初心者がつまずきやすいポイント

サーバーレスとは:サーバーを意識しない実行方式

サーバーレス(Serverless)は、直訳すると「サーバーがない」ですが、実際にサーバーが消えるわけではありません。正しくは「サーバーの用意と運用を自分でしなくてよい」という意味です。

従来のWebアプリケーションでは、まずサーバーを1台用意するところから始まります。OSを入れ、ミドルウェアを入れ、セキュリティ更新を当て続け、アクセスが増えれば増強し、減れば持て余す。プログラムを書く前と後に、こうした作業が延々と付いてきます。

サーバーレスでは、開発者が用意するのは処理そのものだけです。「リクエストが来たら、この処理を実行してほしい」というコードを預けると、実行環境の確保・起動・拡大・縮小はすべてプラットフォーム側が引き受けます。アクセスが来ない時間は何も動かず、料金も発生しません。

Cloudflare Workersは、このサーバーレスをCloudflareの世界規模ネットワークの上で実現したサービスです。そして「どこで実行されるか」が、他社のサーバーレスとの決定的な違いになります。

Workersはどこで動くのか

一般的なクラウドのサーバーレス(AWS Lambdaなど)では、実行するリージョン(地域)を自分で選びます。東京リージョンを選べば、世界中のどこからアクセスが来ても処理は東京で走ります。ブラジルの利用者は、地球を半周した先で処理が終わるのを待つことになります。

Workersにはリージョンの選択がありません。デプロイしたコードはCloudflareの全ネットワークへ配布され、リクエストを受け取った拠点でそのまま実行されます。日本からのアクセスは東京や大阪で、ドイツからのアクセスはフランクフルトで処理される。利用者から見れば、常に一番近いところにサーバーがある状態です。

この「利用者に近い場所」を、ネットワークの言葉でエッジ(edge:末端)と呼びます。第1章で扱ったCDNが「コンテンツを利用者の近くに置く」仕組みだったのに対し、Workersは「プログラムの実行そのものを利用者の近くに置く」仕組みです。

従来のサーバー構成とWorkersの違い
図1:従来のサーバー構成とWorkersの違い

デプロイの速さも特徴です。wrangler deploy の1コマンドで、数十秒のうちに世界中の拠点へ反映されます。地域ごとにサーバーを立てて回る必要はありません。

なぜ起動が速いのか:V8アイソレート

サーバーレスには昔から、コールドスタート(久しぶりのリクエストで実行環境を起動するまでの待ち時間)という弱点がありました。一般的なサーバーレスは、関数ごとにコンテナや仮想マシンを立ち上げ、その中で言語のランタイムを起動します。この準備に数百ミリ秒から数秒かかることがあります。

Workersはこの構造を採りません。使うのはV8アイソレート(isolate)という仕組みです。V8はGoogle Chromeにも使われているJavaScriptエンジンで、アイソレートはその中に作られる隔離された小さな実行空間を指します。ブラウザが複数のタブを互いに干渉させずに動かしているのと同じ考え方です。

Cloudflareの各サーバーでは、JavaScriptランタイムを最初に一度だけ起動しておき、その上に何百・何千というアイソレートを並べて切り替えながら動かします。リクエストが来たときに用意するのはアイソレートひとつだけなので、コンテナや仮想マシンを立ち上げる場合と比べて桁違いに速く、消費メモリも大幅に少なくて済みます。公式ドキュメントでは、コンテナ上でNodeプロセスを起動する場合の約100倍速く起動できると説明されています。

隔離が保証されているため、同じサーバーの上で無数の利用者のWorkersが同時に動いていても、互いのデータやメモリに触れることはできません。

Workersのコードはどんな形か

Workersのコードは、「リクエストを受け取り、レスポンスを返す関数」という形をしています。もっとも単純なWorkerは次のようになります。

export default {
  async fetch(request, env, ctx) {
    return new Response("Hello World!");
  },
};

fetch は、HTTPリクエストが届いたときに呼ばれる入口(ハンドラ)です。引数の意味は次のとおりです。

  • request:届いたリクエスト。URL・ヘッダー・メソッド・本文などを読み取れます
  • env:後述するバインディング(他サービスへの接続口)や環境変数がまとまっています
  • ctx:レスポンスを返した後に処理を続ける(waitUntil)などの制御に使います

書き方はブラウザのJavaScriptとほぼ同じで、RequestResponsefetch() といったWeb標準のAPIがそのまま使えます。JavaScript・TypeScriptのほか、Python・Rust、WebAssembly経由で他の言語にも対応しています。

HTTPリクエスト以外にも、時刻指定で起動するCron Triggers(定期実行)、メール受信をきっかけに動くEmail Workers、キューからメッセージを受け取る処理など、複数の入口が用意されています。

開発から公開までの流れ

開発にはWranglerというCloudflare公式のコマンドラインツールを使います。基本の流れは3ステップです。

npm create cloudflare@latest -- my-first-worker   # ひな形を作る
npx wrangler dev                                  # 手元で動かす(localhost:8787)
npx wrangler deploy                               # 世界中へ公開する

wrangler dev は手元のPCでWorkersの実行環境を再現するため、本番と同じ挙動をオフラインでも確認できます。

デプロイすると、<Worker名>.<アカウント名>.workers.dev という無料のURLがすぐに割り当てられ、その場で動作を確認できます。独自ドメインで公開したい場合は、Cloudflareで管理しているドメインにルート(例:example.com/api/*)やカスタムドメインを設定します。ドメインの取得・移管については第1章の解説を参照してください。

Workersは静的ファイル(HTML・CSS・画像など)の配信にも対応しており、静的アセットの配信自体は無料です。フロントエンドとバックエンドを1つのWorkerにまとめて公開する構成が、現在の標準的な作り方になっています。

バインディング:他サービスとつながる仕組み

Workersが単なる小さな実行環境で終わらないのは、バインディング(binding)という仕組みがあるからです。

バインディングは、Workerに対して「このリソースを使ってよい」という権限と、そのための操作方法を同時に与える接続口です。設定ファイルで対応付けておくと、コード中では env.MY_KV のような形で直接呼び出せます。APIキーやトークンをコードに書く必要がなく、鍵そのものがコードに露出しないため、うっかり漏らす事故も起きません。

バインディングでつながるCloudflareのサービス群
図2:バインディングでつながるCloudflareのサービス群

主なバインディングには次のものがあります。いずれも本ガイドの後の章で個別に解説します。

  • Workers KV:エッジのKey-Valueストア(第6章)
  • R2:オブジェクトストレージ(第6章)
  • D1:SQLiteベースのデータベース(第6章)
  • Durable Objects:状態を持てるWorkers(次章のテーマのひとつ)
  • Queues / Workflows:非同期処理・長時間処理(第5章後半)
  • Workers AI / Vectorize:AIモデルの実行とベクトル検索(第7章)
  • Hyperdrive:既存のデータベースへの高速接続(第6章)
  • Service bindings:他のWorkerを直接呼び出す接続

Workersを中心に、必要な部品をバインディングで足していく。これがCloudflareの開発プラットフォームの基本構造です。

何に使えるのか

具体例を挙げます。

  • APIサーバー:フォームの受け取り、外部APIの中継、認証付きのデータ取得など。サーバーを持たずにバックエンドを用意できます
  • リクエストの書き換え:アクセス元の国や端末に応じて表示を出し分ける、古いURLを新しいURLへ転送する、ヘッダーを付け足すといった処理
  • フルスタックアプリ:静的アセットの配信とサーバー側の処理を1つのWorkerにまとめ、React・Next.js・Astroなどのフレームワークをそのまま動かす
  • 定期実行のバッチ処理:Cron Triggersで、毎朝の集計や外部データの取得を自動化する
  • AIアプリケーション:Workers AIやAI Gatewayと組み合わせ、AIの応答を返すアプリを作る(第7章)

第4章までに扱ったWAFやRate Limitingが「決まった機能を設定で使う」ものだったのに対し、Workersは「必要な処理を自分で書いて足せる」層です。Cloudflareの標準機能では届かない要件を、自分のコードで埋められるようになります。

料金

Workersには無料プランと有料プランがあります(2026年8月時点)。

Free Workers Paid
月額 0円 5ドル〜
リクエスト数 1日10万まで 月1,000万まで込み、超過分は100万あたり0.30ドル
CPU時間 1リクエストあたり10ミリ秒まで 月3,000万CPUミリ秒まで込み、超過分は100万CPUミリ秒あたり0.02ドル
転送量課金 なし なし

ここで重要なのは、課金や制限の対象がCPU時間であって、処理の待ち時間ではないという点です。CPU時間とは、実際にプロセッサが計算に費やした時間を指します。外部APIやデータベースの応答を待っている間はCPUを使っていないため、この時間には含まれません。「無料プランは10ミリ秒まで」と聞くと厳しく感じますが、待ち時間が中心の一般的なAPI処理であれば、10ミリ秒に収まることは珍しくありません。

有料プランでは、1回の実行あたり最大5分(既定値は30秒)までCPU時間を使えます。Cron TriggersやQueueの処理では最大15分まで延長できます。

主な制限

代表的な上限は次のとおりです(2026年8月時点)。

  • メモリ:どのプランでもアイソレートあたり128MB
  • コードサイズ:Free 3MB/Paid 10MB(いずれもgzip圧縮後)
  • サブリクエスト:1回の実行から外部へ出せるリクエストは Free 50/Paid 1,000(上位では拡張可能)
  • Worker数:1アカウントあたり Free 100個/Paid 500個
  • 環境変数:Free 64個/Paid 128個(1つあたり5KBまで)

初心者が注意するポイント

  • Node.jsそのものではありません:Workersの実行環境はWeb標準APIが基本です。ただし2026年8月4日以降の互換性日付(compatibility date)を指定したWorkerでは、Node.js互換モードが既定で有効になり、node:cryptonode:buffer などの主要な組み込みAPIが追加設定なしで使えます。それでも、ファイルシステムへの自由な読み書きなど、サーバー前提のライブラリがそのまま動かない場面はあります
  • 状態を保持できません:Workerは基本的にリクエストごとに独立して動き、同じ利用者の2回のアクセスが同じ実行環境に届く保証はありません。変数に値を入れて次のリクエストで読む、という書き方は成立しません。データを保持したいときはKVやD1などのストレージを使い、リアルタイムに一貫した状態が必要な場合はDurable Objectsを使います
  • CPU時間と実時間の混同:前述のとおり制限はCPU時間です。逆に言えば、重い計算をループで回すような処理は、実時間が短くても上限に当たります
  • リージョンは選べません:処理はリクエストを受けた拠点で走ります。「必ず国内で処理させたい」といったデータ所在地の要件がある場合は、別途の検討が必要です
  • 無料プランの1日10万リクエスト:ここでいうリクエストはWorkerの実行回数です。ページ内の画像やCSSをWorker経由で配信していると、想像より早く消費します。静的アセットの配信は無料の枠で扱われるため、構成を分けておくと無駄がありません

関連サービス

  • Pages:静的サイトのホスティング。現在は静的アセット対応のWorkersが後継となる位置づけ(次ページ)
  • Durable Objects:状態を持つWorkers。チャットや共同編集など、一貫性が必要な処理に使う(第5章)
  • KV / R2 / D1:Workersから使うストレージとデータベース(第6章)
  • Workers AI:Workersの上でAIモデルを動かす(第7章)
  • Email Routing:受信メールをWorkersで処理できる(Email Workers)
  • WAF・Rate Limiting:Workersで作ったAPIも、第2章のセキュリティ機能でそのまま守れます

まとめ

  • サーバーレスとは、サーバーの用意と運用をプラットフォームに任せ、処理だけを書く方式
  • Cloudflare Workersはリージョンを選ばず、リクエストを受け取った最寄りの拠点でコードを実行する
  • V8アイソレートにより、コンテナ方式のサーバーレスより桁違いに速く起動する
  • コードは「リクエストを受けてレスポンスを返す」関数の形。Wranglerで作成・ローカル実行・デプロイまで完結する
  • バインディングでストレージ・データベース・AIなどのサービスと接続でき、これが開発プラットフォームの中核になる
  • 無料プランは1日10万リクエスト・CPU時間10ミリ秒まで。有料プランは月5ドルから

次のページでは、Workersと並ぶ入口だったCloudflare Pagesを扱います。静的サイトのホスティングとして広く使われてきたサービスですが、いまWorkersとの関係がどうなっているのかも含めて整理します。

次に読む

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。

タイトルとURLをコピーしました