# Prisma vs Drizzle vs TypeORM vs Kysely 技術選定ガイド：型安全TypeScript ORM/クエリビルダの違いと選び方（2026）

> TypeScriptのDB層をどれで作るか——Prisma・Drizzle・TypeORM・Kyselyを公式の事実に基づき比較する技術選定ガイド。スキーマ定義（DSL/コード生成 vs 推論 vs デコレータ）、マイグレーション、型安全のアプローチ、エッジ/軽量性、成熟度、ユースケース別の推奨を、Prisma v7のRustフリー化も踏まえて、案件で迷わない判断軸として整理します。

- 公開日: 2026-06-26
- 著者: 友田 陽大
- タグ: Prisma, Drizzle, TypeScript, アーキテクチャ設計, 型安全
- URL: https://tomodahinata.com/blog/prisma-vs-drizzle-vs-typeorm-kysely-orm-comparison-guide

## 要点

- 4つは別カテゴリ。Prisma=スキーマ駆動ORM（DSL＋コード生成）、Drizzle=SQLライクな軽量ORM（TS推論）、TypeORM=デコレータORM（ActiveRecord/DataMapper）、Kysely=型安全クエリビルダ（ORMではない）
- 型安全の出どころが違う。Prismaは生成、Drizzle/Kyselyは推論、TypeORMはデコレータ。どれもas/anyで崩さない規律が前提
- 迷ったら：宣言的設計＋厚いマイグレーション＋マネージド連携ならPrisma、SQL透明性と軽量・エッジならDrizzle、デコレータ/NestJS文化ならTypeORM、生SQL志向＋最小抽象ならKysely
- Prisma v7はRustフリー化（公式ベンチで最大3.4倍・バンドル約90%減・driver adapter必須）でエッジ/サーバーレスの弱点を大きく解消した
- 公式のツール間移行ガイドは存在しない。乗り換えはデータ層の抽象化と段階移行で。選定は宗教戦争ではなくプロジェクト制約で決める

---

「TypeScript のバックエンドで、DB層を何で作るか」——この一問は、その後の開発速度・型安全性・運用負荷を長く左右します。候補は主に4つ：**Prisma・Drizzle・TypeORM・Kysely**。SNSでは宗教戦争になりがちですが、実務では**プロジェクトの制約で粛々と決める**のが正解です。この記事は、各ツールの**公式の事実**に基づいて違いを整理し、案件で迷わないための判断軸を提供します。

私は Prisma も Drizzle も本番で使っており、どれかを盲目的に推す立場にはいません。大事なのは「**スキーマを唯一の真実源にし、`as`/`any` で境界をまたがない**」という規律で、それはどのツールでも貫けます。Prisma を深く使う実装は[Prisma ORM 本番運用ガイド（v7）](/blog/prisma-orm-production-guide-type-safe-database-v7-driver-adapters)、Drizzle は[Drizzle ORM 本番運用ガイド](/blog/drizzle-orm-typescript-type-safe-database-production-guide)にあります。

