広告媒体の広告ポリシー・入稿規定・計測の仕様の更新をエージェントが毎週見回り、運用中の広告主と商材に影響するものを運用担当へ知らせる

処理の起点を決める

毎週月曜の朝7時に、Schedule Trigger で動かします。 週の初めに運用推進チームが一覧を見て、その週のうちに運用担当へ渡せるようにするためです。Schedule Trigger の週単位の設定では、何週ごとか、曜日、時、分を指定できます。

Schedule Trigger は、ワークフローのタイムゾーンが無ければ n8n のインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。ワークフローの設定でタイムゾーンを Asia/Tokyo にします。Schedule Trigger を使うワークフローは、保存して公開する必要があるとされています。

見回りの対象は、媒体の一覧の表で持ちます。 列は、媒体名、ページの種類（ポリシー／入稿規定／計測）、URL、CSS セレクター、本文の言語、英語版の取り方、受け持ちのメンバーです。ワークフローの中にURLを書き込まないでください。 媒体がページの場所を変えたときや、新しい媒体を扱い始めたとき、表に1行足すだけで見回りの対象になります。

年が変わる月には、年ごとのページの行を足します。 Google 広告の変更ログは年ごとのページに分かれているため、1月の第1週に新しい年のページを表に足し、前の年のページは3か月ほど並べて見回ります。 年をまたいで書き換わるお知らせがあるからです。

入力データを集める

質を決めるのは、広告主の一覧の「商材の区分」と「配信国」の列です。 媒体のポリシーは、金融商品、ヘルスケアと医薬品、アルコール、ギャンブルとゲーム、暗号資産のような商材の単位と、国の単位で書かれます。一覧の商材の区分が「EC」「通販」のように粗いと、健康食品の広告主に当たる更新を拾えません。 区分は媒体のポリシーの単位に合わせて付けます。

「使っている媒体と広告の種類」の列も要ります。 住所アセットやマストヘッドの要件のように、広告の種類に当たる更新があるからです。

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

Google 広告のお知らせは、日本語版と英語版を両方取ります。 同じ answer/ の番号で hl=ja と hl=en を付け替えると、同じお知らせの日本語版と英語版が返ります。例えば2026年6月のリンク先の要件の更新では、日本語版の「2026 年 7 月上旬に適用されます」と、英語版の「take effect in early July, 2026」が対応します。措置は英語版の記述に沿うとされているので、日付と対象国は英語版を正とします。

ページは間隔を空けて1件ずつ取ります。 HTTP Request には、1回に送る件数（Items per Batch）と、次の送信までの待ち時間（Batch Interval、ミリ秒）を決める Batching の設定があります。1件ずつ、数秒の間隔で取ります。新しいお知らせが週に十数件なら、両方の言語を取っても数十回の取得で済みます。

AIへ渡す前に整形する

1. 見出しで絞る … 「ポリシー」「要件」「更新」「Policy」「requirements」などの語を含むものを残し、それ以外は見出しとURLだけを一覧の末尾に残します
2. 国の語を拾う … 見出しの「（対象: ブラジル）」「France」のような国名を取り出し、自社の広告主の配信国に無い国だけの更新は、エージェントに渡さず件数だけ数えます
3. 本文の共通部分を外す … メニュー、関連記事の一覧、フィードバックの欄を外し、お知らせの本文だけにします
4. 投稿日の行を確かめる … 「（投稿: 2026 年 6 月 23 日）」「(Posted on ...)」の行が取れたかを確かめ、取れなければ人に回します
5. 本文のハッシュを取る … 見出しが同じでも本文が変わったものを、次の回で拾えるようにします
6. 件数を確かめる … 1つのページで新しいお知らせが20件を超えたら、ページの作りが変わったとみなして比較を止めます

2番目の効き目は大きいです。 Google 広告の2026年の一覧の上の方だけでも、コロンビア、ブラジル、スロベニア、クロアチアを対象にしたギャンブルとゲームの更新が並んでいます。配信国の一覧と突き合わせて先に外すと、エージェントに渡す件数がはっきり減ります。 ただし、外したものも件数と見出しは残し、配信国が増えたときに読み直せるようにします。

AIに処理させる

させるのは、お知らせ1件ごとに、種類・対象・日付を本文から写し取り、広告主の一覧を引いて影響の候補を挙げることです。

取り出しは、本文の文言をそのまま写させます。 「2026 年 7 月上旬」と書かれていれば「2026 年 7 月上旬」のまま写し、7月1日のような日付に置き換えさせません。 適用の時期の並べ替えは、ワークフローの側で月の初め・中旬・下旬を決まった日に読み替えて行います。

1行目がいちばん起きやすい失敗です。 「金融サービスの広告主を対象とする適格性確認の要件の導入」のようなお知らせを渡すと、生成AIは金融の区分の広告主すべてに「対応が必要」と書きがちです。実際には、対象の国やサービスの種類が限られていることが多く、結論を書かせると関係のない広告主の担当まで動かします。

指示内容を固定する

AI Agent ノードの System Message に、次のように書きます。

あなたは広告会社の運用推進チームで、広告媒体が公表したポリシー・
入稿規定・計測の仕様の更新を、自社が運用する広告主に照らす担当です。
入力は、新しく見つかったお知らせ1件の日本語版と英語版の本文、
媒体の名前、お知らせのURLです。

