Cloudflareのエッジコンピューティング機能

コードとデータを、ユーザーの最寄りで実行する

エッジコンピューティングとは

従来のクラウドは、特定の地域にあるデータセンターでアプリケーションを実行するため、地理的に離れたユーザーほど通信の往復に時間がかかります。
例えば、東京のユーザーが米国東海岸のデータセンターにリクエストを送る場合、往復だけで150～200ms程度の遅延が発生し、これがAPI呼び出しのたびに積み重なります。
エッジコンピューティングは、この処理そのものをユーザーの最寄りの拠点で実行することで、この往復時間を削減する仕組みです。
Cloudflareは、世界8地域・100か国以上、337都市にまたがる自社ネットワーク上で、コードとデータの両方をエッジで実行・保持できる「Workers」プラットフォームを提供しています。

コンテナ・VMとの違い

一般的なサーバーレス基盤(AWS Lambda等)は、リクエストごとにコンテナやマイクロVMを起動するため、休眠状態からの起動、いわゆる「コールドスタート」に数百ms～数秒かかることがあります。
Workersは、コンテナやVMではなく、ブラウザのJavaScriptエンジンでも使われている軽量な実行単位「V8 Isolate」で処理を分離しているため、コールドスタートがほぼ発生せず、1ms未満でリクエストの処理を開始できます。
この違いにより、認証チェックやパーソナライゼーションのような、リクエストのたびに必ず通る処理を、遅延の影響を抑えたままエッジに置くことができます。

Workersの動作の仕組み

Workersは、fetchイベントと呼ばれる仕組みでリクエストを受け取り、用途に応じて2つの動作方式を使い分けられます。
どちらの方式も、リクエストがオリジンサーバーに到達するかどうかをエッジ側で制御できる点は共通です。

HTTPリクエストを変更しない方式

リクエスト内容はそのままに、特定の判定・観測処理のみをエッジ側で行い、判定結果に応じてオリジンへの到達可否だけを制御します。
認証トークンの検証結果によるリクエストの遮断や、A/Bテストの振り分けラベルをヘッダーに付与するだけの処理などが該当します。

HTTPリクエスト・レスポンスを変更する方式

Workerが、設定したロジックに基づいてHTTPリクエストを変更したうえでオリジンサーバーへ送信します。
オリジンからのHTTPレスポンスについても、同様にエッジ側で内容を変更したうえでエンドユーザーへ返却できます。
複数APIレスポンスの集約や、画像・広告クリエイティブの差し替えなどが該当します。

主な用途

EdgeComputingの価値は、オリジンサーバーに計算させる必要のない処理をエッジ側で完結させ、レスポンスを高速に返せる点にあります。
あるいは、オリジンに送るべきデータの前処理をエッジ側で行い、結果だけをオリジンへ渡すことで、オリジンの負荷そのものを下げることもできます。
重要なのは、オリジンサーバーが計算すべきもの(トランザクションを伴う処理など)と、しなくてもよいものを見極めたうえで設計することです。
より一般化すると、判断基準は「単一の正となるデータソースで整合性を取る必要があるか、それとも多少の遅延・分散があっても実害が小さいか」です。
決済や在庫引当のように整合性が求められる処理はオリジン側で行い、トークンの有効性チェックのように多少古い情報でも実害が小さい処理はエッジ側で完結させる、という切り分けになります。

• 画面遷移・入力フォームの一時データ保持
• オリジンに送る前のデータの絞り込み・前処理
• 認証トークンの検証
• APIレスポンスの集約・整形
• 広告処理
• その他の活用パターン

画面遷移・入力フォームの一時データ保持

複数ステップの入力フォームや画面遷移では、各ステップの入力内容を一時的に保持しながら、セッションを管理する処理が発生します。
この一時データの保持とセッション管理をWorkersとDurable Objectsで行い、最終的なSubmit時のデータのみをオリジンサーバーへ送信する設計が可能です。
オリジンサーバーは、各ステップごとの一時保存処理から解放され、本来計算すべき最終データの処理のみに専念できます。
なお、途中のステップで在庫引当や決済などのトランザクションが発生する場合は、その処理はオリジン側で行う必要があります。

