LabHub

ブログ

TypeScript エコシステム 2026 完全ガイド — Bun · Deno · Hono · Elysia · NestJS · Effect · tRPC · Drizzle · Prisma · Zod · Vitest ディープダイブ

2026-05-16 · 37 分で読めます · #typescript#node-js#bun#deno#hono#elysia#nestjs#effect#trpc#drizzle#prisma#zod#vitest#pnpm

한국어English日本語

「JavaScriptの自由の上にTypeScriptの安全を載せ、その上にEffectで関数型エフェクトを、Bunで速度を、Honoでエッジを加える — それが2026年のTypeScriptバックエンドだ」 — TypeScript Conf 2025 基調講演の要旨

2012年に Anders Hejlsberg の手から TypeScript 0.8 として登場してから14年が経った。その間に TypeScript は単なる「型を付けた JavaScript」から、巨大なバックエンドとフルスタックエコシステムの標準言語へと変わった。2026年5月時点で、npm のダウンロード統計では TypeScript コンパイラが毎週1億ダウンロードを超え、Stack Overflow Developer Survey 2025 では TypeScript が「最も愛される言語」4位、「最も使われる言語」3位に入った。

特にバックエンド領域の変化が劇的だ。Node.js は 22 LTS と 24 Active の二つのメジャーが共存し、Bun 1.2 はもはや「実験的な速いランタイム」ではなく実プロダクションで採用される選択肢となり、Deno 2.x は npm 互換性を完成させて再び舞台に戻ってきた。Hono は V8 isolate 上で最も使われるエッジフレームワークになり、Elysia は Bun 専用の高性能フレームワーク、NestJS 11 はエンタープライズの標準として定着した。本記事では TypeScript 5.6、ランタイム3種、Web フレームワーク7種、ORM 5種、検証ライブラリ5種、ワークフローエンジン、テストツール、ビルドツール、そして韓国・日本の実採用事例までを一本にまとめる。

1. 2026年の TypeScript バックエンド地図

2026年5月時点で、TypeScript バックエンドはおおむね以下の5軸に整理できる。

軸代表ツール主要キーワード
ランタイムNode.js 22/24, Bun 1.2, Deno 2.x互換性・速度・セキュリティ
Web フレームワークHono, Elysia, NestJS 11, Fastify 5, h3/Nitroルーティング・DI・ミドルウェア
検証Zod 4, ArkType, Valibot, Effect Schema, TypeBox型推論・実行時検証
ORMDrizzle 0.40, Prisma 6, Kysely, MikroORM 6SQL DSL・マイグレーション
ワークフローEffect, Temporal, Inngest, Trigger.dev, Hatchet再試行・永続化・スケジュール

最大の変化は「ランタイムの選択がもはや『Node かそうでないか』の問題ではない」という点だ。Bun 1.2 は Node 互換モードでほぼ全ての npm パッケージを動かし、Deno 2.x は npm: / jsr: スキームで npm エコシステムをそのまま吸収した。だから2026年の選択基準は「どのランタイムが最も速いか」ではなく、「我々のチームの運用ツール・観測ツール・プラットフォームがどちらをサポートしているか」へと移った。

2. TypeScript 5.6 — using 宣言 · isolated declarations · ISO 8601 Date

TypeScript 5.6 は 2025年後半に正式リリースされ、2026年5月時点で 5.7 が RC 段階だ。バックエンドの観点から 5.6 の三つの機能を取り上げる価値がある。

一つ目は using 宣言 (ECMAScript Explicit Resource Management)。using db = await pool.connect() のように宣言するとスコープを抜けたときに自動で Symbol.dispose または Symbol.asyncDispose が呼ばれ、リソースが閉じられる。DB コネクション、ファイルハンドル、トランザクションなどの資源管理に RAII に近いパターンを使えるようになった。

二つ目は isolated declarations (--isolatedDeclarations)。すべての export に明示的な型注釈を強制するモードで、ビルドツールが推論なしで型情報を抽出できる。Bun、esbuild、swc、oxc のような tsc 以外のビルダが .d.ts を直接生成でき、モノレポでの tsc -b のボトルネックを大きく削減した。

三つ目は ISO 8601 Date 処理の改善。new Date('2026-05-16T00:00:00Z') のような ISO 文字列処理でタイムゾーン推論と Intl API がどちらも強化され、バックエンドのロギング・観測ツールのタイムスタンプ一貫性が良くなった。

