【2026年版】ORMとは？手書きSQLとの違いをコードで比較しながら初心者向けに解説

2026年4月22日 2026年4月22日

admin

バックエンド開発を学んでいると必ずぶつかる「ORM」という言葉。「SQLを書かなくていいって聞いたけど、本当に使えるの？」「手書きSQLとどう違うの？」という疑問、よくわかります。この記事では、ORMの概念をゼロから説明したうえで、手書きSQLと並べてコードを比較しながらその違いを体感できるよう解説します。

ORMとは何か？

ORM（Object-Relational Mapper）とは、リレーショナルデータベース（RDB）とオブジェクト指向プログラミングの橋渡しをしてくれるツールのことです。

データベースはテーブルと行・列でデータを管理しますが、プログラム側ではオブジェクトや配列でデータを扱います。この「世界観の違い」を自動で変換してくれるのがORMです。

たとえるなら、ORMは「日本語（プログラムコード）を英語（SQL）に自動翻訳してくれる通訳者」です。あなたは日本語だけ話せばOK、SQLは内部で勝手に生成されます。

手書きSQLとORMの違い、コードで比較

ここが一番大事なところです。同じ処理を「手書きSQL」と「ORM（例：Prisma）」で書き比べてみましょう。

① ユーザーを1件取得する

手書きSQL（Node.js + pg）

const result = await pool.query(
  `SELECT id, email, name
   FROM users
   WHERE email = $1
   LIMIT 1`,
  ['taro@example.com']
)
const user = result.rows[0]

ORM（Prisma）

const user =
  await prisma.user.findUnique({
    where: {
      email: 'taro@example.com'
    }
  })

② ユーザーと紐づく投稿記事を同時に取得する（JOIN）

手書きSQL

const result = await pool.query(
  `SELECT u.id, u.name,
          p.title, p.published
   FROM users u
   LEFT JOIN posts p
     ON p.author_id = u.id
   WHERE u.id = $1`,
  [userId]
)

ORM（Prisma）

const user =
  await prisma.user.findUnique({
    where: { id: userId },
    include: {
      posts: true
    }
  })

③ 新しいレコードを作成する

手書きSQL

await pool.query(
  `INSERT INTO users
     (email, name)
   VALUES ($1, $2)`,
  ['taro@example.com',
   '山田太郎']
)

ORM（Prisma）

await prisma.user.create({
  data: {
    email: 'taro@example.com',
    name:  '山田太郎',
  }
})

コードを並べると一目瞭然ですね。ORMを使うとSQLの文字列を直接書かなくて済み、読みやすさが大幅に向上します。特にJOINを伴う複雑なクエリほど、差が開きます。

ORM導入で変わること・変わらないこと

観点	手書きSQL	ORM
コード量	多い（SQL文字列が長くなりがち）	少ない・直感的
型安全性	なし（文字列なので実行時エラー）	TypeScriptと組み合わせで補完・型チェックが効く
DB移行のしやすさ	SQL方言の書き直しが必要	設定を変えるだけで対応DBを切り替えられる場合が多い
複雑なクエリ	柔軟に書ける	ORMのAPIで表現しにくい場合はRaw SQLも使える
学習コスト	SQLの知識が必要	ORMのAPI学習が必要（SQLの理解もあると◎）
パフォーマンス	最適化しやすい	自動生成クエリが非効率になるケースも。監視が必要

手書きSQLを使い続けて気づいたこと

実際に手書きSQLだけでアプリを作っていた立場から正直に言うと、最初はそこまで不便を感じませんでした。しかし開発が進むにつれ、次のような問題が出てきます。

テーブルのカラム名を変えると、SQL文字列を全ファイル検索して直す羽目になる

SQL中のtypoはコンパイル時に検出されず、テスト実行時に初めて気づく

JOIN が増えるほどSQL文が長くなり、コードレビューが辛くなる

別のDBに移行するとき（MySQLからPostgreSQLなど）、方言の違いで書き直しが発生する

こういった経験を積んでから改めてORMを導入すると、その恩恵がよく理解できます。ORMはただの「楽をするツール」ではなく、コードの保守性・安全性を高めるための設計上の選択です。

ORMを使うべきでない場面もある

ORMが万能というわけではありません。数百万件のデータを扱う集計クエリや、複雑なウィンドウ関数を使う場面では、ORMが生成するSQLが非効率になることがあります。そういった箇所はRaw SQLを直接書く選択肢も持っておきましょう。PrismaやTypeORMはどちらもRaw SQLの実行をサポートしています。