WordPressは5日の間に、セキュリティ更新が2回出た ── 担当サイトの版・自動更新・バックアップを一覧で確かめる13項目（2026年10月時点）

目次

1. 01 何が起きたか — WordPressは、9月17日と22日の2回、セキュリティの修正を出した
   1. 7.1.1は、9月17日に出た
   2. 7.1.2は、5日後の9月22日に出た
   3. 2026年10月4日に確かめた、いちばん新しい版
2. 02 なぜ・背景 — 「自動で更新される」と書いてあっても、確かめる理由がある
   1. 47日の間に、セキュリティ関連の版が4回出ている
   2. 公式の整理の目安は、数か月に1回だった
   3. 自動更新が効かないサイトが、実際にある
   4. 複数のサイトを預かる人には、「どのサイトが済んだか」が見えにくい
3. 03 この記事で出てくる用語
   1. メンテナンスリリースとセキュリティリリース
   2. 自動バックグラウンド更新
   3. プラグインとテーマの自動更新
   4. サイトヘルス
   5. WP-Cron
4. 04 型別 — 適用範囲・この記事が確かめていないこと・手順
   1. 適用範囲 — この記事が向いているサイトと、向いていないサイト
   2. この記事が確かめていないこと
   3. 手順の流れは4つに分かれる
   4. 自動更新の状態を、3か所で確かめる
5. 05 明日、担当サイトで確認できることチェックリスト
   1. まず13項目を通して見る
   2. 観点別の内訳と、かかる時間
   3. 5分で終わらない項目があったとき
6. 06 代替・他の選択肢（表で）
   1. 更新を、誰が、どう行うか — 3つの運用の形
   2. WordPress以外のCMSの場合 — 公式の告知の場所を、1つずつ控える
   3. 複数サイトの更新をまとめて見る道具もある
   4. プラグインとテーマの自動更新は、別に決める
   5. バックアップは、データベースとファイルの両方
   6. 使っていないプラグインとテーマは、減らす
7. 07 一覧表を、運用に落とす — 頻度・担当・戻し方
   1. 一覧表の見本
   2. 更新の前に取るバックアップの作法
   3. バックアップの手順 — 取る対象・保存先・戻す練習
8. 08 このテーマの、これまで
   1. 2026年8月からのリリースの流れ
   2. 当サイトの過去の記事 — 通知の数を数える話と、点検の話
9. 09 この記事のまとめ

01 何が起きたか — WordPressは、9月17日と22日の2回、セキュリティの修正を出した

7.1.1は、9月17日に出た

WordPressの公式ニュースに、「WordPress 7.1.1 Maintenance and Security Release」（訳: WordPress 7.1.1 メンテナンスおよびセキュリティリリース）という告知が出た。日付は2026年9月17日である。中身は、本文によれば、コアのバグ修正が17件、ブロックエディターのバグ修正が19件、セキュリティの修正が11件である。

"the security fixes are being backported, where necessary, to all branches eligible to receive security fixes (currently through 4.7)."

（訳: セキュリティの修正は、必要な場合には、セキュリティ修正を受け取る資格のあるすべての系統に、さかのぼって適用されます（現時点では4.7まで）。）

「系統」は、WordPressの版の大きなまとまり（4.7、5.0、6.0、7.0など）のことである。告知は、古い系統にも修正を戻すと書いている。一方で、同じ告知は、実際に保守されているのは最新の版だけとも書いている。古い系統に修正が戻ることと、その系統が保守されていることは、別の話として読む必要がある。

7.1.2は、5日後の9月22日に出た

5日後の2026年9月22日に、「WordPress 7.1.2 Release」（訳: WordPress 7.1.2 リリース）が出た。公式ニュースの一覧には、この版について、重大度が「critical」（訳: 致命的）の脆弱性の修正を含むセキュリティリリース、という説明が付いている。修正の対象は、ページテンプレートの解決に関わる部分と書かれている。この記事では、脆弱性の仕組みや、悪用の手順には触れない。書くのは、自分のサイトで何を確かめるかだけである。

"Because this is a security release, it is recommended that you update your sites immediately."

