タグアーカイブ wp-config.php

WordPressでデータベースのテーブルが見つからないエラーの原因と対処法

WordPressで「テーブルが見つからない」エラーが表示されたら、まずwp-config.phpのテーブル接頭辞（$table_prefix）とデータベース内の実際のテーブル名を照合する。接頭辞が一致していなければ設定を修正し、そもそもテーブルが存在しない場合はバックアップからの復元が必要になる。

なぜWordPressで「テーブルが存在しない」エラーが発生するのか

WordPressは投稿や固定ページ、ユーザー情報をすべてデータベースに保存している。データベースの中には複数のテーブルがあり、それぞれ「接頭辞＋テーブル名」という形式で管理される。接頭辞はセキュリティ対策としてサイトごとに変えられる仕組みだ。たとえば初期状態ではwp_posts、wp_optionsという名前になる。

この接頭辞はwp-config.phpという設定ファイルの$table_prefixで指定する。実際のデータベースにあるテーブル名と、この設定ファイルの値が食い違うと、WordPressが存在しない名前のテーブルを探しに行き「テーブルが見つからない」エラーを起こす。サイト移転や手動バックアップの復元時に、データベースだけ別の接頭辞で持ってきてしまった場合に起きやすい。

データベース修復機能は破損したテーブルを直すためのもので、存在しないテーブルを新しく作ることはできない。そのため「修復」を実行してもエラーは解消されない。問題の切り分けには、まず実際にどんなテーブルが存在するのかを確認する必要がある。

データベース内の実際のテーブル接頭辞を調べる方法

エラーの原因が接頭辞の不一致か、それともテーブル自体が消えているのかを切り分けるには、データベース管理ツールを開いて実在するテーブル名を確認する。レンタルサーバーの管理画面にログインし、phpMyAdminと呼ばれるデータベース管理ツールを選択するのが最も確実だ。

テーブル一覧にwp_postsやwp_optionsという名前が見えたら、実際の接頭辞はwp_だ。この場合、設定ファイルが別の値を指していることが原因なので、次の手順で修正する。一方、テーブル一覧が空だったり、別の名前でも見当たらない場合は、テーブル自体が失われている可能性が高い。

wp-config.phpのテーブル接頭辞を正しい値に直す手順

設定ファイルの修正は、FTPソフトかレンタルサーバーのファイルマネージャでwp-config.phpを直接編集する。WordPressをインストールしたルートディレクトリにあるこのファイルを開き、$table_prefixが書かれた行を探す。

保存後にサイトを再読み込みすると、これまで表示されていたテーブル関連のエラーが消えて通常の画面が戻る。管理画面にもアクセスできるようになるはずだ。なお、wp-config.phpを編集する前には必ずファイルのバックアップを取っておくこと。

ファイルマネージャで編集できない場合は、FTPソフトでサーバーに接続して同じファイルをダウンロードし、テキストエディタで修正してアップロードする。文字コードはUTF-8のまま保存する。

テーブルが実際に消えている場合の復元方法

phpMyAdminで確認しても該当するテーブル自体が存在しない時は、設定の不一致ではなくデータが失われている状態だ。この場合は修復機能では戻らないため、バックアップからの復元が必要になる。

1. レンタルサーバーの自動バックアップ機能を確認する
2. 運用中に取得していたバックアップデータから復元する
3. ホスティング事業者のサポートに問い合わせる

バックアップが手元にない場合でも、ホスティング事業者が定期的にサーバー全体のバックアップを保持していることが多い。データベースだけを復元できるか、サポートに確認するのが得策だ。復元後は接頭辞の一致を必ず確かめる。

テーブル接頭辞の不一致を防ぐための確認ポイント

サイト移転やバックアップ復元の後に同じエラーを再発させないためには、接頭辞とデータベースの状態を習慣的に確認しておくとよい。最低限のポイントを挙げる。

• サイト移転時は設定ファイルとデータベースの接頭辞を照合する
• テスト環境と本番環境では同じ接頭辞にそろえる
• wp-config.php を編集する前に必ずバックアップを取る
• 不要なデータベース修復を連続実行しない

よくある質問

接頭辞を直したのにまだテーブルが見つからないエラーが出る

設定ファイルを保存した後もブラウザやサーバーのキャッシュが残っていると表示が変わらない場合がある。ブラウザをスーパーリロードし、サーバー側のキャッシュを削除してから確認する。それでも出る場合は、実際に存在するテーブル名と設定値をもう一度照合し、データベース名やホスト名も確認する。

