SaaS 企業が販売代理店から届く案件登録の申請を Make で受け、既存の登録・商談との重複と登録の条件を判定して、承認の判断材料をそろえる

処理の起点を決める

代理店が申請フォームを送信したことを起点にします。 フォームの送信先を Make のカスタムの Webhook のURLにし、1件ずつシナリオを動かします。1日1回のまとめ処理にはしません。 案件登録は先に届け出たほうが優先される制度なので、受け付けた時刻そのものが判定の材料になります。

シナリオの設定で「Process data in order」を有効にします。 即時の Webhook は既定では並行して動き、前の実行が終わるのを待ちません。同じ顧客の申請が2社からほぼ同時に届くと、両方とも「重複なし」で通ってしまいます。 順番に処理させれば、後から来た申請の検索には先の申請の行が台帳に入っています。

受付番号は Webhook response のモジュールで返します。 ただし、途中に置くと後のモジュールのエラーでシナリオが止まらなくなるとされているので、エラーの通知は別に設けます。

入力データを集める

質を決めるのは、顧客と商談の一覧の「別名」の列です。 略称、英語表記、旧社名を、営業が気づいたときに足していく列です。候補に入らなかった行は、AIが見比べようがありません。 ドメインの列も持たせ、担当者のメールアドレスがあればドメインで引きます。

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

候補を引く前に、会社名から核になる語を取り出します。 「株式会社」「(株)」「ホールディングス」「HD」などの法人格とよくある語を落とし、残った語で検索します。Search Rows (advanced) は Google Charts Query Language で検索でき、contains を使えば部分一致で引けます。ただし、この検索は結果に行の番号を返しません。 後で台帳の行を書き換えたいときは、受付番号の列で引き直します。

候補は広めに引きます。 核の語・別名・ドメインのどれかに当たった行を、最大20行までAIに渡します。狭く引くと見落としが残り、広く引いた分の見比べはAIが受け持ちます。 20行を超えたら、核の語が短すぎる（「日本」「東京」など）可能性が高いので、AIに渡さず担当者へ回します。

AIの呼び出しは Make a request で、本文の入力は「Data structure」にします。 JSON の予約文字が自動でエスケープされるからです。「JSON string」だと、自由記述に引用符や改行が入ったときに呼び出しが壊れます。 「Return error if HTTP request fails」を有効にし、4xx・5xx でシナリオを止めて通知します。

AIへ渡す前に整形する

1. 必須の欄の確認 … 顧客の会社名・製品・ライセンス数・予定時期が空なら、AIを呼ばずに「情報不足」にします
2. 数値と日付の形をそろえる … 「20〜30ID」は小さいほうの20、「来年春」は日付にせず空のまま「時期の記載があいまい」の印を付けます
3. 条件 D・E・F の判定 … ライセンス数の下限、予定時期の上限、代理店の区分で扱える製品を、条件表で判定します
4. 会社名の核になる語の取り出し … 法人格とよくある語を落とします。落とした結果が2文字以下なら、元の会社名のまま検索します
5. 候補の行を引く … 顧客と商談の一覧と案件登録台帳から、核の語・別名・ドメインのどれかに当たる行を引きます
6. 期限切れの登録を分ける … 案件登録台帳の行のうち、有効期限が過ぎたものに印を付けます（重複の対象から外すかは決まりの表で決めます）
7. AIに渡す範囲を絞る … 顧客の担当者の名前とメールアドレスは渡しません。会っているかの判定に要るのは「担当者の名前が書かれているか」だけなので、名前は「記載あり」に置き換えます

2番目で「来年春」を日付にしないのは、条件 E の判定が狂うからです。 「来年春」を4月1日に直すと、それだけで180日以内かどうかが決まってしまいます。あいまいな時期は、あいまいなまま担当者に見せます。

AIに処理させる

させるのは2つです。候補の行ごとに申請の顧客と同じ顧客かを判定すること、条件 A・B・C を判定することです。 どちらも、根拠にした申請の文と台帳の行を書き出させます。

group を same と分けているのが、第3章の（b）への答えです。 同じグループだが別の法人と読めるものは group にし、重複とするかは規約の取り決めとして決まりの表の側で扱います。

4行目がいちばん起きやすい失敗です。 生成AIは会社の名前から親会社や業界を知っていることがあり、何も言わなければ「〇〇製造は〇〇ホールディングスの子会社なので group」と書きます。その知識が古ければ、存在しない重複で代理店を差し戻すことになります。 判断の材料は渡した行だけに限ります。

指示内容を固定する

あなたはソフトウェア会社のパートナー営業部で、販売代理店から届いた
案件登録の申請を確認する立場です。渡した申請と候補の行だけを見て判定してください。
会社についてあなたが知っていることを、判定の材料にしないでください。

【1. 候補の行ごとの判定】
申請の顧客と、候補の行の顧客が同じかを、次の4つから選んでください。
- same ....... 同じ法人と読める（略称・英語表記・旧社名・部署の違いを含む）
- group ...... 親会社・子会社・関連会社など、同じグループの別の法人と読める
- different .. 別の顧客と読める
- unclear .... 材料が足りず決められない
グループかどうかは、候補の行の「親会社」の列に書かれている場合だけ group にしてください。
列に書かれていないのに、知識で親会社を補わないでください。

【2. 条件の判定】
各条件について met／not_met／unknown を選び、根拠を書いてください。
A. 新規の顧客 … same と判定した行に「契約あり」が1つでもあれば not_met
B. 重複が無い … same と判定した行に、他の代理店の有効な登録、
   または直販の進行中の商談が1つでもあれば not_met。
   unclear の行が残っていれば unknown
