WordPress安心診断 by MozCheck

「更新に失敗しました／公開に失敗しました」―プラグイン更新エラーの対処法まとめ

Written by

Yudai Tsuyuzaki

in

WordPressの更新ボタンを押しただけなのに、「更新に失敗しました」や「公開に失敗しました」が唐突に現れて作業が止まる——。

とくにプラグインの更新時はサイト全体の挙動に関わるため、不安も大きくなります。

結論から言えば、この種のエラーは“ひとつの原因”で起きるわけではありません。多くは次のどれか（または複合）です。

  • REST API がブロックされている（WAF／ファイアウォール、Basic認証、CORS など）
  • キャッシュ／CDNやセキュリティ機能の干渉
  • ファイル権限・所有者の不整合、ディレクトリ作成不可
  • ディスク容量不足や /tmp の枯渇
  • PHP 設定不足（memory_limit・max_execution_time など）やタイムアウト／cURLエラー
  • メンテナンスモード固着やアップデータのロック

本記事は、こうした「プラグイン更新での更新／公開エラー」を短時間で切り分け、確実に復旧するための実践ガイドです。

まずは5分で試せる即効チェックをまとめ、現場でそのまま使える手順で整理しました。

難しいコマンドを覚えていなくても大丈夫。

バックアップを前提に、順番どおりにチェックすれば、ほとんどのケースは落ち着いて復旧できます。

制作会社・運用担当・個人サイトのどの立場でも役立つ“現場用チートシート”としてお使いください。

目次

症状の把握とスコープを確認する

表示されるメッセージの種類（「更新に失敗しました」「公開に失敗しました」「現在オフラインのようです」など）

最初にメッセージの文言を正確に控えます。
「更新に失敗しました」は更新処理のどこかで失敗、「公開に失敗しました」は編集画面の通信（REST API）や権限が疑わしいサイン、「現在オフラインのようです」は接続断・WAF・認証の可能性が高い合図です。
「Allowed memory size exhausted」「cURL error 28」「ディレクトリを作成できませんでした」など固有語があれば、後続の切り分けが一気に進みます。

どの操作で発生するか（プラグイン更新／投稿公開／特定プラグインのみ／全体）

発生場面を最小単位で再現します。

  • すべてのプラグインで発生するか
  • 特定のプラグインだけか
  • 投稿の公開・更新でも出るか
  • いつから出たか（直前の変更は何か）

これにより、**REST API 起因（全体）**か、**ファイル／権限起因（特定）**かの目星がつきます。

影響範囲（管理画面のみ／フロントも影響）と再現手順の整理

管理画面だけでエラーなら認証・CSRF・WAF、フロントも不安定ならキャッシュやPHP設定の疑い。
再現手順は「どの画面で」「何を押すと」「何秒後に」「何色のバナーで」まで書き出すと、後でログ照合が容易です。

作業前の安全対策（バックアップ・ステージング・メンテナンス告知）

いきなり大手術は禁物です。

  • バックアップ（DB＋wp-content）
  • 変更はステージングで先に検証
  • 作業中はメンテナンス告知や時間帯調整
  • 現状の有効プラグイン／テーマ一覧とサイトヘルスのスクショを保存

「現在の状態を記録→小さく変更→結果を確認」のリズムを徹底しましょう。

まず試す即効チェック（5分で確認）

ブラウザ更新・再ログイン・キャッシュ削除・nonceエラー回避

  • ブラウザのシークレットウィンドウで再ログイン
  • ログアウト→ログインで資格情報を更新
  • ブラウザ／プラグインのキャッシュ削除
  • 別ユーザー権限（管理者）で再現確認
  • 編集画面を長時間開いた後の送信失敗＝nonce期限切れの可能性。いったん再読み込みしてから更新を実行

これだけで復旧するケースは意外と多く、根本要因の切り分けにも役立ちます。

プラグイン／テーマのキャッシュ機能とCDNの一時無効化

ページキャッシュ、ミニファイ、遅延読み込み、オブジェクトキャッシュ、CDN／WAFのキャッシュは更新処理と相性が悪いことがあります。

  • 主要キャッシュ系（例：ページ／オブジェクト）を一時停止
  • CDNの開発モードやキャッシュ無効化で挙動を確認
  • クリア後に管理画面だけリロードして挙動を再確認

副作用を最小にするため、停止→確認→元に戻すの順で。

同時更新の回避・更新順の最適化（コア→プラグイン→テーマ）

一括更新は避け、1件ずつ実行します。

  • 順序はWordPressコア → プラグイン → テーマ
  • セキュリティ系／キャッシュ系は最後に回す
  • 複数ユーザーが同時作業しないようロックを意識

「another update is currently in progress」が出る場合は時間を置くか、後述の手順でロック解除を行います。
まずは軽微な対処で回復するかを見極め、重い調査（REST/WAFやPHP設定）に進みます。

REST APIとWAF／ファイアウォールを点検

Site HealthでREST APIの到達性を確認する

「サイトヘルス（ツール → サイトヘルス）」のステータスに「REST API が正しく動作していません」等の警告がないか確認します。
同時に https://example.com/wp-json/ を直接開き、JSONが返るかを手早くテスト。
403/401/404/タイムアウトのいずれかなら、WAF・認証・CORS・リライトルールの線が濃くなります。
投稿画面での「公開に失敗しました」は編集画面と REST API が通信できていない合図。プラグイン更新エラーでも、この裏側の通信が詰まっていることが多いです。

WAF／CDN／ModSecurityの除外設定と一時無効化

サーバーWAFや ModSecurity、CDN（例：Cloudflare）のセキュリティルールがRESTや更新リクエストをブロックしているケースは頻出します。

  • 一時的にWAFを無効化、または除外ルールに /wp-json/ と /wp-admin/admin-ajax.php を登録
  • CDNは開発モードやキャッシュ無効化で挙動を確認
  • ブロックログ（WAFログ）に該当リクエストが記録されていないかを照合

結果が改善するなら、恒久対応として特定パスの除外やレベルの調整を行います。

認証・CORS・IP制限・Bot対策の影響を洗う

  • Basic認証やIP制限、Bot対策プラグインはREST APIの通信を阻害しがち
  • 管理画面だけBasic認証をかけている場合、Application Passwordsや認証ヘッダの引き継ぎに注意
  • CORS設定の誤りで管理画面→REST APIの通信が弾かれることも

まずはすべての遮断要素を一時停止→改善確認→最小限の除外で再度堅牢化、の順で進めると安全です。

サーバー／ファイルまわりの原因を洗う

パーミッションと所有者（755/644、所有者www-data等）

プラグイン更新で「ディレクトリを作成できませんでした」「書き込みできません」系は権限と所有者が原因です。

  • 目安はディレクトリ755／ファイル644、実行ユーザー（例：www-data）が所有者
  • wp-content/ 配下（plugins/、upgrade/）の権限を重点確認
  • オーナー不整合（SFTPで別ユーザーが作成）も失敗要因

権限を安易に777にはせず、所有者の是正＋適正権限で対応します。

ディスク容量・/tmp・open_basedir制限

容量不足や一時ディレクトリの枯渇は更新の天敵。

  • ディスク空き（サーバーの利用量／ログ肥大）
  • PHPの**upload_tmp_dir、システムの/tmp** が書き込み可能か
  • open_basedir で書き込み先が制限されていないか

プラグイン更新は一時的に大きなファイル展開が走るため、余裕を持った空き容量を確保しましょう。

PHP設定（memory_limit／max_execution_time／max_input_vars）

更新がタイムアウトやメモリ不足で途切れることは珍しくありません。

  • memory_limit は 256M〜512M を目安に増量
  • max_execution_time は 60〜120秒 程度に引き上げ
  • 大規模サイトは max_input_vars（メニューやウィジェット多用時）も見直し

wp-config.php の WP_MEMORY_LIMIT だけでなく、サーバー側のPHP設定も合わせて調整するのがコツです。

更新プロセス特有のつまずきに対処

メンテナンスモード固着（.maintenance の削除）

更新途中で中断するとメンテナンスモードが解除されないことがあります。
WordPress をメンテナンスしています… の表示や、更新が始まってすぐ戻る症状が目安。

  • サイトルートの**.maintenance を削除**
  • その後、キャッシュを全てパージして再確認

これで復帰しない場合は、次項のロックや権限も併せて点検します。

「another update is currently in progress」の解除

コアの更新ロックが残っていると、他の更新が待たされ続けることがあります。

  • 時間を置く（通常は数十分で解放）
  • WP-CLI で wp option delete core_updater.lock
  • もしくはDBの wp_options から core_updater.lock を削除

解除後に個別更新→全体の順で慎重に再開します。

cURL error 28／タイムアウト／DNS遅延の切り分け

外部APIや公式配布サーバーへの接続が遅延・遮断されると発生。

  • サーバーのDNS解決（/etc/resolv.conf）やIPv6/IPv4優先を確認
  • アウトバウンドのファイアウォール／プロキシ設定を点検
  • 一時的にCDNやセキュリティプラグインをオフにして再試行

サーバー側の名前解決や接続性能の問題は表面上「WordPressの問題」に見えるため、ネットワーク視点での切り分けが有効です。

ログとデバッグで原因を特定する

WP_DEBUG／デバッグログの有効化と読み方

wp-config.php に以下を設定し、画面表示は抑止してログへ出力します。
WP_DEBUG、WP_DEBUG_LOG を true、WP_DEBUG_DISPLAY を false。
ログは通常 wp-content/debug.log に出力。
発生時刻と同時刻のスタックトレースを追うだけで、メモリ不足・関数未定義・権限拒否などが特定できます。

Webサーバー／PHP-FPM／WAFログの照合

  • Apache/Nginxのerror.log、PHP-FPMのログ
  • WAFのブロックログ（ルールID、リクエストURI）
  • CDNのファイアウォールイベント

「どのURIに」「どの応答コードで」「何秒かかったか」を突き合わせ、ボトルネックの実体を掴みます。

バージョン互換性（WordPress／PHP／プラグイン）の突合

更新失敗後に致命的エラーが発生する場合、PHPバージョン非対応や依存関係の齟齬も疑います。

  • プラグインの対応PHP/WordPressバージョン
  • 直近でPHPを上げた／下げた履歴
  • 依存プラグインの先行更新が必要か

互換性は作者のリリースノートも含め、必ず確認しましょう。

復旧とロールバックの実践

バックアップからの復元と差分リストア

サイト全体のリストアがベストですが、影響を最小化したい場合は差分復元を検討。

  • 該当プラグインのディレクトリのみ復元
  • 直前のDBスナップショットから関連オプションのみ戻す

復旧後はキャッシュ削除→動作確認→ログ確認までが一連のセットです。

プラグインの手動更新（FTP／WP-CLI）と破損ファイルの置換

自動更新で失敗する場合、手動更新が確実です。

  • FTPで該当プラグインを一旦リネーム→新バージョンをアップ→有効化
  • WP-CLI なら wp plugin install <slug> --force で上書き再インストール
  • 依存関係のあるアドオンは順序を意識して段階更新

破損ファイルをクリーン置換できる点が手動の強みです。

代替プラグインへの退避・段階的再導入と検証

更新後に不具合が残る場合は、代替プラグインで一時退避しつつ、検証環境で再現→原因特定。
設定移行やショートコード差し替えを段階的に行い、ダウンタイムを抑えます。

最後に：再発防止の運用ベストプラクティス

ステージング環境・段階更新・監視（アラート）設計

本番直更新は避け、ステージングで検証→本番反映を基本に。

  • 段階更新（コア→プラグイン→テーマ）
  • Uptime監視／ログ監視で異常を早期検知
  • 失敗時のロールバック手順をドキュメント化

セキュリティ／キャッシュ／バックアップ運用の見直しチェックリスト

  • WAF／CDNは管理用エンドポイントを除外
  • キャッシュは更新時の自動パージを構成
  • 日次バックアップ＋世代管理、復元テストを定期実施
  • PHPバージョンのサポート期間とプラグイン互換性を定期棚卸し

チーム運用と変更管理

複数人での同時作業で事故は起きます。

  • 更新ウィンドウと担当者を明確化
  • **変更履歴（いつ／誰が／何を）**を記録
  • 重大更新は事前告知→検証→反映→確認の4点セットで運用

小さなルールの積み重ねが、更新エラーの再発ゼロに直結します。

参考・参照リンク

関連記事

  1. 初心者向け！WordPressのバックアップと復元の基本ステップと注意点
  2. あれ、サイトの見た目が変…？WordPressの「表示が崩れた！」ときの原因と対処法
  3. WordPressが突然真っ白に…よくある原因とすぐできる対処法
  4. 【2025年版】WordPressにログインできないときの完全ガイド｜原因別エラー対処と最短復旧フローチャート

投稿者

Yudai Tsuyuzaki

フリーランスのWeb系プログラマー。 長野県の北アルプス地方在住

🛠️ WordPressのトラブルでお困りですか？

ログインが出来ない・白画面・更新崩れなどの緊急トラブルは、
「WordPress保守サービス」で即対応いたします。

今すぐ依頼する（ランサーズページへ）

🧰 WordPress無料診断

サイト改善の第一歩をお届け

当サイト「MozCheck」は、WordPressサイトの不安をチェックできる無料診断サービスです。
URLを入力するだけ。登録不要、すぐに診断結果が表示されます。

無料で診断する

コメント

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA


More posts