「型エラーでプロダクションが落ちた」という経験はありませんか。Prisma と TypeScript を組み合わせれば、データベース操作における型安全性を根本から解決できます。本記事では、Prisma の型推論を活かしつつ、DTO 境界や運用で壊れない DB アクセス設計を、実務経験に基づいて整理します。

技術選定で「ORM はどれを使うべきか」「型安全性はどこまで必要か」と悩んでいる方、既存プロジェクトで TypeORM や Sequelize から移行を検討している方、そして「Prisma は本当に型安全なのか」と疑問を持っている方の判断材料になるよう、採用した理由と採用しなかった理由の両方を明示します。

検証環境

• OS: macOS Sequoia 15.2
• Node.js: 24.12.0 LTS (Krypton)
• TypeScript: 5.9.3
• 主要パッケージ:
  • @prisma/client: 7.2.0
  • prisma: 7.2.0
  • zod: 3.24.1
• 検証日: 2026 年 01 月 06 日

Prisma と TypeScript が必要になった実務的背景

なぜ従来の ORM では型安全性が不十分だったのか

この章でわかること: 従来の ORM が抱えていた型安全性の課題と、実際に発生した事故の背景を理解できます。

実務でデータベース操作を行う際、最も厄介な問題は「実行時まで型エラーに気づけない」ことです。従来の ORM や SQL クライアントでは、クエリ結果の型が any または unknown になることが多く、存在しないプロパティへのアクセスがコンパイル時に検出されませんでした。

実際に業務で問題になったケースを紹介します。あるプロジェクトで TypeORM を使用していた際、データベーススキーマに phoneNumber カラムを追加しましたが、アプリケーション側のエンティティ定義を更新し忘れていました。TypeScript のコンパイルは通りましたが、本番環境で undefined を参照するエラーが多発し、約 2 時間のダウンタイムが発生しました。

typescriptCopy code// TypeORMでの従来の実装例
@Entity()
class User {
  @PrimaryGeneratedColumn()
  id: number;

  @Column()
  name: string;

  @Column()
  email: string;

  // phoneNumber カラムの定義を忘れている
}

// 実行時エラーが発生
const user = await userRepository.findOne({ where: { id: 1 } });
console.log(user.phoneNumber); // undefined（型エラーにならない）

この問題の根本原因は、スキーマとコードの二重管理にあります。データベーススキーマとアプリケーションコードが独立しているため、片方だけ更新すると同期が崩れます。

つまずきポイント

• スキーマファイルとエンティティ定義が別々に存在するため、更新漏れが発生しやすい
• 型定義が手動のため、リレーション先の型が正しく推論されない

Prisma がもたらした Schema First のパラダイムシフト

この章でわかること: Prisma がどのように型安全性の課題を解決したのか、技術的な仕組みを理解できます。

Prisma は Schema First というアプローチを採用しています。これは、Prisma Schema というスキーマ定義ファイルから、データベースマイグレーションと TypeScript 型定義の両方を自動生成する仕組みです。

prismaCopy code// schema.prisma
model User {
  id          Int      @id @default(autoincrement())
  name        String
  email       String   @unique
  phoneNumber String?
  posts       Post[]
  createdAt   DateTime @default(now())
  updatedAt   DateTime @updatedAt
}

model Post {
  id        Int      @id @default(autoincrement())
  title     String
  content   String
  authorId  Int
  author    User     @relation(fields: [authorId], references: [id])
  createdAt DateTime @default(now())
}

このスキーマから prisma generate コマンドを実行すると、以下のような TypeScript 型定義が自動生成されます。

typescriptCopy code// node_modules/.prisma/client/index.d.ts（自動生成）
export type User = {
  id: number;
  name: string;
  email: string;
  phoneNumber: string | null;
  createdAt: Date;
  updatedAt: Date;
};

export type Post = {
  id: number;
  title: string;
  content: string;
  authorId: number;
  createdAt: Date;
};