実装にあたっては、Durable Objectsは1つのオブジェクトが特定のエッジロケーションに固定されるため、同じユーザーの複数リクエストを同一のDurable Objectへ確実にルーティングする設計が必要です。
単純な一時データであれば、結果整合性のWorkers KVでも代替できますが、書き込みが全世界へ反映されるまで最大60秒程度かかる点に注意が必要です。
一時データの保存・参照自体はI/O待ちが中心の処理のため、JavaScriptで十分対応できます。

オリジンに送る前のデータの絞り込み・前処理

リクエストヘッダやCookie、地域・デバイス情報などをもとに、オリジンへ送る必要のないリクエストをエッジ側で判定し、除外・集約したうえでオリジンへ送信します。
不正なリクエストや無効なパラメータをオリジン到達前にエッジ側で弾くことで、オリジンサーバーは正当なリクエストの処理のみに計算資源を使えます。

実装にあたっては、IPジオロケーションによる地域判定には一定の誤差があり、法人プロキシやVPN経由のアクセスでは意図しない判定になる場合がある点に注意が必要です。
除外条件を誤ると正当なユーザーのリクエストまで弾いてしまうため、段階的に適用しながらCloudflare Logsで効果を確認することを推奨します。
ヘッダやCookieに基づく判定は軽量な処理のため、JavaScriptで十分対応できます。

認証トークンの検証

JWT等のセキュアトークンの検証を最寄りのエッジで行い、有効なリクエストのみをオリジンサーバーへ通過させます。
トークン検証のたびにオリジンへ問い合わせる必要がなくなり、オリジンの負荷とエンドユーザーの待ち時間の両方を削減できます。

実装にあたっては、トークンの失効(ログアウトや権限変更など)をどう即時にエッジへ反映するかが課題になります。
失効リストをWorkers KVに配信して各エッジロケーションで参照する、または有効期限を短く設定して定期的に再検証させる、といった設計を検討する必要があります。
一般的なJWT検証程度の暗号演算であればJavaScript(Web Crypto API)でも十分な性能が出ますが、検証件数が非常に多い場合はRustでビルドしたWebAssemblyでの実装がより有利です。

APIレスポンスの集約・整形

複数のバックエンドAPIから取得したデータを、エッジ側で集約・整形してからクライアントへ返す処理も、オリジンの負荷を下げる代表的なパターンです。
例えば、ECサイトの商品ページで、価格API・在庫API・レビューAPIを個別に呼び出す代わりに、エッジ側でまとめて呼び出し、1回のレスポンスとしてクライアントへ返す設計が可能です。
データの取得・計算自体はAPI(オリジン)側の責務として残しつつ、複数APIの呼び出しをまとめる処理や、JSONとして返すかHTMLまで組み立てて返すかといった整形処理をエッジ側で行います。
クライアントとAPIサーバーの物理的な距離が離れているサービスほど、エッジ側での集約によりラウンドトリップを削減できる効果が大きくなります。

実装にあたっては、複数APIを並行して呼び出す際、1つのAPIが遅延・エラーとなった場合に全体のレスポンスが引きずられないよう、タイムアウト設計と、失敗したAPIを除いて残りのデータだけ返すフォールバック設計を検討する必要があります。
また、集約後のレスポンスをWorkersのキャッシュ機能で短時間キャッシュすれば、ラウンドトリップの削減に加えて、オリジンへのリクエスト数そのものも減らせます。
複数APIの呼び出し待ちが処理時間の大半を占めるため、集約・整形のロジック自体はJavaScriptで十分対応できます。

広告処理

広告配信に関わる処理も、エッジとオリジンの切り分けが特に効果を発揮する領域です。
地域・デバイス・ファーストパーティCookieのセグメントなどに応じたクリエイティブの出し分けは、パーソナライゼーションと同じくエッジ側で完結できます。
複数の広告取引先(SSP)へ並行してリクエストを送り、最高値の入札を選ぶヘッダービディングの集約も、APIレスポンスの集約と同じパターンで実装できます。
動画配信のマニフェスト(HLS/DASH)へ広告セグメントを組み込むSSAI(サーバーサイド広告挿入)は、CPU負荷が高くなりやすいため、RustでビルドしたWebAssemblyでの実装が向いています。

