製造業の設備アラーム分析にAIを導入する方法｜履歴から原因候補を絞る

製造業で「設備アラーム分析にAIを導入したい」と考えるとき、最初の課題は故障を予言することではありません。停止の前後に大量のアラームが並び、どれが発端で、どれが結果なのかを現場が短時間で判別しにくいことです。本記事では、アラーム履歴と設備状態、作業記録を結び、AIで原因候補と確認順序を提示する実務的な導入方法を解説します。安全に関わる判断は既存のアラーム設計と運転手順に従い、AIは調査を助ける役割に限定します。

設備アラーム分析AIが解く問題は何か

設備が止まった瞬間、HMIにはモーター過負荷、搬送詰まり、下流待機、通信異常などの通知が同時に現れることがあります。すべてを同じ重みで上から読み、最初に目に入った通知を「原因」と決めると、結果として発生した二次アラームに引きずられます。一方、発生時刻の最初の1件だけを原因とみなすのも危険です。制御機器の時計がずれている、ロギングの遅延がある、予兆的なイベントと実際の停止要因が異なる、といった事情があるためです。

そこで扱う単位を「単独のアラーム」から「設備イベントのまとまり」に変えます。開始・復帰・確認・リセットの状態遷移を残し、停止前後のイベントを設備系統と工程で束ねます。AIは過去の類似ケース、アラームの発生順、状態値、作業票の記述を照合し、「確認すべき原因候補」を根拠付きで並べます。最終原因の確定、復旧操作、ライン再開の判断は現場の責任者が行います。

この用途は予知保全や異常検知とは別です。予知保全は将来の故障可能性を推定する取り組みです。異常検知は通常と異なる振る舞いを見つけます。ここでの設備アラーム分析は、すでに起きた、または起きているイベント群を読み解き、対応の順序を明確にします。既存の閾値や安全インターロックをAIに置き換える話ではありません。

英国HSEは、アラームが運転員の注意を必要な状態へ向け、必要な行動を知らせるべきだと説明しています。ISA-18.2もアラームの優先度、記録、運転手順、教育、評価、変更管理を継続的な活動として扱います。AIを入れる前に、アラームそのものが現場で意味を持つかを確認する理由はここにあります。

アラーム洪水では「件数削減」より確認順序を整える

短時間に多くの通知が押し寄せるアラーム洪水では、画面上の件数を減らすことだけを成果にしてはいけません。重要な警報を隠せば、見かけの件数が改善してもリスクが増します。まずは既存の優先度や安全分類を固定の条件として扱い、その中で重複・連鎖・工程状態による違いを整理します。安全に関わる通知の抑制や優先度変更は、設備管理者の変更管理を経るべき作業です。

具体例を考えます。搬送コンベヤーの入口センサーがワーク滞留を検知し、数秒後にモーター過負荷、さらに下流側に「搬送待ち」が出たとします。三つの通知が連続したからといって、AIは「入口センサーが根本原因」と断定できません。センサーの汚れ、実際のワーク詰まり、モーター駆動系の故障、時刻同期のずれがあり得ます。そこで、候補を「入口のワーク詰まり」「センサー誤検知」「駆動系異常」に分け、各候補を確認する観察点を示します。例えば、停止時のセンサー波形、モーター電流、作業員による現物確認です。

候補の横には「根拠」と「反証になり得る情報」を並べると実用的です。根拠は「同じ設備・同じ品種で過去に同じ順序があった」、反証は「停止時のモーター電流が正常なら過負荷仮説を再検討」といった形です。このように見せれば、AIの提案を鵜呑みにせず、短時間で検証できます。

導入前に整えるアラーム履歴のデータ項目

最初に確認するのは、HMIの画面を撮影できるかどうかではなく、イベントの履歴を再現できるかどうかです。最低限、設備ID、アラームID、発生・復帰時刻、状態、優先度、メッセージ、運転モード、製品またはロット、シフト、停止イベントIDを確認します。原因分析に使うなら、確認時刻と確認者、リセット、手動停止、保全対応、再開時刻も有用です。個人情報を含む場合は必要性と閲覧権限を整理します。

