WordPressアップデートでBad Gatewayが出た原因と対処方法を徹底解説｜「別の更新が現在進行中です」の直し方もわかる実践ガイド

WordPressを管理していると、ある日突然アップデート中に Bad Gateway が表示されてヒヤッとすることがあります。さらに再度「更新」ボタンを押したら、「別の更新が現在進行中です。」 と表示され、身動きが取れなくなることもあります。

この症状は、WordPress運用者にとってかなりよくあるトラブルです。しかも、見た目は大ごとに見えるのに、原因自体は比較的わかりやすく、順番通りに対処すれば落ち着いて復旧できるケースが多いです。

この記事では、WordPressアップデート中にBad Gatewayが出る原因、「別の更新が現在進行中です」の意味、今すぐ復旧する具体的手順、そして再発防止策まで、WordPress運用者全員に向けて実務目線でわかりやすく解説します。

WordPressアップデートでBad Gatewayが出るのはなぜ？

まず結論からいうと、WordPressアップデート中のBad Gatewayは、更新処理の途中でサーバー側の応答が止まった、またはタイムアウトしたときに発生しやすいです。

WordPressの更新では、ただボタンを押して終わりではありません。裏側では次のような処理が動いています。

• 更新ファイルのダウンロード
• ZIPファイルの展開
• 既存ファイルの上書き
• 必要に応じたデータベース更新
• 更新中の競合を避けるためのロック処理

これらの処理の途中で、PHPの実行時間制限やメモリ不足、サーバー負荷、通信不安定などが起きると、画面には 502 Bad Gateway やそれに近いエラーが表示されることがあります。

「別の更新が現在進行中です。」と出る原因

Bad Gatewayのあとに、WordPress管理画面で再び更新しようとしたとき、「別の更新が現在進行中です。」 と表示されることがあります。

これはWordPressが、更新中であることを示すロック情報を持っているためです。通常は更新が正常終了すれば自動的に解除されますが、途中で落ちるとロックだけ残ることがあります。

よく関係するのが、データベース内の core_updater.lock です。これが残っていると、WordPressは「まだ更新作業が終わっていない」と判断します。

Bad Gatewayの主な原因一覧

WordPressアップデートでBad Gatewayが起きる原因は1つとは限りません。実務では、いくつかの要因が重なって発生することも多いです。

原因	内容	起こりやすさ
PHP実行時間不足	max_execution_time が短く、更新処理が途中でタイムアウトする	かなり多い
メモリ不足	memory_limit が足りず、ZIP展開や更新処理で落ちる	かなり多い
サーバー高負荷	共用サーバーなどで一時的に負荷が高くなり応答不能になる	多い
ディスク容量不足	更新ファイルの展開領域が足りず失敗する	時々ある
ファイル権限の問題	WordPressが必要なファイルに書き込めない	時々ある
プラグイン干渉	セキュリティ系・キャッシュ系・バックアップ系などが更新処理に干渉する	よくある
.maintenance残存	更新失敗後にメンテナンスファイルが残り、サイトや管理画面に影響する	よくある
ロック残存	core_updater.lock が残り、再更新できなくなる	かなり多い

まず最初にやるべきこと

WordPress更新中にBad Gatewayが出たら、次の順番で進めると安全です。

1. まず1〜2分ほど待つ
2. サイト表示と管理画面の状態を確認する
3. .maintenance が残っていないか確認する
4. core_updater.lock を確認・解除する
5. PHP設定やメモリ設定を見直す
6. 必要なら手動更新に切り替える

.maintenance ファイルが残っていないか確認する

更新処理の途中で失敗すると、WordPressルートに .maintenance というファイルが残ることがあります。これが残っていると、メンテナンスモードが解除されず、サイトや管理画面に影響が出ることがあります。

.maintenance とは何か

WordPressは更新時に一時的にメンテナンスモードへ入り、その印として .maintenance を作成することがあります。正常終了すれば自動で消えますが、更新失敗時は残ることがあります。

確認場所

通常はWordPressのルートディレクトリ直下です。たとえば次のような場所です。

/public_html/.maintenance
/www/.maintenance
/wordpress/.maintenance

対処方法

FTPソフトやサーバーのファイルマネージャーで接続し、.maintenance が存在していたら削除します。

「別の更新が現在進行中です」を解除する方法

このメッセージの原因になりやすいのが、データベースの core_updater.lock です。これを削除することで、更新ロックを解除できる場合があります。

phpMyAdminで解除する手順

1. サーバーの phpMyAdmin にログインする
2. 対象のWordPressデータベースを選択する
3. wp_options テーブルを開く
   ※接頭辞が wp_ とは限らないため、実際のテーブル名に読み替えてください
4. option_name が core_updater.lock の行を探す
5. 該当行を削除する

SQLで削除する場合

接頭辞が wp_ の場合は、次のSQLで削除できます。

DELETE FROM wp_options WHERE option_name = 'core_updater.lock';

たとえば接頭辞が abc_ なら、テーブル名は abc_options に置き換えます。

PHP実行時間不足が原因の場合の対処方法

WordPressアップデートでBad Gatewayが出る原因として非常に多いのが、PHP実行時間不足です。つまり、更新処理が終わる前に、PHP側が「時間切れ」と判断して処理を打ち切ってしまうケースです。

このとき見直したいのが max_execution_time です。

max_execution_time とは

max_execution_time は、PHPスクリプトの最大実行時間を秒数で制限する設定です。たとえば 30 なら30秒を超えた時点で処理が打ち切られます。

WordPress本体更新や重いプラグイン更新では、30秒では足りない場合があります。共用サーバーや、ファイル数の多い環境、性能に余裕の少ない環境では特に起こりやすいです。

.htaccessで変更する方法

サーバーが許可している場合は、.htaccess に次のように記述します。

php_value max_execution_time 300
php_value memory_limit 256M

300秒、つまり5分まで実行可能にする設定です。

php.iniで変更する方法

サーバー管理画面やカスタムPHP設定で変更できる場合は、次のように設定します。

max_execution_time = 300
memory_limit = 256M

wp-config.phpで補助的に設定する方法

環境によっては wp-config.php に次のような設定を入れることもあります。

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');
@ini_set('max_execution_time', 300);
set_time_limit(300);

ただし、サーバー側で強く制限されている場合、wp-config.php 側だけでは反映されないこともあります。そのため、可能ならサーバー設定側を優先して見直すのが基本です。

メモリ不足が原因の場合の対処方法

WordPressアップデートで見落としやすいのがメモリ不足です。更新時は単なる画面表示よりも多くの処理を行うため、通常閲覧時は問題なくても、更新時だけ落ちることがあります。

memory_limit を見直す

PHPのメモリ上限である memory_limit が低いと、更新ファイルの展開や置き換えでエラーになりやすくなります。

設定例は次の通りです。

memory_limit = 256M

WordPress側でも補助的に、次のように設定することがあります。

define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '256M');

メモリ不足で起きやすい症状

• 更新開始後にBad Gatewayになる
• 管理画面が途中で真っ白になる
• プラグイン更新だけ異常に失敗しやすい
• エラーログに Allowed memory size exhausted 系のメッセージが出る

サーバーのエラーログを確認する

Bad Gatewayは画面上だとざっくりしたエラーに見えますが、サーバーのエラーログを見ると原因が見えてくることがあります。

たとえば、次のようなキーワードがログに出ていないか確認してみてください。

• Maximum execution time exceeded
• Allowed memory size exhausted
• Premature end of script headers
• upstream timed out
• mod_fcgid: read data timeout
• 502 Bad Gateway

ディスク容量不足やファイル権限も確認する

意外と見落としやすいのが、ディスク容量不足やファイル権限の問題です。

ディスク容量不足

更新時は一時的にファイルをダウンロード・展開するため、空き容量が少ないと失敗することがあります。特にバックアップファイル、キャッシュファイル、古いログファイルが大量に残っていると危険です。

ファイル権限の問題

WordPressが必要な場所に書き込めないと、更新途中で止まることがあります。たとえば、wp-admin や wp-includes、wp-content/upgrade まわりに問題があると失敗しやすくなります。

チェックしたい場所

• wp-content/upgrade に更新残骸が溜まっていないか
• サーバー容量がいっぱいになっていないか
• 更新対象ファイルに書き込み権限があるか

プラグインやテーマが干渉している場合

セキュリティ系、キャッシュ系、最適化系、バックアップ系のプラグインは、更新時に干渉することがあります。また、古いテーマや独自カスタマイズされたテーマも、更新中の動作に影響する場合があります。

疑うべきケース

• 特定のプラグイン更新だけ毎回失敗する
• キャッシュ削除後はうまくいくことがある
• セキュリティ系プラグイン導入後に更新トラブルが増えた
• WAFやサーバーセキュリティ設定が強め

対処の考え方

安全に切り分けたいなら、まずロックやメンテナンス状態を解消したうえで、必要に応じてキャッシュ系やセキュリティ系プラグインを一時停止し、再度更新を試します。

WordPressアップデート失敗時の安全な復旧手順

ここでは、Bad Gatewayと「別の更新が現在進行中です。」が出たときに、実務でおすすめしやすい復旧手順をまとめます。

手順1：まず数分待つ

本当に処理がまだ裏で続いている可能性もゼロではありません。まずは1〜2分程度待ってから再確認します。

手順2：サイト表示と管理画面の状態を確認する

サイト全体が落ちているのか、更新画面だけ問題なのかを切り分けます。

手順3：.maintenance を削除する

FTPまたはファイルマネージャーでWordPressルートを確認し、.maintenance が残っていれば削除します。

手順4：core_updater.lock を削除する

phpMyAdminなどで core_updater.lock を削除し、更新ロックを解除します。

手順5：PHP設定を見直す

max_execution_time と memory_limit を確認し、必要なら引き上げます。

手順6：再度アップデートを試す

ここまで整えてから、改めて更新します。

手順7：まだダメなら手動更新に切り替える

自動更新にこだわらず、手動更新へ切り替えると安定することがあります。

どうしても管理画面から更新できないときは手動更新する

