予知保全にAIを使うときは、最初に「何を検知し、誰がどの保全行動を取るのか」を決めましょう。本記事では、設備データの準備、将来の運転を想定した評価、通知後の保全判断を一組で検証する進め方を提案します。
対象は、設備のセンサーデータを使った試行を検討する保全責任者とAI導入担当者です。以下では技術資料で確認できる事実と、現場で検証条件を決めるための提案を分けて説明します。
予知保全AIで何を予測するかを先に決める
MathWorksは、予知保全の方法として、正常な挙動からの逸脱を捉える「異常検知」、損傷などによる挙動を捉える「故障検知」、劣化の推移から寿命を推定する「残存寿命（RUL）推定」を区別しています。出典：MathWorksの予知保全の解説
試行の目的も、この違いに合わせて絞ることを勧めます。
| 試行の目的 | 確かめたい出力 | 出力後に検討する行動の例 |
|---|---|---|
| 普段と違う状態を見つける | 異常度と発生時刻 | 設備担当者が運転状態を確認する |
| 対象とする故障兆候を捉える | 対象故障に対応する通知 | 点検対象と点検時期を決める |
| 交換までの余裕を推定する | 残存寿命の推定値 | 部品調達や交換計画と照合する |
この表は導入目的を整理する提案です。異常の通知だけで故障原因や交換日まで判断できると扱わず、検証する出力を明記します。
RUL推定についてMathWorksは、類似設備の故障までの履歴、故障を示す指標の閾値、故障までの時間や使用量などを挙げ、手持ちのデータと設備の知識に応じたモデル選定を説明しています。これらをすべて揃えるという意味ではありません。出典：RUL推定モデルの選び方
故障履歴が乏しい設備では、まず正常状態からの逸脱を点検候補として提示する試行に範囲を絞る案があります。その段階の結果だけで「故障を何日前に予測できる」と評価しないようにします。
設備データは保全記録と結び付けて棚卸しする
導入担当者と保全担当者で、次の表を埋めることを提案します。センサー値が存在するかに加え、「どの設備の、どの運転条件のデータか」「何を正解として照合するか」を確認するための表です。
| 確認するデータ | 最初に確かめる内容 | 不足している場合の検証範囲 |
|---|---|---|
| 設備・部品の識別情報 | 設備ID、部品交換日、センサーの取付位置 | 履歴を追跡できる設備に限定する |
| センサーの時系列 | 時刻、単位、取得間隔、欠損、校正・交換履歴 | データの取得品質を確認する段階に留める |
| 運転条件 | 回転数、負荷、製品切替、起動・停止など | 条件を揃えられる運転区間で比較する |
| 点検・故障・修理の記録 | 発見時刻、症状、確認した原因、処置内容 | 原因が不明なものを特定故障の正解にしない |
| 通知後の対応記録 | 確認者、点検結果、作業時間、実施した処置 | 精度の検証と並行して記録様式を整える |
たとえば、部品を交換した日しか残っていない場合、その日をそのまま故障発生日とみなさず、定期交換か不具合への対応かを確認します。区別できない記録は「原因不明」として残し、評価対象に含めるかを事前に決めてください。
運転条件についても、起動直後と定常運転を同じ扱いにするかを保全担当者と確認します。判別できない区間を無理に正常・異常へ振り分けず、試行の対象外として記録する方法があります。
評価は時系列と設備を意識して分ける
scikit-learnの公式文書は、時系列データで未来のデータを学習に使い、過去のデータで評価する分割の問題を説明しています。また、予測時点で利用できない情報が混ざる「データ漏洩」は、性能を過大に見積もる原因になります。出典：時系列の分割、出典：データ漏洩の注意点
本記事では、次の評価設計を勧めます。
- 過去の期間を学習用、その後の期間を評価用として確保する。
- 正規化などの前処理で求める平均値等も、学習用データだけで決める。
- 点検後に確定した原因や修理結果を、通知時点の入力に混ぜない。
- 別設備へ展開したい場合は、学習に使っていない設備でも評価する。
同じ設備の将来を評価する試行と、別設備への展開を評価する試行は分けて記録します。また、しきい値を調整した期間とは別に、最終確認用の期間を残す設計にします。
正解率に加えて、保全に間に合ったかを数える
ここからは評価項目の提案です。センサーの各時点が正しかったかだけでなく、故障や点検のまとまりを単位にして結果を確認します。同じ不具合に対する連続通知を何件と数えるかも、集計前に決めておきましょう。
| 評価項目 | 記録する内容 | 判断すること |
|---|---|---|
| 見逃し | 対象の故障・異常のうち通知できなかった事象 | 対象とした故障を捉えられるか |
| 誤報・未確定通知 | 点検で異常を確認しなかった通知と、未点検の通知を別々に記録 | 追加確認の負担を受け入れられるか |
| 予告時間 | 最初の有効な通知から、事前に定義した故障・処置時点までの時間 | 点検や部品手配に間に合うか |
| 対応負荷 | 通知の確認・追加点検に使った時間 | 現場で継続できるか |
故障事象がない評価期間では、誤報や対応負荷を確認できても、故障の見逃しを実測で評価できません。「故障が起きなかったから予測できた」とは結論づけず、確認できた範囲を報告します。
比較対象には、現在のしきい値監視や既存の点検方法を置く案があります。同じ設備・期間で、追加の検知と追加作業の両方を比較してください。合格値は一律に置かず、必要な準備時間と現場の対応可能量から、評価前に決めます。
AIの通知を保全判断につなげる条件
試行では、まず通知と点検結果の照合から始めることを提案します。通知を受ける人、確認期限、停止・継続運転を判断する責任者を決め、既存の設備管理手順と接続します。
| 検証結果・状態 | 次の対応案 |
|---|---|
| 対象故障を必要な余裕時間で捉え、確認負荷も許容範囲に収まる | 対象設備を限定して運用へ進める |
| 通知は出るが、点検準備に間に合わない | 予測対象・入力・通知条件を見直す |
| 通知後の点検結果が記録されていない | 評価を保留し、結果の記録を優先する |
| 運転条件やセンサー構成が変わった | 適用範囲を再確認し、再評価する |
| データ欠損やシステム停止で判定できない | 「正常」とせず判定不能を表示し、既存手順に沿って確認する |
本番移行の判断材料には、モデルの評価表に加え、通知への対応時間、データ取得・保存・運用の費用も含めることを勧めます。費用対効果を計算する場合は、確認済みの実績と、停止を回避できたと仮定した試算を分けて提示します。
試行を始める前に残す一枚
着手前には、対象設備・対象故障、使うデータ、評価期間、比較対象、必要な予告時間、許容する通知負荷、対応責任者を一枚にまとめてください。埋められない項目があれば、まずデータ取得や点検記録の整備を試行の目的にします。
「通知できるか」と「通知を受けて保全できるか」を同じ試行で確かめることが、本記事の提案です。自社のAI活用を検討する際の事業情報は、テクノヴァースのAI活用に関する案内をご覧ください。