コンセプト

なぜ営業メール自動検知を作ったのか -- 10件中8件が営業だった現場と、AIに任せきらない設計

なぜ営業メール自動検知を作ったのか -- 10件中8件が営業だった現場と、AIに任せきらない設計

最終更新日: 2026-04-17

この記事はFORMLOVAの営業メール自動検知を作った背景と設計思想を、開発チームの視点でまとめたものです。機能の告知は 営業メールをAIが自動で検知します -- 全プラン無料で提供開始、具体的な使い方は 営業メール自動検知の使い方 を参照してください。

10件中8件が営業メールだった

数字を先に書くと、それは「10件中8件が営業メール」という日でした。

クライアントの問い合わせフォーム運用を手伝っていたある時期のことです。広告からの問い合わせを分析するために一覧を開いたら、見覚えのあるテンプレ文面、見覚えのないお名前、見覚えのない会社名が並んでいました。目視で1件ずつラベルを付け、営業を除いて、残った2件で広告の費用対効果を計算して、報告書を書きました。

この作業は、広告費が走っている限り毎週発生します。しかも、正確にやれば時間がかかり、雑にやれば数字が嘘をつく。どちらを選んでも割に合わないな、とはっきり意識したのは、このときでした。


フォーム運用で「営業を手で弾く」という前提

Gemini_Generated_Image_u9iyf3u9iyf3u9iy.webp

既存のフォームサービスには、CAPTCHAなどのBOT対策はあります。人が書いた営業メールは違います。人間が手で打って送ってきている以上、「送信をブロックする」ことはそもそも目的にできません。送信は通す、でも届いたあとでどう扱うかは別問題。その「届いたあと」を、現場は手作業でさばいていました。

話を聞いていくと、丁寧な人は1件ずつ目で見て営業を除外し、雑な人は営業込みの数字をそのまま報告していました。前者は時間が溶け、後者は意思決定の根拠が汚れる。どちらの道にも勝ち筋が見えませんでした。

CVRが狂うと、次にやる判断が狂います。広告のチャネル配分、クリエイティブの評価、そして「このキャンペーンを続けるか止めるか」。フォームの受け皿に営業が2割か8割か混ざっているだけで、それらすべての判断材料が信頼できなくなります。これはフォームの外の話ではありません。フォームという受け皿が、結果をそのまま運用判断に流し込む仕事をしている以上、フォーム側で解くべき課題だと考えました。


「フォームサービス側でやる」ことの意味

営業を除外する仕事が手動で行われているなら、それをツール側が引き受けられないか。私たちが調べた限り、AIで回答内容を分類しているフォームサービスは存在しません。BOT対策と違って、明らかに業界の空白地帯でした。

空白だったのには理由があります。LLMのコストと精度が、ちょっと前まで「フォームサービスが全プラン無料で吸収できる」水準に届いていませんでした。でもこの1年ほどで、軽量モデルのコストと品質が一気に実用に入ってきた。つまり、作れる下地がそろったのは今で、誰も作っていないのも今。拡張軸として最初から視界には入れていた機能を、このタイミングで出すことにしました。

技術的には、1回答あたり約0.03円です。Free プランで毎月上限いっぱいに回答が来ても、コストは FORMLOVA 側で十分吸収できます。プランの課金軸にしなかったのは、これを「上位プランの特権」にしたくなかったからです。営業を見分けることは、今のフォーム運用者にとって 標準装備 であるべきだと考えています。


設計の中心にある「迷ったらlegitimate」

Gemini_Generated_Image_7ci4yt7ci4yt7ci4.webp

設計で一番時間をかけたのは、アルゴリズムそのものよりも、判定のデフォルトをどちらに置くかという判断でした。

AIの精度を信用しきるなら「分類は機械に任せ、営業は自動で非表示にする」という設計ができます。私はその設計を却下しました。理由は単純で、正当な問い合わせを営業として弾いてしまうことだけは絶対にしたくなかったからです。問い合わせを1件落とすことは、信頼を1件落とすことと同じ重さを持ちます。営業メールの混入で数字が狂うのと、正当な問い合わせを見落とすのと、どちらも嫌だけれど、後者は取り返しがつかない。

