💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> 「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 | 型推論・実行時検証 |

| ORM | Drizzle 0.40, Prisma 6, Kysely, MikroORM 6 | SQL 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 宣言の例

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 の変化のうち、バックエンドに直接影響するものを整理する。

- **組み込み `fetch` と `WebSocket`**: undici 由来の fetch は 22 で安定化、WebSocket クライアントも標準化。

- **`node:test`**: 組み込みテストランナーが 22 で安定。Jest や Mocha なしでも軽い単体テストが可能。

- **`--watch` モード**: `node --watch app.ts` だけでファイル変更検知・再起動。nodemon の代替。

- **`--env-file=.env`**: dotenv なしでも環境変数ファイルを読み込み。

- **Permission Model**: `--permission --allow-fs-read=...` のような権限分離。Deno スタイル。

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 の主な特徴:

- **Node 互換性**: `node_modules`、CommonJS、ESM、`package.json` の全フィールドをそのままサポート。Express、Fastify、NestJS、Next.js のほとんどはそのまま動く。

- **速度**: コールドスタートが Node に比べて約4倍、`bun install` は npm 比で最大25倍(公式ベンチマーク基準)。

- **組み込みバンドラ**: `bun build` コマンドで esbuild 級のバンドリングを別ツールなしに。

- **組み込みテスト**: `bun test` は Jest 互換 API を提供。

- **組み込み SQLite**: `import { Database } from "bun:sqlite"`。

- **組み込み Redis / HTTP / WebSocket**: `Bun.serve()`、`Bun.redis()` で外部依存を最小化。

- **bun.lockb から bun.lock へ**: 1.2 でテキストロックファイルのオプションを追加。コードレビュー親和性が向上。

// Bun.serve() で HTTP サーバ (Hono なしの純 Bun)

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 の要点:

- **npm / jsr 互換**: `import express from "npm:express"`、`import zod from "jsr:@zod/zod"` のように直接インポート。`node_modules` の自動生成もオプションで提供。

- **Workspace モノレポ**: `deno.json` の workspaces フィールド。

- **Permission モデル**: デフォルトで権限なし。`--allow-net`、`--allow-read` などで許可。

- **`deno compile`**: シングルバイナリ生成。Lambda / Worker デプロイに最適。

- **Deno Deploy**: 世界35リージョンの V8 isolate ベースのエッジプラットフォーム。

- **組み込み `deno test`、`deno lint`、`deno fmt`**。

// deno.json で依存を宣言 + 権限分離で実行

// $ deno run --allow-net --allow-env main.ts

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種はそれぞれの領域を確立した。

| マネージャ | バージョン | 特徴 |

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

| npm | 11 | Node 同梱、レジストリ標準、シンプル |

| pnpm | 10 | シンボリックリンクベース、ディスク節約、モノレポ |

| Yarn | 5 Berry (PnP/nm) | Plug'n'Play、エンタープライズ |

| Bun | 1.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月時点の主要機能:

- **Ultra-fast Router**: TrieRouter / RegExpRouter / LinearRouter — 環境ごとに最適なルータを自動選択。

- **型安全なミドルウェア**: ミドルウェアがコンテキストに加えた値が次のハンドラの型に伝播。

- **`hono/zod-validator`、`hono/typebox-validator`**: 検証ライブラリの公式統合。

- **`hono/jsx`**: React 非依存のサーバーサイド JSX レンダリング。

- **HonoX**: Hono ベースのメタフレームワーク (Next.js 風フルスタック代替)。

// Hono で書く最小限の REST API

const app = new Hono()

const CreateUserSchema = z.object({

email: z.string().email(),

})

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** によるエンドツーエンドの型安全を提供する。

差別化ポイント:

- **Bun ネイティブ**: 他のランタイム互換を諦め、Bun 上で最大性能。

- **コンパイル時ルーティング**: コード生成で最速のルーティング。

- **Eden**: サーバ側のルート型がクライアントでそのまま推論される tRPC 類似機能。

- **TypeBox 統合**: 検証ライブラリとして TypeBox がデフォルト。

- **OpenAPI 自動生成**。

const app = new Elysia()

.get("/", () => "Hello Elysia")

.post(

"/users",

({ body }) => ({ ok: true, user: body }),

{

body: t.Object({

email: t.String({ format: "email" }),

}),

}

)

.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 で、次の変化が核心:

- **Express 5 と Fastify 5 の両方を一級サポート**: アダプタを選択可能。

- **TypeScript 5.6 + Stage 3 デコレータの正式サポート**。

- **Microservices・GraphQL・WebSocket・Bull キューモジュールの標準化**。

- **OpenAPI / Swagger 自動生成の安定性向上**。

- **Standalone アプリケーション**モード — HTTP なしの CLI ツールとしても利用可能。

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

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 プラグイン

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 系で安定化している。

主要コンセプト:

- **`Effect<A, E, R>`**: 成功値 `A`、失敗型 `E`、依存 `R`。型にエラーと依存が明示される。

- **構造化並行性 (Structured Concurrency)**: `Effect.all`、`Effect.race`、`Effect.fork` による fiber ベース並行性。

- **Retry / Schedule**: `Effect.retry(Schedule.exponential("100 millis"))` のような宣言的リトライ。

- **Layer**: 依存性注入システム。モジュール間で R を合成。

- **Schema**: 検証・デコード・エンコードを統合(Zod の代替)。

- **STM**: ソフトウェアトランザクショナルメモリ。

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。

- **Procedures**: query、mutation、subscription の三種。

- **アダプタ**: Express、Fastify、Next.js、Bun、Hono、AWS Lambda をすべてサポート。

- **Links**: HTTP、WebSocket、batch、splitLink。

