WordPress 7.0 アップデート手順と注意点まとめ

WordPress 7.0 とは？主な新機能・変更点まとめ
アップデート前に必ず確認する7つのポイント
アップデートのタイミング：リリース直後に急ぐ必要はない
本番サイトへのアップデート手順
1. ダッシュボードからアップデートする手順
2. WP-CLI でアップデートする手順
アップデート後の動作確認チェックリスト
よくあるトラブルと対処法
完全チェックリスト：アップデート前後の全確認項目

この記事の結論：WordPress 7.0へのアップデートは「PHP 8.3以上への更新」「フルバックアップ」「ステージング環境での事前検証」「プラグイン互換性の確認」の4つを事前に済ませてから行ってください。リリース直後に急ぐ必要はなく、2〜4週間待って主要プラグインの対応状況を確認してからステージングで検証→本番適用の順番が鉄則です。

検証環境：WordPress 6.9.4 / PHP 8.3.21 / Xserver スタンダードプラン（2026年4月時点）

WordPress 7.0 は当初 2026年4月9日に正式リリースが予定されていましたが、リアルタイムコラボレーション機能のデータベース設計見直しのため延期されました。新しいリリーススケジュールは2026年4月22日までに発表予定です。リアルタイムでの共同編集、DataViews と呼ばれる新しい管理画面、AI 連携機能など、盛りだくさんの内容です。バージョンが 6 から 7 に上がるだけあって、今回は久々の大型アップデートになりそうです。

ただ、正直なところ「アップデートの通知が来たからポチッと更新した」だけでは危ないのがメジャーバージョンアップです。PHP のバージョン・プラグインの互換性・バックアップ・テスト環境での確認——この4つを事前に済ませておかないと、いざ更新したときにサイトが真っ白になる、管理画面が開かないといったトラブルが起きることがあります。

この記事では、WordPress 7.0 の新機能を紹介しながら、安全にアップデートするための確認手順と、本番に適用する前にテスト環境で検証する方法をまとめています。個人ブログを運営している方から、お仕事でサイト管理をしている方まで参考にしていただける内容です。

【追記・2026年4月10日】リリース延期のお知らせ

2026年3月31日、リリースリード Matias Ventura が WordPress 7.0 の延期を正式発表しました。原因はリアルタイムコラボレーションのデータベース設計問題（アクティブな編集セッション中に永続キャッシュが無効化される問題）で、専用の新しいテーブルを設計し直す必要があります。追加プレリリースは4月17日まで一時停止、新スケジュールは4月22日までに発表予定です。現在の安定版は WordPress 6.9.4 です。

この記事でわかること

WordPress 7.0 の主な新機能・変更点
PHP・プラグイン・テーマの互換性チェック方法
ステージング（テスト）環境の作り方と活用法
バックアップの正しい取り方
ダッシュボード・WP-CLI それぞれのアップデート手順
アップデート後の動作確認チェックリスト

WordPress 7.0 とは？主な新機能・変更点まとめ

WordPress 7.0の目玉はリアルタイム共同編集・DataViews（管理画面刷新）・AI連携の3点です。便利になる反面、既存プラグインやテーマへの影響が大きいため、アップデート前の互換性チェックとステージング環境での事前検証は必須です。

WordPress 5.0 でブロックエディターが導入されたとき、「使い方が変わりすぎる」と戸惑った方も多かったと思います。あのとき以来の大きな変化が、今回の 7.0 です。コラボレーション・AI 連携・管理画面の刷新という3本柱で、WordPress がチーム向けの CMS として本格的に動き出す感じです。

Gutenberg プロジェクトの「Phase 3」と呼ばれるフェーズに入り、複数人で同時に編集できる機能がいよいよ実装されます。「うちは一人運営だから関係ない」と思うかもしれませんが、DataViews の管理画面刷新や PHP 要件の変更はすべてのサイトに影響します。まず何が変わるのかをざっくり把握しておきましょう。

① リアルタイム共同編集（Phase 3 Gutenberg）

ひとことで言うと「WordPress 版 Google ドキュメント」です。複数のユーザーが同じ投稿・固定ページを同時に編集でき、他の編集者のカーソルや変更がリアルタイムで見えます。チームでブログを運営している方には便利な機能ですね。

技術的なポイント

WordPress コアはデフォルトで HTTP ポーリングという方式で同期します。WebSocket サーバーを別途用意しなくても共有ホスティングで動くのはありがたいところです。同期の頻度は一人で編集中は4秒ごと、複数人が同時編集中は1秒ごとです。WebSocket が使えない共有ホスティングでリアルタイム通信を実装した話は、XserverでWebSocketもSSEも動かない｜共用レンタルでチャットを実現したLong Polling実装で詳しく書いています。

⚠️ ひとつ注意点として、Classic ブロック（core/freeform）はリアルタイムコラボレーションに今のところ対応していません。Classic ブロックを多用しているサイトは切り替えを検討する必要があります。

【追記】リアルタイム共同編集の重要な制限事項

① デフォルト「オフ」（オプトイン方式）：RC1の時点で初期状態が「オフ」に変更されました。使うには管理画面の「設定 → 投稿」から手動で有効にする必要があります。同時編集できるのはデフォルトで最大2名までです。

② メタボックスがある投稿では自動的に無効化：Yoast SEO・Rank Math などの SEO プラグインや、ACF などのカスタムフィールドプラグインが使う「メタボックス」（投稿画面下部の追加設定エリア）が存在する投稿では、リアルタイムコラボレーションが自動的に無効になります。日本語サイトの多くでこれらのプラグインが使われているため、共同編集できる投稿が想定より少なくなるケースがあります。

③ 共有サーバーでの負荷：2名が1つの投稿を共同編集するだけで1分間に約480回の HTTP リクエストが発生します。格安共有サーバーでは負荷が高い時間帯に遅延が起きることがあります。

② DataViews（管理画面の刷新）

投稿・固定ページ・メディアの一覧画面が DataViews によって全面的に作り直されます。インラインフィルタリング・グリッドとテーブルのレイアウト切替・密度コントロールなど、従来の一覧表示とはかなり見た目が変わります。

⚠️ DataViews との競合で問題が出やすいプラグイン

旧来の WP List Table という仕組みに依存しているプラグインは、DataViews 導入後に表示崩れや機能喪失が起こる可能性があります。カスタム管理列を追加するプラグイン・一括操作を拡張するプラグイン・管理画面のテーマ系プラグインは特に要注意です。

③ WP AI クライアント・Abilities API

WordPress コアに WP AI クライアントと Abilities API が入ります。OpenAI・Gemini・Claude などの AI と WordPress をつなぐ標準的な仕組みが整備されるイメージです。AI 機能そのものはプラグインで実装する形ですが、MCP アダプターを経由して AI アシスタントから WordPress を操作する道が開けます。

④ レスポンシブ編集モード

デスクトップ・タブレット・モバイルごとにブロックの表示・非表示をエディター内で直接設定できます。今まで CSS や別プラグインで対応していた方には地味にうれしい機能です。

⑤ フォントライブラリ（クラシックテーマ対応）

クラシックテーマを使っているサイトでも「外観 → フォント」からカスタムフォントを管理できるようになります。TTF・OTF・WOFF・WOFF2 に対応しており、フォント管理プラグインが不要になるケースも出てきそうです。

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

画像などのメディアをブラウザ側で処理してからアップロードする機能が予定されていましたが、RC1 の段階で品質問題が発覚し WordPress 7.0 のリリース対象から除外されました。

【追記】クライアントサイドメディア処理は 7.0 から除外されました

「画像アップロードをブラウザ側で処理することでアップロードが速くなる」と紹介していましたが、RC1のリリース準備中に以下の問題が判明し 7.0 リリース対象から外れました。

処理速度：M4 Pro MacBook Proという高性能な環境でも JPEG の処理に約19秒、AVIF では29〜55秒かかることが判明。他のツールが3秒未満で完了しているのと比べて著しく遅く、実用水準に達していないと判断
ブラウザ対応：現時点で Chromium ベース（Chrome・Edge）のみ対応。Safari・Firefox では動作しない
パッケージサイズ：使用する WASM ライブラリが約13MB あり、パッケージサイズが大幅増加する一因に

