問い合わせフォームと資料請求の見込み客を選別して担当へ配る

処理の起点を決める

フォームが送信されたことを、Webhook で受け取ります。

Make には、URLを作って任意のデータを送れる「カスタムWebhook」があります。自社サイトのフォームの送信先にこのURLを指定すれば、送信と同時にシナリオが動きます。 アプリごとに用意された「インスタントトリガー」も同じ仕組みで、データが届いた時点で実行されます。

定期実行のトリガーを使わないでください。 15分おきに新着を確認する方式にすると、最悪15分の遅れが加わります。この業務では、その15分に意味があります。

Webhook を使うときは、第三者が同じURLに偽のデータを送れる点に注意してください。フォーム側で署名を付けるか、Webhook の直後に「そのデータが自社のフォームから来たものか」を検証する処理を入れます。

入力データを集める

「企業情報は外部から引く」ことを設計の前提にしてください。 会社名をLLMに渡して「この会社の従業員数は」と聞いてはいけません。実在する会社でも数字は当てになりませんし、実在しない会社名でももっともらしい答えが返ります。

企業データベースが使えない場合は、「規模不明」として扱い、人が判断するほうが安全です。

データの取得方法を決める

フォームの送信内容： Webhook のペイロードとして受け取ります。自由記述欄を必ず設けてください。 選択式だけのフォームにすると入力の負担は減りますが、検討段階を読み取る手がかりが失われます。

CRM の照合： メールアドレスのドメインで引くのが確実です。会社名の表記ゆれ（「(株)」「株式会社」「カタカナ表記」）で引くと当たりません。フリーメールのドメインは照合対象から外します。

企業情報： 企業データベースのAPIを、法人名またはドメインで照会します。ヒットしない場合は「不明」として扱います。

過去の振り分け実績： 分類の精度を測るために使います。過去1年分の「問い合わせ内容 → 振り分け先 → 商談化したか」の一覧があると、割り当てルールの妥当性を検証できます。

AIへ渡す前に整形する

1. 重複の検出 … 同じ人が短時間に複数のフォームを送ることがあります。メールアドレスで15分以内の重複をまとめます
2. フリーメールの判別 … 法人ドメインかフリーメールかを判定します。フリーメールだから除外するのではなく、企業情報の照合方法を変えます
3. 除外リストの適用 … 営業目的で繰り返し送ってくるドメインを、分類の前に弾きます。LLMに毎回読ませる必要はありません
4. 自由記述の長さの判定 … 空欄または10文字未満の記述は、検討段階の手がかりになりません。「情報なし」として扱います
5. 個人情報の分離 … 氏名・電話番号は、LLMに渡す必要がありません。会社名・ドメイン・自由記述・選択項目だけを渡します

AIに処理させる

割り当てのルールはプログラムで判定します。 「従業員1,000名以上かつ関東は大企業担当のAさん」といったルールは、条件分岐で書けます。LLMに判断させると、ルールを変えたときに挙動が読めなくなります。

LLMにさせること：

LLMに企業の属性を推測させないでください。 「株式会社◯◯」という会社名から業種や規模を推測させると、それらしい答えが返ります。根拠がありません。 企業情報は必ず外部のデータベースか自社のCRMから引き、引けなければ「不明」とします。

同じ理由で、「商談化しそうか」の点数付けもLLMにさせないでください。 点数は、抽出した項目（検討段階、規模、既存取引の有無、行動履歴）から、プログラムで計算します。そうすれば、なぜその点数になったかが説明できます。

指示内容を固定する

あなたは、問い合わせの内容を読み取る担当者です。
フォームに入力された内容だけから、用件の種別と検討段階を判定してください。

【厳守事項】
- 会社名から、業種・従業員数・事業内容を推測しないでください。
  これらは別の経路で取得済み、または不明として扱います。
  あなたの知識にある企業情報を答えに含めないでください。
- 自由記述に書かれていないことを補わないでください。
  検討段階が読み取れない場合は "unknown" としてください。
  「おそらく情報収集段階」と推測しないでください。
- 用件の種別は、下記の6つからのみ選んでください。
  新しい種別を作らないでください。判断できない場合は "other" とし、
  reason に判断できなかった理由を書いてください。
- 商談化の見込みを点数で答えないでください。
  点数は別途計算します。
- 比較対象として社名が書かれている場合のみ competitors に入れてください。
  「他社と比較」とだけ書かれている場合は、社名を挙げないでください。
