スパム対策 | YOSHIO.dev

LPやサービスページの問い合わせフォームを公開すると、英語の営業文、同じ内容の連続送信、意味のない文字列、怪しいURLを含む投稿が届くことがあります。

受信箱で1件ずつ削除するだけでは、担当者の確認時間が増え、本物の問い合わせがスパムに埋もれます。一方で、対策を強くしすぎると、入力途中の見込み客やスマートフォン利用者まで送信できなくなるかもしれません。

大切なのは「スパムをゼロにする」ことだけを目標にしないことです。

正規の相談を通しながら、明らかな自動送信を入口で止め、判断が難しいものは隔離し、担当者へ届く通知を減らす設計が必要です。

この記事では、小規模事業者や少人数チーム向けに、問い合わせフォームのスパム対策を5段階で整理します。

結論：入口・判定・通知を分けて対策する

問い合わせフォームのスパム対策は、次の5段階で考えると整理しやすくなります。

フォームの入力項目と受付条件を見直す
CAPTCHAなどで自動送信を判定する
サーバー側で検証し、連続送信を制限する
「通す・保留・拒否」に分ける
スパム件数と正規送信の失敗を計測する

CAPTCHAはこのうち2番目の部品です。画面にウィジェットを表示しただけで、フォーム処理全体が安全になるわけではありません。

たとえばCloudflare Turnstileの公式資料では、ブラウザで発行したトークンをサーバー側からSiteverify APIへ送り、検証する手順が必須と説明されています。攻撃側は画面を経由せず、送信先へ直接リクエストする可能性があるためです。

まずは現在のフォームで、どの段階まで実装されているかを確認します。

最初に「何がスパムか」を記録する

対策を入れる前に、直近2〜4週間ほどの迷惑送信を分類します。

種類	例	最初に検討する対策
同じ内容の連続送信	数秒おきに同文が届く	送信頻度制限、重複判定
海外営業・自動営業	英語の営業文、SEO勧誘	CAPTCHA、内容判定、隔離
URL大量記載	本文に複数の外部リンク	URL数による保留
意味のない文字列	ランダム文字、空欄に近い内容	必須項目、最低文字数、検証
フォームを経由しない送信	画面上の対策を無視したPOST	サーバー側トークン検証
同一メール・本文の再送	何度も同じ相談が届く	受付ID、重複確認

この分類がないまま対策すると、本当に困っている原因へ届きません。

たとえば連続送信が主因なのに、入力項目を増やしても担当者の負担は減りにくいでしょう。URLを1件含む正規相談が多い業種で、URL入りをすべて拒否すると機会損失につながります。

「何件来たか」「どの型が多いか」「本物を誤判定したか」を記録し、対策後と比較できる状態にします。

1. フォームの入力項目と受付条件を見直す

スパム対策の前に、フォーム自体を必要最小限にします。

入力項目が多いほど安全になるわけではありません。正規の見込み客には負担が増え、自動送信側には一定の形式で埋める欄が増えるだけの場合があります。

最初の問い合わせなら、次のような項目で足りることがあります。

名前または会社名
返信先メールアドレス
相談の種類
相談内容
個人情報の取り扱いへの同意

電話番号、住所、予算、希望納期などは、初回受付で本当に必要かを確認します。

同時に、受付条件も決めます。

メールアドレスの形式が正しい
必須項目が埋まっている
本文が短すぎない
本文の最大文字数を超えていない
許可していないファイル形式が添付されていない
同意チェックがある

ここでの目的は、正規ユーザーを試すことではなく、明らかに壊れた入力を早い段階で止めることです。

2. CAPTCHAは「見せ方」と「失敗時」を決める

CAPTCHAには、チェックボックスを押す方式、画像を選ぶ方式、画面上の操作を増やさずリスクを判定する方式などがあります。

Cloudflare TurnstileにはManaged、Non-interactive、Invisibleのモードがあり、Google reCAPTCHA v3はユーザー操作を中断せずスコアを返す方式です。どちらが適切かは、フォーム構成、利用者、既存システム、プライバシー方針、運用できる範囲で判断します。

確認したいのは、導入できたかどうかだけではありません。

スマートフォンで送信できるか
JavaScriptの読み込みが遅いときにどう見えるか
判定に失敗したとき、やり直し方が分かるか
キーボード操作や支援技術で利用できるか
海外や社内ネットワークから極端に失敗しないか
同意文やプライバシーポリシーと矛盾しないか

