お問い合わせフォームに営業メールしか来ないときの止め方｜スパムを弾く4層と、CV数をそのまま信じない見方

サイトのお問い合わせフォームを開けてみたら、届いていたのは制作会社やSEO業者、人材紹介からの売り込みばかり。お客さまからの相談は1件も入っていない——という状態は、フォームを設置したサイトなら遅かれ早かれ起こります。

先に結論を書きます。止め方は「弾く仕組みを4層で重ねる」こと、そして対策に着手する前に「今カウントされている問い合わせ件数の中身を、受信箱の実物と突き合わせて数える」ことです。

順番が逆になりやすいので強調しておきます。多くの場合、スパムを止めることより先に確認すべきなのは、アクセス解析上のコンバージョン（CV）数が、営業スパムで水増しされていないかです。ここを数えずに対策だけ入れると、翌月にCV数が急落して「対策のせいでサイトが壊れた」と誤解する事故が起きます。

弊社graciautoは名古屋でホームページ制作とLINE公式アカウント構築を手掛けており、自社サイトを含め、フォーム受信の経路が異なるサイトを複数運用しています。この記事では、実際に自社サイトで対策を入れたときの実測値と設定内容を、そのまま使える手順に整理して書きます。

—

手順0：対策の前に、今のCV数の中身を数える

最初にやることは設定変更ではなく、突き合わせです。

1. アクセス解析（GA4など）で、直近1〜2週間のフォーム送信イベント（generate_lead や form_submit）の件数を出す
2. 同じ期間に、フォームの通知先メールボックスへ実際に届いたメールを1通ずつ開く
3. 「見込み客からの相談」と「業者からの売り込み」に仕分けて、件数を比べる

自社サイトで2026年8月上旬にこれをやったところ、6日間で記録されていたフォーム送信は5件。受信箱の実物を1通ずつ確認すると、5件すべてが制作会社・SEO業者・人材紹介などからの売り込みで、見込み客からの相談はゼロでした。

この数字が持つ意味は2つあります。

• CV数を広告やSEOの判断材料にしていた場合、その判断は根拠を失っている。 「今月は5件取れた」を前提に予算を組んでいたなら、実際の母数はゼロです
• 対策を入れれば、CV数は確実に減る。 減るのが正常な状態であって、異常ではありません

この2つを先に把握してから対策に入ると、後の判断が濁りません。逆に数えないまま導入すると、CV数の急落が「対策の副作用」なのか「本物のリードの取りこぼし」なのか区別できなくなります。

—

スパムを弾く4層：どこまでやれば止まるか

フォームの防御は、1つの仕組みで完結しません。突破されるパターンが層ごとに違うためです。下から順に積み上げます。

第1層：ハニーポット（自動bot対策）

人の目には見えない入力欄をフォームに1つ置き、そこに値が入っていたらbotと判定します。欄の名前は website や company_url など、botが埋めたくなるものにします。

安価な自動botはページの入力欄を機械的に全部埋めるため、この1層だけで機械送信のかなりの割合が落ちます。コストゼロで効果が出る層なので、最初に必ず入れます。

第2層：連投制限（同一送信元の反復対策）

同じIPアドレスからの送信を、一定時間に1回までに制限します。自社サイトでは同一IPから60秒に1回とし、サーバー上の一時ファイルをロック代わりに使って判定しています。

これはbotの連続投下を止めると同時に、フォームを踏み台にした大量送信の予防にもなります。

第3層：リファラ判定（外部からの直接POST対策）

自社サイト以外のページから送信処理へ直接POSTされた場合は403で拒否します。フォームのHTMLをコピーして外部から叩く手口を防ぐ層です。

あわせて、この層でヘッダインジェクション対策（送信者名やメールアドレス欄に改行を仕込まれ、メールヘッダを書き換えられる攻撃の防止）と入力文字数の上限も入れておきます。フォームの受信処理を自前で書く場合、ここは必須と考えてください。

第4層：reCAPTCHA v3（人力送信・高機能bot対策）

