WordPressサイトが立ち上がらない時の現状調査｜WP-CLI鉄板コマンド完全ガイド【実例付き】

「昨日まで普通に見られていたWordPressサイトが、今朝はなぜか立ち上がらない」。ローカル環境でも本番でも、これは前触れなくやってきます。管理画面にすら入れず、真っ白な画面とにらめっこ――そんな経験はありませんか。

結論から言うと、こういうときは闇雲に触らず「層」を順番に切り分けるのが最短ルートです。そしてその切り分けを高速にこなしてくれるのが WP-CLI（WordPressをコマンドラインから操作するツール）。この記事では、筆者が実際に遭遇した「サイトが立ち上がらない」トラブルを題材に、現状調査の鉄板コマンドを打つ順番ごとに解説します。

検証環境: WordPress 7.0 ／ WP-CLI 2.x 系（確認日: 2026-06）。コマンドの出力や挙動は環境によって異なります。

まず「原因は3つの層のどこか」と考える

サイトが開けないとき、原因は大きく3つの層に分けられます。この地図を頭に入れておくだけで、調査の迷子になりません。

層	代表的な原因	主な症状	確認の手段
DB層	接続情報ミス・MySQL停止・テーブル破損	「データベース接続確立エラー」・真っ白な画面	wp db query、wp db check
WordPress層	コアファイル破損・改ざん、URL設定のズレ	リダイレクトループ・管理画面404・改ざんページ	wp core verify-checksums、wp option get
プラグイン・テーマ層	互換性の衝突・悪意あるコードの混入	Fatal Error・特定ページだけ壊れる	wp plugin list、wp plugin verify-checksums

ポイントは、内側（①②）から順に潰していくこと。そして①②を一気に確認できるのがWP-CLIです。

なぜWP-CLIが効くのか（と、唯一の弱点）

WP-CLIはコマンドを実行するたびに、内部でWordPressをブラウザと同じように読み込み（ブートストラップ）ます。つまり、ブラウザやWebサーバーを介さずに、WordPress本体・DB・プラグイン・テーマの状態を直接のぞけるわけです。

ただし弱点が1つあります。WP-CLIが見えるのは「WordPressより内側」だけ。Webサーバーの設定、ポート、ドメインの名前解決といった環境側（外側）はまったく見えません。だからWP-CLIは、curl やログ確認とセットで使うのが鉄則です。

現状調査の鉄板コマンド【打つ順番つき】

ここからが本題です。筆者がトラブル時に上から順に流すコマンドを紹介します。まずは全体像を一覧で。

#	コマンド	確認する層	見るポイント
1	wp db query "SELECT 1"	DB	DBに接続できるか
2	wp db check	DB	テーブル構造の破損（≠マルウェア）
3	wp option get siteurl && wp option get home	WordPress	URL設定のズレ・リダイレクトハック
4	wp core verify-checksums --locale=ja	WordPress	コアファイルの改ざん・欠落
5	wp plugin verify-checksums --all	プラグイン	プラグインファイルの改ざん
6	wp theme verify-checksums --all	テーマ	テーマファイルの改ざん
7	wp plugin list --status=active --format=csv	プラグイン	有効プラグインの一覧・更新状況
8	wp theme list --status=active	テーマ	有効テーマ・親テーマの確認
9	wp user list --role=administrator --format=csv	WordPress	不正な管理者アカウントの有無
10	wp cron event list --format=table	WordPress	バックドアによる常駐処理の痕跡

ここまでで参考になったらシェアしてください

同じ症状で困っている方に届くと、調査時間を短縮できます。

X でシェア Facebook

この順番で、何が分かるのか

1. wp db query “SELECT 1″｜DB接続の死活確認

wp db query "SELECT 1"

DBに接続できるか最初に確認します。成功すれば 1 が返ります。「データベース接続確立エラー」が出ているときはここで止まります。wp-config.php の DB_HOST・DB_NAME・DB_USER・DB_PASSWORD を次に確認してください。

2. wp db check｜テーブル構造の破損チェック（マルウェア駆除とは別物）

wp db check

重要な誤解を防ぐ：wp db check はテーブルの「構造破損・インデックス異常」を検出するコマンドです。テーブル内のデータに混入したマルウェアコード・不正なphpコード・スパムリンクはこのコマンドでは検出できません。DBの中身（オプション値・投稿本文）の調査は wp db query で直接SQLを実行する必要があります。

3. wp option get siteurl / home｜URL設定とリダイレクトハック対策

wp option get siteurl
wp option get home

リダイレクトハックの手口として、siteurl または home の値を攻撃者が書き換えるケースがあります。両方を必ず確認してください。どちらか一方だけでは見逃す可能性があります。wp-config.php で WP_SITEURL/WP_HOME を定数定義している場合はDBの値より優先されるため、ファイルも確認します。

4. wp core verify-checksums –locale=ja｜コアファイルの改ざん検知

wp core verify-checksums --locale=ja

日本語環境では --locale=ja が必須です。オプションを省略すると en_US のチェックサムと照合されます。日本語版WordPressは一部のファイルが異なるため、--locale=ja なしでは偽陽性（誤検知）が発生します。検出対象は wp-admin/・wp-includes/・ルートのコアファイルです。wp-content/ は対象外です。

5 ＆ 6. wp plugin / theme verify-checksums｜プラグイン・テーマの改ざん検知

wp plugin verify-checksums --all
wp theme verify-checksums --all

WordPress.org配布のプラグイン・テーマのファイルを公式版チェックサムと照合します。バックドアが既存プラグインのファイルに挿入されているケースで有効です。有料・独自開発のプラグイン・テーマは照合対象外なので、wp plugin list で別途確認してください。

7 ＆ 8. wp plugin list / wp theme list｜有効プラグイン・テーマの確認と記録

# 有効プラグインを確認
wp plugin list --status=active

# CSV形式で保存（差分比較に便利）
wp plugin list --format=csv > /tmp/plugin-list-$(date +%Y%m%d).csv

# テーマ確認
wp theme list --status=active

--format=csv で出力することで、インシデント前後のリストを diff コマンドで比較できます。知らないプラグインやテーマが有効になっていないか確認してください。子テーマを使っている場合、active が2件（親・子）表示されます。

9. wp user list –role=administrator｜不正な管理者アカウントの検出

wp user list --role=administrator --format=csv

不正アクセスの典型的な手口は、管理者権限のユーザーを新規作成してバックドアとして使うことです。見覚えのない管理者アカウントがあれば即座に削除を検討します。--format=csv で定期保存しておくと、インシデント前後の差分をすぐに取れます。

10. wp cron event list｜バックドア常駐処理（再感染）の調査

wp cron event list --format=table

マルウェアはWordPressのwp-cronを悪用して自分自身を再インストール（再感染）することがあります。身に覚えのないフック名やコールバック関数が登録されていないかを確認してください。不審なイベントは wp cron event delete <hook> で削除できますが、コードを先に調査してから削除してください。削除だけでは再感染する可能性があります。

異常発見後の即時対応アクション例

⚠️ 実行前に必ずバックアップを取ってください。変更系コマンドは取り消せません。

# 不審な管理者ユーザーを削除
wp user delete 147 --reassign=1

# 不審なプラグインを無効化（削除より先に無効化で影響を確認）
wp plugin deactivate suspicious-plugin

# 全プラグインを一括無効化（原因特定のため）
wp plugin deactivate --all

# 不審なcronイベントを削除
wp cron event delete inject_footer_links

# コアファイルのみ再インストール（wp-contentは変更しない）
wp core download --force --locale=ja

# URLの書き換えを元に戻す
wp option update siteurl "https://example.com"
wp option update home "https://example.com"

WP-CLIで確認できる項目別ガイド

wp core verify-checksums と wp plugin verify-checksums は「公式ファイルとの差分」を見ます。一方、公式には存在しないファイルが追加されているケース（独自PHPファイルの設置）は別の手段が必要です。

# wp-adminに不審なphpファイルがないか
find wp-admin -name "*.php" -newer wp-login.php

# アップロードディレクトリに実行可能ファイルがないか（必ず確認）
find wp-content/uploads -name "*.php" | head -20

wp-content/uploads/ に .php ファイルが存在する場合は、ほぼ確実に不正ファイルです。wp plugin verify-checksums --all と wp theme verify-checksums --all を組み合わせることで、公式配布ファイルの範囲は網羅できます。

Local環境を使う人向けの注意点

ローカル開発ツール「Local」で、同梱のPHPから直接WP-CLIを叩く場合、MySQLのソケット指定でつまずきがちです。wp option get siteurl が「データベース接続確立エラー」になっても、それはサイトの障害ではなくCLI側がLocal専用のソケットを見ていないだけのことがあります。

• PHPの mysqli.default_socket をLocalのソケットへ向ける（php -d mysqli.default_socket=...）と、localhost 指定でも繋がる
• wp db query は内部で mysql クライアントを呼ぶため、PHPとは別にクライアント側のソケット指定が必要（既定の /tmp/mysql.sock を見て失敗する）

まとめ：10コマンドで「現状把握」を完結させる

調査の流れは「DB接続確認 → URL確認 → コア整合性 → ユーザー確認 → プラグイン/テーマ確認 → cronジョブ確認」の順で進めると、原因の層を素早く特定できます。

優先度	コマンド	目的
★★★	wp db query "SELECT 1"	DB接続の死活確認
★★★	wp option get siteurl && wp option get home	リダイレクトハック検出
★★★	wp core verify-checksums --locale=ja	コア改ざんの検出
★★★	wp user list --role=administrator	不正管理者の検出
★★☆	wp plugin verify-checksums --all	プラグイン改ざんの検出
★★☆	wp theme verify-checksums --all	テーマ改ざんの検出
★★☆	wp cron event list	バックドア常駐処理の検出
★☆☆	wp db check	DB構造破損の確認（≠マルウェア）
★☆☆	wp plugin list --format=csv	プラグイン状態の記録・比較
★☆☆	wp theme list --status=active	有効テーマの確認

コマンド一本で「なんとなく直った」ように見えても、再感染のリスクが残っていることがあります。根本原因の除去が完了するまで、公開を再開しないことを強く推奨します。