2025.12.20

なぜ勝手にメジャーアップデートしたのか？

WEB先案内

2025年12月3日（水）の朝、クライアントから立て続けにメッセージが飛んできました。

「管理画面が WordPress 6.9 になってるんですが、これって更新して大丈夫なんですよね？」
「うちも6.9になってました。もしかして自動で上がる設定でしたっけ？」

自分でメジャーアップデートした覚えはない。
なのに、同じサーバー上の複数サイトが一斉に 6.8.3 → 6.9 へ。

その瞬間、頭の中でフラグが立ちます。

・誰かが勝手に設定を変えた？
・サーバー側の自動更新が動いた？
・それとも、何かセキュリティインシデントの前兆？

保守サイトを何十件も抱えていると、
「理由の分からない自動更新」は、ただの仕様ではなくリスクになります。

この記事では、そうした状況に備えるために

・コア自動更新の方針が、どのバージョンからどう変わってきたのか
・update-core.php / schema.php のコードが、何を根拠に自動更新の可否を決めているのか
・自分が預かっているサイトの「現在の自動更新設定」を、どこを見れば把握できるのか

を、クライアントワーク前提の実務目線で整理します。

「誰がポチったのか」を探すのではなく、
「なぜそう動いたのか」をコードと設定から説明できるようになりたい制作者向けのガイドです。

1. コア自動更新のざっくり結論
- Automatic Background Updates
- 自動バックグラウンド更新
2. 自動更新の公式ポリシーをざっくり押さえる
3. 自動更新を決めている4レイヤー構造
4. 5.5系までと 5.6 以降で何が変わったか
- 5.5.17 まで
- 5.6 以降
5. schema.php の populate_options() で決まる「新規インストール時のデフォルト」
6. update-core.php の core_auto_updates_settings() がやっていること
7. 6.8.3 → 6.9 の自動更新が起きる条件整理
8. 自分のサイトの「自動更新状態」を確認するチェックリスト
9. まとめ
- 9.1. メジャー自動更新を「怖がる」のではなく「設計する」
ウェブナラはじめました！

1. コア自動更新のざっくり結論

先に全体像だけ押さえておきます。

WordPress 3.7 以降
「メンテナンス・セキュリティリリース（いわゆるマイナー更新）」は自動更新が標準仕様になっている
→ 3.7 の正式ドキュメントのハイライトに「Background Updates（保守・セキュリティ更新の自動適用）」と明記されています。

Automatic Background Updates

For WordPress 3.7+, you don’t have to lift a finger to apply minor and security updates. Most sites are now able to automatically apply these updates in the background. If your site is capable of one-click updates without entering FTP credentials, then your site should be able to update from 3.7 to 3.7.1, 3.7.2, etc. (You’ll still need to click “Update Now” for major feature releases.)

日本語訳

自動バックグラウンド更新

WordPress 3.7以降では、マイナーアップデートやセキュリティアップデートの適用に手間取ることはありません。ほとんどのサイトでは、これらのアップデートがバックグラウンドで自動的に適用されます。FTP認証情報の入力なしでワンクリックアップデートが可能なサイトであれば、3.7から3.7.1、3.7.2などにアップデートできるはずです。（メジャー機能リリースの場合は、「今すぐ更新」をクリックする必要があります。）

WordPress 5.6 以降
「新規インストールされたサイト」に限り、メジャー更新も自動適用を前提にした設定が追加された（後述の auto_update_core_major オプション）。

This Release and Next

WP5.6: For new installations, default behavior will change: opted-in to minor updates by default and opted-in to major updates by default.

WP5.6: Provide some updates to the design of the UI.

WP5.6: For existing installations, the behavior will remain the same as it is today: opted-in to minor updates by default, but a user must opt-in to major updates (constants and filters that are already in use by hosts or agencies will still take precedence).

日本語訳

このリリースと次回

WP5.6 : 新規インストールの場合、デフォルトの動作が変更されます。デフォルトではマイナーアップデートがオプトインされ、デフォルトではメジャーアップデートがオプトインされます。

WP5.6 : UI のデザインにいくつかの更新を加えます。

WP5.6 : 既存のインストールの場合、動作は現在と同じままです。マイナーアップデートはデフォルトでオプトインされますが、メジャーアップデートはユーザーがオプトインする必要があります (ホストまたは代理店によって既に使用されている定数とフィルターは引き続き優先されます)。

実際に自動更新されるかどうかは、ざっくり言うと次で決まります。