ここまでの3層を入れても、人が手で送っている売り込みと、ブラウザを本物同様に動かす高機能なbotは通り抜けます。 先ほどの「6日間で5件、全部が売り込み」は、まさに3層を入れた状態で通過してきた分です。

そこで4層目としてreCAPTCHA v3を入れます。v3はチェックボックスを出さず、訪問者の挙動から0.0〜1.0のスコアを算出する方式です。送信時にトークンを取得してサーバーへ渡し、サーバー側でGoogleの検証API（siteverify）に問い合わせて判定します。

どこまで入れるかの判断基準

状況	推奨
月の問い合わせが数件・売り込みは月1〜2通	第1〜3層で十分
業者の売り込みが毎日届く／CV数を広告やSEOの判断に使っている	第4層（v3）まで入れる
完全に止めたい・自動送信が明らかに多い	v2のチェックボックス方式。ただし正規の訪問者にも操作を強いるため離脱と引き換えになる

v3を入れる基準は「スパムの量」ではなく「その数字を判断に使っているか」です。 数字を判断に使っていないなら、3層で運用して受信箱で仕分けるほうが安く済みます。

—

弾き方の設計：エラーを返さず「成功を装って捨てる」

判定した後の挙動には、正解があります。

スパムと判定した送信には、エラーを返さずに「送信完了」を返し、内部で破棄します。

エラーを返してしまうと、送信側に「弾かれた」という情報を渡すことになり、条件を変えて再挑戦されます。成功したように見せておけば、相手は通ったと思って去ります。実装としては、破棄した事実だけをサーバーのエラーログへ1行記録しておきます（例：recaptcha_reject score=0.2）。

自社サイトでは、スコアのしきい値を0.5未満で破棄に設定しています。この値は1か所の定数として置き、後から緩められるようにしておくのが要点です。正規の訪問者が誤って弾かれる事象が出た場合、0.5→0.3へ下げるだけで対応できます。

あわせて必ず入れる例外処理：検証APIに繋がらないときは通す

reCAPTCHAの検証はGoogleのサーバーへの通信を伴います。この通信が失敗したときは、判定をあきらめて送信を通す設計にします。

理由は単純で、Google側の一時的な障害や自社サーバーからの外部通信エラーが、そのまま「問い合わせが1件も届かない状態」に直結してしまうためです。スパムを100点で止めることより、本物の問い合わせを落とさないことを優先します。セキュリティの層を足すときは、その層が落ちたときに何が止まるかを必ずセットで決めておく——これはフォームに限らず共通する考え方です。

—

動いているかを確かめる方法（ログが読めないサーバーの場合）

導入して終わりにすると、防御が効いているかどうか分からないまま運用することになります。ここが一番厄介な部分です。

レンタルサーバーの多くは、PHPのエラーログや一時ファイルを外部から読めません。「弾いた記録」を直接確認できないため、外から観測できる挙動の差で判定します。

使えるのが、第2層（連投制限）との組み合わせによる判定です。

1. reCAPTCHAのトークンを付けずに、フォームの受信処理へ2回連続でPOSTする
2. 結果を見る

結果	意味
1発目が成功、2発目が429（制限）	reCAPTCHAを素通りしている。1発目が連投制限のロックを作ったため2発目が弾かれた＝第4層が機能していない
1発目も2発目も成功が返る	reCAPTCHAの関門で先に捨てられている。連投制限のロックまで処理が到達していない＝正しく動いている

一見すると「2回とも成功」のほうが素通りに見えますが、逆です。この判定法なら、ログが読めない環境でも防御の有無を外側から確定できます。

なお、この確認とは別に、正常系（自分のブラウザからフォームを普通に送って届く）のテストは必ず実機で行ってください。 スパムを弾く仕組みは、設定を誤ると本物の問い合わせも同じように静かに捨てます。エラーが出ないため、届かないことに誰も気づきません。

—

導入時に防いでおきたい2つの事故

1. キーの入れ忘れで、防御が黙って消える

reCAPTCHAのシークレットキーを受信処理のPHPファイルへ直接書き込む構成にした場合、キーを持っていない別のパソコンやサーバー上のソースから、そのファイルを再度書き出すと、防御が無言で外れます。

