필사 모드: Node.js & Bun & Deno バックエンドフレームワーク 2026 完全ガイド — Hono · Fastify · Express 5 · NestJS 11 · Elysia · tRPC · Encore TS · h3 · Effect 徹底解剖

プロローグ — 「Node を知っていればバックエンドは終わり」の時代は終わった

2018年頃、誰かが「JavaScript でバックエンドを書く」と言えば、迷う余地なく Node.js + Express だった。2026年に同じ言葉を聞けば、最低でも7つは聞き返す。「ランタイムは? Node 22 LTS? 24? Bun? Deno? エッジ? オリジン? Hono? Fastify? ORM は Prisma? Drizzle? tRPC を挟む? Encore TS のようなインフラ一体型に行く? Effect まで使う?」答えによってアーキテクチャは完全に分岐する。

本稿は2026年5月時点における Node.js · Bun · Deno バックエンドフレームワークのエコシステムの地図を描く。ランタイムの違いからフレームワーク比較、ORM とバリデーションライブラリ、キューとワーカー、認証、ロギング、WebSocket、クラウドデプロイまで全体を見渡す。最後に Toss · Coupang · KakaoPay · Mercari · LINE Yahoo · DeNA · freee など韓国・日本企業の実採用事例をまとめる。

第1章 · 2026年 JavaScript ランタイム戦争の地形図

まずはランタイムそのもの。2026年には次の4つが同時に本番で動いている。

| ランタイム | エンジン | 強み | 弱み |

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

| Node.js 22 LTS / 24 | V8 | エコシステム、安定性、npm 互換性100% | 起動が遅い、コールドスタート |

| Bun 1.2+ | JSC (JavaScriptCore) | 速い起動、バンドラ・テスト内蔵 | 一部ネイティブモジュールの互換性 |

| Deno 2 | V8 | セキュリティ最優先、TS ネイティブ、標準ライブラリ | npm 互換は互換にすぎない |

| Cloudflare Workers | V8 isolate | コールドスタート ~0ms、グローバル分散 | 一部 Node API 未対応、CPU 制限 |

その上に Vercel Edge Functions、Netlify Edge Functions (Deno)、AWS Lambda@Edge、Deno Deploy のようなサーバーレス・エッジ派生が加わる。**唯一の正解はない。** ワークロード、チーム、コスト、コールドスタート感度がすべて違うからだ。

核心的な変化は2つ。1つ、**エッジランタイムが本番の1級市民になった**。Cloudflare Workers はグローバル320+ POP で V8 アイソレートを動かし、50ms TTFB を日常にする。2つ、**Bun と Deno はもう実験ではない**。Bun 1.2 は Vercel の一部インフラと Discord の一部サービスで本番稼働しており、Deno 2 は Netlify のエッジランタイムとして毎日数百億リクエストを処理する。

第2章 · Node.js 22 LTS / 24 — いまだデフォルト、しかし進化

2025年末に Node 22 が active LTS に落ち着き、Node 24 が current になったことで標準ラインナップが変わった。新たに入ったものをまとめると。

- **内蔵テストランナー** (`node:test`) — Jest なしで単体テスト可能。2024年に stable になり、2026年には mock・snapshot・coverage まで入って、小規模プロジェクトは依存なしで完結する。

- **`--watch` モード** — nodemon なしでファイル変更検知の再起動。開発ワークフローから依存が1つ消える。

- **内蔵 `.env` ローディング** (`--env-file`) — dotenv なしで環境変数ファイルを読み込み。

- **fetch / WebStreams / FormData 内蔵** — `node-fetch` のようなポリフィルはもう不要。

- **Permission Model**(実験的)— `--allow-fs-read=/etc` のような Deno スタイルの権限制御。

- **WebSocket クライアント内蔵** — Node 22 から。

- **Test Reporter API**、**Custom ESM Loaders の安定化**、**WASI 安定化**。

Node.js の強みはやはり **npm パッケージ200万本との互換性** と **本番実績**。Netflix · PayPal · LinkedIn · Uber · Walmart · Goldman Sachs · NASA がメインバックエンドに使っている。保守的なチームなら、Node 22 LTS は2027年4月までメンテされるので安全なデフォルト。

第3章 · Bun 1.2+ — JSC ベースの野心作

Bun は Jarred Sumner が作った JSC(Safari エンジン)ベースの JavaScript ランタイム + パッケージマネージャ + バンドラ + テストランナー + シェル。2024年に1.0が出て、2026年5月時点で1.2.x が安定チャネル。

Bun の魅力は明確。

- **起動時間**: Node 比で約4倍速いコールドスタート。

- **`bun install`**: npm 比で約20倍速いインストール(キャッシュヒット時はさらに)。

- **バンドラ**: esbuild 水準の速度で TS · JSX · CSS · WASM を処理。

- **`bun test`**: Jest 互換 API でより高速。

- **`Bun.serve()`**: 内蔵 HTTP サーバ、約3倍のスループット。

- **SQLite 内蔵** (`bun:sqlite`)、**password hashing 内蔵**、**ffi 内蔵**。

弱点もはっきりしている。

- **ネイティブモジュール互換性**: `node-gyp` でビルドされる一部パッケージは依然として鬼門。

