WordPress 7.0 で開発者が確認しておきたいこと – apiVersion 3、PHP 7.4、DataViews(2026年5月20日リリース)

WordPress 7.0 で開発者が確認しておきたい技術的変更点を整理したプラグイン・テーマ開発者向けアイキャッチ WordPress
2026.02.28
この記事は約60分で読めます。
  1. WordPress 7.0 のリリースと現在の状況
    1. 2026年4月25日に公開された詳細スケジュール
  2. まず確認したい変更点の全体像
  3. サーバー要件の引き上げ:PHP 7.4 が新しい最低サポート、データベースは現行公式要件
  4. Block API v3：プラグイン提出時に必須化される動きが進行中
  5. AI 基盤：WP AI Client、Connectors API、Abilities API
    1. WP AI Client
    2. Connectors API と新しい Connectors 画面
    3. Abilities API（PHP 版と JS 版）
  6. DataViews：管理画面一覧の作り方が変わる
  7. iframed editor：7.0 では条件付き、完全 iframe 化は 7.1 へ延期
  8. React 19：古い書き方のカスタムブロックを確認する
  9. Interactivity API：state.navigation の非推奨化と watch() の追加
  10. @wordpress/build：esbuild ベースの新しいビルドツールが登場
  11. PHP-only ブロック登録：PHP だけで動的ブロックを登録できる
  12. Pattern Overrides の拡張：カスタムブロックでも使えるように
  13. 新しいブロックサポートとデザインツール
    1. ビューポート別表示制御（Block Visibility for viewports）
    2. Custom CSS for individual block instances
    3. Dimensions Support の拡張
    4. textIndent と textColumns（タイポグラフィ）
    5. contentOnly モードの拡張とパターン編集
  14. リアルタイム共同編集：7.1 へ延期されました(当初予定されていた仕様の概要)
  15. クライアントサイドメディア処理：当初予定から縮小
  16. theme.json とデザインツールの変更
  17. WP-CLI の新コマンド：wp block と ability コマンド
  18. Visual Revisions（ビジュアルリビジョン）の実装方式
  19. 移行チェックリスト
  20. 対応スケジュールの目安(リリース後)
  21. まとめ：WordPress 7.0 は「先に検証した開発者」が有利になる
  22. WordPress 7.0 関連記事

WordPress 7.0「Armstrong」が、2026年5月20日 17:00 UTC（日本時間5月21日未明）に正式リリースされました。当初は4月9日のリリースを予定していましたが、リアルタイム共同編集まわりのアーキテクチャ改善のため、5月20日へと延期されました。さらに、2026年5月8日に公開された RC3 のリリースノートで、リアルタイム共同編集（Real Time Collaboration、以下 RTC）が WordPress 7.0 から外され、7.1 リリースサイクルで再評価されることが正式にアナウンスされました（WordPress 7.0 RC3 リリースノート、Make WordPress Core「RTC removed from 7.0」）。その後、5月14日(日本時間5月15日)に RC4 が hard string freeze に到達し、5月19日には RC5 がリリースされたうえで、予定通り5月20日の公開を迎えました（WordPress 7.0 RC4 リリースノート）。コードネームの「Armstrong」は、ジャズトランペット奏者の Louis Armstrong にちなんでいます。一般ユーザー向けには「管理画面の刷新（DataViews 化）」「Notes 機能の強化」「AI 連携の土台」が目立つアップデートですが、開発者目線で見るとそれだけではありません。

AI連携の土台になるAPI、Reactベースの管理画面UI、エディターのiframe化、PHPだけで登録できるブロック、新しい @wordpress/build ビルドツール、Interactivity API のルーター変更、ブロックの apiVersion 3 必須化、PHP 7.4 を新しい最低サポートとする要件引き上げ(MySQL は 8.0+ または MariaDB 10.6+ が現行公式要件)など、プラグインやテーマの作り方に関わる変更が多く含まれています（リアルタイム共同編集の同期処理は 7.0 から外され、7.1 で再評価される予定です）。古い書き方をしているコードは、表面上は動いているように見えても、警告やエラーが出始めるかもしれません。

この記事では、新機能の紹介ではなく、自作プラグイン・テーマを WordPress 7.0 に対応させるためにどこを確認すればよいか、という観点でまとめます。すべての変更にすぐ対応する必要はありませんが、影響が出やすい領域は早めに見ておいたほうが安心です。RC3・RC4・RC5 と段階を踏んでのリリースで、API 仕様レベルの変更はもう入りません。リリースされた今が、正式版での検証を本格的に始めるタイミングです。

確認日：2026年5月20日(WordPress 7.0「Armstrong」リリース当日) / 参照元：Make WordPress Core、WordPress Developer Blog、WordPress.org 日本語版のリリーススケジュール告知、Gutenberg GitHub など。
検証環境：Local by Flywheel / WordPress 7.0-RC5 / PHP 8.3.21。

【最新情報】WordPress 7.0「Armstrong」がリリースされました(2026年5月20日 17:00 UTC / 日本時間5月21日未明)

WordPress 7.0「Armstrong」が、2026年5月20日 17:00 UTC(日本時間5月21日未明)に正式リリースされました。RC3(5月8日)、RC4(5月14日、hard string freeze)、RC5(5月19日)を経ての公開です。875 名を超える貢献者が関わり、420 を超える機能強化と修正が入りました。RTC の 7.1 延期方針はリリースまで維持されています。開発者にとっては、API 仕様レベルの変更はもう入らない確定段階に到達したので、正式版での検証を本格的に進められるタイミングです。

確認日と検証範囲

確認日: 2026年5月20日(WordPress 7.0「Armstrong」リリース当日)
確認できたこと: Make WordPress Core、WordPress Developer Blog、Block Editor Handbook、Gutenberg GitHub の各 Dev Note、RC3 のリリースノート、RTC の 7.1 延期発表、RC4・RC5 のリリース、5月20日 17:00 UTC の正式リリース、Local by Flywheel + WordPress 7.0-RC5 + PHP 8.3.21 環境での簡易動作確認
確認できていないこと: WordPress 7.0 正式版を本番環境(Xserver スタンダード)へ適用した結果、自作プラグイン 3 本(Rapls AI Chatbot、Thanks Mail for Stripe、Rapls PDF Image Creator)の apiVersion 3 移行、本番での DataViews 化の影響、Plugin Check の最終的な Error 格上げタイミング
備考: 本記事の API 名・引数名・挙動は、各 Dev Note および Block Editor Handbook の記述ベースです。リリース後の細かなバグ修正で挙動が調整される可能性はあるので、実装時はお使いの版の Dev Note を必ず合わせてご確認ください。

コード例について：本記事中のコードは、各公式 Dev Note および Handbook で確認できる API 名や引数名に合わせています。コピーして本番投入するための完成コードではなく、WordPress 7.0 対応時に確認すべき最小構成のサンプルです。実装時は、お使いの版の Dev Note を必ず合わせてご確認ください。

WordPress 7.0 管理画面（ダッシュボード）の全体スクリーンショット

WordPress 7.0 のリリースと現在の状況

WordPress 7.0「Armstrong」は、2026年5月20日 17:00 UTC（日本時間5月21日未明）に正式リリースされました。

当初は2026年4月9日のリリースが予定されていましたが、リアルタイム共同編集まわりのアーキテクチャ改善のため、リリースサイクルが延長されました。2026年4月22日付の Make WordPress Core の記事で、5月20日リリースの新スケジュールが発表されています。日本語版の公式告知も、これを受けて 2026年4月25日に WordPress.org 日本語版で公開されました（翻訳：Akira Tachibana さん）。

