【開発者向け】WordPress 7.0の技術的変更点を深掘り ― Abilities API・AI Client・DataViews・iframe化のすべて

【開発者向け】WordPress 7.0の技術的変更点を深掘り ― Abilities API・AI Client・DataViews・iframe化のすべて WordPress
この記事は約20分で読めます。
  1. 1. リリースタイムラインと開発体制の背景
    1. 2025年の開発停滞と技術的負債の清算
    2. 7.0のリリーススケジュール
  2. 2. Abilities API & Workflows API ― WordPressの能力をマシンリーダブルに
    1. 設計思想
    2. Abilities APIの基本構造
    3. プラグイン開発者はどう活用する？
  3. 3. WP AI Client ― プロバイダー非依存のAI統合基盤
    1. 設計方針
    2. アーキテクチャ
    3. プラグイン開発での活用
    4. AI Experimentsプラグイン
  4. 4. MCP Adapter ― AIエージェントとWordPressの橋渡し
    1. MCPとは
    2. WordPress MCP Adapterの役割
    3. 実用シナリオ
  5. 5. エディタの完全iframe化 ― 破壊的変更と移行ガイド
    1. 何が変わるのか
    2. なぜiframe化するのか
    3. 影響を受けるコード
    4. 移行対応
  6. 6. DataViews & DataForm の拡張
    1. DataViewsの新機能
    2. DataFormの新機能
    3. プラグイン開発者への影響
  7. 7. PHP-onlyブロック登録 ― JavaScriptなしでブロックを作る
    1. 概要
    2. メリット
    3. 制限事項
  8. 8. Block Bindings & パターンオーバーライドの強化
    1. パターンオーバーライドとは
    2. 7.0での拡張
  9. 9. ブロック単位のカスタムCSS
    1. 使い方
    2. 開発者の視点
  10. 10. リアルタイムコラボレーションのトランスポート設計
    1. デフォルト: HTTP Long Polling
    2. 拡張: WebSocket対応
    3. オフライン編集とコンフリクト解決
  11. 11. クライアントサイドメディア処理
    1. 技術的なポイント
  12. 12. その他の注目変更点まとめ
  13. 13. PHP 7.4最低要件化への対応
    1. なぜPHP 7.4が必要か
    2. プラグイン開発者の対応
  14. 14. 開発者向けマイグレーションチェックリスト
    1. 即座に対応すべき項目（高優先度）
    2. Beta期間中に対応すべき項目（中優先度）
    3. GA前までに対応すべき項目（低優先度・将来準備）
  15. 15. まとめ ― 7.0は「プラットフォーム化」への転換点

WordPress 7.0（リリース予定: 2026年4月9日）は、Gutenberg Phase 3の本格始動だけでなく、プラグイン開発者・テーマ開発者にとって無視できない技術的な変更を数多く含んでいます。

この記事では、一般ユーザー向けの機能紹介では触れきれないAPI変更、アーキテクチャの刷新、ブロック開発の新パラダイム、そして互換性に影響する破壊的変更を掘り下げて解説します。

Beta 1（2026年2月19日公開）、Beta 2を経て、RC1（3月19日予定）に向けたテストが活発に進んでいるいま、この記事を参考にプラグインとテーマの互換性検証を始めてください。

この記事の対象読者

  • WordPressプラグイン・テーマの開発者
  • WordPress案件を扱うWeb制作会社のエンジニア
  • WordPressのアーキテクチャ変遷に関心のあるエンジニア
  • AI × CMSの連携基盤に興味がある開発者

1. リリースタイムラインと開発体制の背景

WordPress 7.0のコードフリーズに至るまでのタイムラインを整理しておきます。技術的な判断の背景を理解すると、「なぜこのAPIが入ったのか」「なぜこの機能が延期されたのか」が見えてきます。

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-19 RC1 文字列フリーズ（翻訳開始）
2026-04-09 GA WordCamp Asia Contributor Day

