WordPress 7.0 リリース前の確認メモ – 2026年5月20日リリース予定、RC3 時点で見えている主要変更点

WordPress 7.0のリリースに向けて、公式スケジュールが更新され、RC4 (Release Candidate 4) も無事リリースされました。

今わかっていることをひとつにまとめると、WordPress 7.0は2026年5月20日にリリース予定であり、Notes機能、ビジュアルリビジョン、DataViewsによる管理画面の刷新、AI連携のための基盤(WP AI Client / Connectors API)、PHPとMySQLの動作環境要件の引き上げ、ブロックAPIバージョン3への移行など、サイト運営にもプラグイン開発にも関わる大きな変更が含まれる見込みです。

ただし、WordPress 7.0はまだ正式リリース前です。この記事では、2026年5月15日時点(RC4 リリース直後)で確認できる公式情報をもとに、サイト運営者・ブロガー・プラグイン利用者・プラグイン開発者の目線で「何が変わるのか」「今から何を準備すべきか」を整理します。

この記事では、次の内容を順番に見ていきます。

• WordPress 7.0のリリース予定日と現在の状況(RC4 リリース後)
• (7.1 へ延期された)リアルタイム共同編集で予定されていた変更点
• Notes、ビジュアルリビジョン、DataViewsを中心とした管理画面の変更点
• WP AI ClientとConnectors APIの正確な仕様
• PHP 7.4 を新しい最低サポート、MySQL 8.0+ または MariaDB 10.6+ は WordPress.org の現行要件、block.json apiVersion 3 など、技術的な変更
• アップデート前に確認しておきたい準備
• プラグイン開発者として、自作プラグインで何を直す必要があるか

WordPress 7.0のリリース予定日と現在の状況

WordPress 7.0の正式リリースは2026年5月20日予定です。残り 5 日となりました。

当初は2026年4月9日のリリースが予定されていましたが、リアルタイム共同編集(RTC)のデータベースアーキテクチャを作り直す必要があったため、スケジュールは見直されました。Make WordPress Coreの公式ページでは、2026年5月8日にRC3、5月14日にRC4(共にリリース済み)、5月19日にドライランと24時間コードフリーズ、5月20日に正式リリースという流れが示されています。

5月8日の RC3 発表のタイミングで、RTC を 7.0 から外し 7.1 リリースサイクルで再評価する判断が公式にアナウンスされました。RTC の遅延が 7.0 リリーススケジュール延長の主な理由だった経緯を考えると、これは大きな方針転換です。5月14日の RC4 リリース告知では、RTC に関する追加発表はなく、7.1 への延期方針は維持されています。

RC4 は hard string freeze ポイントです。ここから先は翻訳対象となる文字列の追加・変更が原則停止されるため、Polyglots Team による翻訳作業が本格化します。日本語ロケールでも、5月15日から5月19日のコードフリーズまでに翻訳率を上げていく動きが進んでいます。

日本語版のWordPress.orgでも、RC4のリリース後に5月20日リリースのスケジュール更新が反映されています。日本時間では、RC3が2026年5月9日、RC4が5月15日(共にリリース済み)、正式リリースが5月20日予定として案内されています。

リリーススクワッドは、リリースリードを Matias Ventura、テックリードを Ella van Durpe、Mukesh Panchal、Sergey Biryukov の3名が務めています。コア開発者の名前まで把握しておくと、Make WordPress Slack や Trac でのアナウンスを追いかけるときに見通しが良くなります。

RC4 が予定通りリリースされ、string freeze に到達したことで、リリース日程の前倒し・後ろ倒しのリスクは大きく下がりました。ここから先、5月19日のコードフリーズまでは、バグ修正による挙動の調整が中心になります。本番サイトで先行版を試すのではなく、検証用の環境で確認するのが現実的、という方針自体は変わりません。

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

2026年4月22日に Make WordPress Core からスケジュール更新が発表され、4月25日にはWordPress.org 日本語版でも翻訳が公開されました(翻訳：Akira Tachibana さん)。

このスケジュール更新では、Beta 1 からリリースまでの全マイルストーンと、各リリースパーティーの司会(リリースリード)・コミッター・セキュリティ担当・ミッションコントロール(全体調整)の名前まで明示されています。Beta 1 から正式リリースまでの全体の流れを、日本時間で整理しました。

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

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

なお、正式リリース当日の時刻は本記事執筆時点では未定(時間未定)とされており、ドライラン / 24 時間コードフリーズが終わったあと、リリースチームから順次告知される見込みです。

なお、2026年は WordPress が年3回のメジャーリリースに戻る年でもあります。2025年は法的紛争やコントリビューターの離脱など外部要因の影響で開発リズムが乱れていましたが、2026年は7.0・7.1・7.2が予定されており、安定したペースに戻る見込みです。WordPress 7.0で導入される基盤の上に、7.1で RTC を含めた共同編集機能、7.2でその先の機能が積み上がっていく、という流れを意識しておくとよさそうです。

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