将来のバージョンでの実装が期待されます。

機能・項目	WordPress 6.x	WordPress 7.0
編集体験	基本的なブロックエディター	リアルタイム複数ユーザー編集
コンテンツ管理 UI	従来型リストビュー	DataViews（アプリ型インターフェース）
レスポンシブ編集	手動 CSS か別プラグイン	エディター内でデバイス別に表示切替
AI 連携	プラグインごとに個別実装	WP AI クライアント・Abilities API で共通化
メディア処理	サーバーサイド処理	サーバーサイド処理（変更なし） ※クライアントサイド処理は品質問題のため7.0除外→将来版で実装予定
PHP 最低要件	7.2 以上	7.4 以上（推奨：8.3 / 8.5）

まとめ

共同編集・DataViews・AI 連携の3点が今回の目玉です。便利になる反面、既存のプラグインやテーマへの影響も大きいので、アップデート前の互換性チェックとテスト環境での確認は必須です。

アップデート前に必ず確認する7つのポイント

アップデートで起きるトラブルの大半は事前確認の不足が原因です。PHPバージョン確認→フルバックアップ→ステージング検証→プラグイン互換性確認→テーマ確認→サーバー環境確認→放置WordPressの削除の7ステップを順番に実施してください。

アップデートで起きるトラブルのほとんどは、事前確認を怠ったことが原因です。「PHP のバージョンが古かった」「プラグインが対応していなかった」——よくある話ですが、ステージング環境で一度試しておけば本番でのトラブルはかなり防げます。7つのポイントを順番に見ていきます。

Step 1：PHP バージョンの確認（最重要）

STEP 1

確認場所：WordPress 管理画面 → ツール → サイトヘルス → 「情報」タブ → サーバー

最初に確認するのは PHP のバージョンです。WordPress 7.0 では PHP 7.2 と 7.3 のサポートが終了し、最低でも PHP 7.4 が必要になります。サーバーが古い PHP のままだとそもそもアップデートできないので、ここは最優先で確認してください。

PHP バージョン	WordPress 7.0 での扱い	セキュリティサポート
PHP 7.2・7.3	❌ サポート終了（更新不可）	✗ 終了済み
PHP 7.4	⚠️ 最低要件（推奨しない）	✗ 2022年11月28日終了
PHP 8.0・8.1	△ 動作はするが推奨ではない	△ 8.1 のみサポート中
PHP 8.2・8.3	✅ 推奨（安定・高速）	✅ サポート中
PHP 8.5	🚀 ベータサポート提供開始	✅ 最新版

「最低要件の PHP 7.4 なら大丈夫」ではありません

PHP 7.4 はすでに2022年11月28日にセキュリティサポートが終了しています。WordPress 7.0 が動くかどうかとセキュリティが保たれているかは別の話。現時点でまだ 7.4 のまま運用しているサイトは、攻撃対象になりやすい状態が続いています。

このタイミングで PHP 8.3 以上に上げておくのをおすすめします。新しい DataViews 管理画面の速度を最大化したいなら PHP 8.5 が最適です。

PHP バージョンの変更はホスティングの管理パネルから操作できるケースがほとんどです。エックスサーバー・さくらインターネット・ConoHa WING はどれも管理画面から切り替えられます。ただし、PHP バージョンを変えるときも必ずステージングで先に動作確認をしてください。PHP 8 系に上げたらプラグインが動かなくなった、というトラブルは珍しくないので。

データベースのバージョンも確認しておこう

WordPress 7.0 では MySQL 8.0 以上、または MariaDB 10.5 以上が推奨されます。DataViews やコラボレーション機能を快適に使うために必要です。ホスティングの管理画面から現在のバージョンを確認しておきましょう。

まとめ

PHP 7.4 以下は要アップグレード。推奨は PHP 8.3 以上です。「サイトヘルス → 情報 → サーバー」でまず確認しましょう。