Beta 1からGAまで約7週間。この間にプラグイン・テーマの互換性テストを完了する必要があるため、時間は潤沢とは言えません。

2. Abilities API & Workflows API ― WordPressの能力をマシンリーダブルに

能力の登録→発見→実行のシーケンス図

Abilities APIは、WordPress 7.0で最も注目すべきアーキテクチャ変更のひとつです。端的に言えば、「このWordPressサイトに何ができるか」を構造化された形式で公開する仕組みです。

設計思想

従来の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等）がプラグインの機能を発見して自動的に活用できる
  • コマンドパレットにプラグインの操作が自動的に表示される
  • 他のプラグインとの連携が容易になる（能力ベースのプラグイン間通信）
  • 将来のWordPressリリースでのワークフロー自動化機能との統合
// Ability登録のイメージ（概念コード）
import { registerAbility } from ‘@wordpress/abilities’;

registerAbility( ‘myplugin/generate-alt-text’, {
  title: ‘画像のalt属性を自動生成’,
  description: ‘アップロードされた画像をAIで解析してalt属性を生成します’,
  category: ‘ai’,
  callback: async ( context ) => {
// 実装
  }
} );

⚠️ 注意: Abilities APIの仕様は7.0リリースまでに変更される可能性があります。本番プラグインへの組み込みはRC1以降のAPIが安定してから行うことを推奨します。開発ブログのWhat’s New for Developersを定期的にチェックしてください。

3. WP AI Client ― プロバイダー非依存のAI統合基盤

プロバイダー非依存のAPI設計概念図

WP AI Clientは、WordPressコア内に搭載されるAIモデルとの通信を抽象化するレイヤーです。

設計方針

WordPress 7.0のAI統合において最も重要な設計判断は、「特定のAIプロバイダーに依存しない」という方針です。コアにはAIプロバイダーが同梱されず、デフォルトでは外部へのAI関連通信も発生しません。サイトオーナーが明示的にプロバイダーの認証情報を設定して初めてAI機能が有効になります。

アーキテクチャ

WP AI Clientは以下の構成で動作します。

  • 統一API ― OpenAI、Anthropic、Google Geminiなど異なるプロバイダーを同じインターフェースで呼び出し可能
  • 認証管理 ― APIキーやOAuthトークンを安全に格納・管理する仕組み
  • Abilities APIとの統合 ― AI関連のAbility（テキスト生成、画像解析、要約など）を標準的な形式で提供
  • プライバシー重視 ― ユーザーが設定しない限り外部通信なし。データ送信の明示的な同意フロー

プラグイン開発での活用

これまで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 による投稿の抜粋自動生成（エディタUI付き）
  • Abilities Explorer ― 登録済みのAI能力を一覧表示・テストできる管理画面
  • Content Summarization / Image Generation ― バックエンドAPIのみ実装（UIは今後）

4. MCP Adapter ― AIエージェントとWordPressの橋渡し

AI Agent → MCP → WordPress Abilitiesの連携フロー図

WordPress 7.0のAI戦略の中で見逃せないのがMCP（Model Context Protocol）Adapterです。

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化 ― 破壊的変更と移行ガイド

スタイル分離とWYSIWYG精度向上を示す構造図

WordPress 7.0では、投稿エディタが常にiframe内で動作するようになります。これは最も広範囲に影響する破壊的変更のひとつです。

何が変わるのか

WordPress 6.x系まで、投稿エディタはメインドキュメントのDOMの一部として描画されていました。サイトエディタでは既にiframe化されていましたが、投稿エディタは違いました。7.0ではこれが統一され、投稿エディタも常にiframe内で実行されます。

ただし、APIバージョンが3未満のブロックが挿入されている場合はiframe化が無効になるフォールバック機構があります。

なぜiframe化するのか

  • スタイル分離: サイトのCSSとエディタのCSSが完全に分離され、WYSIWYG（見たまま編集）の精度が大幅に向上する
  • サイトスタイルの漏れ防止: テーマやプラグインのCSSがエディタ内に漏れてレイアウトを崩す問題が解消される
  • セキュリティ: iframe境界によるサンドボックス化でブロック間の意図しない干渉を防止

