問い合わせフォームの営業メールが、reCAPTCHAで止まらない理由と対策 ── 「消す」より「仕分ける」設計へ

2026.10.16#INQBOX #Web開発 #セキュリティ #生成AI

コーポレートサイトの問い合わせフォームを運用していると、届く通知の多くが営業の売り込みで占められる状況は珍しくありません。SEO対策の提案、Web制作の営業、人材紹介、補助金の案内などが日常的に届きます。reCAPTCHAを導入し、フォームの上に「営業目的のご連絡はお断りしています」と明記しても、送信数がほとんど減らないケースは多く見られます。

既存のスパム対策で営業メールが止まらない原因は、ツールの導入ミスではなく、防御側の前提と営業側の送信手法が噛み合っていない点にあります。営業メールを根絶しようとして遮断条件を厳しくすると、本来届くべき見込み客からの連絡まで巻き込んで破棄してしまう危険が生じます。

営業メールが増えている背景

フォーム経由の営業が増加した背景には、生成AIによって自然な日本語の文面を大量に作成できるようになった環境と、フォームへの送信を自動化・半自動化する営業支援ツールの普及があります。

以前の営業文面は定型的であり、一目で見分けがつくものが大半でした。現在は、送信先サイトの事業内容をあらかじめ読み込み、「貴社の◯◯事業を拝見し」と個別の事業名や実績に触れる文面が生成されています。こうした文面は、人間が読んでも本物の問い合わせと即座に区別をつけるのが難しくなっています（メールフォームスパム対策ガイド：リスク・手法・最新トレンドをわかりやすく解説｜松崎まさひろ、2024年5月18日）。

さらに、こうした営業の送信主体には「人間」または「人間が介在するツール」が含まれる点も見落とせません。前掲の記事でも、フォームスパムを「ボットによる自動送信」と「手動による営業メール」の2種類に分類し、現在はその両方にAIによる文面生成が組み合わさっていると整理されています。既存のセキュリティ対策の多くは機械的な自動アクセスの検知を前提としているため、人間による手動操作を排除できない点が、機能しない直接の原因となります。

reCAPTCHA・Turnstile・ハニーポットが営業を止められない理由

reCAPTCHA、Cloudflare Turnstile、ハニーポットは、いずれも「送信者が人間か、プログラムか」を識別するための仕組みです。

reCAPTCHA（v3）は、ページ上での利用者の挙動などからスコアを算出し、ボットらしさを判定します。
Turnstileは、ブラウザの挙動や実行環境をもとに、利用者にパズルなどの操作を要求せず判定します（Cloudflare TurnstileでreCAPTCHAを代替する設定方法｜株式会社クロト、2025年12月25日）。
ハニーポットは、CSSなどで人間には見えないダミーの入力欄を配置し、そこに値を入力した送信をボットとみなします。

いずれの仕組みも、無差別に大量送信を試みる機械的なプログラムに対しては有効に働きます。Contact Form 7でもTurnstileとの連携機能が提供されており、導入の手間も抑えられます。

しかし、営業担当者や代行業者がブラウザでフォームを開き、文面を貼り付けて送信ボタンを押す場合、システムから見れば「人間による正規の送信」そのものです。CAPTCHAのスコア判定を問題なく通過し、隠しフィールドに入力することもありません。AIが作成した文面であっても、ブラウザを操作しているのが人間、あるいは通常ブラウザをエミュレートした環境であれば判定はすり抜けます。

これらの仕組みは送信主体の性質のみを検証しており、送信された文面の内容を評価していません。営業メールは文面の内容に起因する問題であるため、送信者の人間性を測る技術では防ぐ対象になり得ません。reCAPTCHAを導入しても営業が止まらないのは、設定の不備ではなく、機能の担当範囲が異なるためです。

「営業お断り」の表記が効かない理由

「営業目的の送信はご遠慮ください」といった注意書きをフォーム付近に配置しても、送信件数を抑える効果は限定的です。

専用の送信ツールは、HTML内の入力フィールドを検出して文面を一括入力する設計が多く、ページ上のテキストを読んで送信可否を判断する処理は行いません。また手作業で送る代行業者であっても、リスト化された企業サイトに対して機械的に送信作業をこなす運用では、個別の注意書きを精読して手を止めることは期待できません。注意書きを読んで自発的に送信を取りやめる送信者にしか抑止効果がなく、送信操作そのものを技術的に遮断できないためです。

対策の比較

フォームスパムへのアプローチは、防げる対象と発生する副作用がそれぞれ異なります。

CAPTCHA（reCAPTCHA・Turnstile）

自動送信ボットの排除には有効であり、基礎的な防壁として機能します。一方で、人間が手動または半自動で送る営業には作用しません。また、ボット判定の閾値を厳しく設定しすぎると、正当な見込み客の送信まで弾かれる恐れがあるため、導入後は実際の挙動を検証する必要があります（スパム問い合わせ急増のときにやるべき切り分けと対策｜AREA DRIVE、2024年5月26日）。

ハニーポット

正規の利用者に一切の手間をかけず、手軽に実装できます。単純な巡回ボットには効果を発揮するものの、人間の手動送信や、実際のブラウザを自動操作して不可視要素を判別する高度なスクリプトは防げません。

