最終更新: 2026年2月 | Laravel 12対応
Laravelのマイグレーション実行状況を確認するphp artisan migrate:statusコマンドについて、基本的な使い方から実務での活用方法、トラブルシューティングまで徹底解説します。
💡 他のコマンドも知りたい方は artisanコマンド完全チートシート をご覧ください
1. migrate:statusコマンドとは
php artisan migrate:statusは、データベースマイグレーションの実行状況を一覧表示するコマンドです。
このコマンドでできること
- ✅ どのマイグレーションが実行済みか確認
- ✅ どのマイグレーションが未実行か確認
- ✅ マイグレーションファイルとDB状態の整合性チェック
- ✅ バッチ番号の確認（ロールバック時に重要）
いつ使うのか
開発中:
- マイグレーション実行後の確認
- 複数人開発でDB状態の同期確認
- 「あれ？このテーブル作成済みだっけ？」という時
本番環境:
- デプロイ後のマイグレーション確認
- トラブル発生時の状態確認
- 定期的な健全性チェック
2. 基本的な使い方
最も基本的な使い方
php artisan migrate:status実行結果の例:
+------+--------------------------------------------------+-------+
| Ran? | Migration | Batch |
+------+--------------------------------------------------+-------+
| Yes | 2014_10_12_000000_create_users_table | 1 |
| Yes | 2014_10_12_100000_create_password_resets_table | 1 |
| Yes | 2019_08_19_000000_create_failed_jobs_table | 1 |
| Yes | 2023_01_15_create_posts_table | 2 |
| No | 2023_02_20_add_status_to_posts_table | |
+------+--------------------------------------------------+-------+オプション一覧
| オプション | 説明 | 使用例 |
|---|---|---|
--database= | 使用するデータベース接続を指定 | php artisan migrate:status --database=mysql |
--path= | 特定のパスのマイグレーションのみ表示 | php artisan migrate:status --path=database/migrations/2023 |
--realpath | 相対パスではなく絶対パスを使用 | php artisan migrate:status --realpath |
--pending | 未実行のマイグレーションのみ表示（Laravel 10+） | php artisan migrate:status --pending |
データベース接続を指定
複数のデータベース接続がある場合:
# MySQLの状態確認
php artisan migrate:status --database=mysql
# PostgreSQLの状態確認
php artisan migrate:status --database=pgsql
# テスト用DBの状態確認
php artisan migrate:status --database=testingconfig/database.php での設定例:
'connections' => [
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_HOST', '127.0.0.1'),
// ...
],
'pgsql' => [
'driver' => 'pgsql',
'host' => env('DB_HOST_PGSQL', '127.0.0.1'),
// ...
],
],特定のパスのみ確認
# 2023年のマイグレーションのみ確認
php artisan migrate:status --path=database/migrations/2023
# モジュール別に管理している場合
php artisan migrate:status --path=modules/Blog/Database/Migrations未実行のみ表示（Laravel 10+）
php artisan migrate:status --pending出力例:
+------+--------------------------------------------------+-------+
| Ran? | Migration | Batch |
+------+--------------------------------------------------+-------+
| No | 2023_02_20_add_status_to_posts_table | |
| No | 2023_03_15_create_comments_table | |
+------+--------------------------------------------------+-------+用途:
- CI/CDで未実行マイグレーションの検出
- デプロイ前の確認
- チーム開発での同期確認
3. 出力結果の見方
各カラムの意味
+------+--------------------------------------------------+-------+
| Ran? | Migration | Batch |
+------+--------------------------------------------------+-------+
| Yes | 2023_01_15_create_posts_table | 2 |
| No | 2023_02_20_add_status_to_posts_table | |
+------+--------------------------------------------------+-------+Ran? カラム
Yes: 実行済み（migrationsテーブルに記録あり）No: 未実行（ファイルは存在するがDB未適用）
Migration カラム
- マイグレーションファイル名（タイムスタンプ付き）
database/migrations/配下のファイル名
Batch カラム
- マイグレーション実行時のバッチ番号
- 同時に実行されたマイグレーションは同じ番号
- ロールバック時にこの単位で戻る
Batch番号の重要性
# 例: 3回に分けてマイグレーション実行
# 1回目（初期テーブル作成）
php artisan migrate
# → Batch 1
# 2回目（新機能追加）
php artisan migrate
# → Batch 2
# 3回目（カラム追加）
php artisan migrate
# → Batch 3ロールバック時:
# 最後のBatch（Batch 3）のみロールバック
php artisan migrate:rollback
# 2回分ロールバック（Batch 3, 2）
php artisan migrate:rollback --step=2実際の出力例と解釈
+------+--------------------------------------------------+-------+
| Ran? | Migration | Batch |
+------+--------------------------------------------------+-------+
| Yes | 2014_10_12_000000_create_users_table | 1 |
| Yes | 2014_10_12_100000_create_password_resets_table | 1 |
| Yes | 2023_01_15_create_posts_table | 2 |
| Yes | 2023_01_20_create_comments_table | 2 |
| Yes | 2023_02_10_add_published_at_to_posts_table | 3 |
| No | 2023_02_20_add_status_to_posts_table | |
+------+--------------------------------------------------+-------+この状況の解釈:
- Batch 1（初期セットアップ）
- ユーザーテーブル
- パスワードリセットテーブル
- 最初の
php artisan migrateで実行
- Batch 2（ブログ機能追加）
- 投稿テーブル
- コメントテーブル
- 2回目の
php artisan migrateで同時実行
- Batch 3（カラム追加）
- 公開日時カラム追加
- 3回目の
php artisan migrateで実行
- 未実行
- ステータスカラム追加が未実行
php artisan migrateを実行するとBatch 4になる
4. 実務での使用シーン
シーン1: デプロイ前の確認
# ローカル環境で新しいマイグレーション作成
php artisan make:migration add_slug_to_posts_table
# マイグレーション実行
php artisan migrate
# 状態確認
php artisan migrate:statusデプロイ前チェックリスト:
# 1. 未実行のマイグレーションを確認
php artisan migrate:status --pending
# 2. Git管理下にあるか確認
git status database/migrations/
# 3. 本番環境で実行予定のマイグレーションをレビュー
cat database/migrations/2023_02_20_add_slug_to_posts_table.phpシーン2: 本番デプロイ後の確認
# SSH接続して本番環境へ
ssh user@production-server
# アプリケーションディレクトリへ移動
cd /var/www/html
# デプロイ前の状態確認
php artisan migrate:status
# マイグレーション実行
php artisan migrate --force
# 実行後の確認
php artisan migrate:status経験上、本番デプロイでは必ず前後でmigrate:statusを実行すべきです。
シーン3: チーム開発での同期確認
# 他の開発者がマイグレーションを追加した後
# 最新のコードをpull
git pull origin main
# Composer依存関係を更新
composer install
# マイグレーション状態確認
php artisan migrate:status
# 未実行があれば実行
php artisan migrateよくあるトラブル:
他の開発者: 「新しいテーブル追加したよ！」
あなた: 「え、ローカルでエラー出るんだけど...」
→ migrate:statusで確認 → 未実行マイグレーションを発見シーン4: トラブルシューティング
ケース1: テーブルが存在しない
# エラー発生
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'app.posts' doesn't exist
# 状態確認
php artisan migrate:status出力例:
+------+--------------------------------------------------+-------+
| Ran? | Migration | Batch |
+------+--------------------------------------------------+-------+
| Yes | 2023_01_15_create_posts_table | 2 | ← 実行済みのはず
+------+--------------------------------------------------+-------+原因候補:
- 手動でテーブル削除してしまった
- 別のDB接続を見ている
- migrationsテーブルの記録のみ残っている
対処法:
# DB接続確認
php artisan tinker
>>> DB::connection()->getDatabaseName()
# 実際のテーブル存在確認
php artisan tinker
>>> Schema::hasTable('posts')
# マイグレーションを再実行（手動削除した場合）
# 一旦migrationsテーブルから該当レコード削除
php artisan migrateケース2: マイグレーションファイルが無い
php artisan migrate:status出力に警告が出る:
Migration not found: 2023_01_15_create_posts_table原因:
migrationsテーブルに記録はあるが、ファイルが削除されている
対処法:
# 1. Gitから復元
git checkout database/migrations/2023_01_15_create_posts_table.php
# 2. または、migrationsテーブルから該当レコード削除（慎重に！）
php artisan tinker
>>> DB::table('migrations')->where('migration', '2023_01_15_create_posts_table')->delete()シーン5: CI/CDでの自動チェック
# .github/workflows/ci.yml
name: CI
on: [push, pull_request]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: '8.2'
- name: Install Dependencies
run: composer install
- name: Setup Database
run: |
cp .env.example .env
php artisan key:generate
touch database/database.sqlite
- name: Check Migration Status
run: php artisan migrate:status
- name: Run Migrations
run: php artisan migrate --force
- name: Verify All Migrations Ran
run: |
PENDING=$(php artisan migrate:status --pending | grep "No" | wc -l)
if [ $PENDING -gt 0 ]; then
echo "未実行のマイグレーションがあります"
exit 1
fi
- name: Run Tests
run: php artisan testシーン6: 複数環境の状態比較
# スクリプト化して定期的に実行
# check-migrations.sh
#!/bin/bash
echo "=== ローカル環境 ==="
php artisan migrate:status
echo ""
echo "=== ステージング環境 ==="
ssh staging "cd /var/www/html && php artisan migrate:status"
echo ""
echo "=== 本番環境 ==="
ssh production "cd /var/www/html && php artisan migrate:status"注意点:
環境間でマイグレーション状態がズレていると、「ローカルでは動くのに本番で動かない」という最悪の事態に陥ります。
5. よくあるエラーと対処法
エラー1: “SQLSTATE[42S02]: Base table or view not found: ‘migrations'”
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'app.migrations' doesn't exist原因:
migrationsテーブルが存在しない（初回セットアップ未完了）
解決方法:
# マイグレーションテーブルを作成
php artisan migrate:install
# その後、状態確認
php artisan migrate:statusエラー2: “Database connection refused”
SQLSTATE[HY000] [2002] Connection refused原因:
- データベースサーバーが起動していない
.envの接続設定が間違っている
解決方法:
# 1. DBサーバー起動確認
# MySQL
sudo systemctl status mysql
# Docker
docker ps | grep mysql
# 2. 接続設定確認
cat .env | grep DB_
# 3. 接続テスト
php artisan tinker
>>> DB::connection()->getPdo()エラー3: “Access denied for user”
SQLSTATE[HY000] [1045] Access denied for user 'root'@'localhost'原因:
- データベース認証情報が間違っている
解決方法:
# .env確認
cat .env
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=laravel
DB_USERNAME=root
DB_PASSWORD=your_password # ← ここを確認
# 設定キャッシュクリア
php artisan config:clear
# 再度実行
php artisan migrate:statusエラー4: 出力が文字化けする
Windowsでの問題:
+------+--------------------------------------------------+-------+
| Ran? | Migration ������ | Batch |解決方法:
# コマンドプロンプトの文字コード変更
chcp 65001
# または、PowerShellを使用
# PowerShellはデフォルトでUTF-8対応6. 関連コマンドとの組み合わせ
マイグレーション系コマンドの全体像
# 1. 状態確認
php artisan migrate:status
# 2. 未実行があれば実行
php artisan migrate
# 3. 再度確認
php artisan migrate:status
# 4. 問題があればロールバック
php artisan migrate:rollback
# 5. 全削除して再構築（開発環境のみ）
php artisan migrate:fresh --seedよく使う組み合わせパターン
パターン1: 開発中のリセット
# 現在の状態確認
php artisan migrate:status
# 全削除して再構築
php artisan migrate:fresh --seed
# 確認
php artisan migrate:statusパターン2: 本番デプロイフロー
# デプロイ前（ローカル）
php artisan migrate:status --pending
# 未実行マイグレーションがあることを確認
# デプロイ実行（本番サーバー）
ssh production
# デプロイ前の状態保存
php artisan migrate:status > /tmp/migrate_status_before.txt
# マイグレーション実行
php artisan migrate --force
# デプロイ後の状態確認
php artisan migrate:status > /tmp/migrate_status_after.txt
# 差分確認
diff /tmp/migrate_status_before.txt /tmp/migrate_status_after.txtパターン3: ロールバック確認
# ロールバック前の状態
php artisan migrate:status
# 最後のBatchをロールバック
php artisan migrate:rollback
# ロールバック後の状態
php artisan migrate:status
# 問題なければ再度マイグレーション
php artisan migrate関連コマンド一覧
| コマンド | 説明 | 詳細記事 |
|---|---|---|
migrate | マイグレーション実行 | 詳細 |
migrate:install | migrationsテーブル作成 | 詳細 |
migrate:status | 実行状況確認（本記事） | – |
migrate:rollback | ロールバック | 詳細 |
migrate:reset | 全ロールバック | 詳細 |
migrate:refresh | リセット＋再実行 | 詳細 |
migrate:fresh | 全削除＋再実行 | 詳細 |
make:migration | マイグレーションファイル作成 | 詳細 |
7. Laravel 12での変更点
出力フォーマットの改善
Laravel 12では、migrate:statusの出力が若干見やすくなりました。
Laravel 11以前:
+------+--------------------------------------------------+-------+
| Ran? | Migration | Batch |
+------+--------------------------------------------------+-------+Laravel 12:
┌──────┬──────────────────────────────────────────────────┬───────┐
│ Ran? │ Migration │ Batch │
├──────┼──────────────────────────────────────────────────┼───────┤
│ Yes │ 2014_10_12_000000_create_users_table │ 1 │
└──────┴──────────────────────────────────────────────────┴───────┘※ 環境によっては従来の表示のままの場合もあります
パフォーマンス改善
- 大量のマイグレーションファイルがある場合の表示速度が向上
- データベースクエリの最適化
--pendingオプションの安定化
Laravel 10で追加された--pendingオプションがより安定して動作します。
# 未実行のみ表示
php artisan migrate:status --pending8. チートシート（コピペ用）
# 基本的な使い方
php artisan migrate:status
# 未実行のみ表示
php artisan migrate:status --pending
# 特定のDB接続
php artisan migrate:status --database=mysql
# 特定のパスのみ
php artisan migrate:status --path=database/migrations/2023
# よく使う組み合わせ
# 状態確認 → 未実行があれば実行
php artisan migrate:status && php artisan migrate
# 開発環境リセット
php artisan migrate:fresh --seed && php artisan migrate:status
# 本番デプロイ確認
php artisan migrate:status --pending && php artisan migrate --force && php artisan migrate:status9. 実務でのベストプラクティス
✅ DO（推奨）
- デプロイ前後で必ず確認
php artisan migrate:status- CI/CDに組み込む
- name: Check migrations
run: php artisan migrate:status- 定期的な環境間同期確認
# 週1回程度、全環境の状態確認- マイグレーション実行後は必ず確認
php artisan migrate
php artisan migrate:status # ← これを忘れない❌ DON’T（非推奨）
- 状態確認せずにマイグレーション実行
# 悪い例
php artisan migrate --force # 状態不明のまま実行
# 良い例
php artisan migrate:status # まず状態確認
php artisan migrate --force # 確認後に実行- 本番環境で未実行マイグレーションを放置
# 本番環境で No が表示されたら必ず対処- エラーを無視する
# "Migration not found" などの警告を見逃さないまとめ
覚えておくべきポイント
✅ migrate:statusの重要性:
- マイグレーション管理の基本
- トラブル予防の第一歩
- チーム開発での同期確認に必須
✅ Batch番号の理解:
- ロールバック時の単位
- 同時実行されたマイグレーションのグループ
- トラブルシューティングの手がかり
✅ 実務での活用:
- デプロイ前後の確認
- CI/CDへの組み込み
- 環境間の状態比較
開発上のアドバイス
実際にあったトラブル例:
- ケース1: 本番環境で未実行マイグレーション
- 状況: デプロイ後にエラー多発
- 原因:
migrateを実行し忘れ - 対策:
migrate:statusで事前確認
- ケース2: 環境間のズレ
- 状況: ローカルでは動くが本番で動かない
- 原因: 本番のマイグレーションが古い
- 対策: 定期的な
migrate:status比較
- ケース3: チーム内の混乱
- 状況: 「このテーブルどこ？」
- 原因: マイグレーション未実行
- 対策: Pull後は必ず
migrate:status確認
これらのトラブルは、migrate:statusを習慣化するだけで99%防げます。
