v6までに蓄積した4つの負債 ── ORM Manifestoが告白したこと
2024 年 12 月 2 日、Prisma エンジニアリングマネージャーの Will Madden 氏が一本のブログ記事を公開した。**「Prisma ORM Manifesto」**である。
この記事は通常のプロダクト告知とは異質だった。「これからの機能」ではなく、「これまでに積み残した問題」を正面から列挙していたからである。v7 の構造改革は、ここから始まっている。本章ではこの Manifesto が告白した四つの負債を順に見ていく。
問題の全体像
Manifesto は冒頭で、こう切り出している（要約）。
Prisma ORM は 2020 年の GA から 5 年弱で大きく成長した。しかし同時に、未処理 Issue が 3,200 件を超え、Preview 機能の GA 化が遅延し、優先順位が不透明になり、コミュニティの期待に応えきれていない。
これを受けて、四つの領域で負債が告白された。
mindmap
root((v6 までの負債))
Issue の肥大化
3200件超の未処理
優先順位が不明瞭
いつ直されるか見えない
Preview の塩漬け
数年 GA 化されない機能
本番で使ってよいか不明
Feature flag の長期滞在
Rust アーキテクチャ
コントリビューション障壁
デプロイの複雑性
ランタイム非互換
フォーカスの分散
多数のDBドライバ対応
Accelerate / Pulse / Studio
優先すべき DB が不明瞭負債 ①：Issue バックログの肥大化
症状
2024 年末時点で、prisma/prisma リポジトリには 3,200 件以上の未処理 Issue が滞留していた。人気 OSS なら珍しくない数に見えるが、Manifesto はこれを問題として明示的に受け止めた。
何が問題だったか：
① upvote（+1）を集めた Issue が数年放置されていた
② 「検討中」ラベルのまま何年も動かない Issue
③ 重複 Issue、古い Issue、リポジトリ横断の Issue が錯綜
④ 「いつ直るか」「直すつもりがあるか」が見えない根本原因
Manifesto は「優先順位の透明性」の欠如を原因として挙げた。Prisma 社としての戦略と、コミュニティからの要望が噛み合っていなかったのである。
解決策（v7 で実行された）
- upvote ベースの優先順位付けを公式化
- 3 ヶ月単位のロードマップを GitHub Issue として公開（例：Dec 2024 - Feb 2025、Sept - Nov 2025）
- Preview → GA の四半期サイクルを公約
3 ヶ月ロードマップは「この期間に何をやるか」を Issue として明示し、コミュニティが進捗にコメントできる形式になった。これが後述する Rust → TS 移行の進捗可視化にも使われている。
負債 ②：Preview 機能の塩漬け
症状
Prisma には previewFeatures という機能フラグ機構がある。本来これは「本番投入前に試せる実験機能」を表すはずだった。
generator client {
provider = "prisma-client-js"
previewFeatures = ["driverAdapters", "queryCompiler", "fullTextSearch"]
}ところが v6 までの時点で、数年間 Preview のままの機能が複数存在していた。
Preview 長期滞在の例：
- Full-text search：数年 Preview、本番利用の可否が不明瞭
- Metrics：Preview のまま方針転換（v7 で削除）
- tracing：Preview のまま
- 他多数この状態は、ユーザーに三つの不利益を与えていた。
① 本番で使っていいのか判断できない
→ ドキュメントには「Preview」と書いてあるが
実質 GA 相当の安定性のケースもあり区別がつかない
② 依存していると破壊的変更が降ってくる可能性
→ GA 化のタイミングで API が変わることがある
③ 放置されているだけの機能と生きている機能の区別がつかない
→ 「この Preview、開発止まってる？」の疑念根本原因
新機能追加のインセンティブに対して、既存 Preview の GA 昇格・デプリケート判断のインセンティブが弱かった。Preview は「作って終わり」になりがちだった。
解決策（v7 で実行された）
- 四半期サイクルの強制：今期 Preview に出した機能は翌四半期で GA/捨てる、を原則化
- 長期 Preview の一掃：
fullTextSearch、metricsなど一部は v7 で削除 - Preview の粒度の見直し：大きな機能を細かく Preview しない
この公約の効果は v7 のリリースノートで確認できる。v6 系で Preview だった機能が、v7 では GA か削除のいずれかに整理されている。
負債 ③：Rust アーキテクチャの三重苦
ここが v7 の核心につながる。
症状 A：コントリビューション障壁
Prisma にバグ修正 PR を出そうと思うと、以下のスキルセットが要求された。
必要スキル（v6 まで）：
✅ TypeScript（CLI、クライアントコード）
✅ Rust（Query Engine 本体）
✅ 両者間の FFI / プロトコル知識
✅ OS × OpenSSL バージョンごとのビルド環境結果、コミュニティ PR は「TypeScript 側の軽微な修正」に偏った。クエリエンジン本体に手を入れられる外部コントリビューターはほぼゼロという状態だった。
症状 B：デプロイの複雑性
Rust バイナリは OS × アーキテクチャ × OpenSSL バージョンの組み合わせでビルドが必要だった。
同梱されるバイナリの組み合わせ（v6 時代の典型）：
- query-engine-darwin
- query-engine-darwin-arm64
- query-engine-debian-openssl-1.1.x
- query-engine-debian-openssl-3.0.x
- query-engine-linux-arm64-openssl-1.1.x
- query-engine-linux-arm64-openssl-3.0.x
- query-engine-linux-musl
- query-engine-linux-musl-openssl-3.0.x
- query-engine-rhel-openssl-1.0.x
- query-engine-rhel-openssl-1.1.x
- query-engine-rhel-openssl-3.0.x
- query-engine-windowsこの結果、バンドルサイズは 14MB 前後（gzip 後でも 7MB）に膨れ上がった。AWS Lambda のパッケージサイズ上限（250MB 展開後、50MB zip）を圧迫する主犯格となり、「Lambda に Prisma をデプロイすると他の依存が入らない」という苦情は定常的に出ていた。
加えて、「ローカルで動くのに Docker では動かない」問題の多くが OpenSSL バージョン違いに起因していた。エンジニアの時間が「どのバイナリを同梱するか」のチューニングに溶けていた。
症状 C：ランタイム非互換
2024〜2025 年、バックエンドランタイムは多様化した。
ネイティブバイナリが動かない／制約のあるランタイム：
- Cloudflare Workers（V8 Isolate。ネイティブ addon 不可）
- Vercel Edge Runtime（V8 Isolate ベース）
- Deno Deploy（Deno ランタイム）
- Bun（別 JS ランタイム）
- AWS Lambda @ Edgeこれらはもはや「エッジ」という周縁ではなく、TypeScript バックエンドのメインストリームになっていた。Prisma は Driver Adapters（v5 で Preview、v6 で GA）でこの問題に対処しようとしたが、肝心の Query Engine が Rust バイナリのままでは、WASM 版や軽量版を別途提供する必要があり、コードパスが二重化した。
Deno の共同創業者 Luca Casonato 氏は、Prisma 側への引用で次のようにコメントしている。
“Not dealing with the native addon API would make supporting Prisma in Deno so much simpler.”
つまり「ネイティブバイナリに対応しないで済むなら、Deno で Prisma をサポートするのはずっと楽になる」。これは Deno 側から見た率直な本音である。
根本原因
「言語横断のコアを持つ」という設計が、アプリランタイムの多様化と噛み合わなくなった。2020 年の前提「ネイティブバイナリが動くサーバー環境が標準」が、2024 年には覆されていた。
負債 ④：フォーカスの分散
症状
Prisma は ORM 以外にも製品群を抱えていた。
Prisma の製品群（v6 時点）：
- Prisma ORM（本丸）
- Prisma Accelerate（グローバル接続プーリング + キャッシュ）
- Prisma Pulse（リアルタイム DB 変更ストリーム）
- Prisma Studio（GUI）
- Prisma Postgres（マネージド DB サービス、2024 後半〜）加えて、ORM 側でサポートする DB も PostgreSQL、MySQL、MariaDB、SQLite、SQL Server、MongoDB、CockroachDB と幅広かった。
Manifesto は、このフォーカスの分散がユーザー体験を劣化させていると認めた。
症状：
- 「MongoDB 対応はいつ安定するのか？」が常に後回しになる
- 「SQL Server 向け機能 X は PostgreSQL では使えるのに…」の食い違い
- コアチームのリソースが薄く広く分散解決策（v7 で実行された）
First-Class Databases（FCDB） という概念で優先順位を明示。
First-Class Databases（FCDB）：
✅ PostgreSQL（最優先）
✅ Prisma Postgres（Prisma 自家製マネージド PG）
✅ MySQL / MariaDB
✅ SQLite
⚠️ MongoDB（v7 では未対応、v8/Prisma Next で復活予定）
⚠️ SQL Server（継続サポートだが優先度は下）
⚠️ CockroachDB（同上）注目すべきは MongoDB が v7 で一時的にドロップ したことである。「全ての DB を同じ優先度でサポートする」という網羅主義を明確に捨てた。批判はあったが、Prisma はこの選択を貫いた。
四つの負債をひとつながりで見る
バラバラの問題に見えて、背後には一つの因果がある。
graph TD
A[マルチ言語クライアント戦略<br/>→ Rust 製コア] --> B[コントリビューション障壁]
A --> C[デプロイ複雑性]
A --> D[ランタイム非互換]
B --> E[Issue 滞留]
C --> E
D --> E
E --> F[Preview の塩漬け]
A --> G[フォーカス分散<br/>全 DB 網羅主義]
style A fill:#f99,stroke:#333,stroke-width:3px**起点は「マルチ言語クライアント戦略 → Rust 製コア」**である。この戦略が、コントリビューション障壁・デプロイ複雑性・ランタイム非互換を生み、結果的に Issue が滞留し、Preview が塩漬けになった。
ならば解くべきはここだ。次章では、Prisma が下した「逆走の設計判断」── Rust を捨てて TypeScript に戻る決断と、そこで発明された WASM Query Compiler という妥協点を掘っていく。
本章のまとめ
✅ v7 は機能追加ではなく「構造改革」のメジャーリリース
起点は 2024 年 12 月の ORM Manifesto
✅ 四つの負債：
① Issue バックログの肥大化（3,200 件超）
② Preview 機能の塩漬け（数年 GA 化されない）
③ Rust アーキテクチャの三重苦（貢献障壁・デプロイ複雑性・ランタイム非互換）
④ フォーカス分散（全 DB 網羅主義）
✅ これらは独立した問題ではなく、「マルチ言語クライアント戦略」
という出発点の前提変質から派生した症状だった
✅ Manifesto は「告白して公約する」というスタイルで、
v7 の構造改革の出発点となった