WordPress 7.0「Armstrong」がリリースされました – 2026年5月20日公開、主要変更点まとめ

WordPress 7.0「Armstrong」（表記によっては WordPress7・ワードプレス7.0）が、2026年5月20日 17:00 UTC (日本時間5月21日未明) に正式リリースされました。当初は2026年4月9日のリリースが予定されていましたが、リアルタイム共同編集 (RTC) のアーキテクチャ作り直しが必要になったため、5月20日に延期されました。その後、5月8日の RC3 リリース時には RTC を 7.1 リリースサイクルへ延期する判断が公式に発表され、5月14日 (日本時間5月15日) には RC4、5月19日には RC5 が出て、予定通り5月20日のリリースを迎えています。

ここまでの流れを整理すると、WordPress 7.0 は2026年5月20日にリリースされたもので、Notes 機能、ビジュアルリビジョン、DataViews による管理画面の刷新、AI 連携の基盤 (WP AI Client / Connectors API)、PHP と MySQL の動作環境の引き上げ、ブロック API バージョン 3 への移行など、サイト運営にもプラグイン開発にも関わる大きな変更が含まれます。コードネームの「Armstrong」は、ジャズトランペット奏者の Louis Armstrong にちなんでいます。

リリースされた今、確認できる公式情報をもとに、サイト運営者・ブロガー・プラグイン利用者・プラグイン開発者の目線で「何が変わったのか」「これから何を準備すべきか」を整理します。

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

