広告主の来月の広告予算を、媒体・キャンペーンごとの過去の成績と季節の動きから見込んで配分の案にし、提案資料の下書きにする

処理の起点を決める

毎月15日の朝7時に、時間主導型のトリガーで動かします。 提案の締め切りが20日前後なので、15日に案が出れば担当者が直す時間が3営業日ほど残ります。前月の成績が媒体の側で確定するのを待つ必要もあり、月初には動かしません。

1回の実行は6分までなので、1回で5社を処理し、処理済みの広告主をスプレッドシートの管理表に記録して、次の実行で続きから始めます。 続きの実行は10分おきのトリガーで拾い、未処理の広告主が無くなったらそのトリガーを止めます。40社は8回の実行で終わります。

トリガーは作った人のアカウントで動きます。 担当者が異動するとトリガーごと止まるので、運用部の共有アカウントで作り、その旨を管理表に書いておきます。

CSVの置き忘れに備え、15日の時点でフォルダが空の広告主は処理せず、管理表に「データ未着」と残して担当者へ知らせます。 置かれた時点で手動で1社だけ流せるよう、広告主の番号を指定して動かす関数も用意します。

入力データを集める

質を決めるのは、出来事の表です。 在庫切れで2週間止めた月や、計測のタグが外れて成果が0件になった月をそのまま入れると、その月を「予算を減らしたら成果が落ちた月」として学んでしまいます。 出来事の表で、その月を見込みの材料から外します。

条件の表の「増減の幅の上限」は必須にします。 既定は前月比でプラスマイナス30％です。過去に経験したことの無い予算の水準まで、見込みを伸ばさないための枠です。

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

媒体のAPIから直接取るのではなく、管理画面から書き出したCSVを使います。 媒体ごとにAPIの使い方も認証も違い、40社分をつなぐ開発は大きくなります。月1回の処理なので、書き出しの手間は1社あたり数分に収まります。

スクリプトはフォルダのCSVを読み、列名の対応表で名前を統一し、費用を税抜きにそろえ、1つの縦長の表（月×キャンペーン）にします。 この表をCSVの文字列にして、Gemini API へ渡します。

キャンペーンの名前は、途中で変わることがあります。 名前ではなく媒体の側のキャンペーンIDで突き合わせ、名前が変わったものは最新の名前に寄せます。

AIへ渡す前に整形する

1. 列と単位の統一 … 列名の対応表で名前をそろえ、費用を税抜きの円にそろえます
2. 月数の確認 … キャンペーンごとに何か月分のデータがあるかを数えます。13か月未満のものは季節の係数を出さない印を付けます
3. 欠けた月の確認 … 途中で配信を止めた月は0ではなく「欠け」として扱います
4. 除外する月の印 … 出来事の表に載った月を、あてはめから外す印を付けます
5. 急変の検知 … 前月比で成果の単価が3倍以上になった月を一覧にし、出来事の表に載っていないものは担当者に知らせます
6. 少なすぎるキャンペーンの束ね … 月の費用が少額で成果が月数件のものは、媒体ごとに1本へまとめて扱います
7. 条件の確認 … 最低額の合計が総額を超えていないか、止めるキャンペーンに最低額が入っていないかを確かめます

5番目を軽く見ないでください。 急変のうち多いのは計測の不具合で、数字の上では「急に効かなくなったキャンペーン」に見えます。 そのまま入れると、配分の案がそのキャンペーンから予算を引き上げます。

7番目で矛盾が見つかったら、その広告主は処理しません。 条件が成り立たないまま配分を出しても、担当者が条件を直して出し直すことになるだけです。

AIに処理させる

させるのは、コードを書いて走らせ、次の4つを数字で出すことです。 文章で「伸ばせそう」と書かせることはしません。

配分の考え方は、「最後に足した1万円が、どのキャンペーンでも同じくらいの成果を生む」ところを探すことです。 獲得単価の平均が安いところに全部寄せるのではなく、伸びが鈍ってきたところから、まだ伸びるところへ少しずつ移します。 これが第3章の（b）の頭打ちへの答えです。

2行目がいちばん大事です。 費用を足すほど伸びが鈍る式でも、過去に月50万円までしか出したことの無いキャンペーンに150万円を入れた見込みは、式の外側の当て推量です。 条件の表の「増減の幅の上限」と、過去の最大額の1.3倍のどちらか小さいほうを、配分の上限にします。

指示内容を固定する

あなたは広告の運用担当として、来月の予算の配分の案を作ります。
必ず Python のコードを書いて実行し、数字はすべてコードの実行結果から出してください。
文章で見当を付けた数字を書かないでください。

【入力】
- 成績の表（CSV）：month, media, campaign_id, campaign_name, cost, impressions,
  clicks, conversions, conversion_value, exclude_flag
- 条件：total_budget, campaign_limits（最低額・上限額）, stop_campaigns,
  max_change_ratio（前月比の増減の上限）

【手順】
1. exclude_flag が 1 の月をあてはめから外す。
2. キャンペーンごとに、月の cost と conversions の関係を
   conversions = a × log(1 + cost / b) の形であてはめる。
   cost の最大と最小の比が 1.5 未満のものは形が決まらないので fit_status を flat にする。
3. 季節の係数を、前年と前々年の同じ月の、年平均に対する比の平均で出す。
   13か月未満のキャンペーンは seasonality_status を none にし、係数を 1 にする。
4. 来月の見込みを、あてはめた式 × 季節の係数で出す。
   残差のばらつきから、見込みの下限と上限も出す。