正式リリース前の段取りとしては、2026年5月8日に RC3 が公開されました。当初は名称が RC3 でも内容としては「新しい Beta 1」として扱われる位置づけになっていましたが、RC3 のリリース当日に RTC を 7.0 から外し 7.1 へ延期する判断が発表され、RC3 はもはや「新しい Beta 1 相当」としては扱われないことになりました。続いて5月14日(日本時間5月15日)に RC4 が hard string freeze に到達し、5月19日に RC5 がリリースされました。24時間のコードフリーズを経て、5月20日に正式リリースされています。

リリーススクワッドは、リリースリードを Matias Ventura、テックリードを Ella van Durpe、Mukesh Panchal、Sergey Biryukov の3名が務めています。今回のリリースには 875 名を超える貢献者が関わり、420 を超える機能強化と修正が入りました。リリースの公式情報を追いたい場合は、Make WordPress Core ブログ（https://make.wordpress.org/core/）と Make WordPress Slack の #core チャンネルが一次情報として最も信頼できます。

開発者から見たスケジュールの読み方(リリース後)

RC3・RC4・RC5 を経て正式リリースされたことで、文字列レベルでも API 仕様レベルでも、大きな変更はもう入りません。プラグイン・テーマ開発者にとっては、正式版で動作確認を行い、問題がなければ Tested up to: 7.0 の更新や対応版のタグ付けを進める段階です。リリース直後はコミュニティから不具合報告が出始めるタイミングでもあるので、報告を眺めつつ、自分のプラグイン・テーマの最終確認を進めるのが現実的です。Field Guide（リリース全体の Dev Notes をまとめた公式ドキュメント）も、最終的な内容で公開されています。

2026年4月25日に公開された詳細スケジュール

2026年4月22日に Make WordPress Core からスケジュール更新が発表され、4月25日には WordPress.org 日本語版でも翻訳が公開されました（翻訳：Akira Tachibana さん）。Beta 1 から正式リリースまでの全マイルストーンに加えて、各リリースパーティーの司会・コミッター・セキュリティ担当・ミッションコントロール（全体調整）の名前まで明示されています。Beta 1 から正式リリースまでの全体の流れを、日本時間で整理しました。

マイルストーン 日付（JST） 司会（リリースリード）
Beta 1 2026年2月20日 @amykamala
Beta 2 2026年2月27日 @amykamala
Beta 3 2026年3月5日 @amykamala
Beta 4（予定外） 2026年3月11日 @desrosj
Beta 5 2026年3月13日 @chaion07
RC 1 2026年3月25日 @amykamala
RC 2 2026年3月27日 @4thhubbard
ホスティング事業者向けテスト募集 2026年4月24日 @desrosj
RC 3（新 Beta 1 相当として案内 → RTC 延期で見直し） 2026年5月9日 @amykamala
RC 4(hard string freeze ポイント) 2026年5月15日 @4thhubbard(リリースノートのレビューは @chaion07)
RC 5 2026年5月20日(リリース済み) 最終 RC。24時間コードフリーズへ。
正式リリース 2026年5月20日 17:00 UTC（日本時間5月21日未明） 「Armstrong」として公開

テーブルで一つ補足したいのが、Beta 4 の位置づけです。Beta 4 は元々のスケジュールに含まれていなかった予定外のベータ版で、WordPress 6.9.2〜6.9.3 のセキュリティリリースを反映する形で挟まれたものです。リリースチームが「当初の予定どおりに進める」よりも「安定性を優先して柔軟に組み直す」姿勢を取っていることが、ここからも見えてきます。

司会（リリースリード）はパーティーごとにローテーションしており、@amykamala さん、@4thhubbard さん、@chaion07 さん、@desrosj さんが交代で務めました。テックリードは @ellatrix さん、セキュリティ担当は @audrasjb さん、全体調整（ミッションコントロール）は @sergeybiryukov さんがほぼ一貫して担当しています。Trac チケットや Make WordPress Slack でアナウンスを追いかけるとき、このメンバー名簿が手元にあると、誰の発言かを把握しやすくなります。

正式リリースは 17:00 UTC（日本時間5月21日未明）に行われました。RC 3 は当初「新 Beta 1 相当」、RC 4 は「新 RC 1 相当」とアナウンスされていましたが、5月8日の RC3 で RTC を 7.1 へ延期する判断が出たことで、その位置づけ自体が見直された形です。リリースチームが「予定どおりに突き進む」よりも「安定性を最優先して柔軟に組み直す」姿勢を取り続けていたことが、ここからも読み取れます。

もう一つ注意したいのは、7.0 に向けた変更の中に、まだ実装詳細が調整されている領域があることです。リアルタイム共同編集自体は 7.1 へ延期されましたが、RTC のために整備されていた周辺の API（メタボックスからサイドバーへの移行ブリッジ、register_post_meta() 経由の投稿設定の扱いなど）は 7.0 にも残っています。これらの仕様は、7.1 で RTC が改めて実装される段階で、再度公式情報を確認するのが安全です。7.1 は WordCamp US に合わせて2026年8月19日が目標とされています。

まず確認したい変更点の全体像

WordPress 7.0 で開発者が確認しておきたい変更を、大きく分けると、こんな領域があります。

  • サーバー要件:PHP 7.4 が新しい最低サポート、MySQL 8.0+ または MariaDB 10.6+ が WordPress.org の現行公式要件として示されている(2026年5月時点)
  • ブロック開発：block.json apiVersion 3 が事実上必須になりつつある
  • AI 連携基盤：WP AI Client、Connectors API、Abilities API（PHP 版・JS 版）
  • 管理画面 UI：DataViews / DataForm への移行
  • エディター：iframe 化（7.0 では条件付き、完全 iframe 化は 7.1 へ延期）
  • React：React 19 へのアップグレード
  • Interactivity API：state.navigation の非推奨化、watch() の追加
  • ブロック開発：PHP-only ブロック登録、Pattern Overrides の拡張
  • 共同編集：リアルタイムコラボレーション、Yjs、HTTP ポーリング、メタボックスとの非互換 (7.1 へ延期)
  • ビルドツール：@wordpress/build（esbuild ベース）が登場
  • 新しいブロックサポート：textIndent、textColumns、ビューポート別表示制御、Custom CSS
  • テーマ開発：theme.json、デザインツール、パターン編集、dimensions 拡張

すべてのサイトに同じ影響が出るわけではありません。記事中心のサイトなら影響は限定的かもしれませんが、投稿編集画面を拡張しているプラグイン、独自ブロックを持つテーマ、管理画面の一覧表示をカスタマイズしているプラグインでは、事前検証がかなり重要になります。

サーバー要件の引き上げ:PHP 7.4 が新しい最低サポート、データベースは現行公式要件

WordPress 7.0 で最初に確認すべきなのは、サーバー要件の確認です。Make WordPress Core の案内によれば、PHP 7.4 未満の環境については、WordPress 7.0 で自動更新対象外になる予定と公式にアナウンスされています。データベース要件については、WordPress.org の現行要件として MySQL 8.0+ または MariaDB 10.6+ が推奨として示されています(技術的なハード最低は MySQL 5.5.5 のまま)。WordPress 7.0 でデータベース要件が自動更新条件としてどう扱われるかは、リリース後の WordPress.org のアナウンスで再確認するのが安全です。

WordPress 7.0 では、PHP 7.4.0 以上が最低バージョンとして示されています(2026年5月時点)。これまで最低要件として示されていた PHP 7.2.24 と 7.3 のサポートは、Make WordPress Core の発表によれば段階的に終了する予定です。PHP 7.2 や 7.3 を使っているサイトは WordPress 7.0 の自動更新が提供されない予定で、6.9 ブランチに留まる見込みです。推奨バージョンは引き続き PHP 8.3 以上です。

