Cloudflare Workers実践入門｜エッジコンピューティングのデプロイ・KV/R2連携・コールドスタートゼロ設計の実装ガイド

Cloudflare Workersとは何か｜AWS Lambda@Edge・Fastly Compute@Edgeとの位置関係

エッジコンピューティングの定義とCloudflare Workersの特徴

Cloudflare Workersは、Cloudflareのグローバルネットワーク上で動作するサーバーレスコンピューティング環境です。従来のクラウドコンピューティングがリージョン単位でリソースを配置するのに対し、エッジコンピューティングはユーザーに最も近い地点でコードを実行することで、レイテンシを最小化します。Cloudflare Workersは世界330以上の都市に展開されたデータセンターで動作し、リクエストを受けた地点で即座に処理を実行できる点が最大の特徴です。

エッジコンピューティングの本質は「処理をユーザーに近づける」ことにあります。従来のWebアプリケーションでは、ユーザーのリクエストはCDNでキャッシュされた静的コンテンツを返すか、オリジンサーバーまで到達して動的処理を実行する二択でした。Cloudflare Workersはこの中間層として機能し、CDNエッジでJavaScript/TypeScript/Rust/Cなどのコードを実行できます。これにより、認証チェック・A/Bテスト・パーソナライゼーション・地理情報に基づくルーティングなどの動的処理をエッジで完結させ、オリジンサーバーへの負荷を大幅に削減できます。

Cloudflare Workersの技術基盤はV8 Isolatesです。これはGoogle Chromeと同じJavaScriptエンジンを使用しながら、各リクエストを独立した軽量な実行環境（Isolate）で処理します。従来のコンテナやVMと異なり、Isolatesは数ミリ秒で起動し、メモリフットプリントも数キロバイトに抑えられます。この設計により、コールドスタートがゼロに近い状態を実現し、リクエストごとに新しいIsolateを生成してもパフォーマンスへの影響がほぼありません。

AWS Lambda@Edgeとの違い｜コールドスタート・デプロイ・実行モデル

AWS Lambda@EdgeはAWS CloudFrontのエッジロケーションでLambda関数を実行するサービスです。Cloudflare Workersとの最大の違いは実行モデルとコールドスタートにあります。Lambda@EdgeはNode.jsまたはPythonのランタイムをコンテナ環境で実行するため、初回リクエスト時のコールドスタートが数百ミリ秒から数秒発生します。対してCloudflare WorkersはV8 Isolatesを使用するため、コールドスタートは1ミリ秒未満です。

デプロイの速度も大きく異なります。Lambda@Edgeは関数を更新すると全エッジロケーションへの伝播に15分から30分かかります。Cloudflare Workersは平均30秒以内にグローバル展開が完了します。これは開発サイクルの速度に直結し、本番環境での不具合修正やA/Bテストの迅速な調整が可能になります。

実行時間の制限も異なります。Lambda@Edgeはビューワーリクエスト・ビューワーレスポンスで最大5秒、オリジンリクエスト・オリジンレスポンスで最大30秒です。Cloudflare Workersは無料プランで10ミリ秒のCPU時間、有料プランで50ミリ秒のCPU時間が割り当てられます。CPU時間は実際の処理時間のみをカウントし、ネットワークI/O待機時間は含まれないため、外部APIを呼び出すようなI/O集約的な処理では実質的な実行時間は数秒に達することもあります。

Fastly Compute@Edge・Vercel Edge Functionsとの比較軸

Fastly Compute@EdgeはWebAssembly（Wasm）ベースのエッジコンピューティング環境です。Rust・Go・AssemblyScriptなど複数の言語で記述したコードをWasmにコンパイルして実行します。パフォーマンス面ではCloudflare Workersと同等ですが、言語選択の自由度が高く、既存のRustエコシステムを活用できる点が強みです。ただし、Wasmへのコンパイルが必要なため、開発環境のセットアップが複雑になります。

Vercel Edge FunctionsはNext.jsとの統合が深く、React Server ComponentsやMiddlewareとシームレスに連携できます。実行環境はCloudflare Workersと同じV8 Isolatesを使用していますが、Vercelのプラットフォーム内でのみ動作します。フロントエンドフレームワークとの一体化を重視する場合はVercelが、インフラレイヤーでの柔軟性を求める場合はCloudflare Workersが適しています。

料金モデルも選択の重要な軸です。Cloudflare Workersは月間10万リクエストまで無料で、以降1百万リクエストあたり0.50ドルです。Lambda@EdgeはCloudFrontのデータ転送料金に加えて、リクエストあたり0.0000006ドル（100万リクエストで0.60ドル）と実行時間による課金があります。Fastly Compute@Edgeはリクエストあたり0.0000035ドル（100万リクエストで3.50ドル）で、CPU時間課金はありません。Vercel Edge Functionsは月間500時間のFunction実行時間が無料で、超過分は100Function時間あたり2ドルです。

主要エッジコンピューティングサービスの比較（Workers・Lambda@Edge・Compute@Edge・Vercel Edge）

選定基準｜コールドスタート許容度・既存インフラ・開発言語

