設備の振動や温度、電流などを監視し、異常検知モデルが一定の性能を示したとしても、それだけで予兆保全の仕組みが完成するわけではありません。
本番運用へ進む段階で、しばしば問題になるのが「異常通知が出た後、誰が何をするのか」です。
例えば午前2時に設備の異常通知が発生した場合、その通知を誰が確認するのでしょうか。担当者個人のメールに届くだけでは、就寝中、休暇中、出張中などに確認されない可能性があります。複数人へ一斉送信しても、「誰かが確認するだろう」と責任が曖昧になる場合があります。
予兆保全を実際の保全業務へ組み込むには、モデル精度だけでなく、一次確認担当、確認手順、アラートの重要度、エスカレーション、夜間・休日対応、対応履歴、定期レビューまでを一つの運用として設計することが重要です。
予兆保全は「異常を検知できたら完成」ではない
異常検知モデルの役割は、設備データの変化から「通常とは異なる可能性がある状態」を見つけることです。
しかし、異常スコアが上昇したからといって、直ちに設備を停止すべきとは限りません。運転条件の変更、負荷変動、センサーの状態などによって値が変化する場合もあります。
そのため、実運用ではモデルから出力された情報を、現場の保全判断へ変換する工程が必要になります。
大きく分けると、アラート処理は次の6段階で整理できます。
IEC 62682:2022はプロセス産業のアラームシステムを対象とする規格であり、予兆保全AIの通知を直接規定するものではありません。ただし、アラームの主要な役割を、異常状態や設備不具合をオペレーターへ知らせ、その対応を支援することと位置付けています（IEC, 2022）。
予兆保全でも、「通知を発生させる」ことを目的にするのではなく、通知された情報から必要な確認・判断・対応を行える状態を作ることが重要です。
夜中に異常通知が来たら誰が確認するのか
説明用の仮想例として、午前2時10分に稼働中のポンプから異常通知が発生したケースを考えます。
通知には、対象設備、検知時刻、異常状態の概要、関連データを確認するための情報が含まれているものとします。
ここで最初に決めるべきなのは、通知手段よりも「誰が一次確認の責任を持つか」です。
個人名だけで運用すると、人事異動、休暇、夜間勤務体制の変更等に弱くなります。そのため、「夜間当番」「保全当直」など、役割・当番として定義し、その役割に担当者を割り当てる方法が考えられます。
午前2時10分の通知を受けた一次確認担当は、例えば次の事項を確認します。
- 対象設備が現在も運転しているか
- 異常状態が継続しているか、一時的な変化だったか
- 振動、温度、電流、負荷等の関連データにも変化があるか
- 回転数、流量、生産品種等の運転条件に変化がなかったか
- PLCや設備監視システムから別の警報が発生していないか
- 直近に点検・部品交換・運転条件変更等がなかったか
その結果に応じて、経過観察、追加確認、保全担当への連絡、生産責任者等による運転判断へ進みます。
ここで重要なのは、一次確認担当者がそのまま設備停止の最終意思決定者である必要はないことです。通知確認、技術的な状態判断、生産停止判断は、それぞれ別の権限・役割として設計できます。
アラート運用で最初に決めたい5つの役割
予兆保全アラートを本番運用する前に、少なくとも次の役割を整理しておくと責任の空白を減らしやすくなります。
1．アラート所有者
そのアラートルールや運用全体について責任を持つ役割です。通知先、確認内容、運用方法、見直し等について管理します。
2．一次確認担当
通知を最初に確認し、必要な情報を集める担当です。必ずしも詳細な故障診断や設備停止判断まで担当する必要はありません。
3．設備・現場確認担当
必要に応じて対象設備の外観、音、振動、漏れ、周辺設備などを現場で確認します。無人時間帯などでは、いつ・誰が現場確認できるかも事前に決めます。
4．保全判断担当
点検継続、部品交換、計画保全への組込みなど、設備保全上の対応方針を判断する役割です。
5．運転・生産に関する最終意思決定者
生産停止、減速運転、ライン切替など、生産計画へ影響する対応について必要な権限を持つ担当者です。設備の重要度や組織規模によって、保全判断担当と同じ場合も異なる場合もあります。
実際の組織では、一人が複数の役割を兼ねても構いません。重要なのは、役割ごとの責任が明確になっていることです。
異常通知を受けた後に何を確認するか
通知文に「異常を検知しました」とだけ表示されても、担当者は次の行動を判断しにくくなります。
そのため、アラートごとに一次確認項目をあらかじめ定義しておきます。
| 確認観点 | 確認する内容の例 |
|---|---|
| 異常の継続性 | 一時的な変動か、現在も異常傾向が続いているか |
| 関連センサー | 振動だけでなく、温度、電流、圧力等にも変化があるか |
| 運転条件 | 負荷、速度、流量、品種、運転モード等が変わっていないか |
| 既存警報 | PLCや設備監視システムで他の警報が出ていないか |
| 保全履歴 | 直近に点検、部品交換、調整等を行っていないか |
| 現場状態 | 音、振動、漏れ、臭い等について現場確認が必要か |
アラートごとに確認項目が決まっていれば、担当者の経験だけに依存しにくくなります。また、後から対応品質を振り返りやすくなります。
アラートの重要度・緊急度をどう分けるか
すべての異常通知を同じ扱いにすると、軽微な変化と重要な異常が同じ通知経路へ流れ、必要な情報が埋もれる可能性があります。
そこで、設備重要度、異常の程度、継続性、生産影響、安全・品質への影響などから、通知の扱いを整理します。
| 観点 | 低 | 中 | 高 |
|---|---|---|---|
| 状態 | 経過観察候補 | 追加確認候補 | 速やかな判断が必要な可能性 |
| 通知 | 通常の通知経路 | 優先度を上げた通知 | 事前に定めた緊急経路 |
| 担当 | 通常の担当者 | 保全担当を含めて確認 | 必要な責任者を含めて判断 |
| 記録 | 残す | 残す | 残す |
この表は概念例です。具体的な閾値や対応時間は、対象設備の重要度、安全要求、有人・無人運転、夜間体制、生産への影響等を踏まえて企業ごとに定めます。
また、Severity（影響の大きさ）とPriority（対応優先度）は必ずしも同一ではありません。影響が大きい設備でも、変化が緩慢で計画的に確認できる場合があります。一方、影響範囲が比較的小さくても短時間で状態が変化する場合には、早い確認が必要になることがあります。
エスカレーションルールをどう設計するか
アラート運用では、「誰に通知するか」だけでなく、どの状態になったら次の担当者へ判断を移すのかを決めておきます。
- 異常状態が一定時間継続している
- 複数の関連指標に変化が出ている
- 既存の設備警報も同時に発生している
- 現場確認で通常と異なる状態が確認された
- 設備の安全・品質・生産への影響を判断する必要がある
- 一次担当だけでは技術的な判断ができない
ここでも具体的な条件は設備ごとに設定します。異常スコアが特定値を超えたことだけを理由に設備停止へ結び付けるのではなく、関連情報と合わせて判断できる構成にします。
さらに、担当者が通知を確認できなかった場合の代替経路も必要です。「一次担当が不在の場合は誰へ移すか」「未確認状態が続いた場合はどう扱うか」「同じ異常が再発した場合に扱いを変えるか」などを決めておきます。
夜間・休日・担当者不在時の対応を決める
平日日中に成立する運用が、そのまま夜間や休日にも成立するとは限りません。
例えば夜間無人の工場では、通知を受信できても現場確認をすぐに行えない場合があります。夜間勤務者がいる工場でも、設備保全の専門担当が常駐しているとは限りません。
そのため、時間帯ごとに次の事項を整理します。
- 一次確認を行う役割
- 現場確認が可能か
- 保全担当へ連絡できる条件
- 生産責任者へ判断を移す条件
- 担当者不在時の代替者
- 翌営業日まで保留できるアラートの扱い
「夜間は必ず電話」「重大通知は必ず何分以内」といった一律のルールではなく、設備のリスクと実際の勤務体制に合わせて設計することが重要です。
アラートが多すぎる場合に見直すポイント
異常検知を本番運用すると、PoCでは見えなかった大量通知の問題が発生することがあります。
同じ設備状態について短時間に何度も通知されたり、運転条件変更のたびに異常判定されたりすると、担当者の確認負担が増えます。こうした状態が続くと、重要な通知まで軽視される可能性があります。
通知が多い場合には、単純に閾値を厳しくする前に、次の点を確認します。
- 同じ異常の重複通知が発生していないか
- 一時的な変動だけで毎回通知されていないか
- 運転条件変更を異常と誤認していないか
- 正常復帰後の再通知ルールが適切か
- 通知先が必要以上に多くないか
- 重要度の低い情報まで即時通知していないか
IEC 62682やISA-18系のアラーム管理はプロセス産業を対象としていますが、アラームの優先度付け、運用手順、教育、履歴、監視・評価、変更管理をライフサイクルとして継続管理する考え方は、予兆保全アラートを運用する際にも参考になります（Fitzpatrick, 2018）。
対応履歴をモデル改善につなげる
アラート対応は、通知を閉じたら終了ではありません。対応結果を残すことで、運用とモデルの両方を改善するためのデータになります。
最低限、次の情報を記録できるようにします。
- 対象設備
- アラート発生日時
- 確認した担当者
- 確認日時
- 確認したデータ・現場状態
- 判断内容
- 実施した対応
- 実際に設備異常があったか
- 保全結果
- アラートが有効だったか、誤報だったか
例えば、特定の運転条件で同じ誤報が繰り返されていることが分かれば、閾値やモデルだけでなく、運転条件の扱いそのものを見直す材料になります。
逆に、アラートは出ていたのに保全行動へつながらなかった場合には、モデル性能ではなく、通知経路や判断権限、夜間体制に問題があった可能性もあります。
設備条件、センサー、保全方式、組織、通知方法が変更された場合には、アラート運用ルール自体も再確認します。
本番運用前のアラート対応チェックリスト
| 観点 | 確認項目 |
|---|---|
| 責任体制 | アラートのOwnerが決まっているか |
| 一次確認担当が決まっているか | |
| 最終判断を行う役割が明確か | |
| 夜間・休日 | 時間外の一次確認担当が決まっているか |
| 担当者不在時の代替者がいるか | |
| 現場確認できない場合の扱いが決まっているか | |
| 確認手順 | アラートごとの一次確認項目があるか |
| 関連データへのアクセス方法が明確か | |
| 既存設備警報との確認方法が決まっているか | |
| エスカレーション | 上位判断へ移す条件が決まっているか |
| 誰へ連絡するか明確か | |
| 未確認・再発時の扱いが決まっているか | |
| 通知品質 | 重複通知が多すぎないか |
| 重要度の低い通知が多すぎないか | |
| 必要な情報が通知内容に含まれているか | |
| 改善 | 対応履歴を保存しているか |
| 誤報・有効通知を定期的に振り返っているか | |
| 設備・組織変更時にルールを見直しているか |
このチェック項目の数だけで、運用の良否を自動的に判定するものではありません。
異常通知を実運用へ移す際は、通知先だけでなく、一次確認担当、確認項目、エスカレーション先、夜間・休日の代替体制、対応履歴まで一つの業務フローとして整理します。AIが異常を検知できても、その後の判断経路が曖昧であれば、保全行動につながらない場合があります。
まとめ
予兆保全では、異常検知モデルが完成した時点で運用が完成するわけではありません。アラートを実際の設備保全判断へつなげるためには、通知後の業務プロセスを設計する必要があります。
特に、誰が一次確認するのか、夜間・休日は誰が対応するのか、何を確認するのか、どの状態で上位担当へエスカレーションするのかを明確にしておくことが重要です。
また、アラートを受信した担当者と設備停止の最終意思決定者は、必ずしも同じである必要はありません。一次確認、技術判断、生産・運転判断の役割を分け、必要な情報が適切な担当者へ届く構成にします。
さらに、対応結果を記録し、誤報、見逃し、重複通知、確認手順などを定期的に振り返ることで、モデルだけでなく運用そのものも改善できます。
SCI総合研究所株式会社のMIRASENTでは、「異常検知モデルはできたが、誰がアラートを確認するか決まっていない」「夜間・休日を含む運用フローを整理したい」「誤報への対応やエスカレーションルールまで設計したい」といった段階から、対象設備、保全体制、既存の点検・連絡手順、取得データ、アラート後に必要な判断等を整理しながら運用方法を検討します。
AIモデルの構築だけでなく、異常通知を実際の設備保全判断へつなげられる運用体制まで含めて整理します。
参考文献
- International Electrotechnical Commission. 2022. Management of alarm systems for the process industries. IEC 62682:2022. Edition 2.0. https://webstore.iec.ch/en/publication/65543
- International Society of Automation. 2016. ANSI/ISA-18.2-2016 Management of Alarm Systems for the Process Industries. ISA. https://www.isa.org/standards-and-publications/isa-standards/isa-18-series-of-standards
- Fitzpatrick, B. 2018. Alarm management life cycle. InTech. International Society of Automation. https://www.isa.org/intech-home/2018/march-april/features/alarm-management-life-cycle