// using 宣言の例
import { Pool } from 'pg'

const pool = new Pool({ connectionString: process.env.DATABASE_URL })

async function fetchUser(id: string) {
  await using client = await pool.connect()
  const result = await client.query('SELECT * FROM users WHERE id = $1', [id])
  return result.rows[0]
  // スコープ終了時に client[Symbol.asyncDispose]() が自動で呼ばれる
}

5.6 はまた --noUncheckedSideEffectImports を追加し、import './styles.css' のような副作用 import が型チェック段階で抜け落ちないようにした。

3. Node.js 22 LTS と 24 Active — 組み込み fetch、test runner、watch モード

Node.js は2026年5月時点で 22.x が LTS(Active LTS 段階)、24.x が Active(開発中の次期 LTS 候補)、26.x が間もなく分岐を準備している。22 LTS の変化のうち、バックエンドに直接影響するものを整理する。

24.x は V8 12.8、ICU 75 へ更新し、node --experimental-sqlite で SQLite 組み込みをベータ公開した。さらに 24 からは node --experimental-strip-types で TypeScript ファイルをトランスパイルなしに直接実行できる(型チェックは別)。

# Node 22 LTS で TypeScript を直接実行 (実験的)
node --experimental-strip-types app.ts

# 組み込みテストランナーで *.test.ts を実行
node --test --experimental-strip-types '**/*.test.ts'

# .env ファイル読み込み + 権限モデル
node --env-file=.env --permission --allow-fs-read=./data app.ts

2026年時点、Node 本体に TypeScript 実行が入ったことで「Node + tsx」の組合せの必要性は薄れたという声もあるが、プロダクション環境では今でも tsc で事前ビルドする流れが標準だ。

4. Bun 1.2 — Node 互換、高速起動、バンドラ・SQLite・Redis 同梱

Bun は Jarred Sumner が 2021年に始めた Zig ベースの JavaScript ランタイムで、JavaScriptCore(WebKit)エンジンを使う。2024年に 1.0 が出てから1年半で 1.2 まで進化し、「実験的な速いランタイム」から「Node の代替」へと性格が変わった。

1.2 の主な特徴:

// Bun.serve() で HTTP サーバ (Hono なしの純 Bun)
import { Database } from "bun:sqlite"

const db = new Database(":memory:")
db.run("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)")
db.run("INSERT INTO users (name) VALUES (?)", ["Toss"])

Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url)
    if (url.pathname === "/users") {
      const rows = db.query("SELECT * FROM users").all()
      return Response.json(rows)
    }
    return new Response("Not Found", { status: 404 })
  },
})

console.log("Listening on http://localhost:3000")

2026年には Vercel、Cloudflare、Railway、Fly.io といった PaaS がすべて Bun ビルドランタイムを一級サポートしており、韓国では Toss の一部サイドプロジェクトとライブバックエンド、日本ではメルカリと LayerX の一部マイクロサービスが Bun で運用されている。

5. Deno 2.x — npm · jsr 互換、Permissions、Deno Deploy

Deno は Ryan Dahl が Node を作ったあとに「10 の後悔」を整理して 2020年にリリースしたランタイムだ。1.x の時期は「npm 非互換」が大きな足かせだったが、2.0(2024年10月)以降は空気が変わった。

2.x の要点:

// deno.json で依存を宣言 + 権限分離で実行
// $ deno run --allow-net --allow-env main.ts
import { Hono } from "jsr:@hono/hono"
import { z } from "npm:zod@4"

const app = new Hono()

const UserSchema = z.object({ id: z.string(), email: z.string().email() })

app.post("/users", async (c) => {
  const body = UserSchema.parse(await c.req.json())
  return c.json({ ok: true, user: body })
})

Deno.serve({ port: 8000 }, app.fetch)

2026年時点の Deno は jsr.io パッケージレジストリを定着させ、「TypeScript 優先のセキュアなランタイム」というアイデンティティを確立した。ただし採用率は依然として Node・Bun より低く、主な用途はエッジ・CLI・スクリプト領域だ。

6. パッケージマネージャ — npm 11 · pnpm 10 · Yarn 5 Berry · Bun

