機械警備の発報の記録を毎朝集め、誤報の原因を設定・小動物・機器の不具合などで分けて、同じ契約先で続く誤報を担当に知らせる

処理の起点を決める

毎朝6時に1回動かします。 Schedule Trigger の Days の間隔で時刻を決めるか、cron の式で 0 6 * * * と書きます。n8n を自社のサーバーに置く場合、タイムゾーンの既定は America/New York です。 ワークフローかインスタンスのタイムゾーンを Asia/Tokyo にしないと、日本時間の夜に動きます。

発報のたびに動かす形にはしません。 誤報の原因は、警備員が現場から戻って対処報告を書き終えてからでないと分かりません。深夜の発報の報告は明け方に入ることもあるので、前日分が出そろう朝にまとめて読みます。

監視の仕組みの書き出しを5時、ワークフローを6時にずらしておきます。 書き出しが遅れた日に、空のファイルを読んで「発報0件」と報告しないためです。ワークフローは、前日の日付の CSV が無ければ止まって管制課へ知らせます。

Schedule Trigger を使うワークフローは、保存して公開しておく必要があります。 編集の画面で試しに動かすだけでは、翌朝は動きません。

入力データを集める

AI に渡すのは、2行目の所見の自由記述と、信号の種類・センサーの種類だけです。 契約先の名称・住所・警戒の時刻は渡しません。原因を読み分けるのに、どこの建物かは要りません。

契約先の対応表には「建物の種類」の列を持たせます。 店舗と倉庫と介護施設では、同じ「扉の開閉の信号」でも誤報の起き方が違います。連続の基準を建物の種類で変えるときに使います。

センサーの設置年は、技術の担当へ渡す連絡文に入れます。 古い機器で誤作動が続いているなら、設定を見直すより交換の提案が先になります。

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

取り込んだ CSV は、成功したときだけ処理済みのフォルダへ移します。 FTP ノードの Rename で、移し先のフォルダが無ければ作るオプションを有効にしておきます。書き出し用のフォルダに残っている数が、そのまま未処理の日数になります。

CSV の1行目が見出しになっているかを、最初に確かめます。 Extract From File の CSV の取り込みには見出しの行の扱いを決める設定があり、見出しとして扱わないと、列が番号で返ります。 監視の仕組みの書き出しの文字コードもあわせて確かめ、文字化けしたまま分類に回さないようにします。

誤報台帳と対応表は、Code ノードからは直接読めません。 公式ページでは、Code ノードは Data Table の値に直接アクセスできないとされています。Data Table ノードで取り出してから、後ろの Code ノードへ渡します。

AIへ渡す前に整形する

1. 前日分の確認 … 発報の日時がすべて前日の範囲に入っているかを見ます。範囲外の行は、書き出しの設定の誤りとして止めます
2. 本当の異常の可能性があるものを外す … 次のどれかに当たる行は分類に回さず、人の確認の列へ回します

- 信号の種類が火災・非常通報 - 警備員の報告の区分が「異常あり」 - 警察・消防への通報の有無が「あり」 - 対処報告の所見が空欄、または「確認中」

1. 伏せ字 … 所見の自由記述から、契約先の名称、人の名前、電話番号、暗証番号らしい数字の並びを伏せます
2. 短すぎる所見の扱い … 「異常なし」の一言だけのものは、分類に回さず「所見なし」として台帳に記録します
3. 重複の除去 … 同じ契約先・同じセンサー・数分以内の発報が続いているものは、1件の出動にまとめます

2番目が、この構成の安全の要です。 本当の侵入や火災の発報を「環境による誤報」に分けてしまうと、台帳の上では何も起きなかったことになります。 その種類の発報は最初から AI に見せません。

3番目で暗証番号を伏せるのは、所見に書かれることがあるからです。 「暗証番号◯◯◯◯を3回誤入力」と書く警備員がいます。解除の番号が外へ出ることは、建物の鍵が外へ出ることと同じです。

