WordPress のメジャーバージョンアップグレード（5.x → 6.x、いずれ来る 6.x → 7.x）は、マイナーリリースとは別物として扱う必要があります。マイナー（6.4.1 → 6.4.2 のような）はバグ修正中心で互換性破壊が少ないですが、メジャーは API の deprecate・PHP 最小要求の引き上げ・コアブロックの差し替え など、運用に効いてくる変更が一気に入ります。
「とりあえず管理画面の更新ボタンを押して、壊れたら直す」運用は、サイト 1 つなら何とかなりますが、複数サイトを保守する立場では破滅的になりやすい ── 同時多発で壊れると原因切り分けが追いつかなくなります。今回は、メジャーアップグレードを実行する前に確認すべき項目を、チェックリスト形式で 7 つにまとめておきます。
1. PHP の最小要求バージョンが上がっていないか
WordPress のメジャーリリースでは、PHP の最小サポートバージョンが引き上げられることがあります（6.6 で PHP 7.2 → 7.2.24、将来の 7.0 では PHP 8.x 必須になる可能性が高い）。
ここで気をつけたいのは、サーバーの PHP バージョンと WordPress が要求する最小バージョンの両方に加えて、プラグイン・テーマが対応している PHP バージョンの交差点が安全圏になる、ということ。サーバーの PHP は上げられても、古いテーマやプラグインが新しい PHP で動かないケースは少なくありません。
実機で踏みやすいのは、たとえば PHP 8.2+ と古い WP-CLI の組合せで Deprecated 警告が JSON 出力に混入する罠 のような、表面的にはエラーが出ないけれど運用ツールが壊れるパターンです。アップグレード前に、本番の PHP 環境で wp plugin list --format=json が綺麗な JSON を返すかを確認しておくと、後で困る確率が下がります。
2. プラグインの「Tested up to」を全件確認する
各プラグインの readme.txt には Tested up to: X.X という記述があります。これは「この WordPress バージョンまでで開発者が動作確認した」という宣言で、メジャーアップグレード前の互換性チェックの第一指標になります。
WP-CLI で全プラグインの一覧と最終更新日を一気に取れば、棚卸しの精度と網羅性が一段上がります:
wp plugin list --fields=name,version,update_version,update --format=table
「Tested up to が古い + 直近 1 年更新がない」プラグインは要注意です。開発が止まっている可能性があり、メジャーアップグレード後に動かなくなった時に修正パッチが期待できません。代替プラグインへの移行を含めて、アップグレード前に判断する方が安全です。
3. テーマの互換性 — 子テーマと深いカスタマイズの確認
テーマもメジャーアップグレードで影響を受けます。特に注意すべきは:
- ブロックエディタ系の API（5.x→6.x で大量の API 変更があった）
- カスタマイズが入った子テーマ（親テーマが更新されても子テーマ側のフックが古いまま）
- ページビルダー系プラグインのバージョン要求
クライアント案件で「テーマが古いから PHP を上げられない」状況は珍しくありません。テーマ側の制約で WordPress 本体のアップグレードも見送る判断になるケースは、計画段階で識別しておく必要があります。
4. データベースバックアップ — 3 世代以上保持
メジャーアップグレードは DB マイグレーションを伴うことがあります。WordPress の DB マイグレーションは基本的に冪等ですが、中途半端に途中で死んだ場合のリカバリーが面倒です。実行前にフルバックアップを取り、直前 + 直近 + 1 つ前くらいの 3 世代を残しておくのが安全策。
# DB エクスポート（圧縮込み）
wp db export - | gzip > backup_$(date +%Y%m%d_%H%M%S).sql.gz
# wp-content も併せて取る場合
tar czf wp-content_$(date +%Y%m%d_%H%M%S).tar.gz wp-content/
サイズが大きい場合は エクスポート中の SSH 切断で .sql が残骸として残ることがあるので、完了確認をしてから次に進みます。
5. ステージング環境で先に流す
本番にいきなりメジャーアップグレードを当てるのは、サイトを 1 つしか持っていない場合でも避けたい運用です。ステージング環境（本番のクローン）で先にアップグレードして、見た目の崩れ・管理画面の動作・WP-CLI の動作・主要プラグインの管理画面遷移を確認してから本番に流します。
レンタルサーバーによっては「ステージング機能」が標準で提供されているので、それを使うのが一番速い。SSH で同じサーバー内の別ディレクトリに rsync で複製する手もあります（DB は別途インポート）。
ステージングでの確認項目は最低限:
- 管理画面が開けるか・記事編集が崩れていないか
- フロントの主要ページが正常表示されるか
- お問い合わせフォーム等の動的機能が動くか
- WP-CLI で
wp plugin listが綺麗に取れるか
6. WP-CLI で段階的に更新する（管理画面のワンクリック更新を使わない）
管理画面の「更新」ボタンは、複数の更新を一気に当てる設計です。コア更新 + プラグイン更新 + テーマ更新がまとめて走ると、どれが壊したか切り分けられなくなる。これがメジャーアップグレードでは特に致命的です。
WP-CLI なら、コアだけ・プラグインだけ・テーマだけを順番に当てられます。
# 1. コアだけ先に当てる
wp core update --version=6.7
# 2. DB マイグレーション
wp core update-db
# 3. プラグインは 1 つずつ
wp plugin update <plugin-name>
# 4. テーマも同様
wp theme update <theme-name>
--version= を指定することで「スキップ更新」を避けて段階的に進められます。たとえば 6.4 から 6.7 へ直接ジャンプせず、6.5 → 6.6 → 6.7 と刻むと、どの段階で何が起きたかを切り分けやすくなります。
ちなみに、WP-CLI が壊れたプラグインで起動段階から落ちるケース もあるので、メジャーアップグレード後に WP-CLI 自体が動かなくなる経路を見越して --skip-plugins --skip-themes の救命フラグを覚えておくと安心です。
7. ロールバック手順を書面化しておく
最後に、失敗したらどう戻すかを実行前に書面化しておきます。「困った時にググる」は時間がかかりすぎる ── トラブル中はパニックも入るので、手順書を見ながら復旧する方が安全です。
最低限の項目:
- DB のリストア手順（5 で取ったバックアップから戻す具体的コマンド）
- ファイルシステムのリストア手順（
tar xzfのフルコマンド） - WP-CLI で 1 バージョン前のコアに戻す手順:
bash
wp core update --version=6.6 --force - プラグイン単位での旧バージョン戻し（ピンポイントロールバックの考え方 を参考に）:
bash
wp plugin install <plugin-name> --version=X.X.X --force
ロールバック手順を「書く」過程で、不足している準備（バックアップ取り忘れ・WP-CLI が入っていないサーバー等）に気づくことが多いので、手順書化そのものが事前チェックの役割を果たします。
まとめ — 「アップデート前の 10 分」で「アップデート後の数時間」が変わる
7 項目を並べると重く見えますが、慣れればアップグレード前の確認は 10〜15 分で終わります。一方、確認なしで突っ込んでサイトが壊れた時の復旧は、数時間から半日の話になります。複数サイトを保守している場合は、その差が運用全体に効きます。
「アップデートしてから直せばいい」は、1 サイトの個人運用なら成立する戦略ですが、保守を仕事として請け負っている場合は破綻します。チェックリストを 1 つ手元に持っておいて、メジャーアップグレードを実行するたびに上から順に潰していく ── それだけで、事故率は目に見えて下がるはずです。