WordPressの自動更新は有効にする？本体・テーマ・プラグイン別の判断基準

WordPressの自動更新は、すべて有効にすれば安全になるわけでも、すべて止めれば事故を防げるわけでもありません。結論は、WordPress本体のマイナー更新は原則として自動、メジャー更新と影響の大きいテーマ・プラグインはサイトごとに判断することです。

更新を止め続ければ既知の脆弱性や互換性問題が残ります。一方、確認なしで自動更新すると、決済・予約・問い合わせフォーム・会員機能・独自カスタマイズが更新直後に止まっても発見が遅れるおそれがあります。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。更新後の復旧現場では、更新そのものより「対象を分けずに同じ設定にしたこと」と「正常確認の担当がいなかったこと」が問題になるケースを多く見てきました。

この記事では、単なるオン・オフの操作ではなく、更新対象の役割、サイト停止時の影響、復元できる体制まで含めて判断します。レンタルサーバー側が更新を管理している場合もあるため、WordPress管理画面だけで結論を出さないことが重要です。

現在の設定を変える前に、バックアップの取得日時と復元方法を確認してください。更新で問題が起きた時に戻せない状態なら、自動更新の設定変更より先に復旧手段を整えるのが正解です。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPress自動更新の結論は対象ごとに分ける

WordPress自動更新の基本方針は、本体・テーマ・プラグインを一括で考えず、更新の緊急性と壊れた時の影響を対象ごとに比べることです。

セキュリティ修正を早く取り込む利点は大きいものの、すべての更新が同じ危険度ではありません。小さな修正と仕様変更を含む大型更新、表示だけに関わる機能と売上に関わる機能では、確認すべき範囲が違います。

本体のマイナー更新は原則として有効にする

WordPress本体のマイナー更新には、セキュリティ修正や不具合修正が含まれます。たとえば「6.x.1から6.x.2」のような更新は、古い脆弱性を残さないため、原則として自動更新を維持します。

ただし、ホスティング会社が独自に更新を制御している場合や、古いPHP・長期間更新されていないテーマを使うサイトでは例外があります。自動更新を止めるなら、代わりに誰が何日以内に適用するかまで決めなければなりません。

メジャー更新は検証できる体制で決める

「6.xから7.x」のようなメジャー更新は、機能追加や内部仕様の変更が広く含まれます。個人ブログや標準構成の小規模サイトなら自動化しやすい一方、独自テーマや重要機能があるサイトでは先にテスト環境で確認すべきです。

メジャー更新を手動にしても、何か月も放置してよいわけではありません。公開後の一定期間で互換性情報を確認し、バックアップを取ったうえで計画的に更新します。

テーマとプラグインは役割と保守状況で決める

テーマとプラグインは、同じサイト内でも自動更新を個別に設定できます。影響が小さく、更新頻度が安定し、問題時にすぐ戻せるものは自動更新の候補です。

決済、予約、会員、フォーム、SEO、キャッシュ、バックアップ、ページビルダーなど、停止時の影響が大きいものは慎重に扱います。更新履歴と対応バージョンを確認し、監視できる時間帯に手動更新する運用が安全です。

WordPressのアップデート・保守をしないと危険｜放置で起こる深刻なリスクとは

WordPress自動更新で本体・テーマ・プラグインの違いを知る

WordPress自動更新を安全に使うには、更新対象ごとの役割と、管理画面に表示される設定の意味を理解することが先決です。

WordPress本体は更新の種類が複数ある

WordPress本体には、開発版、マイナー版、メジャー版など異なる更新があります。一般的な本番サイトでは、マイナーなセキュリティ・保守リリースの自動更新が重要です。

メジャー版の自動更新状態は、導入時期、管理画面の選択、サーバー会社の自動更新サービスによって異なります。「初期設定は必ずこうだ」と決めつけず、管理画面の「ダッシュボード→更新」とサーバー側の管理画面を両方確認してください。

本体だけを新しくしても、古いテーマやプラグインが対応していなければ不具合は起こります。本体の自動更新を判断する時は、現在使っているPHP、テーマ、主要プラグインの対応状況を一組として見ます。

テーマ更新は親テーマと子テーマを区別する

公式ディレクトリから入れた親テーマは、管理画面から自動更新を選べる場合があります。ただし、親テーマのファイルを直接編集していると、更新時に修正内容が上書きされます。

子テーマでカスタマイズしていれば親テーマを更新しやすくなりますが、互換性が自動的に保証されるわけではありません。テンプレート構造、フック、CSSの変更によって、子テーマ側の表示が崩れる可能性は残ります。

購入テーマや制作会社独自テーマでは、ライセンス認証や専用アップデーターが必要なこともあります。管理画面に自動更新の表示がないからといって、更新不要という意味ではありません。

プラグイン更新は機能ごとの事業影響を見る

