検証環境：WordPress 7.0-RC2 / PHP 8.3.21 / Xserver スタンダードプラン / Node.js 25.8.1 / WP-CLI 2.12.0（2026年4月時点）
【追記・2026年4月10日】リリース延期のお知らせ
2026年3月31日、リリースリード Matias Ventura がWordPress 7.0の延期を正式発表しました。原因はリアルタイムコラボレーションのデータベース設計問題（post_metaベースではセッション中に永続キャッシュが無効化される）で、専用テーブルを設計し直す必要があるためです。追加プレリリースは4月17日まで一時停止、新スケジュールは4月22日までに発表予定です（複数の情報源では5月中旬〜下旬の正式リリースを見込む報道も出ています）。現在の安定版はWordPress 6.9.4です。なお、April 2026 Developer Blogによれば、RTC以外のすべての機能は準備完了の状態です。
WordPress 7.0は5.0でブロックエディターが導入されて以来、最大の技術的変更を伴うリリースです。AI連携の標準化、管理画面のReactベース刷新、エディターのiframe完全移行——いずれもプラグイン・テーマ開発者に直接影響します。
この記事では、一般向けの新機能紹介ではなく、開発者が対応すべき破壊的変更・新API・移行チェックリストに焦点を当てて解説します。一般向けのアップデート手順やバックアップ方法は「WordPress 7.0 アップデート完全ガイド」をご覧ください。
AI基盤：WP AI Client・Abilities API・Connectors・MCP Adapter
WordPress 7.0最大の構造的変更はAI基盤のコア統合です。WP AI Clientがプロバイダー非依存のPHP APIを提供し、Abilities APIがプラグインの機能をAIエージェントに公開し、MCP AdapterがModel Context Protocolで外部AIアシスタントとの接続を担います。開発者はこの基盤の上にAI機能を構築することで、プロバイダーロックインを回避できます。
WP AI Client
WordPress 7.0に同梱されるプロバイダー非依存のPHP SDKです。プラグインがAIモデルにプロンプトを送信し、結果を受け取るための一貫したインターフェースを提供します。コアにはAIプロバイダーが直接バンドルされず、OpenAI・Google・Anthropic向けのプロバイダーパッケージがプラグインディレクトリに公開されています。
APIキーの管理はConnectors APIが担当し、管理画面の「設定 → Connectors」で一元管理できます。プラグイン開発者がクレデンシャルを個別に処理する必要はありません。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
// WP AI Client の基本的な使い方 $prompt = wp_ai_client_prompt() ->set_model( 'text' ) ->set_system_instruction( 'You are a helpful assistant.' ) ->add_user_message( 'Summarize this post: ' . $post->post_content ); $result = $prompt->send(); if ( is_wp_error( $result ) ) { // エラーハンドリング } else { $text = $result->get_text(); } |
【追記】公式3社に加え、コミュニティ製プロバイダーも公開済み
April 2026 Developer Blogによると、OpenAI・Google・Anthropic向けの公式プロバイダーパッケージに加えて、コミュニティ製のOpenRouter・Ollama・Mistral向けプロバイダープラグインがプラグインディレクトリに公開されています。独自プロバイダーを作りたい開発者向けに、Connectors API Dev Noteが公開されています。
Connectors拡張性の向上（Gutenberg 22.8）
【追記】Gutenberg 22.8でConnectorsシステムの拡張性が改善されました。サードパーティ製プロバイダープラグインがConnectors画面とAPIにより深く統合できるようになっています。独自のAIプロバイダープラグインを開発する場合は、この新しい拡張性APIの活用を検討してください。
Abilities API（クライアントサイド拡張）
6.9で導入されたAbilities APIのサーバーサイドPHP API（wp_register_ability()）に加え、7.0ではクライアントサイドのJavaScript APIが追加されました。サーバーに登録されたAbilityは@wordpress/core-abilitiesを介して自動的にクライアントでも利用可能になります。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
// サーバーサイド：Abilityの登録 register_ability( 'my_plugin/run_backup', [ 'label' => 'Run Site Backup', 'callback' => 'my_plugin_run_backup', 'capability' => 'manage_options', 'description' => 'Triggers a full site backup.', ] ); // クライアントサイドで利用する場合 add_action( 'admin_enqueue_scripts', function() { wp_enqueue_script_module( '@wordpress/core-abilities' ); } ); |
MCP Adapter
Model Context Protocol（MCP）はAIアシスタントが外部ツールと通信するためのオープン標準です。WordPress MCP Adapterは登録されたAbilityをMCPツールとして公開し、ClaudeなどのAIアシスタントからWordPressを操作できるようにします。MCP Adapterはブリッジパターンで設計されており、将来MCPが別のプロトコルに置き換わっても移行が容易です。自作プラグイン「Rapls AI Chatbot」でもこのAbilities APIとの統合を検討しています。
【追記】WordPress Playground MCPサーバー対応
April 2026 Developer Blogによると、WordPress PlaygroundがMCPサーバーに対応しました。ClaudeやGeminiなどのAIエージェントからPlaygroundに接続し、プラグインのインストール・PHPの実行・WordPressの操作をブラウザ上で直接行えるようになっています。開発・テスト環境としての活用範囲が大きく広がります。
DataViews：WP_List_Tableの置換と開発者への影響
WordPress 7.0では投稿・固定ページ・メディアの一覧画面がDataViewsに置き換わります。ただしカスタム投稿タイプの一覧画面は7.0ではWP_List_Tableのままです。管理画面のカラム追加・一括操作拡張・UIカスタマイズ系プラグインはDataViewsとのDOM競合を確認する必要があります。
DataViewsはReactベースのコンポーネントで、インラインフィルタリング・グリッド/テーブルレイアウト切替・密度コントロール・新しいactivityレイアウトなどを提供します。開発者はDataViewsとDataFormコンポーネントを使って自作の管理画面インターフェースを構築でき、combobox・adaptiveSelectなどの新コントロールとバリデーション機能も利用可能です。
破壊的変更の範囲：7.0ではコアの投稿・固定ページ・メディア画面のみがDataViewsに変換されます。register_post_type()で登録したカスタム投稿タイプの一覧画面は7.0時点ではWP_List_Tableのままです。ただし、今後のリリースで段階的に移行される予定なので、早めにDataViews APIに慣れておくことをおすすめします。
iframed投稿エディターとReact 19
WordPress 7.0では投稿エディターがiframe内でレンダリングされます（ブロックAPI v3以上の場合）。documentやwindowグローバルに依存しているプラグインのCSS・JSは動作しなくなります。さらにReact 18→19へのアップグレードにより、古いReact APIに依存したカスタムブロックで互換性問題が発生する可能性があります。
iframed editor
サイトエディター・テンプレートエディターは6.x時点で既にiframe化されていましたが、投稿エディターは条件付きでした。7.0では、登録されている全ブロックがBlock API v3以上であればiframeモードが有効になります（完全強制は7.1で予定）。
何が壊れるか：親ウィンドウのdocumentやwindowを直接参照しているコードは、iframe境界によって動作しなくなります。メタボックス・TinyMCE時代のセレクタ・エディターキャンバスへの直接DOM操作が対象です。メタボックスの移行先はregister_post_meta()＋@wordpress/edit-postのPluginSidebarコンポーネントです。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
// ❌ NG：グローバルdocumentへの直接参照 document.querySelector('.my-block'); // ✅ OK：refを使ってownerDocumentを取得 import { useRef, useEffect } from '@wordpress/element'; import { useBlockProps } from '@wordpress/block-editor'; export default function Edit() { const ref = useRef(); useEffect( () => { const { ownerDocument } = ref.current; const { defaultView } = ownerDocument; // defaultView経由でwindowにアクセス }, [] ); return <div { ...useBlockProps( { ref } ) }>Hello</div>; } |
React 18→19アップグレード
7.0ではGutenbergのReactバージョンが19に上がります。非推奨APIを使用しているカスタムブロックプラグインで予期しない動作が起きる可能性があります。特にクラスコンポーネントや古いライフサイクルメソッドを使用している場合は要注意です。
PHP-onlyブロック登録
WordPress 7.0では、サーバーサイドレンダリングのみの簡素なブロックをPHPだけで作成できるようになりました。JavaScriptのビルドステップが不要になるため、簡単な動的ブロックの開発ハードルが大幅に下がります。ただし、高度なインタラクティブ機能は従来通りJSが必要です。
Make WordPress Coreの公式Dev Noteでは「このAPIは既存のクライアントサイドパラダイムを置き換えるものではなく、サーバーサイドレンダリングだけで十分なブロックの開発を簡素化するもの」とされています。インスペクターコントロールがPHPの属性定義から自動生成されるため、npm run buildなしでブロックを公開できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
// PHP-onlyブロックの登録例（JSビルド不要） register_block_type( 'my-plugin/notice', [ 'title' => 'Notice', 'category' => 'text', 'attributes' => [ 'message' => [ 'type' => 'string', 'default' => '' ], 'type' => [ 'type' => 'string', 'default' => 'info' ], ], 'render_callback' => function( $attributes ) { return sprintf( '<div class="notice notice-%s"><p>%s</p></div>', esc_attr( $attributes['type'] ), esc_html( $attributes['message'] ) ); }, ] ); |
【追記】create-blockのinteractive variantにクライアントサイドナビゲーション追加（Gutenberg 22.8）
@wordpress/create-blockのscaffoldingツールにinteractive variantが追加されました。これはInteractivity APIのクライアントサイドナビゲーションサポートを最初から含んだ実用的なテンプレートで、ページネーション・検索結果・フィルタリングアーカイブのナビゲーションパターンをすぐに使えます。追加セットアップなしでscaffold直後から動作します。
自作プラグインの開発で使いたい方は、WordPress.orgへのプラグイン公開手順を「SVNの使い方｜基本コマンドからデプロイ・TortoiseSVNまで」にまとめているので参考にしてください。
リアルタイム共同編集（CRDT / Yjs）の技術実装
共同編集の同期にはCRDTエンジンとしてYjsが採用され、HTTPポーリングで通信します。デフォルトオフ（オプトイン）で、メタボックスがある投稿では自動無効化されます。共有サーバーでは2名の同時編集で1分間に約480回のHTTPリクエストが発生するため、負荷設計に注意が必要です。
RTCの実装ではYjsという軽量なCRDTライブラリが使われています。April 2026 Developer Blogでも「The implementation uses Yjs as the underlying CRDT engine」と明記されており、WebRTCではなくHTTPポーリングが採用された理由として、あらゆるホスティング環境での互換性確保が挙げられています。
同期データはwp_sync_storageという内部投稿タイプのpost_metaに永続化されます（延期の原因はこのストレージ設計の見直しで、専用テーブルへの移行が進行中）。同期プロバイダーのアーキテクチャはストレージ層とトランスポート層を差し替え可能に設計されており、sync.providersフィルターでホスティング事業者がWebSocketプロバイダーを提供する道も開かれています。
同期頻度は一人で編集中は4秒ごと、複数人が同時編集中は1秒ごとです。デフォルトの同時編集上限は2名ですが、wp-config.phpの定数で変更できます。WebSocketが使えない共有ホスティングでのリアルタイム通信については、XserverでWebSocketもSSEも動かない｜Long Polling実装で詳しく書いています。
【追記】RTC：共同編集者のテキスト選択が可視化されました
Gutenbergの最新リリースで、共同編集中に他ユーザーがテキストを選択した箇所がハイライト表示されるようになりました。Googleドキュメントのカーソル・選択範囲の可視化に近い体験になります。
その他の開発者向け変更点
PHP 7.2/7.3のサポート終了（最低7.4・推奨8.3）、ブロックリビジョンのビジュアルdiff、パターンのContent-Only編集モード・カスタムブロック対応、Interactivity APIルーターの変更、Tabsブロックの内部構造変更、管理バーからのCommand Palette（⌘K）、WP-CLI 3.0のwp block/wp abilityコマンドなど、多数の変更があります。
PHP 7.4最低要件
PHP 7.2・7.3は完全にサポート対象外になります。7.4は最低要件ですが2022年11月にセキュリティサポートが終了しているため、PHP 8.3以上を推奨します。April 2026 Developer Blogでは「PHP 8.2+を推奨」と明記されています。
ブロックリビジョンのビジュアルdiff
エディターのリビジョンパネルで、変更が色分けオーバーレイで表示されるようになりました。追加ブロックは緑枠、削除ブロックは赤枠、設定変更は黄枠。テキストの追加は緑下線、削除は赤取り消し線で表示されます。
パターンのContent-Only編集モード・カスタムブロック対応
7.0ではパターンがデフォルトでContent-Only編集モードになりました。コンテンツクリエイターはデザインに触れずにコンテンツだけを編集できます。管理者はdisableContentOnlyForUnsyncedPatterns設定でオプトアウト可能です。
|
1 2 3 4 5 6 7 8 9 10 |
// PHP フィルター add_filter( 'block_editor_settings_all', function( $settings ) { $settings['disableContentOnlyForUnsyncedPatterns'] = true; return $settings; } ); // JavaScript dispatch wp.data.dispatch( 'core/block-editor' ).updateSettings( { disableContentOnlyForUnsyncedPatterns: true } ); |
【追記】パターンオーバーライドがカスタムブロックにも対応（Gutenberg 22.8）
Gutenberg 22.8より、パターンオーバーライドがコアブロックだけでなくカスタムブロックにも対応しました。独自のカスタムブロックを含む同期パターン（synced patterns）でも、インスタンスごとに異なるコンテンツを差し替えられるようになります。これにより、デザインテンプレートとしてのパターンをより柔軟に構築できます。
Interactivity APIルーターの変更
state.navigationを使用していたコードはそのまま動作しなくなります。影響範囲は限定的ですが、Interactivity APIのルーティングを使ったプラグインは必ず確認してください。
Tabsブロックの内部構造変更（破壊的変更の可能性）【追記】
April 2026 Developer BlogによるとTabsブロックの内部ブロック構造が変更されています。Tabsブロックを組み込んでいるテーマやプラグインは既存コンテンツへの影響を確認してください。特にカスタムCSSセレクタでTabsブロックの内部要素を指定している場合、スタイルが崩れる可能性があります。
theme.json関連の変更【追記】
April 2026 Developer Blogから、テーマ開発者が知っておくべきtheme.json関連の変更点：
- Buttonブロックの擬似状態スタイリング（hover・focus・active）がGlobal Stylesから設定可能に
- theme.jsonでのボタン疑似要素サポート（::before / ::after）が追加
- ナビゲーションリンクのカレントアイテムスタイルがtheme.jsonで定義可能に（
navigation.currentLinkキー） - 背景画像へのグラデーションオーバーレイが追加（カバーブロック・テーマセクションでのグラデーション合成に対応）
WP-CLI 3.0とwp block / wp abilityコマンド
WP-CLI 3.0ではwp block（ブロックエンティティの読み取り・パターンとテンプレートのエクスポート）とwp ability（Abilities APIの操作）コマンドが追加されます。WP-CLIの基本操作は「WP-CLI完全入門」を参照してください。
7.0対応の移行チェックリスト（18項目）
WordPress 7.0リリース前にプラグイン・テーマごとに確認すべき項目をまとめました。iframed editor・DataViews・React 19・PHP最低要件・AI基盤・テーマ変更の6領域をカバーしています。
□ PHPバージョンが7.4以上か確認（推奨8.2以上、理想は8.3）
□ add_meta_box()の呼び出しを検索し、iframed editorでの動作を確認
□ メタボックスの移行先としてregister_post_meta()＋PluginSidebarを検討
□ document/windowグローバルへの直接参照をownerDocument/defaultViewに置換
□ ブロックのapiVersionを3に更新してiframeモードでテスト
□ React 19で非推奨になったAPIを使用していないか確認
□ enqueue_block_assetsフックでエディター内のスタイルを正しく読み込んでいるか確認
□ 投稿・固定ページ・メディア一覧のカスタマイズがDataViewsで動作するか確認
□ カスタム投稿タイプの一覧画面は7.0では影響なし（WP_List_Table継続）を認識
□ Interactivity APIのstate.navigationを使用していないか確認
□ 【追記】Tabsブロックの内部構造変更により既存のCSSセレクタが壊れていないか確認
□ 【追記】WP AI Client / Connectors API / Abilities APIとの統合を検討（公式3社＋OpenRouter・Ollama・Mistral対応プロバイダーも確認）
□ 【追記】パターンオーバーライドのカスタムブロック対応を活用できないか検討
□ PHP-onlyブロック登録が自作ブロックの簡素化に使えるか評価
□ 【追記】theme.jsonのButton擬似状態・ナビゲーションカレントリンク・背景グラデーション対応を確認
□ ステージング環境でWP_DEBUGを有効にし、debug.logのエラーを確認
□ 全プラグインの「Tested up to」が7.0になっているか確認（リリース後2〜4週間待つ）
□ 【追記】create-blockのinteractive variantを使った新しいブロック開発パターンを把握しておく
まとめ：7.0は開発者にとって5.0以来の転換点
WordPress 7.0はAI基盤（WP AI Client・Abilities API・MCP Adapter）・管理画面刷新（DataViews）・エディター変更（iframe化・React 19）・PHP-onlyブロック登録の4領域で、プラグイン・テーマ開発者に直接的な対応を求めるリリースです。リリース後すぐに対応版を出せるよう、今からステージングでの検証を始めてください。
iframed editorとDataViewsの移行は「次のリリースまで先延ばし」が通用しません。7.0で互換性ウィンドウがさらに狭まり、7.1で完全強制される方向です。今のうちに移行を完了させておけば、今後のリリースごとの対応コストが大幅に減ります。
アップデートの具体的な手順（バックアップ・ステージング構築・本番適用フロー）はWordPress 7.0 アップデート完全ガイドにまとめています。WAF誤検知でエディターが動かない場合はXserverのWAF誤検知で501エラー！原因と完全対策ガイドを参照してください。
【追記】リリース日は延期されました
4月9日の正式リリースは見送られ、新スケジュールは2026年4月22日までに発表予定です（延期理由はリアルタイムコラボレーションのデータベースアーキテクチャ見直し）。April 2026 Developer Blogによれば、RTC以外のすべての機能は準備完了の状態です。リリース日が確定次第、本記事を更新します。
コメント