Step 2：バックアップの取得

STEP 2

対象：データベース＋ wp-content ディレクトリ＋ wp-config.php / .htaccess

当たり前のことではありますが、アップデートの前には必ずフルバックアップを取ってください。これが後で「やっておいてよかった」と思う場面が実際にあります。

バックアップに含めるべきものはこの4つです。

データベース（投稿・設定・ユーザー情報が入っている）
wp-content ディレクトリ（テーマ・プラグイン・アップロードしたファイル）
wp-config.php（DB 接続情報・認証キーが書かれている）
.htaccess（パーマリンク設定など）

⚠️ 「ファイルがあるから大丈夫」は過信です

バックアップが存在していても、復元できなければ意味がありません。一度でいいので、ステージング環境でバックアップから実際に復元してみることをすすめます。「いざというとき動かなかった」では困りますよね。

もうひとつ、ホスティング上だけにバックアップを置くのも危険です。サーバーごとトラブルになったらバックアップも消えます。Google Drive や Dropbox などオフサイトにも必ず置いておきましょう。

バックアッププラグインは何でも構いませんが、代表的なものを挙げておきます。

UpdraftPlus（無料・Google Drive / Dropbox / S3 に直接保存できる）
BackWPup（無料・スケジュール自動バックアップが得意）
All-in-One WP Migration（移行・バックアップ兼用で使いやすい）

まとめ

DB ＋ファイル両方のバックアップをオフサイト含め保存。アップデート直前にも再取得しましょう。

Step 3：ステージング（テスト）環境での事前検証【最も重要な工程】

STEP 3

原則：本番サイトへのアップデートは、ステージングで検証完了後に行う

正直、これが一番大事です。本番サイトで直接 WordPress 7.0 にアップデートするのはやめてください。「うちはシンプルなブログだから平気だろう」と思っていても、ステージングで一度試してから本番に適用するのが安全です。

プラグインが多い・カスタムテーマを使っている・WooCommerce でお店を運営しているといった環境では、ステージング検証はほぼ必須と思ってください。

ステージング環境ってなに？

ステージング環境とは、本番サイトのコピーを別の場所に作った「お試し用サイト」のことです。ここで先にアップデートを適用して動作を確認すれば、本番サイトを壊すリスクなく互換性の問題を洗い出せます。

ステージング環境の作り方

作り方はいくつかあります。使っているホスティングによって選択肢が変わります。

ホスティングのワンクリックステージング機能（Kinsta・SiteGround・ConoHa WING など多くのマネージドホストが対応）
WP Staging プラグイン（無料・同じサーバー内にクローンを作れる）
InstaWP（クラウド上にさっとテスト環境を立ち上げられる）
Local by Flywheel / Laragon（手元の PC でローカル環境を作る）
WordPress Playground（ブラウザ上で動作確認するだけなら手軽）

ステージングで WP_DEBUG を有効にしておく

ステージング環境の wp-config.php に以下を追加しておくと、PHP のエラーや非推奨の警告を裏でログに記録してくれます。

// ステージング環境のwp-config.phpに追加
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

// ステージング環境のwp-config.phpに追加

define( 'WP_DEBUG', true );

define( 'WP_DEBUG_LOG', true );

define( 'WP_DEBUG_DISPLAY', false );

エラーは画面に出ず、wp-content/debug.log というファイルに蓄積されます。アップデート後にこのファイルを確認すると、互換性の問題を早い段階で気づくことができます。

ステージングで確認しておきたいこと

✅ WordPress 7.0 へのアップデートが正常に完了するか
✅ 管理画面の各メニュー・投稿一覧・メディア一覧が正常に表示されるか
✅ フロントエンドの表示が崩れていないか
✅ お問い合わせフォームが正常に送信できるか
✅ WooCommerce（使用している場合）が正常に動作するか
✅ debug.log にエラーや非推奨警告が出ていないか
✅ サイトヘルスに新しい警告が増えていないか

WP-CLI でステージングに WordPress 7.0 をインストールする方法

