WordPress更新は「一括更新して祈る」では危ない。ステップごと更新とHTTPチェックの考え方

WordPressの管理画面には、更新対象をまとめて選んで一括更新できる機能があります。

とても便利です。

ただ、保守の現場で考えると、一括更新には怖さもあります。

プラグインを5件、10件とまとめて更新して、そのあとサイトが500エラーになった場合、どの更新が原因だったのかをすぐには判断できません。結局、更新履歴を見直し、プラグインをひとつずつ戻し、エラーログを確認しながら原因を探すことになります。

要点: WordPress更新で大事なのは、ただ更新を完了させることではありません。問題が起きたときに「どの更新で壊れたか」を特定できる形で進めることです。

レイヤーワークスでは、WordPress保守ツールの開発を通じて、更新処理を「一括で流す」のではなく、ステップごとに分けて確認する設計を重視しています。

この記事では、WordPress更新で事故を減らすための「ステップごと更新」と「HTTPチェック」の考え方を整理します。

一括更新が危ない理由

一括更新そのものが悪いわけではありません。

小規模なサイトや、検証環境が整っているサイトでは、まとめて更新しても問題ない場面はあります。

ただし、本番サイトの保守作業として見ると、一括更新にはいくつかの弱点があります。

• どのプラグインが原因で不具合が起きたか分かりにくい
• 更新直後のサイト状態を段階的に確認できない
• 問題が起きたとき、戻す範囲が大きくなりやすい
• ログに「何の後に壊れたか」が残りにくい
• 複数の更新が絡むと、原因の切り分けに時間がかかる

たとえば、10個のプラグインを一括更新したあとにHTTP 500が出たとします。

この場合、「10個のうちどれかが原因」までは分かります。しかし、どれなのかは分かりません。

さらに、複数のプラグインの組み合わせで不具合が起きている可能性もあります。

保守作業で本当に避けたいのは、更新そのものよりも、問題発生後に原因が見えなくなることです。

ステップごと更新とは何か

ステップごと更新は、更新対象をひとつずつ処理し、その都度サイトの状態を確認する考え方です。

たとえば、次のような流れです。

1. 更新前にサイトのHTTPステータスを確認する
2. WordPress本体を更新する
3. HTTPステータスを確認する
4. プラグインAを更新する
5. HTTPステータスを確認する
6. プラグインBを更新する
7. HTTPステータスを確認する

この形にすると、もしプラグインBの更新後にHTTP 500が出た場合、原因候補をかなり絞れます。

「プラグインBを更新した直後に壊れた」と分かるからです。

もちろん、実際にはキャッシュ、外部API、テーマとの組み合わせなど、単純に1つのプラグインだけが原因とは限りません。それでも、一括更新後にまとめて壊れるより、調査の出発点がかなり明確になります。

HTTPチェックで見るべきこと

更新後の確認では、まずHTTPステータスを見ます。

代表的には次のような分類です。

ここで大事なのは、HTTPチェックを「成功か失敗か」の単純な二択にしないことです。

たとえばHTTP 500以上であれば、PHP Fatal errorやプラグイン互換性の問題が疑われます。この場合は、直前の更新を戻す判断が必要になります。

一方で、タイムアウトやHTTP 0は少し扱いが難しいです。

通信の一時的な遅延、サーバー負荷、セキュリティ設定、外部ネットワークの問題でも起こり得ます。ここで機械的にロールバックすると、逆に不要な巻き戻しになる可能性があります。

そのため、HTTP 500以上はError、タイムアウトはWarningとして扱う、というように線引きを決めておくことが重要です。

どこまで自動で戻すかを決めておく

ステップごと更新をするなら、異常時の戻し方も先に決めておく必要があります。

考え方としては、問題が起きた直前の更新だけを戻すのが基本です。

たとえば、次のような流れです。

プラグインA 更新 → HTTP 200
プラグインB 更新 → HTTP 200
プラグインC 更新 → HTTP 500
プラグインC だけロールバック
復旧確認
残りの更新を続行するか判断

このようにすれば、問題のない更新までまとめて戻す必要がありません。

また、ログにも「プラグインC更新後にHTTP 500、プラグインCをロールバック、復旧確認」という形で残せます。

保守作業では、このログがかなり大事です。

あとからクライアントに説明するときも、社内で見直すときも、「何をして、どこで異常を検知し、どう戻したか」が分かる状態にしておく必要があります。

HTTP 200でも安心しすぎない

ここまでHTTPチェックの話をしてきましたが、HTTP 200が返れば完全に安心というわけではありません。

サイトはHTTP 200を返していても、次のような問題が起きることがあります。

• レイアウトが崩れている
• JavaScriptエラーでフォームが動かない
• スライダーやメニューが表示されない
• 管理画面だけ不具合が出ている
• 特定ページだけ崩れている

HTTPチェックは、あくまで最初の入口です。

最低限「サイトがサーバーエラーになっていないか」を見るものです。

そのため、重要なサイトでは、HTTPチェックに加えて、トップページや主要ページの表示確認、フォーム確認、スクリーンショット比較なども組み合わせる必要があります。

ただし、すべてを自動判定しようとしすぎると、運用が重くなります。

まずはHTTPステータスで大きな障害を検知する。次に、必要なページを人間の目やスクリーンショットで確認する。

この段階分けが現実的です。

WP-CLIを使うと、ステップごと更新を組み立てやすい

WordPressの管理画面からでも、プラグインを1件ずつ更新することはできます。

ただ、保守作業として安定させるなら、WP-CLIを使うと流れを組み立てやすくなります。

たとえば、更新対象の確認、プラグインの個別更新、バージョン確認、ロールバック、ログ取得などをコマンドとして扱えるからです。

イメージとしては次のような流れです。

wp core check-update
wp plugin list --update=available
wp plugin update plugin-slug

もちろん、本番環境でコマンドを実行する場合は、事前バックアップ、実行ユーザー、PHPバージョン、WP-CLIパス、メンテナンス時間帯などを確認する必要があります。

WP-CLIは便利ですが、強い道具です。

だからこそ、コマンドを打てることよりも、どの順番で確認し、どの条件で止めるかを決めておくことが大切です。

保守で残すべきログ

ステップごと更新をするなら、ログには最低限次の情報を残したいところです。

• 更新前のWordPress本体・プラグインのバージョン
• 更新対象
• 各更新の実行結果
• 各更新後のHTTPステータス
• Error / Warning の分類
• ロールバックの有無
• 復旧確認の結果
• 手動確認が必要な項目

このログがあると、保守作業の説明がしやすくなります。

「更新しました」だけでは、保守の品質は伝わりません。

「どこを確認し、何を異常と判断し、問題があった場合にどう対処したか」まで残っていて、はじめて運用として信頼できます。

まとめ

WordPress更新は、ボタンを押して終わりではありません。

特に本番サイトでは、更新後に問題が起きたとき、すぐに原因を切り分けられる進め方が重要です。

一括更新して、問題が起きたら祈りながら戻す。

このやり方では、原因特定にも説明にも時間がかかります。

更新をステップごとに分ける。各ステップのあとにHTTPステータスを確認する。HTTP 500以上、タイムアウト、4xxの扱いを決めておく。異常時には直前の更新だけ戻せるようにする。ログに残す。

こうした地味な設計が、WordPress保守の安全性を支えます。

AIや自動化を使う場合でも、考え方は同じです。

大事なのは「自動で更新できること」ではありません。

問題が起きたときに、どこで起きたか分かること。

そして、必要な範囲だけ戻せることです。