はじめに

アプリを開発していると、「ユーザーテーブルに新しいカラムを追加したい」「テーブルの名前を変更したい」といった場面が必ず出てきます。

普段データサイエンティストやデータエンジニアとしてSQLを叩いている方であれば、「そんなの ALTER TABLE 文を1行実行すれば終わりでは？」と思うかもしれません。

しかし、本番運用されているアプリケーションのデータベースにおいて、手動で直接構造を書き換える行為は、一歩間違えると「データ全喪失」や「システム全停止」を引き起こしてしまいます。

こうしたデータベースの構造変更（スキーマ変更）を、履歴として記録しながら安全に管理・適用するための仕組みが「マイグレーション」です。

今回は、そもそもマイグレーションとは何か、そしてなぜそれが必要とされているのかを整理していきます。

1. そもそもスキーマとは何か

マイグレーションを理解するには、まず「スキーマ」という言葉を押さえておく必要があります。

スキーマとは、データベースの中に「どんなテーブルがあり、それぞれにどんなカラム（列）があり、どんなリレーション（親子関係）が結ばれているか」を定義した全体の設計図のことです。

例えば、ユーザーを管理するテーブルであれば、以下のようなルールを決めるのがスキーマ定義です。

user_id：数値型、重複不可（主キー）
email：文字列型、空白不可（NOT NULL制約）
created_at：日付型、デフォルトは現在時刻

アプリケーションの開発が進むということは、新機能の追加に合わせて、この設計図を何度も書き換え、アップデートしていくプロセスそのものだと言えます。

2. マイグレーションとは何か

マイグレーション（Migration＝移行）とは、このスキーマの変更プロセスを、プログラムのコード（履歴）として管理・実行する仕組みのことです。

「カラムを1つ追加する」「インデックスを貼る」といった1回分の変更内容を、「マイグレーションファイル」と呼ばれる1つのファイル（SQL文や、専用のプログラムコード）として独立させて記録します。

[0001_create_users_table.sql]  初期テーブル作成
       ↓
[0002_add_status_to_users.sql]  statusカラムを追加
       ↓
[0003_create_posts_table.sql]   postsテーブルを新規作成

イメージとしては、ソースコードにおける「Gitのコミット履歴」と全く同じです。

スキーマの変更内容を定義したマイグレーションファイルを作成する

データベースには、「どのマイグレーションファイルまで適用済みか」を記録する専用のテーブルが用意される

マイグレーションを実行すると、まだ適用されていないファイルだけが、古いものから順番に適用される

適用が終わると、そのファイルも「適用済み」として記録される

このファイルを順番に適用していくことで、データベースの構造を、今の設計に合った状態まで少しずつ進めていきます。

このように、設計図の進化の歴史がファイルとして1から順番に記録されているため、「いつ、誰が、どんな目的でDBの構造を変えたのか」が追跡可能になります。

3. なぜ手動でテーブルを変更してはいけないのか

マイグレーションツールを使わなくても、自分のパソコン（ローカル環境）のデータベース管理画面からポチポチとマウス操作でカラムを追加すれば、その場ではアプリは動きます。

しかし、これを手動でやり始めると、変更の記録が残らないことに加えて、次のような恐ろしい問題（開発の闇）に直面します。

本番環境への反映し忘れ：

ローカル環境のDBにはカラムを追加したけれど、本番環境のDBに同じ設定を適用するのを忘れていた。その結果、リリースした瞬間に本番環境だけで「そんなカラムはありません」とエラーを吐いてシステムが落ちる。
「私の環境では動く」問題：

複数人で開発している場合、他のメンバーのデータベースには自分の変更が反映されません。結果として、開発メンバーごとにデータベースの構造がバラバラになり、お互いのコードが動かなくなります。

結局こういった問題が起こった時に、「誰が、いつ、なぜ」その変更を行ったのかが追跡できなくなり、後から「なぜこのカラムがあるのか」が分からなくなってしまいます。

マイグレーションの仕組みを使うことで、「このマイグレーションファイルまで適用すれば、誰の環境でも同じ構造になる」という状態を保つことができます。

4. 分析用DWHとの違い

ここで、勘違いしやすいポイントに触れておきます。

分析基盤のモデリングでは、スキーマを変更したいとき、「テーブルを一度削除（DROP）して、最初からデータを全量再投入する（フルリフレッシュ / 洗い替え）」というアプローチがごく当たり前に取られます。

なぜDWHの世界では、こんな大胆な手法が許されるのでしょうか。

理由は主に3つあります。

データの「発生源」が他にあるから：

DWHにあるデータは、基幹系DBや各種ログ、SaaSから同期してきた「コピー」であり、大元のオリジナルデータは別に保管されています。

過去のロジックを遡及修正したいから：

計算ロジックを変えたから、3年前のデータまで遡って新しいロジックで集計し直したいという場合、全件洗い替えた方がデータの整合性を保ちやすく、コードもシンプルになります。

バッチ処理の世界だから：

分析は基本的に定期的なバッチ処理で行われるため、数分間テーブルをドロップしても、一般のユーザーに迷惑がかかることはありません。

しかし、これから作ろうとしているWebアプリケーションのデータベース（本番RDB）では、この「洗い替え」が絶対に許されません。

理由は、DWHとは前提条件が真逆だからです。

データの「オリジナル」がそこにある：

アプリのデータベースは、今まさにこの瞬間にユーザーが登録したアカウント情報や、決済データ、投稿内容そのものが蓄積されている「データの発生源」です。一度テーブルをドロップしたら、その瞬間にユーザーの資産は文字通り永遠に消え去ります。

24時間365日、動き続けている：

スキーマを変更している最中であっても、世界中からユーザーの書き込みや読み込みがリアルタイムに飛んできます。メンテナンスのために数分間書き込みを止めて、テーブルを再作成することは、サービスの信頼性に直結するため簡単にはできません。

つまり、以下のようなイメージです。

DWHのモデリング：お店を一時休業し、商品をすべて外に出して並び替える「棚卸し」
アプリのマイグレーション：お店を通常営業しながら、お客さんが買い物をしている真横で「棚をそっと入れ替える作業」

いつでもお店（バッチ処理）を止めて最初から並び替えられるDWHに対し、アプリのデータベースは常にユーザーが利用しているため、営業を止めるわけにはいきません。

だからこそ、過去のデータを一粒も傷つけず、サービスも止めずに、構造だけを少しずつ「進化」させていくための仕組み（マイグレーション）が不可欠になります。

5. 実務で気をつけたいこと

マイグレーションは便利な仕組みですが、実務で扱ううえで注意しておきたい点もあります。

実務の際に特に注意しなければならない怖いシナリオが2つあります。

🚨 実務で直面する「2つの罠」

「カラム削除」による既存データの消失

例えば、古い age（年齢） カラムを削除して、新しく birth_date（生年月日） カラムに移行するマイグレーションを実行したとします。

コマンドを実行した瞬間、過去数年分ためてきた age のデータはデータベースから物理的に消滅します。

もし移行プログラム（ロジック）にバグがあり、生年月日へのデータ変換がうまくできていなかった場合、過去の顧客データをすべて失うという大惨事につながります。

本番環境への適用前には、必ず内容を確認し、必要であればバックアップを取っておくことが大切です。

アプリのコードとの「時間差」によるシステム停止

本番環境のデータベースの構造を書き換えるタイミングと、新しいアプリのコードをサーバーにデプロイ（配置）するタイミングには、どうしても数秒〜数分の「時間差」が生じます。

DBの変更を先に適用してカラムを消してしまうと、まだサーバー上で動いている「古い状態のアプリ」がそのカラムを探しに行ってしまい、即座にクラッシュします。

