WordPress 7.2 Beta 1を試した｜12月公開予定の主な変更6つと、本番サイトを触らずに確かめる手順

2026年10月23日

WordPress 7.2 Beta 1が10月20日に公開され、正式版は12月8日の予定

WordPressの開発チームは2026年10月20日、次のバージョン7.2の最初の試験版「WordPress 7.2 Beta 1」を公開しました。公開されたスケジュールでは、正式版は12月8日15時（協定世界時）、日本時間では12月9日午前0時の予定です。試験版は動作確認のためのもので、公開中のサイトとは別の環境で使います。

この記事で扱う7.2の変更は、編集画面（7.1で入った画面幅ごとの設定の対象拡大、文字の影、投稿の設定パネル）、管理画面（ダッシュボードの表示、ナビゲーションメニューの編集、アイコンとJavaScript・CSSの読み込み方）、開発者向けの仕組み（Secrets API）の3つに分かれます。発表文には十数項目が並びますが、文章で読むだけでは、自分のサイトに関係する変更がどれか判断しにくいところがあります。

この記事では、Docker（自分のPCに、ほかと切り離した実行環境を作るツール）で作った検証用のWordPressを、WP-CLI（WordPressをコマンドで操作する公式ツール）で7.1.3から7.2 Beta 1へ更新し、主な変更6つを実際に操作して確かめました。前半は運営者に関係する変更を画面とともに、後半はプラグイン開発者向けのSecrets API、Beta 1で使えないもの、本番サイトに入れずに試す手順を説明します。

4つの要点

7.2は「画面幅ごとの設定がギャラリーにも広がった」ことと「秘密情報の暗号化保存」が大きな変更。Beta 1から正式版まで7週間あり、ブラウザだけでも試せる

正式版の予定

12月8日

日本時間では12月9日午前0時。Beta 2〜4とRC（リリース候補版）1〜3を毎週公開。今から試せば、自分のテーマやプラグインの問題を先に見つけられる。

検証で動いた主な変更6つ

1. ギャラリーの画面幅ごとの設定（7.1の機能を拡張）
2. 文字の影
3. 新しい投稿設定パネル
4. この日に公開した記事（Published On This Day）
5. サイトエディターでのナビゲーションメニュー編集
6. Secrets API（開発者向け）

Beta 1で使えないもの

新テーマIpsum

Beta 1の後、10月22日に開発版へ追加され、Beta 2以降で入る見込み。新しい項目の一部は英語のまま。秘密情報を扱う wp secret コマンド（WP-CLI）は本体に入らない。

試す方法

3つ

ブラウザだけのPlayground、ステージングにBeta Testerプラグイン、DockerとWP-CLI。どれも試験版を本番サイトに入れずに試せる。

7.1で入った画面幅ごとの設定が、7.2でギャラリーの列数にも広がった

WordPressでは7.1から、タブレットとスマートフォンの表示だけに別のスタイル（文字サイズ、色、背景、枠線、余白など）を持たせられるようになりました（7.1の開発者向けノート）。編集画面の「表示」メニューでタブレットかモバイルを選び、「レスポンシブスタイル」を有効にすると、その画面幅だけに効く値を設定できます。7.2ではこの「画面幅ごとの設定」が、より多くの設定とブロックに広がりました。発表文は例としてギャラリーの列数、切り抜き、縦横比を挙げ、テストガイドには高度な設定の「追加CSS」を画面幅ごとに書く手順もあります。この記事で確かめたのはギャラリーです。

違いは同じ投稿で確かめました。3枚の画像を入れたギャラリーを7.1.3で開き、タブレット表示で「レスポンシブスタイル」を有効にすると、設定パネルには「背景」「サイズ（ブロックの間隔）」「枠線・角丸」の項目だけが並び、列数（カラム）の項目はありませんでした。7.2 Beta 1へ更新して同じ操作をすると、設定パネルに「カラム」が加わりました。

7.2 Beta 1でタブレット用の列数を2にすると、デスクトップの値は3のまま残りました。保存された投稿の中身を読み出すと、タブレット用の値だけが次のように追加されていました。編集画面では、右上の︙メニューの「コードエディター」で同じ記述を見られます。

