冷凍・冷蔵ケースの温度の記録を n8n で15分ごとに見回り、逸脱の続き方と過去の対処から、商品の扱いと保守の連絡の要否を店長に知らせる

処理の起点を決める

Schedule Trigger で、15分ごとに動かします。 公式ページでは、Schedule Trigger は分・時間・日などの間隔か cron の式で動き、ワークフローに時間帯が設定されていればそれに、無ければインスタンスの時間帯に従うとされています。自前で置いたインスタンスの既定は America/New York です。霜取りの時刻表は店の時刻で書かれているので、ワークフローの時間帯を Asia/Tokyo にします。 そうしないと、霜取りの時間帯の判定がすべてずれます。

間隔を15分にしているのは、センサーの記録が10分ごとだからです。 5分ごとに見回っても新しい値が無い回が増えるだけで、30分ごとにすると、知らせるのが最大で30分遅れます。 1回の見回りで直近3時間を取り直すので、前の回で取れなかった値も次の回で拾えます。

ワークフローは保存して公開（publish）しておく必要があります。 また、取りこぼした実行の既定は「動かさない」です。n8n が止まっていたあいだの回は動かないので、毎回直近3時間を取り直す設計で埋めます。

入力データを集める

質を決めるのは、霜取りの時刻表と、社内の基準の表です。 厚生労働省のページでは、令和3年6月1日から、原則として、すべての食品等事業者がHACCPに沿った衛生管理に取り組むとされています。その衛生管理計画の温度の値を、種類ごとの数字の表に写すのが最初の準備作業です。

対処の記録は、最初は空です。 記録簿から直近半年で保守会社を呼んだ件だけを入れれば足ります。

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

Data Table の値は、Code ノードから直接は読めません。 公式ページでは、Code ノードは組み込みの方法や変数で Data Table の値に直接アクセスできないとされています。先に Data Table ノードで取り出し、その結果を Code ノードへ渡す順にします。

温度の記録は、全店・全ケースを1回で取ります。 件数に上限があれば Pagination で続きを取り、利用回数に上限があれば Batching で呼び出しの間を空けます。

応答の状態を必ず見ます。 既定では2xx以外は失敗になり、「Never Error」を有効にすると状態に関係なく成功として扱われます。状態を見ないと、温度監視サービスが止まっていても「逸脱なし」と読みます。 Include Response Headers and Status を有効にし、2xx以外は「記録が取れない」として品質管理部に知らせます。

AIへ渡す前に整形する

1. 途切れの検出 … 直近30分に記録が無いケースは、温度の判定をせずに stale の印を付けます
2. 上限との比較 … 記録ごとに、ケースの管理温度の上限を超えているかを見ます
3. 続いている長さ … 直近の連続して超えている記録の数から、外れている分数を出します
4. 霜取りの時間帯 … 時刻表の開始から「1回の長さ＋戻りの猶予」のあいだにあるかを見ます
5. 傾き … 直近60分の温度の上がり方（10分あたり何度）を出します
6. 同じ店の他のケース … 同じ店で同じ時刻に上限を超えているケースの数を数えます
7. 段階の決定 … 社内の基準の表で、none／watch／notify／urgent を決めます

1番目を最初に置くのは、記録が無いことと温度が正常なことを分けるためです。 電池が切れて止まった記録の最後の値が正常なら、そのまま「正常」と読んでしまいます。

7番目の段階は、規則だけで決めます。 霜取りの時間帯の外に上限を2回続けて超えたら watch、決めた分数を超えたら notify、さらに長く続くか同じ店の3台以上が同時なら urgent、のように衛生管理計画の値で表を作ります。 分数は各社で決めるもので、本記事では置きません。AIに渡すのは notify と urgent だけです。

6番目は、AIに頼らず数えます。 同じ店の複数のケースが同時に上がっているなら、冷凍機・電源・空調の側を疑う材料になります。

AIに処理させる

Basic LLM Chain に、逸脱の型と、店長が確かめる必要と保守へ連絡する必要の判定をさせます。 公式ページでは、Basic LLM Chain はモデルに渡すプロンプトを決めるノードで、「Require Specific Output Format」を有効にすると、Structured Output Parser などの出力パーサーをつなぐとされています。

いちばん起きやすいのは4行目です。 過去の記録に「コンプレッサーの不調」と1件あると、AIは「コンプレッサーの故障の可能性が高い」と書きます。 伝わると保守会社の見立てを狭めます。書いてよいのは、前回の所見の写しだけです。

指示内容を固定する

Basic LLM Chain のシステムメッセージに、次のように書きます。

あなたは食品スーパーの品質管理部の担当として、冷凍・冷蔵ケースの温度の逸脱を
店長に知らせる文を作ります。商品の扱いを決めるのは店長です。

【入力】
- ケースの情報（店、ケース名、種類、管理温度の上限、霜取りの時刻表）
- 直近3時間の温度の記録（10分ごと）
- 規則で計算した値：外れている分数、直近60分の傾き、霜取りの時間帯か、
  同じ店で同時に上限を超えているケースの数
- 規則で決めた段階（notify / urgent）
- このケースの過去の対処の記録（直近10件。無ければ空）

【逸脱の型の選び方】
- defrost_recovery_delay：霜取りの時刻表の直後から上がり、傾きが小さくなっている
- door_or_loading：品出しの時間帯に急に上がり、急に下がる動きをくり返している
- cooling_decline：霜取りと関係なく、数時間かけて少しずつ上がっている
- multi_case：同じ店で同時に上限を超えているケースが3台以上
- sensor_suspect：10分で数度以上跳ねて戻るなど、ケースの温度として不自然
- unclear：上のどれとも言えない
迷ったときは unclear を選び、無理に型を決めないでください。

