繰り返し注文する取引先の次の注文時期を購買履歴から見込んで、声をかける先と文面を用意する

処理の起点を決める

時間主導型トリガーで、毎週月曜の朝に動かします。 注文は日々来ますが、フォローの判断は週に1回まとめて行えば足ります。毎日動かすと、同じ先が連日候補に出て、担当者が一覧を見なくなります。

トリガーは2本に分けます。1本目が計算と抽出（月曜6時台）、2本目が Gemini API の呼び出し（月曜7時台、以降は未処理が残っていれば15分ごと）です。1回の実行は6分までなので、計算と呼び出しを1本にまとめると、候補の多い週に途中で止まります。2本目は候補シートの「未処理」の行だけを取り、処理した行に印を付けて、次の実行は続きから始めます。

受注履歴のCSVが今週分に貼り替わっていなければ、1本目は計算をせずに担当者へ知らせて終わります。古い履歴で計算すると、先週注文した先が「遅れ」として出ます。

入力データを集める

計算の質を決めるのは受注履歴の粒度です。 1回の注文に複数の品目があるときは、品目ごとに1行になっている必要があります。受注番号の単位で1行のCSVしか出せない場合は、品目で行を分けるところから準備します。

営業メモを直近90日に絞るのは、古い事情で今の遅れを説明させないためです。 1年前の「担当者交代」を根拠に、今月の遅れを説明する下書きが出るのを防ぎます。

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

販売管理システムからの取り込みは、最初は手作業で構いません。 週に1回CSVを貼る作業は数分です。自動化するのは、計算の結果が営業に使われると確かめてからです。

Gemini API の呼び出しは、UrlFetchApp.fetch に送信先、method: 'post'、contentType: 'application/json'、APIキーを入れたヘッダー、本文を渡します。APIキーはスクリプトの本文に書かず、スクリプトの設定側に置きます。

AIへ渡す前に整形する

ここがこの記事の中心です。計算はすべて Apps Script で行い、AIには渡しません。

抽出の条件は「L が W を超えている」ことです。 平均ではなく中央値を使うのは、1回だけの長い空白（年末年始の休業など）に引きずられないためです。ばらつきにも同じ理由で中央値からの差を使います。W の下限を7日にしているのは、毎回きっちり同じ間隔で注文する先で S が0になり、1日の遅れで候補に出てしまうのを防ぐためです。

数量の補正は、まとめ買いへの対策です。 前回いつもの2倍を買った先は、次の注文もいつもより遅くなるのが普通です。補正を掛けずに計算すると、まとめ買いをしてくれた上客ほど「遅れ」として出てきます。

振り分けは次の順で行います。

1. フォロー停止中の取引先 … 取引先の表に停止理由がある先は、計算せずに除きます
2. 注文回数が3回未満 … 間隔が1つしか取れず、ばらつきを出せません。候補にはせず、「履歴不足」として件数だけ数えます
3. 季節品目 … 品目の表で季節品目とした品目は、M と W による判定を使いません。前年の同じ月の前後1か月に注文があり、今年の同じ期間に無いときだけ候補にします
4. 切り替えの兆し … 直近3回の数量がいずれも数量の中央値の半分以下で、L が W を超えている先は、「減少」として別の区分にします
5. 長期停止 … L が M の3倍を超えている先も、「長期停止」として別の区分にします
6. 残りのうち L が W を超えた先 … 「遅れ」として候補にします

4番目と5番目を「遅れ」と分けるのは、声のかけ方が違うからです。 数か月注文が無い先や、少しずつ量を減らしている先に「そろそろ在庫はいかがですか」と送ると、事情を分かっていない会社だと受け取られます。この2つの区分は下書きを作らず、担当者の判断に回します。

1社で複数の品目が候補になったときは、取引先ごとに1行にまとめます。 同じ週に同じ先へ品目ごとの連絡が3通届くのを防ぎます。

中央値と判定の部分は、次のように書けます。

function median(values) {
  const a = values.slice().sort((p, q) => p - q);
  const mid = Math.floor(a.length / 2);
  return a.length % 2 ? a[mid] : (a[mid - 1] + a[mid]) / 2;
}

// dates: 同じ取引先・同じ品目の受注日（Date）を古い順に並べたもの
function judge(dates, baseDate, correctedIntervalDays) {
  if (dates.length < 3) return { status: 'insufficient_history' };
  const day = 86400000;
  const gaps = [];
  for (let i = 1; i < dates.length; i++) {
    gaps.push(Math.round((dates[i] - dates[i - 1]) / day));
  }
  const m = median(gaps);
  const s = median(gaps.map(g => Math.abs(g - m)));
  const w = Math.max(s + s, 7);
  // correctedIntervalDays は M に数量の補正を掛けた日数（別の関数で計算）
  const expected = new Date(dates[dates.length - 1].getTime());
  expected.setDate(expected.getDate() + Math.round(correctedIntervalDays));
  const lateDays = Math.round((baseDate - expected) / day);
  return { median_interval: m, spread: s, tolerance: w,
           expected_date: expected, late_days: lateDays,
           is_late: lateDays > w };
}

AIに処理させる

Gemini API に渡すのは、候補になった先の計算結果と、直近90日の営業メモだけです。 受注履歴そのものは渡しません。

事情の分類は、在庫過多（まとめ買いした、在庫が余っている）、担当者交代、他社検討（相見積もり、他社の名前が出ている）、休業・改装、需要減（店舗の閉鎖、生産の縮小）、不満あり（納期・品質の苦情）、記載なし の7つです。

他社検討 と 不満あり が出た先も、下書きは作りますが担当者に先に知らせます。 定型の文面で済ませてよい先ではありません。

指示内容を固定する

system_instruction に次を置きます。