<!-- wp:gallery {"columns":3,"linkTo":"none","style":{"@tablet":{"columns":2}}} -->

公開した画面でも効き方を確かめました。幅700pxで表示すると、設定した投稿だけが2列になり、同じギャラリーで設定していない投稿は3列のままです。検証サイト（テーマはTwenty Twenty-Five）で、タブレット用の列数を1にした投稿の幅を変えて測ると、タブレット用の値は幅481〜782pxで使われ、480px以下では使われませんでした。480px以下はモバイルの範囲で、モバイル用の値を設定していない投稿は、ギャラリー標準の表示に戻ります。ギャラリーは標準で、幅600px未満では2列に並びます（検証サイトでの測定）。この境目は7.1からの既定値で、テーマの設定で変えられます。

タブレットだけ列を減らしたい、スマートフォンでは1列にしたい、といったこれまでテーマ側のCSSで直していた調整を、ギャラリーでも編集画面で済ませられるようになります。スマートフォンの表示を変えるときは、「表示」でモバイルを選んで同じ手順で設定します。

見出しに文字の影を付けられ、投稿の設定パネルも新しくなった

タイポグラフィの設定に「文字の影」が加わりました。見出しブロックを選び、設定パネルのタイポグラフィ欄の右上にある︙メニューから「Text shadow」を表示すると、プリセットの「Light」「Strong」から影を選べます。自分で色・ぼかし・位置を決めた影は、サイトエディターの「スタイル」で作ります（公式のテストガイドの手順）。Beta 1では「スタイル」→「タイポグラフィ」に、影のプリセットを並べる「Text shadow presets」の欄も加わっていました。Beta 1では、どちらの項目名も英語のままでした。

投稿の設定パネル（右側の「投稿」タブ）は、新しい部品に置き換わりました。同じ投稿を7.1.3で開くと、値は青いリンクで並んでいましたが、7.2 Beta 1ではステータス、日付、スラッグ、投稿者、テンプレート、ディスカッション、Format、リビジョンが、名前と値の2列の表に並びます。公式のテストガイドは、従来のパネルでできた設定がすべてできることを確認項目にしています。アイキャッチ画像の設定と抜粋は同じタブの上部に、カテゴリーとタグはパネルの下の折りたたみ欄にあります。

ダッシュボードに「この日に公開した記事」が出て、ナビゲーションメニューはサイトエディターの左サイドバーで編集できる

ダッシュボードの「アクティビティ」の枠に、過去の同じ日付に公開した記事を並べる「Published On This Day」（この日に公開した記事）の欄が加わりました。検証では、公開日時を前年と前々年の10月22日にした投稿を作ると、2件が並びました。長く続けているブログほど、昔の記事を見直すきっかけになります。あわせて、最近のコメントはダッシュボード上の別の枠「最近のコメント」に分かれました。

「この日」はサイトのタイムゾーン（設定→一般）の日付で判定されます。検証サイトのタイムゾーンが協定世界時（UTC）のままだった日本時間の朝は、前日扱いになって表示されませんでした。日本時間で使うなら、タイムゾーンを東京にしておきます。

サイトエディター（外観→エディター）では、発表文によると、左のサイドバーからナビゲーションメニューの項目を追加、並べ替え、編集できるようになりました。検証では、サイドバーで項目を選ぶとその横に表示テキストとリンク先の設定が開き、項目の下に追加用の＋ボタンが並びました。サイトエディターはブロックテーマを使っているサイトで表示される画面です。検証サイトにクラシックテーマのTwenty Twenty-Oneを追加でインストールして切り替えると、外観メニューの「エディター」は「デザイン」（スタイルとパターンだけを扱う画面）に変わり、ナビゲーションの画面のURLを直接開くと、今のテーマではこの画面を使えないという表示が出ました。クラシックテーマのメニューは、従来どおり外観→メニューで編集します。

管理画面のアイコンと、JavaScript・CSSの読み込み方も変わった