- **Cluster API の部分対応**、一部の `process` イベントに差異。

- **本番検証**は Node ほどではない — ただし2025年後半から Vercel、Discord、Tigris などが一部で使用。

**いつ Bun を選ぶか**: モノレポのビルド速度がボトルネックのとき、コールドスタートが重要なサーバーレスシナリオで Workers が合わないとき、Elysia のような Bun 最優先フレームワークを使いたいとき。

第4章 · Deno 2 — セキュリティ最優先、標準最優先

Ryan Dahl(Node の創始者)が Node への「後悔」を集めて作り直したランタイム。2024年の Deno 2.0 が大きな転換点になった — **npm 互換**が入ったからだ。

Deno のデザイン原則。

1. **セキュリティ最優先** — 既定でファイル・ネットワーク・環境変数アクセスがブロック。`--allow-net`、`--allow-read` などで明示的に権限付与。

2. **TypeScript ネイティブ** — トランスパイル不要で `.ts` を直接実行。

3. **標準ライブラリ** — `@std/http`、`@std/fs`、`@std/crypto` など検証済み標準。

4. **単一実行ファイル** — `deno compile` で自己完結バイナリを出力。

5. **JSR**(JavaScript Registry)— TS 最優先のモジュールレジストリ。

2026年時点での Deno の本当の強みは **Deno Deploy** プラットフォームと **Netlify Edge Functions**(Deno ベース)で最もよく現れる。グローバル分散の V8 アイソレートに TypeScript をそのまま載せる体験は非常に滑らか。

弱点は **npm パッケージ互換がよくできているとはいえ100%ではない** こと、そして **Express のような一部レガシーミドルウェアが Deno では曲芸が必要** なこと。代わりに Hono、Oak、Fresh のような Deno 親和フレームワークがしっかり定着している。

第5章 · Cloudflare Workers — エッジ V8 アイソレートの黄金期

Workers は Node や Bun のような「ランタイム」というより、**実行モデル自体が違う**。コンテナ上の Node プロセスではなく、V8 アイソレートをグローバル320+ POP で即座に立ち上げる。だからコールドスタートは事実上ゼロに収束する。

2026年 Workers エコシステムの中心。

- **Workers + Durable Objects** — グローバル分散ステートマシン。WebSocket・セッション・リアルタイム同期に強い。

- **Workers KV / R2 / D1** — Key-Value・オブジェクトストレージ・SQLite ベースのグローバル DB。

- **Workers Queues** — 非同期ジョブキュー、BullMQ のエッジ版。

- **Workers AI** — エッジ LLM 推論(Llama · Mistral など)。

- **Workers Smart Placement** — オリジンに近い POP で自動実行。

制約もある。**CPU 時間 50ms(無料プラン)/ 30s(有料)制限**、**Node API の部分対応**(`nodejs_compat` フラグで互換 ON)、**メモリ 128MB**。重い ML 推論や長い trace 処理はできない。

**Hono が事実上の標準** になった。Cloudflare 自身が Hono をワーカーデモと公式ドキュメントで使い、honojs/hono リポジトリにも Cloudflare 社員が contributor として参加している。

第6章 · Hono 4 — エッジ最優先、マルチランタイムの勝者

Hono(炎)は日本の Yusuke Wada が作ったフレームワーク。**Cloudflare Workers、Deno、Bun、Node.js、Vercel、AWS Lambda、Fastly Compute@Edge で同じコードが動く** ことが決定的な強み。

const app = new Hono()

app.get('/', (c) => c.text('Hello Hono!'))

app.get('/users/:id', (c) => {

const id = c.req.param('id')

return c.json({ id, name: 'Alice' })

})

export default app

特徴。

- **Web Standards ベース**: Request/Response/fetch API の上で動作。ランタイム依存なし。

- **速い**: Workers で Express の約5倍、Node では Fastify 並み。

- **型安全**: end-to-end 型 (`hono/client`) でクライアントもサーバ型を直接推論。

- **豊富なミドルウェア**: JWT · OAuth · CORS · 圧縮 · キャッシュ · Logger · Bearer · Basic Auth すべて内蔵。

- **RPC モード** (`hono/rpc`): tRPC スタイルの型安全呼び出し。

- **Validator** 統合: Zod · Valibot · ArkType · TypeBox · class-validator すべて対応。

2026年の Hono は **エッジ最優先フレームワークの事実上の標準**。Cloudflare の公式デモ、Vercel のドキュメント、Deno Deploy のガイド、いずれも Hono を例示に使う。

第7章 · Fastify 5 — Node 最速の正統派

Hono がエッジの王なら、**Node ランタイムでは Fastify 5 が性能チャンピオン**。Express と同じミドルウェアモデルだが、はるかに速く型フレンドリー。

- **TechEmpower ベンチマーク** Node 部門上位 — Express 比で約2倍のスループット。

- **JSON スキーマベースのシリアライズ**: fast-json-stringify でレスポンスシリアライズが約2倍速い。

- **Encapsulation モデル**: プラグイン隔離で大きなコードベースもクリーン。

- **Pino ロギング内蔵**: 最速の Node ロガーがデフォルト。

- **TypeBox 統合**: JSON Schema と TS 型を同時に。

