営業メール自動検知を作った理由 -- 問い合わせフォーム営業をブロックせず分類する設計

最終更新日: 2026-10-15

営業メール自動検知を作った理由は、正当な相談を落とさず、受け付けた回答の確認と集計を整理したかったからです。入口で削除するのではなく、保存後に分類し、人が直せる設計にしました。以下の「10件中8件」の話は開発のきっかけとなった過去の経験であり、すべての問い合わせフォームの営業割合を示す統計ではありません。

初期の3分類から、現在は正当・営業・要確認・ジャンクの4分類です。全プランで使える通常フォーム向けの機能ですが、有効化後の新規回答が対象で、有料フォームは対象外です。分類を入れただけで有効商談数やCVRが確定するわけではありません。

対象となる新規フォームは既定で営業メール検知が有効です。対象の自由入力欄が必要で、選択式のみ・有料フォームは分類対象外です。実際の設定を確認し、不要なら無効にします。既存フォームの設定は引き継ぎ、旧来の未決定フォームは公開前に選択が必要な場合があります。公開時の確認表では、分類の有効状態と外部AIによる処理を確認してください。

先に結論

FORMLOVAが営業メール自動検知を作った理由は、問い合わせフォームの価値が「送信された瞬間」ではなく、その後の判断で決まるからです。

フォームの役割は、回答を保存するだけではありません。問い合わせを担当者へ渡す。広告レポートの数字にする。営業やサポートのワークフローに流す。次のメールを送る。こうした後工程の入口になります。

そこに営業メールが混ざると、後ろの判断が濁ります。

営業メール自動検知は、営業メールを消すための機能ではありません。

本物の問い合わせを守るために、営業メールを見分ける機能です。

きっかけは、10件中8件が営業だった日でした

最初にこの機能を作ろうと思ったのは、クライアントの問い合わせフォーム運用を見ていたときです。

広告経由の問い合わせを分析するために回答一覧を開くと、10件のうち8件が営業メールでした。SEO対策の提案、広告運用の提案、人材紹介の提案、制作会社からの提案。文面は丁寧です。人が書いています。スパムボットのような雑な文字列ではありません。

でも、そのフォームの目的から見ると、ほとんどは問い合わせではありませんでした。

やることは単純です。1件ずつ読みます。これは営業、これは本物、これは判断保留。当時は人が本文を確認して営業を除外し、残りを集計していました。単純なAI分類後の残件数を成果と扱うという意味ではありません。最後にレポートへ反映します。

単純ですが、毎週やると重いです。

丁寧にやれば時間がかかります。雑にやれば数字が汚れます。どちらを選んでも、フォーム運用としては負けています。ここで初めて、これは「フォームの外で人が頑張ればよい作業」ではなく、フォームサービス側が扱うべき課題だと思いました。

手で除外する作業は、フォームの外側で起きているように見えます

営業メールの除外は、ぱっと見るとフォームサービスの外側の作業に見えます。

回答が届いた後に、人が一覧を見て判断する。CSVを出してから削る。広告レポートを作る前に営業を除く。Slackに流れてきた通知を見て「また営業か」と思う。

でも、それは本当にフォームの外側の問題でしょうか。

私は違うと思っています。

フォームが業務の入口であるなら、その入口で入ってきた情報の意味を、最低限扱える必要があります。問い合わせなのか。営業なのか。判断が必要なのか。ここを一切区別せずに後工程へ流すと、すべての後工程が少しずつ鈍ります。

たとえば広告運用では、営業メールを含めた問い合わせ件数でCVRを見てしまうと、実際より良く見えることがあります。逆に、営業メール対応に時間を取られて本物の問い合わせへの初動が遅れると、数字以上に機会損失が出ます。

セミナーや資料請求でも同じです。

営業メールが混ざっているだけで、担当者の確認時間が増えます。返信対象の優先順位が曖昧になります。通知の信頼度が落ちます。最初は小さなノイズでも、毎週積み重なると、チームがフォームを見る習慣そのものを失っていきます。

だから、営業メールは単なる迷惑メールではありません。フォーム運用の信頼度を下げるノイズです。

なぜブロックではなく分類なのか

営業メール対策と聞くと、まず「止める」ことを考えます。

reCAPTCHAやTurnstileのようなBot対策。営業お断り文言。送信前の同意チェック。営業窓口の分離。こうした入口対策は有効です。実際、問い合わせフォームの営業メール対策 でも、入口で減らす方法をかなり詳しく書いています。

