広告主ごとの出稿額と反響、やり取りの記録から出稿を減らしそうな広告主を毎月予測し、先に連絡する順と提案の案を出す

処理の起点を決める

毎月2営業日目の朝に動かします。 前月の発注・請求のデータが締まり、運用担当の月次レポートがそろった後です。月初1日目に動かすと、前月分の出稿額がまだ確定していない広告主が混ざります。 確定前の数字で「減りそう」と出すと、営業は最初の月に一覧を信用しなくなります。

Google Apps Script の時間主導型トリガーは、指定した時刻ちょうどではなく、その時刻から1時間のあいだのどこかで動きます（毎日9時と指定すれば9時から10時のあいだ）。営業会議の資料に間に合わせるなら、会議の前日の朝に動くように置きます。

1回の実行は6分までです。 240社のメモを1社ずつ Gemini API に渡すと、1回では終わりません。そこで次のように分けます。

1. 最初の実行で、240社の一覧と数字の兆しを作り、処理待ちの列に並べる
2. 処理待ちから30社ずつ取り出し、Gemini API に渡して結果を書く
3. 5分を過ぎたら処理を止め、どこまで終わったかをスクリプトのプロパティに残す
4. 数分後に動く時間主導型トリガーを作り直し、残りを続ける
5. 処理待ちが空になったら点数を付けて一覧を完成させ、続きのトリガーを消す

インストール型のトリガーは、作った人のアカウントで動きます。 営業の誰か個人のアカウントで作ると、その人が異動したときに止まります。部署で管理する専用のアカウントで作ります。 Google Workspace のアカウントでは、トリガーの合計実行時間は1日6時間まで、外部へのURL呼び出しは1日10万回までです。月1回・240社なら余裕があります。

入力データを集める

質を決めるのは、上から3つ目と4つ目です。 メモが「定例。特になし」ばかりなら、言葉の兆しは何も拾えません。決算月と契約の区切りの月が無いと、予算を見直す時期が近いかどうかが分かりません。 広告主マスタにこの2列を足すのが最初の準備です。

出稿額を13か月分取るのは、前年同月と比べるためです。 求人や不動産の広告は季節で大きく動きます。前月比だけで見ると、毎年3月に減る広告主が、毎年3月に「減りそう」と出ます。

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

営業支援システムからの取り出し方は、製品によって違います。 APIで取れる製品もあれば、画面から書き出すしかない製品もあります。この部分は利用しているシステムに合わせた個別の実装が必要です。 最初は月1回の書き出しをドライブに置く運用でも、この構成は動きます。

広告主の突き合わせは、広告主コードで行います。 発注のデータとメモでは、同じ広告主が「株式会社◯◯」「◯◯（人材事業部）」と別の名前で書かれていることがよくあります。名前で突き合わせると、事業部ごとに別の広告主として扱われ、出稿額が半分に見えます。

AIへ渡す前に整形する

1. 広告主コードでそろえる … 3つのデータを広告主 × 月の表にし、コードの無い行は「未対応」に分ける
2. 数字の兆しを計算する … 直近3か月の出稿額と、その前の3か月の比。前年同月との比。獲得単価の前年同月との比。最後にメモがあった日からの日数
3. 数字の兆しに印を付ける … 下の表の条件に当たるものに印を付ける
4. メモを整える … 日付の新しい順に並べ、署名や定型の見出しを除く。本文は要約しない
5. メモが無い広告主を分ける … 90日間メモが無い広告主は、AIに渡さず「接点なし」の印を付ける
6. 個人の名前を置き換える … メモに書かれた先方の担当者の氏名を「先方担当A」のように置き換える

条件の数字は、最初は仮の値です。 第7章の保存・ログで記録する当たり外れを見ながら、部長と一緒に直します。大事なのは、この計算をAIにさせないことです。 同じ数字を渡しても、AIに比を計算させると呼び出しのたびに端数が変わります。

AIに処理させる

させるのは3つです。 メモから言葉の兆しを根拠の文とともに拾うこと、数字の兆しと合わせて翌月以降の見込みを出すこと、減りそうな広告主に提案の案を出すことです。

右の列を指示に入れるのが要です。 「予算内で運用してほしい」は予算の話ですが、減額の兆しではありません。拾わない例を示さないと、予算という語が出るたびに兆しとして拾います。

見込みは次の4つから選ばせます。

decrease_likely の条件に「両方」を入れているのが大事です。 数字だけ落ちている広告主は季節の動きかもしれず、言葉だけの広告主は雑談かもしれません。両方がそろったときだけ強く出すと、営業が最初に訪ねる数社が絞れます。

2行目の「金額を出さない」は、意図して外しています。 「来月は約30％減る見込み」と書かせると、その数字だけが独り歩きします。この構成が出すのは「減りそうかどうか」と「なぜそう見えるか」までです。

指示内容を固定する

あなたは広告代理店の営業部で、既存の広告主の出稿の見込みを整理する立場です。
渡された数字の兆しと、打ち合わせのメモだけを根拠にしてください。推測で補わないでください。

【1. 言葉の兆しを拾う】
メモから、出稿の減少につながる記述を次の種類で拾ってください。
- budget ........ 広告費・予算を減らす、見直すという記述
- contact_change 先方の担当者や決裁者が代わる、代わったという記述
- competitor .... 他社の提案やコンペの記述
- inhouse ....... 運用を社内で行う検討の記述
- dissatisfaction 成果や単価への不満の記述
- business_change 事業の縮小・停止・拡大の記述
次のものは拾わないでください。
- 「予算内で」のように、予算の枠に触れただけの記述
- 先方の休暇や一時的な不在
- 業界一般や景気の話題
拾った兆しごとに、根拠にしたメモの文を一字も変えずに quote に写し、そのメモの日付を書いてください。
根拠の文が無い兆しは書かないでください。

