更新の自動化は、全部任せるか全部止めるかではなく種類ごとに決める。WordPressは公式が種類ごとに既定を書き、OSの更新は通知・取得・導入の3段に分けられる ── 担当サイトの自動更新を種類ごとに確かめる13項目（2026年11月時点）

目次

1. 01 何が書いてあるか — 公式は、更新の自動化を「種類ごとの既定」で書いている
   1. 7月17日と10月28日のWordPressの告知
   2. WordPressの更新の種類ごとの既定と、変える方法
   3. OSの側は、通知・取得・導入の3つの段に分けられる
2. 02 なぜ・背景 — 「自動で入れる」と「自動で確かめる」は、別の話である
   1. 更新の5つの段と、機械に任せられる範囲
   2. 入れたあとに、失敗に気づく仕組み
   3. 更新の頻度は、手で入れる回数に直すと見えてくる
3. 03 用語 — 出てくる言葉を、先にそろえる
   1. 更新まわりの言葉
   2. どこの文書の言葉か、で呼び名が違う
4. 04 型別 — 適用範囲、書かれていないこと、手順
   1. 適用範囲 — この記事の話が当てはまる人
   2. 書かれていないこと — この記事が確かめていないもの
   3. 手順 — 5つの段で、任せる範囲を決める
5. 05 明日、担当サイトで確認できることチェックリスト
   1. このリストの使い方
   2. 13項目
6. 06 代替・他の選択肢 — 全部任せる、通知だけにする、手で入れる
   1. 方法を並べる
   2. 止める手段の対応表
   3. 自動にしたあとに、確かめ続けること
7. 07 当サイトで確かめたこと — 自動では入らなかった更新を、手で入れた2つの記録
   1. 記録に残っていること
   2. いま確かめていないこと
   3. 2026年11月10日 追記 ── 種類ごとの一覧を作った
8. 08 このテーマは、ここまで — 版の一覧から、任せる範囲の決め方へ
   1. これまでの記事
   2. 当サイトのブログとの対応
   3. 今回の記事の位置
   4. 2026年11月10日 — この記事の確認日
9. 09 この記事のまとめ

01 何が書いてあるか — 公式は、更新の自動化を「種類ごとの既定」で書いている

7月17日と10月28日のWordPressの告知

WordPress.orgのニュースには、2026年7月17日付けで7.0.2のリリースの告知がある。要旨は3つである。セキュリティ更新なので、直ちに更新するよう勧めていること。深刻度が高いため、WordPress.orgのチームが自動更新の仕組みを使った強制的な更新を有効にしたこと。自動のバックグラウンド更新に対応しているサイトでは、更新が自動で始まること。直した問題は、深刻度が最も高い区分と、その次の区分の2件で、SQLインジェクションと、そこからコードの実行につながりうる問題が含まれる、と書かれている。

2026年10月28日付けの7.1.4の告知も、同じ型で書かれている。セキュリティ更新なので直ちに更新するよう勧めていて、自動のバックグラウンド更新に対応しているサイトでは、更新が自動で始まる、という文がある。強制的な更新の文は、7.0.2の告知では読んだが、7.1.4の告知では読まなかった。この記事の筆者が読んだ範囲での違いである。

7月17日から10月28日までを、WordPress.orgのリリースの一覧（Release Archive）で数えると、更新が出た日は7日ある（7月17日、8月6日、8月12日、9月17日、9月22日、10月6日、10月28日）。8月19日の7.1は、新しい系統の公開で、この7日には数えていない。期間は103日で、日の間隔は、時系列に並べると20日、6日、36日、5日、14日、22日である。7.0系と7.1系の2つの系統が並走し、9月17日、22日、10月6日、10月28日は、両方の系統が同じ日に出ている（7.0.5〜7.0.8と、7.1.1〜7.1.4）。版の番号で数えると11件になる。告知の題に「セキュリティ」と付くものと付かないものがあり、すべてがセキュリティ更新かどうかは、告知ごとには確かめていない。7.0.5以降は、一覧の表示で読んだもので、個別の告知は読んでいない。当サイトの別の記事では、10月28日の7.1.4について、WordPress 7.1.4は10月28日に出て、公式は直ちに更新するよう勧めたで、担当サイトの版を一覧にして期限を決める手順を書いた。