失敗時に「エラーが発生しました」だけを表示すると、正規ユーザーは原因も直し方も分かりません。

「認証を更新して、もう一度送信してください」「解決しない場合はこちらのメールアドレスへ」のように、次の行動を示します。

3. サーバー側で検証し、連続送信を制限する

フォーム画面にCAPTCHAを表示しても、受信処理で結果を確認していなければ、送信先へ直接データを送られる可能性があります。

サーバー側では、少なくとも次を確認します。

CAPTCHAトークンが有効か
想定したフォーム・ホストからの送信か
トークンが期限切れ・再利用ではないか
同じ送信元から短時間に繰り返していないか
同じメールアドレス・同じ本文が連続していないか
必須項目や文字数を再検証したか

入力画面のチェックは使いやすさのため、サーバー側のチェックは受付を守るため、と役割を分けます。

連続送信制限は、たとえば「短時間に一定回数を超えたら待ってもらう」という仕組みです。ただし、会社や施設の共通ネットワークでは、複数人が同じIPアドレスに見える場合があります。

IPアドレスだけで永久に拒否せず、時間、メールアドレス、本文の類似、CAPTCHAの結果などを組み合わせます。

4. 「通す・保留・拒否」の3段階に分ける

すべてを通すか、すべてを拒否するかの2択では、判定が難しい問い合わせを扱えません。

小さく始めるなら、次の3段階に分けます。

通す

CAPTCHA検証に成功した
送信頻度に問題がない
必須項目が正常
本文に明らかな危険パターンがない

通常の問い合わせとして保存し、担当者へ通知します。

保留する

URLが多い
短時間に似た本文が届いた
リスク判定が境界付近
営業文に見えるが、正規相談の可能性もある

通常の受信箱とは別の「要確認」へ入れます。すぐ削除せず、一定期間は確認できるようにします。

拒否する

サーバー側のトークン検証に失敗した
明らかな大量連続送信
禁止した形式やサイズを大幅に超える
同じトークンや受付情報の不正な再利用

拒否した理由を内部ログへ残します。ただし、攻撃側へ判定条件を細かく教える必要はありません。

この3段階にすると、対策の初期は保留を広めにし、実データを見ながら拒否条件を調整できます。

5. 通知を減らし、正規送信の失敗も計測する

フォーム側で止めきれないスパムがあっても、担当者へ毎回通知しなければ、業務負担を減らせます。

通知設計では次を分けます。

通常: 担当者へ即時通知
要確認: まとめて通知、または専用一覧で確認
拒否: 原則通知せず、件数だけ記録
システム異常: 管理者へ別経路で通知

見るべき数字は、スパム件数だけではありません。

指標	見る理由
受信総数	問い合わせ量全体を把握する
通常・保留・拒否の件数	判定の偏りを見る
同一内容の連続数	自動送信の増減を見る
CAPTCHA失敗率	設定不良や利用者のつまずきを探す
フォーム表示から送信完了まで	正規ユーザーの離脱を確認する
保留から正規へ戻した件数	誤判定を確認する
通知件数	担当者の負担が減ったかを見る

対策後にスパムが減っても、正規問い合わせまで大きく減ったなら成功とは言い切れません。

問い合わせ件数には季節や広告出稿などの影響もあるため、導入前後だけで断定せず、送信テスト、失敗ログ、保留確認を組み合わせます。

ハニーポットは補助策として使う

ハニーポットは、人には見せない入力欄を用意し、自動入力された場合に怪しい送信として扱う方法です。

簡単に追加できることがありますが、単独では十分ではありません。

高度なボットは非表示欄を避けることがある
自動入力機能や支援技術との相性を確認する必要がある
CSSで隠しただけの欄は実装を見れば分かる
誤判定時の保留・確認方法が必要

ハニーポットだけで完全に防ぐのではなく、CAPTCHA、サーバー検証、頻度制限と組み合わせる補助策として考えます。

WordPressフォームで確認したいこと

WordPressのフォームプラグインを使っている場合も、プラグインを有効化しただけで終わらせません。

フォームプラグインとWordPress本体が更新されているか
CAPTCHA連携が現在も正常か
秘密鍵を本文や公開コードへ書いていないか
スパム判定された送信をどこで確認できるか
メール通知に失敗しても管理画面に受付データが残るか
本番ドメイン以外で鍵が使われていないか
バックアップと復旧方法があるか

