はじめに

前回、データベースの構造変更を安全に履歴管理する「マイグレーション」の思想について整理しました。

手動でデータベースを書き換えるリスクを排し、コードで設計図を管理することがいかに大切か、というお話でした。

では、実際のアプリケーション開発において、データベースの構造を定義したり、中にデータを保存したり読み出したりするプログラムは、どのように書くのがベストでしょうか。

生のSQL（SELECT や INSERT）をコードの中に直接ガシガシ書いていくのも一つの手ですが、現代のWeb開発では 「ORM（Object-Relational Mapper）」 というツールを間に挟むのが主流です。

1. そもそも「ORM」とは何か？

ORMとは一言でいえば、「データベースのテーブル」と「プログラムのコード（オブジェクト）」を翻訳して結びつけてくれる仕組みのことです。

生のSQLをプログラムに直接埋め込む場合、クエリはただの「文字列」として扱われます。

そのため、カラム名をタイポ（打ち間違い）していても、実際にアプリを動かしてそのクエリが実行されるまでエラーに気づけません。

また、取得したデータがどんな形（データ型）をしているのかをプログラム側で手動で定義し直す必要があり、開発の規模が大きくなると管理が破綻しがちです。

ORMを採用すると、SQL文を直接書く代わりに、お使いの言語（TypeScriptなど）の直感的なメソッドを使ってデータを操作できるようになります。

データベースの面倒な仕様をツールが吸収してくれるため、開発者は安全かつスピーディに機能を組み立てることに集中できます。

2. その中でも、なぜ「Prisma」なのか？

数あるORMの中でも、現代のTypeScript環境（特にNext.jsなど）で熱狂的な支持を集めているのが 「Prisma（プリズマ）」 です。

従来のORMは初期設定が複雑だったり、型安全（データの種類が正しいことをプログラムが保証する仕組み）の恩恵を100%受けられなかったりする課題がありました。

しかしPrismaは、

独自の非常に読みやすい設計図ファイルを1枚書くだけで、データベースの構築（マイグレーション）からプログラム側の型定義までを、裏側で一発で自動同期してくれる

という、これまでにない快適な開発体験を提供してくれます。

今回は、このPrismaの心臓部であり、データベースのすべての設計図が書き込まれる schema.prisma というファイルの基本的な書き方について、実務的な視点を交えて整理していきます。

3. schema.prismaとは何か

schema.prisma とは、一言でいえば「データベースの未来の姿を宣言するファイル」です。

schema.prismaとは、Prismaにおいて「データベースにどんなテーブルがあり、それぞれにどんなカラムがあるか」を定義する、いわば設計図そのもののファイルです。

前回の記事で登場した「スキーマ（設計図）」を、Prisma専用の非常に読みやすい形式で記述します。

このファイルに定義を書き、コマンドを実行することで、Prismaが自動的に生SQL（CREATE TABLE など）のマイグレーションファイルを生成し、実際のデータベースに反映してくれます。

ファイルの中身は、大きく分けて次の2つの要素で構成されています。

データソース・クライアントの設定部分： 「どのデータベース（PostgreSQLか、MySQLかなど）に、どのURLで接続するか」というインフラ情報
モデルの定義部分： 「どんなテーブルがあり、どんなデータが入るか」という純粋なデータ構造の情報

今回は、日々の開発で最も頻繁に書き換えることになる、後者の「モデル定義」の書き方にスポットを当てて見ていきます。

4. モデル定義の基本構成

Prismaでは、データベースの1つのテーブルを「model（モデル）」という単位で定義します。

モデルの中には、そのテーブルが持つカラムを「名前」「型」「属性（付加情報）」という3つの要素を並べて書いていきます。

具体的なコード例を見たほうがイメージが湧きやすいでしょう。例えば、ユーザーを管理する User テーブルは以下のように記述します。

model User {
  id        Int      @id @default(autoincrement()) // 名前、型、属性（主キー & 自動連番）
  email     String   @unique                       // 一意の制約（ユニーク）
  name      String?                                // 「?」はNullable（空を許可）
  createdAt DateTime @default(now())               // レコード作成時の時刻を自動注入
}

「識別するためのID」「名前」「メールアドレス」「登録日時」といったカラムを、それぞれの型と付加情報とあわせて並べていくイメージです。

IDには「自動的に一意な値を割り振る」という付加情報を、登録日時には「レコードが作られた瞬間の時刻を自動的に入れる」という付加情報を指定する、といった具合です。

普段からSQLを叩いている方であれば、それぞれの要素が以下のように直感的にマッピングされているのが分かるはずです。

