Edge Functions採用の判断軸とアンチパターン

TL;DR

• 採用が向く場面: 認証・geo-routing・A/B 振り分け・パーソナライズドキャッシュ・LLM ストリーミングのプロキシなど、短時間で完了する処理 × 地理分散の効くワークロード
• 採用が向かない場面: 重い CPU バウンド処理・Node-only ライブラリ依存・DB 直結 TCP（公式 Socket / 接続プール代替が無い構成）・長時間接続主体のアプリ
• 最初の一歩: 既存サーバーの 前段 にだけ Edge を置き、認証・geo-routing から段階導入する。本格採用は §4 の決定木を通してから

はじめに

こんにちは、みねです。

「Edge Functions を採用すべきか」——プラットフォーム選定で答えに詰まる場面が増えました。Cloudflare Workers・Vercel Edge Functions・Deno Deploy はどれもエッジで動きますが、ランタイム種別や制約は微妙に違います。気がつけば「とりあえず Edge」と決まり、後から CPU 時間制限や Node API 非対応で苦労する——よくあるパターンです。

この記事では、Edge Functions の採用判断軸を レイテンシ／cold start／runtime 制約／運用 の4本に整理し、決定木とアンチパターンで「いつ採用し、いつ採用しないか」を言語化します。

この記事でできるようになること

• Cloudflare Workers / Vercel Edge Functions / Deno Deploy の位置関係をランタイム種別と制約で説明できる
• 4つの判断軸（レイテンシ・cold start・runtime 制約・運用）で採用是非を判断できる
• アンチパターンを事前に切り分けて回避できる

対象読者

• バックエンド／プラットフォーム／SRE エンジニア（経験 3〜10 年）
• Next.js / Express / Lambda で API を運用した経験がある
• 採用是非をチームに説明する材料が欲しい

この記事でやらないこと

• 各プラットフォームの料金最適化（プラン変更が頻繁なため別記事に譲る）
• 個別チュートリアル（公式ドキュメントが詳しい）
• ブラウザ向け Edge / CDN キャッシュ戦略の詳細

1. なぜいま Edge Functions の判断が難しいのか

1.1 Edge / Serverless / 通常サーバーの位置関係

「Edge Functions」と一括りにすると判断を誤ります。実際は3層が重なっています。

• 通常サーバー（EC2 / Cloud Run / コンテナ）: 任意の言語・ライブラリ・長時間処理 OK
• Serverless Functions（Lambda / Vercel Functions / Cloud Functions）: コンテナ系が多く Node API はほぼ揃うが起動はやや遅い
• Edge Functions（Workers / Vercel Edge / Deno Deploy / Fastly Compute）: V8 isolate / Wasm で動かし起動は最速だが ランタイム制約がきつい

Edge は「速いが制約も多い」層で、「処理時間が数百 ms 以内 × ユーザー位置に結果が依存」条件にハマったときだけ効きます。

1.2 比較が崩れる典型パターン

議論が崩れる原因は混同です。

• 「Edge Functions」と「Edge ネットワーク（CDN）」: CDN キャッシュで足りる用途を押し込んでいないか
• 「ランタイム種別」と「PaaS」: Workers は V8 isolate、Fastly Compute は Wasm。同じ Edge でも基盤と制約が違う
• 「Vercel Edge Functions」と「Vercel Functions（Node ランタイム）」: 両方を提供し設定 1 行で切替。比較対象を明確にしないと議論が滑る

2. 主要プラットフォーム早見表

2.1 ランタイム種別と主要言語

スペック値（CPU 時間上限・メモリ・サイズ等）はベンダーが頻繁に更新します。本記事では数値の固定断言を避け、公式ドキュメント記載として URL へ送ります（References 参照）。

2.2 Cloudflare Workers と Pages Functions の関係

混同されがちですが、Cloudflare Pages Functions は Workers runtime 上で動く Pages 統合の関数機能で、KV / Durable Objects / D1 / R2 などのバインディングも利用できます（公式ドキュメント記載）。ランタイム制約は Workers 系として見て差し支えありません。役割の違いは用途で、Workers は汎用 API / バックエンド向け、Pages Functions は Pages プロジェクトに紐づくフルスタック用途、と整理できます。

2.3 状態保持・データアクセス手段

