広告の審査で不承認になった広告の理由を通知とAPIから取り、広告ポリシーに沿った修正案の文面を作って運用担当に渡す

処理の起点を決める

Google 広告から届く不承認の通知メールを起点にします。 運用部の共有アドレスに通知が届くよう各アカウントの通知設定をそろえ、Gmail のフィルタで不承認の通知にラベルを付けます。Make の Watch emails でそのラベルを見張り、15分ごとに動かします。

通知を取りこぼしたときのために、毎朝8時にもう1本の入口を動かします。 管理しているすべてのアカウントについて、前日から不承認のままの広告を API で引き直し、修正案の一覧に無いものだけを処理します。UC-0391 の朝の見回りを入れている場合は、その一覧の不承認の行を入口にしても構いません。

同じ広告を二度処理しないよう、広告ID と根拠の文字列の組で修正案の一覧を引き、すでにあれば処理しません。 根拠の文字列が変わっていれば、別の不承認として処理します。

入力データを集める

質を決めるのは、ポリシーの対応表です。 topic の値だけをAIに渡すと、AIはポリシーの中身を推測して修正案を作ります。運用部の経験者が、topic ごとに「直す場所」と「直し方の要点」を2〜3行で書いた表を渡します。 第2章で経験者の頭の中にあった知識を、ここに移します。

過去の修正は、同じ広告主の同じ topic で採用された案を最大3件だけ渡します。 広告主が以前に認めた言い回しに寄せると、確認の往復が減ります。

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

通知メールの本文から、顧客ID（123-456-7890 の形）とアカウント名を取り出します。 取り出しは正規表現で行い、AIにはさせません。顧客ID が取れなかった通知は、毎朝の入口に任せます。

広告の情報は、Google Ads Campaign Management の Make an API Call で、問い合わせの文を送って取ります。 問い合わせは、公式のサンプルの条件に、広告の文面と最終ページURL の項目を足したものです。

SELECT ad_group_ad.ad.id, ad_group_ad.ad.type,
       ad_group_ad.ad.final_urls,
       ad_group_ad.ad.responsive_search_ad.headlines,
       ad_group_ad.ad.responsive_search_ad.descriptions,
       ad_group_ad.policy_summary.approval_status,
       ad_group_ad.policy_summary.policy_topic_entries
FROM ad_group_ad
WHERE ad_group_ad.policy_summary.approval_status = DISAPPROVED

広告の種類によって、文面の項目は変わります。 ここではレスポンシブ検索広告の見出しと説明文を取っています。ほかの種類の広告は、修正案を作らずに「対象外の種類」として一覧に載せ、人が直します。 種類を広げるのは、件数の多い種類から順にします。

ポリシーの対応表と表現ルールは、Google スプレッドシートの Search Rows で引きます。 対応表は topic で、表現ルールは顧客ID と広告主の対応から引きます。

AIへ渡す前に整形する

1. 直す場所で分ける … ポリシーの対応表で、topic を「広告文」「リンク先」「事業の制限」に分けます。AIに渡すのは「広告文」のものだけです
2. 根拠の文字列と文面を結び付ける … 根拠の文字列が、どの見出し・説明文に含まれているかを文字列の一致で探し、その見出し・説明文の番号を付けます
3. 対応表に無い topic を止める … 対応表に行が無い topic は、AIに渡さず「未登録のポリシー」として人へ回します
4. 再審査の回数を付ける … 修正案の一覧から、この広告でこれまでに出した再審査の回数を数えて付けます

1番目がいちばん効きます。 リンク先が開かない、表示URL と最終ページURL が一致しない、といった不承認は、広告文を何度直しても通りません。 第3章の（c）の空振りは、ここで止めます。

3番目は、AIにポリシーを推測させないための処理です。 対応表に無い topic のときに修正案を作らせると、ポリシーの名前から想像した直し方が、それらしい文面で出てきます。

AIに処理させる

させるのは、根拠の文字列が含まれる見出し・説明文ごとに、修正案を2つ作り、何を変えたかを書くことだけです。

修正案Aは小さく、修正案Bは大きく直します。 広告主の確認が取りやすいのはAで、審査に通りやすいのはBであることが多いという2つを並べ、運用担当が選びます。

1行目がいちばん大事です。 「最安」が当たっているなら「最-安」や「最 安」にする、という直し方は、指摘された表現を残したまま審査だけを通そうとするものです。Google 広告のポリシーは、検出または違反措置を回避することを意図した広告文の不正操作を許可しておらず、この種の違反はアカウントが事前の警告なく停止されうる重大な違反とされています。

指示内容を固定する

あなたは広告代理店の運用部で、審査で不承認になった広告の
修正案を作る担当です。
与えられた情報だけを使ってください。ポリシーの中身を推測しないでください。

【手順】
1. 根拠の文字列が含まれる見出し・説明文ごとに、修正案を2つ作って
   ください。
   - fix_a: 根拠の文字列にあたる表現だけを言い換える
   - fix_b: 訴求を保ったまま、文全体を書き直す
2. それぞれについて、元の文から外したものと足したものを書いてください。
3. 直し方が、ポリシーの対応表の「直し方の要点」のどれに当たるかを
   書いてください。
4. 訴求の意味が変わる場合、または「法務の確認が要る言い回し」を
   使った場合は、client_check を required にしてください。
   迷ったときも required にしてください。

