reCAPTCHAを入れても営業メールが減らない理由｜自動送信と人力送信は別物で、人力にはキーワード判定と「営業目的ではない」チェックで対処する

問い合わせフォームにreCAPTCHA v3を入れ、設定も検証も済ませた。それなのに翌週も、制作会社やフリーランスからの売り込みが同じように届く——これは設定ミスでも導入失敗でもありません。

先に結論を書きます。

reCAPTCHA v3が止めるのは「機械が送っている分」だけです。人が自分のブラウザで打ち込んで送っている営業メールは、v3ではまず止まりません。人が送っている以上、reCAPTCHAのスコアは満点に近い値が出るからです。

したがって、v3を入れても売り込みが残るなら、打つ手はreCAPTCHAの設定をいじることではなく次の2つです。

1. 本文のキーワードで判定し、件名に [営業] を付けて振り分ける（捨てずにタグを付けるのが要点）
2. フォームの直上に抑止文を置き、「営業目的ではありません」のチェックを必須にする

弊社graciautoは名古屋でホームページ制作とLINE公式アカウント構築を手掛けており、自社サイトと複数のクライアントサイトでフォーム受信を運用しています。この記事では実際に計測した数字をもとに、「v3で止まる分」と「止まらない分」の線引きと、止まらない分への対処を書きます。v3そのものの入れ方やハニーポット・連投制限といった基本の層は別記事に譲り、ここでは導入したあとに残る分を扱います。

—

手順0：増えたのは「アクセス」か「送信だけ」か

対策に入る前に、必ずこの切り分けをします。アクセス自体が増えてその一部が営業だったのか、アクセスは増えていないのに送信だけが集中したのか。前者なら流入元（広告・SEO・SNS）を見る話ですが、後者なら流入は無関係で、送信者の性質だけを見る話になります。

自社サイトで「営業の売り込みが急に増えた」と感じた日に計測したところ、結果は明確に後者でした。

指標	実測
GA4のセッション数（当日）	19セッション（直近35日で最低水準。月平均は約40）
問い合わせページのPV	増加なし（流入元も通常どおり）
フォーム通知メール（当日）	4通（それまでは日別最大2通）

アクセスは月内で最も少ない日なのに、フォーム送信だけが通常の2倍という形です。ここで「アクセスが増えたせいだ」と判断していたら、広告の配信面を疑うという見当違いの調査に時間を使うことになります。GA4のセッション数とフォーム通知の実通数を同じ期間で並べる——この1手だけで、調べる方向が決まります。

—

自動送信型と人力送信型の見分け方

営業フォーム送信には、性質のまったく違う2つの型があります。対処法が違うので、まず自分に届いているのがどちらかを判定します。

型A：自動送信（ツールによる一括投下）

判定の手がかりは3つです。

• 送信元IPがクラウド事業者に偏る（AWSやGCPの国内リージョンのIP帯が繰り返し現れる）
• 本文が崩れている（項目名が本文に混ざる、--- メッセージ --- のような区切り文字が本文欄に入る）
• 短時間に同一IPから複数回届く

自社サイトにある時期に届いていた売り込みがこの型で、送信元はいずれもAWS東京リージョンのIPアドレス、本文には毎回同じ位置に区切り文字の混入がありました。この型にはreCAPTCHA v3が効きます。むしろv3はこの型のために入れる層です。

型B：人力送信（人が実際にブラウザで送っている）

こちらの手がかりは次のとおりです。

• 送信元IPが1通ごとにバラバラで、すべて一般の国内回線（クラウドのIP帯ではない）
• 本文は崩れておらず、日本語として自然に読める
• 文面が同一テンプレート（宛名の形式、盛り込む要素、締めの言い回しまで揃う）
• 送信ページがトップページなど、人間がたどる動線と一致している

自社サイトに1日で届いた4通は、すべてこの型でした。差出人は4社とも別、送信元IPも4つとも別の国内回線。にもかかわらず文面の構成はほぼ同じで、宛名の書き方、外部サービスに置いたポートフォリオへのリンク、1分程度の自己紹介動画のURL、「外部パートナー」「リソース不足の際は」という言い回しまで共通していました。同じ営業テンプレートを、別々の人間が手作業で送っている状態です。

この型はreCAPTCHA v3では止まりません。

—

なぜv3は人力送信を止められないのか

reCAPTCHA v3は「これは人間か、機械か」を0.0〜1.0のスコアで返す仕組みです。1.0に近いほど人間らしく、サーバー側でしきい値（一般的には0.5）を決めて、それを下回った送信を破棄します。

