最終更新日: 2026-05-11
問い合わせフォームに迷惑送信が増えると、まず「CAPTCHAを入れよう」と考えます。
候補は、Google reCAPTCHA、Cloudflare Turnstile、hCaptcha、ハニーポット。WordPressならプラグインも多く、独自フォームなら実装方法もいろいろあります。
ただ、ここで混乱しやすいんです。
CAPTCHAは、主にBotっぽい送信を減らすための入口対策です。人間がブラウザで開いて営業文を貼り付ける送信までは、基本的に止められません。だから、選ぶべきものは「どれが最強か」ではなく、「本物の問い合わせを落とさず、Botを減らし、残った回答をどう扱うか」で決まります。
この記事では、reCAPTCHA v3、Cloudflare Turnstile、hCaptcha、ハニーポットの違いと、問い合わせフォームでの選び方を整理します。
Contact Form 7を使っている場合は、実装寄りの話をContact Form 7の迷惑メール対策にまとめています。Googleフォーム側の標準設定は、Googleフォームのスパム対策を見てください。
先に結論
迷ったら、この順番で考えます。
| 状況 | まず見る対策 |
|---|---|
| 新しく問い合わせフォームを作る | TurnstileまたはreCAPTCHA v3 |
| Google系の運用に統一したい | reCAPTCHA v3 |
| Cloudflareを使っている、Google依存を減らしたい | Cloudflare Turnstile |
| reCAPTCHAから移行したい、hCaptcha運用に寄せたい | hCaptcha |
| 実装コストを低くBotだけ少し減らしたい | ハニーポット |
| 営業メールが多い | CAPTCHAだけでなく届いた後の分類 |
どれを選んでも、サーバー側の検証は必要です。
ブラウザにウィジェットを置くだけでは不十分です。フォーム送信時に発行されたトークンをサーバー側で検証し、失敗した送信を処理しない設計にする必要があります。
もう1つ大事なのは、CAPTCHAを強くしすぎないことです。
問い合わせフォームの目的は、怪しい送信をゼロにすることではありません。本物の問い合わせを受け取ることです。
CAPTCHAが止めるもの、止めないもの
CAPTCHAやBot対策を入れる前に、問題を分けます。
| 問題 | CAPTCHAで減らせるか | 別に必要な対策 |
|---|---|---|
| 自動送信Bot | 減らせます | サーバー側検証、レート制限 |
| 低品質な連投 | ある程度減らせます | IP/時間/重複の監視 |
| 人間が送る営業メール | ほぼ止まりません | 営業お断り文言、回答分類 |
| 要確認の問い合わせ | 止めるべきではありません | ステータス管理、レビュー |
| 通知メールが迷惑メールに入る | 別問題です | メール認証、送信設定 |
ここを混ぜると、判断を間違えます。
たとえば、reCAPTCHAを入れたのに営業メールが減らない場合、reCAPTCHAが失敗しているとは限りません。残っているのがBotではなく、人間が送る営業文かもしれないからです。
入口対策は必要です。
ただし、問い合わせ運用では「入口で減らす」と「届いた後に分ける」を分けて設計したほうが安定します。
Cloudflare Turnstile
Cloudflare Turnstileは、問い合わせフォームのBot対策として扱いやすい選択肢です。
Cloudflare公式ドキュメントでは、Turnstileはブラウザ側のウィジェットでトークンを生成し、サーバー側でそのトークンをCloudflareに検証してもらう二段構えとして説明されています。Cloudflareのプロキシ配下でないサイトにも埋め込めます。
向いているケースです。
GoogleアカウントやGoogle運用に依存したくない
ユーザー体験をできるだけ静かにしたい
Cloudflareをすでに使っている
新規フォームの標準Bot対策を決めたい
注意点は、サーバー側検証を省かないことです。
フォームにTurnstileウィジェットを表示しても、送信処理側でトークンを検証しなければ、実質的には飾りになってしまいます。Cloudflare側も、Siteverify APIでトークンを確認する流れを前提にしています。
FORMLOVAでは、公開フォームのBot対策としてCloudflare Turnstileとレート制限を組み合わせる設計にしています。さらに、届いた後の回答を分類して、営業メールや要確認回答を分けられるようにしています。
Google reCAPTCHA v3
reCAPTCHA v3は、GoogleのBot対策です。
Google公式ドキュメントでは、reCAPTCHA v3はユーザーの操作を中断せずにスコアを返す仕組みとして説明されています。フォーム送信、ログイン、購入などのアクションごとに実行し、サーバー側でトークンとアクション名を検証します。
向いているケースです。
社内のセキュリティ運用がGoogle中心
すでにreCAPTCHAを使っているサイトがある
スコアを見ながら段階的に運用したい
Googleの管理画面で分析したい
reCAPTCHA v3で大事なのは、スコアをすぐ強いブロックに使わないことです。
Google公式ドキュメントでも、サイトごとにトラフィックを見ながらしきい値を調整する考え方が示されています。導入直後のスコアだけで厳しく弾くと、本物の問い合わせを落とす可能性があります。
最初は、次のような運用が現実的です。
低スコアを即ブロックせず、要確認に回す
明らかなBotだけ拒否する
問い合わせ数と誤判定を見てしきい値を調整する
問い合わせフォームでは、1件の本物の相談を落とすほうが、1件の営業メールを受け取るより痛いことがあります。
hCaptcha
hCaptchaも問い合わせフォームのBot対策として使われます。
hCaptcha公式ドキュメントでは、reCAPTCHAからの移行時に既存コードを少ない変更で使えることや、Invisible hCaptchaでは通常は背景で処理し、必要な場合だけチャレンジを表示することが説明されています。
向いているケースです。
reCAPTCHAから移行したい
hCaptcha対応の既存フォームやCMSを使っている
明示的なチェックボックス型の運用にしたい
Enterprise側のリスクスコアなども含めて検討したい
hCaptchaでも、サーバー側検証は必要です。
ブラウザ側でチャレンジに成功すると、フォームデータにトークンが入ります。そのトークンをサーバーから検証エンドポイントに送り、正しいトークンか確認します。
つまり、Turnstile、reCAPTCHA、hCaptchaのどれを選んでも、実装の中心は同じです。
1. ブラウザ側でトークンを発行する
2. フォーム送信と一緒にサーバーへ送る
3. サーバー側で公式APIに検証する
4. 失敗時は送信処理を止める、または要確認にする
ハニーポット
ハニーポットは、人間には見えないダミー入力欄をフォームに置く方法です。
単純なBotは、見える/見えないに関係なく全フィールドへ値を入れることがあります。そこで、隠しフィールドに値が入っていたらBotとして扱います。
ハニーポットの良いところは、ユーザー体験をほぼ邪魔しないことです。
ただし、限界もあります。
人間が送る営業メールには効かない
フォーム構造を読むBotには回避される
CSSやアクセシビリティの作りが雑だと本物のユーザーに影響する
だから、ハニーポットは単体の主役ではなく、軽い補助対策として使うのが現実的です。
選び方の実務基準
実務では、次の順番で決めると迷いにくいです。
1. まずフォームの目的を決める
2. 公開範囲と回答者の属性を決める
3. Bot対策を1つ選ぶ
4. サーバー側検証とレート制限を入れる
5. 低リスクな送信は通す
6. 怪しい送信は要確認に回す
7. 営業メールは届いた後で分類する
公開問い合わせフォームなら、最初から厳しすぎる制限を入れないほうがよいです。
社内申請や会員向けフォームなら、ログイン必須、1人1回、強めの検証も使いやすいです。一般公開の問い合わせフォームなら、静かなBot対策と最低限の入力検証から始めます。
Google Search Centralのユーザー生成スパム対策でも、フォーム完了時間、同じIP範囲からのリクエスト数、ユーザーエージェント、フォーム送信値などを見てスパムパターンを把握する考え方が示されています。
つまり、CAPTCHAだけを見ないことです。
送信の速さ、回数、内容、送信後の扱いまで合わせて見る必要があります。
やらないほうがよいこと
フォームスパムが増えると、つい防御を積みすぎたくなります。
でも、次のような実装は避けたほうがよいです。
CAPTCHAを複数重ねる
スコアが少し低いだけで即ブロックする
失敗理由が分からないエラー文にする
問い合わせ本文を長文必須にする
営業メール対策の警告文を大きく出しすぎる
本物の問い合わせをする人にとって、フォームは最初の接点です。
Bot対策の都合で、送信者に不信感を与えすぎないようにします。エラー文を出す場合は、フォームのエラーメッセージ例のように、直し方が分かる文にしてください。
届いた後の分類まで考える
最後に、ここが一番大事です。
CAPTCHAは入口対策です。
入口対策を入れても、人間が書いた営業メール、判断が必要な問い合わせ、重複、低品質な回答は残ります。
だから、問い合わせフォームの運用では、次のような後処理が必要になります。
営業メール: 返信対象から外す
要確認: 人間が見る
本物の問い合わせ: 優先して対応する
重複/テスト: 分析から除外する
FORMLOVAでは、フォーム送信後の回答を分類し、ステータス管理や分析除外につなげる運用を前提にしています。Bot対策で入口を整えたうえで、届いた後のノイズを分ける。ここまでをセットで見ると、問い合わせフォームの運用はかなり安定します。
営業メール全般の対策は、問い合わせフォームの営業メール対策も参考になります。
まとめ
問い合わせフォームのCAPTCHA選びは、reCAPTCHA、Turnstile、hCaptchaのどれが絶対に強いかを決める話ではありません。
大事なのは、フォームの目的と運用に合わせることです。
Google運用に寄せるならreCAPTCHA v3。静かな新規Bot対策ならTurnstile。hCaptcha運用や移行方針があるならhCaptcha。軽い補助ならハニーポット。
そして、どれを選んでもサーバー側検証は省かないでください。
ただし、CAPTCHAだけで営業メールは消えません。入口でBotを減らし、届いた後に回答を分類する。この二段構えが、問い合わせフォームでは一番現実的です。
Disclosure and Verification
- Verified on: 2026-05-11
- Main official sources checked:
- FORMLOVA仕様確認: 公開フォームのTurnstile/レート制限に関するユーザー向け説明、回答分類、ステータス管理、問い合わせフォーム運用記事群との内部リンク整合を確認しました。
- Note: This article is an operational guide, not legal, security, or compliance advice for a specific site. Review your own form stack, privacy requirements, accessibility needs, and risk tolerance before changing production forms.
