Prisma 入門：そもそも何者か、からインストールまで

Posted at 2026-04-04

はじめに

この記事では Prisma（プリズマ）が どんな道具か、そして プロジェクトにどう入れるか を、できるだけ噛み砕いて整理します。難しい設定の細部より、「用語の地図」と「最初の一通りの手順」を意識しています。

対象読者: データベースには触ったことがあるが、Prisma は初めての方
前提知識: ターミナルで npm が使えること、SQL や「テーブル」という言葉のイメージがあると読みやすいです
読んだあと: Prisma の位置づけが説明できる・空の Node プロジェクトに Prisma を入れてスキーマまで書ける、というところまでを目指します

Prisma とは

Prisma は、Node.js / TypeScript 向けの データベースツールキット です。ひとくちに言うと、「DB の形をコードで表し、その形に合わせたクライアントを自動で作ってくれる仕組み」 だと捉えるとわかりやすいです。

よく一緒に語られる ORM（Object-Relational Mapping） は、「テーブル行をオブジェクトのように扱う」ための層のイメージです。Prisma はそのうえで、スキーマファイル（後述）を中心に、マイグレーション（DB 構造のバージョン管理）や 型付きクエリ までひとまとめで扱えるのが特徴です。

たとえばレストランでいうと、メニュー表が schema.prisma、厨房との連絡役が PrismaClient だと思うと分かりやすいかもしれません。メニュー（モデル）が決まっていれば、注文（クエリ）の取り違えが減ります。

手書き SQL だけだと、「カラム名をひとつ間違えても実行するまで気づかない」みたいなことが起きがちです。Prisma なら エディタの補完や型チェック の恩恵を受けやすく、「DB とアプリの約束」がコードに残る ので、あとから読んでも迷子になりにくいです。

Prisma の特徴・メリット

スキーマファースト: schema.prisma にモデル（テーブルに相当）を書き、そこからクライアントやマイグレーションの土台になる
型安全: 生成された PrismaClient のメソッドに、引数・戻り値の型がつきやすい（TypeScript と相性がよい）
マイグレーション: スキーマの変更を SQL の履歴として残し、環境ごとに同じ構造を再現しやすい
複数 DB に対応: PostgreSQL、MySQL、SQLite など、プロジェクトに合わせて選べる（利用できる機能は DB によって差がある）

やり方	うれしいところ	気をつけるところ
生 SQL	自由度が高い、複雑なクエリに強い	型や命名のブレを自分で守る必要がある
Prisma	型・補完・チームでの「約束」が立てやすい	スキーマ DSL と API を覚える必要がある

主要コマンド：いつ・何のために使うか

プロジェクトに最初から Prisma を入れるとき … init が中心
日々の開発でスキーマやモデルをいじるとき … migrate dev と generate が中心
サーバーや CI に載せるとき … migrate deploy と generate が中心

下の表は、入門でよく触るものに絞っています。

コマンド	だいたいいつ使う？	何が起きる？	補足
`prisma init`	そのプロジェクトで Prisma を始める最初の一度（または新規サービスを足すとき）	`schema.prisma` のひな形や `.env` の雛形ができる	既存プロジェクトに後から足す場合も同じ。すでにあるなら二重に走らせない
`prisma generate`	`schema.prisma` を変えたあと、リポジトリを clone したあと、`prisma` / `@prisma/client` のバージョンを上げたあと	`PrismaClient` のコード（型・メソッド）がスキーマに合わせて作り直される	DB には触れない。「アプリが使うクライアントを最新の約束に合わせる」作業。CI の build 前に入れることも多い
`prisma migrate dev`	開発中、モデルを増やした・カラムを変えたなどスキーマを変えて、その変更を開発用 DB に反映したいとき	差分からマイグレーション SQL を生成し、`prisma/migrations` に保存かつ開発 DB に適用。多くの場合 `generate` もまとめて走る	本番 DB には使わないのが原則。チームではこのフォルダを Git で共有する
`prisma migrate deploy`	本番・ステージング・CI で、すでにコミット済みのマイグレーションを順に当てたいとき	`migrations` フォルダの未適用分だけを DB に実行	新しいマイグレーションを“生み出す”コマンドではない（開発で作ったものを流す側）
`prisma db push`	試作や個人検証で、マイグレーション履歴を残さずにとりあえず DB をスキーマに近づけたいとき	スキーマを DB に押し付ける（履歴は `migrate` ほど厳密でない）	チーム開発の本流には向きにくいことが多い。公式も用途を分けて説明しているので、慣れたら `migrate` との違いを読むとよい
`prisma studio`	ブラウザでテーブルの中身を見たい・手で直したいとき（開発中）	ローカル UI が立ち上がる	本番 URL に繋いで触るのは権限とセキュリティに注意
`prisma validate`	コミット前や CI で、スキーマの文法や設定が妥当か確認したいとき	エラーがあれば終了コードで分かる	`migrate` や `generate` と別に、「まず軽くチェック」に使える
`prisma format`	スキーマをきれいに揃えたいとき（任意）	`schema.prisma` を整形	エディタ拡張と役割が被ることも多い