- **v11 の変化**: AbortSignal サポート、出力 transformer の強化、FormData 入力。

// サーバ

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 5**: The Guild がメンテナンスする軽量 GraphQL サーバ。Hono / Fastify アダプタ。

- **Apollo Server 5**: 最も広く使われる GraphQL サーバ。2025年の 5.0 で Express 5 / Fastify 5 アダプタ。

- **GraphQL Codegen**: スキーマから TS 型と React Query フックを生成。

// Pothos + GraphQL Yoga (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 で同じスキーマを比較

const ZodUser = z.object({ email: z.string().email(), age: z.number().min(0).max(150) })

const ValibotUser = v.object({

email: v.pipe(v.string(), v.email()),

age: v.pipe(v.number(), v.minValue(0), v.maxValue(150)),

})

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+**: 最も急成長。SQL DSL をそのまま TypeScript で表現。ビルド時マイグレーション生成。エッジランタイムを一級サポート。

- **Prisma 6**: 最も広く使われる。2025年から **Rust エンジンを deprecate** し、TypeScript-only へ移行中。Prisma Postgres(自社サーバレス DB)が登場。

- **Kysely**: 型安全な SQL ビルダ。ORM ではなくクエリビルダ寄りのミニマリズム。Drizzle よりさらに SQL に近い。

- **MikroORM 6**: TypeORM の空席を埋めたデータマッパ ORM。Unit of Work パターン。

- **TypeORM**: 引き続き使われているが新規採用は減少。NestJS のデコレータ親和 ORM。

// Drizzle 0.40 — スキーマとクエリ

export const users = pgTable("users", {

id: serial("id").primaryKey(),

email: text("email").notNull().unique(),

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.dev | TS-only。コードがそのままジョブ |

| Hatchet | Postgres ベースの OSS キュー + ワークフロー |

| Restate | Durable execution + RPC + state |

// 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**: Vite ベースの TS 親和テストランナー。Jest 互換 API。2025–2026年で事実上の標準。

- **Bun test**: Bun ランタイム同梱。Vitest 互換 API。Bun 利用チームでは第一候補。

- **`node:test`**: Node 22+ 組み込み。外部依存なしで軽量テスト。

- **Playwright**: ブラウザ E2E の標準。Microsoft メンテナンス。

- **Jest 30**: 引き続き利用されている。ただし新規プロジェクトでの採用は減少。

// Vitest 3 単体 + Playwright コンポーネントテスト

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 同梱 |

| oxc | TS・linter・formatter | Rust ベース、次世代 |

| 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 パッケージを一つのリポジトリで管理するモノレポツールの比較。

- **Turborepo 2.x**: Vercel メンテナンス。タスクキャッシュと並列実行が強み。

- **Nx 20**: 豊富なプラグインとコードジェネレータ。エンタープライズで広く使われる。

- **pnpm workspaces 10**: パッケージマネージャ自身のワークスペース。

- **Bun workspaces**: 速い install、シンプル。

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

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

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

- **Vercel AI SDK 4**: OpenAI / Anthropic / Google / Mistral / Bedrock などの抽象化。ストリーミング、ツール呼び出し、RAG を一級サポート。

- **transformers.js**: Xenova が作った Hugging Face モデルをブラウザ・Node で実行するライブラリ。ONNX Runtime 由来。

- **vec-tor / 自前ベクトルライブラリ**: Drizzle / Prisma + pgvector の組合せで埋め込みを保存。

// Vercel AI SDK で LLM レスポンスをストリーミング + ツール呼び出し

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 事件以降、再び注目されている。

- **`npm audit` / `pnpm audit`**: 既知 CVE のスキャン。

- **`pnpm install` の lifecycle script ブロック(10.x)**: 悪意ある postinstall を阻止。

- **Sigstore / Provenance**: npm パッケージのビルド出自を検証。

- **Node 22 の Permission Model**: `--allow-fs-read` のようなフラグでファイルシステム分離。

- **Deno の既定権限拒否**。

- **Snyk、Socket、GitGuardian**: 外部セキュリティスキャナ。

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

24. 観測 — OpenTelemetry · pino · Sentry

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

- **OpenTelemetry JS SDK**: トレース・メトリクス・ログの標準。Node・Bun の両方をサポート。

- **pino**: Fastify と組み合わせて最も速い JSON ロガー。

- **Sentry**: エラー追跡、パフォーマンス監視、セッションリプレイ。

- **Datadog · New Relic · Grafana Cloud**: 商用 APM。

// OpenTelemetry + 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 フレームワーク**

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

**ORM**

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

| MikroORM 6 | Unit of Work | 自社 | 一部 |

**検証**

| ライブラリ | バンドルサイズ | DSL | 強み |

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

| Zod 4 | 中 | メソッドチェーン | エコシステム |

| ArkType | 小 | TS ライク文字列 | 可読性 |

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

- TypeScript: [typescriptlang.org](https://www.typescriptlang.org/)

- Node.js: [nodejs.org](https://nodejs.org/)

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

- Deno: [docs.deno.com](https://docs.deno.com/)

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

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

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

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

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

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

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

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

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

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

- Vitest: [vitest.dev](https://vitest.dev/)

- pnpm: [pnpm.io](https://pnpm.io/)

- Fastify: [fastify.dev](https://fastify.dev/)

- Express: [expressjs.com](https://expressjs.com/)

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

- Temporal TS SDK: [docs.temporal.io](https://docs.temporal.io/dev-guide/typescript)

- Inngest: [inngest.com](https://www.inngest.com/)

- Vercel AI SDK: [sdk.vercel.ai](https://sdk.vercel.ai/)

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

- Mercari Engineering: [engineering.mercari.com](https://engineering.mercari.com/)