- **Fastify v5 (2024)** — Node 20+ 要求、ESM 最優先、async ミドルウェア100%、より厳格なスキーマ。

いつ Fastify を選ぶか: **Node オリジンサーバでスループットが重要なとき**、**OpenAPI 自動生成が必要なとき**(@fastify/swagger)、**多数のマイクロサービスが小さな Fastify アプリで構成されるとき**。

Coupang が Express から Fastify へ一部サービスを移行した事例が2024年のカンファレンスで紹介された。スループット40%向上、p99 レイテンシ30%減。

第8章 · Express 5 — 10年越しの GA、それでも生きている

Express 5.0 は2014年に最初のアルファが出てから、**ほぼ10年後の2024年9月にようやく stable** になった。5.1.x も2025年に続いた。

5.0 の主要な変更。

- **async/await の正式サポート** — ミドルウェアが reject した Promise を自動で next(err) に渡す。

- **path-to-regexp v6** — ルート正規表現処理の改善、セキュリティ修正(ReDoS 防御)。

- **req.host / req.protocol** の挙動を正規化。

- **Node 18+ 要求**。

依然として **世界で最も使われている Node フレームワーク**。ダウンロード数、依存パッケージ数、チュートリアル・講義・StackOverflow 回答数すべて1位。学習資料が無限にあるので、**新人バックエンドの最初のプロジェクトとしては今も良い選択**。

弱点は明確。**性能面で Fastify · Hono に劣る**、**型サポートが別パッケージ(`@types/express`)必要**、**OpenAPI 自動化が別ライブラリ(express-openapi-validator)依存**。新規本番で Express をあえて選ぶ理由は減ってきている。

第9章 · Koa.js — async ミドルウェアの元祖

TJ Holowaychuk(Express 原作者)が作った後継作。2026年時点で Koa 2.x が安定。async/await ミドルウェアを最初に綺麗に整えたフレームワーク。

const app = new Koa()

app.use(async (ctx, next) => {

const start = Date.now()

await next()

const ms = Date.now() - start

ctx.set('X-Response-Time', `${ms}ms`)

})

app.use(async (ctx) => {

ctx.body = 'Hello Koa'

})

app.listen(3000)

- **オニオンモデルのミドルウェア**: `await next()` の前後で自然に前処理・後処理。

- **すべてが `ctx` に集まる** — req/res の分離なし。

- **Express より小さく軽い** — 慣れるとコードがクリーン。

2026年時点での採用率は下がった。Hono · Fastify · Express 5 が似た抽象度を提供する中で、わざわざ Koa を新規に選ぶ理由は薄れた。ただし **Strapi**、**Egg.js**、**Sails** のようなメタフレームワークが Koa 上にあるので、間接利用者は依然として多い。

第10章 · NestJS 11 — Angular スタイルの依存性注入

NestJS は Kamil Mysliwiec が作ったエンタープライズ志向フレームワーク。Angular のデコレータ・モジュール・DI パターンをそのままバックエンドに持ち込んだ。**2025年後半に v11 が安定化**。

@Controller('users')

class UsersController {

@Get(':id')

findOne(@Param('id') id: string) {

return { id, name: 'Alice' }

}

}

@Module({ controllers: [UsersController] })

export class AppModule {}

特徴。

- **モジュール・コントローラ・サービス・プロバイダ** パターン — Spring Boot や ASP.NET のような大規模コードベースの構造をそのまま。

- **DI コンテナ** — コンストラクタ注入、インターフェイスベースのテスト。

- **マイクロサービス組込** — Redis · NATS · Kafka · gRPC · MQTT トランスポート。

- **GraphQL · WebSocket · Swagger · Auth · Caching** すべて1級モジュール。

- **CLI ベースのコード生成** — `nest g module users` など。

NestJS v11 の変更点。

- **Express v5 / Fastify 5 同時サポート** — アダプタを選べる。

- **Node 20+ 要求**。

- **`SWC` ビルドがデフォルト** — TypeScript コンパイル約20倍高速。

いつ NestJS を選ぶか: **チームが大きいとき**、**DI・テスト・ドキュメント自動化のようなエンタープライズ要件があるとき**、**モノレポで多数のマイクロサービスを回すとき**。重すぎると感じるなら Hono · Fastify など軽量側のほうがよい。

第11章 · AdonisJS 6 — JavaScript 版 Laravel

Harminder Virk が作ったフルスタック MVC フレームワーク。Laravel のデザインをほぼそのまま引き継ぎ、2024年の v6 で ESM と TypeScript 最優先に再整備された。

特徴。

- **Lucid ORM**(Active Record)、**Edge** テンプレートエンジン、**Auth · Mail · Session · Validation · Queue** すべて内蔵。

- **豊富な CLI**: `node ace make:controller`、`node ace migration:run` など。

- **フルスタック**: Inertia.js 統合で React/Vue フロントエンドも容易。

- **Routing**: ルートグループ、ミドルウェア、リソースルーティング。

Hono · Fastify が「組み立て型」なら、AdonisJS は「完成品」。Laravel 出身の開発者が Node に来るときに最も馴染む選択。2026年もインド・東欧・南米コミュニティで活発。

第12章 · Elysia — Bun ネイティブ、end-to-end 型

