プロローグ — ランタイム戦争の再来
「ランタイム」は昔「NodeかPythonか」を意味した。2026年では立派な建築判断である: 伝統的なNode/JVM/Python、Bun、Deno、Workers風V8 isolate、ネイティブランタイム (Go、Rust/Tokio)。それぞれ違う問題を解く。
1章. Node 22 — 「大人のNode」
Node 22 (2024末にLTS) は新プラットフォームと感じる機能を搭載。
- 権限モデル (
--permission --allow-fs-read=./data) — Nodeプロセスをサンドボックス化。 - ネイティブTypeScript (
--experimental-strip-types、Node 23+で安定)。 - 組み込みテストランナー成熟。
- 性能 — V8 13.x、改善されたストリーム。
- Fetch, WebSocket, Blob, FormData — 標準グローバル。
用途: 既存Node生態系、安定LTS、長寿命サービス。
2章. Bun 1.1+ — ツールチェーン統合ランタイム
Bunは「ランタイム兼ツールチェーン」を名乗る: パッケージマネージャ、バンドラ、テストランナー、SQLite、JSX、TS — すべて組み込み。
要点
- V8でなくJavaScriptCoreエンジン (WebKit由来)。
- Bun.serve() — JS界最速のHTTPサーバ。
- ネイティブSQLite·Postgresドライバ。
bun install— npm/yarn比一桁速い。bun test— Jest互換。- 2025: S3ネイティブ、マクロ、Node互換改善。
用途: 新規プロジェクト、スループット重視の小サービス、ツールを減らしたいモノレポ。 注意: Node互換の端境事例に今も噛まれる。
3章. Deno — リセット
Denoは元々「Nodeだがセキュア、TS標準」。純TS/URLインポート路線はnpmの引力に負けた。Deno 2 (2024末) でnpmに舵を切る: node_modules対応、deno.jsonはpackage.json互換、完全なnpmレジストリ。
- 権限は今も第一級 (
--allow-net)。 - Fresh、Deno KV、Deno Deploy。
jsr.io— Denoの答え、TS型が良好。
用途: TSファーストで設定ファイルを減らしたい、Deno Deployを狙う。
4章. Cloudflare Workers — プロセスではなくIsolate
設計上の洞察: 多テナントを単一V8プロセス内のisolateで動かし、メモリ/コンパイルキャッシュを共有する。コールドスタートが秒ではなくマイクロ秒。
- 制限 (2025): ~30s CPU、128MBメモリ、Node API非対応 (ただしnodejs_compat拡大)。
- ストレージ: Workers KV (eventual)、Durable Objects (一貫状態)、R2、D1 (SQLite)、Queues。
- Node互換:
nodejs_compatフラグ +bun-compatモードで2025年にはほとんどの生態系が動く。 - Workers for Platforms: テナント当たりWorkerを大規模に。
用途: グローバル低レイテンシ、API集約、認証ミドルウェア、エッジロジック。
5章. Vercel Functions & Edge — 実用的なペア
Vercelは2レーン: Node.js Functions (裏はLambda) とEdge Functions (Workers互換ランタイム)。
- Edge: コールドスタート ~0、制限はWorkersに類似。
- Node Functions: 完全なNode生態系、Lambdaコールドスタートのトレードオフ。
- Fluid Compute (2025): ハイブリッド — Node Functionsがisolate的に並行リクエストをプール。大きな性能改善。
用途: Next.jsで出荷、レイテンシ/生態系のハイブリッドトレードオフ。
6章. Deno Deploy / WinterJS / Fastly Compute — 同僚
- Deno Deploy: V8 isolate + Deno API、Deno中心チーム向け。
- WinterJS: Wasmer製Rust基盤のJSランタイム、WinterCG標準に注力。
- Fastly Compute: Wasm基盤、多言語 (Rust、Go、JS、AssemblyScript)。
WinterCG標準化がランタイムを入れ替え可能に感じさせる理由 — APIが収束している。
7章. 非JS側 — Go, Rust/Tokio, Python
Go
- 速いランタイム、goroutine、net/http 1.22+はネイティブルーティング。
- 小バイナリ、簡単デプロイ。
- スイートスポット: 運用のシンプルさが重要なバックエンド。
Rust + Tokio
- 最速 + 最もメモリ効率。
- 生態系 (Axum、Tower) が成熟。
- 用途: 性能クリティカル、WASMターゲット、WASM付きエッジコンピュート。
- トレードオフ: コンパイル時間と学習曲線。
Python (3.13)
- フリースレッド (No-GIL) ビルドは実験的 — 本番にはまだ。
- FastAPI、Litestarは今も優秀。
- ベスト: AI/ML隣接、ラピッドプロト、Djangoレガシー。
8章. ベンチマークの現実 (2025年相当)
単一コア、ローカル機でのおおよその「hello world」HTTPスループット (実戦テストではない)。
| Runtime | req/s (目安) |
|---|---|
| Rust Axum | 600k+ |
| Go net/http | 250–400k |
| Bun.serve | 200–300k |
| Node 22 (uWebSockets) | 150–250k |
| Node 22 (stock http) | 70–120k |
| FastAPI (uvicorn) | 30–60k |
注意
- 実アプリはhello worldではない。DB·JSON·認証が支配。
- 短命関数ではコールドスタートが支配 — そこはWorkers/Isolateが他を圧倒。
- 実本番では接続当たりメモリが生req/sより重要。
9章. ストリーミングとSSE — AI時代の現実
AI API (OpenAI、Anthropic) は応答をストリーム。バックエンドは:
- ストリーミング上流を開く (SSEまたはchunked HTTP)。
- バッファリングなしでトークンをFEへ。
- クライアント切断時に上流を中断。
うまく動くもの
- Hono/Bun — ネイティブ
ReadableStreamパイプライン。 - FastAPI +
StreamingResponse。 - Cloudflare Workers — 優れたSSE、用途に合う設計。
- Node 22の
fetch+res.write。
注意
- サーバーレスFunctions (非Edge) は継続時間制限 — 長ストリームに不向き。
- APIゲートウェイがバッファする可能性 (API Gateway v1、特定設定のないCloudFront)。
10章. ランタイム層の観測性
- Node 22は
--inspectと改善されたperf hooks。 - BunはOTel統合を2025年に出荷。
- WorkersはTail Workers + Logpushで観測性。
- Rust/Tokio:
tracingクレートが既定。 - FastAPI: OpenTelemetry Python SDK、Datadog/Honeycomb連携。
ルール: フレームワーク層でトレース、システム層でメトリクス、プロセス層でログ。OpenTelemetryが結合組織。
11章. メモリ·コネクションモデル
| Runtime | 並行性 | 10k req/s時メモリ |
|---|---|---|
| Rust Tokio | 非同期タスク | ~50MB |
| Go | goroutine | ~80MB |
| Bun | JSイベントループ | ~120MB |
| Node 22 | JSイベントループ | ~160MB |
| Node + Workersプール | 複数プロセス | ~500MB |
| FastAPI (uvicorn) | 非同期 | ~200MB |
サーバーレスではメモリが境界。価格とコールドスタートが相関。
12章. 意思決定ツリー
Q1: 超低グローバルレイテンシ？
├─ はい: Cloudflare Workers, Vercel Edge, Deno Deploy
└─ いいえ → Q2
Q2: 生性能 / メモリが重要？
├─ はい: Rust (Axum), Go
└─ いいえ → Q3
Q3: TSチーム、モダンツールチェーン希望？
├─ はい: Bun + Elysia/Hono, or Node 22 + Hono/Fastify
└─ いいえ → Q4
Q4: Pythonデータ/AI隣接？
├─ はい: FastAPI (async Python)
└─ いいえ → Node 22 LTS + NestJS/Fastify
13章. 2026年展望
- WinterCG収束 — ランタイムがAPIレベルで類似。Nodeに書いたハンドラをBunで書き換えなし。
- Node vs Bun vs Denoよりサーバ vs エッジisolate vs ネイティブが重要に。
- WASMコンポーネントでRustモジュールをJSランタイムに差し込む。
- 永続isolate (Durable Objectsなど) が「リクエストスコープのコンピュート」と「ステートフルサーバ」の境界を曖昧に。
- Bun Deploy + Elysiaがサードパーティサーバーレスの信頼できる選択肢に。
12項目導入チェックリスト
- チーム強みがランタイム選択にマップ済み？
- コールドスタート予算は定義？
- 観測性は初日から？
- フレームワーク生態系の成熟度は確認？
- 認証·バリデーションライブラリは選択ランタイムで利用可能？
- データベースドライバの品質検証？
- パッケージマネージャの速度は許容範囲？
- ローカル開発は本番パリティ？
- メモリ/CPUコストを規模でモデル化？
- ベンダーロック評価 (Workers、Deno Deploy)？
- 離脱経路定義 (移行できるか)？
- AI/ストリーミングユースケースがネイティブ処理？
よくある間違い10
- エンタープライズで早すぎるBun採用 — Node互換ギャップが高価。
- 長実行タスクにWorkersを選択 — CPU制限。
- 同期コードだらけのFastAPI — 部分async/awaitはデッドロック。
- チャットストリーミングにLambda — 継続時間制限でUX壊れる。
- 「なんでもRust」 — 開発速度低下、バグは減らない。
- NodeとEdgeを互換視 — DBドライバが異なる。
- Lambdaのプロセス当たりリクエストコスト無視 — プール/fluid computeを使う。
- 軽量ヘルスチェックなし — ハングしたランタイム検出されず。
- 高カーディナリティstdoutログ — 観測性料金爆発。
- ランタイムAPIのハードコード — 後の移行が苦痛。
次回予告
シーズン7 第2回: モダンバックエンドフレームワーク 2025 — NestJS、Fastify、Hono、Elysia、Spring Boot、FastAPI、Go、Axum、APIスタイル (tRPC、GraphQL、gRPC)。どのフレームワーク、どのAPIスタイル、どのチームに。
— モダンバックエンドランタイム編、完。