独立サイトのエッジコンピューティング：Cloudflare Workers／Vercel Edgeの活用シーンと性能
1. エッジコンピューティングとは何か、CDNとの関係
従来のCDNは静的ファイルのキャッシュだけを行い、ユーザーのリクエストが来たらそのままキャッシュを返します。エッジコンピューティングはCDNノード上で短いJavaScriptコードを動かし、レスポンスを返す前にロジックを判断します。ユーザーの位置情報で表示ページを切り替え、cookieで表示するバージョンを決め、JWTが有効かを検証する、といった処理です。このロジックはユーザーから数十ミリ秒のノードで実行され、オリジンへ戻る必要がありません。
サーバーサイドレンダリング（SSR）との違い：SSRは自社のサーバーで動くため、世界中のユーザーが海を越えてそのサーバーへ接続します。エッジ関数は世界300以上のノードで同時に動くので、ユーザーは最寄りのノードに接続するだけで済みます。越境B2Bの独立サイトでは、この距離の差がTTFBを100ミリ秒にするか800ミリ秒にするかを直接左右します。CDNとエッジの関係はこちらをご覧くださいCDNグローバル高速化。
直感に反する判断：エッジコンピューティングは「より速いサーバー」ではなく「より小さいサーバー」です。各エッジ関数のCPU時間には厳しい上限があり、重い計算はできません。200ミリ秒かかるデータベースクエリのロジックをエッジへ移すと、オリジンで動かすより3倍以上遅くなります。エッジノードからデータベースまでのネットワーク距離が遠いからです。
| 実行環境 | 実行場所 | CPU時間の上限 | コールドスタート | データベースアクセス | 料金モデル |
|---|---|---|---|---|---|
| 従来のサーバー（VPS） | 単一のデータセンター | 厳密な上限なし | なし（常駐） | ローカル／社内ネットワーク、高速 | 月額固定 |
| Cloudflare Workers | 世界300以上のノード | 無料10ミリ秒／有料30ミリ秒 | ほぼゼロ（V8アイソレート） | 外部データベースへの接続が必要、低速 | リクエスト数に応じた課金 |
| Vercel Edge Functions | 世界25以上のノード | 最長30秒 | 10〜50ミリ秒 | Edge DBに対応 | 呼び出し時間に応じた課金 |
| AWS Lambda@Edge | 世界のCloudFrontノード | 最長5秒 | 10〜100ミリ秒 | パブリックネットワーク経由でRDSへ接続 | リクエスト数＋時間 |
2. エッジコンピューティングを使う価値が本当にある3つのシーン
最初のケース:地理位置と言語によるリダイレクト。海外向けサイトで、ドイツのユーザーがアクセスすると自動的に/de/のドイツ語版へ、中東のユーザーは/ar/のアラビア語版へ飛びます。従来の方法はサーバー上でIPデータベースを参照して判定し、リクエストのたびにオリジンサーバーへ戻る必要がありました。Cloudflare Workersで10行のコードを書けば、エッジノードでIPの国に基づいて直接301を返せます。TTFBは400ミリ秒から50ミリ秒に短縮されます。多言語サイトでのhreflangの設定方法はこちらHreflang多言語対応。
2つ目のケース:A/Bテストの振り分け。トップページを2つのバージョンにして、50%のユーザーにA版、50%にB版を見せたいとします。従来の方法はサーバー側でcookieを読み取ってどちらをレンダリングするか決めていました。エッジでの方法はもっと簡単です。Workersがcookieのハッシュ値に基づいて、HTML内のリソースパスを書き換えたり、異なる変数を注入したりします。オリジンサーバーはまったく関与しません。振り分け自体は10ミリ秒以内に完了し、TTFBには影響しません。
3つ目のケース:軽量な認証とbot対策。ユーザーがログイン後に送るリクエストは、まずエッジでJWTの有効性を検証し、無効なら直接401を返してオリジンサーバーには戻しません。これによりオリジンサーバーは正当なリクエストだけを処理し、帯域とCPUを節約できます。bot対策もエッジで行えます。不審なUAやリクエスト頻度の高さを検知したら、直接チャレンジページを返し、リクエストをオリジンサーバーに到達させません。
| シナリオ | エッジでの実装方法 | パフォーマンス効果 | 開発工数 | 推奨優先度 |
|---|---|---|---|---|
| 地理リダイレクト | Workersがrequest.cf.countryを読み取る | TTFBが50〜150ミリ秒短縮 | 半日 | 高 |
| A/Bテスト振り分け | Workersがcookieハッシュで振り分け | TTFBは増加しない | 1〜2日 | 中 |
| JWTエッジ認証 | エッジでtokenを検証し、無効なら即拒否 | オリジンサーバー負荷が20%〜40%削減 | 2日 | 高 |
| bot対策/レート制限 | エッジでUAと頻度を検知 | 悪意あるリクエストをオリジンに通さない | 1日 | 高 |
| パーソナライズページのレンダリング | エッジでHTMLフラグメントを組み立て | 繰り返し使うフラグメントにのみ有効 | 3〜5日 | 低 |
3、エッジコンピューティングを使うべきでない2つの落とし穴
1つ目の落とし穴:データベースクエリをエッジに移すこと。「エッジコンピューティングはすごい」と思って、ユーザーセンターのクエリ処理までエッジに移す人が多くいます。しかしエッジノードは遠隔のデータベースに接続するため、1回のクエリのネットワーク往復だけで200ミリ秒かかり、オリジンサーバーのローカルクエリより5倍遅くなります。エッジ関数は「ステートレスで軽い計算、キャッシュ頼み」の処理に向いており、「データベースへの問い合わせが必要」な処理には向いていません。
2つ目の落とし穴:SSR全体をエッジに移すこと。Next.jsのEdge Runtimeモードは確かにVercelのエッジノードでReactレンダリングを実行できますが、複雑なページのレンダリングには100ミリ秒以上のCPU時間がかかることがあり、無料版の制限に引っかかったり、コールドスタートで初回訪問ユーザーを50ミリ秒余計に待たせたりします。複雑なサーバーサイドレンダリングは依然としてオリジンサーバーで実行すべきで、エッジは軽量な中間層に徹するべきです。サードパーティスクリプトの管理方法はこちらサードパーティスクリプトの管理。
場面別の例：海外展開するSaaS製品で、ユーザーのダッシュボード画面がデータベースを参照して描画する必要があったとします。チームは最初、Vercel Edge Runtimeでこの画面を書き直せることに興奮しましたが、エッジノードからAWS RDSデータベースまでの遅延が80ミリ秒あり、描画時間を加えるとTTFBは250ミリ秒から450ミリ秒に逆に増えてしまいました。その後、ダッシュボードをオリジンに戻し、エッジではログイン検証とルーティングの振り分けだけを行うようにしたところ、TTFBは250ミリ秒に戻りました。
| 落とし穴 | 一見よさそうに見える点 | 実際の結果 | 正しい方法 |
|---|---|---|---|
| データベース参照をエッジに移す | 「ユーザーに近い」 | エッジからDBはネットワークが遠く、遅延が3〜5倍に増える | DB参照はオリジンに残し、エッジはキャッシュ読み取りだけにする |
| サイト全体のSSRをエッジで動かす | 「グローバル高速化」 | CPU上限超過やコールドスタートの遅さで、TTFBが逆に増える | エッジは中間層だけにして、描画はオリジンに残す |
| 大量のファイル読み書き | 「ローカル処理」 | エッジには永続ディスクがなく、メモリも限られる | ファイル操作はオブジェクトストレージAPI経由にする |
| 長時間の計算処理 | 「並列で速くなる」 | CPUタイムアウトで1102エラーになる | 小さな処理に分割するか、メッセージキュー経由にする |
4. コストと選定：Cloudflare Workers vs Vercel Edge
Cloudflare WorkersとVercel Edge Functionsは、現在の独立系サイトで最もよく使われる2つのエッジプラットフォームです。選定は主に技術スタックとトラフィック規模で決まります。Cloudflare WorkersはV8 isolateを使い、コールドスタートがほぼゼロで、無料版は1日10万リクエストまで。軽量なルーティングや認証に向いています。Vercel Edge FunctionsはNext.jsと深く統合されており、すでにNext.jsを使っているなら移行コストが最も低いですが、コールドスタートはWorkersより遅いです。
コスト面では、Cloudflareの有料版は月5ドルからで1000万リクエストを含みます。VercelのPro版は月20ドルからで、エッジ関数は実行時間に応じた課金のため、トラフィックが増えると請求額が急速に膨らみます。中小B2Bの独立系サイトで月間PVが10万以内なら、Cloudflareの無料版でほぼ十分です。性能の監視方法はこちらをご覧くださいサイト監視とアラート。
| 次元 | Cloudflare Workers | Vercel Edge Functions | AWS Lambda@Edge |
|---|---|---|---|
| コールドスタート | ほぼゼロ（V8） | 10〜50ミリ秒 | 10〜100ミリ秒 |
| 無料枠 | 10万リクエスト/日 | 100GB-時間/月 | 100万リクエスト/月 |
| 有料プラン開始価格 | 5ドル/月 | 20ドル/月 | 従量課金、月額定額なし |
| 開発言語 | JavaScript/TypeScript | JavaScript/TypeScript | Node.js/Python |
| 向いているフレームワーク | 純粋な関数/ミドルウェア | Next.jsと深く統合 | AWSエコシステムのサイト |
| ノードのカバレッジ | 300以上の都市 | 25以上の国 | CloudFrontでグローバル展開 |
FAQ よくある質問
Cloudflare Workersの無料版は本当に十分ですか？
エッジ関数とCDNキャッシュはどんな関係ですか？
Vercel Edge FunctionsとCloudflare Workersはどちらが速い？
エッジ関数でSEO対策はできますか？
エッジ関数でエラーが出たらどうロールバックする？
どういう場合にエッジコンピューティングはサイトを速くしない？
最後に
エッジコンピューティングは”小さくて美しい”最適化手段であり、サイト全体のアーキテクチャを変える革命ではありません。解決するのは”リクエストのたびにオリジンサーバーへ戻る”という具体的なボトルネックで、軽量なルーティング、認証、振り分けといったロジックに向いています。”エッジに載せればサイト全体が2倍速くなる”という期待で取り組むと、おそらく失望します。遅さの大部分はデータベースクエリとサードパーティスクリプトにあり、ネットワーク距離にはないからです。
まずは最小のユースケースから始めましょう。Cloudflare Workersで地理リダイレクトを組み、ドイツのユーザーを自動でドイツ語ページへ誘導します。この変更なら半日でリリースでき、性能面の効果はすぐに表れ、リスクも最も低いです。2週間安定して運用できたら、A/Bテストによる振り分けやエッジでの認証を検討しましょう。最初からサイト全体をエッジに移そうと考えないことです。
覚えておきたい一言：エッジコンピューティングはユーザーに最も近い配送拠点であって、データベースに最も近い倉庫ではありません。仕分けの仕事は任せても、倉庫の仕事まで持ち込まないようにしましょう。