問い合わせフォームのスパム対策は、安いものから順に積むのが正解です。レートリミット、基本チェック、内容の選別——この 3 つを、この順番で入れれば大半のケースは成立します。複雑な仕組みを最初から入れる必要はありません。
この記事は、中小企業の Web 担当・情シス・問い合わせ担当者に向けて、各段が何を止めて何を止めないのか、実装の勘所はどこにあるのかを整理します。CMS ごとの設定手順ではなく「考え方と順番」の話です。なお、メールアドレス宛に直接届くものは入口も効く手当ても違うため、会社の迷惑メール対策で別に整理しています。
なぜ順番が大事なのか:安くて、本物を巻き込まないものから
結論から言うと、実装コストが低く、本物の問い合わせを落とす危険も低いものから積むのが原則です。
対策で失敗する典型は、いきなり高度な仕組みに手を出すことです。AI 生成文の検知や機械学習モデルは、導入と運用のコストが高いわりに、前段で素直に止まるはずのものまで肩代わりさせられます。順番どおりに積めば後段に届く量が減り、後段の精度も運用コストも安定します。
もう一つの理由がより本質的です。前段ほど「本物を巻き込む危険」が小さい。1 秒で 10 通送ってくる送信を止めても、人間が書いた本物の問い合わせは 1 件も落ちません。一方、内容を読んで弾く判定は、設計を誤ると本物を落とします。危険の小さい順に並べる、と言い換えてもかまいません。
3 段で止まるもの・止まらないもの
3 段のうち最初の 2 つは「機械が送ったか」を見ており、内容を読むのは 3 段目だけです。
| 段 | 対策 | 止まるもの | 止まらないもの | 実装コスト | 本物を落とす危険 |
|---|---|---|---|---|---|
| 1 | レートリミット | 同一送信元からの連投・短時間の大量送信 | 1 日数件に抑えた送信、分散送信 | 低 | ほぼ無し |
| 2 | 基本チェック(必須・形式・ハニーポット・送信タイミング・整合性) | フォームを解析せず投げるスクリプト型ボット | ブラウザを自動操作するボット、人間の手入力 | 低〜中 | 低(設計を誤ると中) |
| 3 | 内容の選別 | 人が書いた営業メール、テンプレート営業文 | 判定が割れるもの(人が最終確認する前提) | 中 | 設計次第で高い |
この「見ているものが違う」という点が、順番の理由でもあります。1〜2 段をいくら強化しても、人が書いて送ってきた営業メールは減りません。
第 1 段:レートリミット——閾値より「何を単位に数えるか」
レートリミットは、閾値の数字そのものより、何を単位にカウントするかで効き方が決まります。
判断の出発点はきわめて単純で構いません。「1 秒で 10 通送る人間はいない」。これだけで、機械による大量送信の多くは止まります。 複雑な確信度モデルは要りません。
数える単位は、たとえば次のように使い分けます。
- IP アドレス単位:基本。ただし企業内 NAT やモバイル回線では複数人が同じ IP に見えます。厳しくしすぎない。
- 同一メールアドレス・同一本文ハッシュ単位:同じ内容の反復に素直に効きます。実データでも、同じ送信元が同一フォームに 10 件以上送っている例が複数ありました。ただし数えるのは「反復」という事実だけにとどめ、「あの会社からの送信はすべて営業」と企業単位で決めつけない。同じ相手でも、次の 1 通が本当の取引の相談ということは起こります。
- サイト全体の合計:参考値としては見てよいものの、これを攻撃判定に使わない。プレスリリースや SNS での拡散、キャンペーンで正常に急増するからです。
閾値は「人間の最速」を基準にします。フォームに入力して送信する動作を人間が繰り返しても、どんなに急いで 1 分に数件が限界です。まずは緩く始め、ログを見てから絞る。最初から厳しくすると、通信が不安定で二重送信してしまった本物のユーザーがエラー画面に当たります。
第 2 段:基本チェック——必須項目とハニーポットは別物
必須項目チェックは「人間の入力ミス」対策、ハニーポットは「機械」対策で、役割がまったく違います。
必須項目やメールアドレス形式のバリデーションは、フォームとして当然の実装ですが、スパムはほとんど止まりません。ボットは全項目を埋めてくるからです。
ハニーポット(人間には見えないダミーの入力欄。CSS で隠し、そこが埋まっていたら機械と判断する)は、HTML を解析せず全欄を埋めるタイプのボットによく効きます。コストがほぼゼロで、本物を落とす危険も小さいのが利点です。ただしスクリーンリーダー利用者が誤って入力しないよう、aria-hidden と autocomplete="off" を付け、ラベルに「入力しないでください」と添える配慮は必要です。ブラウザを自動操作する型のボットには効きません。
送信タイミングも同じ層です。フォーム表示から送信までが 1 秒未満なら、人間の入力としては不自然です。
整合性チェックで見るのは、単一の項目ではなく組み合わせです。
- 会社名が空なのに、法人向けの申込内容が選ばれている
- 選択された用件と、本文の話題が噛み合っていない
- 氏名欄に URL やメールアドレスが入っている
- 電話番号欄の桁数が、選択された国・地域の形式として成立しない
ここで守るべき原則が一つあります。1 つ当てはまったら即ブロック、にしない。 どれも本物の問い合わせで単独に起こり得ます。当てはまった数をスコアとして積み、閾値を超えたものだけを人の目に回すのが安全です。
ボット判定の技術的な中身はフォームのボット対策で、CMS ごとの具体的な設定は WordPress の問い合わせフォームのスパム対策と Contact Form 7 のスパム対策で扱っています。
第 3 段:ここから先は「人が書いた営業メール」
1〜2 段を抜けて残るのは、人が書いた(あるいは人が書いたものと区別できない)営業メールです。ボット・半自動・人が書いた営業という 3 層の分け方は、スパムとは何かで整理しています。
reCAPTCHA v3 は 0.0〜1.0 のスコアを返し、閾値と対応はサイト側が決める設計です(Google 公式ドキュメント)。つまり推定しているのは「機械らしさ」であって、内容が営業かどうかは対象外です。役割が違うだけで、ボット除去としては有効に働きます。コメントスパム対策として生まれた Akismet も同様に守備範囲があり、その得意・不得意はAkismet は問い合わせフォームに効くのかで検証しています。
Hajik が分析した、美容商社(国内最大手・上場)の実フォームデータでも、これは数字に出ました。対象は 3 種類のフォーム・合計 1,894 件・約 20 か月分。いずれも reCAPTCHA v3 を通過した送信で、明らかなボットは事実上ゼロでした。それでいて残った中身はこうです。
| フォームの用途 | 営業とみられる比率 |
|---|---|
| 問い合わせフォーム | 12.9%(ほかに「判定困難」が 32.2%) |
| 汎用フォーム | 56.2% |
| 採用フォーム | 65.8%(中途採用のみでは 73.1%) |
業種・規模・フォームの性格によって比率は大きく変わります。あくまで一社・一時点のサンプルです。それでも言えるのは、1〜2 段を積んでも届く量はゼロにならないということ。ボット対策と営業メール対策は、別の問題です。
この段の判定は、日本語の文脈・業種・定型フレーズを読む作業になります。最優先は、本物を落とさないこと。迷ったらブロックせず、ラベルを付けて人に見せる。 上の 3 フォーム合算でも月平均 100 件程度なので、最終確認を人が担う運用は十分現実的です。
仕分けを日々の運用に落とし込む手順は、問い合わせフォームの営業メール対策(実務ガイド)にまとめています。
最初から作り込まない——3 段で足りる理由
AI 生成文の検知のような難所に、最初から手を出す必要はありません。
理由は 2 つあります。1 つは投資対効果で、上の 3 段で実務上の大半が成立します。もう 1 つは、精緻な自動判定を目指すほど、判定が読めなくなり、本物を落としたときに原因を追えなくなることです。
現実的な目標は、8〜9 割を自動で仕分け、残りを人が確認できる状態に整えることです。Hajik も「99%+ を遮断し、残り約 1% は人が判断する」という前提で設計しています。完全な自動化を目指さない代わりに、取りこぼしたときに人が気づける導線を必ず残す。これが 3 段構成の到達点です。
よくある質問
レートリミットだけでスパムは止まりますか
機械による大量送信の多くは止まります。ただし 1 日数件に抑えて送ってくる相手や、人が手で送ってくる営業には効きません。3 段目が必要になるのはそのためです。
ハニーポットと reCAPTCHA は併用すべきですか
併用して問題ありません。役割が重なる部分はありますが、ハニーポットは実装コストがほぼゼロで、利用者に追加の操作を求めない点が利点です。
実際に「届いていない」と言われました。どこから調べればいいですか
送信されているのか、送信されたが届いていないのかを先に切り分けてください。ブラウザ・サーバー受付・メール送信・受信側の4段で見る手順をフォームから送信できない・届かないときの切り分けにまとめています。スパム対策の設定が原因で本物が黙って捨てられている場合も、この手順で見つかります。
対策を強めると、本物の問い合わせが届かなくなりませんか
そのリスクは実在します。だからこそ、単独の条件で即ブロックせずスコアで積む、迷ったら通してラベルだけ付ける、という設計にします。短文である・英語である・海外からである、といった理由だけで弾くのは危険です。実データでも、本物の問い合わせは「この商品の在庫はありますか」程度の一行が多くを占めていました。
流入が急に増えたら攻撃と考えるべきですか
いいえ。メディア掲載や SNS での拡散で正常に急増します。同じ実データでも、問い合わせフォームの営業比率は平常月で 2〜3 割、12〜1 月には 0% 近くまで落ちる月もありました。量ではなく中身で判断してください。
3 段すべてを自前で実装する必要がありますか
1 段目と 2 段目は多くのフォームツールやプラグインで実現できます。ただし Google フォームのスパム対策で整理したとおり、回答画面に自前のコードを差せないツールでは 2 段目に打てる手が限られます。3 段目の内容判定を自前で持つのは負担が大きいため、外部サービスを使う判断が現実的です。
明日やること
- 自社フォームに レートリミットが入っているかを確認する。無ければ、まず緩い閾値で入れる。単位は IP と本文ハッシュの 2 つから。
- ハニーポットと送信タイミング判定を追加する。実装は数十分、利用者の操作は増えません。
- 直近 1 か月の問い合わせを開き、営業が何件混ざっていたかを数える。3 段目が要るかどうかは、この実数で決めます。
- 数えた結果が月に十数件を超えるなら、内容ベースの選別を検討する。
Hajik は、フォームに届く営業メールを日本語の文脈で選別する B2B SaaS です(運営:GrowGroup株式会社)。導入はサイトに script タグを 1 行、プラグインや DNS の変更は不要。保存されるフォーム内容はブラウザ内で暗号化され、Hajik 側は保管データを復号できません(判定の瞬間だけ内容を AI に渡し、クレジットカード番号・マイナンバー・銀行口座・パスポート番号・健康情報の 5 種はブラウザ内で除去してから送ります)。
まずは自社フォームの現状を 無料診断 で確認できます。実際の判定結果を見たい場合は、14 日間の無料トライアルをご利用ください。