2026年5月時点で、JavaScript のパッケージマネージャ4種はそれぞれの領域を確立した。

マネージャバージョン特徴
npm11Node 同梱、レジストリ標準、シンプル
pnpm10シンボリックリンクベース、ディスク節約、モノレポ
Yarn5 Berry (PnP/nm)Plug'n'Play、エンタープライズ
Bun1.2最速、Bun ランタイムと統合

pnpm 10 の変化が最も興味深い。pnpm install の lifecycle script 実行をデフォルトでブロック(セキュリティ)、pnpm dlx が npx の代替として一般化、catalogs 機能でモノレポの依存バージョンを中央管理。npm 11 はワークスペースコマンドの一貫性と audit fix の精度を改善し、Yarn 5 は Plug'n'Play をデフォルトに据えつつ nodeLinker: node-modules オプションで互換モードを安定化させた。

# pnpm 10 catalogs の例 (pnpm-workspace.yaml)
# catalog を定義 → 各パッケージで catalog:default を参照
#
# packages:
#   - 'apps/*'
#   - 'packages/*'
# catalog:
#   typescript: ^5.6.0
#   zod: ^4.0.0

# ワークスペース全体にパッケージを追加
pnpm -r add zod@catalog:

# Bun ワークスペース
bun install --frozen-lockfile

# Yarn 5 (Berry) Plug'n'Play
yarn install --immutable

ベンチマーク上は Bun が最も速い(コールドインストール比較で npm の25倍)が、韓国・日本の大規模モノレポでは pnpm 10 が最も広く使われている。Toss、クーパン、メルカリ、freee はいずれも pnpm ベース。

7. Hono — V8 isolate で最も使われるエッジフレームワーク

Hono(炎)は、日本在住の韓国系開発者 Yusuke Wada によって作られた超軽量 Web フレームワークだ。Express スタイルの API に ultra-fast ルータ、そしてあらゆるランタイムで動く互換性を組み合わせている。

対応ランタイムが極めて広い: Cloudflare Workers、Deno、Bun、Node.js、AWS Lambda、Vercel Edge、Fastly Compute。同じコードをそのまま移植できることが核心的価値。

2026年5月時点の主要機能:

// Hono で書く最小限の REST API
import { Hono } from "hono"
import { zValidator } from "@hono/zod-validator"
import { z } from "zod"

const app = new Hono()

const CreateUserSchema = z.object({
  email: z.string().email(),
  name: z.string().min(1),
})

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

app.post("/users", zValidator("json", CreateUserSchema), async (c) => {
  const body = c.req.valid("json")
  // body は { email: string; name: string } として推論される
  return c.json({ ok: true, user: body }, 201)
})

// Cloudflare Workers、Deno、Bun、Node のいずれも同一コード
export default app

Cloudflare が公式採用した結果、2026年時点で Workers コードの70%以上が Hono で書かれており、Vercel、Deno Deploy、Bun、Fastly でも急速に広がっている。npm ダウンロードは2024年の週50万から2026年5月の週350万へと約7倍に成長。

8. Elysia — Bun 専用の高性能フレームワーク

Elysia は Hono と比較されることが多いが方向性は異なる。Bun に特化して JIT 最適化可能なコード生成を積極的に活用し、型システムを通じた Eden によるエンドツーエンドの型安全を提供する。

差別化ポイント:

import { Elysia, t } from "elysia"

const app = new Elysia()
  .get("/", () => "Hello Elysia")
  .post(
    "/users",
    ({ body }) => ({ ok: true, user: body }),
    {
      body: t.Object({
        email: t.String({ format: "email" }),
        name: t.String({ minLength: 1 }),
      }),
    }
  )
  .listen(3000)

export type App = typeof app
// クライアントは Eden 経由で App 型をそのまま import

ベンチマーク上、単純な JSON 応答スループットは Bun 上の Hono に対して1.5倍、Express に対して20倍以上速い。ただし Bun 依存が強く、マルチランタイム戦略のチームには不向き。

9. NestJS 11 — エンタープライズ標準、Angular 風 DI

NestJS は Kamil Myśliwiec が 2017年に作った Angular スタイル DI コンテナベースのバックエンドフレームワークだ。2026年5月時点でメジャーは 11.x で、次の変化が核心:

NestJS の価値は「大規模チームが規約衝突なしに一緒に働ける構造」だ。Module / Controller / Service / Provider の階層が明確で、依存性注入が強制されるため単体テストが容易になる。

import { Controller, Get, Post, Body, Injectable, Module } from "@nestjs/common"
import { IsEmail, MinLength } from "class-validator"

class CreateUserDto {
  @IsEmail()
  email!: string

  @MinLength(1)
  name!: string
}

@Injectable()
class UsersService {
  private users: CreateUserDto[] = []
  create(dto: CreateUserDto) {
    this.users.push(dto)
    return dto
  }
  findAll() {
    return this.users
  }
}

@Controller("users")
class UsersController {
  constructor(private readonly users: UsersService) {}

  @Get()
  list() {
    return this.users.findAll()
  }

  @Post()
  create(@Body() body: CreateUserDto) {
    return this.users.create(body)
  }
}

@Module({
  controllers: [UsersController],
  providers: [UsersService],
})
export class AppModule {}

韓国ではカカオエンタープライズ、クーパンの一部チーム、ヤノルジャが、日本ではサイバーエージェント、LINE の一部サービスが NestJS ベース。「Spring Boot に慣れた Java エンジニアが TS へ移るのに最も馴染みやすい形」という評価が多い。

10. Fastify 5 · Express 5 · h3/Nitro · Encore.ts — その他のバックエンドフレームワーク

Fastify 5 は Matteo Collina と Tomas Della Vedova が作った Node 標準の高性能フレームワークだ。Express の2倍以上速く、JSON スキーマベースの検証、豊富なプラグインエコシステムが強み。2026年5月時点の v5 で ESM / TypeScript 型の改善が大きい。

Express 5 は17年ぶりのメジャーアップデート(2024年 GA)。非同期エラー処理の標準化、Express Router のライブラリ分離、ボディパーサ同梱。それでも npm ダウンロード1位のバックエンドフレームワーク。

h3/Nitro は Nuxt チーム(UnJS)が作った H3 ASGI 風ハンドラとその上に乗る Nitro サーバビルダ。Nuxt は Nitro 上で構築されており、一般のバックエンドとしても直接使える。Cloudflare / Vercel / Deno / Bun の各アダプタを提供。

Encore.ts は「バックエンドデータインフラまでコードで定義する」フルスタックバックエンド。DB・キュー・cron・API をすべて TypeScript 型で宣言し、Encore がインフラをプロビジョニング。利用は小さいが DX が話題。

// Fastify 5 + Zod 4 プラグイン
import Fastify from "fastify"
import { z } from "zod"
import { serializerCompiler, validatorCompiler, ZodTypeProvider } from "fastify-type-provider-zod"

const app = Fastify({ logger: true }).withTypeProvider<ZodTypeProvider>()
app.setValidatorCompiler(validatorCompiler)
app.setSerializerCompiler(serializerCompiler)

app.route({
  method: "POST",
  url: "/users",
  schema: {
    body: z.object({ email: z.string().email(), name: z.string().min(1) }),
    response: { 201: z.object({ ok: z.literal(true) }) },
  },
  handler: async (req, reply) => {
    // req.body の型は z.infer<...> 経由で自動推論
    return reply.code(201).send({ ok: true })
  },
})

await app.listen({ port: 3000 })

11. Effect — TypeScript の関数型エフェクトシステム

Effect (旧 Effect-TS) は Michael Arnaldi が主導する、ZIO / Cats Effect / RIO に着想を得た TypeScript のエフェクトシステムライブラリだ。2024年に 3.0 が出て、2026年5月時点では 3.10 系で安定化している。

主要コンセプト:

import { Effect, Schedule, Console, Layer } from "effect"

const fetchUser = (id: string) =>
  Effect.tryPromise({
    try: () => fetch(`/api/users/${id}`).then((r) => r.json()),
    catch: (e) => new Error(`fetch failed: ${String(e)}`),
  })

const program = Effect.gen(function* () {
  const user = yield* fetchUser("u_1").pipe(
    Effect.retry(Schedule.exponential("100 millis").pipe(Schedule.compose(Schedule.recurs(3))))
  )
  yield* Console.log(`got user: ${JSON.stringify(user)}`)
})

Effect.runPromise(program)

