WordPress は標準ではログインの失敗を保存しないため、「不正ログインを試されているのか」「スタッフがパスワードを間違えて締め出されたのか」を後から確かめられません。ログイン失敗を記録するプラグインを入れておけば、いつ・どの IP から・どのユーザー名で失敗したかが一覧で分かり、攻撃の傾向に合わせた対策を選べるようになります。この記事では、目的別のプラグインの選び方、導入後に確認する設定、記録の読み方、プラグインを使わずに最小限の記録を残す方法を解説します。
ログイン失敗を記録すると何が分かるか
WordPress では、ログインに失敗するとコアのアクション wp_login_failed が実行されます。ログ記録プラグインはこのタイミングなどをとらえて、次のような情報をデータベースに保存します。
- 失敗した日時
- 接続元の IP アドレス
- 入力されたユーザー名（またはメールアドレス）
- 失敗の理由（ユーザー名が存在しない、パスワードが違う、など）
これが残っていると、たとえば「実在するユーザー名ばかり狙われている」「深夜に海外の IP から毎分のように試行がある」「特定の社員の IP で朝だけ失敗が続く」といった状況を区別できます。対策の優先順位を決めるための材料になります。
目的別のプラグインの選び方
ログイン失敗を記録できるプラグインはいくつかありますが、記録の範囲と本来の役割が異なります。
- Simple History: 投稿の更新、プラグインの有効化、ユーザーのログイン・ログアウトなど、サイト上の操作を時系列で記録するプラグイン。ログイン失敗も記録対象に含まれ、ダッシュボードから手軽に確認できる。まず記録を見たいという用途に向く
- WP Activity Log: より詳しい操作ログ（監査ログ）を残すプラグイン。複数人で運用するサイトで、誰が何をしたかまで追いたい場合に向く。通知や外部への転送など一部の機能は有料版の範囲
- Limit Login Attempts Reloaded: ログイン試行回数を制限するのが本来の役割で、ロックアウトした IP やユーザー名の記録を確認できる。記録と同時に攻撃を止めたい場合に向く
- Wordfence Security: ファイアウォールやマルウェアスキャンを含む総合セキュリティプラグイン。アクセス状況の画面でログイン失敗も確認できる
すでに総合セキュリティプラグインを使っているなら、まずその中にログイン記録の機能がないかを確認してください。似た役割のプラグインを重ねると、同じ処理が何重にも走り、管理画面が重くなる原因になります。各プラグインの機能範囲や無料版で使える機能は更新で変わることがあります（2026年10月現在）。導入前に、WordPress.org のプラグインページで最終更新日と対応バージョンも確認しておきましょう。
導入の流れ（Simple Historyの例）
ここでは、設定が少なく始めやすい Simple History を例に流れを説明します。
- 管理画面の「プラグイン」→「新規プラグインを追加」で「Simple History」を検索し、インストールして有効化する
- ダッシュボードのウィジェット、または管理メニューに追加される Simple History の画面を開く
- ログの一覧で、検索や絞り込みを使ってログイン関連のイベントだけを表示する
導入した時点から記録が始まるので、導入前の失敗は表示されません。試しに、シークレットウィンドウで存在しないユーザー名とでたらめなパスワードでログインを試し、一覧に失敗が記録されることを確認しておくと安心です。画面の名称や絞り込みの方法はバージョンによって異なることがあるため、表示が違う場合はプラグインの説明を参照してください。
導入後に確認したい設定
接続元IPが正しく取れているか
Cloudflare などの CDN やリバースプロキシを経由しているサイトでは、記録される IP がすべて CDN のアドレスになっていることがあります。これでは攻撃元を判断できません。プラグインに接続元 IP の取得方法を選ぶ設定がある場合は、使っている環境に合わせて設定します。
ただし、X-Forwarded-For などのヘッダーは利用者側で自由に書き換えられます。プロキシを経由していないサイトでこのヘッダーを信頼する設定にすると、攻撃者が偽の IP を記録させられるので注意してください。
保存期間
ログはデータベースに蓄積されます。攻撃が多いサイトでは短期間でかなりの件数になり、データベースの肥大化や管理画面の表示の遅さにつながります。保存期間を設定できるプラグインでは、必要な期間（たとえば数十日〜数か月）に絞っておきます。
個人情報としての扱い
IP アドレスやユーザー名は、個人に結び付く情報として扱われることがあります。記録している旨と保存期間をプライバシーポリシーに書いておくと、問い合わせがあったときにも説明しやすくなります。
記録の読み方と次の対策
記録が集まったら、パターンを見て次の対策を決めます。
- 存在しないユーザー名（admin、test など）への試行が大量: 無差別のボットです。ログイン試行回数の制限やログイン URL の変更で、試行そのものを減らします。
- 実在するユーザー名が狙われている: ユーザー名が外部に知られています。著者アーカイブの URL や REST API のユーザー一覧からユーザー名が分かる場合があるため、表示名をユーザー名と別にする、二段階認証を有効にするなどの対策を検討します。
- 少数の IP から集中して試行: その IP をサーバーやファイアウォールで遮断します。
- 多数の IP から少しずつ試行: IP 単位の遮断が効きにくい分散型の攻撃です。二段階認証や、管理画面への IP 制限のような、接続元に依存しない対策が向いています。
- 社内の IP で同じユーザー名の失敗が続く: 攻撃ではなく、パスワード忘れやブラウザの保存パスワードの誤りの可能性があります。本人に確認し、パスワードのリセットを案内します。
なお、XML-RPC（xmlrpc.php）経由のログインも同じ認証処理を通るため、ログイン画面を開いていないのに失敗が記録されることがあります。XML-RPC を使っていないなら、無効化すると記録の件数も大きく減ります。
プラグインを使わずに最小限の記録を残す
管理画面での一覧表示が不要で、サーバーのログに残せれば十分という場合は、wp_login_failed アクションを使って PHP のエラーログに書き出す方法もあります。wp-content/mu-plugins/ に次のようなファイルを置きます。
<?php
/**
* Plugin Name: Login Failure Logger
* Description: ログイン失敗を PHP のエラーログに記録する最小構成。
*/
add_action( 'wp_login_failed', function ( $username, $error = null ) {
$ip = isset( $_SERVER['REMOTE_ADDR'] )
? sanitize_text_field( wp_unslash( $_SERVER['REMOTE_ADDR'] ) )
: 'unknown';
$code = ( $error instanceof WP_Error ) ? $error->get_error_code() : 'unknown';
error_log( sprintf(
'[wp-login-failed] user=%s ip=%s reason=%s',
sanitize_user( $username ),
$ip,
$code
) );
}, 10, 2 );wp_login_failed の第2引数（WP_Error）は WordPress 5.4 で追加されたもので、invalid_username や incorrect_password といったエラーコードから失敗の理由が分かります。出力先はサーバーの PHP エラーログで、wp-config.php で WP_DEBUG_LOG を有効にしている場合は wp-content/debug.log になります。debug.log は外部から閲覧できる場所にあるため、本番で使う場合はアクセスを禁止するか、出力先を公開ディレクトリの外に変更してください。
この形式でログに残しておくと、fail2ban などのサーバー側のツールで一定回数以上失敗した IP を自動で遮断する、といった連携もしやすくなります。
まとめ
- WordPress は標準ではログイン失敗を保存しないため、記録したい場合はプラグインかコードで対応する
- 記録だけなら Simple History、詳しい監査ログなら WP Activity Log、記録と遮断を一緒に行うなら Limit Login Attempts Reloaded などが候補
- CDN 経由では接続元 IP の取得方法を確認し、保存期間とプライバシーポリシーも整える
- 狙われているユーザー名や IP の分布を見て、試行回数の制限・二段階認証・IP 制限などを選ぶ
- 一覧表示が不要なら、
wp_login_failedアクションでエラーログに書き出す方法もある