フォーム自体は問題なく動き続け、送信も通り、通知メールも届きます。外から見て何も変わらないため、スパムが再び増えるまで誰も気づきません。

これを避けるには、次のどちらかを最初に決めておきます。

• キーをソースに直書きせず、サーバーの環境変数や、公開領域外に置いた設定ファイルから読み込む
• 直書きする構成にするなら、キーを入れる場所を一覧化し、作業マシン側とサーバー側の両方に投入するまでを1つの作業とする

「更新したら防御が消えた」ではなく、「更新しても消えない置き方を先に選ぶ」——設定値の置き場所は、実装の最初に決めるべき設計事項です。

2. バッジの扱いを後回しにしない

reCAPTCHA v3を入れると、画面右下にバッジが表示されます。デザイン上これを消したい場合、Googleの規約により「このサイトはreCAPTCHAによって保護されています」といった帰属表示をフォーム付近に入れることが条件になります。

消すか出すかはデザイン判断ですが、導入時に決めておかないと、公開後に「知らないマークが出ている」という指摘を受けてから慌てることになります。

—

対策後の計測：減った数字が、本当の母数

対策を入れた後、CV数は下がります。冒頭で数えておくべきと書いたのは、この落差を事前に説明可能にしておくためです。

• 対策前：フォーム送信 5件（内訳＝売り込み5・見込み客0）
• 対策後：フォーム送信の記録が減り、残った数字が実際の相談数に近づく

ここで見るべきは件数の増減ではなく、「数字が実態と一致したかどうか」です。CV数が5件から0件になったのなら、それは対策の失敗ではなく、もともと0件だったという事実が可視化されただけです。そこから初めて「では相談をどう増やすか」という本来の課題に取りかかれます。

経路を分けておくと、本物のリードは残る

もう1つ、実測から得られた要点があります。

先ほどの「6日間でフォーム経由の相談ゼロ」と同じ時期に、LINE公式アカウント上に置いた相談フォームからは、実在する経営者からの具体的な相談が1件届いていました。 同じ日にブログ記事の記事下LINEボタンがクリックされた記録が解析側に残っており、記事のテーマと相談内容も一致していることから、経路は「検索 → ブログ記事 → 記事下のLINEボタン → 友だち追加 → LINE上の相談フォーム」だったと考えられます（解析データから個人は特定できないため、経路については状況証拠です）。

差が出た理由は導線の構造にあります。LINE経由は「友だち追加」という一段を挟むため、フォームの受信処理へ機械的にPOSTする手口が通用しません。結果として、Webフォームがスパムで埋まっていても、LINE側には本物だけが残る状態になります。

問い合わせ経路をWebフォーム1本に絞らず、LINEを併存させておくことは、接客のためだけでなくリードの品質を切り分ける手段としても機能する——スパム対策を進めるうえで、覚えておく価値のある構造です。

—

まとめ：着手順

1. 数える：解析上のCV数と、受信箱の実物を同じ期間で突き合わせ、売り込みと相談の比率を出す
2. 3層を入れる：ハニーポット／同一IPの連投制限／リファラ判定（＋ヘッダインジェクション対策・入力長制限）
3. 判断する：その数字を広告やSEOの意思決定に使っているなら、reCAPTCHA v3まで入れる
4. 捨て方を決める：エラーを返さず成功を装って破棄。しきい値は1か所の定数に。検証APIに繋がらないときは通す
5. 確かめる：トークン無しPOSTの2連射で防御の有無を外側から判定し、正常系は実機で送信テスト
6. 置き場所を決める：キーは環境変数へ。直書きするなら投入先を全部リスト化する
7. 説明できるようにする：対策後にCV数が減るのは正常。減った後が本当の母数

スパム対策は「フォームを守る作業」に見えますが、実際に守っているのはその数字を見て下す経営判断のほうです。件数が正しくなって初めて、集客の議論が始められます。

弊社では、ホームページ制作とあわせてフォームの受信設計・計測・LINE導線までを一続きで構築しています。問い合わせの数字が実態と合っていない、あるいは営業メールばかりで本来の相談が埋もれているという場合は、現状の確認からご相談ください。