出稿期間が翌月に終わる広告主ごとに、配信結果の要点と継続・見直しの提案メールを下書きして担当営業に渡す

処理の起点を決める

毎月5日の朝9時に、Make のシナリオを予定で動かします。 Make の予定には At regular intervals、Daily、Weekly、Monthly、Specified dates などがあり、Monthly で日付と時刻を決めます。 5日にしているのは、前月分の実績が実績の表に入りそろうのを待つためです。1日に動かすと、前月の最後の数日分が入っていない数字で提案を書くことになります。

対象にするのは「出稿終了日が翌月の1日から末日まで」の広告主です。 当月に終わる広告主は、すでに間に合いません。翌月に終わる広告主に、終わる日の3〜8週間前に提案が届くように、この幅にしています。広告主の社内で次の期間の予算を通すのに、それくらいの時間がかかるからです。

月の途中で契約が決まり、すぐに期間が終わる広告主もいます。 予定の実行のほかに、On demand の実行（Run once）で、担当営業が案件台帳の行を指定して1社だけ動かせるようにしておきます。例外を予定の実行に混ぜないで、別の動かし方で拾います。

入力データを集める

質を決めるのは、方向と運用メモの2つです。 数字だけを渡すと、AIは「クリック率が上がりました」のような、表を読めば分かることしか書けません。運用メモに「4月から検索広告の除外キーワードを見直した」と一言あれば、「見直しの結果、獲得単価が下がった」という提案の芯が書けます。

実績の表の率は、表の式で計算したものを渡します。 クリック率・獲得単価・達成率を、AIに件数と費用から計算させることはしません。AIの仕事は、計算された値を写して文章にすることです。

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

案件台帳の Search Rows は、条件に合う行を1行ずつ別のまとまりとして返します。 後ろのモジュールは広告主1社ずつ動くので、広告主ごとに実績の検索とAIの呼び出しが1回ずつ行われます。 1社の中で複数の媒体・月の行がある実績は、Aggregate to JSON で1つにまとめてからAIに渡します。JSON の Aggregate to JSON は、複数のまとまりを1つにまとめるモジュールです。

配列を1件ずつに分けたいときは、Make の Iterator を使います。 Iterator は配列を一連のまとまりに変える特別なモジュールで、AIが返した「数字の一覧」を1つずつ照合するときに使います（後述）。

実績の表は、広告主コードで引きます。 広告主名で引くと、「株式会社」の有無や略称の違いで行が拾えません。案件台帳と実績の表の両方に、同じ広告主コードの列を持たせておきます。

AIへ渡す前に整形する

1. 出稿期間の月だけに絞る … 実績の表には過去の期間の行も残っています。出稿開始日の月から前月までの行だけを渡します
2. 当月の行を落とす … 当月は途中の数字なので、渡すと月の途中の数字で比べることになります
3. 数字の形をそろえる … 費用は円の整数、率は小数1桁の文字列にして渡します。AIが桁を読み違える余地を減らします
4. 方向の列を確かめる … 空なら、下書きを作らずに「方向が未入力」として担当営業と運用担当に知らせます
5. 運用メモの長さを確かめる … 1,000字を超えるものは、運用担当に短くしてもらいます。長いメモは要点がずれる原因になります
6. 停止の連絡が来ていないか確かめる … 案件台帳の状態が「停止連絡あり」なら、提案は作りません

4番目を省かないでください。 方向が空のまま渡すと、AIは数字だけを見て方向を選び、目標に届かなかった広告主に「増額して継続」と書くことがあります。 下書きが担当営業の受信箱に入るとはいえ、方向の誤った下書きは直すより書き直すほうが早く、作った意味がなくなります。

6番目は、運用担当が広告主から直接連絡を受けることがあるためです。 停止が決まっている広告主に継続の提案を送ると、広告主の話を聞いていない会社に見えます。

AIに処理させる

させるのは、渡した数字と運用メモから、結果の要点を3つと、決められた方向の提案を書くことだけです。

いちばん下の行が、この構成の安全装置です。 本文に書いた数字を、どの媒体・月・項目の値かとあわせて一覧で返させます。ワークフローの側で、その一覧の数字が渡した表の値と同じかを照らします。AIの文章を人が読む前に、数字の写し間違いを機械で拾います。

2行目と3行目が、いちばん起きやすい失敗です。 「3か月合計でコンバージョンは何件」と書かせると、AIは月ごとの値を足して書きます。足し算が合っていても、表の合計の行と違う値になることがあります（集計の対象期間や、媒体の計測の遅れの扱いが違うため）。合計が要るなら、表に合計の行を作って渡します。

指示内容を固定する

あなたは広告会社の営業部で、担当営業が広告主に送る提案メールの下書きを書く立場です。
渡した案件の情報・配信結果・運用メモだけを使って書いてください。

【書くもの】
1. 件名（広告主名、出稿期間、「次の期間のご提案」を入れる）
2. 期間のふり返り（1〜2文）
3. 結果の要点を3つ（目標に届いた媒体、届かなかった媒体、運用メモの施策とその後の数字）
4. 次の期間の提案（方向は {direction} のとおりに書く。理由を数字で1つ添える）
5. 次の期間の申込の締切と方法の案内

【数字の扱い】
- 数字は、配信結果の表にある値をそのまま写してください。
- 足し算・割り算・比率の計算をしないでください。合計や率が表に無ければ、その数字は書かないでください。
- 本文に書いた数字は、すべて figures_used に、媒体・月・項目名とあわせて並べてください。
- 「約」「およそ」で数字を丸めないでください。

【厳守事項】
- 提案の方向は {direction} です。数字を見て別の方向が良いと思っても、方向は変えず、
  その考えは questions に書いてください。