影響を受けるコード

iframe化により、以下のようなコードが動作しなくなる可能性があります。

// ❌ 動作しなくなる可能性のあるパターン

// グローバルdocumentへの直接アクセス
document.querySelector( ‘.wp-block-my-plugin’ );

// グローバルwindowオブジェクトへの依存
window.addEventListener( ‘resize’, handler );

// グローバルスコープのCSSセレクタ
/* .editor-styles-wrapper .my-block { … } */

移行対応

影響を受けるブロックの移行ガイドはWordPressハンドブックに掲載されています。主要な対応ポイントは以下のとおりです。

  • ブロックのAPIバージョンを3に上げる
  • グローバルなdocument/windowへの直接参照を避け、Block EditorのAPIを使ったDOM操作に切り替える
  • ブロックスタイルシートがiframe内でも正しく読み込まれるか確認する
  • editorStyleで登録したCSSがiframe内にインジェクトされることを確認する

🔴 対応必須: グローバルDOMを直接操作しているブロックプラグインは、7.0で確実に影響を受けます。Beta期間中にステージング環境でテストし、必要な修正を行ってください。

6. DataViews & DataForm の拡張

従来のWP List Tableと新DataViewsの比較スクリーンショット

従来のWordPress管理画面の一覧表示はWP_List_Tableクラスに基づいていました。WordPress 7.0ではDataViewsコンポーネントの適用範囲がさらに広がり、管理画面のモダナイゼーションが進みます。

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-onlyブロック登録の実際のコード

WordPress 7.0で導入されるPHP-onlyブロック登録は、ブロック開発のパラダイムを大きく変える可能性があります。

概要

従来、カスタムブロックの開発にはJavaScript（React）でのフロントエンド実装が必須でした。7.0では、PHPだけでブロックを定義し、インスペクターコントロール（サイドバーの設定パネル）を自動生成させることができます。

サーバーサイドレンダリングを前提としたブロックであれば、JavaScriptのビルド環境（webpack, @wordpress/scripts等）を用意する必要がなくなります。

メリット

  • PHPしか書けない開発者でもカスタムブロックを作れる
  • ビルドプロセスが不要になり、プラグインの配布がシンプルになる
  • サーバーサイドレンダリングパターンとの相性が良い
  • Block APIへの登録が自動で行われる

制限事項

エディタ上でのインタラクティブなプレビューやリアルタイム編集のUIが必要なブロックには向きません。あくまで「サーバーで描画される静的ブロック」の開発効率を上げるための手段です。

8. Block Bindings & パターンオーバーライドの強化

動的ブロックとパターンの関係を示す概念図

WordPress 7.0では、Block Bindingsの仕組みが拡張され、パターンオーバーライドがカスタムの動的ブロックでもサポートされるようになります。

パターンオーバーライドとは

ブロックパターンの一部を「可変」に設定し、パターンの利用箇所ごとに異なるコンテンツを挿入できる仕組みです。たとえば、ヒーローセクションのパターンで「見出しテキスト」と「背景画像」だけを差し替え可能にする、といった使い方です。

7.0での拡張

  • カスタム動的ブロックのサポート ― コアブロックだけでなく、カスタムブロックでもパターンオーバーライドが利用可能に
  • サーバーサイドからの部分同期推論 ― パターンがどのブロックを部分的に同期できるかをサーバーサイドから推論する機能
  • 柔軟なデータバインディング ― カスタムフィールド、外部API、動的データソースとブロックの紐付けがより柔軟に

この強化により、テーマ開発者やサイトビルダーは「デザインは統一するが、コンテンツは場所ごとに変える」というパターンをより効率的に実装できるようになります。

9. ブロック単位のカスタムCSS

Gutenberg 22.5で導入され、WordPress 7.0に搭載されるこの機能は、個々のブロックインスタンスに対してカスタムCSSを追加できる仕組みです。