もう1つの大きな変更が、MySQL の動作要件です。WordPress 6.9 では実質的に MySQL 5.5.5 まで動作していましたが、WordPress.org の Requirements ページでは、現時点(2026年5月)で MySQL 8.0 以上または MariaDB 10.6 以上が推奨として示されています。推奨は MySQL 8.4 LTS、MariaDB 11.4 LTS とされています。

プラグイン・テーマ開発者の立場からは、こんなふうに分けて考えるとよさそうです。

  • 動作ライン：WordPress 7.0 で最低サポートの PHP 7.4、データベースは WordPress.org の推奨として MySQL 8.0+ または MariaDB 10.6+(2026年5月時点)
  • 実務上の推奨ライン：パフォーマンスとセキュリティを考えた PHP 8.2 以上、できれば PHP 8.3 以上
  • AI 連携を扱う場合：外部 AI SDK の多くが PHP 8.0 以上を要求するため、PHP 8.2 以上を実質的な前提に

PHP 7.4 はすでにセキュリティサポートが終了しています。新規開発や自作プラグインの検証では、PHP 8.2 以上を基準にしたほうが現実的です。サーバー要件は、サイト運営者向け記事「WordPress 7.0 アップデート前にサイト運営者が確認しておきたいこと」でも別の角度から触れています。

Block API v3：プラグイン提出時に必須化される動きが進行中

独自ブロックを持つプラグイン・テーマで最も重要な変更が、block.json の apiVersion: 3 です。

WordPress 6.9 の段階で、block.json スキーマは apiVersion 1 や apiVersion 2 を非推奨扱いにし、これらのバージョンを使うブロックを登録するとブラウザのコンソールに警告を出すようになっています。WordPress 7.0 では、エディター完全 iframe 化は 7.1 へ延期されたものの、Plugin Check（WordPress.org のプラグイン審査ツール）に 「block.json の apiVersion が 3 以上であること」をチェックする項目が追加される動きが進んでいます。

Plugin Check の Issue #1205 によれば、運用方針はこんな形で進む予定です。

  • 新規プラグインの提出時：apiVersion 3 未満は Error 扱い（必須）。修正しないと提出できない
  • 既存プラグインの更新時：apiVersion 3 未満は Warning 扱い。今後 Error に格上げされる可能性あり

新規にプラグインを提出する場合、block.json を持つすべてのブロックで apiVersion 3 以上が必須、という運用が始まる方向です。既存のプラグインも、Warning が出ている時点で対応を進めておくほうが安全です。

出典：以下は、Block Editor Handbook「Metadata in block.json」の最小構成例です。apiVersion を 3 にし、エディター内で iframe を前提にしたコードを書く必要があります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
{
    "$schema": "https://schemas.wp.org/trunk/block.json",
    "apiVersion": 3,
    "name": "my-plugin/notice",
    "title": "Notice",
    "category": "text",
    "icon": "info",
    "version": "1.0.0",
    "textdomain": "my-plugin",
    "editorScript": "file:./index.js",
    "editorStyle": "file:./index.css",
    "style": "file:./style-index.css",
    "render": "file:./render.php"
}

コア・コミッターの内部議論では、Plugin Check が apiVersion 3 必須を Error として扱うようになるタイミングは、WordPress 7.0 のリリース前後とされています。すでに block.json を使っているプラグインは、まずローカルや正式版環境で Plugin Check を走らせて、自分のブロックがエラーを出さないか確認しておくのが安全です。

ちなみに、私自身の話ですが、本記事執筆時点で WordPress.org に公開している3つのプラグイン（Rapls AI Chatbot、Thanks Mail for Stripe、Rapls PDF Image Creator）は、まだ apiVersion 3 への移行ができていません。ブロックを使っていない実装、もしくは古い API バージョンのままの実装になっています。リリースを受けて、自分のプラグインの block.json を順次更新していく予定です。同じ立場の方も、検証は早めに始めておくと安心です。

AI 基盤：WP AI Client、Connectors API、Abilities API

WordPress 7.0 では、AI 機能そのものを標準搭載するというより、AI サービスと連携するための共通基盤が用意されました。中心になるのは、WP AI Client、Connectors API、Abilities API の3つです。

WordPress Developer Blog では、WP AI Client について、OpenAI、Anthropic、Google などの AI サービスと通信するための標準化された PHP ライブラリとして説明されています。各プラグインが AI サービスごとに個別実装するのではなく、共通の抽象化レイヤーを使えるようにする考え方です。

WP AI Client

WP AI Client は、プラグインが AI モデルにプロンプトを送り、返答を受け取るための共通インターフェースです。ここで押さえておきたいのは、WordPress 本体が特定の AI サービスを同梱するわけではない、という点です。

AI プロバイダーとの接続は、別途プロバイダープラグインや Connectors API を通じて行います。これにより、OpenAI だけ、Google だけ、Anthropic だけに依存しない作りにしやすくなります。WP AI Client は、コミュニティで開発されてきた php-ai-client パッケージを基盤にしています。

WordPress 7.0 のリリースに合わせて、Plugin Directory には以下の 3つの公式プロバイダープラグインが公開されました。Core には同梱されておらず、必要に応じて別途インストールします。

  • OpenAI（ChatGPT、GPT などの API 接続）
  • Google（Gemini API 接続）
  • Anthropic（Claude API 接続）

さらにコミュニティが開発したプロバイダーとして、OpenRouter、Ollama（ローカル LLM）、Mistral などのプラグインもすでに公開されています。Gutenberg 22.8 で Connectors システムの拡張性が改善されたため、サードパーティのプロバイダープラグインも Connectors 画面と API に深く統合できるようになりました。

出典：以下は、Make WordPress Core「Introducing the AI Client in WordPress 7.0」（2026年3月24日）で示されている wp_ai_client_prompt() の基本形をもとにした最小例です。WordPress 7.0 では、wp_ai_client_prompt() が WP_AI_Client_Prompt_Builder を返し、生成メソッドとして generate_text() を呼び出す形が示されています。

1
2
3
4
5
6
7
8
9
// WordPress 7.0 AI Client の最小例
// 出典：Make WordPress Core
// Introducing the AI Client in WordPress 7.0（2026年3月24日）
 
if ( function_exists( 'wp_ai_client_prompt' ) ) {
    $text = wp_ai_client_prompt( 'Summarize the benefits of caching in WordPress.' )
        ->using_temperature( 0.7 )
        ->generate_text();
}

実装する場合は、接続先の API キーや権限、エラー時のフォールバック、ログに残してよい情報の範囲を慎重に決める必要があります。AI 連携は強力ですが、本文や個人情報、管理画面の情報を外部サービスへ送る可能性があるため、機能を入れる前にプライバシー説明とセットで考えておきましょう。

Connectors API と新しい Connectors 画面

Connectors API は、外部サービスとの接続設定を扱う仕組みです。AI プロバイダーの API キーや接続情報を、各プラグインがばらばらに持つのではなく、WordPress 側で共通的に扱えるようにする方向です。

WordPress 7.0 では、管理画面に新しい 「設定 → Connectors」画面が追加されました。サイトオーナーが好きな AI プロバイダーを選んで接続情報を設定でき、複数のプラグインが同じ接続情報を共有できる構成です。これまで AI 連携は「プラグインごとに設定画面が分かれていて API キーが散らばる」という問題がありましたが、Connectors 画面が一元管理の場所になります。

開発時の注意点