（訳: これはセキュリティリリースなので、サイトをただちに更新することをお勧めします。）

この版も、修正が、セキュリティ修正を受け取る資格のあるすべての系統に戻されたと書かれている（現時点では4.7まで）。そして、7.1.1と同じく、自動のバックグラウンド更新に対応したサイトでは、更新が自動で始まる、という趣旨の一文がある。

2026年10月4日に確かめた、いちばん新しい版

公式ニュースのリリース一覧（2026年10月4日に開いた）では、7.1.2より新しい版は見つからなかった。つまり、この日の時点で、最新の版は7.1.2である。ただし、この一覧は、開いた日の姿でしかない。読む日には、もう一度、公式のページで確かめてほしい。

02 なぜ・背景 — 「自動で更新される」と書いてあっても、確かめる理由がある

47日の間に、セキュリティ関連の版が4回出ている

公式ニュースの一覧によると、8月6日に7.0.3（告知に「WordPress 7.0.3 is now available which features several security fixes.」（訳: WordPress 7.0.3が公開されました。複数のセキュリティ修正を含みます。）とある）、8月12日に7.0.4（告知に「features a security fix」（訳: セキュリティの修正を含みます）とある）、9月17日に7.1.1、9月22日に7.1.2が出ている。8月19日の7.1は機能追加の版なので、数えていない。8月6日から9月22日までは47日で、約7週間に、セキュリティの修正を含む版が4回出たことになる。

7.0.3の告知には、「Because this is a security release, it is recommended that you update your sites immediately.」（訳: これはセキュリティリリースなので、サイトをただちに更新することをお勧めします。）という一文もある。この数字は、更新の回数の話であって、「危険が増えた」という話ではない。

公式の整理の目安は、数か月に1回だった

WordPressの公式文書「WordPress Housekeeping」（訳: WordPressの手入れ）には、更新の確認について、古くからの目安が書かれている。

"It is recommended to check in with WordPress for updates and upgrades at least every three months, six months at the most."

（訳: WordPressの更新とアップグレードは、少なくとも3か月に1回、長くても6か月に1回は確認することをお勧めします。）

この文書は、日常の手入れの目安として書かれたものである。セキュリティ更新が5日の間に2回出た週には、この目安だけでは間に合わない。手入れの目安と、緊急の更新に備える仕組みは、別々に用意するほうがよい。

自動更新が効かないサイトが、実際にある

公式の文書は、自動更新が効かない場合を、対象ごとに書いている。コアについては、5.6以降の新規インストールが、バージョン管理のチェックアウトを検出した場合を除いて、既定で自動更新の対象になる、という書き方である（5.6より前から使っているサイトは、前の動きのままで、管理者・定数・フィルターでメジャー更新の自動更新を有効にした場合だけ変わる、とも書かれている）。プラグインとテーマの自動更新については、更新の実行がWordPressの定時実行の機能（WP-Cron）に頼っているため、サーバーやプラグインによっては正しく動かないことがある、と書かれている。操作の表示が管理画面に出ない場合は、ホスティング会社かプラグインが、その機能を一部または全部、無効にしている可能性がある、とも書かれている。

複数のサイトを預かる人には、「どのサイトが済んだか」が見えにくい

1つのサイトなら、管理画面を開けば、版の数字が見える。担当サイトが5つ、10つと増えると、管理画面ごとにログインして、版を確かめることになる。自動更新が効いているはず、という思い込みと、実際に更新が済んだことは、別である。この記事の中心は、この差を、1枚の一覧表で埋めることである。

03 この記事で出てくる用語

メンテナンスリリースとセキュリティリリース

7.1.1の告知の題名は、メンテナンス（不具合の修正）とセキュリティの両方を含んでいる。7.1.2の告知の題名は、「Release」だけで、本文でセキュリティリリースと説明している。題名だけで判断せず、本文のセキュリティの記述まで読むのがよい。

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

管理画面を開かなくても、WordPressが自分で更新を行う仕組みである。公式の文書は、WordPress 5.6より前は、すべてのサイトで、小さな更新（マイナーリリース）と翻訳ファイルだけが、既定で自動更新の対象だったと書いている。

