ECの自社ブランドに届く卸取引の希望を、販売先の業態・地域・希望数量で取引の基準と照らして一次判定し、取引条件の案内か見送りかの返信の下書きを作る

処理の起点を決める

卸取引の問い合わせフォームに回答が届いたことを起点にします。 Google Forms の New Form Response は Instant のトリガーで、回答の直後に動きます。判定と下書きが回答の数分後にでき、担当者はその日のうちに送れます。

1件ごとに動かします。 まとめて処理すると、案内する相手を先にする今の癖が、そのまま残ります。見送りの下書きも、案内と同じ時刻にできあがるようにします。 第3章の（a）は、ここで解きます。

フォームを作り直すときは、回答の記録先のスプレッドシートを変えないでください。 トリガーは回答の保存先を通して動くので、記録先が変わると Zap が動かなくなります。 Google の API の上限を超えると、429 のエラーになることもあります。

入力データを集める

質を決めるのは、2行目の卸の取引基準書です。 基準を、業態・地域・数量の見出しごとに、当てはまる例と当てはまらない例を並べて書きます。「世界観に合う店」のような言葉だけでは、AIも新しい担当者も同じ判断ができません。「実店舗がある、またはブランドの商品だけを集めたページを作れる自社サイトがある」のように、見て確かめられる言葉に直します。

基準書は、たとえば次のような形で書きます。

右端の列を必ず書きます。 分からない例が書かれていないと、AIはどちらかに寄せます。

基準書を書くときに、入れてはいけない基準を確かめます。 流通・取引慣行に関する指針は、安売りを行うことを理由に取引しないようにさせることを、原則として違法としています。一方で、品質の保持や適切な使用の確保など消費者の利益の観点から合理的な理由に基づく基準を、希望する他の流通業者にも同等に当てはめる場合は、その結果として特定の安売り業者が基準を満たさなくても、通常は問題とならないとされています。基準は「どう売るか」ではなく、「どこで、どんな形で扱うか」で書きます。

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

同じ地域の卸先は、複数の行をまとめて引きます。 Lookup Spreadsheet Row は1行を返す検索で、複数の行は Lookup Spreadsheet Rows (Advanced) で最大500行まで取れます。所在地の市区町村で引き、同じ商業施設の名前があるかどうかを AI に渡します。

過去の問い合わせは、見つからなければ続ける設定にします。 Lookup Spreadsheet Row は見つからないときに、行を作る・続ける・止めるを選べます。初めての相手が大半なので、「続ける」にします。 見つかった場合は、前回の判定と理由を AI に渡し、前回と違う判定になるときは要確認にします。

相手のサイトは、この構成では開きません。 AI by Zapier はWebサイトや URL を検索できないとされています。URLを渡しても、AIは中身を見ずにURLの文字から推し量ります。 サイトの確認は、人の仕事として残します。

AIへ渡す前に整形する

1. 所在地をそろえる … 都道府県と市区町村に分け、卸先の一覧と同じ書き方にします
2. 希望数量を数字にする … 「各10個くらい」「まずは少量で」のような書き方は、数字にできなければ空にし、数量の判定を「分からない」にします
3. メールのドメインを取り出す … フリーメールかどうかの印を付けます。フリーメールだけで見送りにはしません
4. URLの形を確かめる … ECモールの店舗ページ、SNSのアカウント、自社のドメインのどれかに分けます。中身は見ず、URLの形だけで分けます
5. 同じ相手の短い間の重複を除く … フォームを二度送った場合、同じ店名・同じメールの回答が数分の間に届きます

4番目でURLの形を分けるのは、業態の判定の材料にするためです。 ECモールの店舗ページなら「ECモールへの出店」、SNSのアカウントだけなら「実店舗・自社サイトの有無は不明」として、AIが中身を見たかのように判定することを防ぎます。

AIに処理させる

させるのは、業態・地域・数量の3つの基準について、当てはまるかを判定し、根拠を書くことです。

unknown を必ず選べるようにしているのが、この構成の要です。 開業前の店、SNSのアカウントだけの店、数量が書かれていない相談は、フォームの回答だけでは判定できません。 当てはまる・当てはまらないのどちらかに寄せさせると、案内すべき相手を見送るか、見送るべき相手に条件を案内することになります。

1行目と2行目がいちばん気をつける点です。 自由記述に「セールで売りたい」「価格は自由に決めたい」と書かれていると、生成AIはブランドを守る方向に気を回して、見送りの理由や、案内の文面の「販売価格はブランドの定める価格で」という一文に変えてしまうことがあります。指示で明示して止めます。

指示内容を固定する

1回目（基準の項目ごとの判定）の指示です。 卸の取引基準書をナレッジのソースとして付けます。

あなたは生活雑貨ブランドの営業部で、卸取引の問い合わせを、付けられた
卸の取引基準書と照らして一次判定する担当です。

【やること】
業態・地域・数量の3つについて、それぞれ fits／not_fits／unknown を選び、
根拠をフォームの回答と基準書の言葉で書いてください。

【厳守事項】
- 判定の根拠は、フォームの回答、既存の卸先の情報、基準書だけにして
  ください。相手の店やサイトの中身を見たように書かないでください。