WP-CLI が使える環境なら、コマンド一本でベータ・RC 版をインストールしてテストできます。WP-CLI の基本的な使い方は【第1章】WP-CLI完全入門：WordPressを”コマンド”で管理する基礎に書いていますので参考にしてください。

# WordPress ナイトリービルドをインストール（テスト環境のみ）
# ※リリース延期中はナイトリービルドでテスト継続が可能
wp core update --version=nightly
# または現在の最新安定版（6.9.4）
wp core update

# WordPress ナイトリービルドをインストール（テスト環境のみ）

# ※リリース延期中はナイトリービルドでテスト継続が可能

wp core update --version=nightly

# または現在の最新安定版（6.9.4）

wp core update

まとめ

「本番で試してみよう」は厳禁。ステージングで先に 7.0 を適用してプラグイン・テーマ・フォームなど主要機能を一通り確認してから、本番に適用しましょう。

Step 4：プラグインの互換性確認

STEP 4

確認場所：各プラグインの WordPress.org プラグインページ「Tested up to」欄

アップデート準備の中で一番手間がかかるのがプラグインの確認です。セキュリティ企業 Patchstack の調査によると、WordPress の脆弱性の 96% はプラグインが原因とされています。更新が止まった古いプラグインは、機能しなくなるだけでなくセキュリティ上の穴にもなります。

特に注意が必要なプラグインカテゴリ

カテゴリ	リスクレベル	理由
管理画面カスタム系（カラム追加・管理 UI 変更）	🔴 高	DataViews との DOM 競合
Classic ブロック依存のプラグイン	🔴 高	共同編集機能に非対応
カスタムブロック提供プラグイン【追記】	🔴 高	React 18→19へのアップグレードによる互換性問題の可能性
ページビルダー（Elementor・Divi・Bricks 等）	🟠 中〜高	管理フック競合の可能性
コラボレーション・コメント系プラグイン	🟠 中	7.0 のコア機能と重複・競合しやすい
カスタム投稿タイプ・フィルター系	🟠 中	DataViews 対応アップデートが必要な場合あり
SEO・フォーム・バックアップ系	🟡 低〜中	主要ベンダーは通常 1 週間以内に対応

【追記】7.0 で特に影響が大きい2つの変更点

① React 18 → 19 へのアップグレード：WordPress 7.0 はエディターの JavaScript フレームワークを React 19 に更新します。古い React API に依存したカスタムブロックプラグインで予期しない動作が起きる可能性があります。カスタムブロック系・ページビルダー系プラグインは必ずステージングで動作確認してください。

② メタボックス使用プラグインと共同編集の非互換：Yoast SEO・Rank Math などの SEO プラグインや ACF などが使うメタボックスが存在する投稿では、リアルタイムコラボレーションが自動的に無効化されます。共同編集機能の導入を検討している場合は、使用中のプラグインがモダンな API に移行済みかどうかを確認しましょう。

「Tested up to 7.0」の確認方法

WordPress.org のプラグインページ右カラムに「Tested up to」という項目があります。ここが 7.0 になっていれば、そのプラグインは 7.0 での動作確認済みです。リリース後 1〜2 週間ほど待つと、主要プラグインの多くがこの表示を更新してきます。

互換性チェックの手順

ステージング環境で全プラグインを最新版に更新する
WordPress を 7.0 にアップデートする
普段使っている管理画面の全メニューを確認する
投稿作成・メディアアップロード・フォーム送信・WooCommerce 注文処理など主要な操作をテストする
カスタムブロック系プラグインの動作を確認する（React 19 への影響）
ツール → サイトヘルスで新しい警告が出ていないか確認する
wp-content/debug.log にエラーや非推奨警告が出ていないか確認する

共同編集系プラグインは一度無効化してテストを

WordPress 7.0 からコラボレーション・インラインコメント・変更の提案といった機能がコアに入ります。これらを担っていたプラグインをそのまま残しておくと、コア機能と重複して競合する可能性があります。ステージングで一時的に無効化して確認しましょう。

まとめ