開発のループのイメージ

日々の作業では、だいたい次のループになります。

schema.prisma を編集する（モデル追加・フィールド変更など）
npx prisma migrate dev --name 変更のわかりやすい名前 で、マイグレーション作成＋開発 DB 反映（＋多くの場合 generate まで）
アプリのコードを、新しいフィールド名などに合わせて直す
動かして確認する

generate だけ単独で打つ場面の例は次のようなときです。

migrate dev を使わずにスキーマだけ直した（または別ブランチを取り込んだ）あと、型が古いと言われた
npm install で Prisma のバージョンが変わった ので、生成物を揃え直したい
Docker や CI で、migrate deploy のあとに ビルド前に必ず generate を入れている

`migrate dev` と `migrate deploy` の役割分担（短く）

migrate dev … 開発者のマシンで「新しい変更のパック（マイグレーション）を作って、自分の DB に当てる」
migrate deploy … サーバーで「Git に入っているマイグレーションを、まだ当たっていない分だけ順に当てる」

この切り分けができると、「なぜ本番で migrate dev を打ってはいけないのか」 も腹落ちしやすいです（dev は対話的な処理やシャドウ DB など、開発向けの前提が絡むことがあります）。

実際の使い方：インストールから最初の一歩まで

ここでは 新しい Node プロジェクトに Prisma を足す 流れの例です。すでに Next.js など別フレームワークがある場合も、「prisma を devDependency に入れる」「schema.prisma を置く」 という骨格は同じです。

1. プロジェクトの用意とパッケージのインストール

空のフォルダで package.json を用意し、CLI 用の prisma と 実行時の @prisma/client を入れます。

npm init -y
npm install @prisma/client
npm install -D prisma

prisma: migrate や generate など、開発時に使う CLI
@prisma/client: アプリから import して使うクライアント本体（generate で中身が生成される）

2. Prisma を初期化する

npx prisma init

すると、だいたい次のようなものができます。

prisma/schema.prisma … モデルと DB 接続の設定を書くファイル（いわゆる スキーマ）
.env … 接続文字列 DATABASE_URL を置く場所（秘密情報は Git に上げない）

3. `schema.prisma` のイメージ

最小限の例です（DB は例として PostgreSQL を想定）。

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

model User {
  id    Int    @id @default(autoincrement())
  email String @unique
  name  String?
}

generator: クライアントをどう生成するか
datasource: どの DB に繋ぐか（url は .env から）
model: アプリ側の「型」のような単位で、テーブルに対応づけられる

Prisma の バージョンによっては、generator の provider が prisma-client-js ではなく prisma-client などになっていることがあります。その場合は npx prisma init で生成されたファイルをベースにする のがいちばん確実です。

.env には、使っている DB に合わせた URL を入れます（例はダミーです）。

# PostgreSQL の例（ユーザー・パス・ホスト・DB 名は環境に合わせて変更）
DATABASE_URL="postgresql://USER:PASSWORD@localhost:5432/mydb"

4. DB に反映する（マイグレーション）

開発中は、だいたい次のようなコマンドで スキーマからマイグレーションを作り、DB に当てる 流れになります。

# 初回など：マイグレーションを作成して開発用 DB に適用
npx prisma migrate dev --name init

migrate dev: ローカル開発向け。prisma/migrations に SQL の履歴が溜まります
本番や CI では migrate deploy を使うことが多いです（環境によって運用は変わります）

5. クライアントを生成する

マイグレーションの前後で、スキーマを変えたら生成を忘れないようにします。

npx prisma generate

migrate dev の過程で一緒に走ることも多いですが、「スキーマをいじったら generate」 と覚えておくと安心です。

6. Node からクエリする（超短い例）

import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

async function main() {
  const users = await prisma.user.findMany();
  console.log(users);
}

main()
  .finally(async () => {
    await prisma.$disconnect();
  });

補足（Prisma 7 以降の方へ）: バージョンによっては、PrismaClient に ドライバアダプター を渡す形が推奨されることがあります。入門の段階では「公式ドキュメントの Getting Started を自分の DB に合わせて一通りやる」のがいちばん安全です。

まとめ

Prisma は スキーマを中心に、DB アクセスを型付きで扱いやすくする ためのツールキットです
init は最初の一度、日々は migrate dev（開発）と generate（スキーマ変更後・clone 後など） が中心、本番は migrate deploy と覚えると運用が整理しやすいです
導入の基本は npm install → prisma init → schema.prisma → migrate dev →（必要なら）generate の流れです
.env の DATABASE_URL は環境ごとに切り替え、リポジトリにコミットしない ようにします
手書き SQL と比べて チームでの「約束」がコードに残りやすい のが大きなメリットです
次の一歩としては、Prisma 公式の Getting Started で、自分が使う DB（PostgreSQL / MySQL など）の手順をそのままなぞるのがおすすめです

参考文献

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up