この時間差を考慮した「壊れないスキーマ変更の手順」を設計する必要があり、ここが最も神経を使う部分です。

🛠️ 大惨事を防ぐための「2つの鉄則」

こうした罠を踏んでシステムを崩壊させないために、マイグレーション運用には絶対に破ってはいけない鉄則があります。

鉄則1：常に「ロールバック（巻き戻し）」を考慮する

マイグレーションを本番環境に適用した直後、想定外のバグが見つかることは珍しくありません。

その際、システムを大急ぎで元の正常な状態に戻すための手順が「ロールバック」です。

多くのツールでは、変更を適用する Up という処理に対して、変更を元に戻す Down という処理をセットで記述します。

「進める手順」だけでなく、「安全に1歩下がる手順」も合わせて用意しておくことが、本番運用の最低限の命綱になります。

💡 NeonやSnowflakeのタイムトラベル機能の活用
ここで、私が個人開発で採用しているNeonや、データ分析の世界でお馴染みのSnowflakeなど、モダンなデータベースを使っているなら絶対に知っておきたい機能があります。

それが「タイムトラベル機能」です。

タイムトラベル機能とは、従来の重たいバックアップ・リストア手順を踏むことなく、「10分前」「1日前」といった過去の任意の時点のデータを直接クエリしたり、その時点の状態へとデータベースを丸ごと巻き戻したりできる革新的な仕組みです。

もし万が一、本番環境で「ロールバックの手順（Down）を用意し忘れたのに、バグのあるマイグレーションを実行してデータを消してしまった！」という絶望的な状況に陥っても、タイムトラベル機能があれば「マイグレーション実行直前の1分前」に時計の針を戻してデータを無傷で救出できます。

ただし、これはあくまでインフラ側の「データ救済措置」であり、マイグレーションの代わりになるわけではありません。

「いつ、なぜ構造が変わったのか」をアプリのコードと同期して管理する役割は、やはりマイグレーションファイルにしかできないからです。

「マイグレーションという論理的な歴史管理」と、「タイムトラベルという物理的な時間巻き戻し」。

この2つが補完し合うことで、現代の開発者はかつてないほどの安全性を手に入れています。

鉄則2：過去のマイグレーションファイルは「絶対に」書き換えない

一度作成し、本番環境や他の開発メンバーに共有された過去のマイグレーションファイルの中身は、後から絶対に直接書き換えてはいけません。

書き換えにより、「すでにそのファイルを適用し終えている本番環境」と、「書き換えられた後のファイルを新しく読み込む環境」との間で、データベースの構造に致命的なズレが発生するからです。

「過去の歴史を改ざんしない」が大原則です。

もし構造をさらに変更したい場合は、必ず「新しく次のマイグレーションファイルを追加する」のが正しい作法です。

まとめ

データベースのマイグレーションの本質について整理しました。

スキーマ： データベースのテーブルや列のルールを定義した設計図
マイグレーション： 設計図の変更履歴を「Gitのコミット」のようにコード化して管理する仕組み
最大の価値： 手動による人為的ミスを排除し、あらゆる環境のDB構造を「コマンド1発」で完全に一致させる
運用のリアル： 稼働中のデータを壊さないよう、本番環境への適用（特に削除や型変更）には細心の注意が必要

これらをすべて生SQLのDDL（ALTER TABLEなど）で完璧に管理し、ロールバックの手順まで自前で用意するのは、非・開発者でなくとも非常に神経を使う作業です。

しかし幸いなことに、現代のWeb開発エコシステムには、このマイグレーションを極めて安全に、かつ直感的にサポートしてくれる優秀なツール（Next.js界隈であればPrismaやDrizzleなど）が豊富に揃っています。

データベースを直接触る恐怖に怯える必要はありません。

まずはマイグレーションという仕組みの「思想」と「鉄則」をしっかり頭に入れた上で、頼れるツールを賢く味方につけ、安全で快適な個人開発を進めていきましょう。