Edge Functions の制約として最初に効くのは「TCP 直結を前提にした DB 接続設計が崩れやすい」点です。プラットフォームによっては TCP ソケット自体を提供しますが（Cloudflare Workers の cloudflare:sockets 等）、Edge から DB へ直接プールを張る設計は 接続数・リージョン分散・認証情報管理 で難しくなりやすいので、HTTP / managed connector / 公式接続プール（Hyperdrive など）を優先するのが定石です（経験則）。

• HTTP ベース DB: PlanetScale Serverless / Neon HTTP / Supabase REST / Cloudflare D1
• コネクションプール代替: Cloudflare Hyperdrive / Prisma Accelerate
• エッジ KV: Workers KV / Vercel KV / Deno KV（読み込み主体・結果整合）
• 強整合のステート: Cloudflare Durable Objects（リージョン固定の Actor 風）

「DB と Edge を直結」を捨て、HTTP API の前段で Edge を使う設計に置き換えるのが定石です。

3. 4つの判断軸（レイテンシ／cold start／runtime／運用）

3.1 レイテンシ — 地理分散の効き目

Edge の価値は「ユーザーに近い PoP で実行」による TTFB 短縮です（経験則で、リージョン違いで数十〜数百 ms の差が出るケース）。

ただし 次の条件で効果が消えます。

• DB が単一リージョンにしかない: Edge から遠回りでむしろ遅くなる
• CDN キャッシュ HIT で足りる: 純粋なオーバーヘッド
• 処理がほぼ DB 待ち: ボトルネックが DB I/O なら Edge にしても変わらない

「Edge 化で速くなるのは計算と分岐がボトルネックだったとき」と覚えれば判断が早いです。

3.2 Cold Start — V8 isolate と Wasm の優位性

Edge Functions は通常のコンテナ系 Serverless（Lambda 等）より cold start が短いと一般に言われます（公式ドキュメントで V8 isolate / Wasm の起動が高速と説明あり）。具体値は固定せず、各ベンダー公式を参照するのが安全です（経験則）:

• V8 isolate: スクリプト初期化中心。import 解決が重いと顕在化
• Wasm（Fastly Compute）: モジュール instantiate コスト。バイナリサイズを抑えると速い
• コンテナ系（Lambda）: イメージ起動・VPC 接続初期化が乗ると遅い

cold start が実トラフィックで効くかは p50 ではなく p95/p99 で見ます。Wasm 寄りの深掘りは Wasmはサーバー実装で本当に効くのか を参照。

3.3 Runtime 制約 — Web 標準 vs Node API

最も移植コストに直結する軸です。Edge ランタイムは「Web 標準 API ファースト」で、Node 独自 API は限定対応です。

• 動くもの: fetch / Request / Response / URL / WebCrypto / Streams / Headers
• 動かないことが多いもの: fs / child_process / net / native addon / 一部の Buffer 用法
• プラットフォーム依存: process.env、AsyncLocalStorage

既存 Node アプリの移植可否は「Node-only 依存が何本あるか」で決まります。jsdom 等の重量級が混じれば移植 NG と即断できます。サンドボックス全体像は AIコーディング時代のセキュリティ設計 を参照。

3.4 運用 — 観測・デバッグ・コスト

• ログ: 分散実行でリージョンごとに散る。集約手段（Logpush / Tail / Drain）を先に決める
• デバッグ: ローカル CLI（wrangler / vercel dev / deno deploy / Fastly CLI）に依存。本番差異を把握する
• コスト: リクエスト数 + CPU 時間課金が多い。ループ内で Edge を呼ぶ誤用で請求が爆発する
• タイムアウト: プラットフォームごとに CPU 時間 ／ 初回レスポンスまでの時間 ／ ストリーミング/接続 duration で上限が分かれる（公式ドキュメント記載、Cloudflare Workers は CPU と duration を別管理、Vercel Edge は初回応答と stream duration を別管理 等）。長時間処理は 絶対に Edge に置かない

リトライ・冪等性の設計は エラーハンドリング設計ガイド と合わせます。

4. 採用判断の決定木

下のフローで判断します（diagram を参照）。

Q1. 処理が p95 で 数百 ms 以内に終わるか？
   ├─ No  → 通常 Serverless / コンテナへ（Edge は不適）
   └─ Yes → Q2

