2026年7月15日、WordPress 7.1 Beta 1 が公開された。正式リリースは8月19日。今回の目玉はレスポンシブ編集や新メディア処理だが、プラグイン運用者にとっての本命は「ポストエディタが常に iframe になる」変更だ。筆者は自サイトのブロックを1行のコマンドで棚卸しして、5分で「待つ側」に回れることを確認した。その手順ごと書く。
目次
何が起きたか
WordPress 7.1 Beta 1 が公式発表された。Beta は4回、Release Candidate は2回の予定で、正式版は WordCamp US に合わせた 2026年8月19日。7.0.2 の緊急対応の影響でベータ日程は一度組み替えられているから、追いかける人は 7.1 のリリースページを直接見るのが確実だ。
| 日付 | マイルストーン |
|---|---|
| 2026-07-15 | Beta 1（フィーチャーフリーズ） |
| 2026-07-17 / 07-22 / 07-29 | Beta 2 / 3 / 4 |
| 2026-08-05 / 08-12 | RC 1 / RC 2 |
| 2026-08-19 | 正式リリース |
新機能は多い。画面幅ごと・ホバー状態ごとのスタイルをCSSなしで指定するレスポンシブ／状態別スタイリング、wasm-vips によるクライアントサイド画像処理（HEIC・AVIF・WebP、GIFの動画変換）、新しいメディア編集モーダル、Playlist・Tabs ブロック。ただ、既存サイトを壊しうる変更は1つだけで、それがエディタの iframe 化だ。
「Block API v3 必須化」の正確な中身
見出しだけ読むと「v2 のブロックが動かなくなる」ように見える。実際の仕様はもう少し細かい。公式の移行ガイドと 7.0 時点の dev note（「7.0 では iframe を強制しない」と明言している文書）から、バージョンごとの挙動を整理する。
| バージョン | ポストエディタの iframe 挙動 |
|---|---|
| 〜6.9 | apiVersion 2 以下の登録にコンソール警告。iframe 化は「全登録ブロックが v3」のときだけ |
| 7.0 | 判定が「投稿に実際に挿入されたブロック」基準に変更。v2 以下が挿入されると非 iframe にフォールバック（公式 dev note が「7.0 では強制しない」と明言） |
| 7.1 | apiVersion に関わらず常に iframe。フォールバック廃止 今回 |
v2 のブロックは 7.1 で「動作停止」するのではない。「iframe の外に逃げられなくなる」。エディタ画面の admin 側 document を触っていたコードや、admin 側に読み込まれることを前提にしたエディタ用CSSが、iframe の内側に届かなくなって崩れる。壊れ方が地味なぶん、リリース後に気づくと原因を追いにくい。
例えるなら、同じ事務所に同居していたブロックたちが、ガラス張りの別室へ引っ越す。姿は見えるし仕事も続くが、今までのように隣の机（admin 側の document）へ手を伸ばすことはできない。別室に置き忘れた道具（エディタ用CSS）は、部屋の中へ運び直す必要がある。
立場ごとの影響を分けて考える
「iframe 化」と一括りにされるが、読者の立場によってやることは違う。
| 立場 | 7.1 までにやること |
|---|---|
| 配布プラグイン・テーマの作者 | 今すぐ Beta で検証。ユーザーのエディタを壊すと影響範囲が自分のサイトでは済まない |
| 自作ブロックを自サイトで使っている | 棚卸し → v2 以下があれば次節のパターン修正 → Playground か検証環境で確認 |
| ブロックを自作していない（筆者もここ） | 棚卸しで「該当なし」を確認したら待つ。使用中プラグインの対応はプラグイン側の仕事 |
| ページビルダー系の大型プラグイン依存 | 各プラグインの 7.1 対応アナウンスを追う。8月19日までに対応表明が無ければ更新を保留する判断もある |
自分がどの行にいるかは、次の棚卸しコマンドが5分で確定させてくれる。
ひとつ補足しておくと、この「全テーマ・無条件で iframe」という適用範囲は Beta 期間中の議論次第で「ブロックテーマのみ」に軟化する可能性が報じられている。確定は RC 時点の dev note 待ちで、筆者もそこは未確認のまま書いている。準備を先に済ませておけば、どちらに転んでも困らない。
自サイトのブロックを1行で棚卸しする
影響を受けるのは block.json を持つプラグインとテーマだけだ。SSH できるサーバーなら、これで一覧が出る。
find wp-content/plugins wp-content/themes -name block.json -maxdepth 4 \
-exec sh -c 'echo "$1"; grep -o "\"apiVersion\"[^,]*" "$1"' _ {} \;筆者のサイト（WordPress 7.0.2・クラシックテーマ + 子テーマ運用）で実行した結果はこうだった。
wp-content/plugins/contact-form-7/includes/block-editor/block.json
"apiVersion": 3block.json を持つのは Contact Form 7 のただ1つ。すでに apiVersion 3 だった。自作プラグイン2本（先日 7.0.2 対応を検証したヘッダー復元系と配信系）はブロックを登録していないから対象外。ここまで5分。筆者のサイトは 7.1 の iframe 化を「待つ側」でよいと分かった。
棚卸しの結果、v2 以下が出てきた人だけが次の節の対象になる。
iframe で壊れる典型パターンと直し方
公式の移行ガイドが壊れ方をパターンごとに整理している。要点を3つに絞る。
1. window / document のグローバル参照
window.innerWidth やクリック監視が admin ページ側を見てしまい、iframe 内のキャンバスに届かない。修正は要素起点で iframe 側の document を辿る。公式推奨は @wordpress/compose の useRefEffect だ。
const ref = useRefEffect( ( element ) => {
const { ownerDocument } = element;
const { defaultView } = ownerDocument;
defaultView.addEventListener( 'resize', onResize );
return () => defaultView.removeEventListener( 'resize', onResize );
}, [] );2. enqueue_block_editor_assets で読むエディタCSS
このフックで読み込んだCSSは admin ページ側に注入されるため、iframe 内のキャンバスには当たらない。block.json 側に移すと WordPress がキャンバスへ自動挿入してくれる。
{ "editorStyle": "file:./index.css" }3. 分離時代の「防御コード」の逆噴射
admin と同居していた時代の .wp-admin .my-block セレクタ、管理バー分の top: 32px 補正、calc(100vw - 160px)。iframe が分離を提供する環境では、これらが逆に崩れの原因になる。消してよい。Masonry や lightbox のようなライブラリが内部で document.querySelectorAll() を呼ぶ場合は、要素を明示的に渡す形へ書き換える。
画像処理がブラウザ側に移る影響も見ておく
iframe の陰に隠れがちだが、サイト運営者に効くもう1つの変更がクライアントサイド画像処理だ。アップロード画像のリサイズと変換を、ブラウザ内の WebAssembly（wasm-vips）が引き受ける。従来この仕事はサーバーの ImageMagick の担当だった。全サブサイズをブラウザで生成してからサーバーへ送るハイブリッド構成で、HEIC・AVIF・WebP の入力、GIF の動画変換まで対応する。
共用サーバー勢には朗報のはずだ。筆者のサイトもロリポップの共用サーバーで、大きめの写真を上げたときのサブサイズ生成はサーバー側の仕事だった。これがアップロードした人のPCの仕事になる。
ただし全員がこの経路に乗るわけではない。公式のテスト告知によると、Firefox と Safari、iOS 上の全ブラウザ、RAM 2GB 以下の端末、低速回線（2G / Save-Data ヘッダ）、blob を禁止する CSP のいずれかに当たると、従来どおりサーバー処理へ静かにフォールバックする。自分の環境がどちらで動いたかは、ブラウザのコンソールで window.__clientSideMediaProcessing を見れば分かる。「アップロードが速くなった気がする」を実測で確かめられる稀な例なので、7.1 に上げたら一度見てみるといい。
レスポンシブ編集は theme.json から試せる
もう1つの目玉、ビューポート別スタイリングのブレークポイントは theme.json で定義できるようになった（Gutenberg PR #79104）。
{ "settings": { "viewport": { "mobile": "29rem", "tablet": "42rem" } } }生成されるメディアクエリはレンジ構文で、デスクトップの値がタブレット・モバイルに継承される。既定のブレークポイント（7.0 時点でハードコードされていた Mobile ≤480px / Tablet 480〜782px）をテーマ側の値に差し替えられるのが実務上のポイントだ。
置き換え候補がどれくらいあるかも数えてみた。筆者の子テーマの style.css には @media が15個あり、内訳は max-width 600px 系が7個、WordPress の管理画面境界と同じ 782px 系が3個、residual が5個。このうちブロックのスタイル調整に相当するものが theme.json 側へ移れる候補になる。ただしクラシックテーマでこの機能がどこまで使えるかは、公式情報に言及がなく筆者も未確認。ここは8月上旬に出るはずの Field Guide を待ってから子テーマで試す予定でいる。数えるだけ数えて、移すのは仕様が固まってからにする。
試すだけなら本番は要らない。WordPress Playground でブラウザ内に 7.1 Beta を立ち上げるのが一番早く、テスト環境なら wp core update --version=7.1-beta1 で入る。継続的に追うなら WordPress Beta Tester プラグインで「Bleeding edge + Beta/RC Only」を選んでおく手もある。
書き手向けの新要素にも短く触れておく。Notes は太字・リンク・絵文字・@メンション対応になり、テキスト選択単位のインライン注記が付いた。複数人でドラフトを回すサイトなら、エディタ内で校閲のやりとりが完結する場面が増えるはずだ。新ブロックは波形表示つきの Playlist と Tabs の2つ。どちらもコアブロックなので apiVersion の心配は要らない。
よくある疑問への答え
クラシックテーマだから無関係では。ポストエディタを使っている限り関係はある。iframe 化はテーマ形式の話というよりエディタ本体の話で、少なくとも Beta 1 時点の実装はテーマ種別を見ない。クラシックテーマで「無関係」と言い切れるのは、ブロックを一切使わずクラシックエディタプラグインで書いている場合くらいだ。
apiVersion を 3 に書き換えるだけで対応完了になるか。ならない。"apiVersion": 3 の宣言は「iframe の中で正しく動く」という表明であって、書き換え自体は挙動を変えない。中身が admin 側の document を触っていれば、宣言だけ変えても壊れたままだ。宣言の前にコードの点検が要る。
Beta を本番に入れて確かめてよいか。公式がテスト環境での実施を明記している。筆者も本番には入れない。Playground なら1分でブラウザ内に立つので、確認だけならそちらで足りる。
使用中プラグインの対応状況はどう確認するか。まず自サイトの棚卸しで、そのプラグインが block.json を持つか・apiVersion がいくつかを見る。v3 なら対応済みで、確認はそこで終わる。v2 以下だった場合は、プラグインの changelog か開発ブログで「7.1」「iframe」「apiVersion」への言及を探す。8月に入っても音沙汰のないプラグインは、7.1 当日に上げず様子見に回すのが無難だと筆者は考えている。エディタが崩れてから戻す作業のほうが、待つコストより確実に高い。
7.0.2 を飛ばして 7.1 に上げてよいか。だめだ。7.0.2 は先日検証したとおりセキュリティ対応を含む緊急リリースで、7.1 を待つ理由にはならない。今 7.0.2 に上げて、8月19日に改めて 7.1 を判断する。二段構えでいい。
まとめ
筆者の判断はこうだ。クラシックテーマ運用でも、8月19日を待たずに「block.json の棚卸し1行」だけは今やっておく価値がある。5分で「待つ側」か「直す側」かが確定し、直す側だと分かった場合に7月なら Beta 4 まで detection と修正の時間が丸ごと残っている。React 19 への移行と同じで、7.0.1 のときに準備の先取りを勧めたのと同じ理屈が iframe 化にも当てはまる。
正式版が出たら、筆者は子テーマの theme.json でビューポート指定を実測して続報を書く。style.css の15個のメディアクエリのうち何個を実際に減らせたか、数字で報告するつもりだ。棚卸しの5分だけ、今日のうちに済ませておいてほしい。
