アップグレード前のチェックリスト 7 項目 と 「いつ当てるか」の判断軸 で、メジャーアップグレードの準備とタイミングを整理しました。3 部作の最後は「何が起きうるか」── 過去のメジャーで実際にどんな事故が起きたのかを、5 つのパターンとして整理しておきます。
特定のリリース（5.0 / 5.6 / 6.0）の話に見えますが、同じ構造のパターンが新しいメジャーでも繰り返されるのがポイントです。未来の 7.0 や 8.0 でも応用が利く「型」として頭に入れておくと、後から踏むときの対処スピードが上がります。
パターン 1 — 「エディタ周辺の UI 拡張」が一斉に消える（5.0 Gutenberg 移行）
WordPress 5.0 でブロックエディタ（Gutenberg）が標準化された時に発生した、運用上もっとも影響の大きかった事故です。
症状: クラシックエディタ（TinyMCE）を前提にしていたカスタムメタボックス、カスタムフィールド UI、第三者プラグインのエディタ拡張が一斉に動かなくなった。コンテンツ自体は壊れていないけれど、編集 UI が消失した状態。
原因: クラシックエディタの DOM 構造とフックを前提に書かれたコードが、Gutenberg の React ベース UI では参照点を失う。add_meta_box() を呼ぶだけのシンプルな拡張は引き続き動いたが、TinyMCE インスタンスに直接 hook していた拡張は全滅した。
対処の型: Classic Editor プラグインで一時的に旧 UI を維持しながら、ブロックエディタ対応のフォーク・代替プラグインへ計画移行する。「アップグレードを当てる前に、エディタ周辺の依存プラグインを棚卸し」しておくと、移行スコープが事前に見えます。
この事故が示唆するのは、メジャーリリースの目玉機能は周辺エコシステムへの影響が最大化されること。同じ構造は将来の「新しいエディタ系機能」「新しい管理画面 UI」でも繰り返されます。
パターン 2 — JS ライブラリの一斉バージョンアップで連鎖崩壊（5.6 jQuery 3.x 化）
WordPress 5.6 で jQuery が 1.x 系から 3.x 系へジャンプした時の事故です。
症状: フロントエンドの JS 動作が止まる。スライダー・モーダル・フォームバリデーション等の広く使われている jQuery プラグインが動かなくなり、サイトの「動的な部分」が一斉に壊れた。テーマ・プラグインの両方で発生。
原因: jQuery 3.x で $.live()、$.bind() の一部挙動、$.ajax の戻り値の Promise インターフェース等、deprecated だった API が完全削除された。これらに依存していた古いコードが、構文エラーではなく実行時に静かに失敗する。
対処の型: jquery-migrate プラグインで deprecated API の互換レイヤーを提供しつつ、コンソールの警告ログを元に JS 側を順次リファクタする。ステージングでブラウザの開発者ツールを開いて Console タブを監視するのが必須工程になります。
この事故の教訓は、「フロントエンドは管理画面チェックでは見えない」こと。W1 のステージング検証 で「フロントの主要ページが正常表示されるか」を入れる理由は、まさにこのパターンへの備えです。
パターン 3 — PHP 最小要求引き上げで古いプラグインが構文エラー
これは特定のリリースではなく、メジャーアップグレードのたびに断続的に起きる汎用パターンです。代表的なのは PHP 7.4 → 8.0 の境界、PHP 8.1 → 8.2 の dynamic property deprecation。
症状: アップグレード後、特定のプラグインが管理画面で「停止」になっている。あるいは Fatal error でサイト全体が真っ白。エラーログには PHP Parse error または PHP Fatal error: Cannot use ... in write context 系の構文エラー。
原因: PHP の新バージョンで構文・型システムが厳格化される。古いプラグインの「ちょっとだけ古いコード」が、新 PHP ではそもそもパースできない。あるいは、warning が deprecated に格上げされ、表示設定次第で致命的に見える。
対処の型: 事前監査で wp plugin list --format=json を新 PHP 環境で叩いて、JSON が綺麗に返るかを確認する（実機運用ツールが Deprecated 警告で壊れる罠 も併せて）。Tested up to が古いプラグインは、メジャーアップグレード前に代替を検討するのが安全策。
特に注意したいのは、「PHP は上げたが、Tested up to で古いプラグインを残した」という中間状態。PHP が WordPress 側の要求を満たしていても、プラグイン側が PHP 新バージョンに追随していないとサイトが壊れます。
パターン 4 — テーマ構造の前提変更で子テーマカスタマイズが効かなくなる（6.0 FSE 移行期）
WordPress 6.0 で Full Site Editing（FSE）が本格化した時の事故です。
症状: 既存の Classic Theme のカスタマイズが、6.x へのアップグレード自体では崩れていないものの、テーマを Block Theme に切り替えた瞬間に、子テーマで上書きしていた template-parts/*.php が効かなくなる。header.php footer.php などの伝統的なテンプレート階層が、Block Theme では HTML テンプレート（block-templates/*.html）に置き換わる。
原因: Block Theme はテーマファイル構造そのものが Classic Theme と別物。子テーマの上書き機構は同じファイル名規則に依存しているので、Block Theme の HTML テンプレート構造には届かない。
対処の型: 当面 Classic Theme を使い続ける判断と、Block Theme へ移行する場合の子テーマ設計の作り直しの二択。「クライアントサイトのテーマを移行するかどうか」と「WordPress 本体をアップグレードするかどうか」は別問題として扱う必要があります。
この事故が示唆するのは、メジャーリリースが「移行期」を作ること。Classic Theme と Block Theme のように 2 系統が併存する期間は、どちらを使い続けるかの判断軸を運用ルールとして明文化しておく価値があります。
パターン 5 — 内部 API の小さな変更で外部連携が静かに壊れる
ここまでの 4 つは比較的気づきやすい事故ですが、最も発見が遅れるのがこのパターンです。
症状: アップグレード直後はすべて正常に見える。数日〜数週間後、「外部システムから WordPress に POST してくる API 連携が止まっている」ことに気づく。CRM・基幹システム・社内ワークフロー等からの自動投稿・自動更新が、エラーログに残らずただ静かに失敗している。
原因: REST API のスコープ変更、認証方式の細かい調整、CORS 系のヘッダ要件変化、X-WP-Nonce の有効期間変更など。WordPress 公式リリースノートの「Developer Notes」セクションに埋もれている小さな変更が、外部システムの認証フローを破壊する。
対処の型: W2 で書いたステージング 1 週間 soak は、まさにこのパターンを捕まえるための工程です。アップグレード直後の管理画面チェックでは見えない種類の不具合で、時間経過と実トラフィックでしか発覚しない。Site Health の「Loopback テスト」や cron 系のジョブを、ステージングで一定期間動かし続けて観察する必要があります。
外部連携を持っているサイトは、メジャーアップグレード時のチェックリストに「連携先全件の認証経路テスト」を必ず入れます。
まとめ — パターンを知っておくと、未来の事故に対処できる
5 つのパターンを並べると、共通しているのは:
- エディタ・UI 周辺は目玉機能リリース時に集中して壊れる（パターン 1）
- JS / PHP のメジャーバージョン依存は連鎖崩壊しやすい（パターン 2・3）
- 構造的な前提変更は「移行期」を作って共存期間が発生する（パターン 4）
- 静かに壊れるものは時間経過でしか発覚しない（パターン 5）
これらの構造は、次に来るメジャー（7.0 や 8.0）でも別の形で再現します。
| シリーズ全体の関係 |
|---|
| W1 = 何を確認するか（事前チェックリスト 7 項目） |
| W2 = いつ当てるか（5 つの判断軸） |
| W3 = 何が起きうるか（5 つの典型パターン）← 本記事 |
メジャーアップグレードの全工程を「準備 → タイミング → リスク予測」で並べると、運用判断の精度が上がります。未来の WordPress 7.0 が出たときも、「過去 5 パターンのどれに該当するか」を最初に当てはめると、対処の方向が見えやすくなるはずです。
サイトを 1 つ運用しているだけでは見えないこの「型」は、複数サイトを横断して保守している立場では、ほぼ毎メジャーで何らかの形で出会います。事故ごとに対処する運用から、事故パターンを予測して当たりをつける運用へ ── その移行こそが、保守を仕事として持続させるための核心だと思います。