WordPress 7.0で当初注目されていたのが、リアルタイム共同編集(Real-Time Collaboration、以下RTC)です。

これまでのWordPressでは、同じ投稿を複数人が同時に編集する場面にはあまり向いていませんでした。たとえば、ライターが記事を書いている最中に編集者が同じ投稿を開くと、編集ロックがかかることがあります。

WordPress 7.0で当初予定されていたのは、Googleドキュメントのように、複数のユーザーが同じ投稿を開き、それぞれの変更をリアルタイムに反映できる仕組みの導入でした。実装の遅延と、データベースアーキテクチャの作り直しが必要になったことを背景に、最終的に 7.1 リリースサイクルへの延期が決まっています。

この変更は、企業のオウンドメディア、Web制作会社、教育機関、複数人で運営しているブログなどにとって大きな意味があります。記事作成、校正、画像差し替え、公開前チェックを、WordPress上で進めやすくなる方向に進んでいるからです。7.1 のリリースタイミングは現時点で未確定ですが、当初の方向性自体は変わっていません。

共有レンタルサーバーでも動く設計が検討されていました

RTCの実装で意外と重要だったのが、デフォルトの同期方式が HTTPポーリング であった点です。当初検討されていたWebRTCは、共有レンタルサーバーや一部のホスティング環境で使えないことがあり、互換性の問題が懸念されていました。最終的にHTTPポーリングが採用されたことで、Xserverやさくらインターネットなどの一般的な共有サーバーでも動く設計を目指していました。

同期データは、内部用の専用投稿タイプ wp_sync_storage のpost_metaにCRDT(Conflict-free Replicated Data Type、競合のないレプリケート可能なデータ構造)として保存される設計でした。リクエストはバッチ化され、定期的にコンパクションされる仕組みです。WebSocketに対応したホスティング環境では、ホスト側で sync.providers フィルターを使って、より高速なWebSocket同期に差し替えることもできるよう設計されていました。

もうひとつ知っておきたいのは、初期段階では同時に編集できるユーザー数が 2人に制限 されている点です。これはクライアント側Gutenbergコードのデフォルト設定で、ホスト側で別のプロバイダーを追加するか、wp-config定数で調整することは可能です。3人以上で同時編集する運用を期待している方は、7.1 で実装された場合でも、初期段階では難しいかもしれない、という認識を持っておくとよさそうです。

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

クラシックメタボックスとの非互換性は 7.1 でも論点になりそうです

これは見落とされがちな重要な仕様でした。クラシックメタボックス(add_meta_box() で追加される旧式のメタボックス)が登録されている投稿では、リアルタイム共同編集モードが無効化される方向で設計が進んでいました。

実際の影響としては、Advanced Custom Fields(ACF)、SEOプラグイン、カスタムフィールドを多用するプラグインなどがクラシックメタボックスを使っていると、その投稿タイプでは共同編集機能が動かない、という形です。

WordPress 7.0サイクルは、プラグイン開発者にとって、クラシックメタボックスから register_post_meta() と PluginSidebar コンポーネントへの移行を進めるための「互換性ブリッジ実装の窓」として位置づけられていました。RTC が 7.1 へ延期されたことで、この移行を急ぐ必要はなくなりましたが、長期的な方向性としては変わらないと見られます。共同編集を活用したい運営者は、利用中のプラグインがクラシックメタボックスを使っていないかを今のうちに確認しておくと、7.1 のリリース時に慌てずに済みそうです。

個人ブログにも関係がありそうですが、すぐではありません

「共同編集」と聞くと、チーム向けの機能に感じるかもしれません。たしかに、最も恩恵を受けるのは複数人で運営するサイトです。

ただ、個人ブログでも無関係ではありません。外注ライターに記事を書いてもらう、知人にレビューしてもらう、編集者とやり取りしながら記事を仕上げる、といった場面では便利になる可能性があります。RTC が 7.1 で改めて実装されてからの話になりますが、当初の方針は変わっていません。

一方で、共有サーバーでは負荷や同期の遅れが気になるケースも考えられます。HTTPポーリングのおかげで動作はしますが、初期は2人制限があり、サーバーへのリクエスト頻度も増えます。利用中のサーバーやプラグインとの相性を確認しながら使うのがよさそうです。

Notes機能は、記事レビューをWordPress内で完結しやすくします

Notes機能は、WordPress上で記事の確認や修正依頼をしやすくするための機能です。

記事を公開する前に、本文の言い回し、見出し、画像、注釈などを誰かに確認してもらうことはよくあります。これまでは、Googleドキュメントで下書きを作り、コメントをもらい、それをWordPressに移すという流れになりがちでした。

Notes機能が強化されると、WordPressの編集画面上でコメントを残し、修正依頼や確認事項を管理しやすくなります。特定のブロックや文章に対してコメントを残せるため、レビューのやり取りが散らばりにくくなります。

Notes 機能自体は WordPress 6.9 で先行導入されており、7.0 でも引き続き使えます。ただし、当初予定されていた「Notes のリアルタイム同期」については、RTC が 7.1 へ延期されたことに伴い、リアルタイム同期部分も同じく 7.1 で再評価される見込みです。「インラインでコメントを追加するための新しいキーボードショートカット」など、RTC に依存しない改善は 7.0 で導入される見込みで、RC4 でも仕様変更のアナウンスはありませんでした。最終的な確定情報は、正式リリース時のリリースノートで確認するのが安全です。

ニュース記事、製品紹介記事、マニュアル記事のように、公開前の確認が重要なコンテンツでは特に役立つはずです。

ビジュアルリビジョンで、変更点を見た目で確認しやすくなります

ビジュアルリビジョンは、過去の編集内容を見た目で比較しやすくするための機能です。

WordPressには、以前からリビジョン機能があります。過去の編集履歴を確認し、必要に応じて以前の状態に戻せる便利な機能です。

ただし、従来のリビジョンはテキストやHTMLの差分が中心でした。そのため、画像の位置、ブロックの並び、カラム構成、余白など、見た目の変更は把握しづらい面がありました。

WordPress 7.0で予定されているビジュアルリビジョンでは、ページの見た目を比較しながら変更点を確認しやすくなります。実装としては「変更されたブロックを高速にチェック → フラグが立ったブロックだけリッチテキスト比較を行う」という二段階処理になっており、テーマの色設定に追従するために currentColor を使った差分表示が採用されています。ランディングページ、固定ページ、商品紹介ページなど、デザインの崩れが売上や信頼性に直結しやすいページでは、かなり実用的な改善です。

管理画面はDataViewsで大きく変わります

WordPress 7.0では、管理画面まわりの見た目や操作性に大きな変更が入ります。中心となるのが DataViews です。

DataViewsは、これまでの WP_List_Table(投稿、ページ、メディアの一覧画面で使われていた、サーバーレンダリングのHTMLテーブル)を置き換える、Reactベースのモダンなインターフェースです。リストビュー、グリッドビュー、テーブルビューといった複数の表示方式を切り替えられ、ページリロードなしでフィルタリングやソートが行えます。

WordPress 7.0では、投稿・ページ・メディアの一覧画面が DataViews に置き換わります。大量の記事を管理しているサイトでは、絞り込みや並び替えのレスポンスが大きく改善する一方で、これらの一覧画面に独自の列、独自のフィルター、独自の一括アクションを追加するプラグインを使っている場合は、表示崩れや機能不全が起きないか確認しておく必要があります。

また、開発者向けには groupByField プロパティが groupBy オブジェクトに変更されるなど、APIレベルでの破壊的変更も入っています。これらは、DataViewsを使ったカスタム管理画面を作っているプラグインで影響が出る部分です。

管理画面のCSSをカスタマイズしているサイトや、投稿一覧の表示を大きく変更するプラグインを使っている場合は、ステージング環境で必ず確認しておきましょう。

WP AI ClientとConnectors APIで、AI連携の土台が整います

WordPress 7.0では、AI機能そのものが標準搭載されるというより、AIサービスと連携するための基盤が整備されます。

ここは誤解されやすいところです。WordPress 7.0に更新しただけで、いきなり記事生成AIが動き出すわけではありません。OpenAI、Google、Anthropicなどの外部AIサービスを使う場合は、ユーザーやプラグイン側で設定する必要があります。

この方向性は、プライバシー面では重要です。設定していないAIサービスへ、勝手に記事本文やサイト情報が送信される設計ではないからです。

WP AI ClientとConnectors APIの役割

WordPress 7.0で導入される2つの相互に関連したシステムが、WP AI ClientとConnectors APIです。

WP AI Clientは、AIサービスとの通信のための標準化されたインターフェースを提供する、新しいコアPHPライブラリです。プラグインごとにOpenAI、Anthropic、Googleと個別に統合するのではなく、WP AI Clientという1つの抽象レイヤーを通すことで、プロバイダーの切り替えがコード書き換えではなく設定変更で済むようになります。基盤には、コミュニティで開発されてきた php-ai-client パッケージが使われています。

Connectors APIは、認証情報の保存とプロバイダー選択を、プラグインごとではなくプラットフォームレベルのインフラとして扱う仕組みです。管理画面の新しい「Connectors」画面で、サイトオーナーが自分の好きなAIプロバイダーを設定できます。

WordPress 7.0のリリース時点で、Plugin Directoryに3つの公式プロバイダープラグインが用意される予定です。

• OpenAI(ChatGPT、GPT-4 などの API)
• Google(Gemini API)
• Anthropic(Claude API)

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

