WordPress 2025.12.11

WordPress自動更新で本番サイトが壊れた！安全な更新運用と復旧手順

約7分で読めます

WordPress自動更新でサイトが表示されなくなった経験はありませんか？本番環境での安全な更新手順と、トラブル発生時の迅速な復旧方法を実案件の経験をもとに解説します。

こんな悩みありませんか？

  • 朝、会社に来たらWordPressサイトが真っ白になっていた
  • 自動更新が走って、プラグインの競合でサイトが表示されない
  • 更新後にお問い合わせフォームが動かなくなった
  • 「どこから手をつけていいかわからない」と途方に暮れている

実は、弊社にも月に2〜3件は「サイトが壊れて困っている」というSOSの連絡が入ります。多くの場合、WordPress本体やプラグインの自動更新が原因です。

実際にあったトラブル事例

先月、横浜の製造業のお客様から緊急の連絡がありました。

「サイトにアクセスすると『Fatal error』というエラーが表示されて、まったく見られない状況です。昨日までは正常だったのに...」

調査すると、WordPress 6.4への自動更新と同時に、古いプラグインが動作しなくなったことが原因でした。このお客様は年間約200件の問い合わせを獲得する重要なサイトだったため、1日でも止まると大きな機会損失になります。

結果的に3時間で復旧しましたが、適切な更新手順があれば防げたトラブルでした。

緊急時の復旧手順（まず最初にやること）

1. 状況の確認

# FTPまたはcPanelでサイトにアクセス
# wp-config.phpでデバッグモードを有効化
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

2. プラグインの一時停止

最も効果的な応急処置です：

# FTPで /wp-content/plugins/ フォルダ名を変更
plugins → plugins_backup

これで全プラグインが無効化され、多くの場合サイトが復旧します。

3. テーマの確認

# /wp-content/themes/ で現在のテーマフォルダ名を変更
active-theme → active-theme_backup

4. バックアップからの復元

定期バックアップがある場合は、直近の正常な状態に戻します。

安全な更新運用の構築（根本解決）

上記のお客様には、トラブル解決後に以下の運用体制を構築しました。結果として、その後1年間、更新関連のトラブルは0件になっています。

ステージング環境での事前テスト

// wp-config.phpでステージング環境を識別
if (strpos($_SERVER['HTTP_HOST'], 'staging') !== false) {
    define('WP_DEBUG', true);
    define('STAGING_SITE', true);
}

運用フロー：

  1. ステージング環境で更新実行
  2. 48時間の動作確認
  3. 問題なければ本番環境で更新

自動更新の適切な設定

// wp-config.phpに追加
// WordPress本体の自動更新を無効化
define('WP_AUTO_UPDATE_CORE', false);

// プラグインの自動更新を選択的に制御
add_filter('auto_update_plugin', function($update, $item) {
    // 信頼性の高いプラグインのみ自動更新を許可
    $allowed_plugins = [
        'akismet/akismet.php',
        'hello-dolly/hello.php'
    ];
    
    return in_array($item->plugin, $allowed_plugins);
}, 10, 2);

バックアップの自動化

#!/bin/bash
# 更新前の自動バックアップスクリプト
BACKUP_DIR="/path/to/backup/$(date +%Y%m%d_%H%M%S)"
mkdir -p $BACKUP_DIR

# ファイルのバックアップ
tar -czf $BACKUP_DIR/files.tar.gz /path/to/wordpress/

# データベースのバックアップ
mysqldump -u username -p database_name > $BACKUP_DIR/database.sql

よくある失敗パターンと対策

20年の経験で見てきた「やりがちなミス」をご紹介します：

1. テスト環境なしで本番更新

失敗例： 「小さなサイトだからテスト環境は不要」 結果： マイナーな更新でも予期しない不具合 対策： サブドメインでも良いので必ずテスト環境を作る

2. 複数項目の同時更新

失敗例： WordPress本体 + 10個のプラグインを一度に更新 結果： 問題の原因特定に時間がかかる 対策： 1つずつ更新し、動作確認を行う

3. バックアップの取得忘れ

失敗例： 「いつものことだから大丈夫」 結果： 完全復旧まで数日を要する 対策： 更新前バックアップを必須タスク化

更新後の成果測定も重要

適切な更新運用により、お客様が得られた成果：

  • ダウンタイム：月3〜4時間 → 0時間
  • セキュリティレベルの向上（脆弱性対応の迅速化）
  • サイト速度の改善（最新版の性能向上を享受）
  • Web担当者の精神的負担軽減

特に最後の点は重要で、「いつサイトが止まるかわからない不安」がなくなったことで、本来の業務に集中できるようになったとのフィードバックをいただいています。

今日から始める安全な更新運用

まず最初にやるべきこと（今日中）：

  1. 現在のバックアップ状況を確認

    • 最終バックアップ日時をチェック
    • 復元テストの実施

  2. 自動更新設定の見直し

    • 現在の自動更新設定を確認
    • リスクの高いプラグインの自動更新を無効化

  3. 緊急連絡先の整備

    • 技術サポート先の連絡先を整理
    • 復旧手順書の作成

1週間以内にやること：

  • ステージング環境の構築
  • 更新スケジュールの策定
  • 動作確認チェックリストの作成

まとめ

WordPressの更新は避けて通れない作業ですが、適切な手順と体制があれば安全かつ効率的に実施できます。

トラブルが発生してからの対応では、時間的・金銭的コストが大きくなります。平時からの備えが、サイト運営の安定性と事業継続性を支えます。

「更新作業が不安」「トラブル対応に追われたくない」とお感じでしたら、お気軽にご相談ください。20年の実績をもとに、お客様の環境に最適な運用体制をご提案いたします。

この記事をシェア

関連記事

ブログ一覧に戻る