営業担当のメールのやり取りから、取引先ごとの商談の経緯と返事待ち・宿題を毎週要約し、フォローが止まっている取引先を一覧にする

処理の起点を決める

毎週月曜の朝に、時間主導型のトリガーで動かします。 時間主導型のトリガーは、毎分から月1回まで設定でき、時刻はおおよその幅で決まります。 6時に設定すると6時から7時のあいだに動き、その時刻は週ごとに保たれます。会議が10時なら、営業担当が9時までに直せるように6時台にします。

取引先からの質問を週に1回しか拾わないのでは、（b）の待たせる問題が残ります。 そこで、返事待ちの判定だけは毎朝動かすもう1つのトリガーを置きます。毎朝の処理はAIを呼ばず、最後のメールの送り手と日付だけを見て、自社の返事待ちが3営業日を超えた取引先を、その担当者だけにメールで知らせます。

トリガーが失敗したときは、作った人に失敗をまとめたメールが届きます。 営業担当の誰かのトリガーが止まると、その人の行だけが一覧から抜けます。 週次の一覧に「最終更新」の列を持たせ、更新されていない担当者を営業マネージャーが見て分かるようにします。

入力データを集める

質を決めるのは、取引先の一覧のドメインの列です。 ドメインが無い取引先は、メールを探す手がかりがありません。取引先の担当者が個人のメールのドメインから書いてくる場合は、そのアドレスを個別の列に入れます。 個人のメールのドメインそのものを取引先のドメインとして登録すると、関係のない人のメールまで拾います。

前週の一覧を渡すのは、経緯をつなぐためです。 先週の要約と、担当者が直した一言を一緒に渡すと、電話で決まったことが今週の要約に引き継がれます。 メールだけを渡すと、電話で済んだ話がまだ未解決として出続けます。

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

取引先ごとに、そのドメインとの送受信のスレッドを、直近の分だけ取ります。 一度に全取引先を検索すると、スレッドの合計が大きくなって失敗するおそれがあるので、取引先ごとに検索し、件数を区切って読みます。

送信者のアドレスから、ドメインを取り出して自社か取引先かを決めます。 getFrom は表示名とアドレスが一緒に返ることがあるので、アドレスの部分だけを取り出してから比べます。 自社のドメインの一覧はスクリプトのプロパティに置きます。スクリプトのプロパティは、そのスクリプトのすべての利用者に共有される、アプリ全体の設定値の置き場所です。値は文字列で保存されるので、ドメインはカンマで区切った文字列にします。

下書きとゴミ箱のメッセージは除きます。 isDraft と isInTrash で確かめ、まだ送っていない下書きを「自社が返信した」と数えないようにします。

AIへ渡す前に整形する

1. 引用の除去 … 返信の本文には、前のメールの全文が引用として付いてきます。引用を残すと、同じ内容を何度も要約します
2. 署名の除去 … 自社と取引先の署名を取り除きます。電話番号や住所をAIへ渡さないためでもあります
3. 定型の文の除去 … 「いつもお世話になっております」などの書き出しと結びを除きます
4. 時系列に並べる … 取引先ごとに、複数のスレッドのメッセージを日時の順に並べ、送り手が自社か取引先かの印を付けます
5. 長さの調整 … 1社の本文が長すぎるときは、古いものから削り、直近の分を必ず残します
6. 一斉配信の除外 … 取引先からのメールマガジンや自動送信の通知を除きます。送り手のアドレスの一覧で除き、返事待ちの判定に入れません

1番目を軽く見ないでください。 引用を残したまま渡すと、3週間前の「お見積りをお送りします」が、今週の宿題としてもう一度出てきます。 宿題の一覧が膨らむと、担当者は一覧を読まなくなります。

AIに処理させる

させるのは、取引先ごとに5つの項目を決まった形で書き出すことです。

2行目の「迷ったら reply_needed」が、この構成でいちばん大事な決めごとです。 返事を求めていないメールを reply_needed にしても、担当者が一度見て消すだけです。返事を求めているメールを no_reply_needed にすると、その取引先は返事を待たせたまま一覧から消えます。 誤りの重さが違うので、迷ったときの寄せ先を決めます。

宿題は、メールの中で約束した言葉を根拠にします。 「来週中にお送りします」は、メールの日付から見た来週です。AIには期日を日付に直させず、本文の言葉と、そのメールの日付を並べて書かせます。 日付への換算はスクリプトで行います。

3行目がいちばん起きやすい失敗です。 「お見積りをお送りします」に期日が無いとき、何も言わなければ「今週中」と書き足してきます。 書き足された期日は、担当者の記憶にも取引先の期待にも無い期日です。

指示内容を固定する

あなたは営業部で、担当者の週次の営業会議の準備を手伝う係です。
下のメールのやり取りは、1つの取引先とのものです。
書かれていることだけを使い、推測で補わないでください。

【取引先】{account_name}（商談の段階：{stage}）
【先週の一覧の内容と、担当者が直した一言】{last_week}
【メールのやり取り（古い順。各メールに日付と、送り手が自社か取引先かの印）】
{messages}

【書き出す項目】
1. history … 先週までに何が起き、今どこにいるかを3文以内で
2. last_message_reply … 最後のメールが返事を求めているか
   - reply_needed ...... 質問、依頼、日程の打診など、返事が要る
   - no_reply_needed ... お礼や了承だけで、返事が要らない
   迷ったときは reply_needed を選んでください。
