世間の評価と移行の痛み ── 歓迎・批判・現場の声
どれだけ丁寧にリリースされても、破壊的変更を投入すれば必ず摩擦は起きる。本章では v7 に対する世間の反応を、歓迎・批判の両方を率直に並べていく。Prisma が最終的に折れた点（Mapped enums revert）まで含めて見ると、OSS プロジェクトの意思決定の生々しさが伝わってくるはずだ。
全体トーン：「mixed but largely positive」
InfoQ が 2026 年 1 月に出した Prisma 7 評価記事では、業界全体のトーンを **「mixed but largely positive（まちまちだが概ね好意的）」**と総括している。
quadrantChart
title v7 に対する反応マップ
x-axis "個別の痛み" --> "構造的改善"
y-axis "批判" --> "歓迎"
quadrant-1 "構造改善への歓迎"
quadrant-2 "個別痛みへの歓迎"
quadrant-3 "個別痛みへの批判"
quadrant-4 "構造改善への批判"
"バンドル90%減": [0.9, 0.95]
"型チェック70%高速": [0.85, 0.9]
"エッジ対応改善": [0.8, 0.88]
"Rust撤退の意思決定": [0.85, 0.7]
"依存136MB問題": [0.15, 0.12]
"ESM 強制": [0.2, 0.25]
"Mapped enums 破壊": [0.1, 0.15]
"SSL 検証厳格化": [0.25, 0.4]
"自動seed 廃止": [0.3, 0.5]
"MongoDB 一時ドロップ": [0.75, 0.25]上半分（歓迎）は「構造的改善」に集中、下半分（批判）は「個別の痛み」と「MongoDB ドロップ」に集中する。これが v7 に対する反応の典型的な分布である。
肯定的な評価
1. Deno コミュニティの歓迎
Deno 共同創業者の Luca Casonato 氏は、Prisma 公式ブログの引用でこう述べている。
“Not dealing with the native addon API would make supporting Prisma in Deno so much simpler.”
（「ネイティブアドオン API を扱わなくていいなら、Deno での Prisma サポートはずっと簡単になる」）
Deno にとって、Node.js のネイティブアドオンとの互換性は歴史的に頭痛の種だった。v7 はこの問題を Prisma 側で解消したことになる。
2. Kent C. Dodds の「スイッチ簡単」評
React / Remix エコシステムの重鎮 Kent C. Dodds 氏は、移行体験を次のようにコメント（Prisma 公式引用）。
“It was great to see how well everything went and how easy it was to switch.”
「大きな破壊的変更」と身構えたが、実際の移行は想像以上にスムーズだった、という評価。これは公式アップグレードガイドと AI プロンプトの効果が出ていたと読める。
3. Prisma Postgres の称賛
Jason Lengstorf 氏は Prisma Postgres について次のように発言（公式引用）。
“Being able to create a database this easily is amazing!”
npm create db 一発で PostgreSQL インスタンスが立ち上がる体験は、v7 の目玉機能の一つ。Prisma Postgres が unikernel microVM 基盤でサーバーレス的に立ち上がる仕組みは、ORM 側の進化と相まって「薄い抽象で使いやすい」方向に進んでいる。
4. 開発者コミュニティの実測共有
Reddit の r/node、Hacker News の Prisma 関連スレッドでは、「実際に移行してみたら速くなった」系の個別報告が継続的に出ている。特に以下のポイントが繰り返し言及される。
繰り返し称賛される点：
✅ tsc のフル型チェックが明らかに速くなった
✅ Lambda のコールドスタートが短くなった
✅ node_modules が小さくなった
✅ Docker イメージのビルドが軽くなった
✅ エッジ（Workers / Vercel）で素直に動くようになった批判・懸念の声
歓迎ばかりではない。痛みと批判も、率直に見ておく。
1. 依存関係の肥大化：136MB 問題
GitHub Discussion #28787 で持ち上がった話題。計測値はこうだった。
インストール後のサイズ比較：
v6.19.0 ： 87MB / 33 パッケージ
v7.0.1 ：136MB / 92 パッケージ（+56%）「バンドルサイズ（ランタイムに同梱する Prisma Client のサイズ）は確かに減ったが、node_modules 全体のサイズは逆に増えた」という指摘である。
原因は @prisma/dev という新しい依存。ここから @electric-sql/pglite（ブラウザ/Node で動くバンドル済み PostgreSQL）が引き込まれていた。
議論のポイント：
Prisma 側の立場：
ローカル開発・テストで DB を瞬時に立ち上げるために有用
→ 開発体験を上げるための投資
批判側の立場：
本番ランタイムに dev 依存が混ざるのは不健全
CI / Docker build が遅くなる
オプショナル依存として分離すべきこの批判は妥当性が高く、Prisma 側も問題を認めて改善を進めている。v7 の後半バージョンでは @prisma/dev の位置づけを見直す方向に進んでいる。
2. セキュリティ脆弱性（初期のみ）
v7.0.x のリリース直後、transitive dependencies（間接依存）に High severity の脆弱性が含まれることが指摘された。これは v7.1.0 で修正されており、2026 年 4 月時点では解消済み。
初期リリース直後の依存監査は重要で、npm audit や Snyk を回すタイミングをリリースと揃える運用は、どの OSS にも共通の課題である。
3. ESM 強制による周辺ツール混乱
v7 が ESM ネイティブになった影響で、周辺ツール（特に古い設定の TypeScript プロジェクト）で混乱が起きた。
よくあるエラーパターン：
① import に .js 拡張子が必要になる
→ tsconfig の moduleResolution 設定と相性が悪い
② Next.js 16 + Turbopack で prisma-client の解決エラー
→ Turbopack 側の ESM 解決に不具合があった時期がある
③ CommonJS の既存コードベースで require() できない
→ interop はあるが運用でハマる
④ Jest / Vitest の ESM 設定でつまずく
→ ts-jest や vitest のバージョン条件対処はケースバイケースだが、典型的には package.json の "type": "module" 設定と、tsconfig.json の "module": "NodeNext" か "ESNext" + bundler リゾルバで収まる。ただし**既存の大規模プロジェクトで「v7 にしたいだけなのに設定を全部見直す羽目になった」**ケースは散見される。
4. Mapped enums の破壊的変更 → 最終的に revert
v7.0 の RC 時点では、@map を使った enum の挙動に破壊的変更が入る予定だった。
enum Role {
ADMIN @map("admin")
USER @map("user")
}GitHub Issue #28599 で「既存コードを全面改修する必要があり実害が大きい」という指摘が集中。最終的に Prisma 側は v7.0 でこの変更を revertした。v6 互換の挙動が維持されている。
この一件の教訓：
✅ リリース直前でもコミュニティフィードバックで方針を変える柔軟性
✅ 「mapped enums は別の構文で将来再実装」と予告を残した
✅ 感情的な反発ではなく、具体的な影響の大きさを示した Issue が効いた破壊的変更は「メジャーで一気にやる」が原則だが、影響範囲がユーザー側の予想を超えて広いと判明した場合、revert するのは正しい判断。Prisma はこれを淡々と実行した。
5. SSL 検証の厳格化による接続エラー
Ch.5 で触れたとおり、Driver Adapter が pg ドライバを使うようになった結果、SSL 証明書検証がデフォルトで有効になった。
報告されたケース：
- 自己署名証明書を使っていた社内 RDS / オンプレ PostgreSQL
- 一部の Supabase プロジェクト
- セルフホストの PostgreSQLセキュリティ的には厳格化が正しいが、**「何も変えていないのに繋がらなくなった」**と感じるユーザー体験は悪い。対処は ssl: { rejectUnauthorized: false } を明示するか、正しい CA 証明書チェーンを配備するか。Prisma 側のドキュメントは改善されたが、移行時の「詰まりポイント」として今も残る。
6. MongoDB 一時ドロップへの不満
MongoDB ユーザーからは当然ながら不満が出た。
MongoDB ユーザーの声：
「v7 に上げたいが、MongoDB が対応していない」
「Prisma Next（v8）待ちの期間が読めない」
「他の ORM に乗り換えるか悩む」Prisma の対応は、**「v7 では v6 を継続使用してください、v8 で復活予定です」**という明確な方針を早期に出したこと。MongoDB 関連の Issue に「v8 予定」のラベルを付けて進捗を追えるようにしたのは誠実な対応だが、待たされる側の不満が消えるわけではない。
7. 感情的な反発 Issue
GitHub Issue #28887 には「prisma v7 sucks i am not in good term with my boss…」という件名の Issue が立った。技術的な詳細記述は乏しかったが、メジャーバージョンアップがビジネスのリスクとして降りかかる現場の生々しさを映している。
OSS 側からすれば、こういう Issue は「建設的ではない」と切り捨てたくなるが、大きな破壊的変更を出せば一定数は必ず出る。感情的反発も「どの痛みが許容限界を超えたか」のシグナルとして読む価値はある。
競合 ORM コミュニティの視線
Drizzle 側の反応
Drizzle 公式・作者（Andrew Sherman 氏ら）から Prisma 7 に対する直接的なブログ / X コメントは、2026 年 4 月時点では見つけられなかった。ただし第三者の比較記事（MakerKit、Bytebase 等）では次のような議論がある。
第三者視点の比較要点：
✅ Prisma v7 は「Drizzle が拾っていた Prisma の不満」を相当程度解消
✅ しかしバンドルサイズ（7KB vs 1.6MB）の桁違いはまだ残る
✅ コールドスタート（10〜20ms vs 90ms）も Drizzle が有利
✅ エッジ・極小サーバーレスでは Drizzle のアドバンテージが残る
✅ 「大規模スキーマ + 公式ツール充実」なら Prisma v7、
「軽量 + SQL に近い書き味」なら Drizzle という棲み分け補足：「PlanetScale が Drizzle コアチームを買収」という話題が 2026 年 3 月頃に二次情報として流通していたが、一次情報での確認は取れていない。この動きが本当なら Drizzle のエコシステムに影響が出る可能性はあるが、本稿では不確実情報として注記に留める。
Kysely・TypeORM 側
Kysely、TypeORM のメンテナーからも、Prisma 7 に対する直接の公式コメントは確認できなかった。これらは ORM としての立ち位置（Kysely = 型安全 SQL ビルダ、TypeORM = Decorator 型 ORM）が Prisma と異なるため、直接対抗する発信はしていない。
現場で v7 移行を判断するための視点
「結局、今プロジェクトを v6 → v7 に上げるべきか？」という問いには、簡単な判定フローで考えられる。
graph TD
A[v7 移行を検討] --> B{MongoDB を<br/>使っている?}
B -->|Yes| C[v8 まで v6 継続]
B -->|No| D{ESM 移行が<br/>済んでいる?}
D -->|No| E[ESM 化を先行]
D -->|Yes| F{本番環境で<br/>Driver Adapter対応?}
F -->|No| G[段階的に<br/>Driver Adapter 導入]
F -->|Yes| H{自己署名 SSL<br/>/ 特殊なプール設定?}
H -->|Yes| I[接続周りを<br/>先に確認]
H -->|No| J[移行可能<br/>EA 期の人柱情報を参照]プロジェクトタイプ別の推奨
✅ 新規プロジェクト（2026 年 4 月以降）
→ v7 から始める。Prisma Next（v8）を見据えた設計に
✅ 小〜中規模・PostgreSQL / MySQL / SQLite
→ 移行ハードルは低め、恩恵も大きい
⚠️ 大規模・レガシー CommonJS コードベース
→ ESM 化の工数を評価してから判断
⚠️ 自己署名 SSL / カスタムコネクションプール
→ 接続周りの検証を先行
🛑 MongoDB 利用
→ v6 継続、Prisma Next（v8）待ち本章のまとめ
✅ 全体トーン：mixed but largely positive
構造的改善には歓迎、個別の痛みに批判が集中
✅ 肯定的評価：
- Deno：ネイティブアドオン問題の解消を歓迎
- Kent C. Dodds：移行がスムーズ
- コミュニティ：型チェック高速化・コールドスタート改善を実感
✅ 主な批判：
- 依存サイズ 87MB → 136MB（+56%）：@prisma/dev の影響
- ESM 強制による周辺ツール混乱
- Mapped enums の破壊的変更 → 最終的に revert
- SSL 検証厳格化で接続エラー
- MongoDB 一時ドロップへの不満
✅ 競合の反応：
- Drizzle / Kysely から直接の公式反応なし
- 比較記事では「棲み分けが明確化した」論調
✅ 移行判断の指針：
- MongoDB 利用は v6 継続
- 大規模 CommonJS はスクリプトの ESM 化工数を評価
- 自己署名 SSL は事前検証
- それ以外は移行の恩恵が大きい残すは最終章、エピローグ。Prisma が早くも告知している Prisma Next（v8） の方向性、そして ORM という層の未来像を展望して、このシリーズを閉じる。