運用している広告アカウントの前日の数値をエージェントが毎朝見回り、予算消化・CPA・配信停止・不承認の異常に原因の候補と対応の案を付ける

処理の起点を決める

n8n の Schedule Trigger で、営業日の毎朝7時30分に動かします。 Schedule Trigger は、秒・分・時・日・週・月の間隔と、カスタムの cron 式に対応しています。cron 式は (秒) 分 時 日 月 曜日 の6つの欄で、秒の欄は省略できるとされています。月曜から金曜の7時30分なら 30 7 * * 1-5 です。

タイムゾーンを必ず設定してください。 Schedule Trigger は、ワークフローにタイムゾーンが設定されていればそれを、なければインスタンスのタイムゾーンを使います。自分でホストする場合の既定は America/New York、n8n Cloud は登録時に検出を試み、できなければ GMT とされています。ワークフローのタイムゾーンを Asia/Tokyo にします。 忘れると、朝の見回りが夜中に動き、「前日」の範囲がずれます。

保存して公開しないと動きません。 Schedule ノードをトリガーにするワークフローは保存して公開するよう注意書きがあり、cron 式に変数を使った場合は、その値が公開の時点で評価されるとされています。時刻を変えたら公開し直します。

7時30分にするのは、出社前に一覧をそろえるためです。 取り込んだ前日の値が朝のうちに管理画面の値と変わっていないかを試しの期間に確かめ、時刻を決めます。

入力データを集める

質を決めるのは、作業記録と広告主の予定の2つです。 この2つが無ければ、エージェントは数値だけから原因を推し量るしかなく、「入札の変更によるものと考えられます」のような、根拠の無い候補を出します。 作業記録に「いつ、誰が、何を変えたか」が残っていれば、候補は記録を指して書かれます。

広告主の予定は、担当営業に書いてもらいます。 セールの終わりでCPAが上がるのは異常ではありません。予定が書かれていないと、毎月同じ時期に同じ「異常」が上がり、一覧が読まれなくなります。

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

数値と状態は、ワークフローの冒頭で全アカウント分を取ります。 ここは決まった手順なので、エージェントに任せません。作業記録と広告主の予定は、冒頭では読みません。 異常の出たアカウントについてだけ、エージェントが道具で引きます。120アカウント分の記録を毎朝まるごと生成AIへ渡さないためです。

取り込んだ前日の数値は、毎朝保存しておきます。 直近28日の比較を毎回 API から取り直すと呼び出しが増え、後から値が変わっていた場合に比べる基準が日によって変わります。

AIへ渡す前に整形する

1. 金額の換算 … Google Ads API の micros を円に直します。Meta の金額の単位もそろえます
2. 消化のペースの計算 … 月の予算、月の途中の増減、経過日数から、前日時点で使っているはずの額を出し、実際の費用と比べます
3. CPAの変化の計算 … 前日のCPAを、直近7日の平均と、前週の同じ曜日と比べます
4. 表示回数の急減の検出 … 配信中のキャンペーンで、前日の表示回数が0か、直近の平均から大きく下がったものを拾います
5. 状態の異常の検出 … 不承認、支払いの問題、WITH_ISSUES などを拾います
6. 少ない数での揺れを外す … コンバージョンが数件のアカウントでは、1件の差でCPAが倍になります。一定の件数に満たないものは、CPAの変化としては拾いません
7. 台帳との突き合わせ … 同じアカウント・同じ種類の異常で、対応中のものは外します。状態が変わったものだけを残します

2番目で、予算の増減を必ず入れてください。 月の途中で増額されたのに元の予算で計算すると、正常な消化を「早すぎ」として毎日拾います。 予算表に増減の日付と額の列を持たせます。

6番目を省くと、一覧が小さなアカウントの揺れで埋まります。 コンバージョンの少ないアカウントは、CPAではなく費用とクリック数の変化で見ます。 閾値は、試しの期間に拾った件数を見て決めます。

AIに処理させる

させるのは、規則で拾った異常1件ごとに、必要な道具を選んで事実を集め、次の4つを組み立てることです。

どの道具を呼ぶかを決めるのが、エージェントの仕事です。 不承認なら get_policy_detail、コンバージョンだけが急に0になったなら check_landing_page と get_change_log を先に呼ぶ、というように、異常の種類と、呼んだ結果によって次に呼ぶものが変わります。 これを固定の手順で書くと、分岐が異常の種類の数だけ増えます。

3行目は、指示ではなく道具の作りで守ります。 指示で「変更しないでください」と書いても、変更できる道具がつながっていれば呼ぶことがあります。API の認証情報を読み取りの権限だけにし、書き込みの道具をそもそもつながないのが確実です。

指示内容を固定する

AI Agent ノードの System Message に次を入れます。

あなたは広告代理店の運用部で、毎朝の見回りを手伝う立場です。
渡された異常1件について、道具を使って事実を集め、
原因の候補と、担当者が取るべき対応の案をまとめてください。

【異常は判定済みです】
異常の種類、数値、急ぎの度合いは、規則ですでに決まっています。
それらを変えたり、異常ではないと判断したりしないでください。

【道具の使い方】
- まず get_past_incidents で、同じアカウントの過去の同じ種類の異常を見てください
- 数値の変化なら get_change_log と get_client_calendar を見てください
- 不承認なら get_policy_detail を見てください
- コンバージョンが急に減ったなら check_landing_page を見てください
- 同じ道具を同じ条件で2回呼ばないでください

