Skip to content
Published on

エッジコンピュートプラットフォーム 2026 — Cloudflare Workers / Vercel Fluid / Deno Deploy / Fastly Compute / Bun 徹底比較

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

1. 2026年のエッジコンピュート地図 — V8 isolate / WASM / Firecracker の3モデル

2026年5月現在、「エッジコンピュート」という言葉はもう一つのカテゴリではありません。同じ「サーバーレス関数」に見えても、内部の実行モデルは明確に3つに分かれています。

実行モデルコールドスタート隔離単位代表的なプラットフォーム
V8 isolate約 0 msV8 コンテキストCloudflare Workers, Deno Deploy, Vercel Edge, Netlify Edge, Supabase Edge
WebAssembly35 マイクロ秒WASM モジュールFastly Compute(旧 Compute@Edge), Cloudflare Workers(WASM バックエンド)
MicroVM(Firecracker)100 ms 以下(SnapStart で 50 ms 以下)VMAWS Lambda, Lambda SnapStart, Fly.io Machines, Vercel Fluid(混合)

トレードオフは常に同じです。

  • V8 isolate: 最速のコールドスタート、最も広いグローバル分散(300+ PoP)、ただし Node.js ネイティブアドオン不可
  • WebAssembly: 言語の自由度(Rust, Go, Swift, JavaScript すべて WASM にコンパイル可能)、マイクロ秒のコールドスタート、ただしエコシステムは小さい
  • MicroVM: 完全な Linux、すべての npm パッケージが動く、ただしコールドスタートは重く地理分散は限定的

2026年のトレンドは明確です。フルスタックエッジプラットフォーム(Cloudflare)と ハイブリッドサーバーレス(Vercel Fluid Compute)が両極を占め、残りは特定ワークロード(Fastly の CDN、Deno の Web 標準、Bun の速度)に居場所を見つけています。

WinterCG から WinterTC へ — 標準の進化

すべての主要エッジランタイムが WinterTC(旧 WinterCG)の Minimum Common API を実装しています。fetch、Request、Response、URLPattern、crypto.subtle、TextEncoder、ReadableStream、Headers、FormData、AbortController はどこでも同じ動作をします。つまり、よく書かれたエッジ関数は Cloudflare Workers、Deno Deploy、Vercel Edge、Netlify Edge で一行も変えずに動きます。

2. Cloudflare Workers — 最も完成したエッジプラットフォーム

Cloudflare Workers は 2025-2026 年にかけて、単純な「エッジ関数」から完全なフルスタックプラットフォームへと進化しました。主要な構成要素は7つあります。

サービス役割2026年5月の状態
WorkersV8 isolate 実行環境GA、300+ PoP
R2S3 互換オブジェクトストレージGA、egress 無料
D1SQLite ベースのグローバル DBGA(2024年4月)
Durable Objectsステートフルオブジェクト(SQLite バックエンド)GA、SQLite バックエンドは2025年 GA
HyperdrivePostgres / MySQL コネクションプーラーGA
QueuesメッセージキューGA
Workers AIGPU 推論GA

最大の変化は Durable Objects の SQLite バックエンドです。従来 K/V 形式だった状態保存が、2025年から各 DO インスタンスに組み込み SQLite が付くようになりました。つまり 各 Durable Object はミニデータベース + コンピュートの組み合わせになったわけです。

// Durable Object with SQLite backend (2025+)
import { DurableObject } from 'cloudflare:workers'

export class ChatRoom extends DurableObject {
  sql: SqlStorage

  constructor(state: DurableObjectState, env: Env) {
    super(state, env)
    this.sql = state.storage.sql
    this.sql.exec(`
      CREATE TABLE IF NOT EXISTS messages (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        user TEXT NOT NULL,
        body TEXT NOT NULL,
        ts INTEGER NOT NULL
      )
    `)
  }

  async addMessage(user: string, body: string) {
    this.sql.exec(
      'INSERT INTO messages (user, body, ts) VALUES (?, ?, ?)',
      user,
      body,
      Date.now()
    )
  }