Elysia は SaltyAom が作った Bun 最優先のフレームワーク。**Bun 上で最高のスループット**を出し、**型推論が Hono よりも精密**。

const app = new Elysia()

.get('/users/:id', ({ params }) => ({ id: params.id, name: 'Alice' }), {

params: t.Object({ id: t.String() }),

})

.listen(3000)

export type App = typeof app

特徴。

- **TechEmpower ベンチマーク上位** — 一部のシナリオでは Hono · Fastify を上回ることも。

- **Eden** — tRPC スタイルの型安全クライアント。上の `App` 型を import すれば自動推論。

- **TypeBox ベースのバリデーション** — JSON Schema 同時生成。

- **プラグインシステム** — Swagger · JWT · CORS · Static · WebSocket すべて揃う。

- **AOT コンパイル** — ルートを静的解析して高速化。

弱点: **Bun 依存**。Node・Deno で直接は動かない。だから「Bun を使うなら Elysia、それ以外なら Hono」が2026年の通常結論。

第13章 · h3 / Nitro / UnJS — Vue/Nuxt のバックエンドエンジン

**UnJS** は Pooya Parsa が率いる Vue/Nuxt エコシステムのユニバーサルライブラリ集合。その中心に **h3**(HTTP フレームワーク)と **Nitro**(サーバエンジン)がある。

- **h3** — ミニマル HTTP フレームワーク。Express に似たハンドラモデルでマルチランタイム対応。

- **Nitro** — h3 上で動くフルサーバエンジン。ルーティング・アセット・キャッシュ・ストレージ・タスク・ミドルウェア・アダプタをまとめ、Node · Bun · Deno · Workers · Lambda · Netlify · Cloudflare 向けにビルド。

Nuxt 3·4 のサーバ部分は Nitro。SolidStart、Analog のような他のメタフレームワークも Nitro 上で動く。**バックエンド単独で使いたい場合** も `nitropack` だけ持ち込んで使える。

魅力は **単一コードベースで全ランタイムをターゲット** にできる点。弱点は Hono と比べて認知度と資料が少ないこと。

第14章 · Encore TS — インフラまでコードで

Encore は Marcus Kohlberg が始めたバックエンドフレームワーク + インフラ。**宣言したリソースが自動でクラウドにプロビジョニングされる** ことが、ほかのフレームワークとの決定的な違い。

const db = new SQLDatabase('users', { migrations: './migrations' })

export const getUser = api(

{ expose: true, method: 'GET', path: '/users/:id' },

async ({ id }: { id: string }) => {

const row = await db.queryRow`SELECT * FROM users WHERE id = ${id}`

return row

},

)

- **データベース · キュー · pub-sub · キャッシュ · cron** をコードで宣言するだけでインフラが自動生成。

- **ローカル開発**: Docker コンテナで全依存を自動起動。

- **型安全 RPC**: 関数呼び出しがそのまま API 呼び出し。

- **トレース · メトリクス · ログを自動収集**。

- **Encore Cloud Platform**(有料)または **自前クラウド(AWS · GCP)** にデプロイ。

いつ Encore を選ぶか: **DevOps 人員が不足する小さなチーム**、**インフラを標準化したいスタートアップ**。弱点は **lock-in の印象** と **細かいインフラ制御の不足**。

第15章 · Effect — 関数型 TypeScript の野心

Effect-TS は Michael Arnaldi が率いる関数型 TS エコシステム。Scala の ZIO や Haskell の IO モナドの発想を TypeScript に持ち込んだ。

特徴。

- **`Effect.gen` / `Effect.pipe`**: 非同期エラー処理・再試行・タイムアウト・キャンセルを型で表現。

- **Schema**: Zod の代替。より豊富な型推論と変換。

- **Services & Layers**: DI コンテナ + 依存の合成。

- **Stream / Queue / Hub**: 構造化された並行性。

- **HttpApi**: Effect ベースの HTTP サーバフレームワーク。

const getUser = (id: string) =>

pipe(

Effect.tryPromise(() => fetch(`/users/${id}`)),

Effect.flatMap((res) => Effect.tryPromise(() => res.json())),

Effect.retry({ times: 3 }),

Effect.timeout('5 seconds'),

)

学習曲線は急。だが **複雑な非同期ワークフロー**(決済・orchestration・多数の外部 API 呼び出し)では、try/catch 地獄よりはるかに明瞭になる。2026年には目にする機会が増えているが、チーム全員が関数型に慣れている必要がある。

第16章 · tRPC 11 — エンドツーエンド型安全 RPC

tRPC は Alex / KATT が作った RPC フレームワーク。**GraphQL の型安全性をスキーマなしで** 達成するのが核心。

const t = initTRPC.create()

export const appRouter = t.router({

getUser: t.procedure

.input(z.object({ id: z.string() }))

.query(({ input }) => ({ id: input.id, name: 'Alice' })),

})

export type AppRouter = typeof appRouter

クライアント側で `AppRouter` 型だけ import すれば呼び出しが完全に型安全。

- **v11(2024年後半)**: React Server Components 1級サポート、signal ベース購読、fetch アダプタ。

- **Next.js · Express · Fastify · Hono · Nuxt** のアダプタ。

