WordPress の自動更新を「とりあえず全部ON」にして、ある朝サイトが真っ白に──制作会社や Web 担当者なら一度はヒヤッとした経験があるはずです。かといって更新を放置すれば、既知の脆弱性を突かれて改ざん・乗っ取りに遭います。本記事は 「壊さず・放置せず」を両立する自動更新の方針を、コア / プラグイン / テーマの 3 系統に分けて整理し、wp-cli での一括設定と更新前バックアップをコピペで使える形でまとめます。対象は WordPress を運用する Web 担当者・サイト運営者・制作会社です。

なぜ「全部ON」も「全部OFF」も危険なのか

自動更新の設定は、極端な 2 択にすると必ずどちらかで事故ります。

全部OFF(放置型): 更新通知を消したまま放置すると、プラグインの既知脆弱性が公開された瞬間から「いつ攻撃されてもおかしくない」状態になります。実際、Web サイト乗っ取りの多くは「更新を当てていれば防げた」既知の穴が入口です。
全部ON(無条件型): 決済・予約・会員系など、サイトの根幹を担うプラグインまで無条件で自動更新すると、互換性の崩れや PHP 致命的エラー(白画面)を営業時間中に踏む可能性があります。気づくのが顧客からの「サイトが見られない」という連絡、というのが最悪のパターンです。

そこで本記事は、「更新の種類(コア/プラグイン/テーマ)」×「重要度」で振り分ける運用を取ります。考え方はシンプルです。

対象	推奨方針	理由
コア(WordPress 本体)	マイナー(セキュリティ)は自動 / メジャーは手動	マイナーは互換性影響が小さく、放置のリスクが大きい
プラグイン(定番・低リスク)	自動ON	更新頻度が高く、放置すると穴になりやすい
プラグイン(決済・フォーム・大規模カスタム)	自動OFF(手動+ステージング検証)	1 つの不具合が売上・問い合わせ直撃
テーマ(公式・親テーマ)	子テーマ運用なら自動ON	カスタムは子テーマ側にあり親更新の影響が小さい
テーマ(フルカスタム)	自動OFF	更新で独自改修が壊れる/上書きされる恐れ

コアの自動更新:マイナーはON、メジャーは手動

WordPress 本体は、wp-config.php の定数 1 行で挙動を固定できます。マイナー(セキュリティ・メンテナンス)更新だけ自動、メジャーは手動にするのが多くの運用サイトでの安全側の既定値です。

// wp-config.php(/* That's all, stop editing! */ より上に追記)
// 'minor' = マイナー(セキュリティ)更新のみ自動。メジャーは管理画面で手動。
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

値の意味は次の通りです('minor' が通常サイトのデフォルト挙動)。

'minor' … マイナー(例: 6.5 → 6.5.x)のみ自動。推奨。
true … 開発版・マイナー・メジャーをすべて自動。検証フローが整っていないサイトでは非推奨。
false … すべての自動更新を停止。セキュリティ更新まで止まるため、手動運用を徹底できる場合以外は避けます。

メジャー更新(例: 6.5 → 6.6)は、後述のステージングで表示崩れ・プラグイン互換を確認してから手動で当てます。

プラグイン/テーマ:重要度で振り分ける(wp-cli)

プラグイン単位の自動更新は WordPress 5.5 以降、管理画面でも切り替えられますが、複数サイト・多数プラグインを一括で・再現可能に管理するなら wp-cli が確実です。

まず現状を棚卸しします。

# 各プラグインの有効状態と自動更新の ON/OFF を一覧
wp plugin list --fields=name,status,auto_update --allow-root

定番で更新頻度が高く、壊れても影響が限定的なものは自動ONにします。

# 例: スパム対策・SEO など低リスクな定番は自動更新ON
wp plugin auto-updates enable akismet wordpress-seo --allow-root

逆に、決済・カート・予約・問い合わせフォーム・大規模な独自カスタムを含むプラグインは自動OFFにし、手動でステージング確認してから更新します。