OPC UAのAlarms & Conditionsは、状態を持つConditionと状態変化によるEventのモデルを定義しています。OPC UA Part 11は履歴イベントの扱いを定義します。ただし、OPC UAを使えば履歴が自動的に長期保存されるという意味ではありません。OPC Foundationは、アラームログの保管がクライアント側の機能であり、履歴で利用できるフィールドは保存設定に依存すると説明しています。接続プロトコルの有無と、調査に必要な履歴が実際に残っているかは別々に確認します。

時刻品質は特に重要です。PLC、HMI、SCADA、MES、保全システムの時刻が違えば、見かけの「最初のアラーム」は誤ります。記録には元時刻と受信時刻を分け、タイムゾーンと時刻同期の状態を保持します。分析時には順序を一意に確定できないイベントを「同時または順序不明」と表示する方が、誤った因果説明を作るより安全です。時刻精度を評価せずにミリ秒単位の順序から原因を語るべきではありません。

アラーム名だけで意味を理解させようとせず、設備構成表も用意します。親設備、上流・下流の関係、センサーとアクチュエータ、工程の入口と出口、インターロック関係を対応付けます。設備改造でタグ名が変わる場合は有効期間を持たせます。タグ「ALM_003」が何を示したかを当時の構成で復元できなければ、過去事例との比較は不安定になります。

先に確認するデータ品質チェック

表は導入時の確認例です。すべての設備が同じ項目を持つ必要はありません。ただし、欠損を隠して「原因を特定した」と表示しない運用は共通です。

AIによる原因候補の絞り込みはどう動くか

実装は、ルール、統計、言語モデルを役割別に組み合わせるのが現実的です。第1段階では設備のアラーム優先度、安全分類、運転モード、既知のインターロックをルールで守ります。第2段階では、同じ時間窓で頻繁に連鎖するイベント、最初の発生から復帰までの長さ、設備間の位置関係を使い、候補となる事象群を作ります。第3段階で、作業票や過去の対処記録を検索し、似たケースと異なるケースを表示します。

言語モデルは、タグ名、作業票、メーカーの説明、現場メモを読み、運転員が分かる文章に整理する用途に向きます。ただし、もっともらしい説明を生成できても、設備の物理状態を直接観測したわけではありません。「原因はベアリング摩耗」と断定する代わりに、「過去の作業票ではベアリング交換で解消した例がある。今回は振動記録と現物確認が必要」と記載します。参照したイベントIDと文書版を表示し、出典がない推測は推測だと明示します。

過去の復旧結果を教師データにする場合も注意が必要です。作業票の「清掃したら動いた」は、汚れが根本原因だったことを証明しません。ほかの調整や自然復帰が同時に起きたかもしれません。ラベルは「確認済みの原因」「有力な仮説」「処置のみ記録」「原因未確定」に分けます。未確定の事例を正解として学習させると、AIは現場の思い込みを再生産します。

候補を並べる際には、単純な出現頻度だけでなく、時間順、設備の接続関係、運転モード、処置後の再発有無を合わせて評価します。ただし、重み付けの方法が何であっても、表示するのは「調査の優先順」です。安全上の優先度をAIの類似度スコアが上書きしないよう、表示と権限を分けます。

設備アラーム分析AIの導入手順を5段階で進める

1. 対象設備と調査場面を絞る

全工場のすべてのアラームから始めると、タグの意味も作業票の粒度もそろわず、評価が難しくなります。まずは停止後の調査に時間がかかり、同種のアラーム連鎖が繰り返される設備群を一つ選びます。例は搬送設備、包装ライン、ポンプ群、空調設備などです。何を改善するかも「停止の予測」ではなく、「最初の原因候補を探す時間」「確認すべき履歴を集める時間」と明文化します。

設備管理、製造、保全、品質が同じ目的を共有することも必要です。品質に関係するアラームなら、再開だけを成功とみなさず、対象ロットの隔離・確認を含めます。工程が連続する場合は、上流の異常で下流通知が大量に出ることがあります。対象範囲を決める段階で、上流・下流を含めてログを取る範囲を決めます。

