設備ログから異常候補を見つけるには｜運転条件・誤報・現場確認のPoC設計

温度や電流などの設備ログが蓄積されていても、毎日すべての変化を確認するのは大変です。普段と違う動きを候補としてまとめ、担当者が調べる順番を決められないか。こうした課題では、異常検知のPoCが選択肢になります。

最初に試すのは、一つの設備と限られた計測項目です。候補の表示と現場確認までを対象とし、設備の自動停止や安全制御、故障原因の自動確定は含めません。既存の警報や保安手順も置き換えません。

「普段と違う」と「故障」を分ける

普段と異なる値が出ても、故障とは限りません。起動直後、製品の切替え、清掃、外気温の変化でもログは動きます。一方、重要な故障がいつも大きな数値の変化として現れるとは限りません。

scikit-learnの公式資料は、異常を含むデータから外れ値を探す場合と、正常なデータを基に新しい観測を判断する場合を区別しています。どの方法を使うか以前に、学習に使う期間に何が含まれているかを整理する必要があります。

PoCでは、モデルが出す「普段からの外れ具合」と、現場が付ける「点検が必要」「運転条件による変化」「原因不明」を分けて記録します。スコアを故障確率と呼ぶ場合は、その意味を別に検証しなければなりません。

ログの日時、単位、記録間隔、センサーの交換履歴を確認します。欠測をゼロで埋めると、停止したように見える場合があります。値が取れていない状態と、実際にゼロだった状態を区別してください。

履歴がある期間だけでなく、季節や運転条件が偏っていないかも調べます。設備ごとの癖が大きい場合、複数台のデータをまとめる前に、同じ条件として比べられるかを確認します。

温度が一定値を超えたら確認するなど、既存の単純なルールを比較対象に残します。AIを使う理由は、従来のルールでは拾いにくい組み合わせや変化を、現場の負担を増やさず見つけられるかです。

モデルの調整に使う期間と評価する期間を分けます。時系列の近い行を無作為に混ぜると、同じ運転の似た状態が両方へ入り、実運用よりよく見えることがあります。将来の期間で使う想定に合わせて、時間の順序を意識した評価を設計します。

以下は説明用の仮例です。通常運転と立ち上げ直後の温度を一緒に比較した結果、毎朝の立ち上げが異常候補に上がるとします。

その場合は、候補を無条件に消す前に、運転状態を分けて評価できるかを調べます。立ち上げ中にも確認すべき事象はあり得るため、状態ごとに何を見逃してはいけないかを現場と合意します。警報件数が減ったことだけを成功とはしません。

候補が毎日大量に出ると、確認が追い付かなくなります。候補のうち点検が必要だった割合、不要な通知の件数、見逃した既知事象、確認にかかった時間を別々に測ります。同じ事象が何度も通知される場合は、事象単位と通知単位の両方で数えます。

既知の故障が少ない場合、見逃しの少なさを十分に証明できないことがあります。評価できた条件と不足している条件を明示し、観察期間を延ばす判断も残します。実績のない故障を必ず予知できるとは説明しません。

候補画面には、該当時刻、対象項目、前後のログ、運転条件を示します。担当者が原記録へ戻り、確認済み・保留・点検依頼を記録できるところまでを成果物に含めると、運用の負担を評価しやすくなります。

見積りは、ログの取り出し、時刻と単位の整理、評価用事象の確認、候補の計算、表示画面、通知や記録の連携に分けます。新しいセンサーの設置や設備への接続工事が必要なら、ソフトウェアの検証と別に範囲を確認します。

AiPHAのPoC開発・検証は20万円からで、対象業務と開発範囲に応じた見積りです。AIサービス利用料などの別途費用は事前に案内します。LPの「10日で納品」という表記についても、ログの準備と評価期間を含む進め方は相談時に確認します。継続保守や追加開発は別途相談です。

運用費には処理・保存費のほか、候補の確認、センサー変更への対応、運転条件が変わった後の再評価を含めます。誤報が増えたときに誰が基準を見直すかを決め、現場の確認結果を集める担当者も置きます。

ログの意味が分からない、時刻がそろわない、候補を確認できる人がいない場合は、検知モデルより先にデータと体制を整理します。安全上重要な設備をこのPoCだけで無人管理する要件には適しません。

相談時は、設備の種類、記録している項目、困っている確認作業、過去の事象が残る期間を整理してください。実データを送る前に、共有範囲と取り扱い方法を確認できます。