phpMyAdmin を使わずに接頭辞を確認できるか

wp-config.php の設定だけでは実際のテーブル名は分からない。データベース管理ツールか、ホスティング事業者の管理画面にあるデータベース一覧で確認する。どうしても見つからない時はサポートに問い合わせると接頭辞を教えてもらえる場合がある。

WordPress の修復機能でテーブルが消えることはあるか

修復機能は既存テーブルの破損を修復するのが目的で、テーブル自体を削除する動作ではない。ただし存在しないテーブルは作成できないため、修復を実行してもテーブルがないエラーは解消しない。元のテーブルが消える主な原因はデータベースの操作ミスやインポート時の上書きだ。

バックアップからデータベースだけ復元する手順は

ホスティングの管理画面にあるバックアップ機能を開き、復元したい日時のデータベースを選ぶ。phpMyAdmin からインポートできる SQL ファイルがある場合は、該当するデータベースを選択してインポートを実行する。操作前に現在のデータを追加でエクスポートしておくと安全だ。

接頭辞を wp_ に変更すると既存データは消えるか

接頭辞の変更そのものはテーブル名を読み替えるだけで、データを削除しない。ただし実在しない接頭辞に変更すると WordPress がテーブルを見つけられず、同じエラーになる。必ずデータベース内の実名と一致する値に変更する。

この記事のポイント

• テーブルが見つからないエラーは接頭辞の不一致が第一原因
• phpMyAdmin で実際のテーブル名を確認する
• wp-config.php の $table_prefix を実在の接頭辞に合わせる
• テーブル自体が無い時はバックアップ復元が最短ルート
• 設定変更前に必ず wp-config.php とデータベースのバックアップを取る

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WordPressサイト全体にアクセスできなくなった時の原因と復旧手順

サイトにも管理画面にもまったくアクセスできなくなった場合、最初に確認すべきはサーバーのファイル構造とWordPressのインストールパスだ。外部からの不正アクセスを受けた後にページが表示されなくなる症状では、改ざんされたプラグインの残骸や、不完全に変更された設定ファイルが読み込みを妨げている可能性が高い。

なぜサイト全体にアクセスできなくなったのか

管理画面も含めてあらゆるページが表示されない状態は、WordPressの根幹となるファイルが破損しているか、サーバーがPHPを正しく処理できなくなっていることを意味する。特に不正アクセスを受けた後であれば、攻撃者が設置した不正なコードがセキュリティプラグインや手動の復旧作業によって一部だけ削除され、不完全な状態で残っている可能性が高い。

最も厄介なのは、WordPress本体のコアファイルや設定ファイルそのものが破損しているケースだ。テーマやプラグインの不具合であれば、それらを無効化することで少なくとも管理画面にはアクセスできるようになるが、コア破損ではそれすらも不可能になる。

不正アクセスからの復旧作業で起こりやすい副次的な破損

外部から侵入を受けた後、多くのユーザーはパスワード変更やソルトキーの更新、不審なプラグインの削除といった応急処置を行う。しかしこれらの作業中に誤って重要なファイルを削除してしまったり、修正が中途半端な状態で終わってしまったりすることがある。特にソルトキーを手動で更新した場合、wp-config.php内で閉じ引用符が欠落していたり、PHPの定数定義が壊れていたりすると、WordPress全体が読み込めなくなる。

最初に試すべき緊急アクセス手順

サイトが完全に応答しなくなった場合、まずはブラウザの問題ではなくサーバー側の問題であることを確認する。シークレットウィンドウで自分のサイトURLを開く、別の端末やネットワークからアクセスしてみる、example.com/readme.htmlのような静的なHTMLファイルが表示されるか試すといった切り分けが有効だ。静的なHTMLすら表示されないなら、DNS設定やサーバー自体の停止を疑う必要がある。

上記の手順で管理画面に到達できるようになれば、あとは管理画面からプラグインを1つずつ有効化して原因を特定し、テーマを正式に切り替えればよい。

wp-config.php の破損を確認する

ソルトキーを変更した直後にアクセス不能になったなら、wp-config.phpが最も疑わしい。このファイルはWordPressのルートディレクトリにあり、データベース接続情報や認証用のユニークキーを定義している。編集時にシングルクォートが1つ抜けている、余分な文字が混入している、PHPの開始タグ<?phpが欠落しているといった単純なミスで、サイト全体が真っ白になる。

