Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに — 2026年5月、サーバレスは「ただのインフラ」になった

2020年のサーバレスは「機能検証用 PoC ツール」、2023年は「MAU100万くらいまでなら無難」だった。2026年5月現在、サーバレスとエッジランタイムはもはや傍流の選択肢ではない。Coupang のスパイク吸収、Toss の決済後処理、LY(LINE Yahoo)の通知ファンアウト、Mercari の検索バックエンドの一部、Sansan の名刺 OCR 後処理 — 日韓を代表するサービスが Lambda、Cloud Run、Workers を本番トラフィックの一部として運用している。

この記事はマーケティング比較表ではない。2026年5月時点で **各プラットフォームが本当に向いているワークロードは何か**、コールドスタートはどこまで解決したか、WebSocket とストリーミングはどこまで動くか、価格は何で決まるか、を実コードと合わせて並べる。

サーバレス vs エッジ — 2026年の二軸を整理し直す

まず用語を分離する。2026年時点の「サーバレス」は実質3つのレーンに分かれる。

1. **リージョン・サーバレス**:AWS Lambda、Google Cloud Functions / Cloud Run、Azure Functions / Container Apps。単一リージョンでコンテナか microVM を借りるモデル。

2. **エッジランタイム**:Cloudflare Workers、Vercel Edge、Netlify Edge、Deno Deploy、Fastly Compute@Edge、Akamai EdgeWorkers。PoP 単位で分散される V8 isolate または Wasm ランタイム。

3. **コンテナ PaaS(サーバレスコンテナ)**:AWS App Runner、Google Cloud Run、Fly.io、Railway、Render、Koyeb、Northflank。「Dockerfile を投げれば動かす」に近いモデル。

3つのレーンはそれぞれ違う限界を持つ。Lambda は15分タイムアウト、Workers は CPU 時間30秒(有料プランで最大5分)、Cloud Run は最大60分リクエスト、Fly.io は実質フル VM。だから「サーバレス1つで全部やる」は嘘だ。2026年の正解は、それぞれのワークロードに合う場所に合う道具を置くことである。

コールドスタートはほぼ解決した — 2026年の実測値

コールドスタートは2019年からサーバレス最大の弱点とされてきた。2026年5月現在、この弱点はほぼ消えている。

- **AWS Lambda SnapStart**:Java/.NET/Python 3.12 以降で GA。Firecracker スナップショットを事前に作っておき復元するため、Java 関数のコールドが1〜2秒から100〜300ms に落ちる。

- **Cloudflare Workers**:V8 isolate モデルでコールドスタートは事実上ゼロ(通常5ms 未満)。

- **Cloud Run**:min-instances 設定が標準化。0 インスタンスからは1〜3秒、min-instances=1 なら実質ウォーム。

- **Vercel Fluid Compute**:同じインスタンスで複数リクエストを同時処理し、コールドの頻度自体を減らした。

- **Fermyon Spin**:Wasm モジュールのインスタンス化が約1ms。「コールド」という概念がほぼ意味を持たない。

プラットフォーム別の P50 コールドスタート(2026年5月実測):

| --- | --- | --- | --- |

| AWS Lambda | Node.js 20 | 180ms | 450ms |

| AWS Lambda | Python 3.12 | 220ms | 500ms |

| AWS Lambda + SnapStart | Java 21 | 130ms | 280ms |

| Cloud Run (min=0) | Go/Node | 900ms | 2.5s |

| Cloud Run (min=1) | Go/Node | 5ms | 30ms |

| Cloudflare Workers | V8 isolate | 3ms | 15ms |

| Vercel Edge | V8 isolate | 5ms | 25ms |

| Deno Deploy | V8 isolate | 7ms | 30ms |

| Fastly Compute@Edge | Wasm | 35μs | 200μs |

| Fermyon Spin | Wasm | 1ms | 5ms |

「コールドスタートのせいでサーバレスは使えない」という2019年の主張は、2026年にはほぼ嘘である。