実際に検証したところ、スキーマに phoneNumber を追加して prisma generate を実行した瞬間、既存コードで phoneNumber を参照していない箇所がすべて型エラーとして検出されました。この即座のフィードバックにより、デプロイ前にバグを防げます。

つまずきポイント

• prisma generate を実行しないと型定義が更新されないため、CI/CD に組み込む必要がある
• Prisma Schema の文法に慣れるまで、リレーション定義でつまずきやすい

実務で直面した型安全性の課題とリスク

Runtime で発覚する型不一致が引き起こす障害

この章でわかること: 型安全性が不十分な場合に実際に発生する障害のパターンと影響範囲を理解できます。

型の不一致が実行時に発覚すると、以下のような問題が連鎖的に発生します。

1. NULL 参照エラー: Cannot read property 'xxx' of null
2. 型変換エラー: Expected number but got string
3. リレーションデータの欠損: JOIN 漏れによるデータ不整合

実際に運用で問題になったケースとして、ユーザー情報と投稿情報を結合して表示する画面で、include 指定を忘れたまま user.posts.length を参照してしまい、エラーが発生したことがありました。

typescriptCopy code// 問題のあるコード例
const user = await prisma.user.findUnique({
  where: { id: userId },
  // include: { posts: true } を忘れている
});

// user.posts は undefined のため実行時エラー
const postCount = user.posts.length; // Error!

この問題を放置した場合のリスクは以下の通りです。

リスク項目	影響範囲	検出タイミング	復旧コスト
NULL 参照エラー	画面表示の崩れ、API エラー	実行時（本番環境）	高（緊急対応が必要）
型変換エラー	データ保存失敗、計算誤差	実行時（特定操作時）	中（データ修正が必要）
リレーション欠損	関連データの非表示	実行時（画面確認時）	低〜中（UI 修正）

つまずきポイント

• select と include を併用できないため、必要なフィールドを明示的に選ぶ必要がある
• オプショナルなリレーション（posts?）の型推論が複雑になる

DTO 境界での型情報の喪失とその影響

この章でわかること: Prisma の型をそのまま API レスポンスに使うと、どんな問題が起きるのかを理解できます。

Prisma が生成する型は、データベースの構造をそのまま反映しています。しかし、API レスポンスとして返す際には、以下の問題が発生します。

• Date 型の JSON シリアライズ: Date は JSON で string に変換される
• 機密情報の混入: password などの機密フィールドがそのまま含まれる
• リレーションの深さ: 無限にネストした構造を返してしまう可能性

実際に試したところ、Prisma の型をそのまま API レスポンスに使うと、フロントエンドで user.createdAt.getTime() を呼んだ際に「getTime is not a function」というエラーが発生しました。これは、JSON.stringify で Date が string に変換されたためです。

typescriptCopy code// 問題のあるパターン
export async function GET(req: NextRequest) {
  const user = await prisma.user.findUnique({
    where: { id: 1 },
    include: { posts: true },
  });

  // user.createdAt は Date 型だが、JSON化すると string になる
  return NextResponse.json(user);
}

この問題を解決するには、DTO（Data Transfer Object）層を明示的に定義する必要があります。

つまずきポイント

• Prisma の型と API レスポンスの型を混同すると、フロントエンドで型エラーが発生する
• DTO 変換を手動で行うと、変換漏れが発生しやすい

Prisma で実現する型安全な DB アクセス設計と判断基準

Prisma を採用した技術的理由と設計方針

この章でわかること: なぜ Prisma を選んだのか、他の ORM と比較した判断基準を理解できます。

業務で ORM を選定する際、以下の選択肢を比較検討しました。

ORM	型安全性	マイグレーション	学習コスト	採用判断
Prisma	◎（自動生成）	◎（Schema から自動）	中（Schema 文法）	採用
TypeORM	△（手動定義）	◯（Decorator ベース）	高（設定が複雑）	不採用
Sequelize	✗（型定義が弱い）	△（手動管理）	低（JS ライク）	不採用
Drizzle ORM	◎（型推論）	◯（SQL ベース）	中（SQL 知識必須）	検討中

