WordPressセキュリティプラグインとは、不正ログイン・改ざん・マルウェア感染といった攻撃からWordPressサイトを守るための機能拡張です。ログイン試行の制限、WAF（Web Application Firewall）、マルウェアスキャン、2段階認証などを管理画面から設定できます。
2026年時点で多くの企業サイトにとっての現実解は、「国産プラグイン1本＋サーバー側WAF＋更新・バックアップ運用」の組み合わせです。海外製の高機能プラグインを入れることが正解とは限りません。むしろ、機能が重複する複数のプラグインを同時に入れたことで管理画面にログインできなくなる、サーバー側のWAFと干渉して正常な投稿が弾かれる——こうした事故のほうが、実際の保守現場ではよく起こります。
本記事では、WordPress保守サービス「WPセンター」として企業サイトの運用を預かる立場から、主要7プラグインの機能・料金・日本語対応を比較したうえで、カタログスペックでは分からない「入れたあとに何が起きるか」まで踏み込んで解説します。
※本記事のプラグイン情報は2026年9月時点のWordPress.org公式ディレクトリの掲載内容に基づきます。料金・有効インストール数は変動するため、導入前に公式サイトで最新情報をご確認ください。
WordPressセキュリティプラグインおすすめ7選【比較一覧表】
以下の7種類を押さえておけば、個人ブログから中〜大規模のコーポレートサイトまで対応できます。
というのも、WordPressの脆弱性の大半は、コア本体ではなくプラグイン・テーマ由来だからです。セキュリティベンダーPatchstackの年次レポートによれば、2025年にWordPressエコシステムで確認された新規脆弱性は11,334件。その内訳は次のとおりです。
- プラグイン：91%（約10,300件）
- テーマ：9%（約1,000件）
- WordPressコア本体：6件（いずれも低リスク）
件数は前年比42%増で、2023年の5,948件から2年で約1.9倍に増加しています。「WordPressは危険」なのではなく、危険なのは管理されていないプラグインとテーマというのが、データが示す実態です。
つまり「何を入れるか」と同じくらい、「何を入れないか」「入れたものをどう更新し続けるか」が重要になります。
主要7プラグイン 機能比較表
| プラグイン名 | 提供元 | 有効インストール | WAF | マルウェアスキャン | ログイン保護 | 2段階認証 | 日本語UI | 料金 |
|---|---|---|---|---|---|---|---|---|
| SiteGuard WP Plugin | JP-Secure（EGセキュアソリューションズ） | 60万+ | × | × | ◎ | × | ◎ | 完全無料 |
| 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 | 20万+ | ◎ | ◎ （クラウド処理） | ○ | ○ | × | 無料／有料版あり |
※◎＝標準搭載で実用十分、○＝搭載、△＝限定的、×＝非搭載
※有効インストール数は2026年9月時点のWordPress.org公式ディレクトリの掲載値です。料金は各公式サイトをご確認ください。
SiteGuard WP Plugin｜国内の中小規模サイトにおける標準解
日本国内向けのコーポレートサイト・オウンドメディアであれば、まず最初に検討すべき国産プラグインです。
理由は3点あります。第一に、開発元がEGセキュアソリューションズ（旧JP-Secure）という日本のセキュリティ専業ベンダーであり、日本語のドキュメントとUIが完備されていること。第二に、機能を「ログインページと管理画面の防御」に絞り込んでいるため動作が軽く、他のプラグインやサーバー環境と衝突しにくいこと。第三に、完全無料でありながら継続的にアップデートされており、WordPress 7.x系にも追随している点です。
搭載されている主な機能は次のとおりです。
- 管理ページアクセス制限
- ログインページURL変更（
wp-login.phpの変更） - 画像認証（CAPTCHA）
- ログインロック（一定時間内の連続失敗をブロック）
- ログインアラート（ログイン成功時のメール通知）
- フェールワンス（正しいID／パスワードでも1回目は必ず失敗させる）
- XML-RPC防御（ピンバック無効化／XML-RPC全体の無効化）
- ユーザー名漏えい防御
- 更新通知
- WAFチューニングサポート（別製品「SiteGuard Server Edition」向けに誤検知の除外ルールを生成する補助機能）
機能範囲は正確に押さえておく必要があります。SiteGuardはマルウェアスキャン機能を持たず、2段階認証も非搭載、WAF本体も搭載していません。上記のWAFチューニングサポートは、あくまで別製品のサーバー型WAF向けにルールを生成する補助機能です。
改ざん検知や感染後の駆除、あるいは2段階認証までカバーしたい場合は、後述するプラグインやサーバー側・外部サービスとの組み合わせが必要になります。
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クイックスタート」では、チェックが入った状態で同時導入の候補として提示されるため、意識しないまま導入済みになっているケースがあります。まず管理画面のプラグイン一覧を確認してみてください。なお他社サーバーでも利用可能です。
「国産・日本語・無料・オールインワン」という条件を最も満たすのがCloudSecure WP Securityです。ただし有効インストール数は10万件台と歴史が浅いため、長期運用サイトでは更新頻度のウォッチを継続してください。
Wordfence Security｜機能を最優先する中〜大規模サイト向け
世界で500万件以上に導入された最大手です。マルウェアスキャンとWAFを1本で完結させたい場合の第一候補になります。
エンドポイントファイアウォール（サーバー上で動作するWAF）、マルウェアシグネチャによるファイルスキャン、リアルタイムのIPブロックリスト、ログイン保護、2段階認証までを単体でカバーしています。脆弱性情報の収集・公開を自社で行っているベンダーでもあり、脅威情報の一次発信元として参照されることも少なくありません。
一方で、注意点も明確です。
- スキャン時にサーバーリソースを消費する：リソースに余裕のある環境では体感差は出ませんが、CPU制限の厳しい共用サーバーでは影響が出ることがあります（後述の実測を参照）
- 無料版はシグネチャ更新が30日遅延：最新の脅威への即応を求めるならPremiumが前提になります
- 管理画面が英語主体：日本語化は限定的で、担当者のリテラシーを選びます
- 通知メールが多い：初期設定のままだと運用担当者が通知疲れを起こしやすくなります
Wordfenceは「運用担当者が英語ドキュメントを読める」「サーバーリソースに余裕がある」中〜大規模サイト向けです。なお、当ブログで実測したところスキャン中の表示速度の低下はほぼ観測されませんでした。詳細は後述しますが、「重いから避ける」ではなく自分のサーバーで測ってから判断するのが正解です。
All-In-One Security (AIOS)｜無料で幅広い機能を試したい場合
無料で最大限の機能数を求めるなら有力な選択肢です。
UpdraftPlus（バックアッププラグインの大手）を開発するTeam Updraftが提供しており、ログイン保護・ファイアウォールルール・スパム対策・データベース設定変更・ファイルパーミッション診断など、非常に広範な機能を無料で提供しています。セキュリティ強度をスコア形式で可視化するダッシュボードがあり、対策状況を非エンジニアに説明する際に便利です。
ただし機能が広範ゆえに、設定項目が多く、誤設定による事故が起きやすいという性質があります。特に「.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段階認証、脆弱性スキャナー、ファイアウォール、ブルートフォース防御などを備え、有効インストール数は70万件超。セットアップウィザードが用意されており、初期設定のハードルは比較的低めです。
機能バランスは良好ですが、日本語UIがない点と名称変更の経緯を踏まえると、社内に情報を引き継ぐ運用体制がある組織向けといえます。
Sucuri Security｜外部からの改ざん検知・監視を重視するなら
ファイル整合性監視とセキュリティ監査ログに強みを持つ、「検知」に特化した設計のプラグインです。
無料版の中心機能は「リモートマルウェアスキャン」「ファイル整合性チェック」「セキュリティアクティビティの監査ログ」「ブロックリスト監視」であり、サーバー上で重い処理を行いません。実際のWAF機能は有料のクラウド型サービス側で提供され、DNSを切り替えてトラフィックを経由させる構成になります。
使いどころとしては、「誰がいつ何を変更したか」を追跡したい複数人運用のサイト、あるいは改ざん被害の有無を定期確認したいケースが挙げられます。逆に、無料版だけで攻撃を能動的にブロックする用途には向きません。
Sucuriは「防御」ではなく「検知と記録」のレイヤーとして組み込むのが正しい使い方です。
MalCare｜サーバー負荷を避けたいEC・会員制サイト向け
スキャン処理をクラウド側で実行するため、サーバーリソースを消費せずにマルウェア対策を行いたいサイトに適しています。
MalCareはサイトのファイル情報を自社クラウドに送信して解析する方式を採っています。そのためWordfenceのようなサーバー上でのフルスキャンが不要になり、ECサイトや会員制サイトのようにアクセスが常時発生し、かつレスポンス低下が売上に直結する環境と相性が良くなります。
無料版で使えるのはクラウドスキャン、WAF、ログインページ保護、ボット対策までです。ワンクリックでのマルウェア駆除は有料版の機能である点に注意してください。「感染を見つけたら自動で駆除される」と考えて無料版を導入すると、いざというときに検知だけで止まります。
注意点として、有効インストール数は20万件台と前述の海外大手より小規模であり、UIは英語のみです。また、クラウドに情報を送信する仕様のため、取り扱うデータの機密性が高いサイトでは、社内のセキュリティポリシーとの整合確認が必要になります。
MalCareは「サーバー負荷を避けたい」「駆除まで一気通貫で行いたい」という明確な要件がある場合に選ぶプラグインです。
失敗しないWordPressセキュリティプラグインの選び方｜5つの判断基準
プラグインは「機能が多いほど良い」わけではありません。以下の5基準で絞り込んでください。
セキュリティプラグイン自体がWordPressにとっての追加コードであり、増やすほど攻撃面（アタックサーフェス）と障害要因が増えるためです。実際、セキュリティプラグイン自身の脆弱性が公表された事例も複数あります。
①サイトの規模と目的に機能が見合っているか
数十ページのコーポレートサイトに、EC向けのリアルタイム監視機能は不要です。まず自社サイトが何を守るべきかを定義してください。
| サイト種別 | 主に守るべきもの | 推奨構成 |
|---|---|---|
| コーポレートサイト（小〜中規模） | 改ざん・ブランド毀損 | SiteGuard または CloudSecure ＋ サーバーWAF |
| オウンドメディア | 記事の改ざん・スパム | SiteGuard ＋ コメントスパム対策 |
| ECサイト・会員制サイト | 個人情報・決済情報 | MalCare または Wordfence Premium ＋ クラウドWAF |
| 多言語・グローバルサイト | 広域からの攻撃 | Wordfence Premium ＋ クラウド型WAF |
②日本語対応とサポート体制
運用担当者が設定内容を理解できないプラグインは、セキュリティ上むしろ危険です。意味の分からない項目をONにしたまま放置する、あるいは警告メールを読み飛ばすといった運用が常態化するためです。社内に英語ドキュメントを読める担当者がいない場合、国産プラグイン（SiteGuard／CloudSecure）を優先してください。
③開発元の信頼性と更新頻度
WordPress.orgのプラグインページで、必ず次の3点を確認します。
- 最終更新日——半年以上更新がないプラグインは候補から外す
- 「最新バージョンでテスト済み」の表記——現行のWordPressバージョンに対応しているか
- 有効インストール数とレビュー数——利用者が多いほど脆弱性の発見・修正が早い
④レンタルサーバー側のWAF・CDNとの役割分担
ここが最も見落とされる基準です。エックスサーバー、さくらのレンタルサーバ、ロリポップ、ConoHa WINGなど主要な国内レンタルサーバーは、標準でWAFを提供しています。ここにプラグイン側のWAFを重ねると、防御が二重になるだけでなく、正常な操作まで弾かれる誤検知が発生します。
原則として、WAFはサーバー側に任せ、プラグインは「ログイン防御」と「スキャン」に役割を限定する設計が安定します。
⑤無料版で足りるか／有料版が必要なラインはどこか
無料版で十分なのは、次の条件を満たす場合です。
- 会員情報・決済情報を扱っていない
- サイト改ざんが発生しても事業継続に致命傷を与えない
- 更新作業とバックアップを定期的に実施する運用体制がある
逆に、個人情報を保持している／停止すると売上が止まる／社外に対して安全性を説明する責任があるサイトは、有料版またはマネージドな保守サービスの導入を検討すべきラインです。
【保守現場の実例】プラグイン導入で実際に起きたトラブルと回避策
セキュリティプラグイン導入で最も多い事故は「攻撃を受けたこと」ではなく、設定と競合による自滅です。
セキュリティプラグインの多くが wp-login.php の挙動、.htaccess、リクエストヘッダーといった同じ箇所を書き換えにいくためです。単独では正しく動く機能同士が、組み合わせた瞬間に破綻します。
WPセンターでは他社から保守を引き継ぐ案件を数多く扱っており、その初手は必ず現行環境の棚卸しです。そこで高い頻度で見つかるのが、次の3つの状態です。
- ログインURL変更機能を持つプラグインが、2つ以上同時に有効化されている
- 作業のために一時停止したサーバー側WAFが、そのまま戻されていない
- セキュリティプラグインは入っているが、WordPress本体・テーマ・他プラグインが数バージョン遅れている
いずれも攻撃を受けた形跡ではなく、設定の重複と放置です。セキュリティプラグインを入れたこと自体が目的化し、そこで運用が止まってしまっているケースが大半を占めます。
ログイン防御プラグインの併用｜管理画面から締め出される典型パターン
ログインURL変更機能を持つプラグインを、2つ以上同時に有効化してはいけません。
この機能を持つのは、SiteGuard WP Plugin、CloudSecure WP Security、All-In-One Security (AIOS)、WPS Hide Loginなどです。複数を同時に有効化すると、片方が生成したログインURLをもう片方がブロックする、あるいはリダイレクトがループするといった状態になり、管理者自身が管理画面に入れなくなります。
なおWordfenceにはログインページのURLを変更する機能はありません。そのため上記のプラグインと共存させること自体は可能ですが、ログイン試行制限が二重にかかるため、想定より早くロックされたり、どちらがブロックしたのか切り分けられなくなったりします。機能が重なる場合は、必ずどちらか一方に寄せてください。
回避策は次のとおりです。
- ログインURL変更は1つのプラグインに限定し、他方では必ずOFFにする
- 設定変更前に、変更後のログインURLを別ブラウザ（シークレットウィンドウ）で必ず確認してから、元のセッションを閉じる
- FTP／SSHでのアクセス手段を事前に確保しておく（ロックアウト時の唯一の復旧経路）
ログイン制限を入れてもブルートフォースが止まらないときの盲点
ログイン試行制限を設定したにもかかわらず不正アクセスの試行が続く場合、xmlrpc.php が攻撃の入口になっている可能性があります。
xmlrpc.phpの system.multicall は、1回のリクエストに多数の認証試行をまとめて送れる仕様です。そのためログイン画面側の「◯回失敗したらロック」という制限をすり抜けて、大量のID・パスワードの組み合わせを試行できてしまいます。ログイン画面だけを守っても、裏口が開いたままという状態です。
対処は次の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_CRONを無効化し、サーバー側のcronから定期実行する
なお、Apacheで除外設定を書く際によく使われる Satisfy any は、Apacheのバージョンによって非推奨・非対応となっています。設定を書く前に、利用中のサーバーの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にする
- 各設定変更後、シークレットウィンドウでサイト表示とログインを確認
SiteGuard WP Plugin の設定の勘所
有効化した時点でログインURLが自動変更され、管理者宛に新URLがメール送信されます。このメールを見落とすとログイン不能になるため、有効化直後に必ずメールを確認してください。「管理ページアクセス制限」はIPが変動する環境ではOFF推奨です。
CloudSecure WP Security の設定の勘所
2段階認証を有効化する際は、認証アプリの登録が完了したことを別デバイスで確認してから、既存セッションを終了してください。シンプルWAFはサーバー側WAFと機能が重複するため、どちらか一方に寄せます。
Wordfence Security の設定の勘所
初期状態のファイアウォールは「Learning Mode（学習モード）」で動作します。1週間程度運用して誤検知がないことを確認してから「Enabled and Protecting」に切り替えます。メール通知は初期設定のままだと大量に届くため、通知レベルを「Critical」中心に絞り込んでください。
プラグインだけでは守れない3つの領域
セキュリティプラグインは対策全体の一部にすぎません。残る3領域は運用でしか埋められません。
前述のとおり脆弱性の大半がプラグイン・テーマ由来であり、「入れたプラグインを更新し続ける」という行為そのものが最大の防御だからです。どれほど高機能なセキュリティプラグインを入れても、放置された古いプラグインの既知脆弱性は塞げません。
この点は、前出のPatchstackレポートの数字がはっきり示しています。同レポートによれば、WordPress固有の脆弱性を狙った攻撃のうち、従来型の防御がブロックできたのは12%にとどまりました。さらに、影響度の高い脆弱性のおよそ半数が公開から24時間以内に悪用されており、最初の悪用までの時間は加重中央値で5時間と報告されています。
プラグインやWAFは「時間を稼ぐ手段」であって、根本的な穴を塞ぐのは更新作業です。セキュリティプラグインさえ入れておけば安心、という理解は現実のデータと一致しません。
①コア・テーマ・プラグインの更新運用
WordPress本体、テーマ、プラグインを最新に保つことが、費用対効果の面で最も優れた対策です。ただし、自動更新に全面依存すると、更新によるレイアウト崩れや機能停止を検知できません。
- セキュリティパッチ（マイナーアップデート）は自動更新を有効化
- メジャーアップデートはステージング環境で検証してから本番反映
- 更新前に必ずバックアップを取得
- 更新後は主要ページ・フォーム送信・決済フローの動作確認
ステージング検証を挟むべき理由は、更新そのものがサイトを壊すことがあるからです。PHPのバージョンを上げた際に、古い書き方を残したテーマやプラグインが致命的エラーを起こして管理画面が真っ白になる、サーバー移行に伴うURL置換の不備で500エラーが発生する——こうしたトラブルは、保守の現場では日常的に起きています。
セキュリティプラグインもこの例外ではありません。「更新するのが怖いから古いまま使い続ける」という判断が、結果として最も危険な状態を生みます。怖くない状態、つまり壊れてもすぐ戻せる体制を先に作ることが、更新運用の本質です。
②バックアップと復旧体制
改ざんされた場合、最終的な解決手段はクリーンな状態からの復元です。バックアップは「取得していること」ではなく「復元できること」が要件になります。
- 保存先はサーバーとは別の場所（クラウドストレージ等）に分離
- 世代管理（最低でも7世代、可能なら30日分）
- 年に1回は実際に復元テストを実施する
③脆弱性情報の継続監視
自社サイトで使用しているプラグインに脆弱性が公表された際、それを知る仕組みがなければ対処のしようがありません。Patchstack、WPScan、JPCERT/CCの注意喚起など、脆弱性情報を継続的にウォッチする体制が必要です。
この3領域は、社内にWordPressに精通した担当者が常駐していない限り、現実的には形骸化します。運用を仕組みとして外部化するという選択肢も含めて検討してください。
WordPressセキュリティプラグインに関するよくある質問
- QWordPressセキュリティプラグインとは何ですか？
- A
WordPressサイトを不正ログイン・改ざん・マルウェア感染などの攻撃から守るための機能拡張です。ログイン試行の制限、WAF、マルウェアスキャン、2段階認証といった機能を、専門知識がなくても管理画面から設定できるようにするものです。
- Qセキュリティプラグインは複数入れてもいいですか？
- A
推奨しません。特にログインURL変更機能を持つプラグインを複数有効化すると、管理画面にログインできなくなる事故が発生します。「ログイン防御は1本」を原則とし、役割が明確に異なる場合（例：ログイン防御＋外部監視）に限り、機能の重複がないことを確認したうえで併用してください。
- Q無料プラグインだけで十分ですか？
- A
会員情報や決済情報を扱わず、更新・バックアップの運用体制があるサイトであれば、無料プラグインでも一定の水準は確保できます。一方、個人情報を保持するサイトや、停止が事業に直結するサイトでは、有料版または保守サービスの導入を推奨します。
- Qセキュリティプラグインを無効化するとどうなりますか？
- A
設定していた防御機能が停止します。特にログインURLを変更していた場合、無効化によって通常の
wp-login.phpに戻ります。この仕様を利用して、ロックアウト時にはFTPでプラグインフォルダ名を変更して強制無効化し、復旧することができます。
- Qマルウェアに感染した場合、駆除できるプラグインはありますか？
- A
MalCareやWordfence Premiumはマルウェアの検知・駆除機能を備えています。ただし、感染後の対応はプラグインだけで完結しないケースがほとんどです。侵入経路の特定、バックドアの除去、パスワード・認証キーの全面変更、Google Search Consoleでのセキュリティ問題の解除申請まで必要になるため、専門業者への相談を推奨します。
- Qセキュリティプラグインは本当に必要ですか？
- A
サーバー側WAFと適切な更新運用があれば、プラグインなしでも一定の防御は可能です。ただし、ブルートフォース攻撃（総当たりログイン）への対策はプラグインが最も手軽で効果的です。WordPressはログインURLが既定で公開されているため、最低限ログイン防御だけは導入することを推奨します。
まとめ｜サイト規模別の推奨構成
WordPressセキュリティプラグインは、「高機能なものを選ぶ」のではなく「自社の規模・体制に合ったものを1本選び、正しく設定し、更新し続ける」ことが本質です。
規模別の推奨構成を整理します。
| サイト規模・種別 | 推奨プラグイン | 併用すべき対策 |
|---|---|---|
| 個人ブログ・小規模サイト | SiteGuard WP Plugin または CloudSecure WP Security | サーバー側WAF、自動更新 |
| 中規模コーポレートサイト | CloudSecure WP Security（2段階認証あり） | サーバー側WAF、ステージング検証、外部バックアップ |
| 大規模・多言語サイト | Wordfence Premium | クラウドWAF、脆弱性情報の継続監視 |
| EC・会員制サイト | MalCare または Wordfence Premium | クラウドWAF、世代バックアップ、復元テスト |
そして繰り返しになりますが、プラグインの導入は出発点であって、ゴールではありません。更新運用、バックアップと復元体制、脆弱性情報の監視——この3つが回って初めて、セキュリティ対策は機能します。
自社での対応が難しい場合は、WordPress保守専門チームを持つ当社が継続監視と定期診断を代行します。ぜひ、WPセンターに一度お問い合わせください。
WPセンター安心サポート
WPセンターは初期費用0円で始められます。