API キーの保存方式、権限チェック、管理者以外のユーザーが接続情報を見られない設計、エラー時にキーを画面やログへ出さないこと、これらを必ず確認してください。AI 連携は機能面だけでなく、セキュリティと説明責任が重要になります。Connectors API がプラットフォームレベルで扱う情報なので、自前で API キーを保存する設計は避けて、Connectors 画面に乗せる方向で実装するのがおすすめです。

Abilities API（PHP 版と JS 版）

Abilities API は、「この WordPress サイトで何ができるか」を機械にも人間にも扱いやすい形で登録する仕組みです。バックアップを実行する、投稿を要約する、画像の alt 属性を作る、といった処理を Ability として定義できます。

AI エージェントや外部ツールが WordPress の機能を安全に呼び出すには、何が実行できるのか、どの権限が必要なのか、入力と出力は何か、これらを明示する必要があります。Abilities API は、そのための土台になります。

PHP 版は WordPress 6.9 ですでに先行導入されており、WordPress 7.0 ではこの JavaScript 版（Client-Side Abilities API）が新たに登場しました。@wordpress/abilities（純粋な状態管理）と @wordpress/core-abilities（WordPress 統合レイヤー）の2つのパッケージで構成され、サーバー側で登録された Ability を REST 経由で自動取得します。

これにより、入力・出力スキーマ、権限コールバック、注釈付きの abilities をクライアント側でも扱えるようになり、ブラウザエージェントや WebMCP（Web 版 Model Context Protocol）統合の基盤が整います。

出典：以下は、Make WordPress Core「Abilities API in WordPress 6.9」（2025年11月10日）で示されている登録方法に沿った例です。Abilities は wp_abilities_api_categories_init と wp_abilities_api_init の各フックで登録します。WordPress 7.0 では、サーバー側で登録した Ability が @wordpress/core-abilities を通じてクライアント側でも利用できるようになります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// Abilities API の登録例
// 出典：Make WordPress Core
// Abilities API in WordPress 6.9（2025年11月10日）
 
add_action( 'wp_abilities_api_categories_init', 'my_plugin_register_ability_categories' );
 
function my_plugin_register_ability_categories() {
    wp_register_ability_category(
        'content-management',
        array(
            'label'       => __( 'Content Management', 'my-plugin' ),
            'description' => __( 'Abilities for managing and organizing content.', 'my-plugin' ),
        )
    );
}
 
add_action( 'wp_abilities_api_init', 'my_plugin_register_abilities' );
 
function my_plugin_register_abilities() {
    wp_register_ability(
        'my-plugin/get-post-count',
        array(
            'label'               => __( 'Get Post Count', 'my-plugin' ),
            'description'         => __( 'Retrieves the total number of published posts.', 'my-plugin' ),
            'category'            => 'content-management',
            'input_schema'        => array(
                'type'        => 'string',
                'description' => __( 'The post type to count.', 'my-plugin' ),
                'default'     => 'post',
            ),
            'output_schema'       => array(
                'type'        => 'integer',
                'description' => __( 'The number of published posts.', 'my-plugin' ),
            ),
            'execute_callback'    => 'my_plugin_get_post_count',
            'permission_callback' => function() {
                return current_user_can( 'read' );
            },
        )
    );
}
 
function my_plugin_get_post_count( $input ) {
    $post_type = $input ?? 'post';
    $count     = wp_count_posts( $post_type );
 
    return (int) $count->publish;
}

自作プラグインで Abilities API を使う場合は、まず「AI に何をさせたいか」よりも、「その処理を人間の管理者が実行するとき、どの権限が必要か」から考えるほうが安全です。AI 連携は、権限設計が甘いと危険な操作につながりかねません。

DataViews：管理画面一覧の作り方が変わる

DataViews は、WordPress 管理画面の一覧表示を React ベースで再構築するための仕組みです。従来の WordPress 管理画面では、投稿一覧や固定ページ一覧などに WP_List_Table が使われてきました。WordPress 7.0 では、投稿・固定ページ・メディアの一覧画面が DataViews へ置き換わりました。

これは見た目だけの話ではありません。管理画面の DOM 構造や操作 UI が変わるため、こうしたプラグインは影響を受ける可能性があります。

  • 投稿一覧に独自カラムを追加しているプラグイン
  • 一覧画面に独自ボタンやフィルターを追加しているプラグイン
  • jQuery で管理画面の DOM を直接操作しているプラグイン
  • 一括操作やクイック編集を拡張しているプラグイン
  • 管理画面の CSS を細かく上書きしているテーマ・プラグイン

プラグインページの「Tested up to」表示

注意したいのは、現時点では manage_posts_columns、manage_posts_custom_column、bulk_actions といった従来の WP_List_Table 系のフックが DataViews と完全には統合されていない点です。WordPress コアでは、サードパーティのコンテンツタイプを DataViews に対応させるための作業が続いていますが、一部の機能で挙動が一貫しない可能性があります。既存のフックは多くの場面で動き続けますが、安定した動作を期待してはいけません。リリース直後に互換性報告が集中するのも、この部分です。

DataViews の API レベルでも破壊的変更があります。@wordpress/dataviews パッケージを使ってカスタム管理画面を作っているプラグインは、groupByField（文字列）が groupBy（オブジェクト）に変わっている点に注意してください。

1
2
3
4
5
6
7
8
9
10
11
// 6.9 までの書き方
const view = { groupByField: 'status' };
 
// WordPress 7.0 の書き方
const view = {
    groupBy: {
        field: 'status',
        direction: 'asc',
        showLabel: true
    }
};

独自の管理画面を持つプラグインでは、早めに DataViews / DataForm の考え方に慣れておくとよさそうです。新しい details レイアウト、combobox や adaptiveSelect といった追加コントロール、すべてのレイアウトでの validity 対応など、管理画面 UI を作るための機能が一気に増えています。

iframed editor：7.0 では条件付き、完全 iframe 化は 7.1 へ延期

当初 WordPress 7.0 では、ブロックの apiVersion に関係なくエディターを 常に iframe 化する計画でした。しかし、この「Always-iframed post editor」は WordPress 7.1 へ延期されました。Gutenberg プラグイン側では引き続きエディターブロックの iframe 化が進められていますが、WordPress コアでの完全 iframe 化は 7.1 まで持ち越しです。

WordPress 7.0 の段階では、挙動はこうなります。

  • 登録されているすべてのブロックが apiVersion 3 以上であれば、エディターは iframe 化される
  • 1つでも apiVersion 1 や 2 のブロックがある場合、エディターは iframe 化されないことがある
  • クラシックメタボックスがある投稿では、引き続きエディターが iframe 化されない

結局のところ、WordPress 7.0 のうちに iframe 化の影響を受けるかどうかは、サイトでアクティブなブロックの状況による、というのが現状の挙動です。とはいえ、WordPress 7.1 で完全 iframe 化が実施される前提で動いているので、対応は早めに進めておく必要があります。

iframe 内では、これまでのように親画面の document や window を前提にしたコードが、期待どおりに動かない場合があります。特に確認したいのは、こんなコードです。

  • document.querySelector() でエディター内の要素を直接探している
  • window に依存したサイズ計算やイベント処理をしている
  • ブロックの DOM 構造を前提に jQuery で書き換えている
  • メタボックスとブロックエディターの両方にまたがる処理をしている
  • エディター用 CSS を管理画面全体に読み込ませている

出典：以下は、Block Editor Handbook「Migrating Blocks for iframe Editor Compatibility」（2025年12月8日公開、2026年1月21日更新）の useRef 例に沿ったコードです。iframe 内では管理画面側のグローバルな document や window ではなく、対象要素の ownerDocument と defaultView を使います。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// 避けたい例：親画面の document を前提にする
const target = document.querySelector( '.my-block' );
 
// iframe対応例：refから ownerDocument / defaultView を取得する
import { __ } from '@wordpress/i18n';
import { useBlockProps } from '@wordpress/block-editor';
import { useRef, useEffect } from '@wordpress/element';
 
export default function Edit() {
    const ref = useRef();
 
    useEffect( () => {
        if ( ! ref.current ) {
            return;
        }
 
        const { ownerDocument } = ref.current;
        const { defaultView }   = ownerDocument;
 
        const onResize = () => {
            // iframe側のwindowに対する処理を書く
        };
 
        defaultView.addEventListener( 'resize', onResize );
 
        return () => {
            defaultView.removeEventListener( 'resize', onResize );
        };
    }, [] );
 
    const blockProps = useBlockProps( { ref } );
 
    return (
        <div { ...blockProps }>
            { __( 'Hello world!', 'my-plugin' ) }
        </div>
    );
}

実務上のおすすめ

独自ブロックを持っている場合は、Block API v3 への移行、エディター CSS の読み込み位置、DOM 直接操作の有無を先に確認してください。WordPress 7.0 でいったん条件付きの iframe 化に留まったとしても、7.1 で完全 iframe 化が予定されているので、対応は先送りせず進めておくのが安全です。

React 19：古い書き方のカスタムブロックを確認する

WordPress 7.0 では、Gutenberg まわりで React 19 への移行が進みました。通常のブロック利用だけなら大きな問題は出にくいかもしれませんが、独自ブロックを開発している場合は注意が必要です。

React 19 で削除・非推奨化された主要な API を挙げます。

  • ReactDOM.render / ReactDOM.hydrate：React 18 の段階で非推奨。React 19 で完全に削除。代替は createRoot / hydrateRoot
  • element.ref：React 19 では ref が通常の prop に。element.props.ref 経由でアクセス
  • Legacy Context API（contextTypes、getChildContext）：完全削除。contextType もしくは useContext を使う
  • UMD ビルド：React 19 で削除。CommonJS / ESM のいずれかを使う
  • Function Components の defaultProps：非推奨。デフォルト値はパラメータの分割代入で書く

そのほか、TypeScript 利用者は types-react-codemod で型定義の自動更新を試せます。React 公式が用意した codemod も使えます。

確認しておきたい項目を挙げておきます。

  • React の古いライフサイクルメソッドを使っていないか
  • @wordpress/element を通さず、React 本体に直接依存していないか
  • ReactDOM.render / ReactDOM.hydrate を呼び出している箇所がないか
  • element.ref を直接読み取っているコードがないか
  • ビルド環境の依存パッケージが古すぎないか
  • ブラウザコンソールに deprecated 警告が出ていないか
  • ブロックの編集画面とフロント表示の両方で動作確認しているか

React 19 対応は、いきなり本番で確認するものではありません。まずステージング環境で WordPress 7.0 を試し、編集画面を開いた直後のコンソールエラーを確認するところから始めるのが安全です。

Interactivity API：state.navigation の非推奨化と watch() の追加

Interactivity API を使ったブロックを開発している方は、WordPress 7.0 で1つ重要な変更があります。core/router ストアの state.navigation へのアクセスが非推奨化されました。

これまで、ローディングインジケーターなどを実装するために state.navigation.hasStarted や state.navigation.hasFinished を直接読んでいるコードがあったかもしれませんが、これらは元々公開 API として意図されたものではありませんでした。WordPress 7.0 から、state.navigation への直接アクセスは SCRIPT_DEBUG モードで開発時にコンソール警告を出すようになり、将来のバージョンで完全に動かなくなる予定です。

正式なナビゲーション状態追跡の仕組みは、WordPress 7.1 で導入される予定です。それまでの間は、@wordpress/interactivity から提供される新しい watch() 関数を使う方法が示されています。

1
2
3
4
5
6
7
8
9
10
11
12
// WordPress 7.0 で追加された watch() 関数の使い方
// 出典：Make WordPress Core
// Changes to the Interactivity API in WordPress 7.0（2026年3月4日）
 
import { store, watch } from '@wordpress/interactivity';
 
const { state } = store( 'core/router' );
 
watch( () => {
    // クライアントサイドナビゲーションのたびに実行される
    sendAnalyticsPageView( state.url );
} );

watch() は、コールバック内でアクセスしたリアクティブな値を監視し、変化のたびに再実行します。クリーンアップ用のコールバックも返せます。state.navigation を直接読むコードがあるなら、state.url の監視と watch() の組み合わせに置き換える方向で対応するのが現実的です。

もう1つ、Gutenberg 22.6 のタイミングで @preact/signals から effect ではなく watch をエクスポートするように内部実装が変わりました。直接 @preact/signals をインポートしているコードがあれば、import 文の確認が必要です。これは小さなコード差分ですが、リアクティブな処理に影響するため、確認だけはしておくべきです。

@wordpress/build：esbuild ベースの新しいビルドツールが登場

WordPress 7.0 のサイクルに合わせて、新しいビルドツール @wordpress/build が登場しました。これは将来的に @wordpress/scripts（webpack + Babel ベース）の中身を置き換える予定の、esbuild ベースのビルドツールです。

公式 Developer Blog では、@wordpress/build の特徴がこんなふうにまとめられています。

  • esbuild ベースで、webpack + Babel パイプラインより大幅に高速
  • ゼロコンフィグ。packages/ や routes/ といった決まった名前のフォルダを置くだけで、自動的にビルド対象を見つける
  • PHP 登録ファイルの自動生成。package.json の規約から、スクリプト・モジュール・スタイルの登録 PHP を自動生成
  • Watch モードでの開発時インクリメンタルビルド対応
  • Gutenberg の100以上のパッケージのビルドにすでに採用されている

長期的な計画としては、@wordpress/build が @wordpress/scripts の内部エンジンになる予定です。普段 wp-scripts build を実行している開発者も、ワークフローを変えずに高速化と PHP 自動生成の恩恵を受けられるようになります。

ただし、WordPress 7.0 のリリース時点では、ブロックを登録するプラグインのユースケースに対するサポートが完成していません。Gutenberg プラグイン群のビルドには使えていますが、ブロック登録を含む一般的なプラグインで採用するには、まだ手動の調整が必要な部分があります。リリース直後にいきなり乗り換えるのではなく、しばらく動きを見てから、検証ブランチで試してみるのがよさそうです。

当面は @wordpress/scripts を使い続けて問題ありません。@wordpress/build は今後の選択肢として頭に入れておく、というスタンスが現実的です。

PHP-only ブロック登録：PHP だけで動的ブロックを登録できる

WordPress 7.0 では、JavaScript のビルドを使わずに、PHP だけでブロックを登録しやすくなりました。これまでブロック開発は、ちょっとした動的表示でも block.json、JavaScript、ビルド環境が必要になりがちでした。PHP-only ブロック登録は、サーバーサイドレンダリングだけで十分なブロックを作る場合に向いています。

大きな利点は、PHP のみで インスペクター（設定パネル）の UI も自動生成される点です。ブロックの属性に label や type、enum を指定しておくと、それに対応する設定 UI が自動でサイドバーに表示されます。設定だけのブロックのために JavaScript ビルド環境を整える必要がなくなります。

出典：以下は、Make WordPress Core「PHP-only block registration」（2026年3月3日）で示されている形式に合わせた例です。PHP-only ブロックとして自動登録させるには、render_callback に加えて supports.autoRegister を true にする必要があります。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
// PHP-onlyブロックの登録例
// 出典：Make WordPress Core
// PHP-only block registration（2026年3月3日）
 
add_action( 'init', 'my_plugin_register_php_only_blocks' );
 
