人材派遣会社の営業が派遣先を訪問した記録から、増員・職種の追加・条件の見直しの提案の候補と、お礼とフォローのメールの下書きを作る

処理の起点を決める

トリガーは2つあります。 1つはフォームの送信で、訪問の記録を受け取り、Gemini API を呼んで提案の候補とメールの本文を一覧に書きます。ここまでは共用のアカウントで動きます。 もう1つは営業の操作で、ウェブアプリの「下書きを作る」のボタンが押されたときに、営業のアカウントで下書きを作ります。

フォームの送信のトリガーは、品質を上げるためにすぐ動かします。 訪問の直後なら、営業は派遣先との話をまだ覚えています。候補を見て「その話は違う」と気づけるうちに確認してもらうために、まとめて夜に処理することはしません。

トリガーを作るのは、営業部の共用のアカウントです。 インストール型のトリガーは作った人のアカウントで動くので、個人のアカウントで作ると、その人が異動したときに止まります。

入力データを集める

質を決めるのは、訪問の記録の「話した内容」です。 「特に問題なし」だけの記録からは、何も出てきません。フォームの説明に「派遣先が言ったことを、できるだけ言葉のまま書く」と書いておきます。 音声入力でそのまま話してもらうのも有効です。

直近の訪問の記録を渡すのは、続きの話を拾うためです。 先月「来月から繁忙期」と聞き、今月「やはり忙しくなってきた」と聞けば、増員の提案の根拠は2回分になります。 1回分の記録だけでは、この流れは見えません。

スタッフの名前は渡しません。 訪問の記録には、スタッフの働きぶりについての派遣先の言葉が入ることがあります。フォームではスタッフをスタッフ番号で書いてもらい、名前は記録に入れません。

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

抵触日までの月数は、AIに計算させずにスクリプトで出します。 日付の計算をAIに任せると、月の数え方を間違えることがあります。計算した結果を「12か月以内」「6か月以内」のような印にして、指示に差し込みます。

この印は、期間制限に当たるかの判断ではありません。 期間制限には、無期雇用の派遣スタッフなど適用されない場合があり、延長には派遣先の過半数労働組合などからの意見を聴く手続きがあります。どれに当たるかは、派遣元の責任者が確かめます。 印は「確かめるべき派遣先」を見落とさないためのものです。

AIへ渡す前に整形する

1. 派遣先の照合 … フォームで選ばれた派遣先のコードが契約の一覧にあるかを確かめます
2. 記録の長さの確認 … 話した内容が30字に満たない記録は、「記録が短い」として候補を作らず、メールの本文だけを作ります
3. 個人の情報の確認 … 話した内容に、スタッフ番号ではない人名らしい語が入っていれば、営業に確認を返します
4. 直近の記録の整理 … 直近3回の記録を、日付と選ばれた提案を付けて並べます
5. 抵触日の印 … 契約の一覧から印を付けます

2番目で候補を作らないのは、根拠の無い提案を防ぐためです。 短い記録から候補を作らせると、AIは派遣先の業種から一般論で候補を考えます。 それは営業がすでに知っていることで、根拠の無い候補は営業の信頼を失わせます。

AIに処理させる

させるのは3つです。 派遣先の発言の抜き出し、提案の候補、メールの本文です。

提案の候補は、根拠にした発言と1対1で結びます。 「繁忙期で人が足りない（今月の記録）」「来月から物量が増える（先月の記録）」から「増員」。根拠が記録の言葉として示せない候補は出させません。 確かめる質問は、次の訪問か電話で聞くことです（「何名くらい、いつからを考えていらっしゃいますか」）。

物流の派遣先の例で、発言と候補の結び方を示します。

①と②は同じ増員でも、時間帯が違う別の候補です。 1つにまとめさせると、営業が派遣先に確かめる中身がぼやけます。④の「条件の見直し」も、数字は書かせず種類だけにします。

条件の見直しの候補には、数字を入れさせません。 「時給の見直し」「勤務の時間帯の調整」のように種類だけを書かせ、単価や時給の数字は営業が決めます。 数字が下書きに入ると、そのまま派遣先に届くおそれがあります。

指示内容を固定する

あなたは人材派遣会社の営業の補助として、派遣先の訪問の記録から、
次の提案の候補と、お礼とフォローのメールの本文を作る立場です。

【訪問の記録】{visit_note}
【直近の訪問の記録（新しい順）】{recent_notes}
【この派遣先の契約の現状】{contracts}
【期間制限の印】{period_flag}
【自社の提案のメニュー】{menu}
【メールの書き方】{mail_style}

【作るもの】
1. statements：記録の中の、派遣先の困りごと・見通し・要望を、言葉のまま抜き出してください。
   どの記録（今回／前回／前々回）からかを付けてください。
2. proposals：提案の候補。種類は increase（増員）／new_role（職種の追加）／
   terms（条件の見直し）／other のどれか。
   - 各候補に、根拠にした statements の番号を必ず付けてください。
   - 根拠が無い候補は出さないでください。候補が無ければ空の配列にしてください。
   - 各候補に、次に派遣先へ確かめる質問を1〜2個付けてください。
3. mail_body：お礼のメールの本文。話した内容の要点を2〜3行で書き、
   最後に「{proposal_slot}」とだけ書いてください（提案は営業が選んだ後に差し込みます）。

【厳守事項】
- 単価、時給、人数、開始日の数字を書かないでください。約束と受け取られる表現も避けてください。
- 期間制限の印が period_check_required のときは、increase の候補に
  「期間制限の確認が要る」と note に書いてください。期間制限に当たるかどうかは判断しないでください。
- メールの本文に、スタッフの働きぶりや評価を書かないでください。
- 記録に書かれていないことを、話したこととして書かないでください。
- 派遣先の業種から一般的に考えられる提案を、記録の根拠なしに出さないでください。

「根拠が無い候補は出さない」と「候補が無ければ空」を両方書いているのは、AIが何かしら候補を出そうとするからです。 空の配列を許すと明記しないと、一般論の候補で埋めてきます。 候補が無い訪問があるのは当たり前です。

メールの本文に提案の欄を空けておくのは、営業が選ぶ前に提案が本文に入らないようにするためです。 選ばれた候補だけを、営業の画面で差し込みます。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力では、response_format に mime_type: "application/json" と JSON Schema を渡し、type を enum で4つに限ります。公式の案内では、値はアプリケーションの側で必ず検証するようにとされています。

{
  "statements": [ { "no": 1, "text": "", "from": "current | previous | before_previous" } ],
  "proposals": [
    { "type": "increase | new_role | terms | other",
      "summary": "", "basis": [1], "questions": [""], "note": "" }
  ],
  "mail_body": ""
}

スクリプトで確かめること：

2行目が、根拠を本物にする検査です。 AIが「派遣先が言った」として書いた言葉が、記録の中に本当にあるかを文字列で確かめます。 言い換えられていて見つからないものは、根拠として扱いません。

システムへ連携する

営業の画面は、ウェブアプリの1ページです。 左に訪問の記録と発言の抜き出し、右に提案の候補をチェックの欄付きで並べ、下にメールの本文を編集できる欄を置きます。期間制限の印がある派遣先は、画面の上に帯で示します。 画面を開くとき、ウェブアプリはアクセスした営業のメールアドレスで、その営業が担当する派遣先の行だけを表示します。

「下書きを作る」を押したときの処理は、次のとおりです。

選ばれた候補の summary を、本文の {proposal_slot} の位置に差し込む
本文に数字（円・名・時給）が無いかをもう一度確かめる（あれば確認を求める）
宛先 = 派遣先の担当者の一覧のメールアドレス
件名 = 「本日のご訪問のお礼（{自社名}）」
GmailApp.createDraft(宛先, 件名, 本文, { cc: 上司のアドレス（任意） })
提案の一覧に、選ばれた候補を派遣先・種類・期日（2週間後）で書く

ウェブアプリが営業のアカウントで動くので、下書きは営業本人の Gmail にできます。 初めて使うときに、営業ごとに Gmail の権限の承認が求められます。

Gemini API の呼び出しでは、store を false にします。 Interactions API は既定でやり取りを保存し、有料の枠では55日保持するとされています。この構成は1回で完結する呼び出しで、前のやり取りを引き継ぐ必要がありません。派遣先の言葉をサーバーの側に残さないよう、保存しない設定にします。

人が確認する

営業は、訪問の当日か翌日に自分の画面を開きます。

1. 発言の抜き出しを見る … 派遣先の言葉として正しいか、取り違えが無いかを見ます
2. 提案の候補を選ぶ … 進めるものにチェックを入れ、要らないものは理由を選んで外します（「予算が無い」「すでに話した」「根拠が弱い」など）
3. メールの本文を直す … 選んだ候補が差し込まれた本文を読み、言い方を整えます
4. 下書きを作る … ボタンを押すと、自分の Gmail に下書きができます
5. Gmail で送る … 宛先と本文を確かめて送ります

2番目で外した理由を選ばせるのは、指示を直すためです。 「根拠が弱い」が多ければ、候補を出す基準が甘すぎます。 「すでに話した」が多ければ、直近の記録に選ばれた提案が渡っていないか、営業が記録に書いていません。

1番目で取り違えを見つけたら、記録のほうを直します。 抜き出しが違っているのは、たいてい記録の書き方があいまいなときです。記録を直して再度処理すると、候補もそれに合わせて出し直されます。

上司は週に1回、提案の一覧を見ます。 増員と職種の追加の候補を、派遣先と期日で並べ、期間制限の印が付いたものは派遣元の責任者に回します。

例外に対処する

4行目は、提案より先に対応が要る場面です。 スタッフの就業のトラブルや苦情の話が記録にあるとき、その訪問のお礼のメールに増員の提案を添えるのは逆効果です。 苦情らしい語があれば、候補を作らずに上司へ回します。

記録を残す

• 訪問の記録の原文と、指示の全文、返ってきたJSONの全文
• 検証で捨てた候補と、その理由
• 営業が選んだ候補、外した候補と理由
• 作った下書きの本文（送った本文は Gmail に残る）
• 提案の一覧（種類、派遣先、期日、進み具合）

営業が外した理由を残すのは、次の訪問の材料になるからです。 「予算が無い」で外した増員の候補は、次の期の初めにもう一度候補になり得ます。