目次を表示する

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

OSSメジャーバージョンアップの進め方 ── Manifestoからデフォルト化まで

OSSメジャーバージョンアップの進め方 ── Manifestoからデフォルト化まで

本章では角度を変える。技術的な話はひとまず置いて、Prisma がどうやってこのメジャーリリースを世に出したか ── OSS プロジェクトとしての進め方を見ていく。

Rust 撤退のような大手術は、黙って発表されたら炎上する案件である。Prisma はこれを 18 ヶ月かけて段階的に実行した。その段取りは、OSS メジャーバージョンアップの事例として参考にする価値がある。


18 ヶ月のタイムライン

まず全体像を時系列で掴んでおく。

timeline
    title Prisma v7 リリースまでの 18 ヶ月
    2024-12-02 : ORM Manifesto 公開<br/>負債を告白、方針転換を予告
    2025-03    : From Rust to TypeScript<br/>公式発表、進捗共有
    2025-04-30 : v6.7.0 Early Access<br/>PostgreSQL / SQLite で Rust-free を試せる
    2025-06-05 : v6.9.0<br/>PostgreSQL / SQLite で Rust エンジン除去可能
    2025-06-17 : v6.10.0<br/>MSSQL / PlanetScale 対応拡大
    2025-09-10 : v6.16.0<br/>Rust-free が GA 化
    2025-11-19 : v7.0.0 リリース<br/>Rust-free がデフォルト化
    2026-03-04 : The Next Evolution of Prisma ORM<br/>12 ヶ月サポート保証、Prisma Next 発表

一瞬のリリースではなく、「告白→予告→試用→GA→デフォルト→次章」の六段階で進めている。一段ごとに公式ブログで節目を打ち、コミュニティに「今ここ」を常に示し続けた。


ステージ 1:Manifesto で「告白する」

2024 年 12 月 2 日、Will Madden 氏が公開した ORM Manifesto(原典)。これは新機能発表ではなく、「今まで何がダメだったか」の告白文だった。

この告白スタイルには三つの効果があった。

① 共感の獲得
   ユーザーが不満に思っていたことを先に会社側が認める
   → 「わかってくれていたんだ」という信頼につながる

② 期待値の制御
   「これから全部直す」ではなく「この順で直す」と公約する
   → 過剰な期待で炎上しない

③ 破壊的変更の正当化
   「なぜそこまでやるのか」の土台を作る
   → 後の v7 の痛みに対する耐性が生まれる

ここで重要なのは、Manifesto が具体的な数字を伴っていたこと。「Issue が多い」ではなく「3,200 件超」と書いた。「Preview が多い」ではなく「四半期サイクルに」と書いた。曖昧な反省ではなく検証可能な公約にした点が、後の信頼を作った。


ステージ 2:3 ヶ月ロードマップの公開

Manifesto 公開と並行して、Prisma は3 ヶ月単位のロードマップを GitHub Issue として公開する運用を始めた。

公開された 3 ヶ月ロードマップ(一部):
  - Dec 2024 - Feb 2025:Issue #25794
  - March - May 2025   :Issue #26592
  - Sept - Nov 2025     :Issue #28270(v7 リリース期)

特徴は以下。

ロードマップ Issue の設計:
  ✅ GitHub Issue として公開 → コメントで進捗が議論できる
  ✅ チェックボックスで進捗が可視化される
  ✅ 3 ヶ月という短いスパン → 公約のずれに気付きやすい
  ✅ 「やらないこと」も明示 → 期待の過剰化を防ぐ
  ✅ 各期の最後に振り返りコメント → 次期の計画に反映

「ロードマップを公開する」は多くの OSS がやっているが、「3 ヶ月スパンで Issue として出し、チェックボックスで進捗を示す」形は細部が優れている。PDF や HTML 上のロードマップは古くなりやすいが、Issue はコメントで更新され、履歴として残る。


ステージ 3:Early Access という「試せる予告」