"new installations have automatic updates enabled for both minor and major core releases by default, unless WordPress detects a version control checkout."

（訳: 新規インストールでは、WordPressがバージョン管理のチェックアウトを検出した場合を除いて、小さなコアの更新と大きなコアの更新の両方が、既定で自動更新の対象になります。）

この文は、「5.6以降の新規インストール」の話である。それより前から使っているサイトは、設定が違う場合がある。自分のサイトが、どちら側なのかは、画面で確かめるまで分からない。

プラグインとテーマの自動更新

コアの自動更新とは別に、プラグインとテーマにも、1つずつ自動更新を入れる機能がある。公式の文書は、WordPress 5.5から、管理者が、テーマ単位・プラグイン単位で、自分で選んで有効にできると書いている。つまり、こちらは、有効にしなければ、動かない。

サイトヘルス

管理画面の「ツール」の中にある、サイトの健康状態を見る画面である。公式の文書では、「Status」（状態）と「Info」（情報）の2つのタブがあり、「Status」には、重要な問題・改善の推奨・合格した項目が出ると説明されている。管理画面の言語が日本語なら、表示の名前は変わる場合がある。

WP-Cron

WordPressの、定時に何かを実行する仕組みである。公式の開発者向け文書は、仕組みを次のように説明している。

"WP-Cron does not run constantly as the system cron does; it is only triggered on page load."

（訳: WP-Cronは、サーバー本体の定時実行のように、常に動いているわけではありません。ページが読み込まれたときにだけ動きます。）

プラグインとテーマの自動更新は、この仕組みに頼っている。アクセスの少ないサイトでは、予定の時刻より遅れて動く可能性がある。

04 型別 — 適用範囲・この記事が確かめていないこと・手順

適用範囲 — この記事が向いているサイトと、向いていないサイト

向いているのは、WordPressで作られた、1つ以上のサイトを、自分で、または管理会社を通じて預かっている人である。複数のサイトを預かるほど、一覧表の効果が出る。

この記事が確かめていないこと

7.1.1と7.1.2の、個々の修正の中身は確かめていない。修正が、どのプラグインや設定のサイトに影響するかも、確かめていない。ホスティング会社が、独自に更新を代行している場合の動きも、確かめていない。この記事は、更新が出たと知った日に、自分の手で確かめることを整理したものであって、サイトが安全だと判断する材料ではない。

手順の流れは4つに分かれる

手順は、4つに分かれる。集めるのは、担当サイトを1行ずつ書き出す作業である。確かめるのは、各サイトの版・自動更新・プラグイン・バックアップを見る作業である。並べるのは、結果を1枚の表にする作業である。決めるのは、更新の順番と、更新する人を決める作業である。

自動更新の状態を、3か所で確かめる

コアの自動更新の設定は、サイトの設定ファイル（wp-config）に書かれる場合がある。公式の開発者向け文書は、次の3つの値を挙げている。

• WP_AUTO_UPDATE_CORE が true：開発版・マイナー・メジャーの更新が、すべて有効になる。
• WP_AUTO_UPDATE_CORE が false：開発版・マイナー・メジャーの更新が、すべて無効になる。
• WP_AUTO_UPDATE_CORE が minor：マイナーの更新だけが有効になり、開発版とメジャーは無効になる。

自動更新をすべて止める設定として、AUTOMATIC_UPDATER_DISABLED を true にする書き方も、同じ文書に載っている。この設定ファイルに、これらの定数が書かれていなければ、既定の動きになる。自分で設定ファイルを開けない場合は、管理会社に、「この2つの設定が書かれているか」を聞けば足りる。

管理画面では、ダッシュボードの「更新」の画面が、更新を始める入口である。公式の「Updating WordPress」（訳: WordPressの更新）は、更新の方法を、次のように書いている。

"You can launch the update by clicking the link in the new version banner (if it's there) or by going to the Dashboard > Updates screen."

（訳: 新しい版の知らせの表示（出ている場合）のリンクを押すか、ダッシュボードの「更新」画面を開くことで、更新を始められます。）

