主要な仕入先のWebのお知らせ（価格改定・製造中止・納期遅延）をエージェントが毎週見回り、自社の購買品目と照らして影響する品目と手配の担当を一覧にする

処理の起点を決める

毎週月曜の朝7時に、Schedule Trigger で動かします。 週の初めにバイヤーが一覧を見て、その週の手配に反映できるようにするためです。Schedule Trigger の週単位の設定では、何週ごとか、曜日、時、分を指定できます。

Schedule Trigger は、ワークフローのタイムゾーンが無ければ n8n のインスタンスのタイムゾーンを使い、セルフホストの既定は America/New York とされています。ワークフローの設定でタイムゾーンを Asia/Tokyo にし、保存して公開します。公開しないと Schedule Trigger は動かないとされています。

見回りの対象は、仕入先の一覧の表で持ちます。 列は、仕入先コード、仕入先名、URL、RSS の有無、CSS セレクター、取り扱いの区分（メーカー直／商社経由）、受け持ちのバイヤーです。ワークフローの中にURLを書き込まないでください。 仕入先が増えたとき、表に1行足すだけで見回りの対象になります。第3章の（a）は、この表で解きます。

商社経由で買う品目は、商社ではなくメーカーのページを見回りの対象にします。 第2章で書いたとおり、メーカーの公表のほうが商社からの連絡より早いからです。

入力データを集める

質を決めるのは、品目マスタのシリーズ名の列です。 お知らせが「XXシリーズ全品」と書いてきたとき、品目マスタにシリーズ名が無ければ、エージェントは型番の前方一致で推し量るしかありません。型番の頭の文字が同じでも別のシリーズということがあり、候補が広がりすぎます。 年間の使用量の多い品目から、シリーズ名を埋めます。

過去のお知らせの記録は、同じ型番が何度も出てくるために持ちます。 価格改定の予告と確定、製造中止の予告と最終受注日の決定のように、同じ品目について2回、3回とお知らせが出ます。 前回のお知らせを添えると、バイヤーは差分だけを見れば済みます。

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

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

リンクの比較は、リンク先と見出しの組で行います。 仕入先によっては、同じお知らせを更新すると見出しに「（更新）」が付くだけでURLは変わりません。見出しが違う同じURLは「更新」として拾います。 Compare Datasets の「違うもの」の出力がそれに当たります。

RSS とページの両方がある仕入先は、RSS を優先します。 ページの作りの変更に左右されないからです。

AIへ渡す前に整形する

1. 見出しで絞る … 「価格」「改定」「値上げ」「生産終了」「製造中止」「販売終了」「EOL」「納期」「供給」「出荷」などの語を見出しに含むものだけを、エージェントに渡します。外したものは見出しとURLだけを一覧の末尾に残します
2. 本文の共通部分を外す … メニュー、フッター、関連記事の欄を外し、お知らせの本文だけにします
3. PDFの文字が取れたかを確かめる … 画像だけのPDFは文字が取れません。取れた文字数が極端に少なければ、人に回します
4. 型番の書き方をそろえる … 全角・半角、ハイフンと長音記号の取り違え、空白を、お知らせと品目マスタの両方で同じ規則でそろえます
5. 写しの日付を確かめる … 前夜の品目マスタと発注残の写しが作られていなければ、照合を止めます
6. 新しいお知らせの件数を確かめる … 1社で20件を超えたら、ページの作りが変わったとみなして、その仕入先の比較を止めます

4番目を軽く見ないでください。 型番には「-」と「‐」と「ー」が混ざり、PDFから取り出した文字では全角になっていることがあります。そろえずに照合すると、品目マスタにある品目が「該当なし」になります。 エージェントが見落としたように見えますが、原因は文字の違いです。

AIに処理させる

させるのは、お知らせ1件ごとに、種類・対象の型番・日付・代替品を取り出し、品目マスタと発注残を引いて影響の候補を挙げることです。

取り出しの段階では、お知らせに書かれた文言をそのまま写させます。 価格改定の率が「平均10％」と書かれていれば「平均10％」、「品目により異なる」と書かれていれば、そのまま写します。品目ごとの改定率を推し量らせません。

3行目がいちばん起きやすい失敗です。 「2027年3月末で生産を終了します」とだけ書かれたお知らせを渡すと、生成AIは最終受注日を数か月前に置いて書き添えることがあります。最終受注日は仕入先が決めるもので、推した日付で手配を組むと間に合いません。

指示内容を固定する

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

あなたは装置メーカーの購買部で、仕入先のWebサイトに出たお知らせを、
自社の購買品目と照らす担当です。入力は、新しく見つかったお知らせ1件の
本文（添付のPDFから取り出した文字を含む）と、仕入先の名前です。

