Cloudflare Workersのエッジ実行を比較｜Lambda@Edge・Fastly・Akamaiとの違いとできること

Cloudflare Workersは、Cloudflareのネットワークの全拠点でJavaScriptやWebAssemblyを動かすエッジ実行基盤です。「エッジで動く」ことの中身は、AWSのLambda@Edge、Fastly Compute、Akamai EdgeWorkersとそれぞれ違い、使える時間・メモリ・データの持ち方に数十倍の差があります。この記事では、2026年10月時点の公式ドキュメントの値で各社のエッジ基盤を比べ、Workersに任せるべき処理と任せるべきでない処理を整理します。Workersそのものの料金・対応言語・始め方は「Cloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめ」で扱っています。

まとめ：Cloudflare Workersをエッジ基盤として選ぶ判断の要点

• Workersは特定のリージョンではなく、348都市（2026年10月時点の公式ネットワークページ）のどの拠点でも同じコードが動く。デプロイ先のリージョンを選ぶ工程が無い。
• CPU時間はFreeで1リクエスト10ms、Paidで既定30秒・最大5分。メモリは128MBで、Akamai EdgeWorkers（通常のハンドラーで1.5〜4MB、responseProviderで2〜6MB）やCloudFront Functions（2MB）より桁違いに大きい。
• 向いているのは、リクエストごとに完結する軽い判定と書き換え（国別の振り分け、A/Bテスト、認証ヘッダーの検査、HTMLの差し替え、APIの中継）。
• 向いていないのは、遠いデータベースへ何度も往復する処理。ユーザーの近くで動くほどDBから遠くなるため、Smart Placementで実行場所をDBの近くへ寄せ、Hyperdriveで接続確立の往復を減らす。
• Workers KVは結果整合で、書き込みが他拠点に見えるまで60秒以上かかる場合がある。即時に一貫した値が必要ならDurable Objects、SQLならD1を選ぶ。

Cloudflare Workersがエッジで動く仕組み：全拠点での実行とIsolate

リクエストを受けた拠点で実行される配置モデル

AWS LambdaやCloud Runは、東京リージョンのように実行場所を1つ選んでデプロイします。Workersにはこの選択がありません。wrangler deployしたコードはCloudflareのネットワーク全体に配られ、ユーザーのリクエストを受け付けた拠点（多くは最寄りのデータセンター）でそのまま実行されます。Cloudflareのネットワークページは2026年10月時点で「348 cities」と公表しており、東京・大阪のように国内にも拠点があります。

CDNのキャッシュと同じ場所でコードが動くため、キャッシュの前段で判定や書き換えをするのが得意です。CDNとの関係は「CDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説」が詳しいです。

コンテナではなくV8 Isolateで分離する理由

どの拠点でも多数の顧客のコードを動かすには、1つの関数あたりのメモリと起動時間を極端に小さくする必要があります。Workersはリクエストごとにコンテナや仮想マシンを立てず、1つのランタイムプロセスの中で多数のV8 Isolate（ヒープを分けた実行単位）を切り替えて動かします。公式ドキュメントは、Isolateの起動はコンテナや仮想マシン上のNodeプロセスより約100倍速く、起動時のメモリも1桁少ないと説明しています。

Node.jsそのものが動いているわけではなく、node:cryptoやnode:fsなどの組み込みAPIはWorkers側の互換実装で提供されます。互換実装はcompatibility_dateが2026-08-04以降なら既定で有効になり（それ以前はnodejs_compatフラグが必要）、ネイティブアドオンを含むnpmパッケージは動きません。Isolateの分離の強さや起動時間の実測は「V8 Isolateとは？Contextとの違い・起動時間の実測とCloudflareの分離設計【2026年9月】」で扱っています。

Smart Placementで「エッジで動かさない」選択肢

ユーザーの近くで動くことは、データベースが1か所にある場合は不利になります。シドニーのユーザーに対してフランクフルトのDBへ3回クエリを投げるWorkerは、往復のたびに地球の反対側まで通信します。Smart Placement（設定はplacement.mode = "smart"）を有効にすると、Cloudflareが拠点ごとのリクエスト所要時間を計測し、速くなる場合だけWorkerをバックエンドの近くの拠点へ寄せて実行します。全プランで使え、判定には配置後最大15分かかります。AWS・GCP・Azureのリージョン名をplacement.regionで明示する指定方法もあります。

Smart Placementが効くのはfetchハンドラーだけで、RPCメソッドや名前付きエントリーポイントは対象外です。配置が有効なWorkerには、Cloudflareがリクエストヘッダーcf-placementを付けます。Worker内でこの値を読み、remote-LHRならロンドン近くへ寄せて実行、local-EWRのようにlocal-で始まれば通常の拠点で動いたと判断できます。