WordPressの更新の種類ごとの既定と、変える方法

開発者向け文書の更新の設定のページによれば、自動のバックグラウンド更新はWordPress 3.7で入った。対象は、本体（コア）、プラグイン、テーマ、翻訳ファイルの4種類である。種類ごとに、既定が違う。

• 本体の小さな更新は、ほとんどのサイトで既定で有効と書かれている。
• 本体の大きな更新は、5.6より前は、小さな更新と翻訳ファイルだけが既定の対象だった。5.6以降の新しい導入では、小さな更新と大きな更新の両方が既定で有効になり、既存のサイトは、管理者が大きな更新を有効にしない限り、従来の動きのままと書かれている。
• 翻訳ファイルは、既定で自動更新される。
• プラグインとテーマは、2020年の告知によれば、5.5で自動更新の画面が加わり、既定は無効で、管理者が有効にする。

止める・変える手段も、種類ごとに別である。本体の更新は、wp-config.phpに書く定数WP_AUTO_UPDATE_COREで、真・偽・小さな更新だけ、の3通りを指定できる。すべての種類の自動更新を止めるには、定数AUTOMATIC_UPDATER_DISABLEDを真にするが、文書は止めることを強く勧めないと書く。プラグインとテーマは、管理画面で1つずつ切り替えられ、フィルターという別の手段もある。2020年の告知は、フィルターで返した値は、管理画面で選んだ自動更新の設定をすべて上書きすると書く。画面で「無効」にしたはずのプラグインが、フィルターのせいで更新される、という食い違いが起きうる、というのが筆者の読みである。

OSの側は、通知・取得・導入の3つの段に分けられる

サーバーのOSの更新にも、自動の仕組みがある。Ubuntuの文書は、自動更新のunattended-upgradesが、既定では公式のリポジトリだけを設定した形で入ると書く。見送りたい更新は、Package-Blacklistの行に書く。各行は正規表現として検査される。文書は、止めたパッケージに依存する更新も、入らなくなることがあると注意している。再起動の設定（Automatic-Reboot）の既定は偽で、真にすると、更新の実行の終わりに、確認なしで再起動する。再起動の時刻は、「今すぐ」か、「時:分」の形で決められる。メールの報告は、宛先を書いたときだけ出て、メールを送る別のパッケージが要る。

RHEL系のOSで使うdnf-automaticは、設定のファイルとは別に、3つのタイマーを用意している。1つ目は、更新があることを知らせるだけ。2つ目は、ダウンロードまでで、入れない。3つ目は、ダウンロードして入れる。設定には、対象を、すべての更新にするか、セキュリティの勧告のあるものだけにするか（upgrade_type）、入れるかどうか（apply_updates）、再起動するか（reboot）がある。rebootの既定は再起動しないで、「更新のたびに再起動する」と「再起動が必要なときだけ再起動する」の選択肢もある。

02 なぜ・背景 — 「自動で入れる」と「自動で確かめる」は、別の話である

更新の5つの段と、機械に任せられる範囲

NISTのパッチ管理の手引き（2022年4月）は、組織のパッチ管理を、見つける、優先を決める、取得する、入れる、入れたことを確かめるの5つの動詞で説明している。手引きは、パッチを当てることを、技術にとっての予防的な保守と位置づけ、手順を簡単にして日々の作業に乗せる戦略を作ることを勧めている。この記事で使う「自動化」は、この5つの段のうち、どこまでを機械に任せるか、という意味である。

図のとおり、WordPressの自動更新も、OSの自動更新も、仕組みとして用意されているのは、おもに「入れる」までである。「入れたことを確かめる」の段は、仕組みによって、ある範囲まで入っているものと、人の手が要るものに分かれる。次の節で、WordPressの例を読む。

入れたあとに、失敗に気づく仕組み

