工場の生産設備と監視システムから届くアラームのメールを、緊急度と設備・現象で分類し、保全担当へ回すものと記録だけのものに分ける

処理の起点を決める

アラームのメールの受信を起点にします。 保全課の共有アドレスを IMAP で読み、Email Trigger (IMAP) で受け取ります。定時の実行にはしません。 すぐ対応のアラームを数十分待たせる理由がありません。

受信箱には、アラーム専用のフォルダを作ります。 監視の仕組みの送信元アドレスで振り分けるルールを受信箱の側に作り、Email Trigger はそのフォルダだけを読みます。業者からの見積や社内の連絡まで分類に流さないためです。

受け取ったメールは「Mark as Read」で既読にします。 未読のまま残すと、人が受信箱を開いたときに処理済みかどうかが分かりません。既読になっていないアラームのメールが残っていれば、ワークフローが拾えていないということです。

ワークフローそのものが止まったときの知らせを、別に用意します。 Error Trigger は、自動で動いているワークフローがエラーになったときに動くワークフローを作るノードで、元のワークフローの設定で、エラー時に動かすワークフローとして指定します。 手動での実行では動かないので、試すときは自動の実行で止めてみます。アラームを運ぶ仕組みが黙って止まるのが、いちばん困る失敗です。

加えて、Schedule Trigger で1時間ごとに受信箱を見て、既読になっていないアラームのメールが残っていないかを数えます。 Error Trigger は、トリガーのノード自体の不具合では実行の情報を持たないとされています。受け取り口の接続が切れた状態は、未読の数で拾います。

入力データを集める

質を決めるのは、緊急度の表です。 最初からすべてを埋める必要はありません。コンプレッサー、受変電、冷却水のように、止まると工場全体に響くものから書きます。 表に無いアラームはAIが分けますが、表にあるものはAIより先に決まります。

設備台帳の「止まったときに影響する範囲」の列は、AIが緊急度を分ける材料になります。 「全ライン」「この1台」「空調のみ」のように書いておくと、表に無いアラームでも、影響の広さから当日対応か記録のみかを分けられます。

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

監視の仕組みの見分けは、送信元のアドレスで行います。 件名や本文の書き方で推測しません。仕組みが分かれば、その書式で設備の番号を取り出せます。

同じメールの再送は、Remove Duplicates で落とします。 「Remove Items Processed in Previous Executions」の操作で、前の実行で処理した値と比べて、新しい値だけを残せます。比べる値はメールの Message-ID にします。 設備とアラームの番号で比べると、同じアラームが翌週にまた起きたときに落としてしまいます。 繰り返しのまとめは、時間の幅を持たせて別の段で行います。記録しておく件数は既定で10,000件です。

AIへ渡す前に整形する

1. 再送の除去 … Message-ID で、前の実行で処理したメールを落とします
2. 監視の仕組みの判定 … 送信元のアドレスで仕組みを決めます。一覧に無い送信元は「不明な送信元」として当日対応に置きます
3. 書式による取り出し … 仕組みごとの規則で、設備の番号・アラームの番号・発生か復旧か・発生の時刻を取り出します
4. 添付のCSVの分解 … 1通に複数のアラームが入っているものは、1行ずつ別の件に分けます
5. 取り出せなかったものの受け渡し … 設備の番号か、発生か復旧かが取れなかったものだけを、Information Extractor に渡します
6. 台帳と表の照合 … 設備台帳と緊急度の表を引き、表の緊急度があれば付けておきます
7. 時刻の確認 … メールの受信時刻と、本文の発生の時刻を両方残します。ずれが大きいものは、メールの遅れとして印を付けます

3番目と5番目の順を逆にしないでください。 全部をAIに渡すと、設備の番号の「M-12」と「M-21」のような取り違えが、ごく稀に起きます。書式で確実に取れるものは規則で取り、AIは規則が取れなかった分だけを受け持ちます。

7番目は、メールの遅れに気づくためです。 監視の仕組みのなかには、通信が切れている間のアラームを、つながった時点でまとめて送るものがあります。1時間前の発生がいま届いた、という件を、いま起きたものとして扱わないようにします。

AIに処理させる

させるのは2つです。取り出しの規則で取れなかった項目を本文から取り出すことと、緊急度を3つのどれかに分けることです。

Information Extractor で取り出すのは、設備の番号、設備の名前の表記、現象、発生か復旧か、本文に書かれた値（温度・圧力など）の5つです。 値は書かれたとおりに写させ、単位も本文のままにします。

現象は、自社で決めた区分のどれかに当てます。 温度・圧力・電源・通信・停止・品質・その他の7つで、台帳で設備ごとの傾向を数えるための区分です。

1行目は、AIの外の規則で守ります。 指示に書くだけでなく、AIの結果を受けた後に表の値と比べて、低ければ表の値に置き換える段をワークフローに置きます。指示が守られなかったときにも、結果が変わりません。

指示内容を固定する

Text Classifier には、3つのカテゴリーに上の表の「当たるもの」を説明として付けます。 System Prompt Template には次の文を入れます。

あなたは工場の保全課で、設備のアラームを読む順を決める補助をします。
アラームを次のどれか1つに分けてください。
{categories}

【判断の材料】
- 設備の名前と、止まったときに影響する範囲（設備台帳より）
- 現象、発生か復旧か、本文に書かれた値
- 同じ設備・同じアラームの過去24時間の回数
- 表で決めた緊急度（無い場合は「未登録」）

