なぜ今あらためてエッジを比較するのか
- 年までは「Cloudflare Workers で十分」というのが多くの日本企業の結論だった。しかし2025年以降、Fastly Compute の WASM ランタイムが安定し、AWS が Lambda@Edge を CloudFront Functions 2.0 として刷新、Akamai が EdgeWorkers のメモリ上限を引き上げるなど、選択肢が再度拮抗してきている。特に東南アジア（シンガポール・ジャカルタ・バンコク・マニラ）への展開を伴う日本企業にとって、各社の PoP 分布と法規制対応が戦略的に効いてくる。
本稿では4プラットフォームを「cold start」「実効メモリ」「GB-秒単価」「地理分布」「WAF / Bot 管理統合」の5軸で比較し、ユースケース別の選定マトリクスを提示する。数値は2026年4月時点のパブリック情報と弊社の本番ベンチマーク（東京・シンガポール・ムンバイの3リージョンで各1時間 / 1000 req/s）に基づく。
Cold Start と実効メモリ
Cloudflare Workers は V8 Isolate のため cold start がほぼ計測不能（p99 で 5ms 未満）だが、Isolate 1 個あたりのメモリは 128MB 固定である。Fastly Compute は WebAssembly を起動するための wasmtime ベースランタイムで、cold start は p50 で 0.3ms、p99 で 5ms 前後と Workers と並ぶ速度を持ちつつ、メモリは 512MB まで拡張できる。AWS Lambda@Edge は従来通りの Firecracker MicroVM ベースで、cold start は p50 で 150ms、p99 で 600ms を超えることもあり、定期的な warm-up が必須である。Akamai EdgeWorkers は V8 ベースだが、tier ごとに CPU time と memory 上限が分かれ、Dynamic tier で 256MB / 200ms が上限となる。
ベンチマークの結論は明快で、「1ms 応答が必要なホットパス」は Cloudflare か Fastly、「100ms 以上の処理が必要な重いロジック」は AWS Lambda@Edge というすみ分けになる。Akamai はその中間に位置し、既存 Akamai CDN 契約がある組織にとって追加コストなしで使える点が強みだ。
``` # 東京 PoP での単純 JSON 返却 p99 レイテンシ（2026年4月社内計測） Cloudflare Workers : 4.8ms Fastly Compute (WASM) : 5.2ms Akamai EdgeWorkers : 12.1ms AWS Lambda@Edge (cold) : 612ms / (warm) 38ms ```
GB-秒コストと請求モデル
Cloudflare Workers は「実行時間 × リクエスト数」ではなく「CPU time のみ」で課金する独自モデルで、I/O 待ちが課金対象外になる。Bundled プランは月 500万リクエスト + 50ms CPU time が 5 USD、Unbound は 10M req + 30M CPU-ms で 5 USD。Fastly Compute は「コアインスタンスあたりの月額」モデルで、1 インスタンス 50 USD から、リクエスト従量は超過時のみ発生する。AWS Lambda@Edge は 1ms 単位の GB-秒課金で、オリジンリクエストとビューワーリクエストで単価が異なる（ビューワー側が 3 倍高い）。Akamai EdgeWorkers は契約ベースで、Dynamic tier が月 50 万回実行までで 500 USD 前後、超過は従量。
実効単価を「1M req / 平均 CPU 10ms / ペイロード 10KB」で試算すると以下のレンジになる。Cloudflare 0.5 USD、Fastly 0.4 USD（コアインスタンス契約内に収まる場合）、AWS Lambda@Edge 2.1 USD、Akamai 3.0 USD 前後。単純単価では Cloudflare / Fastly が圧倒的に安い。ただし AWS は既存 CloudFront / S3 / DynamoDB とのデータ転送無料圏内で動くため、総コストで見ると逆転する局面もある。
地理分布と日本 × 東南アジア Traffic
日本発・東南アジア着のトラフィックにおける PoP カバレッジは以下の通り。Cloudflare は東京・大阪・ホーチミン・ハノイ・ジャカルタ・マニラ・バンコク・シンガポール・クアラルンプールと主要都市を網羅する。Fastly は東京・大阪・シンガポール・香港が強く、インドネシア・ベトナムは相互接続プロバイダ経由となり平均 RTT が 20ms 程度増える。AWS Lambda@Edge は CloudFront PoP に準じ、東京・大阪・シンガポール・ジャカルタ・マニラ・バンコクにあるが、Lambda 実行は PoP ではなく最寄り Regional Edge Cache（東京・シンガポール・ムンバイ等の11箇所）で動くため、純粋な PoP 実行ではない。Akamai は地球上最多の PoP を持つが、EdgeWorkers が動く PoP はその一部に絞られる。
「東南アジア全域に等しく低レイテンシ」を求めるなら Cloudflare が最有力、「日本・シンガポール軸で完結」するなら Fastly の WASM 性能が活きる、「AWS 既存資産と統合」するなら Lambda@Edge、という整理になる。ASEAN 向け EC サイトで p95 で 80ms 以下を維持したい場合、Cloudflare + Durable Objects のシャーディングが最もコストパフォーマンスが高かった、というのが弊社3案件の一貫した結論である。
WAF / Bot 管理の統合度
エッジコンピュートはもはや「ロジック実行」だけでなく、WAF・Bot 管理・DDoS 防御とセットで評価する時代になった。Cloudflare は WAF（OWASP Core Rule Set + 独自ルール）・Bot Management・Turnstile が Workers と同一管理画面で完結し、Workers 内から cf.botManagement.score を直接参照して動的に挙動を変えられる。Fastly は Signal Sciences（2020年買収）をベースにした Next-Gen WAF を持ち、Compute 内で RulesEngine を呼び出せる。AWS は AWS WAF + Shield が CloudFront レイヤーで動き、Lambda@Edge 内では event.Records[0].cf.request.headers の検査を自前で書く必要がある。Akamai は App & API Protector（旧 Kona）が最も成熟しており、金融業界では依然として第一選択肢だ。
Bot 判定精度は4社とも 2025年以降 ML ベースに移行しており、OWASP ATP（Automated Threat Protection）の検出率は95%前後で横並びになった。差がつくのは「誤検知時の救済フロー」と「SOC 連携」で、Akamai と Cloudflare が SIEM 連携（Splunk / Sentinel / Datadog）を標準提供する一方、Fastly は Datadog のみ、AWS は CloudWatch 経由の変換が必要となる。
選定マトリクス: ユースケース別推奨
以下は弊社が顧客提案時に使っている選定マトリクスの抜粋である。
- 超低レイテンシ API（1ms 台の応答）: Cloudflare Workers または Fastly Compute
- ステートフルなエッジロジック（協調編集・シグナリング）: Cloudflare Workers + Durable Objects 一択
- 既存 AWS スタック（S3 / DynamoDB / Cognito）との密結合: AWS Lambda@Edge + CloudFront
- 金融・医療など規制業界の WAF / SOC 要件重視: Akamai EdgeWorkers + App & API Protector
- 月数億リクエストの大規模 B2C でコスト最優先: Fastly Compute の月額コアインスタンス
- 日本 + ASEAN 全域で一貫した SLO（p95 80ms）: Cloudflare Workers
- 動画・画像のリアルタイム変換（100ms 超の CPU 処理）: AWS Lambda@Edge または Fastly Compute（メモリ 512MB）
結論: 一社依存から脱却する時代
- 年のエッジアーキテクチャは、単一プラットフォームへの依存が技術的にも事業継続性的にもリスクとなっている。Cloudflare の大規模障害（2023年11月、2025年2月）や AWS us-east-1 障害がたびたびグローバル影響を起こしている現実を踏まえ、「プライマリは Cloudflare、静的コンテンツは Akamai、バッチ処理は AWS」といったマルチエッジ戦略を採る大企業が増えた。OpenTelemetry でメトリクスを統一し、Terraform で IaC を横断管理することで、ベンダーロックインのコストを下げつつ可用性を確保する。
選定は「一番速い一社」を選ぶ問題ではなく、「ワークロードごとに最適な組合せを設計する」問題に変わった。ベンチマーク数値は陳腐化するが、プラットフォームの思想の違いは長期間有効な判断基準となる。自社のトラフィック特性・規制要件・既存資産を明示化し、四半期ごとに見直す運用がエッジ時代の標準形である。