プラグインは、管理画面の一覧から1つずつ自動更新を有効化できます。すべてを同時にオンにする前に、そのプラグインが止まると何が起きるかを書き出してください。

たとえばフォームが止まれば問い合わせ機会を失い、決済が止まれば売上へ直結します。キャッシュや最適化の更新では表示崩れ、SEOプラグインではメタ情報やサイトマップの変化、セキュリティプラグインではログイン制限の挙動変化が起こることがあります。

一方、更新を止めた古いプラグインは攻撃の入口になり得ます。重要機能だから止めるのではなく、重要機能だからこそ、検証・バックアップ・更新後確認をセットにした手動運用へ切り替えると考えてください。

WordPress自動更新の判断基準をサイト別に決める

WordPress自動更新を有効にする範囲は、サイトの規模ではなく、停止した時の損失と更新後に確認できる体制で決めます。

個人ブログや標準構成は自動化しやすい

標準テーマに近く、投稿閲覧が中心で、問い合わせや決済などの重要機能が少ないサイトは自動化しやすい構成です。本体マイナー更新に加え、保守が継続している小規模プラグインを個別に自動化できます。

ただし、個人ブログでもアクセスや広告収益が大きい場合、停止の影響は小さくありません。自動更新メールを受け取るだけでなく、トップページと主要記事を外部監視し、異常時に気づける状態を用意します。

企業サイトは問い合わせ導線を基準にする

会社案内サイトでも、問い合わせフォーム、資料請求、採用応募、電話計測などが営業導線なら重要システムです。公開ページが見えていても、フォーム送信だけ失敗している更新事故は見逃されやすくなります。

企業サイトでは、更新後にトップ、主要サービス、スマートフォン表示、フォーム送信、通知メール、管理画面を確認します。担当者が翌営業日まで確認できないなら、金曜深夜や長期休暇中の自動更新は避ける運用が安全です。

EC・予約・会員サイトは重要機能を手動にする

EC、予約、会員、オンライン講座、多言語など複数のプラグインが連携するサイトでは、主要機能の自動更新を一律で有効にしない方が安全です。更新前にテスト環境で注文やログインを再現し、問題がなければ本番へ反映します。

特に決済プラグインだけでなく、在庫、税計算、メール、PDF発行、会員権限、定期課金との組み合わせを確認します。単体の更新履歴に「互換」と書かれていても、自サイト固有の連携まで保証されるわけではありません。

独自開発や古い環境は先に棚卸しする

制作会社が追加した独自プラグイン、親テーマ直接編集、配布終了テーマ、古いPHPがあるサイトは、自動更新の前に構成を棚卸しします。更新通知が出ない独自機能ほど、WordPress本体との互換性確認が必要です。

現場では「自動更新を止めていたから壊れなかった」のではなく、古さが積み上がって一度に更新できなくなるケースがあります。止める期間が長いほど、段階更新、代替プラグイン、テーマ改修など作業範囲が広がります。

WordPressアップデート後に不具合発生？よくあるエラーと回避・復旧のポイント

WordPress自動更新の設定と安全な変更手順

WordPress自動更新の設定は、現在値を記録し、バックアップを確認してから、1種類ずつ変更するのが安全です。

管理画面で対象ごとの状態を確認する

最初に「ダッシュボード→更新」でWordPress本体の状態を確認します。続いて「プラグイン→インストール済みプラグイン」と「外観→テーマ」で、自動更新の有効・無効表示を1件ずつ確認します。

画面に「自動更新を有効化」と表示されていれば現在は無効、「自動更新を無効化」と表示されていれば現在は有効です。操作リンクの文言は現在状態ではなく、押した後に実行される動作を示す点に注意してください。

テーマは、使用中だけでなく待機中の標準テーマも確認します。使っていないテーマやプラグインは無効のまま残すより、復旧用の標準テーマなど必要なものを除いて削除した方が管理対象を減らせます。

設定ファイルとサーバー側の上書きを確認する

管理画面で設定を変えても反映されない場合、wp-config.php、MUプラグイン、通常プラグイン、サーバー側の管理機能で自動更新が制御されている可能性があります。

WordPress本体の自動更新方針を設定ファイルで管理する例は次のとおりです。ただし、既存の定義を重複させず、編集前に必ずファイルを保存してください。

// マイナーなコア更新だけを自動化する例
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

WP_AUTO_UPDATE_COREにはtrue、false、minorなどの指定がありますが、サーバー会社や管理プラグインの制御と組み合わさると結果が変わることがあります。コードを追加しただけで安心せず、次の更新通知と実行履歴まで確認します。

最初は一度にすべて有効化しない

設定変更は、まず影響の小さいプラグイン1〜2件から始め、更新通知、表示監視、バックアップの動作を確認します。問題に気づける運用ができてから対象を広げてください。

自動更新が実行された時刻、更新前後のバージョン、確認したページを記録すると、問題の原因を切り分けやすくなります。複数更新が同じ夜に走った場合でも、メールやログが残っていれば候補を絞れます。