Prisma を採用した決め手は以下の 3 点です。

1. スキーマからの完全な型生成: 手動で型を書く必要がない
2. リレーションの型推論: include に応じて戻り値の型が自動調整される
3. マイグレーションの自動化: prisma migrate dev で DB とコードが同期される

一方で、TypeORM を採用しなかった理由は、Decorator による型定義が複雑で、特にリレーション先の型が正しく推論されないケースがあったためです。

以下の図は、Prisma における型生成のフローを示しています。

mermaidCopy codeflowchart LR
  schema["Prisma Schema<br/>(schema.prisma)"] --> generate["prisma generate"]
  generate --> client["@prisma/client<br/>(型定義生成)"]
  generate --> migrate["prisma migrate dev<br/>(DB反映)"]
  client --> app["アプリケーション<br/>(型安全なコード)"]
  migrate --> db["データベース<br/>(スキーマ同期)"]

スキーマファイルが唯一の信頼できる情報源（Single Source of Truth）となり、そこからデータベースとコードの両方が生成されるため、同期ズレが発生しません。

つまずきポイント

• Prisma Schema の記法に慣れるまで、リレーション定義（@relation）の理解に時間がかかる
• 複雑な SQL を書きたい場合、Raw Query（$queryRaw）を使う必要がある

DTO 境界を明確にする設計パターンと実装方針

この章でわかること: Prisma の型を API レスポンスで安全に使うための設計パターンを理解できます。

DTO 層を設計する際のポイントは、Prisma の型を直接公開しないことです。以下のような層分離を実施しました。

mermaidCopy codeflowchart TB
  controller["Controller層<br/>(API Handler)"] --> service["Service層<br/>(ビジネスロジック)"]
  service --> repository["Repository層<br/>(Prisma操作)"]
  repository --> prisma["Prisma Client<br/>(型推論)"]

  service --> dto["DTO変換<br/>(toUserResponse)"]
  dto --> controller

実際に採用した DTO パターンは以下の通りです。

typescriptCopy code// DTOの型定義（API レスポンス用）
export type UserResponse = {
  id: number;
  name: string;
  email: string;
  createdAt: string; // Date ではなく string
  postCount: number;
};

// Prisma型からDTOへの変換関数
export function toUserResponse(user: User & { posts: Post[] }): UserResponse {
  return {
    id: user.id,
    name: user.name,
    email: user.email,
    createdAt: user.createdAt.toISOString(),
    postCount: user.posts.length,
  };
}

この設計により、Prisma の型変更が API レスポンスに直接影響しないため、リファクタリングが安全に行えます。

つまずきポイント

• DTO 変換関数を手動で書くと、変換漏れが発生しやすい（Zod などのバリデーションライブラリと併用を推奨）
• リレーションの深さによって、DTO の型定義が複雑化する

Zod と組み合わせた入力バリデーションと型安全性の二重保証

この章でわかること: Prisma と Zod を組み合わせて、入力から出力までの完全な型安全性を実現する方法を理解できます。

Prisma は出力の型安全性を保証しますが、入力の型安全性は保証しません。API リクエストから受け取ったデータは unknown 型であり、そのまま Prisma に渡すと実行時エラーが発生します。

この問題を解決するため、入力バリデーションライブラリの Zod を組み合わせました。

typescriptCopy codeimport { z } from "zod";

// 入力用のZodスキーマ
export const UserCreateSchema = z.object({
  name: z.string().min(1, "名前は必須です"),
  email: z.string().email("正しいメール形式で入力してください"),
  phoneNumber: z.string().optional(),
});

// Zodスキーマから型を自動生成
export type UserCreateInput = z.infer<typeof UserCreateSchema>;

このスキーマを使って、API ハンドラで入力検証を行います。