Abilities APIのJavaScript版も登場

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

これにより、入力・出力のスキーマ、権限コールバック、注釈付きの abilities を登録できるようになり、ブラウザエージェントや WebMCP 統合の基盤になっていく見込みです。

新しいブロックとデザイン機能も追加されます

WordPress 7.0では、コンテンツ作成やデザイン調整に関わるブロック機能も強化されます。

アイコンブロック

アイコンブロックは、SVG形式のアイコンをコンテンツ内に挿入できる新しい標準ブロックです。サーバーサイドのSVGアイコン登録APIに支えられており、/wp/v2/icons というREST APIエンドポイントで検索とフィルタリングができます。初期セットは wordpress/icons パッケージから取り込まれます。

ボタンの横にアイコンを置く、特徴リストにアイコンを付ける、注意書きに視覚的な目印を加える、といった用途で使いやすそうです。

ただし、初期リリース版ではサードパーティのアイコンコレクションは登録できません。Icon registry API のアーキテクチャをもう少し詰めてから、サードパーティ登録の対応は WordPress 7.1 で予定されています。Font Awesome や Lucide のようなアイコンセットを丸ごと使いたい場合は、現状はそれらの専用プラグインが引き続き必要です。

パンくずブロック

パンくずリストは、ユーザーが今どの階層のページを見ているのかを示すナビゲーションです。SEOのためだけでなく、読者がサイト内を移動しやすくするためにも重要です。

これまではテーマやSEOプラグイン側で実装することが多い機能でしたが、ブロックとして扱えるようになり、サイト編集の自由度が上がります。WordPress 7.0では、クエリループやカスタム投稿タイプの文脈でのパンくずの挙動も改善され、開発者向けには block_core_breadcrumbs_items や block_core_breadcrumbs_post_type_settings といったフィルターも追加されています。

カバーブロックの動画背景

カバーブロックに動画背景を使えるようになると、トップページやランディングページで動きのある表現を作りやすくなります。

ただし、動画背景は見た目の印象が強い反面、ページ速度やモバイル表示に影響する場合があります。使う場合は、表示速度、ファイルサイズ、スマホでの見え方を確認したうえで導入するのが安全です。

レスポンシブ対応のGridブロックとビューポート別の表示制御

Gridブロックのレスポンシブ対応が進むと、PC・タブレット・スマートフォンでのレイアウト調整がしやすくなります。これまでCSSを書かないと難しかったカード型レイアウトや比較表風の配置も、ブロックエディタだけで作りやすくなる可能性があります。

関連して、WordPress 7.0では ブロック単位のビューポート別表示制御 も入ります。デスクトップ、タブレット、モバイルの各画面サイズで個別のブロックを表示・非表示にできるようになり、デバイスごとに別々のセクションを複製する必要が減ります。

ただし、検索エンジン向けに重要な本文をスマホだけ非表示にするような使い方は避けたほうがよいでしょう。読者にとって自然で、情報の欠落がない表示設計にすることが大切です。

フォントライブラリは、クラシックテーマでも使えるようになります

フォント管理が、すべてのテーマタイプで使えるようになる点もWordPress 7.0の大きな改善です。

これまでフォントライブラリはブロックテーマでの利用が中心でしたが、WordPress 7.0からはクラシックテーマ(PHPベースのテーマ)でも、外観 → フォント からフォントをアップロード・管理できるようになります。サポートされる形式は TTF、OTF、WOFF、WOFF2 です。

これにより、フォント管理用の外部プラグインを使わずに、ローカルにフォントファイルを置いてサイト全体に適用する運用ができます。日本語サイトではフォント選びが読みやすさに直結するため、クラシックテーマ(Cocoonなどを含む)を使っている方には地味ですが大きな改善です。

また、ブロック単位でPC・スマホの表示を切り替えやすくなることで、スマホでは長すぎる比較表を非表示にする、PCでは詳細な図を表示する、といった調整がしやすくなります。

PHP・MySQL の WordPress.org 現行要件が引き上げられています

WordPress 7.0では、サーバー要件が引き上げられます。これは多くのサイト運営者に直接影響する変更です。

PHPの最低バージョンは7.4に

これまでWordPressは PHP 7.2.24 以上が最低要件として示されていましたが、WordPress 7.0 では PHP 7.4.0 以上が必須として案内されています。Make WordPress Core の発表によれば、PHP 7.2 と 7.3 のサポートは段階的に廃止される予定です。

ここで気をつけたいのが、Make WordPress Core の案内によれば、PHP 7.2 や 7.3 のサイトには WordPress 7.0 の自動更新が提供されない予定である、という点です。これらのサイトはWordPress 6.9ブランチに留まり、セキュリティパッチだけは引き続き提供される形になる予定です。

