最終更新日: 2026-04-17
この記事はFORMLOVAの営業メール自動検知機能の使い方ガイドです。機能そのものの告知は 営業メールをAIが自動で検知します -- 全プラン無料で提供開始、設計の背景は なぜ営業メール自動検知を作ったのか を参照してください。
営業メール自動検知は、フォームに届いた回答を legitimate(正当) / sales(営業) / suspicious(判別困難) の3段階でAIが自動ラベル付けする機能です。この記事では有効化からダッシュボードの見方、分析での除外、ワークフローとの組み合わせまで、日々の運用で使う操作を一通り解説します。
| セクション | 内容 |
|---|---|
| 1. 有効化 | 新規フォーム / 既存フォームで営業メール検知をONにする |
| 2. ダッシュボード | ラベル・スコアの見方、フィルタ、ソート |
| 3. 手動修正 | 誤判定をユーザーが直す、監査ログ |
| 4. 分析での除外 | チャット、MCPツール、エクスポートでの除外 |
| 5. ワークフロー連携 | 営業ラベルを条件にしたアクション自動化 |
| 6. 運用のコツ | フィールド設計、精度のモニタリング |
| 7. トラブルシュート | 分類されない、誤判定が多い、など |
1. 営業メール検知を有効にする
新しくフォームを公開するとき
テキスト入力フィールド(短文、長文、メール、URL、電話番号)を含むフォームを公開するとき、FORMLOVAのMCPサーバーが publish_form のチェックリストで営業メール検知の有効/不要を必ず聞いてきます。
チャットへの入力例:
このフォームを公開して。
MCPサーバーは重複回答防止、プライバシーポリシー、サンクスページなどと並んで「営業メール検知を有効にしますか？」を確認します。「有効にして」と答えれば forms.spam_filter_enabled = true が記録され、以降の回答は自動分類対象になります。
この確認はサーバー側チェックリストとして強制されているため、確認を飛ばして公開することはできません。フォームの用途上営業混入がありえないと判断した場合は「不要」と答えてください。
すでに公開中のフォームで後から有効にする
既存フォームでも、チャットから切り替えられます。
チャットへの入力例:
問い合わせフォームの営業メール検知をONにして。
有効にした時点以降の新しい回答が分類対象になります。過去に送信済みの回答は自動では分類されません(これはコスト・プライバシー両面での設計判断です)。
管理画面(/ark/forms/{formId}/settings)からも同じ設定を切り替えられます。
検知対象にならないフォーム
以下のフォームでは分類を実行しません。
- テキスト入力フィールドを一切含まないフォーム(選択式のみなど)
- Stripe Connect で参加費を受け取る有料イベントフォーム
前者はそもそも営業メッセージが入り込む余地がないため、後者は参加費を払ってまで営業送信する人が極めて少ないため、精度とコストの両面から対象外としています。
2. ダッシュボードで分類結果を確認する
回答一覧
管理画面の回答一覧(/ark/forms/{formId}/responses)には、各回答の右側に以下が表示されます。
- ラベル:
legitimate/sales/suspicious - スコア: 0〜100(100に近いほど営業の確信度が高い)
- 分類ソース:
auto(AI自動) またはmanual(ユーザー修正)
営業ラベルの回答は視覚的に少し淡く表示されます。存在は見えるが手を動かす優先度は低い、という運用が自然になるようにしています。
フィルタ
回答一覧上部のフィルタで、ラベル別に絞り込みができます。
- 「営業のみ」: スパム扱いの回答だけを確認
- 「判別困難のみ」: グレーゾーンだけを見て、手動ラベル付けをする運用
- 「営業を除く」: 正当な問い合わせだけを一覧で見る
ソート
スコアの昇順/降順でもソートできます。suspicious を多く抱えているときにスコア降順で並べると、「より営業っぽい順」で確認できます。
3. 手動でラベルを修正する
AIの判定は完璧ではありません。正当な問い合わせを営業と判定する、その逆もあります。誤判定を見つけたら手動で修正してください。
修正の手順
- 回答詳細画面を開く
- ラベル選択プルダウンから正しいラベルを選ぶ
- 保存
修正すると spam_label_source が manual になります。以降、自動分類の再実行でこの回答のラベルが上書きされることはありません。AIは提案、最終判断は人間、という方針です。
監査ログ
ラベル変更は audit_logs に記録されます。誰がいつどの回答をどのラベルに変えたかを追跡できます。チーム運用時や、基準を揃えるためのレビューで役立ちます。
4. 分析から営業メールを除外する
チャットで除外する
チャットへの入力例:
今月のCVRを営業メールを除いて出して。 先週の問い合わせフォームの分析、営業を省いて。
「営業を除いて」「営業を抜いて」「sales を除いて」など、自然な表現でMCPサーバーが意図を汲み取ります。内部的には分析クエリに exclude_sales = true が渡され、sales ラベルの回答を除いた集計が返ります。
MCPツール経由で除外する
get_responses と export_responses では exclude_sales パラメータを直接渡せます。
{
"form_id": "xxxxx",
"exclude_sales": true
}
この指定で、取得結果から sales ラベルの回答が除外されます。suspicious は残るので、判別困難な回答を見落とすことはありません。
エクスポートでの除外
CSV/Excel/JSONエクスポート時にも exclude_sales を指定できます。広告効果のレポートを顧客に出すときなどに、営業混入で数字が狂うのを防げます。
5. ワークフローと組み合わせる
分類結果はワークフローのトリガー条件として使えます。
例1: 正当な問い合わせだけSlack通知
「回答があったらSlack通知」のワークフローに、「営業は除外」の条件を加えておくと、Slackに流れるのは正当な問い合わせだけになります。チームの集中を守る効果が大きい組み合わせです。
チャットへの入力例:
問い合わせフォームの回答をSlackに通知して。ただし営業メールは除いて。
例2: 営業ラベルだけに自動返信
営業メールと判定された回答に、定型の「対応しかねます」メッセージを自動返信する運用も可能です。ただしこれは 営業側の精度を100%信頼できるとき にだけ使ってください。正当な問い合わせを営業扱いで自動返信すると、失礼になります。
チャットへの入力例:
営業ラベルの回答にだけ、お断りの自動返信を送って。
不安があるなら、まずは suspicious と sales に対して手動でラベル確認してから返信する運用をおすすめします。
例3: HubSpotに正当な回答だけ登録
MCPクライアントがHubSpot MCPサーバーに接続されていれば、「営業を除いてHubSpotに登録」という分岐も一言で組めます。
チャットへの入力例:
問い合わせフォームの回答をHubSpotのコンタクトに追加して。営業は除いて。
6. 運用のコツ
フィールド設計で誤判定を減らす
フォームのフィールド名やラベルが曖昧だと、AIが回答の意図を読み取りにくくなります。
- 良い例: 「ご相談内容」「お問い合わせの目的」
- 曖昧な例: 「メッセージ」「内容」
フィールド名が明確だと、AIは「何のための回答か」を踏まえた判定ができます。既存フォームで誤判定が目立つ場合、フィールド名を見直すだけで改善することがあります。
最初の1〜2週間は手動修正を多めに
リリース直後は、誤判定を見つけたら積極的に手動で修正してください。修正は監査ログに残るので、どんなパターンで誤判定が起きているかを振り返れます。
スコアの分布を時々見る
多くの回答が suspicious(スコア 40〜60)に偏っている場合、フォームの性質上グレーゾーンが多いということです。そのフォームでは「判別困難のみ」でフィルタして定期確認する運用にすると、見落としが減ります。
7. トラブルシューティング
ラベルがついていない回答がある
- テキスト入力フィールドを含まないフォームでは分類を実行しません
- Stripe Connect利用の有料フォームでは分類を実行しません
- 機能有効化前に送信された回答には遡って分類しません
- ごくまれに分類処理がタイムアウトすると
nullラベルのまま保管されます(フォーム送信は壊しません)
上記のいずれにも当てはまらず、かつ forms.spam_filter_enabled = true なのに分類されない場合は、チャットから管理者に報告してください。
正当な問い合わせが sales と判定される
プロンプトは「迷ったら legitimate」という方針で組んでいますが、語彙や文面によっては誤判定することがあります。手動で修正してください。手動修正は今後のAI判定で上書きされません。
同様のパターンが多い場合は、フォームのフィールド設計(6. を参照)を見直すと改善することがあります。
営業が legitimate と判定される
こちらも「迷ったら legitimate」方針ゆえに、微妙な営業は正当扱いになることがあります。手動で sales に修正してください。suspicious に一度寄せて、後でまとめて確認するのもおすすめです。
スコアがすべて極端(0か100)
文面が非常に明確(完全に正当な質問、または完全に定型営業)の場合、スコアは両端に寄ります。これは仕様で、問題ではありません。
よくある質問
過去の回答にも遡って分類できますか？
現在は自動では遡りません。コストとプライバシー(既に受信済みデータを再処理する妥当性)の両面で、新規回答のみ対象としています。今後の要望が集まればオプション提供を検討します。
分類結果は他社に共有されますか？
いいえ。分類のためにOpenRouter経由でClaude Haiku 4.5を呼びますが、モデル提供側に学習用途で渡されることはありません(OpenRouter側のデータ保持ポリシーに従います)。
機能をOFFに戻せますか？
はい。チャットまたは管理画面から spam_filter_enabled = false に戻せます。過去に付いたラベルは残りますが、以降の新規回答は分類されません。
有料プランに上げると分類精度は上がりますか？
いいえ。分類は全プラン同じ仕組み・同じモデル・同じプロンプトで動作します。プランで差はつけていません。
まとめ
- 有効化はフォーム公開時または管理画面/チャットから1ステップ
- ダッシュボードでラベル・スコア・分類ソースを確認
- 誤判定は手動で修正できる。修正はAI側で上書きされない
- 分析・エクスポート・ワークフローのどれでも
exclude_salesで除外可能 - フィールド設計で誤判定を減らせる
関連記事:
- 営業メールをAIが自動で検知します -- 全プラン無料で提供開始 -- リリース告知
- なぜ営業メール自動検知を作ったのか -- 設計の背景と思想