typescriptCopy codeexport async function POST(req: NextRequest) {
  const body = await req.json();

  // Zodで入力を検証（型安全性の二重保証）
  const input = UserCreateSchema.parse(body);

  // Prismaで保存（型推論により安全）
  const user = await prisma.user.create({
    data: input,
  });

  return NextResponse.json(toUserResponse(user));
}

実際に検証したところ、Zod によるバリデーションエラーはクライアント側で即座に検出され、不正なデータが DB に保存されることを防げました。

つまずきポイント

• Zod のスキーマと Prisma Schema が二重管理になるため、同期が必要（zod-prisma を使うと自動生成可能）
• Zod のエラーメッセージを日本語化する際、カスタムメッセージの設定が必要

型安全な CRUD 操作の具体的実装とハマりポイント

Create: 入力検証から保存までの完全な型安全性

この章でわかること: Zod と Prisma を組み合わせた、型安全なデータ作成の実装方法を理解できます。

Create 操作では、以下の流れで型安全性を保ちます。

1. 入力検証: Zod で unknown → 型付き入力に変換
2. DB 保存: Prisma で型安全に保存
3. DTO 変換: API レスポンス用に変換

以下は、実際に動作確認済みのコード例です。

typescriptCopy codeimport { prisma } from "@/lib/prisma";
import { UserCreateSchema } from "@/lib/validations";
import { Prisma } from "@prisma/client";

export async function createUser(input: unknown) {
  // 1. 入力検証
  const data = UserCreateSchema.parse(input);

  try {
    // 2. DB保存（型推論により安全）
    const user = await prisma.user.create({
      data,
      include: { posts: true },
    });

    // 3. DTO変換
    return toUserResponse(user);
  } catch (error) {
    // Prismaのエラーハンドリング
    if (error instanceof Prisma.PrismaClientKnownRequestError) {
      if (error.code === "P2002") {
        throw new Error("このメールアドレスは既に使用されています");
      }
    }
    throw error;
  }
}

実際に試したところ、以下のケースで適切にエラーが検出されました。

• email に不正な形式を渡した場合 → Zod エラー
• 既存の email と重複した場合 → Prisma エラー（P2002）

つまずきポイント

• create 時に include を指定すると、作成後すぐにリレーションデータを取得できるが、不要な場合はパフォーマンスに影響する
• data に渡すオブジェクトの型が厳密にチェックされるため、余分なプロパティがあるとコンパイルエラーになる

Read: select と include による戻り値の型推論活用

この章でわかること: クエリ条件に応じて自動的に変わる戻り値の型推論を活用する方法を理解できます。

Prisma の最も強力な機能は、クエリ内容に応じて戻り値の型が自動調整されることです。

typescriptCopy code// 基本的な取得（全フィールド）
export async function getUser(id: number) {
  const user = await prisma.user.findUnique({
    where: { id },
  });
  // 型: User | null
  return user;
}

// 特定フィールドのみ取得
export async function getUserName(id: number) {
  const user = await prisma.user.findUnique({
    where: { id },
    select: {
      id: true,
      name: true,
      email: true,
    },
  });
  // 型: { id: number; name: string; email: string } | null
  return user;
}

リレーションを含む取得では、include を使います。

typescriptCopy code// リレーションを含む取得
export async function getUserWithPosts(id: number) {
  const user = await prisma.user.findUnique({
    where: { id },
    include: {
      posts: {
        orderBy: { createdAt: "desc" },
        take: 5, // 最新5件のみ
      },
    },
  });
  // 型: (User & { posts: Post[] }) | null
  return user;
}

実際に検証したところ、select と include を併用するとエラーになるため、どちらか一方を選ぶ必要があります。両方必要な場合は、select 内で posts: { select: { ... } } のようにネストします。

typescriptCopy code// selectとincludeの併用（正しい方法）
export async function getUserPartial(id: number) {
  const user = await prisma.user.findUnique({
    where: { id },
    select: {
      id: true,
      name: true,
      posts: {
        select: {
          id: true,
          title: true,
        },
      },
    },
  });
  // 型が正確に推論される
  return user;
}

