WordPressセキュリティプラグインとは、不正ログイン・改ざん・マルウェア感染といった攻撃からWordPressサイトを守るための機能拡張です。ログイン試行の制限、WAF（Web Application Firewall）、マルウェアスキャン、2要素認証（2FA）などを管理画面から設定できます。
2026年時点で多くの企業サイトにとっての現実解は、「国産プラグイン1本＋サーバー側WAF＋更新・バックアップ運用」の組み合わせです。海外製の高機能プラグインを入れることが正解とは限りません。むしろ、機能が重複する複数のプラグインを同時に入れたことで管理画面にログインできなくなる、サーバー側のWAFと干渉して正常な投稿が弾かれる——こうした事故のほうが、実際の保守現場ではよく起こります。
本記事では、WordPress保守サービス「WPセンター」として企業サイトの運用を預かる立場から、主要8プラグインの機能・料金・日本語対応を比較したうえで、カタログスペックでは分からない「入れたあとに何が起きるか」まで踏み込んで解説します。8選には、こうした保守現場の経験をもとに当社が開発した国産プラグイン「CenterShield（センターシールド）」も含めています。
※本記事のプラグイン情報は2026年10月時点のWordPress.org公式ディレクトリの掲載内容に基づきます。料金・有効インストール数は変動するため、導入前に公式サイトで最新情報をご確認ください。
- WordPressセキュリティプラグインおすすめ8選【比較一覧表】
- 主要8プラグイン 機能比較表
- CenterShield（センターシールド）｜国産・日本語・1本で完結させたい企業サイトに
- SiteGuard WP Plugin｜国内の中小規模サイトにおける標準解
- CloudSecure WP Security｜エックスサーバー利用者が最初に確認したい国産プラグイン
- Wordfence Security｜機能を最優先する中〜大規模サイト向け
- All-In-One Security (AIOS)｜無料で幅広い機能を試したい場合
- Kadence Security（旧Solid Security／旧iThemes Security）｜名称変更に注意が必要な定番
- Sucuri Security｜外部からの改ざん検知・監視を重視するなら
- MalCare｜サーバー負荷を避けたいEC・会員制サイト向け
- 失敗しないWordPressセキュリティプラグインの選び方｜5つの判断基準
- 【保守現場の実例】プラグイン導入で実際に起きたトラブルと回避策
- WordPressセキュリティプラグインの導入・初期設定手順
- プラグインだけでは守れない3つの領域
- WordPressセキュリティプラグインに関するよくある質問
- まとめ｜サイト規模別の推奨構成
WordPressセキュリティプラグインおすすめ8選【比較一覧表】
以下の8種類を押さえておけば、個人ブログから中〜大規模のコーポレートサイトまで対応できます。
というのも、WordPressの脆弱性の大半は、コア本体ではなくプラグイン・テーマ由来だからです。セキュリティベンダーPatchstackの年次レポートによれば、2025年にWordPressエコシステムで確認された新規脆弱性は11,334件。その内訳は次のとおりです。
- プラグイン：91%（約10,300件）
- テーマ：9%（約1,000件）
- WordPressコア本体：6件（いずれも低リスク）
件数は前年比42%増で、2023年の5,948件（同社の2024年版レポートによる）から2年で約1.9倍に増加しています。「WordPressは危険」なのではなく、危険なのは管理されていないプラグインとテーマというのが、データが示す実態です。
つまり「何を入れるか」と同じくらい、「何を入れないか」「入れたものをどう更新し続けるか」が重要になります。
主要8プラグイン 機能比較表
| プラグイン名 | 提供元 | 有効インストール | WAF | マルウェアスキャン | ログイン保護 | 2要素認証（2FA） | 日本語UI | 料金 |
|---|---|---|---|---|---|---|---|---|
| CenterShield （センターシールド） | WPセンター（当社） | 2026年9月公開 | ○ （軽量WAF） | ◎ | ◎ | ◎ | ◎ | 完全無料 |
| SiteGuard WP Plugin | EGセキュアソリューションズ | 50万+ | × | × | ◎ | × | ◎ | 完全無料 |
| CloudSecure WP Security | エックスサーバー株式会社 | 10万+ | ○ | × | ◎ | ◎ | ◎ | 完全無料 |
| Wordfence Security | Defiant | 500万+ | ◎ | ◎ | ◎ | ◎ | ○ | 無料／有料版あり |
| All-In-One Security (AIOS) | Team Updraft | 100万+ | ○ | △ （有料版のみ） | ◎ | ◎ | ○ | 無料／有料版あり |
| Kadence Security （旧Solid Security／旧iThemes Security） | StellarWP（Nexcess） | 70万+ | △ （仮想パッチは有料版） | × | ◎ | ◎ | △ | 無料／有料版あり |
| Sucuri Security | Sucuri（GoDaddy） | 60万+ | ◎ （有料のクラウドWAF） | ◎ | △ （無料版は記録のみ） | ○ | × | 無料／有料版あり |
| MalCare | BlogVault | 10万+ | ◎ | ◎ （クラウド処理） | ○ | ○ | × | 無料／有料版あり |
※◎＝標準搭載で実用十分、○＝搭載、△＝限定的または有料版のみ、×＝非搭載
※有効インストール数は2026年10月時点のWordPress.org公式ディレクトリの掲載値です。CenterShieldは2026年9月に公開したばかりのため、公開時期を記載しています。料金は各公式サイトをご確認ください。
CenterShield（センターシールド）｜国産・日本語・1本で完結させたい企業サイトに
「国産プラグイン1本」で、ログイン防御からマルウェアスキャンまでまとめて対策したい企業サイトに、まずおすすめしたいのが、当社WPセンターが開発・提供する国産プラグイン「CenterShield（センターシールド）」です。
日々の保守現場で繰り返し目にしてきた「複数のプラグインを重ねて競合する」「設定の意味が分からないまま放置される」という課題を解消するために開発しました。特徴は次の3点です。
第一に、ログイン防御・2要素認証・不要機能の無効化・ファイル保護・マルウェアスキャンを1本で網羅していること。プラグインを重ねる必要がないため、競合のリスクを構造的に減らせます。
第二に、管理画面とメッセージがすべて日本語で、各設定に「何を守るのか」「ONにすると何が変わるのか」の説明が付いていること。専門知識がなくても、自社サイトに必要な対策を判断できます。
第三に、有効化しただけではサイトに何も変更を加えない設計であること。ダッシュボードの「推奨設定を適用」ボタンで推奨の対策をまとめて有効化することも、1項目ずつ有効化することもできます。本記事で繰り返しお伝えしている「1機能ずつ有効化して確認する」という運用に、そのまま沿う作りです。
搭載されている主な機能は次のとおりです。
- ログイン保護：ログイン試行回数の制限、ユーザー名漏えい防止、ログインURLの変更、ログイン画面のBasic認証、reCAPTCHA（v2／v3）、管理画面のIPアドレス制限
- 2要素認証：認証アプリ・メール・バックアップコードに対応。権限ごとの必須化、設定までの猶予期間、信頼済み端末で30日間コード入力を省略する機能
- 不要機能の無効化：XML-RPC（署名付きのJetpackの通信は許可）、ピンバック、REST APIの制限（Contact Form 7・Jetpack・WooCommerceなど主要プラグインは許可）、投稿者アーカイブ、ファイル編集機能、アプリケーションパスワード
- ファイル・サーバー保護：wp-config.phpや設定ファイル・バックアップファイルへの直接アクセスの遮断、アップロードフォルダでのPHP実行の禁止、ディレクトリ一覧の無効化、セキュリティヘッダーの付与、パーミッションの確認と修正
- 継続的な防御：軽量WAF（入力のフィルタリング）、コメントスパムの遮断、2年以上更新のないプラグイン・テーマの検出
- マルウェアスキャン：WordPress本体とプラグインの公式ファイルとの照合、既知の脆弱性データベースとの照合、マルウェアのシグネチャ照合、データベース（投稿・ウィジェット・管理者アカウント）の検査、検出ファイルの隔離と公式の元ファイルからの復元
スキャンに必要なマルウェア定義や脆弱性情報は当社のサーバーから取得しますが、サイトのアドレスや、導入しているプラグイン・テーマの一覧、投稿・ユーザーのデータは送信しません。照合はすべてサイト上で行うため、取り扱うデータの機密性が高いサイトでも導入しやすい仕様です。
公開から間もないプラグインのため、有効インストール数はこれから伸びていく段階です。当社の保守サービスで培った運用ノウハウを反映しながら、継続的にアップデートしていきます。
SiteGuard WP Plugin｜国内の中小規模サイトにおける標準解
日本国内向けのコーポレートサイト・オウンドメディアで、ログイン防御だけを軽く導入したいなら、有力な国産プラグインです。
理由は3点あります。第一に、開発元が日本のセキュリティ専業ベンダーであるEGセキュアソリューションズであり、日本語のドキュメントとUIが完備されていること。第二に、機能を「ログインページと管理画面の防御」に絞り込んでいるため動作が軽く、他のプラグインやサーバー環境と衝突しにくいこと。第三に、完全無料でありながら継続的にアップデートされており、WordPress 7.x系にも追随している点です。
搭載されている主な機能は次のとおりです。
- 管理ページアクセス制限
- ログインページURL変更（
wp-login.phpの変更） - 画像認証（CAPTCHA）
- ログインロック（一定時間内の連続失敗をブロック）
- ログインアラート（ログイン成功時のメール通知）
- フェールワンス（正しいID／パスワードでも1回目は必ず失敗させる）
- XML-RPC防御（ピンバック無効化／XML-RPC全体の無効化）
- ユーザー名漏えい防御
- 更新通知
- ログイン詳細エラーメッセージの無効化
- WAFチューニングサポート（同社のサーバー型WAF製品向けに、誤検知の除外ルールを生成する補助機能）
機能範囲は正確に押さえておく必要があります。SiteGuardはマルウェアスキャン機能を持たず、2要素認証も非搭載、WAF本体も搭載していません。上記のWAFチューニングサポートは、あくまで同社が別途提供するサーバー型WAF向けに、誤検知の除外ルールを生成する補助機能です。
改ざん検知や感染後の駆除、あるいは2要素認証までカバーしたい場合は、後述するプラグインやサーバー側・外部サービスとの組み合わせが必要になります。1本でまとめて対策したい場合は、前述のCenterShieldが選択肢になります。
SiteGuardは「不正ログイン対策の専門プラグイン」と位置づけ、スキャン系は別レイヤーで担保する設計が適切です。
CloudSecure WP Security｜エックスサーバー利用者が最初に確認したい国産プラグイン
2026年時点で、国産プラグインの選択肢としてSiteGuardと並んで検討すべき存在です。
エックスサーバー株式会社が無償提供しており、ログイン防御と簡易WAFを1本でカバーできる点が特徴です。SiteGuardが持たない2段階認証（Google Authenticator／メール認証）を標準搭載し、さらに「シンプルWAF」機能によってSQLインジェクションやXSSといった代表的な攻撃パターンへの対策も可能です。複数プラグインを併用せずに済むため、後述する競合リスクを構造的に減らせることが利点といえます。ただしマルウェアスキャン機能は搭載していません。
- ログイン無効化／ログインURL変更／ログインエラーメッセージの統一
- 画像認証・2段階認証
- 管理画面アクセスIP制限
- XML-RPC・REST APIの無効化
- シンプルWAF（SQLインジェクション・XSS対策）
- ログイン通知／アップデート通知／サーバーエラー通知
エックスサーバーの「WordPress簡単インストール」「WordPressクイックスタート」では、チェックが入った状態で同時導入の候補として提示されるため、意識しないまま導入済みになっているケースがあります。まず管理画面のプラグイン一覧を確認してみてください。なお他社サーバーでも利用可能です。
国産・日本語・無料で、ログイン防御と2段階認証を備えたプラグインとして有力です。ただし有効インストール数は10万件台と歴史が浅いため、長期運用サイトでは更新頻度のウォッチを継続してください。マルウェアスキャンまで1本で済ませたい場合は、CenterShieldを検討してください。なお、ログインURL変更などの機能が重なるため、CenterShieldと同時に有効化するのは避けてください。
Wordfence Security｜機能を最優先する中〜大規模サイト向け
世界で500万件以上に導入された最大手です。マルウェアスキャンとWAFを1本で完結させたい場合の第一候補になります。
無料版の時点で、エンドポイントファイアウォール（サーバー上で動作するWAF）、コアファイル・テーマ・プラグインを対象としたマルウェアスキャン、ログイン試行制限、2要素認証、ログイン画面のCAPTCHAまでを単体でカバーしています。一方、リアルタイムIPブロックリストと国別ブロックはPremium限定です。脆弱性情報の収集・公開を自社で行っているベンダーでもあり、脅威情報の一次発信元として参照されることも少なくありません。
一方で、注意点も明確です。
- スキャン時にサーバーリソースを消費する：リソースに余裕のある環境では体感差は出ませんが、CPU制限の厳しい共用サーバーでは影響が出ることがあります（後述の実測を参照）
- 無料版はシグネチャ更新が30日遅延：最新の脅威への即応を求めるならPremiumが前提になります
- 公式ドキュメント・サポート情報は英語が中心：管理画面は日本語で表示されますが、ヘルプやサポート情報を読むには英語の資料にあたる必要があります
- 通知メールが多い：初期設定のままだと運用担当者が通知疲れを起こしやすくなります
Wordfenceは「運用担当者が英語ドキュメントを読める」「サーバーリソースに余裕がある」中〜大規模サイト向けです。なお、当ブログで実測したところスキャン中の表示速度の低下はほぼ観測されませんでした。詳細は後述しますが、「重いから避ける」ではなく自分のサーバーで測ってから判断するのが正解です。
All-In-One Security (AIOS)｜無料で幅広い機能を試したい場合
無料で最大限の機能数を求めるなら有力な選択肢です。
UpdraftPlus（バックアッププラグインの大手）を開発するTeam Updraftが提供しており、ログイン保護・ファイアウォールルール・スパム対策・データベース設定変更・ファイルパーミッション診断など、非常に広範な機能を無料で提供しています。セキュリティ強度をスコア形式で可視化するダッシュボードがあり、対策状況を非エンジニアに説明する際に便利です。
ただしマルウェアスキャンはPremium版の機能です。無料版に含まれるのはファイル変更検知（改ざんの通知）までで、マルウェアの検出そのものは行いません。ここを混同したまま「無料で全部まかなえる」と考えると、想定した防御になりません。
また機能が広範ゆえに、設定項目が多く、誤設定による事故が起きやすいという性質があります。特に「.htaccessの書き換えを伴う設定」「データベースのテーブル接頭辞（プレフィックス）変更」「ログインURL変更」は、失敗するとサイト全体が表示できなくなる可能性があります。必ずバックアップを取得したうえで、1項目ずつ有効化して挙動を確認してください。
AIOSは「検証環境で挙動を確認できる体制がある」場合に力を発揮します。本番サイトでいきなり全機能をONにする運用は推奨しません。
Kadence Security（旧Solid Security／旧iThemes Security）｜名称変更に注意が必要な定番
機能とUIのバランスに優れた定番ですが、2026年時点で「Kadence Security」に名称変更されている点に注意が必要です。
このプラグインは iThemes Security → Solid Security → Kadence Security と2度のリブランドを経ています。提供元はStellarWP（Nexcess）。ネット上には旧名称のままの解説記事が大量に残っており、古い記事を参考にすると管理画面のメニュー名と一致せず混乱します。導入前には必ずWordPress.org公式ディレクトリで現行名を確認してください。
無料版で使えるのは、2要素認証、パスワード強度の要件設定、ローカル／ネットワーク両方のブルートフォース防御、ファイル変更検知、Site Scanner（1日4回）、データベースバックアップです。有効インストール数は70万件超で、セットアップウィザードが用意されており初期設定のハードルは比較的低めです。
ここで誤解しやすいのがスキャン機能の中身です。Site Scannerが見ているのは既知の脆弱性情報との照合と、Google Safe Browsingのブロックリスト参照が中心で、WordfenceやMalCareのようなファイル単位のマルウェアスキャンではありません。改ざんファイルの検出を主目的にするなら、この製品は選択肢から外れます。
また、reCAPTCHA、パスワードレスログイン、信頼済みデバイス、マジックリンク、Patchstack連携、ユーザー操作ログ、バージョン管理、ジオロケーションは有料版（Pro）の機能です。
そしてもう1点、ファイアウォール機能の範囲も押さえておきましょう。ファイアウォールのルール設定（カスタムルールの作成を含む）、IPアドレスの管理、不正なボットのブロック、ユーザーのBANといった機能は備えていますが、既知の脆弱性を狙った攻撃を自動で防ぐ仮想パッチは、有料版（Pro）のPatchstack連携の機能です。脆弱性への即応までプラグインに任せたいなら、有料版か、サーバー側のWAFで担保してください。
日本語の翻訳自体は提供されていますが、公式ドキュメントやサポート情報は英語が中心です。機能バランスは良好なものの、名称変更の経緯も踏まえると、社内に情報を引き継ぐ運用体制がある組織向けといえます。
Sucuri Security｜外部からの改ざん検知・監視を重視するなら
ファイル整合性監視とセキュリティ監査ログに強みを持つ、「検知」に特化した設計のプラグインです。
無料版の中心機能は「リモートマルウェアスキャン」「ファイル整合性チェック」「セキュリティアクティビティの監査ログ」「ブロックリスト監視」「2要素認証」です。マルウェアスキャンはSucuri側から外部的に行うため、サイトのサーバーへの負荷は軽く抑えられます。実際のWAF機能は有料のクラウド型サービス側で提供され、DNSを切り替えてトラフィックを経由させる構成になります。
注意したいのはログイン保護の範囲です。無料版が提供するのはログイン失敗の記録と可視化までで、ブルートフォース攻撃を能動的にブロックする機能は有料のファイアウォール側に含まれます。「Sucuriを入れたから総当たり攻撃は防げている」という理解は誤りです。
使いどころとしては、「誰がいつ何を変更したか」を追跡したい複数人運用のサイト、あるいは改ざん被害の有無を定期確認したいケースが挙げられます。逆に、無料版だけで攻撃を能動的にブロックする用途には向きません。ログイン防御は、CenterShieldやSiteGuard、CloudSecureなど別のプラグインに任せる構成が現実的です。
Sucuriは「防御」ではなく「検知と記録」のレイヤーとして組み込むのが正しい使い方です。
MalCare｜サーバー負荷を避けたいEC・会員制サイト向け
スキャン処理をクラウド側で実行するため、サーバーリソースを消費せずにマルウェア対策を行いたいサイトに適しています。
MalCareはサイトのファイル情報を自社クラウドに送信して解析する方式を採っています。そのためWordfenceのようなサーバー上でのフルスキャンが不要になり、ECサイトや会員制サイトのようにアクセスが常時発生し、かつレスポンス低下が売上に直結する環境と相性が良くなります。
無料版で使えるのはクラウドスキャン、WAF、CAPTCHAによるログインページ保護までです（ボット対策は、公式の料金表では有料プランの機能として掲載されています）。ワンクリックでのマルウェア駆除は有料版の機能である点に注意してください。「感染を見つけたら自動で駆除される」と考えて無料版を導入すると、いざというときに検知だけで止まります。
注意点として、有効インストール数は10万件台と前述の海外大手より小規模であり、UIは英語のみです。また、クラウドに情報を送信する仕様のため、取り扱うデータの機密性が高いサイトでは、社内のセキュリティポリシーとの整合確認が必要になります。
MalCareは「サーバー負荷を避けたい」「駆除まで一気通貫で行いたい」という明確な要件がある場合に選ぶプラグインです。
失敗しないWordPressセキュリティプラグインの選び方｜5つの判断基準
プラグインは「機能が多いほど良い」わけではありません。以下の5基準で絞り込んでください。
セキュリティプラグイン自体がWordPressにとっての追加コードであり、増やすほど攻撃面（アタックサーフェス）と障害要因が増えるためです。
これは机上の話ではありません。本記事で紹介しているSiteGuard WP Pluginにも、開発元自身が公表している脆弱性情報のページが存在します。セキュリティプラグインだから安全、ということはない——だからこそ、開発元が脆弱性を隠さず公表し、修正版を配布しているかどうかが選定基準になりますし、入れたあとに更新し続けることが前提になります。
①サイトの規模と目的に機能が見合っているか
数十ページのコーポレートサイトに、EC向けのリアルタイム監視機能は不要です。まず自社サイトが何を守るべきかを定義してください。
| サイト種別 | 主に守るべきもの | 推奨構成 |
|---|---|---|
| コーポレートサイト（小〜中規模） | 改ざん・ブランド毀損 | CenterShield ＋ サーバーWAF（ログイン防御だけでよければ SiteGuard または CloudSecure） |
| オウンドメディア | 記事の改ざん・スパム | CenterShield（コメントスパム対策を含む）または SiteGuard ＋ コメントスパム対策 |
| ECサイト・会員制サイト | 個人情報・決済情報 | MalCare または Wordfence Premium ＋ クラウドWAF |
| 多言語・グローバルサイト | 広域からの攻撃 | Wordfence Premium ＋ クラウド型WAF |
②日本語対応とサポート体制
運用担当者が設定内容を理解できないプラグインは、セキュリティ上むしろ危険です。意味の分からない項目をONにしたまま放置する、あるいは警告メールを読み飛ばすといった運用が常態化するためです。社内に英語ドキュメントを読める担当者がいない場合、国産プラグイン（CenterShield／SiteGuard／CloudSecure）を優先してください。
③開発元の信頼性と更新頻度
WordPress.orgのプラグインページで、必ず次の3点を確認します。
- 最終更新日——更新間隔だけで判断せず、変更履歴・サポート状況・既知の脆弱性への対応状況も確認する
- 「最新バージョンでテスト済み」の表記——現行のWordPressバージョンに対応しているか
- 有効インストール数とレビュー数——利用状況の参考にする。ただし、利用者の多さだけで脆弱性の発見・修正の早さは判断できない
④レンタルサーバー側のWAF・CDNとの役割分担
ここが最も見落とされる基準です。エックスサーバー、さくらのレンタルサーバ、ロリポップ、ConoHa WINGなど主要な国内レンタルサーバーは、標準でWAFを提供しています。ここにプラグイン側のWAFを重ねると、防御が二重になるだけでなく、正常な操作まで弾かれる誤検知が発生することがあります。
サーバー側WAFを基本としつつ、WordPress固有の攻撃を補完できるプラグイン側WAFを併用する方法もあります。併用する場合は、誤検知や機能重複がないか確認してください。
⑤無料版で足りるか／有料版が必要なラインはどこか
無料版で十分なのは、次の条件を満たす場合です。
- 会員情報・決済情報を扱っていない
- サイト改ざんが発生しても事業継続に致命傷を与えない
- 更新作業とバックアップを定期的に実施する運用体制がある
逆に、個人情報を保持している／停止すると売上が止まる／社外に対して安全性を説明する責任があるサイトは、有料版またはマネージドな保守サービスの導入を検討すべきラインです。
【保守現場の実例】プラグイン導入で実際に起きたトラブルと回避策
セキュリティプラグイン導入で最も多い事故は「攻撃を受けたこと」ではなく、設定と競合による自滅です。
セキュリティプラグインの多くが wp-login.php の挙動、.htaccess、リクエストヘッダーといった同じ箇所を書き換えにいくためです。単独では正しく動く機能同士が、組み合わせた瞬間に破綻します。
WPセンターでは他社から保守を引き継ぐ案件を数多く扱っており、その初手は必ず現行環境の棚卸しです。そこで高い頻度で見つかるのが、次の3つの状態です。
- ログインURL変更機能を持つプラグインが、2つ以上同時に有効化されている
- 作業のために一時停止したサーバー側WAFが、そのまま戻されていない
- セキュリティプラグインは入っているが、WordPress本体・テーマ・他プラグインが数バージョン遅れている
いずれも攻撃を受けた形跡ではなく、設定の重複と放置です。セキュリティプラグインを入れたこと自体が目的化し、そこで運用が止まってしまっているケースが大半を占めます。
ログイン防御プラグインの併用｜管理画面から締め出される典型パターン
ログインURL変更機能を持つプラグインを、2つ以上同時に有効化してはいけません。
この機能を持つのは、CenterShield、SiteGuard WP Plugin、CloudSecure WP Security、All-In-One Security (AIOS)、Kadence Security、WPS Hide Loginなどです。複数を同時に有効化すると、片方が生成したログインURLをもう片方がブロックする、あるいはリダイレクトがループするといった状態になり、管理者自身が管理画面に入れなくなります。
なおWordfenceにはログインページのURLを変更する機能はありません。そのため上記のプラグインと共存させること自体は可能ですが、ログイン試行制限が二重にかかるため、想定より早くロックされたり、どちらがブロックしたのか切り分けられなくなったりします。機能が重なる場合は、必ずどちらか一方に寄せてください。
回避策は次のとおりです。
- ログインURL変更は1つのプラグインに限定し、他方では必ずOFFにする
- 設定変更前に、変更後のログインURLを別ブラウザ（シークレットウィンドウ）で必ず確認してから、元のセッションを閉じる
- FTP／SSHでのアクセス手段を事前に確保しておく（ロックアウト時の唯一の復旧経路）
ログイン制限を入れてもブルートフォースが止まらないときの盲点
ログイン試行制限を設定したにもかかわらず不正アクセスの試行が続く場合、xmlrpc.php が攻撃の入口になっている可能性があります。
xmlrpc.php は、現在もブルートフォース攻撃の対象になりやすいエンドポイントです。ログイン画面だけでなく、XML-RPCへの対策も確認してください。利用していない場合は無効化し、Jetpackなどで必要な場合はWAFやレート制限などで保護します。
対処は次の3点です。
- Jetpackやモバイルアプリからの投稿を使っていなければ、xmlrpc.phpを無効化する（本記事で紹介した国産プラグインはいずれも設定項目を持っています）
- ログインフォームにreCAPTCHAまたは画像認証を併用する
- ユーザー名の漏えい防止を有効化し、総当たりの前提となるIDを特定させない
不正ログインの試行が続いているサイトの対応では、ログイン画面側の設定を細かく詰める前に、まずこの3点が塞がっているかを確認するところから着手します。
レンタルサーバーWAFとの誤検知｜サーバー別の注意点
管理画面での投稿保存・プラグイン更新が「403 Forbidden」になる場合、その原因の多くはサーバー側WAFです。
HTML／JavaScriptを含む記事本文の保存、テーマファイルの編集、特定の文字列（SQL構文に似たもの）を含むフォーム送信などが、WAFのシグネチャに引っかかります。
| サーバー | 設定場所 | 備考 |
|---|---|---|
| エックスサーバー | サーバーパネル →「WAF設定」 | 設定変更の反映に時間がかかります。公式マニュアルでは新パネルで最大30分程度、旧パネルで最大1時間程度と案内されています |
| さくらのレンタルサーバ | コントロールパネル →「セキュリティ」→「WAF設定ドメイン」 | ドメイン単位で設定。WAF検出ログは前日分の表示で、即時反映ではありません |
| ロリポップ！ | ユーザー専用ページ →「WAF設定」 | 公式マニュアルでは「有効」状態が推奨されています |
| ConoHa WING | コントロールパネル →「WING」→「サイト管理」→「サイトセキュリティ」→「WAF」タブ | 検出ログから、特定の攻撃内容を個別に「除外」設定できます |
ここで実務上の落とし穴になるのが、設定変更が即座には反映されないサーバーがあるという点です。エックスサーバーの場合、公式マニュアルで最大30分程度（旧パネルは最大1時間程度）とされています。「WAFをOFFにしたのに、まだ403が出る」という状況の多くは、設定ミスではなく単に反映待ちです。ここで慌てて他の設定まで触ると、原因の切り分けができなくなります。
なお、誤検知が特定のルールに起因すると分かっている場合は、WAF全体をOFFにするのではなく該当ルールだけを除外設定するのが安全です。ConoHa WINGのように、検出ログから個別に除外できるサーバーもあります。
重要なのは、作業後に必ず再有効化することです。「一時的にOFFにしたまま戻し忘れる」ことが、実務上の最大のリスクになります。
アクセス制限でwp-cronが止まり、予約投稿とバックアップが静かに停止する
管理画面へのIP制限やBasic認証をかけたとき、同時に wp-cron.php へのアクセスまで遮断されてしまう——これは実際の保守現場で繰り返し遭遇する事故です。
WordPressの予約投稿、バックアップの定期実行、プラグインの自動更新は、いずれもwp-cronに依存しています。ところがwp-cronが止まっても管理画面にエラーは表示されません。気づくのは「予約したはずの記事が公開されていない」「バックアップが数週間分存在しない」と分かった時点、つまり手遅れになってからです。
回避策は次のいずれかです。
wp-cron.phpを認証・アクセス制限の対象外に設定する（Apacheであれば当該ファイルを除外する記述を追加）wp-config.phpでDISABLE_WP_CRONをtrueに設定し、サーバー側のcronから定期実行する
なお、Apacheで除外設定を書く際によく使われる Satisfy any は、Apache 2.4 では非推奨（deprecated）とされています。公式ドキュメントでも、Order／Allow／Deny といった旧来のディレクティブと、新しい Require を混在させることは「技術的には可能だが推奨しない」と明記されています。設定を書く前に、利用中のApacheバージョンと推奨される記法を必ず確認してください。古い解説記事をそのままコピーすると、除外が効かないまま「設定したつもり」になります。
管理画面のIP制限は「今つながること」だけで判断しない
IP許可リストによる管理画面の制限は防御として強力ですが、運用でつまずく確率が最も高い設定でもあります。
実務で問題になるのは次のような場面です。
- 拠点の追加、リモートワーク、回線のIP変動によって、自社の担当者が締め出される
- 本番環境とステージング環境の両方に許可リストがあり、片方だけ更新して気づかない
- 制作会社やパートナーが作業する場合、その会社の接続元IPも登録が必要になり、依頼のたびに申請と反映の手間が発生する
固定IPが確保できない環境では、IP制限に頼らず2要素認証とログイン試行制限に寄せるほうが、結果的に安全かつ運用が回ります。IP制限を採用する場合は、許可リストの管理を誰が行うかまで含めて運用設計してください。
【実測】Wordfenceのスキャン中、表示速度はどれだけ落ちるのか
「Wordfenceは重い」という評価は広く共有されています。ただ、実際にどれだけ遅くなるのかを計測した情報はほとんど見当たりません。そこで当ブログで検証しました。
計測条件
- 対象：当ブログの記事ページ1本（nginx環境）
- 規模：14,685ファイル／23プラグイン／4テーマ／94投稿
- ページキャッシュ：なし（
Cache-Control: no-store, no-cache。毎回PHPが動作する状態） - 計測指標：TTFB（サーバーが最初の1バイトを返すまでの時間）
- 方法：5秒間隔で30回計測し、スキャン停止中とスキャン実行中を比較
- スキャン所要時間：2分1秒（12,596URLを含むフルスキャン）
計測結果
| 状態 | サンプル数 | 最小 | 中央値 | 平均 | p95 | 最大 |
|---|---|---|---|---|---|---|
| スキャン停止中 | 30 | 80.9 ms | 104.7 ms | 109.3 ms | 138.5 ms | 208.7 ms |
| スキャン実行中 | 24 | 81.4 ms | 107.7 ms | 110.5 ms | 137.3 ms | 174.3 ms |
スキャン実行中も30回計測していますが、スキャンが2分1秒で完了したのに対し計測には2分25秒かかったため、スキャン完了後に取得された末尾6サンプルを除外し、24サンプルで集計しています。
差は中央値で3.0ms（2.9%）。統計的な有意差は認められませんでした（Mann-Whitney U検定、p=0.47）。p95に至ってはスキャン中のほうがわずかに速いという結果です。
14,685ファイルと12,596件のURLを2分間で処理する、決して軽くない処理を走らせている最中でも、閲覧者から見た表示速度には現れなかったということになります。
この結果をどう解釈するか
「Wordfenceは重いから避けるべき」という一般論を、この結果は無条件には支持しません。サーバーリソースに余裕がある環境では、スキャンの負荷は閲覧者に届く前に吸収されます。
一方で、CPU使用率やプロセス数に厳しい制限がかかる共用サーバーでは事情が変わります。制限に抵触すれば503エラーやスキャンの中断が発生し、その場合は数msどころの話ではなくなります。つまり重要なのは「Wordfenceが重いかどうか」ではなく、自分のサーバーが、スキャンの負荷を吸収できるかどうかです。
自分のサイトで測る方法
評判ではなく実測で判断できるよう、使用したコマンドを公開します。Windowsなら標準の curl.exe でそのまま実行できます。
curl.exe -s -L -o NUL -w "%{time_starttransfer} %{http_code}" "https://example.com/"計測時のポイントは3つです。
- ページキャッシュを迂回する——キャッシュされたHTMLを測ってもPHPの負荷は反映されません。キャッシュプラグインやCDNが有効なら、URLにランダムなクエリを付けて迂回します
- 30回以上測り、中央値で比較する——1回の計測では判断できません。平均値は外れ値1つで数十ms動くため、中央値を使います
- スキャンの所要時間に計測時間を合わせる——スキャンが先に終わると、後半は平常時を測ることになり差が消えます
サーバーパネルのリソースモニターでCPU使用率のグラフも併せて確認すると、より実態が掴めます。
スキャナ同士がぶつかる｜セキュリティプラグインが別のセキュリティプラグインを「マルウェア」と検知する
今回の検証中、Wordfenceのスキャン結果に「致命的」判定が3件表示されました。検出されたのは、いずれも別のマルウェアスキャナ系プラグインが持つファイルです。
これはスキャナ同士の典型的な誤検知です。マルウェア検知プラグインは、検体の判定用に「悪意あるコードのサンプルやシグネチャ」を自身のフォルダ内に保持しています。そのファイルを別のスキャナが走査すると、当然ながらマルウェアとして反応します。同様の報告はWordPress.orgの公式フォーラムにも上がっています。
厄介なのは、「致命的」と表示されるため、本物の侵入と区別がつきにくい点です。焦ってファイルを削除すると、今度はそのスキャナ側が動作不能になります。
対処の考え方は次のとおりです。
- 検出されたパスがインストール済みプラグインのフォルダかどうかを確認する
- 該当プラグインを自分で入れた覚えがあるか確認する。覚えがない場合は削除せず、まず調査する（削除すると侵入経路の痕跡も消えます）
- 正規プラグインのファイルだと確認できたら、該当の検出結果だけを「無視」に設定する。フォルダ全体を除外設定にすると、そこに本物を置かれたときに検知できなくなります
日常的な対策は、常駐させるマルウェアスキャン機能を持つプラグインを1本に絞ることを基本にします。常駐スキャナを重ねると、誤検知や運用工数が増えることがあります。ただし、感染が疑われる場合に、別のスキャナを追加調査として一時的に利用するのは有効です。
設定ミスによる管理画面ロックアウトと復旧手順
ロックアウトは必ず起こり得るものとして、復旧手順を事前に用意しておきます。
万一ログインできなくなった場合の復旧フローは次のとおりです。
- FTP／SSHでサーバーに接続
/wp-content/plugins/内の該当プラグインフォルダ名を変更（例：siteguard→siteguard_off）- これによりプラグインが強制的に無効化され、ログイン可能になる
- 管理画面から設定を修正し、フォルダ名を元に戻す
この手順を実行するにはFTPアカウント情報が必要です。セキュリティ設定を変更する前に、接続情報の所在と疎通を必ず確認してください。
WordPressセキュリティプラグインの導入・初期設定手順
導入手順そのものは共通です。重要なのは「バックアップ → 1機能ずつ有効化 → 別ブラウザで確認」の順序を守ることです。
インストールの共通フロー
- バックアップを取得（BackWPup、UpdraftPlus、サーバー側の自動バックアップなど）
- WordPress管理画面から「プラグイン」→「新規追加」
- プラグイン名で検索し、提供元が正しいことを確認して「今すぐインストール」
- 「有効化」
- 初期設定はすべてOFFの状態から、1項目ずつONにする
- 各設定変更後、シークレットウィンドウでサイト表示とログインを確認
CenterShield の設定の勘所
CenterShieldは、有効化した時点ではサイトに何も変更を加えません。すべての設定がOFFの状態から始まり、.htaccess への書き込みやスキャンの予約も、自分で有効にするまで行われません。
有効化したら、管理画面の「CenterShield」メニューを開き、ダッシュボードの「推奨設定を適用」で推奨の対策をまとめて有効化するか、項目ごとに有効化します。設定が済んだら、マルウェアスキャンを一度実行して現状を確認してください。
万一に備えて、次の復旧方法を押さえておくと安心です。
- 変更したログインURLを忘れた場合：FTPやサーバーのファイルマネージャーで、
wp-content/plugins/内のCenterShieldのフォルダ名を変更すると、通常の/wp-login.phpでログインできます（設定は保持されます） - 管理画面に入れなくなった場合：
wp-config.phpにdefine( 'WPCS_DISABLE', true );を追記すると、CenterShieldのすべての機能が一時停止します - ログイン画面のBasic認証のパスワードを忘れた場合：Basic認証は
.htaccessに書き込まれるため、フォルダ名の変更では解除されません。サイト直下の.htaccessから、CenterShieldのBasic認証の記述を削除してください
なお、軽量WAFはサーバー側のWAFと機能が重なることがあります。サーバー側でWAFを有効にしている場合も併用は可能ですが、機能重複や誤検知がないか確認し、問題が起きた場合は設定を調整してください。
SiteGuard WP Plugin の設定の勘所
インストールして有効化した時点で、ログインページのURLが自動的に変更されます。公式の説明によれば、wp-login.php が login_〈5桁の乱数〉 という形式に置き換わります。Nginx環境や .htaccess が使えないApache環境では、末尾に .php が付く点も押さえておいてください。
新しいURLは、管理者宛に「WordPress: ログインページURLが変更されました」という件名のメールで通知されます。このメールを見落とすとログイン不能になるため、有効化直後に必ず確認し、管理画面の「SiteGuard」→「ログインページ変更」で新しいURLをブックマークしてください。万一URLが分からなくなった場合は、バージョン1.8.0で追加されたログインURLレスキュー機能（/?siteguard-rescue=1 にアクセスし、管理者のメールアドレスを入力すると、ログインURLがメールで届く機能）も使えます。
なお「管理ページアクセス制限」は、IPが変動する環境ではOFF推奨です。
CloudSecure WP Security の設定の勘所
2段階認証を有効化する際は、認証アプリの登録が完了したことを別デバイスで確認してから、既存セッションを終了してください。シンプルWAFはサーバー側WAFと機能が重複することがあるため、併用する場合は誤検知がないか確認し、必要に応じて設定を調整します。
Wordfence Security の設定の勘所
インストール直後のファイアウォールは「Learning Mode（学習モード）」で動作します。公式ドキュメントによれば、この学習期間は既定で7日間で、オプション画面から変更もできます。
重要なのは、この期間中にサイトの機能を一通り操作しておくことです。公式が推奨しているのは、記事や固定ページの投稿・公開、テーマの設定変更、プラグインの設定変更、ウィジェットの追加と削除、コメントの投稿と承認、そして導入済みプラグインの全機能を使ってみること。ここで通った操作が許可リストに登録されるため、使わなかった機能ほど、後から誤ってブロックされやすくなります。
一通り操作し終えたら、ファイアウォールのオプション画面で状態を「Enabled and Protecting」に切り替えます。メール通知は初期設定のままだと大量に届くため、通知レベルを「Critical」中心に絞り込んでください。
プラグインだけでは守れない3つの領域
セキュリティプラグインは対策全体の一部にすぎません。残る3領域は運用でしか埋められません。
前述のとおり脆弱性の大半がプラグイン・テーマ由来であり、「入れたプラグインを更新し続ける」という行為そのものが最大の防御だからです。どれほど高機能なセキュリティプラグインを入れても、放置された古いプラグインの既知脆弱性は塞げません。
この点は、前出のPatchstackレポートの数字がはっきり示しています。同レポートによれば、すでに悪用が確認されている脆弱性に絞った調査で、WordPress固有の脆弱性を狙った攻撃のうち、従来型の防御がブロックできたのは12%にとどまりました。さらに、影響度の高い脆弱性のおよそ半数が公開から24時間以内に悪用されており、最初の悪用までの時間は加重中央値で5時間と報告されています。
プラグインやWAFは「時間を稼ぐ手段」であって、根本的な穴を塞ぐのは更新作業です。セキュリティプラグインさえ入れておけば安心、という理解は現実のデータと一致しません。
①コア・テーマ・プラグインの更新運用
WordPress本体、テーマ、プラグインを最新に保つことが、費用対効果の面で最も優れた対策です。ただし、自動更新に全面依存すると、更新によるレイアウト崩れや機能停止を検知できません。
- セキュリティパッチ（マイナーアップデート）は自動更新を有効化
- メジャーアップデートはステージング環境で検証してから本番反映
- 更新前に必ずバックアップを取得
- 更新後は主要ページ・フォーム送信・決済フローの動作確認
ステージング検証を挟むべき理由は、更新そのものがサイトを壊すことがあるからです。PHPのバージョンを上げた際に、古い書き方を残したテーマやプラグインが致命的エラーを起こして管理画面が真っ白になる、サーバー移行に伴うURL置換の不備で500エラーが発生する——こうしたトラブルは、保守の現場では日常的に起きています。
セキュリティプラグインもこの例外ではありません。「更新するのが怖いから古いまま使い続ける」という判断が、結果として最も危険な状態を生みます。怖くない状態、つまり壊れてもすぐ戻せる体制を先に作ることが、更新運用の本質です。
②バックアップと復旧体制
改ざんされた場合、最終的な解決手段はクリーンな状態からの復元です。バックアップは「取得していること」ではなく「復元できること」が要件になります。
- 保存先はサーバーとは別の場所（クラウドストレージ等）に分離
- 世代管理（最低でも7世代、可能なら30日分）
- 年に1回は実際に復元テストを実施する
③脆弱性情報の継続監視
自社サイトで使用しているプラグインに脆弱性が公表された際、それを知る仕組みがなければ対処のしようがありません。Patchstack、WPScan、JPCERT/CCの注意喚起など、脆弱性情報を継続的にウォッチする体制が必要です。CenterShieldのマルウェアスキャンでは、導入しているプラグイン・テーマを既知の脆弱性データベースと照合できるため、こうした確認の手間を減らせます。
この3領域は、社内にWordPressに精通した担当者が常駐していない限り、現実的には形骸化します。運用を仕組みとして外部化するという選択肢も含めて検討してください。
WordPressセキュリティプラグインに関するよくある質問
- QWordPressセキュリティプラグインとは何ですか？
- A
WordPressサイトを不正ログイン・改ざん・マルウェア感染などの攻撃から守るための機能拡張です。ログイン試行の制限、WAF、マルウェアスキャン、2要素認証といった機能を、専門知識がなくても管理画面から設定できるようにするものです。
- Qセキュリティプラグインは複数入れてもいいですか？
- A
推奨しません。特にログインURL変更機能を持つプラグインを複数有効化すると、管理画面にログインできなくなる事故が発生します。「ログイン防御は1本」を原則とし、役割が明確に異なる場合（例：ログイン防御＋外部監視）に限り、機能の重複がないことを確認したうえで併用してください。ログイン防御からマルウェアスキャンまで1本で済ませたい場合は、CenterShieldのようなオールインワン型を選ぶのも方法です。
- Q無料プラグインだけで十分ですか？
- A
会員情報や決済情報を扱わず、更新・バックアップの運用体制があるサイトであれば、無料プラグインでも一定の水準は確保できます。一方、個人情報を保持するサイトや、停止が事業に直結するサイトでは、有料版または保守サービスの導入を推奨します。
- Qセキュリティプラグインを無効化するとどうなりますか？
- A
設定していた防御機能が停止します。特にログインURLを変更していた場合、無効化によって通常の
wp-login.phpに戻ります。この仕様を利用して、ロックアウト時にはFTPでプラグインフォルダ名を変更して強制無効化し、復旧することができます。
- Qマルウェアに感染した場合、駆除できるプラグインはありますか？
- A
CenterShieldは、検出したファイルの隔離や、WordPress公式の元ファイルからの復元を管理画面から行えます。Wordfenceも無料版で、改変されたファイルの修復や不審なファイルの削除が可能です。MalCareは有料版でワンクリックの自動駆除に対応しています。ただし、感染後の対応はプラグインだけで完結しないケースがほとんどです。侵入経路の特定、バックドアの除去、パスワード・認証キーの全面変更、Google Search Consoleでのセキュリティ問題の解除申請まで必要になるため、専門業者への相談を推奨します。
- Qセキュリティプラグインは本当に必要ですか？
- A
サーバー側WAFと適切な更新運用があれば、プラグインなしでも一定の防御は可能です。ただし、ブルートフォース攻撃（総当たりログイン）への対策はプラグインが最も手軽で効果的です。WordPressはログインURLが既定で公開されているため、最低限ログイン防御だけは導入することを推奨します。
まとめ｜サイト規模別の推奨構成
WordPressセキュリティプラグインは、「高機能なものを選ぶ」のではなく「自社の規模・体制に合ったものを1本選び、正しく設定し、更新し続ける」ことが本質です。
規模別の推奨構成を整理します。
| サイト規模・種別 | 推奨プラグイン | 併用すべき対策 |
|---|---|---|
| 個人ブログ・小規模サイト | CenterShield (センターシールド)、または SiteGuard WP Plugin／CloudSecure WP Security | サーバー側WAF、自動更新 |
| 中規模コーポレートサイト | CenterShield（2要素認証・マルウェアスキャンあり） | サーバー側WAF、ステージング検証、外部バックアップ |
| 大規模・多言語サイト | Wordfence Premium | クラウドWAF、脆弱性情報の継続監視 |
| EC・会員制サイト | MalCare または Wordfence Premium | クラウドWAF、世代バックアップ、復元テスト |
そして繰り返しになりますが、プラグインの導入は出発点であって、ゴールではありません。更新運用、バックアップと復元体制、脆弱性情報の監視——この3つが回って初めて、セキュリティ対策は機能します。
まずは国産・日本語・無料で使えるCenterShieldで、自社サイトの現状をスキャンするところから始めてみてください。自社での対応が難しい場合は、WordPress保守専門チームを持つ当社が継続監視と定期診断を代行します。ぜひ、WPセンターに一度お問い合わせください。
WPセンター安心サポート
WPセンターは初期費用0円で始められます。