この「更新」の画面には、利用者が切り替えられる自動更新の設定がある。公式の文書は、設定ファイルの定数との関係を、次のように書いている。

"When set, the constant overrides the user-controllable automatic update setting provided on the Updates screen in wp-admin."

（訳: 定数が設定されている場合、その定数は、管理画面（wp-admin）の「更新」画面で提供されている、利用者が操作できる自動更新の設定よりも優先されます。）

つまり、設定ファイルに定数が書かれているサイトでは、更新の画面の設定と、実際の動きが食い違う場合がある。画面のどの位置に出るかは、2026年10月4日に開いた公式の文書の範囲では、書かれていなかった。プラグインとテーマの自動更新については、次の自動更新までの時間が、この画面に出ると、公式の文書が書いている。3か所目の確認として、サイトヘルスの「重要な問題」に出る「Background updates are not working as expected.」（訳: バックグラウンドの更新が、期待どおりに動いていません。）の有無を見る。設定ファイルの値・更新の画面・サイトヘルスの3か所を見て、食い違いがないかを確かめる。

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

まず13項目を通して見る

以下は、明日、担当サイトの管理画面を開いて、1枚の一覧表を作るための項目である。チェックの状態はブラウザに保存され、サーバーには送信されない。1〜3番目が表の準備、4〜9番目が各サイトで版と自動更新と不要なものを見る作業、10〜11番目がバックアップを見る作業、12〜13番目が更新の担当と順番を決める作業である。担当サイトが1つだけなら、1行だけの表で同じ手順を進める。

• 担当しているWordPressのサイトを、すべて書き出し、サイト名・URL・管理者の名前を、1行1サイトで表にする
• 表に「版」「自動更新」「古いプラグイン数」「止めているプラグイン数」「最後のバックアップ日」「更新の担当」の6つの列を足す
• 公式ニュースのリリース一覧を開き、いちばん新しい版の数字を、表の上に1行で書く
• 1つ目のサイトの管理画面で、ダッシュボードの更新の画面を開き、WordPressの版の数字を、表の「版」の列に書き写す
• 残りのサイトも同じ方法で、版の数字を、表の「版」の列に書き写す
• 表の版を、公式ニュースの最新の版と見比べ、同じでないサイトの行に印を付けて、その数を数える
• 各サイトのコアの自動更新が、有効か、無効か、分からないかを、管理会社への確認か、更新の通知メールで確かめ、3つのうち1つを表に書く
• 各サイトのプラグインの一覧を開き、更新が出ているプラグインの数と、止めているプラグインの数を数えて、表に書く
• 各サイトで、サイトヘルスの「重要な問題」の件数を数え、1件以上あるサイトの行に、問題の題名を1行で書く
• 各サイトで、最後にバックアップを取った日を、バックアップの画面で確かめ、表の「最後のバックアップ日」に書く
• 最後のバックアップに、データベースとファイルの両方が入っているかを確かめ、入っていないサイトの行に印を付ける
• 各サイトの更新の知らせを受け取る担当者の名前と連絡先を、1行ずつ表に書く
• 印が付いたサイトの中から、更新を急ぐ順に3つを選び、更新する日を決めて、表の上に書く

観点別の内訳と、かかる時間

すべてに目を通す時間は、担当サイトが5つなら、あわせて70分ほどである（筆者の見積もりで、担当サイトの数やログインの手間で変わる）。内訳は、1〜3番目が10分、4〜11番目が1サイトあたり10分（5サイトで50分）、12〜13番目が10分である。4〜11番目は50分かかるので、この部分だけは、2回に分けてもよい。

5分で終わらない項目があったとき

管理画面にログインできないサイトがあるときは、そのサイトの行に「ログイン不可」と書いて、飛ばしてよい。確かめられなかったことを、確かめられなかったと書いておくことが、表の役目である。

06 代替・他の選択肢（表で）

更新を、誰が、どう行うか — 3つの運用の形

更新の運用には、いくつかの形がある。どれが良いかは、サイトの数と、更新後の確認にかけられる人手による。表の「よい点」と「気をつける点」は、公式が勧めている順番や評価ではなく、筆者の整理である。

この表から言えるのは、どの形でも、「自分のサイトの版を、自分で見て確かめる手段」が1つは必要なことである。4つ目の道具は、「そういう種類の道具がある」という紹介であって、優劣をつけるものではない（次の節）。任せる場合でも、版の数字を、月に1回は自分の目で確かめるとよい。

WordPress以外のCMSの場合 — 公式の告知の場所を、1つずつ控える

担当サイトのすべてがWordPressとは限らない。ほかのCMSにも、セキュリティの公式の告知の場所がある。2026年10月4日に開いて確かめた範囲では、次のとおりである。

• Drupal：「Security advisories | Drupal.org」（訳: セキュリティ勧告）のページがある。ページは、Drupalの本体と、追加の部品（contributed projects）の脆弱性についての告知を並べ、メール（ログインしてニュースレターを購読）、RSS（本体・追加の部品・公共の案内の3種類）で受け取れると書いている。
• Joomla：「Security Announcements」（訳: セキュリティの告知）のページがある。ページは、Joomlaのリリースで解決したセキュリティの問題の告知を載せ、「Vulnerable Extensions List」（訳: 脆弱性のある拡張機能の一覧）も案内している。告知は、RSSリーダーで購読できる。

この記事の範囲では、DrupalとJoomlaの告知のページを開いて、上の点を確かめた。それぞれのCMSの版の数字や、更新の手順は、確かめていない。使っているCMSの公式の告知の場所を、一覧表の列に1つずつ控えておくと、更新が出た日に探す時間が減る。

複数サイトの更新をまとめて見る道具もある

WordPressのサイトを多く預かる場合に、複数のサイトの状態を、1つの画面にまとめて見る道具がある。たとえば、ManageWPの公式ページには、「Effortlessly monitor and maintain all your WordPress websites from a single, user-friendly dashboard.」（訳: すべてのWordPressサイトを、使いやすい1つの画面から、手間なく監視し、保守できます。）と書かれている。MainWPの公式ページには、「Run updates, backups, security and reporting across all client sites from your own server.」（訳: 更新・バックアップ・セキュリティ・報告を、自分のサーバーから、すべての顧客サイトに対して実行できます。）と書かれている（自分のサーバーで動かす形と説明されている）。

この記事は、そういう種類の道具がある、と紹介するところまでであり、どれが良いか、安全かは書いていない。使う場合は、道具の公式の説明で、見られる範囲と必要な権限を確かめてほしい。

プラグインとテーマの自動更新は、別に決める

コアの自動更新を入れていても、プラグインとテーマの自動更新は、別の設定である。公式の文書は、プラグインとテーマの自動更新を入れる前に、問題が起きたときに戻せる状態にしておくことを勧めている。

"Before enabling auto-updates on your plugins and themes, you may want to make sure you're able to rollback to a previous version of your website in case things go wrong."

（訳: プラグインとテーマの自動更新を有効にする前に、問題が起きたときに、サイトを以前の状態に戻せることを確かめておくとよいでしょう。）

バックアップは、データベースとファイルの両方

公式のバックアップの文書は、バックアップの対象を、2つに分けている。

"There are two parts to backing up your WordPress site: Database and Files. You need both to be able to fully restore a typical WordPress site."

（訳: WordPressサイトのバックアップには、2つの部分があります。データベースと、ファイルです。ふつうのWordPressサイトを完全に復元するには、両方が必要です。）

頻度についても、書かれている。更新の少ない小さなサイトでは週に1回、投稿の多いサイトでは毎日、という目安である。さらに、自動のバックアップについて、ときどき手動でも取って、仕組みが動いているかを確かめるよう勧めている。バックアップは、取っていることよりも、戻せることが大事である。

使っていないプラグインとテーマは、減らす

サイトヘルスの文書は、使っていないテーマについて、使う予定がなければ削除を勧めている。「WordPress Housekeeping」も、古いプラグインや不要なプラグインを削除する手順を載せている。使っていないものは、更新の対象が増えるだけで、役に立たない。更新の数を減らす一番簡単な方法は、使っていないものを消すことである。消す前には、バックアップを取っておく。