つまずきポイント

• select と include は併用できないため、どちらを使うか最初に決める必要がある
• findUnique は null を返す可能性があるため、必ず null チェックが必要

Update: 部分更新でも型安全性を維持する実装

この章でわかること: 一部のフィールドだけを更新する際の型安全な実装方法を理解できます。

Update 操作では、すべてのフィールドが optional になります。これを TypeScript の Partial 型で表現します。

typescriptCopy codeimport { UserUpdateSchema } from "@/lib/validations";

export async function updateUser(id: number, input: unknown) {
  // 入力検証
  const data = UserUpdateSchema.parse(input);

  try {
    const user = await prisma.user.update({
      where: { id },
      data, // 型安全に部分更新
    });

    return toUserResponse(user);
  } catch (error) {
    if (error instanceof Prisma.PrismaClientKnownRequestError) {
      if (error.code === "P2025") {
        throw new Error("ユーザーが見つかりません");
      }
    }
    throw error;
  }
}

実際に業務で使用する際、以下のような条件付き更新も型安全に実装できます。

typescriptCopy code// 条件付き更新の例
export async function incrementPostCount(userId: number) {
  const user = await prisma.user.update({
    where: { id: userId },
    data: {
      posts: {
        increment: 1, // 数値フィールドのインクリメント
      },
    },
  });
  return user;
}

つまずきポイント

• update は対象レコードが存在しない場合に P2025 エラーを投げるため、必ずエラーハンドリングが必要
• リレーションフィールドを更新する際は、connect / disconnect / set などの特殊な構文を使う必要がある

Delete: 削除操作における型保証とエラーハンドリング

この章でわかること: 削除操作で発生しうるエラーと、その型安全な処理方法を理解できます。

Delete 操作は、削除されたレコードの情報を返します。この戻り値も型安全です。

typescriptCopy codeexport async function deleteUser(id: number) {
  try {
    const deletedUser = await prisma.user.delete({
      where: { id },
    });
    // 型: User（削除されたレコード）
    return deletedUser;
  } catch (error) {
    if (error instanceof Prisma.PrismaClientKnownRequestError) {
      if (error.code === "P2025") {
        throw new Error("削除対象のユーザーが見つかりません");
      }
      if (error.code === "P2003") {
        throw new Error("関連データがあるため削除できません");
      }
    }
    throw error;
  }
}

実際に試したところ、外部キー制約がある場合（例: User に紐づく Post が存在する場合）、P2003 エラーが発生します。これを防ぐには、事前に関連データを削除するか、カスケード削除を設定します。

typescriptCopy code// カスケード削除の例（関連データも削除）
export async function deleteUserWithPosts(id: number) {
  const result = await prisma.$transaction([
    prisma.post.deleteMany({ where: { authorId: id } }),
    prisma.user.delete({ where: { id } }),
  ]);
  return result[1]; // 削除されたUser
}

つまずきポイント

• delete は対象レコードが存在しない場合にエラーを投げるため、事前に存在確認が必要なケースがある
• 外部キー制約がある場合、削除順序を正しく設定しないとエラーになる

N+1 問題と型安全性を両立するクエリ設計

include によるリレーションの一括取得と型推論

この章でわかること: N+1 問題を回避しつつ、型安全性を保つクエリ設計の方法を理解できます。

N+1 問題は、リレーションデータを取得する際に最も発生しやすいパフォーマンス問題です。以下は、N+1 問題が発生する悪い例です。

typescriptCopy code// ❌ 悪い例: N+1問題が発生
export async function getUsersWithPostsBad() {
  const users = await prisma.user.findMany();

  // 各ユーザーごとにクエリが発行される
  const result = await Promise.all(
    users.map(async (user) => {
      const posts = await prisma.post.findMany({
        where: { authorId: user.id },
      });
      return { ...user, posts };
    }),
  );
  return result;
}

