「壊れる前に分かれば、保全を最適化できる」。予知保全の価値は明快ですが、実際のプロジェクトでは故障予測モデルより前に止まります。故障履歴が設備IDと結びつかない、センサーの時刻がずれる、アラート後に交換部品を手配できない、といった問題です。
予知保全は、計測から保全判断までをつなぐシステムです。この記事では、状態監視・異常検知・故障診断・残存寿命予測を分け、データ設計、評価、しきい値、現場運用の順に組み立てます。工場全体のシステム地図はエンジニアのための製造業入門もあわせてどうぞ。
保全方式を4段階で見る
設備保全は、実施のきっかけで整理できます。
| 方式 | きっかけ | 長所 | 弱点 |
|---|---|---|---|
| 事後保全 | 故障した | 部品寿命を使い切れる | 突発停止の影響が大きい |
| 時間基準保全 | 日数・稼働時間 | 計画しやすい | まだ使える部品も交換する |
| 状態基準保全 | 振動・温度・摩耗が基準超過 | 実状態に合わせられる | 基準と計測品質が必要 |
| 予知保全 | 劣化傾向から将来を予測 | 作業・部品・停止を前倒し計画 | 学習・評価・運用が複雑 |
予知保全を始める前に、単純なしきい値による状態基準保全で十分ではないかを確認します。振動が一定値を超えたら点検するルールが安定して効くなら、RULモデルを作る必要はありません。
4つの出力を混同しない
「予知保全AI」と呼ばれるモデルの出力は、少なくとも4種類あります。
- 状態監視: 現在値と傾向を見える化する
- 異常検知: 通常運転から外れたことを知らせる
- 故障診断: 軸受、潤滑、アンバランスなど原因候補を示す
- 予後推定: 故障までの残存寿命(RUL)や一定期間内の故障確率を出す
異常検知だけでは原因も交換日も決まりません。逆にRULを出すには、劣化開始から終端までの履歴と、どこを故障と定義するかが必要です。
ISO 13374-1は、機械状態監視・診断情報の処理、通信、提示に関するソフトウェア仕様の一般指針を定めています[1]。実装では「データ取得 → 状態検出 → 健全性評価 → 予後推定 → 意思決定支援」の責任を分けると、モデル変更と現場運用を切り離しやすくなります。
センサーより先に故障モードを決める
「とりあえず振動を取る」では、必要なデータになりません。対象設備について、何が壊れ、その前に何が変わり、どのくらい前に知れば行動できるかを決めます。
| 故障モード | 兆候の候補 | 必要な猶予 |
|---|---|---|
| 軸受劣化 | 振動周波数成分、温度 | 交換部品と停止枠の確保 |
| 工具摩耗 | 主軸負荷、音、加工面品質 | 不良が出る前の工具交換 |
| 潤滑不足 | 摩擦、温度、振動 | 焼き付き前の点検・給脂 |
| フィルター詰まり | 差圧、流量、電力 | 能力低下前の交換 |
振動監視では、測定方法だけでなくセンサー選定、設置位置、固定方法、データ取得時の機械運転条件が結果を左右します。ISO 13373-1も、これらを一般手順の範囲に含めています[2]。
同じ振動値でも、回転数や負荷が違えば意味が変わります。設備状態だけでなく、運転モード、品種、速度、負荷を同時に記録し、比較できる条件へそろえます。
必要なのは保全履歴との結合
予知保全データは、センサー時系列だけでは完成しません。最低限、次を設備IDと時刻で結びます。
- 設備・部品マスタ、型式、設置日
- センサー値とサンプリング条件
- 運転モード、負荷、品種、環境条件
- アラーム、停止、再起動、段取り替え
- 点検、給脂、調整、部品交換の作業履歴
- 故障箇所、原因、交換部品、停止時間
「交換したら振動が下がった」のか、「生産品種が変わったから下がった」のかを区別するにはイベント履歴が必要です。保全記録が自由記述だけなら、作業種別、対象部品、症状、原因を構造化するところから始めます。
故障しなかった設備の履歴も重要です。評価期間を無故障で終えた設備は、故障日が不明なのではなく、その時点までは稼働したという情報を持ちます。これを単純に削除すると、故障例だけに偏ったデータになります。
NASAは、実飛行条件と運転履歴を模したエンジンのrun-to-failureデータを公開し、劣化と運用履歴を結びつける予後推定研究に使える形を示しています[3]。C-MAPSSの説明でも、飛行条件、健全性指標、温度・圧力など複数パラメータを時系列で扱います[4]。ただし模擬データで動くことと、自社設備で保全判断に使えることは別です。
リークしない評価を作る
時系列を行単位でランダム分割すると、同じ設備の故障直前データが学習とテストへ混ざります。モデルは設備固有の特徴や未来の劣化を見てしまい、本番より高く評価されます。
評価は、用途に合わせて次のどちらかにします。
- 新しい設備への一般化: 設備ID単位で学習・テストを分ける
- 同じ設備の未来予測: 過去期間で学習し、それより後の期間で評価する
保全後にリセットされた状態をどう扱うか、部品交換を設備全体の新しい寿命開始とみなすかも決めます。特徴量の移動平均や正規化は、各評価時点より未来の値を使わないように計算します。
詳しい分割としきい値の原則はモデル評価設計入門で扱っています。
精度より「間に合ったか」を測る
予知保全では、故障を当てても1分前では部品を手配できません。逆に3か月前の曖昧なアラートは、忘れられるか、点検を増やしすぎます。
モデル指標に加え、次を評価します。
- 故障の何日前・何サイクル前に最初の有効アラートが出たか
- 目標予告期間内の故障を何件拾えたか
- 設備・月あたりの誤報件数
- 同じ故障に何回重複アラートを出したか
- 点検・交換へ進んだ割合と、結果として見つかった不具合
- 回避できた突発停止時間と、増えた点検・部品費用
RULのMAEが小さくても、交換判断の境界付近で誤ると業務影響は大きくなります。保全担当者が必要とする予告期間を先に決め、「30日以内に故障するか」の分類として評価する方が直接的な場合もあります。
しきい値とアラートを運用へ落とす
異常スコアをそのまま通知すると、ノイズでアラートが増えます。運用では段階を作ります。
- 一時的な逸脱は、連続回数や時間窓で平滑化する
- 注意、要点検、停止検討の複数段階にする
- 同じ設備・故障候補のアラートをまとめる
- 根拠となる波形、基準値、運転条件を添える
- 担当者、期限、確認結果を記録する
しきい値はモデル精度だけでなく、保全チームが週に何件を確認できるかで決まります。アラートが正しくても、部品在庫や停止枠がなければ価値につながりません。異常検知入門で扱った、見逃しと誤報のトレードオフを保全能力へ接続します。
小さく始める順序
予知保全は、重要設備すべてへ一斉展開せず、故障モードを一つ選びます。
- 停止影響が大きく、兆候が観測できる設備を選ぶ
- 現行の点検基準と故障モードを文書化する
- センサーと保全履歴を設備ID・時刻で結ぶ
- まず可視化とルールベースでベースラインを作る
- ルールで拾えない正常変動が多い場合に異常検知を加える
- 予告期間の教師データが蓄積してから予後推定を検討する
この順序なら、モデルが完成しなくてもデータ品質と点検基準が改善します。予知保全のPoCを、精度比較だけで終わらせないための設計です。
まとめ
- 予知保全は、計測・状態検出・診断・予後推定・保全判断をつなぐシステム
- 単純なしきい値で十分なら、無理にRULモデルを作らない
- センサー選定は故障モード、兆候、必要な予告期間から逆算する
- 時系列に設備・運転条件・保全作業・故障結果を結合する
- 設備IDと時間を守って分割し、未来情報のリークを防ぐ
- 成功はMAEやAUROCではなく、間に合う検知と処理可能な誤報数で測る
- アラート後の担当者、部品、停止枠、記録までが予知保全の実装
最初に作るべき成果物はモデルではなく、「対象故障モード・観測できる兆候・必要な予告期間・アラート後の行動」を1枚にした表です。
参考文献・一次情報
- [1]STANDARDISO 13374-1:2003 — Condition monitoring and diagnostics of machines
機械状態監視データの処理・通信・提示に関する一般指針。2025年確認済みの現行版
- [2]
- [3]REPORTAircraft Engine Run-To-Failure Data Set Under Real Flight Conditions
運転履歴と劣化を結びつけたrun-to-failure予知保全データセット
- [4]