WordPress 7.0 アップデート前にサイト運営者が確認しておきたいこと(2026年5月20日リリース)

WordPress 7.0「Armstrong」が、2026年5月20日 17:00 UTC(日本時間5月21日未明)に正式リリースされました。AI 連携の基盤(Connectors API)、管理画面の刷新(DataViews 化)、Notes 機能の強化、ビジュアルリビジョン、ブロック機能の拡充など、影響範囲の広いメジャーアップデートです。当初は2026年4月9日リリースの予定でしたが、リアルタイム共同編集まわりのアーキテクチャ改善のため、5月20日へと延期されました。さらに、2026年5月8日に公開された RC3 のリリースノートで、リアルタイム共同編集(RTC)が WordPress 7.0 から外され、7.1 リリースサイクルで再評価されることが正式にアナウンスされました(WordPress 7.0 RC3 リリースノート、Make WordPress Core「RTC removed from 7.0」)。その後、5月14日(日本時間5月15日)に RC4 が hard string freeze に到達し、5月19日に RC5 がリリースされたうえで、予定通り5月20日の公開を迎えました(WordPress 7.0 RC4 リリースノート)。コードネームの「Armstrong」は、ジャズトランペット奏者の Louis Armstrong にちなんでいます。

この記事では、アップデート前に確認しておきたい変更点と、本番サイトを安全にアップデートするための準備手順をまとめます。あくまでサイト運営者の視点で書いていますので、開発者向けの細かい API 変更などには深く踏み込みません。「自分のサイト、いつ更新したらいいんだろう」と迷っている方の参考になれば幸いです。

確認日:2026年5月20日(WordPress 7.0「Armstrong」リリース当日)。本記事の情報は、WordPress 7.0 RC4 リリースノート、Make WordPress Core 公式投稿および WordPress.org 日本語版のリリーススケジュール告知をもとにしています。
確認環境:Xserver スタンダードプラン / WordPress 7.0 / PHP 8.3.21 / MySQL 8.0系 / Cocoon 2.x。

WordPress 7.0 のリリースと現在の状況

WordPress 7.0「Armstrong」は、2026年5月20日 17:00 UTC(日本時間5月21日未明)に正式リリースされました。2026年4月22日に Make WordPress Core で公開された Release Lead からの告知で、5月20日リリースの新スケジュールが発表され、日本語版の公式告知も WordPress.org 日本語版で公開されていました。

リリース直前の段取りとしては、5月8日に RC3 が公開されました。当初は名称が RC3 でも内容としては「新しい Beta 1」として扱われる位置づけになっていましたが、RC3 のリリース当日に RTC を 7.0 から外し 7.1 へ延期する判断が発表され、RC3 はもはや「新しい Beta 1 相当」としては扱われないことになりました。続いて5月14日(日本時間5月15日)に RC4 が hard string freeze に到達し、5月19日に RC5 がリリースされました。24時間のコードフリーズを経て、5月20日に正式リリースされています。

リリース後の現行安定版は WordPress 7.0 ですが、本番サイトをすぐに 7.0 へ上げる必要はありません。リリース直後はプラグイン側の互換性修正が集中するため、しばらく 6.9 系で運用しながら様子を見るのが安全です。

リリーススクワッドは、リリースリードを Matias Ventura が、テックリードを Ella van Durpe、Mukesh Panchal、Sergey Biryukov の3名が務めています。今回のリリースには 875 名を超える貢献者が関わり、420 を超える機能強化と修正が入りました。一次情報を追いたい場合は、Make WordPress Core ブログと、WordPress.org 日本語版の最新告知を確認するのが確実です。

リリースされたとはいえ、すぐに本番サイトを更新する必要は必ずしもありません。メジャーアップデートの直後は、プラグインやテーマ側の対応が追いついていないこともよくあります。個人ブログでも仕事で使っているサイトでも、まずはテスト環境で確認してから本番更新する、という順番にしておくのが無難です。

サイト運営者としては、テスト環境での検証を進め、必要なら 7.0.1 などの初期修正版を待ってから本番更新する、という流れが現実的でしょう。あわてる必要はありません。

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

2026年4月22日に Make WordPress Core からスケジュール更新が発表され、4月25日には WordPress.org 日本語版でも翻訳が公開されました(翻訳:Akira Tachibana さん)。Beta 1 から正式リリースまでの全マイルストーンが公開されているので、ここに整理しておきます。

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

RC 3 は当初「新 Beta 1 相当」、RC 4 は「新 RC 1 相当」とアナウンスされていましたが、5月8日の RC3 で RTC を 7.1 へ延期する判断が出たことで、その位置づけ自体が見直された形です。リリースチームが「予定どおりに突き進む」よりも「安定性を最優先して柔軟に組み直す」姿勢を取り続けていたことが、ここからも読み取れます。RC3・RC4・RC5 を経て、安定した状態で5月20日のリリースを迎えました。本番サイトを抱えている運営者としては、リリースから少し落ち着いてから本番更新するのが、現実的な判断軸になりそうです。

なお、2026年は WordPress が年3回のメジャーリリース体制に戻る年でもあります。2025年は法的な紛争で開発リズムが乱れたため、リリースが2回に減っていましたが、2026年は7.0、7.1、7.2と3つのメジャーリリースが予定されています。7.1 は WordCamp US に合わせて2026年8月19日が目標です。WordPress 7.0で導入された土台の上に、続く7.1・7.2で機能が積み上がる流れです。

WordPress 7.0 とは?主な新機能・変更点

WordPress 7.0 は、単なる管理画面の見た目変更ではありません。特に大きいのは、コンテンツレビュー機能(Notes、ビジュアルリビジョン)、管理画面の刷新、AI 連携、新しいブロック、動作環境の変化、というあたりです。当初は目玉として位置づけられていたリアルタイム共同編集は 5月8日の RC3 リリース時に 7.1 へ延期されましたが、その経緯も含めて順番に見ていきます。

1. リアルタイム共同編集は WordPress 7.1 へ延期されました

当初の予定では、複数のユーザーが同じ投稿や固定ページを同時に編集できるようになる機能(Google ドキュメントのような共同編集)が、7.0 の目玉のひとつとして搭載される計画でした。複数人で記事を編集している制作会社や、複数著者がいるメディアサイトには便利になるはずでした。RTC アーキテクチャの作り直しが必要になったことが、4月9日リリースから5月20日リリースへ延期された主な理由でしたが、5月8日の RC3 のタイミングで「7.0 では搭載せず、7.1 で再評価する」という判断が公式に発表されました。Matt Mullenweg は「現状のアプローチが Core に入れるほど堅牢だと確信が持てない」として、処理範囲の広さ、競合状態、サーバー負荷、メモリ効率、ファズテストで見つかる不具合などを理由に挙げています。

当初予定されていた仕様の概要だけ、参考までに書き残しておきます。共同編集の同期方式は、ホスティング環境を選ばずに動かすために、デフォルトで HTTP ポーリング方式が採用される予定でした。WebRTC は、共有レンタルサーバーや一部のホスティング環境で使えないことがあり、最終的に却下されました。Xserver、ConoHa WING、ロリポップ!などの一般的な共有サーバーでも動く設計です。RC3 のリリースノートでは、RTC アーキテクチャの新バージョンのテストに協力したホスティング会社として、Kinsta、Bluehost、GoDaddy、WordPress.com、XServer、Ionos が挙げられていました。初期段階では、同時編集できるユーザー数が2人に制限される設計でした。

これらの仕様は、7.1 で改めて実装される際に変更される可能性があります。サイト運営者として今できることは、「7.1 で RTC が再実装されたタイミングで、もう一度確認すればよい」という心づもりに切り替えることです。個人ブログや一人運営のサイトでは、急いで使い始める必要はありません。共同編集機能を本格的に使いたい方も、7.1 の正式リリースまで待つほうが現実的です。

2. Notes 機能:投稿に直接コメントを残せる

WordPress 6.9 で導入された Notes 機能が、7.0 で機能拡張されました。RTC が外れた今回のリリースでは、Notes が共同作業まわりの中心的な機能になりました。Notes は、投稿の中の特定のブロックや段落に対して、コメントを直接残せる機能です。

これまで記事のレビューは、Google ドキュメントで下書きを書いてコメントをもらい、それを WordPress に移す、というやり方が一般的でした。Notes機能を使えば、WordPress の編集画面の中で、対象のブロックに紐づいたコメントが残せます。「この見出しを変えてほしい」「この画像差し替え予定」といった指示が、編集者と書き手の間で散らばらずに済みます。@メンションで担当者に通知も飛ばせます。

WordPress 7.0 では、Notes にインラインでコメントを追加するためのキーボードショートカットなど、RTC に依存しない改善が入りました。一方で、当初予定されていた「Notes のリアルタイム同期」については、RTC が 7.1 へ延期されたことに伴い、リアルタイム同期部分も同じく 7.1 で再評価される見込みです。複数人で記事を作っているサイトでは、まずは現行の Notes 機能を使いつつ、リアルタイム同期は 7.1 のリリースを待つ、という形が現実的です。

3. ビジュアルリビジョン:見た目で変更を比較できる

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

WordPress 7.0 のビジュアルリビジョンでは、ページの見た目を比較しながら変更点を確認できます。色分けは、追加されたブロックが緑のアウトライン、削除されたブロックが赤、設定が変更されたブロックが黄色、といった形です。テキスト内では、追加された部分が緑下線、削除部分が赤の取り消し線で表示されます。過去のバージョンに戻すためのタイムラインスライダーも付きました。

ランディングページや商品紹介ページなど、デザインの崩れが売上に直結しやすいページでは、変更履歴を見直すときの安心感が大きく上がります。

4. DataViews による管理画面の刷新

投稿一覧・固定ページ一覧・メディア一覧などの管理画面が、新しいインターフェースに置き換わりました。従来の WP List Tables(古い形式の一覧表示)から、より現代的でフィルタリングしやすい一覧画面に変わるイメージです。

これは見た目だけの変更ではなく、内部の仕組みも変わります。投稿一覧・固定ページ一覧・メディア一覧の表示をカスタマイズしているプラグインは、影響を受ける可能性があります。普段使っている管理画面系プラグインがある場合は、必ずステージング環境で表示と操作を確認してください。リリース直後にもっとも互換性トラブルが出やすいのが、この DataViews 化の部分です。

「管理画面のカラムを追加するプラグイン」「投稿一覧で一括編集の項目を増やすプラグイン」などは、特に要注意です。最初は戸惑うかもしれませんが、新しい一覧画面のほうがフィルタや表示切替は柔軟になります。リスト・グリッド・テーブルの3つのレイアウトを切り替えられ、フィルタや並び替えがページリロードなしで動作します。

5. WP AI Client・Connectors API・Abilities API による AI 連携基盤

WordPress 7.0 では、AI 機能を直接搭載するというより、AI サービスと連携するための基盤が整備されました。WP AI Client、Connectors API、Abilities API などがその中心です。

ひとつ気をつけたいのは、WordPress 本体に特定の AI サービスが同梱されるわけではない点です。実際の AI 機能は、プラグインや外部サービスと組み合わせて使う形になります。WordPress 7.0 のリリースに合わせて、Plugin Directory に 3つの公式プロバイダープラグイン(OpenAI、Google、Anthropic)が公開されました。これらは Core には同梱されておらず、必要に応じて別途インストールします。さらに、コミュニティが開発した OpenRouter、Ollama(ローカル LLM 用)、Mistral などのプロバイダーも公開されています。

管理画面には新しく 「設定 → Connectors」画面が追加されました。AI プロバイダーの API キーや接続情報を、各プラグインが個別に持つのではなく、Connectors 画面で一元管理できる仕組みです。これまで AI プラグインを複数入れると API キーの設定画面が散らばっていましたが、Connectors 画面で一覧管理できるようになります。

API キーの管理や外部サービス連携が関わるので、導入する場合はプライバシーポリシーや利用規約の見直しも必要になるでしょう。「AI には興味はあるけど、いきなり使い始めるのは怖い」という方は、当面は使わない選択肢で問題ありません。プロバイダーを設定しなければ、今までどおりに動きます。

6. 新しいブロックとデザイン機能

WordPress 7.0 では、コンテンツ作成に役立つ新しいブロックや機能も追加されました。

• アイコンブロック:SVG アイコンをコンテンツ内に挿入できる新しいブロックです。これまで外部プラグインに頼っていた部分が、WordPress 標準で扱えるようになります。初期セットは標準で含まれていますが、サードパーティのアイコンセット(Font Awesome や Lucide など)を丸ごと使いたい場合は、引き続き専用プラグインが必要です
• パンくずブロック:パンくずリストを標準ブロックとして配置できるようになります。これまでは SEO プラグインやテーマ側で実装することが多い機能でした
• カバーブロックの動画背景:トップページやランディングページで、動画を背景に使えるようになります。ローカルにアップロードした動画だけでなく、YouTube や Vimeo の URL を背景動画として指定できます。表示速度に影響しやすいので、モバイルでの見え方も含めて確認したうえで導入してください
• レスポンシブ対応の Grid ブロック:画面サイズに合わせてレイアウトが自動調整されるようになります。比較表やカード型レイアウトが組みやすくなります
• ビューポート別表示制御:ブロック単位で、デスクトップ・タブレット・モバイルでの表示・非表示を切り替えられます。これまではプラグインや独自 CSS が必要だった機能です

ビューポート別表示制御を使うと、PC では詳細な比較表を表示し、スマホでは簡略版に切り替える、といった調整がブロック単位でできるようになります。ただし、検索エンジン向けに重要な本文をスマホだけ非表示にするような使い方は避けたほうがよさそうです。読者にとって自然で、情報の欠落がない表示設計を心がけましょう。

7. フォントライブラリがすべてのテーマで使えるように

これまでブロックテーマ向けの機能だったフォントライブラリが、WordPress 7.0では クラシックテーマ(PHP ベースのテーマ)でも使えるようになりました。サポートされる形式は TTF、OTF、WOFF、WOFF2 です。

「外観 → フォント」からフォントをアップロードして管理できるようになります。Cocoon を使っているサイトでは、これまで独自のフォント管理プラグインを併用していた場合があると思います。WordPress 標準のフォントライブラリと既存のフォント管理プラグインがバッティングしないか、ステージング環境で確認しておくとよさそうです。

8. PHP・MySQL の動作環境が WordPress.org 現行要件に合わせて引き上げられました

WordPress 7.0 のリリースに合わせて、サーバー要件の確認も必要です。これは多くのサイト運営者に直接影響します。Make WordPress Core の案内によれば、PHP 7.4 未満の環境については、WordPress 7.0 で自動更新対象外になる予定と公式にアナウンスされています。これらのサイトは引き続き 6.9 ブランチに留まり、セキュリティパッチは継続して提供される見込みです。データベースについては、WordPress.org の現行要件として MySQL 8.0+ または MariaDB 10.6+ が推奨として示されています(技術的なハード最低は MySQL 5.5.5 のまま)。WordPress 7.0 でデータベース要件が自動更新条件としてどう扱われるかは、リリース後の WordPress.org のアナウンスで再確認するのが安全です。

確認するのは2つです。

• PHP:WordPress.org が示す現行要件は 7.4 以上、推奨 8.3 以上(2026年5月時点)。これまでの最低要件だった PHP 7.2.24 と 7.3 のサポートは段階的に終了する予定です
• MySQL / MariaDB:WordPress.org の推奨として MySQL 8.0+ または MariaDB 10.6+ が示されています。推奨は MySQL 8.4 LTS、MariaDB 11.4 LTS

PHP のバージョンは、レンタルサーバーの管理画面(コントロールパネル)から切り替えられることが多いです。お使いのサーバーで PHP のバージョン切り替えができるか、できる場合はどのバージョンが選べるかを確認しておきましょう。

注意したいのは、MySQL のほうです。MySQL のバージョンはサーバー側で固定されていることが多く、利用者側では切り替えられないケースがあります。MySQL 5.7 は Oracle のサポートが 2023年10月に終了しており、推奨ラインの引き上げ自体は妥当な流れです。自分のサーバーが MySQL 8.0 以上に対応しているかを確認しておくのが安全です。

確認方法は次の項で詳しく書きます。

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

「すぐ更新ボタンを押して終わり」というアップデートではありません。これから挙げる7つの項目を順に確認しておくと、トラブル発生率は大きく下がります。リリースされた今が、ステージング環境での検証を本格的に始めるタイミングです。

1. 現在の WordPress と PHP・MySQL のバージョンを確認する

まずは現在のサイトの環境を把握しておきます。WordPress 管理画面の「ツール → サイトヘルス → 情報」から、WordPress バージョン、PHP バージョン、サーバー情報、データベースのバージョンなどが確認できます。

確認すべき項目は次の通りです。

• WordPress バージョン(6.9.x 以上が望ましい)
• PHP バージョン(WordPress.org 現行要件は 7.4 以上、できれば 8.3 以上)
• MySQL または MariaDB のバージョン(MySQL 8.0 以上、または MariaDB 10.6 以上)

PHP 7.3 以下の場合は、WordPress 7.0 に上げる前にサーバー側で PHP のバージョンアップが必要です。Make WordPress Core の案内によれば、PHP 7.2 や 7.3 のサイトには WordPress 7.0 への自動更新が提供されない予定です。MySQL 5.7 以下の場合は、WordPress.org の推奨(MySQL 8.0+ または MariaDB 10.6+)に合わせるためサーバー会社に相談するのが確実です。

多くのレンタルサーバーは管理画面から PHP バージョンを切り替えられるようになっています。MySQL のバージョンが古い場合は、レンタルサーバー会社のサポートに「MySQL 8.0 への移行は可能か」を直接聞いてみるのが確実です。私自身が使っている Xserver スタンダードプランは PHP 8.3.21 / MySQL 8.0系で稼働していたので、両方とも問題ありませんでした。

2. 必ずバックアップを取る

メジャーアップデートの前には、データベースとファイル一式のバックアップが必須です。バックアッププラグインを使う方法のほか、レンタルサーバー側のバックアップ機能を使う方法もあります。お使いの環境に合わせて選んでください。

ここでひとつ大事なのは、「バックアップから戻す手順」も一度確認しておくことです。バックアップは取ってあるのに戻し方を知らない、という状態は、いざというときに役に立ちません。テスト環境で一度復元の練習をしておくと安心です。

3. テーマとプラグインを最新版に更新する

WordPress 本体を上げる前に、まずテーマとプラグインを最新版に更新しておきます。WordPress 7.0 への対応版が、すでにテーマ側・プラグイン側でリリースされていることが多いからです。

特に、管理画面まわりをカスタマイズするプラグイン(投稿一覧をカスタマイズするものなど)は、DataViews との相性が問題になる可能性が高いので、必ず最新版にしておきましょう。

4. ステージング環境で先にアップデートする

本番サイトでいきなり更新ボタンを押すのは避け、ステージング環境(テスト環境)で先に WordPress 7.0 にしてから動作確認します。多くのレンタルサーバーには、ワンクリックでステージング環境を作る機能があります。エックスサーバーや ConoHa WING、ロリポップ!などにも備わっています。

ステージングでは、トップページ、投稿一覧、編集画面、お問い合わせフォームなど、よく使う画面を一通り確認してください。スマホでの表示も忘れずに合わせてチェックします。

5. 普段使っているプラグインの対応状況を見る

各プラグインの WordPress.org 公式ページで、「テスト済みバージョン」の項目を確認します。ここに WordPress 7.0 が表示されていれば、ひとまず安心材料の一つになります。

「テスト済みバージョン」が古いままのプラグインを使っている場合、開発者の対応がまだの可能性があります。重要なプラグインであれば、開発者の発信(公式ブログや GitHub の Issue など)を見て、対応予定があるかどうかを確認しておくと良いでしょう。リリース直後はプラグインの対応版が続々と出てくる時期なので、数日おきに更新を確認するのがおすすめです。

SEO プラグインやカスタムフィールド系プラグイン、独自の投稿設定を持つプラグインで クラシックメタボックスを使っているものは、7.1 で RTC が再実装された際に、共同編集を無効化する設計と当初アナウンスされていました。RTC が 7.1 へ延期されたため、対応の優先度は当初より下がっていますが、長期的な方向性として、クラシックメタボックスから新しい仕組みへ移行する流れは変わりません。共同編集機能を将来的に使いたい方は、利用中のプラグインがクラシックメタボックスをどう扱っているかにも目を向けておくとよさそうです。

6. テーマの対応状況を確認する

テーマも同様に、テスト済みバージョンを確認します。Cocoon や SWELL のような国内主要テーマは、リリース前後に更新情報を出すことが多いので、テーマ公式サイトを見ておきましょう。

独自テーマや、長期間更新されていないテーマを使っている場合は、ステージングでの確認をより念入りに行う必要があります。テーマの開発が止まっている場合、これを機に別のテーマへの移行を検討するのも一つの手です。

7. AI 機能を使う予定があるか考える

これは技術的というより、運用面の話です。AI 連携を、自分のサイトで使うつもりがあるかどうかを考えておきます。リアルタイム共同編集は 7.0 では搭載されない(7.1 へ延期された)ため、共同編集の準備は 7.1 のリリースが近づいてから検討すれば十分です。

「とりあえずアップデートはするが、新機能はまだ使わない」という選択肢ももちろんアリです。AI 連携も Connectors 画面で接続情報を設定しなければ動きません。すべての新機能を最初から使う必要はありません。

本番アップデートのタイミング

リリースされた直後にアップデートするか、少し様子を見るか。これは判断が分かれるところです。

すぐにアップデートするメリットは、新機能をすぐに使えること、セキュリティ面の改善を即座に取り込めることです。一方で、リリース直後は他の利用者からの不具合報告が出始めるタイミングでもあります。報告されている問題が、自分のサイトでも起きる可能性はあります。特に今回は DataViews が従来の一覧画面を置き換えたため、管理画面まわりのプラグインで互換性の修正が出やすい状況です。

多くのサイト運営者にとって現実的なのは、正式リリースから2〜4週間ほど待ってから本番更新する、という方針です。この期間に初期不具合の修正版(7.0.1、7.0.2 など)が出ることが多く、プラグインやテーマの対応状況も整ってきます。

ただし、ステージング環境での検証は早めに着手しておきましょう。本番更新の判断材料を、自分の環境で集めておくことが何より大事です。

自動更新の挙動:WordPress 7.0 は自動では入りません

もう一点、サイト運営者として知っておきたいのは、WordPress 7.0 のような大型のメジャーアップデートは、デフォルトでは自動更新の対象外として扱われるという点です。

WordPress 3.7 以降、マイナーリリース(6.9.1、6.9.2 など)とセキュリティリリースは自動更新の対象になっていますが、6.9 → 7.0 のようなメジャーアップデートは、管理画面から手動で更新ボタンを押すか、自動更新を明示的にオプトインする必要があります。

「ダッシュボード → 更新」画面で「このサイトは WordPress のメンテナンスとセキュリティリリースで自動的に最新の状態に保たれます」という表示が出ているなら、メジャーアップデートは自動では入りません。安心して、自分のタイミングで更新を進めることができます。

逆に、メジャーアップデートも自動で適用される設定にしている場合は、予期せず WordPress 7.0 が適用される可能性があります。本番サイトで予期しないタイミングの更新を避けたい場合は、wp-config.php で define( 'WP_AUTO_UPDATE_CORE', 'minor' ); を設定しておくと、マイナー更新のみが自動化され、メジャーアップデートは手動になります。

古い環境のサイトに対する WordPress 7.0 の自動更新の扱いは、PHP と MySQL で扱いが分かれます。Make WordPress Core の案内によれば、PHP 7.2 / 7.3 のサイトは WordPress 7.0 への自動更新が提供されない予定です。MySQL 5.7 以下については、WordPress.org の推奨として MySQL 8.0+ または MariaDB 10.6+ が示されていますが、WordPress 7.0 でデータベース要件が自動更新条件としてどう扱われるかは、リリース後の WordPress.org のアナウンスで確認するのが安全です。いずれにせよ、WordPress 7.0 を導入したい場合は、サーバー側のバージョンアップを先に行うのが現実的です。

本番サイトへのアップデート手順

ステージングでの検証が問題なく終わったら、本番サイトを更新します。次の手順を、できれば連休前ではなく、平日のサイト訪問が少ない時間帯に行うのが安心です。

1. メンテナンスモードに入る(任意)

サイト訪問者が多い場合は、アップデート中にエラー画面が出ないよう、メンテナンスモードのプラグインで一時的にメンテナンス表示を出す方法があります。短時間のアップデートであれば必須ではありませんが、安心感はあります。

2. 直前バックアップを取る

事前にバックアップを取っていても、アップデート直前に「念のためのバックアップ」をもう一度取ります。何か問題が起きた場合に、最新の状態に戻せるようにするためです。少し手間ですが、保険と思って実行してください。

3. プラグインとテーマを最新版に更新する

これも事前にやっているはずですが、本番アップデートの直前にもう一度確認します。新しいバージョンが出ていたら、先に更新しておきます。

4. WordPress 本体を更新する

「ダッシュボード → 更新」から WordPress 7.0 に更新します。途中で画面が遷移しますが、ブラウザのタブを閉じずに完了を待ちます。回線が遅い環境だと数分かかることもあるので、焦らず待ちましょう。

5. データベースの更新を求められたら実行する

メジャーアップデートでは、データベースのスキーマが更新されることがあります。管理画面に「データベースの更新が必要です」というメッセージが出たら、画面の指示に従って実行します。これを行うまで管理画面の他の操作はできない状態になります。