WordPressには、プラグインの自動更新が失敗したときに、前の版に戻す仕組みの提案がある。2024年4月19日の提案によれば、自動更新のあとにホームページへの読み込み（ループバック）を行い、そこでPHPの致命的なエラーを検出したら、前に入っていた版を復元し、サイトの管理者のメールアドレスに通知を送る。自動更新をしている間は、メンテナンスモードが有効になる、とも書かれている。提案は、ループバックが動かないサイトでは、自動更新は走らないはずだ、とも述べている。

この仕組みが、いつの版から入ったかは、開発者向け文書の関数の説明で確かめられる。致命的エラーを検出する関数の説明には、6.6.0で加わったという変更履歴があり、致命的なエラーはメンテナンスモードが有効でないと検出できない、という説明もある。提案の文書は計画であって、出荷された挙動そのものではない。出荷後の細かい挙動は、この記事では確かめていない。

更新の頻度は、手で入れる回数に直すと見えてくる

01章で数えたとおり、103日の間にWordPressの更新が出た日は7日あった。間隔は、20日、6日、36日、5日、14日、22日の順である。更新のたびに、バックアップを取り、複製で確かめ、本番に入れ、表示を確かめるなら、担当サイトが10あれば、103日の間に70回（7日×10サイト）の手順が回る。ここまでの手順を、全部、人が毎回やると決めるのか、一部を機械に任せるのか。この記事は、その線引きを決める材料を、公式の文書から集めたものである。

03 用語 — 出てくる言葉を、先にそろえる

更新まわりの言葉

言葉	意味（読んだ文書の要旨）	この記事での使い方
自動のバックグラウンド更新	WordPress 3.7で入った、管理者が操作しなくても更新が入る仕組み	WordPressの自動更新のこと
小さな更新・大きな更新	文書は、minorとmajorと書く。この記事では日本語で、小さな更新・大きな更新と書く	WordPress本体の更新の2種類
安全更新	dnf-automaticで、セキュリティの勧告のある更新だけを対象にする設定（upgrade_type）	OSの更新の絞り込みの例
通知だけ	更新があることを知らせるだけで、入れない設定。dnf-automaticには専用のタイマーがある	任せる・手での中間の選択肢
戻し	更新の失敗のあと、前の版に戻すこと。WordPress 6.6.0以降の仕組みと、バックアップから戻す手順がある	入れる前に、戻せるかを確かめる対象
複製（ステージング）	本番と同じ作りで、本番に影響しない場所に作ったサイトの写し	更新の前に、所要時間と表示を確かめる場所

どこの文書の言葉か、で呼び名が違う

同じ更新の自動化でも、文書によって、使う言葉が違う。WordPressの文書は「自動更新」と「バックグラウンド更新」、Ubuntuの文書は「無人の更新（unattended upgrades）」、DNFの文書は「自動（automatic）」と書く。担当サイトの設定を調べるときは、画面や設定のファイルの名前が、これらのどれかになる。探す言葉を、先に3つ並べておくと、探し漏れが減る。

04 型別 — 適用範囲、書かれていないこと、手順

適用範囲 — この記事の話が当てはまる人

当てはまるのは、WordPressなどのCMSと、そのサーバーの更新の方針を、担当サイトごとに決める人である。共用のレンタルサーバーで、OSの更新を事業者が行う場合は、OSの話は、事業者がどの種類をいつ入れるのかを、契約や案内で確かめる話になる。WordPressの話は、どの環境でも、管理者の側の設定である。

制作会社や社内の担当者として、複数のサイトを見る人は、サイトごとに、更新の方針が違う（本体は自動、プラグインは手、など）状態になりやすい。更新の方針を、1つの台帳に書いて見える形にするだけでも、更新の日の判断が速くなる、というのが筆者の想定である。

書かれていないこと — この記事が確かめていないもの

読んだページに書かれておらず、この記事では確かめていないことを、先に挙げる。

• いまのWordPressの管理画面で、プラグインとテーマの自動更新の既定が、無効のままか。読んだのは2020年の告知で、いまの画面は開いていない。
• 翻訳ファイルの自動更新を、どの手段で止められるか。読んだ文書に、止め方は書かれていなかった。
• 7月17日の強制的な更新が、どの版のサイトを対象にしたか、実際に何件に入ったか。
• WordPress 6.6.0以降の戻しの仕組みの、出荷後の細かい挙動。読んだのは、提案の文書と、関数の説明である。
• Red Hatの製品文書。2026年11月10日に開こうとしたが、アクセスを拒否されて開けなかったので、RHEL固有の記述は確かめていない。DNFの開発側のページを読んだ。そのページには、設定の項目がいつの版から入ったかの記載は無かった。

手順 — 5つの段で、任せる範囲を決める

手順は、更新の種類を並べるところから、台帳に書くところまで、5つの段で進める。05章のチェックリストは、この順に並べてある。

1. 更新の種類を、並べる。WordPress本体の小さな更新、大きな更新、プラグイン、テーマ、OSの安全更新、OSのそれ以外、再起動を伴う更新の7つにする。
2. いまの設定を、種類ごとに確かめる。設定のファイルと管理画面で、自動・通知だけ・手のどれになっているかを書く。
3. 3つの問いで、種類ごとに分ける（下の図）。
4. 通知の宛先と、読む人を決める。自動にした種類ほど、結果を読む人が要る。
5. 確かめる手順と、見直す日を、台帳に書く。

05 明日、担当サイトで確認できることチェックリスト

このリストの使い方

このリストは、WordPressの管理画面と、サーバーの端末（またはサーバーの管理画面）を開いた状態で、上から順に進める。表示の名前は、画面の言語や版で違うことがあるので、近い名前の項目で読み替える。チェックの状態は、ブラウザに保存され、サーバーには送られない。13項目のうち、数や値を書く項目は、台帳（表計算でよい）に書き写す。

13項目

• WordPressの管理画面で、更新の画面を開き、いまのWordPressの版と、新しい版の表示の有無を、台帳に書き写す
• wp-config.phpを開き、AUTOMATIC_UPDATER_DISABLEDとWP_AUTO_UPDATE_COREの2つを検索し、見つかったか、値は何かを書く（無ければ「無し」と書く）
• プラグインの一覧を開き、有効なプラグインの数と、自動更新が有効になっているものの数を、数えて書く
• テーマの一覧を開き、テーマの数と、自動更新が有効になっているものの数を、数えて書く
• 自動更新が有効なプラグインのうち、決済・会員・予約・フォームのどれかを担うものを3つまで選び、名前を書いて、自動のままにするか、通知だけにするかを決める
• WordPressの管理者のメールアドレスを開き、自動更新の失敗や戻しの通知が届く宛先か、読む人のものかを確かめ、宛先を台帳に書く
• サーバーがUbuntuかDebianなら、unattended-upgradesの設定でAutomatic-Rebootの値と、Package-Blacklistの行の数を書き、試し実行（--dry-run）を1回行って、入る予定の更新の数を書く
• サーバーがRHEL系なら、dnf-automaticのタイマー3つ（通知・取得・導入）のうち、有効なものを一覧で見て書き、設定のupgrade_typeとrebootの値を書く
• 自動の再起動が許可されているかを書き、許可されているなら、再起動の時刻が、サイトの利用の少ない時間かを、アクセスの記録で確かめる
• 直近のバックアップの日時を書き、そのうち1つを複製の環境に戻して、トップページが開くかを、1回確かめる
• パッケージの更新の履歴（dnf historyか、apt の履歴のファイル）で、直近30日に入った更新の数を数えて書く
• 更新のあとに必ず開く5ページ（トップ、お問い合わせ、決済か予約、ログイン、記事1本）を決めて書き、更新の前後で同じ5ページの画面を撮って比べる手順を書く
• 更新の種類ごと（本体の小さな更新、大きな更新、プラグイン、テーマ、OSの安全更新、OSのそれ以外、再起動）に、「任せる」「通知だけ」「手で」を1つずつ書き、見直す日を決めて書く

06 代替・他の選択肢 — 全部任せる、通知だけにする、手で入れる

方法を並べる

更新の自動化の選び方は、全部を同じ強さにすることではない。表は、読んだ文書の説明から筆者が整理したもので、どれを選ぶかは、担当サイトの事情で決まる。