2025 年 4 月 30 日、v6.7.0 で Rust-free 版が Early Access として提供された。

// v6.7.0 で試す方法(Early Access)
generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["queryCompiler", "driverAdapters"]
}

Preview フラグをオンにすると、Rust-free 版のクエリエンジンで動く。動かなければ戻せる。この可逆性が、コミュニティが気軽に試せる条件だった。

Early Access の運用で巧かった点

① 本流(main branch)に取り込む
   → 実験ブランチで分断せず、同じバイナリに両方を同梱

② Preview フラグ一つで ON/OFF
   → 切り戻しが瞬時にできる

③ Issue で体系的にフィードバックを集める
   → GitHub Discussions / Discord と併用

④ 使える DB を段階的に増やす
   v6.7  :PostgreSQL / SQLite
   v6.9  :MySQL 追加
   v6.10 :MSSQL / PlanetScale 対応
   → 「一部の DB ユーザーから先に試してもらう」段取り

v6.7 から v6.16 GA まで 4.5 ヶ月。この間に公式ブログで進捗記事を打ち続け、GitHub Issue でフィードバックを拾い続けた。


ステージ 4:GA と「選べる状態」

2025 年 9 月 10 日、v6.16.0 で Rust-free 版が GA 化された。ただしデフォルトはまだ Rust 版

v6.16 の状態:
  デフォルト       :Rust 版(後方互換)
  Preview 解除     :Rust-free 版を安定版として使える
  併存期間         :約 2 ヶ月

GA と同時にデフォルト化しなかった判断は大きい。「GA」は「安定しました」の意味であり、「今すぐ全員移行しろ」ではないからだ。Rust-free 版を本番投入した早期アダプターのフィードバックをさらに 2 ヶ月集めてから、次のステージに進んだ。


ステージ 5:v7 でデフォルト化

2025 年 11 月 19 日、v7.0.0 がリリース。Rust-free 版がデフォルトになり、Rust エンジンは削除された。

このタイミングで一気に破壊的変更の束が投入された。

v7.0.0 に詰め込まれた破壊的変更:
  - Rust バイナリ撤去
  - generator provider 変更
  - output 必須化
  - ESM ネイティブ
  - Driver Adapters 必須化
  - 自動 generate / seed 廃止
  - prisma.config.ts 移行
  - Middleware 廃止
  - 環境変数・フラグ多数削除

破壊的変更を小刻みに出すのではなく、メジャーバージョンに集約して一度にやる。これは SemVer の教科書通りだが、徹底できる OSS は意外と少ない。Prisma はこれを律儀に守った。


移行支援ツールキット

破壊的変更を投入するなら、移行支援の質が生命線になる。Prisma は以下を揃えた。

① 公式アップグレードガイド

/docs/guides/upgrade-prisma-orm/v7 に、破壊的変更の一覧と移行手順が集約された。短縮 URL pris.ly/migrateto-prisma7 も用意。

AI プロンプト版ガイド

これが今風で巧い施策。/docs/ai/prompts/prisma-7 に、LLM に貼り付けて移行を指示できるプロンプトが公開された。

AI プロンプト版の目的:
  ✅ Claude / ChatGPT / Cursor などにコンテキストとして渡せる
  ✅ リポジトリを読んで差分を提案してもらえる
  ✅ 「ここは手作業」「ここは自動化できる」の切り分けが楽

2026 年時点では、OSS がこういう「AI に読ませる移行ガイド」を公式に整備するのは徐々に増えてきているが、Prisma は早期に始めた例の一つ。

prisma-upgrade-v7 Agent Skill

Claude Code などで使える Agent Skill として、移行作業用の自動化スキルを公開。プロジェクトを解析し、必要な変更を提案するワークフローが含まれている。


コミュニケーション戦略

v7 リリース前後、Prisma は複数チャネルを計画的に使い分けた。

