WordPressの自動更新は安全か — 有効にする前に決めておく4つのこと

結論：問うべきは「有効にするか」ではない

「WordPress の自動更新はオンにしても大丈夫でしょうか」と、よく聞かれます。

この問いには、そのままでは答えられません。自動更新の危険度は、更新そのものではなく壊れたときに気づけるか、戻せるかで決まるからです。検知と復旧の手当てがあれば自動更新は安全側の選択になりますし、無ければ手動更新のほうがまだましです。手動なら、少なくとも作業した人が直後に画面を見ます。

自動更新を「更新作業の自動化」と捉えると、判断を誤ります。実際には運用設計の問題です。この記事では、有効にする前に決めておくべきことを整理します。

自動更新は 1 つの機能ではない。既定で動くのはどれか

まず前提を揃えます。WordPress の自動更新は対象ごとに別の仕組みで、既定値も異なります。

対象	既定	補足
コアのマイナー更新	有効	セキュリティ修正・不具合修正。WordPress 3.7 以降
コアのメジャー更新	無効	明示的に有効化が必要
プラグイン	無効	5.5 以降、1 つずつ切り替え
テーマ	無効	同上
翻訳ファイル	有効

つまり何も設定していないサイトでも、コアのマイナー更新はすでに自動で当たっています。「うちは自動更新を使っていない」と認識しているサイトの多くが、実際には一部だけ自動で動いている状態です。

制御は wp-config.php の WP_AUTO_UPDATE_CORE 定数や auto_update_plugin フィルタで行いますが、これらに触れる前に決めるべきことがあります。

もう 1 つ、見落としやすい前提があります。自動更新は wp-cron に依存します。負荷対策で DISABLE_WP_CRON を有効にし、代替のシステム cron を設定していないサイトでは、有効にしたつもりの自動更新が一度も動きません。管理画面には「自動更新有効」と表示されたままなので、気づく機会がありません。

「更新に成功しました」は、動作の証明ではない

ここがこの記事で最も伝えたい点です。

更新処理の成功は、ファイルの入れ替えが完了したことしか意味しません。サイトが訪問者にとって正しく動いているかは、まったく別の話です。

WordPress 6.3 以降、プラグインの自動更新で致命的エラー（fatal error）が発生した場合に自動で元へ戻す仕組みが入りました。これは大きな前進ですが、拾えるのはサイトが落ちる壊れ方だけです。

運用で本当に困るのは、落ちない壊れ方のほうです。

• お問い合わせフォームが送信できなくなる（画面は正常に表示される）
• 予約フォームの日付選択が動かなくなる
• レイアウトが崩れる、特定のブロックだけ表示されなくなる
• 検索や並び替えの結果が変わる

これらはいずれも HTTP ステータスは 200 です。死活監視も、fatal エラーのロールバックも反応しません。更新ログには「成功」と残ります。誰かが実際に問い合わせようとして初めて分かり、そのときには何日か経っています。

壊れたことに気づく経路を、更新の成否とは別に用意する必要があります。

自動更新で壊れるときの、典型的な 3 つの形

1. 手を入れたプラグインが、元に戻る

プラグイン本体の PHP を直接書き換えて運用しているサイトは、珍しくありません。PHP 8 系への移行にあたって、やむを得ず手を入れたというケースが特に多く見られます。

自動更新はこれを予告なく上書きします。厄介なのは、上書きされた結果が「元の正しい状態」ではないことです。PHP 8 で動かないコードに戻るので、更新した瞬間に fatal エラーになります。

自動更新を有効にする前に、プラグインへ直接手を入れた箇所がないかを棚卸しする必要があります。そして見つかったら、その事実を台帳として記録し、対象を自動更新から除外します。「たぶん無いはず」で始めると、いつか必ず当たります。

2. 商用プラグインが「成功」と記録して、何も更新しない

有料ライセンスのプラグインは、公式ディレクトリではなく開発元のサーバーから更新を取得します。この経路はライセンスキーの認証を伴うため、キーが失効していても、通信に失敗しても、更新処理そのものはエラーにならないことがあります。

