WordPress 7.1は8月19日公開予定｜制作会社が更新前に確認したい変更点
顧客のWordPressサイトを複数保守していると、「正式版の公開後に一斉更新してよいのか」「どのサイトから検証すべきか」で迷います。独自ブロックを使うメディアサイトと、標準機能を中心にした小規模サイトでは、確認すべき範囲も異なります。
WordPress 7.1は2026年8月19日に正式公開される予定ですが、8月1日時点の最新版はBeta 4であり、Beta 3以降にもエディター51件、Core 63件の計114件の更新・修正が含まれています。
この記事では、制作会社やサイト運営者が更新判断に使えるよう、主な変更点、検証の優先順位、複製環境で確認したい操作を整理します。ベータ版は本番サイトへ導入せず、検証環境またはローカル環境で使用してください。
WordPress 7.1は8月19日公開予定、最新状況はBeta 4
WordPress 7.1 Beta 3は、WordPress.orgから2026年7月22日に公開されました。その後、7月29日にBeta 4が公開されているため、2026年8月1日時点でBeta 3は最新版ではありません。
Beta 4には、Beta 3以降の変更としてエディター関連51件、WordPress Core関連63件、計114件の更新・修正が含まれています。Beta 3で確認した表示や不具合がBeta 4では変わっている可能性があるため、更新可否をBeta 3だけで判断するのは適切ではありません。
WordPress 7.1の正式公開予定日は2026年8月19日です。ただし、WordPressの公式リリース日程には直前に変更される可能性がある旨が示されています。日本時間での公開時刻も、今回確認した資料からは確定できません。顧客へ作業日を案内する場合は、「8月19日に公開予定」と伝え、正式な公開を確認してから本番更新日を決める必要があります。
また、Beta 3とBeta 4はテスト・開発専用です。WordPress.orgは、本番サイトや重要な業務サイトへベータ版を導入しないよう案内しています。検証には、本番サイトを複製したステージング環境、ローカル環境、WordPress Playgroundなどを使用します。
公開予定日までに行うべきことは、全サイトへベータ版を入れることではありません。まず保守対象サイトを分類し、影響を受ける可能性がある実装を持つサイトから複製環境を用意することです。RC（Release Candidate、正式版の候補となる版）やField Guideが公開された場合は、最終仕様と既知の注意事項を改めて確認します。
制作会社が優先して確認したいWordPress 7.1の変更点
WordPress 7.1では複数の変更が予定されていますが、制作・保守業務との関連が特に大きいのは、投稿エディターのiframe化、Block API v3への更新案内、エディター用コンポーネントの変更です。
投稿エディターが常にiframe内で動作する予定
WordPress 7.1では、投稿エディターを常にiframe内で動作させる予定が示されています。iframeとは、現在の管理画面とは分離された文書領域をページ内へ埋め込む仕組みです。編集キャンバスを管理画面側のスタイルから分けることで、編集時の表示を予測しやすくする狙いがあります。
これは公式に「エディター分離」という名前で発表された独立機能ではありません。確認できる具体的な変更は、「投稿エディターのiframe化の強制」です。
標準機能を中心に構成したサイトで、直ちに問題が生じると発表されているわけではありません。一方、編集部による技術的な整理では、次の実装は優先的な検証対象になると考えられます。
- 独自に開発したブロック
- 投稿編集画面へ読み込ませているCSS
- エディター内で動作するJavaScript
- 管理画面側のDOM構造を直接参照する処理
- 管理画面全体へ適用したグローバルCSSに依存する表示
- エディターを拡張するプラグインや独自テーマ
例えば、管理画面へ読み込んだCSSがそのまま編集キャンバスにも適用されることを前提にしている場合、iframe内では想定どおりに反映されない可能性があります。独自ブロックの編集画面だけ余白や文字サイズが変わる、操作用JavaScriptが対象要素を取得できない、といった事象がないかを複製環境で確認します。
ただし、これらは検証候補であり、すべてのサイトで表示崩れや操作不能が発生するという意味ではありません。
Block API v2以下はv3への更新対象を確認
Beta 1の公式発表では、Block API v2以下を使用するブロックについて、互換性を確保するためv3への更新が案内されています。Block APIは、ブロックの登録方法やエディター内での動作条件を定める仕組みです。
独自ブロックを保有している制作会社は、ブロックの登録コードやblock.jsonにあるapiVersionを確認します。値が1または2の場合は、公式資料と実装内容を確認したうえでv3への移行計画を立てます。
確認対象は、自社で開発したブロックだけではありません。テーマやプラグインが独自ブロックを提供している場合もあります。ただし、外部製のテーマやプラグインを制作会社側で無断改変すると、その後の公式アップデートを適用できなくなるなど、別の問題につながる可能性があります。外部製品については、まず開発元の告知、更新履歴、サポート情報でWordPress 7.1への対応状況を確認してください。
「Block API v2以下だから必ず動かなくなる」と断定することもできません。確認すべきなのは、使用バージョン、エディター上の表示と操作、保存後の内容、開発元の対応方針です。
エディター用コンポーネントのサイズ変更と削除
WordPress 7.1では、@wordpress/componentsが提供する対象フォームコントロールの高さが原則40pxになります。@wordpress/componentsは、WordPressの管理画面やプラグインのUIを構築するための部品群です。
これまで次期サイズを有効にする目的で使われていた__next40pxDefaultSizeは不要となり、WordPress 7.1では指定しても実行時に効果を持たないと案内されています。独自プラグインや管理画面UIで対象コンポーネントを使っている場合は、入力欄、ボタン、周囲の余白、横並びの位置などを実画面で確認する必要があります。
また、非推奨だったNavigationコンポーネントとそのサブコンポーネントが削除され、Navigatorへの移行が案内されています。実験的なユーティリティである__experimentalApplyValueToSidesも削除対象です。
これらの変更は、一般のWebサイトに設置された問い合わせフォームがすべて40pxになるという話ではありません。対象は@wordpress/componentsを利用して構築されたUIです。問い合わせフォームの表示と、WordPress管理画面内の独自UIを混同しないようにしてください。
Beta 3ではこのほか、ブロックインスペクターの「Apply globally」に確認手順が追加され、変更したスタイルのうちグローバルへ適用する対象を選択できるようになりました。Notes、レスポンシブスタイル、カスタムCSS、メディアアップロードなどにも修正が行われています。これらの挙動もベータ期間中に変わる可能性があるため、正式版の仕様として断定せず、RCや正式リリース時の情報で再確認します。
Abilities APIは新規導入ではなく7.1での拡張
Abilities APIについて、「WordPress 7.1で新しく導入される」と説明するのは正確ではありません。Abilities API自体はWordPress 6.9で導入済みであり、7.1ではクエリ、フィルタリング、入力値検証などの拡張が進められています。
2026年7月2日のCore開発チームによるマージ提案では、WordPress 7.1向けの候補として、次の読み取り専用Abilityが示されました。
core/read-settingscore/read-contentcore/read-users
Abilityは、WordPress上で実行できる処理や取得できる情報を、一定の形式で扱うための仕組みです。ただし、権限を無視して設定や利用者情報へアクセスできる仕組みではありません。
提案内容では、core/read-settingsの利用にmanage_options権限が必要です。core/read-usersも、利用者がすでに閲覧権限を持つ情報だけを返し、権限のないフィールドを除外する設計が示されています。
また、今回示されているのは読み取り専用の候補です。設定、コンテンツ、ユーザー情報を変更するmanage系Abilityは7.2以降の構想として記載されており、7.1の予定範囲ではありません。WordPress 7.1によって設定変更や投稿更新まで自動化される、と解釈しない注意が必要です。
これらはマージ提案に基づく情報であり、3種類のAbilityがすべて変更なく正式版へ収録されるかは確定していません。Abilities APIを直接利用していない一般的な事務所サイトや企業サイトでは、この変更が直ちに日常の投稿業務へ影響するとは限りません。開発者は最終的な収録範囲を確認し、サイト運営者は過度な不安を抱かず、利用中のテーマやプラグインの対応状況を優先して確認するのが実務的です。
顧客サイトを分類して事前検証の順序を決める
数十件の顧客サイトを管理している場合、すべてを同じ深さで同時に検証するのは現実的ではありません。技術的な影響の受けやすさと、問題が起きた場合の業務影響を組み合わせて優先順位を決めます。
優先度を上げたいサイト
次の条件に該当するサイトは、早めに複製環境を準備する候補です。
- 独自ブロックを使用している
- Block API v2以下のブロックがある
- 独自テーマやエディター用CSS・JavaScriptがある
- ページビルダーやエディター拡張プラグインを使用している
@wordpress/componentsを使った独自の管理画面UIがある- 削除対象の
Navigationなどへ依存している - 更新不能やサイト停止が受注、予約、情報発信へ与える影響が大きい
- バックアップや復旧手順が整備されていない
例えば、月に一度だけお知らせを更新する小規模な事務所サイトと、複数の担当者が毎日記事を公開するメディアサイトでは、同じ不具合でも業務への影響が異なります。後者では、投稿の新規作成だけでなく、予約投稿、既存記事の再編集、独自ブロックの操作まで優先的に確認する必要があると考えられます。
行政書士事務所が許認可情報を自所で更新している場合も、WordPress 7.1が行政書士業務そのものへ直接影響するわけではありません。しかし、担当者が告知を更新できなくなれば情報発信に支障が出ます。外部へ保守を委託している事務所では、技術仕様を自ら判定するより、委託先へ事前検証の有無と復旧方法を確認する方が実行しやすいでしょう。
中小企業診断士が顧客のDXやWeb運用を支援している場合は、技術検証を制作会社へ委ねつつ、更新判断者、検証担当者、障害時の連絡先が決まっているかを確認できます。役割分担が曖昧な企業では、WordPress 7.1への対応を保守手順の整理に利用できると考えられます。
複製環境で行う共通テスト
検証にはBeta 4または、その後に公開されるRCを使用します。本番サイトのデータを扱う場合は、個人情報や機密情報の取り扱いにも注意し、組織の管理ルールに従ってください。
複製環境では、少なくとも次の順序で確認します。
- WordPress、テーマ、主要プラグインの検証時点のバージョンを記録します。
- 投稿と固定ページを新規作成し、通常使用するブロックを配置します。
- 既存ページを開き、文章、画像、リンクなどを変更します。
- 下書き保存、公開、更新、プレビューが完了するか確認します。
- 独自ブロックの表示、入力、並べ替え、設定変更を確認します。
- エディター用CSSがiframe内で想定どおり適用されるか確認します。
- エディター内の独自JavaScriptや補助機能を操作します。
- 管理画面の独自フォームや設定画面に崩れがないか確認します。
- 主要なテーマ、プラグイン、ページビルダーの基本操作を確認します。
- 問題が見つかった場合は、再現手順、画面、影響範囲、暫定対応を記録します。
すべての確認が完了しても、正式版で同じ挙動になるとは限りません。ベータ版で問題がなかったという結果は有用ですが、本番更新を無条件に承認する根拠にはせず、RCまたは正式版でも必要な範囲を再確認します。
更新可否を判定表へ残す
口頭やチャットだけで検証結果を共有すると、「どのバージョンで確認したのか」「誰が更新を承認したのか」が分からなくなりがちです。サイトごとに次の項目を保守台帳や更新判定表へ残します。
- 検証したWordPressのバージョン
- 検証日と担当者
- 使用中の主要テーマとプラグイン
- 独自ブロックとBlock APIのバージョン
- テーマやプラグイン開発元の対応表明
- 検証した操作と結果
- 未確認の機能や既知の問題
- 本番更新の可否と判断者
- 本番更新の予定日
- バックアップの取得方法と保管先
- 問題発生時の復旧手順と担当者
判定基準も先に決めておくと、担当者ごとの判断差を抑えやすくなります。例えば、「記事の新規作成、既存ページの編集、保存、プレビューが完了する」「業務で使う独自ブロックに操作不能がない」「主要プラグインの開発元が対応状況を示している」「復旧テストが完了している」といった条件です。
開発元が対応を表明していない場合は、「未対応」と断定せず「対応状況を確認できていない」と記録します。そのうえで、サイトの重要度と検証結果を踏まえて更新を延期するか判断します。
まとめ｜公開前に決めるのは更新日より検証体制
WordPress 7.1は2026年8月19日に正式公開される予定です。ただし、日程と収録内容は変更される可能性があります。2026年8月1日時点ではBeta 4が最新であり、Beta 3以降にもエディター51件、Core 63件の計114件の更新・修正が含まれています。Beta 3だけを根拠に本番更新の可否を決めるべきではありません。
制作会社が優先して確認したいのは、投稿エディターのiframe化、Block API v2以下の利用、エディター用CSS・JavaScript、独自の管理画面UI、削除対象コンポーネントへの依存です。Abilities APIは7.1で新規導入されるものではなく、6.9で導入済みの仕組みに対する拡張です。マージ提案の内容を正式収録済みの機能として扱わないよう注意してください。
今日から取れる行動は、保守対象サイトの一覧に次の3項目を追加することです。
- 独自ブロックの有無とBlock APIのバージョン
- 検証環境、バックアップ、復旧手順の有無
- 更新判断者と障害時の復旧担当者
該当項目が多く、情報発信の停止が事業へ与える影響も大きいサイトから、複製環境で検証します。外部製のテーマやプラグインは、公式サイトの告知、更新履歴、サポート情報を見てWordPress 7.1への対応状況を確認してください。
RCまたは正式版が公開されたら、WordPress.orgのリリース告知とWordPress 7.1 Field Guideを確認し、公開日、iframe化とBlock APIの最終仕様、Abilities APIの収録範囲を判定表へ反映します。公開予定日に合わせて一斉更新することより、誰が何を確認し、問題時にどのバックアップから誰が復旧するかを決めておくことが、実務上の備えになります。
出典一覧
- WordPress.org「WordPress 7.1 Beta 3」（2026-07-22）
- WordPress.org「WordPress 7.1 Beta 4」（2026-07-29）
- WordPress.org「WordPress 7.1 Beta 1」（2026-07-15）
- Make WordPress Core「WordPress 7.1 Release Party Schedule」（2026-07-03）
- Make WordPress Core「Merge Proposal: Expanding WordPress Core Abilities」（2026-07-02）
- Make WordPress Core「Editor components updates in WordPress 7.1」（2026-07-23）
この記事はAIが生成し、編集長のチェックを受けて公開しています。