選び方	できること	注意すること
入れるまで任せる	更新の公開から、入るまでの時間が短い。7月17日の告知のように、公式が自動更新で強制的に入れる場合も、対応するサイトでは自動で始まる	入れたあとの確かめは、別に必要。戻しの仕組みは、致命的なエラーを見る範囲に限られると読んだ
取得までは任せ、入れるのは手で	dnf-automaticの取得用タイマーのように、ダウンロードまでを機械に任せ、入れる時刻を人が決められる	取得したままで入れ忘れると、更新が溜まる。入れる担当と日を決める必要がある
通知だけにする	更新があることを、メールなどで知れる。入れる・入れないの判断は人が持つ	通知が読まれないと、手での更新も止まる。宛先と、読む人の決め方が要る
全部を手で入れる	入れる時刻と順番を、完全に人が決められる	公式の文書は、すべての自動更新を止めることを強く勧めないと書く。更新の頻度が高い時期は、手の回数が増える

止める手段の対応表

止めたい種類が決まったら、止める手段を、文書で確かめる。表は、読んだ文書が書く手段を、種類ごとに並べたものである。

種類	止める手段	注意すること
WordPress本体	wp-config.phpの定数WP_AUTO_UPDATE_COREを、偽か、小さな更新だけ、にする	すべての種類を止める定数もあるが、文書は強く勧めない
プラグイン・テーマ	管理画面で1つずつ切り替える。フィルターで一括にもできる	フィルターの値は、画面の設定をすべて上書きする（2020年の告知）
Ubuntu・Debianのパッケージ	Package-Blacklistに、見送るパッケージを書く	止めたものに依存する更新も、入らなくなることがある
OSの再起動	Automatic-Rebootを偽のままにする。dnf-automaticは、rebootを「再起動しない」にする	再起動が要る更新は、入れたあとも、新しい版が使われていないことがある
RHEL系のOSの更新	dnf-automaticの通知用タイマーだけを有効にする。または、取得用までにする	入れる担当と日を決めないと、更新が溜まる

自動にしたあとに、確かめ続けること

自動にした種類は、設定した日で終わらない。確かめることは、3つに絞れる。通知が届いているか（宛先が変わっていないか）、更新の履歴が残っているか（直近30日に何が入ったか）、更新の後の5ページが開くかである。この3つのどれかが欠けると、自動の更新は、「何が入ったか分からない更新」に変わる。

07 当サイトで確かめたこと — 自動では入らなかった更新を、手で入れた2つの記録

記録に残っていること

当サイトには、自動更新の対象にならず、手で入れた更新の記録が2つある。1つ目は、2026年10月22日のPHPである。使っているPHPの系統には、公式の更新版が通常の更新として出ていなかったため、公式が示した修正を当てて作り直した版に、手で入れ替えた。入れ替えの前後で、複数のページの中身を比べた。手順は、PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本でと、PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だったに書いた。入れたことの確かめ方は、PHPの2件の脆弱性が悪用リストに載り、期限は10月29日だったに書いた。

2つ目は、2026年11月4日の、毎朝の解析の処理の実行環境である。手で入れた、保守の終わった系統の実行環境で動いていた。提供元の修正版は別の系統で出ていたが、手で入れたものはサーバーのパッケージの更新の外にあり、更新されていなかった。そこで、パッケージ管理の仕組みで入れた側の実行環境へ手で切り替え、2回の朝で、処理が最後まで終わることを確かめた。記録は、毎朝の解析の処理が、保守の終わった系統の実行環境で動いていたにある。

いま確かめていないこと

この記事を書いた2026年11月10日には、当サイトの自動更新の設定は、確かめていない。どの種類を自動にし、どの種類を手にしているかを、この記事には書かない。運用の内部の設定は、公開しない方針のためである。05章の13番目の「種類ごとの一覧」を当サイトの運営の側で作り、日付をつけて、この章の末尾に追記する。