管理バーと管理メニューのアイコンは、文字として表示していたアイコン（Dashicons）から、画像形式のSVGに置き換わりました。開発チームの説明によると、スクリーンリーダーでの読み上げ、高コントラスト（強制カラー）の設定、アイコンのフォントが読み込めないときに崩れにくくするための変更です。

管理画面のJavaScriptとCSSは、まとめて配る方式をやめて、1つずつ読み込むようになりました。ブラウザがファイルごとにキャッシュできます。検証サイトでは、従来のまとめ配信用のURL（load-scripts.php）が、廃止を示す「410 Gone」という応答を返しました。管理画面を軽くする系統のプラグインや、このURLを指定したキャッシュの設定を使っている場合は、検証サイトで管理画面が正しく表示されるかを確かめておきます。

/random/ でランダムな記事へ移動できる

サイトのURLの末尾に /random/ を付けて開く（例: https://example.com/random/）と、ランダムに選ばれた記事へ転送されるようになりました。/random/category/news/ のようにカテゴリーを付けると、そのカテゴリーの中から選びます。検証サイトでも、開くたびにランダムに選ばれた記事へ転送されました。パーマリンク設定が「基本」のサイトでは、/?random=1 で同じ動作になりました。

Secrets APIで、プラグインのAPIキーを暗号化して保存できる（開発者向け）

プラグインが外部サービスのAPIキーやトークンを保存する場所は、これまで設定値をしまうデータベースの表（wp_options）が中心でした。8月の提案によると、多くのプラグインは値をそのまま（平文で）入れています。データベースのバックアップやエクスポート、SQLインジェクション（入力欄などを悪用してデータベースを不正に読む攻撃）で表を読まれると、キーもそのまま漏れます。7.2のSecrets APIは、こうした秘密情報を暗号化して保存する共通の仕組みで、提案から2か月でBeta 1に入りました。

7.2に更新しただけでは、各プラグインが保存済みのキーは今までどおりの場所に残ります。プラグインがSecrets APIの関数を使うように変わると、キーが暗号化して保存されます。

検証サイトで、関数を直接呼んで動作を確かめました。保存した値は _wp_secret_ で始まる設定値に暗号文として入り、設定値の表（wp_options）全体を平文の値で検索しても1件も見つかりませんでした。同じ名前で上書きすると前の値が「previous」として残るので、新しいキーへ切り替える途中でも、前のキーで動いている連携を止めずに済みます。

// 保存（名前は「プラグインのスラッグ/用途」の形）
wp_set_secret( 'myplugin/api-key', 'sk-...' );

// 取り出し。WP_Secret が返り、値は reveal() で取り出す
$secret = wp_get_secret( 'myplugin/api-key' );
$key    = $secret ? $secret->reveal() : null;

// 文字列化や json_encode では値が出ない（検証サイトでの出力形式）
echo (string) $secret;   // [secret:myplugin/api-key]

// 上書き前の値を取り出す
$old = wp_get_secret( 'myplugin/api-key', WP_Secret_Version::PREVIOUS );

// 既存の設定値の取り込み（元の設定値は残る）
wp_import_option_as_secret( 'myplugin_token', 'myplugin/token' );

既存の設定値を取り込む関数は、元の値を消さずにコピーします。取り込んだキーには「ローテーションが必要」という印が付き、サイトヘルスに「Some secrets are pending rotation」と表示されます。平文で保存されていた期間があるキーなので、外部サービス側でキーを再発行して差し替える（ローテーション）よう促す印です。元の設定値は残るので、移行が終わったらプラグイン側で削除します。

専用の鍵は、秘密情報を保存する前に設定する

暗号化の鍵は、wp-config.php に WP_SECRETS_KEY を定義するとそれを使い、なければ既存の LOGGED_IN_KEY と LOGGED_IN_SALT から作ります。検証サイトで専用の鍵を置かずに使うと、サイトヘルスに「Secrets API is using a fallback key」（代わりの鍵を使っている）という推奨項目が出ました。