推奨バージョンは引き続き PHP 8.3以上 です。WordPressコアは PHP 8.0 から 8.3 まで完全互換、PHP 8.4 と 8.5 はベータサポートとされています。WP AI Client などの新機能は、外部のAI SDKがそもそもPHP 8.0 以上を要求することが多く、PHP 7.4 で動作はしてもAI連携を活用するならPHP 8.2 以上が現実的です。

MySQL も WordPress.org の現行要件として 8.0 以上

もうひとつの大きな変更が、データベースの動作要件です。

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 とされています。

これは、PHPの引き上げよりも実は厄介な可能性があります。レンタルサーバーによっては、PHPは管理画面から自由に切り替えられても、MySQLのバージョンはサーバー側で固定されていることが多いためです。MySQL 5.7 は Oracle のサポートが 2023年10月に終了しており、現行要件への引き上げ自体は妥当な流れです。ただし、WordPress 7.0 正式版でデータベース要件が自動更新条件としてどう扱われるかは、2026年5月時点で公式の確定情報がまだ出ていないため、正式リリース後に WordPress.org のアナウンスを再確認するのが安全です。

MySQL/MariaDBのバージョンは、レンタルサーバーの管理画面か、WordPressの「ツール → サイトヘルス → 情報」タブで確認できます。私自身が使っているXserverは MySQL 8.0系で動作しているので問題ありませんでした。シックスコアやお名前.comなどでも MySQL 8.0 以降が標準ですが、古い格安共有サーバーや、長期契約をそのまま使い続けているケースでは確認が必要です。

プラグイン開発者として直す必要があること

ここからは、プラグインを開発・公開している方向けの話です。サイト運営者の方は読み飛ばしていただいて構いません。

私は WordPress.org に 3つのプラグイン(Rapls AI Chatbot、Thanks Mail for Stripe、Rapls PDF Image Creator)を公開しています。WordPress 7.0のリリースを前に、自分のプラグインで何を直す必要があるかをひととおり整理してみました。結果として、いくつか対応が必要な項目が出てきましたので、同じ立場の方の参考になればと思います。

block.json apiVersion 3 への移行は事実上必須です

これがプラグイン開発者にとって、WordPress 7.0で一番大きな変更です。

WordPress 7.0 以降、ポストエディタはブロック登録の状況を見て、iframe 内で動作することを前提に設計される方向で進められています。iframe 内で正しく動かすために、ブロックの block.json ファイルでは apiVersion: 3 を指定することが推奨されています。

WordPress 6.9 の時点で、apiVersion 1 や apiVersion 2 のブロックを登録すると、ブラウザのコンソールに警告が出るようになっています。WordPress 7.0では、エディタを完全にiframe化するという当初計画は7.1へ延期されたものの、新規プラグインの登録時には apiVersion 3 が必須として Plugin Check のチェックも追加される方向で議論が進んでいます。

正直に書いておくと、本記事執筆時点では、私の3プラグインはまだ apiVersion 3 への移行ができていません。Rapls AI Chatbot、Thanks Mail for Stripe、Rapls PDF Image Creator のいずれも、現状はブロックを使っていない実装か、ブロックを使っている部分が古いAPIバージョンのままです。WordPress 7.0のリリース後、まずは自分のプラグインの block.json を確認して、apiVersion 3 への対応を進める予定です。対応の過程は、リリース後の実機検証記事でまとめる予定でいます。

これからプラグインを公開する方は、新規プラグインは 最初から apiVersion 3 で書き始める のが安全です。既存プラグインで対応していない方は、WordPress 7.0 のリリースを境に対応を検討することをおすすめします。

クラシックメタボックスをサイドバーに移行する(優先度は 7.1 リリースに合わせて再評価)

共同編集の節でも触れましたが、クラシックメタボックス(add_meta_box() で追加するメタボックス)が登録されている投稿では、リアルタイム共同編集モードが無効化されます。RTC が 7.1 へ延期されたため、この対応の優先度は当初の予定より下がりました。

とはいえ、WordPress 7.0サイクルで「プラグイン開発者がメタボックスを register_post_meta() + PluginSidebar コンポーネントへ移行するための互換性ブリッジ実装の窓」として整備された部分は、7.0 で利用可能なまま残ります。すぐにすべてを移行する必要はありませんが、共同編集を活用するユーザーの体験を考えると、長期的には PluginSidebar への移行が望ましい方向性です。RTC が 7.1 で改めて実装されたタイミングで対応する、という進め方でも間に合います。

私のプラグインでも Thanks Mail for Stripe で一部メタボックスを使っているので、7.0 リリース後にここも見直す予定です。

DataViews 関連のフックを使っているプラグインは破壊的変更に注意

投稿、ページ、メディアの一覧画面に独自の列、フィルター、一括アクションを追加するプラグインは、WordPress 7.0 で挙動が変わる可能性があります。manage_posts_columns、manage_pages_columns といった WP_List_Table 系のフックを使っているコードは、DataViews 化の影響を受ける可能性があります。