2. アラーム台帳と判断ルールを確認する

設備ID、タグ、説明、優先度、必要な運転員の行動、対応期限を台帳で確かめます。安全・環境・品質の重大アラームは別分類にし、AIの候補順位より優先する条件を明示します。ISAのアラーム管理資料は、優先度、手順、教育、履歴保持、監査をライフサイクルの要素として挙げています。AIプロジェクトが台帳の欠陥を見つけた場合、モデルで覆い隠さず、設備側の是正として扱います。

アラームに必要な対応が定義されていない場合、その通知は分析対象として使えても、行動の提案には直結できません。「何を見て、誰に伝え、何をしてはいけないか」を現場の手順に落とすことが先です。緊急停止や安全系のインターロックを解除する判断をAIに委ねない設計をここで確定します。

3. 過去ケースを束ね、正解の質を分ける

停止イベントIDを軸に、停止前後のアラーム、設備値、作業票、原因判定、処置、再開確認を結びます。過去ケースを数だけ集めても、作業票が「設備異常」の一語で終わるなら根拠には使えません。原因の確度で層を分け、現場責任者が確認した事例を優先して評価に使います。初期段階では20件や100件といった固定の閾値を設けるより、対象設備の典型的な異常パターンを覆っているかを見るべきです。

この時点で「似たアラーム列でも違う原因だった」事例を意図的に選びます。それが誤った確信を見つける試験になります。過去ケースの記録だけで判定できなければ、無理に原因ラベルを作らず「判定不能」とします。記録の改ざんや後からの推測を防ぐため、元イベントと人が付けた注釈を別々に保存します。

4. 現場に見せる前に過去データで検証する

過去の停止を時系列に分け、古い期間で設定し、新しい期間で試します。同じ停止イベントの一部が学習側と評価側に分かれると、見かけの精度が高くなります。判定したいのは「正解原因が候補上位に入ったか」だけではありません。安全・品質に関わるケースで必要な警報を見落とさなかったか、根拠が正しいイベントを指したか、知らないケースで適切に「不明」と答えたかを調べます。

指標は、上位候補への正解包含率、調査着手までの時間、運転員が根拠を開けた割合、誤誘導の件数などを組み合わせます。数値目標は工場の現状を測ってから決めます。「AIで停止時間が必ず半減する」といった一般化はできません。対照として、同じ種類の停止に従来手順で対応した時の時間も残します。

5. 影運用から始め、変更管理で広げる

初期はAIの提案を実作業の横に表示し、運転員の対応を変えずに比較します。誤りを記録し、原因候補の表示方法、設備辞書、作業票の検索範囲を改善します。次に、許可された設備とシフトで調査補助として使います。運転手順の変更、アラーム優先度の変更、自動制御への接続は別の承認プロセスに分けます。EEMUA 191が扱う設計・管理の考え方や、NIST AI RMFが示す人による監督と継続的な評価は、こうした段階的導入と整合します。

画面には「上位候補」だけでなく検証手順を出す

使いやすい画面は、AIが長い説明文を出す画面ではありません。運転員が「今、何を確認するか」を短時間で判断できる画面です。上部には安全・品質の重大アラームを既存の優先度で表示し、その下に今回の停止イベントを一つの束として表示します。候補ごとに、発端となり得るイベント、関連する設備値、過去事例、確認事項、確認できなかった情報を並べます。

例として「搬送入口のワーク詰まり」の候補を出すなら、単に「可能性80%」と示すより、「入口センサーONが継続」「モーター電流上昇」「同じ型番の品種で過去に詰まり対応」のような根拠を見せます。モデルの数値が校正されていない段階で確率表示を使うと、数字が客観的な故障確率に見えるおそれがあります。必要なら「高・中・低」などの順位表現から始め、検証で意味が確かめられた数値だけを使用します。

各候補には、反証の方法を添えます。「現物に詰まりがなければ、センサー汚れと駆動系を確認」「電流履歴が欠けているため、この候補は低信頼」といった説明です。AIが分からない状態を表現できることが、導入時の重要な品質です。運転員が候補を却下した理由と実際の処置を記録すれば、次の改善にも使えます。