手動更新は順番と確認を固定する

手動運用にする重要機能は、担当者の感覚に任せず、毎回同じ順番で進めます。更新前後の比較ができるよう、画面と動作の確認項目を先に決めます。

1. バックアップの完了時刻と保存先を確認する
2. 更新履歴、対応WordPress、対応PHPを確認する
3. 可能ならステージング環境で更新する
4. 本番では対象を1件ずつ更新する
5. 表示、フォーム、ログイン、重要機能を確認する
6. キャッシュを整理し、別端末でも確認する

WordPressプラグイン更新でエラーが出る時の復旧方法と安全なアップデート手順

WordPress自動更新を安全に続ける運用設計

WordPress自動更新は、スイッチを入れた時点ではなく、異常を検知して戻せる仕組みまで用意して完成です。

バックアップは取得より復元確認を重視する

自動バックアップが「成功」と表示されても、保存容量不足、データベース欠落、外部ストレージの認証切れなどで戻せないことがあります。ファイルとデータベースの両方があり、更新前の世代が残っているかを確認します。

ECや会員サイトでは、丸ごと復元すると更新後に入った注文や登録が消えるおそれがあります。プラグインだけ戻す、テーマだけ戻す、データベースを比較して必要箇所だけ直すなど、復元単位も事前に決めます。

更新メールと外部監視を組み合わせる

WordPressの更新メールは結果確認に役立ちますが、メール到着だけではサイトが正常とは判断できません。HTTP監視、ページの見た目、フォーム送信など、事業上重要な動作を別の方法で確認します。

最低限、トップページ、主要サービスページ、問い合わせ完了までの導線、管理画面ログインを確認対象にします。エラー通知の受信先は個人の退職済みアドレスではなく、現在の担当者が見られる共有先に設定してください。

更新を止めた対象には期限を付ける

互換性問題のため一時的に自動更新を止める判断はあります。しかし、「壊れるのが怖い」という理由だけで無期限に停止すると、脆弱性と技術的負債が増えます。

停止時には、理由、現在版、最新版本、脆弱性情報、代替候補、再確認日を記録します。開発元が更新を再開しない場合は、同等機能へ移行する期限を決めるべきです。

月1回は自動更新対象を見直す

サイトの機能は変化します。最初は単純なブログでも、後からフォーム、予約、会員、決済が追加されれば、自動更新の適切な範囲も変わります。

月1回、更新失敗メール、バックアップ、保留中の更新、使っていない拡張機能、PHP対応状況を確認します。大きな機能追加の前後では、自動更新設定を一時的に見直し、作業が落ち着いたら元へ戻します。

セキュリティ更新は通常更新より優先する

自動更新を無効にしているプラグインでも、重大な脆弱性が公表された時は通常の点検日を待たずに対応します。開発元の更新履歴、脆弱性情報、影響するバージョンを確認し、利用中ならバックアップ後すぐに検証してください。

すぐ更新できない場合は、対象機能の一時停止、アクセス制限、代替プラグインへの切り替えなどで攻撃経路を減らします。「自動更新を切っているから今回は見送る」という運用は、重要なセキュリティ修正を取り逃がします。

反対に、更新通知のすべてを緊急扱いにすると担当者が疲弊します。セキュリティ修正、重大不具合、機能追加、翻訳更新のように通知を分類し、対応期限を分けると継続できます。

更新後の確認結果を一枚に残す

更新台帳には、実行日時、対象名、変更前後の版、実行者、自動か手動か、バックアップ先、確認したURL、フォーム結果、エラーの有無を残します。専門的な監視ツールがなくても、共有表1枚から始められます。

記録があれば、翌日に表示崩れを見つけても「いつ、何が変わったか」を追えます。同じ更新で問題が再発した時も、過去の切り戻し手順を再利用でき、復旧時間を短縮できます。

WordPressのトラブルを防ぐための定期メンテナンスFAQとチェックリスト【完全保存版】

WordPress自動更新のよくある質問

WordPress自動更新の判断基準まとめ

WordPress自動更新は、本体マイナー更新を原則として有効にし、メジャー更新、テーマ、プラグインはサイトへの影響と検証体制で分けるのが基本です。

小規模サイトでも監視がなければ異常を見逃し、企業サイトでもバックアップと確認手順が整っていれば安全に自動化できる範囲は広がります。サイト規模より「気づけるか」「戻せるか」で判断してください。

自動更新を止める対象には必ず更新期限を設けます。脆弱性を放置せず、重要機能はテスト環境と手動確認で守り、影響の小さい対象から自動化することが現実的です。

まず今日、管理画面とサーバー管理画面の現在設定、バックアップの最終成功日時、更新通知の送信先を確認してください。この3点が分かれば、自分のサイトに合う自動更新方針を具体的に決められます。

WordPressバージョンアップ費用の相場と注意点

WordPress更新トラブルが自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で