  async recent(limit = 50) {
    return this.sql
      .exec('SELECT * FROM messages ORDER BY ts DESC LIMIT ?', limit)
      .toArray()
  }
}

Hyperdrive — エッジから Postgres を使う方法

Workers の V8 isolate は TCP ソケットを直接開けないのが長年の制約でした。Hyperdrive がこれを解決します。Postgres / MySQL の接続を Cloudflare のネットワーク内部でプーリングし、Workers は HTTP ライクなインターフェースでクエリを投げます。

// wrangler.toml
// [[hyperdrive]]
// binding = "DB"
// id = "your-hyperdrive-id"

import { Client } from 'pg'

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const client = new Client({ connectionString: env.DB.connectionString })
    await client.connect()
    const { rows } = await client.query('SELECT NOW()')
    return Response.json(rows)
  },
}

Hyperdrive の本当の価値は グローバルコネクションプーリング + エッジキャッシングです。東京から来たリクエストがアメリカの RDS まで往復せず、東京 PoP のプール済み接続を再利用し、キャッシュ可能なクエリはキャッシュから返します。

3. Cloudflare Workers AI / Vectorize / AI Gateway

2026年5月時点で、Cloudflare の AI スタックは3本柱です。

  • Workers AI: Llama 3、Mistral、Stable Diffusion など 50+ モデルを GPU で直接推論。PoP に分散された H100/A100。
  • Vectorize: ベクトル DB。RAG に必須。メタデータフィルタリング、32K 次元対応。
  • AI Gateway: OpenAI、Anthropic、Replicate などの外部 LLM API をプロキシ。キャッシング、レート制限、ロギング、トークンコストのトラッキング。
// AI Gateway through Workers
export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    // 1) Workers AI (Cloudflare's own GPU)
    const llmResp = await env.AI.run('@cf/meta/llama-3-8b-instruct', {
      messages: [
        { role: 'system', content: 'You are a helpful assistant.' },
        { role: 'user', content: 'Explain edge compute in one sentence.' },
      ],
    })

    // 2) AI Gateway proxy to OpenAI (cached, rate-limited)
    const openaiResp = await fetch(
      'https://gateway.ai.cloudflare.com/v1/ACCOUNT/my-gw/openai/chat/completions',
      {
        method: 'POST',
        headers: {
          Authorization: `Bearer ${env.OPENAI_KEY}`,
          'Content-Type': 'application/json',
        },
        body: JSON.stringify({
          model: 'gpt-4o-mini',
          messages: [{ role: 'user', content: 'Hello' }],
        }),
      }
    )

    return Response.json({ workers_ai: llmResp, openai: await openaiResp.json() })
  },
}

AI Gateway の本当の怖さは すべての外部 LLM 呼び出しをキャッシュできる点です。同じプロンプト + 同じモデルならキャッシュヒットでコストがゼロになります。本番ワークロードでトークン単価が 30-60% 削減される事例が普通に出ています。

4. Cloudflare Containers(2024年発表) — エッジで Linux

2024年9月に発表され、2025年ベータを経て2026年に GA に到達した Cloudflare Containers は、Workers の V8 isolate 制限を正面から突破します。完全な Linux コンテナを Cloudflare PoP で実行できるのです。

特徴:

  • リージョン固定が可能: Workers と違い、コンテナは特定リージョン(例: ソウル)にピン留めできます。
  • Workers との緊密な連携: Worker コード内で env.MY_CONTAINER.fetch(req) でコンテナを起動して呼び出せます。最初の呼び出しはコールドスタート(5-10 秒)ですが、その後は暖かい状態で保たれます。
  • OCI イメージ: 通常の Dockerfile が使えます。ffmpeg、headless Chrome、Python ML ライブラリなんでも。
  • ユースケース: 動画トランスコーディング、ヘッドレスブラウザ、AI 推論(GPU 未対応)、レガシーコードのホスティング。
// wrangler.toml
// [[containers]]
// binding = "MY_CONTAINER"
// image = "./Dockerfile"
// max_instances = 5

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    // Container is auto-started, kept warm for some time
    const container = env.MY_CONTAINER.get(env.MY_CONTAINER.idFromName('worker-1'))
    return container.fetch(req)
  },
}