サーバーのファイルマネージャーやFTPクライアントでwp-config.phpをダウンロードし、バックアップを取った上で内容を確認する。特にソルトキーを定義しているセクション（AUTH_KEYやLOGGED_IN_KEYなどが並ぶ部分）に注目し、各行がdefine('キー名', '値');の形式を正しく守っているか、閉じ括弧とセミコロンが揃っているかを1行ずつ検証する。不安があれば、WordPressの公式ソルトキー生成ページから新しいキーセットをコピーし、該当セクションを丸ごと置き換えるのが安全だ。

プラグインを強制的に全無効化する

管理画面にさえアクセスできない状態では、データベースを直接操作するか、FTPでプラグインフォルダの名前を変更することでプラグインを無効化する。手順はシンプルで、/wp-content/plugins/ディレクトリに移動し、その中にある全プラグインのフォルダ名の先頭に「_」や「disabled_」を付け加えるだけだ。例えばwordfenceを_wordfenceにリネームすれば、WordPressはそのプラグインを認識しなくなる。

この方法の利点は、プラグイン本体のファイルを削除せずに済むため、原因特定後にすぐ元の名前に戻して復元できることだ。大量のプラグインを1つずつリネームするのが面倒な場合は、pluginsフォルダ自体をplugins_backupにリネームし、空のpluginsフォルダを新規作成すると一括で無効化できる。

WordPress コアファイルを手動で上書きする

wp-config.phpに問題がなく、プラグインをすべて無効化しても症状が改善しない場合、WordPress本体のプログラムファイルが改ざんまたは破損している。攻撃者がwp-adminやwp-includesディレクトリに仕込んだバックドアが、不完全に削除されたまま残っているケースも多い。

対処法は、WordPress公式サイトから最新版の ZIP ファイルをダウンロードし、展開した中身をFTP経由でサーバーにアップロードすることだ。このとき絶対に上書きしてはいけないファイルが2つある。wp-config.php（サイト固有の設定）と/wp-content/ディレクトリ（テーマ・プラグイン・アップロードメディア）だ。これらを除くすべてのファイルとフォルダを上書きアップロードすることで、コアファイルだけがクリーンな状態にリセットされる。

サーバー側のエラーログを確認する方法

ここまでの手順で復旧しない場合は、具体的なエラー内容を把握する必要がある。ブラウザには「重大なエラーが発生しました」としか表示されないが、サーバーには詳細なエラーログが記録されている。レンタルサーバーの管理パネル（cPanelやカスタムコントロールパネル）で「エラーログ」や「error_log」という項目を探し、直近のエントリを確認する。

エラーログには「PHP Fatal error」や「Allowed memory size exhausted」といった具体的な原因が記録されている。特に不正アクセス後によく見られるのが、改ざんされたファイルから呼び出された存在しない関数によるエラーや、不完全に削除されたコードの残骸による構文エラーだ。ログの内容を手がかりに、問題のファイルを特定して修正するか、該当プラグインを完全に削除する。

WP_DEBUG を一時的に有効化して詳細を表示する

サーバーのエラーログが見つからない場合は、WordPressのデバッグモードを有効にしてエラーを画面に直接表示させる。これはwp-config.phpに以下の定数を追加または変更することで実現できる。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', true);

WP_DEBUGをtrueにするとWordPressがエラーを表示するようになり、WP_DEBUG_LOGで/wp-content/debug.logにエラーが記録される。WP_DEBUG_DISPLAYをtrueにすると、ブラウザ上にもエラーメッセージが直接表示される。なお、作業が終わったらこれらの定数をfalseに戻すか削除すること。本番サイトでデバッグ表示を有効にしたままにすると、訪問者にもエラー内容が見えてしまいセキュリティリスクになる。

.htaccess ファイルの破損を疑う

不正アクセスの痕跡として、.htaccessファイルが改ざんされているケースも多い。このファイルはWebサーバー（Apache）の挙動を制御しており、ここに不正なリダイレクトルールやアクセス制限が書き込まれていると、サイト全体にアクセスできなくなる。

WordPressルートディレクトリの.htaccessをダウンロードしてバックアップを取り、一度ファイル名を.htaccess_backupに変更して無効化する。その後、WordPress管理画面の「設定」→「パーマリンク設定」で「変更を保存」をクリックすれば、クリーンな.htaccessが自動生成される。ただし管理画面にアクセスできない現状では、以下の内容で新規に.htaccessを作成してもよい。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

