WordPress メジャーリリースは即日当てない — 「x.0.1 を待つ」判断軸と運用ルール

メジャーアップグレード前のチェックリスト 7 項目 で「何を確認するか」をまとめましたが、保守の現場で次に来る問いは「いつ当てるか」です。

WordPress のメジャーリリースが「今日出た」というニュースを見たとして、その日のうちに本番に当てるべきか。明日か。1 週間後か。月次定期メンテのタイミングまで待つか。この判断は属人化しやすい領域ですが、いくつかの軸を組み合わせれば、毎回ぶれない運用ルールに落とし込めます。今回はその判断軸を 5 つに整理しておきます。

大前提 — メジャーは「セキュリティ修正」とは別物として扱う

最初に確認したいのは、メジャーアップグレード = セキュリティ修正ではないという点です。

WordPress のセキュリティ修正は基本的にマイナーリリース（6.4.1 → 6.4.2、6.5.0 → 6.5.1 のような 2 桁目の上がり方）で配信されます。これらは即日適用が原則です。一方、メジャーリリース（6.4 → 6.5、いずれの 6.x → 7.0）は新機能・API 変更が中心で、セキュリティ修正のために即日当てる性質のものではない。

この区別を持っておかないと、「当てないとセキュリティが」という心理的プレッシャーで、本来待つべき場面で性急に当ててしまいます。マイナーは即日、メジャーは判断 ── まずこの分離を運用ルールに置きます。

判断軸 1 — x.0.1 を待つ

ほぼ全てのメジャーリリースには、リリース後 1〜3 週間で x.0.1（最初のパッチリリース）が出ます。ここに、リリース直後に発覚した致命的な不具合の修正が入ります。

過去のメジャーで実際にあったのは、たとえば「特定の設定下で管理画面が真っ白になる」「特定のテーマでブロックエディタが動かない」「DB マイグレーション中に特定環境で停止する」といった種類のバグ。リリース日には誰も踏んでいなかったけれど、世界中で使われ始めて数日〜数週間で表面化したものです。

「x.0 ではなく x.0.1 まで待つ」だけで、こうした初期バグの大半をやり過ごせます。リリース直後の数週間は、世界中の WordPress ユーザーが事実上のベータテスターとして動いているので、彼らが踏んでくれた地雷を踏まなくて済む立場にいる方が、保守としては合理的です。

判断軸 2 — 主要プラグインベンダーの「Tested up to」が動くまで待つ

メジャーアップグレードで詰まる原因の上位は、ほぼ常にプラグイン互換性です。テーマ互換性も後を追いますが、影響度ではプラグインが先行します。

そこで観察すべきは、主要プラグインが新メジャーに対応した宣言を出しているか。具体的には:

• ACF（Advanced Custom Fields）
• WooCommerce（EC 系を扱うなら必須）
• Yoast SEO / Rank Math（SEO 系）
• Elementor / Beaver Builder（ページビルダー系）
• WPML / Polylang（多言語）
• Wordfence / iThemes Security（セキュリティ）

これらの大手プラグインが readme.txt の Tested up to を新バージョンに更新するか、公式ブログで「対応しました」とアナウンスを出すまでは、本番適用を見送るのが安全策。主要プラグインが追従していない時点では、まだメジャーは「枯れていない」と判断します。

判断軸 3 — ステージングで 1 週間 soak させる

W1 でも触れたステージング検証ですが、メジャーアップグレードでは「当てた直後の挙動」だけでなく「時間経過で発覚する不具合」も観察対象に入れます。具体的には:

• wp-cron が動き続けているか（日次・週次ジョブが時刻通りに走るか）
• メール送信が止まっていないか（コメント通知・お問い合わせ通知）
• キャッシュが壊れて中身がずれていないか
• 画像生成（サムネイル・OGP）が時間差で失敗していないか

これらは「アップグレード直後に管理画面を開いて見る」では捕まらない種類の不具合で、最低 1 週間の自然運用が必要です。ステージングを 1 週間動かして、エラーログに変なものが積み上がっていなければ、ようやく本番候補に乗せられる状態になります。

判断軸 4 — 案件のリスクプロファイル

「いつ当てるか」は、サイトのリスクプロファイルでも変わります。ざっくり 3 階層に分けると:

EC や予約システムは「注文が落ちる = 売上が落ちる」直結なので、待機期間を長く取る価値があります。逆に静的コーポレートサイトは仮にレイアウトが少し崩れても直近の事業影響が小さいので、もう少し前のめりでよい。

「全サイト同じタイミングで一斉適用」を避けて、リスクプロファイル別に段階適用するのは、保守業務として大事な分散戦略です。

判断軸 5 — クライアントとの契約・SLA の整合

最後の軸は契約面です。月次定期メンテナンス契約を結んでいるなら、メジャーアップグレードも次回の月次定期のタイミングに合わせる方が、契約上の説明がスムーズになります。

「月次メンテで適用する範囲を超えた緊急更新があるか」を毎回確認して、緊急性がなければ次回月次に組み込む。緊急性がある（重大セキュリティ修正がメジャーに含まれているような例外的ケース）なら、別途見積もりで臨時メンテに切り出す。

この境界線を契約段階で明文化しておくと、「今すぐ当てて」「しばらく待って」というクライアントごとの要望のズレが減って、運用が安定します。

「待つコスト」と「突っ込むコスト」のフレーム

5 軸を並べると「待つばかりで何もできない」印象になりますが、待つことには明確なコストがあります:

• 新機能を享受できない期間が長い
• マイナーアップデート時にメジャー差分も一緒に来ると、差分が大きくなる
• 過去バージョンのサポート切れに引っかかるリスク

一方、突っ込むコストは:

• 障害発生 → クライアント信用低下
• 復旧対応の人件費（時間外含む）
• 場合によっては事業継続への直接影響

このトレードオフを、サイトごとのリスクプロファイルと照らして判断するのが「いつ当てるか」の核です。決まったルールは作れませんが、5 軸を組み合わせれば、毎回ぶれない判断のスケルトンは作れます。

メジャー適用が事故になると、その後の「コア更新後にメンテを止める」のような halt 経路の発動 も視野に入ります。性急な適用が長期化する復旧負担を生むことを思えば、x.0.1 まで数週間待つ判断は、保守の長期 ROI でほぼ確実に黒字になる選択肢です。「何が起きうるか」を過去事例から型にした 失敗 5 パターン と合わせて読むと、判断軸がさらにシャープになります。