Cloudflare Containers は Workers + Containers のハイブリッドアーキテクチャへの道を開きます。通常のリクエストは Workers(0 ms cold)で、重い処理は Containers(Linux full)へルーティングするパターンが標準になりつつあります。

5. Vercel Fluid Compute(2025年4月) — サーバーレス進化の次の段階

2025年4月、Vercel は既存の Serverless Functions を Fluid Compute という名前で全面的に再設計しました。コアアイデアはシンプルです。

「1 インスタンス = 1 リクエスト」のサーバーレスモデルを捨て、1つのインスタンスが複数のリクエストを同時に処理する。

従来の AWS Lambda モデルでは、同時リクエストごとに新しいインスタンスを起動します。Vercel Fluid Compute では1つの Node.js プロセスが複数のリクエストを in-flight で扱い、I/O 待ち時間を他のリクエストに譲り合います。結果として:

  • コールドスタート頻度の低下: 同じインスタンスが長く生き、より多くのリクエストを処理
  • コスト削減: 同時処理によって同じトラフィックをより少ないインスタンスで処理(Vercel 公式発表で平均 40-90% 削減)
  • AI ワークロードに最適: LLM レスポンス待ち時間(数秒)に他のリクエストを差し込める

Fluid Compute はすべての Vercel 関数のデフォルトになりました。Edge Runtime はそのまま V8 isolate 上で動き、Node.js Runtime が Fluid に進化した形です。

// app/api/chat/route.ts (Next.js 15+)
// Runs on Vercel Fluid Compute by default
export async function POST(req: Request) {
  const { prompt } = await req.json()

  // This await frees the Fluid worker to handle other requests
  // while the LLM streams back
  const stream = await openai.chat.completions.create({
    model: 'gpt-4o',
    messages: [{ role: 'user', content: prompt }],
    stream: true,
  })

  return new Response(stream.toReadableStream(), {
    headers: { 'Content-Type': 'text/event-stream' },
  })
}

Edge Functions の今後は?

Vercel は 2025 年後半から Edge Functions(Edge Runtime)と Fluid Compute の境界を徐々に曖昧にしています。Middleware は引き続き Edge で動きますが、route handler は大抵 Fluid のほうが有利です。推奨ルールは:

  • Middleware、ジオロケーション、A/B ルーティング: Edge Runtime(V8 isolate)
  • API route、LLM 呼び出し、DB クエリ: Fluid Compute(Node.js)
  • 静的ページ: ISR + CDN(Edge Cache)

6. Deno Deploy + KV + Queues

Deno Deploy は Deno ランタイムをグローバル 35 リージョンの V8 isolate 上で実行します。最大の強みは Web 標準ファーストであることです。

  • Deno.serve() で即座に HTTP サーバー起動
  • Deno.openKv() — strongly consistent な KV ストア(FoundationDB ベース)
  • Deno.cron() — コード内で直接 cron を定義
  • Deno.serve() ハンドラから直接キューに enqueue / dequeue
// main.ts
const kv = await Deno.openKv()

Deno.serve(async (req) => {
  const url = new URL(req.url)

  if (url.pathname === '/enqueue') {
    await kv.enqueue({ task: 'send-email', to: 'user@example.com' })
    return new Response('Queued')
  }

  if (url.pathname === '/count') {
    const result = await kv.get<number>(['visits'])
    const next = (result.value ?? 0) + 1
    await kv.atomic().check(result).set(['visits'], next).commit()
    return new Response(`Visits: ${next}`)
  }

  return new Response('Hello from Deno Deploy')
})

// Queue consumer
kv.listenQueue(async (msg: { task: string; to: string }) => {
  console.log('Processing:', msg.task, msg.to)
  // send email...
})

// Cron job — runs every hour
Deno.cron('hourly cleanup', '0 * * * *', async () => {
  await kv.delete(['expired-cache'])
})

Deno Deploy の魅力は 追加インフラなしで小さなフルスタックアプリが完成する点です。Deno + Deno KV + Deno Queues + Deno Cron だけでバックエンドが完結します。Fresh フレームワークや Hono と相性抜群です。

2026年現在の Deno Deploy の弱点は AWS / Cloudflare に比べてリージョン数が少ないこと(35 vs 300+)と、コールドスタートが Workers よりやや遅いことです。

7. Fastly Compute@Edge — WASM ベース

Fastly は最初から WebAssembly(Wasmtime ベース) を選んだ唯一の主要エッジプラットフォームです。名前も 2024 年に単に「Fastly Compute」に短縮されました。WASM の利点:

  • マイクロ秒単位のコールドスタート: V8 isolate より速い 35 マイクロ秒レベル
  • 多言語サポート: Rust、JavaScript、Go(TinyGo)、AssemblyScript、Swift、C/C++
  • V8 isolate より強いサンドボックス: WASI による capability ベースの権限モデル
// Rust on Fastly Compute
use fastly::http::{Method, StatusCode};
use fastly::{Error, Request, Response};

#[fastly::main]
fn main(req: Request) -> Result<Response, Error> {
    match (req.get_method(), req.get_path()) {
        (&Method::GET, "/") => Ok(Response::from_status(StatusCode::OK)
            .with_body_text_plain("Hello from Fastly WASM!")),
        (&Method::POST, "/api/echo") => {
            let body = req.into_body_str();
            Ok(Response::from_status(StatusCode::OK).with_body_text_plain(&body))
        }
        _ => Ok(Response::from_status(StatusCode::NOT_FOUND)),
    }
}

Fastly の強みは CDN との深い統合です。元々 CDN 会社なので、キャッシュ無効化、ESI(Edge Side Includes)、VCL との結合が自然です。メディア、ニュース、e コマースの CDN ワークロードに最適。

弱点は フルスタックビルディングブロックがないことです。KV ストアはありますが、DB、キュー、AI は外部依存。Cloudflare のように一か所で全て完結はできません。

8. Bun on Render / Fly.io / Railway / Coolify

Bun はエッジプラットフォームの一級市民ではありません。正確には ローカル開発 + 通常のコンテナホスティングの組み合わせで強力です。2026年現在、Bun 1.2 が安定版で、Render / Fly.io / Railway / Coolify が一級 Bun サポートを持っています。

// server.ts — Bun 1.2 native HTTP server
const server = Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url)
    if (url.pathname === '/json') {
      return Response.json({ hello: 'world', runtime: 'bun' })
    }
    return new Response('Hello from Bun!')
  },
})
console.log(`Listening on ${server.url}`)

Bun の価値提案:

  • 高速な起動時間: Node.js より 2-3 倍速いコールドスタート
  • バンドラー + トランスパイラー + パッケージマネージャー + テストランナーが統合: bun install、bun build、bun test を一つのツールで
  • Web 標準 API ファースト: fetch、Request、Response がネイティブ
  • Node.js 互換性 95%+: 大抵の npm パッケージが動く

Bun をどこで動かすか?

  • Fly.io: Firecracker microVM ベース、グローバル 30+ リージョン。Bun コンテナをそのままデプロイ可能。WebSocket、永続ボリュームに対応。
  • Render: 単一リージョン中心だが最も簡単なデプロイ体験。Bun ビルドパックが一級。
  • Railway: Render に類似。より強い PaaS の印象。
  • Coolify: セルフホスト PaaS。自前 VPS で Vercel ライクな体験。

Bun + Fly.io が特に人気の理由は Cloudflare Workers の制約(50 ms CPU time、128 MB RAM)を避けながらグローバル分散を維持できる点です。

9. Netlify Edge Functions

Netlify Edge Functions は Deno ランタイムを Netlify インフラ上で実行する形態です。つまりコードモデルは Deno Deploy と同じで、違いはインフラ(Netlify の CDN)+ 統合(Netlify Forms、Identity、Blobs)だけです。

// netlify/edge-functions/geo.ts
import type { Config, Context } from '@netlify/edge-functions'

export default async (req: Request, context: Context) => {
  const country = context.geo.country?.code ?? 'unknown'
  const city = context.geo.city ?? 'unknown'

  return new Response(
    JSON.stringify({ country, city, ip: context.ip }),
    { headers: { 'Content-Type': 'application/json' } }
  )
}

export const config: Config = {
  path: '/api/geo',
}

Netlify は 静的サイトホスティングが本業で、Edge Functions は補助ツールです。SSG + 一部の動的ルートなら Netlify が最速で展開できますが、フルサーバーサイドアプリなら Vercel か Cloudflare のほうが適しています。

10. AWS Lambda SnapStart — コールドスタート問題の解決

Lambda は長らくコールドスタート問題でエッジに後れを取っていました。Java は数秒、Python でも数百 ms が基本でした。2022 年に Java 向けに始まった SnapStart が 2024 年に Python / .NET まで拡張され、2026 年現在はほぼすべてのマネージドランタイムで利用可能になりました。

SnapStart の原理:

  1. 関数が初めてデプロイされたときに一度だけ初期化(Init)を実行
  2. Firecracker microVM のメモリスナップショットを保存(数十 MB)
  3. コールドスタート時にスナップショットを復元 — 初期化ステージをスキップ
  4. 結果: コールドスタートが 50 ms 以下まで下がる(Java で 90% 削減)
# AWS SAM template
Resources:
  MyFunction:
    Type: AWS::Serverless::Function
    Properties:
      Runtime: python3.13
      Handler: app.handler
      CodeUri: ./src
      SnapStart:
        ApplyOn: PublishedVersions

SnapStart の制限:

  • PublishedVersions にのみ適用: $LATEST エイリアスには適用不可。デプロイワークフローが少し複雑に。
  • VPC + ENI 時間は減らない: ネットワーク接続時間は別問題。
  • スナップショット時点の可変状態に注意: 初期化段階で作った DB 接続などはスナップショットに焼き込まれ、復元後は死んだ接続の可能性があります。SDK が提供するフック(beforeCheckpoint / afterRestore)で対処が必要です。

Lambda は SnapStart でコールドスタートをある程度解決しましたが、依然としてリージョン数が約 30 で、真のエッジ(300+ PoP)ではありません。 Lambda@Edge がその役割を担っていましたが、CloudFront に縛られ制約が多く、2026 年には事実上 Cloudflare Workers / Vercel Edge に席を譲りました。

11. Supabase Edge Functions

Supabase Edge Functions は Deno ランタイム + Supabase DB / Auth / Storage の統合です。コードは Deno Deploy とほぼ同じですが、import { createClient } from 'jsr:@supabase/supabase-js' で Supabase リソースに認証付きでアクセスできます。

// supabase/functions/send-welcome/index.ts
import { createClient } from 'jsr:@supabase/supabase-js@2'

Deno.serve(async (req) => {
  const { user_id } = await req.json()

  const supabase = createClient(
    Deno.env.get('SUPABASE_URL')!,
    Deno.env.get('SUPABASE_SERVICE_ROLE_KEY')!
  )

  const { data: profile } = await supabase
    .from('profiles')
    .select('email, name')
    .eq('id', user_id)
    .single()

  // Send email...
  return new Response(JSON.stringify({ ok: true, profile }))
})

デプロイは supabase functions deploy send-welcome の一行。自動的に https://PROJECT.supabase.co/functions/v1/send-welcome エンドポイントができます。

Supabase Edge は 既に Supabase を使っているチームに最適です。DB + Auth + Storage + Realtime + Edge Functions が一つのコンソールにあり、RLS と自動連動します。欠点はリージョンが少なく、Cloudflare ほどの分散ではないことです。

12. WinterCG / WinterTC — クロスプラットフォーム標準

WinterCG は 2022 年に W3C コミュニティグループとして始まり、2025 年に Ecma TC55(WinterTC) に昇格しました。今や ECMA 公式の標準トラックです。目的はシンプルです。

サーバーサイド JavaScript ランタイムが従うべき共通 API サーフェス(Minimum Common API)を定義する。

2026年5月時点で、以下のランタイムが WinterTC Minimum Common API 互換を宣言しています。

  • Cloudflare Workers
  • Deno Deploy / Deno
  • Vercel Edge Runtime
  • Netlify Edge Functions
  • Supabase Edge Functions
  • Bun
  • Fastly Compute(JavaScript SDK)

コア API:

  • fetch、Request、Response、Headers、FormData
  • URL、URLPattern、URLSearchParams
  • TextEncoder、TextDecoder、Blob、File
  • crypto.subtle、crypto.getRandomValues
  • ReadableStream、WritableStream、TransformStream
  • AbortController、AbortSignal
  • console、setTimeout、setInterval、queueMicrotask
  • structuredClone、EventTarget、Event、CustomEvent

実用的な意味: WinterTC API だけを使ったよく書かれたエッジ関数は、5つのプラットフォームで一行も変えずに動きます。フレームワーク(Hono、itty-router、Hattip)はこの標準の上でマルチプラットフォームをサポートします。

// Hono — runs on Cloudflare Workers, Deno Deploy, Vercel Edge, Bun, Node.js
import { Hono } from 'hono'

const app = new Hono()

app.get('/', (c) => c.text('Hello from any edge runtime!'))
app.get('/json', (c) => c.json({ runtime: 'wintertc-compatible' }))
app.post('/echo', async (c) => c.json(await c.req.json()))

export default app
// Cloudflare: export default app
// Deno: Deno.serve(app.fetch)
// Bun: Bun.serve({ port: 3000, fetch: app.fetch })
// Node: serve({ fetch: app.fetch, port: 3000 })

13. 誰が何を選ぶべきか — グローバル / 韓国 / 日本トラフィック

グローバルトラフィック(北米 + 欧州 + アジア均等)

  • 第1位: Cloudflare Workers + R2 + D1 + Workers AI — 300+ PoP、最速のグローバルレスポンス、egress 無料
  • 第2位: Vercel Fluid Compute(Edge + Fluid ハイブリッド) — Next.js 優先、AI/RAG ワークロード最適
  • AI ヘビー: Workers AI + Vectorize + AI Gateway の組み合わせが最も統合度が高い

韓国トラフィック中心

韓国はすべての主要クラウドの KR リージョンがあり選択肢が多いです。

  • フルスタックエッジ: Cloudflare(ソウル PoP あり)または Vercel(icn1)
  • DB が韓国にある必要がある: AWS Seoul(Lambda + RDS)または Supabase Tokyo + Cloudflare キャッシュ
  • レガシー互換 / Linux 必須: AWS Lambda + SnapStart または Fly.io Singapore(韓国から 40-60 ms)
  • 迷うなら: Vercel + Supabase Tokyo が最も手軽なフルスタック

日本トラフィック中心

  • Cloudflare: 東京 PoP は最大級のノードの一つ、日本トラフィックは非常に高速
  • Vercel: nrt1(東京)リージョンが Edge から即応答
  • AWS: ap-northeast-1(東京)Lambda SnapStart が 50 ms 以下のコールドスタート
  • Deno Deploy: 東京リージョンあり、日本語 i18n サイトに適合

ワークロード別クイック選択マトリックス

ワークロードおすすめ
グローバル静的サイト + 一部 APICloudflare Workers + Pages
Next.js フルスタック + AIVercel Fluid Compute
Postgres ヘビー + エッジCloudflare Workers + Hyperdrive
LLM API キャッシング / コスト削減Cloudflare AI Gateway
Deno ファースト、KV で完結できるバックエンドDeno Deploy
WASM 多言語(Rust 等)Fastly Compute
Linux 必須、npm フル互換Bun + Fly.io または Lambda SnapStart
Supabase をすでに使用中Supabase Edge Functions
動画トランスコーディング / ヘッドレスブラウザCloudflare Containers
単一リージョンで OK、最も簡単なデプロイRender または Railway

14. 参考 / References

Discuss on Twitter • View on GitHub