Q2. Node-only ライブラリへの強依存があるか？
   ├─ Yes → 移植コストを試算 → 高ければ通常ランタイムに留める
   └─ No  → Q3

Q3. データアクセスは HTTP ベース、または公式の接続プール／ソケット機能で接続数を制御できるか？
   ├─ No  → コネクションプール代替（Hyperdrive 等）導入で再判定
   └─ Yes → Q4

Q4. 長時間接続（WebSocket / SSE）が主機能か？
   ├─ Yes → 対応状況をプラットフォーム単位で確認（Workers Durable Objects / Deno Deploy / Vercel Edge は仕様差あり）
   └─ No  → Q5

Q5. 地理分散で本当にレイテンシが下がる構成か？
   ├─ No  → Edge を選ぶ理由が薄い → 通常 Serverless
   └─ Yes → Edge Functions 採用 GO

5問とも Yes でようやく Edge 採用が筋になります。1問でも No なら、その No に対する逃がし方を設計してから再判定するのが安全です。

5. アンチパターン集（避けるべき採用）

5.1 重い CPU バウンド処理を Edge に押し込む

PDF 生成・画像のフル変換・ML 推論など CPU を秒オーダーで使う処理は Edge で止まります。プラットフォームごとに CPU 時間 の上限が定められており、超えると処理が切られます（公式ドキュメント記載）。逃がし方: 重い処理は Lambda / Cloud Run / Job キューに分離し、Edge は入口の認証・振り分けに絞る。「Edge から非同期キューに enqueue → 重い処理は通常ランタイム」が定石です。

5.2 Node-only ライブラリへの強依存を放置

fs.readFileSync や child_process.spawn を本体ロジックで使うコードはそのまま Edge に行きません。逃がし方: 移植コストを先に試算。1〜2本のラッパーで済むなら移植、深く依存しているなら Edge は諦めて通常 Serverless。マイクロサービスの失敗パターン の「分散の認知コスト」と同じ罠です。

5.3 DB 直結 TCP 接続を素朴に Edge から張る

プラットフォームによっては TCP Socket API を提供しますが（Cloudflare Workers の cloudflare:sockets 等）、Edge から 接続プールを素朴に張ると PoP ごとに分散して DB 側が枯渇する事故が起きます。逃がし方: HTTP ベース DB（PlanetScale Serverless / Neon HTTP / D1 / Supabase REST）か、公式の接続プール代替（Hyperdrive / Prisma Accelerate）を必ず挟む。詳細は DBマイグレーション失敗パターン と合わせて読むと事故が減ります。

5.4 長時間接続を前提にした設計

WebSocket / SSE を主機能にする場合、Edge プラットフォームで対応状況が大きく違います（公式ドキュメント記載）。逃がし方: durable workflow としてサーバー側に長期実行を残し、Edge は接続のフロントに留める設計。詳細は agent loop を durable workflow で安定化する実装 を参照。

6. 段階導入のレシピ

「いきなり全部 Edge」は失敗確率が高いので、段階を切ります。

6.1 既存サーバーの前段にだけ Edge を置く

最小リスクの第一歩は既存サーバーの手前に Edge を一段挟むこと。Bot 判定・キャッシュキー操作・ヘッダ書き換えなど ステートレスな前処理だけを Edge に出し、本体 API は Node ランタイムのまま動かします。

6.2 認証・geo-routing を Edge へ切り出す

次は認証ヘッダ検証やリージョン振り分けを Edge に移すパターン。JWT 検証は Web Crypto で実装可能で Edge と相性が良く、認証通過後に本体 API へ proxy します。認証認可の設計は 認証・認可設計のやり直しガイド と並べて検討してください。

6.3 LLM ストリーミングのプロキシとして使う

LLM API のストリーミングレスポンスを Streams API で中継する役として Edge は強力です。トークンを露出させず前段で API キーを差し込め、TTFB が短く体感が良くなります。ただし「LLM の重い後処理」を Edge に置くのは §5.1 のアンチパターンに直結するので、後処理は Worker キューや通常 Serverless に逃がす設計を最初から組んでおきます。

採用判断について「自社構成で本当に効くか自信がない」と感じたら、設計レビューの相談だけでも歓迎です。

FAQ

