LLaravel Bootcamp

Day 2・ディレクトリ構造、artisan、マイグレーションの思想

マイグレーションの思想 — DBスキーマをコードで版管理する

なぜDBの構造をコードで管理するのか、チームでの共有やロールバックの意義を理解する。

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

(マイグレーション)とは、データベースのテーブル構造(スキーマ)を、SQLの手作業ではなくPHPのコードとして定義し、その変更履歴を1つずつファイルとして残していく仕組みです。「usersテーブルを作る」「postsにcolumnを1つ足す」といった変更が、それぞれ日付付きのファイルとして積み上がっていきます。

PHP
<?php
// database/migrations/2026_08_07_000000_create_posts_table.php
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::create("posts", function (Blueprint $table) {
            $table->id();
            $table->string("title");
            $table->text("body");
            $table->timestamps();
        });
    }

    // down: 変更を取り消す(テーブルを消す)
    public function down(): void
    {
        Schema::dropIfExists("posts");
    }
};
up が「適用」、down が「取り消し」。この対で、進むことも戻すこともできる。

なぜDBの構造をコードで版管理するのか

手作業でSQLを流してテーブルを作ると、その変更履歴はどこにも残りません。「いつ、誰が、何のためにこのcolumnを足したのか」が分からなくなり、開発者ごとにDB構造がズレていきます。マイグレーションはDB構造の変更を、アプリのコードと同じようにGitで版管理できるようにします。これにより、変更の履歴・理由・順序がすべて追跡でき、DBの状態をコードから完全に再現できるようになります。

悪い例: 手作業でSQLを流す

各開発者が自分のDBに直接 ALTER TABLE を実行する。誰がどう変えたか履歴が残らず、環境ごとにDB構造がズレる。新メンバーはDBを正しく再現できない。

良い例: マイグレーションで管理

スキーマ変更をマイグレーションファイルにし、Gitで共有する。全員が php artisan migrate を実行するだけで同じDB構造を再現でき、変更履歴も残る。

チームでの共有: 全員が同じ手順でDBを揃える

マイグレーションファイルはコードなのでGitで共有されます。新しくチームに入った人は、リポジトリを取得して「php artisan migrate」を一度実行するだけで、全員とまったく同じDB構造を手元に再現できます。口頭やドキュメントで「このテーブルを作って」と伝える必要がなくなります。

ターミナル
# 未適用のマイグレーションをすべて実行し、DBを最新の構造にする
php artisan migrate

# 初期データ(seeder)も一緒に投入する
php artisan migrate --seed
新メンバーはこれ一発で、チームと同じDB構造・初期データを再現できる。

補足: 初期データは Seeder で

テーブルの「構造」はマイグレーション、その中に入れる「初期データ」は という別の仕組みで用意します。構造とデータを分けることで、テーブル定義とデータ投入をそれぞれ独立して管理できます。

ロールバック: 変更を安全に巻き戻す

各マイグレーションには、適用のupと取り消しのdownがペアで書かれています。このおかげで、間違ったスキーマ変更を「php artisan migrate:rollback」で1つ前の状態に戻せます。DBの変更を、コードのcommitのように進めたり戻したりできるのがマイグレーションの強みです。

ターミナル
# 直近のマイグレーションを取り消す(downが実行される)
php artisan migrate:rollback

# 現在のマイグレーションの適用状況を確認する
php artisan migrate:status
rollbackでdownが実行され、直前の変更を安全に巻き戻せる。

注意: 本番のロールバックはデータ消失に注意

rollbackはスキーマを戻すため、column削除を伴う場合はそのcolumnのデータが失われます。本番環境では、ロールバックよりも「打ち消す新しいマイグレーションを追加する」方が安全な場合が多い、という運用上の判断も知っておくと差がつきます。

面接ではこう言う

「マイグレーションは、DBスキーマの変更をコードとして版管理する仕組みです。手作業のSQLでは履歴が残らず環境がズレますが、マイグレーションならGitで共有でき、全員が migrate 一発で同じDB構造を再現できます。upとdownで適用と取り消しができ、変更を安全に巻き戻せる点も利点です。ただし本番のロールバックはデータ消失リスクがあるので、打ち消しマイグレーションを足す運用も検討します」と、再現性とロールバックの両面、さらに本番運用の注意まで話せると高評価です。

読んでも腑に落ちない所は、AIに噛み砕いてもらいましょう。

理解度チェック

答えられれば、面接で説明できる状態に一歩近づきます。

Q1

DBのテーブル構造をマイグレーションで管理する最大の利点はどれか。

Q2

マイグレーションファイルの up と down メソッドの役割の説明として正しいものはどれか。

Q3

「DBの構造を手作業のSQLで管理するのではなく、マイグレーションで管理するのはなぜか」を、チーム開発の観点から説明してください。

記述式です。まず自分の言葉で答えを考えてから、模範解答を開いて自己採点してください。