実装にあたっては、同じ「広告の表示回数」というデータでも、用途によって扱いを変える必要があります。
フリークエンシーキャップのための視聴回数カウントは、多少の遅延・分散があっても実害が小さいためエッジ側で完結させてよい一方、広告主への請求根拠となるインプレッション集計は、単一の正となるデータソースで整合性を取る必要があるため、オリジン側で行う必要があります。
また、広告リクエストの不正・ボットトラフィックをエッジ側で判定し、正当なリクエストのみを広告サーバーへ送る前処理も有効です。
ヘッダービディングの集約やクリエイティブの出し分けはI/O待ちが中心のためJavaScriptで十分ですが、SSAIのようなCPU負荷の高い処理はRustが向いています。

その他の活用パターン

パーソナライゼーション

ユーザーの地域・デバイス種別・ログイン状態などに応じたページ内容の出し分けを、オリジンへ問い合わせることなくエッジ側で判定します。
条件分岐が中心の軽い処理であれば、JavaScriptで十分対応できます。

A/Bテストの振り分け

どちらのバージョンを表示するかという振り分け判定自体は、オリジンが計算する必要のない処理です。
エッジ側でトラフィックを振り分けることで、オリジンへの問い合わせなしに実験を実施できます。
振り分けロジックが単純なランダム判定であれば、JavaScriptで十分です。

画像の変換

オリジナル画像をWebデザインに合わせた形式へ変換する処理をエッジ側で完結させ、オリジンサーバーを画像加工処理から解放します。
リサイズや形式変換はCPU負荷が高くなりやすいため、RustでビルドしたWebAssemblyでの実装が向いています。

軽量な判定処理・推論結果のキャッシュ

ルールベースの判定はJavaScriptで十分ですが、Workers AIによる軽量なモデルの推論結果をエッジ側でキャッシュする判断はCPU負荷が高くなりやすいため、Rustでビルドしたロジックが向いています。
本当に重い生成AI呼び出しが必要な場合のみ、オリジンやより大きなAI基盤へリクエストを振り向けます。

その他のカスタムロジック

ヘッダ操作、リライト、リダイレクトなど、オリジンサーバーが計算する必要のない処理を、独自のロジックとしてエッジ側に実装できます。
いずれもI/O待ちが中心の軽い処理のため、JavaScriptで十分対応できます。

Workers(コンピューティング)

V8 Isolateによる実行環境

コンテナや仮想マシンではなく、軽量なV8 Isolateという単位でコードを分離実行するため、コールドスタートがほぼ発生せず、リクエストの応答を即座に開始できます。

対応言語

JavaScript、TypeScriptに加え、Rust等でビルドしたWebAssemblyの実行にも対応しています。

Wrangler CLI

コマンドラインツール「Wrangler」を使い、ローカル環境での開発・検証から、本番環境へのデプロイまで一貫して行えます。

料金・利用制限(Cloudflare公式、2026年時点)

CPU時間は、実際にコードが処理をしている時間のみが課金対象です。
外部APIやデータベースへの問い合わせを待っている時間(I/O待ち)は、CPU時間に加算されません。
Cloudflareの公表値では、一般的なWorkerの平均CPU時間は1リクエストあたり約2.2ミリ秒とされていますが、認証処理やサーバーサイドレンダリングなど重めの処理では10～20ミリ秒程度になることもあり、Freeプランの10ミリ秒という上限に達しやすい点は留意が必要です。

データ・ストレージ

Workers KV

グローバルに分散したキー・バリュー型ストレージです。読み取り性能を優先した結果整合性モデルを採用しており、書き込みが全世界に反映されるまで最大60秒程度かかる場合があります。
設定値やフィーチャーフラグ、リダイレクトルールなど、更新頻度が低く読み取りが圧倒的に多いデータの配信に向いています。

Durable Objects

強整合性を持つ、状態を保持できるエッジコンピューティングの仕組みです。
チャットルームでの複数クライアント間のメッセージ配信、共同編集ドキュメントの排他制御、ゲームのセッション管理など、リアルタイムかつ厳密な整合性が求められる用途に向いています。

D1

SQLiteベースの、フルマネージドなエッジデータベースです。リレーショナルデータをエッジ上で扱え、小～中規模のアプリケーションのメインデータベースとしても利用できます。

R2

S3互換のオブジェクトストレージです。エグレス(データ転送)料金がかからない点が特長で、画像・動画・バックアップファイルなど、転送量の多いデータの保管・配信コストを抑えられます。
既存のS3互換クライアントやSDKからほぼそのまま移行できる点も実務上のメリットです。