ただし、入口対策には限界があります。

人が手で送ってくる営業メールは、Bot対策だけでは止まりません。フォーム営業の代行サービスは、相手のサイトを見て、文脈に合わせて文章を書き、自然な問い合わせの形で送ります。完全に拒否しようとすると、本物の問い合わせまで巻き込むリスクが出ます。

ここが大事です。

問い合わせフォームにおいて、最も避けたい失敗は「営業メールが1件届くこと」ではありません。最も避けたいのは、本物の問い合わせを営業扱いして見落とすことです。

本物の問い合わせを1件落とすと、売上だけでなく信頼も落とします。採用応募なら候補者との接点を失います。パートナー相談なら、将来の機会を失います。問い合わせフォームは、外から来た人が初めて手を伸ばす場所です。そこを強く締めすぎると、守りたいものまで閉じてしまいます。

だからFORMLOVAでは、営業メールを入口で消すより、届いた後に分類する設計を選びました。

送信は受け取る。意味を見分ける。必要なら除外する。迷うものは人が見る。

この順番の方が、実務では安全だと考えています。

設計の中心は、迷ったら正当です

営業メール自動検知で一番大事な設計は、モデルの種類ではありません。

判定に迷ったとき、どちらへ倒すかです。

FORMLOVAでは、迷ったら 正当 に寄せます。営業っぽい言葉が入っていても、フォームの目的に沿っている可能性があれば、いきなり営業として扱いません。営業の可能性がありつつも断定しにくいものは 要確認 に置きます。

この方針は、かなり意識して入れています。

たとえば「御社サービスとの協業を相談したいです」という文面は、営業にも見えます。ですが、事業提携の相談かもしれません。「代理店として紹介できます」という文面も、売り込みかもしれませんが、こちらの事業に合う可能性もあります。

こうしたグレーゾーンをすべて営業として処理すると、見た目の精度は上がるかもしれません。でも運用上は危険です。問い合わせフォームでは、営業を見逃すコストより、本物を弾くコストの方が大きいからです。

AIは、最初の分類を提案します。

人は、その分類を見て直せます。

この分業が崩れると、AI機能は便利さより怖さが前に出ます。だからFORMLOVAでは、AIを最終判断者にしません。AIは下書きの判断を出す。人が必要なときに上書きする。手動で直したラベルは、自動分類で勝手に戻さない。この順番を守っています。

この考え方が自分の受付に合うか確かめる

以下は試すための依頼文の例です。この記事で実行した結果ではありません。既存の公開フォームを変更する前に、検証用の下書きで確かめます。

問い合わせフォームの検証用下書きを作り、相談の種類と本文を聞いてください。正当な相談、明確な売り込み、曖昧な提携、無関係な投稿という仮例を使い、人が確認すべき点と想定ラベルの表を作ってください。これは分類結果の実測ではなく検証計画として示し、公開・送信・実回答変更はしません。未分類と誤判定を誰が確認するかも未決事項として残してください。

出力されたら、次を確認してください。

• フォームの目的に合う相談を、営業らしい言葉だけで切り捨てていないか。
• 要確認・未分類に加え、除外した営業/ジャンクの点検も計画にあるか。
• 仮例、AIの提案、人の確認済み判断が区別できるか。

現在の4ラベルと、曖昧さを残す理由

初期は正当・営業・要確認の3分類で説明していました。現在は意味不明・リンクのみ等の投稿を分けるジャンクが加わっています。

未分類には処理待ちや失敗も含まれます。営業除外の条件はsalesとjunkを除き、suspiciousと未分類は残します。この残りを自動で「本物の問い合わせ」や「有効商談」と数えないでください。

曖昧な内容を人が見られる状態に残すことと、除外したラベルを点検することは両方必要です。スコアはモデルの確信度の目安で、正しさを保証しません。

AIを信用しすぎないために入れた制約

営業メール自動検知はAI機能ですが、AIに任せきる設計にはしていません。

実装上も、いくつかの制約を置いています。

• 回答送信後に非同期で分類します。分類が遅れても、フォーム送信自体は壊しません。
• フォーム単位でON/OFFできます。すべてのフォームに強制しません。
• 対象の新規フォームは既定ONで、不要なら無効にできます。旧来の未決定フォームでは公開前に選択を確認します。
• 手動でラベルを直した回答は、自動分類で勝手に上書きしません。
• 選択式だけのフォームは分類対象外です。
• Stripe Connectを使う有料フォームでは分類を実行しません。