【やること】
1. 種類を policy / format / measurement / review_process / other から選ぶ。
2. 対象の商材、国・地域、広告の種類、条件の文言を取り出す。
3. 投稿日と、適用の時期を取り出す。
4. 商材が書かれていれば、商材の区分で広告主の一覧を引く。
5. 国・地域が書かれていれば、配信国で広告主の一覧を引く。
6. 広告の種類が書かれていれば、媒体と広告の種類で広告主の一覧を引く。
7. 同じポリシーについての過去のお知らせの記録を引く。

【厳守事項】
- 商材、国、条件、日付は、本文に書かれた文言をそのまま写してください。
- 適用の時期が「上旬」「早期」のように書かれていても、日付に直さないでください。
  書かれていなければ「記載なし」とし、check_points に書いてください。
- 日付と対象国は英語版の記述から写し、日本語版と食い違うときは
  translation_gap にその箇所を両方とも写してください。
- 広告主の広告が違反する・しないの結論を書かないでください。
  match_basis に、どの道具で何が一致したか（category / country / ad_type）だけを書いてください。
- 「事前の承認を得た場合」「一部の国で」などの条件があるときは、
  condition_text に写し、check_points に条件の確認を書いてください。
- 一致した広告主がいないときも、no_match_reason に理由を書いてください。
- 本文に無いポリシーの内容を、一般的な知識で補わないでください。

【出力】指定のJSONの形で返してください。

「日付に直さない」を書くのは、「上旬」を1日に置くと、並べ替えで実際より早く見えるからです。 逆に「下旬」を末日に置くと遅く見えます。読み替えの規則はワークフローの側に1つだけ置き、エージェントには触らせません。

「一般的な知識で補わない」も明記します。 媒体のポリシーは改定をくり返しており、生成AIが知っている内容は古いことがあります。根拠はその週に取った本文だけにします。

出力形式を固定する

Structured Output Parser で、次の形のJSONを返させます。

{
  "platform": "", "source_url": "", "title_ja": "", "title_en": "",
  "notice_type": "policy | format | measurement | review_process | other",
  "posted_text": "", "effective_text": "",
  "categories": [""], "countries": [""], "ad_types": [""],
  "condition_text": "", "translation_gap": "",
  "matches": [
    { "advertiser": "", "owner": "", "match_basis": "category | country | ad_type",
      "matched_value": "", "previous_notice": "" }
  ],
  "no_match_reason": "",
  "check_points": [""]
}

Structured Output Parser は、JSON スキーマに沿った項目を返させる部品で、JSON の例からスキーマを作る方法と、JSON スキーマを直接書く方法があります。例から作るとすべての項目が必須として扱われ、直接書く場合は$ref による参照に対応していないとされています。スキーマは入れ子のまま書きます。

1つ目の理由は、match_basis で確からしさを分けられることです。 商材の区分と配信国の両方で一致した広告主は確度が高く、片方だけのものは人が確かめる前提です。同じ広告主が複数の道具で当たったら、ワークフローの側で1行にまとめ、一致した根拠を並べます。

2つ目は、effective_text で並べられることです。

3行目を別に立てるのは、計測の仕様の変更は審査落ちに表れず、成果の数字が静かにずれるだけだからです。

システムへ連携する

影響の候補の一覧への書き込みは、ワークフローの側で行います。 Postgres ノードはAIエージェントの道具として使え、多くのパラメーターをAIの指示で設定できるとされていますが、エージェントに渡す道具は Select と Execute Query だけにします。 Execute Query では、Options の Query Parameters に値を渡す形を使います。公式の説明では、クエリパラメーターのデータは n8n が無害化し、SQL インジェクションを防ぐとされています。媒体のページから取った文字を、問い合わせの文にそのまま埋め込まないでください。

通知は運用担当ごとに分けます。 全体の一覧を30名に流すと、第3章の状態に戻ります。運用推進チームには全体の一覧を、運用担当には確認を済ませた自分の広告主の分だけを出します。

人が確認する

1. 並べ順の1と2を、その週のうちに見る … 本文と条件の文言を読み、候補の広告主が本当に対象かを決めます
2. translation_gap を確かめる … 日本語版と英語版の食い違いを、英語版で読み直します
3. 条件付きの更新を判断する … 「事前の承認を得た場合」のような条件が、広告主の配信に当てはまるかを見ます。ここが運用推進チームの仕事の中心です
4. 運用担当に渡す … 対象と判断した広告主の担当に、お知らせのURLと確かめる点を渡します
5. 判断を記録する … 対象かどうか、渡した相手、運用担当の対応を一覧に残します

3番目を省かないでください。 エージェントの候補は、商材の区分や国が一致したということしか意味しません。候補に挙がったことは、影響があることを意味しません。

目標は、1件をならして9分です。 取り出しの結果と本文の確認に4分、候補の広告主の判断に3分、運用担当への受け渡しと記録に2分という見込みです。

例外に対処する

上から2行目は、媒体のヘルプセンターの模様替えのときに起きます。 Tools Agent の Max Iterations は、答えを出すまでにモデルを何回動かすかの上限で、既定は10です。件数の上限と回数の上限の2つで、暴走を止めます。

記録を残す

• 実行ごとの、媒体ごとの取得の成否と、新しく拾ったお知らせの一覧
• 取った本文（日本語版と英語版）と、本文のハッシュ
• エージェントのJSON出力と、呼んだ道具の順番
• 運用推進チームの判断 … 対象かどうか、渡した運用担当、判断した日
• お知らせの投稿日、見回りで拾った日、適用の時期、運用担当が対応を終えた日

最後の行が、この構成の物差しです。 適用の何日前に拾い、何日前に対応を終えたかを並べると、見回りが遅れているのか、社内の受け渡しが遅れているのかが分かれて見えます。