【原因の候補の書き方】
- 候補は1〜3個までにしてください
- すべての候補に、根拠にした記録を evidence として付けてください
  （作業記録の日時と内容、予定の名前、ポリシーの名称、状態コードなど）
- 道具で得た記録に根拠が無い原因は、候補に入れないでください
- 根拠が見つからないときは、原因の候補を空にし、
  cause_unknown を true にしてください。推測で埋めないでください
- 媒体の仕組みの変更や競合の動きなど、確かめようのない原因を書かないでください

【対応の案の書き方】
- 担当者が確かめること、担当営業に聞くことを分けて書いてください
- 予算を増やす・減らす、配信を止めるといった判断を、結論として書かないでください。
  「〜を確かめる」「〜を検討する」の形にしてください

【異常】{anomaly_json}

「根拠が無ければ空にする」を書かないと、エージェントは必ず何かを書きます。 作業記録にも予定にも手がかりが無いとき、「季節要因」「競合の出稿の増加」のような、確かめようのない候補で埋めます。 担当者はそれを読んで、調べるのをやめてしまいます。分からないことを分からないと返させることが、この一覧を信用してもらう条件です。

「同じ道具を2回呼ばない」は、繰り返しを止めるためです。 Tools Agent には、答えを作るためにモデルを何回回すかの上限（Max Iterations）があり、既定は10とされています。見回りでは、異常1件あたり道具を5回ほど呼べば足りるので、上限を下げておきます。 上限に達したものは、cause_unknown として一覧に出します。

出力形式を固定する

Tools Agent の「Require Specific Output Format」を有効にし、Structured Output Parser をつなぎます。 次の形のJSONで受け取ります。

{
  "account_id": "",
  "platform": "google | meta",
  "anomaly_type": "budget_pace_fast | budget_pace_slow | cpa_spike | impressions_drop | disapproved | billing | delivery_issue",
  "severity": "critical | high | normal",
  "what_happened": "",
  "cause_candidates": [
    { "cause": "", "evidence": "", "source": "change_log | calendar | policy | landing_page | past_incident" }
  ],
  "cause_unknown": false,
  "actions": {
    "check_by_operator": [ "" ],
    "ask_sales": [ "" ]
  },
  "tools_called": [ "" ]
}

1つ目の理由は、severity と anomaly_type を規則の側から持ち込めることです。 この2つはエージェントに渡した値をそのまま返させ、ワークフローの側で、渡した値と返ってきた値が同じかを確かめます。 違っていれば、エージェントが判定を書き換えたということなので、その行は差し戻します。

2つ目は、source で根拠の種類が分かることです。 担当者は、候補が作業記録から来たのか、予定から来たのかを見て、どこを確かめればよいかがすぐ分かります。

critical のものは、朝の一覧を待たずに担当者へ直接通知します。

システムへ連携する

媒体の API には書き込みません。 認証情報は読み取りの権限に絞り、この構成から予算も入札も配信の状態も変えられないようにします。 自動のルールで予算を動かしたいなら、それは媒体の機能で、人が条件を決めて設定するものです。

作業記録にも書き込みません。 作業記録は運用担当が書くもので、エージェントの出力を混ぜると、「誰が何を変えたか」の記録に、変えていないことが紛れ込みます。

人が確認する

運用担当が見るのは、自分の担当分の朝の一覧です。全アカウントを開くことはしません。

1. critical を最初に見る … 配信の停止、支払い、不承認。すぐに管理画面を開いて状態を確かめます
2. high の原因の候補を確かめる … evidence の記録を見て、候補が当たっているかを判断します
3. cause_unknown のものを自分で調べる … エージェントが根拠を見つけられなかったもの。経験の出番はここです
4. 対応を決めて実行する … 予算や配信の変更は、広告主との約束の範囲で担当者が行います
5. 候補が当たっていたかを記録する … 当たった、外れた、別の原因だった、を台帳に残します

5番目を省かないでください。 この記録が get_past_incidents の中身になり、次に同じアカウントで同じ異常が出たとき、エージェントが最初に見る根拠になります。 記録がたまるほど、候補が当たるようになります。

一覧に何も無いアカウントは開きません。 ただし週に1回、受け持ちの全アカウントを流し見る時間を別に取ります。 規則の閾値に掛からない緩やかな悪化は、この一覧では拾えないからです。

例外に対処する

1行目がいちばん大事です。 取得に失敗したアカウントが一覧に何も出ないと、担当者は「異常なし」と読みます。 失敗は、異常よりも目立つ場所に出します。

3行目は、媒体の側の障害の日のためです。 多くのアカウントで同時に表示回数が落ちた日は、1件ずつ原因を探しても答えは出ません。 まとめて知らせ、人が判断します。

記録を残す

• 毎朝取り込んだ数値と状態（アカウント・日付ごと）
• 規則で拾った異常と、そのとき使った閾値と予算表の内容
• エージェントの入力、呼んだ道具とその結果（Return Intermediate Steps で取得）、出力のJSON
• 担当者が取った対応と、原因の候補が当たっていたか
• 取得に失敗したアカウントと、その理由

3つ目の「呼んだ道具とその結果」は、Tools Agent の Return Intermediate Steps を有効にして残します。 エージェントが途中でたどった手順を最終の出力に含める設定です。候補が外れたときに、どの記録を見てその候補を出したのかを後から追えます。 外れの理由が、記録の不足なのか、読み違いなのかで、直す場所が変わります。