【厳守事項】
- 規則で決めた段階は変えないでください。urgent のときは、
  product_check を check_now、maintenance_call を call_now か after_check にしてください。
- 商品を販売してよいか、廃棄するかは書かないでください。
- 「故障です」「〜が原因です」と断定しないでください。
  過去の対処の記録にある原因は「前回（日付）の保守会社の所見は〜」と記録のまま写してください。
- 過去の対処の記録に無い件を、似た件として挙げないでください。
- 温度の値を補ったり、記録の無い時刻の値を推定したりしないでください。
- evidence には、入力の数字をそのまま写してください。
- 店長への文は3文まで。何が、いつから、どう続いているかを先に書いてください。

「迷ったら unclear」を明記しないと、型を必ず1つに決めます。 型を誤ると、店長が売場で見る場所を誤ります。 unclear のときは「売場で見ること」を一般の順（扉、吹き出し口、積みすぎ、表示の温度）にします。

「段階は変えない」は、ワークフローでも検査します。 過去の記録に「様子見で戻った」が続くと、urgent の件にも check_soon を付けることがあるからです。

出力形式を固定する

Structured Output Parser で、次の形に決めます。 公式ページでは、スキーマは JSON の例から作るか JSON Schema で定義でき、JSON の例から作るとすべての項目が必須として扱われるとされています。また、$ref を使った参照には対応していないとされているので、スキーマは1つの塊で書きます。

{
  "case_id": "S12-F07",
  "store": "12号店",
  "notify_level": "notify | urgent",
  "pattern": "defrost_recovery_delay | door_or_loading | cooling_decline | multi_case | sensor_suspect | unclear",
  "product_check": "check_now | check_soon",
  "maintenance_call": "call_now | after_check | not_needed_yet",
  "similar_past_ids": ["R-2026-0811-03"],
  "look_at": ["吹き出し口の霜・氷", "霜取りの表示灯", "ケースの表示の温度"],
  "evidence": {
    "minutes_out": 70,
    "slope_per_10min": 0.4,
    "in_defrost_window": false,
    "same_store_cases_out": 1
  },
  "message": ""
}

1つ目の理由は、規則の段階とAIの判定を並べて検査できることです。 後段の Code ノードで、notify_level が urgent なのに product_check が check_soon なら、check_now に上書きして記録します。AIの判定が軽くても、店長に届く前に直ります。

2つ目は、similar_past_ids で過去の件を確かめられることです。 Code ノードで、そのIDが対処の記録に本当にあるかを照らします。無いIDが書かれていたら、その欄を空にして「似た件なし」とします。 作り話の過去の件が店長に届くのを止めます。

3つ目は、Teams の通知と記録を同じ形で作れることです。 通知には、ケースといまの温度、続き方の数字、型、過去の似た件（日付・原因の記録・保守会社の所見）、売場で見ること、回答の欄を並べます。

システムへ連携する

店長への通知は、Teams の Send and Wait for Response で送ります。 公式ページでは、Microsoft Teams ノードの Chat Message には Send and Wait for Response の操作があり、メッセージを送って人の確認や入力までワークフローを止めるとされています。回答の形は Approval・Free Text・Custom Form の3つで、Custom Form では Form トリガーのフォームと同じ要素で欄を作れます。 店長の回答は、商品の扱い（移した／そのまま／販売を止めた）、保守への連絡（した／しない）、気づいたこと（自由記入）の3つの欄にします。

回答の待ち時間に上限を付けます。 Limit Wait Time で、決めた時間か時刻が来たら自動で再開するとされています。urgent は20分、notify は60分を上限にし、回答が無ければ副店長と品質管理部のチャネルに送ります。

温度監視サービスには書き込みません。 設備の霜取りの時刻を変えたら、ケース台帳も同じ日に直します。

人が確認する

店長が見るのは、notify と urgent の件だけです。 watch は逸脱の記録に残るだけで、通知しません。ここで通知が多すぎれば、規則の分数の値を見直します。 AIの判定を緩めて減らすことはしません。

1. 型と「売場で見ること」を読んで売場へ行く … 霜取りの戻り遅れなら吹き出し口の霜、扉なら閉まりとすき間、という順に見ます
2. 商品の扱いを決める … 衛生管理計画の手順に従い、移す・販売を止める・そのままを決めます。決めるのは店長です
3. 保守への連絡を決める … call_now でも、売場で原因が明らかに扉なら連絡しないことがあります。その判断を回答の欄に書きます
4. 回答を入力する … 回答が対処の記録に入り、次の判定の材料になります

4番目を省かないでください。 対処の記録が増えなければ、AIは過去の件を引けないままです。 品質管理部は週に1回、全店の逸脱の記録を見て、何度も cooling_decline になるケースを保守の点検の候補にします。

例外に対処する

上から2行目が、最初の数か月でいちばん多い例外です。 途切れを温度の正常と混ぜないことが、この構成の土台です。

最後の行は見落としやすいものです。 容量が80％に近づくと警告が出ます。対処の記録が書けなくなると、店長の回答が消えます。

記録を残す

• 実行ごとに、取り出した記録の件数と、途切れたケースの一覧
• 逸脱の記録（ケース、始まった時刻、段階、AIの判定、通知した時刻）
• AIの判定を規則で上書きした記録 … どの欄を、何から何に変えたか
• 店長の回答（商品の扱い、保守への連絡、気づいたこと）と、回答の時刻
• 保守会社の所見（品質管理部があとから足す）
• 回答が無く副店長と品質管理部へ送った記録

3つ目は、AIの判定の質を測る材料になります。 上書きが多い型は、選び方の指示を直します。