5. total_budget の範囲で、追加の1万円あたりの成果がそろうように配分する。
   - stop_campaigns は 0 円。flat のものは前月の額のまま。
   - 各キャンペーンの額は、前月の額 × (1 ± max_change_ratio) と、
     過去の最大の月の費用 × 1.3 のうち、より狭い範囲に収める。
   - 合計は total_budget と一致させる。1,000円単位で丸め、端数は最も効く1本で調整する。
6. 結果を表にして出す。

【厳守事項】
- 入力に無い事情（新商品、競合、媒体の仕様変更）を推測で数字に入れない。
- total_budget を変える提案をしない。
- 見込みは必ず下限と上限を付ける。1つの数字だけで出さない。
- あてはめができなかったものを、できたものとして扱わない。
- コードがエラーになったときは、その旨と原因を書く。直せなければ数字を出さない。

【成績の表】{csv}
【条件】{constraints}

「数字はすべてコードの実行結果から出す」を最初に置かないと、モデルはコードを走らせる前に「おおむね20％増が妥当」と書き始めることがあります。文章で出た数字と、コードの結果が食い違う提案書が、いちばん困ります。

手順5の「より狭い範囲に収める」は、第7章のAIに何をさせるのかの2行目をそのまま式にしたものです。 言葉で「無理に伸ばさない」と書くより、上限の計算式を渡すほうが確実に守られます。

出力形式を固定する

コード実行の結果を、次の形のJSONで受け取ります。 説明文の下書きは別の呼び出しで、構造化出力で返させます。

{
  "client_id": "",
  "target_month": "2026-11",
  "total_budget": 0,
  "campaigns": [
    {
      "campaign_id": "",
      "media": "",
      "fit_status": "ok | flat | insufficient",
      "seasonality_status": "ok | none",
      "seasonal_factor": 1.0,
      "last_month_cost": 0,
      "proposed_cost": 0,
      "change_ratio": 0.0,
      "forecast_conversions": { "low": 0, "mid": 0, "high": 0 },
      "range_flag": "normal | wide",
      "cap_reason": "max_change | history_max | none"
    }
  ],
  "allocation_sum": 0,
  "code_errors": []
}

1つ目の理由は、検算をスクリプトでできることです。 allocation_sum と total_budget の一致、各キャンペーンの change_ratio が上限の内にあるか、stop_campaigns が0円か、をスクリプトが確かめます。1つでも外れていれば、その広告主の結果は使わず、担当者に回します。

2つ目は、cap_reason で「なぜこの額で止めたか」が読めることです。 担当者が「もっと伸ばせるのでは」と思ったとき、history_max なら過去の最大額で止めた、max_change なら増減の上限で止めた、と分かります。

説明文の下書きは、次の形で返させます。

説明文には、JSONの数字だけを使わせます。 下書きに入った数字がJSONの値と一致するかを、スクリプトが文字列で照らします。

システムへ連携する

提案資料のスライドへは、自動で書き込みません。 広告主ごとに資料の書式が違い、自動で埋めると書式を直す手間のほうが大きくなります。一覧から表と文章を貼り付けるのは、1社あたり数分です。

媒体の管理画面への書き込みも行いません。 第6章のとおり、予算の設定を変えるのは、広告主の了承を取った後の担当者です。

人が確認する

担当者が見るのは、配分の案のうち次の3つです。

1. 前月から大きく動くキャンペーン … change_ratio がプラスマイナス15％を超えるもの。理由がデータの上で納得できるかを確かめます
2. wide と none の印が付いたもの … 見込みが不確かなもの。広告主に出す前に、配分を前月寄りに戻すかを決めます
3. 広告主の事情 … 新商品、セール、在庫の見通しなど、データに無い事情を重ねて直します

直したら、直した理由を一覧の欄に書きます。 翌月の実績と比べたとき、AIの案と担当者の修正のどちらが当たったかを見るためです。

上長は、提案資料の文章と数字の一致を見ます。 説明文の下書きは数字を照らしてありますが、担当者が直した後に食い違うことがあります。

目標は、1社あたり60分です。 そのうち40分が配分の案の確認と修正、20分が提案資料の仕上げという想定です。新しい広告主や、媒体を入れ替えた広告主は60分を超えます。

例外に対処する

4行目と5行目は、ほとんどがデータの大きさの問題です。 30本を超えるキャンペーンを持つ広告主では、媒体ごとに分けて実行し、最後の配分だけを全体で行う形にします。

最後の行で「下書きなし」を選べるようにしておくのが大事です。 数字の合わない説明文を直すより、担当者が一から書くほうが早く、安全です。

記録を残す

• 統一した後の成績の表（広告主ごと・月ごと）
• Gemini API が書いたコードの全文と、その実行結果
• 配分の案のJSONと、検算の結果
• 説明文の下書きと、数字の照合の結果
• 担当者が直した箇所と、その理由
• 翌月の実績と、案・修正後の見込みとの差

2つ目のコードの全文を残すのは、見込みの根拠を後から説明するためです。 広告主から「なぜこの配分だったのか」と聞かれたとき、どの式で、どの月を外して、どう計算したかをそのまま示せます。

最後の行が、この構成を育てる材料です。 3か月分たまると、どのキャンペーンで見込みが外れやすいか、担当者の修正がどちらに寄りがちかが見えます。

保管の期間は、広告主との契約に合わせます。 成績の表とコードは、取引が続くあいだは翌年の季節の係数の材料になります。取引が終わった広告主のデータは、契約で決めた期間を過ぎたらフォルダごと消し、消したことを管理表に残します。