Effect をフルスタックで採用したチーム(例: Effectful Tech、一部のフィンテック)は「例外が消えた」と表現する。依存・エラー・並行性のすべてが型に表現されるため、大規模なバックエンドのリファクタリングが安全になる。ただし学習曲線は急で、小規模チームには過剰なツールと評されることもある。

12. tRPC 11 — エンドツーエンドの型安全 RPC

tRPC は Alex Johansson が作った「REST や GraphQL なしに TypeScript の型だけでクライアントとサーバを結ぶ」RPC ツールだ。2024年に v11 が出て、React Query v5、Tanstack Router、Next.js App Router との統合が完成した。

主要特性:

// サーバ
import { initTRPC } from "@trpc/server"
import { z } from "zod"

const t = initTRPC.create()

export const appRouter = t.router({
  user: t.router({
    byId: t.procedure
      .input(z.object({ id: z.string() }))
      .query(({ input }) => ({ id: input.id, name: "Toss user" })),

    create: t.procedure
      .input(z.object({ email: z.string().email(), name: z.string() }))
      .mutation(({ input }) => ({ ok: true, ...input })),
  }),
})

export type AppRouter = typeof appRouter

// クライアント
// import type { AppRouter } from "./server"
// const trpc = createTRPCClient<AppRouter>({...})
// const u = await trpc.user.byId.query({ id: "u_1" })
// → u は { id: string; name: string } として自動推論

tRPC は同じモノレポで BE/FE を一緒に書くフルスタックチームに圧倒的な DX を提供する。韓国の Toss、日本のメルカリの一部フルスタックチームが採用。ただし他言語・外部クライアントとの連携には GraphQL / OpenAPI のほうが適する。

13. GraphQL — Pothos · Yoga · Apollo Server 5

GraphQL は2015年に Facebook が公開したクエリ言語で、TypeScript エコシステムの中でも最も成熟した分野の一つだ。2026年の中心スタック:

// Pothos + GraphQL Yoga (Hono 上)
import SchemaBuilder from "@pothos/core"
import { createYoga } from "graphql-yoga"
import { Hono } from "hono"

const builder = new SchemaBuilder({})

builder.queryType({
  fields: (t) => ({
    hello: t.string({
      args: { name: t.arg.string({ required: true }) },
      resolve: (_, { name }) => `Hello, ${name}`,
    }),
  }),
})

const yoga = createYoga({ schema: builder.toSchema() })
const app = new Hono()
app.all("/graphql", (c) => yoga.fetch(c.req.raw, c.env))

export default app

大規模 BFF パターン、モバイルクライアントを伴うバックエンド、マイクロフロントエンドを束ねる GraphQL Gateway などでは依然として GraphQL が強い。

14. 検証ライブラリ — Zod 4 · ArkType · Valibot · Effect Schema · TypeBox

実行時検証は TypeScript バックエンドの中核インフラだ。5種を比較する。

ライブラリバンドルサイズ特徴
Zod 4中最も使われる、エコシステム豊富、v4 でサイズ半減
ArkType小TypeScript ライクな構文で検証を表現
Valibot非常に小さいツリーシェイク親和、関数合成
Effect Schema中Effect 統合、双方向デコーダ
TypeBox小JSON Schema を直接生成、Elysia のデフォルト

Zod 4 は2025年に正式リリースで v3 比でバンドルサイズ50%減、ケースによっては検証速度3倍向上。ArkType は type({ email: "string.email", age: "number<150" }) のような TS 構文を文字列で表現するユニークなアプローチ。Valibot はツリーシェイクで未使用の検証コードをビルドから除去。Effect Schema は Effect エフェクトシステムと自然に連携。TypeBox は JSON Schema が即座に必要な場合(Fastify、Elysia)に第一候補。

// Zod 4 / Valibot / ArkType で同じスキーマを比較
import { z } from "zod"
const ZodUser = z.object({ email: z.string().email(), age: z.number().min(0).max(150) })

import * as v from "valibot"
const ValibotUser = v.object({
  email: v.pipe(v.string(), v.email()),
  age: v.pipe(v.number(), v.minValue(0), v.maxValue(150)),
})

import { type } from "arktype"
const ArkUser = type({ email: "string.email", age: "0 <= number <= 150" })

// いずれも同じ結果: { email: string; age: number }