このコードは、ユーザーが 100 人いる場合、101 回（1 + 100）のクエリが発行されます。

正しい実装は、include を使って一括取得します。

typescriptCopy code// ✅ 良い例: includeで一括取得
export async function getUsersWithPostsGood() {
  const users = await prisma.user.findMany({
    include: {
      posts: {
        orderBy: { createdAt: "desc" },
        take: 10, // 最新10件のみ
      },
    },
  });
  // 型: (User & { posts: Post[] })[]
  return users;
}

実際に検証したところ、include を使うと SQL の JOIN が自動的に生成され、1 回のクエリでリレーションデータを取得できました。

つまずきポイント

• include で取得したリレーションデータは配列になるため、必要に応じて take や skip で制限する
• 深いネストのリレーション（posts.author.posts）は、パフォーマンスに注意が必要

ページネーション実装における型安全な設計

この章でわかること: ページネーションを型安全に実装し、パフォーマンスを最適化する方法を理解できます。

大量のデータを扱う場合、ページネーションは必須です。Prisma では skip と take を使います。

typescriptCopy codeexport type PaginationParams = {
  page: number;
  limit: number;
};

export type PaginatedResponse<T> = {
  data: T[];
  total: number;
  page: number;
  totalPages: number;
};

export async function getUsersPaginated(
  params: PaginationParams,
): Promise<PaginatedResponse<UserResponse>> {
  const { page, limit } = params;
  const skip = (page - 1) * limit;

  const [users, total] = await Promise.all([
    prisma.user.findMany({
      skip,
      take: limit,
      orderBy: { createdAt: "desc" },
      include: { posts: true },
    }),
    prisma.user.count(),
  ]);

  return {
    data: users.map(toUserResponse),
    total,
    page,
    totalPages: Math.ceil(total / limit),
  };
}

実際に試したところ、Promise.all で findMany と count を並列実行することで、クエリ時間が約 40% 短縮されました。

つまずきポイント

• skip と take は大量データで遅くなるため、カーソルベースのページネーション（cursor）を検討する
• count() はテーブル全体をスキャンするため、大規模データでは重い

実務で採用した型安全パターンとアンチパターン

Repository パターンによる Prisma の抽象化

この章でわかること: Prisma を直接使わず、Repository 層で抽象化するメリットとデメリットを理解できます。

実務では、Prisma をそのまま使わず、Repository パターンで抽象化することを検討しました。結論として、小規模プロジェクトでは不要、中〜大規模では有効と判断しました。

typescriptCopy code// Repository層の実装例
export class UserRepository {
  async findById(id: number) {
    return prisma.user.findUnique({ where: { id } });
  }

  async findByEmail(email: string) {
    return prisma.user.findUnique({ where: { email } });
  }

  async create(data: UserCreateInput) {
    return prisma.user.create({ data });
  }

  async update(id: number, data: Partial<User>) {
    return prisma.user.update({ where: { id }, data });
  }
}

採用しなかった理由は、以下の通りです。

• 型推論の恩恵が薄れる: include の有無で戻り値の型が変わるため、Repository 層で型を固定すると柔軟性が失われる
• 抽象化のコスト: Prisma 自体が既に抽象化されているため、さらに抽象化する必要性が低い

ただし、複数の DB を切り替える可能性がある場合や、テストで Prisma をモックしたい場合は、Repository パターンが有効です。

つまずきポイント

• Repository パターンを採用すると、include の型推論が失われるため、ジェネリクスで型を渡す必要がある

Transaction 処理における型安全性の確保

この章でわかること: 複数の DB 操作を一括で行う際の型安全な実装方法を理解できます。

トランザクション処理では、すべての操作が成功するか、すべて失敗するかを保証する必要があります。