IP単位のレート制限

同一のIPアドレスから短時間に繰り返される連続送信を遮断できます。同一事業者による同一環境からの連投には効力を持ちますが、プロキシ経由や分散した環境から1件ずつ送信される営業には機能しません。また、同一のオフィス回線や共用ネットワークから複数の正規送信が行われた場合に、正常なアクセスを巻き込んで遮断するリスクがあります。

キーワードフィルタ

「SEO」「集客」「業務提携」などの特定の営業用語を含む送信を拒否する手法です。Contact Form 7では、WordPressの「コメント禁止キーワード」に指定した文字列やIPアドレスを含む送信をスパムと判定し、通知メールを送信しない機能が存在します（Disallowed list｜Contact Form 7）。

実装は平易ですが、語句の表記揺れや言い換えによって容易に回避されます。さらに、「自社のSEO施策について相談したい」といった正当な問い合わせまで、通知されないまま送信データが消失する危険を伴います。除外キーワードの保守を継続的に行う運用負荷も発生します。

手作業での確認

受信したすべての通知を担当者が目視で確認し、仕分ける方法です。文脈を踏まえた判断精度は最も高いものの、営業メールの件数に比例して確認工数が増大します。大量の営業文面に埋もれることで、重要な商談の通知を見落としたり、返信対応が遅延したりする要因となります。

内容にもとづく分類

送信された文面そのものを構文解析や自然言語処理で読み取り、営業文面である確率を算出する方法です。人間が手作業で送信した文面や、AIが生成した自然な言い回しに対しても、内容そのものから判定できる点が従来のボット対策と異なります。ただし、内容判定は確率的な推定に基づくため、誤判定を完全になくすことはできません。

このように、手法ごとに防げる対象や発生する副作用は異なります。

「削除」ではなく「仕分け」を基本にする

営業メール対策で「営業をゼロにする」ことを要件に置くと、フィルタの条件を厳格化せざるを得なくなります。しかし条件を厳しくするほど、正当な問い合わせを誤ってスパムと判定し、排除してしまうリスクが高まります。前掲のAREA DRIVEの記事でも、完全な遮断を目指すほど正当な連絡の不達を招きやすくなるため、ゼロを目指さない方針を推奨しています。

問い合わせフォームにおける誤判定は、営業のすり抜けよりも遥かに大きな損害を生みます。営業メールが1通届くだけなら破棄に数秒かかるだけですが、見込み客からの引き合いを1件誤って遮断した場合、失われた受注機会を取り戻すことは困難です。送信側からすれば「送信を完了したのに連絡が来ない」状態になるため、サイト運営者が取りこぼしに気付く機会は極めて限られます。

たとえばContact Form 7でAkismetなどのスパムフィルタを連携させた場合、スパムと判定された送信は通知されず、標準のContact Form 7は送信データをデータベースに保持しません。判定結果を後から確認したり誤判定を救出したりするためには、Flamingoなどのプラグインを別途導入して送信履歴を保存しておく必要があります（Spam filtering with Akismet｜Contact Form 7）。保存の仕組みがなければ、誤判定された正規の問い合わせは検知できないまま消滅します。

正当な問い合わせを失わないためには、判定結果を破棄ではなく仕分けとして扱う設計が適しています。

自動判定は送信を遮断するためではなく、振り分け先の分類に用いる
営業と判定した送信データも破棄せずに保持し、後から一覧で確認できるようにする
営業か正当な問い合わせか判別が難しい送信は、「確認待ち」の領域に隔離する
誤判定が発生した場合に、手動で問い合わせ一覧へ戻せる仕組みを用意する

仕分けを前提にすれば、自動判定の精度が完璧でなくとも商談機会を損なわずに済みます。運用担当者は普段「正規の問い合わせ」と「確認待ち」の受信箱だけを注視し、営業判定された一覧は必要に応じて定期確認する運用へ移行できます。

INQBOXの取り組み

パーティーハード株式会社では、こうした「文面を評価して判定し、破棄せずに仕分ける」運用の実現に向けて、フォームサービス「INQBOX」（https://inqbox.jp）を開発しています。

INQBOXは、フォームからの送信をルールベースとAIの二重で判定し、「問い合わせ一覧」「スパム一覧」「確認待ち」の3つに仕分けるサービスです。送信データを自動で破棄することはなく、各一覧の間は手動で移動できます。

ルール判定では、選択式項目の未操作、極端に長い件名、選択肢の全選択、同一IPからの短時間連投といった機械的な兆候を捕捉します。AI判定では文面から営業である確率を算出し、80%以上をスパム、50〜80%を確認待ち、50%未満を正当な問い合わせとして振り分けます。除外したい業種や歓迎したい相談内容などの判定基準は、自然言語の指示文として個別に調整できます。

フォームの実装は、ページ上にscriptタグと <div data-inqbox-form> を記述する構成です。既存サイトのCSSが引き継がれるためデザインを損なわず、Next.jsやVueを採用したモダンなフロントエンド環境でも導入できます。Freeプランでは、フォーム1つの設置、30日間の履歴保持、汎用Webhook連携が利用できます。

営業メールの確認や仕分け作業に工数を取られている場合は、無料で試すことから運用の見直しを検討してみてください。