費用を考えるときは接続範囲と運用負荷を分ける

設備アラーム分析AIの費用は、AIモデルの利用料だけでは決まりません。既存設備からイベントを取れるか、履歴の保存期間は足りるか、時刻同期は整っているか、設備辞書と作業票を結べるかで初期作業が変わります。HMIやSCADAから履歴を出せても、復帰・確認の状態が欠ける場合には、ログ側の改修が必要になることがあります。さらに、設備改造時のタグ更新、現場レビュー、権限管理、モデル評価は継続費用です。

見積もりを比較するときは、対象設備数だけでなく、対象タグ数、取得項目、保存期間、接続方式、既存システムの改修有無、画面と現場教育、月次のレビュー範囲をそろえます。AIの回答精度だけを契約条件にせず、根拠を遡れること、重大アラームを隠さないこと、誤提案を報告できることも受け入れ条件に入れます。

PoCで確認したいのは「デモで正しい説明が出たか」ではなく、実際の履歴で調査時間を短縮し、誤誘導を増やさないかです。最初から全工場へ展開する見積もりより、設備1群でデータ品質、評価、運用手順を確認した後に拡張費用を算定すると、見積もりの前提が明確になります。

失敗しやすい設計と対処

第一は、アラーム洪水を画面上でまとめたことを原因分析と取り違えることです。類似通知のグルーピングは見やすさを改善しますが、発端を証明しません。まとめた後も元イベントを開けるようにし、順序や状態を確認できる必要があります。第二は、タグ名や作業票の自然言語をそのまま学習させ、設備改造や記録の誤記を無視することです。辞書の版と文書の有効期間を持たせます。

第三は、AIの回答を作業指示として直接使うことです。特に安全・品質・環境に影響する事象では、既存手順が優先されます。AIは原因候補と照会先を提示し、運転員が実機、手順書、責任者と照合します。第四は、評価対象を成功したケースだけにすることです。原因未確定、ログ欠損、複数原因、時刻不整合を含め、適切に保留できるか確認します。

第五は、稼働開始後に見直さないことです。設備改造、品種変更、季節変動、保全方法の変更で、同じアラーム列の意味が変わり得ます。ISAが強調する監視・評価と変更管理、NIST AI RMFが示す継続的な測定の観点からも、誤提案を収集し、設備辞書と評価事例を更新する担当を決めておきます。

既存の停止監視や品質トレーサビリティとどう連携するか

停止監視は「いつ、どれだけ止まったか」を正確に把握する土台です。アラーム分析は「その停止の前後に何が起き、何を先に確かめるか」に踏み込みます。両者を結ぶキーは停止イベントID、設備ID、時刻です。停止分類とアラーム群を結び、同じ停止を別々に数えないようにします。停止監視の設計を検討する場合は、チョコ停削減と設備監視の記事も参考になります。

品質トレーサビリティは対象ロットや工程条件と不良の関係を追います。設備アラーム分析では、品質に影響し得るアラームが出たとき、どのロットが該当するかを照会できると判断が速くなります。ただし、アラームが出たことだけで製品不良を断定しません。検査結果、ロット境界、工程変更を合わせて評価します。原因調査の横断的なデータ連携は、不良原因とトレーサビリティの記事を併せて参照してください。

クリーンルームや環境監視では、設備アラームの意味が温湿度、差圧、環境条件と結び付くことがあります。その場合も、監視値の逸脱、センサー異常、設備故障を区別する必要があります。本記事が対象とするのは、こうした複数システムのイベントを突合し、確認の順番を示す部分です。

PoCの受け入れ条件をどう書くか

PoCを発注する前に、成功の条件を文章で合意します。例えば「対象の包装ラインで、直近の停止事例を時期で分け、評価用の各事例について上位三つの候補、根拠となるアラームID、確認すべき現物と設備値を表示する」という条件です。そのうえで、原因が現場でも確定していない事例には「確定不能」を許し、安全・品質の重大通知が候補の表示順位に埋もれないことを確認します。期間や件数は、実際に取得できる履歴と停止頻度で決めます。