function my_plugin_register_php_only_blocks() {
    register_block_type(
        'my-plugin/notice',
        array(
            'title'      => __( 'Notice', 'my-plugin' ),
            'category'   => 'text',
            'attributes' => array(
                'message' => array(
                    'label'   => __( 'Message', 'my-plugin' ),
                    'type'    => 'string',
                    'default' => __( 'Hello World', 'my-plugin' ),
                ),
                'type' => array(
                    'label'   => __( 'Type', 'my-plugin' ),
                    'type'    => 'string',
                    'enum'    => array( 'info', 'warning', 'success' ),
                    'default' => 'info',
                ),
            ),
            'render_callback' => function( $attributes ) {
                $type    = isset( $attributes['type'] ) ? $attributes['type'] : 'info';
                $message = isset( $attributes['message'] ) ? $attributes['message'] : '';
 
                return sprintf(
                    '<div class="notice notice-%s"><p>%s</p></div>',
                    esc_attr( $type ),
                    esc_html( $message )
                );
            },
            'supports' => array(
                'autoRegister' => true,
            ),
        )
    );
}

ただし、PHP-only ブロックは万能ではありません。複雑なインタラクション、リアルタイムプレビュー、編集画面での細かい UI が必要な場合は、従来どおり JavaScript を使う必要があります。使いどころとしては、お知らせボックス、関連記事一覧、最新投稿リスト、ショートコードの置き換え、サーバー側の条件分岐で表示内容が変わるブロック、といった用途が向いています。

Pattern Overrides の拡張：カスタムブロックでも使えるように

これまで Pattern Overrides（同期パターン内の特定ブロックだけを編集できる仕組み）は、Heading、Paragraph、Image、Button の4つのコアブロックに限定されていました。WordPress 7.0 では、この制限がなくなります。

Block Bindings をサポートするすべてのブロック属性が、Pattern Overrides でも使えるようになります。これにより、自作のカスタムブロックでも Pattern Overrides を有効にできるようになりました。

有効にするには、block_bindings_supported_attributes フィルター（または block_bindings_supported_attributes_{$block_type} の動的フィルター）でサポートする属性を宣言します。

1
2
3
4
5
6
7
8
9
10
11
12
13
// カスタムブロックで Pattern Overrides を使えるようにする例
// 出典：Make WordPress Core
// Pattern Overrides in WP 7.0: Support for Custom Blocks（2026年3月16日）
 
add_filter(
    'block_bindings_supported_attributes_my-plugin/cta-block',
    function( $supported_attributes ) {
        $supported_attributes[] = 'heading';
        $supported_attributes[] = 'description';
        $supported_attributes[] = 'buttonLabel';
        return $supported_attributes;
    }
);

同期パターン内に独自ブロックを含めて、ボタンラベルや見出しだけインスタンスごとに変えたい、というユースケースに使えます。エージェンシー案件で、ボタンの文言やキャンペーン用の見出しだけを差し替える運用が、独自ブロックでも自然に組めるようになりました。

新しいブロックサポートとデザインツール

WordPress 7.0 では、ブロックの design supports もまとめて拡張されています。テーマ開発者・ブロック開発者が押さえておきたい主な追加項目を挙げます。

ビューポート別表示制御（Block Visibility for viewports）

WordPress 6.9 で導入された Block Visibility（ブロック単位の表示・非表示）が、WordPress 7.0 で ビューポートごとの制御に拡張されました。デスクトップ、タブレット、モバイルの各画面サイズで、ブロック単位で表示・非表示を切り替えられるようになります。

これは元々プラグインや子テーマで実装されていた機能ですが、コアに取り込まれることで、追加のプラグインなしで条件付き表示が組めるようになります。表示制御は CSS ベース（wp-block-hidden-{viewport} クラス）で実装されており、SEO 観点で完全な非表示にしたい場合は、別途サーバーサイドの制御を組み合わせる必要があります。

Custom CSS for individual block instances

WordPress 7.0 では、ブロックの個別インスタンスに対して、インスペクターサイドバーから直接 Custom CSS を入力できる機能が追加されました。ブロックのインスペクター（高度な設定）パネルに「Custom CSS」フィールドが追加されます。

セレクタを書く必要はなく、style.css サブキーに保存され、wp_unique_id_from_values() で生成された一意のクラス名を通じて適用されます。アクセスは edit_css 権限でゲートされており、HTML マークアップを含む CSS は拒否される仕組みです。

ブロック開発者にとって悩ましい問題は、「自分のブロックでこの機能を有効にするか」という判断です。インスタンスごとの Custom CSS は、メンテナンス性の観点からは諸刃の剣です。多くの場合、theme.json のグローバルスタイルやブロックスタイルバリエーションで管理する方がコードベースは綺麗に保てます。

Dimensions Support の拡張

ブロックがオプトインできる dimensions サポートが拡張され、width と height のコントロールが追加されました。theme.json でも settings.dimensions.dimensionSizes プリセットが使えるようになり、テーマでサイズパレットを定義してブロックから一貫して使う運用が可能になります。

textIndent と textColumns（タイポグラフィ）

WordPress 7.0 では、新しいタイポグラフィ系のブロックサポートが追加されました。

  • textIndent：text-indent の CSS プロパティをブロックでネイティブにサポート。Paragraph ブロックが最初の対応ブロック。長く要望されていた機能です
  • textColumns：1段落を新聞のような複数列レイアウトで表示するサポート。Paragraph ブロックで使えます

1
2
3
4
5
6
7
{
    "supports": {
        "typography": {
            "textIndent": true
        }
    }
}

テーマやプラグインで「first-line indent」のためだけに独自 CSS を書いていた場合は、textIndent サポートに乗り換えることで、独自実装を削減できます。

contentOnly モードの拡張とパターン編集

WordPress 7.0 では、非同期パターンとテンプレートパーツも、デフォルトで contentOnly 編集モードで開かれるようになりました。これまで主に同期パターンに限定されていた contentOnly が、非同期パターンにも広がる形です。

contentOnly モードでは、ブロック構造や深いスタイル制御を露出せず、テキストや画像といった「コンテンツ」の編集だけを許可します。エージェンシー案件で「クライアントにレイアウトを壊させたくない」場合に効果的なモードです。

独自パターンを登録しているプラグインは、コンテンツ編集だけで完結するか、構造的な編集が必要かを見直しておくとよいでしょう。管理者向けには、PHP フィルター disableContentOnlyForUnsyncedPatterns を使って、非同期パターンの contentOnly を無効化できます。

1
2
3
4
5
// 非同期パターンの contentOnly モードを無効化する
add_filter( 'block_editor_settings_all', function( $settings ) {
    $settings['disableContentOnlyForUnsyncedPatterns'] = true;
    return $settings;
} );

リアルタイム共同編集：7.1 へ延期されました(当初予定されていた仕様の概要)

このセクションは、当初 WordPress 7.0 で導入予定だったリアルタイム共同編集（RTC）の仕様をまとめたものです。2026年5月8日の RC3 リリース時に、RTC は 7.0 から外れ、7.1 リリースサイクルで再評価されることが決まりました（RTC removed from 7.0）。リリース版にもこの方針が反映されています。7.1 で改めて実装される際は、ここで紹介する仕様（HTTP ポーリング、CRDT、wp_sync_storage、2人制限、メタボックス非互換など）と異なる可能性があります。プラグイン開発者として「7.1 で何を意識しておくべきか」「7.0 サイクルで整備された移行ブリッジを今のうちに使えるか」の参考として残しています。