5番目は、数え過ぎを防ぐためです。 扉が風で揺れて数分おきに3回発報した出動を3件と数えると、1晩で連続の基準を超えてしまいます。

AIに処理させる

させるのは、所見の文面を読み、誤報の原因を次の区分のどれか1つに分けることだけです。

Allow Multiple Classes To Be True はオフにします。 1件の誤報に区分を1つだけ付けます。複数を許すと、「扉が半開きで風に揺れた」が利用者の操作と環境の両方になり、台帳の数え方が決まらなくなります。

When No Clear Match は「Output on Extra, 'Other' Branch」にします。 既定の Discard Item のままだと、どの区分にも当てはまらない発報が黙って消えます。 消えた発報は台帳にも残らず、連続の数にも入りません。

5行目がいちばん起きやすい失敗です。 倉庫の扉の開閉の発報で所見が「異常なし、施錠確認」だけのとき、モデルは倉庫ではよくあることとして小動物を選びがちです。根拠の無い分類は台帳を汚し、存在しない連続を作ります。

指示内容を固定する

Text Classifier の System Prompt Template を次のように書き換えます。{categories} は区分の一覧が入る置き場所です。

あなたは機械警備の監視センターで、警備員の対処報告から誤報の原因を分類する係です。
渡されるのは、警備員が現場で「異常なし」と報告した発報の所見だけです。

【区分】
{categories}

【厳守事項】
- 所見に書かれた事実だけを根拠にしてください。
  建物の種類や時刻から「よくある原因」を推測して区分を選ばないでください。
- 所見に原因の手がかりが無いとき、どの区分も選ばないでください。
- 「扉が半開き」のように、人の操作と環境の両方が書かれているときは、
  発報の直接のきっかけになった方を選んでください。
  直接のきっかけが書かれていなければ、どの区分も選ばないでください。
- 機器の不具合は、警備員が機器の異常（電池切れの表示、配線の外れ、
  センサーの破損、通信の途絶）を確かめた記述があるときだけ選んでください。
  「原因不明のため機器の誤作動と思われる」は機器の不具合ではありません。
- 侵入・火災・けが人の可能性をうかがわせる記述があれば、
  どの区分も選ばないでください。

Input Prompt には次の式を入れます。

信号の種類：{{ $json.signal_type }}
センサーの種類：{{ $json.sensor_type }}
所見：{{ $json.finding_masked }}

「原因不明のため機器の誤作動と思われる」を機器の不具合にしない、と書くのが要点です。 警備員は原因が分からないとき、この言い回しをよく使います。何も言わなければ機器の不具合の区分が膨らみ、技術の担当に根拠の無い点検の依頼が届きます。

最後の1行は、前処理の規則をすり抜けたものへの二重の守りです。 「異常なし」の報告でも、所見に「窓ガラスに傷」と書かれていることがあります。その1件を分類せず Other に出して人に見せます。

入力の式は Text Classifier の Input Prompt の側に書きます。 Anthropic Chat Model のようなサブノードでは、式が常に最初の1件で解決されるとされています。チャットモデルの側に {{ $json... }} を書くと、全件が1件目の所見で分類されます。

出力形式を固定する

Text Classifier の出口ごとに Set のノードを置き、台帳の1行を次の形に揃えます。

{
  "alarm_id": "A-20261013-0412",
  "alarm_at": "2026-10-13T02:14:00+09:00",
  "contract_code": "C-01873",
  "sensor_id": "S-05",
  "signal_type": "intrusion",
  "route": "classified | excluded | other | no_finding",
  "cause": "user_operation | configuration | animal | environment | equipment | null",
  "finding_masked": "",
  "classified_by": "ai | rule | human",
  "corrected": false
}

1つ目の理由は、route で「分類されなかった理由」を残せることです。 規則で外した（excluded）、AI がどの区分も選ばなかった（other）、所見が無かった（no_finding）は、どれも cause が空ですが、意味がまったく違います。 混ぜると、本当の異常の可能性で外した発報まで「原因不明の誤報」に数えられます。