graph TD
    A[コミュニケーション戦略] --> B[一次情報]
    A --> C[双方向]
    A --> D[反応分析]

    B --> B1[公式ブログ<br/>節目ごとの記事]
    B --> B2[GitHub Issue<br/>ロードマップ / RFC]
    B --> B3[アップグレードガイド]

    C --> C1[GitHub Discussions<br/>Q&A]
    C --> C2[Discord<br/>リアルタイム対話]
    C --> C3[月次 AMA<br/>2025 年開始]
    C --> C4[X @prisma<br/>告知・短い議論]

    D --> D1[upvote による優先順位]
    D --> D2[Issue コメントの解析]
    D --> D3[SNS 反応のモニタ]

月次 AMA の効果

2025 年に開始された月次 AMA(Ask Me Anything)は、破壊的変更への不安をリアルタイムに吸収する装置として機能した。v7 リリース後にも「Prisma 7 AMA」として特別回が行われ、質疑がまとめられて ブログ記事 になっている。

AMA のいいところは、答えを記事化して「あの疑問にはここで答えた」と参照できる点。Discord で散発的に答えるよりも、公式見解として残せる。


サポート保証:「ちゃんと長く使える」の約束

2026 年 3 月 4 日、Prisma は「The Next Evolution of Prisma ORM」という記事で v7 の 12 ヶ月サポート保証 を明示した。

The Next Evolution of Prisma ORM(2026-03-04)の主な内容:
  ✅ Prisma 7 は今後 12 ヶ月継続サポート
  ✅ MongoDB 対応は次期 "Prisma Next"(v8)へ持ち越し
  ✅ 新規プロジェクトは Prisma Next に移行を推奨
  ✅ v7 ユーザーには Prisma Next への橋渡しを用意

これは次の v8 に向けた事前告知でもある。「v7 出したら終わり」ではなく、「v7 は 12 ヶ月もつから、その間に次に備えてね」というメッセージ。2024 年 12 月の Manifesto と同じ 「予告 → 公約」のスタイル を踏襲している。


OSS 運営の教訓として抽出できる 6 原則

ここまでの段取りから、一般化できる原則を抽出しておく。

原則 1: 大きな方向転換は Manifesto で告白する
  → 具体的な数字と公約でまとめる

原則 2: ロードマップは短いスパン(3 ヶ月)で、
       GitHub Issue として「生きた文書」にする

原則 3: Preview フラグ一つで ON/OFF できる形で早期アクセスを出す
  → ユーザーに「戻せる」安心を与える

原則 4: GA とデフォルト化を分ける
  → 「安定」と「全員移行」のタイミングをずらす

原則 5: 破壊的変更はメジャーバージョンに集約する
  → SemVer を律儀に守る

原則 6: 移行支援は「ドキュメント + AI プロンプト + 自動化ツール」の三点セット
  → 2026 年時点では LLM 向けガイドが標準装備になりつつある

本章のまとめ

✅ v7 は 18 ヶ月・六段階で世に出された:
   Manifesto → ロードマップ → Early Access → GA → デフォルト化 → 次章予告

✅ Manifesto は「告白文」として機能した
   負債を具体的な数字で認め、公約を立てた

✅ 3 ヶ月ロードマップを GitHub Issue で運用することで
   進捗と期待値を常に可視化した

✅ Preview フラグでの Early Access により、
   コミュニティが気軽に試せる状態を作った

✅ GA とデフォルト化のタイムラグで、
   本番投入者のフィードバックを吸収した

✅ 移行支援として「公式ガイド + AI プロンプト + Agent Skill」を整備

✅ 月次 AMA で疑問を吸収、記事化して残した

✅ v7 リリース後は「12 ヶ月サポート + v8 予告」で継続性を約束

ここまでが 「Prisma がどう世に出したか」 である。では **「世の中はどう受け取ったか」**は? 次章では、Deno や Kent C. Dodds の称賛、136MB に膨らんだ依存サイズへの苦情、ESM 強制で起きた混乱、Mapped enums の revert など、歓迎と批判の両方を見ていく。

参考文献