AWS Lambda — 依然デフォルト、そして2026年の新機能

Lambda は2014年に登場し、2026年も依然としてサーバレスのデフォルトだ。ただし2024〜2026年の間に意味のある変化があった。

- **Lambda SnapStart**:前述の Firecracker スナップショット復元。2026年5月時点で Java、.NET、Python 3.12 以降が GA。Node.js はベータ。

- **Lambda Web Adapter**:Express/Fastify/Hono/Spring/Flask など標準 HTTP サーバーをそのまま Lambda に載せる。実質コンテナイメージでのデプロイ。

- **Lambda Powertools**:AWS 公式ミドルウェアライブラリ。ロギング、トレーシング、メトリクス、idempotency、parameter store を一括提供。

- **Lambda Layers**:共通依存を分離。2026年でもモノレポで有用。

- **Lambda Function URL + RESPONSE_STREAM**:API Gateway なしで直接 HTTP。レスポンス・ストリーミングにより LLM トークン・ストリーミングが可能。

典型的な2026年スタイルの Lambda ハンドラ(Node.js、Powertools):

const logger = new Logger({ serviceName: 'orders-api' })

const tracer = new Tracer({ serviceName: 'orders-api' })

const metrics = new Metrics({ namespace: 'orders', serviceName: 'orders-api' })

const handler = async (event: any) => {

logger.info('received order', { orderId: event.orderId })

metrics.addMetric('OrderReceived', MetricUnit.Count, 1)

return { statusCode: 200, body: JSON.stringify({ ok: true }) }

}

export const main = middy(handler)

.use(injectLambdaContext(logger))

.use(captureLambdaHandler(tracer))

.use(logMetrics(metrics))

Python では次のように書く。

from aws_lambda_powertools import Logger, Tracer, Metrics

from aws_lambda_powertools.metrics import MetricUnit

from aws_lambda_powertools.utilities.typing import LambdaContext

logger = Logger(service="orders-api")

tracer = Tracer(service="orders-api")

metrics = Metrics(namespace="orders", service="orders-api")

@logger.inject_lambda_context

@tracer.capture_lambda_handler

@metrics.log_metrics

def handler(event: dict, context: LambdaContext):

logger.info("received order", extra={"order_id": event.get("orderId")})

metrics.add_metric(name="OrderReceived", unit=MetricUnit.Count, value=1)

return {"statusCode": 200, "body": '{"ok": true}'}

Lambda の限界は今も同じだ。最大15分、メモリ10GB、/tmp 10GB、デフォルト同時実行1000。15分を超えるジョブは Step Functions で細分化するか、Fargate/Batch に渡す。

AWS Fargate vs App Runner — Lambda で解けない場所

Lambda が窮屈なワークロードは2つ。1つ目は15分超のバッチ。2つ目は永続接続(WebSocket プール、gRPC サーバー)が必要なケース。AWS はこのスロットに2つの答えを用意する。

- **AWS Fargate**:ECS あるいは EKS のコンピュート・バックエンド。「マネージド・コンテナ・ホスティング」の王道。cluster、task definition、service は運用者が直接面倒を見る。

- **AWS App Runner**:コンテナイメージか GitHub リポを渡すだけで、ビルド・デプロイ・HTTPS・オートスケールまで自動でやる。Cloud Run に最も近い AWS サービス。

App Runner は2024年に ALB 統合と VPC Connector を強化し、Cloud Run との差をかなり縮めた。ただしリージョン数と価格では Cloud Run の方が一歩前という評価が多い。

Google Cloud Run — 「コンテナ・サーバレス」の事実上の標準

Cloud Run は2019年 GA 以降、コンテナ・サーバレスのデフォルトになった。2026年5月時点の強みは:

- **リクエストタイムアウト最大60分**(Lambda の4倍)。

- **CPU always-on** オプションでバックグラウンド処理(Pub/Sub 非同期、WebSocket fan-out)が可能。