- 基準書に書かれていない基準を足さないでください。
- 安売り・値引き・セール・価格の決め方に関する記述を、判定の根拠に
  使わないでください。
- 回答だけで判断できない項目は unknown にし、questions に、担当者が
  確かめることか、相手に聞くことを書いてください。
- 取引を始めるべきかの結論を書かないでください。
- 前回の問い合わせの判定が渡されたときは、前回と違う判定になる項目を
  changed_from_previous に書いてください。

【フォームの回答】{form}
【同じ地域・同じ商業施設の既存の卸先】{nearby_retailers}
【前回の問い合わせ】{previous}

2回目（返信の下書き）は、分岐ごとに指示を変えます。 案内の下書きには、基準書にある取引条件（初回の最低ロット、支払の条件、配送の条件、申込の手順）だけを書かせ、販売価格の指示を書かないこと、希望小売価格は参考として示すことを明記します。見送りの下書きには、判定の根拠のうち相手に伝えてよいもの（初回の数量、開業の時期など）だけを書かせ、地域の既存の卸先の名前は書かせません。

「サイトの中身を見たように書かない」が、この指示の要の1つです。 URLを渡すと、生成AIはドメインやパスの文字から「ナチュラルな雰囲気のセレクトショップ」のように書くことがあります。見ていないものを根拠にした判定は、担当者が確かめようがありません。

出力形式を固定する

AI by Zapier の出力のフィールドとして、次の項目を定義します。

{
  "business_type": { "judgment": "fits | not_fits | unknown", "evidence": "" },
  "area": { "judgment": "fits | not_fits | unknown", "evidence": "" },
  "quantity": { "judgment": "fits | not_fits | unknown", "evidence": "" },
  "url_kind": "own_site | marketplace | sns | none",
  "questions": [""],
  "changed_from_previous": [""]
}

1つ目の理由は、Paths の分岐を AI の結論ではなく、3つの判定の組み合わせで決められることです。

Paths は、Custom rules で A と B を作り、どれにも当たらないものを Fallback の C に落とします。 分岐は左から右へ1つずつ評価されます。判定の組み合わせが想定の外になったときも、必ず人が見る C に入ります。

2つ目は、evidence を問い合わせの一覧に残せることです。 半年後に同じ相手から問い合わせが来たとき、前回どの基準で見送ったかが一覧で分かります。第3章の（c）は、ここで解けます。

3つ目は、questions が要確認の返信にそのまま使えることです。 「開業の時期」「実店舗の所在地」「初回の数量」のように、相手に聞けば決まることを、聞く文面にして下書きに入れます。

システムへ連携する

Gmail は Create Draft までにします。 見送りの返信を自動で送ると、判定の誤りがそのまま相手に届きます。Gmail には送信の数の上限もあり、超えると停止のおそれがあります。 下書きにしておけば、担当者が1日の中でまとめて送れます。

問い合わせの一覧には、回答の行ごとに、3つの判定、根拠、分岐、下書きを作った時刻、送った時刻、覆した記録の列を足します。 回答のスプレッドシートとは別のシートにし、回答の行そのものは書き換えません。 フォームの回答の記録と、判断の記録を分けておくためです。

人が確認する

1. 要確認（C）を先に見る … questions を見て、相手のサイトを開いて確かめるか、相手に聞く下書きを送ります
2. 案内（A）の相手のサイトを確かめる … 実店舗や自社サイトがフォームのとおりかを、この段階で人が見ます
3. 見送り（B）の根拠を確かめる … evidence がフォームの回答と合っているかを見ます。数量や開業の時期の読み違いが無いかを確かめます
4. 下書きを直して送る … 案内の文面に販売価格の指示が入っていないか、見送りの文面に既存の卸先の名前が入っていないかを見ます
5. 判定を覆したら記録する … どの項目を、どう変えたかを一覧に残します

2番目を省かないでください。 AI は相手のサイトを見ていません。案内に進める前に相手の店を見るのは、この構成では人の仕事です。

5番目の記録は、基準書を直す材料です。 同じ項目で同じ方向に覆している判定が続くなら、AIの誤りではなく、基準書の書き方が担当者の判断とずれています。 月に一度、覆した記録を項目ごとに数えます。

目標は、1件をならして5分です。 見送りの根拠の確認は1〜2分で済み、案内と要確認の相手はサイトの確認を含めて10分ほどかかる見込みです。

例外に対処する

上から3行目までは、フォームの業態の選択肢を足すだけで減らせます。 「個人での購入」「法人の記念品」「海外からの卸」の選択肢があれば、AI を通す前に分岐させられます。

記録を残す

• フォームの回答と受け取った時刻
• 引いた既存の卸先と前回の問い合わせ
• AI の判定（3つの判定、根拠、確認事項）と、そのときの基準書の版
• 分岐（A／B／C）と、担当者が送った返信と時刻
• 担当者が判定を覆した記録

3つ目で基準書の版を残すのは、基準が変わるからです。 最低ロットや対象の業態を見直すと、過去の見送りの意味が変わります。どの版の基準で判定したかが残っていないと、もう一度案内すべき相手を探せません。