プラグイン名や画面は更新で変わるため、実装時は利用中の製品の公式資料と現在の設定を確認します。

導入は3段階で進める

段階1：記録と軽い対策

スパムの種類と件数を記録する
必須項目、文字数、メール形式を見直す
同じ内容の連続送信をまとめる
拒否ではなく保留を中心にする

段階2：人間判定とサーバー検証

CAPTCHAまたはリスク判定を導入する
サーバー側でトークンを検証する
失敗時の説明と代替連絡先を用意する
スマートフォンと実端末で送信テストをする

段階3：頻度制御と運用改善

短時間の連続送信を制限する
通常・保留・拒否の振り分けを作る
通知先と通知頻度を分ける
誤判定と送信失敗を定期的に確認する

一度に強い遮断を入れるより、実際の送信を見ながら段階的に調整する方が、正規問い合わせの取りこぼしを見つけやすくなります。

制作会社・開発者へ相談するときのメモ

問い合わせフォームのスパム対策を相談するときは、次をまとめると話が早くなります。

対象ページとフォームURL
利用中のCMS・フォームプラグイン
1週間または1か月の受信数
スパムの件数と主なパターン
正規問い合わせの件数
現在のCAPTCHA・メール・保存設定
通常、保留、拒否を確認する担当者
送信できなかった場合の代替連絡先
変更後に確認したい指標

YOSHIO.devでは、LP制作、既存フォームの見直し、通知の振り分け、小型ツールによる受付管理など、現在の運用に合わせた範囲から相談できます。

まとめ

問い合わせフォームのスパム対策は、CAPTCHAを追加するだけでは完了しません。

入力項目と受付条件を見直す
CAPTCHAなどで自動送信を判定する
サーバー側で検証する
連続送信を制限する
通す・保留・拒否に分ける
担当者への通知を整理する
スパム減少と正規送信の失敗を両方見る

この順番で整理すると、迷惑送信を減らしながら、本物の相談を受け取れるフォームへ近づけられます。

まずは直近のスパムを3〜5種類に分け、現在どの段階で止められていないかを確認してみてください。

FAQ

問い合わせフォームのスパム対策はCAPTCHAだけで十分ですか？

CAPTCHAは有効な部品ですが、それだけで十分とは限りません。画面を経由しない送信に備えたサーバー側検証、短時間の連続送信制限、怪しい送信の隔離、通知の整理、誤判定の確認を組み合わせます。

CAPTCHAを入れると問い合わせが減りませんか？

追加操作や読み込み失敗があると、正規ユーザーの負担になる可能性があります。操作を増やさない方式も含めて比較し、スマートフォンでの送信、失敗時の再試行、導入前後の完了率を確認します。

Cloudflare TurnstileとreCAPTCHAはどちらを選ぶべきですか？

一律には決められません。既存のフォーム、サーバー側で実装できる範囲、プライバシー方針、利用者、運用画面、障害時の対応を比較します。どちらも製品名だけで選ばず、検証と監視まで含めて判断します。

スパムらしい送信は自動で削除してもよいですか？

導入初期は、判断が難しい送信をすぐ削除せず「保留」へ入れる方が安全です。一定期間確認し、正規問い合わせの誤判定が少ないと分かってから拒否条件を調整します。

小規模なLPでもサーバー側の検証は必要ですか？

フォームの規模にかかわらず、送信先へ直接リクエストされる可能性があります。利用するCAPTCHAやフォーム製品の公式手順に従い、サーバー側で検証結果を確認してから受付処理を進めます。

スパムを減らし、本物の問い合わせを見逃さないフォームへ

「迷惑送信が多くて受信箱を確認しきれない」「CAPTCHAを入れたが効果が分からない」「正規の相談まで止めるのが不安」という場合は、現在のフォーム、通知、受付後の流れを一緒に整理できます。

YOSHIO.devでは、LP制作、既存フォームの改善、通知振り分け、小型受付ツールまで、必要な範囲に絞ってご相談いただけます。

問い合わせフォームのスパム対策を相談する

参考にした一次情報

注: 各製品の機能・設定・料金・データ取り扱いは変更される可能性があります。実装時は利用中の環境と最新の公式資料を確認してください。

タグ: スパム対策

問い合わせフォームのスパムを減らす｜CAPTCHAだけに頼らない5段階対策