家電・日用品のリコールの公表をエージェントが毎日見回り、自社の取扱商品と販売の記録に照らして、該当しそうな商品を品質の担当に届ける

処理の起点を決める

毎日朝6時と午後1時に、Schedule Trigger で動かします。 朝6時は開店前に店舗へ知らせるため、午後1時は午前中に載ったリコールを夕方の売場の点検の前に拾うためです。週末と祝日も止めません。 店舗は営業しているからです。

Schedule Trigger は、ワークフローのタイムゾーンが無ければ n8n のインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。ワークフローのタイムゾーンを Asia/Tokyo にし、保存して公開します。公開しないと Schedule Trigger は動かないとされています。1つの Schedule Trigger に複数の実行の規則を足せるので、6時と13時の2つの規則を置きます。

リコール情報サイトには、リコール情報メールサービスもあります。 品質管理部の共有のメールボックスで受け取っておき、ワークフローが止まったときの控えとして人が見るようにします。

このワークフローが止まったことに、人が気づける仕組みを必ず作ります。 朝6時の実行が終わったら、件数がゼロでも「本日の見回り完了（新しいリコール 0件）」をチャットに出します。通知が来ないこと自体が、止まった合図になります。

入力データを集める

質を決めるのは、そろえた型番の列です。 第3章の（b）のとおり、同じ型番でも空白や記号の入り方が違います。商品マスタに、空白・ハイフン・全角半角を取り除いた「そろえた型番」の列を毎晩作り、リコール側の型番も同じ規則でそろえてから引きます。

販売の記録は、明細ではなく商品ごとの集計で写します。 照合に要るのは、その商品をいつからいつまで、どこで、何個売ったかだけです。会員の購入履歴は写しに入れず、人が案内を決めたあとに別の手順で引きます。

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

一覧は60件ごとの表示で取り、1ページ目に前回の最新の管理番号が無ければ、次のページも取ります。 連休明けの朝は前回の続きが2ページ目に入ることがあります。ページを送るのは、前回の管理番号が見つかるまでにします。

詳細のページは、間隔を空けて1件ずつ取ります。 HTTP Request の Batching で、1回に送る件数と次の送信までの待ち時間を決められます。応答のヘッダーを待つ時間の上限を Timeout で決め、1件が止まっても全体を止めないようにします。

Code ノードは、JavaScript か Python を書いてワークフローの1段として動かせます。 詳細のページの HTML から、欄の見出しと、スクリプトに埋め込まれた文字を順に拾い、欄の名前と文字の組にそろえてからエージェントに渡します。 ページの作りが変わったときに直す場所を、この1か所にまとめます。

AIへ渡す前に整形する

1. 型番をそろえる … 空白、ハイフン、スラッシュ、全角・半角を取り除き、大文字にそろえます。リコール側と商品マスタ側の両方に同じ規則を当てます
2. 対象の特定情報を分ける … 「型番：」「販売期間：」「対象台数：」「製造番号：」のような見出しで行を分け、見出しと値の組にします。分けられない行もそのまま渡します
3. 期間を日付に直す … 「2025年2月～2025年9月」を、開始の月初と終了の月末に直します。直せないものは文字のまま残し、人が見ます
4. 自社ブランドを分ける … 事業者名が自社と同じものは、この流れから外し、自社ブランドの担当に回します
5. 写しの日付を確かめる … 前夜の商品マスタと販売の記録の写しが作られていなければ、照合を止め、「照合できていない」と通知します
6. スクリプトの文字が取れたかを確かめる … 対象の特定情報の欄が空なら、fields_missing を付けて人に回します

6番目は、ページの作りの変化に気づくための前処理です。 スクリプトの埋め込み方が変わると、エラーにならずに欄が空のまま流れます。空の欄で照合すると、型番が無いまま「当たらない」になります。

AIに処理させる

させるのは、リコール1件ごとに、事業者・商品・型番・期間・理由を取り出し、商品マスタと販売の記録を引いて該当の候補を挙げることです。

理由の区分を分けさせるのが、第3章の（d）への答えです。 発火・発煙・発熱とけが・感電は、急ぎの度合いを上げます。理由の文言は詳細のまま写させ、区分はその文言から選ばせます。

3行目が、この構成で特に大事な線です。 「W5PRO」のリコールに対して、商品マスタに「W5PRO-BK」「W5PRO-WH」があれば、前方一致の候補として挙げさせますが、「末尾の色違いも対象」とは書かせません。 対象かどうかは、詳細の文と事業者の公表で人が確かめます。

指示内容を固定する

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

あなたはホームセンターのチェーンの品質管理部で、消費者庁のリコール情報サイトに
載ったリコールを、自社の取扱商品と販売の記録に照らす担当です。
入力は、新しく見つかったリコール1件の件名と、詳細のページの各欄の文字です。

【やること】
1. リコール事業者名、法人番号、商品名、製品名、型番、JANコード、製造番号、
   販売期間、対象台数、理由を取り出す。
2. 理由の区分を fire_smoke_heat / injury / electric_shock / malfunction /
   label / other から1つ選ぶ。