2026年5月の npm ダウンロード基準では Zod が圧倒的1位、Valibot が2位で急速に伸び、ArkType がダークホースとして台頭中。

15. ORM — Drizzle 0.40 · Prisma 6 · Kysely · MikroORM 6

JS / TS の ORM 領域は2024–2025年に最も大きく動いた分野だ。

// Drizzle 0.40 — スキーマとクエリ
import { drizzle } from "drizzle-orm/postgres-js"
import { pgTable, serial, text, timestamp } from "drizzle-orm/pg-core"
import { eq } from "drizzle-orm"
import postgres from "postgres"

export const users = pgTable("users", {
  id: serial("id").primaryKey(),
  email: text("email").notNull().unique(),
  name: text("name").notNull(),
  createdAt: timestamp("created_at").defaultNow(),
})

const sql = postgres(process.env.DATABASE_URL!)
const db = drizzle(sql)

// 推論型: { id: number; email: string; name: string; createdAt: Date }[]
const rows = await db.select().from(users).where(eq(users.email, "a@toss.im"))

2024年後半から Drizzle は Vercel、Cloudflare、Neon が公式推奨 ORM として採用し、韓国・日本の新規プロジェクトの ORM 選定では Prisma とほぼ同率または優勢。Prisma は Prisma Postgres によって「ORM + DB バンドル」という新ビジネスモデルにフォーカス中。

16. ワークフローエンジン — Temporal · Inngest · Trigger.dev · Hatchet · Restate

長時間実行ワークフロー(承認、決済、バッチ、マルチステップ AI パイプライン)は TS バックエンドの最大の難所の一つだった。2026年では次の5ツールが標準候補。

ツール特徴
Temporal TS SDK最も成熟。ワーカー、タスクキュー、シグナル、永続化されたリトライ
Inngest関数型イベントベース。サーバレス親和
Trigger.devTS-only。コードがそのままジョブ
HatchetPostgres ベースの OSS キュー + ワークフロー
RestateDurable execution + RPC + state
// Inngest ワークフロー (マルチステップ + リトライ + 待機)
import { Inngest } from "inngest"

const inngest = new Inngest({ id: "toss-app" })

export const onboardUser = inngest.createFunction(
  { id: "onboard-user", retries: 3 },
  { event: "user/signup" },
  async ({ event, step }) => {
    await step.run("send-welcome-email", async () => {
      // このステップは失敗時に自動リトライ、結果は永続化される
      return sendEmail(event.data.email)
    })

    await step.sleep("wait-1-day", "24h")

    await step.run("send-day1-tips", async () => sendDay1Tips(event.data.email))
  }
)

各ツールは「ステップ結果をどこに永続化するか」が中心の差別化軸だ。Temporal は自社サーバ、Inngest はクラウド SaaS + OSS、Trigger.dev はセルフホスト可能、Hatchet は Postgres、Restate は自社の分散 KV。

17. テスト — Vitest 3 · Bun test · node:test · Playwright · Jest

テストツールはビルドツールと並んで最も速く統合が進んでいる領域だ。

// Vitest 3 単体 + Playwright コンポーネントテスト
import { describe, it, expect } from "vitest"
import { sum } from "./math"

describe("sum", () => {
  it("adds two numbers", () => {
    expect(sum(1, 2)).toBe(3)
  })

  it("handles negatives", () => {
    expect(sum(-1, -2)).toBe(-3)
  })
})

// Playwright (e2e/login.spec.ts)
// import { test, expect } from "@playwright/test"
// test("login", async ({ page }) => {
//   await page.goto("/login")
//   await page.getByLabel("email").fill("a@b.com")
//   await page.click("text=Sign in")
//   await expect(page.locator("h1")).toHaveText("Welcome")
// })

Vitest の最大の強みは Vite と同じ変換パイプラインを共有する点。Next.js・Remix・SvelteKit・Astro との単体テストがシームレスに動く。

18. ビルドツール — tsup · tsc · esbuild · swc · oxc · Bun bundle

ライブラリ・アプリのビルドツールも多層構造になっている。

ツール役割特徴
tsc型チェック + コンパイル標準、最も遅い
tsupライブラリバンドラesbuild 上、設定最小
esbuildトランスパイラGo ベース、非常に速い
swcトランスパイラRust ベース、Next.js 同梱
oxcTS・linter・formatterRust ベース、次世代
Bun bundleバンドラZig ベース、ランタイム統合