@id：SQLでいう PRIMARY KEY（主キー）
@default(autoincrement())：自動連番シリアル
@unique：UNIQUE 制約（重複不可）
String?****（型の後ろの型修飾子 ?****）：デフォルトは NOT NULL であり、? をつけることで初めて NULL を許容する設定になる
@default(now())：SQLの DEFAULT CURRENT_TIMESTAMP

Excelのテーブル定義書や、無機質なSQL文を眺めるよりも、はるかに可読性が高く、データ構造が一目で理解できる書式になっているのがPrismaの大きな魅力です。

5. リレーション（テーブル間のつながり）の表現

実際のアプリケーション開発では、1つのテーブルだけで完結することはほぼありません。複数のテーブルが互いに関連し合う「リレーション（親子関係）」を定義する必要があります。

リレーションには主に次のようなパターンがあります。

1対多：1人のユーザーが、複数の記事を持つ（ユーザーと記事の関係など）
多対多：1つの記事が複数のタグを持ち、1つのタグも複数の記事に付けられる（記事とタグの関係など）
1対1：1人のユーザーが、1つのプロフィール詳細情報を持つ（ユーザーとプロフィールの関係など）

最も頻繁に登場するのが、「1対多（One-to-Many）」の関係です。例えば、「1人のユーザー（User）が、複数の記事（Post）を投稿できる」というケースを考えてみます。

Prismaでは、テーブル同士のつながりを以下のように表現します。

// 親テーブル
model User {
  id    Int    @id @default(autoincrement())
  posts Post[] // 1人のユーザーは複数の「Post」を持つ（1対多の「多」）
}

// 子テーブル
model Post {
  id       Int    @id @default(autoincrement())
  title    String
  authorId Int    // 実際にDBに保存される外部キー（Foreign Key）

  // Prisma専用の仮想フィールド（実際にDBとどう紐づいているかの宣言）
  author   User   @relation(fields: [authorId], references: [id])
}

💡 読み解きのポイント

子である Post モデル側の記述が秀逸です。

実際のデータベースには、数値型としての外部キー（authorId）だけが保存されますが、Prismaのスキーマ上には @relation という特別な仕組みを使って、「このauthorIdは、Userモデルのidと結びついているんだよ」という関係性を明示します。

このようにPrismaでは、モデルの中に「関連する相手のモデル」をフィールドとして書き加えることで、テーブル間のつながりを表現します。

あわせて、実際にデータベース上でどのカラムとどのカラムが結びついているか（外部キー）を指定することで、テーブル同士の関係がスキーマ上に明示されます。

データ分析でいう「ER図の矢印」を、そのままテキストコードとして書き落としている感覚です。これにより、テーブル間の依存関係が極めてクリアになります。

6. 定義したschemaはどう使われるか

このように schema.prisma にモデルとリレーションを書き終えたら、この定義をもとにマイグレーションを実行します。

この1枚のファイルから、Prismaは2つの絶大な恩恵をもたらしてくれます。

安全なマイグレーションの自動生成：

コマンドを叩くだけで、このファイルとの差分を計算し、完璧なSQLのマイグレーションファイルを自動で吐き出してDBに適用してくれます。手動SQLによるタイポやミスはここで完全に撲滅されます。
TypeScriptの型（Type）の自動生成：

これがフロントエンド開発においてPrismaが熱狂的に支持される最大の理由です。 Prismaは、この設計図を読み込んで「データベースの構造と100%一致したTypeScriptの型定義」を裏側で自動生成してくれます。

これにより、コード側でデータベースを操作する際に、存在しないカラム名を指定してしまったり、型の異なる値を入れてしまったりすると、実行前の段階でエラーとして検出できます。

インフラ（DBの構造）の変更が、リアルタイムにアプリケーションのコード（型）へと伝播するこの「型安全（Type Safe）」な体験こそが、現代のWeb開発の強力な基盤となっています。

まとめ

Prismaの心臓部である schema.prisma の書き方について整理しました。

schema.prisma****： テーブル構造、データ型、制約、リレーションのすべてを内包するアプリ開発の絶対的な設計図。
モデル定義： SQLの制約（主キーやユニーク、Nullableなど）を、人間が最も読みやすいシンプルな構文で宣言する。
リレーション： 親子関係を @relation で記述し、ER図のような繋がりをコード上に明示する。
型安全への昇華： 記述された設計図は、マイグレーションの実行だけでなく、アプリケーション側の「型定義」へと自動変換される。

この1枚の設計図を正しくメンテナンスしていくことさえ意識すれば、データベースの管理や日々のクエリの実装は、驚くほど安全でイージーなものになります。

「データベースの構造」という一見硬くて脆いインフラを、プログラムのコードと同じように柔軟に、かつ厳格にコントロールする。

この体験を一度味わうと、手動でSQLを実行していた過去にはもう戻れなくなるはずです。