- **subscriptions**: WebSocket / SSE。

- **batch · prefetch · キャッシュ** が1級。

**Next.js / Nuxt モノレポでバックエンドとフロントを同時に書くとき** に強力。他言語クライアントや外部公開 API には合わない — それは OpenAPI / GraphQL の領域。

第17章 · バリデーションライブラリ — Zod · Valibot · ArkType · TypeBox

API 入力バリデーションと型推論は2026年バックエンドの核心的な意思決定の1つ。

| ライブラリ | モデル | 強み | 弱み |

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

| Zod 3.x | object-builder | エコシステム1位、Hono · tRPC · Fastify 1級 | ツリーシェイキング弱、バンドルサイズ |

| Valibot | モジュラー | ツリーシェイキング・バンドルサイズ約10倍小さい | エコシステムは小さい |

| ArkType | 型表現 | 推論が速く、TS-native な表現 | 学習曲線 |

| TypeBox | JSON Schema | 標準 JSON Schema を同時生成、Fastify のデフォルト | API が冗長 |

| Joi | クラス | 成熟、hapi の標準 | 型推論が弱い |

| Yup | クラス | React フォーム親和 | バックエンドでは縮小 |

**デフォルトは依然として Zod**。ただし、バンドルサイズが決定的なとき(エッジ · モバイル同期コード共有)は Valibot、性能が決定的なときは ArkType、OpenAPI 自動生成が重要なときは TypeBox。

第18章 · ORM 戦争 — Prisma 6 vs Drizzle 0.40

2025~2026年で最も熱い比較。2つの ORM は哲学が完全に違う。

**Prisma 6**。

- **宣言的スキーマ** (`schema.prisma`) — 専用 DSL。

- **migrate · introspect · studio** など豊富なツールチェーン。

- **型安全クエリ** 自動生成。

- **すべての主要 DB をサポート** — Postgres · MySQL · SQLite · MongoDB · CockroachDB · MS SQL。

- **欠点**: エッジランタイムで重い(別エンジンバイナリ)、マイグレーション lock-in。

**Drizzle ORM 0.40**。

- **TypeScript-first スキーマ** — `.ts` ファイルで直接定義。

- **SQL に近いビルダ** — 学習曲線が低い。

- **バンドル小さくエッジ親和** — Cloudflare D1 · Vercel Postgres · Turso の事実上の標準。

- **欠点**: Prisma ほどリッチなツーリングはまだない。

**いつ Prisma**: 大きなモノレポ、MongoDB のような多様なバックエンド、マイグレーション自動化中心。**いつ Drizzle**: エッジデプロイ、Workers · Vercel · Neon · Turso、SQL に慣れたチーム。

ほかに **Kysely**(型安全 SQL ビルダ、最も薄い)、**MikroORM 6**(Unit of Work パターン、エンタープライズ)、**TypeORM 0.3**(デコレータベース、シェア低下)、**Sequelize 6**(レガシー)、**Objection.js / Bookshelf / Knex**(クエリビルダ + 軽量 ORM)も依然として活動中。

第19章 · API パターン — REST · GraphQL · tRPC · gRPC · OpenAPI

| パターン | 強み | 弱み |

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

| REST + OpenAPI | 普遍性、キャッシュ、豊富なツール | over-fetching、多段ラウンドトリップ |

| GraphQL | 単一エンドポイント、クライアント主導フェッチ | キャッシュが難しい、N+1、複雑 |

| tRPC | TS エンドツーエンド型、ボイラープレート少 | TS 限定、外部公開が難しい |

| gRPC + Protobuf | 双方向ストリーミング、多言語、効率的 | ブラウザから直接呼びにくい |

| JSON-RPC | シンプル、メッセージキュー親和 | ツーリングが貧弱 |

2026年の実務トレンド: **外部公開 API は REST + OpenAPI**、**内部マイクロサービスは gRPC**、**モノレポフルスタックは tRPC**、**公開グラフ API は GraphQL**、**イベント/RPC は JSON-RPC または NATS**。1つに統一しようとせず、境界ごとに合うものを選ぶ。

第20章 · ジョブキュー — BullMQ · Cloudflare Queues · Inngest

非同期ジョブ、再試行、バックオフ、スケジューリングが必要なところ。

**BullMQ**(Redis ベース)。

- 最も広く使われている Node ジョブキュー。優先度 · 再試行 · rate limit · sandbox · UI(Bull Board)まで。

- **弱点**: Redis 依存、自前運用が必要。

**Cloudflare Queues**。

- Workers ネイティブ。自前運用なしでグローバル分散。

- **弱点**: Cloudflare エコシステム lock-in。

**Inngest**(durable workflow 専門)。

- 別記事で扱う durable functions プラットフォーム。step 関数単位で自動再試行 · 永続化。

- **弱点**: 外部サービス lock-in。セルフホスト可だが運用が複雑。

ほかに **Hatchet**(self-hostable durable workflow、Postgres ベース)、**Trigger.dev**(ワーカーベース + UI)、**Temporal**(他言語と併用するとき)— 詳細比較は別記事参照。

第21章 · 認証 — Auth.js v5 · Lucia v3 · better-auth

OAuth、JWT、セッション。2026年の風景。