そこで、プロンプトの内部ルールを「迷ったら legitimate」に寄せました。微妙な判断は正当として扱い、営業として弾かない。そのかわり、スコア(0〜100)を併記して、ユーザーが自分の目で見たときに疑いを持てる材料を残しました。判定は機械、最終判断は人間という分業です。

この方針は、実際のプロンプトを何度も書き直す中で定着しました。初版は3行の単純な判定基準で、確度の高いものは当てられましたがグレーゾーンで暴走気味でした。改善版では判定手順を3ステップに分け、6パターンの正当例、5パターンの営業例、厳しめのsuspicious条件、そして3つのfew-shotサンプルを入れて、最後に「迷ったら legitimate として扱う」を明文化しました。精度は上がりましたが、それ以上に、人間が上書きできる設計になったことが重要でした。


LLMを信用しきらないという設計

付随する設計判断をいくつか書いておきます。

  • 分類結果はラベルだけでなく、常にスコアを併記する。ユーザーに「これはどのくらい怪しいと見ているか」を渡すため
  • 分類は回答送信後に非同期で走り、分類が失敗・遅延してもフォーム送信自体は絶対に壊さない
  • 手動でラベルを直したら、それ以降の自動分類では絶対に上書きしない(spam_label_source = manual)
  • 有料イベントフォーム(Stripe Connect利用)では分類を実行しない。参加費を払って営業を送る人は極めて稀なため
  • テキスト入力のないフォーム(選択式のみなど)では実行しない。そもそも営業文が入る余地がない

これらはどれも、AI側を過信しない、という同じ方針から出ています。AIは提案、人間は決定。AIが強力になるほど、この分業ははっきりさせた方がよいと考えています。


未来のビジョン

Gemini_Generated_Image_4gpptk4gpptk4gpp.webp

今回のリリースは3段階(legitimate / sales / suspicious)ですが、同じ仕組みは応用できます。正当な回答の中でも、導入検討、情報収集、サポート依頼、パートナーシップ相談のようなインテント分類が自然な拡張になります。

ここからが、単独のフォームサービスでは実現しにくい話です。FORMLOVA は MCP サーバーとして外から操作できるフォーム基盤です。つまり、MCP クライアント(Claude や ChatGPT など)を介して、FORMLOVA のMCPと他サービスのMCPを組み合わせる ことができます。

  • 「導入検討」のラベルが付いた回答を、営業チームのSlackに自動通知する
  • 「情報収集」のラベルが付いた回答を、CRMに追加するだけ
  • 「サポート依頼」はヘルプデスクにチケット化する

これらを、チャットでの一言でユーザー自身が組み立てられます。この分岐構造はフォームサービス単体では作れません。「フォームを受ける」+「意味を分類する」+「外部に流す」の3段を、ユーザー環境の中で一気通貫にできるからこそ実現する体験です。

今回のアップデートは、この方向に歩み出した最初の一歩という位置づけです。


最後に

フォームは、人と組織のあいだに立つ受け皿です。受け皿の精度が低いと、その先にある判断もすべて精度が落ちます。逆に言えば、受け皿の側で一手入れるだけで、その先の意思決定、レポーティング、業務の全部が軽くなります。

AIに任せる部分と、人間が決める部分。コストを吸収する側と、データを預かる側。自動と手動。グレーゾーンと確信と。これらの境界をどこに引くかで、プロダクトの立ち方がずいぶん変わると思っています。

今回はその境界を、「AIは提案、人間は決定」「迷ったらlegitimate」「全プラン無料」に置きました。ここから先はユーザーの使い方を見ながら、インテント分類のような次の段に進みます。

関連記事:

最終検証日:

この記事をシェア

Written by

@Lovanaut
@Lovanaut

サポラバ、Lovai、モールラバ、FORMLOVAの開発者。「ラバ = ラブ」の想いで、優しいサービスを作り続けています。

同じカテゴリの記事