また、DataViews自体のAPIにも破壊的変更が入っており、groupByField プロパティが groupBy オブジェクトに変わっています。DataViewsを使ったカスタム管理画面を実装しているプラグインは、API変更への対応が必要です。

その他の開発者向け変更

WordPress 7.0では、上記の他にも開発者に関連する変更がいくつかあります。

• Pattern Overrides の拡張：パターンオーバーライドが、コアブロックだけでなくカスタムブロックでも使えるようになります。同期パターンの中で、特定の部分だけインスタンスごとに編集を許可する仕組みです。
• スタイルバリエーションのライブプレビュー：テーマがブロックスタイルバリエーションを提供している場合、適用前にユーザーがプレビューできるようになります。パターンの contentOnly モードでもスタイルバリエーションが使えるようになります。
• @wordpress/create-block の interactive バリアント：クライアントサイドナビゲーションのサポートを最初から含む新しいスキャフォールディング用バリアントが追加されます。
• PHPのみのブロック登録：JavaScriptを書かずに、PHPだけでインスペクタコントロールを自動生成するブロック登録方式が追加されます。シンプルな設定ブロックを作るときの手間が減ります。
• Interactivity API のルーター更新：Gutenberg 22.6で @preact/signals の effect から watch へインポートが切り替わりました。Interactivity APIを使ったブロックを開発している場合、この変更を反映する必要があります。

これらの変更は、プラグインによっては影響が出るので、Make WordPress Core で公開されている各 Dev Note を読んでおくのがよさそうです。

アップデート前に確認しておきたいこと

WordPress 7.0へ更新する前に、最低限確認しておきたいのは、バックアップ、PHP・MySQLのバージョン、ステージング環境、プラグイン互換性の4つです。

1. 完全バックアップを取る

まず、ファイルとデータベースの両方を含むバックアップを取ってください。WordPress本体の更新は通常スムーズに進みますが、テーマやプラグインとの組み合わせによって不具合が起きることがあります。

バックアップを取るだけでなく、復元方法も確認しておくと安心です。バックアップファイルがあっても、戻し方が分からないと緊急時に困ります。

2. PHPバージョンとMySQLバージョンを確認する

WordPress 7.0では、動作環境要件の確認が必要です。確認するのは2つです。

• PHP：WordPress.org が示す現行要件は 7.4.0 以上、推奨 8.3 以上
• MySQL / MariaDB：WordPress.org の現行要件は MySQL 8.0+ または MariaDB 10.6+、推奨 MySQL 8.4 LTS / MariaDB 11.4 LTS

Make WordPress Core の案内によれば、PHP 7.4 未満の環境については、WordPress 7.0 で自動更新対象外になる予定と公式にアナウンスされています。データベース要件については、WordPress.org の現行要件として MySQL 8.0 以上または MariaDB 10.6 以上が示されていますが、WordPress 7.0 正式版でデータベース要件が自動更新条件としてどう扱われるかは、正式リリース後に再確認するのが安全です。サイトは WordPress 6.9 ブランチに留まることになる場合があります。

確認方法は、レンタルサーバーの管理画面、または WordPress の「ツール → サイトヘルス → 情報」タブで可能です。私自身が使っている Xserver スタンダードプランは PHP 8.3.21 / MySQL 8.0系 で稼働していたので、両方とも問題ありませんでした。古いPHPやMySQLのままになっているサイトがある場合は、リリース前にステージング環境で先に上げておくのが安全です。

古いテーマやプラグインがある状態でPHPだけ先に上げると、別の不具合が出ることもあります。必ずテスト環境で確認してから本番に反映してください。

3. ステージング環境で試す

本番サイトをいきなり更新するのは避けたほうが無難です。ステージング環境、またはローカル環境にサイトのコピーを作り、先にWordPress 7.0で表示や管理画面を確認してください。

特に確認したいのは、投稿編集画面、固定ページ、トップページ、問い合わせフォーム、SEOプラグイン、キャッシュプラグイン、独自ブロックです。

4. プラグインとテーマの対応状況を確認する

WordPress 7.0では、ブロックエディタや管理画面まわりに変更が入るため、特にこのあたりのプラグインは重点的に確認したほうがよいです。

• カスタムブロックを追加するプラグイン(block.json の apiVersion を確認)
• クラシックメタボックスを追加するプラグイン(7.1 で RTC が導入されるとさらに重要になる)
• 投稿一覧や管理画面の表示を変更するプラグイン(DataViews化の影響)
• キャッシュ・高速化系プラグイン
• 長期間更新されていないテーマやプラグイン

「更新されているから必ず安全」「有名プラグインだから必ず大丈夫」とは言い切れません。自分のサイト構成で実際に動作確認することが重要です。

WordPress 7.0への更新は急がなくてよいです

