Local環境でWordPressプラグインのCSSが崩れた原因がCookieだった話

はじめに

納期直前の案件で、Local（by Flywheel）上のWordPressサイトで突然管理画面のCSSが崩れ、プラグインUIが表示されなくなるという事態に遭遇しました。
焦りつつも原因を調査し、最終的には**「ブラウザに残っていたCookie」が原因**であることがわかりました。

本記事では、再発防止と同じ悩みを持つ方の助けになるよう、トラブル発生から解決までの経緯と対処法を共有します。

発生した症状

• WordPress 管理画面にログインできるが、CSSが適用されておらず白黒レイアウトに
• All-in-One WP Migration や ACF（Advanced Custom Fields）などのプラグインUIが完全に崩壊
• DevTools の Console / Network タブには、load-scripts.php や acf-global.min.css などが 400 Bad Request

試したこと（すべて効果なし）

• WordPressテーマをデフォルトに戻す
• プラグインを一時無効化
• wp-config.php に WP_HOME / WP_SITEURL を明記
• Router Mode を Site Domains に切り替える
• Local を再起動／再インストール
• サイトの再インポート（ZIP）
  → それでも直らず

最終的な解決策

Chromeの Cookie 削除（localhost:10008 のみ）

✅ 手順（Chromeの場合）：

1. 表示が崩れているページで 右クリック →「検証」（もしくは Cmd + Option + I）
2. デベロッパーツールが開いたら、上部タブの「Application」を選択
3. 左側のサイドバーから「Cookies > localhost:10008」を選ぶ
4. 右側に表示されたCookieをすべて選択し、右クリック →「Delete」
5. ページをハードリロード（Cmd + Shift + R）
6. 正常にCSS・JSが読み込まれて表示が復活！

→ 管理画面が即座に正常表示され、すべてのCSS・JSが読み込まれるようになった

---

なぜCookieが原因になるのか？

WordPress管理画面では、認証情報や一時的な設定、CSRF保護トークンなどがCookieに保存されます。
これが破損したり、Localの構成変更（再インポート・ドメイン変更）と一致しなくなると、load-scripts.phpやプラグインのアセット読み込みに失敗して 400エラーとなるケースが多く報告されています。

学んだこと

• CSS崩れ・JS読み込み失敗 → Cookieをまず疑え
• Localでのルーティング変更や再インストール後は、キャッシュやCookieのリフレッシュが重要
• ブラウザ（特にChrome）は内部で粘るので、「F12 → Application → Cookies → Delete」が最速

まとめ

今回のようなトラブルは「環境依存＋UI破壊型」のため、外からは一切原因が見えず非常に厄介です。
再発を防ぐためにも、自分の環境に合わせて「Cookie削除」や「Router Modeの扱い方」を習慣化すると良いと実感しました。