07 一覧表を、運用に落とす — 頻度・担当・戻し方

一覧表の見本

05章の表は、次のような形になる。下の図は、見本であって、実在のサイトの数字ではない。

更新の前に取るバックアップの作法

公式の「Upgrading WordPress」（訳: WordPressのアップグレード）の文書は、更新の前の準備として、バックアップを挙げている。

"Before you get started, it's a good idea to back up your website. This means if there are any issues you can restore your website."

（訳: 始める前に、サイトのバックアップを取っておくのがよいでしょう。そうすれば、問題があったときに、サイトを復元できます。）

自動更新に任せているサイトでも、バックアップが、更新の前に取られているかは、別の話である。最後のバックアップの日付が、最後の更新の日より古くなっていないかを、表で見比べる。

バックアップの手順 — 取る対象・保存先・戻す練習

公式のバックアップの文書の範囲で、手順にすると、次の3つになる。

1. 取る対象を2つにする。データベースとファイルの両方である。公式の文書は、ファイルだけのバックアップでは、データベースは入らない、と書いている。
2. 保存先を分ける。公式の文書は、保存先を分ける例を、次の引用のように挙げている。
3. 戻す練習を、1回する。公式の文書は、戻す順番と、自動のバックアップを確かめる勧めを書いている（下の引用と、続く段落）。

"You should keep at least 3–5 recent WordPress backups to stay safe from data loss, with copies stored in different locations — for example, one on your hosting server, one on cloud storage (Google Drive, Dropbox, etc.), and one downloaded to your local computer."

（訳: データの喪失を防ぐために、最近のWordPressのバックアップを、少なくとも3〜5個は持ち、コピーを別々の場所に保存してください。たとえば、ホスティングのサーバーに1つ、クラウドの保存先（Google Drive、Dropboxなど）に1つ、手元のパソコンにダウンロードして1つ、です。）

1か所だけに置くと、その場所が使えなくなった日に、戻せなくなる。

"Restore the WordPress files first, then restore/import the database."

（訳: 先にWordPressのファイルを復元し、そのあとでデータベースを復元（読み込み）してください。）

文書は、移行でデータベースの接続情報を変えた場合は、設定ファイルを合わせるよう書いている。戻す練習を、本番のサイトではなく、別の場所（確認用の環境）で行うことは、公式の文書には書かれていなかったので、筆者の提案である。自動のバックアップについては、文書が、ときどき手動でも取って、仕組みが動いているかを確かめるよう勧めている。

08 このテーマの、これまで

2026年8月からのリリースの流れ

8月6日の7.0.3（セキュリティリリース）、8月12日の7.0.4（1件の脆弱性への対応）、8月19日の7.1（機能追加）、9月17日の7.1.1、9月22日の7.1.2と、2か月足らずの間に、5つの版が出た。この流れは、2026年10月4日に、公式ニュースのリリース一覧で確かめた範囲の話である。それぞれの版の中身は、各告知の本文を読んでほしい。

当サイトの過去の記事 — 通知の数を数える話と、点検の話

当サイトのブログには、「通知や警告の数を、どう読むか」を書いた記事がいくつかある。Search Console の通知 65 件のうち 33 件が未読だった ── 「修正を検証」を押さなかった理由と、毎週の点検にした日は、通知を放置せず、毎週の点検に変えた話である。毎朝の「警告1,415件」を、初めて種類別に数えた ── 96.7%は見なくていいもので、唯一の「本物」は自分で叩くまで分からなかったと、警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かったは、警告の数を、種類別に数え直した話である。

「1本だけ書き方が違う」と指摘された ── 91本で数え直したら、標準だったのはその1本のほうだったは、数え直さないと、どれが標準か分からなかった話である。「リンク切れ0本」も「200が返る」も、まだ2段目だった ── 番号が変わるサイトで見つけた、リンクの3段目のずれは、確かめた範囲が、見えている範囲より狭かった話である。今回の「版を1枚の表に並べる」手順は、これらと同じ考え方である。