アップデート後の確認

アップデート完了後に、次の項目を一通り確認します。

• トップページの表示崩れがないか、JavaScript エラーがないか
• 投稿一覧・固定ページ一覧(DataViews の新しい一覧画面)で、フィルタや並び替えが動作するか
• メディア一覧でも、新しい DataViews UI が動作するか
• 編集画面(ブロックエディター)で、普段使っているブロックが問題なく挿入・編集できるか
• カスタムフィールド系プラグイン(ACF など)の入力欄が、編集画面で正しく動作するか
• お問い合わせフォームをテスト送信して、メールが届くか
• WooCommerce や会員系プラグインを使っている場合は、購入・ログインの動線を一通り確認
• 主要なページをスマホで開いて崩れがないか
• 「ツール → サイトヘルス」で重大な問題が出ていないか

これらすべてを完璧に確認するのは大変なので、優先度の高いページから順番に見ていけば十分です。「お問い合わせフォームが動かない」「カートが進まない」のような、ビジネスに直接影響する画面を最優先で確認してください。

よくあるトラブルと対処法

アップデート後によく起きるトラブルと、その対処法をいくつかまとめておきます。

「データベースの更新が必要です」と表示される

これはメジャーアップデートの正常な流れの一部です。表示された画面のボタンを押せば、データベースの構造が新しいバージョン用に更新されます。エラーではないので、安心してボタンを押してください。

管理画面の投稿一覧の見た目が変わってしまった

DataViews による刷新の影響です。最初は戸惑うかもしれませんが、新しい一覧画面のほうがフィルタや表示切替は柔軟です。リスト・グリッド・テーブルの3つのレイアウトが切り替えられるようになっています。慣れるまで時間がかかる場合は、表示密度(行間の広さ)の設定で調整してみてください。

特定のプラグインで表示崩れが起きている

管理画面まわりをカスタマイズしているプラグインで、DataViews との相性問題が起きている可能性があります。該当プラグインを一時的に停止して動作が回復するかを確認し、回復するならプラグインの最新版を待つか、開発者に問い合わせる流れになります。リリース直後はこの種の互換性報告が集中するので、数日待つと対応版が出てくることが多いです。

白い画面(致命的なエラー)が表示される

テーマかプラグインのどれかが、新しい WordPress と互換性がない可能性があります。FTP やサーバーのファイルマネージャから wp-content/plugins フォルダの名前を一時的に変えてプラグインを全停止状態にし、サイトが復旧するか確認します。

これでも復旧しない場合は、テーマを停止する処置(wp-content/themes 内の使用中テーマフォルダを名前変更)を行い、デフォルトテーマで動作確認します。原因が特定できたら、バックアップから復旧することも検討してください。

共同編集を 7.0 で使えるか確認したい

2026年5月8日の RC3 リリース時に、リアルタイム共同編集(RTC)は WordPress 7.0 から外され、7.1 リリースサイクルで再評価されることが正式に発表されました。リリース版でもこの方針は維持されています。WordPress 7.0 のリリース時点では、複数人による同時編集機能は使えません。共同編集を使いたい場合は、7.1 の正式リリース(WordCamp US に合わせた2026年8月19日が目標)を待つことになります。なお、Notes 機能(投稿への直接コメント)は 7.0 でも引き続き使えるので、複数人レビューには Notes を活用するのが現実的な選択肢です。

「自動更新が WordPress 7.0 を提示しない」

サイトの環境が WordPress.org が現行要件として示している PHP 7.4 以上 / MySQL 8.0+ または MariaDB 10.6+ を満たしていない可能性があります。「ツール → サイトヘルス → 情報」で PHP バージョンとデータベースバージョンを確認してください。PHP 7.2 / 7.3 のサイトは Make WordPress Core の案内によれば WordPress 7.0 への自動更新が提供されない予定です。データベース要件と自動更新条件の関係はリリース後の WordPress.org のアナウンスで再確認するのが安全です。PHP のバージョンが古い場合は、まずレンタルサーバー側でアップデートを行い、MySQL のバージョンが古い場合はサーバー会社に相談する流れになります。

AI 連携を使うときの注意点

WordPress 7.0 で「設定 → Connectors」画面を見ると、AI プロバイダーを追加できる UI があります。ここから AI 連携を始める前に、最低限おさえておきたいことを整理しておきます。

