飲食チェーン・食品小売の本部で、食品のリコール・自主回収の公表をエージェントが毎日見回り、自社の仕入品と照らして該当の疑いがある品目を品質管理へ知らせる

処理の起点を決める

毎日朝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章の（a）は、ここで解きます。

入力データを集める

質を決めるのは、メーカー名の対応表です。 第3章の（b）のとおり、公表と仕入品マスタでは同じ会社の書き方が違います。対応表に「◯◯食品」→「（株）◯◯食品工業」を持たせ、エージェントは対応表を先に引きます。 対応表は、候補の無かった公表の件名を人が流し見て気づいたものから足していきます。

入荷記録を直近90日に絞るのは、賞味期限の短い食材が大半だからです。 冷凍食品や調味料のように期限の長いものは、仕入品マスタの「期限の長い品」の印を見て、その品だけ1年分を引くようにします。

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

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

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

参照情報に厚生労働省の食品衛生申請等システムへのリンクがあれば、それも記録します。 対象の特定情報（JANコード、期限、ロット）が詳細のページの欄で読み取れないときに、人が確かめに行く先になるからです。

AIへ渡す前に整形する

1. 社名の書き方をそろえる … 「株式会社」「（株）」「㈱」、全角・半角、空白を外し、公表と仕入品マスタの両方を同じ規則でそろえます
2. 件名から事業者と商品を分ける … 件名は「事業者「商品名」（販売先）- 対応」の形が多いので、かぎ括弧で分けて取り出しの手がかりにします。分けられない件名もそのまま渡します
3. JANコードの形をそろえる … 公表の本文から13桁・8桁の数字を拾い、仕入品マスタの JANコードと同じ形にします
4. 日付をそろえる … 「2026年10月05日」「R8.10.5」「26.10.05」などを日付に直します。直せないものは文字のまま残し、人が見ます
5. 写しの日付を確かめる … 前夜の仕入品マスタと入荷記録の写しが作られていなければ、照合を止め、「照合できていない」と通知します
6. 画像だけの欄を見分ける … 対象の特定情報が画像で載っていて文字が取れないときは、target_in_image を付けて人に回します

5番目は、止めて知らせることを選んでいます。 古い写しで照合すると、昨日から仕入れ始めた食材が漏れます。リコールの照合で「該当なし」と出すことは、照合できないと知らせることより危険です。

AIに処理させる

させるのは、公表1件ごとに、事業者・商品・対象・理由を取り出し、仕入品マスタと入荷記録を引いて該当の候補を挙げることです。

理由の区分を分けさせるのが、第3章の（d）への答えです。 アレルギー物質の表示の欠落と、異物・微生物は、急ぎの度合いを上げます。理由の文言は公表のまま写させ、区分はその文言から選ばせます。

1行目が、この構成でいちばん大事な線です。 商品名が少し違うだけで「別の商品」と判断させると、規格違い・容量違いの同じ商品を見落とします。 エージェントには候補の近さを書かせますが、候補から外す権限は持たせません。

指示内容を固定する

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

あなたは飲食チェーンの品質管理部で、公表された食品のリコール・自主回収を、
自社の仕入品と入荷記録に照らす担当です。入力は、新しく見つかった公表1件の
件名と詳細のページの本文です。

【やること】
1. 事業者名、販売者か製造者か、商品名、規格、JANコード、賞味期限・消費期限、
   ロット、販売地域・販売先、理由を取り出す。
2. 理由の区分を allergen_label / foreign_matter / microbial / other_label /
   other から1つ選ぶ。
3. JANコードがあれば、仕入品マスタを JANコードで引く。
4. メーカー名の対応表を引き、当たった社名で仕入品マスタを引く。
   商品名でも仕入品マスタを引く。
5. 当たった仕入品について、入荷記録を引き、対象の期限・ロットと見比べる。
6. 過去の照合の記録を引き、同じ事業者・商品の前回の判断を添える。

【厳守事項】
- 事業者名、商品名、期限、ロット、理由は、公表に書かれた文言を
  そのまま写してください。