- **min-instances** でコールドスタートを実質ゼロ化。

- **GCS、Pub/Sub、Cloud Tasks、Eventarc** とネイティブ連携。

- **HTTP/2、gRPC、WebSocket** すべて対応。

典型的な Cloud Run サービス定義:

apiVersion: serving.knative.dev/v1

kind: Service

metadata:

name: orders-api

annotations:

run.googleapis.com/launch-stage: GA

spec:

template:

metadata:

annotations:

autoscaling.knative.dev/minScale: "1"

autoscaling.knative.dev/maxScale: "200"

run.googleapis.com/cpu-throttling: "false"

spec:

containerConcurrency: 80

timeoutSeconds: 900

containers:

- image: gcr.io/myproj/orders-api:2026.05

resources:

limits:

cpu: "2"

memory: 1Gi

env:

- name: DATABASE_URL

valueFrom:

secretKeyRef:

name: db-url

key: latest

Mercari は2022年から検索バックエンドの一部を Cloud Run に移しており、韓国では Toss の一部決済後処理が Cloud Run で動くと言われている(ミートアップ発表ベース)。

Cloud Functions 2nd gen — Cloud Run の上に乗った関数モデル

Cloud Functions 2nd gen は実質、Cloud Run の上に抽象化された関数ランタイムである。したがって60分タイムアウト、コンテナ同時実行、Eventarc 統合をそのまま継承する。1st gen 関数も2026年5月時点で互換モードとして残るが、新規コードは 2nd gen がデフォルトだ。

Azure Functions + Container Apps — そして Durable Functions

Azure 側も2つのレーンに分かれる。

- **Azure Functions**:Consumption / Premium / Dedicated プラン。Consumption は Lambda 同様の従量制、Premium はコールドスタート除去用。

- **Azure Container Apps**:KEDA ベースのコンテナ・サーバレス。Dapr 連携が強み。Cloud Run と直接競合。

Durable Functions は Azure の特長だ。C#/JS/Python でオーケストレーション・ワークフローをコードとして書き、Azure がチェックポイントとリトライを管理する。AWS Step Functions をコード親和的にしたモデル、と捉えればよい。

Cloudflare Workers — V8 isolate という別次元

Workers は他のサーバレスと根本的に違う。コンテナでも microVM でもなく、**V8 isolate** を使う。同一プロセス内に複数ユーザーのコードを分離して動かすので、コールドスタートはほぼゼロ、デプロイは300以上の PoP に自動配信される。

2026年5月時点の Workers 生態系は以下のとおり:

- **Workers**:V8 isolate ベースの関数。

- **Workers AI**:GPU 上で LLaMA、Mistral、Whisper、BGE 埋め込みなどの OSS モデルを実行。リクエスト単位の課金。

- **R2**:S3 互換オブジェクトストレージ。下り無料。

- **KV**:グローバル分散 key-value。結果整合性、60秒の読み取りキャッシュ。

- **D1**:SQLite ベースの分散 DB。2024年からマルチリージョン読み取りに対応。

- **Durable Objects**:状態を持つオブジェクト。1オブジェクトにつき単一インスタンスが保証されるため、WebSocket fan-out、カウンター、レートリミットに自然。

- **Queues**:at-least-once メッセージキュー。

- **Vectorize**:ベクター DB。RAG 用途。

- **Pages Functions**:Pages サイトの隣で動く Workers。

典型的な Worker コード:

export interface Env {

ORDERS_KV: KVNamespace

DB: D1Database

AI: Ai

}

