WordPress表示崩れの原因をAIと切り分ける方法｜テーマ・プラグイン・キャッシュの調査手順

宿主とAIがテーマ・プラグイン・キャッシュの三つに分けてWordPress表示崩れの原因を調査するイラスト AIサイト管理

WordPressを更新した後に表示が崩れると、「テーマが悪いのか」「プラグインがぶつかったのか」「古い画面が残っているだけなのか」が分からず、不安になります。

このとき、思いついた設定を次々に変えると、元の不具合と後から加えた変更が混ざります。AIへ頼む場合も同じです。最初から修正させるのではなく、再現条件を記録し、原因候補を一つずつ減らす調査役として使います。

この記事では、ITに詳しくない宿主さんでもCodexやClaude Codeへ調査を頼めるように、テーマ・プラグイン・キャッシュを安全に切り分ける順番を説明します。

結論：最初に直さず、四つの箱へ分ける

表示崩れを見つけたら、原因候補を次の四つに分けます。

原因候補 よくある見え方 最初の確認
キャッシュ 管理者と一般客、端末によって見え方が違う シークレット画面、別端末、キャッシュ層
テーマ メニュー、余白、画像、見出しが広範囲に変化 親・子テーマ、独自CSS、更新履歴
プラグイン フォーム、予約部品、スライダーなど一機能が壊れる 有効一覧、更新時刻、検証環境での競合確認
実行環境 真っ白、500エラー、処理途中で停止する PHP・WordPressのログ、バージョン、容量

AIには、証拠がない段階で一つに決めつけさせません。「可能性」「確認方法」「確認結果」を表にして、結果が出るたびに候補を絞らせます。

まず追加変更を止める

次の操作は、原因が分かるまで止めます。

  • 別のプラグインやテーマも続けて更新する
  • 直りそうなCSSを何本も追加する
  • 本番でプラグインを一括停止する
  • キャッシュを何度も消しながら設定も変える
  • バックアップの戻し方を確認せず復元する
  • エラーログ全文をそのままAIへ貼る

予約受付や問い合わせが止まっている場合は、調査より先に宿としての代替連絡手段を案内します。電話やOTAなど、現在使える予約経路をお知らせしたうえで保守担当者へ連絡してください。

AIへ渡す「症状メモ」を作る

AIは実際の画面や変更履歴を見なければ、一般論しか返せません。次の項目をメモします。

  1. 問題が起きたURL
  2. 正常だった最後の日時と、発見した日時
  3. 直前に更新したWordPress・テーマ・プラグイン
  4. パソコンとスマートフォンのどちらで起きるか
  5. ログイン中とログアウト状態のどちらで起きるか
  6. 表示だけか、予約・問い合わせ操作も失敗するか
  7. エラー番号や画面上の短いメッセージ
  8. 更新前後のスクリーンショット

氏名、メールアドレス、予約番号、決済情報、Cookie、認証情報が写っている画像やログは渡しません。必要部分だけ伏せ、AIへ渡す前にもう一度確認します。

第1段階：キャッシュかどうかを確認する

WordPress公式ドキュメントも、変更が反映されない原因としてブラウザ、サーバー、キャッシュプラグインを挙げています。キャッシュとは、表示を速くするために以前の画面を一時保存する仕組みです。

次の順で、同じURLを確認します。

  1. 普段のブラウザを再読み込みする
  2. シークレットウィンドウで開く
  3. ログインしていない別の端末で開く
  4. 宿のWi-Fiではなく別回線から開く
  5. 利用中のキャッシュ機能を保守担当者に確認する

「自分のパソコンだけ古い」「管理者だけ正常」「一部の地域だけ古い」といった違いは、キャッシュを疑う材料になります。ただし、キャッシュ削除はブラウザ、WordPressプラグイン、レンタルサーバー、CDNなど層ごとに異なります。AIに推測で全削除させず、使用中のサービスと公式手順を確認します。

キャッシュを消して一時的に正常になっても、それだけで原因が解決したとは限りません。新しい壊れた画面が保存され直さないか、時間を置いて再確認します。

第2段階：テーマの問題かを確認する

テーマ側の問題では、複数ページに共通する見た目が変わりやすくなります。

  • ヘッダーやメニューの位置
  • 全体の文字サイズや余白
  • アイキャッチ画像の比率
  • サイドバーやフッター
  • スマートフォン表示の横はみ出し
  • テーマ独自のボタンや装飾

AIへは、現在使っている親テーマと子テーマ、更新前後のバージョン、独自CSSの保存場所を読み取りだけで整理させます。親テーマを直接編集していた場合、更新で変更が消えた可能性があります。

テーマを一時変更して確認する作業は、公開中の本番では表示全体が変わるため避けます。検証環境で標準テーマへ切り替え、同じ症状が消えるかを確認します。消えた場合はテーマ側が有力ですが、テーマそのものだけでなく、テーマと特定プラグインの組み合わせも残ります。

第3段階：プラグイン競合を確認する

一つの機能だけが壊れた場合は、その機能を提供するプラグインや関連プラグインを調べます。

  • 問い合わせフォームだけ送信できない
  • 予約ボタンだけ反応しない
  • スライド写真だけ表示されない
  • 地図や動画だけ読み込めない
  • SEOのdescriptionだけ出なくなった

まず、有効なプラグイン名、現在版、更新日時をAIへ一覧化させます。この読み取りだけでサイトの表示は変わりません。次に、更新履歴と症状が始まった時刻を照合します。

プラグインを停止して確認する場合は、原則として検証環境を使います。一度に全部止めず、対象を記録して一つずつ確認します。予約、決済、セキュリティ、バックアップ、キャッシュに関係するプラグインは、影響を理解せず本番で停止してはいけません。