管理画面カスタム系・Classic ブロック依存系・カスタムブロック系（React 19 影響）は特に重点確認。ステージングで全プラグインを 7.0 環境でテストして、問題があれば更新対応を待つか代替プラグインを検討しましょう。

Step 5：テーマの確認

STEP 5

確認方法：ステージングで 7.0 適用後、フロントエンドとエディターの動作を確認

テーマはプラグインほど大きな影響を受けないことが多いですが、フォントライブラリとレスポンシブ編集モードについては確認が必要です。

クラシックテーマ：外観 → フォントで新しいフォントライブラリが正しく動作するか確認。既存のフォント系プラグインやカスタム CSS と競合しないかをチェック。
ブロックテーマ：レスポンシブ編集モードで各デバイスのブレークポイントが想定通りに動くか確認。テーマのカスタムブレークポイントと WordPress 標準の設定がずれていないかを見ておく。
クラシックテーマ全般の注意点：共同編集・DataViews などのフル機能はブロックテーマ専用です。クラシックテーマを使い続ける場合は、その点を頭に入れておきましょう。

まとめ

テーマはステージングでフロントエンドの表示崩れがないかを確認。長期的にはブロックテーマへの移行も視野に入れておくと、7.x 系での新機能についていきやすくなります。

Step 6：ホスティング・サーバー環境の確認

STEP 6

確認項目：PHP バージョン・SSL・WAF 設定・WebSocket サポート

リアルタイム共同編集の快適さはホスティング環境に左右されます。また HTTPS（SSL）が設定されていないと、コラボレーション機能や一部の AI API がそもそも動きません。

SSL 証明書の確認：サイトが https:// で動作しているか確認。Let’s Encrypt の有効期限も忘れずに。
WebSocket サポート：チームで共同編集をしっかり使いたい場合は、ホストが WebSocket をサポートしているか問い合わせてみましょう。共有ホスティングは HTTP ポーリングへのフォールバックで動きますが、速度面で差が出ます。
WAF（Web Application Firewall）の設定確認：エックスサーバーなどの WAF が WordPress 7.0 の新しいリクエストを誤検知してブロックすることがあります。WAF で投稿できないトラブルの話はXserverのWAF誤検知で501エラー！原因と完全対策ガイドにまとめているので、アップデート後に管理画面の動作がおかしいと感じたら参考にしてみてください。
一人でサイトを運営している場合：共同編集はそもそも使わないので、WebSocket の設定は気にしなくて大丈夫です。

まとめ

HTTPS（SSL）の設定は必須確認。共同編集をフル活用したい場合は WebSocket サポートの有無もホストに確認しておきましょう。

Step 7：サーバー内に残った旧 WordPress の確認

STEP 7

確認方法：ホスティングのファイルマネージャーや FTP でサーバー内のディレクトリを確認

メインのサイトをきちんと最新状態にしていても、同じサーバー内に「昔テスト用に入れたまま放置している WordPress」があると、そこが攻撃の足がかりになります。これを機に一度サーバーの中を見直してみてください。

不要な WordPress が見つかった場合は迷わず削除。まだ使う予定があるなら、今すぐアップデートしてください。

まとめ

サーバー内の使っていない WordPress は即削除。放置した古い環境が侵入口になるリスクをなくしましょう。

アップデートのタイミング：リリース直後に急ぐ必要はない

リリースから2〜4週間の観察期間を置き、使っているプラグインの「Tested up to 7.0」更新を確認してからステージングで検証→本番適用の順番が鉄則です。シンプルなブログなら1〜2週間、WooCommerce等の業務サイトなら最低1ヶ月待ちましょう。

【追記・2026年4月10日】リリース延期中です

当初の4月9日リリースは延期されました。新スケジュールは2026年4月22日までに発表予定です。この期間をステージングでのテストやプラグイン互換性確認に充てることができます。リリース日が確定してからアップデートの準備を最終化することをおすすめします。

WordPress 7.0 がリリースされても、その日のうちに本番サイトへ適用する必要はまったくありません。リリースから 2〜4 週間ほど様子を見てから動くのが現実的です。

