コンテンツへスキップ
WordPress保守

WordPress メジャーアップグレード後の動作確認 — 「更新完了」から「稼働確認」までの 7 ステップ

WordPress メジャーアップグレード後の動作確認 — 「更新完了」から「稼働確認」までの 7 ステップ

W4 で整理した WP-CLI の段階実行手順を経て、「Success: Core updated successfully」のメッセージが出た。そこで終わりにしてしまうのが、最も多い見落としの一つです。

WP-CLI の「成功」は「コアファイルの更新が完了した」という意味であって、「サイトが正常に動いている」という意味ではありません。DB マイグレーションが走ったこと、プラグインが新コアと噛み合っていること、フォームが送信できること、カートが通ること ── これらは更新後に人の目で確認するしかない工程です。

この記事はW1 の事前チェックリストと対をなす「事後確認」のリストです。W4 の実行手順を終えた直後に続けて行う作業として読んでください。

なぜ「更新成功」で終わりにしてはいけないか

WP-CLI の出力に「Success」と表示されても、以下のことは保証されていません。

  • プラグイン同士の組み合わせが新コアで正常に動くか
  • PHP の Warning や Notice がページ上に表示されていないか（WordPress は非 Fatal エラーを握り潰したまま「成功」と返すことがある）
  • フォームやカートなどのインタラクション系が正しく動作するか
  • キャッシュが古い状態で配信されていないか

W3 で整理した事故パターンの多くは「更新直後ではなく、数時間後または次の操作まで気付かない」という共通点があります。確認を後回しにするほど、原因の特定が難しくなります。

確認の優先順位 — 影響が大きいものから始める

確認の順序は「壊れていた場合にユーザーへの影響が最大のもの」から並べます。問題を見つけた時点でロールバックを判断できるよう、影響範囲の大きいチェックを前半に置くのが基本方針です。

STEP 1 — コアファイルの整合性を再確認する

W4 でも実行した wp core verify-checksums を、アップグレード完了後にもう一度実行します。

# 最終的なバージョンを確認
wp core version

# コアファイルを WordPress.org のチェックサムと照合
wp core verify-checksums

更新プロセス中に何らかの原因でファイルが壊れていた場合、このコマンドが検出します。差分が出た場合は wp core download --force で再インストールします。正常に完了すれば「Success: WordPress installation verifies against checksums.」が出ます。

STEP 2 — 管理画面へのログインと表示確認

WordPress 管理画面（/wp-admin/）にログインして、以下を目視します。

  • ダッシュボードが表示されるか（真っ白・500 エラー画面でないか）
  • 投稿・固定ページ・メディアが正常に一覧表示されるか
  • 「プラグイン」ページを開いて、更新前にアクティブだったプラグインが全件有効になっているか

最後の確認が特に重要です。コアとの非互換が検出された場合、WordPress はプラグインを自動的に無効化することがあります。WP-CLI でもチェックできます。

# アクティブなプラグイン一覧（強制 deactivate がないか確認）
wp plugin list --status=active --format=table

# 非アクティブになっているプラグインがあれば表示される
wp plugin list --status=inactive --format=table

更新前の状態と比べてアクティブ数が減っている場合は、非アクティブリストを確認します。

STEP 3 — フロントエンドのページ表示と JavaScript エラー確認

主要ページに curl または実際のブラウザでアクセスして、HTTP 200 が返るか確認します。

# 主要ページの HTTP ステータス確認
curl -s -o /dev/null -w "%{http_code}" "https://example.com/"
curl -s -o /dev/null -w "%{http_code}" "https://example.com/contact/"
curl -s -o /dev/null -w "%{http_code}" "https://example.com/shop/"

curl でのステータス確認と合わせて、ブラウザのコンソールタブ（F12 → Console）を開いて JavaScript エラーが出ていないかを確認します。W3 のパターン 2（jQuery 連鎖崩壊）はコンソールの JS エラーとして現れることが多く、ページが「見た目は表示されている」状態でも内部で機能が壊れていることがあります。

確認するページの目安:

ページ種別 確認優先度
トップページ 最優先
お問い合わせ・フォームページ 高
カート・決済ページ（EC 系） 最優先
投稿一覧・個別記事 中
検索結果ページ 中

STEP 4 — フォーム・インタラクション確認

サイトの核心機能であるインタラクション系を実際に操作して確認します。

  • コンタクトフォーム: 送信 → 完了画面表示 → 通知メールの着信まで確認
  • 検索フォーム: キーワードを入れて結果が表示されるか
  • ログイン / 会員登録: ログイン画面からの認証フロー
  • コメント機能: コメントを有効にしている場合は投稿テスト

この工程は WP-CLI では代替できません。テスト用のアカウント・メールアドレスを事前に準備しておいて、実際に手を動かして確認します。フォームプラグイン（Contact Form 7 / WPForms 等）はコアのメジャー更新に伴って JavaScript の動作が変わることがあり、送信ボタンを押しても反応しないという症状が出やすい箇所でもあります。