フィルタ allow_*_auto_core_updates
定数 WP_AUTO_UPDATE_CORE
サイトオプション auto_update_core_dev / minor / major
それらが存在しない場合の「デフォルト値」

つまり

6.8.3 → 6.9 のメジャー更新が自動で走るケースは、
「5.6以降に新規インストールされたサイト」かつ
「WP_AUTO_UPDATE_CORE やホスティングの制御で止められていない」

という条件がそろっている場合に、普通にありえます。

2. 自動更新の公式ポリシーをざっくり押さえる

歴史を簡単にまとめると、こうなります。

3.7 で「自動バックグラウンド更新」導入
- メンテナンス・セキュリティ更新（3.7.x みたいな末尾だけ変わる更新）は自動で当てる方針が採用。
それ以降も「マイナーは基本自動、メジャーは慎重に」がベースライン
5.6 でメジャー自動更新の UI と新規インストール向けデフォルトが導入
- 「このサイトはWordPressの新しいバージョンごとに自動更新されます」的な切り替えリンクが update-core.php に追加される。

この「自動更新の方針」は、開発者向けドキュメント「Automatic Background Updates」でも整理されています。

3. 自動更新を決めている4レイヤー構造

コアの自動更新は、一か所で決まっているわけではありません。
ざっくり、下の4レイヤーを上から順に評価して「最終的なYES/NO」が決まります。

フィルタ
- allow_dev_auto_core_updates
- allow_minor_auto_core_updates
- allow_major_auto_core_updates
定数
- WP_AUTO_UPDATE_CORE
- AUTOMATIC_UPDATER_DISABLED など
サイトオプション
- auto_update_core_dev
- auto_update_core_minor
- auto_update_core_major
デフォルト
- 何も指定が無い場合にどう振る舞うか（バージョンや環境によって異なる）

ポイント

「フィルタ」が最上位にいて、ホスティング事業者やプラグインがここでゴリっと上書きできる
定数 WP_AUTO_UPDATE_CORE は「サイト側の意思表示」としてかなり強いシグナル
新規インストールで自動的に保存される初期オプションは schema.php の populate_options() が担当

4. 5.5系までと 5.6 以降で何が変わったか

5.5.17 まで

UIとして「メジャーアップデートを自動にする／しない」の切り替えは存在しない
基本路線は「マイナーのみ自動、メジャーは手動」
ただし、ホストやプラグインがフィルタや定数で上書きすればメジャー自動も可能

つまり、コア単体のデフォルト世界観としては

マイナー: 自動
メジャー: 自動ではない（が、コード上は「やろうと思えばできる状態」）

5.6 以降

ここで大きな差分が入ります。

開発ブログの「Auto-updates for major Core releases」では、5.6 以降の挙動がこう説明されています。

新規インストールされたサイトでは
- auto_update_core_major オプションが「enabled」で保存される
- つまり「メジャー自動更新前提」でスタートする
既存サイト（アップグレードして5.6以降になったサイト）は
- いきなりメジャー自動ONにはしない
- 管理画面からONに切り替えるか、定数・フィルタで明示的に有効化する

このため、

5.5系から運用している古いサイト
→ 通常はメジャー更新は自動になっていない（ホストや定数で変えていない限り）
5.6 以降に「新規インストール」したサイト
→ 何もいじっていないと、メジャー更新も自動になる可能性が高い

という差が生まれます。

5. schema.php の populate_options() で決まる「新規インストール時のデフォルト」

新規インストール時に wp_options にどんな値が入るかは、
wp-admin/includes/schema.php の populate_options() で一括定義されています。

5.6 以降では、ここで

'auto_update_core_dev'   => 'enabled',
'auto_update_core_minor' => 'enabled',
'auto_update_core_major' => 'enabled',

'auto_update_core_dev'   => 'enabled',
'auto_update_core_minor' => 'enabled',
'auto_update_core_major' => 'enabled',

PHP

のように、コアの自動更新関連オプションが初期登録されます（バージョンやブランチによって細部は異なりますが、趣旨としてはこのイメージ）。

ポイントは二つです。

populate_options() が動くのは「新規インストール時」
→ 既存サイトのアップグレードでは実行されない
ここで auto_update_core_major が enabled になるかどうかで
「6.8.3→6.9のようなメジャー自動更新の候補に乗るか」が決まる

この「新規インストール時だけメジャー自動をONにする」という設計が、
5.6 以降の大きな仕様差分です。

wp_optionsとは？

wp_options テーブルは、WordPressの「サイト設定倉庫」です。
コアの自動更新ポリシーも、最終的にはここに保存されているフラグで決まります。