- direction が空のときは、提案の段落を書かず、questions に「方向が未入力」と書いてください。
- 「必ず」「確実に」「保証」など、成果を約束する表現を使わないでください。
- 媒体の仕様・新機能・ほかの広告主の事例は書かないでください。
- 値引き、料金、契約条件の変更を提案しないでください。
- 運用メモに書かれていない施策を、行ったこととして書かないでください。
- 実績の行が欠けている月があれば、その月を本文で触れず、data_gaps に書いてください。
- 文体は丁寧語。1段落は3文まで。本文は600字以内。

【案件の情報】{deal}
【配信結果】{results_json}
【運用メモ】{ops_memo}
【申込の決まり】{renewal_rule}

「方向は変えず、考えは questions に書く」を明記しないと、AIは数字に合わせて方向を書き換えます。 達成率が低い広告主に「継続」と指定すると、「見直しをおすすめします」と書いてくることがあります。AIの考えを捨てるのではなく、担当営業への確認事項に移します。 担当営業が読んで、運用担当の判断と食い違うと気づけば、それはそれで役に立ちます。

「運用メモに無い施策を書かない」も同じ理由で入れています。 数字が改善した月があると、AIは「入札の調整により」のような、もっともらしい理由を付け足します。行っていない施策を広告主に報告することになります。

出力形式を固定する

次の形のJSONで受け取ります。 構造化出力のスキーマとして渡し、この形以外では返らないようにします。

{
  "advertiser_code": "",
  "subject": "",
  "body": "",
  "direction_used": "continue | increase | revise | consider_stop | none",
  "figures_used": [
    { "value": "", "media": "", "month": "", "metric": "" }
  ],
  "data_gaps": [""],
  "questions": [""]
}

1つ目の理由は、figures_used で数字を機械で照らせることです。 Make の Parse JSON で受け、Iterator で figures_used を1件ずつに分け、実績の表の該当の値と比べます。1つでも一致しなければ、下書きに「数字の確認が要る」の印を付けて担当営業に送ります。 Claude の構造化出力は数値の範囲や文字列の長さの制約に対応していないので、値は文字列で受け、照合はワークフロー側で行います。

2つ目は、direction_used で方向の取り違えを拾えることです。 案件台帳の方向の列と direction_used が違えば、AIが方向を書き換えたということです。その下書きは送らず、作り直しに回します。

3つ目は、questions を本文と分けておけることです。 担当営業へのメールの先頭に questions と data_gaps を置き、その下に下書きを置きます。確認事項が本文に混ざると、広告主へのメールに「方向が未入力」と書かれたまま送られることがあります。

担当営業へ届くメールは、次の並びです。

【確認してほしいこと】
・（questions の各行）
・（data_gaps の各行）
【数字の照合】一致 12件／不一致 0件
【下書き】
件名：（subject）
（body）

システムへ連携する

広告主へのメールは、この構成からは送りません。 Gmail のモジュールには Send an email も Create a draft email もありますが、送り先は社内の担当営業だけにします。 Create a draft email で下書きを作る形も考えられますが、下書きができるのはつないだアカウントの下書きフォルダです。担当営業8名それぞれの受信箱に下書きを置くには、8つの接続が要ります。社内のメールで送り、担当営業が自分のメールに貼るほうが、つなぐものが少なく済みます。

案件台帳への書き込みは、「提案を作った日」の列だけです。 同じ月に2回動いても、この列に日付が入っている広告主は対象から外します。同じ広告主に下書きが2通届くことを防ぎます。

人が確認する

担当営業は、届いた下書きを全件読みます。 ここは省けません。広告主に届くメールで、送り主は担当営業本人です。

1. 確認事項を先に読む … questions と data_gaps があれば、運用担当に確かめてから下書きを直します
2. 数字の照合の結果を見る … 不一致があれば、その数字を実績の表で確かめて直します。一致していても、本文の数字が正しい媒体・月の値かを1つは見ます
3. 提案の方向を確かめる … 広告主の最近の様子と合っているかを見ます。方向を変えるなら、運用担当と話してから案件台帳の列も直します
4. 自分の言葉に直す … 挨拶や結びは、広告主との関係に合わせて書き換えます
5. 送ったら管理表に日付を入れる … 送らないと決めたものは、理由を1語入れます

3番目で方向を変えたら、台帳の列も直します。 列を直さないと、翌月の照合と管理表で、方向が食い違ったまま残ります。

目標は、60件をならして1件12分です。 下書きを読んで直すのに数分、確認事項があるものは運用担当とのやり取りが加わります。確認事項が多い月は、運用メモの書き方を運用部と見直す材料にします。

例外に対処する

上の2行が、例外の大半です。 どちらもAIの問題ではなく、運用担当が台帳と実績の表を月初めにそろえられているかの問題です。 毎月5日に動かす前に、運用部で「方向と運用メモの入力を4日までに終える」と決めておきます。

記録を残す

• 実行した日時と、対象になった広告主の一覧
• AIに渡した案件の情報、実績の行、運用メモ（そのときの値）
• AIが返したJSONの全文（body、figures_used、questions）
• 数字の照合の結果（一致・不一致の件数と、不一致の値）
• 担当営業が送った日と、送らなかった理由
• 広告主の返事（継続・見直し・停止）と、次の期間の申込の有無

2つ目で「そのときの値」を残すのは、実績の表が後から直されるためです。 媒体の計測の遅れで前月の数字が書き換わると、下書きの数字と表が合わなくなります。どちらが正しかったかを、そのときの値で確かめられるようにします。

最後の行は、方向の選び方を見直す材料になります。 「見直して継続」で書いた提案がどれだけ継続につながったかを数か月分並べると、運用担当が方向を選ぶときの手がかりになります。