広告会社が運用する広告主のLPを、エージェントが毎日見回り、リンク切れ・計測タグの欠落・フォームの不具合・掲載終了したキャンペーンの残りを拾って、修正依頼の案を作る

処理の起点を決める

n8n の Schedule Trigger で、毎朝6時に動かします。 cron 式は (秒) 分 時 日 月 曜日 の欄で書き、秒の欄は省略できるとされています。毎日6時なら 0 6 * * * です。LPは週末にも広告から人を受けるので、土日も動かします。

ワークフローのタイムゾーンを Asia/Tokyo にします。 設定が無いとインスタンスのタイムゾーンが使われ、自分でホストする場合の既定は America/New York とされています。前日の送信の数を取る範囲が、日本の1日とずれます。 Schedule Trigger を使うワークフローは、保存して公開しないと動きません。

入力データを集める

質を決めるのは、LPの台帳の「入っているはずのタグのID」と、キャンペーンの台帳の「表記の文字列」です。 IDが台帳に無ければ、タグが入っているかは分かっても、正しいタグかどうかは分かりません。 表記の文字列が無ければ、終了したキャンペーンをページの文字から探せません。

サイト更新の連絡は、担当者に書いてもらいます。 予定されたメンテナンスで一時的に開かないのは、修正依頼を送る話ではありません。予定が書かれていないと、広告主へ同じ連絡を毎回送ることになります。

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

取得は、ワークフローの冒頭で全LP分を決まった手順で行います。 ここはエージェントに任せません。キャンペーンの台帳やサイト更新の予定は、冒頭では読みません。 不具合の出たLPについてだけ、エージェントが道具で引きます。

HTMLで見えるタグには限りがあります。 タグ管理の仕組みを使っているサイトでは、解析や媒体のタグはページを開いた後にスクリプトで読み込まれ、取得したHTMLには、タグ管理のコンテナの読み込みの部分しか現れません。 そのため、HTMLで確かめるのはコンテナのIDまでとし、その先のタグが動いているかは、解析の送信の数で裏付けます。

リクエストには、自社の見回りであることが分かる User-Agent を付けます。

AIへ渡す前に整形する

1. 状態コードの確認 … 200以外のLPと、トップページなど台帳と違うURLに転送されたLPを拾います
2. リンク先の確認 … ページ内のリンクのうち、同じサイトの中と、申込・予約などの主要な遷移先の状態コードを確かめます。外部のSNSの共有ボタンなどは対象から外します
3. タグのIDの照合 … 台帳のIDがHTMLの script の src や本文に含まれるかを見ます。別のIDが入っているものも拾います
4. フォームの送信先の確認 … form の action が台帳の送信先と違う、または action が空のフォームを拾います
5. 送信の数の変化の計算 … 前日の送信の完了の数を、直近7日の平均と比べます。平均が数件に満たないLPは、急減の判定から外します
6. 終了したキャンペーンの表記の検索 … 終了日を過ぎたキャンペーンの表記の文字列が、ページの文字に残っているかを探します
7. 台帳との突き合わせ … 同じLP・同じ種類の不具合で、修正を依頼中のものは外し、状態が変わったものだけを残します

3番目で「別のIDが入っている」を拾うのが、目視では難しかった点です。 制作会社が別の広告主のLPを複製して作ると、元の広告主のタグのIDが残ったまま公開されることがあります。タグはあるので、有無だけの確認では通ってしまいます。

5番目の「数件に満たないLPを外す」を省くと、一覧が揺れで埋まります。 送信が1日に1〜2件のLPでは、0件の日は珍しくありません。こうしたLPは、7日続けて0件になったときに拾う規則にします。

AIに処理させる

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

どの道具を呼ぶかを決めるのが、エージェントの仕事です。 LPが開かないなら refetch_page で一時的なものかを確かめ、次に get_site_updates で予定を見る。タグのIDが無いなら get_ga4_events で計測が本当に止まっているかを見る。送信の数が普段どおりなら、タグの入れ方が変わっただけかもしれません。

2行目は、指示ではなく道具の作りで守ります。 HTTP Request の道具に POST の操作を持たせなければ、エージェントがフォームを送ることはできません。 フォームの送信の不具合は、解析の送信の完了の数で間接に見ます。広告主がテスト用の送信の仕組みを用意している場合だけ、別の手順として人が試します。

指示内容を固定する

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

あなたは広告会社の運用部で、広告の遷移先のLPの毎朝の見回りを手伝う立場です。
渡された不具合1件について、道具を使って事実を集め、原因の候補と、
広告主のWeb担当へ送る修正依頼の案をまとめてください。

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

【道具の使い方】
- まず get_past_issues と get_site_updates を見てください
- ページが開かない・転送されているときは、refetch_page で取り直してください
- タグのIDが無いときは、get_ga4_events で送信の数が止まっているかを見てください
- 終了した表記が残っているときは、get_campaign で終了日を確かめてください
- 同じ道具を同じ条件で2回呼ばないでください

【原因の候補の書き方】
- 候補は1〜3個までにし、すべてに根拠の事実を evidence として付けてください
- 道具で得た事実に根拠が無い原因は、候補に入れないでください
- 根拠が見つからないときは、候補を空にし、cause_unknown を true にしてください

【修正依頼の案の書き方】
- 宛先は広告主のWeb担当です。丁寧な言葉で、どのURLの、どの箇所が、
  どうなっているかを、事実だけで書いてください
- 「直してください」と断定せず、「ご確認をお願いできますでしょうか」の形にしてください
- 終了した表記については、残っている文字列と、台帳の終了日を書き、
  法令に違反しているかどうかは書かないでください
- 広告を止める・止めないについては書かないでください

【不具合】{issue_json}

「法令に違反しているかどうかは書かない」を入れないと、修正依頼の案に「景品表示法上問題となるおそれがあります」と書かれます。 判断としてはありえても、運用担当から広告主へ送る文面としては、責任の取れない断定です。 事実と終了日を書けば、広告主の側で判断できます。

「根拠が無ければ空にする」は、エージェントに必ず書かせる一行です。 書かないと、「サイトの改修によるものと考えられます」のような、確かめようのない候補で埋めます。 担当者はそれを読んで調べるのをやめてしまいます。Tools Agent には答えを作るまでの繰り返しの上限（Max Iterations、既定は10）があり、上限に達したものも cause_unknown として一覧に出します。

出力形式を固定する

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

{
  "lp_id": "",
  "url": "",
  "issue_type": "page_down | redirected | broken_link | tag_missing | tag_mismatch | form_action | form_drop | expired_campaign",
  "severity": "critical | high | normal",
  "what_happened": "",
  "cause_candidates": [
    { "cause": "", "evidence": "", "source": "refetch | links | ga4 | campaign | site_update | past_issue" }
  ],
  "cause_unknown": false,
  "request_draft": "",
  "tools_called": [ "" ]
}

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

2つ目は、source で根拠の種類が分かることです。 担当者は、候補が解析の数値から来たのか、更新の予定から来たのかを見て、どこを確かめればよいかがすぐ分かります。 途中でたどった手順は、Return Intermediate Steps を有効にして受け取ります。

critical のものは、朝の一覧を待たずに担当者へ直接通知します。 広告は止めていないので、気づくのが1時間遅れれば、その分の広告費が壊れたLPへ流れます。

システムへ連携する

広告主のサイトには、取得以外の操作をしません。 HTTP Request の道具は GET だけにし、フォームの送信も、ログインも、設定の変更もできない作りにします。

修正依頼も、自動では送りません。 案は一覧に置き、担当者が直して自分のメールから送ります。広告主のWeb担当とのやり取りは、運用担当の関係そのものです。 誤った依頼が1通届くと、次の依頼から読まれなくなります。

人が確認する

担当者が見るのは、自分の受け持ちの朝の一覧だけです。

1. critical を最初に見る … LPを自分のブラウザで開いて確かめます。本当に開かないなら、広告を止めるかを広告主とすぐに相談します
2. high の原因の候補を確かめる … タグのIDの食い違いは、ページのソースで目で確かめます。終了した表記は、ページのどこに残っているかを見ます
3. cause_unknown のものを自分で調べる … エージェントが根拠を見つけられなかったもの。担当者の経験の出番はここです
4. 修正依頼の案を直して送る … 宛先と、指摘の箇所を確かめてから送ります
5. 原因の候補が当たっていたかを記録する … 当たった、外れた、別の原因だった、を不具合の台帳に残します

1番目の「自分のブラウザで開く」を省かないでください。 見回りのサーバーからの取得だけが、広告主のサイトの防御の仕組みで拒まれている場合があります。利用者には開けているのに、修正依頼を送ってしまうことを防ぎます。

月に1回は受け持ちの全LPを流し見ます。 見た目の崩れや文章の誤りは、規則では拾えないからです。

例外に対処する

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

記録を残す

• 毎朝の取得の結果（状態コード、最後に着いたURL、取り出したリンク・タグのID・フォームの送信先）
• 取得したHTMLの写し（不具合の出たLPのもの）
• 規則で拾った不具合と、そのとき使った台帳の内容
• エージェントの入力、呼んだ道具とその結果（Return Intermediate Steps で取得）、出力のJSON
• 送った修正依頼の文面と日時、直った日
• 原因の候補が当たっていたか

2つ目の「HTMLの写し」は、直された後でも、どこがどう壊れていたか、表記がいつまで残っていたかを示すために残します。