目次を表示する

Prisma v7 — なぜRustから撤退したのか、OSSの構造改革として読み解く

プロローグ ── なぜPrisma v7を今読み解くのか

プロローグ ── なぜPrisma v7を今読み解くのか

シリーズ構成（全9章）

Part 1 — 背景と歴史 Ch.1 プロローグ（本章） / Ch.2 Prismaはなぜ Rust で始まったのか / Ch.3 v6までに蓄積した4つの負債

Part 2 — v7の設計 Ch.4 逆走の設計判断 — Rust撤退の本当の理由 / Ch.5 各領域の変更マップ / Ch.6 パフォーマンス — 本当に速くなったのか

Part 3 — プロジェクトと評価 Ch.7 OSSメジャーバージョンアップの進め方 / Ch.8 世間の評価と移行の痛み

Ch.9 エピローグ — Prisma Next (v8) とORMの未来

この記事で扱う「違和感」

2026年、バックエンド界隈で定着した技術選定の「常識」がある。

あるある場面：

場面1: 「Node.js で書いてた CLI を Rust に書き直したら30倍速くなった」
  → Xのタイムラインで年に何度か見るやつ

場面2: 「esbuild（Go）、Biome（Rust）、Turbopack（Rust）、
         uv（Rust）、Bun（Zig）…」
  → JS ツールチェインの Rust/Go 化が完全に主流に

場面3: Deno も Bun も Rust/Zig。Next.js コンパイラも Rust に
  → 「TypeScript ランタイムを高速化するなら、内側はネイティブ」が定石

この流れの真逆を行くリリースが、2025年11月19日に出荷された。

Prisma ORM 7.0 ── Rust 製のクエリエンジンを捨て、TypeScript に戻したのである。

世間の流れ：  Node.js  →  Rust / Go / Zig
Prisma v7：  Rust     →  TypeScript + WASM

v1〜v6 まで、Prisma の心臓部は Rust バイナリだった。findMany を呼ぶたびに、内部では Node.js プロセスが別プロセスの Rust エンジンと通信していた。このアーキテクチャは「SQL 生成もコネクション管理もネイティブで高速」という触れ込みだった。

それを、わざわざ TypeScript に書き直した。

  • 「速くするために Rust にしたんじゃなかったのか？」
  • 「マルチ言語サポートのために Rust じゃなかったのか？」
  • 「エッジで動かない問題は Rust の制約じゃなかったのか？」

この三つの疑問に、Prisma チームは明快に答えている。答えは「はい、そうでした。でも全部やめました」である。

なぜ今、この判断を読み解く価値があるのか

Prisma v7 は単なるバージョンアップではない。以下の三層の物語が重なっている。

① 技術の物語
   「クロス言語通信のシリアライズコスト」という、
   Rust 推し潮流の死角を突いた設計判断

② プロダクト戦略の物語
   「マルチ言語 ORM」という創業期のビジョンを
   正式に畳み、TypeScript に全振りする決断

③ OSS ガバナンスの物語
   Manifesto で負債を告白 → 四半期サイクル公約 → Preview → GA →
   デフォルト化 という、教科書的なメジャーリリース運営

この三層はばらばらの話ではない。「なぜ Rust で始めたのか（Ch.2）」→「何が詰まったのか（Ch.3）」→「どう解きほぐしたのか（Ch.4〜6）」→「どう世に出したのか（Ch.7〜8）」という一つの因果として繋がっている。Prisma チーム自身が、2024年12月の「ORM Manifesto」から 2026年3月の「The Next Evolution of Prisma ORM」まで、2年弱のあいだにこの因果を一貫して語ってきた。

逆に言えば、v7 を表面の「Rust やめました、速くなりました」だけで理解すると、次の v8（Prisma Next）のロードマップが読めなくなる。Prisma は自分たちの戦略を根本から書き換えている最中なのである。

この記事を読み終えると何ができるようになるか

✅ Prisma v7 の技術的変更を、歴史的文脈とセットで理解できる
   → 「なぜこの破壊的変更が必要だったか」を背景から説明できる

✅ 「Node→Rust/Go」の潮流を盲信せず、言語境界のコストを判断できる
   → 自分のプロジェクトで Rust/WASM を採用する際の判断軸が増える

✅ OSS メジャーバージョンアップの進め方を模範例として参照できる
   → Manifesto、ロードマップ公開、EA→GA 移行の段取りが見える

✅ v6 → v7 移行判断を自分のプロジェクトで下せる
   → 痛み（ESM 強制、Driver Adapter 必須、依存肥大）と
     果実（バンドル90%減、型チェック70%高速）を天秤にかけられる

対象読者

対象：
  - Prisma を使っている／v7 移行を検討している TypeScript エンジニア
  - ORM 選定の判断軸を深めたい方（Drizzle、Kysely、TypeORM との比較視点）
  - OSS のメジャーバージョンアップ運営に興味がある方
  - 「Rust で速くなる」の一歩先、言語境界のオーバーヘッドに関心がある方

難易度：★★★☆☆
読了時間：約2時間30分（全章通読時）
対象バージョン：Prisma ORM 7.0.0 〜 7.7.0（2026年4月時点）
前提知識：
  - Node.js / TypeScript のバックエンド開発経験
  - Prisma を触ったことがある（schema.prisma を読める）
  - WASM・ESM などの用語を聞いたことがある

本記事が扱わないこと

❌ Prisma の入門的な使い方（モデル定義、CRUD 操作の基本）
   → 公式チュートリアルで十分。本書は「なぜそうなっているか」を扱う

❌ Drizzle・Kysely の詳細な機能解説
   → 比較軸として触れるが、それぞれ独立した解説書がふさわしい

❌ 特定のフレームワーク（Next.js / Remix 等）との統合ガイド
   → フレームワーク側の事情は本題から外れる

本記事の読み方

通読を推奨するが、関心によって以下の入り口から読み始められる。

「Rust やめた話を知りたい」            → Ch.2 → Ch.4
「移行すべきか判断したい」              → Ch.5 → Ch.8
「OSS 運営の教訓として読みたい」        → Ch.3 → Ch.7
「数字で性能を見たい」                  → Ch.6
「これから先、Prisma はどうなるのか」    → Ch.9

次章では、そもそもなぜ Prisma が Rust で始まったのかを掘る。2018〜2019 年の Prisma 2 設計時、この選択は極めて合理的だった。その合理性が、なぜ2024年には負債に反転したのか。因果の起点を確かめることから始めよう。