- **Auth.js v5(旧 NextAuth)** — Next.js と強く統合、OAuth プロバイダ80+。

- **Lucia v3** — セッションベース、DB を直接制御。軽量で明示的。

- **better-auth** — 2024年後半に台頭した type-first 認証ライブラリ。OAuth · 2FA · マジックリンク · API key を内蔵。

- **Clerk · Auth0 · Stytch · WorkOS** — ホスト型 IDP。

選択基準: **フルスタックモノレポなら Auth.js または better-auth**、**バックエンド単独で明示的セッションが必要なら Lucia**、**運用負担を外注したいなら Clerk/WorkOS**。

第22章 · テスト — Vitest · Jest 30 · node test · Bun test · Playwright

| ツール | 強み |

| --- | --- |

| Vitest | Vite ネイティブ、watch モード速い、Jest 互換 API |

| Jest 30 | 最も成熟、資料豊富、強力なモック |

| node test | 依存なし、CI が速い |

| Bun test | Bun 上で最速 |

| Playwright | E2E、ブラウザ自動化 |

2026年の新規プロジェクトでは **Vitest がデフォルト** になった。CI 環境では **node test** も使われる頻度が増えてきている。E2E は **Playwright が事実上の標準**(Cypress 比でマルチブラウザ · より速い)。

第23章 · ロギング — Pino · Winston · Bunyan

Node バックエンドロギングの3大巨頭。

- **Pino**: 最速の Node ロガー。JSON シリアライズ最適化、Fastify のデフォルト。トランスポートは別途(pino-pretty · pino-elasticsearch)。

- **Winston**: 最も豊富なトランスポート。file · console · http · syslog · 多様な外部サービス。性能は Pino より落ちる。

- **Bunyan**: JSON 最優先、CLI ツール優秀。人気は減ったが一部企業が標準として維持。

2026年の通常選択: **新規プロジェクトなら Pino**、**多様な外部 sink が必要なら Winston**。その上に OpenTelemetry で分散トレーシング。

第24章 · WebSocket — ws · uWebSockets.js · Socket.io · Hono WS

| ライブラリ | 強み | いつ |

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

| ws | 最もシンプル、RFC6455 直接 | 低レベル WS、独自プロトコル |

| uWebSockets.js | 最速(C++ バインディング) | 数十万同時接続 |

| Socket.io 4.8 | room · ack · 再接続 · pub-sub アダプタ | クライアントも同じライブラリ |

| Hono WebSocket | Workers · Bun · Node マルチランタイム | エッジで WS |

| Bun.serve WS | Bun ネイティブ高速 | Bun 専用 |

Discord は約1億同時接続を Elixir + Rust で処理しつつ、一部 API は Node + Socket.io ベース。uWebSockets.js は一部の取引所 · ゲーム会社で使われる。

第25章 · クラウドデプロイ — Vercel · Workers · Lambda · Render · Railway · Fly.io

2026年バックエンドデプロイの選択肢。

- **Vercel**: Next.js 1級、Edge + Node + Python 全対応。PR 単位のプレビュー環境。

- **Cloudflare Workers**: エッジの王。Hono · Itty Router · SvelteKit と相性良し。

- **AWS Lambda**: 最も普遍的。SAM · CDK · Serverless Framework で IaC。

- **Render**: Heroku の後継。Docker · Postgres · cron · queue まで一貫。

- **Railway**: DX が良い PaaS。GitHub → デプロイ即時。

- **Fly.io**: グローバル Docker。Postgres · Redis 同梱。日本・韓国リージョンあり。

いつ何を選ぶか。

- **新規フルスタック SaaS**: Vercel + Neon/Supabase + Upstash + Inngest。

- **エッジ最優先 API**: Cloudflare Workers + D1/R2/KV + Hono。

- **他の AWS サービスと密結合**: Lambda + DynamoDB + SQS。

- **コンテナを直接回すのが楽**: Fly.io · Render · Railway。

第26章 · ミドルティアとマイナーフレームワーク

頻度は低くてもドメインでは強いもの。

- **Restify** — REST 最優先の軽量フレームワーク。Netflix で一部サービス使用。

- **Polka · Sirv** — ミニマリストルータ。独自ビルドツールに埋め込まれて運ばれる。

- **Marble.js** — RxJS ベースのリアクティブフレームワーク。関数型 + ストリーム。

- **Ts.ED** — デコレータベース。Express/Koa アダプタ。

- **FoalTS** — フルスタック TS フレームワーク。

- **Feathers** — REST + リアルタイム統合。

- **Moleculer** — マイクロサービスフレームワーク。

このいずれかを新規に選ぶことは稀だが、**メンテコードで遭遇しうる** ので、名前と立ち位置は覚えておくと助かる。

第27章 · モニタリング · 観測性 — OpenTelemetry · Sentry · Datadog · Grafana

2026年バックエンド観測スタック。

- **OpenTelemetry** — 標準 trace · metric · log スペック。事実上すべてのツールが互換。

- **Sentry** — エラートラッキングの標準。韓国・日本でも広く採用。

- **Datadog · New Relic** — 総合 APM、高額だがリッチ。

- **Grafana Stack** — Prometheus + Loki + Tempo。セルフホスト親和。