• WordPress 7.0 のリリースと現在の状況
• (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 はいつリリースされた？ ― 2026年5月20日リリースと現在の状況

WordPress 7.0「Armstrong」は、2026年5月20日 17:00 UTC (日本時間5月21日未明) に正式リリースされました。

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

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

RC4 は hard string freeze の段階でした。ここから先は翻訳対象となる文字列の追加・変更が原則停止されたため、Polyglots Team による翻訳作業が本格化しました。日本語ロケールでも、リリースに向けて翻訳率を上げる動きが進みました。

リリーススクワッドは、リリースリードを Matias Ventura、テックリードを Ella van Durpe、Mukesh Panchal、Sergey Biryukov の3名が務めています。今回のリリースには、875 名を超える貢献者 (うち初参加が 200 名以上) が関わり、420 を超える機能強化と修正が入りました。コア開発者の名前まで把握しておくと、Make WordPress Slack や Trac でのアナウンスを追いかけるときに見通しが良くなります。

RC3、RC4、RC5 と段階を踏み、コードフリーズ期間も経て、予定通り5月20日にリリースされました。本番サイトでいきなり更新するのではなく、検証用の環境で確認してから本番に反映する、という方針自体は変わりません。むしろ、リリース直後はプラグイン側の互換性修正が集中するため、本番更新は数日から 1〜2 週間ほど待つほうが安全です。

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 でのアナウンスを追いかけるときに見通しが良くなります。

なお、2026年は WordPress が年3回のメジャーリリースに戻る年でもあります。2025年は法的紛争やコントリビューターの離脱など外部要因の影響で開発リズムが乱れていましたが、2026年は7.0、7.1、7.2が予定されており、安定したペースに戻りつつあります。7.1 は WordCamp US に合わせて2026年8月19日が目標とされています。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 リリースサイクルへの延期が決まりました。Matt Mullenweg は「現状のアプローチが Core に入れるほど堅牢だと確信が持てない」として、処理範囲の広さ、競合状態、サーバー負荷、メモリ効率、ファズテストで見つかる不具合などを理由に挙げています。

この変更は、企業のオウンドメディア、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 上で記事の確認や修正依頼をしやすくするための機能です。RTC が外れた今回のリリースでは、Notes が共同作業まわりの中心的な機能になりました。

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

Notes 機能を使うと、WordPress の編集画面上でコメントを残し、修正依頼や確認事項を管理しやすくなります。特定のブロックや文章に対してコメントを残せるうえ、@メンションで担当者に通知も飛ばせるため、レビューのやり取りが散らばりにくくなります。リアルタイムの同時編集ではなく、非同期のコメントベースですが、「下書きを Google ドキュメントにコピーしてコメントして貼り戻す」という流れからは抜け出せます。

Notes 機能自体は WordPress 6.9 で先行導入されており、7.0 でも引き続き使えます。7.0 では、インラインでコメントを追加するためのキーボードショートカットなど、RTC に依存しない改善が入りました。一方で、当初予定されていた「Notes のリアルタイム同期」については、RTC が 7.1 へ延期されたことに伴い、リアルタイム同期部分も同じく 7.1 で再評価される見込みです。

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

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

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

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

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

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

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

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

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

WordPress 7.0 では、投稿、ページ、メディアの一覧画面が DataViews に置き換わりました。大量の記事を管理しているサイトでは、絞り込みや並び替えのレスポンスが大きく改善する一方で、これらの一覧画面に独自の列、独自のフィルター、独自の一括アクションを追加するプラグインを使っている場合は、表示崩れや機能不全が起きないか確認しておく必要があります。リリース直後にもっとも互換性トラブルが出やすいのが、この 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 サービスを使う場合は、ユーザーやプラグイン側で設定する必要があります。プロバイダーを 1 つも設定しなければ AI 機能は動かないため、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つの抽象レイヤーを通すことで、プロバイダーの切り替えがコード書き換えではなく設定変更で済むようになります。入口は wp_ai_client_prompt() 関数で、メソッドチェーン形式でテキスト・画像・音声・動画生成を扱えます。基盤には、コミュニティで開発されてきた php-ai-client パッケージが使われています。

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

WordPress 7.0 のリリースに合わせて、Plugin Directory に3つの公式プロバイダープラグインが公開されました。これらは Core には同梱されておらず、必要に応じて別途インストールする形です。

• OpenAI (ChatGPT、GPT などの 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 統合の基盤になっていく見込みです。

WP AI Client を、自作 AI プラグインの開発者という実装目線でさらに掘り下げた記事も用意しています。プラグイン側からどう呼び出すか、php-ai-client との関係などに踏み込んだ「WordPress 7.0 WP AI Client を実装目線で読み解いた話」もあわせてどうぞ。

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

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 といったフィルターも追加されています。

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

カバーブロックに動画背景を使えるようになりました。7.0 では、ローカルにアップロードした動画だけでなく、YouTube や Vimeo の URL を背景動画として指定できます。トップページやランディングページで動きのある表現を作りやすくなります。

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

レスポンシブ対応の 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月7日更新) では、MySQL 8.0 以上または MariaDB 10.6 以上が推奨として示されています。推奨は MySQL 8.4 LTS、MariaDB 11.4 LTS とされています。なお、技術的なハード最低要件としては MySQL 5.5.5 / MariaDB 10.4 のままですが、これらはすでにサポートが終了しているため、本番運用では推奨ラインに合わせるのが安全です。

これは、PHP の引き上げよりも実は厄介な可能性があります。レンタルサーバーによっては、PHP は管理画面から自由に切り替えられても、MySQL のバージョンはサーバー側で固定されていることが多いためです。MySQL 5.7 は Oracle のサポートが 2023年10月に終了しており、推奨ラインの引き上げ自体は妥当な流れです。

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

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

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

より踏み込んだ技術的な変更点 (apiVersion 3、PHP 7.4、DataViews) は、開発者向けにまとめた「WordPress 7.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 バージョンのままです。リリースを受けて、まずは自分のプラグインの 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 で一部メタボックスを使っているので、ここも見直す予定です。

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つです。

サイト運営者向けに、更新前の準備と手順だけをコンパクトにまとめた「WordPress 7.0 アップデート前にサイト運営者が確認しておきたいこと」も用意しています。あわせてどうぞ。

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 以上が示されています。ハード最低要件は MySQL 5.5.5 のままですが、すでにサポート終了しているため、本番では推奨ラインに合わせるのが安全です。

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

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

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

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

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

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

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

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

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

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

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

セキュリティ修正が含まれる場合は別ですが、大きなメジャーアップデートでは、リリース直後に細かな不具合修正が入ることがあります。特に今回は DataViews が従来の一覧画面を置き換えたため、管理画面まわりのプラグインで互換性の修正が出やすい状況です。安定運用を優先するなら、まずは公式情報と主要プラグインの対応状況を確認し、ステージング環境で問題がないことを見てから更新するのが現実的です。本番更新は、リリースから 1〜2 週間ほど様子を見てからでも遅くありません。

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

よくある質問

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

A. 2026年5月20日 17:00 UTC (日本時間5月21日未明) に正式リリースされました。コードネームは「Armstrong」です。RC3 (5月8日)、RC4 (5月14日)、RC5 (5月19日) を経ての公開でした。

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

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

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

A. 一般的なサイトでは、急いで更新するよりも、バックアップとテストを優先したほうが安全です。特に今回は DataViews による管理画面の刷新があるため、リリース直後はプラグインの互換性修正が集中します。本番更新は 1〜2 週間ほど様子を見てからが無難です。

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 のバージョンが表示されます。WordPress.org の推奨は MySQL 8.0 / MariaDB 10.6 以上です。詳しい動作は、レンタルサーバー会社のサポートに確認するのが確実です。

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

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

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

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

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

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

Q. 出荷された主な機能は何ですか？

A. AI Client (wp_ai_client_prompt() の PHP API)、3つの公式 AI プロバイダープラグイン (Anthropic / Google / OpenAI、別配布)、ブロックレベルの Notes (@メンション通知付き)、DataViews による管理画面の刷新、カバーブロックの埋め込み動画背景、PHP のみのブロック登録、ビジュアルリビジョン、カスタマイズ可能なナビゲーションオーバーレイなどです。当初の目玉だったリアルタイム共同編集は外れました。

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

WordPress 7.0「Armstrong」は、Notes、ビジュアルリビジョン、DataViews による管理画面の刷新、WP AI Client、Connectors API、新しいブロック機能、フォントライブラリのクラシックテーマ対応、PHP・MySQL の動作環境の確認、block.json apiVersion 3 への移行など、サイト運営にもプラグイン開発にも関わる大きなリリースです。当初の目玉だったリアルタイム共同編集は、5月8日の RC3 発表で 7.1 リリースサイクルへ延期されました。RC3、RC4、RC5 を経て、2026年5月20日 17:00 UTC (日本時間5月21日未明) に正式リリースされています。

メジャーアップデート直後は、プラグイン側の互換性修正が集中します。だからこそ、本番サイトでいきなり更新するのではなく、ステージング環境で先に試し、プラグインの対応状況を見て、必要なら 7.0.1 などの修正版を待つ、というやり方が現実的です。ニュース記事として大事なのは、期待感だけを伝えることではなく、確認できる情報と、まだ確定していない情報を分けて伝えることだと思います。

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

• WordPress 7.0 は2026年5月20日にリリースされました。本番サイトには急いで入れず、1〜2 週間ほど様子を見るのが安全です。
• PHP 7.4 未満は、WordPress 7.0 で自動更新対象外になる予定と公式にアナウンスされています。MySQL 8.0 以上または MariaDB 10.6 以上は WordPress.org の推奨として示されています。
• 本番サイトへの更新前に、バックアップとステージング確認を行いましょう。
• リアルタイム共同編集は 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)
• WordPress Requirements (WordPress.org、2026年5月7日更新)
• Dropping support for PHP 7.2 and 7.3 (Make WordPress Core)
• DataViews, DataForm, et al. in WordPress 7.0 (Make WordPress Core)
• Introducing the AI Client in WordPress 7.0 (Make WordPress Core)
• Block API Versions (Block Editor Handbook)

リリース後の検証予定

本記事は、WordPress 7.0「Armstrong」のリリース当日 (2026年5月20日) に公式情報を整理したニュース記事です。リリースを受けて、私自身が運営する 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月20日 (WordPress 7.0「Armstrong」リリース当日)

WordPress 7.0 関連記事

• WordPress 7.0 で開発者が確認しておきたいこと – apiVersion 3、PHP 7.4、DataViews ── 開発者向け、技術的な変更点を詳しく解説。
• WordPress 7.0 アップデート前にサイト運営者が確認しておきたいこと ── サイト運営者向け、アップデート前の準備と確認手順。
• WordPress 7.0 WP AI Client を実装目線で読み解いた話 ── WP AI Client / Connectors API を開発者目線で深掘り。