> **この記事のルール**：各ツールの**カテゴリ・スキーマ定義・マイグレーション・型安全の方式**は各公式ドキュメント（2026年6月時点）に基づきます。GitHub スター数などの**成熟度の数値は概算**（公式APIではなく集計値）で、参考程度に。最終判断は必ず各[公式](https://www.prisma.io/docs/orm/overview/introduction/what-is-prisma)で最新を確認してください。

---

## 0. メンタルモデル：4つは「同じ土俵」ではない

最初に誤解を解きます。この4つは**機能で横並び**ではなく、**抽象度のレイヤが違います**。

> **Kysely（クエリビルダ）< Drizzle（SQLライクな軽量ORM）< Prisma / TypeORM（フルORM）**

- **Kysely** は「型安全な**SQLクエリビルダ**」。ORM ではありません。スキーマ管理やリレーション解決の魔法はなく、あなたがSQLの形でクエリを書きます。
- **Drizzle** は「**SQLに近い軽量ORM**」。TypeScriptでスキーマを書き、型は推論で流れます。SQLの透明性を保ちます。
- **Prisma / TypeORM** は「**フルORM**」。リレーション取得・マイグレーション・モデル中心の開発体験まで含みます。

「どれが良いか」ではなく「**どの抽象度が、このプロジェクトに合うか**」を選ぶ——これが出発点です。

---

## 1. 4ツールの素性（公式の事実）

### 1.1 Prisma

- **カテゴリ**：スキーマ駆動の次世代ORM。`.prisma` DSL でデータモデルを宣言し、`prisma generate` で**型付きクライアントを生成**します。
- **マイグレーション**：内蔵（Prisma Migrate）。`schema.prisma` を編集 → `migrate dev`。
- **型安全**：**コード生成**。「モデルの一部の列だけ取得する場合でも完全な型安全」を提供します。
- **v7 の進化**：2025年11月リリース。**Rustエンジンを廃止**しTypeScript＋WASMのクエリコンパイラへ。公式ベンチで**最大3.4倍高速・バンドル約90%減（約14MB→1.6MB）**、**driver adapter が全DBで必須**化、**Vercel Edge / Cloudflare Workers** など**エッジ展開が大幅に簡素化**されました。
- **ベストフィット**：「あらゆる Node.js / TypeScript バックエンド（サーバーレス・マイクロサービス含む）」。スキーマを単一真実源にし、マネージドなマイグレーション/接続プール/キャッシュ込みで素早く本番化したいチーム。

### 1.2 Drizzle

- **カテゴリ**：「ヘッド付きのヘッドレスTypeScript ORM」。「SQLを知っていれば Drizzle を知っている」を掲げる軽量ライブラリで、SQLライクAPIとリレーショナルクエリの両方を持ちます。
- **スキーマ定義**：**TypeScript**（`pgTable()` 等）。`$inferSelect` で型を推論。DSLもコード生成も不要。
- **マイグレーション**：内蔵（**drizzle-kit**）。TSスキーマからSQLを自動生成。
- **型安全**：**推論**（別生成クライアント不要）。
- **軽量性**：公式が「依存ゼロ」「スリム」「サーバーレス対応」を掲げる軽量さが持ち味（具体的なサイズ表記はバージョンで変動）。
- **ベストフィット**：フレームワークのオーバーヘッドなしに型安全なDBアクセスが欲しい、特にサーバーレス/エッジ、SQLに近く居たいチーム。

### 1.3 TypeORM

- **カテゴリ**：**デコレータベースのORM**。「**DataMapper と ActiveRecord の両パターン**」をサポートし、好きな方を選べます。
- **スキーマ定義**：**デコレータ付きクラス**（`@Entity()` / `@PrimaryGeneratedColumn()` / `@Column()`）。
- **マイグレーション**：内蔵（CLI、**自動生成**対応）。
- **型安全**：デコレータ＋「DBモデルの完全な型安全」。TypeScript で一から構築。
- **対応の広さ**：Node.js・ブラウザ・モバイル・デスクトップで動作し、MySQL/PostgreSQL/MariaDB/SQLite/MS SQL Server/Oracle/MongoDB/CockroachDB 等を広くサポート。
- **ベストフィット（編集部）**：デコレータ/ActiveRecord 文化（NestJS、Java/Hibernate、Laravel 出身）に馴染むチーム、最大級のDB・プラットフォーム互換が要る場面。

### 1.4 Kysely

- **カテゴリ**：「**型安全で補完が効く TypeScript SQLクエリビルダ**」。Knex 系の発想で、**ORM ではありません**。Node.js/Deno/Bun で動作。
- **スキーマ/型定義**：DBインターフェース（型）を与えると、選択列・別名・サブクエリの型を**推論**します（インターフェースは手書き、またはサードパーティ `kysely-codegen` で生成）。
- **マイグレーション**：**マイグレーションランナーは内蔵**（`Migrator` / `migrateToLatest()`）。ただし `up`/`down` は**手書き**——スキーマからの自動生成はありません。
- **型安全**：クエリ自体からの**推論**。「結果型は選択した列だけを正しい型で持つ」。
- **ベストフィット（編集部）**：ORM の抽象や自動生成を避け、**生SQLに近い制御＋完全な型安全**が欲しいチーム。

---

## 2. 一望比較

| 観点 | Prisma | Drizzle | TypeORM | Kysely |
| --- | --- | --- | --- | --- |
| カテゴリ | スキーマ駆動ORM | 軽量SQLライクORM | デコレータORM | クエリビルダ |
| スキーマ定義 | `.prisma` DSL＋生成 | TS（`pgTable`）＋推論 | デコレータクラス | 手書き/codegen インターフェース |
| マイグレーション | 内蔵（自動生成） | 内蔵（自動生成） | 内蔵（自動生成） | ランナーのみ（手書き） |
| 型の出どころ | コード生成 | 推論 | デコレータ | 推論 |
| 抽象度 | 高 | 中 | 高 | 低（SQLそのもの） |
| エッジ/軽量 | v7でRustフリー化し改善 | もとから軽量 | 重め・広範対応 | 非常に軽量 |
| 学習対象 | DSLを覚える | TSのみ | デコレータ作法 | SQL＋ビルダAPI |

> **型安全の質に注意**：4つとも「型安全」を謳いますが、出どころが違います。Prisma は生成物、Drizzle/Kysely は推論、TypeORM はデコレータ。どの方式でも、**`as`/`any` で結果型をねじ曲げた瞬間に安全は崩れます**。ツール選定より、この規律のほうが結果を左右します。

---

## 3. ユースケース別の推奨

抽象論より、状況に当てはめた指針が役立ちます。

**Prisma を選ぶ**
- 宣言的なデータモデルを**単一真実源**にしたい。チームのSQL習熟度に幅がある。
- マイグレーション運用を**厚く・安全に**回したい（レビュー可能なSQL、ベースライン、無停止移行）。
- **Prisma Postgres / Accelerate** のマネージドな接続プール・キャッシュ込みで素早く本番化したい。
- → v7 でエッジ/サーバーレスの弱点が解消され、「とりあえず Prisma」が以前より広く正解になりました。

**Drizzle を選ぶ**
- **SQLの透明性**を保ちたい。生成物より**推論で完結**させたい。依存を最小にしたい。
- サーバーレス/エッジで**軽さ**を最優先したい。SQLが得意なチーム。

**TypeORM を選ぶ**
- **NestJS** などデコレータ文化のスタック。ActiveRecord/DataMapper の作法に馴染んでいる。
- 既存のTypeORMコードベースを継続する（新規での第一候補にはしにくいが、資産がある場合は合理的）。

**Kysely を選ぶ**
- ORM の抽象を**持ちたくない**。生SQLに近い制御を、**完全な型安全**で書きたい。
- 複雑なクエリが主役で、モデル中心の開発体験は要らない。
- → Drizzle や Prisma と**併用**（重いクエリだけ Kysely、等）する選択もあります。

---

## 4. 乗り換えコストと現実的な進め方

**重要な事実**：Prisma は公式の **v6→v7 アップグレードガイド**を持ちますが、**ツール間（Prisma→Drizzle 等）の公式移行ガイドは存在しません**。世に出回る「X から Y への移行」は第三者の記事であり、公式の保証はありません。

だからこそ、乗り換えを前提にするなら**最初からデータアクセスを抽象化**しておくのが効きます。

```ts
// リポジトリ層でORMを隠す：呼び出し側はORMを知らない（ETC＝変更容易性）
export interface UserRepository {
  findById(id: number): Promise<User | null>;
  create(input: NewUser): Promise<User>;
}

// 実装をPrismaにするかDrizzleにするかは、この層の中だけの話
export class PrismaUserRepository implements UserRepository {
  /* prisma.user.findUnique(...) など */
}
```

こうしておけば、将来 ORM を入れ替えても**影響がリポジトリ層に閉じます**。とはいえ YAGNI——**移行予定が無いなら過剰な抽象は不要**です。「いま最適な1つ」を選び、境界だけ薄く保つ、が現実解です。

> **私の立場**：ツールは制約で選ぶもので、宗教にしないこと。型安全を `as`/`any` で崩さず、スキーマを真実源にし、マイグレーションをレビュー対象として運用する——この規律さえあれば、Prisma でも Drizzle でも本番品質に届きます。

---

## 5. 選定チェックリスト

- [ ] **抽象度**：フルORM（Prisma/TypeORM）か、SQLライク（Drizzle）か、クエリビルダ（Kysely）か——プロジェクトに合う層はどれか
- [ ] **スキーマの書き方**：DSL＋生成（Prisma）／TS推論（Drizzle・Kysely）／デコレータ（TypeORM）の好みと相性
- [ ] **マイグレーション**：自動生成の厚み（Prisma/Drizzle/TypeORM）が要るか、手書き運用（Kysely）で十分か
- [ ] **デプロイ先**：エッジ/サーバーレスの軽さが要件か（Prisma v7・Drizzle・Kyselyが有利）
- [ ] **チームの素地**：SQL習熟度、NestJS等のフレームワーク文化
- [ ] **マネージド連携**：接続プール・キャッシュ込みで早く出したいなら Prisma（Postgres/Accelerate）
- [ ] **乗り換え耐性**：将来の入れ替え可能性があるならリポジトリ層で抽象化（無いなら作らない＝YAGNI）
- [ ] **規律**：どれを選んでも `as`/`any` 禁止・スキーマを真実源・マイグレーションをレビュー

---

## まとめ

Prisma・Drizzle・TypeORM・Kysely は、**抽象度の違う別カテゴリのツール**です。Prisma は宣言的なスキーマ駆動ORM（v7でRustフリー化しエッジも強くなった）、Drizzle はSQLライクで軽量、TypeORM はデコレータ文化、Kysely は型安全なクエリビルダ。「どれが最強か」ではなく「**このプロジェクトの制約に、どの抽象度が合うか**」で選べば、選定で失敗しません。そして最終的に結果を分けるのは、ツールよりも**型安全を崩さない規律**です。

「**新規プロダクトのDB層を、将来の運用まで見据えて選定したい**」「**既存のORM選定が本当に最適か、第三者の目で検証してほしい**」——プロジェクトの制約（デプロイ先・チーム・要件）から、後悔しない技術選定をご一緒します。受賞プロダクトや決済基盤での実運用知見を、あなたの意思決定に提供します。