【厳守事項】
- 指摘された語を、記号・空白・別の文字・読みの近い語で崩して
  残さないでください。指摘された表現は、意味ごと外してください。
- 広告主の表現ルールで「使ってはいけない表現」にあるものを
  使わないでください。
- 表現ルールに無い効果・効能・数値・比較の表現を足さないで
  ください。
- 外した表現の代わりに、広告に書かれていない事実を足さないで
  ください。
- 修正できないと判断した場合は、status を cannot_fix にして、
  理由を書いてください。
- 文字数を数えたり、上限に合わせて調整したりしないでください。
- 再審査を出すべきか、法令に照らして表示してよいかを書かないで
  ください。

【ポリシーの項目と根拠の文字列】{policy_entries}
【ポリシーの対応表（該当する行）】{policy_guide}
【不承認になった広告の見出し・説明文（番号付き）】{ad_text}
【広告主の表現ルール】{client_rules}
【同じ広告主・同じポリシーで過去に採用された修正】{past_fixes}

「読みの近い語で崩して残さない」まで書くのは、記号の禁止だけでは足りないからです。 記号を禁じると、AIはひらがなや似た漢字で同じ意味を残そうとします。禁じるのは書き方ではなく、指摘された表現を残すことそのものです。

「広告に書かれていない事実を足さない」も同じ理由で入れます。 外した表現の穴を埋めようとして、AIは「医師監修」「満足度95％」のような広告主が言っていない根拠を足します。 それは新しい不実表示の種です。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "ad_id": "",
  "items": [
    {
      "field": "headline | description",
      "index": 3,
      "original": "",
      "evidence": "",
      "status": "fixed | cannot_fix",
      "fix_a": { "text": "", "removed": "", "added": "" },
      "fix_b": { "text": "", "removed": "", "added": "" },
      "guide_point": "",
      "client_check": "required | not_required",
      "cannot_fix_reason": ""
    }
  ]
}

1つ目の理由は、items で見出し・説明文ごとに修正案を持てることです。 1つの広告で複数の見出しが当たっていても、どの見出しをどう直すかが1行ずつ並びます。

2つ目は、status と client_check を決まった値に絞れることです。 構造化出力のスキーマで enum を使うと、決めた値以外が返ってきません。 Claude API の構造化出力では、オブジェクトの additionalProperties を false にする必要があり、文字列の長さの制約はサポートされないとされています。文字数の確認は、受け取った後にワークフローで行います。

3つ目は、removed と added で確認が速くなることです。 運用担当は、修正案の全文を読む前に、何が外れて何が足されたかを見るだけで、広告主に説明すべき点が分かります。

ワークフローは、受け取ったJSONに次の照合の結果を足して、修正案の一覧に書きます。

3行目の「根拠の残り」は、プロンプトの1つ目の厳守事項を機械で確かめるためのものです。 指摘された語がそのまま残っている案は、一覧で赤く表示し、選べないようにします。

システムへ連携する

Google Ads API は読むだけにします。 広告の更新や再審査の請求の経路は作りません。修正案の一覧から管理画面へ直すのは、運用担当の手作業です。 管理画面で広告を直して保存すると、広告は自動的に再審査に送られます。

リンク先と事業の制限に分けたものは、修正案を作らずに別の担当へ回します。 リンク先はウェブの担当、事業の制限は営業の窓口です。

人が確認する

1. cannot_fix と「未登録のポリシー」を先に見る … 直し方が決まっていない不承認です。経験者が直し方を決め、ポリシーの対応表に行を足します
2. 修正案を選ぶ … AとBのどちらを使うか、手直しするかを決めます。evidence_remains と rule_violation の案は選べません
3. 広告主へ確認を依頼する … client_check が required のものは、外した表現と足した表現を添えて確認を依頼します
4. 管理画面で直して保存する … 承認を得たら直します
5. 再審査を出すかを決める … 直して保存した時点で再審査に回ります。判定に誤りがあると考えて別に再審査を請求するときは、回数を確かめてから出します

1番目で対応表に行を足すことが、この構成を育てる作業です。 1件の未登録のポリシーに直し方を書けば、次の月から同じ不承認は新しい担当者でも直せます。

5番目で回数を見るのは、上限があるからです。 Google 広告のヘルプでは、再審査の請求は各広告につき最大3回で、3回失敗するとサポートに連絡するまで請求できず、同じ広告やキャンペーンについては前回から24時間以上空けるよう案内されています。

目標は、120件をならして1件10分です。 理由を探す時間と、ポリシーを読む時間がほぼ無くなり、運用担当の時間は選ぶことと広告主への説明に使われます。

例外に対処する

上から4行目と5行目が、修正案を作らない判断です。 広告文で直せない不承認に案を作ると、運用担当がその案で直して保存し、再審査の回数を1つ使います。

記録を残す

• 通知メールと、API から取った広告の文面・ポリシーの項目・根拠の文字列
• AIに渡した対応表の行と表現ルールの版、AIが返したJSONの全文
• ワークフローの照合の結果（over_limit・rule_violation・evidence_remains）
• 運用担当が選んだ案と、手直しした後の文面
• 広告主へ確認を依頼した日時と、承認・差し戻しの結果
• 再審査の結果（承認・不承認・再度の不承認）

最後の行が、過去の修正として次の修正案の材料になります。 承認された修正だけを「過去に採用された修正」として渡すので、通らなかった直し方が繰り返されません。