本番DBに直接SQLを実行してはいけない理由と安全なデータ修正フロー

「ちょっとだけデータを直す」つもりが取り返しのつかない事態に。本番DBへの直接SQL実行が危険な理由と、Laravelプロジェクトでの安全なデータ修正フローを実案件ベースで解説します。

こんな経験、ありませんか？

「急いでデータを修正しなければならない」——そんな状況で、phpMyAdminやTablePlusを開き、本番データベースに直接UPDATEやDELETEを実行したことはないでしょうか。

あるいは「ちょっとしたデータ修正だから大丈夫」と、何の準備もなくSQLを叩いてしまったことは？

ベテランエンジニアでも、プレッシャーのかかる場面では判断が鈍るものです。実は弊社でも過去に、外部から引き継いだ案件でこの問題に遭遇しました。前任者が「確認のためだけ」のつもりで叩いたはずのUPDATEが、WHERE句なしで数千件のレコードを書き換えていたのです。復旧には丸一日かかりました。

この記事では、本番DBへの直接SQL実行が引き起こすリスクと、実際の現場で使える安全なデータ修正フローを、コード例を交えながら解説します。

なぜ本番DBへの直接SQL実行が危険なのか

「SQL自体は正しいのだから問題ない」と思うかもしれませんが、リスクは「SQLの正しさ」だけにあるわけではありません。

1. ロールバックできない変更が一瞬で走る

MySQLのデフォルトはオートコミットモードです。UPDATEやDELETEを実行した瞬間、トランザクションを明示しない限り変更は即座に確定します。「Enter」キーを押した0.1秒後には、取り消す手段がありません。

2. WHERE句の抜け漏れは人間的なミス

以下のSQLを見てください。

-- 意図: 特定ユーザーのメールアドレスを更新
UPDATE users SET email = '[email protected]';
-- WHERE句を書き忘れると全件更新！

エディタでなくターミナルや管理ツール上でSQLを書いていると、こういったミスが起きやすくなります。緊張や焦りがある場面ではなおさらです。

3. 変更履歴が残らない

アプリケーションコードを経由した変更はGitのコミット履歴やアプリログに残りますが、管理ツールから直接実行したSQLは誰が・いつ・何を変更したかの記録が残りません。後から原因を調査しようとしても手がかりがなく、デバッグに膨大な時間を要します。

4. 外部キー制約や整合性チェックをスキップしてしまう

LaravelのEloquentを通じた更新であれば、モデルのイベント（saving, updatingなど）やObserverが走り、関連データの整合性を保つ処理が動きます。直接SQLではこれらが完全にスキップされます。

安全なデータ修正フロー：実践編

弊社がLaravelプロジェクトで採用している、安全なデータ修正フローを紹介します。ポイントは「作業をコードとして記述し、レビューを経て実行する」という原則です。

flowchart TD
    A[修正要件を確認] --> B[ローカル・ステージングで検証]
    B --> C[Artisan Commandまたはマイグレーションとして実装]
    C --> D[コードレビュー・PR作成]
    D --> E[本番バックアップ取得]
    E --> F[トランザクション付きで本番実行]
    F --> G[実行結果を確認・ログ記録]
    G --> H{問題あり?}
    H -->|Yes| I[ROLLBACKまたはバックアップから復旧]
    H -->|No| J[完了・チケットクローズ]

Step 1. Artisan Commandとして実装する

「一度きりのデータ修正」でもコマンドとして実装することで、ステージング環境での事前検証とレビューが可能になります。

<?php
// app/Console/Commands/FixUserEmailDomain.php

namespace App\Console\Commands;

use App\Models\User;
use Illuminate\Console\Command;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Log;

class FixUserEmailDomain extends Command
{
    protected $signature = 'fix:user-email-domain {--dry-run : 実際には変更せずに対象件数のみ表示}';
    protected $description = '旧ドメインのメールアドレスを新ドメインへ移行する';