使い方

ブロックのサイドバー設定 → 「高度な設定」 → 「追加CSS」から、そのブロックだけに適用されるCSSを記述できます。CSSが追加されると、エディタとフロントエンドの両方で.has-custom-cssクラスが動的に付与されます。

開発者の視点

便利な反面、管理上の課題も生じます。どのブロックにカスタムCSSが設定されているかを把握しにくく、将来的なメンテナンスが困難になる可能性があります。カスタムCSSの有無を示すインジケータの実装についてはオープンチケットで議論が進行中です。

テーマ開発者としては、.has-custom-cssクラスの存在を前提にした処理（たとえばカスタムCSS適用ブロックのスタイル優先度調整）を検討しておくとよいでしょう。

10. リアルタイムコラボレーションのトランスポート設計

リアルタイム共同編集のトランスポートレイヤー設計は、インフラ寄りの開発者にとって興味深い技術的判断が含まれています。

デフォルト: HTTP Long Polling

WordPress 7.0はHTTP Long Pollingをデフォルトの同期プロバイダーとして採用します。この選択は「あらゆるWordPress環境で動作する」ことを最優先にした結果です。共有ホスティングやCDNの背後にある環境でも、特別なサーバー設定なしで機能します。

拡張: WebSocket対応

より低遅延な同期が必要な場合、ホスティング会社やプラグインがWebSocketベースのSyncプロバイダーを提供できます。アーキテクチャは以下のようにプロバイダーパターンで設計されています。

// Syncプロバイダーの概念構造
[Editor] ⇄ [Sync Provider Interface]
   ├── HTTP Long Polling (default)
   ├── WebSocket (plugin/host provided)
   └── Custom Provider (extensible)

Beta期間中のテスト結果では、標準的なホスティング環境でHTTP Long Pollingが安定動作する一方、共有ホスティングでは同期遅延が報告されています。WebSocket対応環境では体感できるレベルで同期が高速化するため、マネージドWordPressホスティングでの利用が推奨されます。

オフライン編集とコンフリクト解決

ネットワーク切断時も編集作業を継続でき、再接続時にサーバーと同期する仕組みが実装されています。同一箇所の競合が発生した場合のマージ戦略はOT（Operational Transformation）ベースの手法が採用されています。

11. クライアントサイドメディア処理

WordPress 7.0では、画像アップロード時のリサイズと圧縮処理がブラウザ側（クライアントサイド）で実行されるようになります。

技術的なポイント

  • Canvas APIを活用した画像リサイズ・圧縮をアップロード前に実行
  • サーバーへ送信されるデータ量が削減され、アップロード時間が短縮
  • サーバー側のCPU・メモリ負荷が軽減
  • 共有ホスティングのメモリ制限による画像処理エラーが減少

プラグイン開発者にとっては、wp_handle_uploadフィルタで受け取る画像データが既にクライアントサイドで処理済みである可能性を考慮する必要があります。画像処理系プラグインは、処理の重複や品質の低下がないか確認してください。

12. その他の注目変更点まとめ

上記以外にも、開発者が知っておくべき変更点が多数あります。

変更点 詳細
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開発ツールとの連携が容易に

13. PHP 7.4最低要件化への対応

WordPress 7.0では最低PHPバージョンがPHP 7.4に引き上げられます。PHP 7.2 / 7.3は公式サポート対象外となります。推奨はPHP 8.3以上です。

なぜPHP 7.4が必要か

  • 型付きプロパティ ― PHP 7.4のtyped propertiesにより、コードベースの型安全性が向上し、IDEやAIツールの解析精度も上がる
  • 外部ライブラリ要件 ― AI関連のSDKやコラボレーション機能に使用するライブラリの多くがPHP 7.4以上を要求
  • パフォーマンス ― PHP 7.4はPHP 7.2に対してOPcacheのpreloading対応など性能面で優位
  • セキュリティ ― PHP 7.2/7.3はすでにEOL（End of Life）を迎えており、セキュリティパッチが提供されていない