新規インストール時：schema.php の populate_options() が、初期値を wp_options に書き込む
既存サイトをアップグレードしたとき：アップグレード処理が、wp_options 内の auto_update_core_major などを上書きする

つまり、「サイトはメジャー自動更新が有効なのか？」を突き詰めていくと、最終的には wp_options に保存された auto_update_core_* の値を見る話になります。

6. update-core.php の core_auto_updates_settings() がやっていること

次に、ユーザーがよく目にする「更新画面の表示ロジック」です。
wp-admin/update-core.php に定義されている core_auto_updates_settings() は、
おおまかに次のような手順で状態を組み立てています。

6-1. サイトオプションから初期値を読む

$upgrade_dev   = get_site_option( 'auto_update_core_dev',   'enabled' ) === 'enabled';
$upgrade_minor = get_site_option( 'auto_update_core_minor', 'enabled' ) === 'enabled';
$upgrade_major = get_site_option( 'auto_update_core_major', 'unset'   ) === 'enabled';

$upgrade_dev   = get_site_option( 'auto_update_core_dev',   'enabled' ) === 'enabled';
$upgrade_minor = get_site_option( 'auto_update_core_minor', 'enabled' ) === 'enabled';
$upgrade_major = get_site_option( 'auto_update_core_major', 'unset'   ) === 'enabled';

PHP

dev / minor は、オプションが無ければ「enabled」扱い
major は、オプションが無い場合は「unset」として扱い、後段のロジックで判断

6-2. WP_AUTO_UPDATE_CORE 定数で上書き

if ( defined( 'WP_AUTO_UPDATE_CORE' ) ) {
    if ( false === WP_AUTO_UPDATE_CORE ) {
        $upgrade_dev   = false;
        $upgrade_minor = false;
        $upgrade_major = false;
    } elseif ( true === WP_AUTO_UPDATE_CORE
        || in_array( WP_AUTO_UPDATE_CORE, array( 'beta', 'rc', 'development', 'branch-development' ), true )
    ) {
        $upgrade_dev   = true;
        $upgrade_minor = true;
        $upgrade_major = true;
    } elseif ( 'minor' === WP_AUTO_UPDATE_CORE ) {
        $upgrade_dev   = false;
        $upgrade_minor = true;
        $upgrade_major = false;
    }

    $can_set_update_option = false;
}

if ( defined( 'WP_AUTO_UPDATE_CORE' ) ) {
    if ( false === WP_AUTO_UPDATE_CORE ) {
        $upgrade_dev   = false;
        $upgrade_minor = false;
        $upgrade_major = false;
    } elseif ( true === WP_AUTO_UPDATE_CORE
        || in_array( WP_AUTO_UPDATE_CORE, array( 'beta', 'rc', 'development', 'branch-development' ), true )
    ) {
        $upgrade_dev   = true;
        $upgrade_minor = true;
        $upgrade_major = true;
    } elseif ( 'minor' === WP_AUTO_UPDATE_CORE ) {
        $upgrade_dev   = false;
        $upgrade_minor = true;
        $upgrade_major = false;
    }

    $can_set_update_option = false;
}

PHP

ここで重要なのは

false
→ コアの自動更新はすべて無効
true
→ dev / minor / major すべて自動更新対象
‘minor’
→ マイナーだけ自動

という3パターンのプリセットがあることです。

また can_set_update_option を false にしているので、
この定数が定義されている環境では

管理画面側の「自動更新を有効／無効」のUIは、
状態表示だけで、クリックしても実質変更できない

という挙動になります。

6-3. 自動更新全体が禁止されている場合

WP_Automatic_Updater::is_disabled() が true の場合（AUTOMATIC_UPDATER_DISABLED、ファイル書き込み不可等）、

dev / minor / major をすべて false に落とし込み
UI側も「そもそも自動更新できない状態」として扱う

という分岐があります。

6-4. フィルタによる最終調整

最後に

allow_dev_auto_core_updates
allow_minor_auto_core_updates
allow_major_auto_core_updates

の各フィルタが呼ばれ、ここで true/false を上書きできます。
ホスティング事業者が「うちの環境ではメジャー自動は危険だから禁止」などのポリシーを入れるのはここです。

6-5. 管理画面にどう表示されるか

最終的な $upgrade_major / $upgrade_minor の組み合わせで、

マイナーバージョンもメジャーバージョンも自動更新される画面

マイナーバージョンのみ自動更新される画面

マイナーバージョンのみ更新できるリンクが表示される