エッジ実行基盤の比較：Lambda@Edge・CloudFront Functions・Fastly Compute・Akamai EdgeWorkers

「エッジ関数」と呼ばれるサービスは、実行方式も上限値もばらばらです。各社の公式ドキュメントの既定値を並べると次のとおりです（2026年10月1日時点）。

出典はWorkersがCloudflare Workers Limits、CloudFront FunctionsとLambda@EdgeがDifferences between CloudFront Functions and Lambda@Edge、FastlyがCompute resource limits、AkamaiがResource tier limitationsです。Akamaiは通常のイベントハンドラーの値をBasic〜Enterpriseの範囲で示し、レスポンス本体を生成するresponseProviderの値を括弧内に併記しました。WorkersのCPU時間はfetch()やKVの応答待ちを含まないため、外部APIを待つ処理なら10msの枠でも足りることが多く、公式は平均的なWorkerの消費を1リクエストあたり約2.2msとしています。

Lambda@Edge・CloudFront Functionsとの違い

AWSはエッジ処理を2段に分けています。CloudFront Functionsはビューワーリクエスト／レスポンスでヘッダーやURLを書き換えるための軽量関数で、ネットワークアクセスもリクエストボディの参照もできません。コードは10KBまでです。外部APIを呼ぶ、ボディを読む、といった処理はLambda@Edgeの担当です。こちらは1つのAWSリージョンで発行した関数をCloudFrontが各地へ複製して実行する仕組みで、料金は100万リクエストあたり0.60ドルに実行時間（128MB秒あたり0.00000625125ドル）が加わります。

Workersは1つのランタイムで両方の役割をこなします。ヘッダーの書き換えと、外部APIを呼んでボディを組み立てる処理を同じコードに書けるのが実務上の最大の違いです。逆に、CloudFrontの配信設定やIAMロールでAWSのサービスと連携させたい場合はLambda@Edgeのほうが設定が少なく済みます。ただしLambda@Edgeは、VPC内のリソースへアクセスする設定や通常の環境変数に対応していません。CDNをCloudFrontのまま使うならAWS側、CDNごと移せるならWorkersという分け方が現実的です。

Fastly Compute・Akamai EdgeWorkersとの違い

Fastly Computeはコードを必ずWebAssemblyにコンパイルし、Wasmtimeで動かします。公式SDKはRust・JavaScript・Go・C++の4言語です。1リクエストのCPU時間は50msで、Workers Paidの既定30秒と比べると短く、重い処理より大量の軽い処理に向いた設計です。WebAssemblyで書く場合の各基盤の上限やWASIの対応状況は「サーバーレスWebAssemblyで何ができるか｜Cloudflare・Fastly・Lambdaの上限とWASI 0.3の現在地」にまとめています。

Akamai EdgeWorkersはJavaScriptのイベントハンドラー（onClientRequestなど）をCDNの処理段階に差し込む方式で、メモリは通常のハンドラーで1.5〜4MB、responseProviderでも2〜6MBと小さく、Akamaiの既存CDN契約に付け足して使う前提の製品です。データストアのEdgeKVは結果整合で、書き込みが全ノードに行き渡るまでの「inconsistency window」を公式は通常10秒以内としています。Workers KVの公式説明は「他拠点では60秒以上かかる場合がある」という上振れの注意で、EdgeKVの「通常10秒以内」とは数値の性質が違うため、同条件の速度比較にはなりません。どちらも書き込み直後の読み取りで古い値が返りうる点は同じです。

VercelとDeno Deployに見るエッジ専用ランタイムの見直し

エッジ実行は各社が同じ方向に進んでいるわけではありません。Vercelは2026年10月時点のドキュメントで「edgeからNode.jsへの移行を推奨」と明記し、Next.js 16.3ではruntime = 'edge'の指定自体が使えなくなりました。Deno Deploy Classicも2026年7月20日での提供終了が告知され、新しいDeno Deployへの移行が案内されています。フレームワーク側のエッジ実行に依存した構成は、提供元の方針で移行を迫られることがあります。Workersを選ぶときも、コードをWeb標準APIで書き、Honoのような複数ランタイムで動くフレームワークを使っておくと移行の手間が減ります（Honoの特徴は「Hono vs FastAPI（Python）の違い」で解説しています）。

Cloudflare Workersで何ができるか：エッジ向きの処理と実装例

エッジに置く価値があるのは、オリジンへ届く前に答えを出せる処理です。代表的なものは次の4つです。