    public function handle(): int
    {
        $targets = User::where('email', 'like', '%@old-domain.com')->get();

        $this->info("対象件数: {$targets->count()} 件");

        // --dry-run オプションで実行前に対象を確認できる
        if ($this->option('dry-run')) {
            $this->table(['ID', 'Email'], $targets->map(fn($u) => [$u->id, $u->email]));
            $this->warn('dry-run モードのため変更は行いません。');
            return self::SUCCESS;
        }

        if (!$this->confirm('上記のレコードを更新してよいですか？')) {
            $this->info('キャンセルしました。');
            return self::SUCCESS;
        }

        DB::transaction(function () use ($targets) {
            foreach ($targets as $user) {
                $oldEmail = $user->email;
                $user->email = str_replace('@old-domain.com', '@new-domain.com', $user->email);
                $user->save();

                Log::info('ユーザーメール変更', [
                    'user_id'   => $user->id,
                    'old_email' => $oldEmail,
                    'new_email' => $user->email,
                    'operator'  => get_current_user(),
                ]);
            }
        });

        $this->info('完了しました。');
        return self::SUCCESS;
    }
}

この実装のポイントは3つあります。

• --dry-runオプション: 実際に変更する前に対象件数とレコードを確認できる
• DB::transaction(): 途中でエラーが発生した場合、すべての変更を自動的にロールバック
• Log::info(): 誰が・いつ・何を変更したかの記録をアプリログに残す

Step 2. ステージング環境で必ず事前検証する

# まずdry-runで対象を確認
php artisan fix:user-email-domain --dry-run

# 問題なければステージングで本実行
php artisan fix:user-email-domain

ステージングで期待通りに動いたことを確認してから、本番に臨みます。

Step 3. 本番実行前にバックアップを取得する

# MySQL バックアップ
mysqldump -u root -p --single-transaction your_database > backup_$(date +%Y%m%d_%H%M%S).sql

# または Laravel の場合は spatie/laravel-backup を活用
php artisan backup:run --only-db

よくある失敗パターンと対処法

❌ 失敗1：「確認だけ」のつもりがSELECTではなくUPDATEを実行

SQLクライアントのタブを複数開いているときに起きがちなミスです。弊社が引き継いだあるECサイト案件では、開発者が「商品の在庫数を確認しようとしたら、別タブに書きかけのUPDATEがあり、誤って実行した」という事故が起きていました。

対処法: 本番DBへの接続は読み取り専用ユーザーを用意し、通常時はそちらを使う。書き込みが必要な場合のみ、権限のあるユーザーで接続する運用にする。

-- 読み取り専用ユーザーを作成する
CREATE USER 'readonly_user'@'%' IDENTIFIED BY 'strong_password';
GRANT SELECT ON your_database.* TO 'readonly_user'@'%';
FLUSH PRIVILEGES;

❌ 失敗2：トランザクションを使わずに複数テーブルを更新

「ordersテーブルを更新した後、order_itemsテーブルを更新しようとしたらエラーが出た」——このとき、ordersだけ更新されてorder_itemsは未更新という不整合状態に陥ります。

対処法: 複数テーブルにまたがる変更は必ずDB::transaction()でラップする。エラー時は全件ロールバックされるため、中途半端な状態になりません。

❌ 失敗3：本番でいきなりARTISANコマンドを実行

ステージングで動作確認をせず、いきなり本番で実行するのも危険です。データ量の違いによるタイムアウトや、環境差異による予期しない挙動が起こりえます。

対処法: 必ずステージング→本番の順で実行。大量レコードの場合はchunk()を使ってバッチ処理する。

// 大量データはchunkで分割処理
User::where('status', 'pending')->chunk(500, function ($users) {
    foreach ($users as $user) {
        $user->update(['status' => 'inactive']);
    }
});

まとめと次のステップ

「急いでいるから直接SQL」は、短期的には時間を節約できるように見えて、ひとたび事故が起きれば何倍もの時間とコストを失います。Artisan Commandとして実装し、dry-runで確認し、トランザクションでラップする——このフローを習慣にするだけで、データ修正にまつわるリスクは大幅に下がります。

まずは既存プロジェクトの本番DB接続ユーザーの権限を見直すことから始めてみてください。書き込み権限を持つユーザーでの日常的な閲覧作業をやめるだけでも、ミスのリスクを減らせます。

データ修正フローの整備やDB運用ルールの策定について、「自社の開発体制に合った形で整えたい」という場合は、ぜひ弊社にご相談ください。20年以上の実績をもとに、現場の実態に合ったアドバイスをいたします。