また、現場が使う画面の操作条件も重要です。停止イベントから該当アラーム群を開くまでの手順、根拠を元ログに遡る操作、候補を却下する入力、異なるシフトへの引き継ぎ方法を試します。分析の結果が正しくても、根拠を確認するまでに多数の画面遷移が必要なら、現場での効果は限定されます。設備からデータが取れない期間、ネットワークが切れた期間、タグが変更された直後も、AIが「分析できない」と明示し、通常の運転手順に戻れることを試験します。

受け入れ条件には誤りの報告と再評価の運用も含めます。月次のレビューで、誤った候補、根拠のない提案、記録されなかった復旧操作を集め、設備辞書や検索対象の文書を更新します。更新後は同じ事例で改善を確認するとともに、以前は正しく扱えていた安全・品質事例を再試験します。モデルやプロンプトを変えた日付、データ範囲、評価結果を記録しておけば、「どの版のAIが何を提示したか」を後で追跡できます。

タイ工場など複数言語の現場で注意すること

日本語の本社資料、英語の装置マニュアル、タイ語やベトナム語の作業票が混在する工場では、単語の翻訳だけで設備タグの意味がそろうわけではありません。同じ「詰まり」でも、供給不足、排出側の滞留、センサー位置で現場が使う呼び名が変わります。設備IDとイベントIDを言語に依存しない共通キーにし、表示名と説明文を各言語で管理します。原文を保持したまま翻訳文を追加し、技術的な判断に使う語は現場担当者が確認します。

シフト間の引き継ぎでも、AIの文章だけを残すのではなく、元イベント、確認した現物、未確認の点、実施した処置を構造化して記録します。あるシフトが「センサーを清掃した」と書いた場合、次のシフトは清掃前後の値と再発の有無を見られるべきです。こうした記録がたまると、単なるアラーム件数の集計から、対処の有効性を見直す運用に進めます。

AI提案を現場で扱うための責任分担

設備アラームの分析結果は、製造、保全、品質、情報システムで見方が異なります。製造担当は安全な停止と現物確認を優先し、保全担当は設備構成と故障履歴を確認します。品質担当は影響した可能性のあるロットと検査条件を調べ、情報システム担当はデータ欠損や時刻同期、アクセス権を扱います。AIが一つの画面に情報を集めても、各担当の判断責任を曖昧にしないことが重要です。候補の採否、実施した処置、再開承認を誰が記録するかを導入前に決めておきます。

原因候補を表示した後は、操作履歴を残します。AIの版、参照したイベントの範囲、表示した候補、運転員が開いた根拠、候補を採用または却下した理由を、停止イベントに結びます。これにより、後日「AIが何を根拠に提案し、人が何を確認して復旧したか」を区別できます。学習に使うフィードバックも、単なるボタンの賛否ではなく、現物確認や保全結果に紐付けます。根拠がない却下や採用を正解ラベルとして扱わないためです。

現場でAIサービスが使えなくなった場合の手順も用意します。ネットワークや履歴サーバーが停止したときは、古い候補を現在の状態のように表示せず、取得できた最終時刻と欠けている情報を示します。既存のHMIと紙または電子の運転手順で対応できる状態を維持し、AIの復旧を待つために安全確認を遅らせない運用にします。再接続後には欠落期間を識別し、当該期間のケースを通常の精度評価から分けて確認します。このような障害時の振る舞いもPoCで試すべき項目です。

導入後の成果をどの指標で見るか

AIを導入した後は、回答の正解率だけで効果を評価しません。まず、停止イベントの発生から調査を始めるまでの時間、必要なログと作業票をそろえるまでの時間、現物確認を終えるまでの時間を分けて記録します。AIの寄与を判断するには、同じ設備と似た運転条件での過去期間、または影運用期間と比べます。停止の重さや品種が違う事例を一緒に平均すると、改善したように見えても説明できません。停止時間は生産計画や部品待ちにも左右されるため、AIの評価指標を停止時間だけに絞らないことが大切です。

