お問い合わせフォームに届く営業メールの中には、人ではなく自動送信ツール（bot）が送っているものがあります。本稿は、自社サイトに届いた1通の営業メールを「本当にbotか」から確かめ、止めるまでの約40分の記録です。
やったことは4つです。botかどうかを確かめる。botの弱点を探す。その弱点に合わせてシステムを直す。必要ならサーバーの設定も変える。判定に使った具体的な条件は、ここには書きません。理由は後半で説明します。
届いたのは、よくある営業メールだった
2026年10月7日の14時13分、サイトのお問い合わせフォームから1通のメールが届きました。件名は「協業のご提案」です。
中身は、AI検索で自社が紹介されるかを無料で診断するという営業でした。「貴店・貴社」「店名をお送りください」「配信停止は上記アドレスへ」と、宛先を問わず同じ文面を送る形です。私のサイトはシステム開発の事例を載せているもので、店舗ではありません。
フォームには以前から迷惑送信の対策を入れていました。それをすり抜けてきたので、まず正体を確かめることにしました。
1. botかどうかを確かめる
作業はAIエージェント（Claude Code）に任せ、私は結果を見て判断しました。手がかりは、サーバーが残しているアクセスの記録です。
| 確かめたこと | 分かったこと |
|---|---|
| どこから送られたか | 送信元を調べると、送ってきた会社のメール用ドメインを名乗るクラウド上のサーバーだった。人のPCではない |
| どれくらいの速さか | フォームを開いてから約11秒で、600字近い本文を送っていた。人の入力速度ではない |
| ブラウザとして自然か | 名乗っているブラウザと、実際のふるまいに食い違いがあった |
| 他の仕組みはどう見たか | 前日に入れたアクセス解析は、この訪問をすでにbotと判定し、閲覧数に数えていなかった |
結論は、営業会社のサーバー上で動く、ブラウザ自動操作ツールによる一斉送信でした。いわゆる「フォーム営業」です。
あわせて過去2週間の記録も見ました。粗い作りのbotからの送信が2件あり、こちらは既存の対策で止まっていました。今回のbotは、本物のブラウザを丸ごと動かすタイプです。だから簡単な仕掛けをすり抜けた、ということが分かりました。
2. botの弱点を探す
ブラウザを丸ごと動かすbotは、人のふりが上手です。ページを読み込み、画像も取り、JavaScriptも動かします。それでも、自動で動かしている以上、どこかに痕跡が残ります。今回の記録にも、人のブラウザなら起きない食い違いがいくつかありました。
もう1つの弱点は、もっと単純です。botは「送信しました」という画面しか見ていません。 メールが本当に届いたかは、送った側には分かりません。
3. システムを直す
この2つの弱点に合わせて、フォームを直しました。
- 痕跡で見分ける。 人のブラウザなら起きない食い違いがあれば、その送信はメールにしません。
- 弾いたことを悟らせない。 弾いた送信にも、本物の送信と同じ「送信しました」の画面を返します。応答にかかる時間も揃えました。相手からは、届いたのか捨てられたのか区別がつきません。
- ページに手がかりを残さない。 ページのソースは誰でも読めます。対策の説明コメントや、意味の分かる項目名は消しました。
- 弾いた記録は手元に残す。 いつ、どんな理由で弾いたかを、サーバーにだけ記録します。普通の人を誤って弾いていないかは、ここで確かめます。
直したあとは、実際に試して確かめました。
| 試したこと | 結果 |
|---|---|
| 今回のbotと同じ条件で送信 | 画面は「送信しました」。メールは届かず、記録にだけ残った |
| 試験環境で、主なブラウザ4種（Chrome、Safari、Edge、Firefox）からの送信を再現 | すべて届いた |
| 私が自分のブラウザから本番のフォームで送信 | 届いた。弾いた記録にも載っていない |
| 本番のページのソースを確認 | 対策の手がかりになる語は0件 |
4. 必要ならサーバーの設定も変える
今回のフォームは、システムの修正だけで足りました。botの送信は1通で、量で押してくる攻撃ではなかったからです。
一方、同じ日に、アクセス解析の受け口には連投への備えとして流量制限を入れました。こちらはサーバー（nginx）の設定変更で、管理者権限が要るため、私が自分で実行しました。中身で見分けるならシステムで、量で押されるならサーバーで止める、という分担です。
なぜ判定の条件を書かないのか
書けば、そのまま攻略本になるからです。フォーム営業の業者も、この記事を読めます。「何を見て弾いているか」が分かれば、次の日には直してきます。
同じ理由で、弾いても「送信しました」と返しています。弾かれたことが分からなければ、相手は何を直せばいいかも分かりません。対策は、中身を知られないことまで含めて対策です。
この方法の限界
- 相手が痕跡を消せば、すり抜けられます。 今回の判定は、今回のbotの癖に合わせたものです。そのときの次の手として、「人間確認」の仕組み（CAPTCHAの一種）を候補に残しています。
- 誤って弾いた人にも「送信しました」と見えます。 本人も私も気づけません。だから、弾いた記録をときどき見る必要があります。
- 小さなサイトでの一例です。 送信の量が多いサイトや、問い合わせが売上に直結するサイトでは、誤判定の重みがまったく違います。
費用をかけずに持ち帰れること
- まず本当にbotかを確かめる。 そのために、アクセスの記録を残しておく。記録がなければ、確かめようがありません。
- 既に止めている分も見る。 届いた1通だけでなく、止めた送信も確かめると、どの対策が効いていて、どこが抜けているかが分かります。
- 弾いた理由を相手に返さない。 エラーの文言を分けると、それだけで手の内が伝わります。
- 弾いた記録を残し、ときどき見る。 誤判定に気づける仕組みがないまま、強い対策を入れない。
- ページのソースに手がかりを残さない。 コメントや項目名も、外から読まれる前提で書く。
- 営業メールに返信しない。 「診断希望」と返せば、このアドレスは読まれていると相手に伝わります。
おわりに
botは人のふりが上手になりました。それでも、自動で動く以上、どこかに癖が出ます。記録を残し、それを読み、癖に合わせて直す。地味ですが、この繰り返しが一番効きます。
前の記事（攻撃にAIが使われる時代の守り方）で、作る役と疑う役と決める役を分ける話を書きました。今回も、記録を読んで直すのはAIエージェントで、何をどこまでやるかを決めたのは私です。