広告のクリエイティブごとの日別の成績から効果が落ちてくる時期を見込み、差し替えの時期と次に作る素材の方向の候補を運用担当に出す

処理の起点を決める

取り込みと見込みを分けます。 取り込みは毎朝、前日の成績を媒体のAPIから取って表に足します。見込みは毎週日曜の夜に1回だけ動かし、月曜の朝に一覧を出します。

見込みを毎日にしないのは、日別の成績が揺れるからです。 1日のクリック率は、曜日や配信量で大きく上下します。毎日見込みを出すと、区分が日ごとに「今週発注」と「まだ不要」を行き来し、担当者が信用しなくなります。 週1回、直近7日をならした値で見ます。

取り込みは、前日分だけでなく直近7日分を取り直します。 媒体のコンバージョンは、計上が数日遅れることがあります。直近の数日は取り直して上書きし、確定した値で学習します。

例外として、成績が急に落ちたものは週の途中でも知らせます。 前日のクリック率が、そのクリエイティブの直近14日の中央値の半分を下回り、かつ表示回数が十分にあるときです。これは見込みではなく、起きたことの知らせです。 審査での配信の制限や、リンク切れが原因のことが多いため、担当者に管理画面を見てもらいます。

入力データを集める

質を決めるのは、クリエイティブの属性と出来事の記録です。 媒体のデータだけでも見込みは出ますが、「訴求の軸」と「人物の有無」が無ければ、次に作る方向の候補が出せません。 属性は、制作の依頼票に欄を足して、発注のときに付けてもらいます。

終わったクリエイティブの記録には、止めた理由を必ず付けます。 「飽き」「キャンペーンの終了」「広告主の都合」「審査」の4つから選ぶ形にします。学習の目的の値を作れるのは、理由が「飽き」で、相対の値が0.7を下回った後に止めたものだけです。 理由の無い記録は、学習から外します。

属性の値は決めた一覧から選ばせます。 訴求の軸なら「価格」「機能」「実績」「季節」「限定」「悩みの解決」のように6〜8個です。自由に書かせると、同じ意味の値がばらばらになり、長持ちした傾向を集計できません。

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

Google 広告の問い合わせの例です。

SELECT
  ad_group_ad.ad.id,
  ad_group_ad.status,
  segments.date,
  metrics.impressions,
  metrics.clicks,
  metrics.cost_micros,
  metrics.conversions
FROM ad_group_ad
WHERE segments.date DURING LAST_7_DAYS

媒体ごとに取れる指標の名前と定義は違います。 クリックの数え方、コンバージョンの計上の仕方が媒体で違うため、媒体をまたいで同じ列に入れても、同じ意味にはなりません。 モデルの学習は媒体ごとの列のまま行い、媒体を区別する列を必ず持たせます。

AIへ渡す前に整形する

1. 立ち上がりの基準を決める … 配信開始から7日目以降の、最初の7日間のクリック率の中央値を、そのクリエイティブの基準にします。最初の数日は配信が安定しないので外します
2. 相対の値を作る … 日ごとのクリック率を基準で割り、7日の移動中央値でならします
3. 広告主全体の動きを外す … 同じ広告主・同じ媒体の他のクリエイティブの相対の値の中央値で割ります。全体が下がっているときに、1本だけが飽きたと判定しないためです
4. 出来事の印を付ける … 出来事の記録がある日の前後7日に印を付けます
5. 表示回数の少ない日を外す … 1日の表示回数が決めた下限に満たない日は、相対の値を計算しません
6. 学習の目的の値を作る … 終わったクリエイティブについて、各日から「相対の値が0.7を下回り、そのまま戻らなかった日」までの日数を求めます
7. 特徴量を作る … 配信からの日数、累積の表示回数、直近14日の相対の値の傾き、1日あたりの費用、形式、媒体、訴求の軸、人物の有無、出来事の印

3番目が、この構成の要です。 年末や連休のように市場全体のクリック率が動く時期は、すべてのクリエイティブの値が一緒に動きます。他との比にしておけば、その動きが消え、そのクリエイティブだけの落ち込みが残ります。

6番目の「0.7」は、運用チームで決める値です。 「立ち上がりの7割まで下がったら差し替えの対象」という決まりを、過去の差し替えの記録から決めます。値を変えれば、学習し直します。

AIに処理させる

予測のモデルにさせるのは、配信中のクリエイティブが、相対の値0.7を下回るまでの日数を見込むことだけです。

学習の骨組みは、次のくらいの短さです。

from sklearn.ensemble import HistGradientBoostingRegressor
from sklearn.model_selection import GroupKFold

models = {}
for name, q in [("early", 0.1), ("mid", 0.5), ("late", 0.9)]:
    models[name] = HistGradientBoostingRegressor(
        loss="quantile", quantile=q,
        categorical_features="from_dtype",  # 形式・媒体・訴求の軸
    )

cv = GroupKFold(n_splits=5)
for train_idx, test_idx in cv.split(X, y, groups=creative_id):
    for m in models.values():
        m.fit(X.iloc[train_idx], y.iloc[train_idx])
    # 実際の日数が early〜late の間に入った割合と、
    # early を下回った割合を、媒体・形式ごとに記録する

検証で見るのは、平均の誤差ではありません。 見るのは2つで、実際の日数が早い場合と遅い場合の間に入った割合と、早い場合の値より先に落ちてしまった割合です。発注は早い場合の値で決めるので、後者が多いと「発注が間に合わない」ことになります。分位点0.1で作っていれば、後者は1割前後に収まるはずです。大きく超える媒体・形式は、見込みを出さずに判断保留に回します。