レンタルサーバー環境や、重めのWordPress環境では、管理画面からの更新が不安定なことがあります。何度もBad Gatewayになるなら、FTPやファイルマネージャーでの手動更新のほうが確実な場合もあります。

WordPress本体を手動更新する基本手順

1. 必ず事前にバックアップを取る
2. WordPress公式サイトから最新版をダウンロードする
3. ZIPを展開する
4. wp-admin と wp-includes を上書きする
5. ルート直下のWordPress本体ファイルも必要に応じて上書きする
6. wp-content、wp-config.php、.htaccess は基本的にそのまま残す

上書き時に基本的に消さないもの

wp-content
wp-config.php
.htaccess

プラグインの手動更新も、基本的には対象プラグインのディレクトリを更新する流れになりますが、設定やデータ保持の仕組みはプラグインごとに異なるため、必ず事前バックアップを取ってから実施してください。

再発防止のために見直したいポイント

一度復旧して終わりではなく、次回も同じことが起きないように運用を整えておくのが大切です。

1. 更新前にバックアップを取る

WordPress本体、データベース、必要ならアップロードファイルを含めて、更新前バックアップを習慣化しましょう。万一のとき、復元できる安心感が段違いです。

2. 本番サイトでいきなり大更新しない

本体、プラグイン、テーマを一気に大量更新すると、トラブル発生時の切り分けが難しくなります。可能なら少しずつ更新し、特に大きなバージョンアップは検証環境で確認してから本番へ進めるのが理想です。

3. PHP設定を最低限見直しておく

運用に余裕を持たせるなら、次の設定は一度確認しておきたいところです。

max_execution_time = 300
memory_limit = 256M

4. 不要なプラグインを減らす

使っていないプラグイン、長年更新されていないプラグイン、役割が重複しているプラグインは、トラブルの火種になりやすいです。定期的に整理しましょう。

5. ディスク容量とログを定期確認する

容量不足は地味ですが、更新失敗の原因になります。特にバックアップファイルやキャッシュ、ログの肥大化には注意が必要です。

6. WordPress本体・テーマ・プラグインの更新タイミングを分ける

本体更新、テーマ更新、プラグイン更新を同日にまとめて全部やると、もし問題が起きたときに原因追跡が大変になります。可能なら日や時間を分けて、変化点を小さく管理するのがおすすめです。

WordPress運用者が知っておきたい実務的な考え方

WordPressの更新トラブルは、初心者だけの問題ではありません。経験者でも、サーバー環境や一時的な負荷、プラグインの相性などで普通に遭遇します。

そのため大事なのは、トラブルをゼロにすることではなく、起きたときに落ち着いて復旧できる運用にしておくことです。

• バックアップ手段がある
• FTPやファイルマネージャーに入れる
• phpMyAdminに入れる
• エラーログを確認できる
• サーバーのPHP設定を調整できる

このあたりが整っているだけで、WordPress運用の安心感はかなり変わります。

よくある質問

Bad Gatewayが一度出たあと、サイトは表示されるのに更新だけできません。何が起きていますか？

更新処理自体は失敗したものの、サイト閲覧に必要な主要ファイルは生きている状態だと考えられます。このときは core_updater.lock や .maintenance の残存を疑うとよいです。

「別の更新が現在進行中です。」は待てば消えますか？

正常な更新処理であれば時間経過で解消することもありますが、Bad Gateway後に出ている場合はロック残りの可能性が高いため、core_updater.lock の確認をおすすめします。

max_execution_time を長くしすぎるのは危険ですか？

必要以上に極端な値へ上げるより、まずは 300 秒程度で様子を見るのが無難です。そもそも更新が重い原因を別に抱えている場合、時間だけ伸ばしても根本解決にならないことがあります。

wp-config.php だけで直せますか？

環境によります。サーバー設定が優先される場合は、wp-config.php の設定だけでは不十分なことがあります。できればサーバー側のPHP設定も確認してください。

まとめ｜WordPressアップデートでBad Gatewayが出ても、順番に対処すれば落ち着いて直せる

WordPressアップデート中のBad Gatewayは、見た目ほど珍しい事故ではありません。そして、再度更新しようとしたときに出る 「別の更新が現在進行中です。」 も、更新ロックが残っているだけのことが多いです。

今回のポイントを整理すると、次の通りです。

• Bad Gatewayは更新処理中のタイムアウトやサーバー応答不良で起きやすい
• 更新失敗後は .maintenance と core_updater.lock を確認する
• max_execution_time と memory_limit は見直し価値が高い
• サーバーログを見ると原因特定が早い
• 管理画面更新が不安定なら手動更新も有効
• バックアップ、段階更新、環境確認が再発防止に効く

WordPressは便利ですが、更新処理はサイト運用の中でも意外と事故が起きやすい場面です。だからこそ、ただ更新するだけではなく、トラブル時の復旧パターンを知っていることが運用者として大きな強みになります。もし今まさに困っているなら、まずは .maintenance と core_updater.lock、そして max_execution_time の3点から確認してみてください。

　
※参考にされる場合は自己責任でお願いします。