2026年5月時点でバックエンドビルドワークフローの事実上の標準は「tsc で型チェック、tsup / esbuild で出力」の組合せ。oxc は oxlint(速い ESLint 代替)とともに急成長中で、一部チームでは ESLint を oxlint に置き換えて lint 時間を30分の1に短縮している。

# ライブラリ: tsup
pnpm add -D tsup
pnpm tsup src/index.ts --format esm,cjs --dts

# アプリ: esbuild を直接
pnpm add -D esbuild
node --experimental-strip-types build.ts

# oxc ベース lint
pnpm add -D oxlint
pnpm oxlint .

19. モノレポ — Turborepo · Nx · Bun workspaces · pnpm workspaces

複数の TS パッケージを一つのリポジトリで管理するモノレポツールの比較。

多くのチームは「パッケージマネージャは pnpm / Bun、タスクランナーは Turborepo / Nx」の組合せに収まる。

20. AI / ML SDK — Vercel AI SDK · transformers.js · vec-tor

TS バックエンドに LLM・埋め込みを統合する標準が確立された。

// Vercel AI SDK で LLM レスポンスをストリーミング + ツール呼び出し
import { generateText, tool } from "ai"
import { anthropic } from "@ai-sdk/anthropic"
import { z } from "zod"

const result = await generateText({
  model: anthropic("claude-3-5-sonnet"),
  messages: [{ role: "user", content: "What is the weather in Seoul?" }],
  tools: {
    getWeather: tool({
      description: "Get weather for a city",
      parameters: z.object({ city: z.string() }),
      execute: async ({ city }) => ({ city, tempC: 22 }),
    }),
  },
  maxSteps: 5,
})

console.log(result.text)

LLM 統合が標準化されたことで、バックエンドの TS 開発者は LangChain 級の抽象化を享受するために Python へジャンプする必要がなくなった。

21. 韓国の採用 — Toss · ネイバー · クーパン · カカオ

Toss (トス): フロントエンドは全社 TypeScript 100%。バックエンドも段階的に Spring Boot の一部を NestJS / Hono へ移行中。2024年以降、Toss Tech ブログに NestJS 運用経験、モノレポ構造、ts-pattern 活用事例などが多数公開されている。Toss 証券の一部サイド BFF は Bun で運用。

ネイバー: Whale ブラウザ、LINE WORKS、ネイバーペイの一部 BFF・ゲートウェイレイヤが TypeScript ベース。社内モノレポツールを自社開発。一部チームは Hono + Cloudflare でエッジ API を運用。

クーパン: フロントエンドはフル TypeScript。バックエンドの新規マイクロサービスの一部を NestJS で実装。クーパンプレイの BFF が代表事例。

カカオ: カカオエンタープライズ、カカオペイの一部チームで NestJS を採用。カカオスタイルはフルスタック TS。

韓国市場の特徴は「SI / 銀行は依然として Java / Spring、フィンテック・コマース・コンテンツは段階的に TS へ転換」というパターンだ。

22. 日本の採用 — メルカリ · freee · LayerX · CyberAgent

メルカリ (Mercari): 多数のマイクロサービスが Go ベースだが、新規 BFF・メディア変換サービスに TypeScript マイクロサービスを導入。一部サービスで Bun を採用。自社の GraphQL Gateway は TS。

freee: 会計 SaaS。フロントエンド TS + Rails バックエンドの一部を TS へ移行中。NestJS と tRPC を利用。

LayerX: インボイス SaaS「バクラク」。TypeScript バックエンドの比率が非常に高い。Effect と Drizzle 採用事例を公開。

CyberAgent: AbemaTV、タップル など多くの子会社。NestJS・Hono を利用。自社モノレポツールを運用。

日本市場では「Go・Rails など多様なスタックを維持しながら TS 領域を BFF・リアルタイム・エッジへ拡大する」パターンが強い。

23. セキュリティ — 依存性監査、ロックファイル、権限モデル

TS バックエンドのサプライチェーンセキュリティは2024年の xz utils 事件以降、再び注目されている。

2026年には npm・jsr の両方で attestation(署名されたビルド出自)が既定となり、大企業ほど自前の npm レジストリミラー(Verdaccio、Sonatype Nexus、Artifactory)を立てて外部依存をキャッシュしている。

24. 観測 — OpenTelemetry · pino · Sentry

TS バックエンドの観測標準は次のように整理された。

// OpenTelemetry + Pino
import { NodeSDK } from "@opentelemetry/sdk-node"
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http"
import { getNodeAutoInstrumentations } from "@opentelemetry/auto-instrumentations-node"
import pino from "pino"

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: "http://otel-collector:4318/v1/traces" }),
  instrumentations: [getNodeAutoInstrumentations()],
})
sdk.start()

export const log = pino({ level: process.env.LOG_LEVEL || "info" })

Hono と Elysia は OpenTelemetry ミドルウェアパッケージを提供しており、NestJS には公式 OpenTelemetry モジュールがある。

25. 比較表 — 実選択基準

最後に大きな絵を比較表で整理する。

Web フレームワーク

フレームワークランタイムDI検証おすすめシナリオ
HonoあらゆるランタイムミドルウェアZod/Valibot/TypeBoxエッジ、マルチランタイム
ElysiaBun 専用デコレータTypeBoxBun フルスタック、最大性能
NestJS 11Node/BunAngular スタイルclass-validator/Zodエンタープライズ、大規模チーム
Fastify 5NodeプラグインJSON Schema/Zod高性能標準 Node
Express 5Nodeなし自由レガシー・互換性

ORM

ORMスタイルマイグレーションエッジサポート
Drizzle 0.40+SQL DSLビルド時生成一級
Prisma 6コードファースト自社 Migrate一部(Driver Adapter)
Kyselyクエリビルダ手動・外部一級
MikroORM 6Unit of Work自社一部

検証

ライブラリバンドルサイズDSL強み
Zod 4中メソッドチェーンエコシステム
Valibot非常に小さい関数合成ツリーシェイク
ArkType小TS ライク文字列可読性
Effect Schema中エフェクト統合Effect 利用時
TypeBox小JSON SchemaOpenAPI / Elysia

26. 移行ロードマップ — レガシー Node から 2026 スタックへ

既存の Express + TypeORM ベースのサービスを2026スタックへ移すには、次の順序が合理的だ。

  1. TypeScript 5.6+ へアップグレードし、strict: true、noUncheckedIndexedAccess: true を有効化。
  2. パッケージマネージャを pnpm 10 へ切り替え、ロックファイルを再生成、catalog で依存バージョンを統一。
  3. テストを Vitest 3 へ移行(Jest 互換 API)。
  4. 入力検証を Zod 4 で標準化。ハンドラの入出力に Zod スキーマを強制。
  5. 新モジュールは Hono または Fastify 5 で構築。Express ルータを段階的に移す。
  6. ORM を Drizzle または Prisma 6 へ切り替え。最大の作業。
  7. 観測を OpenTelemetry に統合、エラー追跡は Sentry。
  8. CI で oxlint + tsc + vitest を並列実行し、ビルド時間を短縮。
  9. 長時間処理は Inngest または Temporal へ分離。
  10. Effect の導入は別意思決定。すべてのチームに合うわけではないため慎重に。

このロードマップの核心は「一度にすべてを変えないこと」だ。一段ずつ、測定可能な指標(ビルド時間、p99 レイテンシ、エラー率)で効果を検証する。

27. まとめ — 2026年の選択

2026年の TypeScript バックエンドはもはや「Node + Express + Jest」一行ではない。ランタイムを選び、フレームワークを選び、ORM と検証とワークフローとビルドをそれぞれ選べる。選択肢が多いのは良いことだが、同時に「どの組合せが自分たちのチームの運用環境に合うか」という問いに答えなければならないということでもある。

この記事の結論を一言でまとめると: 新規プロジェクトなら「Bun または Node 22 + Hono + Drizzle + Zod 4 + Vitest 3 + pnpm 10」が最も摩擦なく始められるデフォルトだ。エンタープライズ規模なら NestJS 11 を、関数型エフェクトが欲しいなら Effect を、エッジなら Hono + Cloudflare を、フルスタックの単一モノレポなら tRPC 11 を追加する。

選択の自由には責任が伴う。どのツールを選んだとしても、1年後にチームが楽しく運用できるかをまず問うことだ。

References

コメント

まだコメントはありません。

ログインするとコメントできます