「TypeScript のバックエンドで、DB層を何で作るか」——この一問は、その後の開発速度・型安全性・運用負荷を長く左右します。候補は主に4つ：Prisma・Drizzle・TypeORM・Kysely。SNSでは宗教戦争になりがちですが、実務ではプロジェクトの制約で粛々と決めるのが正解です。この記事は、各ツールの公式の事実に基づいて違いを整理し、案件で迷わないための判断軸を提供します。
私は Prisma も Drizzle も本番で使っており、どれかを盲目的に推す立場にはいません。大事なのは「スキーマを唯一の真実源にし、as/any で境界をまたがない」という規律で、それはどのツールでも貫けます。Prisma を深く使う実装はPrisma ORM 本番運用ガイド（v7）、Drizzle はDrizzle ORM 本番運用ガイドにあります。
この記事のルール：各ツールのカテゴリ・スキーマ定義・マイグレーション・型安全の方式は各公式ドキュメント（2026年6月時点）に基づきます。GitHub スター数などの成熟度の数値は概算（公式APIではなく集計値）で、参考程度に。最終判断は必ず各公式で最新を確認してください。
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。
.prismaDSL でデータモデルを宣言し、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 への移行」は第三者の記事であり、公式の保証はありません。
だからこそ、乗り換えを前提にするなら最初からデータアクセスを抽象化しておくのが効きます。
// リポジトリ層で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選定が本当に最適か、第三者の目で検証してほしい」——プロジェクトの制約（デプロイ先・チーム・要件）から、後悔しない技術選定をご一緒します。受賞プロダクトや決済基盤での実運用知見を、あなたの意思決定に提供します。