次に、提案の安全性と使われ方を追います。重大アラームの見落とし件数、候補に根拠が付いた割合、元ログを開いて確認した割合、原因不明を適切に保留した割合、誤った候補によって遠回りした件数を記録します。「候補を提示した回数」が多くても、運転員が根拠を見ずに却下しているなら画面設計かデータ品質を見直します。逆に採用率が高くても、現物確認が省かれているなら運用上の問題です。数値と一緒に、誤提案の事例と現場のコメントを残します。

月次レビューでは、対象設備の改造、タグの追加、品種や運転条件の変更を確認します。同じアラームの意味が変わる変更があれば、過去ケースの検索条件と評価セットを更新します。改善を急ぐあまり、以前のデータで良好だった結果だけを示してはいけません。新しい期間で再評価し、導入時に定めた受け入れ条件に照らして、利用範囲を広げるか、限定するか、いったん止めるかを決めます。指標を「AIの成績表」にせず、現場の調査手順を良くするための材料として扱います。

よくある質問

設備アラーム分析AIとは何ですか？

設備から出たアラーム履歴を、運転状態、設備構成、過去の作業記録と合わせて読み、原因候補と確認すべきデータを提示する仕組みです。発生していない故障を予測する予知保全とは目的が異なります。候補を提示しても原因確定や復旧判断を自動化するものではありません。

既存のPLCやHMIを入れ替える必要がありますか？

必ずしも必要ではありません。既存のHMI、SCADA、ヒストリアンなどから必要な履歴を取り出せる場合があります。ただし、発生時刻だけで復帰、確認、運転モードが残っていない場合、ログ設定や接続方式の見直しが必要です。可否は設備と保有データを調べて判断します。

アラーム洪水をAIで自動抑制しても安全ですか？

一律の自動抑制を前提にすべきではありません。アラームの優先度、安全分類、必要な対応は設備の管理手順に従います。AIで重複や連鎖を画面上に整理しても、元の重大アラームへ辿れることが必要です。実際の抑制や設定変更は、設備管理者の評価と変更管理で決めます。

設備アラーム分析AIの費用はどう決まりますか？

対象設備数、タグ数、履歴の品質、接続方式、作業票との連携、現場画面、教育、継続的な見直し範囲で変わります。モデル利用料だけの比較では不足します。まず対象設備を一つに絞り、必要なデータと受け入れ条件を確認した上で見積もるのが実務的です。

原因候補の正しさはどう検証しますか？

現場が原因を確認した過去ケースを、時期で分けて評価します。正解原因が候補に含まれたかに加え、安全・品質に関わる通知の見落とし、根拠の追跡可能性、原因不明時の保留、調査時間、誤誘導を見ます。導入後も運転員の指摘と設備変更を反映して再評価します。

まとめ

製造業の設備アラーム分析にAIを導入する目的は、大量の通知から「ありそうな原因」を断定することではなく、イベントのつながりを整理し、現場が確認すべき順番を明確にすることです。実装の出発点は、アラーム台帳、時刻品質、設備構成、作業記録です。既存の安全優先度と運転手順を守り、根拠と反証を示す画面で過去データと影運用を検証してから範囲を広げます。

アラーム履歴がどこまで使えるか、どの設備から試すべきかを検討している段階でも、TOMAS TECHへのお問い合わせからご相談いただけます。現在の設備構成と調査手順を確認し、必要なデータと小さく始める範囲を一緒に整理します。

参考情報

• ISA, ISA-18 Series of Standards：アラーム管理のライフサイクル、優先度、性能監視。
• ISA, Alarm management life cycle：アラーム分類、記録、教育、変更管理。
• OPC Foundation, OPC UA Part 9: Alarms & Conditions：ConditionとEventのモデル。
• OPC Foundation, OPC UA Part 11: Historical Access：履歴イベントの仕様。
• UK Health and Safety Executive, Alarm management：運転員に必要な行動を知らせるアラームの原則。
• EEMUA, Publication 191：アラームシステムの設計・管理指針。
• NIST, AI RMF Core：人による監督、評価、リスク管理。