問い合わせフォームのスパム対策を探してこの記事にたどり着いた方は、おそらくこういう状況ではないでしょうか。reCAPTCHAは入れている。WAFも入れている。それでも、営業メールは毎日届く。
私たちGrowGroup株式会社も、まったく同じ状態でした。そして、この状況にははっきりした理由があります。
フォームに届く迷惑な問い合わせは、性質のまったく違う2種類が混ざっています。機械が送るスパムと、人が書いた営業メールです。前者は既存の対策で止まりますが、後者は止まりません。人間が、実在する会社から、日本語の文章を書いて、正規のフォームから送っているからです。技術的には、本物の問い合わせと見分けがつきません。
私たちが分析した実データでは、reCAPTCHAを通過した後に残っていた営業メールは、中途採用フォームで73.1%。採用の窓口が、実質的に営業の窓口になっていました。この記事では、その「人が書いた営業メール」を選り分けるツールHajik(ハジク)を自社開発するまでの経緯と、実測できた結果をお伝えします。
目次
- 1 きっかけは、お客様からの相談でした
- 2 営業メールは、時間ではなく「数字」を壊す
- 3 被害は、5つの形で出ます
- 4 スパムと営業メールは、別の問題です
- 5 2つに分けることが、そのまま設計になります
- 6 目的を、途中で書き直しました
- 7 5つの原則
- 8 やらないと決めたこと
- 9 「そもそも個人情報を送らない」という設計
- 10 導入は、タグを1行
- 11 成果:実証できたこと
- 12 溜まるほど、日本語の営業メールに強くなる
- 13 なぜWeb制作会社がこれを作るのか
- 14 よくある質問
- 14.1 reCAPTCHAを入れているのに営業メールが届くのはなぜですか?
- 14.2 Hajikを入れれば、既存のボット対策は外していいですか?
- 14.3 本物の問い合わせがブロックされることはありませんか?
- 14.4 問い合わせの内容がAIに渡るのが不安です
- 14.5 導入にサイトの改修は必要ですか?
- 14.6 WordPressのお問い合わせフォーム(Contact Form 7など)でも使えますか?
- 14.7 うちのようなフォームでも効果はありますか?
- 14.8 海外製のスパムフィルタとは何が違うのですか?
- 14.9 同じ会社から何度も営業が来るのですが、まとめてブロックできませんか?
- 14.10 なぜ「営業メールを100%ブロックします」と言わないのですか?
- 15 まとめ
きっかけは、お客様からの相談でした
私たちはWeb制作会社です。年間で数十本のサイトを納品しています。
そして納品後、お客様から同じ相談を受けることが重なりました。「問い合わせフォームに営業メールばかり届いてつらい」——。私たちは制作時に、reCAPTCHAをはじめとするボット対策を標準で組み込んでいます。それでも届く、というのです。
調べてみると、私たち自身のフォームも同じ状態でした。つまりこれは、特定のサイトの設定ミスではありません。いまのボット対策では原理的に止まらないものが、届き続けている。そう理解したことが出発点です。
そして、ここが分岐点でした。自社の困りごとであると同時に、納品したすべてのお客様の困りごとでもある。ならば、自分たちのフォームを直して終わりにするのではなく、お客様に提供できる形にするべきではないか——。Hajikが社内ツールではなく製品として設計されたのは、この時点で決まっています。
営業メールは、時間ではなく「数字」を壊す
営業メールの被害というと、多くの方が「仕分けの手間」を思い浮かべます。もちろんそれもあります。ですが私たちがWeb制作会社として最初に問題視したのは、もっと見えにくい被害でした。
まず、量の話をしておきます。Hajikを実際に動かしている自社および関係先16サイトで、直近約2ヶ月(2026年5月13日〜7月17日)に判定した3,502件のうち、営業と判定したものが70.1%でした。フォームに届くもののうち、本物の問い合わせは22.3%しかありません(内訳は後述の成果の章に載せています)。残りの大半に、これから書く被害がぶら下がっています。
コンバージョンが、誤発火します。
問い合わせフォームの送信完了は、ほぼすべてのサイトでコンバージョン(CV)として計測されています。ところが営業メールも、同じフォームから、同じように送信されます。当然、同じようにCVとしてカウントされます。
何が起きるか。
- 広告の最適化が狂う。広告プラットフォームは「CVが取れた経路」を学習して配信を寄せます。営業メールがCVに混ざれば、営業メールが届きやすい経路に予算が寄っていきます
- サイト改善の判断が狂う。「このページはCV率が高い」という数字を信じて施策を打つ。その数字が営業メールで水増しされていたら、打つ手そのものが的外れになります
- レポートが信用されなくなる。現場は肌感覚で「この数字、盛れてるよな」と気づいています。数字と実感がズレたレポートは、やがて誰も見なくなります
仕分けの手間は、時間を返せば取り戻せます。ですが壊れた数字は、そこから下した判断ごと間違えます。しかも厄介なことに、間違えたことに気づけません。
私たちがこの被害に敏感だったのは、サイトを作って終わりではなく、公開後の数字を見て改善提案までしているからです。自分たちが根拠にしている数字が汚れている、という問題でした。
被害は、5つの形で出ます
コンバージョンの誤発火を筆頭に、営業メールの被害を整理するとこうなります。
| 被害 | 何が起きるか |
|---|---|
| コンバージョンが誤発火する | 営業メールがCVとして計測され、広告最適化とサイト改善の判断が狂う。間違えたことに気づけない |
| 本物の相談を見落とす | 営業メールに埋もれて、大事な問い合わせを見逃す。そのまま受注機会を失う |
| 選別に時間が溶ける | 毎日、届いたメールを仕分ける。判断は要らないのに、時間だけ要る作業 |
| 対応が遅れる | 埋もれるので、本物の相談への返信が遅くなる。速さが命の相談ほど痛い |
| フォームを閉ざさざるを得ない | つらくなって入力項目を増やす、窓口を減らす、最悪は問い合わせをやめる。本末転倒 |
最後の「フォームを閉ざさざるを得ない」は、私たちがいちばん避けたかったものです。問い合わせフォームは、お客様と出会うための窓口です。営業メールがつらいからといって窓口を狭めるのは、迷惑メールに負けて商売の入口を閉じているということにほかなりません。
スパムと営業メールは、別の問題です
ここが、この記事でいちばんお伝えしたい切り分けです。フォームに届く迷惑な問い合わせは2種類あり、解き方がまったく違います。
| ボットスパム | 営業メール | |
|---|---|---|
| 送り主 | 機械 | 人間 |
| 問題の性質 | 量の問題 | 判断の問題 |
| 見分け方 | 送信の挙動で分かる(人間の手では不可能な速度・回数) | 内容を読まないと分からない |
| 既存対策 | reCAPTCHA等が有効 | 素通りする(人が送信するため、ボット判定を通過) |
| 解き方 | 機械的に排除する | AIで本物と選り分ける |
実際にどれくらい残るのか、私たちが分析した実データをお見せします。あるBtoB企業1社のフォーム・約20ヶ月・計1,894件を分類した結果です。
BtoB企業1社の実データ 計1,894件/約20ヶ月分(2026年4月時点)。全件reCAPTCHA通過後=ボットスパムは事実上ゼロ
出典:GrowGroupによるクライアントフォームの実データ分析(2026年4月時点・社名は非公開)。比率は各フォームの全受信件数に占める営業メールの割合。
ご覧のとおり、同じ会社の中でも、フォームの性質によってまったく違いました。一般的な問い合わせフォームなら1割程度ですが、中途採用のフォームは7割超。その大半が、人材紹介サービスの提案でした。いずれも正当な営業活動ですが、採用の応募を受ける窓口としては、本来の用途が埋もれてしまっているという状態です(採用を検討している会社にとっては、同じメールが有益な提案になり得ます。だからこそ送信元では判断できない、というのが後述の原則4です)。
お使いのフォームに営業メールがどれくらい混ざっているかは、タグを1行入れるだけで分かります。
Hajikの無料トライアル
これらはすべて、ボット対策を通過してきたものです。機械なら止まりますが、人が書いていれば止まりません。数字が示しているのは「対策が甘い」ではなく「守備範囲が違う」ということです。
ボットスパムは、実は難しくありません。私たちの判断基準は単純で、1秒で10通送る人間はいません。それだけで十分に見分けがつきます。ここは複雑なモデルを持ち込む場所ではなく、素直に、シンプルに考えるべき領域です。
難しいのは営業メールのほうです。人間が、実在する会社から、まともな日本語で、正規のフォームから送っている。送信の挙動を見ても本物と区別がつきません。内容を読んで、意味を判断するしかない。だからここだけがAIの出番になります。
Hajikは、この2つを両方とも引き受けます。ボットは機械的に弾き、人が書いた営業メールはAIで選り分ける。他の対策の有無に依存しない設計にしました。何かの補助として作ったものではありません。
2つに分けることが、そのまま設計になります
「スパムと営業メールは別の問題」というのは、記事の整理のための話ではありません。この切り分けが、そのまま製品の作りを決めています。
仮に、届いたものを全部AIに読ませて判定させるとどうなるか。原価が破綻します。ボットは1秒に何十通でも送ってきます。その1通ずつをAIに読ませていたら、費用はいくらでも膨らむ。攻撃する側は無料で、防ぐ側だけが課金されるという、勝ち目のない構図になります。
ですから、量の問題は量で、判断の問題だけをAIで解きます。
- ボットは、手前で機械的に落とす。送信の挙動を見れば分かるので、AIを使う必要がありません。ここが防波堤になります
- 防波堤を越えてきたものだけ、AIが読む。人が書いた文章だけが残るので、ここで初めて「意味を判断する」価値が出ます
この構造にすると、ボットがいくら攻めてきても費用が跳ねません。そして人が書いたメールには、費用を惜しまず精度を注ぎ込めます。2つを分けたから、両方に正しい手が打てる——切り分けの実利はここにあります。
逆に言えば、この2つを混ぜて考えている限り、対策は必ずどこかで無理をします。ボット対策を強くしても営業メールは減らず、かといって全部をAIに読ませれば費用が破綻する。「フォーム対策」という一つの言葉で括ってしまうことが、そもそもの詰まりどころだと私たちは考えています。
目的を、途中で書き直しました
正直に書きます。開発の初期、私たちは目的を取り違えていました。
| 目指していたもの | |
|---|---|
| 当初(誤り) | AIで完璧に判定する、高度なSaaS |
| 書き直した後 | 担当者の判定作業を大幅に減らす、現実的なアシスタント |
この違いは、言葉遊びではありません。「完璧」を目指すと、判断に迷ったときにAIが無理やり白黒をつけようとします。その結果、本物の相談をブロックする事故が起きます。営業メールを1通見逃すのは軽傷ですが、本物の相談を1件ブロックしたら、それは失注です。取り返しがつきません。
ですから目的を「減らす」に書き直しました。大半を自動で処理し、迷ったものは人が見る。これが正しい姿でした。
5つの原則
目的を書き直したあと、判断に迷ったときに立ち返る原則を決めました。
- 本物を絶対に見失わない。営業メールを見逃すのは○、本物をブロックするのは×。迷ったら本物扱い。この非対称性がすべての土台です
- 量ではなく質で判断する。問い合わせが急に増えたら攻撃、ではありません。テレビで紹介された、SNSで話題になった——嬉しい急増を攻撃と誤認しない
- AIに過剰な期待をしない。判定しきれないものは人間の仕事として残す。AI判定を「完璧な自動化」として売らない
- 送信元を決めつけない。同じ会社からのメールでも、宛先によって営業にも本物にもなります。人材会社からのメールは、ある会社にとっては営業ですが、採用を考えている会社にとっては本物の相談です
- 得意領域を広く取る。ボット排除から営業選別まで、Hajik単独で対応する
原則2と4は、私たち自身が一度間違えた道です。「流入量の急増は攻撃シグナル」という発想は、直感的で分かりやすい。ですが実装を詰めるほど、それではお客様のサイトが話題になった日に窓口を閉じてしまうと分かりました。同じく「この会社は営業を送ってくる」という企業単位のブラックリストも、文脈依存で破綻します。どちらも自分たちで否定して捨てました。
やらないと決めたこと
何をやるかより、何をやらないかのほうが、製品の性格を決めます。
- 企業単位の絶対ブラックリストは作らない。技術的に破綻しているだけでなく、倫理的にも不適切です。ある会社を「営業を送る会社」と永久に決めつける権利は、私たちにはありません
- 「海外だから」「英語だから」でブロックしない。日本企業でも海外向けにビジネスをしているお客様はいます。誤ブロックは致命的な機会損失です
- ネットワーク層の防御と正面から競合しない。そこは既存のサービスが強い領域です。私たちはそこと戦いません
- お客様のサーバーに手を入れることを要求しない。プラグインの導入も、DNSの変更も、フォームの送信先の変更も求めません
- 複雑さを持ち込まない。確信度を精緻に合算するモデルや、AI生成文章の検知——既存の対策が長年苦労している領域には、手を出さない
最後の1つは、私たちが自分に言い聞かせ続けた戒めです。普通に、シンプルに考えるべき。凝った仕組みを思いついたときほど、それが本当に必要かを疑うようにしました。
「そもそも個人情報を送らない」という設計
AIに問い合わせ内容を判定させる、と聞いて引っかかった方がいるはずです。お客様の個人情報を、AIに渡すことになるのではないかと。
私たちも、そこで一度止まりました。認証や規格を取得すれば説明はつきます。ですがそれは「渡していますが、管理はしています」という説明にすぎません。私たちが選んだのは別の道です。
そもそも個人情報を送らない設計にする。
営業メールかどうかを見分けるのに、氏名や個人のメールアドレスは要りません。必要なのは組織の情報と、問い合わせの中身です。ならば、判定に要らない情報は最初から渡さない。そして保存するデータは暗号化し、私たち自身も中身を読めない形にしました。
「機微情報を消す」は、消しすぎると本物が壊れる
この設計で本当に難しかったのは、機微情報を検出して落とす部分です。健康状態や信条といったセンシティブな情報は、そもそも判定に要りません。ですから見つけたら落とす。ここまでは簡単です。問題は、検出器が本物の問い合わせに誤爆したときに何が起きるかでした。
機微情報の検出は、当てにいくほど誤検知します。そして誤検知した分だけ、本物の問い合わせから判定材料が削られていきます。守っているつもりで、原則1(本物を絶対に見失わない)を自分で崩すことになる。
そこで、感覚で決めるのをやめました。私たちが保有していた実際の問い合わせデータ5,797行を、抜き取りではなく全件流して、誤検知が何行出るかを数えました。出てきたのは、笑えない実例ばかりです。
| 誤検知の実例 | 何が起きていたか |
|---|---|
| 「ゲイ」が反応する | ホテル名や製品名の一部に含まれる2文字に反応していた。性的指向とは何の関係もない |
| 「GID」が反応する | 表計算ツールのURLパラメータに反応していた。共有リンクを貼っただけの問い合わせが該当してしまう |
| マイナンバーが反応する | 検査用の数字(チェックディジット)だけで判定すると、ランダムな12桁が約11回に1回、偶然一致します。桁数が合うだけの数字列は、ただの数字列です |
| 商品コードが反応する | 13桁の商品コードが、偶然チェック式を満たしていた。「式を満たす=その情報である」ではありません |
結果として、5,797行のうち誤検知は42行から10行に減りました。そして本物の問い合わせ本文がフィールドごと消えるような、ハードな誤検知はゼロです。
この検証で、機微情報のカテゴリを6種から5種に減らしました。減らしたのは、性的指向と思想信条の検出器です。全廃しました。守れている量より、誤検知で本物を壊す量のほうが多かったからです。
検出器を増やすほうが、説明としては立派に見えます。「6種類の機微情報に対応」と書けるからです。ですが実データで数えたら、その1種類は本物を削る側にしか効いていませんでした。数えなければ、私たちはたぶん6種類のまま「対応しています」と言い続けていたと思います。
この方針は、後に一部緩めています。問い合わせ本文しかAIに渡さない設計にすると、判定材料が足りず、本物の申込みまで一律で人の確認待ちに回ってしまうケースが出たためです。原則1(本物を絶対に見失わない)を守るために、判定に渡す項目の範囲を広げました。私たちは、訴求として耳ざわりのいいほうではなく、お客様の本物の相談が届くほうを取りました。保存時の暗号化は変えていません。いまも、私たち自身が中身を読むことはできません。
導入は、タグを1行
目的から逆算した結果、導入の形も決まりました。お客様のサイトに、スクリプトタグを1行追加するだけです。
この1行にこだわったのには理由があります。Web制作会社として、お客様のサイトに手を入れることのリスクを知っているからです。プラグインを1つ入れれば、それは将来の更新で壊れる可能性を1つ増やすということです。フォームの送信先を変えれば、それは障害点を1つ増やすということです。
途中、2つの実装方針を検討して、どちらも廃案にしました。CMSのプラグインとして提供する案と、メールの経路そのものを中継する案です。前者は導入のハードルとサイトへの介入が増える。後者は「私たち自身も中身を読めない」という訴求と構造的に矛盾する——中継するなら読めてしまうからです。
結果として、「暗号化を貫く」「フォームの種類を問わない」「お客様の負担はタグ1行だけ」の3つを同時に満たす道は1つしかないと分かりました。それが現在の形です。
成果:実証できたこと
実証できたことを、2段階に分けてお伝えします。1つは、人の目で全件を監査したサンプル検証(277件)。もう1つは、実際に動かしている環境での運用実績(3,502件)です。前者は精度を確かめるための検証、後者は「実際にどう効いているか」の記録です。性質が違うので、混ぜずに並べます。
①サンプル検証:277件を人の目で全数監査
判定の精度は、実データで検証しています。約89,000行から277件を抽出し、全件を人の目で監査しました。
| 検証項目 | 結果 |
|---|---|
| 本物を誤ってブロックした件数 | 0件。自動ブロックした22件を全数監査したところ、すべてテスト送信・不完全な送信・フォーム側の不備によるもの。真の本物をブロックした例はゼロ |
| 担当者の負荷削減率 | 26〜94%(フォームの性質により変動。営業メールの混入率が低いフォームでは削減幅も小さくなります) |
277件を全数監査して算出。本物の誤判定は0件。フォームの性質によって26〜94%と幅があります
出典:GrowGroupによるベンチマーク検証(2026年4月・約89,000行から277件を抽出し全件を人手で監査)。社名は非公開。数値はHajikが「営業」または「スパム」と判定し、担当者が確認しなくてよくなった件数の割合です。
原則1に照らして、いちばん大事な数字は「本物を誤ってブロックした件数が0件」です。負荷削減率が90%でも、本物を1件ブロックしていたら、この製品は失格でした。
②実運用:16サイト・3,502件の稼働実績
上の277件は、精度を確かめるために抜き取って人が監査したものです。ここからは、実際に動かしている環境の記録になります。自社および関係先の16サイトで、2026年5月13日から7月17日までの約2ヶ月に判定した3,502件です。
先にお断りしておきます。この集計からは、予約専用フォーム1サイトを除いています。予約フォームは問い合わせフォームと性質が違い、予約そのものが入ってくるので本物率が84%まで跳ね上がります。混ぜると、問い合わせフォームの実態が見えなくなる。だから外しました。除外した結果がこれです。
自社および関係先16サイトでの実運用(2026年5月13日〜7月17日)。営業2,456件のうち743件(全体の21.2%)は自動ブロック。予約専用フォームは集計から除外
出典:GrowGroupによるHajikの実運用データ(2026年5月13日〜7月17日・計3,502件・自社および関係先16サイト)。サイト名は非公開。予約専用フォームは問い合わせフォームと性質が異なるため、この集計から除いています。
営業が70.1%、本物は22.3%。そして営業のうち743件(全体の21.2%)は、人が見る前に自動でブロックしています。残りの264件(7.5%)は「営業の可能性あり」として、自動ブロックせずに人の確認に回しています。
この「自動で落とすもの」と「人に回すもの」の線引きが、原則1の実装そのものです。判定は、きれいに二極化しています。
- 本物と判定した782件は、確信度のスコアが全件8〜42の範囲に収まっていました。1件の例外もなく、低い側に固まっています
- 自動ブロックした743件は、スコアが96〜99だけ。下限が96です。それ未満は、1件も自動ブロックしていません
- 中間帯(60〜79)に入ったのは94件だけ。そしてそれらは自動ブロックの対象外です
つまりHajikは、「ほぼ確実に営業」と言えるものしか自動では落としていません。少しでも迷う帯域のものは、機械が白黒をつけずに人へ回します。「完璧に判定するSaaS」を諦めて「担当者の作業を減らすアシスタント」に書き直した、という前述の判断が、そのまま数字の形で出ています。
そして、この設計が効いているかどうかの手がかりが1つあります。自動ブロックした判定に対する「これは本物だった」という訂正は、0件です。一方で、「営業の可能性あり(要確認)」から「本物」への訂正は55件ありました。
この55件が、いちばん大事な数字だと思っています。もし迷ったものまで自動ブロックする作りにしていたら、この55件は本物なのに消えていました。迷ったら人に回す、という設計が、実際に本物を55件拾っているということです。
ただし、この「訂正0件」を精度の指標として読まないでください。訂正は、お客様が気づいて操作したものだけが記録されます。気づかれなかった誤りは、そもそも数に入りません。だから私たちはこれを「誤りがない証拠」とは呼びません。事実として言えるのは「自動ブロックに対する訂正は0件だった」という、それだけです。精度の裏取りは、上の277件の全数監査のほうが担っています。
そして実際の運用で、体感として変わったのは次の2つです。
- 営業メールがカットされるので、ノイズが入らない。フォームを開いたときに並んでいるのが、対応すべきものだけになりました
- コンバージョンが荒れない。数字が実感と合うようになりました。冒頭に挙げた「コンバージョンが誤発火する」という問題が、そのまま解けたことになります
なお、導入前後の削減時間は厳密には測っていません。測っていないものを数字で語ることはしません。実証できているのは上の検証結果と、この体感までです。
お使いのフォームに営業メールがどれくらい混ざっているかは、タグを1行入れるだけで分かります。
Hajikの無料トライアル
溜まるほど、日本語の営業メールに強くなる
営業メールは、届くたびに担当者の時間を奪っていきます。使えば使うほど溜まっていく、受け手にとっては価値のないものです。
ですが、私たちはこう考えました。この積み上がったものは、味方に変えられるのではないか。
日本語の営業メールには、型があります。「ご提案がございます」「SEO対策のご案内」「相互リンクのお願い」——手を変え品を変えているようで、実のところ言い回しの引き出しはそう多くありません。そして実データを見ると、ごく少数の企業が繰り返し送っています。私たちの実運用データでは、送信元の上位に立つ企業はいずれも9〜16件を送っており、1社が同じフォームに最大16件を送っていました。同じ型が、何度も繰り返し現れるということです。
ということは、営業メールが届けば届くほど、営業メールの型が集まるということです。集まれば集まるほど、次の1通を見分ける精度が上がる。攻撃されるほど強くなるという構造を、この領域では作れます。
ここで大事なのは、溜めているのは「営業メールの型」であって、お客様の問い合わせの中身ではないということです。前述のとおり、保存するデータは暗号化していて私たち自身も読めません。資産になるのは、営業を送ってくる側のパターンのほうです。
汎用のスパムフィルタが日本語を苦手とするのは、この蓄積が無いからです。日本語のB2B営業メールだけを、集め続けている——それがHajikの土台になります。
これは、使う側にとってこういう意味を持ちます。営業を送っているのはごく少数の企業で、同じ型が多くのフォームに繰り返し現れます。ひとりで対策していると、その型は必ず自分のところで初めて食らうことになります。Hajikを使っている間は、同じ型が先に他のフォームに届いた時点で、それは把握されている——これが、日本語の営業メールにだけ集中しているサービスを使う理由です。
なぜWeb制作会社がこれを作るのか
Hajikは、GrowGroupが自社の課題を解くために内製したツール群の1つです。会議・採用・提案・育成・アクセス解析——社内の業務を、ひとつずつ自分たちの手でDXしてきました。そのなかでHajikは、自社の困りごとから始まり、お客様に提供できる製品まで育ったものです。
この進め方には、私たちなりの型があります。自分たちの困りごとから始めて、外に出せる形まで持っていく。自分たちが毎日使って、痛みを知っていて、直したいところが分かっている。だから使えるものになります。
そしてHajikの設計判断は、どれもWeb制作の現場で培った勘所から出ています。「フォームは商売の入口だから閉ざしてはいけない」も、「お客様のサイトに手を入れるリスク」も、「コンバージョンが汚れると改善判断が狂う」も、サイトを作って運用してきたから見えたことです。
よくある質問
reCAPTCHAを入れているのに営業メールが届くのはなぜですか?
reCAPTCHAは「機械かどうか」を判定する仕組みだからです。営業メールは人間が書いて人間が送っているので、判定を通過します。これはreCAPTCHAの不具合ではなく、そもそも守備範囲が違うという話です。ボット対策と営業メール対策は、別の対策が必要になります。
Hajikを入れれば、既存のボット対策は外していいですか?
Hajikはボット対策も含めて単独で成立するよう設計していますが、既存の対策を外すことは推奨していません。私たちが検証してきたデータも、reCAPTCHA等が前段にある環境で取得したものです。併用のままご利用いただけます。
本物の問い合わせがブロックされることはありませんか?
そこを最優先で設計しています。「営業を見逃すのは○、本物をブロックするのは×」を第一原則にし、迷ったものは本物として扱います。277件の全数監査では、本物を誤ってブロックした例は0件でした。実運用でも、自動ブロックしているのは確信度スコアが96以上のものだけで、迷う帯域のものは人の確認に回しています。とはいえ「絶対に起きない」とは申しません。だからこそ、すべてを自動でブロックする作りにはしていません。
問い合わせの内容がAIに渡るのが不安です
判定に必要な範囲に絞ってお預かりしています。営業メールかどうかの判断に必要なのは、組織の情報と問い合わせの中身です。当初は本文以外の項目をAIに渡さない設計でしたが、それでは本物の申込みが一律で「要確認」に落ちてしまうため、「本物を絶対に見失わない」という第一原則を優先し、現在は判定に渡す範囲を広げています(経緯は本文「そもそも個人情報を送らない」の章に書きました)。保存するデータは暗号化しており、私たち自身も中身を読めません。
導入にサイトの改修は必要ですか?
スクリプトタグを1行追加するだけです。プラグインの導入も、DNSの変更も、フォームの送信先の変更も必要ありません。お使いのフォームの種類も問いません。
WordPressのお問い合わせフォーム(Contact Form 7など)でも使えますか?
ご利用いただけます。スクリプトタグを1行追加するだけで、プラグインの導入もフォームの送信先の変更も必要ありません。
うちのようなフォームでも効果はありますか?
効くかどうかは、実際に測ってみるのが確実です。フォームの性質によって、営業メールの混入率は1割から7割超まで大きく違います。タグを1行貼れば、御社のフォームに何%混ざっているかが実データで出ます。
海外製のスパムフィルタとは何が違うのですか?
日本語の営業メールに特化している点です。日本語のビジネスメールには独特の型があり、海外製の汎用フィルタはそもそも学習してきた対象が違うため、日本語の営業メールの型は学習の対象になりにくいと考えています。悪いのではなく、守備範囲の話です。
同じ会社から何度も営業が来るのですが、まとめてブロックできませんか?
あえてやっていません。同じ会社からのメールでも、宛先や状況によって営業にも本物にもなるからです(原則4)。企業単位で永久にブロックすると、いつか本物の相談を弾きます。私たちはその権利を持たない、というのが方針です。
なぜ「営業メールを100%ブロックします」と言わないのですか?
言えないからです。そして100%を目指すと、本物をブロックする事故が起きます。私たちが約束できるのは「本物を守ること」であって、「営業メールを絶滅させること」ではありません。この2つは両立しません。どちらを取るかを決めるのが設計です。
まとめ
問い合わせフォームのスパム対策を考えるときは、まず原因を切り分けてください。
機械が送るスパムは、既存の対策で止まります。止まらないのは、人が書いた営業メールです。これは量の問題ではなく判断の問題なので、対策の種類が違います。ここを切り分けないまま「もっと強いボット対策」を探しても、営業メールは減りません。
そして営業メールの被害は、仕分けの手間だけではありません。コンバージョンが誤発火し、広告の最適化とサイト改善の判断が狂います。しかも、狂ったことに気づけません。フォームを閉ざしたくなる前に、手を打つ価値があります。
Hajik(ハジク)は、無料でお試しいただけます。スクリプトタグを1行追加するだけで、お使いのフォームに営業メールがどれくらい混ざっているかが分かります。
Hajikの無料トライアルを申し込む
フォーム以外にも、社内に「判断は要らないのに時間だけかかる作業」が溜まっている——という方へ。私たちが自社でやってきた進め方を、御社の業務に合わせてご提案します。ご相談・お見積りはこちら
※reCAPTCHAはGoogle LLCの商標です。本記事の記述は、当社が取得したデータおよび各サービスの公開情報に基づく当社の見解です。






