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つが同時に本番で動いている。

その上に 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 で同じコードが動く ことが決定的な強み。

import { Hono } from 'hono'

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 ミドルウェアを最初に綺麗に整えたフレームワーク。

import Koa from 'koa'

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 が安定化。

import { Controller, Get, Param, Module } from '@nestjs/common'

@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 よりも精密。

import { Elysia, t } from 'elysia'

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

import { api } from 'encore.dev/api'
import { SQLDatabase } from 'encore.dev/storage/sqldb'

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 サーバフレームワーク。

import { Effect, pipe } from 'effect'

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 の型安全性をスキーマなしで 達成するのが核心。

import { initTRPC } from '@trpc/server'
import { z } from 'zod'

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。ただし、バンドルサイズが決定的なとき(エッジ · モバイル同期コード共有)は 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

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

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

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
• Node.js 22 LTS Blog — https://nodejs.org/en/blog/release/v22.11.0
• Bun Documentation — https://bun.sh/docs
• Deno 2 Release — https://deno.com/blog/v2
• Cloudflare Workers — https://developers.cloudflare.com/workers/
• Hono — https://hono.dev/
• Fastify v5 — https://fastify.dev/blog/2024/10/01/fastify-v5-ga/
• Express 5 Release — https://expressjs.com/2024/10/15/v5-release.html
• Koa.js — https://koajs.com/
• NestJS — https://nestjs.com/
• AdonisJS 6 — https://adonisjs.com/
• Elysia — https://elysiajs.com/
• h3 — https://h3.unjs.io/
• Nitro — https://nitro.unjs.io/
• Encore TS — https://encore.dev/
• Effect — https://effect.website/
• tRPC — https://trpc.io/
• Zod — https://zod.dev/
• Valibot — https://valibot.dev/
• ArkType — https://arktype.io/
• TypeBox — https://github.com/sinclairzx81/typebox
• Prisma — https://www.prisma.io/
• Drizzle ORM — https://orm.drizzle.team/
• Kysely — https://kysely.dev/
• BullMQ — https://docs.bullmq.io/
• Auth.js — https://authjs.dev/
• Lucia — https://lucia-auth.com/
• Pino — https://getpino.io/
• Socket.io — https://socket.io/
• Mercari Engineering Hono Article — https://engineering.mercari.com/en/blog/
• Toss Tech — https://toss.tech/