• 国・IP・ヘッダーによるアクセス制御（request.cf.countryで国コードを取れる）
• A/Bテストの群の割り当てと固定（Cookieの読み書き）
• オリジンのHTMLをストリームのまま書き換える（HTMLRewriter）
• 複数APIの中継・認証ヘッダーの付与（APIゲートウェイ）

次のWorkerは前の3つを1本で行う例です。オリジンには手を入れず、管理画面を日本国外から閉じ、ランディングページの見出しをA/B群ごとに差し替えます。

// エッジで完結する3つの処理：国別のアクセス制御・A/Bの割り当て・HTMLの書き換え
const ORIGIN = "https://example.com";

export default {
  async fetch(request) {
    const url = new URL(request.url);

    // 1. 管理画面は日本以外からのアクセスを403で止める
    const country = request.cf?.country ?? "XX";
    if (url.pathname.startsWith("/admin") && country !== "JP") {
      return new Response("Forbidden", { status: 403 });
    }

    // 2. オリジンへ転送（クエリ文字列も引き継ぐ）。/lp のHTML以外はそのまま返す
    const upstream = await fetch(ORIGIN + url.pathname + url.search, request);
    const type = upstream.headers.get("Content-Type") ?? "";
    if (!url.pathname.startsWith("/lp") || !type.startsWith("text/html")) {
      return upstream;
    }

    // 3. A/Bテスト：Cookie「ab」が無ければ50%で割り当て、以後は同じ群に固定
    const cookie = request.headers.get("Cookie") ?? "";
    let group = cookie.match(/(?:^|;\s*)ab=(A|B)(?:;|$)/)?.[1];
    const isNew = !group;
    if (!group) group = Math.random() < 0.5 ? "A" : "B";

    // 4. 見出しを群ごとに書き換える（ストリームのまま変換）
    const rewritten = new HTMLRewriter()
      .on("h1", {
        element(el) {
          el.setInnerContent(group === "A" ? "今すぐ無料で試す" : "14日間の無料トライアル");
        },
      })
      .transform(upstream);

    const res = new Response(rewritten.body, rewritten);
    res.headers.set("X-AB-Group", group);
    if (isNew) res.headers.append("Set-Cookie", `ab=${group}; Path=/; Max-Age=2592000`);
    return res;
  },
};

miniflare 4.20260730.0（ローカル用のWorkersランタイム）でオリジンを模擬して実行すると、cf.countryがUSの/adminは403、JPは200になりました。/lp?campaign=seoはクエリ文字列付きのままオリジンへ転送され、Cookie無しのリクエストにはSet-Cookie: ab=A（またはB）が付きます。ab=Bを送るとSet-Cookie無しで見出しが「14日間の無料トライアル」に差し替わり、notab=B; ab=Badのように名前や値が違うCookieは未割り当てとして扱われました。Content-TypeがJSONの応答は書き換えずに返ります。HTMLRewriterはボディ全体をメモリに読み込まずストリームで書き換えるため、128MBの上限に触れにくい点もエッジ向きです。

この種の処理はオリジン側に実装しても動きますが、オリジンに届く前に403を返せる、キャッシュ済みHTMLにも適用できる、オリジンのコードを触らずに済む、という3点でWorkersに置く意味があります。AIエージェント向けのMCPサーバーをWorkersで公開する用途もあり、手順は「CloudflareでMCPサーバーを構築・公開する方法｜Workersリモートデプロイと認証・ポータル」で解説しています。

エッジでのデータの置き場所：KV・Durable Objects・D1・Hyperdriveの選び方

エッジでコードを動かしても、データが1か所にあれば結局そこまで往復します。Cloudflareはデータの性質ごとに置き場所を分けています。

Workers KVは書き込みを少数の中央ストアに保存し、読まれた拠点にキャッシュする仕組みです。公式のStorage optionsは、よく読まれるキーの読み取りを通常500マイクロ秒〜10msとしていますが、書き込みはキーごとに毎秒1回までで、他拠点へ反映されるまで60秒以上かかる場合があります。「書き込んだ値を直後に別のユーザーが読む」設計にKVを使うと、古い値が返る不具合になります。APIキーの失効やログアウトを即座に効かせたい認証データも、KVだけで管理すると失効前の値で通ってしまう時間が残ります。

Durable Objectsは、IDごとに世界で1つだけ存在するオブジェクトに処理とストレージをまとめる仕組みです。SQLiteバックエンドの容量はPaidで10GB、Freeで1GBです。オブジェクトは単一スレッドで動き、ストレージは強い一貫性を持つため、在庫の引き当てやWebSocketの部屋管理に向きます。ただしfetch()などをawaitしている間は別のリクエストの処理が割り込むため、1リクエストが完了するまで他を待たせる保証ではありません。