C. 顧客と会っている … 商談の状況の文に、顧客の担当者の記載と、
   すでに行った打合せの日付の両方があれば met。
   「予定」「これから」のように、まだ会っていなければ not_met。
   日付が「先日」「先月」のようにあいまいなら unknown
group と判定した行は、A と B の判定に使わないでください。
group の行は group_rows に並べるだけにしてください。

【厳守事項】
- 承認するか、差し戻すかは書かないでください。
- どちらの代理店が先かは判断しないでください。
- ライセンス数・金額・時期の条件は判定しないでください（別の仕組みで判定します）。
- evidence には、根拠にした申請の文、または候補の行の会社名と列の値を
  そのまま写してください。言い換えないでください。
- 迷ったときに met や different を選ばないでください。unknown・unclear を選んでください。
- 申請が案件登録ではない内容（問い合わせ・苦情など）なら、
  判定をせず request_type にその種類を書いてください。

【申請】{application}
【候補の行（顧客と商談の一覧）】{customer_rows}
【候補の行（案件登録台帳）】{registration_rows}
【申請した代理店のID】{partner_id}

「知識で親会社を補わない」を2か所に書いているのは、1か所では効かないことがあるからです。 最初の段落は判定の材料全体について、2つ目は group の判定についてです。group は知識で補いやすく、補ったときの害がいちばん大きいので、その場所でもう一度禁じます。

「迷ったときに different を選ばない」も同じ考えです。 different の候補は担当者が見ないので、見落としがそのまま承認に進みます。

出力形式を固定する

Messages API の output_config.format に JSON スキーマを渡し、次の形で受け取ります。

{
  "request_type": "deal_registration",
  "candidate_judgements": [
    { "source": "customer_list | registration_ledger",
      "row_key": "",
      "match": "same | group | different | unclear",
      "reason": "",
      "evidence": "" }
  ],
  "group_rows": [""],
  "conditions": [
    { "id": "A | B | C",
      "result": "met | not_met | unknown",
      "evidence": "" }
  ],
  "missing_info": [""]
}

1つ目の理由は、候補の行ごとの判定を残せることです。 row_key で行を指させれば、担当者は CRM を検索し直さず、その行だけを開けば済みます。

2つ目は、振り分けを表の決まりで行えることです。 Make のルーターで、conditions と表の式で出した D・E・F の結果を次のように並べます。

group_rows がある申請は、どの振り分けでも担当者の画面に「同じグループの登録あり」と出します。 規約がグループを重複とするなら、表に1行足すだけです。

スキーマで気をつけることがあります。 Claude の構造化出力は、数値の minimum・maximum、文字列の minLength・maxLength に対応しておらず、使うと400のエラーになります。配列の minItems は 0 と 1 しか使えず、オブジェクトの additionalProperties は false にする必要があります。また、文字列の enum の大文字・小文字は保証されないので、ルーターの条件は大文字と小文字を区別せずに比べます。

システムへ連携する

台帳への書き込みは2回に分けます。 受け付けた直後に、受付番号・受付の時刻・代理店・顧客の会社名だけの仮の行を Add a Row で足し、判定が終わったら Update a Row で結果を書きます。先に仮の行を入れておくと、次に来た申請の検索に「判定中の申請」として当たります。 「Process data in order」とあわせて、同時に届いた申請の取りこぼしを防ぎます。

代理店への返事は自動では送らず、下書きを台帳の列に書きます。

人が確認する

パートナー担当は、すべての申請を開きます。ただし、見る場所が変わります。 これまで6分かけていた検索は無くなり、AIが指した行と根拠を確かめるだけになります。

1. 重複の疑いを先に見る … row_key の行を開き、本当に同じ顧客かを確かめます。先に登録した代理店がいる場合は、受付の時刻を台帳で見比べます
2. 担当者が判断のものを見る … unknown が多い申請は、たいてい商談の状況の欄が短いものです。代理店に聞くかを決めます
3. 情報不足のものの確認の文を直して送る … 下書きは「打合せの日付と先方のご担当者の部署をお知らせください」のような形です
4. 承認の候補を承認する … 根拠の欄を一読し、group_rows が無いことを見て承認します
5. 判定を覆したら記録する … どの候補の match を、どれに変えたかを残します

どちらの申請を有効にするかは、規約の「先着」の決まりと経緯で担当者が決めます。 目標は1件4分です。 承認の候補は1〜2分で済み、重複の疑いと担当者が判断のものに時間を使います。

例外に対処する

1行目と2行目は、別名の列が整っていないことの表れです。 件数を毎月数え、別名の列を足すきっかけにします。

記録を残す

• 申請の全項目と、受付の時刻・受付番号
• 引いた候補の行の一覧（そのときの顧客と商談の一覧・案件登録台帳の内容）
• AIの判定の JSON の全文と、呼び出しに使ったプロンプトの版
• 表の式で出した D・E・F の結果と、そのときの条件表の版
• 振り分けの結果、担当者の決定、覆した判定の記録
• 代理店へ送った返事の日時と本文

2つ目で「そのときの一覧の内容」を残すのは、後で争いになったときのためです。 半年後に「なぜあのとき重複と言わなかったのか」と問われたら、当時の候補の行と判定を見せられることが答えになります。Make の実行の記録は3日（Enterprise は30日）しか残らないので、台帳の側に残します。 条件表の版も、線を変えたときの説明のために残します。