注意したいのは、鍵を設定する順番です。検証サイトで、秘密情報を保存したあとに WP_SECRETS_KEY を追加すると、保存済みの秘密情報が復号できなくなり、新しい秘密情報の保存もできなくなりました。サイトヘルスには「Some secrets cannot be decrypted」という致命的な問題が出ます。WP_SECRETS_KEY の定義を外すと、元どおり読み出せるようになりました。

代わりの鍵はログイン用のキーとソルトから作るため、専用の鍵がない状態で LOGGED_IN_SALT を作り直した場合（検証では wp config shuffle-salts を使用）も、保存済みの秘密情報が同じように読めなくなりました。保存済みの秘密情報を新しい鍵へ移す手順は、設計文書では機能プラグイン（本体に入る前に試すため別に配布しているプラグイン）のWP-CLIコマンド wp secret rotate が担い、本体には入っていません。7.2で使うなら、秘密情報を保存する前に専用の鍵を設定しておくのが確実です。すでに秘密情報を保存したサイトでは、サイトヘルスに推奨が出ても、鍵を後から足さないようにします。鍵を設定すると、サイトヘルスの判定は「Secrets API is using a dedicated key」（専用の鍵を使っている）に変わり、その後の保存と読み出しも問題なく動きました。

鍵には32バイトの乱数をbase64で表した値を使います。macOSかLinuxのターミナルで次のコマンドを実行し、出力された値を wp-config.php に書きます。

openssl rand -base64 32

// wp-config.php に追加（値は上のコマンドの出力に置き換える）
define( 'WP_SECRETS_KEY', 'ここに出力された値' );

守れる範囲もはっきりしています。提案文によると、この仕組みが防ぐのはデータベースのダンプ、バックアップ、検証用の複製、SQLインジェクションによる読み取りです。WordPressの中で動くコードは wp_get_secret() を呼べるので、悪意のあるプラグインやテーマが入った状態は守備範囲の外です。管理画面から秘密情報を入力する画面は7.3以降の予定です。7.2ではプラグインのコードから関数で使い、設計文書にある wp secret コマンドは、本体に組み込んだときのコミットによると本体には入らず、Secrets APIの機能プラグイン側に残ります。検証に使ったWP-CLI 2.12.0でも未登録でした。

Beta 1で使えないもの（新テーマIpsum、一部の日本語訳、wp secret）と試すときの注意

試験版なので、公開中のサイトに入れるのは避けます。7.2 Beta 1のような開発版にしたサイトは、WordPress本体の自動更新で、新しい開発版へ更新される設定になります。検証サイトの「更新」画面にも、自動更新の予定と「最新の7.2ナイトリービルドに更新」（ナイトリービルドは毎日作られる開発版）のボタンが表示されました。Beta 1のまま試したい場合は、wp-config.php に define( 'WP_AUTO_UPDATE_CORE', false ); を書いて止めます。

7.2 Beta 1を本番サイトに入れずに試す3つの方法

方法3の手順は次のとおりです。Docker Hubの公式イメージ（WordPressを動かすためのひな形）の wordpress:7.1.3 を起動し、WP-CLIのイメージから更新コマンドを実行します。macOSとLinuxのターミナル（zsh・bash）向けで、WindowsではWSLの中で実行します。パスワードは自分の値に置き換えてください。

# 1. ネットワークとデータベース
docker network create wp72net
docker run -d --name wp72-db --network wp72net \
  -e MARIADB_ROOT_PASSWORD=change-me -e MARIADB_DATABASE=wordpress \
  -e MARIADB_USER=wordpress -e MARIADB_PASSWORD=change-me mariadb:11

# 2. WordPress本体（7.1.3。localhost:8072で開く）
docker run -d --name wp72 --network wp72net -p 127.0.0.1:8072:80 \
  -e WORDPRESS_DB_HOST=wp72-db -e WORDPRESS_DB_USER=wordpress \
  -e WORDPRESS_DB_PASSWORD=change-me -e WORDPRESS_DB_NAME=wordpress wordpress:7.1.3

