WEBサイトWordPress 7.2は12月8日に出る予定で、ベータは10月20日に始まる ── 日程の各日付に試験環境でやることを割り当てる13項目（2026年10月時点）
WordPress 7.2は12月8日に出る予定で、ベータは10月20日に始まる ── 日程の各日付に試験環境でやることを割り当てる13項目（2026年10月時点）
目次
01 何が起きたか — WordPress 7.2は12月8日に出る予定で、日程の案が10月6日に公表された
2026年10月6日に公表された日程
WordPressの開発ブログ（Make WordPress Core）に、2026年10月6日付で「WordPress 7.2 Release Party Schedule」（訳: WordPress 7.2のリリースパーティーの日程）が載った。2026年10月9日に本文を開いて確かめた。投稿の最初の文は、次のとおりである。
"WordPress 7.2 is scheduled for release on December 8, 2026!"
（訳: WordPress 7.2は、2026年12月8日に公開される予定である。）
リリースパーティーは、公式の投稿によると、Slackの#coreチャンネルで開かれる集まりで、公開の前の最後の数週間に、試験に参加して手伝う場である。この記事は、その集まりの話ではなく、表に並んだ9つの日付を、自社のサイトの作業に割り当てることを扱う。
日程は「案」で、直前に変わりうる
投稿は、日程の表を「proposed calendar」（訳: 案の日程）と呼んでいる。変更の可能性についても、次のように書いている。
"As always, there may be last-minute adjustments."
（訳: いつものとおり、直前の調整があるかもしれない。）
変更があった場合の知らせ方も、書かれている。
"The release squad will do its best to communicate any changes promptly by publishing a post on the change, and updating this post as the canonical reference."
（訳: リリースの担当チームは、変更を速やかに知らせるために最善を尽くす。変更についての投稿を出し、この投稿を正本として更新する。）
つまり、日付は決まった約束ではなく、この投稿が更新されるかを、自分で見に行く必要がある。見に行く日は、05章の項目に入れた。
9つの日付を、日本時間に直す
表の日付と時刻は、すべてUTC（協定世界時）で書かれている。日本時間はUTCより9時間進んでいるので、9つとも「15時00分UTC」は、日本では翌日の午前0時00分になる。下の表は、公式の日付を左に、日本時間への換算を真ん中に置いた。
| 公式の日付と時刻（UTC） | 日本時間 | 公式のマイルストーン名 |
|---|---|---|
| 2026年10月20日（火）15:00 | 10月21日（水）0:00 | Beta 1（ベータ1） |
| 2026年10月27日（火）15:00 | 10月28日（水）0:00 | Beta 2（ベータ2） |
| 2026年11月3日（火）15:00 | 11月4日（水）0:00 | Beta 3（ベータ3） |
| 2026年11月10日（火）15:00 | 11月11日（水）0:00 | Beta 4（ベータ4） |
| 2026年11月17日（火）15:00 | 11月18日（水）0:00 | RC 1（リリース候補1） |
| 2026年11月24日（火）15:00 | 11月25日（水）0:00 | RC 2（リリース候補2） |
| 2026年12月1日（火）15:00 | 12月2日（水）0:00 | RC 3（リリース候補3） |
| 2026年12月7日（月）15:00 | 12月8日（火）0:00 | Dry Run / 24-Hour Code Freeze（予行演習と、24時間のコードの凍結） |
| 2026年12月8日（火）15:00 | 12月9日（水）0:00 | General Release（一般公開） |
公式の「12月8日」は、日本では12月9日の午前0時にあたる。日本時間の12月8日の朝に画面を見ても、一般公開はまだ始まっていない。
02 なぜ・背景 — 7.1の修正版の続きに、次の大きな版が来る
7.1のあとに出た、3回の修正版
WordPress.orgのリリースの一覧を2026年10月9日に開くと、7.1の系列は、7.1が8月19日、7.1.1が9月17日、7.1.2が9月22日、7.1.3が10月6日に出ている。7.1.1と7.1.2は、当サイトの記事「WordPressは5日の間に、セキュリティ更新が2回出た ── 担当サイトの版・自動更新・バックアップを一覧で確かめる13項目（2026年10月時点）」で、7.1.3は「WordPress 7.1.3の7件の修正は、それぞれ別の機能に当たる ── 自社のWordPressで使っている機能と突き合わせて確かめる13項目（2026年10月時点）」で扱った。この記事は、それらの内容を書き直さない。
大きな版の周期は、およそ4か月とされている
WordPressの開発の手引きは、大きな版の周期を、次のように書いている。
"A release cycle usually lasts around 4 months, from the initial scoping meeting to the launch of the version."
（訳: 1回のリリースの周期は、通常、最初の範囲を決める会議から、その版の公開までで、およそ4か月かかる。）
7.1が出た8月19日から、7.2の予定の12月8日までは、数えると111日である。08章に、6.9から7.2までの間隔を並べた。
ベータとリリース候補は、何が止まる段階か
同じ手引きは、ベータの段階について、次のように書いている。
"No more commits for new enhancements or feature requests are allowed for the rest of the release."
（訳: この版の残りの期間は、新しい機能の追加や要望のためのコミットは、これ以上受け付けられない。）
リリース候補の段階については、次の1文がある。
"There is a string freeze from this point on."
（訳: この時点から、文字列の凍結が始まる。）
手引きは、この段階の作業を、この版の開発中に入った不具合（リグレッション）に絞る、とも書いている。つまり、ベータの時点で機能の中身はほぼ決まっている。試験で見つけた問題を伝える時期として、早いほど直る機会が多い、と読める。これは手引きの文からの筆者の読みであり、手引きがそう書いているわけではない。
年末は、更新の日取りが自由にならない
12月8日から12月31日までは、23日しかない。年末年始の休業や、キャンペーンの公開を決めている担当サイトでは、更新を入れられる日が、そもそも少ない。この記事が日程を日付ごとの作業に割り当てるのは、そのためである。
03 用語 — 読み違えやすい言葉を先にそろえる
ベータとリリース候補（RC）
公式の用語集は、リリース候補を、次のように説明している。
"One of the final stages in the version release cycle, this version signals the potential to be a final release to the public."
（訳: 版のリリースの周期の最後の段階の1つで、この版は、一般公開の最終版になりうることを示す。）
ベータは、その前の段階である。公式の用語集の説明を要約すると、公開の前の版を、多くの利用者に実際の条件で試してもらう段階である。表の日付で言えば、ベータが4回、リリース候補が3回ある。
UTCと日本時間
UTCは、世界で共通の基準の時刻である。日本時間は、UTCに9時間を足した時刻である。公式の日程は、すべてUTCの15時00分なので、日本時間では9回とも翌日の0時00分になる。日付を手で足し算するときに、1日ずれやすい。
用語
試験環境は、本番のサイトとは別に用意した、更新を先に試すための複製である。本番のデータをそのまま入れると、問い合わせの控えなどの個人の情報が入るため、取り扱いは担当者の決まりに従う。この記事では、試験環境と書く。
予行演習と、コードの凍結
12月7日の行の名前「Dry Run / 24-Hour Code Freeze」の意味は、日程の投稿には書かれていない。名前のとおり、公開の前の予行演習と、24時間のコードの凍結と読んだが、確かめてはいない。この記事では、新しい試験をしない日として扱う。
大きな版（メジャー）と修正版（マイナー）
公式の用語集は、先頭の2つの数字で表す版を大きな版と呼び、「3.6」を例にしている。7.2は大きな版で、7.1.3は修正版である。大きな版には新しい機能が入り、修正版には、不具合の修正やセキュリティの修正が入る、というのが、公式の用語集の説明を要約した形である。
04 型別 — 9つの日付に、試験環境でやることを割り当てる
🅰 適用範囲 — WordPressで動いているサイトが対象
この記事の対象は、WordPressで動いているサイトである。ほかのCMSや、自作のサイトには、7.2の日程は関係ない。ただし、公式の日付をUTCのまま日本時間に直し、各日付に作業を割り当てるという考え方は、ほかのソフトの更新にも使える。
🅱 この記事が確かめていないこと
注意
この記事は、7.2の新しい機能や変更点を読んでいない。公式の要件のページは、2026年10月9日の時点で、PHP 8.3以上を推奨と書いている。だが、7.2でその要件が変わるかは、確かめていない。プラグインやテーマが7.2に対応するかも、サイトごとに違うため、書いていない。
🅲 手順1 — 日程を自分の暦に移す
表の9つの日付を、日本時間に直して、自分の暦に入れる。全部を入れる必要はない。ベータ1（10月21日）・リリース候補1（11月18日）・予行演習の日（12月8日）・一般公開（12月9日）の4つは、必ず入れる。それぞれの3日前に、公式の日程の投稿をもう一度開く予定も、別に入れる。投稿が更新されたかを確かめるためである。
🅲 手順2 — 今の版と環境を書き出す
管理画面のダッシュボードの「更新」の画面で、今のWordPressの版を書く。サイトヘルスの「情報」の画面で、PHPとデータベースの版を書く。公式の要件のページは、ホスティングが対応していることを推奨する環境を、次のように並べている。
"PHP version 8.3 or greater."
（訳: PHPの版は8.3以上。）
"MariaDB version 10.11 or greater OR MySQL version 8.0 or greater."
（訳: MariaDBの版は10.11以上、またはMySQLの版は8.0以上。）
古い環境については、次のように書いている。
"However, these versions have reached their official End Of Life and may expose your site to security vulnerabilities."
（訳: ただし、これらの版は公式の提供の終了に達しており、サイトをセキュリティの弱点にさらすことがある。）
この「these versions」は、直前の文にある「PHP 7.4+」と「MySQL 5.5.5+」を指している。PHPの版が8.3より古いサイトは、7.2を試す前に、PHPの移行の予定を立てる必要が出るかもしれない。7.2が最低でも何を求めるかは、公式の発表を待つことになる。
🅲 手順3 — バックアップを取り、実際に戻してみる
バックアップについて、公式の手引きは、次のように書いている。
"Back up your database regularly, and always before an upgrade."
（訳: データベースを定期的にバックアップし、アップグレードの前には必ず取る。）
取るだけでは足りない。アップグレードの手引きは、取ったバックアップが使えるかを確かめることを、次のように求めている。
"Verify the backups you created are there and usable. This is essential."
（訳: 作ったバックアップが存在し、使えることを確かめる。これは不可欠である。）
戻し方の順番は、バックアップの手引きに書かれている。ファイルを先に戻し、そのあとにデータベースを取り込む、という順である。
"Restore the WordPress files first, then restore/import the database."
（訳: WordPressのファイルを先に戻し、そのあとでデータベースを戻す（取り込む）。）
戻せないバックアップの怖さは、アップグレードの手引きの、巻き戻しについての文に出ている。
"Please note, that without a backup of your entire site and your database, made prior to your upgrade attempt, a successful rollback is near impossible."
（訳: 注意してほしい。アップグレードを試みる前に取った、サイト全体とデータベースのバックアップが無ければ、巻き戻しを成功させることは、ほぼ不可能である。）
本番のデータベースを書き換える作業の監査の規律は、当サイトの記事「本番DBを1秒で書き換えた日 — WEBディレクターが本番DB恐怖から解放される「8点セット」監査規律」で扱った。この記事では、バックアップを試験環境に戻して、トップページとログイン画面が開くかを見るところまでを、手順とする。
🅲 手順4 — ベータを試験環境で試す
ベータやリリース候補を試すための、公式のプラグインがある。WordPress.orgのプラグインの説明は、次のように書いている。
"This plugin provides an easy way to get involved with beta testing WordPress."
（訳: このプラグインは、WordPressのベータの試験に参加する、簡単な方法を提供する。）
同じ説明は、始める前の注意も書いている。
"Don’t forget to backup before you start!"
（訳: 始める前に、バックアップを取るのを忘れないように。）
開発の手引きの「Beta Testing」の章にも、「Backing up first is sensible.」（訳: 最初にバックアップを取るのが賢明である。）とある。使い方の概略は、プラグインを入れ、「Tools」の「Beta Testing」の画面で設定を選び、ダッシュボードの「更新」の画面から更新する、という流れである。設定には、修正版の夜間ビルドを追う選択肢と、不安定になりやすい最先端の夜間ビルドを追う選択肢と、ベータとリリース候補を追う選択肢がある。この選択は、本番ではなく試験環境だけで行う。これは、この記事の整理であり、公式がそう書いているわけではない。
実務のヒント
更新のたびに開くページを、先に5つ決めておく。例は、ホームページ・固定ページ1枚・記事1本・検索結果・問い合わせの送信画面である。更新のあとにこの5つを開くだけで、ベータ1からリリース候補3までの6回の更新を、同じ物差しで見比べられる。
🅲 手順5 — リリース候補で確かめ、公開の後に上げる日を決める
リリース候補の3回は、公開される版に近い形である、という位置づけである。11月18日・11月25日・12月2日の更新のたびに、手順4の5ページを開き、問題が見つかったページを、ページの名前と日付で書き残す。問題がプラグインやテーマに関わるなら、その提供元の問い合わせ先に、見つかった内容を伝える。
公開のあとは、すぐに上げるか、待つかを決める。公式の手引きは、大きな版の公開のすぐあとに修正版が続くことが多い、と書いている（Make WordPress Coreの手引き「How the Release Cycle Works」）。修正版を待つ選択もありうるが、待つ間は、前の版の最新の修正版にとどまることになる。7.1系列の最新は、10月9日の時点で7.1.3である。
| 日本時間 | 公式の名前 | 試験環境でやること |
|---|---|---|
| 10月21日（水） | ベータ1 | 試験環境をPHPとデータベースの版まで本番にそろえ、ベータ1に上げて、5ページを開く |
| 10月28日（水） | ベータ2 | ベータ2に上げ、5ページを開く。ベータ1と違って見えたページを書く |
| 11月4日（水） | ベータ3 | ベータ3に上げ、5ページを開く。有効なプラグインの更新の知らせを数える |
| 11月11日（水） | ベータ4 | ベータ4に上げ、5ページを開く。問題があれば、提供元に伝える下書きを作る |
| 11月18日（水） | リリース候補1 | リリース候補1に上げ、5ページと、問い合わせの送信までを通す |
| 11月25日（水） | リリース候補2 | リリース候補2に上げ、5ページと、問い合わせの送信までを通す |
| 12月2日（水） | リリース候補3 | リリース候補3に上げ、5ページを開く。本番を上げる日の案を書く |
| 12月8日（火） | 予行演習・コードの凍結 | 新しい試験はしない。本番のバックアップを1組取り直す |
| 12月9日（水） | 一般公開 | すぐに本番を上げず、公式の発表と、プラグインの提供元の知らせを読んで、上げる日を決める |
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。項目1〜2が手順1、項目3〜4が手順2、項目5〜6が手順3、項目7〜10が手順4、項目11〜13が手順5と、自動更新の扱いに対応している。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- 公式の日程の投稿を開き、ベータ1と一般公開の日付と時刻を、UTCのままメモに書き、その隣に日本時間に直した値（10月21日の0時と、12月9日の0時）を書く
- ベータ1・リリース候補1・予行演習・一般公開の4つの日本時間を、暦に登録し、それぞれの3日前に日程の投稿を開き直す予定を、4つ登録する
- 管理画面のダッシュボードの「更新」の画面を開き、いまのWordPressの版の数字を、そのままメモに書く（7.1.3なら「7.1.3」と書く）
- サイトヘルスの「情報」の画面を開き、PHPとデータベースの版を書いて、公式の要件の「PHP 8.3以上」「MariaDB 10.11以上またはMySQL 8.0以上」と並べ、満たすかを「満たす」か「満たさない」で書く
- データベースとファイルのバックアップを1組取り、取った日時と置き場所をメモに書く
- そのバックアップを試験環境に戻し、ホームページとログイン画面が開くかを「開く」か「開かない」で書き、戻すのにかかった時間を分で書く
- 試験環境のサイトヘルスの「情報」の画面を開き、PHPとデータベースの版が本番と同じかを「同じ」か「違う」で書く
- 更新のあとに開く5ページ（ホームページ・固定ページ1枚・記事1本・検索結果・問い合わせの送信画面）のURLを、メモに書く
- 10月21日以降に、試験環境へベータ用のプラグインを入れ、ベータ1に上げて、項目8の5ページを開き、エラーの表示があるページの数を書く
- 試験環境のプラグインの画面で、自動更新が有効のものと、そうでないものの数を、それぞれ数えて書く
- 11月18日以降に、試験環境をリリース候補1に上げ、項目8の5ページに加えて、問い合わせの送信を1回通し、通ったかを「通った」か「通らなかった」で書く
- 本番の更新画面で、自動更新の表示を開き、主要なバージョンの自動更新が「有効」か「無効」かを書いて、担当者に設定の根拠を聞く
- 12月の公開の予定と、年末年始の休業の日を書き出し、本番を上げられる日を3つ選んで、日付で書く
時間が限られているときは、項目1・5・6・13の4つだけでも、「日程を日本時間で知っているか」「戻せるバックアップがあるか」「実際に戻せるか」「本番を上げられる日があるか」は分かる。
06 代替・他の選択肢 — 試験環境が無いときと、自動更新に任せるとき
試験環境を持てないとき
試験環境を作れない場合は、バックアップを別の場所に戻して、ホームページが開くかだけを見る方法がある。ただし、これは、ベータを試すことの代わりにはならない。サーバー会社に、試験用の環境を用意する機能があるかを、先に聞いておく。
自動更新に任せるとき
大きな版の自動更新の扱いは、公式の説明が2つに分かれて見える。アップグレードの手引き（2026年7月1日更新）は、次のように書いている。
"Existing installations receive minor core updates by default."
（訳: 既存のインストールは、既定で、小さな版（マイナー）のコアの更新を受け取る。）
"Fresh installations created on WordPress 5.6 or later receive both minor and major core updates by default, unless WordPress detects a version control checkout."
（訳: WordPress 5.6以降で新しく作られたインストールは、既定で、小さな版と大きな版の両方のコアの更新を受け取る。ただし、WordPressがバージョン管理のチェックアウトを検出した場合を除く。）
一方、「Updating WordPress」の説明（2024年9月15日更新）には、次の文がある。
"You’ll still need to click “Update Now” for major feature releases."
（訳: 大きな機能の版では、それでも「今すぐ更新」を押す必要がある。）
2つの説明は、新しさも、対象の範囲も違う。どちらが自分のサイトに当たるかは、サイトの作られた時期と、設定ファイルや更新画面の設定で決まる。そこで、項目12で、自分のサイトの表示を見る。アップグレードの手引きには、設定ファイルで大きな版の自動更新を有効にする定数（WP_AUTO_UPDATE_CORE）や、すべての自動更新を止める定数（AUTOMATIC_UPDATER_DISABLED）の説明がある。後者は、手引きが「強く勧めない」と書いている。
注意
大きな版の自動更新が有効なサイトでは、一般公開のあと、本人が手を動かさなくても7.2に上がることがある。公式の説明は、いつ届くかを書いていない。この記事は、届く日を推測しない。担当者に聞いて、自動更新を一時的に止めるかを決める。
7.2を見送り、7.1の系列にとどまるとき
WordPress.orgのリリースの一覧には、次の1文がある。
"Only the most recent in the 7.1 series is safe to use and actively maintained."
（訳: 7.1の系列で、使うのに安全で、積極的に保守されているのは、最新のものだけである。）
10月6日には、7.1.3のほかに、7.0.7と6.9.10も出ている（一覧の日付による）。見送る場合も、7.1の最新の修正版にとどまり続ける必要がある。
プラグインの自動更新は、別の設定
プラグインの自動更新は、WordPress 5.5から、プラグインの画面で1つずつ有効にできる、と公式の説明にある。本体が7.2に上がった日の前後で、プラグインの自動更新が動くと、本体とプラグインの両方が同じ週に変わることがある。項目10で、有効な数を数える。
画面の見た目を更新の前後で比べる、当サイトの無料ツール
更新の前後の画面を並べたいときは、当サイトの無料ツール🔧 WEBサイトのスクリーンショット、まとめて撮っちゃおツールと、🔧 WEBページのスクリーンショット、表示デバイスの比較をまとめて撮っちゃおツールが使える。リンクの抜けを見るなら、🔧 WEBサイト内のリンク漏れ・チェックツールがある。ただし、自動のスクリーンショットは、読む人の画面と違って写ることがある。その3つの違いは、当サイトの記事「「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数）」で書いた。
更新のあとに、ページが「200」で返っても、中身が正しいとは限らない。その例は、当サイトの記事「24時間越しに自分を捕まえた日 — 「HTTP 200」が嘘をついた配置ミスと、テンプレート1行で1153記事を直した話」にある。「何も起きていない」ように見える状態の危うさは、「"何も起きていない"は、本当に安全か — WEB運営で見逃される「沈黙のリスク」」で扱った。
07 当サイトで確かめたこと
当サイトは、WordPressではない
当サイトはWordPressで動いていない。そのため、「当サイトで7.2のベータを試した」とは書けないし、書かない。代わりに、この記事の手順1（日本時間への換算）を使い、公式の日程の投稿そのものを数えて、書いたことの根拠にした。
日程の投稿の中身を、数えた
2026年10月9日に、日程の投稿の本文を文字にして、次の3つを数えた。日付と時刻の形（「2026 at 15:00 UTC」の形）は9件で、表の9行と一致した。「TBA」（訳: 未定）の語は36件で、9行に、担当者の4つの欄（司会兼リリースの責任者・コミッター・セキュリティ・全体の調整）を掛けた数と合う。「proposed」（訳: 案の）の語は1件だった。日本時間への換算と曜日は、プログラムで日付の計算をして確かめた。
この結果から言えることと、言えないこと
言えるのは、10月9日の時点で、日程の表の担当者の欄は、すべて「未定」だったことである。日付は決まっていても、担当の割り当ては決まっていない。言えないのは、ベータ1が10月20日に実際に出るか、12月8日の公開が守られるか、である。それは、公式の投稿が更新されるかを、日付が来るたびに見るしかない。
08 このテーマの、これまで
大きな版の間隔
WordPress.orgのリリースの一覧の日付から、6.9以降の大きな版の間隔を数えた。7.2は予定の日付で数えている。
| 版 | 公開日 | 前の大きな版からの日数 |
|---|---|---|
| 6.9 | 2025年12月2日 | — |
| 7.0 | 2026年5月20日 | 169日 |
| 7.1 | 2026年8月19日 | 91日 |
| 7.2（予定） | 2026年12月8日 | 111日 |
間隔は一定ではない。公式の手引きの「およそ4か月」（約120日。この記事の計算）と比べると、6.9から7.0までは169日と長く、7.0から7.1までは91日と短い。7.1から7.2までの予定の111日が、いちばん近い。次の周期の長さを、過去の間隔から予想しないほうがよい。
7.1の系列の、日付つきの記録
7.1の系列は、7.1が8月19日、7.1.1が9月17日、7.1.2が9月22日、7.1.3が10月6日である。7.1から7.1.3までは、48日である。
当サイトの、関連する過去の記事
- WordPressは5日の間に、セキュリティ更新が2回出た ── 担当サイトの版・自動更新・バックアップを一覧で確かめる13項目（2026年10月時点） — 7.1.1と7.1.2の内容と、版・自動更新・バックアップの確かめ方。
- WordPress 7.1.3の7件の修正は、それぞれ別の機能に当たる ── 自社のWordPressで使っている機能と突き合わせて確かめる13項目（2026年10月時点） — 7.1.3の7件の修正と、使っている機能の突き合わせ方。
- 本番DBを1秒で書き換えた日 — WEBディレクターが本番DB恐怖から解放される「8点セット」監査規律 — 本番のデータベースを書き換える前の、監査の規律。
- 「準備OK」と答えた瞬間、何が抜けているか — 自己認識ズレを機械で潰す3層検証 — 「準備OK」と答えたときに、何が抜けているかを機械で確かめる記事。
- 「リンク切れ0本」も「200が返る」も、まだ2段目だった ── 番号が変わるサイトで見つけた、リンクの3段目のずれ — リンク切れが0本でも、飛び先がずれていることがあるという記事。
現在の貴方のIPアドレス
このサイトで書いている人
