WordPressスパム対策比較：Akismet・Antispam Bee・CleanTalk
WordPress標準コメントに無料フィルターを使うならAntispam Bee、サービス型のコメント判定と対応フォーム連携ならAkismet、問い合わせ・登録など複数の入口を管理するならCleanTalkを比較しましょう。まずスパムが入る場所とフォームの製品を確認します。コメント対策を入れただけで、すべての問い合わせや登録画面が保護されるわけではありません。
コメント・問い合わせ・登録を区別します
同じ広告文でも、入ってくる経路で必要な対策は異なります。コメントを閉じたサイトの問い合わせフォームが問題なら、コメント専用フィルターでは解決しません。標準コメント、外部コメントシステム、フォーム・会員・販売プラグインのどれかを確認します。
標準コメントは管理画面の「コメント」、問い合わせはフォームの保存記録や通知メール、登録は「ユーザー」に現れる場合があります。利用する問い合わせフォームの連携機能も調べます。既存のCAPTCHAや判定を記録し、同じ送信を複数ツールが重複して遮断しないようにしましょう。
正規の送信をスパムにする誤検知も判断基準です。遮断数の多さだけでは良い製品といえません。正常な送信が通るか、理由を確認できるか、誤判定した内容を戻せるかも比較します。
保護範囲とサービス費用の比較
| 候補 | 主な範囲 | アカウント・費用 | 重要な条件 |
|---|---|---|---|
| Akismet | 標準コメントと対応フォーム連携 | APIキーと契約。無料Personalは非商用条件 | 広告・アフィリエイト・事業紹介は条件を確認 |
| Antispam Bee | 標準コメント・ピンバック・トラックバック | 無料。別のスパム判定サービス契約は不要 | フォームや登録用ではない。独自コメントとの互換確認 |
| CleanTalk Anti-Spam | 対応コメント・フォーム・登録 | 有料クラウド。試用と継続利用を区別 | 連携対象、ログと追加商品の範囲を確認 |
Akismetは個人運営というだけで無料Personalの条件を満たすわけではありません。公式の無料・有料選択ガイドはAdSenseなどの広告コード、アフィリエイトリンク、事業・サービスの宣伝を商用活動の例に挙げています。収益化したブログでは先に確認してください。ホスティングやJetpack契約に含まれる場合は、重複購入前に範囲を調べます。
各ツールで確認すること
Akismet：対応するフォームを実際に接続する
Akismetはサービスで判定し、WordPressのコメント画面で分類を確認します。APIキーは利用契約に対応します。公式接続ガイドではWordPress 7.0以降は「設定 → Connectors」、旧版は「設定 → Akismet Anti-spam」やJetpackの関連メニューです。導入した版の画面に合わせて確認します。
フォームには製品別の連携が必要です。有効化だけで済むと考えず、フィールド対応や保護設定を確認してください。現行プランはサイト数に加えて判定呼び出し量が関係する場合もあります。無料インストールと無料サービス利用は別です。
Antispam Bee：標準コメント向けの無料候補
Antispam Beeは標準コメント・ピンバック・トラックバックが中心です。公式FAQはフォームプラグインや登録スパムを保護対象にしておらず、Jetpack・wpDiscuz・Disqusなどのコメントシステムも互換確認が必要です。標準コメントだけなら役割が明確な候補です。
設定 → Antispam Beeを確認します。国・言語制限や即時削除を初めからすべて有効にせず、別言語の読者や短いコメントへの影響を考えます。公式設定説明には一部の任意機能の外部照会・データ処理もあります。すべての設定で外部通信がないと断定しないほうが正確です。
CleanTalk：複数の入口とログを確認する
CleanTalkはアカウントのAccess Keyでクラウドに接続し、対応するコメント・フォーム・登録を調べます。複数経路が問題の場合の候補ですが、利用するフォーム・ショップ・会員製品が対応するかを先に確認します。Anti-Spamと別売りのセキュリティサービスも区別してください。
公式FAQは有料サービス、試用、接続状態とキーを説明しています。試用後もそのまま保護されるとは限りません。ログ保存や追加機能の範囲と、判定・記録に使う送信内容やIP情報がサイトの方針に合うかも確認します。
制限を強める前に正常な送信を試します
変更前の設定と復旧手段を準備し、コメント・フォーム・メールの正常な状態を記録します。導入方法はプラグインの入手方法を参照してください。最初は結果を検証できる設定にし、即時削除のように元へ戻せない処理は慎重に選びます。
- 入口と連携を確認します。実際のコメント・問い合わせ・登録画面と担当製品、キーやフォーム別設定が有効かを調べます。
- ログアウトして正規の試験内容を送ります。管理者は判定を省略される場合があります。プライベートウィンドウとモバイルで、個人情報ではなく試験文と自分の管理するテストアドレスを使います。
- 各保存先を見ます。承認待ち・スパム、フォーム保存、通知メールを別々に確認します。成功表示だけでは記録と通知の両方が届いたとは分かりません。
- 公式のスパム試験を別に行います。CleanTalkは
stop_email@example.comでコメント・登録・フォームを試すよう案内しています。他製品が同じ値を同じように扱うとは限らないため、製品ごとの手順を使います。 - 誤検知の理由と復旧を確認します。正規送信が止まれば該当設定を一つずつ調整し再試験します。終了後の試験投稿やアカウントは運用方針に従って整理します。
試験は自分の管理するサイト、可能なら試験環境で行ってください。「test」とだけ書いた結果でフィルター全体は評価できません。正常送信、公式スパム試験、実際の連携確認を分けて記録します。
正規のコメントや問い合わせが止まった場合
WordPressのコメント → スパムで不足した内容を探し、「スパムではない」に戻せるか確認します。Antispam Beeで言語・国・時間の条件を使っていれば理由を見ます。即時削除済みの内容は一覧から回収できない場合があるため、導入初期は確認可能な運用が重要です。
CleanTalkのAnti-Spam Logでは許可・遮断を見て「Not Spam」で報告できます。ただし許可リストへの登録は、失われた問い合わせの再送や登録アカウントの作成とは違います。内容の回収や必要な再提出は別に確認してください。
問い合わせが減っても、スパムがなくなったと即断しないでください。判定は通っているのに通知がなければWordPressのメール配信を調べます。フォームで止まるならJavaScript、キャッシュ、重複CAPTCHAも確認します。スパム判定は侵害防御やログイン保護の代わりではないため、目的を分けて管理しましょう。
