- 1. リリースタイムラインと開発体制の背景
- 2. Abilities API & Workflows API ― WordPressの能力をマシンリーダブルに
- 3. WP AI Client ― プロバイダー非依存のAI統合基盤
- 4. MCP Adapter ― AIエージェントとWordPressの橋渡し
- 5. エディタのiframe化 ― 破壊的変更と移行ガイド
- 6. DataViews & DataForm の拡張
- 7. PHP-onlyブロック登録 ― JavaScriptなしでブロックを作る
- 8. Block Bindings & パターンオーバーライドの強化
- 9. ブロック単位のカスタムCSS
- 10. リアルタイムコラボレーションのトランスポート設計
- 11. クライアントサイドメディア処理
- 12. その他の注目変更点まとめ
- 13. PHP 7.4最低要件化への対応
- 14. 開発者向けマイグレーションチェックリスト
- 15. まとめ ― 7.0は「プラットフォーム化」への転換点
WordPress 7.0（リリース予定: 2026年4月9日）は、Gutenberg Phase 3の本格始動だけでなく、プラグイン開発者・テーマ開発者にとって無視できない技術的な変更を数多く含んでいます。
この記事の結論
WordPress 7.0の開発者向け重要変更は3つの方向性に集約されます。①AIファーストの拡張性（Abilities API・WP AI Client・MCP Adapter）、②エディタのサンドボックス化（投稿エディタのiframe化は7.1延期だが準備は今から）、③PHP開発者の再包摂（PHP-onlyブロック登録）。互換性テストを済ませていない場合はGAの4月9日に向けて今すぐ着手してください。
この記事では、一般ユーザー向けの機能紹介では触れきれないAPI変更、アーキテクチャの刷新、ブロック開発の新パラダイム、そして互換性に影響する破壊的変更を掘り下げて解説します。
Beta 1（2026年2月19日公開）からBeta 6を経て、RC2（3月26日公開済み）の段階にある現在、この記事を参考にプラグインとテーマの互換性検証を進めてください。
この記事の対象読者
- WordPressプラグイン・テーマの開発者
- WordPress案件を扱うWeb制作会社のエンジニア
- WordPressのアーキテクチャ変遷に関心のあるエンジニア
- AI × CMSの連携基盤に興味がある開発者
1. リリースタイムラインと開発体制の背景
2024年後半の法的紛争による開発停滞を経て、WordPress 6.9で基盤整備が行われ、7.0はその上に構築された品質重視のリリースです。ベータ版は当初予定の4本から計6本に増加し、RC1の5日延期を経てRC2が3月26日に公開されました。
2025年の開発停滞と技術的負債の清算
2024年後半のAutomattic vs WP Engine訴訟は、コア開発のリソースに直接的なダメージを与えました。Automatticはコアへの貢献を一時停止し、年3回のリリースサイクルは年2回に縮小されました。
この制約の中で、WordPress 6.9（2025年12月リリース）は意図的に「安定化リリース」として位置づけられ、Notes機能のv1実装、Block Visibility v1、Abilities API v1、パフォーマンス改善とレガシーコードの整理といった基盤整備が行われました。
つまり、7.0のBeta 1に含まれる多くの機能は6.9で仕込んだ土台の上に成り立っています。6.9のchangelogを読んでいない方は、まずそこから確認することをお勧めします。
7.0のリリーススケジュール
| 2026-02-19 | Beta 1 ✅ | フィーチャーフリーズ |
| 2026-02下旬 | Beta 2 ✅ | バグフィックス集中期間 |
| 2026-03-06 | Beta 3 ✅ | バグフィックス継続 |
| 2026-03-11 | Beta 4 ✅ | セキュリティパッチ取り込み（6.9.2相当） |
| 2026-03-12 | Beta 5 ✅ | 当初予定外の追加ベータ |
| 2026-03-20 | Beta 6 ✅ 【追記】 | RC1延期に伴い追加。ベータ版は計6本に |
| 2026-03-24 | RC1 ✅ 【追記】 | 文字列フリーズ（当初3月19日予定→5日延期） |
| 2026-03-26 | RC2 ✅ 【追記】 | 翻訳文字列が利用可能に（公開済み） |
| 2026-04-02 | RC3 | 最終確認 |
| 2026-04-09 | GA | WordCamp Asia Contributor Day |
【追記】ベータ版が計6本に・RC2が3月26日に公開
当初3月19日に予定されていたRC1は、リリース準備中に以下の3点の懸念が判明し、3月24日に延期されました。最終リリース日の4月9日は変更ありません。
- RTCのパフォーマンス問題：本番環境に近い負荷でのテスト中に性能不足が顕在化
- クライアントサイドメディア処理の品質問題：処理速度が実用水準に達していないことが判明（詳細は sec11 で後述）
- リリースパッケージサイズの肥大化：WordPress 6.9比で約33MB増という問題
RC1延期の橋渡しとしてBeta 6（3月20日）が追加され、ベータ版は当初予定の4本から計6本となりました。公開されたRC1はBeta 5以降の134以上の更新・修正を含んでいます。その後RC2が3月26日に予定通り公開され、このタイミングで日本語を含む翻訳用文字列が利用可能になっています。
プラグイン・テーマ開発者はRC2を使って最終テストを行い、readme.txt の “Tested up to” を 7.0 に更新してください。
GAまでの時間はさらに短くなっています。互換性テストを済ませていない場合は今すぐ着手してください。
2. Abilities API & Workflows API ― WordPressの能力をマシンリーダブルに
Abilities APIは「このWordPressサイトに何ができるか」を構造化された形式で公開する仕組みで、7.0で最も注目すべきアーキテクチャ変更です。AIエージェントやオートメーションツールがサイトの能力を自律的に発見・活用できるようになります。
設計思想
従来のWordPressでは、プラグインが何をできるかを知るにはドキュメントを読むか、コードを読むしかありませんでした。Abilities APIは「能力（Ability）」という単位でプラグインやテーマが提供する機能を登録し、プログラムから発見・呼び出しできるようにします。
これが重要なのは、AIエージェントやオートメーションツールがWordPressサイトの能力を自律的に発見して活用できるようになるからです。
Abilities APIの基本構造
WordPress 7.0ではサーバーサイドとクライアントサイドの両方にAbilities APIが用意されます。
サーバーサイド（PHP）： WordPress 6.9で導入された基本的な登録・発見の仕組みが引き続き利用できます。
クライアントサイド（JavaScript）： 7.0で新たに導入される@wordpress/abilitiesパッケージがクライアントサイドの能力レジストリを提供します。7.0ではハイブリッドAbility（サーバーサイドとクライアントサイド両方で動作する能力の定義）、フィルタリングと検索、改善されたコマンドパレット（Cmd+K / Ctrl+K）との統合強化、Abilities Explorer（管理画面に新設される一覧画面）が追加されます。
プラグイン開発者はどう活用する？
自分のプラグインが提供する機能をAbilityとして登録することで、AIエージェント（Claude、ChatGPT等）がプラグインの機能を発見して自動的に活用できる、コマンドパレットにプラグインの操作が自動的に表示される、他のプラグインとの連携が容易になる、将来のワークフロー自動化機能との統合が得られる――といったメリットがあります。
import { registerAbility } from ‘@wordpress/abilities’;
registerAbility( ‘myplugin/generate-alt-text’, {
title: ‘画像のalt属性を自動生成’,
description: ‘アップロードされた画像をAIで解析してalt属性を生成します’,
category: ‘ai’,
callback: async ( context ) => {
// 実装
}
} );
WP-CLI v3.0（3月末安定版リリース予定）に先行して、Abilities APIの操作をCLIから行える wp ability コマンドパッケージが開発中です。WP-CLI経由とComposer経由でインストールできます。
wp package install wp-cli/ability-command:dev-main
# Composer 経由（プラグイン開発環境向け）
composer require wp-cli/ability-command:dev-main –dev
注意: Abilities APIの仕様は7.0リリースまでに変更される可能性があります。本番プラグインへの組み込みはRC1以降のAPIが安定してから行うことを推奨します。開発ブログのWhat’s New for Developersを定期的にチェックしてください。
3. WP AI Client ― プロバイダー非依存のAI統合基盤
WP AI Clientは、特定のAIプロバイダーに依存しないAI通信の抽象化レイヤーです。コアにはAIプロバイダーが同梱されず、設定しなければ外部通信も発生しません。OpenAI・Google・Anthropicの3社向けプロバイダーパッケージが既にプラグインディレクトリに公開済みです。
設計方針
WordPress 7.0のAI統合において最も重要な設計判断は、「特定のAIプロバイダーに依存しない」という方針です。コアにはAIプロバイダーが同梱されず、デフォルトでは外部へのAI関連通信も発生しません。サイトオーナーが明示的にプロバイダーの認証情報を設定して初めてAI機能が有効になります。
アーキテクチャ
WP AI Clientは、統一API（OpenAI、Anthropic、Google Geminiなど異なるプロバイダーを同じインターフェースで呼び出し可能）、認証管理（APIキーやOAuthトークンを安全に格納・管理）、Abilities APIとの統合、プライバシー重視の設計（ユーザーが設定しない限り外部通信なし）という構成で動作します。
中核は php-ai-client（Packagist公開済み）という共通PHPライブラリで、各プロバイダーへの通信を標準インターフェース越しに行います。管理画面には「Connectors」スクリーンがコアに追加され、APIキーの保存とプロバイダー選択がプラットフォームレベルのインフラとして提供されます。現在WordPressプラグインディレクトリにOpenAI Provider、Google AI Provider、Anthropic AI Providerの3つのプロバイダーパッケージが公開済みです。
プラグイン開発での活用
これまでAI連携プラグインを開発する場合、各AIプロバイダーのSDKを個別にインストールし、認証管理やエラーハンドリングを自前で実装する必要がありました。WP AI Clientの導入により、プラグインは統一されたAPIを通じてAI機能を呼び出すだけで済みます。
ユーザー側も、プラグインAでOpenAI、プラグインBでAnthropicと個別に設定するのではなく、WordPress設定画面で一箇所にAIプロバイダーの認証情報を入力すれば、すべてのAI対応プラグインがその設定を共有できます。
AI Experimentsプラグイン
WordPress開発チームは、コアのAI機能を先行実装する場として「AI Experiments」プラグインを公開しています。7.0サイクルではExcerpt Generation（AIによる投稿の抜粋自動生成）、Abilities Explorer（登録済みのAI能力を一覧表示・テストできる管理画面）、Content Summarization / Image Generation（バックエンドAPIのみ実装、UIは今後）が追加されています。
4. MCP Adapter ― AIエージェントとWordPressの橋渡し
MCP（Model Context Protocol）Adapterは、Abilities APIとAnthropicが提唱するMCPプロトコルの橋渡し役です。プラグインにAbilityを登録するだけで、MCP経由でClaude CodeやCursorなどのAIエージェントから操作可能になります。
MCPとは
MCPはAnthropicが提唱するオープンプロトコルで、AIモデルが外部のツールやサービスと標準化された方法で通信するための仕様です。すでにClaude、Cursor、GitHub CopilotなどのAIツールがMCPをサポートしています。
WordPress MCP Adapterの役割
WordPress 7.0のMCP Adapterは、Abilities APIとMCPの橋渡し役です。AIエージェントがWordPressサイトに接続すると、サイトが持つAbilitiesをMCPの仕様に沿って公開し、エージェントが自然言語で「新しい投稿を作って」「この画像のalt属性を更新して」といった操作をできるようにします。
開発者にとって重要なのは、自分のプラグインにAbilityを登録するだけで、MCP経由でAIエージェントから操作可能になるという点です。MCPの仕様を直接実装する必要はありません。
実用シナリオ
Claude CodeやCursorからWordPressの操作ができるようになるということは、AIエージェントに「今週の記事の下書きを全部レビューして誤字脱字を修正して」と指示する、自然言語でプラグインの設定変更やコンテンツ操作を実行する、CIパイプラインにAIエージェントを組み込んでコンテンツのQAを自動化する――といったワークフローが現実的になります。
開発者ブログ参考: MCP Adapterの詳細設計については、WordPress Developer Blogの「From Abilities to AI Agents: Introducing the WordPress MCP Adapter」が最も詳しい公式リソースです。
5. エディタのiframe化 ― 破壊的変更と移行ガイド
投稿エディタの常時iframe化はWordPress 7.1に延期されましたが、Gutenbergプラグイン環境では既に適用されています。グローバルdocument/windowへの直接アクセス、グローバルスコープのCSSセレクタなど、iframe化で動作しなくなるコードの洗い出しと修正を今から始めてください。
投稿エディタの常時iframe化は WordPress 7.1 に延期されました
2026年3月10日の公式Developer BlogにてWordPress 7.1に先送りされたことが正式に発表されました。ブロックとの互換性を慎重に確認するための措置です。ただし Gutenbergプラグインを有効化している環境では引き続きiframe化が適用されます。7.1に向けた移行準備は今のうちから進めておくことをおすすめします。
何が変わるのか（7.1に向けた予告）
WordPress 6.x系まで、投稿エディタはメインドキュメントのDOMの一部として描画されていました。サイトエディタでは既にiframe化されていましたが、投稿エディタは違いました。7.1ではこれが統一され、投稿エディタも常にiframe内で実行されます。
APIバージョンが3未満のブロックが挿入されている場合はiframe化が無効になるフォールバック機構があります。
なぜiframe化するのか
スタイル分離（サイトのCSSとエディタのCSSが完全に分離され、WYSIWYGの精度が大幅に向上）、サイトスタイルの漏れ防止（テーマやプラグインのCSSがエディタ内に漏れてレイアウトを崩す問題が解消）、セキュリティ（iframe境界によるサンドボックス化でブロック間の意図しない干渉を防止）が主な理由です。
影響を受けるコード
// グローバルdocumentへの直接アクセス
document.querySelector( ‘.wp-block-my-plugin’ );
// グローバルwindowオブジェクトへの依存
window.addEventListener( ‘resize’, handler );
// グローバルスコープのCSSセレクタ
/* .editor-styles-wrapper .my-block { … } */
移行対応
ブロックのAPIバージョンを3に上げる、グローバルなdocument/windowへの直接参照を避けBlock EditorのAPIを使ったDOM操作に切り替える、ブロックスタイルシートがiframe内でも正しく読み込まれるか確認する、editorStyleで登録したCSSがiframe内にインジェクトされることを確認する――これらが主要な対応ポイントです。
対応必須（7.1に向けて）: グローバルDOMを直接操作しているブロックプラグインは、7.1で確実に影響を受けます。Gutenbergプラグインを使ったテスト環境で今すぐ動作確認を始め、必要な修正を行ってください。
6. DataViews & DataForm の拡張
従来のWP_List_Tableに代わるDataViewsコンポーネントの適用範囲がさらに広がり、DataFormにはバリデーション・新コントロール（Combobox、AdaptiveSelect等）が追加されます。WP_List_Tableを直接拡張しているプラグインは表示崩れに注意が必要です。
DataViewsの新機能
Activityレイアウト（アクティビティログ的な時系列表示のための新しいレイアウトタイプ）と、サードパーティタイプ登録の基盤（将来のリリースでカスタム投稿タイプなどを第三者がDataViewsに登録できる仕組みの基礎）が追加されます。
DataFormの新機能
Detailsレイアウト、新コントロール（Combobox、AdaptiveSelect等）、すべてのコントロールでのバリデーションサポート、Panelレイアウトの専用Editボタンが追加されます。
プラグイン開発者への影響
WP_List_Tableを直接拡張したり、管理画面の投稿一覧やページ一覧をCSSでカスタマイズしているプラグインは、DataViewsへの移行に伴う表示崩れに注意が必要です。DataFormを使ったプラグイン設定画面の構築方法については、Developer Blogの「How to use DataForm to create plugin settings pages」が参考になります。
7. PHP-onlyブロック登録 ― JavaScriptなしでブロックを作る
PHPだけでブロックを定義し、インスペクターコントロールを自動生成させることができるようになります。JavaScriptのビルド環境（webpack等）が不要になり、PHPしか書けない開発者でもカスタムブロックを作れます。ただしインタラクティブなプレビューが必要なブロックには向きません。
概要
従来、カスタムブロックの開発にはJavaScript（React）でのフロントエンド実装が必須でした。7.0では、PHPだけでブロックを定義し、インスペクターコントロール（サイドバーの設定パネル）を自動生成させることができます。
サーバーサイドレンダリングを前提としたブロックであれば、JavaScriptのビルド環境（webpack, @wordpress/scripts等）を用意する必要がなくなります。
メリットと制限事項
PHPしか書けない開発者でもカスタムブロックを作れる、ビルドプロセスが不要になりプラグインの配布がシンプルになる、サーバーサイドレンダリングパターンとの相性が良い、Block APIへの登録が自動で行われる――というメリットがあります。一方、エディタ上でのインタラクティブなプレビューやリアルタイム編集のUIが必要なブロックには向きません。あくまで「サーバーで描画される静的ブロック」の開発効率を上げるための手段です。
8. Block Bindings & パターンオーバーライドの強化
Block Bindingsの仕組みが拡張され、コアブロックだけでなくカスタムの動的ブロックでもパターンオーバーライドがサポートされます。パターンのContent-Only編集モードがデフォルト化され、コンテンツ制作者がデザイン構造を壊しにくくなります。
パターンオーバーライドとは
ブロックパターンの一部を「可変」に設定し、パターンの利用箇所ごとに異なるコンテンツを挿入できる仕組みです。たとえば、ヒーローセクションのパターンで「見出しテキスト」と「背景画像」だけを差し替え可能にする、といった使い方です。
7.0での拡張
カスタム動的ブロックのサポート、サーバーサイドからの部分同期推論、柔軟なデータバインディング（カスタムフィールド、外部API、動的データソースとブロックの紐付け）が追加されます。
WordPress 7.0ではパターンがContent-Only編集モードをデフォルトとして動作するようになります。フィールドはブロックアイコンとフライアウトメニューでグループ化され、コンテンツ制作者向けにデザイン操作を抑制した表示になります。構造的な編集が必要な場合はパターンをデタッチすることでフルアクセスに戻せます。
非同期パターンでのContent-Onlyモードを無効化するには以下のいずれかを使います。
add_filter( ‘block_editor_settings_all’, function( $settings ) {
$settings[‘disableContentOnlyForUnsyncedPatterns’] = true;
return $settings;
} );
// JavaScript dispatch
wp.data.dispatch( ‘core/block-editor’ ).updateSettings( {
disableContentOnlyForUnsyncedPatterns: true
} );
9. ブロック単位のカスタムCSS
個々のブロックインスタンスに対してカスタムCSSを追加できる仕組みが正式搭載されます。サイドバーの「高度な設定」→「追加CSS」から記述でき、.has-custom-cssクラスが動的に付与されます。Global StylesのカスタムCSSがblock.jsonのfeature selectorを正しく参照するようにもなりました。
Gutenberg 22.5で導入され、WordPress 7.0に搭載されるこの機能は、個々のブロックインスタンスに対してカスタムCSSを追加できる仕組みです。
使い方
ブロックのサイドバー設定 → 「高度な設定」 → 「追加CSS」から、そのブロックだけに適用されるCSSを記述できます。CSSが追加されると、エディタとフロントエンドの両方で.has-custom-cssクラスが動的に付与されます。
開発者の視点
便利な反面、管理上の課題も生じます。どのブロックにカスタムCSSが設定されているかを把握しにくく、将来的なメンテナンスが困難になる可能性があります。カスタムCSSの有無を示すインジケータの実装についてはオープンチケットで議論が進行中です。
テーマ開発者としては、.has-custom-cssクラスの存在を前提にした処理（たとえばカスタムCSS適用ブロックのスタイル優先度調整）を検討しておくとよいでしょう。
関連する変更として、Global StylesのカスタムCSSがブロックで定義されたfeature selectorを正しく参照するようになりました。block.json に selectors.css エントリーを定義すると、Global Stylesの「追加CSS」がその内側要素（画像・SVGなど）を正確なターゲットに当てられるようになります。
{
“selectors”: {
“css”: “.wp-block-my-plugin__inner”
}
}
10. リアルタイムコラボレーションのトランスポート設計
デフォルトのトランスポートはHTTP Long Pollingで、あらゆるWordPress環境で動作します。競合解決アルゴリズムにはCRDTが正式採用され、WebRTCは廃棄されました。7.0正式リリース時はデフォルトオフで、「設定→投稿」から手動で有効化します。
リアルタイム共同編集のトランスポートレイヤー設計は、インフラ寄りの開発者にとって興味深い技術的判断が含まれています。
技術スタックとして、WebRTCは信頼性の問題（多くのホスティング環境で非対応）から採用見送りとなりました。競合解決アルゴリズムにはOTではなくCRDT（Conflict-free Replicated Data Type）が正式採用され、データ永続化はCRDTの更新データをwp_sync_storageという専用内部投稿タイプのpost_metaに永続保存する設計です。
Xserverの共用サーバーではWebSocketやSSEも動作しません。ロングポーリングでの実装については「XserverでWebSocketもSSEも動かない」で解説しています
デフォルト: HTTP Long Polling（確定）
WordPress 7.0はHTTP Long Pollingをデフォルトの同期プロバイダーとして採用します。この選択は「あらゆるWordPress環境で動作する」ことを最優先にした結果です。共有ホスティングやCDNの背後にある環境でも、特別なサーバー設定なしで機能します。
拡張: プロバイダーパターンによるカスタム実装
ストレージとトランスポートレイヤーは差し替え可能な設計になっており、ホスティング会社やプラグインが独自のSyncプロバイダーを提供できます。
[Editor] ⇄ [Sync Provider Interface]
├── HTTP Long Polling (default / コアバンドル)
└── Custom Provider (host / plugin 提供)
[CRDT Updates] → post_meta on wp_sync_storage (永続化)
同時編集者数の制限と設定
クライアントサイドのGutenbergコードではデフォルトで同時編集者数を2名に制限しています。ホスティング会社は独自プロバイダーを提供するか、wp-config.phpの定数で上限を変更することができます。
【追記】7.0正式リリース時にRTCはデフォルトオフに変更されました
RC1の時点でRTCの初期状態が「オフ」に確定しました。7.0正式リリース後は管理画面の「設定 → 投稿」から手動で有効化する必要があります。ベータ期間中にオプションを有効にしていたサイトも、7.0へのアップグレード後は自動的にオフになります（オプション名の変更を伴うため）。
開発チームはベータ中はデフォルトオンにしてより広くフィードバックを収集しましたが、ホスティング環境への負荷を考慮し慎重な展開を選択しました。将来のバージョンでデフォルトオンになる方針（リリースリードがその方向性を明言）です。Gutenbergプラグインでは引き続き有効状態が保持されます。
オフライン編集とコンフリクト解決（CRDT）
ネットワーク切断時も編集作業を継続でき、再接続時にサーバーと同期する仕組みが実装されています。CRDTの特性上、同一箇所への並行編集も数学的に矛盾なくマージされます。更新データは定期的に圧縮（compaction）され、リクエストはバッチ処理されるためサーバー負荷も最小化されています。
11. クライアントサイドメディア処理
【追記】クライアントサイドメディア処理はWordPress 7.0のリリース対象から除外されました
「画像アップロード時の処理をブラウザ側で行うことでアップロードが速くなる」と紹介していましたが、RC1のリリース準備中に重大な品質問題が判明し、WordPress 7.0のリリース対象から除外されました。将来のバージョンでの実装が期待されます。
判明した問題の詳細：
- 処理速度：M4 Pro MacBook Proという高性能な環境でも、JPEGの処理に約19秒、AVIFでは29〜55秒かかることが判明。同種の処理を行う他のツールが3秒未満で完了しているのと比べて著しく遅く、実用水準に達していないと判断
- ブラウザ対応：現時点でChromiumベース（Chrome・Edge）のみ対応。SafariとFirefoxでは動作しない
- パッケージサイズ：この機能に使用するWASMライブラリ（vips）が約13MBあり、WordPress 6.9比で約33MBのパッケージサイズ増加の一因となっていた
開発者への影響：wp_handle_uploadフィルタ周辺のコードに「クライアントサイド処理済みデータを考慮する」準備は不要になりました。ただし将来バージョンで実装される際には再度対応が必要になる可能性があります。
12. その他の注目変更点まとめ
CodeMirror v5.65.40更新、HtmlRendererコンポーネント追加、Pullquoteブロック非推奨化、View Transitions適用、WP-CLI wp blockコマンド追加、wp-env Playground phpMyAdmin対応など、開発者が知っておくべき変更点が多数あります。
| 変更点 | 詳細 |
|---|---|
| CodeMirrorの更新 | v5.65.40に更新。拡張性とライブラリオプションが改善 |
| HtmlRendererコンポーネント | HTML→Reactレンダリングの新コンポーネント。不要な<div>ラッパーの削除でフロントエンドとエディタのスタイル一致度が向上 |
| Pullquoteブロックの非推奨化 | Gutenberg 22.2で非推奨に。Quoteブロックへの移行を推奨 |
| Anchorサポートの拡充 | 動的ブロックでもアンカー（id属性）がサポート。ブロックコメント区切りに保存され、フロントエンドで動的レンダリング |
| textAlignのブロック対応拡大 | Heading、Verse、コメント関連ブロック（Author Name, Content, Date等）でtextAlignが完全サポート |
| テキストインデント | 長年リクエストされていたテキストインデント機能がブロックエディタに追加 |
| テキストカラムサポート | 段落ブロックでのテキストカラム（段組み）表示が可能に |
| View Transitions | 管理画面内の画面遷移にCSSのView Transitions APIが適用。フロントエンドは別プラグインで提供予定 |
| theme.jsonのデフォルト変更 | リンクのtext-decorationデフォルト（underline）が削除。ブラウザデフォルトに委譲 |
| WordPress Studio CLI更新 | v1.7.0でCLI操作が大幅強化。Claude CodeやCursorなどのAI開発ツールとの連携が容易に |
| WP-CLI wp block コマンド | ブロックエンティティへの読み取り専用アクセスと、パターン・テンプレートのエクスポートが可能な新コマンド。WP-CLI v3.0（3月末安定版予定）に先行してdev依存でインストール可 |
| wp-env Playground で phpMyAdmin 対応 | wp-envのPlaygroundランタイムがphpMyAdminをサポートし、Dockerランタイムとの機能パリティを達成。.wp-env.json に "phpmyadmin": true, "runtime": "playground" を追加して有効化。起動後は http://localhost:8888/phpmyadmin でアクセス可能 |
| Navigationオーバーレイが正式版に | カスタマイズ可能なNavigation Overlayが実験的フラグを外れ7.0に正式搭載。「Create overlay」ボタンで各種デザインパターンを選択可能 |
| UIパッケージに新コンポーネント追加 | Admin再設計を支援するUIパッケージに新プリミティブが追加。IconButton・Button（minimum switch）・Textarea・Tabs・Dialogの各コンポーネントが利用可能に |
13. PHP 7.4最低要件化への対応
最低PHPバージョンがPHP 7.4に引き上げられ、推奨はPHP 8.5です。PHP 7.4のtyped propertiesやarrow関数が使えるようになり、コードベースの型安全性が向上します。CI/CDのPHPマトリクスも更新が必要です。
WordPress 7.0では最低PHPバージョンがPHP 7.4に引き上げられます。PHP 7.2 / 7.3は公式サポート対象外となります。WordPress 7.0はPHP 8.5のベータサポートを導入する最初のメジャーリリースでもあり、コアチームはDataViewsの管理画面など新機能のパフォーマンスを最大限に活かすためにPHP 8.5を推奨しています。最低要件はPHP 7.4ですが、CI/CD環境のPHPマトリクスもPHP 8.1以上、理想はPHP 8.5を含めた更新を推奨します。
なぜPHP 7.4が必要か
型付きプロパティ（PHP 7.4のtyped propertiesにより型安全性が向上しIDEやAIツールの解析精度も上がる）、外部ライブラリ要件（AI関連のSDKやコラボレーション機能のライブラリの多くがPHP 7.4以上を要求）、パフォーマンス（OPcacheのpreloading対応など性能面で優位）、セキュリティ（PHP 7.2/7.3はすでにEOLでセキュリティパッチが提供されていない）が主な理由です。
プラグイン開発者の対応
自分のプラグインのRequires PHPヘッダーを見直し、7.4以上を要件にしてPHP 7.4以降の構文（アロー関数、null合体代入演算子、型付きプロパティ等）を活用できるよう整備しましょう。CIパイプラインのPHPマトリクスも更新が必要です。
14. 開発者向けマイグレーションチェックリスト
GAの4月9日に向けて、即座に対応すべき高優先度項目（PHP 7.4確認・6.9.4適用・iframe化テスト・グローバルDOM参照の洗い出し）、RC期間中の中優先度項目、GA前の低優先度項目を3段階でまとめます。
即座に対応すべき項目（高優先度）
|
1 2 3 4 5 6 7 |
☐ PHPバージョンが7.4以上であることを確認（本番・ステージング・ローカルすべて） ☐ WordPress 6.9.4 へのセキュリティアップデートを本番環境に適用する ☐ ステージング環境にWordPress 7.0 RC2をインストールして最終テスト ☐ ブロックがiframe化されたエディタで正常に動作するかテスト（Gutenbergプラグインで再現可能） ☐ グローバルdocument/windowに直接アクセスしているJavaScriptを洗い出す ☐ 管理画面のカスタムCSSが新しいデザイントークンと競合しないか確認 ☐ readme.txt の "Tested up to" を 7.0 に更新する（RC1公開後はこれが必須） |
RC期間中に対応すべき項目（中優先度）
|
1 2 3 4 5 6 |
☐ ブロックのAPIバージョンを3に上げてテスト（7.1に向けたiframe化対応の先行対応） ☐ WP_List_Tableを拡張しているコードのDataViews互換性を確認 ☐ theme.jsonのlink text-decoration変更の影響をテーマで確認 ☐ Pullquoteブロックの非推奨化への対応（Quoteブロックへの移行ガイダンス） ☐ パターンのContent-Only編集モードがデフォルト化されることによる表示への影響確認 ☐ RTCが7.0でデフォルトオフになることをユーザー向けドキュメント・UIに反映する |
GA前までに対応すべき項目（低優先度・将来準備）
|
1 2 3 4 5 6 |
☐ プラグインの機能をAbilities APIに登録する設計検討 ☐ WP AI Client / Connector機能との連携可能性の調査 ☐ DataFormを使った設定画面のモダナイゼーション計画 ☐ PHP 7.4構文の積極活用によるコード品質向上 ☐ WP-CLI wp block / wp ability コマンドの動作検証（v3.0正式版リリース後） ☐ クライアントサイドメディア処理（将来バージョン実装時に備えwp_handle_upload周辺を把握しておく） |
WordPress 7.0の進化と並行して、ブラウザだけで本物のWordPressが動く「My WordPress（my.wordpress.net）」も2026年3月に登場しました。WebAssembly技術でサーバー不要・登録不要で使えるこのサービスは、プラグインのテスト環境としても活用できます。
15. まとめ ― 7.0は「プラットフォーム化」への転換点
WordPress 7.0の技術的変更は「AIファーストの拡張性」「エディタのサンドボックス化」「PHP開発者の再包摂」の3方向に集約されます。7.0はGutenberg Phase 3の始まりであり、今の段階で基盤を理解しプラグインやテーマのアーキテクチャを先回りして整えておくことが2026年後半以降の競争力に直結します。
第一に、AIファーストの拡張性。Abilities API、WP AI Client、MCP Adapterという三つの柱は、WordPressを「AIエージェントが操作できるプラットフォーム」に変貌させるための基盤です。これは一過性のAIブームへの追従ではなく、プラグインエコシステム全体のインタラクション方式を標準化するインフラ投資です。Connector機能とOpenAI・Google・Anthropic向けプロバイダーパッケージが揃い、この基盤は着実に動き始めています。
第二に、エディタのサンドボックス化。投稿エディタのiframe化は7.1に延期されましたが、Gutenbergプラグイン環境では既に現実です。スタイル分離とWYSIWYG精度の向上という実利的な理由だけでなく、将来のエディタ拡張への布石と読むこともできます。今から対応準備を進めておくことが重要です。
第三に、PHP開発者の再包摂。PHP-onlyブロック登録は「ブロック開発にはReactが必須」という参入障壁を下げる重要な変更です。WordPressのプラグインエコシステムにはPHPしか書かない開発者が多数おり、彼らがブロックエディタの世界に参入しやすくなります。
7.0はGutenberg Phase 3の「始まり」です。コラボレーション機能もAI統合もまだ初期段階であり、7.1、7.2、さらにその先のリリースで徐々に成熟していくでしょう。今の段階で基盤を理解し、プラグインやテーマのアーキテクチャを先回りして整えておくことが、2026年後半以降の競争力に直結します。
RC2も公開され、正式リリースの4月9日までRC3（4月2日）を残すのみとなりました。ぜひWordPress 7.0 RC1の公式アナウンスおよび最新のMake WordPress Core情報を確認し、最終テストに参加してみてください。
コメント