【やること】
1. お知らせの種類を price_change / discontinuation / delay / other から選ぶ。
2. 対象の型番、シリーズ名、「一部を除く」などの条件の文言を取り出す。
3. 実施日、最終受注日、最終出荷日、遅延の見込みの期間、推奨の代替品を取り出す。
4. 型番は、まず完全一致で、次に前方一致で品目マスタを引く。
5. シリーズ名が書かれていれば、シリーズ名で品目マスタを引く。
6. 見つかった品目について、発注残と、過去のお知らせの記録を引く。

【厳守事項】
- 型番、条件、日付、率は、お知らせに書かれた文言をそのまま写してください。
- 書かれていない日付を推測しないでください。最終受注日が無ければ
  「記載なし」とし、check_points に「最終受注日を仕入先に確認」と書いてください。
- 改定後の価格を計算しないでください。
- 影響する・しないの結論を書かないでください。match_basis に、
  どの道具で何が一致したか（exact / prefix / series）だけを書いてください。
- 「一部を除く」「対象外の品番あり」と書かれているときは、
  excluded_note にその文言を写し、check_points に除外の確認を書いてください。
- 品目マスタに見つからなかった型番も、not_found に残してください。
- 購買に関係のないお知らせ（展示会、休業日など）は relevant を false にしてください。

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

「not_found にも残す」を書くのは、見つからなかった型番が、型番の書き方の違いである可能性があるからです。 見つからなかったものを捨てると、前処理の不備に気づく手がかりも消えます。not_found が毎週多い仕入先は、型番のそろえ方を見直します。

「結論を書かない」も同じ考えです。 「一部を除く」の除外の表は、PDFの奥に付いていることが多く、エージェントが読み落とすと、除外された品目を「影響あり」として回してしまいます。 当てはめは、バイヤーが除外の表を見て行います。

出力形式を固定する

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

{
  "supplier": "", "source_url": "", "title": "", "relevant": true,
  "notice_type": "price_change | discontinuation | delay | other",
  "effective_date": "", "last_order_date": "", "last_ship_date": "",
  "rate_text": "", "delay_text": "", "excluded_note": "",
  "items": [
    {
      "part_no_in_source": "", "series": "", "replacement": "",
      "hits": [
        { "internal_no": "", "maker_part_no": "", "match_basis": "exact | prefix | series",
          "buyer": "", "annual_usage": "",
          "open_po": [ { "po_no": "", "qty": "", "due": "" } ],
          "previous_notice": "" }
      ]
    }
  ],
  "not_found": [""],
  "check_points": [""]
}

Structured Output Parser は、JSON スキーマに沿った項目を返させる部品で、JSON の例からスキーマを作る方法と、JSON スキーマを直接書く方法があります。例から作るとすべての項目が必須として扱われるとされています。$ref による参照は使えないので、スキーマは入れ子のまま書きます。

1つ目の理由は、match_basis で確からしさを分けられることです。 exact の一致は確度が高く、prefix と series は人が確かめる前提です。通知では、exact とそれ以外を分けて出します。

2つ目は、last_order_date と effective_date で並べられることです。 第3章の（d）は、ここで解けます。

5行目も消さずに残します。 「自社の品目に該当なし」も、見回りをした記録だからです。

システムへ連携する

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

通知は担当バイヤーごとに分けます。一覧の全体を全員に流すと、自分の品目を探すところから始まります。

人が確認する

1. 最終受注日の近い製造中止から見る … 90日以内のものは、その週のうちに最終の買い置きと代替品の評価の要否を決めます
2. exact の一致を確かめる … お知らせの型番と品目マスタの型番が同じものかを見ます
3. prefix と series の候補を判断する … 除外の表とシリーズの範囲を見て、自社の品目が対象かを決めます。ここがバイヤーの仕事の中心です
4. not_found を眺める … 型番の書き方の違いで見つからなかったものが無いかを見ます
5. 判断を記録する … 影響の有無、対応（値上げの確認、買い置き、代替品の評価）、仕入先への問い合わせの要否を一覧に残します

3番目を省かないでください。 前方一致とシリーズの照合は、候補を広めに挙げる作りです。候補に挙がったことは、影響があることを意味しません。

目標は、1件をならして12分です。 取り出しと照合の結果の確認に6分、除外とシリーズの範囲の判断に4分、一覧の確認と回付に2分という見込みです。

例外に対処する

上から2行目は、仕入先のサイトの模様替えのときに起きます。 Tools Agent の Max Iterations は、答えを出すためにモデルを何回動かすかの上限で、既定は10です。件数の上限と回数の上限の2つで、暴走を止めます。

記録を残す

• 実行ごとの、仕入先ごとの取得の成否と、新しく拾ったお知らせの一覧
• 取った本文とPDFのファイル
• エージェントのJSON出力と、呼んだ道具の順番
• バイヤーの判断 … 影響の有無、対応、判断した日
• お知らせが公表された日、見回りで拾った日、最終受注日、手配を終えた日

最後の行が、この構成の物差しです。 最終受注日の何日前に拾い、何日前に手配を終えたかを並べると、見回りが遅れているのか、社内の判断が遅れているのかが分かれて見えます。