問い合わせフォームのスパム対策を比べる — CAPTCHA・時間判定・レート制限の選び方
問い合わせフォームのスパムは、CAPTCHA をひとつ入れれば終わる問題ではありません。送信をサーバー側で必ず検証したうえで、honeypot（人には見えない隠しフィールド）と時間判定、レート制限を土台にし、それでも残る自動投稿にだけチャレンジ型を足す、という順序が利用者の負担をいちばん増やしません。OWASP のボット管理チートシートも、画像選択や文字判読のような目に見える CAPTCHA は「最後の手段のステップアップ」として扱い、複数の層を組み合わせるよう勧めています。この記事では、代表的な対策を「防げる攻撃」「利用者の負担」「実装・運用コスト」で比較し、公開状況と被害に応じた組み合わせ方を示します。
防げる攻撃が違う：3つの対策の守備範囲
最初に押さえるべきは、各対策が止めているものが別物だという点です。OWASP の自動化脅威の分類では、フォームへの迷惑投稿は OAT-017 Spamming、CAPTCHA の突破そのものは OAT-009 CAPTCHA Defeat として別々に整理されています。
- honeypot・時間判定：HTML を解析してすべての入力欄を埋める、あるいはページ読み込み直後に送信する単純な自動投稿に効きます。逆に、フォームごとに作り込まれたスクリプトには効きません。
- CAPTCHA・スコア判定：ブラウザ環境やネットワークの評判を含む広い自動化の兆候を見ます。ただし解答代行サービスを使われると人手で突破されるため、絶対的な壁にはなりません。
- レート制限：同じ送信元からの連続投稿や大量送信という「量」を抑えます。1件ずつ丁寧に送られるスパムは止まりません。
そしてどれも、人間が自分でフォームを開いて書く営業メールは止められません。被害の中身が「機械的な大量投稿」なのか「人が書いた売り込み」なのかを分けないまま対策を足しても、効果は出ないという判断がここから導けます。
利用者の負担とアクセシビリティ
honeypot と時間判定は、正しく実装すれば利用者の操作をまったく増やしません。OWASP のチートシートは、画面外に飛ばした要素に aria-hidden と tabindex="-1"、autocomplete="off" を付けた honeypot の例を示しています。スクリーンリーダーに読ませない、キーボード移動の対象にしない、ブラウザの自動入力に埋めさせない、という3点を外すと、支援技術の利用者だけが弾かれる誤検知が起きます。
チャレンジ型は負担の幅が大きく、Cloudflare Turnstile や reCAPTCHA v3 のように操作を求めない方式と、チェックボックスや画像選択を求める方式では、離脱の起き方がまったく違います。W3C は「Inaccessibility of CAPTCHA」で、対話型のテストはその性質上、障害のある利用者を排除しうると指摘しています。WCAG 2.1 の達成基準 1.1.1 も、CAPTCHA を使う場合は目的を説明するテキスト代替と、別の感覚モダリティによる代替手段の提供を求めています。画像や音声の判読を求める方式を選ぶなら、この代替手段と、電話やメールなど人が対応する連絡経路の用意までが実装範囲に入る、と考えるのが安全です。
実装コストは「サーバー側検証」をどう作るかで決まる
フロントにスクリプトを貼るだけで終わる対策はありません。Cloudflare のドキュメントは、ウィジェット単体ではフォームは守れないと明記し、Siteverify API での検証を必須としています。トークンは生成から5分間有効で、使い回しは timeout-or-duplicate として拒否されます。検証時には success だけでなく、想定したホスト名と action 名の一致も確認します。Turnstile が返すのは成功・失敗であってリスクスコアではないため、通過後の扱いを自前で分岐させる余地は少なくなります。
reCAPTCHA v3 は 0.0〜1.0 のスコアを返し、公式ドキュメントはしきい値 0.5 を出発点として、まずブロックせずに自社トラフィックのスコア分布を見てから調整することを勧めています。トークンの有効期限は2分と短く、ページ読み込み時ではなく送信操作時に execute を呼ぶ必要があります。入力に時間がかかる長文フォームでは、期限切れ時の再取得処理まで作らないと「送信できない」問い合わせが発生します。なお v3 の従来ドキュメントは非推奨の表示となり、Google Cloud 側のドキュメントへ誘導されています（2026年10月時点）。新規に採用する場合は、将来の移行作業を見込んでおくべきです。
レート制限は外部サービスに依存しない代わりに、キー設計を自分で決める必要があります。OWASP は IP だけでなくセッション、エンドポイント、ASN といった複数のキーで制限し、固定ウィンドウではなくトークンバケットやスライディングウィンドウを使うこと、上限に達したら詳細を含めない 429 を返すことを挙げています。IP 単位はプロキシで回避されるため「床」として捉える、という位置づけも明示されています。
時間判定は、OWASP の自動化脅威ハンドブックが Expediting（工程の早回し）への対策として挙げる「工程完了のタイムスタンプと入力速度を記録し、平均より速い進行を監視する」という考え方に対応します。ここから読み取れる実務上の含意は、数秒未満の送信を即座に拒否するより、まず記録して分布を見るほうが安全だということです。自動入力や再訪問の利用者は想像より速く送信します。
公開状況と被害に応じた組み合わせ方
判断軸は4つです。フォームが検索エンジンから誰でも到達できるか、1件の送信の価値（一般の問い合わせか、見積もり依頼や申込みか）、いま届いているスパムが機械的か人力か、そして第三者スクリプトを読み込んでよいかというプライバシー・同意の制約です。これを踏まえた積み上げ方を推奨します。
- すべてのフォームの土台：サーバー側での必須項目・形式検証、honeypot、送信時刻の記録、IP とセッション単位の緩やかなレート制限、送信ログ。ここまでは外部サービスなしで実装でき、利用者の負担もゼロです。
- 機械的な投稿が残る場合：Turnstile のような操作を求めないチャレンジを追加し、トークンをサーバー側で必ず検証します。チャレンジを通過しても、レート制限は外さないことが重要です。
- 申込みや会員登録など価値の高い送信：スコア型を使い、低スコアを即ブロックせずメール確認や目視確認キューへ回す段階的な対応にします。reCAPTCHA の公式ドキュメント自身が、ブロックより背後での対応を勧めています。
- 人が書く営業メールが主な被害：技術的なボット対策では解決しません。受信側での振り分け、フォーム項目の見直し（用途の選択肢を必須にする）、公開範囲の調整で運用コストを下げる方向に切り替えます。
逆に、OWASP がアンチパターンとして挙げるのは、単一ベンダーの仕組みだけに頼ること、毎回 CAPTCHA を出してコンバージョンを壊すこと、ログを残さないルールを運用すること、最初の兆候で即ハードブロックすることです。プライバシーに配慮したブラウザ設定の利用者はボットに見えやすいため、ブロックより追加のチャレンジを選ぶべきだとも述べられています。
導入前に決めておく5つのこと
- 効果の測り方：導入前1〜2週間のスパム件数、正規の問い合わせ件数、問い合わせからの返信率を記録しておく。比較対象がないと、しきい値を上げるべきか下げるべきか判断できません。
- 外部サービス障害時の挙動：検証 API が応答しないときにフォームを止めるのか、記録を残して通すのか。これは事業判断であり、実装前に決めておく項目です。
- トークンの期限と入力時間：Turnstile は5分、reCAPTCHA は2分。長文や添付のあるフォームでは再取得の導線を必ず用意します。
- プライバシー表記：第三者サービスへデータが渡る以上、プライバシーポリシーへの記載と、必要なら同意取得の設計が要ります。OWASP もボット対策の処理をプライバシー通知に記載するようチェックリストに入れています。
- 代替の連絡手段：チャレンジを解けない利用者が確実に連絡できる電話・メールの窓口を併記します。
まとめ
まずは honeypot と時間記録、サーバー側検証、緩やかなレート制限とログという土台を1つのフォームで整え、2週間ほど件数を見てから、残った自動投稿に対してだけチャレンジ型を足してください。この順序なら、利用者の操作を増やさずに効果を確認できます。既存フォームの実装状況の確認や、チャレンジ導入後の検証処理・再取得まわりの作り込みで手が足りない場合は、お問い合わせからご相談ください。