【2. 見込みを選ぶ】
- decrease_likely ... 数字の兆しと言葉の兆しの両方がある
- watch ............. どちらか一方だけがある
- stable ............ どちらも無い
- increase_possible . 事業の拡大など、増える兆しがある
迷ったときは watch を選んでください。
reason には、どの数字の兆しと、どの言葉の兆しを見たかを書いてください。

【3. 提案の案（decrease_likely と watch のときだけ）】
拾った兆しに対応する提案の切り口を2〜3個、各80字以内で書いてください。
- 渡された数字と、メモに書かれた先方の関心だけを使ってください。
- 成果の保証、値引き、条件の変更は書かないでください。
- 各案に、どの兆しに対応するかを書いてください。

【厳守事項】
- 数字の計算をしないでください。渡された値をそのまま使ってください。
- 減る金額や割合を予測しないでください。
- メモに書かれていない先方の事情を推測しないでください。
- メモが業務の連絡だけで兆しが無い場合は、signals を空にしてください。

【数字の兆し】{numeric_signals}
【広告主の情報】{client_profile}
【直近90日のメモ（新しい順）】{notes}

以上を読んだうえで、この広告主について指定の形式で返してください。

質問を最後に置いているのは、長い入力のときにそのほうが性能が上がると案内されているためです。 メモが数十件ある広告主では、指示を先頭だけに置くと、最後のほうのメモを読んだところで指示が薄れます。

「一字も変えずに写す」を明記しないと、根拠の文が要約されます。 要約された文は、メモの本文と突き合わせても見つかりません。後段の検証が成り立つのは、原文のまま写させているからです。

出力形式を固定する

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

{
  "client_code": "C-0142",
  "signals": [
    { "type": "budget | contact_change | competitor | inhouse | dissatisfaction | business_change",
      "quote": "", "note_date": "2026-08-21" }
  ],
  "outlook": "decrease_likely | watch | stable | increase_possible",
  "reason": "",
  "proposals": [
    { "angle": "", "for_signal": "budget" }
  ],
  "insufficient_notes": false
}

1つ目の理由は、quote をスクリプトで検証できることです。 quote の文字列がそのメモの本文にそのまま含まれているかを確かめ、含まれていない兆しは捨ててログに残します。

2つ目は、type と outlook を決まった語に限れることです。 構造化出力の enum で選択肢を固定すると、「予算の話」「予算関連」のような表記ゆれが出ず、そのまま重みの表で点数に変えられます。

3つ目は、点数を付ける層を分けられることです。 AIが返すのは兆しと見込みまでで、点数はスクリプトが次の表で付けます。

点数に直近3か月の平均出稿額の区分（大口・中口・小口）を掛け、連絡する順を決めます。 同じ点数なら、減ったときの影響が大きい広告主が上に来ます。重みは部長が決めるもので、この表は最初の仮の値です。

見直し一覧のスプレッドシートには、次の列を並べます。

システムへ連携する

書き込むのは見直し一覧だけです。 営業支援システムにも、発注・請求のデータにも書き込みません。API キーはスクリプトのプロパティに置き、コードに直接書きません。

人が確認する

全件を営業が確かめます。ただし、見る深さを分けます。

1. decrease_likely は根拠の文まで読む … メモの日付と文を読み、そのとき先方がどんな文脈で言ったのかを思い出して、見込みに同意するか直します
2. watch は兆しの種類だけ見る … 自分の知っている事情で説明がつくなら「対象外」とし、理由を一言残します
3. stable と increase_possible は流し見る … 知っている事情と食い違うものだけを直します
4. 営業会議で部長が上位を決める … 点数の上位と、営業が「修正」とした広告主を並べ、訪ねる順を決めます

1番目の「文脈を思い出す」が、人にしかできない部分です。 「来期は予算を見直す」は、減らす話のこともあれば、増やすために見直す話のこともあります。 メモの一文だけでは分からず、その場にいた営業だけが知っています。

営業の判断の欄は必須にします。 空欄のまま会議に出すと、AIの見込みがそのまま会議の結論になります。同意でも修正でも、人が一度判断したという記録を残します。

目標は、240社をならして1社5分です。 decrease_likely の数社は10分以上かけて読み、stable の大半は1分かかりません。

例外に対処する

3行目を「兆し」として扱うのが大事です。 メモが無いことは材料が無いことですが、営業が90日話していない広告主は、それだけで減りやすい相手です。 AIに渡さずに、一覧からも消してしまわないようにします。

記録を残す

• 実行した日時と、使った出稿額・反響・メモの取り出し日時
• 広告主ごとの数字の兆しの値と、印の有無
• AIに渡した入力（置き換え後のメモ）と、返ってきたJSONの全文
• 捨てた兆し（quote がメモに無かったもの）
• そのとき使った重みの表と、付いた点数・順位
• 営業の判断（同意／修正／対象外）と理由
• 翌月の実際の出稿額と、前月の見込みとの突き合わせ

最後の行が、この構成を続けるための記録です。 毎月、前月に decrease_likely と出た広告主のうち実際に減った割合と、stable と出たのに減った広告主の数を数えます。兆しの種類ごとにも数えると、当たらない兆しが分かります。 たとえば dissatisfaction が出た広告主がほとんど減っていないなら、重みを下げます。

営業の判断も同じ表に並べ、AIと営業のどちらが当たったかも数えます。