WordPress の自動更新（バックグラウンド更新）の仕組み — 何が自動で、何が対象外なのか
「WordPress は勝手に更新されるのか」という質問は、保守を引き継いだ直後によく出る。答えは「一部は自動で、一部は自動ではない」であり、その境目を知らないまま運用すると、思っていた更新が実は止まっていた、という状況になりやすい。
この記事では、WordPress の自動更新（バックグラウンド更新）が何を対象にしているか、いつ動くか、どこで設定を変えられるかを整理する。特定の製品の実装ではなく、WordPress 本体の一般的な仕組みの解説である。
補足: ここでの説明は WordPress 公式ドキュメントに記載された挙動に基づく。細かい既定値はバージョンで変わることがあるため、実際の環境では管理画面や
wpコマンドの表示で確かめてほしい。
自動更新の対象は「種類ごと」に違う
WordPress で更新される対象は、大きく分けて次の5種類ある。自動更新に関する既定の扱いは、種類ごとに異なる。
| 対象 | 既定の扱い |
|---|---|
| コア（マイナー・セキュリティ更新） | 自動で更新される |
| コア（メジャー更新） | 自動では更新されない（管理者が選ぶ） |
| プラグイン | 自動では更新されない（個別に有効化できる） |
| テーマ | 自動では更新されない（個別に有効化できる） |
| 翻訳ファイル | 自動で更新される |
ここでいう「マイナー」と「メジャー」は、バージョン番号の付き方の違いである。たとえば 6.5.2 から 6.5.3 のような小さな更新（主に不具合修正やセキュリティ修正）がマイナー、6.5 から 6.6 のように機能が加わる更新がメジャーにあたる。
つまり、何も設定を変えていない標準的なサイトでも、コアの小さな更新と翻訳は黙って適用されている。一方で、プラグインとテーマは、管理者が許可しない限り自動では動かない。
いつ、どうやって動くのか
自動更新は、常駐する専用プログラムが行っているわけではない。WordPress の疑似cron（WP-Cron）の仕組みの上で動く。
- WordPress は1日に2回程度、更新の有無を確認する処理を走らせる
- その流れの中で、自動更新の対象になっているものがあれば、更新を実行する
- 実行後、サイトの管理者宛てに結果をメールで知らせる
WP-Cron は、サイトにアクセスがあったときに動く仕組みである。アクセスのほとんどないサイトでは、更新の確認が遅れることがある。サーバー側の cron から定期的に WP-Cron を呼ぶ構成にしているサイトでは、その定期実行がそのまま自動更新のきっかけになる。
設定を変える3つの入口
1. 管理画面
プラグインとテーマは、一覧画面から1つずつ「自動更新を有効にする」を選べる。コアは、メジャー更新も含めて自動にするかどうかを、更新画面で選ぶ。
2. wp-config.php の定数
コアの自動更新の範囲は、wp-config.php の定数で指定できる。
// コアの自動更新を、マイナー更新だけに限る（既定に近い設定）
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
// メジャー更新も含めて自動にする
define( 'WP_AUTO_UPDATE_CORE', true );
// コアの自動更新を行わない
define( 'WP_AUTO_UPDATE_CORE', false );
また、AUTOMATIC_UPDATER_DISABLED を true にすると、自動更新の仕組み全体を止められる。
3. フィルターフック
テーマやプラグインのコードから、更新の対象を細かく制御するフィルターも用意されている。たとえば、コアのメジャー更新を許可する allow_major_auto_core_updates、プラグインごとに自動更新の可否を決める auto_update_plugin などである。「このプラグインだけは自動にしない」といった個別の判断は、このフィルターで書かれていることが多い。
WP-CLI で状態を確かめる
管理画面を開かなくても、WP-CLI で状態を確かめられる。
# 自動更新が有効になっているプラグインを確認する
wp plugin auto-updates status --all
# 特定のプラグインの自動更新を有効にする
wp plugin auto-updates enable <plugin-slug>
# コアの更新があるかを確認する
wp core check-update
複数のサイトを預かっている場合、「どのサイトのどのプラグインが自動更新になっているか」を一覧で把握しておくと、更新が止まっている原因を探すときに役立つ。
自動更新が「動かない」主な理由
設定上は自動更新が有効なのに更新されない、というケースには、いくつか典型的な原因がある。
- ファイルへの書き込み権限がない。WordPress は更新時にファイルを置き換えるため、書き込みできない環境では止まる。
- バージョン管理下のディレクトリである。コアは、Git などで管理されている環境を開発中とみなし、自動更新を避ける判定を持っている。
AUTOMATIC_UPDATER_DISABLEDが設定されている。ホスティング側や過去の担当者が設定していて、気づかれていないことがある。- WP-Cron が動いていない。cron を無効にしている構成で、代わりの定期実行が設定されていないと、更新の確認自体が走らない。
- ほかの更新処理とぶつかっている。更新中はロックがかかり、途中で失敗すると一時的に再試行が止まることがある。
原因の切り分けでは、まず「設定が有効か」、次に「WP-Cron が動いているか」、最後に「書き込めるか」の順に見ると整理しやすい。
自動更新をどう位置づけるか
自動更新は、更新を忘れることによる事故を減らすための仕組みである。特にコアのセキュリティ更新は、公開から適用までの間隔が短いほど安全側に働く。
一方で、プラグインやテーマの自動更新は、更新後に表示や動作が変わる可能性がある。WordPress 6.6 以降では、プラグインの自動更新で致命的なエラーが検出された場合に、更新前の状態へ戻す仕組みも入っているが、見た目の崩れや機能の変化まで検知できるわけではない。
そのため、実務では次のように考えることが多い。
- コアのマイナー更新と翻訳: 既定のまま自動にしておく
- 更新頻度が高く、影響範囲が小さいと分かっているプラグイン: 自動更新を検討する
- 決済・会員・フォームなど、止まると困る機能を担うもの: 自動にせず、更新前にバックアップを取ったうえで手動で適用し、更新後の表示を確認する
「自動にするか手動にするか」は、技術的な優劣ではなく、そのサイトで更新後の確認に誰がどれだけ時間を割けるかで決まる。自動更新を有効にした場合でも、更新結果のメールが届いているか、更新後に表示が崩れていないかを、定期的に見る習慣は残しておきたい。
まとめ
- 既定で自動なのは、コアのマイナー更新と翻訳。メジャー更新・プラグイン・テーマは明示的に許可しない限り自動にならない
- 動作は WP-Cron に依存する。アクセスが少ないサイトや cron を無効にした構成では、確認が遅れる
- 設定の入口は、管理画面・
wp-config.phpの定数・フィルターフックの3つ。状態の確認は WP-CLI でできる - 自動にする範囲は、更新後の確認に割ける体制と合わせて決める
3-2-1 ルールのようなバックアップの考え方と組み合わせ、「更新前に戻せる状態があるか」を確かめたうえで自動更新の範囲を決めていくと、事故を未然に防ぎやすくなる。