設備メーカーの生産中止・技術情報・不具合のお知らせをエージェントが毎週見回り、設備台帳と照らして影響のある設備を保全の担当に届ける

処理の起点を決める

毎週月曜の朝6時に、Schedule Trigger で動かします。 週の初めに保全課の打合せで扱うためです。生産中止のお知らせは受注の締切りまで数か月あることが多く、週1回で間に合います。ただし、受注締切りまで90日・30日に当たる週は、対応の決まっていないものを必ず出し直します。

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

メーカーや代理店からメールで届くお知らせも、同じ流れに乗せます。 保全課の共有のメールボックスに届いたお知らせの PDF を、決まったフォルダに保存し、週1回の実行でそのフォルダも見回りの先の1つとして扱います。

このワークフローが止まったことに、人が気づける仕組みを必ず作ります。 実行が終わったら、新しいお知らせがゼロでも「今週の見回り完了（メーカー 30、新しいお知らせ 0件）」を出します。通知が来ないこと自体が、止まった合図になります。

入力データを集める

質を決めるのは、設備台帳の形名の正しさです。 台帳の形名が「NZ2EHG」のように末尾を省いて登録されていると、完全一致では当たりません。前方一致を規則に入れ、末尾を省いた登録はエージェントの確かめる点に出させます。

メーカー名の書き方もそろえます。 台帳には「三菱」「三菱電機」「MITSUBISHI」が混ざっていることがあり、メーカー名の対応表を写しに持たせます。

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

取り出しは、n8n の HTML ノードで行います。 Extract HTML Content は、CSS セレクターで要素を指定し、テキスト・属性・HTML を取り出せます。 一覧の表は行ごとに、名称・形名・生産終了年月・代替製品のセルを取り出します。メーカーごとにページの作りが違うので、セレクターは見回りの先の表に持たせます。

PDF は、HTTP Request の応答の形式をファイルにして取り、Extract From File ノードの PDF の取り出しで文字にします。 テクニカルニュースのように文字が埋め込まれた PDF なら、見出しと表の文字が取れます。画像だけの PDF は文字が取れないので、取れた文字の量で見分けて人に回します。

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

AIへ渡す前に整形する

1. 形名をそろえる … 全角・半角、空白、ハイフンの種類をそろえ、お知らせと台帳の両方に同じ規則を当てます
2. 記号付きの形名を展開する … * を任意の文字の並び、(M) を「M があってもなくても」として、照合の規則に直します。直せない書き方は文字のまま残し、エージェントに渡します
3. 規則で照合する … 完全一致、前方一致、記号の展開の順に台帳を引き、当たった行と当たり方を記録します
4. 期日を取り出す … 「受注締切り日: 2027年2月28日」のような見出し付きの日付を、規則で日付に直します。直せないものは文字のまま残します
5. お知らせの種類を分ける … 件名の言葉（生産中止、生産終了、技術情報、不具合、ファームウェア）で仮に分け、エージェントに確かめさせます
6. 写しの日付を確かめる … 前夜の台帳と在庫の写しが作られていなければ、照合を止めて「照合できていない」と通知します

2番目と3番目が、この構成でいちばん効く前処理です。 記号付きの書き方を正規の照合の規則に直しておけば、シリーズ全体が対象のお知らせでも、台帳の4,000行から当たる行が一度に出ます。

AIに処理させる

させるのは、お知らせ1件ごとに、対象・期日・理由・修理の期間・置換えを取り出し、規則で当たらなかった書き方の候補を挙げ、台帳と在庫を引いて影響のある設備と確かめる点を挙げることです。

期日を「書かれたまま」写させるのは、規則で直した日付と突き合わせるためです。 規則で直した日付とエージェントが写した文字が食い違えば、どちらかの読み違いとして人に回します。

3行目が、この構成で特に大事な線です。 FA-D-0499-A の置換え機種は「接続可能品」で、メーカーでは検証していないと書かれています。 AIに置換えを勧めさせると、この条件が落ちます。

指示内容を固定する

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

あなたは工場の保全課で、設備メーカーのお知らせを読み、
自社の設備台帳に照らして影響を調べる担当です。
入力は、お知らせ1件の本文、規則で照合した結果（当たった台帳の行と当たり方）、
規則で直した期日です。

【やること】
1. 品名、形名、対象の製造番号・版、お知らせの種類を取り出す。
2. 受注生産移行、受注締切り、生産中止、修理対応の期限を、本文の文言の
   まま写す。
3. 理由、置換えの機種、置換えの条件を、本文の文言のまま写す。
4. 規則で当たらなかった形名について、設備台帳を前方一致で引き、
   末尾を省いた登録や書き方の違う登録の候補を挙げる。
5. 当たった設備と候補の設備について、予備品の在庫と設備の重要度を引く。
6. 過去の判断を引き、同じ形名の前回の方針を添える。

【厳守事項】
- 本文に書かれていない期日・理由・置換えを書かないでください。
  書かれていなければ「記載なし」としてください。
- 規則で当たった台帳の行を、候補から外さないでください。
- 自分で挙げた候補には、match_basis を ai_candidate とし、
  なぜ候補にしたか（どの文字が合ったか）を書いてください。
- 該当しない、影響が無い、という結論を書かないでください。
- 置換えの機種を勧めないでください。置換えの条件（接続可能品、
  検証の有無など）が書かれていれば、そのまま写してください。
- 予備品の買い置きの数量を書かないでください。
- 本文の文字が少なすぎて読めないときは、text_insufficient を true に
  してください。

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

「規則で当たった行を外さない」が、この指示の要です。 形名が当たっていても、製造番号の範囲や版でお知らせの対象から外れることはあります。ただし、その判断は保全の担当が本文を読んで行います。 エージェントには外す権限を持たせず、外れるかもしれない理由を確かめる点に書かせます。

出力形式を固定する

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

{
  "notice_id": "", "maker": "", "title": "", "issued": "",
  "kind": "discontinued | technical | defect | other",
  "text_insufficient": false,
  "targets": [ { "product_name": "", "model_text": "", "serial_or_version": "" } ],
  "dates_text": { "order_only": "", "last_order": "", "end_of_production": "",
                  "repair_until": "" },
  "reason_text": "", "replacement_text": "", "replacement_conditions": "",
  "equipment": [
    { "equipment_id": "", "line": "", "model": "", "qty": 0,
      "match_basis": "exact | prefix | pattern | ai_candidate",
      "spare_stock": 0, "criticality": "high | mid | low",
      "previous_decision": "", "check_points": [""] }
  ],
  "check_points": [""]
}

1つ目の理由は、match_basis で人が見る順を決められることです。 規則の完全一致は確かめが速く、ai_candidate は台帳の登録を開いて確かめます。当たり方が見えれば、確かめ方を変えられます。

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

3つ目は、dates_text を写しとして持つことで、規則で直した日付と突き合わせられることです。 食い違えば至急の扱いで人に回します。

システムへ連携する

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

予備品の発注は、この構成から出しません。 保全の責任者が方針を決めたあと、予備品の担当が購買の手続きに回します。

人が確認する

1. 至急から見る … 受注締切りが近く重要な設備に当たるもの、不具合のお知らせで設備に当たるものを、その週のうちに責任者に上げます
2. 当たり方を確かめる … exact と prefix は台帳の行で、ai_candidate は台帳の登録と現物の銘板で確かめます
3. 置換えの条件を読む … 接続可能品か、検証の有無、改造が要るかを、本文で確かめます
4. 記録のまとめを流し見る … 形名を見て、台帳に無い設備に心当たりがあれば台帳の登録を直します
5. 判断を記録する … 買い置き、置換え、改造、様子を見る、と理由を照合の一覧に残します

4番目を省かないでください。 照合の漏れは、台帳の登録の抜けから起きます。担当が形名を見て気づくことが、台帳を育てる経路です。

目標は、1件をならして4分です。 記録のものは形名を見るだけで済み、至急のものは本文と台帳を開いて15分を超えます。

例外に対処する

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

記録を残す

• 実行ごとのメーカーごとの取得の成否と、新しく拾ったお知らせ・一覧の行の違い
• 取った PDF とページの本文
• 規則の照合の結果と、エージェントのJSON出力、呼んだ道具の順番
• 人の判断 … 買い置き・置換え・改造・様子を見る、理由、判断した日時
• お知らせの発行、拾った日時、責任者に上げた日時、予備品を発注した日時

最後の行が、この構成の物差しです。 発行から発注までの日数を受注締切りと並べると、締切りに対してどれだけ余裕を持って動けたかが見えます。