先日、WordPressを使ったWeb制作をメインにしている知人から、少しヒヤッとする相談を受けました。
その方は、クライアントサイトのデザインリニューアル作業のため、バックアップデータを使ってローカル環境で検証を進めていたそうです。
ところが作業中、ローカル環境で発生したエラー通知メールが、誤ってクライアント側に送信されてしまいました。
幸い、今回のクライアント様は個人事業の方だったため大きな問題にはなりませんでしたが、場合によっては信用問題にも発展しかねない事故です。
私は普段から、WordPress案件に関わる知人やクライアントから技術相談を受けることが多く、こうしたトラブル対応に関わることも少なくありません。
今回は、この事故をきっかけに、WordPressローカル復元時に起こりうるメール誤送信リスクと、その最も安全な防止策について整理しておこうと思います。
クライアントサイトをローカル環境へ復元して作業するとき、意外と見落とされがちなのが 「メール誤送信事故」 です。
All-in-One WP Migration、WPvivid、UpdraftPlus などを使ってサイトを復元すると、WordPress本体だけでなく、SMTP設定もそのまま引き継がれることがあります。
その結果、ローカル環境で発生したエラー通知やフォーム送信通知が、クライアントに実際に送信されてしまうことがあります。これは開発現場で本当に起こりうる事故です。
なぜメール誤送信が起きるのか？
多くのバックアップ・移行プラグインは、データベースを含めてサイト全体を復元します。
そのため、次のような情報も復元対象に含まれます。
- WP Mail SMTP のSMTP設定
- 送信元メールアドレス
- 管理者メールアドレス
- フォーム通知メール設定
- WooCommerce通知メール設定
つまり、ローカル環境でも WordPress は、「本番と同じSMTP資格情報でメール送信できる状態」になってしまうのです。
どの復元プラグインでも起こる問題なのか？
結論から言えば、All-in-One WP Migration、WPvivid、UpdraftPlus のいずれでも同じ問題は起こります。
なぜなら原因はプラグイン固有ではなく、「データベース復元時にSMTP設定まで復元される構造そのもの」にあるからです。
参考まで、それぞれの復元プラグインには得意分野が異なります。今回のテーマに関係する違いを整理すると、次のようになります。
| 項目 | UpdraftPlus（無料） | All-in-One WP Migration | WPvivid |
|---|---|---|---|
| 主目的 | 定期バックアップ特化 | サイト移行特化 | 移行＋バックアップ両立 |
| ドメイン変更 | △ 手動対応必要（自動化は有料） | ✅ 無料対応 | ✅ 無料対応 |
| ファイル形式 | 分割バックアップ形式 | 単一アーカイブ | 単一または構造型 |
| UX | やや手順多め | 非常に簡単 | 比較的簡単 |
| 部分復元 | ✅ 得意 | ❌ 苦手 | ✅ 対応可能 |
| 定期バックアップ | ✅ 強い | △ 弱め | ○ 強い |
このように、UpdraftPlus は決して移行できないわけではありませんが、本来はバックアップ用途に強みがあります。一方、All-in-One WP Migration や WPvivid は、サイト移行をより簡単に行える設計になっています。
よくある危険なケース
- Fatal error 通知がクライアントへ届く
- テスト注文メールが顧客へ届く
- お問い合わせフォーム通知が誤送信される
- 会員登録通知が誤送信される
特に WP Mail SMTP を使っている場合、wp_mail() を完全に乗っ取ってSMTP送信するため、通常のWordPressメールはほぼすべて送信対象になります。
よくある対策方法の弱点
| 対策方法 | 問題点 |
|---|---|
| SMTPプラグインを無効化 | 復元後に忘れやすい |
| SMTP設定削除 | 手動ミスが起きやすい |
| functions.phpで停止 | テーマ上書きで消える |
| wp-content内MU Plugin | 復元時に消える可能性あり |
これらは一見有効ですが、復元ツールによって上書きされるリスクがあります。
最も安全な方法：wp-content外にMU Pluginを置く
私が現時点で最もおすすめするのは、wp-content外に MU Plugin を置いてメール送信を強制停止する方法です。
この方法のメリットは非常に大きいです。
- 復元ツールに上書きされない
- 自動有効化される
- 無効化忘れが起きない
- AIOWM / WPvivid / UpdraftPlus 全対応
ちなみに MU Plugin（Must-Use Plugin）については、通常のプラグインとは異なる特殊な仕組みです。
私のUdemy講座「WordPressプラグイン開発講座」でも基礎を解説しており、以下のように独立したレクチャーとして紹介しています。
設定方法
1. wp-config.php に追記
|
1 |
define( 'WPMU_PLUGIN_DIR', dirname( ABSPATH ) . '/dev-mu-plugins' ); |
この定義は、必ず wp-settings.php（require_once ABSPATH . ‘wp-settings.php’;）より前に記述してください。 WordPressは起動時にMU Pluginの読み込み先を決定するため、後ろに書くと正しく認識されません。
ローカル環境でメール送信テストを行いたい場合は、この定義を削除するか、コメントアウトしてください。
なお、この方法では MU Plugin の読み込み先を変更するため、すでに wp-content/mu-plugins を利用しているサイトでは注意が必要です。既存のMU Pluginがある場合は、影響を確認してから適用してください。
2. dev-mu-plugins/disable-emails.php を作成
|
1 2 3 4 5 6 7 8 |
<?php /** * Plugin Name: ローカル／開発環境用メール送信停止 */ add_filter( 'pre_wp_mail', function( $return, $atts ) { return true; }, 10, 2 ); |
設定が正しく完了すると、WordPress管理画面の「必須プラグイン」一覧に、次のように表示されます。
この方法が強い理由
WordPress の pre_wp_mail フィルタは、wp_mail() の最初で処理を止められる公式フックです。
つまり、WordPress経由のメール送信を根本から止められるのです。
しかも「送信成功扱い」にできるため、エラー表示もほぼ発生しません。
注意点：完全万能ではない
この方法でも、次のケースは止められません。
- 独自SMTPライブラリ直叩き
- SendGrid SDK直送信
- 外部APIメール送信
- Webhook通知
ただし、通常のWordPress案件では、ほぼ十分な防御力があります。
結論
WordPressローカル復元時のメール誤送信対策として、現時点で最も安全なのは、「wp-content外にMU Pluginを配置する方式」です。
バックアッププラグインに依存せず、復元後も自動的に守ってくれるこの方法は、開発現場ではかなり強力です。
クライアントへの誤送信事故を防ぐためにも、ローカル環境にはぜひ導入しておくことをおすすめします。
