アプリケーション開発をしていると、途中で「データベースの構造を変更したい」という場面が必ず出てきます。
- カラムを追加したい
- テーブル構造を変更したい
- 不要な項目を削除したい
こういった変更を安全かつ管理しながら行う仕組みが「DBマイグレーション」です。
DBマイグレーションとは？
DBマイグレーションとは、
データベースの構造変更をコードで管理する仕組み
のことです。
イメージで理解する
最初に、こんなテーブルがあったとします。
users
- id
- name
開発が進むと、次のような要件が出てきます。
- メールアドレスを追加したい
- パスワードも必要
するとテーブルはこうなります。
users
- id
- name
- email
- password
この「後から構造を変更する作業」がマイグレーションです。
なぜ普通にSQLで変更しないのか？
「ALTER TABLE（テーブルを構造を変更するDDLコマンド）でよくない？」と思うかもしれませんが、実務では問題があります。
① 履歴が残らない
誰が・いつ・何を変更したのか分からなくなります。
② 環境ごとの差異が出る
例えば：
- 開発環境 → 変更済み
- 本番環境 → 変更忘れ
といった事故が発生します。
③ チーム開発で破綻する
複数人がバラバラに変更すると、DBの状態が不一致になります。
マイグレーションの考え方
マイグレーションでは、
「変更を順番に積み上げる」
という考え方をします。
-- 001_create_users.sql
CREATE TABLE users (
id INT PRIMARY KEY,
name VARCHAR(100)
);
-- 002_add_email.sql
ALTER TABLE users ADD COLUMN email VARCHAR(255);
-- 003_add_password.sql
ALTER TABLE users ADD COLUMN password VARCHAR(255);
このように変更をファイルとして管理し、順番に実行していきます。
メリット
✔ 履歴が残る
変更内容がすべて記録される
✔ 再現性がある
どの環境でも同じ状態を再現できる
✔ チーム開発に強い
誰が作業しても同じ結果になる
よく使われるツール
実務では専用ツールを使います。
- Flyway
- Liquibase
- Rails migration
- Django migration
- Prisma
これらは以下を自動でやってくれます：
- 実行済み管理
- 順番実行
- ロールバック（元に戻す）
実務で使われるタイミング
ここが一番重要なポイントです。
① 新機能追加
例：
- 年齢カラムを追加
- 在庫数を追加
カラム追加のマイグレーションを作成
② テーブル設計変更
例：
- カラム名変更
- データ型変更
既存データを壊さないよう慎重に実施
③ 不要なカラム削除
本番データがあるため慎重に行う
④ 複数環境への反映
実務では以下の環境があります：
- 開発環境
- 検証環境
- 本番環境
同じ変更を安全に適用するためにマイグレーションを使う
⑤ CI/CDでの自動実行
最近の開発では、
- GitHub Actions
- 自動デプロイ
と組み合わせて、アプリのデプロイ時にマイグレーションも実行されます。
実務での注意点（重要）
■ 本番DBにはデータがある
→ ミスするとデータ破損のリスク
■ ロールバックを考える
→ 失敗時に元に戻せる設計にする
■ 破壊的変更は段階的に行う
例：
- 新カラム追加
- データ移行
- 旧カラム削除
一気にやらないのがポイント
まとめ
DBマイグレーションとは、
- DBの構造変更をコードで管理する仕組み
- 履歴・再現性・安全性を担保するもの
そして実務では、
DB変更が発生するたびにほぼ必ず使われる重要な仕組み
です。