export default {

async fetch(req: Request, env: Env): Promise<Response> {

const url = new URL(req.url)

if (url.pathname === '/embed' && req.method === 'POST') {

const { text } = await req.json<{ text: string }>()

const out = await env.AI.run('@cf/baai/bge-base-en-v1.5', { text: [text] })

return Response.json({ embedding: out.data[0] })

}

if (url.pathname.startsWith('/orders/')) {

const id = url.pathname.split('/')[2]

const cached = await env.ORDERS_KV.get(id, 'json')

if (cached) return Response.json(cached)

const row = await env.DB.prepare('SELECT * FROM orders WHERE id = ?').bind(id).first()

if (row) await env.ORDERS_KV.put(id, JSON.stringify(row), { expirationTtl: 60 })

return row ? Response.json(row) : new Response('not found', { status: 404 })

}

return new Response('ok')

}

Workers にも限界は明確にある。CPU 時間デフォルト30秒(有料プラン5分)、メモリ128MB、Node.js 互換モードはあるが一部 npm パッケージは動かない。そして KV は結果整合性なので、「書いた直後の値がすぐ見えないことがある」点は常に頭に入れておく。

Cloudflare D1 マルチリージョン — 2026年にようやく実用的

D1 は SQLite を分散システム化したものだ。2024年に read replicas が追加され、2025年に multi-region writes ベータが開き、2026年5月時点でグローバル読み取り整合性と単一リージョン書き込みモデルとして安定した。Coupang のような韓国・東南アジア同時運用に興味深い選択肢になったが、強整合性が必要な決済・財務は依然として RDS や Spanner の方が安全だ。

Deno Deploy — Workers の Web 標準寄り版

Deno Deploy は Cloudflare Workers と非常に似たモデル(V8 isolate、グローバルエッジ)だが、Deno ランタイム上で動くので、ES モジュール、ネイティブ TypeScript、Web Standard API(fetch、Request、Response、WebSocket)に忠実だ。

Deno.serve((req: Request) => {

const url = new URL(req.url)

if (url.pathname === '/hello') {

return new Response(JSON.stringify({ hello: 'world' }), {

headers: { 'content-type': 'application/json' },

})

}

return new Response('not found', { status: 404 })

})

2024年に Deno KV が GA、2025年に Deno Queues が追加された。Deno1ファイルでフルスタック・サーバレス・バックエンドが書ける、というのが大きな変化だ。

Bun Edge — 2026年の新顔

Bun は2024年に1.0 GA した JS ランタイムで、2025年末から Bun Edge というホスティングサービスをベータ運用している。Cloudflare Workers / Deno Deploy と同じスロットだが、Bun が持つ ONNX、TensorRT 連携でエッジ ML 推論に強い。2026年5月時点ではまだベータなので、本番のマルチテナント配備は慎重に。

Vercel Functions / Edge / Fluid Compute — Next.js のデフォルト

Vercel は Next.js ユーザーにとって実質デフォルトのデプロイ先だ。2026年5月時点で次の3モードがある。

- **Vercel Functions**:AWS Lambda の上の抽象。Node.js 関数。

- **Vercel Edge Functions / Edge Middleware**:Cloudflare Workers に近いエッジ isolate。

- **Vercel Fluid Compute**:2024年末に導入。同一インスタンスが複数の同時リクエストを受け、コールドスタートと idle コストを同時に下げる。

Fluid Compute は特に「Next.js サーバーコンポーネントが外部 API を待つ間、同じ Lambda が別のリクエストも捌く」というシナリオで効く。AI チャットボットのように I/O 待ちが長いワークロードに直接効果がある。

Netlify Edge / Background Functions — Deno に乗ったエッジ

Netlify Edge Functions はバックエンドに Deno ランタイムを採用する。だから URL import、ネイティブ TypeScript、Web Standard API が自然だ。Netlify Functions(非エッジ)は AWS Lambda の上で動き、Background Functions として15分の非同期ジョブもサポートする。

export default async (req: Request, ctx: Context) => {

const country = ctx.geo?.country?.code ?? 'JP'

return new Response(JSON.stringify({ country }), {

headers: { 'content-type': 'application/json' },

})

}

Fastly Compute@Edge — Wasm でいくもう一つの道

Fastly Compute@Edge は V8 isolate ではなく **WebAssembly** を使う。だから Rust、AssemblyScript、Go(TinyGo)、JavaScript(SpiderMonkey on Wasm)が全部走る。コールドスタートはマイクロ秒オーダーだ。

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("hello edge")),