- **Honeycomb** — 分散トレース特化、observability 1.0 の思想家。

Node バックエンドなら `@opentelemetry/sdk-node` で自動 instrumentation を仕込み、Sentry でエラーを受け、Grafana や Datadog に forward するパターンが一般的。

第28章 · セキュリティ — Helmet · CSRF · Rate limit · CORS

- **helmet** — セキュリティヘッダ自動設定。CSP · HSTS · X-Frame · X-Content-Type など。

- **csurf** は deprecated。2026年には **csrf-csrf** のような後継ライブラリを使う。

- **express-rate-limit · @fastify/rate-limit · hono-rate-limiter** — IP / ユーザ単位の rate limiting。

- **CORS** — origin · credentials · methods を正確にホワイトリスト。

加えて **OWASP Top 10**(SQL injection · XSS · 認証欠陥 · セキュリティ misconfig など)をコードレビューチェックリストに。2026年でも、間抜けな事故はほぼ OWASP に書かれている。

第29章 · 韓国企業の採用事例 — Toss · Coupang · KakaoPay · Karrot

**Toss**。決済バックエンドの一部で Node + Hono の組み合わせ。グローバル分散決済 API のエッジルーティングに Cloudflare Workers + Hono を使うと、2025年の Toss Tech Conference で公開。Slack · 社内ツールのバックエンドは Node + Fastify。

**Coupang**。フルフィルメント一部 API を Express → Fastify に移行。2024年カンファレンス発表によるとスループット約40%向上、p99 レイテンシ約30%減。検索の一部インデキシングワーカーは BullMQ + Node。

**KakaoPay**。バックエンドの多くは Spring Boot だが、一部 BFF(Backend for Frontend)は Node + NestJS。tRPC パターンでフロントとの結合を減らした。

**Karrot**(당근마켓)。チャット · 通知などリアルタイム領域で Node + Socket.io を使用。最近は一部ワーカーを Bun で実験。

**Line Games · Kakao Games · Nexon**。ゲームメタ API の一部で Node を使用。WebSocket は uWebSockets.js や自社 C++ サーバと併用。

第30章 · 日本企業の採用事例 — Mercari · LINE Yahoo · DeNA · freee

**Mercari**。Hono を作った Yusuke Wada は Cloudflare へ加わる前にメルカリで働いていた。Mercari Shops の一部バックエンドは Hono + Cloudflare Workers。グローバル決済ルーティングと画像処理のエッジ化に Workers を使用。

**LINE Yahoo**。メインバックエンドは Kotlin · Java だが、一部統合 BFF や LINE ノベルのような新規サービスで Node + NestJS。一部広告システムバックエンドで Bun を実験。

**DeNA**。モバイルゲームバックエンドの一部で Node。チャット・イベント処理に Socket.io。

**freee**。会計 SaaS の一部 API で Node + Fastify。OpenAPI 自動生成のため Fastify + TypeBox の組み合わせ。

**Cybozu · CyberAgent · Recruit**。社内ツールの多くで Node + NestJS または Hono。Recruit は一部広告システムで Bun を試験中。

第31章 · 新規プロジェクトの意思決定ツリー

「どれを使うか」を助ける意思決定ツリー。

1. **フルスタックモノレポ(Next/Nuxt)?** → tRPC + Hono/Fastify + Zod + Drizzle。

2. **エッジ最優先 API?** → Cloudflare Workers + Hono + Drizzle + D1/Turso。

3. **エンタープライズ、大きなチーム、DI 必須?** → NestJS 11 + Fastify アダプタ + Prisma 6 + Class Validator。

4. **Bun を採用中?** → Elysia + TypeBox + Drizzle。

5. **Laravel 出身?** → AdonisJS 6。

6. **インフラまで自動化?** → Encore TS。

7. **複雑な非同期ワークフロー?** → Effect + Hono。

8. **レガシー Express のメンテ?** → Express 5 にアップグレード、Fastify への段階移行を検討。

これはガイドラインに過ぎず、**チームの慣熟度が最大の変数**。「最高のツール」などはない。チームが速く書けて、デバッグできるツールが最高のツール。

第32章 · アンチパターン — よく見る失敗

- **Express で async エラーを next に渡さない** — try/catch なしで await すると unhandled rejection。

- **Prisma をそのままエッジに載せる** — 別エンジンバイナリが必要。Drizzle/Kysely に置き換え。

- **すべてを tRPC で** — 外部公開 API まで tRPC で束ねて、他言語クライアントが繋がらない。

- **Bun を本番に無理やり** — 一部ネイティブモジュールが動かないことを確認せず採用。

- **Hono RPC に依存しすぎ** — コンパイル時間が遅くなり型推論が爆発。

- **NestJS のモジュール分割が過剰** — 小さなアプリにモジュール50個作って可読性破綻。

- **チーム合意なしで Effect を導入** — 関数型に慣れているのが1人だけだと PR レビューが止まる。

第33章 · 性能ベンチマークの罠

「TechEmpower スコア」だけで決めてはいけない、というのが2026年の合意。

- **`Hello World`** ベンチマークはミドルウェア · ORM · 外部 API 呼び出しが抜けた非現実シナリオ。

