WordPress 7.0 新機能詳解：AI API実装とリアルタイム共同編集がもたらすWeb制作の変革
WordPress 7.0がリリースされ、CMS（コンテンツ・マネジメント・システム）としての立ち位置が大きく進化を遂げた。今回のアップデートは、単なるエディタの改善や機能追加にとどまらない。人工知能（AI）のネイティブな統合と、複数人によるリアルタイム共同編集の導入という、制作フローの根幹に関わる変革が含まれている。
2026年最初のメジャーアップデートとなる本バージョンは、当初の予定から数週間延期してのリリースとなった。この延期は、特に共同編集機能の安定性を高めるために充てられたものだ。WP Marmiteの報告によれば、WordPress 7.0は「ブログ制作ツール」から「高度な共同制作プラットフォーム」への脱皮を象徴する重要な節目と位置付けられている。
本記事では、WordPress 7.0で導入された主要な新機能を深掘りし、それがWebサイト運営者や開発者の実務にどのような影響を与えるのかを詳しく解説していく。AI APIの仕組みから、新しく追加された便利なブロックまで、現場で役立つ情報を整理してお伝えする。
WordPress 7.0 の概要と管理画面の刷新
WordPress 7.0は、2026年に予定されている3つのメジャーアップデートのうちの第1弾だ。今回のバージョンには、Gutenbergプラグインのバージョン22.0から22.6までの成果が反映されている。まず目に飛び込んでくるのは、より洗練された管理画面のビジュアルだ。
モダン化した管理インターフェース
ダッシュボードにログインすると、色彩設計が刷新されていることに気づく。カラーパレットが現代的なトーンに調整され、タイポグラフィの視認性も向上した。コントラストが強化されたことで、長時間の作業でも疲れにくい設計となっている。画面遷移の際のアニメーションもスムーズになり、全体的な操作感が軽快になった印象を受ける。
どこからでも呼び出せるコマンドパレット
これまでのバージョンで段階的に導入されてきた「コマンドパレット」が、管理画面全体で利用可能になった。Macなら「Cmd + K」、Windowsなら「Ctrl + K」のショートカットで、いつでも検索窓を呼び出せる。特定のコンテンツへの移動や設定画面の呼び出し、各種アクションの実行が、マウス操作なしで完結する。これは、管理画面内を頻繁に行き来するディレクターやエンジニアにとって、大きな時短につながる機能だ。
AI APIの導入：AIネイティブなCMSへの進化
WordPress 7.0の目玉機能の一つが、AIモデルを接続するための専用API（Application Programming Interface）の実装だ。APIとは、異なるソフトウェア同士が情報をやり取りするための窓口のようなものだ。これまでAI機能を活用するには個別のプラグインに頼る必要があったが、今回からWordPress本体に標準的な「接続層」が用意された。
外部AIモデルとのシームレスな連携
新しい「コネクター」メニュー（設定 > コネクター）から、OpenAIやGoogle、Anthropicといった主要なAIプロバイダーのAPIキーを一括管理できるようになった。これにより、テーマやプラグインの開発者は、この共通基盤を利用してAI機能を実装できる。例えば、コンテンツの自動生成やSEOの最適化、画像の代替テキスト生成などが、より安定した環境で利用可能になる。
制作効率を劇的に変える「コネクター」の役割
WP Marmiteの著者によれば、このAPIの導入は「AI活用の標準化」を意味している。特定のプラグインに依存せず、システムレベルでAIを扱えるようになったため、将来的にタスクの自動化がさらに加速するだろう。現在は基盤の提供がメインだが、今後はこの仕組みを利用した革新的なプラグインが続々と登場することが予想される。
リアルタイム共同編集機能の本格稼働
WordPress 6.9から着手されていた「リアルタイム共同編集」が、ついに実用レベルに達した。これはGoogleドキュメントのように、複数のユーザーが同じ記事やページを同時に編集できる機能だ。チームでサイトを運営している企業や制作会社にとって、待望の機能といえる。
複数ユーザーによる同時編集の可視化
共同編集モードでは、他のユーザーがどのブロックを操作しているかがリアルタイムで表示される。編集中の箇所には各ユーザーのカーソルが表示され、誰がどこを修正しているのかが一目でわかる。また、エディタ内でのリアルタイムコメント機能も追加され、修正指示や相談をエディタ上で完結させることが可能になった。この機能は「設定 > 投稿設定」から有効化・無効化の切り替えができる。
現在の制限事項と今後の展望
ただし、リリース時点では注意点もある。SEOプラグインなどが使用する「メタボックス」（投稿画面の下部や横にある設定エリア）は、まだリアルタイム共同編集に完全には対応していない。WP Marmiteの記事では、この問題は今後のマイナーアップデートで順次修正される見込みだと指摘されている。当面は、本文の同時編集をメインに活用するのが現実的だろう。
ブロックエディタとサイト制作機能の強化
ユーザーが最も頻繁に触れるブロックエディタ（Gutenberg）も、WordPress 7.0で大幅な進化を遂げた。特に要望の多かった新しいブロックの追加と、カスタマイズの柔軟性が向上している。
待望の「パンくずリスト」と「アイコン」ブロック
これまでプラグインなしでは実装が難しかった「パンくずリスト」が、標準ブロックとして登場した。パンくずリストとは、サイト内の現在地を示すナビゲーション（例：ホーム > ブログ > 記事タイトル）のことだ。これを配置することで、ユーザーの利便性が高まるだけでなく、検索エンジンがサイト構造を理解しやすくなるためSEO効果も期待できる。
また、SVG形式のアイコンを簡単に挿入できる「アイコンブロック」も追加された。サイズや色、余白、ボーダーなどをエディタ上で直感的に調整できる。現時点ではアイコンライブラリの種類は限られているが、今後のアップデートで拡充される予定だ。
ブロックレベルのカスタムCSSと条件付き表示
高度なカスタマイズを求めるユーザー向けに、各ブロックの設定パネルから直接CSSを記述できるフィールドが追加された。これにより、特定のブロックだけに独自のスタイルを適用することが容易になった。さらに、デバイス（モバイル、タブレット、デスクトップ）ごとにブロックの表示・非表示を切り替える機能も標準搭載された。コードを書かずにレスポンシブなレイアウト調整が可能になった点は、制作現場での大きなメリットだ。
このデモは、デバイスごとにブロックの表示状態を切り替える概念を視覚化したものだ。
運用・管理面の改善点
サイトの日常的な運用を支える機能も、WordPress 7.0でブラッシュアップされている。特にリビジョン管理とフォント管理の改善は、コンテンツ制作の質を高めることに寄与するだろう。
視覚的に分かりやすくなったリビジョン機能
過去の編集履歴を確認するリビジョンインターフェースが刷新された。これまではHTMLコードの差分を比較していたため、専門知識がないと変更箇所の把握が難しかった。新しいインターフェースでは、エディタ上での見た目そのままに、追加された箇所が緑色、削除された箇所が赤色でハイライト表示される。視覚的に変更点を確認し、必要に応じてワンクリックで以前の状態に戻せるようになった。
全テーマ対応のフォント管理
WordPress 6.5で導入された「フォントライブラリ」が、ブロックテーマだけでなく「クラシックテーマ」を含むすべてのテーマで利用可能になった。管理画面の「外観 > フォント」から、プラグインなしでフォントの追加や管理が行える。これにより、デザインの自由度がテーマの形式に縛られなくなった。サイトのブランディングに合わせて、柔軟にタイポグラフィを設定できる。
独自の分析：WordPress 7.0 が示す未来像
WordPress 7.0の変更点を俯瞰すると、開発チームの明確な意図が見えてくる。それは、WordPressを単なる「ブログ作成ツール」から、Webアプリケーションの基盤となる「WebのOS」へと進化させることだ。WP Marmiteの記事でも触れられていたが、近年WordPressの市場シェアの伸びが鈍化しているという指摘がある。その中で、AIや共同編集といったモダンな機能を標準搭載することは、SaaS型の競合ツールに対抗するための必然的な戦略といえる。
特にAI APIの導入は、今後のエコシステムを大きく変える可能性がある。これまでは各プラグインが独自にAIと通信していたため、設定が煩雑になりがちだった。本体が共通のインターフェースを提供することで、ユーザーは一度設定を行うだけで、サイト全体のAI機能を統合管理できるようになる。これは、AIを活用した「次世代のWeb制作」における標準仕様となるだろう。
また、共同編集機能の強化は、WordPressがより大規模な組織やメディアでの利用を強く意識していることを示している。個人が記事を書く時代から、チームでコンテンツを作り上げる時代への変化に、システム側が完全に対応した形だ。WordPress 7.0は、これまでの「使いやすさ」を維持しつつ、プロフェッショナルな制作現場に耐えうる「高度なプラットフォーム」へと昇華したアップデートであると評価できる。
この記事のポイント
- AI APIの標準搭載により、外部AIモデルとの連携がシステムレベルで可能になった
- リアルタイム共同編集機能により、複数人での同時編集やコメントのやり取りがエディタ上で完結する
- パンくずリストやアイコンブロック、ブロックレベルのカスタムCSSなど、制作の柔軟性が大幅に向上した
- リビジョン機能の視覚化や全テーマ対応のフォント管理により、運用面での利便性が高まった
- 推奨環境はPHP 8.3以上（最低7.4以上）。アップデート前には必ずバックアップを取ることが重要だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress開発が劇的に速くなる？次世代ビルドツール「@wordpress/build」の全貌
WordPressのプラグイン開発において、ビルドツールのあり方が大きく変わろうとしている。現在広く使われている @wordpress/scripts の内部エンジンが、より高速でシンプルな @wordpress/build へと移行する計画が進んでいる。この変更は、単なる速度向上にとどまらず、開発者がコードを書く際の手順そのものを効率化するものだ。
2025年10月にプロジェクトが始動し、すでにGutenberg（ブロックエディタ）本体の100以上のパッケージビルドに採用されている。 esbuild（エスビルド）という非常に高速なエンジンを基盤に据えることで、これまでのwebpack（ウェブパック）ベースの環境では数分かかっていた処理が、わずか数秒で完了するようになる。開発の待ち時間がなくなることは、制作現場の生産性に直結する重要な変化だ。
なぜ今、使い慣れたツールを刷新する必要があるのか。それは、WordPress開発における「設定の複雑さ」を解消し、より直感的にコードを書ける環境を整えるためだ。新しいツールが目指すビジョンと、具体的な仕組み、そして今後の開発者がどのように対応すべきかを詳しく解説していく。
WordPressプラグイン開発の新たなスタンダード「@wordpress/build」とは
@wordpress/build は、WordPressコアチームが開発を進めている次世代のビルドツールだ。ビルドツールとは、JavaScriptやCSSなどのソースコードを、ブラウザが読み込める形式にまとめたり、最新の書き方を古いブラウザでも動くように変換したりする道具を指す。
webpack時代の複雑さからの脱却
これまで、WordPressの標準ツールである @wordpress/scripts は、内部でwebpackとBabel（バベル）を使用してきた。これらは非常に多機能で柔軟だが、長年の運用を経て設定が複雑化しすぎている側面があった。特に、依存関係の抽出やPHPファイルの生成など、WordPress特有の処理を組み合わせるために、多くのカスタム設定が必要だった。
結果として、Gutenbergプロジェクト自体が @wordpress/scripts を使わず、独自のカスタムツールでビルドを行うというねじれ現象が起きていた。 @wordpress/build は、この複雑さをツール内部に吸収し、開発者が「設定ファイル」をいじる必要をなくすことを目的としている。
esbuild採用による圧倒的なビルド速度
新しいエンジンの核となるのは esbuild だ。これはGo言語で書かれた非常に高速なバンドラー（ファイルをまとめるツール）で、従来のJavaScript製のツールとは比較にならないほどのパフォーマンスを発揮する。例えるなら、手作業で荷物を仕分けていた倉庫に、最新の高速自動仕分けロボットが導入されるようなものだ。
大規模なプロジェクトでも、フルビルドが数秒で終わる。また、ファイルの変更を監視して自動で再ビルドする「ウォッチモード」では、変更した箇所だけを瞬時に処理するため、修正が即座にブラウザへ反映される。この「待ち時間の消失」こそが、 @wordpress/build を導入する最大のメリットといえるだろう。
「設定」から「規約」へ：新しい開発ワークフロー
@wordpress/build の大きな特徴は、「設定より規約（Convention over Configuration）」という考え方を採用している点にある。これは、あらかじめ決められたルールに従ってフォルダやファイルを配置すれば、ツールが自動的に中身を判断して適切に処理してくれる仕組みだ。
フォルダ構成がそのまま設定になる仕組み
従来のように「どのファイルが入り口（エントリポイント）か」をコードで指定する必要はない。プロジェクト内に特定の名前のフォルダを作るだけで、ツールがビルド対象を自動検知する。
packages/：JavaScriptのパッケージを配置する場所。各サブフォルダが1つのパッケージとして扱われる。routes/：管理画面のルーティング（ページ構成）を定義する場所。blocks/：ブロックのソースコードを置く場所（現在提案中の機能）。
このルールに従うだけで、ツールは各フォルダ内の package.json を読み取り、必要なJavaScriptやスタイルシートを生成する。開発者は「どこに何を書くか」というルールさえ覚えれば、ビルド設定の迷宮に迷い込むことはなくなる。
package.jsonによるシンプルな管理
個別の設定が必要な場合も、webpack.config.jsのような専用ファイルは使わず、 package.json 内に記述する。例えば、あるパッケージをブラウザで読み込むスクリプトとして登録したい場合は、以下のように記述するだけで済む。
{
"name": "@my-plugin/utility",
"wpScript": true
}これだけで、ツールはこのパッケージを「IIFE（即時実行関数式）」形式でビルドし、WordPressの管理画面で適切に読み込めるように準備してくれる。IIFEとは、他のプログラムと名前がぶつからないようにコードをカプセル化する手法のことだ。専門的な知識が必要だった設定が、1行のフラグ指定に集約されている。
PHP登録作業を自動化する革新的な機能
WordPress開発者を悩ませる作業の1つに、JavaScriptファイルを読み込むための wp_enqueue_script() などのPHP記述がある。 @wordpress/build は、このPHP側の登録作業も自動化する道筋を示している。
手動のPHP記述が不要になるメリット
これまでは、ビルドされたファイルのパスを確認し、依存するスクリプト（wp-elementやwp-i18nなど）を手動で配列に書き出す必要があった。新しいツールでは、ビルドプロセスの一環として build/build.php というファイルが生成される。プラグインのメインファイルでこれを1行読み込むだけで、すべての登録が完了する。
require_once plugin_dir_path( __FILE__ ) . 'build/build.php';このファイルには、スクリプト、モジュール、スタイルシートの登録処理がすべて含まれている。開発者がPHP側で「どのファイルを読み込むか」を管理する必要がなくなるため、ファイル名の変更や依存関係の追加に伴うケアレスミスを劇的に減らすことができる。
アセット管理と依存関係の自動解決
JavaScript側で import { __ } from '@wordpress/i18n'; と書けば、ツールは自動的に「このスクリプトはwp-i18nに依存している」と判断し、 .asset.php ファイルを作成する。これは従来も @wordpress/scripts で提供されていた機能だが、 @wordpress/build ではさらに強化されている。
例えば、最新の「スクリプトモジュール（ESM）」と従来のスクリプトの使い分けも、設定一つで切り替え可能だ。さらに、WordPress 6.8で導入された効率的なブロック登録機能（WP_Block_Metadata_Registry）への対応も進められており、最新のコア機能の恩恵を最小限の手間で受けられるようになる。
名前空間と外部依存関係の高度な制御
大規模なプラグインや、複数のプラグインが連携する環境では、「名前空間（Namespace）」の管理が重要になる。 @wordpress/build では、自分のプラグインが提供する機能を他のプラグインからどう参照させるかを、明快に定義できる仕組みが備わっている。
プラグイン間でのスクリプト共有が容易に
例えば、WooCommerceのような他のプラグインが提供するJavaScript機能を利用したい場合、 package.json に外部名前空間として定義する。これにより、コード内で import { Cart } from '@woo/cart'; と書くだけで、実行時には window.woo.cart を参照し、依存関係のリストに自動で追加される。
これは、複数のスクリプトが同じライブラリを二重に読み込んでしまう問題を回避し、サイト全体のパフォーマンス向上に寄与する。開発者は複雑なフックの順序を気にすることなく、モダンなJavaScriptの書き方でプラグイン間の連携を実装できるのだ。
今後のロードマップと開発者が今すべきこと
@wordpress/build は現在も活発に開発が進んでいる段階だ。すぐにすべてのプロジェクトを移行すべきかというと、そうではない。公式のロードマップでは、段階的な統合が予定されている。
@wordpress/scriptsとの統合プロセス
将来的には、 @wordpress/scripts の中身が @wordpress/build に置き換わる予定だ。つまり、開発者は今まで通り npm run build を実行するだけで、内部的に新しい高速エンジンが動くようになる。この際、標準的な設定を使っている開発者は、コードを一切変更することなく、ビルド速度の向上という恩恵を受けられる見込みだ。
一方で、webpackの設定を細かくカスタマイズしている場合は、将来的に移行ガイドを参照しながら調整が必要になる可能性がある。コアチームは、この移行を可能な限りスムーズに進めるためのAPI設計に注力している。
早期導入のメリットと注意点
現在、複数のパッケージを持つ大規模なプラグインを開発しているエンジニアにとって、 @wordpress/build を試す価値は十分にある。モノレポ（複数のパッケージを1つのリポジトリで管理する手法）構成での開発効率が格段に上がるからだ。
ただし、ブロック登録周りなど、まだ手動での作業が必要な箇所も残っている。現時点では実験的な導入にとどめ、GitHubのGutenbergリポジトリで進行中のディスカッションに参加し、フィードバックを送るのが最も賢明な関わり方といえるだろう。特に「blocks/フォルダをルートに置く規約」についての議論は、今後のプラグイン構造の標準を決める重要なポイントだ。
独自の分析：WordPress開発体験（DX）はどう変わるか
今回の @wordpress/build への移行は、WordPressが「独自の進化」から「モダンなWeb標準との融合」へと、さらに一歩踏み出したことを象徴している。 esbuildのような最先端のツールを標準に取り入れることで、WordPress開発特有の「古臭さ」や「設定の煩わしさ」が解消されようとしている。
特に注目すべきは、PHPとJavaScriptの境界線がより曖昧になり、自動化が進む点だ。これまでWordPressエンジニアには、フロントエンドの知識と、それをWordPressに登録するためのPHPの知識の両方が高いレベルで求められてきた。この「登録」という非創造的な作業が自動化されることで、開発者は「ユーザーにどんな機能を提供するか」という本来の目的に集中できるようになる。
また、ビルドが高速化されることは、単に時間の節約になるだけではない。試行錯誤の回数が増え、結果としてコードの品質が向上する。保存した瞬間に画面が変わる「ライブな開発体験」は、開発者のモチベーションを維持する上でも極めて重要だ。 @wordpress/build は、WordPressを「古いブログシステム」から「洗練されたアプリケーションプラットフォーム」へと進化させるための、強力なインフラになるだろう。
この記事のポイント
@wordpress/buildは@wordpress/scriptsの次世代エンジンとして開発されている。- esbuildの採用により、ビルド速度が分単位から秒単位へと劇的に高速化される。
- 「設定より規約」を重視し、フォルダ構成に従うだけで自動ビルドが可能になる。
- PHP側のスクリプト登録処理が自動生成され、手動での記述が不要になる。
- 将来的には既存のツールに統合されるため、標準的な構成なら変更なしで恩恵を受けられる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0 RC2が公開。4月9日の正式リリースに向けた最終テストが開始
WordPress 7.0のリリース候補第2版である「RC2」が、2026年3月26日に公開された。このバージョンは、4月に控えた大規模アップデートに向けた最終調整の段階にあり、開発コミュニティによる徹底的な検証が進められている。本番環境への導入はまだ控えるべきだが、新機能の動作確認や互換性のテストを行うには最適なタイミングだ。
今回のリリースでは、前バージョンのRC1以降に報告されたバグの修正や、細かなUIのブラッシュアップが中心となっている。正式版のリリース日は2026年4月9日に設定されており、WordCamp Asiaの開催時期に合わせたスケジュールとなっている。世界中のサイト運営者や開発者にとって、システムの安定性を左右する重要なマイルストーンといえる。
RC（Release Candidate）とは「リリース候補版」を指し、重大な不具合が見つからない限り、このままの状態で正式版として配布される可能性があるソフトウェアの状態を意味する。つまり、RC2が公開されたということは、新機能の追加はすべて完了しており、現在は「磨き上げ」のフェーズにあるということだ。この記事では、RC2の内容とテスト方法、そしてWordPress 7.0がもたらす変化について詳しく解説していく。
WordPress 7.0 RC2のリリースと今後のスケジュール
WordPress 7.0の開発サイクルは、いよいよ最終盤に差し掛かっている。2026年3月26日にリリースされたRC2は、正式版の公開まで残り2週間というタイミングで登場した。この段階では、機能の追加は行われず、報告された不具合の修正とパフォーマンスの最適化に全力が注がれている。開発チームは、このRC版を実際の運用に近い環境でテストすることを強く推奨している。
正式リリースは4月9日を予定
現在のロードマップによれば、WordPress 7.0の正式リリース日は2026年4月9日だ。この日付は、アジア最大級のWordPressイベントである「WordCamp Asia 2026」の開催期間中にあたる。イベントに合わせてリリースされることで、新機能の普及やコミュニティでの議論が一気に加速することが予想される。ただし、RC2のテストで深刻な問題が見つかった場合は、スケジュールが調整される可能性もゼロではない。
リリース候補（RC）版が持つ意味
RC版は、開発の初期段階である「アルファ版」や、機能がほぼ固まった「ベータ版」を経て提供される。RC2（Release Candidate 2）は、RC1で見つかった細かな修正を反映させたものだ。一般的に、この段階のソフトウェアは機能的に完成しており、安定性も高い。しかし、未知のバグが潜んでいるリスクは依然として残っている。そのため、WordPress.orgは、RC2を本番サイトやミッションクリティカルな環境（停止が許されない重要なシステム）にインストールしないよう警告している。
新機能を安全に試すための4つのテスト方法
WordPress 7.0の新機能を正式リリース前に体験するには、いくつかの方法がある。自分のスキルセットや環境に合わせて、最適なテスト手法を選択することが可能だ。ここでは、初心者からエンジニアまで利用できる4つのアプローチを紹介する。
ブラウザだけで試せるPlayground
最も手軽な方法は「WordPress Playground」を利用することだ。これはWebアセンブリ（Wasm）という技術を使い、ブラウザ上だけでWordPressを動作させる仕組みである。サーバーの契約やローカル環境の構築は一切不要で、リンクをクリックするだけで即座にWordPress 7.0 RC2が起動する。ブラウザを閉じればデータは消去されるため、既存のサイトを壊す心配がなく、気軽に新機能を試すことができる。
プラグインやWP-CLIによる検証
既存のテスト用サイトがある場合は「WordPress Beta Tester」プラグインをインストールするのが便利だ。設定画面で「Bleeding edge」と「Beta/RC Only」を選択すれば、管理画面から簡単にRC2へアップデートできる。また、エンジニア向けには「WP-CLI」を使った方法も用意されている。コマンドラインから wp core update --version=7.0-RC2 を実行することで、迅速に環境を更新できる。より確実に検証したい場合は、公式サイトからzipファイルを直接ダウンロードして手動インストールすることも可能だ。
WordPress 7.0で注目される主な変更点
WordPress 7.0は、ユーザー体験（UX）と開発体験の両面で大きな進化を遂げている。特にブロックエディタ（Gutenberg）の機能強化は、Web制作のワークフローを大きく変える可能性を秘めている。これまでのベータ版やRC1での情報を踏まえ、主要な変更点を整理する。
Gutenbergエディタとブロックの進化
今回のアップデートの目玉の一つは、Tabs（タブ）ブロックのリファクタリングだ。タブブロックとは、限られたスペースに複数のコンテンツを切り替えて表示するためのパーツである。コード構造が刷新されたことで、アクセシビリティが向上し、より直感的な編集が可能になった。また、Navigation Overlay（ナビゲーションオーバーレイ）の改善も含まれている。これは、スマートフォンなどでメニューを開いた際の表示や挙動を制御する機能で、モバイルユーザーの利便性が高まっている。
開発者向けの技術的な改善
開発者向けには、内部的なAPIの整理やパフォーマンスの向上が図られている。RC2までの修正では、GitHub上のコミットやTrac（バグ追跡システム）のチケットが多数処理されており、特にブロック間のデータのやり取りや、メタデータの処理速度が改善されている。Breadcrumbs（パンくずリスト）ブロックの微調整なども行われており、SEO（検索エンジン最適化）に配慮した構造がより作りやすくなっている。
プラグイン・テーマ開発者が今すべきこと
WordPressのエコシステムを支えるプラグインやテーマの作者にとって、RC2の期間は最終確認のデッドラインだ。自身のプロダクトが最新のコアと競合しないか、正常に動作するかを確認する責任がある。
互換性テストと「Tested up to」の更新
開発者は、自身のプラグインやテーマをRC2環境で動作テストし、エラーが出ないかを確認する必要がある。問題がなければ、readme.txtファイルの「Tested up to」項目を 7.0 に更新することが推奨されている。これにより、ユーザーは管理画面で「このプラグインは最新バージョンのWordPressで動作確認済みである」という確信を持ってアップデートできるようになる。もし互換性の問題が見つかった場合は、WordPressのサポートフォーラムの「Alpha/Beta」セクションへ詳細を報告することが、コミュニティ全体の利益につながる。
独自の分析：WordPress 7.0がもたらす運用への影響
WordPress 7.0のリリースは、単なる機能追加以上の意味を持っている。特に中小企業のサイト担当者や個人事業主にとって、このアップデートは「運用の内製化」をさらに一歩進めるものになると分析できる。
ノーコード編集の幅が広がるメリット
Tabsブロックの刷新やナビゲーションの改善は、これまでコーディングが必要だった複雑なレイアウトを、マウス操作だけで完結させるための布石だ。これにより、外部の制作会社に依頼することなく、自社でキャンペーンページや製品紹介ページを柔軟に更新できる範囲が広がる。表示速度の向上も期待されており、これはCWV（Core Web Vitals / コアウェブバイタル）というGoogleの検索順位指標にも好影響を与えるだろう。つまり、日常的な運用コストの削減と、SEO効果の向上が同時に期待できるアップデートといえる。
リリースタイミングとリスク管理
4月9日の正式リリース直後にアップデートを行うのは、リスクを伴う場合がある。特に多くのプラグインを導入しているサイトでは、プラグイン側の対応が遅れる可能性があるからだ。筆者の見解としては、正式リリースから1〜2週間ほど様子を見、マイナーアップデート（7.0.1など）が出てから適用するのが、ビジネスサイトにおいては最も安全な戦略である。RC2の段階でテスト環境を構築し、事前に自社サイトの主要機能が動くかを確認しておくことが、スムーズな移行への近道となるだろう。
この記事のポイント
- WordPress 7.0 RC2が公開され、2026年4月9日の正式リリースに向けて最終調整に入った
- RC2はリリース候補版であり、本番環境ではなくテストサーバーやPlaygroundでの検証が推奨される
- Tabsブロックの刷新やNavigation Overlayの改善など、UIとアクセシビリティの強化が主要な変更点である
- プラグイン・テーマ開発者は互換性を確認し、readmeの「Tested up to」を7.0に更新すべき時期である
- 正式リリース後は運用コストの削減が期待できるが、安定性を重視するなら数週間の様子見も有効な戦略となる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0のリリース延期が決定。リアルタイム共同編集の安定性とAI時代への備えを優先
WordPressの次期メジャーアップデートである「バージョン 7.0」のリリース延期が決定した。当初は2026年4月9日の公開を予定していたが、新機能の安定性を極限まで高めるための措置だという。今回の延期は、WordPressがAI（人工知能）を活用した次世代のコンテンツ管理システムへと進化するための重要なステップと位置づけられている。
開発チームが特に注力しているのは、複数人で同時に記事を編集できる「リアルタイム共同編集（RTC）」機能の完成度だ。この機能はデータベース構造の根本的な変更を伴うため、慎重な検証が求められている。リリースは数日ではなく数週間単位で遅れる見込みだが、これはWordPressの歴史においても異例の判断だ。
この記事では、なぜWordPress 7.0の延期が必要だったのか、その背景にある技術的な課題と将来の展望を詳しく解説する。サイト運営者や開発者が知っておくべき変更点や、ホスティング環境への影響についても触れていく。
異例のリリース延期と「安定性」へのこだわり
WordPressの共同創設者であるマット・マレンウェッグ氏は、開発者向けのコミュニケーションツール「Slack」において、現在のスケジュールを一時停止する意向を表明した。同氏は、バージョン 7.0を単なるアップデートではなく、将来のAI駆動型開発を見据えた極めて重要なマイルストーンと捉えている。
マット・マレンウェッグ氏による決断の背景
マレンウェッグ氏は、現在の開発状況を鑑みて「ベータ版のプロセスに戻り、新しいデータベーステーブルの設計を正しく完了させるべきだ」と述べた。通常、WordPressの開発はあらかじめ決められた「日付」を優先して進められる。しかし、今回の 7.0に関しては、日付よりも「極限の安定性」を優先するという例外的な判断が下された。
この背景には、AIによるソフトウェア開発の加速がユーザーの期待値を高めているという認識がある。AI時代のソフトウェアには、これまで以上の品質とスピードが求められる。そのため、基盤となる 7.0のリリースで妥協を許さない姿勢を示した形だ。
AI時代を見据えたマイルストーンとしての役割
WordPress 7.0は、AIを活用したコンテンツ管理の先駆けとなる機能を含む予定だ。マレンウェッグ氏は、2027年までに年4回のリリースサイクルに戻ることを目標としている。AIの力を借りることで、将来的には現在よりも速いペースで高品質なアップデートを提供できる体制を目指しているという。
今回の延期は、将来の高速な開発サイクルに耐えうる強固な土台を作るための「一歩後退、二歩前進」の戦略といえる。安定した基盤がなければ、その上に高度なAI機能を積み上げることはできないからだ。
リアルタイム共同編集（RTC）が抱える技術的課題
リリースの遅れに最も影響を与えているのが、リアルタイム共同編集（RTC：Real-Time Collaboration）の実装だ。これはGoogleドキュメントのように、複数のユーザーが同じ投稿を同時に編集し、その変更が即座に画面に反映される機能である。非常に便利な機能だが、システム内部では複雑な処理が行われている。
データベース設計とパフォーマンスの葛藤
RTCを実現するためには、データの保存方法を根本から見直す必要がある。開発チーム内では、RTC専用のデータベーステーブルをどのように構築するかで議論が続いている。当初は「編集内容の更新」と「複数環境間の同期」を1つのテーブルで処理する案が出ていた。
しかし、これら2つの処理は性質が大きく異なる。編集内容の更新は「高頻度で瞬間的な書き込み」が必要だが、環境間の同期は「低速で構造化された更新」となる。これらを1つのテーブルに詰め込むと、データベースの負荷が増大し、サイト全体のパフォーマンスが低下する恐れがある。そのため、それぞれの用途に最適化した別々のテーブルに分けるべきだという意見が出されている。
キャッシュ制御と編集セッションの影響
もう一つの大きな課題は「永続オブジェクトキャッシュ」との相性だ。現在のRTCの実装では、編集セッション中にキャッシュが無効化されてしまう問題が指摘されている。キャッシュとは、一度読み込んだデータを一時的に保存して高速に表示する仕組みのことだ。
これが無効になると、管理画面の動作が重くなり、サーバーへの負荷も増大する。開発チームは正式リリースまでに、RTCを有効にしながらもキャッシュの恩恵を維持できる解決策を模索している。
ここで、リアルタイム共同編集の概念を視覚化したデモを紹介する。以下のデモは、2人のユーザーが同時に編集している状態をイメージしたものだ。
| 追記しています
※このデモはリアルタイム共同編集の概念を視覚化したイメージである。実際の動作はブラウザを介した高度な同期処理によって行われる。
ベータへの「逆戻り」を避けたRCフェーズの延長
開発の遅れを取り戻すため、当初は「リリース候補（RC）版」から「ベータ版」にステータスを戻す提案がなされた。しかし、最終的にはRC版のまま、テスト期間を延長する方針が決定した。これには技術的な深い理由がある。
バージョン管理と互換性の制約
WordPressのシステムやプラグイン、そしてPHPというプログラミング言語には、バージョン番号を比較する厳密なルールがある。一度「RC1」や「RC2」として出したものを「Beta」に戻すと、システムの自動更新ロジックや開発ツールが混乱し、予期せぬ不具合を招く可能性がある。
互換性を重視するWordPressにとって、ツールの仕組みを壊すことは避けなければならない。そのため、バージョン名を戻すのではなく、RC3、RC4といった形でリリース候補版を重ねていくことで、必要なテスト時間を確保する道が選ばれた。
Gutenbergプラグインではなく本体での検証
新機能のテストを「Gutenbergプラグイン」で行うという選択肢もあった。しかし、今回の変更はデータベースの構造（スキーマ）に関わるものだ。データベースの変更は、サイトのデータそのものに影響を与えるため、プラグインレベルでの検証では不十分だと判断された。
本体のアップグレードに伴うデータ移行が正しく行われるかを確認するためには、実際のWordPress本体のアップデートプロセスを通じた検証が不可欠だ。延長されたRCフェーズでは、より多くのユーザーからのフィードバックを集め、実環境に近い形でのテストが繰り返されることになる。
ホスティング環境と開発者への影響
今回の延期とRTC機能の実装は、サイトを支えるサーバー環境（ホスティング）にも少なからず影響を及ぼす。新機能がどのようなリソースを消費するのか、まだ未知数な部分が多いからだ。
共有サーバーでのリソース消費への懸念
RTC機能は、デフォルトではオフの状態で出荷される予定だ。しかし、ユーザーがこの機能を有効にした場合、共有サーバー環境でどのような挙動を示すかが懸念されている。複数のユーザーが同時に書き込みを行うRTCは、通常の編集よりもサーバーへのリクエスト頻度が大幅に高くなる。
Search Engine Journalの取材に対し、マネージドWordPressホスティングを提供しているKinstaの担当者は、現在もテストを継続中であると回答している。ホスティング各社は、自社のインフラでRTCが安定して動作するかを確認するため、延長されたRC期間を活用してさらなる検証を行う必要があるだろう。
2027年に向けたリリースサイクルの展望
今回の延期は一時的な例外措置とされている。マレンウェッグ氏は、2027年までに年4回の定期的なリリースサイクルを確立したいと考えている。AIを活用したワークフローが定着すれば、開発スピードは劇的に向上する見込みだ。
開発者にとっては、今後数週間のRCフェーズが重要な期間となる。データベース構造が変更される可能性があるため、自作のプラグインやテーマが新しいRTCの仕組みと競合しないか、細心の注意を払ってテストを続けることが求められる。
独自の分析：スケジュールよりも「信頼」を選んだWordPressの決断
今回のWordPress 7.0のリリース延期は、エコシステム全体にとって非常にポジティブなニュースだと捉えることができる。なぜなら、世界中のWebサイトの4割以上を支えるプラットフォームが、目先の納期よりもシステムの健全性を優先したからだ。
特にデータベースの変更は、一度リリースしてしまうと後戻りが極めて難しい。もし不完全な状態でリリースされ、世界中のサイトでデータ破損やパフォーマンス低下が起きていれば、WordPressの信頼は失墜していただろう。RTCのような野心的な機能を、万全の状態で世に送り出そうとする姿勢は評価に値する。
また、AI時代に向けた準備を公言した点も興味深い。単に「遅れた」のではなく「AI時代のスタンダードを作るために時間をかける」という明確なビジョンがある。ユーザーは、数週間の待ち時間と引き換えに、より安全で、将来の拡張性に優れたWordPressを手に入れることができるはずだ。今は焦らず、安定した正式版の登場を待ちたい。
この記事のポイント
- WordPress 7.0のリリースが、安定性確保のために当初の4月9日から数週間延期された。
- 延期の主な理由は、新機能「リアルタイム共同編集（RTC）」に伴うデータベース設計の最適化だ。
- バージョン管理の互換性を守るため、ベータ版には戻さず「リリース候補（RC）版」を重ねる形でテストを継続する。
- RTC機能はサーバー負荷を高める可能性があるため、ホスティング各社も慎重な検証を行っている。
- 今回の延期は、2027年に向けたAI駆動の開発サイクルを確立するための重要な布石となっている。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0 RC1登場！AI連携基盤と共同編集機能の全容を解説
WordPress 7.0のリリース候補版第1弾（RC1）が、2026年3月24日に公開された。RC（Release Candidate）は、開発の最終段階に入ったことを意味し、致命的なバグが見つからない限り、このバージョンが正式版のベースとなる。正式リリースは2026年4月9日に予定されている。
今回のアップデートでは、AI（人工知能）をシステムレベルで統合するための「AIコネクタ」や、複数のユーザーが同時に記事を編集できる「リアルタイム共同編集（RTC）」の強化が目玉だ。これらは、WordPressが単なるブログツールから、より高度なコンテンツ制作プラットフォームへと進化しようとしている姿勢を示している。
本記事では、RC1で明らかになった新機能の詳細と、サイト運営者や開発者が注目すべき変更点を、技術的な背景を交えて解説する。
WordPress 7.0のリリーススケジュールとRC1の位置付け
WordPress 7.0の開発サイクルは、このRC1のリリースによって大きな節目を迎えた。RC版は、ベータ版での機能追加が終了し、安定性の向上と細かなバグ修正に注力するフェーズだ。記事によれば、ベータ5からRC1までの間に、134件以上の修正と更新が行われたという。
正式版リリースまでのカウントダウン
正式版のリリース日は2026年4月9日に設定されている。このスケジュールは、WordCamp Asiaの開催時期に合わせる形となっている。開発チームは、このRC期間中に世界中のユーザーからフィードバックを募り、最終的な調整を行う。この段階で新しい機能が追加されることは原則としてないが、既存機能の挙動が微調整される可能性はある。
テスト環境での検証が推奨される理由
公式サイトでは、このRC1を本番環境（稼働中のサイト）にインストールしないよう強く警告している。新機能や内部APIの変更により、現在使用しているプラグインやテーマと競合する可能性があるためだ。検証を行う場合は、ローカル環境やステージング環境（本番と同じ設定のテスト用サーバー）を利用するのが鉄則だ。特に今回はAI関連や共同編集といった、コアシステムに深く関わる変更が含まれているため、事前の互換性チェックが欠かせない。
AIコネクタ（AI Connectors）による外部AIサービスの統合
WordPress 7.0の最も野心的な試みの一つが、「AI Connectors（AIコネクタ）」画面の新設だ。これは、WordPress本体と外部のAIプロバイダーを接続するための標準的なインターフェースを提供するものだ。
AI連携のハブとなる新しい管理画面
これまで、WordPressでAIを利用するには、個別のプラグインが独自にAPIキーを管理し、それぞれのUIで設定を行う必要があった。新しく導入されるAIコネクタ画面は、これを一元化する。サイト管理者は、この画面からOpenAIやAnthropicといったAIプロバイダーを選択し、サイト全体で利用するAIの基盤を設定できるようになる。記事によれば、AI以外のプロバイダーを登録するためのAPIも用意されており、拡張性が確保されている。
技術的分析：なぜ「コネクタ」が必要なのか
WordPressが特定のAIサービスを本体に内蔵するのではなく、「コネクタ」という仲介役を用意した点に注目したい。これは、急速に進化するAI分野において、特定のサービスへのロックイン（囲い込み）を防ぐ賢明な判断だ。開発者は共通のAPIを介してAI機能にアクセスできるため、将来的にAIプロバイダーを切り替えても、プラグイン側のコードを大幅に書き換える必要がなくなる。これは、WordPressの哲学である「自由な選択」をAI時代にも継承しようとする動きだと言える。
リアルタイム共同編集（RTC）の実装と強化
Googleドキュメントのように、複数のユーザーが同じ投稿を同時に編集できる「リアルタイム共同編集（RTC: Real Time Collaboration）」がついに現実味を帯びてきた。7.0 RC1では、この機能の安定性と利便性を高めるための修正が多数含まれている。
デフォルトでオプトイン（有効化）される新機能
RC1では、RTCがデフォルトでオプトイン（利用可能な状態）として設定された。また、共同編集セッションの通知をオン・オフできる切り替えスイッチも追加されている。これにより、大規模な編集チームを持つメディアサイトや、クライアントとリアルタイムで修正内容を確認したい制作現場での利便性が飛躍的に向上する。記事によると、RTCのポーリング間隔（データの同期頻度）も調整され、サーバー負荷とリアルタイム性のバランスが最適化されているという。
定数による制御と開発者への影響
開発者向けには、WP_ALLOW_COLLABORATION という新しい定数が導入された。これを wp-config.php で定義することで、サイト全体で共同編集機能を制御できる。共同編集は便利な反面、サーバーリソースを消費し、データの競合リスクも伴う。そのため、ホスティング環境やサイトの運用ポリシーに応じて、柔軟にオン・オフを切り替えられる設計になっている点は評価できる。
管理画面とパフォーマンスの細かな改善点
派手な新機能の影で、日々の運用を支える管理画面やパフォーマンス面でも重要なアップデートが行われている。特に、エディタの操作感に直結する変更がいくつか見られる。
コマンドパレットのショートカット対応
管理画面のどこからでも特定の機能にアクセスできる「コマンドパレット」が、⌘K（Mac）または Ctrl+K（Windows）のショートカットキーで呼び出せるようになった。これまでは特定のエディタ画面内での利用が主だったが、管理バーを通じてサイト全体で利用可能になったことで、ページ遷移の手間が大幅に削減される。これは、キーボード操作を好むパワーユーザーにとって大きな改善だ。
リビジョンとサイトヘルスの強化
リビジョン（変更履歴）機能では、サイドバーに変更されたブロックの属性が表示されるようになった。どのブロックのどの設定がいつ変わったのかを視覚的に把握しやすくなる。また、サイトヘルス画面のサーバー情報に「OPcache」の状態が追加された。OPcacheはPHPの実行を高速化する仕組みで、これが有効かどうかを管理画面から即座に確認できるようになったことは、サイトの高速化診断において非常に有用だ。
WordPress 7.0 RC1を試すための具体的な方法
正式リリース前に新機能を体験したい場合、いくつかの方法が提供されている。自身のスキルや環境に合わせて最適な方法を選択してほしい。
最も手軽な「WordPress Playground」
サーバーを準備することなく、ブラウザ上だけでWordPress 7.0を動作させられるのが「WordPress Playground」だ。公式サイトのリンクをクリックするだけで、最新のRC1環境が即座に立ち上がる。プラグインのインストールや設定の変更もブラウザ内で完結するため、最も安全かつ迅速なテスト方法だと言える。
プラグインやCLIによる検証
既存のテストサイトがある場合は、「WordPress Beta Tester」プラグインを利用するのが便利だ。設定で「Bleeding edge（最先端）」チャンネルと「Beta/RC Only」ストリームを選択すれば、管理画面から簡単にRC1へアップデートできる。また、コマンドライン操作に慣れているエンジニアであれば、WP-CLIを使用して wp core update --version=7.0-RC1 を実行するのが最も確実な方法だ。
この記事のポイント
- 正式リリースは4月9日：RC1は最終テスト段階であり、バグ修正と安定化が主目的。
- AIコネクタの導入：外部AIサービスとWordPressを標準的なAPIで接続する基盤が整備された。
- 共同編集（RTC）の進化：複数人での同時編集がデフォルトで利用可能になり、通知機能も追加。
- 操作性の向上：コマンドパレットが
Ctrl+Kでサイト全体から呼び出せるようになり、効率化が進んだ。 - 検証の重要性：新機能が多いため、正式版公開前にPlaygroundやテスト環境での互換性確認が推奨される。
出典
- WordPress.org News「WordPress 7.0 Release Candidate 1」（2026年3月24日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
モーダルか別ページか？UXを最適化する「意思決定フロー」と使い分けの基準
ウェブサイトやアプリケーションを設計する際、新しい情報を表示するために「モーダル（ポップアップ）」を使うべきか、それとも「新しいページ」へ遷移させるべきかという選択に直面することがある。この判断は、単なる好みの問題ではない。ユーザーの操作フローや、情報の参照しやすさ、さらにはタスクの完了率にまで大きな影響を及ぼす重要な設計判断だ。
不適切なタイミングでのモーダル表示は、ユーザーの集中力を削ぎ、フラストレーションを溜める原因となる。一方で、些細な確認のためにページを切り替えてしまうと、元の画面に戻る手間が発生し、ユーザーが「今何をしていたか」を忘れてしまうリスクがある。どちらの選択肢も、使い方を誤ればユーザー体験を損なう凶器になり得るのだ。
本記事では、Smashing Magazineの記事を基に、モーダルと別ページの使い分けを整理する。さらに、複雑な判断を助ける「意思決定フロー（デシジョンツリー）」の考え方を紹介し、WordPressサイトやWebアプリにおける最適なUI設計の指針を提示する。この記事を読み終える頃には、自信を持って最適なコンポーネントを選択できるようになっているはずだ。
モーダル、ダイアログ、オーバーレイの違いを整理する
UI設計の議論において、これら用語は混同されがちだ。しかし、元記事の著者であるヴィタリー・フリードマン氏は、それぞれの用語には明確なニュアンスの違いがあると指摘している。まずはこれらの定義を正しく理解することが、適切なUIを選択するための第一歩となる。
モーダル（Modal）とノンモーダル（Non-modal）の決定的な違い
「モーダル」とは、そのウィンドウが表示されている間、背景にある元のコンテンツへの操作が一切できなくなる仕組みを指す。ユーザーは、モーダル内のタスクを完了させるか、閉じる操作をしない限り、元の画面に戻ることはできない。これは、システム側がユーザーの注意を完全に拘束したい場合に用いられる。
一方、「ノンモーダル」は、ウィンドウが表示されていても、背景のコンテンツをスクロールしたり、他のリンクをクリックしたりできる。これは、情報の参照を助けるためのツールチップや、画面の端に表示される通知（スナックバー）などが該当する。ユーザーのフローを遮断せず、補助的な情報を提供する場合に適している。
ダイアログ、オーバーレイ、ライトボックスの定義
ダイアログ（Dialog）は、ユーザーとシステムとの「対話」を目的とした汎用的な用語だ。オーバーレイ（Overlay）は、ページの上に重ねて表示されるパネル全般を指す。そして、ライトボックス（Lightbox）は、背景を暗く反転させてモーダル内のコンテンツを強調する視覚的な手法を指す。
アンナ・ケイリー氏の調査によれば、多くのオーバーレイは不適切なタイミングで表示され、ユーザーを邪魔しているという。特に、クリティカルな作業中に表示される強制的なモーダルは、ユーザーにとって非常にストレスフルだ。そのため、デフォルトの選択肢としては、ユーザーの自由度を奪わない「ノンモーダル」な設計を検討すべきだと元記事では述べられている。
モーダルが真価を発揮する「単一タスク」の場面
モーダルは決して「悪」ではない。適切に使えば、ユーザーが現在の場所を見失わずに、必要な作業を素早く完結させるための強力な武器になる。特に、自己完結型の短いタスクにはモーダルが最適だ。
文脈（コンテキスト）を維持するメリット
モーダルの最大の利点は、ユーザーが「現在のコンテキスト（文脈）」を維持できることだ。ページ遷移を伴わないため、元の画面のスクロール位置、入力中のフォーム、適用したフィルター設定などが保持される。例えば、WordPressのメディアライブラリはモーダル形式で開かれるが、これにより投稿編集画面から離れることなく画像を選択し、すぐに執筆に戻ることができる。
「コンテキストを維持する」とは、単にUIが残っていることだけではない。ユーザーの脳内にある「作業の記憶」を維持することを意味する。別のページに飛んでしまうと、元のページで何をしようとしていたかを思い出すのに数秒のコストがかかるが、モーダルならそのコストを最小限に抑えられる。
破壊的な操作の警告とクイックな確認
データの削除や、保存されていない情報の破棄など、取り返しのつかない操作を行う際の「最終確認」にはモーダルが非常に効果的だ。あえてユーザーの動きを止めることで、誤操作を防ぐことができる。また、設定の微調整や、フィルタ条件の選択など、数秒で終わるアクションもモーダルに向いている。
ただし、モーダル内で多くの情報を入力させたり、複数のステップを踏ませたりするのは避けるべきだ。モーダルはあくまで「寄り道」であり、長居をさせる場所ではない。作業が長引く場合は、ユーザーは背景にある情報を参照したくなり、モーダルが邪魔に感じ始めるからだ。
複雑なワークフローには「別ページ」を推奨する理由
一方で、複雑なタスクや、多くの情報を扱う場面では、モーダルではなく独立したページ（またはフルスクリーンのビュー）を用意するのが賢明だ。モーダルという「限られた枠」が、ユーザーの思考を制限してしまうからである。
複数ステップのウィザード形式はページが最適
モーダルの中にタブを設けたり、次へボタンで画面を切り替えたりする「モーダル内ウィザード」は、エンタープライズ製品などでよく見かけるが、UXの観点からは推奨されない。ステップが重なるほど、ユーザーは「今、全体のどのあたりにいるのか」という感覚を失いやすくなる。
複雑な設定フローや、複数の入力項目がある場合は、専用のページへ遷移させるべきだ。ページであれば、ブラウザの「戻る」ボタンが機能し、URLを共有することも可能になる。また、画面全体を使えるため、視覚的な階層構造を整理しやすくなり、ユーザーの認知負荷を下げることができる。
データの比較や参照が必要なケース
ユーザーが作業中に「別の画面にある数字を確認したい」「過去の履歴と見比べたい」と考える場合、モーダルは大きな障害となる。モーダルは背景を覆い隠してしまうため、情報の比較ができないからだ。このような場合、ユーザーはモーダルを閉じたり開いたりするか、あるいは同じサイトを別のタブで開くという苦肉の策をとることになる。
参照性が重要なタスクでは、新しいページを開くか、あるいは後述する「サイドドロワー（引き出し式のパネル）」を採用するのが望ましい。サイドドロワーであれば、メインコンテンツの半分を露出させたまま、サブタスクを並行して進めることができる。
モーダルを避けるべき3つのアンチパターン
元記事では、モーダルの使用を控えるべき具体的なケースが挙げられている。これらは、多くのWebサイトで「良かれと思って」行われているが、実際にはユーザー体験を阻害していることが多い。
エラーメッセージやオンボーディングでの多用
入力エラーが発生するたびにモーダルで「エラーです」と表示するのは、ユーザーの入力を妨げる行為だ。エラーメッセージは、入力フィールドのすぐ側や、画面上部の通知エリアに表示し、ユーザーがエラー内容を見ながら修正できるようにすべきだ。モーダルで表示してしまうと、エラー内容を確認するためにモーダルを閉じなければならず、修正すべき箇所を忘れてしまう。
また、新機能を紹介するオンボーディング（チュートリアル）で、何枚ものモーダルを連続で表示するのも逆効果だ。ユーザーは早くサービスを使いたいと考えており、説明を読まずに「閉じる」を連打する傾向がある。機能紹介は、ユーザーが実際にその機能を使おうとした瞬間に、控えめなツールチップなどで示すのが理想的だ。
ネスト（入れ子）構造のモーダル
モーダルの上にさらに別のモーダルを重ねて表示する「ネスト構造」は、最悪のUXの一つとされている。画面が複雑怪奇になり、どの「閉じる」ボタンがどのウィンドウに対応しているのかが分からなくなる。もしモーダル内でさらに詳細な情報が必要になった場合は、モーダルを切り替えるのではなく、インラインで情報を展開するか、サイドパネルを活用すべきだ。
UXを向上させる「意思決定フロー」の活用
では、具体的にどのように判断を下すべきか。ライアン・ノイフェルド氏が作成した意思決定フロー（デシジョンツリー）を参考に、4つのステップで考えてみよう。このフローに従うことで、直感ではなく論理的な根拠に基づいてUIを選択できる。
ステップ1：文脈維持の必要性を評価する
まず、ユーザーが「元の画面の状態」を保持したまま作業を終える必要があるかを考える。元の画面に戻ったときに、スクロール位置や入力内容がそのまま残っていることが重要であれば、モーダルやオーバーレイが候補に残る。逆に、新しいタスクが元の画面とは全く無関係なものであれば、別ページに飛ばしてしまっても問題ない。
ステップ2：タスクの複雑さと継続時間を測る
そのタスクは数秒で終わるものか、それとも数分かかるものか。1〜2つの項目を入力するだけならモーダルで十分だが、5つ以上の項目があったり、複数の画面を遷移したりする必要があるなら、ページ遷移を選択すべきだ。モーダル内での滞在時間が長くなるほど、ユーザーは「閉じ込めてられている感覚」を抱きやすくなる。
ステップ3：背景情報の参照が必要かを確認する
作業中に元の画面にあるデータをコピー＆ペーストしたり、数字を見比べたりする必要があるか。もし「Yes」なら、モーダルは不適切だ。背景を完全に隠さない「ノンモーダルなサイドパネル」や、画面を分割する「スプリットビュー」を検討しよう。これにより、ユーザーは必要な情報を視界に入れながら作業を進められる。
ステップ4：最適なオーバーレイ形式を選ぶ
オーバーレイを使うと決めた場合でも、必ずしも「モーダル（背景ロック）」である必要はない。情報を表示するだけならツールチップで十分だし、作業を補助するだけなら浮動式のノンモーダル・ウィンドウが適している。ユーザーの注意を完全に引く必要がある「最後の手段」としてのみ、モーダルを選択するのが正しい設計のあり方だ。
WordPress運用におけるUI設計のヒント
WordPressサイトをカスタマイズしたり、プラグインを開発したりする際にも、この考え方は非常に役立つ。現代のWordPress（Gutenbergエディタ）は、この「モーダルを避ける」というトレンドを色濃く反映している。
サイドバー（設定パネル）の活用
Gutenbergのブロック設定は、モーダルではなく右側のサイドバーに集約されている。これは、記事の本文（コンテキスト）を見ながら、フォントサイズや色を調整できるようにするためだ。もしこれがモーダルだったら、変更を適用するたびにモーダルを閉じ、見た目を確認し、また開くという不毛な作業が発生していただろう。
独自の設定画面を作る際も、安易にポップアッププラグインを使うのではなく、WordPress標準のサイドバーUIや、インライン編集（その場での書き換え）を検討してみよう。これにより、管理画面の操作性が劇的に向上する。
CSSによるシンプルなモーダル実装例
最新のブラウザでは `
/* サイドドロワーの基本スタイル */
.side-panel {
position: fixed;
top: 0;
right: 0;
width: 300px;
height: 100%;
background: #ffffff;
box-shadow: -2px 0 10px rgba(0,0,0,0.1);
z-index: 1000;
padding: 20px;
box-sizing: border-box;
}このデモは、画面の右側に補助的なパネルを表示する「サイドドロワー」の概念を視覚化したものだ。中央のメインコンテンツを覆い隠さないため、ユーザーは情報を参照しながら作業を継続できる。※このデモはCSSの概念を視覚化したイメージである。
この記事のポイント
- モーダルは「背景を操作不能にする」ものであり、ユーザーのフローを完全に遮断する。
- 自己完結型の短いタスクや、破壊的操作の最終確認にはモーダルが適している。
- 複雑なワークフローやデータの比較が必要な場合は、別ページかサイドパネルを選択する。
- エラーメッセージやオンボーディングでのモーダル多用は、ユーザーの離脱を招くアンチパターンだ。
- 「文脈維持」「タスクの長さ」「参照の必要性」の3軸で判断する意思決定フローを活用する。
出典
- Smashing Magazine “Modal vs. Separate Page: UX Decision Tree”（2026年3月19日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress開発の転換点：PHPのみでGutenbergブロックを構築する方法
WordPressのブロックエディタ（Gutenberg）が登場して以来、カスタムブロックの開発にはReactやNode.jsといったJavaScriptベースの技術習得が不可欠だった。しかし、最新のアップデートにより、PHPコードのみでブロックを構築・管理できる手法が確立された。この変更は、従来のPHP中心のWordPress開発者にとって、学習コストを劇的に下げる重要な転換点となる。
Gutenberg 21.8以降で導入されたこの機能により、サーバーサイドのJavaScript環境を構築することなく、PHPの関数だけでエディタとフロントエンドの両方にブロックを表示できる。ビルドプロセスの複雑さを排除し、保守性の高いサイト制作を可能にするのが「PHP-onlyブロック」だ。
本記事では、PHPのみでブロックを登録する具体的な手順から、管理画面UIの自動生成、さらには既存のショートコードをブロック化する実践的なテクニックまでを詳しく解説する。この記事を読むことで、最新のWordPress標準に準拠した効率的な開発手法を習得できるはずだ。
PHP-onlyブロックの概要と導入のメリット
これまで、カスタムブロックを作成するには、Reactの知識に加え、WebpackやNPM（Node Package Manager）を用いたビルド環境の構築が必須であった。これは、主にサーバーサイドのPHPでサイトを構築してきた開発者にとって、非常に高い参入障壁となっていた。PHP-onlyブロックは、この障壁を取り払うために設計された仕組みだ。
なぜPHPだけでブロックが作れるようになったのか
WordPress開発チームは、ブロックエディタの普及をさらに加速させるため、従来のPHP開発者が慣れ親しんだ手法でブロックを作成できる環境を整えた。具体的には、サーバー側で登録されたメタデータをエディタ（JavaScript側）へ自動的に受け渡す「auto_register」機能が実装されたことが大きい。これにより、エディタ用のJSファイルを手動で記述する必要がなくなったのだ。
開発者にとっての3つの主要な利点
第一の利点は、学習コストの圧倒的な低減だ。ReactやNode.jsの複雑なエコシステムを学ぶ時間を、サイトの機能向上やデザインのブラッシュアップに充てることができる。第二に、フロントエンドのパフォーマンス向上が挙げられる。不要なJavaScriptの読み込みを削減できるため、ページの読み込み速度を最適化しやすい。第三に、保守性の向上だ。PHPコード一箇所でブロックの定義と出力（レンダリング）を管理できるため、コードの可読性が高まり、バグの混入を防ぎやすくなる。
基本的なPHP-onlyブロックの作り方
PHP-onlyブロックの作成は、従来の「動的ブロック（Dynamic Blocks）」の登録方法と似ているが、最大の違いはエディタ用のスクリプトを指定せずに、特定のフラグを有効にする点にある。元記事の著者は、最小限のコードでブロックを動作させる手法を示している。
register_block_type と auto_register の役割
ブロックの登録には、WordPress標準の `register_block_type` 関数を使用する。この関数の `supports` 配列内に `’auto_register’ => true` を含めることが、PHP-onlyブロックとして動作させるための鍵となる。このフラグが有効な場合、WordPressは `ServerSideRender` というコンポーネントを自動的に使用し、管理画面上でもPHPで生成されたHTMLをプレビュー表示する。
最小構成のコード例
以下は、プラグインやテーマの `functions.php` に記述することで動作する、最もシンプルなPHP-onlyブロックのコードだ。
/**
* レンダリング用コールバック関数
*/
function my_simple_php_block_render( $attributes ) {
return '<div style="padding: 20px; background: #f0f0f0; border: 2px solid #0073aa;">
<h3>🚀 PHP-only ブロック</h3>
<p>このブロックはPHPのみで生成されています。</p>
</div>';
}
/**
* ブロックの登録
*/
add_action( 'init', function() {
register_block_type( 'my-custom/php-block', array(
'title' => 'シンプルなPHPブロック',
'icon' => 'admin-plugins',
'category' => 'text',
'render_callback' => 'my_simple_php_block_render',
'supports' => array(
'auto_register' => true,
),
) );
});🚀 PHP-only ブロック
このブロックはPHPのみで生成されています。
このコードを有効にすると、ブロックエディタの追加メニューに「シンプルなPHPブロック」が表示され、設置すると即座にグレーの枠線で囲まれたプレビューが表示される。これがPHP-only開発の第一歩だ。
属性（Attributes）を活用した管理画面UIの自動生成
単にHTMLを出力するだけでなく、ユーザーがエディタ上でテキストを変更したり、オプションを選択したりできるようにするには「属性（Attributes）」を定義する必要がある。最新のGutenbergでは、PHPで定義した属性に基づいて、サイドパネル（インスペクター）の入力フィールドを自動生成する機能が追加されている。
属性の定義と入力フィールドの対応関係
属性のデータ型（type）を指定することで、WordPressは適切なUIコンポーネントを割り当てる。著者によれば、現在のところ以下のマッピングがサポートされている。
- string: テキスト入力フィールド
- number / integer: 数値入力フィールド
- boolean: チェックボックス（またはトグル）
- enum（string内）: セレクトボックス（ドロップダウン）
実践的な属性付きブロックのコード
以下の例では、タイトル、表示数、有効/無効の切り替え、サイズ選択の4つの属性を持つブロックを定義している。これらはすべて、JavaScriptを一行も書かずに管理画面のサイドバーに表示される。
register_block_type( 'my-plugin/advanced-php-block', array(
'title' => '設定付きPHPブロック',
'attributes' => array(
'blockTitle' => array( 'type' => 'string', 'default' => 'デフォルトタイトル' ),
'itemCount' => array( 'type' => 'integer', 'default' => 5 ),
'isEnabled' => array( 'type' => 'boolean', 'default' => true ),
'displaySize' => array(
'type' => 'string',
'enum' => array( 'small', 'medium', 'large' ),
'default' => 'medium',
),
),
'render_callback' => 'my_advanced_render_func',
'supports' => array( 'auto_register' => true ),
) );この仕組みの導入により、複雑なReactコンポーネント（TextControlやSelectControlなど）を組み合わせて `edit.js` を作成する手間が省ける。ただし、現時点ではリッチテキストエディタ（RichText）や高度なカラーピッカーなど、一部の複雑なコントロールはJS側での定義が必要な場合がある点には注意が必要だ。
実践例：カスタマイズ可能な価格表ブロックの構築
より実用的な例として、Web制作の現場で頻繁に求められる「価格表（料金テーブル）」ブロックをPHPのみで作成する手法を解説する。ここでは、WordPress標準のスタイル機能（色、間隔、タイポグラフィ）を統合する方法が重要となる。
get_block_wrapper_attributes によるネイティブ機能の統合
PHP-onlyブロックで最も強力な武器となるのが `get_block_wrapper_attributes()` 関数だ。この関数は、ユーザーがエディタのサイドバーで設定した背景色、文字色、パディング、マージンなどのスタイル情報をクラス名やインラインスタイルとして一括生成してくれる。これをメインの `div` タグに出力するだけで、自作ブロックがWordPressの標準デザインツールに完全対応する。
価格表ブロックのレンダリング設計
著者が提案する「Smart Pricing Widget」の例では、プラン名、価格、ボタンテキストなどの属性に加え、`supports` 配列で `color`, `spacing`, `typography`, `shadow`, `border` を有効にしている。これにより、エンジニアがCSSを細かく調整しなくても、運用者がエディタ上で自由に見た目をカスタマイズできるようになる。
function render_smart_pricing_block( $attributes ) {
// 属性の取得
$plan_name = esc_html( $attributes['planName'] );
$price = intval( $attributes['price'] );
// スタイル属性の生成
$wrapper_attributes = get_block_wrapper_attributes( array(
'class' => 'my-pricing-card',
) );
return sprintf(
'<div %s>
<h3>%s</h3>
<div class="price">¥%d</div>
<a href="#" class="btn">申し込む</a>
</div>',
$wrapper_attributes,
$plan_name,
$price
);
}プロフェッショナル
PHPのみで作成され、エディタの色設定が反映される価格表ブロックのイメージ
既存のショートコードをブロックへ変換する方法
PHP-onlyブロックの最も現実的かつ即効性のある活用シーンは、古いサイトで多用されている「ショートコード」のブロック化だ。ショートコードは入力が煩雑でプレビューも困難だが、PHP-onlyブロックでラップすることで、直感的な操作感へとアップグレードできる。
ショートコードをラップするメリット
ショートコードをそのまま使い続けるのではなく、ブロックとして再定義することで、ユーザーは「`[my_shortcode type=”info”]`」のような文字列を打ち込む必要がなくなる。代わりに、サイドバーのドロップダウンから「情報」「警告」「エラー」を選択するだけで済むようになる。内部的には既存のショートコード関数を呼び出すため、ロジックを書き直す必要もない。
do_shortcode を使ったレンダリング手法
実装方法は非常にシンプルだ。ブロックの `render_callback` 内で、受け取った属性を基にショートコード文字列を組み立て、WordPress標準の `do_shortcode()` 関数に渡すだけである。記事によれば、これにより管理画面上でもショートコードの実行結果がリアルタイムにプレビューされ、編集体験が劇的に向上するという。
function render_shortcode_wrapper_block( $attributes ) {
$type = esc_attr( $attributes['alertType'] );
$msg = esc_attr( $attributes['message'] );
// 既存のショートコードを動的に生成
$shortcode = sprintf( '[my_alert type="%s"]%s[/my_alert]', $type, $msg );
return sprintf(
'<div %s>%s</div>',
get_block_wrapper_attributes(),
do_shortcode( $shortcode )
);
}WordPress開発の未来とPHP-onlyブロックの立ち位置
PHP-onlyブロックは現在、非常に強力なツールとして進化を続けているが、すべてのJavaScript開発を置き換えるものではない。高度なインタラクションや、複雑な状態管理が必要なUI（例：ドラッグ＆ドロップを伴う高度なレイアウトエディタなど）には、依然としてReactによる開発が適している。
しかし、中小規模のWebサイト制作や、社内向けのカスタム機能の実装においては、PHP-onlyブロックで十分なケースが大半だ。著者も指摘するように、この機能は「ブロックエコシステムを、高度なJavaScriptを操る層以外にも広げる」ための重要な架け橋となるだろう。今後は、より多くの管理画面コントロールがPHPから定義可能になり、JSを書く必要性はさらに低下していくと予想される。
我々Web制作に携わる者にとって、技術の選択肢が増えることは歓迎すべきことだ。プロジェクトの予算、納期、そして保守を担当するチームのスキルセットに合わせて、ReactベースのブロックとPHP-onlyブロックを適切に使い分ける「ハイブリッドな開発スタイル」が、これからのスタンダードになると考えられる。
この記事のポイント
- React/Node.js不要: 複雑なビルド環境なしでカスタムブロックが作成可能。
- auto_registerフラグ: PHPで定義した属性から管理画面のUIを自動生成できる。
- 保守性の向上: PHPコード一箇所で定義と出力を管理でき、コードの可読性が高い。
- ショートコードの進化: 既存のショートコードを簡単に、プレビュー可能なブロックへ変換できる。
- ネイティブ機能の統合: `get_block_wrapper_attributes` でWordPress標準のスタイル設定に即座に対応可能。
出典
- Kinsta Blog「How to build PHP-only Gutenberg blocks」（2026年3月19日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPress 7.0開発最新状況——リアルタイム共同編集とAI連携の標準化が加速
WordPress 7.0のリリースサイクルが佳境を迎えている。2026年3月現在、Gutenberg 22.6のリリースによって主要な機能セットが確定し、3月19日にはリリース候補版（RC1）の公開が予定されている。
今回のメジャーアップデートでは、長年待望されていたリアルタイム共同編集（RTC）の基盤実装や、AIサービスとの連携を標準化する「AIコネクター」など、プラットフォームとしての在り方を大きく変える機能が導入される。現在はBeta 3が公開されており、広範囲なテストが呼びかけられている状況だ。
本記事では、WordPress 7.0で導入される主要機能の技術的背景と、開発者が準備すべきポイントについて、最新の動向を基に解説する。
WordPress 7.0の新機軸：リアルタイム共同編集（RTC）の実装
WordPress 7.0における最大の技術的トピックは、リアルタイム共同編集（RTC: Real-time Collaboration）の導入だ。複数のユーザーが同時に同じ投稿を編集できるこの機能は、これまで外部プラグインや特定のホスティング環境に依存していたが、ついにコア機能として組み込まれる。
HTTPポーリングによる高い互換性の確保
RTCの実装において、技術チームは当初検討されていたWebRTCではなく、HTTPポーリングによる同期プロバイダーを選択した。WebRTCはリアルタイム性に優れる一方で、サーバー構成やファイアウォールの設定によっては通信が不安定になる欠点がある。あらゆるホスティング環境での動作を保証するため、あえて汎用性の高いHTTPポーリングが採用された形だ。
データの整合性を保つ仕組みには、CRDT（Conflict-free Replicated Data Type / 衝突のない複製データ型）が採用されている。これは、複数の場所で同時に行われた変更を、矛盾なく統合するための数学的なアルゴリズムだ。更新データは「wp_sync_storage」という内部ポストタイプに保存され、定期的に圧縮・バッチ処理されることで、データベースへの負荷を最小限に抑える工夫がなされている。
拡張性を考慮した同期アーキテクチャ
この同期システムは、トランスポート層（通信手段）とストレージ層（保存先）を差し替え可能な設計になっている。デフォルトでは2名までの同時編集に制限されているが、ホスティング事業者は独自の同期プロバイダーを導入したり、wp-config.phpの設定値を変更したりすることで、より多人数での編集や高度なパフォーマンス最適化を図ることができる。
RTCをデフォルトで有効化するかどうかの最終判断は、RC2（リリース候補版2）前後で行われる予定だ。プラグイン開発者は、既存のメタボックスやカスタムフィールドがこの共同編集モードと競合しないか、事前の検証が求められる。
AI連携の標準化：AIコネクターとプロバイダーパッケージ
WordPress 7.0では、AIサービスとの通信を標準化するための「コネクター」機能が導入される。これは、特定のAIベンダーに依存せず、共通のインターフェースを通じてAI機能を利用できるようにするインフラストラクチャだ。
php-ai-clientによる共通インターフェースの提供
この機能の核となるのは「php-ai-client」パッケージだ。これは、主要なAIサービスとの通信を抽象化するPHPライブラリである。開発者はこの共通インターフェースに対してコードを書くことで、背後のAIプロバイダー（OpenAI、Google、Anthropicなど）が何であっても、同じように機能を実装できるようになる。
すでにプラグインディレクトリには、OpenAI、Google、Anthropicの各プロバイダーパッケージが公開されている。これにより、ユーザーは管理画面の「コネクター」設定から好みのAIサービスを選択し、APIキーを入力するだけで、サイト全体でAI機能を活用できる環境が整う。
プラットフォームとしてのAI対応
これまでAI機能は各プラグインが個別にAPI連携を実装していたが、コアが認証情報の管理やプロバイダーの選択を担うことで、開発効率とセキュリティが向上する。例えば、コンテンツ生成プラグインとSEO最適化プラグインが、同じAIコネクターの設定を共有するといった運用が可能になる。これは、WordPressが単なるCMSから「AI対応のオペレーティングシステム」へと進化する重要な一歩と言えるだろう。
編集体験の進化：視覚的な変更履歴とコンテンツ専用編集モード
ユーザーインターフェース（UI）の面でも、WordPress 7.0は大きな進化を遂げている。特にリビジョン管理とパターン編集の操作性が大幅に改善された。
カラーコードによる直感的なリビジョン管理
新しいリビジョンパネルでは、ドキュメント内の変更箇所が視覚的に強調表示されるようになった。追加されたブロックは緑、削除されたブロックは赤、設定が変更されたブロックは黄色で縁取りされる。テキスト内容についても、下線（追加）や打ち消し線（削除）を用いて、どこがどう変わったのかが一目で判別できる。
この機能はパフォーマンスにも配慮されており、まず変更されたブロックを素早く特定し、その後に詳細なテキスト比較を行う2段階のプロセスを採用している。テーマの色設定に合わせてカラーが自動調整されるため、どのようなデザインの編集画面でも視認性が損なわれない点も特徴だ。
構造を保護するコンテンツ専用編集（Content-Only Mode）
WordPress 7.0から、パターン編集のデフォルトが「コンテンツ専用編集モード」となる。このモードでは、レイアウトやスタイルの設定が隠され、ユーザーはテキストや画像などのコンテンツ入力に集中できる。これにより、誤ってデザインを崩してしまうリスクを低減できる。
構造的な編集が必要な場合は、パターンを「切り離す（Detach）」ことでフルアクセスが可能になる。管理者は、PHPフィルターやJavaScriptを使用して、非同期パターンのコンテンツ専用モードを無効化することも可能だ。制作会社がクライアントにサイトを引き渡す際、運用の安全性を高めるための強力なツールとなるだろう。
開発者向けツールとテーマ機能のアップデート
開発ワークフローを支えるツール群や、テーマ開発に役立つ新機能も多数追加されている。特にWP-CLIの強化と、ブロックの表現力向上に注目したい。
WP-CLIの新コマンドとPlaygroundの拡充
WP-CLIチームは、ブロックエンティティへの読み取り専用アクセスを提供する「wp block」コマンドや、権限管理を行う「ability」コマンドの開発を進めている。これらはWP-CLI v3.0の一部として、3月末の安定版リリースに向けて調整中だ。
また、ブラウザ上でWordPressを動作させる「WordPress Playground」のランタイムにおいて、phpMyAdminのサポートが追加された。wp-env.jsonの設定に1行加えるだけで、Docker環境と同等のデータベース管理ツールが利用可能になる。ローカル開発環境の構築がこれまで以上に迅速化される見込みだ。
アイコンブロックとナビゲーションオーバーレイ
テーマ制作において要望の多かった「アイコンブロック」がついに導入される。SVGアイコンをライブラリから選択して配置できる機能で、サーバーサイドの「SVG Icon Registration API」によって制御される。現在は標準のアイコンセットのみだが、将来的にはサードパーティ製のアイコンコレクションを登録できる拡張性も計画されている。
さらに、ナビゲーションブロックのモバイルメニュー（オーバーレイ）が完全にカスタマイズ可能になった。「ナビゲーションオーバーレイ」というテンプレートパーツとして独立したため、モバイル専用のメニューデザインを自由なレイアウトで作成できる。これは、モバイルファーストのデザインが求められる現代のWeb制作において、非常に価値の高いアップデートだ。
セキュリティアップデートと今後のロードマップ
新機能の開発が進む一方で、既存バージョンのメンテナンスも継続されている。2026年3月10日には、WordPress 6.9.2（および6.9.4までのマイナーアップデート）がリリースされた。これには10件の脆弱性修正が含まれており、中にはSSRF（サーバーサイドリクエストフォージェリ）やXSS（クロスサイトスクリプティング）といった重要度の高いものも含まれる。
開発チームは、すべてのユーザーに対して直ちにこれらのマイナーアップデートを適用するよう強く推奨している。セキュリティはサイト運営の根幹であり、新機能のテストを行う際も、まずは基盤となる環境の安全性を確保することが先決だ。
WordPress 7.0の正式リリースは4月に予定されている。RTCやAIコネクターといった野心的な機能が安定して動作するか、RC版での検証結果が待たれるところだ。開発者は、自身のプラグインやテーマがこれらの新機能とどのように相互作用するかを確認し、必要に応じてコードの修正を進めるべきだろう。
この記事のポイント
- リアルタイム共同編集（RTC）: HTTPポーリングとCRDTを採用し、あらゆるホスティング環境で安全な同時編集を可能にする。
- AIコネクターの標準化: 共通インターフェースを通じて主要AIサービスと連携。ベンダーに依存しないAI機能の実装が可能になる。
- 視覚的なリビジョン管理: 変更箇所をカラーコードで強調表示。直感的な変更履歴の追跡が可能になり、編集ミスを防ぐ。
- テーマ・開発ツールの強化: アイコンブロックの導入やナビゲーションオーバーレイの刷新、WP-CLIの新コマンドにより開発効率が向上する。
- セキュリティの重要性: 6.9.x系の脆弱性修正が公開されており、7.0への移行準備と並行して既存サイトの即時アップデートが必要だ。
出典
- Developer WordPress News「What’s new for developers? (March 2026)」（2026年3月10日）
- WordPress.org「WordPress 7.0 Beta 3」（2026年3月5日）
- Make WordPress Core「Real-Time Collaboration in the Block Editor」（2026年3月10日）
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験