ここで言いたいのは、AIを使うことそのものより、AIをどこまで信じるかの線引きです。

AIが便利になるほど、プロダクト側は「どこで止めるか」を決める必要があります。FORMLOVAでは、営業メール検知を自動化しつつ、送信、閲覧、手動修正、分析除外のそれぞれで、人が介入できる余地を残しています。

この余地は、弱さではありません。

実務で安心して使うための設計です。

全プランで提供する理由

営業メール自動検知は、上位プランだけの機能にはしませんでした。

理由は単純です。営業メールに困るのは、大きな会社だけではないからです。

むしろ、小さなチームや個人事業の方が、営業メールの確認に割ける時間は少ないです。問い合わせが10件しかない中で、営業メールが8件混ざると、それだけで判断が重くなります。担当者が1人なら、毎回の確認がそのまま負担になります。

フォーム運用において、営業メールを見分けられることは贅沢な分析機能ではありません。

本物の問い合わせを見つけるための基本機能です。

もちろん、サーバー側で分類する以上、FORMLOVA側には処理コストが発生します。それでも、ここは全プラン共通で吸収するべきだと判断しました。フォームを作るだけなら無料でできるサービスは多いです。でも、公開後に届く回答をどう扱うかまで見るなら、営業メールの分類は土台になります。

FORMLOVAが作りたいのは、入力欄を並べるだけのサービスではありません。

フォームの後ろにある運用を、少しずつ軽くするサービスです。

MCPで効くのは、分類された後です

読み取りで分類と対象を確かめてから、必要な引き継ぎを実行します。MCP上のメールはマスクされるため、その表示を生メールとして手動照合・宛先指定に使いません。権限のある正式なCSV、回答者宛て操作、サーバー側連携等の実経路を使います。分類とワークフローの保存済み設定は別で、依頼文だけで継続実行が始まるわけではありません。

営業メール自動検知は、それ単体でも便利です。

ただ、FORMLOVAにとって本当に重要なのは、分類された回答をMCP経由で後工程へ渡せることです。

たとえば、チャットで次のように依頼できます。

営業メールを除いて、今月の問い合わせ傾向を分析して。

要確認の回答だけ一覧にして、対応メモを付けたい。

この回答は営業ではなく正当な問い合わせに直して。

これらは、単にラベルを表示するだけではできません。回答データ、分類ラベル、分析、手動修正、ワークフローが同じ操作面にあるから成立します。

さらに先では、正当 の中をもっと細かく見ることもできます。

導入検討。料金相談。サポート依頼。パートナー相談。採用応募。こうした意図を分類できるようになると、フォームはただの入力画面ではなく、業務の分岐点になります。

MCPクライアント上でFORMLOVAと他のサービスがつながれば、次のような流れも自然になります。

• 導入検討の問い合わせだけSlackに通知する
• サポート依頼だけヘルプデスクに送る
• パートナー相談だけ担当者に転送する
• 営業メールは分析から外す

この話は フォーム運用にMCPレイヤーが必要な理由 でも詳しく書いています。

営業メール自動検知は、単発の便利機能ではありません。フォーム回答を意味で分け、その意味を次の業務に渡すための最初の実例です。

入口対策と矛盾しません

ここまで読むと、「では営業お断り文言やBot対策はいらないのか」と思うかもしれません。

答えは逆です。

入口対策は必要です。営業お断り文言、営業窓口の分離、Turnstile、ハニーポット、同意チェック。これらで減らせるものは、入口で減らした方がいいです。そもそも届かない方が、確認コストは下がります。

Bot対策を具体化するときは、問い合わせフォームでハニーポットを安全に使う設計も確認してください。

ただ、それでも残るものがあります。

人が自然な文章で送ってくる営業メールです。サイトの文脈を読んで、フォームの目的に寄せて、丁寧に書かれた提案です。これは入口対策だけでは完全に止まりません。

だから、入口で減らす対策と、届いた後に分類する対策はセットです。

入口で減らす。届いた後で分ける。分析や通知から営業を外す。迷うものは人が見る。

この4段構えが、今の問い合わせフォーム営業には現実的だと思っています。

使う前に決めておくとよいこと

営業メール自動検知をONにする前に、チームで決めておくとよいことがあります。

まず、要確認 を誰が見るかです。

毎日見る必要があるのか。週に数回でいいのか。問い合わせ数が少ないなら、週1回でも十分かもしれません。確認期限と担当を決め、要確認・未分類に加えて除外した営業・ジャンクも抽出して点検してください。

