Prisma Nextを読む：契約と拡張SPIを軸にしたTypeScript ORM

Prisma ORM 7とPrisma Nextを分けて読む

prisma/prismaのREADMEは、現在のリポジトリをPrisma Nextの開発場所として説明しています。Prisma ORM 7を探している利用者にはv7ブランチを案内し、npmのprismaおよび@prisma/*パッケージも同ブランチから公開されると記載しています。Prisma NextはTypeScriptで書き直された新しい系統で、拡張可能性、組み合わせやすさ、AIエージェントとの利用を軸に掲げています。ここを一つの安定版として扱わず、既存ORMとの版の境界を最初に記録するのが実務上の出発点です。

Node.js 24から始まる二つの初期化経路

前提条件としてREADMEが挙げるのはNode.js 24以上とnpm、pnpm、yarnのいずれかです。新規プロジェクトではnpm create prisma@nextを実行し、対話式のscaffolderでJavaScriptフレームワークとPostgreSQLまたはMongoDBを選びます。既存リポジトリにはnpx @prisma/cli@next orm initを使う経路があり、prisma.config.ts、src/prisma/db.ts、スターター契約、ランタイムを用意して契約を生成します。READMEの説明では、既存のフレームワークやビルド設定には触れません。

生成物がエージェントの作業境界を作る

両方の導入経路は、プロジェクトルートにprisma-next.mdを置き、AIエージェントが先に読む案内を残します。initではワークフローごとのSKILL.mdも生成され、Claude Code向けの.claude/skillsと、CursorやCopilot Agentなどを想定した.agents/skillsの二つの場所に配置されます。skills-lock.jsonは導入したスキルの版を追跡するファイルです。これは自動的に安全な変更を保証する仕組みではありません。生成物をレビュー対象に含め、誰が契約とクエリを確認するかを決める必要があります。

データベース対応は同じ列に並ばない

READMEが示すPrisma 8の対応段階には差があります。PostgreSQLは主対象で、Prisma 8では一般提供と説明されています。MongoDBはEarly Access、SQLiteは現時点のproof of conceptです。MySQLは後続予定で、8.0.0-rc.1までに必要な作業はROADMAPを参照するよう案内されています。対応DBの名前だけを見て同じ運用水準と判断するのは危険です。トランザクション、型の表現、移行手順、障害時の復旧を、実際に使うDBとリリース候補の組み合わせで別々に確かめてください。

Early Accessの表示を採用判断に残す

READMEはPrisma NextをEarly Accessとして扱い、APIは利用者のフィードバックで変わるため本番ワークロードには勧めないと明記しています。AIエージェントには、モデルとリレーションを説明してクエリを書かせる例が示されていますが、生成された変更の正しさを誰が担保するかは利用側の責任です。PRISMA_NEXTのような既定値や未記載の運用ルールを想像で補わず、初期化後の差分、スキルの内容、契約から生成されたコードを保存して確認してください。

Apache 2.0と非公開の脆弱性報告

ライセンスはApache 2.0で、READMEはLICENSEへのリンクを示しています。再配布や改変の可否を判断するには、NOTICEや依存コンポーネントの条件も利用する版に合わせて確認します。セキュリティ問題はSECURITY.mdのPrivate Vulnerability Reportingの流れで扱い、公開issueに投稿しないよう求めています。ライセンスと非公開報告の案内は、サポート契約、性能保証、セキュリティ監査の結果を表すものではありません。採用候補にするなら、まず空の検証用データベースでinitを実行し、作成されたprisma.config.ts、db.ts、契約、skills-lock.jsonをレビューします。PostgreSQLで通常の読み書きと移行を試し、MongoDBやSQLiteを使う場合は対応段階の違いを記録します。エージェントに渡す要求文、生成差分、承認者、失敗時の復旧手順もリポジトリに残してください。Early AccessのAPIが変わった際に再生成だけで済むのか、手作業の修正が必要なのかを確認できて初めて、既存の開発工程へ組み込めます。Node.jsの版、パッケージマネージャー、接続文字列、開発用DBの初期状態も保存し、scaffolderとorm initのどちらを使ったかを記録します。拡張SPIを試す場合は、pgvector、ParadeDB、PostGISなどの例を本体と同じ対応段階だと扱わず、作者、依存、クエリ、データ移行を別に検証します。契約と生成コードを更新した場合は、既存のSQL、権限、トランザクション、エラー処理が変わっていないかを比較し、DBを空に戻して再実行できる手順を残します。

契約、DB、エージェントを別々に確認する

Prisma Nextの導入評価は、初期化が成功したかだけで終わりません。生成された契約がアプリの型と一致するか、db.tsが意図した接続先を使うか、prisma.config.tsの変更が誰に承認されるかを確認します。PostgreSQLの一般提供という説明と、MongoDBのEarly Access、SQLiteのproof of conceptを同じ列に置かず、実際に使うDBだけで読み書き、移行、失敗時の戻し方を試します。拡張SPIを使う場合は、pgvector、ParadeDB、PostGISなどの接続点と依存版を記録し、検索や地理空間処理の結果を自分の入力で確かめます。エージェントにはprisma-next.mdと該当SKILL.mdを読ませても、生成差分を自動承認しません。契約、クエリ、権限、SQL、ログ、秘密情報、バックアップを人が確認し、Early Accessの版とApache 2.0の表示をリリース記録へ残します。

版と変更責任を採用記録に残す

Prisma Nextを採用候補として記録する際は、v7ブランチのPrisma ORM 7と、Early AccessのPrisma Nextを区別します。Node.js 24以上、実行した初期化コマンド、生成物の差分、接続先DB、拡張の版、エージェントの提案と承認者を残します。PostgreSQLの一般提供、MongoDBのEarly Access、SQLiteのproof of conceptという対応段階を明記し、MySQLの予定を現行機能として扱いません。API変更、契約変更、移行失敗、権限漏れが起きた場合に戻せる版とバックアップを定め、Apache 2.0の表示とSECURITY.mdの非公開報告経路もリリース手順へ含めます。

編集部の結論

Prisma Nextは、Node.js 24以上のTypeScriptプロジェクトで、契約を起点にPostgreSQLやMongoDBを扱いたいチームが検討できる構成です。現時点ではPrisma Next自体がEarly Accessで、PostgreSQL以外の対応段階も異なります。採用前に生成物、契約変更、拡張SPI、エージェント用ファイルを固定した小さな検証を行い、本番投入の可否を版ごとに判断してください。READMEが示すscaffolderはフレームワークとデータベースを選び、prisma.config.tsやsrc/prisma/db.tsなどを生成します。既存リポジトリでは作業ツリーを保存し、依存関係、環境変数、マイグレーション、クエリ、スキルの更新を差分で確認してください。PostgreSQLはPrisma 8で一般提供、MongoDBはEarly Access、SQLiteは概念実証で、MySQLは後続とされています。ライセンスはApache 2.0で、セキュリティ問題は公開Issueへ書かない案内があります。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes