広告運用の月次レポートに、数値が動いた理由のコメントを下書きする

処理の起点を決める

トリガーは2つに分けます。 1つは変更履歴を運用ログへ積む毎日の処理、もう1つは月次のコメントを下書きする月1回の処理です。

Make のシナリオは、定期実行の選択肢として「一定間隔」「1回」「毎日」「平日」「毎週」「毎月」「指定日」「オンデマンド」を持っています。毎日の処理は「毎日」、月次の処理は「毎月」で組みます。

3行目の順番を崩さないでください。 集計表への書き込みと数式の再計算が終わる前にAIを呼ぶと、前月比が空欄の行が「変化なし」として下書きに出ます。 集計のシナリオが最後に「完了」の印を書き、コメントのシナリオはその印を確かめてから動く形にします。

Make のシナリオには詳細設定で開始日と終了日を持たせることもできます。契約の開始や終了が決まっているアカウントは、ここで動く期間を区切ります。

入力データを集める

質を決めるのは、3行目の「担当者が書いた意図」です。 変更履歴から自動で入るのは「入札の上限を変えた」という事実までで、なぜ変えたのかは入りません。 意図の欄が空の変更は、コメントでは「〜を変更した」とだけ書かれ、理由には使われません。

4行目の「顧客が重視する指標」を渡さないと、コメントの順番がずれます。 問い合わせ数を見ている顧客に、表示回数の増減から書いたレポートを出すことになります。どの指標から書くかは、アカウントごとに先に決めておきます。

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

数値はGAQLで、キャンペーン単位・日付単位に取ります。 月の合計だけを取らないのは、月の途中の変更の前後で数値を分けて見られるようにするためです。

期間の指定は、定義済みの LAST_MONTH より日付の明示を勧めます。 再実行したときに「前月」の意味が実行日で変わらないようにするためです。GAQLは YYYY-MM-DD の形式で日付を受け付けます。

変更イベントの問い合わせには、2つの決まりがあります。 日付で絞り込むこと、その範囲が過去30日以内であることに加え、結果を最大10,000行に制限する LIMIT 句を入れる必要があります。 変更の多いアカウントでも1日分なら収まる想定ですが、上限に届いた日は運用ログに印を付けます。

変更は反映まで最大3分かかることがあるとされています。毎日の取得を深夜0時ちょうどに動かすと、直前の変更が翌日に回ることがあるので、早朝に少し余裕を持たせて動かします。

AIへ渡す前に整形する

1. 期間の確定 … 前月と前々月の開始日・終了日を日付で決め、集計表と問い合わせの両方に同じ値を書きます
2. 取得の完了確認 … 媒体ごとに、取得した日数が月の日数と一致するかを数えます。欠けた日があれば、そのアカウントを止めます
3. 前月比と寄与の計算 … 集計表の数式で出します。AIへ渡す前に、すべての数値がここで決まっている状態にします
4. 率の分母の確認 … 前々月が0の指標は前月比を出さず、「前々月実績なし」と印を付けます
5. 閾値による印付け … 増減の絶対値と寄与の大きさの両方で、動いた行に印を付けます
6. 運用ログの切り出し … 前月の期間に入るログだけを取り出し、ログIDを振ります
7. 意図の欄の確認 … 意図が空の変更を数え、担当者に通知します

4番目を省くと、下書きに「前月比は計算できない増加」のような文が出ます。 0で割る計算を表計算に任せるとエラー値が入り、そのエラー値をAIが文章にしようとします。分母が0のときの表示は、前処理で文字に置き換えておきます。

7番目は月末ではなく、毎日の処理でも回します。 変更した翌日に「意図が空です」と届けば、担当者は覚えているうちに書けます。月初にまとめて聞くと、第3章の（c）と同じことが起きます。

AIに処理させる

させるのは、印の付いた行ごとに「何が動いたか」を文にし、同じキャンペーン・同じ期間の運用ログを結び付けることだけです。 数値は渡されたものをそのまま使い、理由はログにあるものだけを使います。

2行目の「結び付ける」は、因果を言い切ることではありません。 入札を上げた月にクリック数が増えていても、同じ時期に予算や広告文も変えていれば、どれが効いたかは記録からは分かりません。書くのは「〜の変更を行った時期と重なる」までにさせます。 変更が1つしか無く、変更の前後で日別の数値がはっきり分かれているときも、断定は担当者が決めます。

2行目がいちばん起きやすい失敗です。 生成AIは、秋になれば「季節要因」、競合の多い業種なら「競合の出稿増」と、もっともらしい理由を必ず思いつきます。 禁止を書かないと、ログに無い理由がログにある理由と同じ調子で並びます。

指示内容を固定する

あなたは広告代理店の運用担当として、顧客へ出す月次レポートの
コメント欄の下書きを作ります。
渡された【計算済みの差分】と【運用ログ】だけを材料にしてください。

【書くこと】
1. 印の付いた行（flagged が true の行）について、何がどれだけ動いたか
2. その動きと、同じキャンペーン・同じ期間にある運用ログとの結び付き
3. 運用ログに結び付く変更が無い動き
4. 来月の方針（【来月の予定】に書かれたものだけ）

【数値の扱い】
- 数値は【計算済みの差分】にある値だけを使ってください。
- 足し算、引き算、割り算、率の計算を一切しないでください。
  渡されていない数値（合計、平均、差の差など）を作らないでください。
- 文中に数値を書いたら、その数値の row_id を figures に必ず入れてください。
- previous_zero が true の行は、前月比を書かず「前々月の実績なし」と書いてください。

【理由の扱い】
- 理由として書いてよいのは、【運用ログ】にある変更だけです。
  書くときは、その log_id を evidence に入れてください。
- 季節、競合、市場の動き、媒体の仕様変更、顧客側の事情などは、
  【運用ログ】に書かれていない限り理由として書かないでください。
- 結び付く変更が無い動きは、reason_type を "unexplained" にし、
  本文には「理由は記録からは特定できない」とだけ書いてください。
- 同じキャンペーン・同じ期間に変更が2つ以上ある場合は、
  どれが効いたかを決めず、「〜を行った時期と重なる」と書いてください。
- 変更が1つだけでも、「〜により増加した」と言い切らないでください。
- intent が空のログは「〜を変更した」までにとどめ、意図を補わないでください。

【来月の方針】
- 【来月の予定】に書かれたことだけを文にしてください。
- 予定が空なら next_month を空文字にしてください。提案を書かないでください。
- 予算額・入札額を新たに書かないでください。

【書き方】
- 【アカウントの前提】の重視する指標から順に書いてください。
- 顧客に向けた丁寧語で、1つの動きにつき2文以内にしてください。

【アカウントの前提】{account_profile}
【計算済みの差分】{diff_rows}
【運用ログ】{change_log}
【来月の予定】{next_plan}

「季節、競合…は書かない」を列挙しているのは、抽象的な禁止では止まらないからです。 「推測しないでください」とだけ書くと、AIは季節要因を推測だと思わずに書きます。よく出る理由を名指しで禁じます。

「〜により増加した」と言い切らせない一文も外さないでください。 ログに入札の変更があり、同じ月にクリック数が増えていれば、何も言わなければ因果として書きます。顧客はその文を読んで、翌月も同じ変更を求めます。

出力形式を固定する

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

{
  "account_id": "",
  "period": { "current": "2026-08", "previous": "2026-07" },
  "movements": [
    {
      "row_id": "",
      "summary": "",
      "figures": [""],
      "reason_type": "logged | overlapping | unexplained",
      "evidence": [""],
      "reason_text": ""
    }
  ],
  "unexplained_count": 0,
  "next_month": "",
  "needs_owner_input": ["unexplained", "next_month", "empty_intent"]
}

形の保証には、Claude API の構造化出力を使います。 output_config.format にJSONスキーマを渡すと、応答が常に有効なJSONになり、型と必須項目が保証されるとされています。reason_type のような決まった値は enum で固定できます。

ただし、スキーマで守れるのは形までです。 数値の範囲（minimum や maximum）や文字列の長さ・パターンの制約はサポートされていません。また、オブジェクトには additionalProperties を false で指定する必要があります。figures に入った row_id が本当に集計表にあるか、文中の数値がその行の値と一致するかは、スキーマでは確かめられません。 だからワークフロー側で検査します。

3行目と4行目は、再生成せずに機械で置き換えます。 実在しないログを引いた理由は、書き直させても別のそれらしい理由になりがちです。置き換える先は「記録からは特定できない」一択にします。

システムへ連携する

広告アカウントへは書き込みません。 この構成が触るのは数値と変更履歴の読み取りまでで、入札や予算を変える経路は作りません。 来月の方針が下書きに出ても、実際の変更は担当者が管理画面で行います。

Google Ads API の利用には、開発者トークンや認証の準備が別に要ります。Make からの接続方式（専用のモジュールか、HTTPでの呼び出しか）は、利用する契約と権限に応じて個別に確認してください。

人が確認する

人が見るのは、全60本の下書きです。 ただし、読む場所は決まっています。

1. needs_owner_input を先に埋める … unexplained の動き、空の来月の方針、意図が空のログ。担当者が知っている理由があれば書き、無ければ「調査中」と書きます
2. logged と overlapping の結び付きを確かめる … 引いたログが本当にその動きに関係するか、evidence のログを開いて読みます
3. 言い切りが無いかを見る … 「〜により」「〜の効果で」が入っていれば直します
4. 上長または営業担当が読む … 顧客との関係で書き方を変える箇所だけを直します
5. 直した箇所を記録する … unexplained を担当者が埋めた内容は、運用ログの意図の欄にも書き戻します

1番目に「調査中」を許すのは、空欄を嫌って推測で埋めるのを防ぐためです。 担当者も理由が分からない増減はあります。分からないと書けるレポートの形にしておくと、翌月の調査の対象として残ります。

例外に対処する

4行目は、仕組みを止めたときに必ず起きます。 変更履歴は過去30日以内しか取れないため、毎日の処理が1か月止まると、その期間は二度と取れません。 毎日の処理が動いたかどうかを、別の通知で見張ります。

記録を残す

• 取得に使った期間と問い合わせの内容、取得した日数
• 集計表の計算済みの行（AIへ渡した時点の値）
• AIへ渡した運用ログの範囲と、そのときの意図の欄の内容
• AIの応答のJSON全文と、ワークフローの検査結果
• 担当者と上長が直した箇所 … どの段落を、どう変えたか
• 顧客へ送った最終版と、送った日時
• アカウントごとの unexplained の件数の推移

2行目で「渡した時点の値」を残すのは、数値が後から確定し直すためです。 送ったレポートの数値と、翌月に見た前月の数値が違うことがあります。当時の値が残っていないと、どちらが正しかったのかを顧客に説明できません。

最後の行は、運用ログが書かれているかの物差しになります。 unexplained が多いアカウントは、意図の記入が抜けているか、記録に残らない種類の変更をしています。