プラグイン開発者の対応

自分のプラグインのRequires PHPヘッダーを見直し、7.4以上を要件にしてPHP 7.4以降の構文（アロー関数、null合体代入演算子、型付きプロパティ等）を活用できるよう整備しましょう。CIパイプラインのPHPマトリクスも更新が必要です。

14. 開発者向けマイグレーションチェックリスト

開発者向け確認項目を整理したインフォグラフィック

WordPress 7.0のGA（4月9日）に向けて、開発者が今すぐ着手すべき項目をチェックリスト形式でまとめます。

即座に対応すべき項目（高優先度）

  • ☐ PHPバージョンが7.4以上であることを確認（本番・ステージング・ローカルすべて）
  • ☐ ステージング環境にWordPress 7.0 Beta 2をインストール
  • ☐ ブロックがiframe化されたエディタで正常に動作するかテスト
  • ☐ グローバルdocument/windowに直接アクセスしているJavaScriptを洗い出す
  • ☐ 管理画面のカスタムCSSが新しいデザイントークンと競合しないか確認

Beta期間中に対応すべき項目（中優先度）

  • ☐ ブロックのAPIバージョンを3に上げてテスト
  • ☐ WP_List_Tableを拡張しているコードのDataViews互換性を確認
  • ☐ wp_handle_uploadフック周辺のコードがクライアントサイドメディア処理と競合しないか確認
  • ☐ theme.jsonのlink text-decoration変更の影響をテーマで確認
  • ☐ Pullquoteブロックの非推奨化への対応（Quoteブロックへの移行ガイダンス）

GA前までに対応すべき項目（低優先度・将来準備）

  • ☐ プラグインの機能をAbilities APIに登録する設計検討
  • ☐ WP AI Clientとの連携可能性の調査
  • ☐ DataFormを使った設定画面のモダナイゼーション計画
  • ☐ PHP 7.4構文の積極活用によるコード品質向上

15. まとめ ― 7.0は「プラットフォーム化」への転換点

WordPress 7.0の技術的変更を総括すると、大きく3つの方向性が見えます。

第一に、AIファーストの拡張性。Abilities API、WP AI Client、MCP Adapterという三つの柱は、WordPressを「AIエージェントが操作できるプラットフォーム」に変貌させるための基盤です。これは一過性のAIブームへの追従ではなく、プラグインエコシステム全体のインタラクション方式を標準化するインフラ投資です。

第二に、エディタのサンドボックス化。iframe化はスタイル分離とWYSIWYG精度の向上という実利的な理由だけでなく、将来のエディタ拡張（マイクロフロントエンド的なブロックの独立実行等）への布石と読むこともできます。

第三に、PHP開発者の再包摂。PHP-onlyブロック登録は「ブロック開発にはReactが必須」という参入障壁を下げる重要な変更です。WordPressのプラグインエコシステムにはPHPしか書かない開発者が多数おり、彼らがブロックエディタの世界に参入しやすくなります。

7.0はGutenberg Phase 3の「始まり」です。コラボレーション機能もAI統合もまだ初期段階であり、7.1、7.2、さらにその先のリリースで徐々に成熟していくでしょう。今の段階で基盤を理解し、プラグインやテーマのアーキテクチャを先回りして整えておくことが、2026年後半以降の競争力に直結します。

Beta期間中のテスト参加とフィードバックが、最終リリースの品質を左右します。ぜひWordPress 7.0 Beta 1の公式アナウンスを確認し、テストに参加してみてください。

WordPress 7.0関連で新しい技術情報が公開され次第、この記事も随時アップデートしていきます。

WordPress 7.0の新機能を完全ガイド！初心者でもわかる2026年最大アップデートの全貌
WordPress 7.0が2026年4月9日にリリース。リアルタイム共同編集やAI統合、管理画面の刷新、新ブロック追加など注目の新機能を初心者にもわかりやすく徹底解説。アップデート前の準備もこれ一本でOK。
raplsworks.com

コメント

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