2つ目は、classified_by と corrected で人の直しを数えられることです。 管制担当が区分を直したら human と true にします。どの区分がよく直されているかで、区分の説明の書き直しの順が決まります。

連続の拾い出しは、台帳とは別の形で出します。

{
  "contract_code": "C-01873",
  "building_type": "倉庫",
  "window_days": 30,
  "false_alarm_count": 4,
  "by_cause": { "animal": 3, "environment": 1 },
  "by_sensor": { "S-05": 3, "S-02": 1 },
  "rule_hit": "same_sensor_3_or_more",
  "sales_owner": "",
  "tech_owner": "",
  "draft_message": ""
}

rule_hit に、どの基準で拾ったかを書きます。 「同じ契約先で30日に4回以上」「同じセンサーで30日に3回以上」「同じ区分が3回続いた」のどれに当たったかで、営業に回すか技術に回すかが変わります。

システムへ連携する

連続の数は Summarize ノードで出します。 Data Table の Row の Get で直近30日の誤報を取り出し、Summarize で contract_code と sensor_id を Fields to Split By に入れて Count を取ります。公式ページでは、Fields to Split By は group by に近い働きとされています。

Teams への送り先は、管制課のチャネルにします。 Channel Message の Create で、拾った契約先の一覧と下書きを1日1件のメッセージにまとめます。担当の営業と技術へ直接は送りません。 下書きを確かめた管制担当が転送します。

Teams の資格情報の種類に気をつけます。 公式ページでは、Service Principal（App-Only）の資格情報は Chat・Chat Member・Chat Message に対応せず、Channel Message も一部の対応とされています。チャネルへの投稿が通るかを、組む前に試します。

人が確認する

管制担当が毎朝見るのは、次の3つの列だけです。

1. 規則で外した発報（excluded） … 本当の異常の可能性があるもの。監視センターの通常の手順で、報告の中身と出動の記録を確かめます
2. 区分の付かなかった発報（other） … 所見を読み、区分を付けるか、出動した警備員に聞き直します
3. 連続として拾われた契約先 … 下書きを読み、事実の誤りが無いかを確かめて担当へ転送します

分類が付いた発報は、一覧で流し見ます。 区分の誤りに気づいたら台帳で直し、corrected を立てます。

3番目の下書きは、送る前に必ず所見の原文と突き合わせます。 連絡文は営業から契約先への提案のもとになります。「ネズミが出ている」と契約先に伝えるのは、店舗にとって軽い話ではありません。 所見に書かれていない原因を、下書きが言い切っていないかを見ます。

目標は、1,200件をならして1件1分です。 規則で外すものと Other に出るものが合わせて1〜2割という想定で、それより多い月は、区分の説明か前処理の規則を見直します。

例外に対処する

8行目は、運用を始めて数か月後に効いてきます。 公式ページでは、すべての Data Table の合計は既定で200 MiB までで、80％で警告が出て、上限を超えると書き込みのときにワークフローがエラーになるとされています。自社のサーバーに置く場合は環境変数で上限を変えられますが、古い行を消す運用を最初から組みます。

4行目と5行目は、件数を毎週見ます。 増えているなら、警備員の所見の書き方が変わったか、新しい種類の誤報が出てきた合図です。

記録を残す

• 取り込んだ CSV の原本（処理済みのフォルダに日付ごと）
• 誤報台帳の全行（route、cause、classified_by、corrected）
• AI に渡した伏せ字の後の所見の文面と、選ばれた区分
• 規則で外した発報と、外した理由
• 連続として拾った契約先と、当てはまった基準、送った連絡文の最終版
• 管制担当が区分を直した記録

3つ目で「伏せ字の後の文面」を残すのは、外へ出たものを後から確かめられるようにするためです。 暗証番号らしい数字の並びが伏せ字をすり抜けていないかを、月に1回抜き取りで見ます。

最後の行は、区分の説明を育てる材料です。 「環境」から「利用者の操作」への直しが多いなら、扉の半開きの書き方を区分の説明に足します。