D1の書き込みは1つのプライマリDBに集約されます。読み取りレプリカを使うにはSessions APIを通す必要があり、セッション内の読み書きの順序が保たれます。既存のPostgreSQL・MySQLをそのまま使うならHyperdriveが接続のプールとクエリ結果のキャッシュを受け持ち、Workerから毎回TCP接続を張り直す往復を省きます。読み取り結果は既定で60秒（max_age）キャッシュされるため、書き込み直後の値が必要なクエリにはキャッシュを無効にした設定を使います。ファイル置き場のR2は「Cloudflare R2とは？料金・無料枠とS3互換の範囲、使い方を解説」で扱っています。

エッジで動かすべきでない処理：CPU・メモリ・DB往復の制約

Workersに載せて失敗しやすいのは、次の3つの条件のどれかに当てはまる処理です。

• 遠くのDBへ1リクエストで何度も順に問い合わせる処理：一覧を取ってから関連データを1件ずつ引くような逐次クエリは、往復ごとに遅延が積み上がります。Hyperdriveの解説は、遠いリージョンからだと1クエリあたり20〜30ms、近くに置けば1〜3msと例示しています。Smart PlacementでWorkerをDBの近くへ寄せるか、オリジン側に残します。
• 大きなファイルをメモリに展開する処理：メモリは1 Isolateあたり128MBで、超えるとError 1102で止まります。画像や動画の変換はストリームで扱うか、Cloudflare Imagesなど専用サービスへ回します。
• Free枠で重い計算をする処理：FreeのCPU時間は10msです。JWTの署名検証やサーバーサイドレンダリングは公式でも10〜20msかかる例として挙げられており、Freeでは上限に届きます。本番はPaid（月5ドルから）でcpu_msを設定し、暴走時の上限も決めておきます。

サブリクエスト（Workerから外へ出すfetch）はFreeで1リクエスト50回まで、Paidは既定10,000回で、2026年2月の変更により設定で最大1,000万回まで引き上げられます。同時に開ける外向き接続は6本までなので、数百件のAPIを一気に並列で呼ぶ処理はキューに分けます。数時間かかるバッチや、ネイティブバイナリを含むライブラリが必要な処理は、Workersではなくコンテナかサーバーで動かすほうが素直です。

よくある質問

Cloudflare Workersの読み方は？

「クラウドフレア ワーカーズ」と読みます。Cloudflareの社名に続けて、実行単位であるWorker（ワーカー）の複数形を付けた製品名です。

Cloudflareの「エッジ」とは何を指しますか？

ユーザーの近くにあるCloudflareのデータセンター群を指します。2026年10月時点で348都市にあり、CDNのキャッシュ、WAF、Workersの実行がすべて同じ拠点で行われます。特定のリージョンを指す言葉ではありません。

Cloudflare Workersは無料で使えますか？

Freeプランで1日10万リクエスト、1リクエストあたりCPU時間10msまで無料です。超える場合はWorkers Paid（月5ドル・月1,000万リクエストと3,000万CPUミリ秒を含む）に切り替えます。料金の詳細はWorkersの料金・無料枠の解説にまとめています。

Akamai EdgeKVとWorkers KVの違いは？

どちらも結果整合のキーバリューストアです。Akamai EdgeKVは書き込みの反映を通常10秒以内としてEdgeWorkersから使い、Workers KVは他拠点への反映に60秒以上かかることがあると公式に明記されています。即時の一貫性が必要な処理には、どちらも向きません。

Cloudflare WorkersとPagesの違いは？

Pagesは静的サイトの配信とGit連携のビルドが中心で、動的処理はPages Functions（中身はWorkers）で足します。Cloudflareは新規プロジェクトにWorkersの静的アセット機能を勧めており、使い分けは「Cloudflare Pagesの使い方｜公開手順・独自ドメイン・Web Analytics設定とWorkers移行判断」で解説しています。

関連記事

• Cloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめ
• V8 Isolateとは？Contextとの違い・起動時間の実測とCloudflareの分離設計【2026年9月】
• サーバーレスWebAssemblyで何ができるか｜Cloudflare・Fastly・Lambdaの上限とWASI 0.3の現在地
• CDNとは？仕組み・キャッシュ制御からサービスの選び方まで実装目線で解説
• Cloudflare Pagesの使い方｜公開手順・独自ドメイン・Web Analytics設定とWorkers移行判断