_ => Ok(Response::from_status(StatusCode::NOT_FOUND).with_body("not found")),

}

Wasm Component Model が2024〜2025年に標準化され、「一度ビルドすればどこでも動く」という約束はますます現実に近づいている。

Akamai EdgeWorkers — 伝統 CDN のエッジ関数

Akamai は伝統的な CDN ベンダーだが、EdgeWorkers という名で独自のエッジ関数ランタイムを動かしている。V8 ベースで、レスポンス変換、A/B テスト、トークン検証など CDN 親和的なワークロードに最適化されている。Cloudflare Workers のようにフルバックエンドを書くより、CDN 前段の軽量ロジックという用途が多い。

Fermyon Spin — Wasm ネイティブ・サーバレス

Fermyon Spin は Wasm ネイティブ・サーバレスの代表選手だ。関数単位の Wasm コンポーネントを作って配備する。コールドスタートは約1ms、ポリグロット(Rust、Go、JS、Python、.NET)を全部サポートする。

spin_manifest_version = 2

[application]

name = "orders-api"

version = "0.1.0"

[[trigger.http]]

route = "/orders/..."

component = "orders"

[component.orders]

source = "target/wasm32-wasi/release/orders.wasm"

allowed_outbound_hosts = ["https://api.stripe.com"]

[component.orders.build]

command = "cargo build --target wasm32-wasi --release"

Spin は Spin Cloud、Fermyon Cloud、Kubernetes 上の SpinKube でほぼ同様に動く。2026年時点で Lambda / Cloud Run ほどの認知はないが、Wasm Component Model を最も真剣に推進するプレイヤーだ。

Fly.io — Firecracker で作る「エッジのフル VM」

Fly.io は他のエッジプラットフォームとは違う。Firecracker microVM を世界30以上のリージョンに敷き、ユーザーの Dockerfile をその上で丸ごと動かす。すなわち **「エッジに近い本物のコンテナ」** を運用するモデルだ。WebSocket、TCP、UDP、永続ディスク(Fly Volumes)、Postgres クラスタまで自前で運用できる。

app = "orders-api"

primary_region = "nrt"

[build]

image = "ghcr.io/myorg/orders-api:2026.05"

[http_service]

internal_port = 3000

force_https = true

auto_stop_machines = true

auto_start_machines = true

min_machines_running = 1

[[vm]]

cpu_kind = "shared"

cpus = 1

memory_mb = 512

韓国・日本のトラフィックが多いなら `nrt`(東京)、`kix`(大阪)リージョンを置くのが自然だ。Cloud Run よりも永続接続と状態管理で柔軟。

Railway / Render / Koyeb / Northflank — 「GitHub プッシュでデプロイ」の新世代

この4プラットフォームはすべて「GitHub リポ接続 → 自動ビルド/デプロイ」の PaaS だ。

- **Railway**:最速のスタート。Postgres、Redis、Mongo を1クリックで追加できる。価格は従量制。

- **Render**:Heroku の正統な後継ポジション。Static sites、services、cron jobs、workers を1つの UI で。

- **Koyeb**:グローバルエッジにコンテナを配備する。Fly.io に近いモデルだが UX は Railway 寄り。

- **Northflank**:マルチクラウド(BYOC、自前クラスタ持ち込み)対応が差別化点。ややエンタープライズ寄り。

2026年時点で Heroku を離れたユーザーが一番多く着地しているのが Railway と Render だ。

コールドスタートをもう一度 — SnapStart はどう動いているか

Lambda SnapStart は単なるメモリキャッシュではない。関数の初期化完了直後に Firecracker microVM のメモリページをスナップショットとして保存し、コールドリクエスト時にそのスナップショットを新しい microVM に復元する。JVM や CLR のように初期化が重いランタイムで特に効く。注意点が1つある。スナップショットにメモリ状態が丸ごと入るので、「関数開始時に作ったデータベース接続がそのまま入る」点には気を付ける(復元後に接続が切れている可能性がある)。

WebSocket とストリーミング — どこまでできるか

サーバレスでの WebSocket と SSE の扱いは2026年も依然として難しい場所だ。

- **AWS Lambda**:普通の関数は WebSocket を受け取れない。API Gateway WebSocket と組み合わせる。Function URL の RESPONSE_STREAM モードで SSE / ストリーミングは可能。

- **Cloud Run**:HTTP/2 + WebSocket を正式サポート。60分リクエスト上限内で永続接続が可能。

- **Cloudflare Workers**:WebSocket を正式サポート。Durable Objects と組めば fan-out パターンも自然。

- **Vercel Edge**:SSE ストリーミングは良好、WebSocket は2024年に正式対応。

- **Fly.io**:フル TCP なので WebSocket、gRPC、UDP まで自由。

要するに「エッジで WebSocket プールを受ける」なら Cloudflare Workers + Durable Objects あるいは Fly.io が第一候補。

価格モデル — 何で課金されるのか

サーバレス価格は大きくいくつかのモデルに分かれる。

1. **リクエスト + 実行時間(GB-second)**:AWS Lambda、Cloud Functions、Azure Functions。

2. **リクエスト + CPU 時間(リクエスト単位)**:Cloudflare Workers、Vercel Functions。

3. **コンテナ実行時間(vCPU 秒 + メモリ秒)**:Cloud Run、App Runner、Container Apps。

4. **VM 実行時間(分単位)**:Fly.io、Railway、Render。

2026年5月時点のおおよその単価。正確な数値は各社の価格ページを参照。

{

"aws_lambda": { "per_million_requests": "$0.20", "per_gb_second": "$0.0000166667" },

"cloud_run": { "per_million_requests": "$0.40", "per_vcpu_second": "$0.000024", "per_gib_second": "$0.0000025" },

"cloudflare_workers": { "per_million_requests": "$0.30 paid", "first_10m_free": true, "per_million_duration_ms": "$0.02" },

"vercel_pro_functions": { "included_gb_hours": "1000", "overage_gb_hour": "$0.18" },

"fly_io_shared_1x_cpu": { "per_month": "~$1.94", "memory_256mb_month": "~$0.50" }

}

ここで1つトリックがある。Cloudflare Workers は「CPU 時間」だけを数え、I/O 待ち時間は課金しない。外部 API を待つ LLM チャットボットワークロードに非常に有利だ。

エッジ ML 推論 — 2026年の新スロット

エッジで ML 推論を動かす流れが2024〜2026年に本格化した。

- **Cloudflare Workers AI**:LLaMA 3、Mistral、Whisper、BGE 埋め込み、Stable Diffusion など30以上のモデルをグローバル GPU 上で呼び出す。リクエスト単位課金。

- **Vercel AI SDK**:OpenAI、Anthropic、Google、Cohere、ローカルモデルまで単一 API で呼び出す。ストリーミング、ツール呼び出し、RSC 統合。

- **Bun + ONNX Runtime**:Bun Edge で ONNX モデルを直接推論。埋め込み、分類、OCR に最適。

エッジで推論を回せば、ユーザーに近い場所でトークンを生成し、同じエッジからそのままストリーミングできる。P50 の最初のトークンの遅延を100ms 以下に抑えやすい。

韓国事例 — Toss、Coupang のサーバレス利用断面

韓国でサーバレスがどう使われているか、公開された情報を整理する。

- **Toss**:決済後処理(レシート送信、精算通知、不正取引フック)の一部を AWS Lambda で運用。0 から1000 RPS まで秒単位で跳ねるワークロードに合う。