Hyperdrive

既存のリージョナルなデータベース(PostgreSQL等)へ、コネクションプーリングとキャッシュを介してWorkersから高速に接続するための機能です。既存のDB資産を活かしたまま、エッジ側の処理だけを段階的に導入したい場合に有効です。

Queues

非同期のジョブ処理を行うためのメッセージキュー機能です。画像のサムネイル生成やメール送信など、レスポンスを待たせたくない重い処理を後回しにする用途に使います。

AI

Workers AI

Llama、Mistral、Gemma等のオープンなモデルを中心に、Cloudflareのネットワーク上で推論を実行できる機能です。
自前でGPU基盤を用意することなく、Workersから呼び出せます。
テキスト生成・要約、画像分類、音声認識(Speech-to-Text)など、モデルの種類に応じて複数の用途に対応しています。

AI Gateway

複数のAIプロバイダーへのAPI呼び出しを一元的に可視化・制御するための機能です。
レート制限やログ収集、キャッシュを、アプリケーション側の実装を変えずに追加でき、AI APIのコストとレイテンシの両方を管理しやすくなります。

活用例

エッジでの一次推論・オリジンへのフォールバック

画像のモデレーションやスパム判定など、軽量なモデルでの一次判定をエッジで行い、判定が難しいケースのみオリジン側のより大きなモデルに回すといった構成が可能です。

多言語対応のリアルタイム処理

ユーザーの言語やリクエスト元の地域に応じて、翻訳や要約をエッジ側で処理し、オリジンサーバの負荷とレイテンシの両方を抑えます。

コンテナ(ベータ)

Cloudflare Containersは、Dockerコンテナをエッジ上で実行できる機能で、現在はベータ提供です。
Workersの実行時間・メモリ(1 Isolateあたり128MB)の制約に収まらない、より重い処理を伴うワークロード向けの選択肢として位置づけられています。
既存のコンテナイメージをそのまま活かしたい場合や、Workers単体では実装が難しい常駐プロセス・独自ランタイムが必要な場合に検討対象となります。

導入を検討する際のポイント

実行時間・メモリの制約

Workersは1 Isolateあたりメモリ128MBまでという制約があり、CPU時間もFree/Paidそれぞれ上限があります。大規模なバッチ処理や長時間の計算には、Cloudflare Containersや従来型のサーバー・コンテナ基盤との組み合わせを検討する必要があります。

データの整合性モデル

Workers KVは結果整合性、Durable Objectsは強整合性と、データストアごとに整合性モデルが異なります。用途に応じて使い分けを設計段階で決めておく必要があります。

既存システムとの接続

オンプレミスや他クラウド上の既存データベースと連携する場合は、Hyperdriveの活用や、段階的な移行計画の検討が重要になります。

主要エッジコンピューティングサービスとの機能比較

Cloudflare Workersは、Gcore FastEdge、Akamai EdgeWorkers、AWS Lambda@Edge/CloudFront Functions、Fastly Computeと比較されることが増えています。
各社で実行基盤や対応言語、実行制限、料金体系が異なります。
各社の公開情報に基づく機能比較は次のとおりです。
※2026年8月時点の各社公開情報に基づきます。
※各社ともプランや契約条件により内容が変動するため、詳細は個別にお問い合わせください。

Cloudflare Workers×Spelldataが選ばれる理由

Cloudflare Workersは、Gcore FastEdgeやAWS Lambda@Edge、Fastly Computeなどと同様、公式ドキュメント・サポートとも英語が中心です。
社内にエッジコンピューティングの実装経験を持つエンジニアが少ない企業にとって、設計・実装・運用までを自社だけで完結させるのは容易ではありません。
弊社Spelldataは、日本語による設計・実装支援と、Cloudflare正規代理店としてのサポート体制で、この課題を解決します。

弊社代表の竹洞陽一郎は、Akamaiにおいて日本でのEdgeComputingの普及を推進し、2008年には日本でAkamai在職時にEdgeComputing Allianceを結成するなど、黎明期からEdgeComputingを推進してきた人物です。
Cloudflareにおいても、日本のお客様向けにWorkersの実装を早くから手掛けてきた実績があります。
複数のプラットフォームでEdgeComputingの導入を手掛けてきた経験に基づき、Cloudflare Workersについても、設計から実装・運用まで一貫して支援します。