Q1. Cloudflare Workers と Vercel Edge Functions はどちらを選ぶべきですか？

ランタイムはどちらも V8 isolate ベースで近く、周辺エコシステムで決まります。Cloudflare は KV / Durable Objects / D1 / R2 / Hyperdrive と独自ストアが厚く、Vercel は Next.js デプロイ統合と Edge Config / Vercel KV の導線が短いのが特徴です。Next.js 主体なら Vercel、フロント非依存の API ゲートウェイなら Cloudflare、が経験則の振り分けです。

Q2. Deno Deploy はどんなときに候補に上がりますか？

TypeScript と Web 標準 API を中心にフルスタックを揃えたいチームに向きます。Deno Deploy は full-featured serverless platform として位置づけられ、Web APIs に加えて Deno APIs と Node.js / npm 互換も提供します（公式ドキュメント記載）。状態管理は Deno KV（FoundationDB-backed）が用意されており、強整合プリミティブが必要なら Deno KV、Actor 型の単一オブジェクト配置が必要なら Cloudflare Workers Durable Objects を比較するのが現実解です。

Q3. Lambda@Edge と CloudFront Functions の違いはなんですか？

CloudFront Functions は JS のみ・極短実行時間・状態保持なし の極軽量関数で（公式ドキュメント記載）、ヘッダや URL の書き換えに向きます。Lambda@Edge は Lambda がエッジで動く仕様で多機能ですが、PoP まで関数がレプリカされるためデプロイ整合性に注意。CFF で済む処理を Lambda@Edge に置くのは過剰です。

Q4. Edge Functions に最低限残すべき監視項目は？

p95/p99 レイテンシ・エラー率・CPU 時間使用率（プラン上限比）・サブリクエスト失敗数の4つ。Edge は cold start が速い反面、サブリクエスト先（DB / 外部 API）で詰まると利点が消えるため、個別 SLI を取って責任分界を観測できる状態にすると障害切り分けが早くなります。

Q5. Next.js では Vercel Functions と Edge Functions どちらをデフォルトに？

**Node ランタイム（Vercel Functions）**が安全です。Edge Runtime への切り替えは §4 の決定木を全 Yes で通過したルートだけ。Next.js は Route Segment 単位で export const runtime = 'edge' を切り替えられるため、ルートごとに最適な側を選ぶのが現実解です。

References

1. Cloudflare Workers Documentation — Workers の公式ドキュメント
2. Cloudflare Workers Limits — CPU 時間・メモリ・サイズ等の制約一覧
3. Vercel Edge Functions / Edge Runtime — Vercel の Edge Runtime 仕様
4. Deno Deploy Documentation — Deno Deploy の公式ドキュメント
5. Fastly Compute Documentation — Wasm ベース Edge プラットフォーム
6. AWS Lambda@Edge / CloudFront Functions — AWS のエッジ関数 2 種
7. Next.js Edge Runtime — Next.js の Edge Runtime 対応 API
8. WebAssembly System Interface (WASI) — Wasm ランタイムの I/O 標準

関連記事

• Wasmはサーバー実装で本当に効くのか — Edge ランタイム基盤として Wasm を選ぶ判断軸
• マイクロサービスの失敗パターン — 分散の認知コストで Edge 化を再考する
• エラーハンドリング設計ガイド — Edge と通常ランタイム混在時のリトライ・冪等性
• 認証・認可設計のやり直しガイド — Edge での認証層切り出しと組み合わせる設計
• agent loop を durable workflow で安定化する実装 — 長時間処理を Edge から逃がす先
• WebGPU実用化の現在地と落とし穴 — Edge から GPU compute / ブラウザ ML inference へ広げる場合の役割整理
• Technology Radar の作り方｜30分会議テンプレ付 — Edge Functions 採用判断（Adopt / Trial / Hold）を組織運用に乗せるフレーム

まとめ

Edge Functions は「短時間 × 地理分散 × Web 標準 API」の条件にハマれば強烈に効きますが、外れたときの代償も大きい技術です。決定木の5問とレイテンシ・cold start・runtime・運用の4軸で見る習慣を持てば、判断は安定します。

まずは既存サーバーの 前段に Edge を一段だけ 置き、認証や geo-routing から段階導入してみてください。本格採用は §4 の決定木が全 Yes になってからで遅くありません。