個人的には、一般的な本番サイトでは、正式リリース直後に急いで更新する必要はないと考えています。

セキュリティ修正が含まれる場合は別ですが、大きなメジャーアップデートでは、リリース直後に細かな不具合修正が入ることがあります。安定運用を優先するなら、まずは公式情報と主要プラグインの対応状況を確認し、ステージング環境で問題がないことを見てから更新するのが現実的です。

特に、仕事用サイト、収益化しているブログ、問い合わせフォームが重要なサイト、WooCommerceなどで販売しているサイトは、慎重に進める価値があります。

よくある質問

Q. WordPress 7.0はいつリリースされますか？

A. 公式スケジュールでは、2026年5月20日に正式リリース予定です。RC4 が予定通り 5月14日(日本時間5月15日)にリリースされ、string freeze に到達しました。残り 5 日となります。最終的な公開時刻はリリース直前にアナウンスされる見込みです。

Q. リアルタイム共同編集は WordPress 7.0 で使えますか？

A. いいえ。当初は 7.0 で導入予定でしたが、2026年5月8日の RC3 発表に合わせて 7.1 リリースサイクルへの延期が公式アナウンスされました。RC4 のリリース告知でも追加発表はなく、7.0 リリース時点ではリアルタイム共同編集機能は含まれません。7.1 のリリースタイミングと、改めて実装される際の仕様は、Make WordPress Core の続報をご確認ください。

Q. WordPress 7.0にすぐ更新したほうがいいですか？

A. 一般的なサイトでは、急いで更新するよりも、バックアップとテストを優先したほうが安全です。特に業務用サイトや収益化サイトでは、ステージング環境で確認してから本番に反映することをおすすめします。

Q. PHP 7.2 や 7.3 のサイトはどうなりますか？

A. Make WordPress Core の案内によれば、WordPress 7.0 の自動更新は提供されない予定です。WordPress 6.9ブランチに留まり、セキュリティパッチは引き続き提供される見込みです。長期的にはセキュリティリスクとなるので、PHP 7.4 以上、できれば 8.3 以上への更新をおすすめします。

Q. 共有レンタルサーバーで MySQL のバージョンはどうやって確認しますか？

A. WordPress 管理画面の「ツール → サイトヘルス → 情報」タブから確認できます。データベースの項目に MySQL または MariaDB のバージョンが表示されます。MySQL 8.0 / MariaDB 10.6 未満の環境では、WordPress 7.0 で警告が出たり機能が制限されたりする可能性があります。具体的な動作については、正式リリース後に WordPress.org の最新アナウンスをご確認ください。レンタルサーバー会社のサポートに確認するのが確実です。

Q. AI機能は自動で有効になりますか？

A. WordPress 7.0で予定されているのは、AI連携のための基盤(WP AI Client と Connectors API)です。AIサービスが勝手に動いたり、外部にデータを送ったりするものではありません。実際にAI機能を使うには、OpenAI、Google、Anthropic などのプロバイダープラグインをインストールし、APIキーを設定する必要があります。

Q. 古いプラグインを使っていても大丈夫ですか？

A. 確認なしに大丈夫とは言えません。特にブロックエディタ、管理画面、投稿編集画面に関わるプラグインは、更新前に対応状況を確認してください。長期間更新されていないプラグインは、代替プラグインへの移行も検討したほうが安全です。

Q. プラグイン開発者として、まず何から手をつければいいですか？

A. ブロックを提供しているプラグインなら、block.json の apiVersion を 3 に上げる対応が最優先です。投稿一覧画面の独自カラムを追加しているなら、DataViews 化の影響をテストする必要があります。クラシックメタボックスを使っているなら、register_post_meta() + PluginSidebar への移行は、RTC が 7.1 で改めて実装されるタイミングまでに進めれば間に合います。

Q. RC4 で何が変わりましたか？

A. RC4 は hard string freeze ポイントで、翻訳対象となる文字列の追加・変更が原則停止されました。ここから先、5月19日のコードフリーズまでは、バグ修正による挙動の調整が中心になります。RC4 リリース告知では、RTC の 7.1 延期方針の維持と、5月20日リリース日程の維持が改めて確認されています。

まとめ：WordPress 7.0は、更新前の準備が大切です

WordPress 7.0は、Notes、ビジュアルリビジョン、DataViewsによる管理画面の刷新、WP AI Client、Connectors API、新しいブロック機能、フォントライブラリのクラシックテーマ対応、PHP・MySQLの動作環境要件の確認、block.json apiVersion 3への移行など、サイト運営にもプラグイン開発にも関わる大きなリリースです。当初予定されていたリアルタイム共同編集は、5月8日の RC3 発表で 7.1 リリースサイクルへ延期されました。RC4 が予定通り 5月14日(日本時間5月15日)にリリースされ、string freeze に到達しています。残り 5 日で 5月20日の正式リリースを迎えます。