typescriptCopy codeexport async function transferPost(
  postId: number,
  fromUserId: number,
  toUserId: number,
) {
  return prisma.$transaction(async (tx) => {
    // 1. 投稿の所有者を変更
    const post = await tx.post.update({
      where: { id: postId },
      data: { authorId: toUserId },
    });

    // 2. 元の所有者の投稿数を減算
    await tx.user.update({
      where: { id: fromUserId },
      data: { postCount: { decrement: 1 } },
    });

    // 3. 新しい所有者の投稿数を加算
    await tx.user.update({
      where: { id: toUserId },
      data: { postCount: { increment: 1 } },
    });

    return post;
  });
}

実際に検証したところ、途中でエラーが発生した場合、すべての変更がロールバックされることを確認しました。

つまずきポイント

• $transaction 内では、prisma ではなく tx を使う必要がある
• トランザクション内で await を忘れると、意図しない順序で実行される

運用で壊れない設計と継続的な型安全性の維持

CI/CD における prisma generate の自動化

この章でわかること: デプロイ時に型定義のズレを防ぐための CI/CD 設定を理解できます。

実際に運用で問題になったのは、ローカルで prisma generate を実行し忘れたまま PR を出してしまうケースです。これを防ぐため、CI で以下のチェックを追加しました。

yamlCopy code# .github/workflows/ci.yml
name: CI

on: [push, pull_request]

jobs:
  typecheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: "24"

      - name: Install dependencies
        run: npm install

      - name: Generate Prisma Client
        run: npx prisma generate

      - name: Run type check
        run: npx tsc --noEmit

この設定により、prisma generate を忘れたコードは CI で型エラーとして検出されます。

つまずきポイント

• Docker でビルドする際、prisma generate を Dockerfile の RUN 命令に含める必要がある
• Vercel などの PaaS では、ビルドコマンドに prisma generate を含めないと、デプロイ時にエラーになる

Schema 変更時の影響範囲の把握と安全な移行

この章でわかること: スキーマ変更が既存コードに与える影響を事前に把握する方法を理解できます。

スキーマを変更した際、以下の手順で影響範囲を確認しました。

1. prisma generate を実行: 型定義が更新される
2. npx tsc --noEmit を実行: 型エラーを確認
3. 影響箇所を修正: 型エラーが出た箇所をすべて修正

実際に User モデルに phoneNumber を追加した際、以下の箇所で型エラーが検出されました。

• DTO 変換関数（toUserResponse）
• API レスポンスの型定義
• テストコード

これにより、変更漏れを防ぐことができました。

つまずきポイント

• 既存データがある状態で NOT NULL カラムを追加すると、マイグレーションが失敗する（デフォルト値の設定が必要）
• リレーションを変更する際、既存データの整合性を保つマイグレーションを手動で書く必要がある

まとめ: Prisma と TypeScript で実現する型安全な DB アクセス設計

本記事では、Prisma と TypeScript を組み合わせた型安全な DB アクセス設計について、実務経験に基づいて解説しました。

Prisma を採用する判断基準として、以下のポイントが重要です。

• プロジェクト規模: 小〜中規模で特に効果が高い
• チームのスキル: SQL に詳しくないメンバーがいる場合に有効
• 型安全性の要求度: Runtime エラーを徹底的に防ぎたい場合に最適

一方で、以下のケースでは慎重な検討が必要です。

• 複雑な SQL を多用する場合（Raw Query が増える）
• 既存の大規模 DB を扱う場合（マイグレーション管理が複雑）
• パフォーマンスがクリティカルな場合（クエリの最適化が限定的）

Prisma の型推論、Zod による入力検証、DTO による境界設計を組み合わせることで、入力から出力までの完全な型安全性を実現できます。ただし、型安全性とパフォーマンスのトレードオフを理解し、適切な設計判断を行うことが重要です。

実際に運用して感じたのは、「型安全性は開発体験だけでなく、障害対応コストの削減にも直結する」ということです。初期の学習コストはありますが、長期的には確実に価値を生み出します。

関連リンク

• Prisma Documentation
• Prisma Schema Reference
• Prisma Client API
• TypeScript Handbook
• Zod Documentation
• Prisma 7.0 Release Announcement
• Node.js Releases