WordPress 7.0 で当初の大きな目玉のひとつとして開発されていたのが、リアルタイム共同編集（RTC）です。複数ユーザーが同じ投稿を同時に編集できるようになる機能で、Google ドキュメントの共同編集に近い体験を WordPress にも持ち込むものでした。実装には CRDT の考え方が使われ、Yjs ライブラリが基盤になっています。Matt Mullenweg は「現状のアプローチが Core に入れるほど堅牢だと確信が持てない」として、処理範囲の広さ、競合状態、サーバー負荷、メモリ効率、ファズテストで見つかる不具合などを理由に挙げ、5月8日に RTC を Core から外す判断を下しました。

同期方式は、ホスティング環境の互換性を最優先して、HTTP ポーリングがデフォルトとして採用される予定でした。当初検討されていた WebRTC は、共有レンタルサーバーやネットワーク制限のある環境で動かないことがあるため、最終的に却下されました。HTTP ポーリングなら、Xserver やさくらインターネットなどの一般的な共有サーバーでも動く設計です。

同期データは、専用の内部投稿タイプ wp_sync_storage の post_meta に CRDT 形式で保存される設計と Dev Note で示されていました。クライアントサイドの初期実装では、同時に編集できるユーザー数が2人に制限される設計と案内されていました。ホスト側で別の同期プロバイダーを追加するか、wp-config 定数で調整することで上限は変更できる見込みです。

WebSocket に対応したホスティング環境では、sync.providers フィルターを使ってより高速な WebSocket ベースの同期に差し替えることもできる設計でした。

なお、RC3 のリリースノートでは、RTC アーキテクチャの新バージョンのテストに協力したホスティング会社として、Kinsta、Bluehost、GoDaddy、WordPress.com、XServer、Ionos が挙げられています。Xserver も RTC のテストに参加していたことを考えると、7.1 で改めて実装されたときには、Xserver スタンダードプランなど共有レンタル環境での動作確認情報が比較的早めに出てくる可能性があります。

7.1 で RTC が再実装される際には、開発者やサイト管理者は、いくつかの点を慎重に確認することになりそうです。

  • 共同編集は、環境によってパフォーマンス差が出る可能性がある
  • クラシックメタボックスがある投稿では、共同編集が無効化される設計とアナウンスされていました(7.1 の最終仕様では変わる可能性あり)
  • 同期プロバイダーやストレージ方式は、7.1 のリリース直前まで変更される可能性がある
  • 共有サーバーでは、同時編集時の HTTP リクエスト増加に注意が必要
  • キャッシュプラグインやオブジェクトキャッシュとの相性確認が必要
  • opt-in（明示的な有効化）として動作するかデフォルト有効化されるかは、7.1 の仕様で要確認

ステージング環境と本番環境の関係図

メタボックス利用プラグインは要確認(優先度は 7.1 リリースに合わせて再評価)

SEO プラグイン、カスタムフィールド系プラグイン、独自の投稿設定を持つプラグインでは、メタボックスを使っていることがあります。RTC が 7.1 へ延期されたため、この対応の優先度は当初の予定より下がりました。それでも、WordPress 7.0 サイクルは「プラグイン開発者がメタボックスを register_post_meta() + PluginSidebar コンポーネントへ移行するための互換性ブリッジ実装の窓」として整備された部分は、7.0 で利用可能なまま残ります。共同編集を使いたいサイトでの導入を見越して、メタボックス依存の機能を移行できるかを 7.1 リリース前に検討しておくと、いざ RTC が再実装されたタイミングで慌てずに済みそうです。

自作プラグインで同期処理やキャッシュ層に触れていない場合でも、投稿編集画面にメタボックスを追加しているだけで、7.1 で RTC が再実装された際に共同編集に影響する可能性があります。自分のプラグインが共同編集を止める側にならないか、7.1 のベータ・RC が出始めた段階で確認しておく価値はあります。

クライアントサイドメディア処理：当初予定から縮小

WordPress 7.0 のもう1つの目玉として開発が進められていたのが、クライアントサイドメディア処理です。画像のリサイズや圧縮を、サーバーで ImageMagick や GD を使うのではなく、ブラウザ側で行うことで、サーバー負荷を減らし、AVIF や MozJPEG のような新しいフォーマットを扱いやすくする機能です。

ただし、リリース前のテストで処理速度や互換性に問題が見つかり、当初フル機能で予定されていた実装は WordPress 7.0 から外れました。M4 Pro 搭載の MacBook Pro での処理時間が JPEG で約19秒、AVIF で29〜55秒というベンチマーク結果が出るなど、Squoosh などの類似ツール（同じハードウェアで3秒以下）と比べて大きく遅く、Chromium 系ブラウザでしか動かない問題、メモリ不足によるクラッシュなど、ユーザー体験面で課題が残っていました。

WordPress 7.0 のリリースでは、クライアントサイドメディア処理は限定的な範囲で含まれています。完全な実装は今後のリリースに持ち越されました。プラグインで画像処理を行っている場合、当面はサーバーサイド処理を前提に動作することを確認しておくのがよいでしょう。

theme.json とデザインツールの変更

テーマ開発者にとっては、theme.json 関連の変更も重要です。WordPress 7.0 では、ブロックごとのデザインツール対応が整理され、ボタン、ナビゲーション、背景、疑似状態などのスタイリングがより細かく扱える方向に進んでいます。

特に確認しておきたいのは、こうした項目です。

  • ボタンブロックの hover / focus / active 状態
  • ナビゲーションリンクの現在地表示
  • 背景画像とグラデーションの組み合わせ
  • ブロックごとのカラー、余白、枠線、影の対応状況
  • カスタム CSS に依存している部分を theme.json へ寄せられるか
  • Dimensions サポートで width / height を扱うブロックの対応

クラシックテーマでも、ブロックやパターンを使っている場合は無関係ではありません。Cocoon などのテーマを使いながら独自 CSS を追加しているサイトでは、WordPress 本体の管理画面・エディター側の変更とぶつからないかを、ステージング環境で確認しておくと安全です。

もう1つ、クラシックテーマにも影響する変更として、Font Library がすべてのテーマで使えるようになる点があります。クラシックテーマでも「外観 → フォント」からフォント（TTF、OTF、WOFF、WOFF2）をアップロード・管理できるようになりました。Cocoon などのクラシックテーマで運用しているサイトでは、独自のフォント管理プラグインを併用している場合に、競合しないか確認しておきましょう。

サイトヘルスでのPHPバージョン確認画面

WP-CLI の新コマンド：wp block と ability コマンド

WordPress 7.0 サイクルでは、WP-CLI チームが新しいコマンド群の開発も進めています。

  • wp block コマンド：ブロックエンティティへの読み取り専用アクセス。パターンやテンプレートのエクスポートには例外的に対応
  • wp ability コマンド：Abilities API を CLI から扱うためのコマンド

これらは WP-CLI v3.0 のリリースに先行して、開発依存パッケージとしてテスト可能になっています。

1
2
3
4
5
6
7
8
9
# 開発版を試す方法（出典：What's new for developers? March 2026）
 
# WP-CLI 経由でインストール
wp package install wp-cli/block-command:dev-main
wp package install wp-cli/ability-command:dev-main
 
# Composer 経由でインストール
composer require wp-cli/block-command:dev-main --dev
composer require wp-cli/ability-command:dev-main --dev

WP-CLI v3.0 の安定リリースは、当初2026年3月末を目標としていました。Abilities API を使ったプラグインを開発する場合、コマンドラインからの動作確認に wp ability コマンドが使えるかもしれません。

Visual Revisions（ビジュアルリビジョン）の実装方式

WordPress 7.0 では、ブロックエディターのリビジョンパネルに ビジュアル比較機能が追加されました。これまでテキストや HTML の差分が中心だったリビジョン機能が、見た目の差分まで色分けで表示できるようになります。