ここで重要なのは、この仕組みが判定しているのは「人間かどうか」であって、「その人間の用件が営業かどうか」ではないという点です。人が自分のパソコンで、通常のブラウザで、フォームに手で文字を打って送信すれば、それは定義上まったくの人間です。スコアは高く出ます。

自社サイトでトークンを取得し、Googleの検証API（siteverify）に問い合わせて返ってきた値がこちらです。

success : true
hostname: （自社ドメイン）
score   : 1.0
action  : contact

スコア1.0＝満点です。しきい値をどこに設定していても通過します。

ここを誤解したまま「まだ営業が来る＝reCAPTCHAが壊れている」と判断し、しきい値を0.5から0.8へ引き上げる調整に走るのは典型的な悪手です。人力の営業は1.0で来ているので、しきい値をいくら上げても止まりません。止まるのは本物の見込み客のうち、たまたまスコアが低く出た人だけ。防御は強くならず、機会損失だけが増えます。しきい値をいじるのは「正規の送信が弾かれている疑い」があるときに下げる方向だけ、と決めておくのが安全です。

—

「reCAPTCHAが効いているか」自体を先に確かめる

打ち手を変える前に、v3が本当に動いているかを確認します。ここは目視では分からない領域です。

reCAPTCHA v3は、サイトキーの値が無効でもエラーが表に出ません。スクリプトの読み込みは成功し、コンソールにもエラーは出ず、バッジも出ず、フォームは今までどおり送信できてしまいます。つまり「フォームは動いているから大丈夫」は、防御が生きている証拠になりません。

確かめ方は2つに分けます。

1. シークレットキーは、サーバーから検証APIをダミー値で1回叩きます。

curl -d "secret=シークレットキー&response=dummy" \
     https://www.google.com/recaptcha/api/siteverify

invalid-input-response だけが返ればシークレットは本物（ダミーのトークンが無効なだけ）、invalid-input-secret が返ればシークレットが無効です。

2. サイトキーは、本番ドメインのページ上でトークン取得処理を実行して戻り値を見ます。無効なキーの場合、ここで初めて Invalid site key というエラーが姿を現します。

キーは2つあり、片方だけが無効という状態が普通に起こります。管理画面のスクリーンショットにはキー文字列が表示されないため目視での突き合わせはできません。「設定は正しい」という報告と「動いている」は別物として扱ってください。

設計上の注意：キーを直書きすると、防御が黙って消えることがある

もう1点、構成上のリスクを先に潰しておきます。シークレットキーをPHPファイルなどに直接書き込む構成にした場合、キーを持っていない別のマシンや別の作業環境からファイルを転送・ビルドすると、キーが空のまま上書きされます。このときフォームは正常に動き続けるため、防御だけが静かに消えたことに気づけません。

対策は、キーを環境変数やサーバー側の設定ファイルに置いて転送対象から外すか、直書きのままにするならキーを投入する場所を一覧にして記録し、転送前に必ず突き合わせることです。複数人・複数端末で同じサイトを触る体制では、この事故は「起こり得る」ではなく「いずれ起こる」と考えて設計したほうが確実です。

—

人力の営業送信に効く3つの手

v3が生きていることを確認したうえで、なお届く分への対処です。

手1：キーワード判定で振り分ける（捨てない）

フォームの受信処理に、本文と各項目を対象としたキーワード判定を1段入れます。判定に使う語は届いた実物から抽出します。自社の場合は次の語でした。

• ポートフォリオ
• 外部パートナー / パートナー企業
• リソース（「リソースが不足した際は」の形で頻出）
• 営業代行
• 短縮URLサービスのドメイン、デザイン共有サービスのドメイン、動画共有サービスのドメイン

重要なのは、該当したメールを破棄しないことです。件名の先頭に [営業] のようなタグを付けて通常どおり送信し、メールソフト側でそのタグを見て自動振り分けすれば、受信箱には残りません。

破棄ではなくタグ付けにする理由は、誤判定の保険です。「ポートフォリオ」も「パートナー」も、本物の見込み客が使う可能性のある語です。破棄する設計にした瞬間、その誤判定は永久に気づけません。タグ付けなら、振り分け先のフォルダを月1回眺めるだけで誤判定を発見できます。

判定を広げる目安は「その語を本物の見込み客が使う確率」です。ゼロに近い語（「営業代行」など）は単独で、使われ得る語（「パートナー」など）は複数条件の組み合わせで判定します。

手2：フォーム直上に抑止文と必須チェックを置く

送信ボタンの手前に、次の2つを置きます。