• 日本語での要件整理・設計・実装支援により、社内にWorkers/WebAssembly実装経験がなくても導入可能
• オリジンで整合性を取るべき処理と、エッジで完結させてよい処理の切り分け設計を、要件定義の段階から支援
• Workers KV・Durable Objects・D1など、用途に応じたデータストア選定を含めて伴走支援
• Cloudflareの正規代理店・MSPとしての実績に基づく、導入後の運用サポート体制
• Cloudflare CDN・Zero Trust(Cloudflare Access)・DNS(MailData)など、他のCloudflare関連サービスとあわせて一元的にサポート
• コード実装から本番投入後の継続チューニングまで、弊社のプロフェッショナルサービスが伴走支援

プラン・料金体系

弊社Spelldataが取り扱うのは、Cloudflareの Enterpriseプランです。
Workersおよび関連するデータ・ストレージ機能(KV、Durable Objects、D1、R2、Queues等)のご利用料金は、貴社のご利用規模・要件に応じた個別見積りとなります。
ご参考として、Cloudflare公式サイトに掲載されている、セルフサービス向けFree/Paidプランの主な制限は以下のとおりです。

Enterpriseプランでは、上記のセルフサービス向け制限とは異なる条件(利用量・SLA・サポート体制等)で契約するため、上記表はあくまで目安としてご参照ください。
具体的な料金・条件は、貴社の要件をお伺いしたうえで個別にお見積りします。

Workers導入サポート

Workersの導入には、実行環境の選定(JavaScript/TypeScriptか、RustによるWebAssemblyか)、KV・Durable Objects・D1等のデータストア選定、既存のCDN・オリジン構成との連携など、いくつかの検討事項があります。
弊社のプロフェッショナルサービスをご利用いただくことで、要件整理から本番投入までスムーズに実施いただけます。
料金は1時間あたり30,000円です。
ヘッダ操作・リダイレクト・画像変換等、比較的シンプルなユースケースの場合は、概ね2~3時間の作業で完了します。
画面遷移データの一時保持、APIレスポンスの集約、広告処理(ヘッダービディング連携・SSAI等)など、データストアの選定やエッジ間の整合性設計、外部API連携を伴うユースケースの場合は、要件に応じて概ね5~10時間程度を見込みます。

導入手順

1. 実現したい処理内容のヒアリング

画像変換、パーソナライゼーション、認証、A/Bテスト、API集約、広告処理など、エッジで実現したい処理内容と、既存のCDN・オリジン構成をお伺いします。

2. オリジン/エッジの処理切り分け設計

オリジンで整合性を取るべき処理(トランザクションを伴う処理など)と、エッジ側で完結させてよい処理を整理します。
Workers KV(結果整合性)とDurable Objects(強整合性)のどちらを使うべきか、この段階で設計方針を決定します。

3. アプリケーションの設計・実装

JavaScript/TypeScript、またはRustにて、要件に応じたロジックを設計・実装します。
ネットワークI/O待ちが中心の軽い処理はJavaScript/TypeScript、画像変換や推論結果のキャッシュ判断などCPU負荷の高い処理はRust(WebAssembly)を選ぶのが基本方針です。
既存のテンプレートを活用できる場合は、開発工数を抑えて対応します。

4. Wrangler CLIによるデプロイ設定

実装したWorkerを、Wrangler CLIを用いてビルド・デプロイします。
KV Namespace、Durable Objectsのバインディング、D1データベース等、必要な環境設定をあわせて行います。

5. CDN・オリジンとの連携設定

既存のCloudflare CDNや外部CDN、オリジンサーバーとWorkerを連携させ、リクエスト・レスポンスの処理経路(ルート・トリガー)を設定します。

6. 動作検証

本番投入前に、想定どおりの処理が行われているか、レスポンスタイムやエラー有無を含めて弊社にて検証します。

7. 本番投入・継続チューニング

検証結果をもとに本番トラフィックへの適用を行い、運用開始後もCloudflare Logsの分析やロジックの継続的なチューニングをサポートします。

お問い合わせフォーム

本サービスのご相談やお見積り、事例についてなど、お気軽にお問い合わせ下さい。

➡ サービス、製品に関するお問い合わせ