これでサイトが表示されるようになれば、原因は.htaccessの改ざんだったと特定できる。旧ファイルは内容を精査し、不審な行（知らないドメインへのリダイレクトや、怪しいIPアドレスからのアクセス許可ルールなど）がないか確認してから削除する。

バックアップからの復元がうまくいかない場合の対処

サーバー会社のサポートからバックアップ復元を提案されたが失敗したという状況は、バックアップデータ自体が破損しているか、復元先の環境に不整合があることを示している。特に多いのが、バックアップを上書き復元した後にデータベースの接続情報が古いままになっているケースだ。

バックアップ復元後にサイトが表示されない場合、まずwp-config.php内のデータベース名・ユーザー名・パスワード・ホスト名が、現在のサーバー環境と一致しているか確認する。バックアップが別のサーバーや別のデータベースインスタンスの情報を持ったまま復元されると、WordPressはデータベースに接続できず「データベース接続確立エラー」を返す。

もうひとつの可能性は、バックアップに不正アクセス後の改ざんファイルが含まれていたケースだ。攻撃を受けた後の状態をバックアップしてしまい、それを復元しても問題が再発するだけという悪循環に陥っている。この場合、バックアップからwp-content/uploads/（メディアファイル）とデータベースのダンプファイルだけを取り出し、WordPressのコアファイルとプラグインは公式のクリーンなファイルで置き換える方法が有効だ。

よくある質問

FTPの接続情報がわからない場合はどうすればよいか

多くのレンタルサーバーでは、契約時に送られてくる「サーバーアカウント情報」メールにFTPのホスト名・ユーザー名・パスワードが記載されている。見つからない場合はサーバーの管理パネルにログインし、「FTPアカウント」や「ファイルマネージャー」の項目から確認できる。管理パネル自体にログインできない場合は、サーバー会社のサポートに連絡してFTP情報を再発行してもらう必要がある。

「このサイトで重大なエラーが発生しました」のメールが届いたが確認できない

WordPress 5.2以降では、サイトに致命的なエラーが発生すると管理者メールアドレスに自動通知が届く。このメールには「リカバリーモード」へのリンクが含まれており、クリックするとプラグインを無効化した状態で管理画面にログインできる。メールが届いていない場合は、サーバーのPHPバージョンが古くてメール送信機能が動作していない、または管理者メールアドレスが間違って設定されている可能性がある。

不正アクセスを受けた後、どのプラグインを疑うべきか

攻撃者は多くの場合、更新が長期間止まっている脆弱なプラグインや、公式リポジトリ以外から入手したnulledプラグイン（正規ライセンスを回避した改変版）を経由して侵入する。/wp-content/plugins/内で更新日時が不自然に新しいファイル、プラグイン名とは無関係なファイル名（config.bakやabout.phpなど）が紛れ込んでいないか確認する。また、長期間更新されていないプラグインは、たとえ攻撃の経路でなかったとしても今後のリスクになるため、代替プラグインへの移行を検討すべきだ。

すべて試しても復旧しない場合の最終手段は

サーバー上の全ファイルをローカルにバックアップし、データベースをエクスポートした上で、WordPressを新規インストールする。その後、エクスポートしたデータベースのうちwp_posts（投稿・固定ページ）とwp_postmeta（カスタムフィールド）、wp_options（サイト設定）のテーブルだけをインポートし直す。この方法ではテーマやプラグインの設定の一部が失われる可能性があるが、コンテンツを救出できる可能性が最も高い。作業前には必ず現状の完全バックアップを取っておくことが大前提だ。

この記事のポイント

• 管理画面もサイトも表示されない場合、まずは静的なHTMLファイルが表示されるか確認し、問題の切り分けを行う
• wt-config.phpの文法ミスやプラグインの強制無効化、.htaccessのリセットで多くのケースが解決する
• 不正アクセス後はコアファイルが改ざんされている可能性があるため、wp-content以外をクリーンなファイルで上書きする
• バックアップ復元に失敗したら、データベース接続情報の不一致やバックアップ自体の破損を疑う
• エラーログやWP_DEBUGで具体的なエラー内容を特定し、根本原因に対処するのが最も確実な復旧手順である

佐々木 太陽

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている