2026年9月2日

WordPressの管理者アカウントが突然無効化される原因と復旧手順

ログイン・アクセス

昨日まで使えていた管理者アカウントで、ログインできない、またはログインできても「このページにアクセスする権限がありません」と表示されて管理画面が使えない。この症状の多くは、パスワードの問題ではなく「権限情報（ロール）が失われた」「セキュリティ機能にロックされた」「第三者に乗っ取られた」のいずれかです。この記事では、症状から原因を切り分け、WP-CLIやデータベースで管理者権限を安全に戻すところまでを順に説明します。

まず症状で原因を切り分ける

「無効化された」と一口に言っても、画面に出る内容で疑うべき場所がまったく違います。復旧作業に入る前に、どの症状に当てはまるかを確認してください。

ログイン画面でエラーになる（パスワードが違う、ユーザー名が存在しない）: パスワードやメールアドレスが書き換えられた、アカウント自体が削除された可能性があります。心当たりがなければ乗っ取りを疑います。
ログイン画面そのものが開かない、または「ロックされました」と出る: セキュリティプラグインやWAF、サーバー側のアクセス制限によるブロックです。アカウントは無事なことが多いです。
ログインはできるが、管理画面で権限エラーになる、メニューがほとんど表示されない: ユーザーに紐づくロール（権限）が消えた、または壊れた状態です。最も多いのがこのケースです。
マルチサイトで「スパム」として扱われる旨のエラーが出る: ネットワーク管理画面でユーザーがスパム扱いになっています。

権限エラー系の表示文言はWordPressのバージョンや言語設定で多少異なります（2026年10月現在）。文言の一致より、「ログイン自体は通るかどうか」で判断すると迷いにくくなります。

原因1: ロール情報が消えた・壊れた

WordPressのユーザー権限は、wp_usermeta テーブルの wp_capabilities というメタキーに、シリアライズされた配列として保存されています（wp_ 部分は実際のテーブル接頭辞に置き換わります）。管理者であれば、値はおおむね次の形です。

a:1:{s:13:"administrator";b:1;}

この値が消える・壊れる典型的なきっかけは次のとおりです。

テーブル接頭辞を変更した: wp-config.php の $table_prefix を wp_ から別の値に変えたのに、wp_usermeta 内の wp_capabilities・wp_user_level と、wp_options 内の wp_user_roles を新しい接頭辞に合わせていない。セキュリティ対策として接頭辞を変えた直後に全員の権限が消えた場合は、ほぼこれです。
権限編集プラグインの操作ミス: ロールの権限を編集するプラグインで、管理者ロールから権限を外してしまった。この場合、個々のユーザーではなく wp_user_roles オプション（ロールの定義そのもの）が変わっています。
移行やインポート時の文字列長の不一致: シリアライズ値を検索置換ツールを使わずに書き換え、s:13 などの文字数と実際の文字列が合わなくなった。

WP-CLIで状態を確認する

SSHが使える環境なら、WP-CLIで確認するのが最も安全です。作業前にデータベースのバックアップを取っておきます。

# 作業前にデータベースをバックアップ
wp db export backup-before-role-fix.sql

# 管理者ロールのユーザー一覧
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# 特定ユーザーのロールを確認
wp user get your-admin --field=roles

# 管理者ロールに付与されている権限を確認
wp cap list administrator

wp user get の結果が空なら、そのユーザーのロールが外れています。wp cap list administrator の結果が極端に少ない、あるいはエラーになる場合は、ロールの定義側が壊れています。

権限を戻す

ユーザーのロールだけが外れているなら、ロールを付け直します。ロールの定義が壊れている場合は、管理者ロールを初期状態に戻します。

# ユーザーに管理者ロールを付与（既存のロールは置き換え）
wp user set-role your-admin administrator

# 管理者ロールの権限をWordPressの初期状態に戻す
wp role reset administrator

wp role reset は権限編集プラグインで追加した独自の権限も初期化します。独自権限を使っている場合は、実行後にプラグイン側で設定し直す必要があります。

WP-CLIが使えない場合

phpMyAdminなどで直接確認するときは、まず該当ユーザーのIDを調べてから、メタ値を見ます。

SELECT user_id, meta_key, meta_value
FROM wp_usermeta
WHERE user_id = 1
  AND meta_key LIKE '%capabilities';

接頭辞を変えたのが原因なら、meta_key が旧接頭辞のまま残っているはずです。その場合はメタキーとオプション名を新しい接頭辞に合わせます。下の例は接頭辞を wp_ から abc_ に変えたケースです。データベース全体をエクスポートしてから実行してください。

UPDATE abc_usermeta SET meta_key = 'abc_capabilities' WHERE meta_key = 'wp_capabilities';
UPDATE abc_usermeta SET meta_key = 'abc_user_level'   WHERE meta_key = 'wp_user_level';
UPDATE abc_options  SET option_name = 'abc_user_roles' WHERE option_name = 'wp_user_roles';

値そのものを手で書く場合は、s:13:"administrator" の13が文字数であることに注意します。数字がずれると値全体が読み込めず、権限なしとして扱われます。

原因2: セキュリティプラグインやWAFのロック

ログイン試行回数の制限機能は、自分のパスワード入力ミスや、同じIPアドレスを共有する別の利用者の失敗でも発動します。この場合アカウント自体は無効化されておらず、IPアドレス単位でログイン画面が閉じられているだけです。

確認と解除の手順は次のとおりです。

別の回線（スマートフォンのモバイル回線など）からログイン画面を開いてみる。開けるならIPアドレス単位のブロックです。
プラグインが一定時間で自動解除する設定なら、時間をおいて再試行する。
急ぐ場合は、WP-CLIで該当プラグインを一時的に停止する。

wp plugin list --status=active
wp plugin deactivate plugin-slug

WP-CLIが使えなければ、FTPで wp-content/plugins/ 内の該当フォルダ名を一時的に変更すると、WordPressはそのプラグインを停止扱いにします。ログインできたらフォルダ名を戻し、管理画面でプラグインを有効化してから、ロック対象から自分のIPアドレスを外す設定を見直します。

レンタルサーバーのWAFや国外IPアクセス制限が原因のこともあります。プラグインを止めても変わらない場合は、サーバーのコントロールパネルでアクセス制限やWAFのログを確認してください。

原因3: 第三者による乗っ取り

パスワードもメールアドレスも変えた覚えがないのにログインできない場合や、見覚えのない管理者が増えている場合は、乗っ取りを前提に動きます。攻撃者は既存の管理者の権限を下げたり、パスワードを変えたりしたうえで、自分用の管理者アカウントを作ることがあります。

調べるポイントは次のとおりです。

wp user list --role=administrator に知らないアカウントがないか。登録日時（user_registered）が不自然に新しいものは要注意です。
wp-content/mu-plugins/ に身に覚えのないファイルがないか。ここに置かれたファイルは管理画面から停止できず、特定ユーザーのログインを妨げるコードを仕込まれることがあります。
テーマやプラグイン内の最近更新されたPHPファイル。WP-CLIの wp core verify-checksums と wp plugin verify-checksums --all で、公式配布物との差分を確認できます。

乗っ取りが疑われる場合の対処は、パスワードを戻すだけでは不十分です。不審な管理者の削除、全ユーザーのセッション破棄、wp-config.php の認証用キーとソルトの更新、改ざんファイルの入れ替えまでをまとめて行います。キーとソルトは wp config shuffle-salts で再生成でき、これによって既存のログインCookieはすべて無効になります（実行すると自分もログアウトされます）。ユーザー単位なら wp user session destroy ユーザー名 --all でそのユーザーのセッションを破棄できます。

原因4: マルチサイトのスパム扱い・削除

マルチサイトでは、ネットワーク管理画面でユーザーを「スパム」に設定すると、そのユーザーはログインできなくなります。誤操作でスパム扱いにした場合は、ネットワーク管理画面のユーザー一覧から解除するか、wp_users テーブルの spam 列を確認します。また、特権管理者（ネットワーク管理者）の一覧は個々のロールとは別に管理されているため、wp super-admin list で現在の状態を確かめられます。

再発を防ぐために

管理者アカウントを最低2つ用意する: 1つが使えなくなっても、もう1つから権限を戻せます。
接頭辞の変更や権限編集の前にバックアップ: とくに wp_usermeta と wp_options は、作業前後で比較できるようにエクスポートしておきます。
ログイン履歴と権限変更の記録を残す: いつ誰の権限が変わったかを記録しておくと、原因の特定が早くなります。
二要素認証を導入する: 乗っ取り由来の無効化を防ぐ効果が大きい対策です。

まとめ

管理者アカウントの「無効化」は、ロール情報の消失、セキュリティ機能によるロック、乗っ取り、マルチサイトのスパム扱いのいずれかであることが多いです。
ログインできるのに権限エラーになるなら、wp_capabilities と wp_user_roles を疑い、wp user set-role や wp role reset で戻します。
テーブル接頭辞の変更後に起きた場合は、メタキーとオプション名の接頭辞を合わせます。
心当たりのない変更があれば乗っ取りを前提に、不審なアカウントとファイルの確認、セッション破棄、キーの更新まで行います。
どの作業もデータベースのバックアップを取ってから始めてください。