なぜかというと「タイムラグ問題」があるからです。メジャーリリース直後は各プラグイン・テーマのベンダーが対応版を出すまでに時間差が生じます。その間は、ステージングでの確認がうまくいっていても本番でトラブルが起きることがあります。

「Tested up to 7.0」更新のタイムライン目安

リリース直後〜1週間：Yoast SEO・WooCommerce・Gravity Forms・WPML など主要どころが対応版をリリース
リリース後 2〜4 週間：中小規模のプラグインも順次対応版が出てくる
1ヶ月以上経っても更新なし：開発停止の可能性が高い。代替を検討する時期

自分のサイトはどのパターン？

✅ シンプルなブログ・プラグインが少ない：リリース後 1〜2 週間でステージング検証してから適用
⚠️ プラグインが多い・カスタムテーマを使っている：リリース後 2〜4 週間待った上でステージング検証
🔴 WooCommerce・決済・予約系が絡む業務サイト：最低 1ヶ月様子を見て、主要プラグインの対応を確認してから適用

まとめ

「出たら即更新」は避けましょう。2〜4 週間の観察期間を置き、使っているプラグインの「Tested up to 7.0」更新を確認してからステージングで検証、本番適用の順番が鉄則です。

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

本番適用は「直前バックアップ再取得→メンテナンスモード→プラグイン全更新→テーマ更新→本体更新→動作確認→メンテナンス解除」の順番で、慌てず一手ずつ進めてください。ダッシュボードからのGUI操作とWP-CLIのコマンド操作の両方を紹介します。

ステージングでの確認が終わったら、いよいよ本番サイトに適用します。焦らず順番通りにやるのがポイントです。

ダッシュボードからアップデートする手順

直前バックアップを再取得する
ステージングでの確認が終わった後、本番適用の直前にもう一度フルバックアップを取ります。
（推奨）メンテナンスモードを有効にする
アップデート中に訪問者がエラー画面を見ないよう、メンテナンスモードプラグイン（例：WP Maintenance Mode）を使って一時的にサイトを非表示にします。
プラグインをすべて最新版に更新する
管理画面 → プラグイン → 利用可能なアップデートをすべて適用します。
テーマを最新版に更新する
管理画面 → 外観 → テーマ → アップデートを適用します。
WordPress 本体をアップデートする
管理画面 → ダッシュボード → 更新 → 「今すぐ更新」をクリック。
動作確認をする
次のセクションのチェックリストを参考に確認します。
メンテナンスモードを解除する
確認が終わったらメンテナンスモードを外します。

WP-CLI でアップデートする手順

コマンドラインが使える環境なら、WP-CLI でまとめて更新できます。WP-CLI の導入・基本コマンドは【第1章】WP-CLI完全入門：WordPressを”コマンド”で管理する基礎にまとめているので、慣れていない方はそちらも参考にしてみてください。

# 1. 現在の状態を確認
wp core version
wp plugin list --update=available
wp theme list --update=available

# 2. 直前バックアップ（WP-CLI + mysqldump）
wp db export backup-$(date +%Y%m%d).sql
# wp-contentのバックアップは別途サーバー側で取得

# 3. プラグイン・テーマをすべて更新
wp plugin update --all
wp theme update --all

# 4. WordPress 本体を更新
wp core update

# 5. データベースを更新（コアアップデート後に実行）
wp core update-db

# 6. キャッシュをフラッシュ
wp cache flush

# 1. 現在の状態を確認

wp core version

wp plugin list --update=available

wp theme list --update=available

# 2. 直前バックアップ（WP-CLI + mysqldump）

wp db export backup-$(date +%Y%m%d).sql

# wp-contentのバックアップは別途サーバー側で取得

# 3. プラグイン・テーマをすべて更新

wp plugin update --all

wp theme update --all

# 4. WordPress 本体を更新

wp core update

# 5. データベースを更新（コアアップデート後に実行）

wp core update-db

# 6. キャッシュをフラッシュ

wp cache flush

FTP で手動アップデートする場合