WordPress.orgの「Health Check & Troubleshooting」には、管理者の調査セッションだけでプラグイン停止や標準テーマを試すトラブルシューティングモードがあります。一般の訪問者へ影響させず確認できることが特徴ですが、サイト構成や他の管理者操作との相性は事前に確認し、バックアップ後に導入します。プラグインを追加すること自体も変更なので、AIが無断で入れてよいものではありません。

第4段階：エラーログを必要部分だけ確認する

真っ白な画面、500エラー、保存時の停止などは、見た目の比較だけでは分かりません。PHPやWordPressのエラーログから、問題が起きた時刻付近を確認します。

WordPress公式のデバッグ資料では、WP_DEBUGやWP_DEBUG_LOGなどが説明されていますが、本番サイトでの常時利用は推奨されていません。設定ファイルを触る作業は、レンタルサーバーのサポートまたは保守担当者へ相談してください。

ログをAIへ渡すときは次を守ります。

  • 発生時刻の前後だけを抜き出す
  • サーバー内部のパスや利用者名を伏せる
  • IPアドレス、Cookie、メールアドレスを伏せる
  • 同じエラーの大量な繰り返しは件数だけ伝える
  • ログをサイト上へ公開しない
  • 調査後に一時的なデバッグ設定を元へ戻す

エラーにプラグインのフォルダ名が含まれても、そのプラグインが必ず原因とは限りません。別の処理から呼ばれ、そこで異常が表面化した可能性もあります。

AIへコピペできる調査プロンプト

まず読み取りだけで整理する

WordPress更新後に表示が崩れました。まだ修正しないでください。

症状:
［問題のURL、端末、発生日時、直前の更新、エラー内容］

最初は読み取り専用で、
1. 再現条件
2. キャッシュ、テーマ、プラグイン、実行環境の原因候補
3. 各候補を確認する安全な方法
4. 本番を変更せず確認できる項目
を表にしてください。

証拠がない原因を断定しないでください。
停止、更新、削除、設定変更、キャッシュ削除、再起動は実行しないでください。
個人情報や認証情報が見つかった場合は内容を表示せず、場所だけ報告してください。

検証環境で一つずつ確認する

本番の複製である検証環境を使って、表示崩れの原因を切り分けたいです。
本番は変更しないでください。

更新履歴と有効なテーマ・プラグインを確認し、影響が小さい順に
一項目ずつ検証する計画を作ってください。
各手順に、変更前の記録、期待する結果、元へ戻す方法、確認URLを付けてください。

私が計画を承認するまで、停止・切り替え・更新は実行しないでください。
予約、決済、問い合わせ、メール送信は人が確認する項目として残してください。

調査結果から修正案を比較する

調査の結果、［確認できた事実］が分かりました。
まだ本番を変更しないでください。

修正案を「原因へ直接対処する案」「一時回避」「復元」の三つに分け、
影響範囲、再発可能性、元へ戻す方法、必要な確認を比較してください。
根拠のないCSS追加や、プラグインの無断削除は提案しないでください。

AIの回答をどう判断するか

安全な回答には、次の特徴があります。

  • 調査と変更を分けている
  • 一度に一項目だけ確認する
  • 本番と検証環境を区別する
  • 変更前の記録と戻し方がある
  • 予約・決済・フォームを人が確認する
  • 分からないことを「未確認」と書く

反対に、「とりあえず全プラグインを止める」「CSSへ強制指定を足す」「エラーを非表示にすればよい」「バックアップなしで以前の版へ戻す」という提案は、そのまま実行しません。

最終的な修正は原因に合わせる

確認できた原因 対応の考え方
古いキャッシュ 対象の層と公式手順を確認して更新する
親テーマの直接編集が消えた 子テーマ等、更新で消えにくい管理へ移す
プラグイン競合 公式修正版、設定変更、代替手段を比較する
PHP等との非互換 対応版を検証し、保守担当者と更新順を決める
原因未確定 追加変更を止め、正常時バックアップからの復元を検討する

見た目だけを元へ戻すCSS追加は、原因を隠して次の更新で再発することがあります。恒久対応と、予約受付を続けるための一時回避を分けて記録します。

宿主さんの確認チェックリスト

  • [ ] 問題のURL、端末、発生時刻を記録した
  • [ ] 直前に更新したものを記録した
  • [ ] 追加の更新や場当たり的な修正を止めた
  • [ ] シークレット画面と別端末で確認した
  • [ ] 読み取り調査と変更作業を分けた
  • [ ] テーマ・プラグインの切り替えは検証環境で試した
  • [ ] ログから個人情報と認証情報を除いた
  • [ ] 一度に一項目だけ変更した
  • [ ] 予約、問い合わせ、料金、スマートフォン表示を人が確認した
  • [ ] 原因、修正、確認結果を運用記録へ残した

更新前後の見た目を自動で残したい場合は、Playwrightで画面を比較する方法も利用できます。更新全体の安全な進め方はWordPress更新で表示が崩れたときの対処、バックアップはWordPress更新前のバックアップと復元を参照してください。

参考にした公式情報

まとめ

表示崩れの原因調査では、早く何かを変えるより、同じ症状を再現し、候補を一つずつ消すことが重要です。

AIは変更履歴の整理、比較、ログの分類、検証計画づくりを速くできます。宿主さんは、公開中の予約経路を守ること、変更を承認すること、料金・予約・問い合わせを実際に確かめることを担当します。この役割分担なら、原因不明のまま修正を重ねる危険を減らせます。

タイトルとURLをコピーしました