検証は、クリエイティブ単位で分けます。 scikit-learn の GroupKFold は、同じグループが学習と検証の両方に入らないように分けます。クリエイティブIDをグループにすると、同じクリエイティブの前半で学習して後半を当てる、という甘い検証を避けられます。さらに、配信開始が新しい3か月分を最後の検証に残します。 過去のクリエイティブで学んだことが、新しいものに通じるかを確かめるためです。

区分の規則は次のとおりです。

生成AIにさせるのは、「今週発注」の素材について、次に作る方向の候補を書くことです。

文言そのものを書かせないのは、表現の確認が別の工程だからです。 広告の表現は、広告主の確認と、業種によっては法令に照らした確認が要ります。ここで出すのは「どの軸で作るか」の候補までです。

指示内容を固定する

あなたは広告の運用担当を補佐し、次に作るクリエイティブの方向の候補を
出します。根拠は渡した集計だけです。

【入力】
- 差し替え対象の素材の属性
- 同じ広告主で、長持ちした素材（上位）と短かった素材（下位）の属性の集計
  （件数、相対の値が0.7を下回るまでの日数の中央値）

【出すもの】
1. 次に作る方向の候補を3つ。各候補に、形式・訴求の軸・人物の有無を書く
2. 各候補の根拠。集計のどの行を見たかを書く
3. 避けたほうがよい方向を1つ

【厳守事項】
- 集計に無い傾向を書かないでください。一般的な広告の知識で補わないでください。
- 集計の件数が5件未満の属性は、根拠に使わず「件数が少ない」と書いてください。
- 広告の文言、見出し、キャッチコピーを書かないでください。
- 「効果が上がります」「長持ちします」と書かないでください。
  「過去の集計では日数の中央値が長かった」と、集計の事実として書いてください。
- 属性の値は、渡した一覧の中から選んでください。
- 差し替え対象の素材と同じ組み合わせを候補に入れないでください。

【差し替え対象】{target_attributes}
【属性の集計】{attribute_summary}
【属性の値の一覧】{attribute_vocab}

「件数が5件未満は根拠にしない」を明記します。 過去に1本だけ長持ちした動画があると、生成AIはそれを根拠に「動画が有効」と書きます。1本の偶然を傾向として出すと、制作の予算を誤った方向へ使います。

出力形式を固定する

運用担当の一覧は、クリエイティブ1本を1行にします。

方向の候補は、Claude API の構造化出力で次の形で受け取ります。 output_config.format に type: "json_schema" とスキーマを渡すと、スキーマに沿ったJSONで返ります。

{
  "creative_id": "",
  "candidates": [
    { "format": "image | video | carousel",
      "appeal_axis": "",
      "has_person": true,
      "evidence": "",
      "evidence_count": 0 }
  ],
  "avoid": { "appeal_axis": "", "evidence": "" },
  "low_sample_note": ""
}

一覧の1行は、たとえば次のようになります。

区分の欄に、規則の式をそのまま書いておきます。 なぜ今週発注なのかを担当者がその場で読めるようにし、広告主への説明にもそのまま使えるようにするためです。

JSONにする1つ目の理由は、属性の値を一覧と照らせることです。 appeal_axis が一覧に無い値なら、Python の側で弾きます。2つ目は、evidence_count で根拠の件数を後から確かめられることです。 5未満の候補が混ざっていれば、一覧に出す前に外します。

システムへ連携する

媒体のAPIの権限は、読み取りに限ります。 この構成は成績を読むだけで、配信の設定を変える権限を持たせません。 権限の付け方を誤ると、見込みの誤りがそのまま配信の停止につながる経路ができます。

生成AIに渡すのは、属性の集計だけです。 広告主の名前、費用、コンバージョンの数そのものは渡しません。集計は、広告主ごとに Python の側で作ります。

人が確認する

1. 「判断保留」を先に見る … 理由が「出来事の印」なら、その出来事が成績に効いたかを担当者が判断します。予算を上げた直後のクリック率の低下は、飽きではなく配信先の広がりのことが多いです
2. 「今週発注」を確かめる … 管理画面で直近の推移を見て、見込みに納得できるかを判断します
3. 方向の候補を読む … 候補は制作の依頼の下書きの材料です。採るかどうかは担当者が決め、広告主に相談します
4. 見込みと違う判断をしたら記録する … 「今週発注」と出たが見送った、など。理由を一言残します

4番目の記録は、0.7の値と区分の規則を見直す材料です。 見送りが続く広告主があれば、その広告主にとっての落ち込みの基準が違う可能性があります。

月に1回、チームで「見込みと実際」を振り返ります。 先月「今週発注」と出たもののうち、実際にいつ落ちたか、見送ったものはどうなったかを並べます。見込みが外れた例を担当者全員で見ると、出来事の記録の書き漏れが見つかることが多いです。 見込みの精度を上げるより先に、記録の漏れを埋めるほうが効きます。

例外に対処する

1行目を「0で埋めない」としているのは、0のクリックが成績の急落に見えるからです。 取り込みの失敗を落ち込みと取り違えると、元気なクリエイティブに「今週発注」が出ます。

記録を残す

• 媒体から取り込んだ日別の成績と、取り込んだ日時
• 学習に使ったデータの期間、検証の結果（媒体・形式ごとの的中の幅）
• 毎週の見込み（早い・中央・遅い）と区分
• 生成AIに渡した集計と、返ってきたJSON
• 担当者が見込みと違う判断をした記録と理由
• 配信を止めた日と、止めたときの相対の値

最後の行が、次の学習の材料になります。 配信を止めた時点の値と、見込みの日数を突き合わせると、見込みが早すぎたのか遅すぎたのかが分かります。

発注した日と入稿した日も、同じ表に残します。 制作の日数の表は最初は標準の値で始めますが、実際の日数が分かれば区分の規則に使う値を直せます。第3章の（d）の「どこで遅れたか」も、ここから読めるようになります。