あなたは業務用消耗品の商社で、既存取引先へのフォローを手伝う内勤営業です。
渡された「計算結果」と「営業メモ」だけを使ってください。

【してほしいこと】
1. 営業メモから、注文が遅れている理由になりうる事情を、次の7つから1つ選ぶ。
   在庫過多／担当者交代／他社検討／休業・改装／需要減／不満あり／記載なし
2. 選んだ根拠となるメモの文を、一字一句そのまま evidence に写す。
3. category が「遅れ」の先について、取引先の担当者あてのメール下書きを作る。

【厳守事項】
- 次回見込み日、遅れ日数、品目名は、計算結果の値をそのまま使う。
  書き換えたり、別の日付を計算したりしない。
- メモに書かれていない事情を推測しない。当てはまる記載が無ければ「記載なし」とし、
  evidence は空にする。
- 事情が2つ以上あるときは、日付の新しいメモのほうを選ぶ。
- 下書きでは、注文が遅れていることを責める書き方をしない。
  「前回のご注文から○週ほど経ちましたので、在庫のご状況を伺えればと思います」の調子にする。
- 値引き、特別価格、納期の約束を書かない。
- 他社の名前がメモにあっても、下書きには書かない。
- 在庫過多のときは、次の注文を促さず、状況の確認だけにとどめる。
- 担当者交代のときは、新しいご担当者へのあいさつを先に書く。
- category が「減少」または「長期停止」のときは、draft を空にする。
- 下書きは本文だけ。署名は付けない。300字以内。

本文には、取引先ごとに次を入れます。

【取引先】{customer_name}（担当：{contact_name}）
【計算結果】category: {category} ／ 品目: {items} ／ 前回注文日: {last_date}
           次回見込み日: {expected_date} ／ 遅れ日数: {late_days}
【営業メモ（直近90日、新しい順）】{memos}

「計算結果の値をそのまま使う」を最初に書くのは、下書きの中で日付が変わるのを防ぐためです。 何も言わないと、メモの日付と見込み日を混ぜて「3週間ほど」を「1か月ほど」に言い換えることがあります。

「在庫過多のときは注文を促さない」を明記するのは、下書きの失敗がいちばん目立つ型だからです。 在庫を持ちすぎたと言った先に注文を勧めると、メモを読んでいないことが相手に伝わります。

出力形式を固定する

構造化出力で、次のスキーマを渡します。 送信先は https://generativelanguage.googleapis.com/v1beta/interactions、ヘッダーは x-goog-api-key、本文の response_format に mime_type: "application/json" とスキーマを入れます。

{
  "type": "object",
  "properties": {
    "customer_code": { "type": "string" },
    "reason": {
      "type": "string",
      "enum": ["在庫過多", "担当者交代", "他社検討", "休業・改装", "需要減", "不満あり", "記載なし"]
    },
    "evidence": { "type": "string" },
    "evidence_date": { "type": "string", "format": "date" },
    "expected_date": { "type": "string", "format": "date" },
    "late_days": { "type": "integer" },
    "draft": { "type": "string" },
    "notify_first": { "type": "boolean" }
  },
  "required": ["customer_code", "reason", "evidence", "expected_date", "late_days", "draft", "notify_first"]
}

JSONにする1つ目の理由は、reason を決めた語に固定できることです。 enum で7つに絞るので、「在庫がだぶついている」のような言い換えが入らず、事情ごとの件数を毎週数えられます。

2つ目は、戻ってきた値を検査できることです。 構文として正しいJSONが返っても値の正しさは保証されないので、Apps Script で次を確かめます。

2行目が効きます。 根拠の文がメモに無ければ、それはAIが作った事情です。文字列の一致で機械的に見分けられるので、人が読む前に落とせます。

システムへ連携する

フォロー候補シートは、担当者の列で絞って見られるようにします。 1行ごとに「連絡した／見送った／次回に回す」の選択欄と、結果を書く欄を置きます。

Gmail への送信は、この構成に入れません。 下書きを候補シートからコピーして、担当者がふだんのGmailから送ります。送信まで自動にすると、在庫過多の先に注文を促す1通が、止める人のいないまま出ていきます。

人が確認する

人が見るのは、候補シートに出た先だけです。 300社を毎月見る作業は、計算が肩代わりします。

1. notify_first が付いた先を先に見る … 他社検討 と 不満あり。メールより電話か訪問がよいかを先に決めます
2. 減少・長期停止 の先を見る … 下書きはありません。取引の状況を知っている担当者が、連絡するかを決めます
3. 遅れ の先の下書きを直して送る … 事情と根拠の文を読み、下書きがそれに合っているかを確かめます
4. 結果を記録する … 「在庫があった」「他社に替えていた」「注文をもらえた」を選択欄で残します

4番目を省かないでください。 「在庫があった」が多い先は、数量の補正が足りていないか、間隔の中央値が実態より短く出ています。記録が無いと、計算の規則を直す材料がありません。

例外に対処する

上の3行が、計算の規則だけでは決めきれない部分です。 どれも「遅れ」として一律に扱うと、連絡してはいけない先に定型の文面が届きます。区分を分け、人に回す先をはっきりさせておくことが、この構成の例外処理の中心です。

記録を残す

• 実行日時と、使った受注履歴のCSVの出力日
• 取引先×品目ごとの n、M、S、W、補正、E、L と、振り分けた区分
• Gemini API に渡した本文と、返ったJSONの全文
• 値の検査の結果（通った／要確認 にした理由）
• 担当者の対応（連絡した／見送った／次回に回す）と、連絡の結果

2つ目を毎週残すのは、後から「なぜこの先が候補になったのか」を説明するためです。 候補から漏れた先で注文が止まったときも、その週の計算の値を見れば、W が広すぎたのか、履歴不足で外れたのかが分かります。