- 書かれていない期限やロットを推測しないでください。「記載なし」としてください。
- 社名か商品名のどちらかが仕入品に当たったときは、candidates に必ず残して
  ください。規格や容量が違っても、外さないでください。違いは
  check_points に書いてください。
- 該当する・しないの結論を書かないでください。match_basis に、
  何が一致したか（jan / maker / product_name）だけを書いてください。
- 入荷記録の期限・ロットが対象と一致するかは、lot_match に
  match / no_match / unknown で書き、unknown を no_match にしないでください。
- 健康への影響や、取るべき対応を書かないでください。
- 食品でない公表と判断したときは relevant を false にしてください。

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

「unknown を no_match にしない」が、この指示の要です。 入荷記録にロットが残っていない仕入品は、対象かどうかが分かりません。分からないものを「一致しない」と書かせると、店舗に在庫の確認を頼む候補から落ちます。 3つの値を分けておけば、後段の規則で unknown を必ず店舗の確認に回せます。

出力形式を固定する

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

{
  "recall_id": "", "title": "", "posted": "", "relevant": true,
  "company": "", "company_role": "seller | maker | unknown",
  "product": "", "size": "", "jan": [""],
  "best_before": "", "lot": "", "sales_area": "",
  "reason_text": "",
  "reason_type": "allergen_label | foreign_matter | microbial | other_label | other",
  "target_in_image": false,
  "candidates": [
    { "item_code": "", "maker": "", "item_name": "",
      "match_basis": "jan | maker | product_name",
      "receipts": [ { "date": "", "site": "", "best_before": "", "lot": "" } ],
      "lot_match": "match | no_match | unknown",
      "previous_judgment": "" }
  ],
  "check_points": [""]
}

1つ目の理由は、lot_match で店舗に頼む範囲を決められることです。 match と unknown の入荷先だけに在庫の確認を頼みます。第3章の（c）は、ここで解けます。

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

3つ目は、target_in_image で人が画像を見る公表を分けられることです。 対象の特定情報が画像で載っている公表は、文字の照合が効きません。

システムへ連携する

照合の一覧への書き込みは、ワークフローの側で行います。 エージェントの道具には Insert を含めず、写しを引く Select と Execute Query だけを渡します。Execute Query では $1 のようなパラメーターに値を渡す形を使い、公式の説明では、クエリパラメーターのデータは n8n が無害化し、SQL インジェクションを防ぐとされています。公表の本文の文字を、そのまま問い合わせに埋め込まないでください。

店舗への連絡は、この構成から直接は出しません。 品質管理の担当者が候補を確かめ、店舗に在庫の確認を頼む文面を自分で送ります。

人が確認する

1. 至急から見る … 対象の期限・ロットが入荷と一致したもの、アレルギー表示の欠落で候補があるものは、すぐに仕入先に問い合わせ、入荷先の在庫を確かめます
2. 当日の候補を確かめる … unknown の入荷先に在庫の確認を頼みます
3. 確認の候補を判断する … 社名や商品名だけが当たったものは、仕入先と商品の規格を見て、自社の品かを確かめます
4. 候補の無い公表を流し見る … 1日1回のまとめで件名を見て、取引先なのに当たらなかったものがあれば、メーカー名の対応表に足します
5. 判断を記録する … 該当の有無、店舗への連絡、使用の停止・撤去の有無を照合の一覧に残します

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

目標は、1件をならして5分です。 照合の結果の確認に3分、連絡の要否の判断に2分という見込みです。

例外に対処する

7行目で、スキーマに合わない出力を「至急」で回すのは意図してのことです。 照合ができなかった公表は、該当の有無が分からないという意味で、確かめるまでは最も重く扱います。

記録を残す

• 実行ごとの取得の成否と、新しく拾った管理番号の一覧
• 取った詳細のページの本文
• エージェントのJSON出力と、呼んだ道具の順番
• 人の判断 … 該当の有無、店舗への連絡、使用の停止・撤去の有無、判断した日時
• 公表の掲載日、拾った日時、店舗に連絡した日時、在庫を確かめ終えた日時

最後の行が、この構成の物差しです。 掲載から店舗への連絡までの時間を並べると、見回りの遅れか、社内の確認の遅れかが分かれて見えます。