• 抑止文：「営業・採用に関する売り込みのご連絡はご遠慮ください」
• 必須チェックボックス：「営業目的のご連絡ではありません」

これは技術的な防御ではなく、送る側に一手間と意思表示を要求する仕組みです。テンプレートを機械的に貼り付けて次のサイトへ移る動線に判断を1つ挟むため、人力で大量に送っている相手には効きます。正規の見込み客にとってはチェック1つ増えるだけで、負担はほぼありません。

ただし必須にする以上、チェックを入れ忘れたときのエラー表示が正しく出るかは必ず実機で確認してください。ここが壊れていると、本物の問い合わせを自分で止めることになります。

手3：破棄する分は「成功を装って」捨てる

自動送信型のように明確なスパムを破棄する場合は、エラーを返さず「送信完了」を返したうえで内部で捨てます。エラーを返すと「弾かれた」という情報が相手に渡り、条件を変えて再挑戦されるためです。

あわせて、検証APIへの通信自体が失敗したときは判定をあきらめて通す設計にします。外部サービスの一時的な障害が、そのまま「問い合わせが1件も届かない状態」に直結するのを避けるためです。セキュリティの層を足すときは、その層が落ちたときに何が止まるのかを必ずセットで決めておきます。

—

数字を判断に使っているなら、CV数の中身も数え直す

営業フォーム送信が混ざっていると、アクセス解析上のコンバージョン（CV）数がそのぶん水増しされます。「今月は5件の問い合わせがあった」という数字が、実は全件が売り込みだった、ということは珍しくありません。この数字を広告予算やSEO施策の判断材料にしていたなら、判断の前提そのものが崩れています。

対策を入れればCV数は減りますが、それは正常な動きです。先に「今の数字の中身」を受信箱の実物と突き合わせて数えておけば、翌月の落ち込みに動揺せずに済みます。

なお、フォーム送信イベントの件数と受信メールの通数は一致しないことがあります。ハニーポットなどで破棄された分はイベントだけ記録されるためで、この差はどの層で何件落ちたかの内訳として読むのが正しい見方です。

—

実は受信箱のノイズは、フォームより別の場所から来ていることがある

最後に、実務上いちばん効いた話を書きます。「営業メールが多い」と感じてフォーム対策に着手したものの、受信箱を実際に数えてみると通数の大半はフォーム経由ではありませんでした。

自社の環境で最大のノイズ源だったのは、放置していたWordPressサイトから届く「コメント承認待ち」の自動通知でした。1日あたり10〜51通、承認待ちは4,000件超。フォーム経由の通知が45日間で22通だったのに対し、こちらは1日でその2倍以上が届いていた計算です。

対処はフォームより簡単で、コメント受付を停止する、管理者メールアドレスを業務用と別にする、そもそも閉じる、のいずれかで済みます。

「営業メールが多い」という体感は、通数を実際に数えてみるまで発生源が特定できません。フォーム対策を始める前に、通知先の受信箱を差出人別に集計して上位から潰すほうが効率的です。

なお、レンタルサーバーではアクセスログが有効になっていないことがあります。その場合はサーバー上のメール保管ディレクトリを直接見てファイル単位で数えるのが確実ですが、日本語メールの本文は文字コードが変換されて保管されているため、そのままテキスト検索をかけても引っかかりません。「検索しても0件だからスパムは来ていない」は、よくある読み違えです。

—

まとめ：どこまでやるかの判断基準

状況	打つ手
本文が崩れた売り込みが、同じIP帯から繰り返し届く	reCAPTCHA v3が効く層
文面は自然だが同一テンプレ、IPはバラバラ	v3では止まらない。キーワードでタグ付け＋必須チェック
v3を入れたのに変化の実感がない	キーの生存確認（siteverify照会＋実ドメインでのトークン取得）
CV数を広告・SEOの判断に使っている	対策の前に、受信箱の実物と件数を突き合わせる
そもそも受信箱が通知で埋まっている	差出人別に集計し、フォーム以外の通知源から潰す

reCAPTCHAは万能の門番ではなく、「機械かどうか」だけを判定する1つの層です。人が送ってくる営業には別の層を足し、その層は破棄ではなくタグ付けにして誤判定に気づける形で運用する。完全にゼロにはなりませんが、受信箱に残る営業メールは大きく減り、本物の問い合わせを取りこぼすリスクも抑えられます。

—

問い合わせフォームの設計や、届いた問い合わせをLINE公式アカウントへつなぐ導線の構築については、graciautoまでお気軽にご相談ください。