マイグレーション
Migration
概要（サマリー）
マイグレーション（Migration）とは、IT分野において様々な「移行（引っ越し）」を指す言葉だが、Web開発においては主にデータベースの構造（テーブルの設計図）を作成・変更するための仕組みや操作を指す。
「建物のリフォーム（増改築）の指示書」にたとえられる。手動で直接壁を壊すのではなく、「ここに新しく子供部屋（カラム）を追加する」「壁を取り払う」といった具体的な変更手順をプログラムコード（設計書）として残しておき、それを実行することで、誰のパソコンでも、また本番環境でも、全く同じ安全な手順でデータベースの工事（テーブル構造の書き換え）を行えるようにする。
詳細解説
マイグレーションとは何か
Webアプリケーションを作る際、データベースにデータを保存するためには「ユーザー情報テーブル」「商品テーブル」などの「箱（テーブルの構造）」を定義する必要がある。この構造のことをスキーマと呼ぶ。
開発を進める中で、「やっぱりユーザー情報に『自己紹介欄（bioカラム）』を追加したい」といったスキーマの変更が必ず発生する。その際、各開発者が手動でデータベース管理ツール（phpMyAdminなど）を開いて変更を加えていると、変更の適用漏れが起きたり、チーム内でデータベースの構造がバラバラになったりしてシステムが動かなくなる。
この問題を解消するために、データベースの構造変更の履歴を「コードのファイル（マイグレーションファイル）」として残し、プログラムで一括適用するのがデータベースマイグレーションである。
なぜマイグレーションが必要なのか
- Gitなどによるバージョン管理ができる:
マイグレーションファイルはただのテキストコードなので、Gitで履歴管理ができる。「誰が、いつ、データベースをどう変更したか」がすべて記録される。 - 複数人での開発がスムーズになる:
他のメンバーがデータベースを変更した場合も、最新のコードを取り込んで「マイグレーション実行コマンド」を叩くだけで、自分のパソコン内のデータベースが瞬時に相手と同じ最新構造にアップデートされる。 - 本番環境への安全なデプロイ:
テスト環境から本番環境（サーバー）へプログラムを移す（デプロイする）際、ボタン一つで安全に本番データベースを最新の設計書通りに作り直したり更新したりできる。
マイグレーションコードの例（Laravelの場合）
多くのWebフレームワーク（PHPのLaravelや、Ruby on Railsなど）には、この仕組みが標準で備わっている。
以下は、ユーザー情報テーブルに新しく「年齢（age）」カラムを追加するためのLaravelのマイグレーションファイルのコード例である。
<?php
// PHP/Laravelの例：データベースマイグレーションファイル
use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;
return new class extends Migration
{
/**
* マイグレーション実行時の処理 (Up)
* データベースに変更を加える（年齢カラムを追加）
*/
public function up(): void
{
Schema::table('users', function (Blueprint $table) {
// usersテーブルに、整数型の「age（年齢）」カラムを追加する
// null（空欄）の保存も許可する（nullable）
$table->integer('age')->nullable()->after('name');
});
}
/**
* ロールバック（元に戻す）時の処理 (Down)
* 加えた変更をキャンセルして元に戻す（年齢カラムを削除）
*/
public function down(): void
{
Schema::table('users', function (Blueprint $table) {
// usersテーブルから「age」カラムを削除する
$table->dropColumn('age');
});
}
};
このように、変更を加える「Up」と、万が一のために元に戻す「Down」のセットを書いておくことで、システムをいつでも安全な状態に巻き戻す（ロールバックする）ことができる。
マイグレーションの命名とファイル管理
マイグレーションファイルには、ファイル名の先頭に「タイムスタンプ（実行日時）」が自動的に付与される（例：2026_05_28_120000_add_age_to_users.php）。これにより、複数のファイルが増えても「どの変更が先か」という順序（バージョン履歴）が時刻で管理される。チームで同時に開発するとき、タイムスタンプの順番に従って全員が同じ順序でマイグレーションを実行できるため、「どちらのファイルを先に適用すればよいか」という混乱が起きない。
AIコーディングとの関係
データベース設計を変更する際、AIに適切なマイグレーションコードを書いてもらうことで、各フレームワーク独自のデータベース操作の文法（API）を調べる手間をなくし、記述ミスを防ぐことができる。
- マイグレーションファイルの生成指示:
AIに対して、「Laravelで、postsテーブルに文字列型のcategoryカラムを追加し、必要なくなったsub_titleカラムを削除するマイグレーションファイルのコードを書いて。upとdownの両方のメソッドを含めてください」と指示する。
これにより、フレームワークのルールに沿った正確な移行コードが即座に生成される。 - データの安全性に配慮した設計の相談:
本番環境のデータベースを変更する際、すでにデータが入っているテーブルからカラムを削除したり、データ型を変更したりすると、保存済みのデータが破損するリスクがある。
AIに「すでに1万件のデータが入っている本番DBのstatusカラムのデータ型を文字列から数値に変えたいです。データ損失のない安全なマイグレーションの手順を考えてください」と相談し、段階的な変更コードを提案させることで、本番トラブルを未然に防ぐことができる。
よくある勘違い
マイグレーションは「データの引っ越し（移行）」のことだけを指す？
そうではない。
元々の英語の「Migration（移住、移動）」から、古いシステムから新しいシステムへ「データを引っ越す作業」そのものをマイグレーションと呼ぶこともある（システムマイグレーション、データ移行）。
しかし、Webアプリ開発の日常会話で「マイグレーション」と言うときは、上記で解説した「データベースの設計図（テーブル構造）の変更・管理システム」を指すのが一般的である。混同しないように文脈で判断しよう。
マイグレーションコマンドを実行すると、既存のデータがすべて消えてしまう？
通常の追加や変更の実行（php artisan migrate など）では、既存のデータは保持されたまま、新しいカラムが追加されるだけであり、データは消えない。
しかし、データベースを完全に初期化して作り直すコマンド（migrate:fresh など）を実行すると、テーブルそのものが一度すべて削除（DROP）されて新規作成されるため、中に保存されていたすべてのテストデータは完全に消滅する。本番環境や共有環境で実行するコマンドを間違えると、大惨事になるため細心の注意が必要である。
マイグレーションとバックアップは同じもの？
異なる。
マイグレーションは「テーブル構造（スキーマ）をバージョン管理する仕組み」であり、データそのものを保存・復元する「バックアップ」とは目的が違う。マイグレーションのロールバックで「元の構造」に戻すことはできるが、そのときすでに保存されていたデータは必ずしも自動的に復元されない。データを守るためには、マイグレーションとは別に定期的なデータバックアップも行う必要がある。
まとめ
- マイグレーションは、データベースのテーブル構造（設計図）の作成・変更履歴をコードで管理する仕組み。
- Gitでの履歴管理が可能になり、チーム全員で同じデータベース構造を安全に保つことができる。
- 変更を適用する「Up」と、元に戻す「Down」のセットで構成される。
- 本番環境で実行する際は、データ消失を防ぐため実行するコマンドの種類に十分に注意する。
情報ソース
より詳しくAIに聞いてみよう
- Ruby on RailsやLaravelで、新しくマイグレーションファイルを生成するコマンドと、それを適用（実行）するコマンドの一覧を教えてください。
- マイグレーションで「ロールバック（rollback）」が機能する仕組みと、過去の特定のバージョンまでテーブル構造を巻き戻す手順を教えてください。
- すでに本番稼働しているデータベースから、既存のデータを失うことなくカラムの名前を変更（リネーム）するマイグレーション手順と注意点を解説してください。
- データベースのマイグレーションが途中で失敗した場合（コンフリクトやエラーなど）の、安全なリカバリー手順について教えてください。
- マイグレーションと同時に、開発用のダミーデータや初期データをデータベースに投入する「シーダー（Seeder）」の役割と使い方を教えてください。