【厳守事項】
- 迷ったときは、重い方を選んでください。記録のみに入れてよいのは、
  復旧済み、または定期の通知であることが本文から読み取れるものだけです。
- 表で決めた緊急度があるときは、それより軽い方を選ばないでください。
- 「停止」「漏れ」「発煙」「異臭」「非常停止」「感電」「火災」に当たる表現が
  あれば、ほかの材料にかかわらず「すぐ対応」にしてください。
- 原因を推測しないでください。設備の操作の指示を書かないでください。
- 本文が英語でも、同じ基準で分けてください。

Information Extractor には、項目ごとに説明を付けます。 例えば設備の番号は「本文に書かれた設備の番号をそのまま写す。書かれていなければ空にする。似た番号に直さない」とします。

「迷ったときは重い方」と「記録のみに入れてよい条件」を組にしています。 重い方を選べとだけ書くと、全部を当日対応にします。記録のみに入れる条件をはっきりさせると、軽い方に入るものが限られ、それ以外が重い方に残ります。

出力形式を固定する

ワークフローの最後に、次の形で1件ずつ記録します。

{
  "alarm_id": "",
  "source_system": "molding | utility | compressor | tcu | unknown",
  "equipment_no": "",
  "equipment_name": "",
  "phenomenon": "temperature | pressure | power | network | stop | quality | other",
  "state": "occurred | recovered | unknown",
  "value_text": "",
  "occurred_at": "",
  "received_at": "",
  "urgency_ai": "immediate | today | log_only",
  "urgency_table": "immediate | today | log_only | none",
  "urgency_final": "immediate | today | log_only",
  "reason": "",
  "repeat_count_24h": 0,
  "group_id": ""
}

1つ目の理由は、urgency_ai と urgency_table と urgency_final を別に持てることです。 AIが軽く付けて表で上げた件が、後から数えられます。その件数が多い設備は、AIへの説明文か、設備台帳の影響の範囲の書き方を見直す合図です。

2つ目は、group_id で繰り返しを1件にまとめられることです。 同じ設備・同じアラームが過去24時間に開いたまま残っていれば同じ番号を付け、当番への通知は最初の1回と、回数が一定を超えたときだけにします。 50通の同じ件名が、当番の手元では1件になります。

3つ目は、state で発生と復旧をつなげられることです。 復旧の通知が届いたら、同じ group_id の発生の件を閉じます。第3章の（c）で人が受信箱を探していた作業が、ここで消えます。

value_text は数値に直しません。 「85.3℃」を数値の85.3に直すと、単位が華氏の機器の値と混ざります。単位を含めた文字列のまま残し、数値として比べるのは表で決めた機器だけにします。

システムへ連携する

監視の仕組みとはつながりません。 メールを受け取るだけで、アラームの確認や解除を仕組みの側に返すことはしません。設備の側へ何かを送る経路を作らないことが、この構成の前提です。

人が確認する

当番は、すぐ対応の知らせを受けたら、現場へ向かうかを決めます。 知らせには設備の名前・場所・現象・本文の値・過去24時間の回数が並びます。メールを開かなくても、行くかどうかを決められる形にします。

1. すぐ対応を見る … 当番が知らせを受け、現場へ向かうか、日勤に回すかを決めます。決めたら一覧に記録します
2. 当日対応を割り振る … 日勤の担当が朝と昼に一覧を見て、作業に入れます
3. 記録のみを流し見る … 毎朝、設備ごとに集計した一覧を見ます。同じ設備の記録のみが急に増えていれば、当日対応に引き上げます
4. 表を見直す … 係長が週に1回、urgency_ai と urgency_table が食い違った件と、人が緊急度を変えた件を見て、緊急度の表を直します

3番目を省かないでください。 記録のみのアラームは1件ずつは急ぎませんが、同じものが増えていくのは、壊れる前の設備によくある姿です。 1日1回の集計で、件数の変化だけは人が見ます。

夜勤の時間帯は、当日対応の件も翌朝まで待たせてよいかを表で決めておきます。 例えば冷却水や冷凍機は、夜のうちに当日対応が3回続いたら当番を呼ぶ、のように回数で引き上げる規則を足せます。

人が緊急度を変えたら、その理由を一言残します。 「この温調機は立ち上げのときに必ず出る」のような理由が、次に表へ書き足す行になります。

例外に対処する

6行目が、この構成の安全側の作りです。 AIが応答しないときに分類を止めず、表に無いものは重い方へ倒して回します。 AIが無くても、受け取りとまとめと回し先の振り分けは動き続けます。

3行目の「大量に届く日」は、停電の瞬断や空調の停止のように、原因が1つで多くの設備に出る日です。 まとめると件数は減りますが、原因が1つかどうかは保全課が見て決めます。 知らせには、同じ時間帯に出た設備の一覧を添えます。

記録を残す

• 受け取ったメールの Message-ID、送信元、件名、受信日時、本文
• 取り出した項目と、規則で取ったかAIで取ったかの区別
• urgency_ai、urgency_table、urgency_final と、AIが書いた根拠
• group_id と、まとめた回数、復旧で閉じた日時
• 人が緊急度を変えた記録 … どちらからどちらへ、その理由
• 当番への通知の日時と、当番が見たと記録した日時

2つ目の「規則で取ったかAIで取ったか」は、書式の一覧の手入れに使います。 特定の監視の仕組みでAIの取り出しが増えたら、その仕組みの書式が変わった合図です。

最後の行は、この構成の効き目を測る物差しです。 すぐ対応の件が、メールの受信から当番が見るまでに何分かかったかを、月ごとに見ます。