STEP 5 — EC・予約系サイトの決済フロー確認

EC サイト・予約システム・会員サービスを運営しているサイトは、決済フローのテストを必ず実施します。

  • カートへの商品追加と数量変更
  • チェックアウトページへの遷移
  • 決済フォームの表示（カード情報入力フィールドが正しく出ているか）
  • テスト決済の実行（Stripe のテストモード・ペイジェントのテスト環境等で実際に通す）

「決済画面が表示される」だけでなく「決済が完了する」まで確認します。WooCommerce のような EC プラグインはコアのメジャー更新に敏感で、ページビルダーや決済プラグインとの組み合わせで JavaScript エラーが起きやすい箇所です。STEP 3 のコンソールエラー確認と合わせて行うと見落としが減ります。

EC・予約系でないサイトはこのステップを省略できます。

STEP 6 — PHP エラーログの確認

ページが表示されていても、バックグラウンドで PHP エラーが出続けている場合があります。

# WordPress の WP_DEBUG_LOG が有効か確認
wp eval 'echo defined("WP_DEBUG_LOG") && WP_DEBUG_LOG ? "debug log: on" : "debug log: off";'

# debug.log が有効な場合、最後の 50 行を確認
wp eval 'echo WP_CONTENT_DIR;'
# → /path/to/wp-content などが出る
# 上記パスに debug.log があれば tail で確認

# SSH でサーバーの PHP エラーログを確認（パスはサーバー環境による）
tail -100 ~/logs/php_errors.log 2>/dev/null

V40 で整理した PHP 8.2+ × WP-CLI の Deprecated 警告問題と同様に、PHP バージョンとコアの組み合わせが変わることで新しい Deprecated が増えることがあります。Fatal Error ではないものの、WP-CLI の JSON 出力を汚染したり、管理画面の一部機能に影響することがあるため、アップグレード前後でエラーログの傾向が変化していないか目を通しておきます。

STEP 7 — キャッシュのパージと再確認

キャッシュ系プラグイン（W3 Total Cache / WP Fastest Cache / WP Super Cache 等）やサーバー側のページキャッシュが有効な環境では、アップグレード後にキャッシュをパージしないと古いファイルが配信され続けます。

# プラグインによってコマンドが異なる（対応しているものだけ有効）
wp cache flush
wp w3-total-cache flush all 2>/dev/null
wp super-cache flush 2>/dev/null

サーバー側のページキャッシュ（Xserver 等のサーバーパネルから設定するもの）は管理パネルから手動でパージします。パージ後にもう一度 STEP 3 のフロントページ確認を行い、最新のコンテンツとアセットが配信されているかを確認します。

問題が見つかった場合

STEP 1〜7 のどこかで問題が見つかった場合は、W4 のロールバック手順に従います。

  • コア起因の問題 → wp core update --version=X.X --force でコアを旧バージョンに戻す
  • プラグイン起因の問題 → wp plugin install <name> --version=X.X.X --force でプラグインを戻す

A1 の安全モード起動（--skip-plugins --skip-themes）は、WP-CLI 自体が起動しない状態になった時の救命手段です。管理画面にもアクセスできない状況でロールバックを実行しなければならない場合に使います。

なお、A2 の halt-after-core-rollback 設計が示す通り、コアをロールバックした後はプラグインの更新作業を一時停止するのが原則です。コアが安定してから残りの作業を再開します。

まとめ

ステップ 確認内容 方法
STEP 1 wp core verify-checksums でコアファイル整合性 WP-CLI
STEP 2 管理画面ログイン + プラグイン強制 deactivate チェック ブラウザ + WP-CLI
STEP 3 フロントページ HTTP 200 + コンソール JS エラー curl + ブラウザ DevTools
STEP 4 フォーム送信・検索・ログインの動作確認 手動操作
STEP 5 EC サイトはテスト決済フローまで 手動操作（テストモード）
STEP 6 PHP エラーログで Deprecated / Fatal の変化確認 SSH + tail
STEP 7 キャッシュパージ後に再確認 WP-CLI + 管理パネル

W シリーズ全体の位置関係:

記事 テーマ
W1 = 何を確認するか アップグレード前チェックリスト 7 項目
W2 = いつ当てるか x.0.1 を待つ判断軸 5 つ
W3 = 何が起きうるか 過去の事故 5 パターン
W4 = どう当てるか WP-CLI 実行コマンドと確認ポイント
W5 = 7.0 に備える PHP 要件・FSE 移行・エディタ拡張の 3 つの論点
W6 = 更新後に確認する アップグレード後の動作確認 7 ステップ ← 本記事

「更新が完了した」と「サイトが正常に動いていると確認できた」は別のことです。W4 の実行とこのリストを組み合わせることで、アップグレードの各ステップが可逆的かつ検証済みの状態を維持できます。