WordPress.org から最新版をダウンロードして、FTP やファイルマネージャーで展開する方法もあります。その場合は wp-content フォルダを上書きしないよう注意してください。展開後に管理画面を開くとデータベース更新のプロンプトが出るので、指示に従って更新します。

まとめ

本番適用は「再バックアップ → メンテナンスモード → プラグイン更新 → テーマ更新 → 本体更新 → 動作確認 → メンテナンス解除」の順番で。慌てず一手ずつ進めましょう。

アップデート後の動作確認チェックリスト

アップデート後は管理画面・フロントエンド・フォーム送信・スマホ表示・サイトヘルスの5点を最低限確認してください。何かおかしいと感じたら、まずプラグインをすべて無効化して原因を絞り込みます。

アップデートが終わったら、管理画面とフロントエンドの両方で動作を確認します。問題は早めに気づくほど対処しやすいので、面倒でも一通りやっておくことをおすすめします。

✅ 管理画面（ダッシュボード）が正常に表示される
✅ 投稿一覧・固定ページ一覧が DataViews で正常に表示される
✅ 新規投稿を作成してブロックエディターが正常に動作する
✅ フロントエンドでサイトのデザインが崩れていない
✅ スマートフォンでの表示が正常か
✅ お問い合わせフォームが正常に送受信できる
✅ WooCommerce（使用時）で商品一覧・カート・決済が動作する
✅ ツール → サイトヘルスで「重要な問題」が増えていない
✅ Google Search Console でクロールエラーが増えていない（数日後確認）
✅ ページ表示速度が極端に落ちていない

アップデート後に何かおかしいと感じたら

まず試してほしいのが、プラグインをいったんすべて無効化することです。それでサイトが正常に見えるなら、特定のプラグインが原因です。一つずつ有効化して原因を絞り込んでいきます。

それでも解決しない場合は、バックアップから復元してください。事前にきちんとバックアップを取っておいた意味がここで出てきます。

「見た目が崩れた」と思ったらキャッシュを疑う

アップデート後に CSS やレイアウトがおかしく見える場合、実はキャッシュが原因なことがよくあります。WP-CLI なら wp cache flush、キャッシュプラグインを使っているならパージ機能で解決することが多いです。キャッシュの切り分け方についてはWordPressでCSS更新が反映されない｜キャッシュ5層の切り分けとfilemtimeで二度と揉めない運用をどうぞ。

まとめ

アップデート後は管理画面・フロントエンド・フォーム動作・Search Console の4点を確認。問題が出たらプラグインの無効化で原因を絞り込みましょう。

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

メジャーアップデート後に起きがちなトラブルは「サイト真っ白」「管理画面に入れない」「投稿一覧の表示崩れ」「パーマリンク404」「PHPバージョンエラー」「メール送信不可」の6パターンで、対処法はほぼ決まっています。

メジャーアップデート後に起きがちなトラブルはある程度パターンが決まっています。あらかじめ対処法を知っておくだけで、いざというときに焦らずに動けます。

トラブル	主な原因	対処法
サイトが真っ白になる（WSoD）	プラグイン・テーマの PHP エラー	FTP で wp-content/plugins フォルダを一時リネームして全プラグイン無効化。debug.log でエラー確認
管理画面に入れない	プラグイン競合・PHP メモリ不足	FTP で問題プラグインのフォルダを削除/リネーム。wp-config.php に `define('WP_MEMORY_LIMIT', '256M');` を追記
投稿一覧の表示が崩れる	DataViews と旧プラグインの競合	管理画面カスタム系プラグインを無効化してテスト。該当プラグインの更新版を待つ
パーマリンクが 404 になる	.htaccess の書き込みエラー	設定 → パーマリンク設定を開いて何も変更せずに「変更を保存」。.htaccess が再生成される
PHP バージョンエラーが出る	PHP 7.2/7.3 で更新しようとした	ホスティングの管理画面で PHP バージョンを 7.4 以上に変更してから再試行
メール送信ができない	wp_mail 関数の変更・プラグイン競合	WP Mail SMTP プラグインで SMTP 設定を再確認。テスト送信で確認