フォーム営業を運用すると、必ずボット対策のあるフォームに当たります。ここでの判断は一貫させておく必要があります。自動投稿はせず、回避策も実装しません。その理由と、代わりの扱い方を整理します。

ボット対策が置かれている意味

対策の種類設置の意図
画像認証・チェックボックス型人以外の投稿を防ぐ
スコア判定型（画面上に見えない）挙動から自動投稿を判別する
入力項目を隠しておく（ハニーポット）機械だけが埋める欄で判別する
投稿回数の制限短時間の大量投稿を止める

どの方式でも、設置の意図は同じです。「機械からの投稿は受け付けたくない」という意思表示です。フォームの文面に「営業お断り」と書かれているのと、性質は近いものになります。

引く線

行為可否理由
人が画面を操作して投稿する可人による投稿は想定されている
自動投稿の対象から外すこれが基本意思を尊重する
認証を突破する仕組みを作る不可設置の意思を無効化する
認証代行サービスを使う不可同上
隠し項目を検出して避ける不可判別を無効化する行為

3〜5行目は技術的には実現できます。しかしできるかどうかと、やるかどうかは別です。投稿した先で読むのは人間の担当者で、その担当者はボット対策を設置した側です。回避して投稿した事実が伝われば、そこで関係は終わります。

事前に検知する

投稿対象のフォームがボット対策を持っているかは、多くの場合ページの内容から判別できます。

検知の方法分かること確実性
認証サービスのスクリプト読み込みを探す代表的な対策の有無高い
認証用のクラス名・要素を探す同上中
画面を人が確認するすべて確実

機械的な検知は完璧にはなりません。スコア判定型は画面上に何も表示されないことがあります。したがって「検知できなければ自動投稿してよい」という設計にはしません。人が最終確認する工程を残します。

外すのではなく記録する

ボット対策のあるフォームは、リストから削除しません。「自動投稿の対象外」として記録します。

記録の内容次にできる判断
ボット対策あり（種類）人が手で投稿する候補にする
検知した日後で変わっている可能性がある
公開メールアドレスの有無メール経路に回せるか判断できる
営業お断りの明記の有無そもそも接触しない判断ができる

3行目が実務的な出口です。フォームで自動投稿できない企業でも、公開されているメールアドレスがあればメール経路に回せます。逆にメールもフォームも使えない場合は、その企業への経路がないという事実が明確になります。

投稿の失敗を理由別に残す

フォーム投稿は失敗が起きます。理由を分けて記録すると、次の対応が変わります。

失敗の理由次の対応
ボット対策自動投稿の対象外にする／人が手で／メール経路へ
必須項目が埋められない投稿しない（内容が合っていない可能性）
営業お断りの明記企業単位でNG登録
フォームが存在しない・404URLを更新するか、経路を変える
送信エラー（一時的）時間を置いて再試行

理由を残さず「失敗」としか記録しないと、毎回同じ調査を繰り返します。とくに3行目は一度記録すれば以後の判断が不要になるため、記録の価値が高くなります。

既定は「投稿しない」にする

仕組みとして安全な側に倒しておきます。

  • フォーム投稿機能の既定は投稿しないモード（内容の確認だけ）にする
  • 投稿する場合は明示的に切り替える
  • ボット対策の検知、営業お断りの検知に該当したら投稿しない
  • 必須項目が確実に埋まらないなら投稿しない
  • 投稿しなかった理由をログに残す

既定を「投稿する」にすると、設定ミスや判断漏れがそのまま外部への投稿になります。フォーム投稿は取り消せません。既定を安全側に置くのが確実です。

まとめ

  • ボット対策の設置は「機械からの投稿を受け付けたくない」という意思表示
  • 人が手で操作するのは可。自動投稿はせず、回避策も実装しない
  • 検知は完璧にならないため、「検知できなければ投稿してよい」という設計にしない
  • リストから外すのではなく「自動投稿の対象外」として記録し、メール経路に回せるか判断する
  • 失敗は理由別に記録する。理由がないと毎回同じ調査を繰り返す
  • 既定は投稿しないモード。フォーム投稿は取り消せない