まず、外部 AI サービスを使うには、各サービス(OpenAI、Anthropic、Google)でアカウントを作成し、API キーを取得する必要があります。それぞれのサービスは、利用量に応じた料金がかかります。無料枠があるサービスもありますが、本格的に使うなら有料利用が前提です。3つの公式プロバイダープラグインは Core には同梱されていないので、必要なものを wordpress.org から別途インストールします。

次に、AI に投稿内容や個人情報を送る可能性があるため、プライバシーポリシーと利用規約の見直しが必要です。たとえば、訪問者からの問い合わせ内容を AI で要約する機能を入れた場合、訪問者の個人情報が外部サービスに送られる可能性があります。これを利用規約に書かないままサービスを開始すると、後でトラブルになりかねません。

API キーは、Connectors 画面で一元管理する形になります。キーが漏れると不正利用される恐れがあるので、管理者権限を持つユーザーを最小限に絞ること、定期的にキーをローテーションすることなどを意識しておきましょう。AI プロバイダープラグインは外部 API への通信を行うため、PHP からの外向き HTTPS 通信(ポート 443)が許可されている環境が必要です。一部の格安共有サーバーでは外部通信が制限されていて、タイムアウトのようなエラーになることがあります。

AI 連携は強力ですが、急いで導入する必要はありません。まずは Connectors 画面の存在を把握しておく、くらいでも十分です。

アップデートチェックリスト

まとめ:急がず、テストしてから更新する

WordPress 7.0「Armstrong」は、Notes 機能の強化、ビジュアルリビジョン、DataViews による管理画面の刷新、Connectors 画面による AI 連携基盤、新しいブロック群、Font Library のクラシックテーマ対応、PHP・MySQL の動作環境要件の確認など、影響範囲の大きいアップデートです。当初目玉とされていたリアルタイム共同編集と Notes のリアルタイム同期は、5月8日の RC3 リリース時に 7.1 へ延期されることが発表されました。RC3・RC4・RC5 を経て、2026年5月20日 17:00 UTC(日本時間5月21日未明)に正式リリースされています。だからこそ、本番サイトでいきなり更新ボタンを押すのではなく、ステージング環境で先に試し、プラグインの対応状況を見て、必要なら 7.0.1 などの修正版を待つ、というやり方が現実的でしょう。

サイト運営者として押さえておきたいのは、3つに絞れます。

• WordPress 7.0 は2026年5月20日にリリースされました。本番サイトには急いで入れる必要はなく、1〜2 週間ほど様子を見るのが安全です
• PHP 7.4 未満は、WordPress 7.0 で自動更新対象外になる予定と公式にアナウンスされています。MySQL 8.0 以上または MariaDB 10.6 以上は WordPress.org の推奨として示されています(2026年5月時点)。データベース要件と自動更新条件の関係はリリース後に再確認するのが安全です。
• リアルタイム共同編集は 7.0 では搭載されません(7.1 で再評価)。AI 連携などの新機能も、初期状態ではオフ。設定しなければ今までどおりに動く

「最新版にしたほうが良い」というのは正論ですが、サイトを止めずに運用していくには、慎重さも同じくらい大切です。事前準備をしっかりやれば、メジャーアップデートも怖いものではありません。まずは「自分のサイトの PHP バージョンと MySQL バージョンは何だろう」というところから確認を始めてみてください。リリースされた今が、ステージング環境での検証を始めるのにちょうどよいタイミングです。

本記事の情報は 2026年5月20日時点(WordPress 7.0「Armstrong」リリース当日)のものです。WordPress 7.0 のリリーススケジュールや機能の詳細は、Make WordPress Core および WordPress.org 日本語版 の最新情報を合わせてご確認ください。プラグイン開発者・テーマ開発者の方向けの詳しい情報は、別記事「WordPress 7.0 で開発者が確認しておきたいこと – apiVersion 3、PHP 7.4、DataViews(2026年5月20日リリース)」にまとめています。

WordPress 7.0 関連記事

• WordPress 7.0「Armstrong」がリリースされました – 2026年5月20日公開、主要変更点まとめ ── 一般ユーザー向け、新機能の概要をやさしく解説。
• WordPress 7.0 で開発者が確認しておきたいこと – apiVersion 3、PHP 7.4、DataViews(2026年5月20日リリース) ── 開発者向け、技術的な変更点を詳しく解説。