- 自由記述に個人的な事情（転職の相談、苦情の内容など）が書かれている場合、
  内容を転記せず、needs_human を true にしてください。

【用件の種別（6つ）】
purchase_consideration（導入検討）/ existing_customer（既存顧客の質問）/
recruiting（採用に関する問い合わせ）/ research（取材・調査・学生）/
sales_pitch（営業目的の売り込み）/ other（その他）

【フォームの内容】
送信元ページ: {source_page}
フォームの種類: {form_type}
会社名: {company_name}
メールドメイン: {email_domain}（フリーメール: {is_freemail}）
選択項目: {select_fields}
自由記述: {free_text}

【CRMの照合結果】
既存顧客: {is_existing_customer}
進行中の商談: {open_opportunities}

【企業データベースの照会結果】
業種: {industry} / 従業員数: {employee_count} / 所在地: {location}
（「不明」の場合はそのまま「不明」として扱ってください）

「あなたの知識にある企業情報を答えに含めないでください」の1行が重要です。 これを書かないと、有名企業については学習内容から答え、無名の企業については推測で答えます。どちらも根拠として使えません。

「商談化の見込みを点数で答えない」も外せません。 点数は営業の行動を左右します。なぜその点数かを説明できない仕組みにすると、営業が結果を信用しなくなります。

出力形式を固定する

{
  "submission_id": "",
  "received_at": "",
  "inquiry_type": "purchase_consideration | existing_customer | recruiting | research | sales_pitch | other",
  "inquiry_type_confidence": "high | medium | low",
  "extracted": {
    "stage": "information_gathering | comparing | internal_approval | ready_to_buy | unknown",
    "issues": [],
    "desired_timing": "",
    "competitors": [],
    "decision_hints": [],
    "quoted_text": ""
  },
  "company_info": {
    "source": "crm | company_db | unknown",
    "industry": "",
    "employee_count": null,
    "location": ""
  },
  "existing_relationship": {
    "is_customer": false,
    "open_opportunity": false,
    "owner": ""
  },
  "needs_human": false,
  "reason": ""
}

割り当て（プログラム）の出力：

{
  "submission_id": "",
  "assigned_to": "",
  "assignment_rule": "",
  "priority": "urgent | high | normal | low",
  "priority_basis": [],
  "route": "inside_sales | direct_to_owner | online_self_serve | no_action",
  "suppressed": false,
  "suppression_reason": ""
}

quoted_text（自由記述の該当部分）を残します。 「比較検討段階と判定した」とだけ言われても、担当者は確かめられません。根拠となった一文が添えられていれば、目で確認できます。

company_info.source を持つのは、企業情報がどこから来たかを明示するためです。unknown の場合、規模による振り分けは効きません。その事実を隠さないことが重要です。

priority_basis に、優先度を高くした理由を配列で入れます。 「進行中の商談がある」「従業員1,000名以上」「『すぐに導入したい』の記述」といった根拠が並びます。

なお、Claude API には出力をJSONスキーマに沿わせる構造化出力の機能があります（2026-09-15時点ではベータ機能として提供）。件数が多く後段が機械処理なので、利用できると安全です。

システムへ連携する

一次返信の自動送信は、種別によって分けてください。

導入検討の問い合わせに自動返信だけを送るのは、機会損失になります。 内容に触れた返信のほうが、その後の反応が違います。

人が確認する

全件を人が見ます。ただし見る深さを分けます。

sales_pitch と判定されたものも、必ず一度は人が見てください。 自動で捨てる設計にすると、誤判定で本当の見込み客を失います。 1日10件程度なら、一覧で流し見る運用で足ります。

例外に対処する

記録を残す

• フォームの送信内容（原本）
• 分類結果と、quoted_text（根拠となった記述）
• 企業情報の取得元（CRM／企業DB／不明）
• 割り当て結果と priority_basis
• 人が割り当てを変更した内容と、その理由
• 一次返信の内容と送信日時
• その後の商談化・受注の結果

最後の2つを突き合わせると、割り当てルールの妥当性が検証できます。 「オンライン完結に回した問い合わせのうち、あとから大型商談になったものが何件あるか」が分かれば、規模の境界値を見直す根拠になります。

受信から返信までの時間を必ず記録してください。 この構成の目的は工数削減より速さなので、そこを測らないと効果が分かりません。