✍️ 필사 모드: モダンバックエンドランタイム 2025 — Node 22·Bun·Deno·WinterJS·Cloudflare Workers·V8 Isolate·Tokio 完全比較 (シーズン7 第1回)

プロローグ — ランタイム戦争の再来

「ランタイム」は昔「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スループット (実戦テストではない)。

注意

• 実アプリは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章. メモリ·コネクションモデル

サーバーレスではメモリが境界。価格とコールドスタートが相関。

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年展望

1. WinterCG収束 — ランタイムがAPIレベルで類似。Nodeに書いたハンドラをBunで書き換えなし。
2. Node vs Bun vs Denoよりサーバ vs エッジisolate vs ネイティブが重要に。
3. WASMコンポーネントでRustモジュールをJSランタイムに差し込む。
4. 永続isolate (Durable Objectsなど) が「リクエストスコープのコンピュート」と「ステートフルサーバ」の境界を曖昧に。
5. Bun Deploy + Elysiaがサードパーティサーバーレスの信頼できる選択肢に。

12項目導入チェックリスト

1. チーム強みがランタイム選択にマップ済み？
2. コールドスタート予算は定義？
3. 観測性は初日から？
4. フレームワーク生態系の成熟度は確認？
5. 認証·バリデーションライブラリは選択ランタイムで利用可能？
6. データベースドライバの品質検証？
7. パッケージマネージャの速度は許容範囲？
8. ローカル開発は本番パリティ？
9. メモリ/CPUコストを規模でモデル化？
10. ベンダーロック評価 (Workers、Deno Deploy)？
11. 離脱経路定義 (移行できるか)？
12. AI/ストリーミングユースケースがネイティブ処理？

よくある間違い10

1. エンタープライズで早すぎるBun採用 — Node互換ギャップが高価。
2. 長実行タスクにWorkersを選択 — CPU制限。
3. 同期コードだらけのFastAPI — 部分async/awaitはデッドロック。
4. チャットストリーミングにLambda — 継続時間制限でUX壊れる。
5. 「なんでもRust」 — 開発速度低下、バグは減らない。
6. NodeとEdgeを互換視 — DBドライバが異なる。
7. Lambdaのプロセス当たりリクエストコスト無視 — プール/fluid computeを使う。
8. 軽量ヘルスチェックなし — ハングしたランタイム検出されず。
9. 高カーディナリティstdoutログ — 観測性料金爆発。
10. ランタイムAPIのハードコード — 後の移行が苦痛。

次回予告

シーズン7 第2回: モダンバックエンドフレームワーク 2025 — NestJS、Fastify、Hono、Elysia、Spring Boot、FastAPI、Go、Axum、APIスタイル (tRPC、GraphQL、gRPC)。どのフレームワーク、どのAPIスタイル、どのチームに。

— モダンバックエンドランタイム編、完。