3. 型番があれば、そろえた型番で商品マスタを引く（一致と前方一致）。
4. メーカー名の対応表を引き、当たった事業者名で商品マスタを引く。
5. 当たった商品について、販売の記録を引き、店舗・通販別の販売の期間と数、
   在庫数を添える。
6. 過去の照合の記録を引き、同じ事業者・型番の前回の判断を添える。

【厳守事項】
- 事業者名、型番、期間、理由は、詳細に書かれた文言をそのまま写してください。
- 書かれていない型番や期間を推測しないでください。「記載なし」としてください。
- 型番の末尾に記号を足したり、取り除いたりしないでください。
- 事業者名か型番のどちらかが商品に当たったときは、candidates に必ず残して
  ください。色や容量の違いがあっても外さないでください。違いは
  check_points に書いてください。
- 該当する・しないの結論を書かないでください。match_basis に、
  何が一致したか（model_exact / model_prefix / jan / maker）だけを書いてください。
- 販売の期間がリコールの期間と重なるかを判断しないでください。
- 危険の大きさや、取るべき対応を書かないでください。
- 対象の特定情報の欄が空のときは、fields_missing を true にしてください。

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

「型番の末尾に記号を足したり、取り除いたりしない」が、この指示の要です。 エージェントは「W5 PRO」と「W5PRO」を同じとみなすのと同じ調子で、「W5PRO-BK」も同じ商品とみなして結論を書き始めます。 そろえる規則は前処理で決め、それ以上の近づけはさせません。

出力形式を固定する

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

{
  "recall_id": "", "title": "", "posted": "", "category": "",
  "company": "", "corporate_no": "", "product": "",
  "models": [""], "jan": [""], "serial": "",
  "sales_period_text": "", "units_text": "",
  "reason_text": "",
  "reason_type": "fire_smoke_heat | injury | electric_shock | malfunction | label | other",
  "fields_missing": false,
  "candidates": [
    { "item_code": "", "maker": "", "item_name": "", "model": "",
      "match_basis": "model_exact | model_prefix | jan | maker",
      "sales": [ { "channel": "store | online", "first_sold": "", "last_sold": "",
                   "units": 0, "stock": 0 } ],
      "previous_judgment": "", "check_points": [""] }
  ],
  "check_points": [""]
}

1つ目の理由は、sales の期間を規則でリコールの期間と比べられることです。 ワークフローは、前処理で直したリコールの期間と、first_sold・last_sold を比べ、重なる・重ならない・分からないの3つを付けます。第3章の（c）は、ここで解けます。

2つ目は、reason_type と match_basis と期間の重なりで、急ぎの順を規則で決められることです。 急ぎの度合いはAIに決めさせず、ワークフローが次の規則で付けます。

3つ目は、fields_missing で人が詳細のページを見るリコールを分けられることです。 対象の特定情報が取れなかったリコールは、型番の照合が効きません。

システムへ連携する

照合の一覧への書き込みは、ワークフローの側で行います。 エージェントの道具には写しを引く Select だけを渡します。Postgres ノードはAIエージェントの道具として使え、公式の説明では、クエリパラメーターのデータは n8n が無害化し、SQL インジェクションを防ぐとされています。詳細の文字を、そのまま問い合わせに埋め込まないでください。

店舗やお客さまへの連絡は、この構成から直接は出しません。 品質管理の担当者が候補を確かめ、店舗に在庫の確認を頼みます。会員への案内は、お客さま相談室が責任者の判断のあとに行います。

人が確認する

1. 至急から見る … 型番が一致して在庫があるもの、発火・けがの理由で候補があるものは、すぐに店舗と倉庫に在庫の確認を頼みます
2. 当日の候補を確かめる … 型番の前方一致や JANコードで当たったものは、詳細の文と事業者の公表で対象の型番を確かめます
3. 確認の候補を判断する … 事業者名だけが当たったものは、商品名と型番を見て自社の商品かを確かめます
4. 候補の無いリコールを流し見る … 1日1回のまとめで件名を見て、取引先なのに当たらなかったものがあれば、メーカー名の対応表に足します
5. 判断を記録する … 該当の有無、撤去、会員への案内の有無を照合の一覧に残します

4番目を省かないでください。 照合の漏れは、対応表の抜けと、型番の書き方の違いから起きます。人が件名を見て気づくことが、対応表と型番をそろえる規則を育てる経路です。

目標は、1件をならして6分です。 照合の結果の確認に4分、撤去と案内の材料の確認に2分という見込みです。

例外に対処する

7行目は、リコール情報サイトの説明にもとづく対応です。 サイトの説明では、公表した行政機関等や事業者から追加の情報があれば、掲載の内容を更新することがあるとされています。対象の型番が後から足されることもあるので、更新は新しいリコールと同じ重さで扱います。

記録を残す

• 実行ごとの取得の成否と、新しく拾った管理番号の一覧
• 取った詳細のページの各欄の文字
• エージェントのJSON出力と、呼んだ道具の順番、期間の重なりの計算の結果
• 人の判断 … 該当の有無、撤去、会員への案内の有無、判断した日時
• リコールの掲載日、拾った日時、店舗に連絡した日時、売場から下げ終えた日時

最後の行が、この構成の物差しです。 掲載から売場から下げ終えるまでの時間を並べると、見回りの遅れか、店舗での作業の遅れかが分かれて見えます。