- **Coupang**:Black Friday 級スパイクトラフィックの吸収に Lambda を補助コンピュートとして使用。メインは ECS/EKS だが、非同期処理は SQS + Lambda パターン。

- **KakaoBank / LINE Bank**:社内ツール、通知、バッチ処理にサーバレス。中核の決済は依然コンテナベース。

共通点は「0 → 1000 のスパイクが頻発する場所」でサーバレスを使うこと。

日本事例 — LY Yahoo、Mercari、Sansan

日本側は公開資料がより多い。

- **LY(LINE Yahoo)**:メッセージ後処理、通知ルーティング、一部 LINE Mini App バックエンドに AWS Lambda と Cloud Functions を併用。

- **Mercari**:検索・推薦バックエンドの一部を Cloud Run で運用。Go サービスが主力で、コンテナ同時実行と Cloud Tasks 非同期呼び出しパターンが標準。

- **Sansan**:名刺 OCR 後処理ワークフローに Cloud Run + Cloud Tasks。Functions 2nd gen も一部使用。

3社とも「メインシステムの隣で非同期/スパイクワークロードを受け持つ場所」にサーバレスを置く。

一度ビルド、どこでも実行 — 2026年の実進捗

「Build once, run everywhere」は Wasm Component Model(WIT / WASI Preview 2)の約束だ。2026年5月時点で次が実質可能。

- Fermyon Spin の Wasm コンポーネントは Fastly Compute@Edge、Spin Cloud、SpinKube でほぼ同一に動く。

- Cloudflare Workers は一部 Wasm ランタイムを支援するが、isolate モデルと100%互換ではない。

- Vercel Edge / Netlify Edge は V8 isolate がバックエンドなので Wasm は補助手段。

「本当に一度ビルドして全クラウドで動く関数」はまだ100%ではないが、それに最も近い形が Wasm Component Model の上に収束しつつある。

プラットフォーム比較マトリクス — 2026年5月時点

| --- | --- | --- | --- | --- | --- | --- |

| Azure Functions | 多様 | コンテナ | 60分 | 14GB | 60以上のリージョン | リクエスト + GB-sec |

| Railway | コンテナ | KVM | 無制限 | 32GB | 4以上のリージョン | 時間 + GB-RAM |

サーバレスを選んではいけない場所

最後に、2026年でもサーバレスが答えにならない場所は明確にある。

- **高持続 GPU 推論**:モデルロードに数十秒かかる LLM。専用 GPU インスタンスや SageMaker、Modal、Replicate の方が向く。

- **長期永続接続 + 状態**:大規模マルチプレイヤーゲームサーバー。Fly.io か EC2/GKE の方が自然。

- **数十 ms 以下の末端遅延が一定で必要な取引システム**:取引所、広告入札。ベアメタルか dedicated。

- **数十 GB メモリで回す分析/結合**:Lambda 10GB では不足。Fargate / EKS。

サーバレスは「使うべき場所」が明確になった分、「使うべきでない場所」も明確になった。

References

- AWS Lambda 公式ドキュメント: https://docs.aws.amazon.com/lambda

- AWS Lambda Powertools: https://docs.powertools.aws.dev

- Google Cloud Run ドキュメント: https://cloud.google.com/run/docs

- Azure Functions ドキュメント: https://learn.microsoft.com/azure/azure-functions

- Cloudflare Workers ドキュメント: https://developers.cloudflare.com/workers

- Deno Deploy ドキュメント: https://docs.deno.com/deploy

- Vercel Functions ドキュメント: https://vercel.com/docs/functions

- Netlify Edge Functions: https://docs.netlify.com/edge-functions/overview

- Fastly Compute@Edge: https://developer.fastly.com/learning/compute

- Fermyon Spin: https://developer.fermyon.com/spin

- Fly.io ドキュメント: https://fly.io/docs

- Railway ドキュメント: https://docs.railway.app

- Render ドキュメント: https://render.com/docs

- Koyeb ドキュメント: https://www.koyeb.com/docs