次に、広告やSEOのレポートで営業メールを除外するかです。

問い合わせ件数を「総送信数」として見る場面もあります。一方で、商談や相談の成果を見るなら、営業メールは除外した方が自然です。目的によって、含める数字と除く数字を分けてください。

最後に、手動修正の基準です。

パートナー相談は正当にするのか。取材依頼はどう扱うのか。採用支援の提案は営業にするのか。チームごとに境界は違います。FORMLOVAのラベルは、最初の判断です。自社の運用に合わせて直して構いません。

この柔軟さがあるから、AI分類を日常業務に入れやすくなります。

よくある不安

AIが本物の問い合わせを営業扱いしませんか

可能性はゼロではありません。

だからFORMLOVAでは、迷ったら正当に寄せる設計にしています。営業の可能性があるが断定しにくいものは 要確認 にし、人が見て直せるようにしています。手動で直したラベルをAIが勝手に戻さないことも、同じ理由です。

営業メールを完全に止められますか

止める機能ではありません。

営業メール自動検知は、届いた後に見分ける機能です。入口で減らすには、営業お断り文言、営業窓口の分離、Bot対策、同意チェックなどを組み合わせてください。そのうえで残る営業メールを分類します。

分類結果は分析に使えますか

使えます。

営業ラベルの回答を除外して分析したり、回答一覧で絞り込んだりできます。チャットで「営業メールを除いて分析して」と頼めるのが、FORMLOVAらしい使い方です。詳しい手順は 営業メール自動検知の使い方 にまとめています。

なぜ正当な回答の中身まで分類しないのですか

将来的には、導入検討、料金相談、サポート依頼、パートナー相談のようなインテント分類へ広げたいと考えています。

ただ、最初に解くべきだったのは、営業メールによって本物の問い合わせと分析が汚れる問題でした。まず営業ノイズを分ける。その次に、正当な問い合わせの中身を分ける。この順番が自然です。

そのまま使える関連Workflow

営業メール検知は、分類結果が次の導線に反映されてこそ意味があります。問い合わせ自動応答+エスカレーション を使うと、正規の問い合わせを止めずに、対応が必要なものを上げられます。

日々の運用では 問い合わせ担当者割り当て と 営業メール除外ワークフロー を組み合わせると、AI分類を見えないラベルで終わらせず、担当・除外・確認の判断につなげられます。

最後に

自分のフォームで始めるなら、上の検証計画で対象と確認担当を決めます。本文の体験談は過去の記録で、今回の改稿で精度やCVR改善を再計測したものではありません。

問い合わせフォームは、ただの入力欄ではありません。

人と組織の最初の接点です。そこに営業メールが混ざると、確認、返信、分析、通知、レポートのすべてが少しずつ重くなります。

FORMLOVAが営業メール自動検知でやりたかったのは、その重さをなくすことです。ただし、本物の問い合わせを落としてまで自動化したいわけではありません。

だから、ブロックではなく分類にしました。

だから、曖昧な回答を安易に除外せず、人が確認できるようにしました。

だから、手動修正を優先しました。

AIは提案します。人が決めます。フォームは、その判断を次の業務へ渡します。

この小さな分類が、フォーム運用全体を少し静かにできると考えています。

次に読むなら、実際の設定手順は 営業メール自動検知の使い方、入口で減らす対策は 問い合わせフォームの営業メール対策 を見てください。

関連記事:

• 営業メール自動検知の使い方 -- 有効化、ラベル確認、分析除外まで
• 問い合わせフォームの営業メール対策 -- 営業お断り文言やBot対策を含む入口対策
• 営業メールをAIが自動で検知します -- 機能リリース告知
• 問い合わせフォーム運用まとめ -- 対応漏れ、振り分け、営業メール分類まで含めた親ページ
• MCPフォームサービスまとめ -- 作成後の運用までAIで進める全体像
• フォーム運用にMCPレイヤーが必要な理由 -- 分類後の運用設計

執筆・確認情報

この記事はFORMLOVAの自社ブログ記事です。筆者はFORMLOVAの開発者です。公開時点の公式情報を確認して執筆しています。料金、機能、上限値などの条件は変更される可能性があるため、最新情報は各サービスの公式ページで確認してください。個人情報、採用、法務、医療、金融に関わるフォーム運用は、各社の規程や専門家の確認に合わせてください。