実装方式は2段階です。まず変更されたブロックを高速にチェックし、フラグが立ったブロックだけリッチテキスト比較を行う、というパフォーマンスを意識した設計です。色分けは currentColor を使ってテーマの色設定に追従します。

  • 緑のアウトライン：追加されたブロック
  • 赤のアウトライン：削除されたブロック
  • 黄のアウトライン：設定が変更されたブロック
  • テキスト内では、追加部分が緑下線、削除部分が赤の取り消し線、フォーマットだけの変更が黄色のアウトライン

独自ブロックを持っている場合、ビジュアルリビジョンの動作確認も正式版でしておくと、デザイン崩れを早期に発見できます。

移行チェックリスト

WordPress 7.0 対応で、まず確認しておきたい項目をまとめます。

プラグイン・テーマ開発者向けチェックリスト（リリース後版）

環境準備
□ ステージング環境で WordPress 7.0（正式版）を検証した
□ PHP 8.2 以上、できれば PHP 8.3 以上で動作確認した
□ MySQL 8.0+ または MariaDB 10.6+ で動作確認した(現行公式要件)
□ WP_DEBUG と debug.log を有効にしてエラーを確認した
□ ブラウザコンソールの警告・エラーを確認した（SCRIPT_DEBUG も有効）

ブロック開発まわり
□ 独自ブロックの apiVersion を 3 に更新した
□ Plugin Check を実行して block.json 関連のエラーがないか確認した
□ document / window への直接参照を洗い出した
□ エディター用 CSS が iframe 内でも正しく読み込まれるか確認した
□ React 19 で非推奨 API（ReactDOM.render、element.ref、Legacy Context）を使っていないか確認した
□ Interactivity API の state.navigation 直接アクセスを watch() + state.url に置き換えた
□ @preact/signals から直接インポートしているコードがあれば watch への変更を確認した

管理画面まわり
□ add_meta_box() を使っている箇所を確認した
□ メタボックスを register_post_meta() + PluginSidebar へ移行できるか検討した
□ 投稿・固定ページ・メディア一覧の独自カスタマイズを確認した
□ manage_posts_columns 系のフックが DataViews 化で影響を受ける可能性を認識した
□ @wordpress/dataviews を使っている場合、groupByField → groupBy オブジェクトへの変更に対応した

AI 連携・外部接続
□ AI 連携機能を持つ場合、WP AI Client / Connectors API の利用を検討した
□ API キーや外部送信データの扱いをプライバシーポリシーに反映した
□ Abilities API を使う場合、権限チェック（permission_callback）を明示した

共同編集まわり(7.1 で再評価のため、優先度は下がっています)
□ リアルタイム共同編集でメタボックスが影響しないか、7.1 のベータ・RC 段階で再確認する
□ キャッシュプラグイン・オブジェクトキャッシュとの相性を、7.1 リリース時点で確認する
□ wp_sync_storage 投稿タイプを誤って一覧表示してしまう実装がないか確認した(7.0 でも内部投稿タイプとして残る可能性あり)

パターン・テーマ
□ Pattern Overrides をカスタムブロックで使う場合、block_bindings_supported_attributes フィルターを設定した
□ 独自パターンが contentOnly モードのデフォルト化で問題なく機能するか確認した
□ theme.json の変更で既存スタイルが崩れないか確認した
□ Font Library を使う場合、既存のフォント管理プラグインとの競合を確認した

リリース対応
□ WordPress.org 公開プラグインなら、Tested up to: 7.0 を更新する
□ 公開ページに「確認したバージョン」と「確認日」を明記する

対応スケジュールの目安(リリース後)

2026年5月20日に正式リリースされた今、ここから先の流れを整理しておきます。RC3・RC4・RC5 を経てリリースされたので、自作プラグインやテーマで残された作業は、正式版での最終確認とリリース対応が中心です。

  • リリースまで：RC 版で重大なエラーを確認、PHP・MySQL要件のチェック、block.json apiVersion 3 への対応 → 完了済みの想定
  • リリース直後(現在のフェーズ)：正式版をステージング環境に入れて最終動作確認、Plugin Check 実行、独自ブロックのビジュアル確認、コミュニティの不具合報告のチェック。API 仕様レベルの変更を心配する必要はない
  • リリース後 数日〜1週間：問題がなければ readme の Tested up to: 7.0 を更新、対応版のタグ付け、WordPress.org への公開
  • リリース後 1〜2週間：ユーザーからの互換性報告に対応し、必要に応じて修正版を公開。本番サイトへの適用もこのあたりが目安

特に WordPress.org に公開しているプラグインは、「7.0 対応済み」と書くときに、RC 版での確認なのか正式版での確認なのかが曖昧にならないようにしたいところです。公開ページでは、確認したバージョン(正式版)と確認日を明記したほうが親切です。

WordPress管理画面「ダッシュボード → 更新」

まとめ：WordPress 7.0 は「先に検証した開発者」が有利になる

WordPress 7.0「Armstrong」は、単なる機能追加のリリースではありません。AI 連携、管理画面、エディター、ブロック開発の各領域で、今後の WordPress 開発の方向性が見えるリリースです。当初の目玉だったリアルタイム共同編集は 7.1 へ延期されましたが、そのために整備された移行ブリッジ（メタボックスから PluginSidebar への移行を支援する API）は 7.0 にも残っています。RC3・RC4・RC5 を経て、2026年5月20日 17:00 UTC(日本時間5月21日未明)に正式リリースされ、API 仕様レベルでの大きな変更はもう入らない確定段階に到達しました。

すべての変更にすぐ対応する必要はありません。ただし、特に当てはまる項目があるプラグイン・テーマは、正式版で早めに最終確認しておくのが安全です。

  • 投稿編集画面を拡張している（特にメタボックスを追加している）
  • 独自ブロックを提供している（block.json apiVersion 3 必須化が近い）
  • 管理画面の一覧表示をカスタマイズしている（DataViews 化の影響）

特に、block.json apiVersion 3 への対応、PHP 7.4 を新しい最低サポートとする変更、MySQL 8.0+/MariaDB 10.6+ という WordPress.org 現行要件への対応、Interactivity API の state.navigation 非推奨化、React 19 への対応は、表面上は小さな変更に見えても、古い実装に依存しているコードでは不具合の原因になります。正式リリース後しばらく経ってから慌てて対応するより、早い段階で警告やエラーをつぶしておくほうが、結果的に作業量は少なく済みます。

2026年は、年3回のメジャーリリース（7.0、7.1、7.2）が予定されています。7.0 で導入された土台の上に、7.1 でリアルタイム共同編集、完全 iframe 化、ナビゲーション状態追跡 API、サードパーティアイコンレジストリなどが続いていく流れです。7.1 は WordCamp US に合わせて2026年8月19日が目標とされています。WordPress 7.0 は、今後の WordPress プラットフォームの方向性を読むうえで、最も重要な節目になりそうです。私自身、本記事執筆時点で WordPress.org に公開している3つのプラグインのうち、Rapls AI Chatbot は管理画面の一覧表示にも触れているので、DataViews 移行の影響を重点的に検証する予定です。同じ立場で apiVersion 3 移行を進める方の参考になれば。

一般ユーザー向けのアップデート手順やバックアップ方法は「WordPress 7.0 アップデート前にサイト運営者が確認しておきたいこと」にまとめています。開発者向けには、まずこの記事のチェックリストを使って、ステージング環境でひと通り確認してみてください。

主な参照元

WordPress 7.0 関連記事

コメント

タイトルとURLをコピーしました