欧州で出稿している競合の広告をMetaの広告ライブラリのAPIから毎週取得し、訴求・オファー・クリエイティブの変化を要約して広告主の担当に知らせる

処理の起点を決める

毎週月曜の朝7時に、Schedule Trigger で動かします。 Schedule Trigger はワークフローのタイムゾーンを使い、無ければインスタンスのタイムゾーンを使います。セルフホストの既定は America/New York なので、ワークフローのタイムゾーンを Asia/Tokyo にします。 保存して公開しないと動きません。

週1回にしているのは、広告主への報告が週次だからです。 広告主8社の取得を同じ時刻に始めると呼び出しが重なるので、広告主ごとに数分ずつずらして順に取ります。 毎日取っても、報告に載せるのは週の変化です。ただし、配信の開始と終了の日時を持っているので、週の途中で出て週の途中で止まった広告も拾えます。 月曜の実行では、前の週の月曜から日曜までに配信があった広告を取ります。

広告主から「競合の大型の値引きが始まったらすぐ知りたい」と頼まれている場合は、その広告主だけ別の Schedule Trigger で平日の朝に取り、オファーの分類が「値引き」の新しい広告があれば知らせます。

入力データを集める

質を決めるのは、分類表です。 「価格」とだけ書くと、値引きも高級感の訴えもまとめて価格になります。「値引き：割引率・金額の明記、期間の限定がある」「価格の正当化：高い理由を説明する」のように、手がかりまで書きます。 分類がそろえば、第3章の（d）のばらつきが消えます。

前の週までの分類は、変化を言うために持ちます。 同じ競合が先週も値引きをしていれば、今週の値引きは「新しい打ち出し」ではなく「継続」です。

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

広告は、HTTP Request ノードで ads_archive を呼んで取ります。 主な指定は次のとおりです。

search_terms での検索は使いません。 公式のページでは、キーワードの検索は翻訳されないとされ、広告の言語で書かないと当たりません。 ドイツ語とフランス語の広告を日本語の競合名で探すと漏れます。ページIDなら言語に関係なく取れます。

結果は複数のページに分かれて返ります。 HTTP Request の Pagination を Response Contains Next URL にして、応答の次のページのURLをたどります。ページ送りを設定しないと、最初の一部だけで止まります。

配信の開始日と作成日は別物です。 返る項目には、広告が作られた日時（ad_creation_time）と、配信を始めたい日時（ad_delivery_start_time）があり、公式のページでは作成日時は配信された日時と異なることがあるとされています。「今週出た広告」は、配信の開始日時で判断します。 作成日時で見ると、前から用意されていた広告が今週出たときに「古い広告」と扱われます。

呼び出しの回数が上限に当たると、エラーコード613が返ります。 公式のページは、APIの呼び出しが上限を超えたときのエラーとしてこのコードを挙げています。広告主ごとに呼び出しの間をあけ、613が返ったら待ってから取り直します。

AIへ渡す前に整形する

1. 新しい広告と止まった広告を分ける … Remove Duplicates の Remove Items Processed in Previous Executions で、Keep Items Where を Value Is New、Value to Dedupe On を広告IDにして、新しく見た広告を残します。前の週の一覧にあって今週の配信が無いものを、止まった広告にします
2. 配信の終了日を見る … ad_delivery_stop_time が空の広告は、止めるまで配信される広告です。週の中に終了日があれば止まった広告に入れます
3. 広告文を束ねる … 広告文とリンクの見出しを正規化し（記号と空白をそろえる）、同じ競合の中で文が同じものを1つの束にします。言語が違う同じ訴求は、エージェントに束ねさせます
4. 広告主ごとにまとめる … 1人の広告主の競合の、新しい束と止まった束を1つの入力にします
5. 表示のURLを付ける … 束ごとに代表の広告の ad_snapshot_url を付け、担当者が確かめられるようにします

束ねる処理は Code ノードで書きます。 正規化した広告文と見出しをつないだ文字列を鍵にして、同じ鍵の広告を1つの束にし、本数、言語の一覧、配信面の一覧、配信の開始日の最も早い日を束に持たせます。束の鍵は前の週の記録にも残し、翌週に同じ鍵の束が出たら「継続」の手がかりにします。

3番目を省くと、エージェントに同じ広告が何十本も渡ります。 費用がかかるだけでなく、「新しい広告が40本」という要約が出て、変化の大きさを読み違えます。 文が完全に同じものは規則で束ね、言語違いだけをエージェントに任せます。

AIに処理させる

させるのは、広告主ごとに、新しい束と止まった束の訴求とオファーを分類し、前の週までと比べて何が変わったかを日本語で要約することです。

根拠の文は、原文のまま抜き書きさせ、日本語の訳を別に付けさせます。 訳だけを残すと、値引きの条件（「2点目」「初回のみ」）が訳で落ちたときに気づけません。 ワークフローの側で、抜き書きが広告文の中にそのまま含まれるかを確かめます。

2行目がいちばん起きやすい失敗です。 新しい広告が多い競合について、エージェントは「出稿を強化している」と書きたがります。本数が多いことは、予算が増えたことを意味しません。 書けるのは本数とEUでの推定リーチの範囲までです。

指示内容を固定する

あなたは広告会社の運用部で、欧州向けに販売する広告主のために、
競合が新しく出した広告と止めた広告を調べる担当です。
入力の広告文と、道具で確かめた事実だけで答えてください。

【入力】
- 広告主：{client}（販売国：{countries}）
- 競合ごとの新しい束：{new_groups}
  （束ID、代表の広告文、見出し、言語、配信の開始日、本数、
    EUでの推定リーチ）
- 競合ごとの止まった束：{stopped_groups}

【使える道具】
- get_taxonomy：訴求とオファーの区分と、判断の手がかりを返す
- get_history：競合名を渡すと、前の週までの束と分類を返す
- get_products：広告主の商品の種類と価格帯を返す

【進め方】
1. 新しい束のうち、言語だけが違う同じ訴求をまとめてください。
2. 束ごとに、訴求とオファーを分類表の区分から選んでください。
   根拠の文を原文のまま抜き書きし、日本語の訳を別に付けてください。
3. get_history で前の週までと比べ、new / continued / dropped を
   付けてください。
4. 広告主の商品と重なる変化を挙げ、日本語で要約してください。

【厳守事項】
- 区分は分類表にあるものだけを使ってください。当てはまらなければ
  other とし、理由を書いてください。
- 画像・動画の内容を推し量らないでください。
- 広告費・予算・配信量の増減を書かないでください。
  本数とEUでの推定リーチの値だけを書いてください。
- 値引きの率・金額・条件は、広告文にあるとおりに写してください。
  訳で条件を省かないでください。
- 競合の狙いや戦略を断定しないでください。
- 広告主への提案を書かないでください。

「値引きの条件を訳で省かない」を明記しないと、「2点目半額」が「半額」になります。 広告主が受け取る報告で、最も読み違えると困る部分です。

「区分は分類表にあるものだけ」も明記します。 エージェントは気の利いた新しい区分を作りがちで、それをすると、先週の「価格」と今週の「お得感」が比べられなくなります。

出力形式を固定する

Structured Output Parser で、次の形のJSONを受け取ります。

{
  "client": "",
  "week": "2026-09-28/2026-10-04",
  "competitors": [
    {
      "name": "",
      "groups": [
        {
          "group_id": "",
          "status": "new | continued | dropped",
          "languages": ["de", "fr"],
          "ad_count": 0,
          "appeal": "",
          "offer": "",
          "quote_original": "",
          "quote_ja": "",
          "snapshot_url": ""
        }
      ],
      "summary_ja": ""
    }
  ],
  "overlap_with_client": [],
  "needs_human": false
}

1つ目の理由は、status で週の変化を規則で数えられることです。 報告の冒頭の「新しい打ち出し：3社5件」は、ワークフローが status から数えます。数字をエージェントに書かせません。

2つ目は、quote_original と quote_ja を分けていることです。 担当者は原文と訳を並べて見られ、条件の落ちた訳にすぐ気づけます。

3つ目は、snapshot_url で表示を開けることです。 公式のページでは、表示のURLは圧縮していないメディアで広告を表示するものとされ、ダウンロードしたクリエイティブは分析に使い、利用規約に従うことが求められています。

Structured Output Parser の Generate From JSON Example では、すべての項目が必須として扱われるとされています。空のときは空文字や空の配列を返させます。

システムへ連携する

広告主へは自動で送りません。 下書きの表から担当者が報告を作り、上長が見てから送ります。分類の誤りが、そのまま広告主の判断材料になるのを止めるためです。

人が確認する

人が見るのは、status が new の束と、needs_human が立った広告主です。 continued は件数を流し見、dropped は代表の広告文だけを読みます。

1. new の束の表示を開く … snapshot_url で画像・動画を見て、訴求とオファーの分類が合っているかを確かめます
2. 原文と訳を見比べる … 値引きの率・条件が訳に残っているかを見ます
3. 広告主にとっての意味を一言書く … この一言は担当者が書きます
4. 分類を直したら記録する … どの束の、どの区分を、どう直したかを残します

4番目は、分類表を直す材料になります。 同じ直しが続く区分は、手がかりの書き方が足りていません。

1番目で、表示を開くのは束の代表の1本だけです。 同じ束の他の広告は、画像だけを差し替えていることがあります。画像の違いが報告に要る広告主では、束の全部の表示を開く週を月1回だけ設けます。

目標は、32件をならして1件15分です。 新しい打ち出しの多い週は30分近く、変化の少ない週は数分で終わります。

例外に対処する

1行目は、この構成の範囲の外にいる競合を見つける合図です。 日本国内だけに広告を出している競合は、何度呼んでも0件です。0件が続く競合は、一覧から外すか、画面で見る対象に分けます。

記録を残す

• 実行の日時、広告主ごとの呼び出しの条件と、返った広告の件数
• 広告IDごとの、広告文、見出し、配信の開始・終了、表示のURL、初めて見た週
• 束の内容と、エージェントの入力
• 道具の呼び出しの記録と、結果のJSONの全文、抜き書きの照合の結果
• 担当者が直した分類と、報告に書いた一言
• 広告主へ送った報告の版

2つ目は、広告ライブラリから広告が見えなくなった後も、比較を続けるために残します。 Tools Agent の Return Intermediate Steps を有効にすると、途中の手順も残せます。