3. our_tasks … 自社が約束したこと
4. their_tasks … 取引先が約束したこと
5. next_step … 次の一手の候補を1文。メールから言えなければ空にする

【厳守事項】
- 宿題の期日は、メールに書かれた言葉のまま due_text に写してください。
  「来週」を日付に直さないでください。期日が書かれていなければ「記載なし」としてください。
- 宿題ごとに、根拠にしたメールの日付を source_date に入れてください。
- 引用された古いメールの中の約束を、今回の宿題として数えないでください。
- 先週の一覧で担当者が「済んだ」と書いたものは、メールに新しい動きが無ければ宿題に入れないでください。
- 受注の見込み、取引先の担当者の人柄、営業担当の対応の良し悪しは書かないでください。
- メールに書かれていない電話や対面の内容を想像して補わないでください。

「先週の一覧で担当者が『済んだ』と書いたもの」の一文は、二重の宿題を防ぐために入れます。 電話で見積りの話が済んでいても、メールには「お送りします」としか残っていません。担当者が直した一言を正として扱わせることで、毎週同じ宿題が出続けるのを止めます。

「営業担当の対応の良し悪しは書かない」は、一覧の使われ方を決めるために入れます。 この一覧は会議の準備のためのもので、担当者を評価するためのものではありません。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "account_id": "",
  "history": "",
  "last_message_reply": "reply_needed | no_reply_needed",
  "our_tasks": [
    { "task": "", "due_text": "来週中", "source_date": "2026-09-29" }
  ],
  "their_tasks": [
    { "task": "", "due_text": "記載なし", "source_date": "2026-10-01" }
  ],
  "next_step": ""
}

1つ目の理由は、週次の一覧の列にそのまま書けることです。 Gemini API の構造化出力では、response_format に MIME タイプ application/json とスキーマを渡します。required と enum が使えるので、last_message_reply を2つの値に絞り、すべての取引先で同じ列が埋まるようにします。

2つ目は、規則の判定にAIの値の一部だけを使えることです。 スクリプトは、スレッドから取った日付と送り手に、AIの last_message_reply を1つだけ足して判定します。

日数は自社の営業の取り決めで置き換えてください。 規則はスプレッドシートの側に置き、営業マネージャーが変えられるようにします。

3つ目は、値を検査できることです。 Gemini API の案内でも、構造化出力の値はアプリケーションの側で検査すべきとされています。source_date が渡したメールの日付のどれかに一致しない宿題は、根拠の無い宿題として一覧に載せず、担当者の確認欄に回します。

システムへ連携する

メールには書き込みません。 ラベルを付ける、既読にする、下書きを作る、といった操作はしません。営業担当のメールの状態を変えないことで、スクリプトを入れても普段の使い方が変わらないようにします。

顧客管理のシステムにも書き込みません。 週次の一覧から顧客管理のシステムへ写すかは、担当者が直した後に決めます。AIの要約がそのまま顧客管理の履歴に残ると、誤りが正式な記録になります。

1回の実行は6分までです。 20社を順に処理し、1社ごとにAIを呼ぶと、6分に近づくことがあります。どこまで処理したかをユーザーのプロパティに残し、6分に近づいたら区切って、数分後に続きを動かすトリガーを置きます。 Google Workspace のアカウントでは、メールの読み書きが1日50,000回、トリガーの合計実行時間が1日6時間とされています。

人が確認する

営業担当は、自分の行を必ず見ます。 見る順番を決めておきます。

1. waiting_on_us の取引先を先に見る … 本当に返していないかを確かめます。電話で返していれば、一言欄に「電話で回答済み」と書きます
2. 自社の宿題を確かめる … 済んだものは「済んだ」と書きます。この一言が、翌週の要約に引き継がれます
3. 経緯の誤りを直す … メールに残っていない電話や対面の内容を一言欄に足します
4. silent の取引先に一言を書く … 止まっている理由が分かっていれば書きます

営業マネージャーは、印の付いた行から読みます。 全行を読まずに、waiting_on_us、task_overdue、silent の順に見ます。

2番目を省かないでください。 「済んだ」を書かないと、同じ宿題が毎週出続け、一覧の宿題の欄を誰も信じなくなります。 書くのは1語で足ります。

目標は、1社あたり1分です。 書き出しの作業が無くなり、読んで、違うところだけを直す作業になります。

例外に対処する

8行目は、この構成の限界です。 スクリプトは、動かしている本人のメールしか読めません。担当者が交代したとき、前の担当者とのやり取りは新しい担当者の要約に入りません。 前週の一覧の要約と一言が、引き継ぎの材料になります。

記録を残す

• 週ごとの一覧（要約、宿題、規則の印、担当者の一言）と、その週に読んだスレッドの ID
• AIが返したJSONの全文
• 規則の判定に使った日付と送り手
• 担当者が直した内容と、AIの要約から何を変えたか
• 処理に失敗した取引先と、その理由

メールの本文は一覧に残しません。 残すのはスレッドの ID と要約までにし、本文は必要なときにGmailで開きます。 一覧が共有されるので、本文を写すと、取引先とのやり取りが担当者の外へ広がります。

4つ目の記録は、指示の改善の材料になります。 担当者が毎週同じ種類の誤りを直しているなら、指示か前処理に足りないところがあります。