WordPress を公開していると、コメント欄はスパムの入口になります。スパムコメント対策プラグインを入れれば終わりに見えますが、実際には正常なコメントまで破棄されることがあります。
以前、このブログでは Throws SPAM Away を使っていました。しかし後から確認すると、通常の日本語コメントまで破棄されていることが分かりました。いつから起きていたのかは分かりませんが、長期間そうだった可能性を考えると、単にスパムを減らすだけでは不十分です。
この記事では、WordPress のスパムコメント対策を、プラグイン選定ではなくコメント欄の運用設計として整理します。結論として、技術ブログではコメント欄を開く必要があるのかを最初に判断し、不要であれば閉じるのが最も確実です。
書籍
WordPress 仕事の現場でサッと使える!デザイン教科書 [WordPress 6.x対応版] 改訂第3版
WordPress のサイト構築、テーマ、カスタマイズ、運用項目を確認したい場合の参考書籍です。価格や在庫、WordPress の最新仕様との差分はリンク先や公式ドキュメントで確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
書籍
ModSecurity Handbook, Second Edition
ModSecurity と Web Application Firewall の設定、ログ、ルール、チューニングを確認したい場合の参考書籍です。英語書籍であり、価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連する記事
WordPress 構築、スパム対策プラグイン、REST API、WAF、パーマリンク移行の記事と合わせて、公開 WordPress の運用課題として整理します。
- WordPress Throws SPAM Away スパムコメント対策プラグイン
- Ubuntu 22.04 WordPress – Apache / PHP / MariaDB で CMS を構築する
- WordPress の「返答が正しい JSON レスポンスではありません」を切り分ける
- WordPress 更新後に ModSecurity が偽陽性判定する原因と調整方針
- WordPress のパーマリンクを変更する手順 – 旧 URL を守るリダイレクト設計
スパムコメント対策で起きた問題
元々は、WordPress に大量のスパムコメントが届くため、Throws SPAM Away を導入していました。日本語を含まないコメントを破棄するという発想は、日本語ブログではかなり効果があります。
しかし、後からテストしてみると、通常の日本語コメントも破棄されていました。スパムを減らすことには成功していても、正常なコメントまで消えているなら、コメント欄としては機能していません。
| 状態 | 意味 |
|---|---|
| スパムを通す | 管理負荷が増え、コメント欄が荒れる。 |
| 正常コメントを捨てる | 読者の反応や問い合わせを失う。 |
| すべて承認制にする | 安全だが管理コストが残る。 |
| コメント欄を閉じる | 交流は減るが、スパム入口を閉じられる。 |
まずコメント欄が必要かを決める
スパム対策を考える前に、そもそもコメント欄を開く必要があるのかを決めるべきです。技術ブログの場合、コメント欄で議論するよりも、記事を設計メモや検証記録として残す価値の方が大きい場合があります。
- 読者からの質問をコメントで受けたいのか。
- 記事ごとの議論を残したいのか。
- 問い合わせフォームや SNS で代替できるのか。
- コメントを確認する運用時間を確保できるのか。
- スパム対策プラグインの誤判定を定期的に確認できるのか。
コメント欄を運用する意思がない場合、コメント欄を開けたままスパム対策だけを強化するのは中途半端です。入口を閉じる判断も、立派な運用設計です。
WordPress 側でできる基本対策
コメント欄を残す場合は、まず WordPress の標準設定で守れる範囲を確認します。
- コメントを管理者承認制にする。
- 過去記事のコメントを自動的に閉じる。
- コメント内のリンク数で承認待ちにする。
- ブラックリストまたは禁止語句を設定する。
- ログインユーザーのみコメント可能にする。
- 不要なら新規投稿のコメントをデフォルトで無効にする。
プラグインを入れる前に、標準設定でどこまで閉じられるかを確認します。スパムコメント対策は、多機能なプラグインを入れるほど良いというものではありません。
プラグイン対策の注意点
Akismet、Throws SPAM Away、reCAPTCHA 系プラグインなど、スパムコメント対策の選択肢はいくつもあります。ただし、どれを使っても誤判定や運用負荷は残ります。
| 方式 | 注意点 |
|---|---|
| Akismet | 外部サービス連携や利用条件を確認する必要がある。 |
| Throws SPAM Away | 日本語ブログでは有効だが、正常コメントの破棄を確認する必要がある。 |
| reCAPTCHA | ユーザー体験や外部サービス依存を考える必要がある。 |
| 承認制 | 安全だが、確認し続ける運用が必要。 |
| コメント無効化 | 交流は減るが、スパム入口は閉じられる。 |
特に、スパム対策プラグインは入れた後にテストが必要です。日本語コメント、英数字を含むコメント、URL を含むコメント、短文コメントなど、実際に通したいコメントが処理されるか確認します。
WAF で防ぐものと WordPress で処理するもの
コメントスパムと WAF の役割は分けて考えます。WAF は攻撃的なリクエスト、明らかな不正入力、脆弱性を狙う通信を抑える防御層です。一方、コメントスパムは WordPress の機能を使った迷惑投稿であり、アプリケーション側の運用問題です。
| 層 | 主な役割 |
|---|---|
| WAF | 攻撃パターン、異常なリクエスト、脆弱性狙いの通信を止める。 |
| WordPress 設定 | コメント許可、承認制、リンク数制限、禁止語句を管理する。 |
| スパム対策プラグイン | コメント内容を判定し、スパムを隔離または破棄する。 |
| 運用判断 | コメント欄を開くか閉じるかを決める。 |
WAF でコメントスパムを完全に防ごうとすると、正常なコメントや REST API、管理画面操作まで巻き込む可能性があります。コメント欄の運用は、まず WordPress 側で設計する方が自然です。
WP-CLI でコメント状態を確認する
WP-CLI が使える場合は、コメントの件数や状態を確認できます。スパムや承認待ちが増えているかを見ると、コメント欄を開き続けるべきか判断しやすくなります。
wp comment list --status=spam --format=count
wp comment list --status=hold --format=count
wp comment list --status=approve --format=count
wp comment list --status=spam --fields=comment_ID,comment_author,comment_date,comment_post_ID --format=table不要なスパムコメントを削除する場合は、事前に件数と対象を確認してから実行します。
wp comment delete $(wp comment list --status=spam --format=ids) --force技術ブログならコメント欄を閉じる判断も自然
このブログのように、技術メモ、設計記録、検証手順を蓄積することが主目的であれば、コメント欄を開く価値は必ずしも大きくありません。
コメント欄を閉じても、記事の価値は下がりません。むしろ、スパム対応、誤判定、承認待ち、通知メール、管理画面のノイズを減らせます。問い合わせが必要であれば、別の明確な窓口を用意する方が運用しやすいです。
まとめ
WordPress のスパムコメント対策は、プラグインを入れて終わりではありません。プラグインが正常コメントまで捨てていないかを確認し、コメント欄を開く意味があるのかを判断する必要があります。
コメント欄を残すなら、承認制、標準設定、スパム対策プラグイン、WAF の役割を分けて運用します。不要ならコメント欄を閉じるのが、最も単純で確実な対策です。
公開 WordPress の運用では、入口を増やすほど管理対象が増えます。コメント欄もその 1 つです。開く価値がある入口なのか、閉じるべき入口なのかを先に決めることが重要です。



