PHP 8.1以上に変更すると500エラーが起きる時の原因と対処法
WordPressサイトでPHPを8.0から8.1以上に切り替えると500 Internal Server Errorが発生する場合は、サーバー側のエラーログ確認と拡張機能・PHPハンドラの互換性チェックが解決の最短ルートになる。WordPressのdebug.logが空でも、エラーがWordPress起動前に発生している可能性が高い。
PHP 8.1以上への変更で500エラーが起こる原因
500 Internal Server Errorは「サーバー内部で想定外のエラーが起きた」ことを示す汎用的な表示だ。原因はWordPress内のプラグインやテーマとは限らない。PHPのバージョンアップに伴うサーバー側の設定変更、拡張機能の欠落、PHPハンドラの切り替えなど、WordPressが動き出す前の段階でエラーになるケースも多い。
特にPHP 8.0から8.1以上への変更時は、非推奨だった機能の正式な削除や、デフォルト設定の変更が影響する。古いプラグインやテーマのコードがPHP 8.1で動かない場合もあるが、そのケースでは多くの場合WordPressのデバッグログに記録が残る。一方、debug.logに何も出ない500エラーは、サーバーレベルでの問題を疑うべきだ。
サーバーのエラーログを確認する手順
まず確認すべきは、レンタルサーバーのコントロールパネルにある「エラーログ」または「サーバーログ」だ。PHP 8.1でエラーが出ている場合、WordPressのdebug.logではなく、このサーバーログにだけ記録が残っていることがある。
コントロールパネルで該当ログを探す
国内の一般的なレンタルサーバーでは、管理画面の「ログ」や「アクセス解析」の近くにエラーログの項目がある。エラーログにはタイムスタンプとともに、どのPHPハンドラが失敗したのか、どの拡張機能が読み込めなかったのか、メモリ不足が起きたのかといった記録が残る。エラー発生直後の行をコピーしておくと、原因の特定が速い。
上のデモはサーバーのエラーログを確認する一連の流れを示している。ログにPHPの拡張機能名（例「mysqli」や「curl」）が書かれていれば、その拡張機能がPHP 8.1環境で有効になっていない可能性が高い。ハンドラ名（例「php-fpm」や「FastCGI」）の記述があれば、ハンドラの切り替えに失敗しているケースが考えられる。
PHPハンドラと拡張機能の互換性を確かめる
サーバーログにWordPressが起動する前のエラーが記録されている場合、原因はPHPハンドラまたはPHPの拡張機能にある。PHPハンドラとは、サーバーがPHPファイルを実行するための仕組みのことだ。PHP 8.0から8.1に切り替える際、ハンドラの設定が初期化されたり、互換性のない組み合わせになったりすることがある。
最小限のPHPファイルで切り分ける
WordPressとは無関係に、PHP 8.1自体が正常に動くかどうかを確認する方法がある。FTPソフトなどでWordPressと同じディレクトリに、内容が <?php phpinfo(); ?> だけのファイル（例 php-check.php）をアップロードし、ブラウザでアクセスする。
このファイルも500エラーになるなら、WordPressやプラグインの問題ではない。サーバーのPHP設定・ハンドラ・拡張機能そのものに問題がある。逆にこのファイルが正常に表示されるなら、WordPress側のコードに原因があるため、プラグインやテーマの互換性を順に調べる。
この切り分けでサーバー側の問題だと判明したら、レンタルサーバーの管理画面からPHP 8.1に切り替えた直後の設定を確認する。PHPハンドラが「利用不可」になっていたり、必要な拡張機能（mysqli、mbstring、curl、zipなど）が「無効」になっていたりしないかを確かめる。
debug.logが空でも見落とさない5つのチェックポイント
WordPressのdebug.logにエラーが残っていない場合でも、500エラーの原因は必ず存在する。以下の5点を順に確認すると、隠れた原因に行き着きやすい。
1. wp-config.phpのデバッグ設定を再確認する
WP_DEBUG と WP_DEBUG_LOG が両方とも有効になっているかを確認する。WP_DEBUG_DISPLAY が false のままでもログは出力されるが、設定の記述位置が古いテーマのコードより後だと、エラーが発生する時点でログ設定が読み込まれないことがある。wp-config.phpのなるべく先頭近くに記述を移動しておくと確実だ。
2. php.iniや.user.iniの記述を確認する
PHPのバージョンを変更すると、ホームディレクトリ直下の php.ini や .user.ini が別バージョンの設定として適用される場合がある。PHP 8.0向けに書いた設定がPHP 8.1では不正な構文になるケースや、設定した内容がホスティング側の制限と競合するケースがある。
3. 拡張機能の有効状態を一覧で比較する
PHP 8.0で有効だった拡張機能が、PHP 8.1では無効になっていることがある。特に画像処理のGDや、データベース接続のmysqli、マルチバイト文字列のmbstringが無効だと、WordPressは起動すらできない。phpinfo() の結果をPHP 8.0と8.1で並べて比較すると、差分に気づきやすい。
4. .htaccessからPHP関連の記述を一度外す
PHPのバージョンやハンドラを指定する .htaccess の記述が、新しいPHPの設定と競合して500エラーを起こすことがある。WordPressの標準的な記述だけにした .htaccess を新しく作ったうえで、PHP関連のカスタム記述を一時的に外して確認する。
5. サーバー会社の障害情報と設定上限を確認する
そのサーバーがPHP 8.1への切り替えを一時的に制限している場合や、特定のハンドラがメンテナンス中の可能性がある。サーバー会社の障害・メンテナンス情報ページを確認すると、想定外の原因に行き着くこともある。
WooCommerceを使うPHP 8.1移行で気をつける互換性
WooCommerceはPHP 8.1に正式対応している。ただし、導入している拡張プラグインや子テーマの中にはPHP 8.1で動作しない古いコードが残っている場合がある。PHP 8.0から8.1への変更で、関数の呼び出し方が非推奨から削除に変わったものが影響することもある。
切り分けテストは、WooCommerce以外のプラグインをすべて無効化し、標準テーマ（Twenty Twenty-Fourなど）に切り替えた状態でPHP 8.1を適用する手順が確実だ。その後、1つずつプラグインを有効化して、どのプラグインで500エラーが再発するかを突き止める。ただし、この手順でエラーが再発しない場合も、先に述べたサーバーレベルの問題が残っている可能性を忘れてはならない。
よくある質問
500エラーが出たまま管理画面にログインできない場合はどうする？
FTPソフトでwp-content以下のpluginsフォルダ名を一時的に変更すると、全プラグインを無効化できる。同じくテーマフォルダ名を変更すると標準テーマに切り替わる。その後、PHP 8.1でサイトが表示されるかを確認する。
PHP 8.1に切り替える前の注意点は？
事前にサイト全体のバックアップを取る。次に、プラグインとテーマがPHP 8.1に正式対応しているか、各プラグインの公式ページで確認する。対応表記がない場合は、PHP 8.0のままテスト環境で切り替えテストを行うのが安全だ。
サーバーログで「Allowed memory size exhausted」と出る場合は？
PHPのメモリ上限を増やすことで改善する。wp-config.phpの WP_MEMORY_LIMIT を256MBや512MBに設定し、php.iniの memory_limit も確認する。レンタルサーバー側で上限が固定されている場合は、サーバーの仕様を確認する。
debug.logに「Fatal error」と出る場合の読み方は？
エラーが発生したファイル名と行番号が記録されているので、該当するプラグインやテーマを特定できる。プラグイン名が明示されている場合は、そのプラグインを無効化するか、PHP 8.1対応版への更新を確認する。
PHP 8.0に戻せば解決するが、8.1のままにしたい場合は？
PHP 8.0に戻してサイトを復旧させたうえで、8.1で動かない原因を特定する。テスト環境を作り、プラグインやテーマの互換性を1つずつ確認して、修正または代替プラグインを導入してから本番環境を切り替えるのが安全な進め方だ。
この記事のポイント
- PHP 8.1以上での500エラーはサーバーログに原因が記録されていることが多い
- debug.logが空でもWordPress起動前のエラーを疑う
- 最小のPHPファイルでサーバー側とWordPress側を切り分ける
- PHP 8.0で有効だった拡張機能が8.1で無効になっていないか確認する
- WooCommerceは公式対応だが拡張プラグインの互換性は個別に確かめる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
FoundByAIのllms.txtが404になる原因とDiviショートコード混入の修正手順
FoundByAIが生成する /llms.txtが404を返す場合、Rank Math SEOやYoast SEOなどのSEOプラグインがエンドポイントを確保していることが主な原因だ。プラグインをバージョン1.3.6以降に更新すると、404とDiviショートコード混入の両方を解決できる。
llms.txtが404を返す原因は何か
/llms.txtにアクセスすると404になるのに、パーマリンクを再保存してもキャッシュを削除しても直らない。この症状は多くの場合、SEOプラグインが /llms.txtというURLを「自分の管轄」として押さえていることが原因だ。
Rank Math SEO、Yoast SEO、All in One SEOなどは、llms.txtを自ら配信する機能を持っている。FoundByAIは1.3.5以前、これらのSEOプラグインが有効化されていると「SEOプラグインが配信するだろう」と判断し、/llms.txtの配信役を自ら降りていた。
ところがSEOプラグイン側のllms.txt機能がオフになっていると、どのプラグインもURLに応答しない。結果としてHTTP 404が返る。これが「プラグイン上は生成済みと表示されるのに、実際のURLでは404になる」理由だ。
エンドポイントの担当がSEOプラグインとFoundByAIの間で競合していた状態だ。
Rank Mathのllms.txt機能がオフの環境で起きやすい
特にRank Math SEOは、llms.txt配信機能がデフォルトでオフの状態が多く、AI関連機能を無効化している場合はなおさらだ。しかしFoundByAI 1.3.5以前は「Rank Mathが有効化されている」という事実だけで配信を譲っていたため、404が発生しやすかった。
パーマリンク再保存やキャッシュ削除で直らない理由
この404は .htaccessの書き換え設定ではなく、プラグイン同士の「エンドポイントの取り合い」が原因だ。パーマリンク設定を変更しても、ファイル転送の設定や配信ルールが変わらないため、状況は改善しない。キャッシュが原因でもないため、キャッシュを削除しても同じ結果になる。
FoundByAI 1.3.6への更新で直す手順
バージョン1.3.6では、他のプラグインが /llms.txtを配信しない場合、FoundByAIが自ら配信するように動作が変わった。更新するだけで404は解消する。
更新から配信確認までの一連の流れだ。
更新前に使っているSEOプラグインを確認する
まず利用中のSEOプラグインがllms.txtを配信しているかを確認する。配信しているなら、そのSEOプラグインのファイルが優先されるため、FoundByAI側の設定を変更する必要はない。配信していない場合に、1.3.6以降のFoundByAIが自動で代替する。
更新後の動作確認方法
更新後は、シークレットウィンドウで /llms.txtにアクセスしてHTTP 200が返ることを確認する。あわせて /llms-full.txtの内容にDiviショートコードが残っていないかも目視で確認する。ブラウザのキャッシュが残っていると古い結果が見えることがあるため、シークレットウィンドウを使うのが確実だ。
llms-full.txtにDiviショートコードが混入するのはなぜか
llms-full.txtに [et_pb_section] や [et_pb_row] などの生のショートコードが出力されるのは、生成処理がDiviのモジュール読み込みよりも先に実行されていたためだ。1.3.5以前のFoundByAIは、DiviがショートコードをHTMLに展開する前にページ内容を収集していた。
この結果、Diviのテキストモジュールやアコーディオン、カスタムHTMLブロックの中身が、読みやすいテキストではなく生のショートコードとして埋め込まれる。AIクローラーが読むファイルとしては不適切な内容だ。
[et_pb_row]
[et_pb_text]
本文のテキストが生のまま混ざる
[/et_pb_text]
[/et_pb_row]
[/et_pb_section]
##本文の見出し
読みやすいテキストだけが出力される
更新前後でllms-full.txtの内容はこのように変わる。
1.3.6で修正済みだがDivi 5は要確認
1.3.6はDivi 4.27で動作確認が行われている。Divi 5はコードベースが大きく変更されているため、公式には確認されていない。Divi 5環境では更新後に必ず /llms-full.txtを開いて、生のショートコードが残っていないかを確認する。
Markdown版ページは元から正常だった
補足すると、個別ページのMarkdown版（.md形式）は1.3.5以前からクリーンな出力だった。問題があったのはllms-full.txtという全体をまとめたファイルだけだ。両者の生成タイミングが異なるため、この差が生じていた。
初回アクセスに30〜40秒かかる問題の軽減策
1.3.6への更新後、/llms.txtと /llms-full.txtの初回アクセスに30〜40秒かかることがある。2回目以降はキャッシュが使われ、ほぼ瞬時に表示される。この待ち時間は、サイト全体のページを収集してMarkdownを生成する処理が動くためだ。
より深刻なのはキャッシュの有効期限が切れた直後だ。AIクローラー（OAI-SearchBot、ChatGPT-User、ClaudeBotなど）が初回リクエストを送ったとき、30〜40秒待たされるとタイムアウトして取得を諦める可能性がある。
キャッシュの仕組みを理解する
FoundByAIは生成したファイルを一定時間キャッシュする。キャッシュが有効な間は高速に配信されるが、期限切れ後の最初のリクエストでは再度フル生成が走る。バックグラウンドで事前生成する仕組みがなければ、この「最初の1人」は必ず長い待ち時間を経験する。
静的ファイルを手動配置してタイムアウトを回避する
確実な対策は、生成済みのllms.txtとllms-full.txtをサーバーのルートディレクトリに静的に配置することだ。プラグインの生成処理を待たず、常に即時配信されるため、AIクローラーがタイムアウトする心配がなくなる。
ただし、コンテンツを更新するたびに手動で再生成する運用が必要になる。サイト更新の頻度が高い場合は、キャッシュの有効期限を長めに設定しつつ、更新作業の後に手動でファイルを再配置する運用が現実的だ。
手動アップロードしたllms.txtをどう扱うか
1.3.6への更新前に手動でllms.txtをアップロードした場合、更新後しばらくはそのまま残しておいて問題はない。プラグイン生成版の配信が確認できてから削除するのが安全だ。
手動ファイルが残っていると、生成されたファイルと内容が食い違うことがある。プラグインの生成が安定したら、手動ファイルは削除して一元管理するのが望ましい。サイトの構成や更新頻度に応じて、手動配置を継続するかプラグインに任せるかを判断する。
よくある質問
llms.txtとは何か、誰が読むのか
llms.txtは大規模言語モデル（LLM）向けのサイト案内ファイルだ。robots.txtが検索エンジン向けなら、llms.txtはAIクローラー向け。サイトの重要ページ一覧や要約をMarkdown形式で記述し、AIが効率よくサイトを理解できるようにする。llms-full.txtはより詳細な全文版だ。
Rank Math SEOのllms.txt機能がオフなのに404になるのはなぜか
FoundByAI 1.3.5以前は、Rank Mathが有効化されていると「Rank Mathが配信する」と判断して自ら配信を止めていた。Rank Math側のllms.txt機能がオフだと、どのプラグインも配信せず404になる。1.3.6ではこの判断が修正されている。
Divi 5でもFoundByAI 1.3.6は正常に動くか
1.3.6のDivi対応はDivi 4.27でテストされている。Divi 5はコードベースが異なるため、公式には動作確認されていない。Divi 5環境では更新後に /llms-full.txtを開いて生のショートコードが残っていないか確認する。
プラグインを更新せずにこの問題を回避できるか
手動でllms.txtをアップロードすれば404は回避できる。ただしllms-full.txtのDiviショートコード混入は手動では根本解決できない。1.3.6以降への更新が最も確実な対処だ。
キャッシュ有効期限が切れた後の初回アクセスを速くする方法はあるか
生成済みの静的ファイルをサーバーに直接配置する方法が有効だ。キャッシュ期限に関係なく即時配信される。ただしコンテンツ更新時には手動で再生成する必要がある。
この記事のポイント
- /llms.txtの404はSEOプラグインとの競合が主因
- FoundByAI 1.3.6への更新で404とDiviショートコード混入が解決
- Rank Math SEOのllms.txt機能がオフの環境で発生しやすい
- 初回アクセスの30〜40秒はキャッシュ生成が原因
- 静的ファイルの手動配置でクローラーのタイムアウトを防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Contact Form 7更新後にフォーム管理画面へアクセスできない時の原因と直し方
Contact Form 7を6.2系へ更新した後、管理者以外のユーザーがフォームの編集画面に入れなくなった場合は、管理メニューのURL変更が原因の可能性が高い。メニュー設定を制御するプラグイン（WP Custom Admin Interfaceなど）に新しいURLを追加すれば解決する。
Contact Form 7 6.2系で管理画面URLが変わった理由
Contact Form 7は6.2.0から管理メニューの構成が整理された。従来のフォーム一覧画面は /wp-admin/wpcf7 という直感的なURLだったが、6.2以降は /wp-admin/admin.php?page=wpcf7 に変更された。
あわせて新規作成画面は /wp-admin/admin.php?page=wpcf7-new、ダッシュボードは /wp-admin/admin.php?page=wpcf7-dashboard に分かれた。メニューのスラッグ（識別子）が変わったため、旧URLを基準にアクセス制御をかけていたプラグインが反応しなくなる。
このURLの変化は、フォーム管理画面への直リンクやブックマークにも影響する。旧URLを保存している場合は、新URLへ置き換える必要がある。
管理者以外がフォームを編集できなくなる原因
管理メニューの表示や権限をカスタマイズするプラグインは、メニューのスラッグを記録して「どの役割にどのメニューを見せるか」を制御する。WP Custom Admin Interfaceのようなプラグインは、WordPressが登録するメニュー情報を監視し、条件に合わないメニューを非表示にしたりアクセスを拒否したりする。
CF7 6.2系でメニュー構成が変わると、プラグインが記録していた旧スラッグに一致するメニューが存在しなくなる。結果として、新しく追加された wpcf7 や wpcf7-new というスラッグが「許可されていないメニュー」と見なされ、管理者以外のユーザーが画面を開けなくなる。
マルチサイト環境では、ネットワーク全体を管理するスーパー管理者と、各サイトの管理者とで権限の扱いが異なる。スーパー管理者はネットワークレベルの権限で大半の制限を迂回できるため、一見するとスーパー管理者だけがアクセスできるように見えることがある。
管理メニュー設定に新しいURLを追加する対処手順
まずは利用中のメニュー制御系プラグインの設定画面を開き、Contact Form 7に関連する新しいメニュー項目を許可リストへ追加する。WP Custom Admin Interfaceでは「Admin Menu」設定でメニュー項目ごとに表示・アクセスの可否を管理できる。
追加すべきメニュー項目の一覧
wpcf7（フォーム一覧）wpcf7-new（新規作成）wpcf7-dashboard（ダッシュボード）wpcf7-integration（連携設定、テーマにより表示）
メニュー項目を追加してもアクセスできない場合は、プラグインがURLの完全一致ではなく前方一致や正規表現で判定している可能性がある。wpcf7 という文字列を含む項目をすべて許可する設定ができるかどうかを確認する。
設定を変更しても直らない場合の切り分け
メニュー設定の追加だけで解決しないときは、一時的にメニュー制御系プラグインを無効化して、Contact Form 7のフォーム管理画面へアクセスできるかを確認する。無効化でアクセスできるなら、プラグイン側のURL判定が新しいメニュー構造へ対応していない。
プラグインの開発元がCF7 6.2系への互換アップデートを出しているかを確認し、最新版へ更新する。それでも対応していない場合は、権限制御を別の方法（ユーザー役割の見直しや、Contact Form 7の権限フィルター）で実現することを検討する。
権限設定と役割を確認する方法
Contact Form 7の管理画面へアクセスするには、ユーザーに適切な権限（ケイパビリティ）が必要だ。標準では管理者権限（manage_options）を持つユーザーがフォームを管理できるが、カスタム権限を設定している環境では役割ごとの権限を見直す必要がある。
ユーザー役割編集系プラグインを使っている場合、Contact Form 7自体が要求する権限を確認し、対象の役割へ割り当てる。CF7 6.2系では管理画面のページが細分化されたため、フォーム管理の権限とダッシュボード閲覧の権限が別に扱われることがある。
マルチサイト環境では、サイト管理者とスーパー管理者の権限差も確認する。スーパー管理者だけがアクセスできる状態は、ネットワークレベルの権限設定が影響している場合があるため、各サイトの管理者にも適切な権限が付与されているかを確認する。
プラグイン更新前に検証環境で確認する推奨フロー
Contact Form 7のように管理画面の構造を変える更新は、本番環境へ適用する前に必ずステージング環境（検証サイト）で確認する。特にメニュー制御系や権限管理系のプラグインを併用している場合は、更新後に管理画面へ正常にアクセスできるかを各ユーザー役割でテストする。
ステージング環境を用意できない場合でも、メンテナンス時間を設けて更新し、直後に管理者以外のユーザーでアクセス確認を行う。問題が起きたときにすぐ切り戻せるよう、更新前のバックアップを必ず取得しておく。
よくある質問
Contact Form 7 6.2系の管理URLはどこに変わった？
フォーム一覧が /wp-admin/wpcf7 から /wp-admin/admin.php?page=wpcf7 に変わった。新規作成は wpcf7-new、ダッシュボードは wpcf7-dashboard というページとして分離された。
メニュー管理プラグインを使っていない場合も影響する？
メニュー制御系プラグインを使っていなければ、通常は管理者以上の権限を持つユーザーがそのままアクセスできる。影響が出るのは、旧URLを前提にメニューや権限をカスタマイズしていた場合に限られる。
マルチサイト特有の注意点はある？
マルチサイトではスーパー管理者とサイト管理者の権限差がある。サイト管理者がフォームを編集できない場合は、メニュー制御プラグインの設定に加えて、各サイトのユーザー役割にContact Form 7の管理権限が付与されているかも確認する。
WP Custom Admin Interface以外のメニュープラグインでも同じ問題が起きる？
起きる可能性がある。管理メニューのスラッグを記録してアクセス制御する仕組みを持つプラグインは、Contact Form 7に限らず他のプラグインのメニュー構造が変わったときも同様の競合が起こり得る。
新しいURLを追加してもアクセスできない場合は？
メニュー制御系プラグインを一時的に無効化して、Contact Form 7単体でアクセスできるかを確認する。無効化でアクセスできるなら、プラグインの互換アップデートを待つか、権限管理を別の方法へ移行することを検討する。
この記事のポイント
- Contact Form 7 6.2系で管理画面URLが
admin.php?page=wpcf7に変わった - メニュー制御系プラグインが旧URLを基準にアクセスを拒否する
- 対処は新しいメニュースラッグを許可リストへ追加するのが基本
- 設定追加で直らない場合はプラグイン無効化で切り分ける
- 更新前にステージング環境で各ユーザー役割のテストを行う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
ACFブロックが編集画面で表示されない時の原因と対処（React 19実験を無効化）
GutenbergのReact 19実験が有効になると、ACFで登録したブロックが編集画面で「このブロックでエラーが発生したためプレビューできません」と表示され、プレビューできなくなることがある。この症状はACFがReact 19に未対応の段階で起こる互換性問題で、テーマのfunctions.phpにフィルターを追記してReact 18に固定すれば回避できる。
なぜACFブロックだけが編集画面でエラーになるのか
ACFで登録したブロックは、編集画面のプレビュー部分がReactコンポーネントとして扱われる。React 19ではコンポーネントの渡し方や内部処理が変更されたため、ACF 6.8.10以前の実装と噛み合わず「要素のタイプが無効です」という趣旨のReactエラー（コンソール上はReact error #130）が発生する。
コアブロックでは発生せずACFブロックだけに症状が出るのは、このエラーがブロックエディタ全体の不具合ではなくACFプラグイン側の互換性に起因するためだ。フロントエンドはサーバー側で描画されるため影響を受けず、編集画面のプレビューだけが壊れる。
編集画面では赤いエラー表示だけが出て手も足も出ないが、フロントエンドが正常ならこの互換性問題を強く疑ってよい。
React 19実験はなぜ自動で有効になるのか
GutenbergのReact 19実験は、互換性のないプラグインやテーマが見つからない限り自動で有効になる設計だ。不要なテーマやプラグインを整理した直後など、互換性チェックが通るようになったタイミングで突然有効化されることがある。
管理画面の「Gutenberg」メニューの「実験」画面で有効かどうかを確認できる。ただし一部のホスティング環境では、チェックを外しても保存されず、設定が既定値（有効）に戻ってしまう。そのため管理画面からの無効化だけでは対処できない場合がある。
この流れでReact 19が有効になった結果、ACFブロックのプレビューだけが壊れる。管理画面の設定が保存されない環境では、次の手順で強制的にReact 18へ固定する。
functions.phpでReact 18に固定する手順
対処は子テーマのfunctions.phpにフィルターを追記し、Gutenbergの実験オプションを上書きしてReact 18を維持する方法が確実だ。親テーマを直接編集するとアップデートで上書きされるため、必ず子テーマを使う。
// ACFがReact 19に対応するまでブロックエディタをReact 18に固定する
$theme_disable_react_19 = function($experiments){
$experiments = is_array($experiments) ? $experiments : [];
$experiments['gutenberg-react-19'] = false;
return $experiments;
};
add_filter('option_gutenberg-experiments', $theme_disable_react_19);
add_filter('default_option_gutenberg-experiments', $theme_disable_react_19);このフィルターは、Gutenbergの実験設定を保存するオプションに対して gutenberg-react-19 フラグを常にfalseに上書きする。管理画面でチェックを外しても戻ってしまう環境でも、テーマ側から強制できるため再発しない。
ACFがReact 19に対応したバージョンにアップデートされたあとは、このコードを削除して通常の設定に戻す。削除し忘れると新しいReactを使うべきタイミングでも18に固定されたままになるため、ACFの更新履歴は確認しておく。
修正後にブロックが表示されるか確認する方法
functions.phpにコードを追加したあとは、サーバー側とプラグイン側のキャッシュを削除し、ブロックエディタをハード再読み込み（Ctrl + Shift + Rなど）する。ACFブロックを再配置し、プレビューが表示されることを確認する。
ブラウザのコンソールを開き、React error #130が消えていることも確認すると確実だ。本番環境で直接試すのが不安な場合は、ステージング環境に同じコードを入れて挙動を確認してから反映する。
ACF側の対応と今後のアップデート
この症状はACFがReact 19に正式対応するまでの過渡期の互換性問題として認識されており、ACFの開発側でも修正が進められている。今後のアップデートでReact 19対応が含まれた場合は、本記事のフィルターを外して編集画面の挙動を再確認する。
それまでの間は、本番環境でReact 19実験を有効にしたまま使い続けるリスクを避けるため、本記事のフィルターでReact 18に固定しておくのが現実的だ。関連するプラグインやテーマが更新されたタイミングで、ステージング環境から互換性を確認する流れを作っておくと安全だ。
よくある質問
React 19実験を無効化すればACFブロックは直るのか
直る。ただし一部のホスティング環境では画面上のチェックが保存されず、既定値の有効に戻ってしまう。その場合はfunctions.phpのフィルターで強制的に無効化する。
functions.phpを直接編集せずに対処する方法はあるか
コードスニペットプラグインを使ってフィルターを追加する方法がある。いずれも親テーマを直接編集しないこと。親テーマを更新するとコードが消えるため、子テーマかスニペットプラグインを使う。
フロントエンドは表示されるのに編集画面だけ壊れるのはなぜか
ACFブロックの公開ページはサーバー側で描画されるため、React 19の影響を受けない。編集画面のプレビューだけはReactで組み立てられるため、互換性の問題が表面化する。
ACF以外のブロックが同じエラーを出す場合はどうすればよいか
同じReact error #130がコアブロックや他のプラグインブロックでも出る場合は、React 19実験だけでなくブロックの登録方法やプラグインの競合も確認する。一旦全プラグインを無効化して切り分けるのが早い。
フィルターを入れたままACFをアップデートしても問題ないか
問題はないが、ACFがReact 19に対応した後もフィルターが残っていると、React 18に固定され続ける。ACFの更新履歴を確認し、対応が完了したらフィルターを外して動作を再確認する。
この記事のポイント
- React 19実験の有効化でACFブロックの編集画面プレビューがエラーになる
- フロントエンドは影響を受けず、編集画面だけに症状が出る
- 管理画面のチェックが保存されない環境ではfunctions.phpから強制する
- ACFがReact 19に対応したらフィルターを外して再確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
CleanTalk更新後にサイトが落ちた時のFTP復旧と原因特定
CleanTalk（アンチスパムプラグイン）の更新後にサイト全体が表示されず、管理画面（wp-admin）にも入れなくなった場合は、FTPからプラグインフォルダの名前を変更して無効化するのが最短の復旧方法だ。アクセスを回復した後でエラーログを確認し、プラグインの再インストールや競合の切り分けを行えば原因を特定できる。
CleanTalk更新後にサイトが落ちる主な原因
CleanTalkはスパムコメントや迷惑メール送信を防ぐため、WordPressの全リクエストに介入して送信元IPアドレスをクラウド上の判定サーバーに照会する。この仕組みは強力だが、更新後のコードがサーバー環境と合わなかったり、ほかのプラグインと衝突したりすると、ページ表示の段階で致命的なエラーが発生する。
典型的な原因は次の通りだ。プラグイン更新時のファイル破損、PHPバージョンとの非互換、セキュリティ系プラグインやキャッシュプラグインとの競合、データベース上のテーブル定義差分、そしてCleanTalkのAPIサーバーに接続できないタイムアウトなどが考えられる。このうちどれが該当するかは、後述するエラーログの確認で絞り込める。
このデモはCleanTalk更新によってサイトが停止した状態と、FTPでの無効化による復旧後の状態を表している。更新のたびにページが落ちるのではなく、特定のバージョンや環境の組み合わせで起きることが多い。
FTPでプラグインを無効化してサイトを復旧する手順
管理画面に入れない状態では、サーバー上のファイルを直接操作してプラグインを無効化する以外に確実な方法はない。手順はシンプルで、FTPクライアントかレンタルサーバーのファイルマネージャーがあれば5分程度で完了する。焦らず順番に進めてほしい。
この手順はCleanTalkの主要フォルダ名を変更して、WordPressにプラグインを認識させない仕組みだ。以後の詳しい操作を各STEPに分けて説明する。
FTPクライアントでプラグインディレクトリへ接続する
FTPクライアント（FileZillaやWinSCPなど）を起動し、レンタルサーバーから発行されたFTPホスト名・ユーザー名・パスワードを使って接続する。接続後、サイトのドキュメントルートにあるwp-contentフォルダを開き、その中のpluginsフォルダへ移動する。レンタルサーバーの管理画面にあるファイルマネージャーでも同じ操作が可能だ。
CleanTalkのフォルダ名を変更して無効化する
pluginsフォルダ内にcleantalk-spam-protectというフォルダがある。これを選択してリネームし、末尾に-disabledや-offを付ける。フォルダ名を変えるだけでWordPressはプラグインを見失い、強制的に無効化される。これは「手動によるプラグイン無効化」と呼ばれ、管理画面が使えない時の最終手段として最も確実な方法だ。
サイトと管理画面へのアクセスを確認する
リネームが終わったらブラウザを開き直し、サイトのトップページとwp-adminの両方にアクセスする。正常に表示されれば復旧は成功だ。管理画面の「プラグイン」ページを開くと、CleanTalkが「無効化されています」と表示されるはずだ。ここで「削除」はまだ選ばず、原因調査に進む。
CleanTalkを安全に再有効化して原因を特定する手順
サイトが復旧したら、次はCleanTalkを再び使える状態に戻すための調査を行う。いきなり同じ設定で再有効化すると再発する可能性が高い。エラーログの確認、競合の切り分け、クリーンインストールの順で進めるのが安全だ。
WordPressのエラーログを確認する
まずwp-config.phpに以下の記述を追加してデバッグモードを有効化する。この設定により、ページ表示時に発生した具体的なエラー内容がログファイルに記録される。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );上書き保存後、wp-contentフォルダ内にdebug.logが生成される。この中に「PHP Fatal error」や「Uncaught Error」という行があれば、エラーの発生場所（ファイル名と行番号）が表示される。CleanTalk関連のパス（cleantalk-spam-protect）が含まれているか確認し、含まれていればそれが直接の原因だ。記録が終わったらデバッグモードは必ずfalseに戻す。
ほかのプラグインとの競合を切り分ける
CleanTalkを再有効化する前に、セキュリティ系プラグインとキャッシュ系プラグインを一時的に無効化してから試す。特にWordfenceやSucuriなどのセキュリティプラグイン、W3 Total CacheやWP Super Cacheなどのキャッシュプラグインは、CleanTalkのリクエスト監視と競合しやすい。標準テーマ（Twenty Twenty-Fiveなど）に切り替えた状態でCleanTalkを有効化し、問題が再現するかを確認すると環境の絞り込みが早い。
このデモは競合切り分けの基本フローを表している。すべてのプラグインを無効化した状態からスタートし、CleanTalkだけを先に有効化して問題がなければ、ほかのプラグインを1つずつ戻していく。
CleanTalkをクリーンインストールする
FTPでリネームしたフォルダを削除し、管理画面の「プラグイン」→「新規追加」から「Anti-Spam by CleanTalk」を検索して再インストールする。最新版が配布されており、以前のバージョンで発生していた不具合が修正されているケースも多い。インストール後、APIキー（CleanTalkのダッシュボードで発行されるアクセスキー）を再入力すれば設定はクリーンな状態から始められる。設定のバックアップがなくても、APIキーさえあればスパム対策の主要機能はすぐに再開される。
PHPとWordPressのバージョンを確認する
管理画面の「ツール」→「サイトヘルス」を開くと、現在のPHPバージョンとWordPressバージョンが表示される。CleanTalkが要求するPHPの最低バージョンを下回っている場合は、レンタルサーバーの管理画面からPHPバージョンを上げる操作が必要になる。PHP 8.3や8.4が最新系だが、ほかの古いプラグインとの兼ね合いも確認してから変更しよう。
更新トラブルを防ぐための設定と運用のポイント
CleanTalkに限らず、プラグインの自動更新が原因でサイトが落ちる事故は定期的に発生する。被害を最小限に抑えるには、更新前のバックアップ、ステージング環境での事前検証、自動更新の制御という3つの対策が有効だ。
更新前にバックアップを取る
レンタルサーバーが提供する自動バックアップに加えて、データベースとファイルの両方を手動で取得しておくと安心だ。管理画面が落ちてもFTPから復元できるため、今回のようなプラグイン停止事故から数分で元に戻せる。バックアッププラグインもこの目的に使えるが、プラグイン自体が競合の原因になり得るため、サーバー側のバックアップを優先するのが安全だ。
ステージング環境で更新を検証する
ビジネスで運用しているサイトでは、本番環境と同一構成のステージング環境（テスト用の複製サイト）を用意し、そこにプラグイン更新を適用して表示確認するのが理想だ。レンタルサーバーによっては管理画面からステージングサイトを簡単に作れる。更新後24時間以内に問題が起きなければ本番に反映する、という運用で更新事故の大半は防げる。
自動更新を制御する
WordPressではプラグインごとに自動更新の有効・無効を設定できる。更新直後にサイトが落ちた経験があるなら、CleanTalkの自動更新を無効化し、手動で更新する運用に切り替えるのが現実的な対策になる。自動更新を完全に止めるのではなく、メジャーアップデート（1.0→2.0など）は手動、マイナーアップデート（1.1→1.2など）は自動という使い分けも有効だ。
よくある質問
CleanTalkを無効化している間、スパム対策はどうなるか
CleanTalkを無効化している間は、スパムコメントや迷惑フォーム送信をブロックできなくなる。短期間のメンテナンス中は、WordPress標準の「コメントは管理者の承認が必要」設定や、Akismetなど別のアンチスパム機能で一時的にカバーする。運用上、数日程度の無効化であれば大きな被害にはなりにくいが、早めの再有効化を目指したい。
FTPの接続情報がわからない場合はどうするか
レンタルサーバーの管理画面にログインし、FTPアカウントの作成・確認ページを開けば、ホスト名・ユーザー名・パスワードを確認または再発行できる。管理画面のファイルマネージャー機能があればFTPクライアントは不要で、ブラウザ上でプラグインフォルダのリネームが可能だ。どちらも使えない場合は、サーバー運営会社のサポートに連絡して対応を依頼する。
CleanTalkを更新するたびにサイトが落ちるが、根本対策はあるか
更新のたびに症状が再発するなら、特定のプラグインとの組み合わせやサーバー環境に原因がある可能性が高い。エラーログに記録された発生場所をCleanTalkのサポートに報告し、修正版のリリースを待つか、設定項目で競合しやすい機能（スパムファイアウォールなど）を無効化して回避する。プラグインの更新を手動に切り替え、事前検証を徹底することも有効な根本対策になる。
复旧後にCleanTalkの設定は引き継がれるか
FTPでフォルダ名を変更しただけなら、設定はデータベースに残っているため、元のフォルダ名に戻せば従来の設定のまま再有効化される。一方、クリーンインストール（フォルダ削除→新規インストール）を行うと設定がリセットされるため、APIキーを再入力する必要がある。どちらを選ぶかは、問題の深刻度と設定の複雑さで判断するとよい。
この記事のポイント
- CleanTalk更新後にサイトが落ちたら、まずFTPでプラグインフォルダをリネームして無効化する
- 復旧後はエラーログ（debug.log）を確認し、発生場所を特定する
- 競合切り分けは全プラグイン無効化→CleanTalk単体で有効化→1つずつ戻す手順で行う
- クリーンインストールとPHPバージョン確認で再発を防ぐ
- バックアップ・ステージング環境・手動更新への切り替えが更新事故の根本対策になる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressからS3アップロードが失敗する署名エラーの直し方
WordPressのプラグインや自作コードからAWS S3へファイルをアップロードすると「SignatureDoesNotMatch」というエラーで失敗する場合、シグネチャ生成後にヘッダー名の大文字小文字が入れ替わっていることが代表的な原因だ。署名の計算時とリクエスト送信時でヘッダー名を完全に一致させると、この問題は解決する。
S3アップロードの署名エラーは何が起きているのか
AWS S3に対してファイルを直接アップロードする場合、多くのWordPressプラグインは「Presigned URL」や「署名付きリクエスト」を使う。これは、アクセスキーを直接ブラウザに渡さず、署名入りのURLやHTTPヘッダーを生成してアップロードを許可する仕組みだ。静的にサイトを書き出すプラグイン「Static Porter」もこの方式を採用している。
署名付きリクエストでは、リクエストの一部をSHA256でハッシュ化し、そのハッシュ値をシークレットキーで暗号化して「シグネチャ」を作る。S3側は同じ計算を再現し、シグネチャが一致するかどうかで正当性を検証する。ここで気をつけたいのは、署名の計算対象にHTTPヘッダー名も含まれる点だ。
つまり、署名を計算した時点で「content-type」という小文字のヘッダー名を使っていたのに、送信する直前に「Content-Type」と大文字に変更してしまうと、S3側の署名検証が失敗する。これが今回のエラーの正体だ。
Content-Typeの大文字小文字が署名を無効にする仕組み
AWSのSignature V4（署名バージョン4）では、署名の計算対象となる正規リクエストを作る際、ヘッダー名はそのままの文字列として扱われる。HTTPヘッダー名は本来大文字小文字を区別しないとされているが、署名計算の世界では「文字列として完全に一致していること」が要求される。
ここで問題になるのが、PHPの配列キーの扱いだ。PHPの連想配列はキーの大文字小文字を厳密に区別するため、「content-type」と「Content-Type」は別物として扱われる。署名を計算する関数に小文字の「content-type」を渡した後、別の場所で大文字の「Content-Type」を代入すると、配列には両方のキーが存在する状態になる。
wp_remote_requestがヘッダーを送信する際、どちらのキーが優先されるかは実装次第だ。しかし重要なのは、シグネチャの計算対象になったヘッダー名と、実際に送信されるヘッダー名が一致しなくなる点にある。S3はこの不一致を「署名が無効」と判定する。
上図の通り、シグネチャ生成時と送信時でヘッダー名の表記を揃えるだけで、署名検証のエラーは解消する。
署名エラーを直す具体的な修正手順
Static Porterのようにプラグイン内部のコードに起因する場合は、プラグインの更新で修正されるのを待つ以外にも、一時的なパッチを当てる方法がある。次の手順で問題箇所を特定し、修正する。
Static Porterの場合、問題が起きる箇所はプラグインのメインPHPファイル内で、MIMEタイプを推測した後にヘッダーを上書きしている行だ。
シグネチャ生成に渡したヘッダー配列を特定する
まず、プラグインのソースコードを開き、AWSの署名を計算している関数呼び出しを探す。Static Porterでは「static_porter_aws_sigv4」という関数だ。この関数に渡しているヘッダー配列には、小文字の「content-type」がキーとして含まれている。
署名の計算はこの配列を受け取った時点の内容で行われる。ここでのキー名を記憶しておくことが修正の基準になる。
送信前のヘッダー上書き処理を探す
署名を計算した後、wp_remote_requestに渡す直前に、ヘッダー配列へ新しい値を代入している行がないか確認する。今回のケースでは、次のようなコードが問題になる。
// 修正前のコード
$content_type = static_porter_guess_mime($file_path);
$headers = static_porter_aws_sigv4('PUT', $host, $uri, $region, 's3', $body, [
'content-type' => $content_type,
], $access_key, $secret_key);
$headers['Content-Type'] = $content_type; // ← ここで大文字キーが追加され署名と食い違う
$response = wp_remote_request('https://' . $host . $uri, [
'method' => 'PUT',
'headers' => $headers,
'body' => $body,
'timeout' => 60,
]);シグネチャ生成時には小文字の「content-type」を渡しているのに、その直後に大文字の「Content-Type」という別キーを代入している。これが署名不一致の直接の原因だ。
ヘッダー名のケースを署名側に合わせる
最も確実な修正は、シグネチャ生成時のヘッダー名と送信時のヘッダー名を完全に一致させることだ。今回のケースでは、シグネチャ生成時に小文字を使っているため、後から大文字キーを代入している行をコメントアウトするだけで解決する。
// 修正後のコード
$content_type = static_porter_guess_mime($file_path);
$headers = static_porter_aws_sigv4('PUT', $host, $uri, $region, 's3', $body, [
'content-type' => $content_type,
], $access_key, $secret_key);
// $headers['Content-Type'] = $content_type; // コメントアウトして小文字のまま送信する
$response = wp_remote_request('https://' . $host . $uri, [
'method' => 'PUT',
'headers' => $headers,
'body' => $body,
'timeout' => 60,
]);あるいは逆に、シグネチャ生成時のキーを大文字の「Content-Type」に統一し、後からの代入を削除する方法もある。どちらにせよ、署名を計算した時点と送信時点で同じヘッダー名を使うことが本質だ。
キャッシュをクリアして再テストする
コードを修正したら、WordPressのキャッシュプラグインやオブジェクトキャッシュをクリアし、実際にS3へのアップロードを実行して確認する。アップロード処理に署名済みURLがキャッシュされる仕組みがある場合は、古い署名が残っていないことも確認しておく。
プラグイン本体の編集は子テーマや別プラグインで安全に行う
プラグイン本体のPHPファイルを直接編集すると、プラグインのアップデート時に修正が上書きされて消える。長期的には、プラグイン開発者へバグ報告を出し、公式のアップデートで修正されるのを待つのが妥当だ。
どうしても動かす必要がある場合は、プラグインのコードを直接修正した上で、変更内容を記録しておくか、mu-plugin（Must Use Plugin）で代替処理を差し込む方法を検討する。
自作コードでS3署名を使う場合の落とし穴
プラグイン任せにせず、自前のPHPコードでS3への署名付きアップロードを実装している場合、同じような問題がいくつか潜んでいる。ここでは署名検証が失敗する主なパターンを整理する。
ホスト名とURIの不一致
シグネチャの計算対象には、エンドポイントのホスト名とパス（URI）が含まれる。バケット名のリージョン表記や、URLエンコードの有無、末尾のスラッシュの扱いが違うだけで署名は別物になる。署名を作る関数と実際にリクエストを送るURLが完全に一致しているか確認する。
ボディの変更によるシグネチャ崩れ
S3のPUTリクエストでは、アップロードするファイルのバイナリデータをそのままボディとして署名に含める。署名を計算した後に、余計な空白や改行、文字コード変換が入るとボディが変化し、署名検証に失敗する。ファイルはバイナリのまま扱い、加工しないことが基本だ。
タイムスタンプのスキュー
Signature V4は、リクエスト日時を署名に含める。サーバーのシステムクロックが大幅にずれていると、S3側が「リクエストが古すぎる」と判断して拒否する。エラーメッセージに時刻に関する記述がある場合は、サーバーの時刻同期（NTP）を確認する。
よくある質問
S3の署名エラーとアクセス権限エラーの違いは何か
署名エラーは「SignatureDoesNotMatch」や「The request signature we calculated does not match」と表示され、リクエスト内容が署名と食い違っていることを示す。一方、権限エラーは「AccessDenied」や「403 Forbidden」の形で、署名自体は正しいがIAMポリシーで操作が許可されていないことを示す。エラーコードを見分けることが切り分けの第一歩だ。
プラグインをアップデートしたらS3アップロードが壊れた場合はどうするか
プラグインのアップデートで内部実装が変わった可能性が高い。まずはプラグインの変更履歴（チャンジログ）を確認し、S3関連の修正が入っているか調べる。問題が再現するなら、1つ前のバージョンへ戻して切り分けるのが確実だ。プラグインのフォーラムやGitHubリポジトリで同様の報告が上がっていないかも確認する。
PHPのHTTPヘッダー名は大文字小文字を区別するのか
HTTPの仕様上、ヘッダー名は本来大文字小文字を区別しない。だが、AWSの署名計算は「文字列としての完全一致」を要求するため、区別される。PHPの配列キーも「content-type」と「Content-Type」は別物として扱われる。この2つの事情が重なって問題が起きる。
wp_remote_requestのheaders配列で小文字を使っても動作するのか
WordPressのHTTP APIはHTTPヘッダー名の大文字小文字をある程度正規化する。しかし、S3への署名付きリクエストでは、署名計算時のヘッダー名と食い違うと検証に失敗する。小文字で署名したなら小文字のまま渡すのが安全だ。
AWS SDKを直接使うほうが安全なのか
AWS SDK for PHPを使えば、シグネチャ生成と送信の整合性をライブラリが保証するため、今回のような手動ミスは起きにくい。ただし、SDKを導入すると依存関係が増え、WordPressとの相性も考える必要がある。小規模なアップロード機能なら、シグネチャ生成を手動で実装しつつ、ヘッダー名の一致を徹底する方がシンプルな場合もある。
この記事のポイント
- S3の署名エラーはヘッダー名の大文字小文字不一致が原因になりやすい
- シグネチャ生成時と送信時でヘッダー名を完全に一致させる
- 問題のある代入行をコメントアウトするだけで多くの場合解決する
- プラグイン本体の直接編集はアップデートで消えるため要注意
- 自作コードではホスト名やボディ、時刻ずれにも気をつける
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
TablePress 3.4更新後にテーブルが表示されない時の原因と安全な復旧手順
TablePress 3.4に更新した後にテーブルがショートコード [table id=28 /] のまま表示されない場合、まずプラグインが停止しているか、ショートコードの処理が途中で失敗しているかを確認する。サイト内検索まで動作しなくなったケースでは、古いテーブルデータの保存形式に不整合が起きている可能性が高いが、バックアップを取ればデータを失わずに復旧できる。
TablePress 3.4への更新後にテーブルが表示されない原因
TablePress は、投稿や固定ページに書かれた [table id=28 /] というショートコードを、実際の表の HTML に置き換えて表示する仕組みになっている。プラグインが無効化されていたり、更新の途中で停止していたりすると、この置き換えが行われず、ショートコードがそのまま画面に出る。
更新直後にショートコードだけが見える症状と、プラグイン停止という原因の関係を表したものだ。停止が原因なら再有効化だけで表は戻る。
ショートコードがそのまま表示される仕組み
ショートコードは、WordPress のプラグインがページ表示のタイミングで処理する仮の置き場だ。TablePress が有効な状態なら表に変換されるが、無効になると [table id=28 /] という文字列が読者に見えてしまう。更新後にこの症状が出た場合は、更新処理が最後まで完了せずプラグインが自動で停止したケースが多い。
更新後にプラグインが自動で停止していないか確認する
WordPress の管理画面で「プラグイン」メニューを開き、TablePress の状態を確認する。「有効化」ボタンが表示されていれば、更新後に何らかの理由で停止している。まず一時的に有効化し、テストページで表が表示されるか、サイト内検索が動くかを順に確かめる。
なぜ更新後にサイト内検索が動かなくなったのか
TablePress のデータは、WordPress の投稿と同じデータベースの wp_posts テーブルに保存されている。テーブル本体は JSON という書式で格納されるため、3.4 更新後に古い形式のデータを読み込む処理が変わると、サイト全体の投稿一覧や検索クエリにエラーを引き起こすことがある。特に公開サイトの検索フォームが正常に動作しなくなる症状が報告されている。
古いテーブルデータの保存形式と不整合のリスク
長年運用してきたサイトでは、TablePress が過去に保存したテーブルデータが現在の期待する形式と異なる場合がある。3.4 ではテーブルの読み込み処理が更新されたため、旧形式のデータをそのまま読み込むと PHP の警告や致命的エラーが発生し、結果として検索機能まで落ちることがある。
検索が壊れたときはプラグイン切り分けで特定する
TablePress を無効化して検索が復活したなら、原因は TablePress 側にある可能性が高い。より正確に切り分けるには、TablePress を有効化したままテーブルを1つずつ再保存し、どのテーブルで検索が止まるかを調べる。これにより、データの破損箇所を特定できる。
バックアップを取ったうえで安全に復旧する手順
復旧作業は、必ず現状のバックアップを確認してから進める。ショートコードが表示されたままの公開ページを放置せず、次の手順で原因の切り分けと復旧を行う。
復旧の作業は5段階で進める。いきなり全テーブルを変更せず、表示と検索を細かく確認しながら原因を絞り込むのが安全だ。
復旧前に実施するバックアップの確認
UpdraftPlus のようなバックアッププラグインで、サイト全体とデータベースのバックアップが最新であることを確認する。バックアップの復元方法も1度確認しておくと、万が一テーブルデータを誤って書き換えても元に戻せる。
プラグインの再有効化と表示確認
プラグイン画面で TablePress を有効化し、問題が出ているページを1つだけ開いて表が表示されるか確認する。このときサイト全体のキャッシュが残っていると古い画面が見えるため、シークレットウィンドウや別ブラウザで確認すると正確だ。
古いテーブルを1つずつ再保存して切り分ける
TablePress の管理画面で「テーブル一覧」を開き、公開している各テーブルを編集画面で開いて「変更を保存」を押す。再保存で現在の形式にデータが整い、古い形式に起因するエラーが解消されることが多い。1つ保存するたびに検索が動くかを確認すれば、問題のあるテーブルを特定できる。
ブラウザとサイトのキャッシュを削除して再確認
再保存後も症状が続く場合は、WordPress のキャッシュ系プラグインやサーバー側のキャッシュを削除し、ブラウザのキャッシュもクリアする。キャッシュが残ったままだと、修正後の状態を確認できない。
古いテーブルデータの不整合を調べて修正する方法
古いテーブルデータの不整合が原因で検索まで壊れた場合は、テーブルを再保存するだけでなく、データの中身を直接確認する方法も有効だ。焦らず1つずつ確認すれば、過去の歴史データを失わずに済む。
どのテーブルが古い形式かを特定する方法
TablePress のテーブル一覧で、更新日時が古いテーブルや、長期間編集していないテーブルを優先して確認する。古い形式のデータは、特に大量の行を持つテーブルで問題を起こしやすい。まず行数の多いテーブルから再保存を試す。
JSONデータの破損を修復する手順
TablePress のテーブルは JSON 形式でデータベースに保存されている。破損が疑われる場合は、TablePress の「エクスポート」機能で CSV として書き出し、内容を確認してから新しいテーブルとして読み込む。これにより JSON の構造が新しく作り直され、破損が解消される。
エクスポートと再インポートでデータを整える
元テーブルをエクスポートして CSV を保存し、TablePress の「インポート」で新しいテーブルとして取り込む。取り込み後にショートコードの ID が変わらないよう、元のテーブルを削除して同じ ID に割り当てるか、元テーブルを編集して CSV を貼り直す。ID を変えたくない場合は、テーブル編集画面で内容を丸ごと貼り直すのが安全だ。
旧バージョンへ戻す一時的な対処と再更新の判断
場合によっては、TablePress 3.4 自体の不具合が原因で、データを整えても検索や表示が直らないことがある。その場合は旧バージョンへ戻して一時的に安定させ、修正版のリリースを待つのが現実的な選択になる。
旧バージョンを入手して手動で戻す手順
WordPress.org の TablePress プラグインページにある「詳細を表示」から過去のバージョンを取得する。管理画面の「プラグイン > 新規追加 > プラグインのアップロード」で旧バージョンの ZIP をアップロードすると、現在のバージョンを上書きして戻せる。アップロード前には必ずバックアップを取り直す。
ロールバック後に再度更新するタイミング
旧バージョンへ戻したら、WordPress の更新通知で TablePress 3.4 の修正版が出るまで自動更新を止めておくことも検討する。修正版が公開されたら、テスト環境か深夜の時間帯で更新し、表示と検索を再確認してから本番に適用する。
よくある質問
TablePress を再有効化したら検索が再び壊れるのでは？
まずテーブルを1つずつ再保存してから検索を確認すれば、問題のあるテーブルだけを特定できる。再保存後も検索が壊れるなら、旧バージョンへ戻すか、プラグインの修正版を待つ。バックアップがあれば元に戻せるため、慌てて全データを消す必要はない。
古いテーブルだけが表示されないのはなぜか
古いテーブルはデータの保存形式が現在の TablePress と一致していない場合がある。編集画面で開いて保存し直すと現在の形式に変換され、表示されるようになることが多い。
TablePress を無効化したままでもデータは消えないか
プラグインを無効化しても、テーブルのデータはデータベースに残る。プラグインを削除しない限り過去のデータは保持される。ただし安全のため、無効化中もバックアップを取っておく。
ショートコードが表示されたまま放置するリスクは？
訪問者に [table id=28 /] という文字列が見え続けると、サイトの信頼性が下がる。検索エンジンのクローラーも表の内容を取得できないため、早めに再有効化か代替表示へ切り替える。
キャッシュ系プラグインを使っている場合の注意点は？
修正後も古い画面が表示され続ける場合は、キャッシュ系プラグインの全キャッシュ削除とブラウザのキャッシュクリアを行う。サーバー側のキャッシュが残っていることもあるため、ホスティングの管理画面も確認する。
この記事のポイント
- 更新後にショートコードが見えるのはプラグイン停止が主な原因
- まずバックアップを確認し、それから再有効化する
- 検索が壊れた場合は古いテーブルデータの不整合を疑う
- テーブルを1つずつ再保存して問題箇所を特定する
- 直らないときは旧バージョンへ戻して修正版を待つ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
セキュリティプラグインがテーマファイルを隔離してサイトが表示されない時の復旧手順
セキュリティプラグインが BeTheme の必須ファイルを誤検知して隔離し、WordPress サイトが表示されなくなった場合、まず隔離画面から「復元」を実行し、失敗したら FTP やバックアップから theme-shortcodes.php を戻す。その後キャッシュを削除してテーマが有効であることを確認すれば、サイトは復旧する。
なぜテーマファイルの隔離でサイト全体が表示されなくなるのか
WordPress はアクセスがあるたびに、有効化しているテーマの functions.php と、そのテーマが読み込む必須ファイルを実行する。BeTheme の場合、テーマ本体が theme-shortcodes.php を include して短コードの定義などを登録している。このファイルが隔離で消えると、PHP の致命的エラーが発生してページ全体が止まる。
セキュリティプラグインの隔離機能は、怪しいと判定したファイルを元の場所から移動するか、拡張子を変えて読み込めない状態にする。マルウェア対策としては有効だが、正規のテーマファイルを誤検知すると、テーマごと起動できなくなる。同様のことはテーマだけでなく、プラグインの必須ファイルでも起こる。
その結果、画面には「このサイトで重大なエラーが発生しました」という趣旨のエラーが表示されるか、真っ白な画面になる。管理画面にも入れないケースが多いため、復旧はサーバー側からの操作が中心になる。
WordPress が BeTheme の functions から theme-shortcodes.php を読み込み、サイトが表示される
theme-shortcodes.php が見つからず PHP の致命的エラーになる。サイトは「重大なエラー」で表示不可
テーマ必須ファイルの隔離前と隔離後の状態の違いを示す。
隔離されたファイルを復元する2つの方法
隔離されたテーマファイルの復元は、セキュリティプラグインの管理画面から試す方法と、FTP やバックアップから直接戻す方法の 2 通りある。まず隔離画面から復元し、エラーになる場合は後者を使う。
ファイル復旧からサイト表示確認までの全体の流れを 4 ステップで示す。
セキュリティプラグインの隔離画面から復元する
CleanTalk のセキュリティ機能では、管理画面のセキュリティメニューから隔離タブを開くと、隔離したファイルの一覧が表示される。各ファイルには「復元」または「Restore」ボタンがあるので、該当の theme-shortcodes.php を選んで復元を実行する。
復元に失敗し「エラーが発生しました」「テクニカルサポートに連絡してください」という趣旨の表示が出る場合、プラグイン側でファイルを書き戻す権限が足りないか、隔離時のコピーが壊れている可能性がある。この状態ではプラグイン画面からの復元はあきらめ、次の方法に移るのが早い。
FTP やバックアップから対象ファイルを直接戻す
FTP クライアントでサーバーに接続し、/wp-content/themes/betheme/functions/ ディレクトリを開く。theme-shortcodes.php が存在しないか、拡張子が .quarantine や .bak のように変わっていないかを確認する。ファイルが残っているのに WordPress が読み込めない場合は、正規のバックアップから同じファイルを上書きアップロードする。
バックアップがない場合は、公式の配布元から BeTheme の同じバージョンの zip を入手し、functions フォルダだけをアップロードする。テーマ全体を上書きしても問題はないが、親テーマの functions.php に直接コードを追記していた場合は消えるため、事前にバックアップを取っておく。子テーマを使っていればカスタマイズは残る。
ファイルを復元してもサイトが表示されない時の確認手順
ファイルの復元が終わってもサイトが真っ白なまま、またはエラーが続く場合、残っているキャッシュやテーマの有効状態、ファイル権限が原因になっていることが多い。次の順で確認する。
キャッシュをすべて削除する
ブラウザのキャッシュに加えて、WordPress のキャッシュプラグイン、サーバー側のキャッシュ、CDN のキャッシュをすべてクリアする。復元したファイルが正しくても、キャッシュに残ったエラーページや読み込み失敗の状態が配信され続けると、ブラウザではサイトが壊れたままに見える。
キャッシュプラグインが管理画面から操作できない場合は、wp-content/cache/ ディレクトリの中身を FTP で削除する。サーバー側のキャッシュはコントロールパネルからクリアし、CDN を使っている場合は配信側のキャッシュ削除も必要になる。
テーマが有効なままかを確認する
WordPress はアクティブなテーマの必須ファイルが読み込めないと、テーマを無効化して標準テーマにフォールバックすることがある。管理画面の「外観」から「テーマ」を開き、BeTheme がアクティブのままか確認する。別のテーマになっていれば BeTheme を再度有効化する。
wp-content/themes/ 配下のフォルダ名がリネームされている場合も同じ事象が起こる。隔離機能がファイルを移動したのか、フォルダ名を変えたのかはサーバー側で確認する。フォルダ名が変わっていれば正しい名前に戻す。
ファイルの権限と所有者を確認する
FTP で復元したファイルのパーミッションが適切でないと、WordPress が読み込めないことがある。PHP ファイルの権限は一般的に 644、ディレクトリは 755 に設定する。レンタルサーバーの場合、ファイルの所有者が FTP ユーザーとウェブサーバープロセスで異なると読み込みに失敗するため、サーバーのコントロールパネルで所有者も確認する。
エラーログで失敗原因を特定する
それでも復旧しない場合は、サーバーのエラーログを見て PHP がどのファイルの読み込みに失敗しているかを特定する。wp-config.php にデバッグ設定を追加してエラーをログに出力させると、どの行で止まっているかが確認できる。
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);誤検知を防いで再発させないための設定
正規のテーマやプラグインが隔離される事故を防ぐには、信頼できるファイルをスキャンの除外リストに登録し、バックアップ体制を整えておく。誤検知は一度きりとは限らないため、同じファイルが再度隔離される可能性も考えておく。
誤検知したファイルをスキャン対象から除外する
CleanTalk のセキュリティ機能を使っている場合、誤検知したファイルをスキャンのホワイトリストに追加できる。管理画面のセキュリティ設定から「除外」または「無視リスト」を開き、隔離されたファイルのパスを登録する。テーマ全体を除外するとセキュリティの効果が薄れるため、対象ファイルだけを追加するのが基本だ。
テーマとプラグインは公式の配布元から入手して更新する
マーケットや公式ディレクトリ以外から入手したテーマには、改ざんされたファイルが含まれていることがある。BeTheme は公式の配布元からのダウンロードに限定し、アップデートが配信されたらすぐに適用する。正規のファイルが最新の状態なら、セキュリティスキャナーが誤検知する確率も下がる。
復旧に使えるバックアップを毎日残す
誤検知でサイトが落ちた場合、最短の復旧手段はバックアップからのファイル復元だ。レンタルサーバーの自動バックアップに加えて、WordPress のバックアッププラグインで週 1 回以上のフルバックアップを取っておく。バックアップの保存先はサーバー内だけでなく、外部ストレージにも残すとより安全だ。
よくある質問
セキュリティプラグインがテーマファイルを隔離するのはなぜ？
マルウェアスキャンがファイルのコードパターンを怪しいと判定したためだ。正規のテーマでも、短コードを定義するコードや eval に似た記述があると誤検知されやすい。BeTheme の theme-shortcodes.php は短コードを大量に登録するファイルで、この種の誤検知が起こりやすい。
隔離解除ボタンを押してもエラーになる理由は？
多くはファイルを書き戻す権限の問題だ。サーバーのディレクトリ権限が狭い、ファイル所有者が違う、隔離時の一時ファイルが壊れているなどの理由が考えられる。この場合 FTP やバックアップから手動で戻すのが確実だ。
FTP が使えないサーバーの場合は？
レンタルサーバーのコントロールパネルにファイルマネージャーがあるなら、それでファイルをアップロードできる。それも難しい場合は、サーバー会社のサポートに連絡し、隔離されたファイルの復元と権限確認を依頼する。
テーマを再インストールするとカスタマイズは消える？
親テーマのファイルを上書きするだけなら、データベースに保存されたカスタマイザー設定は残る。ただし親テーマの functions.php に直接コードを追記していた場合は消えるため、事前にバックアップを必ず取ってから行う。子テーマを使っていれば安全だ。
管理画面にも入れなくなった場合は？
FTP でテーマフォルダの名前を一時的に変えると、WordPress が自動的に標準テーマへ切り替えて管理画面に入れるようになる。その後、正しいファイルを戻してからテーマを再度有効化する。
この記事のポイント
- セキュリティプラグインの隔離でテーマの必須ファイルが消えるとサイト全体が停止する
- まず隔離画面から復元し、失敗したら FTP かバックアップで対象ファイルを戻す
- 復元後はブラウザ・プラグイン・サーバーのキャッシュをすべて削除する
- テーマが有効なままか、ファイルの権限が正しいかを確認する
- 誤検知したファイルはスキャンの除外リストに登録して再発を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressでwp-adminとwp-login.phpがトップページにリダイレクトされる原因と対処法
WordPressでwp-adminやwp-login.phpにアクセスしてもトップページへリダイレクトされる場合、原因はセキュリティプラグインによるログインURLの変更、.htaccessのリダイレクト設定、またはCloudflareのページルールであることが多い。ホスティング管理画面にアクセスできない状態でも、まずは非表示ログインURLの候補を順に試し、解決しなければホスティング会社に所有証明を添えて連絡するのが最も確実な復旧経路だ。
なぜwp-adminとwp-login.phpがトップページへ飛ばされるのか
ログインページへのアクセスがホームページへリダイレクトされる症状には、いくつか典型的な原因がある。最も多いのがセキュリティプラグインやログインURL変更プラグインによるURLの秘匿化だ。Elementorなどのページビルダーがログインリダイレクトを引き起こすことはほとんどないため、まずはセキュリティ機能まわりを疑う。
セキュリティプラグインによるログインURLの変更
WPS Hide Login、iThemes Security、All In One WP Securityなどのプラグインは、ログインページのURLを任意の文字列に変更できる。デフォルトのwp-login.phpやwp-adminを無効化し、たとえば「/login/」や「/member/」など開発者が設定したURLだけを有効にする。この機能が有効な状態では、元のURLにアクセスするとホームページへリダイレクトされるのが一般的な挙動だ。
.htaccessに記述されたリダイレクトルール
サーバーの.htaccessファイル（Apacheの設定ファイル）に、wp-adminやwp-login.phpを対象にしたリダイレクトルールが記述されているケースもある。セキュリティ対策として意図的に追加された場合と、不正アクセスによる改ざんの両方が考えられる。改ざんの場合は他のファイルにも不正なコードが仕込まれている可能性があるため、注意が必要だ。
CloudflareのページルールやWAF設定
ドメインのネームサーバーがCloudflareに向いている場合、Cloudflare側のページルールやWAF（Webアプリケーションファイアウォール）のカスタムルールがwp-adminやwp-login.phpへのアクセスをブロックまたはリダイレクトしている可能性もある。Cloudflareの管理画面にアクセスできなければこの設定を確認できないため、原因の切り分けが難しくなる。
カスタムコードによるリダイレクト
テーマのfunctions.phpやmu-plugins（マストユースプラグイン、プラグイン画面から無効化できない自動有効プラグイン）に、ログインURLをリダイレクトするカスタムコードが書かれていることもある。制作会社やフリーランスの開発者がセキュリティ目的で追加するケースが多く、ドキュメントが残っていないと原因の特定に時間がかかる。
ホスティングにアクセスできない時にできる確認と対処
ホスティング管理画面もCloudflareも使えない状況でも、できる確認は残っている。順番に試していくことで、サーバーに触らずにログインできるケースもある。下の図は復旧までの流れをまとめたものだ。
ホスティングやCloudflareにアクセスできない状態で行う確認の流れ。非表示URL候補の試行から始め、それで解決しなければホスティング会社への直接連絡に進む。
非表示ログインURLの候補を順番に試す
ログインURL変更プラグインが使われている場合、実際のログインページはデフォルトのwp-adminやwp-login.phpではない。よく使われる候補として「/login/」「/admin/」「/dashboard/」「/member/」「/members/」「/my-account/」「/wp-login.php?redirect_to=/wp-admin/」などがある。サイトのURLの末尾にこれらを付けて、ログイン画面が表示されるかを確認する。
また、サイトのフッターやお問い合わせページにログインリンクが設置されていないかも確認する。リンク先が非表示ログインURLになっていることがある。サイト内検索で「login」「ログイン」という文字列を探すのも有効だ。
シークレットウィンドウでキャッシュとクッキーの影響を排除する
ブラウザのキャッシュやクッキーが原因でリダイレクトが発生している可能性を排除するため、シークレットウィンドウ（プライベートブラウジング）で同じURLにアクセスする。シークレットウィンドウでも同じ症状が出るなら、ブラウザ側のキャッシュではなくサーバー側の設定が原因だと判断できる。
検索エンジンのキャッシュから過去のログインページを探す
GoogleやBingのキャッシュに、過去のログインページのURLが残っていることがある。検索エンジンで「site:example.com ログイン」や「site:example.com wp-admin」のように検索すると、過去にインデックスされたログイン関連ページが見つかる場合がある。キャッシュされたURLが非表示ログインURLの手がかりになる。
ホスティング会社に直接連絡して管理アクセスを取り戻す手順
ログインURLの候補を試しても解決せず、開発者にも連絡がつかない場合、ホスティング会社に直接連絡して管理アクセスを取り戻すのが最も確実な方法だ。契約者が誰であっても、所有証明を提示すれば対応を受けられるケースが多い。
所有証明書類を準備する
ホスティング会社に連絡する前に、サイトの所有者であることを証明できる書類を準備する。具体的にはホスティングやドメインの契約時の請求書、支払い明細、クレジットカードの利用履歴、登録メールアドレスに届いた契約確認メールなどだ。ドメインのwhois情報に自分の名前が登録されていれば、それも有力な証明になる。
サポート窓口に状況を正確に伝える
ホスティング会社のサポート窓口（電話、チャット、メールフォーム）に連絡し、次の3点を簡潔に伝える。「サイトのドメイン名」「wp-adminがホームページへリダイレクトされてログインできない状況」「開発者が管理しているため管理画面のログイン情報を持っていないこと」。所有証明を求められたら、準備した書類を提示する。
アクセス回復後に依頼する作業
ホスティング会社から管理画面やFTPのアクセス権を回復したら、次の作業を依頼するか自分で行う。まず.htaccessファイルのバックアップを取り、リダイレクトルールの有無を確認する。次にwp-content/plugins/ディレクトリを一時的に別名にリネームして全プラグインを無効化し、ログインできるか試す。これが原因の切り分けとして最も確実な手順だ。
サーバーアクセスを回復した後に直すべき箇所
サーバーやFTPにアクセスできるようになったら、原因箇所を特定して修正する。下の図は.htaccessの修正前後のイメージだ。
RewriteRule ^wp-admin$ / [R=301,L]
RewriteRule ^wp-login\.php$ / [R=301,L]
# WordPress デフォルトのルールのみ残す
.htaccessのリダイレクトルールを削除することで、wp-adminとwp-login.phpへのアクセスが正常に戻るイメージ。変更前に必ずファイルのバックアップを取る。
.htaccessを確認してリダイレクト設定を削除する
FTPクライアントやファイルマネージャーでサーバーに接続し、WordPressのルートディレクトリ（通常はpublic_htmlまたはドメイン名のフォルダ）にある.htaccessファイルをダウンロードする。ファイルを開き、wp-adminやwp-login.phpを対象にしたRewriteRule（リライトルール、URL変換の設定）が記述されていないかを確認する。該当する行があれば削除して上書きアップロードする。
セキュリティプラグインを無効化して切り分ける
.htaccessに問題が見つからない場合、FTPでwp-content/plugins/ディレクトリの名前を一時的に変更する（例、plugins → plugins_bak）。これで全プラグインが無効化される。その後wp-adminにアクセスしてログイン画面が表示されるかを確認する。表示されればプラグインが原因だ。プラグインディレクトリを元の名前に戻し、セキュリティ系プラグインを1つずつ無効化しながら原因を特定する。
wp-config.phpとデータベースの設定を確認する
wp-config.phpに、ログインURLを変更する定数（WP_ADMIN_DIRやWP_HOME、WP_SITEURLなど）が追加されていないかも確認する。また、データベースのwp_optionsテーブルにあるsiteurlとhomeの値が実際のサイトURLと一致しているかを確認する。これらが不整合を起こしていると、リダイレクトループが発生することがある。
ログインページが飛ばされないための再発防止策
ログインページにアクセスできなくなる問題は、適切なアクセス管理とドキュメント化で再発を防げる。とくに外部の開発者に管理を委託している場合は、以下の対策を講じておくことが重要だ。
ログインURLの変更内容を記録して共有する
ログインURLを変更するプラグインを使う場合、変更後のURLを必ずドキュメントに記録し、サイト所有者と開発者の両方で共有しておく。パスワード管理ツールにログインURLと資格情報をまとめて保管するのが実用的だ。URL変更の設定をしたこと自体を忘れてしまうと、今回のようにログイン画面へ到達できなくなる。
ホスティングとドメイン管理へのアクセス権を確保する
サイト運営者自身がホスティング管理画面とドメイン管理画面のログイン情報を保持していない状況は、サイトの所有権を実質的に手放しているのと同じだ。開発者に管理を委託する場合でも、管理者アカウントの追加権限だけは共有してもらい、緊急時にアクセスできる状態を維持する。
定期的なバックアップと復旧手順の確認
ログインページがリダイレクトされる問題に限らず、サイトのトラブル全般に備えて定期的なバックアップを取得しておく。バックアップからの復旧手順も一度シミュレーションしておくと、緊急時に慌てずに対処できる。バックアップに含めるのはデータベースとwp-contentディレクトリの両方だ。
よくある質問
セキュリティプラグインを入れていないのにリダイレクトされるのはなぜ？
セキュリティプラグインがなくても、.htaccessのリダイレクトルール、Cloudflareのページルール、テーマのfunctions.phpに書かれたカスタムコードが原因になる。また、サイトが改ざんされている場合は、不正なコードがリダイレクトを引き起こしている可能性もある。サーバーのファイルを直接確認するのが確実な切り分け方法だ。
ホスティング会社に連絡する時に何を伝えればよい？
ドメイン名、wp-adminがホームページへリダイレクトされる状況、管理画面のログイン情報を持っていないことの3点を伝える。所有証明として請求書や支払い明細、契約確認メールを求められた場合に備えて準備しておく。whois情報に自分の名前が登録されていればそれも提示できる。
Cloudflareのページルールが原因だった場合、どうすればよい？
Cloudflareの管理画面にアクセスできるなら、ページルールとWAFのカスタムルールを確認し、wp-adminとwp-login.phpを対象にしたブロックやリダイレクト設定を無効化する。アクセスできない場合は、Cloudflareのサポートに所有証明を提示してアクセス回復を依頼する。ドメインのwhois情報が自分名義であれば回復できる可能性が高い。
ログインURLを変更した覚えがないのに変更されていた場合、ハッキングの可能性は？
可能性はある。サイトの改ざんによって.htaccessやfunctions.phpにリダイレクトコードが仕込まれたケースも報告されている。ログインできるようになったら、WordfenceやSucuriなどのセキュリティプラグインでスキャンを実行し、不審なファイルや管理者ユーザーがいないかを確認する。パスワードの全面変更も推奨される。
開発者に連絡がつかないままサイトを移管するには？
ホスティング会社からFTPと管理画面のアクセス権を取得したら、データベースのエクスポートとwp-contentディレクトリのダウンロードを行い、新しい環境へ移管する。DNS設定を変更して新しいサーバーに向ける。ドメインの管理権限が自分にあれば、移管は比較的スムーズに進む。旧環境の支払いが止まってサイトが消失する前に、早めの移管作業が重要だ。
この記事のポイント
- wp-adminとwp-login.phpがホームへリダイレクトされる主因はセキュリティプラグインのURL変更、.htaccess、Cloudflare設定
- ホスティングなしでも非表示ログインURLの候補試行やシークレットウィンドウ確認は可能
- 開発者に連絡がつかない場合はホスティング会社へ所有証明を添えて直接連絡する
- サーバーアクセス回復後は.htaccess確認とプラグイン無効化による切り分けが有効
- 再発防止にはログインURLの記録共有とホスティング管理権の自己保持が欠かせない
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress管理画面でトグル設定が勝手にオンに戻る時の原因と対処法
WordPress管理画面のトグル設定をオフにしても勝手にオンに戻る場合、原因は主にJavaScriptエラーかキャッシュの不整合にある。トラッキング不具合時の診断メール設定が保存されない症状では、画面の表示とデータベースの値がずれている可能性が高く、切り分け手順を順に試すことが最も確実な対処法だ。
トグル設定が勝手にオンへ戻るのはなぜか
WordPressの管理画面にあるトグルボタンは、押した瞬間にAJAX通信でサーバーへ設定値を送信する仕組みだ。送信された値はnonce検証を経てデータベースに保存される。ここで問題が起きると、画面上ではオフに切り替わったように見えても、データベースには保存されないままになる。
別のページへ移動して戻った時、画面はデータベースから最新の設定値を読み込む。保存が失敗していれば、以前の値がそのまま表示されるためトグルがオンへ戻ったように見える。これが今回の症状の正体だ。
特に「トラッキング不具合時の診断メール」のような通知系の設定は、プラグイン側がデフォルトでオンにする仕様になっている場合がある。保存の失敗とデフォルト値の再適用が重なると、オフにしても戻るという挙動が顕著に現れる。
原因になりやすい要素は以下のとおりだ。
- 管理画面でJavaScriptエラーが発生しAJAX送信が失敗している
- キャッシュプラグインやオブジェクトキャッシュが古い設定値を返している
- テーマや別のプラグインが設定を強制的にオンへ戻している
- セキュリティプラグインがnonce検証やAJAX通信をブロックしている
- データベースへの書き込み権限やオプション保存処理に問題がある
このデモはトグル設定の保存が正常に終わる場合と、途中で失敗して次回表示時に設定が戻ってしまう場合のフローを示している。次節からは原因を特定するための手順を具体的に進めていく。
JavaScriptエラーをブラウザで確認する手順
最初に確認するべきは管理画面でJavaScriptエラーが発生していないかだ。ブラウザの開発者ツールを使えば、AJAX通信が失敗した原因を直接確認できる。Chromeの場合はF12キー、Macの場合はCommand＋Option＋I、Windowsの場合はCtrl＋Shift＋Iで開発者ツールが開く。
開発者ツールが開いたらConsoleタブに切り替える。ここに赤いエラーメッセージが表示されていれば、それがトグル設定の保存を妨げている原因になる。特に「FAILED」「POST」「403」「500」のような表示がある場合は、AJAX通信そのものが失敗している証拠だ。
エラーが確認できた場合は、エラーメッセージの内容を控えておく。ファイル名や関数名が表示されていれば、どのプラグインやテーマがエラーの原因かを特定する手がかりになる。調査を次の段階へ進める前に、まずはエラーの有無を確認するだけで状況が大きく変わる。
このデモはJavaScriptエラーの確認から発生源の特定までを順に示している。トグル操作を再現してエラーが増える場合は、そのトグルに関連するスクリプトでエラーが起きている可能性が高い。
キャッシュを削除して保存状態を確認する方法
JavaScriptエラーが見つからない場合はキャッシュの影響を疑う。サイト全体のキャッシュを削除してからトグル設定を再度オフにし、別ページへ移動して戻るという流れで確認する。WordPressでは複数のキャッシュ層が重なっていることがあり、それぞれを順にクリアする必要がある。
キャッシュプラグインのキャッシュを削除する
キャッシュプラグインを利用している場合は、プラグインの管理画面からキャッシュを全削除する。代表的なプラグインでは「キャッシュを消去」「Purge All」のようなボタンが用意されている。削除後、トグル設定をオフにして別ページへ移動し、戻って状態を確認する。
オブジェクトキャッシュを無効化して確認する
高速化のためにRedisやMemcachedといったオブジェクトキャッシュを導入している場合は、一時的に無効化して確認する。オブジェクトキャッシュはデータベースの値をメモリ上に保持するため、更新処理が古い値を返し続けてしまうことがある。wp-config.phpに記載されているキャッシュ関連の設定を一時的に外すか、サーバー側のキャッシュサービスを停止してテストする。
ブラウザキャッシュを削除する
ブラウザ側のキャッシュが管理画面の表示に影響することは少ないが、シークレットウィンドウを使えば完全にキャッシュの影響を排除できる。シークレットウィンドウで管理画面へログインし、トグル設定をオフに変更してから別ページへ移動し、再度戻って状態を確認する。この方法で問題が再現しなければ、通常のブラウザセッションにキャッシュが残っていたことになる。
プラグイン競合を切り分ける手順
JavaScriptエラーやキャッシュの影響が見つからない場合、次に疑うのはプラグイン同士の競合だ。特にセキュリティ系プラグインや高速化系プラグインは、管理画面のAJAX通信に干渉することがある。テーマに含まれるスクリプトが原因になることも少なくない。
切り分けは次の順序で行う。まず全プラグインを一括で無効化し、標準テーマ（Twenty Twenty-FourやTwenty Twenty-Fiveなど）へ切り替える。この状態でトグル設定をオフに変更し、別ページへ移動して戻る操作を行い、設定が保持されるか確認する。
この状態で問題が再現しなければ、プラグインの1つずつを有効化して同様の操作を繰り返す。問題が再現した時点で、直前に有効化したプラグインが原因の可能性が高い。特定できたらそのプラグインの設定を見直すか、開発元へ情報を集める。
なお全プラグインの一括無効化はサイトの表示にも影響を与える。切り分け作業を行う場合は、アクセスの少ない時間帯を選ぶかステージング環境を利用する。
このデモはプラグイン競合の特定を効率的に進めるための順序を示している。問題が再現したタイミングを記録しておくと、原因プラグインの特定がスムーズになる。
データベースの設定値を直接確認して修正する方法
ここまでの切り分けで原因が特定できない場合は、データベースに保存されている設定値を直接確認する。WP-CLI（WordPress Command Line Interface。WordPressのコマンドライン操作ツール）が使える環境であれば、管理画面を経由せずにオプション値を調べられる。
WP-CLIでオプション値を検索する
トグル設定に関連するオプション名を確認するには、wp option listコマンドを使う。オプション名はプラグインごとに異なるが、diagnosticやtrackingといったキーワードを含むものが対象になる。該当するオプションの値がオン（1やyesと表示される）になっていれば、設定がデータベースに保存されていないことが確定する。
wp option list | grep -i diagnostic
wp option list | grep -i tracking見つかったオプション名を指定して値を確認するには、wp option getコマンドを使う。値がオンを示していれば、トグル設定が保存されていないことになる。値がオフを示していれば、保存自体は成功しているため別の要因が影響している。
wp option get 該当するオプション名phpMyAdminで直接確認する場合
WP-CLIが使えない環境ではphpMyAdminを使う。データベース内のwp_optionsテーブル（プレフィックスが異なる場合は該当するテーブル）から、option_name列にキーワードを含む行を検索する。option_value列の値がオンを示していれば保存が失敗している。
検索にはSQL文を使う。プレフィックスは環境によって異なるため、テーブル名を確認してから実行する。
SELECT * FROM wp_options WHERE option_name LIKE '%diagnostic%';直接データベースを変更する場合は必ずバックアップを取ってから行う。設定値がシリアル化された配列の中に含まれている場合、直接変更するとデータ構造が崩れるリスクがある。不安がある場合は手動更新を避け、プラグインの設定画面から保存し直す方が安全だ。
このデモはデータベースの設定値の状態から原因の方向性を切り分ける方法を示している。保存の成否を知ることで、その後の調査対象を絞れる。
よくある質問
トグル設定が勝手に戻るのはいつどんな状況で起きるのか
主にJavaScriptエラーが発生している場合に起きやすい。管理画面のトグルはAJAX通信で設定を保存するが、他のプラグインやテーマが読み込むスクリプトと競合して通信が失敗すると、画面表示だけが切り替わって保存が行われない。キャッシュプラグインの影響で古い設定値が表示される場合もある。
キャッシュプラグインを使っていないのに設定が戻るのはなぜか
サーバー側のオブジェクトキャッシュやホスティング会社が提供する静的キャッシュが影響している可能性がある。またテーマのfunctions.phpや別のプラグインに、設定を強制的にオンへ戻すコードが含まれている場合もある。データベースの値を直接確認すれば保存の成否がわかる。
セキュリティプラグインが原因になることはあるか
ある。セキュリティプラグインが管理画面のAJAXリクエストやnonce検証をブロックすると、設定の保存が失敗する。ファイアウォール機能が過剰に反応して管理画面の操作を妨げるケースがあるため、一時的に無効化して切り分けを行う必要がある。
設定値をデータベースから直接変更しても問題ないか
問題ない場合が多いが、バックアップを取ってから行うことが必須。WP-CLIでオプション名を確認してからupdate_optionを行う。ただしプラグインの設定構造によってはシリアル化された配列に含まれており、直接変更が難しいこともある。不安がある場合はプラグインの設定画面から保存し直す方が安全だ。
本体のアップデートで解消されることがあるか
ある。プラグイン側のバグが原因の場合は本体アップデートで修正されることが多い。プラグインとWordPress本体を最新版に更新してから再度確認する価値は十分にある。ただし更新前にバックアップを取っておくと安心だ。
この記事のポイント
- トグル設定が勝手に戻る原因の多くはJavaScriptエラーかキャッシュの不整合
- ブラウザの開発者ツールでconsoleエラーを確認するのが最初の切り分け手順
- キャッシュプラグインとオブジェクトキャッシュを順に無効化して特定する
- プラグインを全停止し1つずつ再有効化して競合元を見つける
- 最終手段としてWP-CLIやphpMyAdminからデータベースの設定値を直接確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている