「自動更新」と「通知」は別物だと理解する
まず整理したいのは、
WordPress には「自動更新」と「自動更新されたことを知らせる通知」という、二つのレイヤーがあるということです。
自動更新
WordPress 本体・プラグイン・テーマを、ユーザー操作なしで自動的にアップデートする仕組み。
通知
「いま自動更新が行われました」「このプラグインが更新されました」といった情報を、メールなどで知らせる仕組み。
プログラミングで言えば、
自動更新＝自動デプロイ
通知＝デプロイ結果を Slack やメールに飛ばす通知
という関係です。
自動更新そのものをどうするか、
そして「それが起きたことをどこまで知りたいか」を分けて考えるのがポイントです。
なぜ「自動更新の通知」を意識する必要があるのか
いつ・何が変わったかを把握できないと怖い
自動更新は便利ですが、
「気づかないうちにコードが変わっている」という状態でもあります。
もし通知が何も来ないと、
ある日サイトの表示がおかしくなったときに、
いつからおかしいのか
何が変わったのか
どの更新が原因か
という手がかりがほとんどありません。
逆に、
「◯月◯日に WordPress 本体が自動更新されました」
「◯◯プラグインが自動更新されました」
という通知が残っていれば、
トラブルシューティングの起点がはっきりします。
天才プログラマー視点で言えば、
「本番環境にいつデプロイが走ったか分からない」のはかなり危険です。
自動更新を使うなら、そのログを人間が追えるようにしておく＝通知設定が重要になります。
通知が多すぎても「ノイズ」になる
一方で、
プラグインが多いサイトで、
すべての自動更新についてメール通知を飛ばすと、
管理者のメールボックスが「更新されました」だらけになります。
そうなると、
本当に重要な通知（セキュリティ修正など）も、
その他大勢に埋もれてしまいます。
つまり、
「通知ゼロ」は怖いけれど、
「通知だらけ」もまた別の意味で危険です。
だからこそ、
どのレベルの自動更新について、
どのくらいの粒度で通知を受け取るか、
を自分の運用に合わせて決める必要があります。
WordPress が標準で送ってくる主な自動更新メール
コア（WordPress 本体）の自動更新通知
WordPress 本体が自動更新されたとき、
デフォルトでは管理者メールアドレス宛に通知が届きます。
内容としては、
どのバージョンからどのバージョンに上がったか
更新が成功したかどうか
場合によっては、セキュリティ修正を含むかどうか
といった情報が書かれています。
これはかなり重要度が高い通知です。
本体の更新は、テーマやプラグインとの互換性に影響することがあるため、
「いつ上がったか」を知っておく価値が大きいからです。
プラグイン・テーマの自動更新通知
プラグインやテーマも、自動更新を有効にしていると、
更新が行われたタイミングでメール通知が来ることがあります。
特に、
セキュリティ修正を含む更新
メジャーアップデート
などは、通知内容をちゃんと読んでおきたいところです。
ただし、
プラグイン数が多いサイトでは、
これが大量に飛んでくることもあります。
ここで「どこまで通知を受けるか」を調整したくなるわけです。
通知設定を考えるときの基本方針
まず「どのメールアドレスに届いているか」を確認する
通知の前提として、
WordPress の「管理者メールアドレス」が正しく設定されているかが重要です。
設定 → 一般 の「管理者メールアドレス」に書かれているアドレスが、
自動更新通知の送り先になります。
ここが、
個人の普段使わないアドレス
前任者のアドレスのまま
共有されていないアドレス
になっていると、
せっかくの通知が誰にも読まれません。
まずは、
「このサイトの自動更新通知は、誰が受け取ることになっているのか」
を一度確認しておくことが大事です。
「誰が読むか」と「どこまで細かく知りたいか」を決める
通知設定を考えるときは、
技術担当（あなた）が読むのか
非エンジニアの担当者も読むのか
チーム全体で共有したいのか
といった「読む人」と、
コアの更新だけでいいのか
プラグイン・テーマも知りたいのか
セキュリティ関連だけに絞りたいのか
といった「知りたい範囲」をセットで考えます。
プログラミングで言えば、
「どのログレベルを、どのチャンネルに流すか」を決めるのと同じです。
ERROR だけメール、INFO はログだけ、みたいな設計ですね。
コードで通知を制御するイメージ
※ここでは「どういう発想で制御するか」を、コードのイメージで説明します（実際にはプラグインでやることも多いです）。
コア更新の通知を抑制・制御するフィルター
WordPress には、自動更新や通知を制御するためのフィルターがいくつか用意されています。
例えば、auto_core_update_send_email フィルターを使うと、
コア更新時のメール送信を制御できます。
イメージとしては、こんな感じです。
add_filter( 'auto_core_update_send_email', function( $send, $type, $core_update, $result ) {
// $type には 'success', 'fail', 'critical' などが入る
if ( $type === 'success' ) {
// 成功時の通知は不要にする例
return false;
}
return $send;
}, 10, 4 );
このイメージでは、
「成功したときの通知は止めるけれど、失敗や重大な更新の通知は受け取る」
というような制御ができます。
プログラミング的には、
「ログレベルごとに通知するかどうかを分ける」
という発想です。
プラグイン・テーマ更新の通知制御
プラグインやテーマの自動更新通知も、
フィルターやフックを使って制御できます。
例えば、auto_plugin_update_send_emailauto_theme_update_send_email
といったフックを使うことで、
「プラグインの自動更新メールは送らない」
「テーマの更新だけ通知する」
といった細かい調整が可能です。
ただし、
ここまでコードで細かく制御するのは、
ある程度慣れてからで十分です。
初心者のうちは、
「通知が来ること」自体をちゃんと理解し、
「どのアドレスに届いているか」を整えるだけでも、大きな前進です。
プラグインで通知を“見える化”するという選択肢
メールだけに頼らず、ダッシュボードで履歴を見る
自動更新の通知はメールだけでなく、
ダッシュボード上で「いつ何が更新されたか」を一覧できるようにするプラグインもあります。
こうしたプラグインを使うと、
メールはざっくり確認用
詳細な履歴はダッシュボードで確認
という役割分担ができます。
プログラミングで言えば、
「アラートは Slack に飛ばしつつ、詳細は監視ツールの画面で見る」
という運用に近いです。
チーム運用なら「共有できる場所」に集約する
複数人でサイトを運用しているなら、
自動更新の情報を「個人のメールボックス」だけに閉じ込めるのはもったいないです。
たとえば、
管理者メールアドレスを共有アドレスにする
メールを転送してチームのメーリングリストに流す
別途、更新履歴をまとめるドキュメントを作る
といった形で、
「誰が見ても、いつ何が更新されたか分かる」状態を作ると、
運用の透明性が一気に上がります。
具体例でイメージする通知ポリシー
例1：個人ブログの場合
あなたが一人でブログを運営していて、
技術的なことも自分で見ているとします。
この場合の現実的な方針は、
管理者メールアドレスを自分が普段見るアドレスにしておく
コアの自動更新通知は必ず受け取る
プラグインの自動更新通知も、最初はオンのまま様子を見る
くらいで十分です。
通知が多すぎてうるさいと感じたら、
後から「成功時だけ抑える」などの調整を考えれば OK です。
例2：企業サイト・クライアントサイトの場合
クライアントのサイトを管理している、あるいは社内の公式サイトを運用している場合、
管理者メールアドレスを「運用チーム用の共有アドレス」にする
技術担当がそのメールを監視し、重要な更新だけを別途報告する
必要に応じて、成功通知を減らし、失敗・重大更新だけをメールに残す
といった運用が現実的です。
ここで大事なのは、
「誰も読んでいない通知が延々と飛び続ける」状態にしないことです。
通知は“読まれて初めて意味があるログ”です。
まとめ：自動更新を「ブラックボックス」にしないための通知設定
「自動更新の通知設定」を考えるというのは、
本番環境でいつコードが変わったか
その結果が成功だったのか失敗だったのか
誰がその事実を把握しているのか
を、ちゃんと設計するということです。
自動更新そのものは、
セキュリティと運用コストのバランスを取るための強力な仕組みですが、
通知がなければ「勝手に変わる怖い仕組み」にもなり得ます。
まずは、
管理者メールアドレスが正しいか確認する
届いた自動更新メールの内容を一度ちゃんと読んでみる
ここからで十分です。
そのうえで、
「通知が多すぎる」「どこまで知りたいか」を自分の運用に合わせて言語化し、
必要ならコードやプラグインで細かく調整していく。
それが、
“なんとなく自動更新をオンにしている人”と
“本番環境の更新フローを設計している人”の分かれ目になります。
