広告主から月次レポートに届く「この数字はなぜ」の質問メールに、レポートの元の数値と運用の記録から回答の下書きを作る

処理の起点を決める

広告主のドメインからメールが届いたことを起点にします。 質問は月次レポートの送付後の1週間に集中しますが、時期で絞らず、いつ届いても動かします。 月の途中に「先週から数字が落ちている」と聞かれることもあるためです。

検索の文字列は、広告主の一覧のドメインから作ります。広告主が増えたら、一覧と検索の文字列の両方に足します。 片方だけ足すと、その広告主の質問だけが下書きされません。月1回、一覧の社数と検索の文字列のドメインの数を比べます。

同じスレッドへの2通目以降でも動きます。 広告主が回答に追加の質問を返してきたときに、同じ流れで下書きを作るためです。ただし、1通目の回答を運用担当が送る前に2通目が届いたときは、下書きを作らずに Slack で知らせます。 同じスレッドに未送信の下書きが2つ並ぶのを避けるためです。

入力データを集める

質を決めるのは、運用の記録です。 記録に「入札を調整」とだけ書かれていれば、下書きの原因の候補も「入札の調整」までしか書けません。記録の書き方を「何を、いくつから、いくつへ、なぜ」に揃えるのが、最初の準備作業です。 たとえば「目標CPAを3,000円から2,500円へ。月末の予算消化を抑えるため」です。

レポートの注記を入れるのは、すでに広告主に伝えた説明と食い違わないためです。 レポートで「新しい広告文のテストを始めた」と書いていれば、回答もそれと揃えます。

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

Lookup Spreadsheet Rows (Advanced) は最大500行を返します。 元の数値は日別・キャンペーン別に持つと1か月で数百行になるので、月別・キャンペーン別に集計した「月次」のシートを別に持ち、そこを引きます。 日別の行をAIに渡すと、合計の計算をAIにさせることになります。

前月比は、シートの計算式で作っておきます。 CPAが前月から何%動いたか、クリック数、CPC、コンバージョン率のどれがどれだけ動いたかを、月次のシートの列として持たせます。 AIに計算させると、桁や割り算の向きを誤ることがあり、その誤りがそのまま広告主に届きます。

運用の記録は、対象のキャンペーンと、その月と前月の期間で取ります。 キャンペーンが特定できない質問では、広告主のすべての記録をその期間で取りますが、30行を超えたら下書きを作らず、運用担当に回します。 記録が多すぎると、関係の無い変更を原因の候補に挙げやすくなります。

AIへ渡す前に整形する

1. 引用の除去 … 返信のメールでは、過去のやり取りが本文の下に引用されています。最新の1通の本文だけを切り出してAIに渡します
2. 署名の除去 … 広告主の署名を切ります
3. 広告主の特定 … 差出人のドメインで広告主の一覧を引きます。同じドメインで複数のブランドを持つ広告主は、件名か本文のブランド名で絞ります
4. 対象の月の決定 … 「先月」「今月」のような表現は、メールの受信日から月に直します。この計算はワークフローで行い、AIにはさせません
5. 指標名の揃え … 広告主が使う「獲得単価」「CV」を、シートの列名（CPA、コンバージョン数）に揃える対応表を持ちます

1番目を省くと、過去の質問にもう一度答えます。 引用された先月の質問が本文に残っていると、AIはそれも質問として拾います。

4番目をワークフローで行うのは、月の境目の誤りを防ぐためです。 10月1日に届いた「先月」は9月ですが、文脈によっては8月のレポートの話のこともあります。受信日から決めた月を下書きに明記し、運用担当が確かめられるようにします。

AIに処理させる

AIのステップは2つに分けます。 1つ目で質問かどうかを判定して対象を拾い、2つ目で回答を書きます。間に数値と記録の参照と Paths を挟み、根拠が揃ったものだけを2つ目に渡します。

1つ目のステップでさせること： 質問かどうか（レポートの数値についての質問／それ以外）、対象の媒体・キャンペーン・指標、質問の数（1通に複数の質問があれば分ける）、急ぎかどうか（「至急」「明日の会議で」などの表現）を拾います。

2つ目のステップでさせること：

1行目と2行目が、最もよく起きる失敗の元です。 AIは、CPAとクリック数と費用から自分で計算し直して、シートと違う値を書くことがあります。記録に原因が見当たらないと、もっともらしい説明を自分で作ります。 どちらも、指示で禁じたうえで、2つ目のステップに渡す材料をシートの行だけに絞ることで防ぎます。

指示内容を固定する

1つ目のステップ（質問の判定と拾い出し）：

広告主から届いたメールの最新の1通を読み、次を判定してください。
- is_report_question：月次レポートの数値についての質問なら true。
  日程の連絡、素材の送付、請求や契約の質問は false。
- 対象の媒体、キャンペーン、指標を、本文に書かれた言葉のまま拾う。
  書かれていなければ空欄。推測で埋めない。
- 質問が複数あれば、質問ごとに分けて questions に並べる。
- 「至急」「明日の会議で」などの表現があれば urgent を true。
- 「先月」「今月」は月に直さず、書かれた言葉のまま period_text に入れる。

【メール本文】{latest_body}
【件名】{subject}

「先月」を月に直させないのは、前処理の4番目でワークフローが決めるためです。 AIの側で直すと、ワークフローの決めた月と食い違ったときにどちらが正しいか分からなくなります。

2つ目のステップ（回答の下書き）：

あなたは広告会社の運用担当です。広告主から届いた月次レポートの
数値についての質問に、回答のメールを下書きしてください。

【厳守事項】
- 数値は【元の数値】【前月比】に書かれた値だけを引用してください。
  自分で計算し直したり、四捨五入の桁を変えたりしないでください。
- 原因の候補は【運用の記録】に書かれた変更だけを根拠にしてください。
  記録に無い原因（競合、季節、媒体の仕様変更、市場の動向など）は
  書かないでください。
- 原因は「〜の可能性があります」と書き、言い切らないでください。
  根拠にした記録の日付と内容を必ず添えてください。
- 記録に該当する変更が無いときは、原因の候補を書かず、
  check_points に運用担当が確かめる点を書いてください。
- 今後の見通し、改善の約束、責任の所在は書かないでください。
- 【伝え済みの説明】と食い違う説明を書かないでください。

【構成】
1. 質問へのお礼と、対象の月・キャンペーン・指標の確認（1文）
2. 数値が示していること（元の数値の引用）
3. 動きの分解（どの要素がどれだけ動いたか）
4. 原因の候補（記録がある場合のみ）
5. 結び（今後の対応は運用担当が書き足す、と空けておく）

【質問】{question}
【対象の月】{target_month}
【元の数値】{metrics_rows}
【前月比】{mom_rows}
【運用の記録】{change_log_rows}
【伝え済みの説明】{report_note}
【指標名の対応】{metric_alias}

「記録に無い原因を書かない」に、例を並べないと効きません。 例が無いと、「競合他社の出稿の増加により」のような一文を自然に書きます。禁じる原因の種類を具体的に並べ、書けないときの行き先（check_points）を用意します。 行き先が無いと、空欄を埋めようとして作ります。

結びの「今後の対応」を空けておくのは、運用担当に必ず一文を書かせるためです。 全部埋まった下書きは、読まずに送られやすくなります。

出力形式を固定する

2つ目のステップは、次の項目で受け取ります。

{
  "target": { "month": "", "media": "", "campaign": "", "metric": "" },
  "facts": [
    { "statement": "", "source_row": "" }
  ],
  "breakdown": [
    { "factor": "clicks | cpc | cvr | cost", "change": "", "source_row": "" }
  ],
  "cause_candidates": [
    { "statement": "", "log_date": "", "log_entry": "" }
  ],
  "check_points": [],
  "draft_body": "",
  "confidence": "high | low"
}

1つ目の理由は、事実と候補を項目で分けられることです。 facts は元の数値の行、cause_candidates は運用の記録の行を必ず指します。source_row や log_entry が空の要素は、ワークフローの側で消します。 根拠の無い文が下書きに残りません。

2つ目は、check_points を Slack にだけ送れることです。 運用担当が確かめる点は、広告主へのメールには入れず、Slack の通知に載せます。たとえば「9月12日以降の変更が記録に無い。管理画面の変更履歴を確認」です。Google 広告の変更履歴では、変更の内容と変更したユーザーを確認でき、対応する期間の表示回数やクリック数なども表示されます。 記録が足りないときに人が見に行く先として、通知に書いておきます。

3つ目は、Paths の判定に使えることです。

「根拠が足りない」でも、facts の部分の下書きは Slack に載せます。 数値が示していることだけでも、運用担当が回答を書く時間は減ります。

システムへ連携する

Paths は左から順に評価され、どれにも当たらないときの分岐を1つ置けます。 「対象が特定できない」を左端に置き、どれにも当たらない分岐は運用担当への通知にします。1つのグループに置ける分岐は10本までです。

シートへは書き込みません。 元の数値と運用の記録は読み取りだけで、回答を送ったかどうかの記録も、Gmail のスレッドに残る送信の履歴で足ります。 書き込みを足すと、元の数値のシートを誤って書き換える経路ができます。

Slack の通知の宛先は、広告主の一覧の窓口と運用の担当の両方です。 窓口と運用の担当が違う広告主では、運用の担当が原因の候補を確かめ、窓口が送ります。

人が確認する

広告主に届くものは、すべて運用担当が確かめてから送ります。

1. 対象の月とキャンペーンが合っているかを見る … 下書きの最初の1文で確認します
2. 引用した数値をシートと見比べる … source_row の行を開いて、値が同じかを見ます。ここだけは省きません
3. 原因の候補が本当に効いているかを判断する … 記録の変更の日付と、数値が動き始めた日がずれていないかを見ます
4. check_points を確かめる … 必要なら管理画面の変更履歴を見て、記録に無い変更が無いかを確かめます
5. 今後の対応を書き足して送る … 結びの空けた箇所に、運用担当の判断を書きます

2番目で値が違っていたら、送る前にその下書きを捨てて書き直します。 1か所でも違えば、他の数値も疑われます。

3番目は、AIにできない判断です。 記録に「9月20日に目標CPAを下げた」とあっても、CPAが上がり始めたのが9月5日なら、その変更は原因ではありません。日別の動きと記録の日付の照らし合わせは、運用担当が管理画面で確かめます。

目標は、120件をならして1件8分です。 根拠の揃った質問は数値の確認と一文の書き足しで済み、根拠が足りない質問は管理画面を見る時間がかかります。

例外に対処する

上から3行目は、思ったより起きます。 広告主の担当者が替わったときや、別の部署から質問が届いたときで、広告主の一覧にドメインではなく個人のアドレスで登録していると漏れます。 一覧はドメインで持ちます。

記録を残す

• 質問のメールと、そのスレッド（Gmail に残る）
• 1つ目のステップで拾った対象と、判定の結果
• 2つ目のステップの出力の全体（facts、cause_candidates、check_points、draft_body）
• 運用担当が実際に送った文面
• 運用担当が原因の候補を採用したか、外したか
• 広告主ごとの質問の数と、質問された指標

5つ目は、運用の記録の質を見る材料になります。 原因の候補が外され続ける広告主は、記録の書き方が粗いか、記録に残っていない変更があるかのどちらかです。

最後の行は、レポートの改善に使えます。 毎月同じ指標について質問が来る広告主には、レポートの側にその指標の分解を最初から載せておけば、質問そのものが減ります。