- 実本番では **DB レイテンシが80%以上** を占める。フレームワークが速くても DB クエリが遅ければ無意味。

- **メモリ効率 · ガベージコレクタ圧 · p99 TTFB** がスループットより重要なケースが多い。

- **コールドスタート** はサーバーレスでだけ重要。コンテナオリジンでは気にしなくていい。

ベンチマークは参考にとどめ、**自分のワークロードで負荷テスト(k6 · autocannon · oha)** するのが真実に近い。

第34章 · 学習ロードマップ

すでに Node がある程度書ける前提。

1. **Hono を1週間で**: Workers 無料プランに Hono + D1 で Todo API を立ち上げる。

2. **Fastify を2週間で**: Postgres + Drizzle + Zod で小さな SaaS API + OpenAPI 自動生成。

3. **NestJS を1か月で**: 本1冊(公式 docs か Ariel Weinberger 講座)+ 小さなマイクロサービスデモ。

4. **tRPC を1週間で**: Next.js モノレポに tRPC でフルスタック CRUD。

5. **Effect を2か月で**: 関数型入門が必要ならさらに長く。

面接の定番 — **イベントループ**、**バックプレッシャ**、**クラスタ · worker_threads**、**stream API**、**CommonJS vs ESM**、**N+1 問題と dataloader**、**GraphQL N+1 緩和**、**JWT vs セッション**、**rate limit アルゴリズム(token bucket、sliding window)**。

第35章 · まとめ — 正解はないが、良い問いはある

2026年の JavaScript バックエンドの風景は「Node + Express」時代よりずっと複雑になったが、それは選択肢が増えたからであり、進歩が遅れたわけではない。**エッジコンピューティングが本番になり**、**型安全性がデフォルトになり**、**インフラがコードになり**、**コールドスタートが0に近づいた**。

次のプロジェクトを始めるとき、「どのフレームワークが熱いか」ではなく、まずこの問いを。

1. どこで動くか? エッジか、オリジンか、両方か?

2. 誰が書くか? 関数型が扱えるチームか、デコレータに慣れているか?

3. 外部公開するか? するなら OpenAPI · REST。

4. クライアントは誰が書くか? 同じモノレポなら tRPC、他言語なら gRPC/REST。

5. 運用は誰がやるか? DevOps が不足なら Vercel · Railway · Encore。

6. 半年後に後悔しないか? 「トレンド」より「メンテ人口」。

良いバックエンドは良いフレームワークからは生まれない。**良い問い** から生まれる。

参考資料 (References)

- Node.js Releases — [https://nodejs.org/en/about/previous-releases](https://nodejs.org/en/about/previous-releases)

- Node.js 22 LTS Blog — [https://nodejs.org/en/blog/release/v22.11.0](https://nodejs.org/en/blog/release/v22.11.0)

- Bun Documentation — [https://bun.sh/docs](https://bun.sh/docs)

- Deno 2 Release — [https://deno.com/blog/v2](https://deno.com/blog/v2)

- Cloudflare Workers — [https://developers.cloudflare.com/workers/](https://developers.cloudflare.com/workers/)

- Hono — [https://hono.dev/](https://hono.dev/)

- Fastify v5 — [https://fastify.dev/blog/2024/10/01/fastify-v5-ga/](https://fastify.dev/blog/2024/10/01/fastify-v5-ga/)

- Express 5 Release — [https://expressjs.com/2024/10/15/v5-release.html](https://expressjs.com/2024/10/15/v5-release.html)

- Koa.js — [https://koajs.com/](https://koajs.com/)

- NestJS — [https://nestjs.com/](https://nestjs.com/)

- AdonisJS 6 — [https://adonisjs.com/](https://adonisjs.com/)

- Elysia — [https://elysiajs.com/](https://elysiajs.com/)

- h3 — [https://h3.unjs.io/](https://h3.unjs.io/)

- Nitro — [https://nitro.unjs.io/](https://nitro.unjs.io/)

- Encore TS — [https://encore.dev/](https://encore.dev/)

- Effect — [https://effect.website/](https://effect.website/)

- tRPC — [https://trpc.io/](https://trpc.io/)

- Zod — [https://zod.dev/](https://zod.dev/)

- Valibot — [https://valibot.dev/](https://valibot.dev/)

- ArkType — [https://arktype.io/](https://arktype.io/)

- TypeBox — [https://github.com/sinclairzx81/typebox](https://github.com/sinclairzx81/typebox)

- Prisma — [https://www.prisma.io/](https://www.prisma.io/)

- Drizzle ORM — [https://orm.drizzle.team/](https://orm.drizzle.team/)

- Kysely — [https://kysely.dev/](https://kysely.dev/)

- BullMQ — [https://docs.bullmq.io/](https://docs.bullmq.io/)

- Auth.js — [https://authjs.dev/](https://authjs.dev/)

- Lucia — [https://lucia-auth.com/](https://lucia-auth.com/)

- Pino — [https://getpino.io/](https://getpino.io/)

- Socket.io — [https://socket.io/](https://socket.io/)

- Mercari Engineering Hono Article — [https://engineering.mercari.com/en/blog/](https://engineering.mercari.com/en/blog/)

- Toss Tech — [https://toss.tech/](https://toss.tech/)