# 例: EC・フォーム系は手動運用(自動更新OFF)
wp plugin auto-updates disable woocommerce contact-form-7 --allow-root

テーマも同じ考え方です。子テーマで運用していれば親テーマ(公式テーマ)は自動ONにできます。独自改修を親テーマ本体に入れている場合は自動OFFにしてください。

# テーマの自動更新状態を確認 → 公式の親テーマは自動ON
wp theme list --fields=name,status,auto_update --allow-root
wp theme auto-updates enable twentytwentyfive --allow-root

補足:--allow-root は root で実行する場合のフラグです。本来は Web サーバの実行ユーザー(例: www-data)で実行するのが安全で、その場合は不要です。

更新前バックアップを自動化する(運用の本体)

自動更新を許す代わりに、「いつでも 1 つ前に戻せる」状態を機械的に担保します。これが無いまま自動更新を任せるのは、シートベルト無しで高速に乗るようなものです。DB とアップロード/プラグイン本体(wp-content)を世代付きで保存するスクリプトを用意します。

#!/usr/bin/env bash
# /usr/local/bin/wp-backup.sh — DB + wp-content を世代付きで保存
set -euo pipefail

WP_PATH="/var/www/html"
DEST="/var/backups/wp/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$DEST"

cd "$WP_PATH"
# DB を SQL でエクスポート(--add-drop-table で復元時に綺麗に上書き)
wp db export "$DEST/db.sql" --add-drop-table

# テーマ・プラグイン・アップロードをまとめて保存
tar czf "$DEST/wp-content.tar.gz" -C "$WP_PATH" wp-content

# 世代管理:14 日より古いバックアップは削除
find /var/backups/wp -maxdepth 1 -type d -mtime +14 -exec rm -rf {} +

実行権限を付けて、自動更新が走る前の早朝に毎日回します。

chmod 750 /usr/local/bin/wp-backup.sh

# /etc/cron.d/wp-maintenance — 毎日 03:30 に Web 実行ユーザーでバックアップ
30 3 * * * www-data /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1

これで「自動更新で何か壊れても、当日早朝の状態へ wp db import と tar 展開で戻せる」状態になります。バックアップの保存先は本番と同じサーバだけに置かない(別ディスク/外部ストレージへも複製する)のが鉄則です。

失敗に気づく仕組み:メール通知と自動ロールバック

WordPress には自動更新の失敗を検知する仕組みが入っています。WordPress 5.5 以降は、プラグイン/テーマの自動更新が成功・失敗するとサイト管理者(admin_email)へ結果メールが届きます。さらに WordPress 6.6 で「自動ロールバック」が本体に追加され、プラグインの自動更新中に PHP の致命的エラーを検知すると、更新前のバージョンへ自動で巻き戻したうえで管理者に通知するようになりました。

ただしこれは万能ではないため、運用側でも更新後の状態を確認できるようにしておきます。

# 各プラグインの現在バージョンと自動更新状態をまとめて確認
wp plugin list --fields=name,version,update,auto_update --allow-root

admin_email が届く実在アドレスになっているか(運用窓口の共有メールなど)も合わせて確認してください。通知が誰にも届かない設定だと、せっかくの失敗検知が機能しません。

まとめ

自動更新は「全部ON / 全部OFF」ではなく、コア・プラグイン・テーマ × 重要度で振り分ける。
コアは WP_AUTO_UPDATE_CORE = 'minor' でマイナーのみ自動、メジャーは手動。
プラグイン/テーマは wp plugin auto-updates enable/disable(wp theme ...)で、定番=自動 / 決済・フォーム・カスタム=手動に振り分ける。
更新前バックアップを cron で自動化し、いつでも 1 つ前へ戻せるようにする。
admin_email を実在の窓口に向け、5.5 以降のメール通知と 6.6 の自動ロールバックを活かす。

関連記事

更新の取りこぼしや、外部から見えてしまっている管理画面・ログイン経路は、サイトドック(無料・登録不要)でまとめて外形チェックできます → https://sitedock.jp