アップグレード前のチェックリスト 7 項目、「いつ当てるか」の判断軸、過去に実際に起きた事故 5 パターン と整理してきた W シリーズの最後は「どう当てるか」です。準備とタイミングが整ったあと、実際にどのコマンドをどの順番で叩くか、各ステップで何を確認するか ── 実作業のコマンド集として整理します。
管理画面の「更新」ボタンを使わない理由
WordPress の管理画面の「更新」ページには、コア・プラグイン・テーマをまとめて「すべて更新」できるボタンがあります。これが最も避けたい実行方法です。
理由は切り分けが効かなくなるからです。コア更新 + プラグイン 5 件 + テーマ 2 件が 1 クリックで一気に走ると、更新後にフロントが崩れた時に「コアが原因か、どのプラグインか、テーマか」が見えなくなります。管理画面の更新は画面上に「更新完了」と出ますが、PHP の Warning や Fatal が出ていても「完了」のまま終わることがあり、問題を見逃しやすい経路でもあります。
WP-CLI なら、コア・DB マイグレーション・プラグイン（1 本ずつ）・テーマを順番に当てて、各ステップで確認を挟めます。
STEP 0 — 実行前の最終確認
作業を始める前に、現状を把握してバックアップを取ります。
# 現在のコアバージョンと更新の有無を確認
wp core version
wp core check-update
# DB バックアップ（圧縮込み）
wp db export - | gzip > backup_$(date +%Y%m%d_%H%M%S).sql.gz
# 更新待ちプラグインと件数を把握
wp plugin list --update=available --format=table
# 更新待ちテーマを確認
wp theme list --update=available --format=table
wp core check-update はターゲットバージョンをコマンド実行前に把握するために使います。「何もしていないのにバージョンが変わっていた」を防ぐ現状確認の癖として入れておくと、作業ログが後から読みやすくなります。
DB バックアップはコア更新の直前に取ることが特に重要です。コアのメジャー更新は DB マイグレーションを伴うことがあり、途中で止まった場合のリカバリーに直前バックアップが必要になります。
STEP 1 — コアを段階的に更新する
メジャーアップグレードで「6.4 から 6.7 へ」というように複数バージョンを一気にスキップすることは、バージョンをまたいだ DB マイグレーションが重なるため、問題が起きた時の切り分けが複雑になります。中間バージョンを刻んで当てると、どの段階で何が起きたかを特定しやすくなります。
# バージョンを明示して更新（最新ではなく対象バージョンを指定）
wp core update --version=6.5
# 必ずコア更新の直後に DB マイグレーションを実行
wp core update-db
# コアファイルの整合性確認（改変・欠損がないか）
wp core verify-checksums
--version= を省略すると最新版に一気に上がります。メジャーアップグレードでは省略しない方が安全です。
wp core update-db は忘れがちですが、WP のコアと DB スキーマのバージョンを揃えるために必須です。DB マイグレーションが走っていない状態で管理画面を開くと、自動的にマイグレーション処理が走ることもありますが、「明示的に実行した結果を確認する」方が証跡として残ります。
wp core verify-checksums は、コアファイルが WordPress.org の正規チェックサムと一致するかを検証します。サーバーに直接 FTP でファイルを置いていた歴史がある環境では、コアが部分的に改変されていることがあるので、更新前後に叩いておくと安全です。
コアを更新したら、管理画面にログインできるか・フロントの主要ページが返ってくるかを確認してから次のステップに進みます。
STEP 2 — プラグインを 1 本ずつ更新する
コアが正常に動くことを確認したら、プラグインを更新します。1 本ずつ当てて、毎回サイトの応答を確認するのが基本です。
# 更新可能なプラグインを一覧表示
wp plugin list --update=available --format=table
# 1 本ずつ更新（プラグイン名は slug で指定）
wp plugin update contact-form-7
# ... HTTP チェック（フロント確認）...
wp plugin update woocommerce
# ... HTTP チェック（決済フロー確認）...
wp plugin update yoast-seo
更新順は影響の小さいものから当てるのが基本です。目安として:
| 先に当てる（影響が出ても復旧しやすい） | 後で当てる（影響範囲が大きい） |
|---|---|
| SEO プラグイン、セキュリティプラグイン | EC（WooCommerce）・フォーム・LMS |
| デバッグ・管理補助系 | ページビルダー |
| キャッシュプラグイン | 認証・マルチサイト関連 |
W3 で整理した事故パターンのうち、パターン 2（JS ライブラリ連鎖崩壊）とパターン 3（PHP 最小要求引き上げ）はプラグイン更新が引き金になりやすい。ページビルダーや jQuery 依存度が高いプラグインは、更新後にブラウザのコンソールタブで JS エラーが出ていないかも確認します。
WP-CLI でプラグインが更新できない状態（Fatal Error で WP-CLI 自体が落ちる）になった場合は、--skip-plugins --skip-themes の安全モード起動で WP-CLI を立ち上げ直すと、プラグイン読み込みをバイパスして作業を継続できます。
STEP 3 — テーマを更新する
プラグイン更新が終わったら、テーマを更新します。
# 更新可能なテーマを確認
wp theme list --update=available --format=table
# テーマを更新
wp theme update twentytwentyfour
親テーマを更新する場合は、子テーマのカスタマイズが引き続き効いているかを確認します。子テーマで上書きしているテンプレートファイルが、親テーマ側の変更と衝突することがあります。特に W3 のパターン 4（Block Theme 移行期の子テーマ問題）は、アップグレード後のテーマ更新のタイミングで表面化しやすい。
テーマは親テーマを更新しても「子テーマの中身は変わらない」という前提で動いていますが、親テーマが参照しているフックの名称変更や削除は子テーマに影響します。主要ページを開いて見た目が崩れていないか確認してから完了とします。
問題が起きた時のロールバック
各ステップで問題が起きた場合のロールバックコマンドは、実行前に手元に用意しておきます。
コアをロールバックする
# 1 バージョン前のコアに強制的に戻す
wp core update --version=6.4 --force
# コアを戻したら DB も戻す（STEP 0 で取ったバックアップを使う）
wp db import backup_20260615_090000.sql.gz
--force を付けることで「既に同バージョンが入っている」状態でも強制再インストールされます。
プラグインをロールバックする
# 旧バージョンを指定して強制インストール（上書き）
wp plugin install contact-form-7 --version=5.8.3 --force
プラグインのロールバックは ピンポイントロールバックの手順 に詳しくまとめています。バージョン番号は wp plugin list の version 列で確認できます。
なお、コアのロールバック後は A2 の halt 設計 と同じ状況です。コアが不安定な状態でプラグイン更新を続けるリスクがあるため、コアが安定するまでプラグイン更新を止める判断を優先します。
まとめ
| コマンド | タイミング |
|---|---|
wp core check-update |
作業前の状態確認 |
wp db export |
コア更新前（必須） |
wp core update --version=X.X |
中間バージョンを刻んで更新 |
wp core update-db |
コア更新の直後（必須） |
wp core verify-checksums |
コア整合性確認 |
wp plugin update <name> |
1 本ずつ更新 + HTTP 確認 |
wp theme update <name> |
テーマ更新 + 表示確認 |
wp core update --version=X.X --force |
コアロールバック（問題発生時） |
wp plugin install <name> --version=X.X.X --force |
プラグインロールバック（問題発生時） |
W シリーズ全体の関係:
| 記事 | テーマ |
|---|---|
| W1 = 何を確認するか | アップグレード前チェックリスト 7 項目 |
| W2 = いつ当てるか | x.0.1 を待つ判断軸 5 つ |
| W3 = 何が起きうるか | 過去の事故 5 パターン |
| W4 = どう当てるか | 実行コマンドと各ステップの確認ポイント ← 本記事 |
| W5 = 7.0 に備える | PHP 要件・FSE 移行・エディタ拡張の 3 つの論点 |
| W6 = 更新後に確認する | アップグレード後の動作確認 7 ステップ |
段階的に当てることは「面倒な手順」ではなく、問題が起きた時の「切り分けを可能にする構造」です。どのコマンドが何を変えるかを 1 ステップずつ把握して実行することが、事後の復旧コストを下げる唯一の方法です。