確かめられている範囲で言えるのは、上の2つの記録だけである。2つは、自動の範囲に入らなかった理由が違う。1つ目のPHPは、公式が、通常の更新の形で出していなかった修正だった。2つ目の解析の処理は、修正版は出ていたのに、手で入れた古い実行環境が、パッケージの更新の外にあったため、更新されなかった。自動の更新は、更新の仕組みの中にあるものだけを入れる。仕組みの外に置かれたものは、台帳に書かない限り、更新の対象から外れ続ける。「自動に任せない更新」と「仕組みの外にあるもの」を、台帳に残しておく理由として、この例を挙げる。

2026年11月10日 追記 ── 種類ごとの一覧を作った

この記事を公開した日に、05章の13番目の「種類ごとの一覧」を、当サイトの運営の側で作った。本体の小さな更新、大きな更新、プラグイン、テーマ、OSの安全更新、OSのそれ以外、再起動の7つに、当サイトで別に扱っているPHPを加えた8つの種類について、「任せる」「通知だけ」「手で」のどれにするかと、そう判断した根拠の設定を、1行ずつ書いた。見直す日は、3か月後の2027年2月10日とした。

一覧を作るときに、11番目の項目にあたる、直近30日のパッケージの更新の履歴も数えた。履歴に残った作業は6回で、うち2回はパッケージの追加と取り外しだった。履歴の6回が、一覧のどの行の話かも確かめた。一覧の中身は、上に書いた方針どおり、この記事には書かない。

08 このテーマは、ここまで — 版の一覧から、任せる範囲の決め方へ

これまでの記事

• WordPressの更新が5日の間に2回出た週に、担当サイトの版・自動更新・バックアップを一覧にする手順は、「WordPressは5日の間に、セキュリティ更新が2回出た」で書いた。
• WordPress本体の更新の最中に、コードを実行されうる脆弱性が悪用確認リストへ載った件は、「WordPress本体の更新の最中に、認証なしでコードを実行されうる脆弱性が、11月3日に悪用確認リストへ載った。期限は11月6日」で書いた。
• 更新を本番に入れる前に、複製で所要時間を測る手順は、「WordPress 7.2 Beta 4は「本番に入れない」試験版で、Beta 3は7.1.4に同梱された」で書いた。
• PHPの修正版が出た日に、どのサイトが当たるかを数分で答えるための一覧は、「PHPの修正版が出た日に「どのサイトが当たるか」を数分で答えるには、担当サイトの一覧が要る」で書いた。

当サイトのブログとの対応

• PHPの重大な脆弱性「php2shell」を、初心者から上級者まで1本で — 公式が通常の更新として出していない修正を、手で入れた記録。
• PHPの修正を入れても、版の番号も「作った日」も入れ替える前と同じ文字だった — 入れたあとに、修正が入ったかを、値で確かめる方法。
• 圧縮の部品（Brotli）の脆弱性は、縮めて送る側ではなく「元に戻す側」の話だった — 更新が入っていても、古い部品を持ったままの処理が残る例。
• 毎朝の解析の処理が、保守の終わった系統の実行環境で動いていた — 定時の処理の実行環境を、手で切り替えて確かめた記録。
• 記事のチェック項目を自分のサイトに当てたら、自分のサーバーが対象だった — 記事に書いた更新の確認を、自分のサーバーに当てた例。

今回の記事の位置

これまでの記事は、どの版が出たか、自分のサイトは当たるか、更新の前後で何を確かめるかを扱った。今回は、その1つ手前の、どの種類の更新を、どこまで機械に任せるかを扱った。読んだ範囲では、公式の文書が書いているのは、種類ごとの既定と、止める手段の名前までで、どこに線を引くかは、書かれていない。線を引くのは、担当サイトの運営の側である、というのが筆者の読みである。

2026年11月10日 — この記事の確認日

WordPressの管理画面での、いまの既定の表示と、翻訳ファイルの止め方、7月17日の強制的な更新の対象と範囲、6.6.0以降の戻しの細かい挙動、Red Hatの製品文書の記述は、確かめられなかった。次に開く日に、リリースの一覧と、各文書の既定の書き方が変わっていないかを、同じ手順で読み直す。