# 3. WP-CLIを呼ぶ関数を定義する
wp72cli() {
  docker run --rm --network wp72net --volumes-from wp72 --user 33:33 \
    -e WORDPRESS_DB_HOST=wp72-db -e WORDPRESS_DB_USER=wordpress \
    -e WORDPRESS_DB_PASSWORD=change-me -e WORDPRESS_DB_NAME=wordpress \
    wordpress:cli wp "$@"
}

# 4. 初期設定（1〜2の起動から数十秒待ってから実行する）
wp72cli core install --url=http://localhost:8072 --title="WP 7.2 beta test" \
  --admin_user=admin --admin_password=change-me --admin_email=admin@example.test --skip-email

# 5. 7.2 Beta 1へ更新し、自動更新を止める
wp72cli core update --version=7.2-beta1 --locale=en_US
wp72cli core update-db
wp72cli config set WP_AUTO_UPDATE_CORE false --raw
wp72cli core version   # 7.2-beta1

# 6. 試し終えたら片付ける
docker rm -f -v wp72 wp72-db && docker network rm wp72net

WP-CLIのコンテナ（イメージから起動した実行環境）を本体とは別に起動するので、データベースの接続先を環境変数で渡しています。この指定がないと「データベース接続確立エラー」になります。更新コマンドの --locale=en_US は、英語版の試験版を使う指定です。日本語で運用しているサイトをWP-CLIで更新する場合、指定がないと日本語版のBeta 1のファイルが用意されておらず、ダウンロードに失敗しました。指定を付けて更新しても、サイトの言語は日本語のまま残りました。この手順のサイトは英語で作られるので、日本語で試すときは更新後に wp72cli language core install ja --activate を実行します。Beta 2以降を試すときは、版の指定を 7.2-beta2 や 7.2-RC1 に変えます。

正式版までの日程と、Beta 2以降で確認したい点

Beta 2以降で確認したい点は、新テーマIpsumが入るか、日本語訳がどこまで追いつくか、Secrets APIに対応するプラグインが出てくるかの3つです。

運営者なら、まずPlaygroundでギャラリーの画面幅ごとの設定と投稿パネルの変化を見て、ステージングがあればBeta Testerプラグインで自分のテーマを確かめるのが近道です。プラグインを作っている人は、APIキーの保存をSecrets APIへ移す準備として、専用の鍵の設定、取り込み関数、サイトヘルスの項目を検証環境で一度動かしておくと、正式版の対応が楽になります。

参考資料

• WordPress.org「WordPress 7.2 Beta 1 is Ready for Download and Testing」（2026年10月20日）。公開日、正式版の予定、試す方法、主な変更の一覧。
• Make WordPress Core「WordPress 7.2 Release Party Schedule」（2026年10月6日）。Beta 2〜RC 3と正式版の日程。
• Make WordPress Test「Help Test WordPress 7.2」（2026年10月20日）。機能ごとのテスト手順、Beta Testerプラグインの設定、ブラウザ側の画像処理の確認項目。
• Make WordPress Core「Responsive block styles and configurable viewports in WordPress 7.1」（2026年8月5日）。7.1で入った画面幅ごとのスタイル、既定の境目、テーマでの変更方法。
• Make WordPress Core「Proposal: A Secrets API for WordPress 7.2」（2026年8月25日）。Secrets APIの設計、守る範囲、管理画面UIの先送り。
• WordPress開発リポジトリ「Security: Introduce the Secrets API.」（2026年10月13日のコミット）。WP-CLIのコマンドは機能プラグインに残るという記述。
• WordPress開発リポジトリ「Bundled Themes: Ipsum」（2026年10月22日のコミット）。Ipsumの開発版への追加。
• Make WordPress Core「Client-Side Media Processing in WordPress 7.1」（2026年7月22日）。7.1で入ったブラウザ側の画像処理。
• Secrets API ドキュメント「Functions」「WP-CLI commands」（2026年10月22日閲覧）。関数の仕様と、機能プラグインの wp secret rotate などのコマンド。
• Make WordPress Core「Replacing Dashicons in the admin bar and menu」（2026年9月4日）。アイコン置き換えの理由。
• Make WordPress Core「Introducing Ipsum, the new default theme」（2026年9月16日）。新デフォルトテーマの発表。