エッジコンピューティングサービスの選定では、まずコールドスタートの許容度を評価します。リアルタイム性が重視されるAPI・認証・パーソナライゼーションではCloudflare Workers・Fastly Compute@Edge・Vercel Edge Functionsが適しています。一方、バッチ処理的な用途やオリジンリクエスト時の処理であればLambda@Edgeのコールドスタートも許容できます。

既存インフラとの統合も重要です。AWSエコシステム内で完結する場合、Lambda@EdgeとDynamoDB・S3・CloudWatchの統合は非常にスムーズです。IAMロール・VPC・AWS X-Rayなど既存のAWSサービスをそのまま活用できます。逆に、マルチクラウド戦略を採用している場合や、Cloudflareを既にCDNとして使用している場合は、Cloudflare Workersが追加コストなく導入できます。

開発言語とエコシステムの適合性も考慮すべきです。JavaScriptエコシステムに慣れた開発チームであればCloudflare WorkersやVercel Edge Functionsがスムーズです。Rustでの高性能実装や既存のGoコードベースを活用したい場合はFastly Compute@Edgeが選択肢になります。ただし、Wasmへのコンパイルステップが増えるため、CI/CDパイプラインの複雑さとのトレードオフを評価する必要があります。

Cloudflare Workersのデプロイ基本（wrangler・Worker Routes・KVバインディング）

wranglerによるローカル開発とデプロイフロー

Cloudflare WorkersのデプロイにはWrangler CLIを使用します。Wranglerはプロジェクトの初期化・ローカル開発サーバー・テスト実行・本番デプロイを一元管理するツールです。まずNode.jsをインストールし、npmまたはyarnでWranglerをグローバルインストールします。

npm install -g wrangler
wrangler login
wrangler init my-worker
cd my-worker
wrangler dev

wrangler initは新しいWorkerプロジェクトを作成し、wrangler.tomlという設定ファイルを生成します。このファイルにWorkerの名前・アカウントID・互換性フラグ・環境変数・KVバインディングなどを記述します。wrangler devはローカル開発サーバーを起動し、localhost:8787でWorkerをテストできます。コード変更は即座にホットリロードされ、開発体験はViteやNext.jsと同等です。

本番デプロイはwrangler publishコマンド一発で完了します。コードがCloudflareのグローバルネットワークに配布され、通常30秒以内に全エッジで有効化されます。デプロイ履歴はCloudflareダッシュボードで確認でき、ロールバックも即座に実行できます。CI/CD環境ではwrangler publishをGitHub ActionsやGitLab CIのステップとして組み込み、mainブランチへのマージで自動デプロイを実現します。

Worker Routesによるトラフィック制御とゾーン連携

