問い合わせフォームにBot対策を導入する

このガイドの対象

企業サイトの問い合わせフォームを管理する担当者と、フォームの送信処理を開発・運用する担当者。Cloudflare Turnstileを使い、正規の問い合わせを受け付けながら、自動送信や連続送信を抑えるための構成と確認手順を整理します。

画面に認証部品を表示するだけでは、送信先のAPIを直接呼び出すリクエストを防げません。入力画面と受付サーバーの両方に対策を設け、通常の問い合わせがメール受信まで到達することを確認します。

対応の流れ

詳しい手順

1. 対象フォームと送信経路を確認する

問い合わせ、無料相談、採用応募など、対象となるフォームを一覧にします。各画面がどのAPIへ送信し、どの処理が会社向け通知と送信者向け自動返信を送るかを確認してください。同じ受付APIを使う画面と、別の受付処理を使う画面を分けると、対策の漏れを把握しやすくなります。

• 入力画面、確認画面、送信API、メール送信処理の接続を記録する。
• 現在の入力チェック、非表示の入力欄、送信回数制限を確認する。
• 正常時の受付結果と、通知・自動返信の受信先を確認する。
• 変更前の設定とプログラムを保存し、不具合時の復旧方法を決める。

2. Turnstileを画面に設置する

対象サイトのホスト名を登録し、サイトキーを使ってフォームにTurnstileを組み込みます。シークレットキーはサーバー側で管理し、ブラウザーへ配信するコードや公開リポジトリに含めないでください。

安全確認が成功したときに得られるトークンを、問い合わせ内容とともに受付APIへ送ります。トークンの有効期間は5分で、検証に使えるのは1回です。確認画面で長時間待った場合や再送信する場合は、期限切れ・使用済みのトークンを再利用しないようにします。Cloudflare公式の検証仕様

安全確認が終わるまで送信ボタンを無効にすることは操作の補助になります。ただし、ボタンの制御だけを受付の許可条件にはしません。エラー時は入力内容を残し、再確認や再送信の方法を利用者に案内します。

3. メール送信前にサーバー側で検証する

受付APIは、受け取ったトークンをシークレットキーとともにSiteverify APIへ送り、結果を確認します。検証に成功し、想定したホスト名や、設定している場合は処理を識別するactionが一致してから、メール送信処理へ進めます。

トークンがない、不正である、期限が切れている、再利用されている場合は、メール送信を実行しません。検証先への通信が失敗した場合も、成功とみなさず、再試行できるエラーとして扱います。Cloudflare公式のサーバー側検証

入力項目の形式・文字数や、受付対象のフォーム種別もサーバー側で検証します。Turnstileの成功は、入力内容が適切であることや送信者の本人確認が済んだことを意味しません。

4. 連続・重複送信への対策を組み合わせる

Bot判定だけに依存せず、受付APIにも複数の制御を設けます。

• 連続送信の制限：一定時間内の受付回数を管理し、過剰な送信を抑えます。
• 重複送信の制限：送信ボタンの連打や同時リクエストで、同じ内容のメールが繰り返し送られないようにします。
• ハニーポット：通常の利用者が入力しない欄を用意し、自動入力を疑う補助情報にします。ブラウザーの自動入力や支援技術による誤判定も試験します。

IPアドレスだけで厳しく制限すると、社内ネットワークなどで同じIPを共有する正規の利用者まで影響を受ける場合があります。実際の利用状況に合わせて条件を決めてください。複数のサーバーで受付を処理する構成では、回数や重複の判定情報を共有できる設計が必要です。

問い合わせ本文やメールアドレスを、調査用ログへ無制限に保存しないようにします。受付識別子、判定結果、エラー分類、時刻など、調査に必要な情報を中心に記録します。

5. 拒否する試験と受け付ける試験を分ける

まず検証環境で、正しい入力だけでなく、トークン未送信、不正トークン、期限切れ、再利用、検証先への通信失敗、連続・同時送信を試します。Turnstileには検証用のキーがあり、成功・失敗を再現する試験に利用できます。本番用のキーと混在させないでください。Cloudflare公式のテスト方法

次に、送信先と試験日時を担当者間で合わせ、本番フォームからテストと分かる問い合わせを送ります。画面の受付完了だけでなく、会社向け通知と送信者向け自動返信を受信箱で確認し、内容と時刻を照合します。スマートフォンでも、安全確認、確認画面への遷移、送信後の表示を確認してください。

完了の確認

• 不正な入力や安全確認に失敗したリクエストから、メールが送られない。
• 通常の問い合わせが受け付けられ、会社向け通知と自動返信を受信できる。
• 連続・重複送信が設計した条件で制限される。
• エラー時に入力内容が保持され、利用者が再試行できる。
• 対象のフォームごとに、設定反映、画面操作、実送信の確認範囲を記録している。

XEROTTAでは、2026年10月2日に通常の問い合わせフォームから1件の実送信を行い、受付完了、会社向け通知、送信者向け自動返信の受信を確認しました。この試験結果は当該フォーム1件についてのもので、すべての窓口の実配送や、あらゆるBotを防げることを証明するものではありません。

うまく進まない場合

安全確認が表示されない場合は、登録ホスト名、サイトキー、スクリプトの読み込み、ブラウザーの拡張機能や通信制限を確認します。

安全確認を通過しても受付に失敗する場合は、トークンの送信漏れ、期限切れ、再利用、サーバーのシークレットキー、hostnameやactionの照合結果を順に確認します。原因を調べるために検証を無効化するのではなく、検証環境で失敗条件を再現します。

受付完了なのにメールが届かない場合は、Bot判定とは別に、メール送信処理の結果、送信サービスの配送記録、受信側の迷惑メール・検疫を確認します。APIの成功応答と、受信箱への到着を分けて記録してください。

参考情報

• Cloudflare：Turnstileのサーバー側検証
• Cloudflare：Turnstile実装のテスト

設定値や受付回数の条件は、利用するフォームと運用環境に合わせて決めます。導入後も正常な問い合わせへの影響と拒否状況を確認し、必要に応じて調整してください。