「テーマを更新したらデザインが崩れた」「カスタムが消えた」──そんな不安がある一方で、更新を放置すればセキュリティや互換性のリスクが確実に積み上がります。
本記事は「安全にアップデートして、崩れもカスタム消失も起こさない」ための実践ガイドです。WordPress 5.5以降のZIP置き換えや自動更新にも対応し、ダッシュボード更新・FTP手動更新・プレミアムテーマ特有の注意点まで、現場で役立つ手順と判断基準をまとめました。
とくに多いトラブルは「何が上書きされ、何が残るのか」を誤解しているケースです。
本記事では失われる設定／失われない設定の線引きを先に示し、子テーマとスニペット運用へ移行することで再発を防ぐ方法まで踏み込みます。さらに、すぐ戻せるロールバック戦略を用意しました。
本記事で得られること：
- 更新前チェックリストで準備漏れゼロ
- 安全な更新手順（ダッシュボード／ZIP置き換え／FTP）
- 更新後チェックと崩れ診断フロー
- 子テーマ＆スニペットで“直編集卒業”
- 復旧と再発防止のベストプラクティス
初心者でも迷わず、実務者でもそのまま現場の手順にできる内容です。最小の手間で最大の安全性を確保し、“更新して良かった”を当たり前にしていきましょう。
テーマ更新で何が起きる？失われるもの・残るもの
まず「どの情報がどこに保存されているか」を押さえておくと、更新時の想定外を避けられます。WordPressではデータベースに保存されるものは基本的に残り、テーマフォルダ内のファイルに直接書いたものは上書きされるのが原則です。
失われない（= データベース保存の項目）
- **外観 → カスタマイズ（カスタマイザー）**の設定
サイト基本情報、色・ロゴ、ウィジェット領域の割り当てなど。
※テーマの大幅な仕様変更により一部項目名や構造が変わると、再設定が必要になる場合はあります。 - 外観 → メニューの内容と、メニューの割り当て
メニュー自体は残りますが、「メニューの位置」側の呼び名が変わると紐付けが外れることがあります。 - ウィジェットの中身（テキスト、HTML、ショートコードなど）
テーマ側のウィジェットエリア（サイドバー/フッター）名称が変わると、再配置が必要。 - 追加CSS（外観 → カスタマイズ → 追加CSS）
テーマ更新で上書きされません。 - サイトの投稿・固定ページ・メディア・設定全般
テーマ更新の対象外です。
失われる（= テーマフォルダの上書き対象）
- 親テーマのファイルに直接書いた変更
functions.php、style.css、各種テンプレート（header.php、single.phpなど）、/template-parts/、/inc/内の編集は更新で上書きされ消えます。 - 親テーマのカスタムJS/CSSファイル
assets/js/*.js、assets/css/*.cssなどに直接追記した場合も同様。 - テーマ内に置いた翻訳ファイル（.po/.mo）
テーマ側の言語フォルダに入れていると上書き対象。/wp-content/languages/themes/側を優先する運用が安全。
結論：親テーマ直編集は厳禁。変更は子テーマに移すか、Code Snippets/WPCode系プラグイン・追加CSSなどデータベース保存の経路に逃がしておくと、更新しても消えません。
更新前チェックリスト（崩れゼロの準備）
更新は“準備8割”。以下のチェックを上から順に済ませれば、ほぼノートラブルで通せます。
バックアップ（ロールバック手段の確保）
- ファイル＋データベースの完全バックアップ
ホスティングのスナップショット機能、またはバックアッププラグイン（例：UpdraftPlus/BackWPup系）で取得。 - 復元テストの有無
いざという時に戻せるか、復元手順の確認だけでも行っておく。 - 更新対象バージョンの控え
現在のテーマバージョン、WordPressコア、PHPバージョン、主要プラグインのバージョンをメモ。
ステージング環境での事前検証
- 本番の複製（ステージング）で先に試す
テーマ更新 → 画面確認 → 機能確認（検索、フォーム、ECのカート/決済など）。 - キャッシュと最適化の無効化
確認前にページキャッシュ/ミニファイ/CDNを一時停止して挙動を正しく見る。
変更差分の棚卸し（直編集の撤去）
- 親テーマに手を入れていないか総点検
git diff、ホスティングのファイルマネージャ比較、日時が新しいファイルの洗い出し。 - 差分は子テーマ/スニペットへ移行
- PHPの追記 → Code Snippets/WPCode へ移行（有効/無効の切替も容易）。
- CSSの追記 → 追加CSSか子テーマ
style.cssへ。 - テンプレートの上書き → 子テーマに該当ファイルをコピーして編集。
- プレミアムテーマのライセンス/更新キー
有効期限切れだと更新通知が出ず手動更新が必要。ログイン情報を確認。
運用上の段取り
- アクセスの少ない時間帯に実施（EC/会員サイトは特に重要）
- メンテナンスモードの準備（短時間で終える場合は不要でも、長引く可能性があるならON）
- 担当者と合意したテスト観点リスト
ヘッダー/フッター/ナビ、トップ/記事/検索/カテゴリ、フォーム、EC、会員機能、Lighthouseの簡易チェック、主要ブラウザ表示など。
WordPress 5.5以降の安全な更新手順
更新方法は大きく3通り：①ダッシュボードの通常更新、②ZIP置き換え（5.5+）、③FTP手動更新。まずは①→②の順で検討し、特殊事情がある場合のみ③へ。
ダッシュボードでの通常更新（推奨）
- キャッシュ/最適化/CDNを一時停止
WP Rocket、LiteSpeed Cache、Cloudflare など。 - ダッシュボード → 更新 または 外観 → テーマ へ
対象テーマに「新しいバージョンがあります」と表示されていれば更新をクリック。 - 更新完了後の確認
- 表示崩れ：ヘッダー/フッター/記事/アーカイブ/検索/固定ページ
- 機能：フォーム送信、検索、カテゴリー絞り込み
- コンソールエラー：ブラウザ開発者ツールでJSエラーがないか
- メニュー/ウィジェットの割り当てが外れていないか
- キャッシュ再有効化 → 再確認
表示に問題がなければキャッシュ系を戻す。CDNのキャッシュパージも忘れずに。
ZIP置き換え更新（5.5以降）
同じテーマ名のZIPをアップロード→“置き換え”を選ぶだけで、ダッシュボードから安全に上書きできます。親テーマ直編集がある場合は必ず移行してから。
- テーマの公式サイト/配布元から最新ZIPを入手。
- 外観 → テーマ → 新規追加 → テーマのアップロード
- ZIPを選択 → 現在のテーマを置き換える を選び実行。
- 完了後、前節の確認項目を同様にチェック。
自動更新の有効化/無効化（運用ルール）
- 外観 → テーマ の一覧で、各テーマの自動更新のON/OFFを切り替え可能。
- 推奨運用：本番は原則OFF、ステージング/検証用でONにし、問題なしを確認→本番に反映。
- 通知メール：自動更新の実行や失敗を通知するメールが届く設定の場合あり。見落とさない運用フローを。
ポイント：自動更新は「小規模サイト」「影響範囲が限定的」「子テーマ＆スニペット運用が徹底されている」環境でのみ有効化を検討。それ以外は手動で計画反映が安全です。
ダッシュボードで更新できない場合（プレミアム/カスタム/改造テーマ）
テーマ配布元の独自アップデータやライセンス連携が必要だったり、ダッシュボード更新に失敗するケースでは**手動更新（FTP/SFTP）**に切り替えます。手順は慎重に、必ずバックアップを取ってから作業しましょう。
FTPでの手動更新（安全な置き換え手順）
- 最新ZIPを配布元から取得（ライセンス/会員エリアを確認）。
- ローカルで解凍 → フォルダ名を確認（テーマの“スラッグ名”が親テーマと一致していること）。
- サーバー接続（SFTP/SSH推奨） →
/wp-content/themes/へ。 - 既存テーマフォルダを一時リネーム
例：themename→themename_backup_2025-09-02（即時ロールバックが容易）。 - 新フォルダをアップロード（権限は通常
755/644）。 - 管理画面 → 外観 → テーマで有効化されているか確認（子テーマ運用なら親は“インストール済み”のままでOK）。
- 問題なしを確認後、バックアップフォルダを削除（容量節約）。
注意：親テーマのフォルダ名を変えると子テーマの紐付けが切れます。スラッグ名は同じにしてください。
メンテナンスモードと作業時間
- 表示影響を最小化するため、アクセスの少ない時間帯に実施。
- 作業が長引く場合のみ、メンテナンスモード（プラグイン or
.maintenance）で一時的に案内を出しておくと安全。
ライセンス・付帯プラグインの再認証
- テーマによっては更新後にライセンス再認証が必要。会員情報・APIキー・ドメイン紐付けを用意。
- 同梱のページビルダー/必須プラグイン（例：スライダー、フォーム、ACF Proなど）がある場合は、同時更新で整合性を取る。
更新後に崩れた時の原因診断フロー
上から順にチェックすると切り分けが速く、ムダがありません。
1. キャッシュ・最適化・CDNの影響を除外
- ブラウザのハードリロード（キャッシュ消去後の再読み込み）。
- キャッシュ系プラグインを一時停止 → 全削除（パージ）。
- CDN（Cloudflare等）のキャッシュを全削除。
- ミニファイ/結合機能をOFFにして、CSS/JSの読み順を素の状態に。
2. メニュー・ウィジェット・カスタマイザーの再割当
- テーマのメニュー位置名やウィジェットエリア名が変わると紐付けが外れることがあります。
- 外観各画面で割当の再設定を確認。
3. WooCommerceなどテンプレート互換
- ステータス画面でテンプレートの互換性を確認。
- テーマ側のテンプレートオーバーライド（
woocommerce/配下など）を更新し、子テーマ上書きがあれば差分を見直し。
4. JS/CSSエラーの確認
- ブラウザのコンソールで赤エラーを確認（404, TypeError, SyntaxErrorなど）。
- エラーの出ているファイルがミニファイ版なら、非ミニファイへ切り替えて原因を特定。
- テーマのアセット再生成（ビルダー系テーマに多い）を実行。
5. プラグイン競合の切り分け
- 全停止 → 重要なものだけ段階的に有効化。
- 再現したタイミングで競合候補を特定し、代替プラグイン/設定変更を検討。
6. PHPレベルの不整合
WP_DEBUG_LOGを有効化してエラーログを確認（PHPバージョン互換性もチェック）。- 親テーマ直編集が消えた疑いがある場合は、バックアップと差分比較を実施。
7. パーミッション/所有権
- テーマ配下の権限（通常 755/644）と所有者を確認。読み込み不可や403でCSSが当たらないことがあります。
NG対応：親テーマに再び直接書く“応急処置”。直後は直っても次の更新でまた消えるため、子テーマ or スニペットへ移行を。
再発防止：子テーマ＆スニペット運用のベストプラクティス
子テーマの基本
style.cssのヘッダーにTemplate: 親テーマのスラッグを記述。functions.phpは最小限のエンキューから。機能追加はスニペット側へ分離。- テンプレート改変は必要ファイルのみ子テーマへコピーして差分管理。
スニペット運用（Code Snippets / WPCode など）
- 目的別にスニペットを分割（表示/管理画面/SEO/短縮コードなど）。
- 無効化で即座に切り戻し可。トラブル時の一次切り分けが早い。
- エクスポート/バージョン管理で引き継ぎや再現性を確保。
CSSの管理
- 小規模な微調整は追加CSS、大きな設計やユーティリティは**子テーマ
style.css**へ。 - コメントとセクション分けで将来の保守性を担保。
運用ルール
- ステージングで先に検証→本番反映を徹底。
- リリースごとに変更履歴（Changelog）と互換情報を確認。
- 定期的に不要スニペット/未使用CSSを整理し、複雑化を防ぐ。
安心のロールバック戦略
ホスティングのスナップショット/復元
- 最速の戻し方。作成時刻を確認して更新直前のポイントへ戻す。
- 復元後は原因の特定まで本番更新を止める。
バックアッププラグインで復元
- ファイル＋DBを同一の時点に戻す（ファイルのみ/DBのみの部分復元は整合に注意）。
- 復元後はキャッシュ全削除 → 動作確認。
WP-CLIでの緊急切替（サーバー操作が可能な場合）
# 有効テーマの確認
wp theme status
# 既定テーマへの切替（例：Twenty Twenty-Five）
wp theme install twentytwentyfive --activate
# テーマの再インストール（手元のZIPを使う場合）
wp theme install /path/to/theme.zip --force
ヒント：テーマ自体に問題があるのか、プラグイン・キャッシュ・PHPに起因するのかを、既定テーマに切り替えて再現するかで大きく切り分けできます。
よくある質問（FAQ）
自動更新はONにすべき？
本番は原則OFF。ステージングで自動更新を有効にし無事故を確認→本番反映が安全です。小規模サイトで影響範囲が限定的、かつ子テーマ/スニペット運用が徹底されている場合のみ本番ONを検討。
子テーマは絶対必要？
親テーマ直編集をしないなら不要ですが、テンプレート上書きや大きめのCSSを扱うなら子テーマは実質必須。将来の拡張や人員交代にも強くなります。
更新通知が来ない/更新できない
- ライセンス期限切れやAPIキー不備の可能性。配布元のアカウントを確認。
- セキュリティ対策で外部接続が遮断されている場合も（ファイアウォール/Basic認証）。
更新後に真っ白・メンテナンスのまま
.maintenanceファイルが残存していないかを確認・削除。- それでも復帰しない場合は既定テーマへ切替し、プラグインを一括停止→段階的に再有効化。
CSSが効かない/一部だけ崩れる
- キャッシュ/ミニファイ/順序を疑う。ミニファイOFFで読み順を素に戻す。
- テーマの新クラス名/HTML構造に変更がないかリリースノートを確認。
EC/会員サイトで気を付ける点は？
- 決済/フォーム/会員ログインの動線はステージングで本番同等のテストを。
- ピーク時間帯は避け、リリース後30～60分の重点監視を行う。
実務で使えるチェックリスト（コピー可）
更新前チェック（10項目）
- ファイル＋DBの完全バックアップ取得
- 復元手順/スナップショットの戻し方を確認
- 現在のバージョン（WP/テーマ/PHP/主要プラグイン）を控える
- 変更差分の棚卸し（親直編集がないか）
- 直編集は子テーマ/スニペット/追加CSSに移行
- ステージングで先行アップデート＆動作確認
- キャッシュ/ミニファイ/CDNを一時停止
- アクセスの少ない時間帯に実施
- チームでテスト観点リストを共有
- ロールバック手段（どこまで戻すか）を明確化
更新後チェック（10項目）
- トップ/記事/固定/検索/カテゴリの表示確認
- メニュー/ウィジェットの割当が維持されている
- フォーム送信/検索/会員/決済など主要機能の実働確認
- ブラウザコンソールでJSエラーがない
- PHPエラーログに致命的エラーがない
- WooCommerce等のテンプレート互換に警告なし
- キャッシュ再有効化 → 再確認
- CDNキャッシュのパージ実行
- Lighthouse等で主要パフォーマンス指標の変化を把握
- 変更点を**記録（Changelog）**して次回に備える
コメントを残す