自動更新しない画面

といったメッセージが出し分けられます。

裏側でやっていることを一言で言うと

populate_options() で用意した初期値
wp-config.php の定数
フィルタ

をまとめて「人間に読める状態」に変換しているのが core_auto_updates_settings() です。

7. 6.8.3 → 6.9 の自動更新が起きる条件整理

ここまでを、実務で問題になりやすい事例にまとめます。

次の条件がそろうと、メジャー更新も自動で走りえます。

そのサイトが 5.6 以降に「新規インストール」されている
- schema.php の populate_options() で auto_update_core_major = enabled がセットされている
wp-config.php に
- define(‘WP_AUTO_UPDATE_CORE’, false);
  が定義されていない
AUTOMATIC_UPDATER_DISABLED などで自動更新自体を殺していない
allow_major_auto_core_updates フィルタで false にされていない
- 逆に、ホストが true を強制している場合もありうる
サーバーの cron / WP-Cron が正常に動いている

レンタルサーバー（例: エックスサーバー）の「WordPress簡単インストール」機能は、独自の自動更新ロジックを追加することがあります。
その場合は

WordPressコア側のロジック
サーバー側の「アプリケーション自動アップデート」機能

の両方を見ないと、実際の挙動は判断できません。

8. 自分のサイトの「自動更新状態」を確認するチェックリスト

ここまで読んで

「で、うちのサイトは今どの設定になってるの？」

という実務的な疑問に対して、確認ポイントをまとめます。

8-1. 管理画面「ダッシュボード → 更新」を見る

ここで表示されるテキストは、core_auto_updates_settings() の判定結果そのもの
メジャー自動ONか、マイナーだけか、完全OFFかが分かる

8-2. wp-config.php を確認する

WP_AUTO_UPDATE_CORE
- false / true / ‘minor’ のどれかが書かれていないか
AUTOMATIC_UPDATER_DISABLED
- true なら、そもそも自動更新全体が止まる

この2つがあれば、サイト側でかなり強い意思表示をしている状態です。

8-3. options.php で auto_update_core_* を確認する

管理画面から
https://example.com/wp-admin/options.php
にアクセス
下記オプションの値を確認
- auto_update_core_dev
- auto_update_core_minor
- auto_update_core_major

注意点

options.php は「生のオプションテーブル編集画面」なので、誤操作すると普通に壊れます
触る前に必ずバックアップを取り、値を変えるならローカルでロジックを理解してから

8-4. サーバー管理画面の自動更新設定も確認

エックスサーバーなど一部ホストは、
「アプリケーション自動アップデート」機能を独自に提供しています
そこでも「メジャー自動ON」「マイナーのみ」「完全OFF」を切り替えられるケースがある

管理画面と wp-config.php を見ても合わない時は、
サーバーパネル側で上書きされている可能性を疑うべきです。

8-5. アップデート制御系プラグインの影響

「自動更新を制御する系」のプラグイン（例: WP Downgrade、Easy Updates Manager など）はフィルタやオプションを書き換えるので、最優先で確認対象になります。

9. まとめ

9.1. メジャー自動更新を「怖がる」のではなく「設計する」

3.7 以降、マイナー更新（セキュリティ・メンテナンス）は「自動」が前提
5.6 以降、「新規インストールされたサイト」はメジャー更新も自動ONの方向に仕様変更
実際に更新が走るかどうかは「フィルタ → 定数 → サイトオプション → デフォルト」の4レイヤーで決定される
6.8.3 → 6.9 の自動更新も、このロジックに沿っていれば「仕様の範囲」

運用側としてやるべきことはシンプル

セキュリティと安定性のバランスを決める
（どこまで自動にするか）
そのポリシーを
- wp-config.php
- サーバーパネル
- プラグイン設定で一貫させる
「なぜこのサイトは勝手にメジャーバージョンになったのか？」を、ソースコードレベルで説明できる状態にしておく

ここまで理解しておけば、
クライアントから「勝手にメジャーバージョンになったんだけど！？」と言われても、

いつインストールされたサイトか
どのレイヤーで自動更新がONになっているか

を順番に確認して、落ち着いて説明できます。

WordPressは、黙って夜中に働いてくれる優秀な子です。
「勝手にやったな？」ではなく、「どの指示を忠実に実行したのか？」という目線で見てあげると、運用設計がだいぶ楽になります。

ココナラよりも安い！

なぜ勝手にメジャーアップデートしたのか？

1. コア自動更新のざっくり結論

Automatic Background Updates

自動バックグラウンド更新