結果として、更新ログには成功が並び、実際のバージョンは古いまま据え置かれます。脆弱性が公表されている版のまま「更新済み」として扱われる、という最も避けたい形になりえます。

対策は、更新ログを信じないことです。更新後に、実際のバージョン番号を読んで突き合わせるしかありません。

3. 版番号の比較が、直感と食い違う

「メジャーバージョンを跨ぐ更新は自動では当てない」という運用は一般的です。ところが、これを実装するのは見た目より難しい。

たとえば 2.4.91 から 2.6.3 への更新を考えます。先頭の数字だけを比べる実装では、どちらも 2 なので「メジャー跨ぎではない」と判定されます。しかし中身はマイナーバージョンを 2 つ飛び越えており、破壊的変更が含まれている可能性は十分にあります。

除外ルールを設けるときは、そのルールが実際に何を通して何を止めるのかを、実データで確認してください。「メジャーは止める設定にしてあります」という言葉だけでは、何も保証されていません。

有効にする前に決めておく 4 つのこと

1. 戻し方（バックアップではなく、復旧手順）

「バックアップは取っています」は答えになりません。決めるべきは、壊れたと分かってから何分で戻せるかです。

• 更新の直前時点に戻せるか（日次バックアップだと、最大 24 時間分の投稿や問い合わせが消えます）
• ファイルとデータベースの両方が揃っているか
• 実際に復旧を試したことがあるか

3 つ目が最も重要です。復旧手順は、試していなければ手順ではありません。

2. 壊れたことの検知方法

前述のとおり、更新の成否とは別の経路が要ります。最低限、次のいずれかは必要です。

• 更新の前後で、主要ページの表示内容を比較する
• フォームの送信を実際に試す
• エラーログの増分を見る

「サイトが開くか」だけの監視では足りません。開くけれど壊れている状態が、最も多いからです。

3. 除外するものと、その理由の記録

自動更新から外すものは、必ず出ます。手を入れたプラグイン、ベンダー指定でバージョンを固定しているもの、更新にデータベースの移行処理を伴うもの。

大切なのは、外した理由を検証可能な形で書き残すことです。「未確認なので保留」と書くと、確認が済んだ後も保留だけが残り続けます。「◯◯の対応が入ったら解除する」のように、解除条件で書いてください。

4. 適用のタイミング

配布直後に当てるか、数日待つか。どちらにも根拠があります。

• 即時に当てる：脆弱性の修正であれば、待つこと自体がリスクになります
• 数日待つ：不具合を含んだ版が短期間で撤回されることは、実際にあります

現実的にはセキュリティ修正は即時、機能追加は待つという切り分けが扱いやすいです。ただしこれを自動で判定するには、更新情報のどのフィールドを根拠にするかを、あらかじめ決めておく必要があります。

それでも、自動更新は有効にしたほうがよい

ここまで危険な面ばかり書きましたが、結論は「自動更新を使うべき」です。

手動更新の最大の問題は、サイトが増えると必ず抜けることです。5 サイトなら回りますが、20 サイトを毎週手で確認する運用は続きません。続かない運用は、いつか止まります。そして、止まったことに誰も気づきません。

CloudHonu では 230 サイト以上を自動更新で運用しています。2026 年 8 月の 1 か月で 2,487 件の更新を適用し、自動ロールバックの発動は 0 件でした。これは自動更新が本質的に安全だからではなく、上に挙げた 4 つを先に決めてあるからです。

まとめ

自動更新は「更新作業の自動化」ではなく「運用の設計」です。決めるべきは、有効にするかどうかではありません。

1. 壊れたときの戻し方（試したことがあるか）
2. 壊れたことの検知方法（更新の成否とは別の経路で）
3. 除外するものと、その理由（解除条件つきで）
4. 適用のタイミング（セキュリティ修正と機能追加で分ける）

この 4 つが決まっていれば、自動更新は安全側の選択です。決まっていなければ、自動でも手動でも、いずれ同じ場所で転びます。