Worker Routesは特定のURLパターンに対してWorkerを実行するマッピング機能です。例えば、example.com/api/*へのリクエストのみをWorkerで処理し、他のパスは通常のCDNキャッシュで配信するといった制御が可能です。ルートパターンはワイルドカードとプレースホルダーをサポートし、柔軟なマッチングができます。

・完全一致: example.com/api/users → 正確にこのパスのみ
・ワイルドカード: example.com/api/* → /api/以下すべて
・サブドメイン: *.example.com/api → すべてのサブドメインのAPIパス
・複数ゾーン: 複数のドメインに同じWorkerを適用可能

Worker Routesは優先順位を設定でき、より具体的なパターンを優先的に評価します。これにより、/api/adminは認証Workerで処理し、/api/*は汎用APIゲートウェイWorkerで処理するといった階層的なルーティングが実現できます。ルートの追加・変更はCloudflareダッシュボードまたはwrangler.tomlで管理し、変更は即座に反映されます。

Cloudflareゾーンとの連携では、WorkerがCDNキャッシュの前段で動作します。Workerからcaches APIを使用してCloudflareのエッジキャッシュを直接操作でき、キャッシュのパージ・TTL変更・カスタムキャッシュキーの生成が可能です。これにより、動的コンテンツのキャッシュ戦略を細かく制御し、オリジンサーバーへのリクエストを最小化できます。

KVバインディングとシークレット管理

Workers KVはCloudflare Workersから利用できるグローバル分散型キーバリューストアです。Workerスクリプト内でKVネームスペースにアクセスするには、wrangler.tomlでバインディングを設定します。バインディングは環境変数のようにWorker内でKVネームスペースをオブジェクトとして参照できるようにする仕組みです。

# wrangler.toml
name = "my-worker"
main = "src/index.js"

[[kv_namespaces]]
binding = "MY_KV"
id = "abc123def456"

上記の設定により、Workerスクリプト内でenv.MY_KVとしてKVネームスペースにアクセスできます。env.MY_KV.get(‘key’)で値を取得し、env.MY_KV.put(‘key’, ‘value’)で値を保存します。KVは結果整合性モデルを採用しており、書き込み後すぐに読み取っても古い値が返ることがあります。通常60秒以内にグローバルで整合性が取れますが、強整合性が必要な場合はDurable Objectsを使用します。

シークレット管理はwrangler secretコマンドで行います。APIキー・データベースパスワード・JWT秘密鍵などの機密情報はwrangler.tomlに平文で書かず、wrangler secret putで暗号化して保存します。シークレットはWorker内でenv.SECRET_NAMEとして参照でき、Cloudflareダッシュボードでも表示されません。環境ごとに異なるシークレットを設定でき、本番環境とステージング環境で異なるAPIキーを使い分けられます。

Workers KVとR2の使い分け（キーバリュー vs オブジェクトストレージ）

Workers KVの特性｜結果整合性・読み取り最適化・低レイテンシ

Workers KVは読み取りパフォーマンスを極限まで最適化したキーバリューストアです。データは世界中のCloudflareデータセンターにレプリケートされ、リクエストを受けたエッジから最も近いデータセンターのKVを参照します。読み取りレイテンシは通常1ミリ秒未満で、データベースクエリやS3 GETと比較して圧倒的に高速です。

KVの主なユースケースは、頻繁に読み取られるがまれにしか更新されないデータです。具体的には、A/Bテスト設定・フィーチャーフラグ・地理情報データベース・ユーザー権限マッピング・翻訳データ・プロダクト情報などです。これらのデータは読み取り頻度が書き込み頻度の100倍から1000倍に達し、KVの読み取り最適化モデルと完全に合致します。

注意すべきはKVの結果整合性です。キーに新しい値を書き込んでも、全エッジへの伝播には最大60秒かかります。この間、古い値が返る可能性があります。リアルタイム性が必要な在庫管理・予約システム・金融取引などではKVは不適切で、Durable ObjectsやリレーショナルデータベースとのREST API連携を検討すべきです。

料金体系は読み取り操作が極めて安価です。2026年5月時点で、月間1千万回の読み取りまで無料、以降1千万回あたり0.50ドルです。書き込み操作は月間100万回まで無料、以降1百万回あたり5ドルです。ストレージは月間1GBまで無料、以降1GBあたり0.50ドルです。読み取り重視のアプリケーションでは月間数億回の読み取りでも数ドルのコストに収まります。

R2の位置づけ｜S3互換・Egress無料・大容量ファイル

Cloudflare R2はS3互換のオブジェクトストレージサービスです。最大の特徴はEgress（データ転送出力）が完全無料である点です。AWS S3ではデータ転送料金が高額になりがちで、1TBのダウンロードで約90ドルかかります。R2は転送量に関わらずゼロドルです。これにより、動画配信・画像ホスティング・ログアーカイブ・バックアップストレージなどのユースケースで劇的にコストを削減できます。

R2のAPIはS3互換であり、AWS SDKやs3cmdなどの既存ツールがそのまま使えます。バケットの作成・オブジェクトのPUT/GET/DELETE・マルチパートアップロード・プリサインドURLなど、S3の主要機能をサポートします。既存のS3ベースのアプリケーションをR2に移行する際、コード変更はエンドポイントURLの差し替えのみで済むケースが多いです。

Workers KVとR2の使い分けの基準は、データサイズとアクセスパターンです。KVは個々の値が25MBまでで、キー数が数百万から数億のシナリオに適しています。R2は個々のオブジェクトが5TBまで対応し、キー数に実質的な制限はありません。読み取りレイテンシはKVが1ミリ秒未満、R2が10～50ミリ秒です。頻繁に読み取る小さなメタデータはKV、大きなファイルや頻度の低いアクセスはR2が最適です。

KV+R2ハイブリッドパターン｜メタデータKV・実体R2

実際のアプリケーションでは、KVとR2を組み合わせたハイブリッドアーキテクチャが効果的です。例えば、画像配信サービスでは画像メタデータ（サイズ・形式・作成日・タグ）をKVに保存し、画像本体はR2に保存します。リクエストを受けたWorkerはまずKVからメタデータを取得し、キャッシュ制御やリサイズパラメータを判断した後、必要に応じてR2から画像本体を取得します。

このパターンにより、メタデータへのアクセスは1ミリ秒以内で完了し、画像本体の取得も並行して行われます。さらに、取得した画像はWorkerからCache APIを使ってCloudflare CDNにキャッシュされ、次回以降のアクセスではR2へのリクエストすら発生しません。結果として、高速・低コスト・スケーラブルな画像配信基盤が構築できます。

別の例として、ユーザーアップロードファイルの管理があります。ファイルアップロード時、Workerはファイル本体をR2に保存し、ファイル名・サイズ・MIMEタイプ・アップロード日時・ユーザーIDなどのメタデータをKVに記録します。ファイル一覧表示時はKVのみを参照し、実際のダウンロード時にR2のプリサインドURLを生成します。この設計により、ファイルリスト取得は極めて高速で、ストレージコストも最小化されます。

コールドスタートゼロを実現するV8 Isolatesの仕組み

V8 IsolatesとコンテナVMの違い｜起動速度・メモリ・セキュリティ境界

V8 Isolatesは、Google Chromeブラウザで使用されているJavaScriptエンジンV8の軽量実行環境です。従来のサーバーレス環境がコンテナやVM（仮想マシン）を使用するのに対し、Cloudflare WorkersはV8の単一プロセス内で複数のIsolatesを動作させます。各Isolateは独立したヒープとスタックを持ち、他のIsolateから完全に隔離されますが、V8エンジン自体やOSカーネルは共有します。

この設計により、Isolateの起動時間は1ミリ秒未満になります。コンテナやVMでは、カーネルの初期化・ネットワークスタックのセットアップ・ランタイムのロードなどに数百ミリ秒から数秒かかります。Isolatesはこれらのオーバーヘッドがなく、必要なのはJavaScriptコードのパースと初期化のみです。さらに、V8のスナップショット機能により、頻繁に使われるコードは事前コンパイル済みの状態で保持され、実質的にパース時間もゼロに近づきます。

メモリフットプリントも劇的に小さくなります。コンテナは最低でも数十MB、VMは数百MBから数GBのメモリを消費します。IsolatesはJavaScriptのヒープとスタックのみを保持するため、通常数KB～数MBで動作します。これにより、単一の物理サーバーで数千から数万のIsolatesを同時に実行でき、高密度な多テナント環境が実現できます。

セキュリティ境界については、IsolatesはV8のサンドボックス機構に依存します。V8は世界中のWebブラウザで毎日数十億回実行されており、セキュリティ研究者による継続的な監査を受けています。Isolate間の隔離は、異なるWebページのJavaScriptが互いに干渉できないのと同じ原理です。ただし、カーネルレベルの隔離ではないため、極めて高いセキュリティ要求がある場合はVM隔離を提供するサービスの方が適切な場合もあります。

コールドスタート最小化の実装テクニック

Cloudflare Workersではコールドスタート自体がほぼゼロですが、スクリプト初期化時間を最小化するベストプラクティスがあります。まず、トップレベルでの重い処理を避けます。fetch(‘https://api.example.com’)のようなネットワークリクエストや、大きなJSONファイルのパースをモジュールのトップレベルで実行すると、Isolate起動時に毎回実行されます。これらは遅延初期化し、最初のリクエスト時に実行するか、KVから取得するようにします。

・依存モジュールの最小化: npm依存を減らし、必要な関数のみを抽出
・遅延初期化: 重い処理はリクエストハンドラ内で実行
・KV/R2からの設定ロード: 静的ファイルではなく動的に取得
・Dynamic Import: 条件分岐でのみ使用するコードはimport()で遅延ロード

バンドルサイズもパフォーマンスに影響します。Workerスクリプトのサイズ上限は無料プランで1MB、有料プランで10MBですが、実際には100KB未満に抑えるべきです。大きなスクリプトはパース時間が増加し、Isolate起動が遅くなります。WebpackやRollupでツリーシェイキングを有効にし、未使用コードを除去します。特に、lodashやmomentなどの大きなライブラリは、必要な関数のみをインポートします。

Durable ObjectsやKVへの接続も最適化できます。Durable Objectsは初回アクセス時にオブジェクトの初期化が発生しますが、同じオブジェクトへの後続リクエストは既に起動済みのインスタンスを再利用します。頻繁にアクセスされるオブジェクトはメモリに保持され、アクセスパターンが予測可能な場合はプリウォーミング戦略を実装できます。

料金体系（リクエスト課金・CPU時間・KV/R2ストレージ・Egress無料）

Workersの料金構造｜無料枠・Bundledプラン・CPU時間課金

Cloudflare Workersの料金は、2026年5月時点で無料プランとBundledプラン（有料）の2種類です。無料プランは月間10万リクエストまで、CPU時間は1リクエストあたり10ミリ秒まで無料です。これは個人プロジェクトや低トラフィックのAPIゲートウェイには十分な規模です。Bundledプランは月額5ドルで、月間1千万リクエストまで含まれ、追加リクエストは100万リクエストあたり0.50ドルです。CPU時間は1リクエストあたり50ミリ秒まで拡張されます。

CPU時間課金の重要な点は、実際の計算時間のみがカウントされることです。外部APIへのfetchや、KV/R2へのアクセス待機時間はCPU時間に含まれません。例えば、外部APIを5つ呼び出すWorkerがあり、各APIが平均100ミリ秒応答する場合、ウォールクロック時間は500ミリ秒以上ですが、CPU時間は数ミリ秒のみです。I/O集約的な処理では、CPU時間制限はほとんど問題になりません。

逆に、CPU集約的な処理では注意が必要です。画像リサイズ・暗号化処理・大量のJSON解析などは実際のCPU時間を消費します。50ミリ秒のCPU時間を超過するとWorkerは強制終了され、エラーが返ります。このような処理はWorkerで完結させず、オリジンサーバーやバックグラウンドジョブに委譲するか、Wasm最適化されたライブラリを使用してCPU効率を改善します。

KV/R2の料金モデル｜読み書き操作・ストレージ・削除操作

Workers KVの料金は操作ベースとストレージベースの組み合わせです。読み取り操作は月間1千万回まで無料、以降1千万回あたり0.50ドルです。書き込み操作は月間100万回まで無料、以降100万回あたり5ドルです。削除操作は月間100万回まで無料、以降100万回あたり5ドルです。リスト操作は月間100万回まで無料、以降100万回あたり5ドルです。ストレージは月間1GBまで無料、以降1GBあたり0.50ドルです。

R2の料金はストレージとAPI操作で構成されます。ストレージは1GBあたり月額0.015ドルで、S3の約10分の1です。クラスA操作（PUT/COPY/LIST）は100万操作あたり4.50ドルです。クラスB操作（GET/HEAD）は100万操作あたり0.36ドルです。最も重要なのは、Egress（データ転送出力）が完全無料である点です。AWS S3では1GBあたり0.09ドルのEgress料金がかかり、大量配信では月数千ドルに達します。

具体的なコスト試算例として、月間1億PVの画像配信サービスを考えます。各ページで平均5枚の画像を表示し、平均画像サイズは100KBとします。総リクエスト数は5億回、総転送量は約47TBです。R2を使用した場合、ストレージ50TBで月額750ドル、クラスB操作5億回で180ドル、Egress無料で合計930ドルです。S3を使用した場合、ストレージ50TBで1,150ドル、GET操作5億回で200ドル、Egress 47TBで4,230ドルで合計5,580ドルです。R2は約6分の1のコストになります。

コスト最適化戦略｜キャッシュAPI活用・バッチ書き込み・TTL設計

Cloudflare Workersのコストを最小化する第一の戦略は、Cache APIの積極的な活用です。WorkerからfetchでオリジンやR2にアクセスする前に、Cloudflare CDNのキャッシュを確認します。キャッシュヒット時はWorkerのCPU時間もほぼゼロで、R2のGET操作も発生しません。適切なCache-Controlヘッダーとカスタムキャッシュキーを設定し、キャッシュヒット率を90%以上に高めることで、実質的なコストは10分の1になります。

KVへの書き込み操作はバッチ化します。個別のユーザーイベントごとにKV.put()を呼ぶと、書き込み操作数が膨大になります。代わりに、イベントをDurable Objectsのメモリに一時蓄積し、10秒ごとまたは100イベントごとにまとめてKVに書き込みます。これにより書き込み操作数を100分の1に削減できます。ただし、Durable Objectsの料金（100万リクエストあたり0.15ドル）が追加されるため、総コストを比較します。

KVのTTL（Time To Live）を適切に設定し、不要なデータを自動削除します。KV.put(‘key’, ‘value’, { expirationTtl: 3600 })のように、1時間後に自動削除されるようにします。セッション情報・一時トークン・キャッシュデータなど、期限がある情報はTTLを設定し、ストレージコストを削減します。手動削除が必要なデータを放置すると、数ヶ月で数百GBに達し、月額数百ドルのコストになることがあります。

R2では、頻繁にアクセスされないデータをライフサイクルポリシーで管理します。例えば、ログファイルやバックアップは90日経過後に削除するルールを設定します。また、CloudflareのCache APIとR2を組み合わせ、人気の高いコンテンツはCDNエッジにキャッシュし、R2へのGET操作を最小化します。これにより、クラスB操作のコストを大幅に削減できます。

実装パターン（A/Bテスト・キャッシュ最適化・JWT検証・地理分散ルーティング）

A/Bテストとフィーチャーフラグのエッジ実装

Cloudflare WorkersはA/Bテストをエッジで実行する理想的な環境です。従来のクライアントサイドA/Bテストでは、JavaScriptがロードされるまでちらつきが発生します。サーバーサイドA/Bテストでは、オリジンサーバーへのリクエストが必要です。Workerはリクエストを受けた瞬間にユーザーをグループに振り分け、対応するコンテンツをキャッシュまたはオリジンから取得して返します。

実装パターンとして、ユーザーのCookieまたはIPアドレスをハッシュ化し、一貫した振り分けを行います。振り分け比率やフィーチャーフラグの設定はKVに保存し、Workers KVから取得します。これにより、A/Bテストの開始・停止・比率変更がリアルタイムで可能になります。

const userId = getCookie('user_id') || request.headers.get('CF-Connecting-IP');
const hash = await crypto.subtle.digest('SHA-256', new TextEncoder().encode(userId));
const bucket = new Uint8Array(hash)[0] % 100;
const config = await env.MY_KV.get('ab_test_config', { type: 'json' });
const variant = bucket < config.variantA_percentage ? 'A' : 'B';
return fetch(request.url + '?variant=' + variant);

フィーチャーフラグも同様にKVで管理します。新機能を特定の地域・ユーザーグループ・時間帯に限定して有効化できます。本番環境に全機能をデプロイしながら、フラグのON/OFFで機能の公開を制御するため、デプロイとリリースを分離できます。問題が発生した場合、KVのフラグを更新するだけで即座に機能を無効化できます。

キャッシュ最適化とカスタムキャッシュキー

Cloudflare WorkersからCache APIを使用すると、Cloudflare CDNのキャッシュを完全に制御できます。デフォルトのキャッシュ動作を上書きし、クエリパラメータ・リクエストヘッダー・Cookieに基づいてカスタムキャッシュキーを生成できます。これにより、パーソナライズされたコンテンツを効率的にキャッシュできます。

例えば、ユーザーの言語設定に基づいてコンテンツを配信する場合、Accept-Languageヘッダーをキャッシュキーに含めます。通常のCDNではヘッダーベースのキャッシュは複雑ですが、WorkerのCache APIでは明示的に指定できます。

const cache = caches.default;
const language = request.headers.get('Accept-Language').split(',')[0];
const cacheKey = new Request(request.url + '?lang=' + language, request);
let response = await cache.match(cacheKey);
if (!response) {
  response = await fetch(request);
  response = new Response(response.body, response);
  response.headers.set('Cache-Control', 'public, max-age=3600');
  await cache.put(cacheKey, response.clone());
}
return response;

動的コンテンツのキャッシュでは、Stale-While-Revalidate戦略が有効です。キャッシュが期限切れでも古いコンテンツを即座に返し、バックグラウンドで新しいコンテンツを取得してキャッシュを更新します。ユーザーは常に高速なレスポンスを得られ、コンテンツの鮮度も維持されます。

JWT検証とAPI認証ゲートウェイ

Cloudflare WorkersはJWT（JSON Web Token）の検証をエッジで実行できます。オリジンサーバーに到達する前にトークンの有効性を確認し、不正なリクエストをブロックします。これにより、オリジンサーバーの負荷を削減し、攻撃面を最小化できます。

JWT検証には、jose（JavaScript Object Signing and Encryption）などの軽量ライブラリを使用します。公開鍵をKVに保存し、Workerから取得して検証します。鍵のローテーションもKVを更新するだけで即座に反映されます。

import { jwtVerify } from 'jose';
const token = request.headers.get('Authorization').replace('Bearer ', '');
const publicKey = await env.MY_KV.get('jwt_public_key');
const { payload } = await jwtVerify(token, publicKey);
if (payload.exp < Date.now() / 1000) {
  return new Response('Token expired', { status: 401 });
}
return fetch(request);

API Gatewayパターンでは、複数のバックエンドサービスへのルーティング・レート制限・リクエスト変換をWorkerで実装します。例えば、/api/users はマイクロサービスAに、/api/products はマイクロサービスBにルーティングし、各サービスのエンドポイントを隠蔽します。レート制限はDurable Objectsでカウンターを保持し、ユーザーごとまたはIPごとに制限を適用します。

地理情報ルーティングとGDPR対応

Cloudflare Workersはリクエストの地理情報をrequest.cf.countryで取得できます。これを利用して、EUユーザーをGDPR準拠のデータセンターに、米国ユーザーを米国のオリジンにルーティングするような地域別最適化が可能です。

・地域別オリジン: EUユーザー→eu-origin.example.com、米国→us-origin.example.com
・GDPR対応: EU圏内でのデータ処理を保証
・言語自動検出: request.cf.countryから言語を推定
・通貨表示: 地域に応じた通貨・価格表示

コンプライアンス要件がある場合、データの物理的な保管場所も制御できます。R2は現在グローバル分散ですが、将来的にリージョン指定が可能になる予定です。現時点では、EU専用のR2バケットを作成し、EUユーザーのデータを分離することで対応します。WorkerはユーザーのIPアドレスから地域を判定し、適切なR2バケットにアクセスします。

よくあるトラブル（CPU時間超過・KVレイテンシ・バインディング不足）

CPU時間超過エラーの診断と対処

Cloudflare Workersで最も頻繁に遭遇するエラーは、CPU時間の上限超過です。無料プランの10ミリ秒、有料プランの50ミリ秒を超えると、Workerは即座に終了し「Error 1102: Worker exceeded CPU time limit」が返されます。このエラーが発生した場合、まずWorkerのログを確認し、どの処理に時間がかかっているかを特定します。

CPU時間を消費する典型的な原因は、大きなJSONのパース・正規表現の複雑なマッチング・暗号化処理・画像処理です。これらの処理を最適化する方法として、JSONは必要な部分のみを抽出し、正規表現はシンプルなパターンに分割します。暗号化処理はWeb Crypto APIを使用し、ネイティブ実装の高速性を活用します。画像処理はWorkerで行わず、Cloudflare Image ResizingやR2のプリサインドURLでオフロードします。

別のアプローチとして、重い処理をDurable Objectsに委譲します。Durable Objectsは長時間実行が可能で、状態を保持できるため、複数のリクエストにまたがる処理を効率的に実行できます。ただし、Durable Objectsにも1リクエストあたりのCPU時間制限があるため、完全な解決にはなりません。最終的には、CPU集約的な処理はオリジンサーバーやバックグラウンドワーカーに移す判断が必要です。

KV読み取りレイテンシとキャッシュ戦略

Workers KVは通常1ミリ秒未満で応答しますが、まれに10～100ミリ秒かかることがあります。これは、データが物理的に遠いデータセンターにある場合や、ネットワーク混雑時に発生します。KVのレイテンシを最小化するには、頻繁にアクセスするデータをWorkerのグローバル変数にキャッシュします。

let configCache = null;
let cacheTime = 0;
const CACHE_TTL = 60000; // 60秒

async function getConfig(env) {
  if (configCache && Date.now() - cacheTime < CACHE_TTL) {
    return configCache;
  }
  configCache = await env.MY_KV.get('config', { type: 'json' });
  cacheTime = Date.now();
  return configCache;
}

このパターンでは、設定情報を最大60秒間メモリにキャッシュします。同じIsolateインスタンスで処理される後続リクエストはKVアクセスなしで設定を取得できます。ただし、Isolateはいつでも破棄・再生成される可能性があるため、キャッシュが常に存在する保証はありません。また、複数のエッジで異なるIsolateが動作するため、設定変更は最大60秒の遅延があることを許容する必要があります。

KVの結果整合性も考慮すべきです。書き込み直後の読み取りで古い値が返ることがあります。強整合性が必要な場合、KVではなくDurable Objectsを使用するか、オリジンサーバーのデータベースに直接アクセスします。KVは「頻繁に読まれるがまれにしか更新されない」データに限定し、リアルタイム性が要求されるデータは別の仕組みで管理します。

バインディング設定ミスとデプロイエラー

Workerをデプロイする際、wrangler.tomlのバインディング設定ミスが頻繁に発生します。KVネームスペース・R2バケット・Durable Objects・環境変数などのバインディングは、ローカル開発環境と本番環境で異なるIDを持ちます。wrangler.tomlに本番環境のIDをハードコードすると、チーム開発時に他のメンバーのローカル環境が動作しなくなります。

ベストプラクティスは、wrangler.tomlで環境ごとに異なる設定を定義することです。

[env.production]
kv_namespaces = [
  { binding = "MY_KV", id = "abc123prod" }
]

[env.staging]
kv_namespaces = [
  { binding = "MY_KV", id = "def456staging" }
]

デプロイ時にwrangler publish –env productionで環境を指定します。ローカル開発ではwrangler dev –env stagingを使用し、本番データに影響を与えません。CI/CD環境では、GitHub SecretsにKVネームスペースIDを保存し、デプロイ時に動的に注入します。

バインディング名の不一致も問題になります。wrangler.tomlでbinding = “MY_KV”と定義したのに、コード内でenv.MY_KEYとタイポすると、実行時にundefinedエラーが発生します。TypeScriptを使用している場合、env.MY_KVの型定義を生成し、コンパイル時にエラーを検出できます。wrangler typesコマンドで型定義を自動生成し、エディタのオートコンプリートでミスを防ぎます。

よくある質問

Cloudflare Workersは既存のAWS環境と併用できますか？

はい、Cloudflare WorkersとAWSは完全に併用できます。典型的なアーキテクチャは、Cloudflare WorkersをエッジレイヤーとしてAWS EC2・ECS・Lambda・RDSの前段に配置する形です。WorkerでJWT検証・レート制限・キャッシュ制御を実行し、有効なリクエストのみをAWSオリジンに転送します。これにより、AWSリソースへの負荷を大幅に削減できます。

具体的な統合パターンとして、Cloudflare Workersでユーザー認証とセッション管理を行い、認証済みリクエストはAWS ALB（Application Load Balancer）に転送します。WorkerからAWS S3のプリサインドURLを生成し、静的コンテンツは直接S3から配信することも可能です。DynamoDBやRDSへのアクセスは、Workerから直接ではなく、API Gateway経由で行うことでセキュリティを保ちます。

注意点として、Cloudflare WorkersからAWSリソースへのアクセスには追加のレイテンシが発生します。エッジからAWSリージョンまでのネットワークホップが増えるためです。これを最小化するには、CloudflareのArgoスマートルーティングを有効化し、最適なネットワークパスを自動選択させます。また、頻繁にアクセスするAWSデータはWorkers KVにキャッシュし、AWS APIコール数を削減します。

Durable ObjectsとWorkers KVはどう使い分ければよいですか？

Durable ObjectsとWorkers KVの使い分けは、一貫性要件とアクセスパターンで判断します。Workers KVは結果整合性で、読み取り最適化されています。書き込み後最大60秒の伝播遅延があり、同時書き込みで最後の書き込みが優先されます。Durable Objectsは強整合性で、単一インスタンスがすべての読み書きを処理するため、整合性が保証されます。

具体的なユースケースとして、セッション管理はDurable Objectsが適しています。ユーザーのセッション状態はリアルタイムで更新され、整合性が重要です。一方、フィーチャーフラグやA/Bテスト設定はWorkers KVが適しています。数分の伝播遅延は許容でき、読み取り頻度が圧倒的に高いためです。

・KV適合: 設定情報・翻訳データ・商品マスタ・地理情報・キャッシュ
・Durable Objects適合: セッション・カウンター・リアルタイムチャット・在庫管理・予約システム

料金面でも違いがあります。Workers KVは読み取りが極めて安価（1千万回0.50ドル）で、書き込みが高価（100万回5ドル）です。Durable Objectsはリクエストあたり課金（100万回0.15ドル）と期間課金（100万GB秒あたり12.50ドル）です。読み取り頻度が書き込みの100倍を超える場合はKV、読み書きが同程度または強整合性が必要な場合はDurable Objectsがコスト効率が良くなります。

Cloudflare Workersでデータベースに接続できますか？

Cloudflare Workersから直接SQLデータベースに接続することは、2026年5月時点では制限があります。従来のTCP接続を使用するMySQL・PostgreSQLなどは、WorkersのV8 Isolates環境からは直接接続できません。ただし、HTTP APIを提供するデータベースサービスは利用可能です。

推奨されるアプローチは、Cloudflare D1（Cloudflareのサーバーレスデータベース）を使用することです。D1はSQLiteベースで、WorkersからSQLクエリを実行できます。バインディング経由でアクセスし、トランザクション・インデックス・JOINなどの標準SQL機能が使えます。レイテンシは通常10ミリ秒未満で、Workerと同じエッジで動作するため高速です。

外部データベースを使用する場合、REST APIやGraphQL経由でアクセスします。PlanetScale・Supabase・FaunaDB・Hasuraなどは、HTTP APIを提供しており、Workerからfetchで呼び出せます。認証はAPIキーまたはJWTで行い、シークレットはwrangler secretで管理します。PostgreSQLやMySQLを使いたい場合、Postgrestやpg-gatewayなどのHTTPゲートウェイを経由する方法もあります。

エラーログやメトリクスはどう収集しますか？

Cloudflare Workersのログとメトリクスは、Logpush・Analytics Engine・Workers Traceの3つの仕組みで収集できます。Logpushは、すべてのWorkerリクエストのログをS3・Google Cloud Storage・Datadogなどの外部サービスにストリーミングします。ログにはリクエストURL・ステータスコード・レスポンス時間・CPU時間・エラーメッセージが含まれます。2026年5月時点で、Logpushは有料プランで利用可能です。

Analytics Engineは、カスタムメトリクスを記録する仕組みです。Workerコード内でenv.ANALYTICS.writeDataPoint()を呼び出し、ビジネスメトリクス（コンバージョン数・エラー率・A/Bテスト結果）を記録します。データはCloudflareダッシュボードのグラフで可視化でき、SQLクエリでも分析できます。料金は100万イベントあたり0.05ドルで、低コストで詳細な分析が可能です。

Workers Traceは、リアルタイムデバッグ用のツールです。wrangler tail –format prettyでWorkerのログをターミナルにストリーミングできます。console.log()の出力やエラーのスタックトレースがリアルタイムで表示されます。本番環境のデバッグ時に、特定のエラーを再現しながらログを観察できるため、問題の特定が迅速になります。

Cloudflare Workersの可用性とSLAはどの程度ですか？

Cloudflareは、Workersを含むネットワーク全体で99.99%以上のアップタイムを達成しています。2026年5月時点で、有料プラン（Pro以上）には100%のアップタイムSLA（Service Level Agreement）が含まれ、未達成時は月額料金の一部が返金されます。無料プランにはSLAはありませんが、実績として同等の可用性が提供されています。

Cloudflareのグローバルネットワークは330以上の都市に展開され、Anycastルーティングにより単一のIPアドレスで全エッジにトラフィックを分散します。1つのデータセンターがダウンしても、トラフィックは自動的に他の健全なデータセンターにルーティングされます。この冗長性により、地域障害や単一障害点による影響を最小化します。

障害対策として、Workerコード内でエラーハンドリングを実装することも重要です。KVやR2へのアクセスが失敗した場合、デフォルトの応答を返すフォールバック処理を実装します。外部APIへのfetchは、タイムアウトと再試行ロジックを設定し、依存サービスの障害が連鎖しないようにします。Cloudflareの障害時はオリジンサーバーに直接トラフィックをルーティングするDNSフェイルオーバーも設定できます。

導入前チェックリスト

・要件整理: エッジで実行すべき処理を明確化（認証・キャッシュ・ルーティング・変換）
・コールドスタート許容度: レイテンシ要件を定義（1ms未満が必要か、100ms許容か）
・CPU時間見積もり: 処理の計算量を評価し、50ms制限内か確認
・データ整合性要件: 結果整合性で問題ないか、強整合性が必要か判定
・既存インフラ統合: AWS・GCP・Azure等との接続方法を設計
・ストレージ選定: KV・R2・Durable Objects・D1のどれを使うか決定
・デプロイパイプライン: CI/CDでwrangler publishを統合
・環境分離: 本番・ステージング・開発環境のバインディングを分離
・コスト試算: 想定リクエスト数・ストレージ量から月額コストを算出
・ログ・監視設計: Logpush・Analytics Engine・Traceの利用計画
・エラーハンドリング: フォールバック処理・タイムアウト・再試行ロジックを実装
・セキュリティ: シークレット管理・JWT検証・レート制限の実装
・パフォーマンステスト: wrangler devでローカル負荷テストを実行
・ドキュメント: Workerの責務・バインディング・デプロイ手順を文書化
・チームトレーニング: Wrangler CLI・TypeScript・V8 Isolatesの基礎知識を共有

本記事のまとめ

Cloudflare Workersは、V8 Isolatesによるコールドスタートゼロのエッジコンピューティング環境です。AWS Lambda@EdgeやFastly Compute@Edgeと比較して、起動速度・デプロイ速度・データ転送コストで優位性があります。wranglerによる開発体験は現代的で、ローカル開発からCI/CD統合までスムーズに行えます。

Workers KVとR2の組み合わせにより、メタデータの高速アクセスと大容量ファイルの低コスト保存を両立できます。A/Bテスト・キャッシュ最適化・JWT検証・地理分散ルーティングなど、エッジで実行すべき典型的なパターンが確立されており、実装の参考になります。

導入にあたっては、CPU時間制限・KVの結果整合性・バインディング設定などの制約を理解することが重要です。適切な設計と実装により、オリジンサーバーへの負荷を大幅に削減し、エンドユーザーへのレスポンスを劇的に高速化できます。2026年5月時点の料金体系は、小規模から大規模まで幅広いユースケースに対応できる柔軟性があり、クラウドインフラの新しい選択肢として検討する価値があります。