正式リリース前の情報には変更の可能性があります。RTC 延期のように、リリース直前に大きな方針転換が入ることもあります。ニュース記事として大事なのは、期待感だけを伝えることではなく、現時点で確認できる情報と、まだ確定していない情報を分けて伝えることだと思います。

サイト運営者としては、次の4点を押さえておけば十分です。

• WordPress 7.0の正式リリース予定日は2026年5月20日です(RC4 リリース済み、残り 5 日)。
• PHP 7.4 未満は、WordPress 7.0 で自動更新対象外になる予定と公式にアナウンスされています。MySQL 8.0 以上または MariaDB 10.6 以上は WordPress.org の現行要件として示されていますが(2026年5月時点)、データベース要件が自動更新条件としてどう扱われるかは正式リリース後に再確認するのが安全です。
• 本番サイトへの更新前に、バックアップとステージング確認を行いましょう。
• リアルタイム共同編集は 7.0 では使えません(7.1 で再評価)。AI 連携などの新機能は、正式版の仕様とプラグイン対応状況を見てから使い始めるのが安全です。

プラグイン開発者としては、次の3点が中心になります。

• ブロックを提供しているプラグインは、block.json の apiVersion を 3 に更新する。
• クラシックメタボックスは、長期的にはサイドバー化を検討する(優先度は 7.1 で RTC が再評価されるタイミングで再判断)。
• 投稿一覧画面の独自カラム・フィルターを追加しているプラグインは、DataViewsの影響をテストする。

WordPress 7.0は、急いで飛びつくアップデートというより、今後のWordPressの方向性を知るうえで重要な節目になりそうです。2026年は7.0、7.1、7.2と年3回のメジャーリリースが予定されており、7.0で導入された基盤の上に、続く7.1で RTC を含めた共同編集機能、7.2でその先の機能が積み上がっていく流れが見えています。まずは落ち着いて情報を確認し、自分のサイトとプラグインに必要な準備から進めていきましょう。

参考にした公式情報

• WordPress 7.0 Release Candidate 4(WordPress News、2026年5月14日) – RC4 リリース告知。hard string freeze ポイント。
• WordPress 7.0 Release Candidate 3(WordPress News、2026年5月8日) – RTC を 7.0 から外す判断が公開された記事です。
• RTC removed from 7.0(Make WordPress Core、2026年5月8日) – RTC を 7.1 で再評価する判断の詳細解説です。
• WordPress 7.0 Release Party Updated Schedule(Make WordPress Core、2026年4月22日)
• WordPress 7.0 リリーススケジュール更新版(WordPress.org 日本語、2026年4月25日)
• WordPress 7.0(Make WordPress Core)
• Dropping support for PHP 7.2 and 7.3(Make WordPress Core)
• DataViews, DataForm, et al. in WordPress 7.0(Make WordPress Core)
• What’s new for developers? April 2026(developer.wordpress.org)
• Block API Versions(Block Editor Handbook)
• Migrating Blocks for iframe Editor Compatibility(Block Editor Handbook)

リリース後の検証予定

本記事は、WordPress 7.0の正式リリース前(2026年5月15日時点、RC4 リリース直後)に公式情報を整理したニュース記事です。リリース後、私自身が運営する WordPress サイト(raplsworks.com)と、WordPress.org公式リポジトリで公開している3つのプラグイン(Rapls AI Chatbot、Thanks Mail for Stripe、Rapls PDF Image Creator)で、以下の項目を実機検証する予定です。

• 各プラグインの動作確認とWordPress 7.0互換性
• 3プラグインの block.json を apiVersion: 3 に更新する作業の実体験記録
• クラシックメタボックスを使っている部分の PluginSidebar への移行検討(7.1 で RTC が再評価されるタイミングに合わせて)
• WP AI Client と Connectors API のプラグイン側からの利用パターン
• DataViews 化が、自作プラグインの管理画面に与える影響
• PHP 8.3 環境での動作と、PHP 8.4・8.5 ベータでの挙動確認
• RTC が 7.1 で改めて実装された際の、Xserver スタンダードプラン(共有レンタルサーバー)での動作と負荷

本記事は「事前情報の整理(ニュース記事)」、別記事は「実機検証レポート(体験記事)」という役割で公開していく予定です。検証結果が出次第、本記事の末尾にも追記する形で、最新情報を反映していきます。

最終確認日：2026年5月15日(RC4 リリース直後、hard string freeze 適用日)

WordPress 7.0 関連記事

• WordPress 7.0 で開発者が確認しておきたいこと – apiVersion 3、PHP 7.4、DataViews(2026年5月リリース予定) ── 開発者向け、技術的な変更点を詳しく解説。
• WordPress 7.0 アップデート前にサイト運営者が確認しておきたいこと(2026年5月20日リリース予定) ── サイト運営者向け、アップデート前の準備と確認手順。