「予知保全システム」と検索して製品を探し始めても、モーター専用のセンサー機器から、複数の時系列データを分析するAI、設備と保全情報を拠点横断で管理するクラウドサービスまで、対象範囲があまりに幅広く、製品名やAI機能の有無を見比べただけでは自社に合う候補を絞りきれない、と感じた方は少なくないはずです。
予知保全システムは、設備から収集した振動や温度、電流、音、圧力などのデータを分析し、故障や性能低下の兆候を捉える仕組みです。異常が起きてから修理するのではなく、兆候をもとに点検や部品交換の時期を判断し、計画外停止の回避につなげます。
ただし、その仕組みを実現する製品は、監視したい設備、必要なデータ、導入の規模がそれぞれ大きく異なります。
この記事では、対象設備と故障モード、取得できるデータ、分析方式、設置方式、PoCや運用支援の範囲という比較する際の観点を整理したうえで、候補となる10製品の特徴、設備・目的に応じた選び方、導入時に決めておきたい運用ルールをまとめました。
自社の設備とデータの状況に照らして読み進めれば、どの観点を優先し、どのタイプの製品を候補にすべきかが見えてくるはずです。ぜひ参考にしてください。

目次- 予知保全システムとは
- 設備データを収集・蓄積できる
- 状態を分析し、異常の兆候を通知する
- 予知保全システムを比較する4つの観点
- 対象設備と取得できるデータ
- 分析方式と必要な故障データ
- 設置方式と既存システムとの連携
- PoC・費用・導入後の支援
- 予知保全システムの検討候補を比較
- 設備・目的別に予知保全システムを選ぶ方法
- モーターや回転機の状態を常時監視したい場合
- プロセス産業の重設備を監視したい場合
- 多変量データから設備の異常兆候を捉えたい場合
- 複数設備・複数拠点を横断管理したい場合
- 専任担当者を置かずノーコードで始めたい場合
- 自社に合う予知保全システムの選び方
- 停止影響の大きい設備を優先する
- 検知したい故障モードと使えるデータを整理する
- 現場利用者を含むPoCで評価する
- 本番運用の責任者と支援範囲を決める
- 予知保全システム導入で失敗しないための注意点
- 誤検知を許容する基準としきい値調整の運用ルールを事前に決める
- 検知精度には限界がある
- センサー設置とデータ整備にも工数がかかる
- 通知後の対応を決めないと定着しない
- 予知保全システムは対象設備を絞って比較しよう
予知保全システムとは
予知保全システム(予兆保全システム)とは、日常点検のデータやIoTセンサー、AI(人工知能)などで設備の状態を継続的に把握し、通常とは異なる変化を検知して、未然に設備停止や異常発生を防ぐツール・システム、仕組みを指します。
点検日をあらかじめ決める予防保全とは異なり、実際の設備状態を保全時期の判断材料にする点が特徴です。
なお、予知保全、予防保全、事後保全の違いは、「予知保全(予兆保全)とは」の記事で詳しく解説しています。
システムの基本的な処理は、設備データの収集、蓄積、分析、通知の流れで捉えると理解しやすくなります。ただし、センサーから通知までを一つの製品で提供するものもあれば、既存センサーやPLC、データベースと分析ソフトウェアを組み合わせるものもあります。
設備データを収集・蓄積できる
予知保全システムを活用することで可能になるのは、設備の状態を表すデータの収集が自動化されることです。新たにセンサーを取り付ける方法のほか、既設のセンサー、PLC、DCS、SCADA、ヒストリアンなどに保存されているデータを利用する方法があります。
主に収集できるデータと、検知可能な異常の例は次のとおりです。
データ | 測定・分析するもの | 検知できる異常の例 | 主な注意点 |
|---|---|---|---|
振動 | 振幅、速度、加速度、周波数など | 回転体のアンバランス、ゆるみ、芯ずれ、軸受摩耗 | 設置位置や周囲の振動が結果に影響する |
温度 | 表面温度、周囲との温度差、温度変化 | 摩擦や潤滑状態、冷却不良などによる過熱 | 負荷や周囲温度を含めて傾向を見る |
電流・電力 | 電流値、電流波形、負荷変動など | モーターや負荷側の状態変化 | 対応するモーター形式やインバーター条件を確認する |
絶縁抵抗 | モーターの絶縁状態 | 絶縁劣化の兆候 | 測定方式と対応電圧を確認する |
音 | 回転音、振動音、漏れ音など | 正常時と異なる音、ガス漏れ音など | 周囲騒音やマイクの位置を含めて評価する |
プロセス値 | 圧力、流量、液位、回転数など | 閉塞、性能低下、運転状態の変化 | 複数項目の関係や運転モードを考慮する |
予知保全システムで記録・収集できるデータと検知できる異常の例
例えば、振動パターンの変化はアンバランス、ゆるみ、芯ずれ、軸受摩耗などを調べる手掛かりになります。温度上昇も軸受の摩耗や潤滑状態、芯ずれなどを疑う契機になりますが、どちらも単独の値だけで故障原因が確定するわけではありません。正常時の基準値、負荷、回転数、周囲環境と合わせて判断します。
集めたデータは、いったん現場側の機器(ゲートウェイやエッジコンピューターと呼ばれる中継用の装置)でまとめられたあと、自社で管理するサーバー、またはインターネット上のクラウドサービスへ送られます。
予知保全では一時点の値だけでなく、時間の経過でどう変化したかが重要になるため、「どの設備の(設備ID)」「いつ測定した(測定時刻)」「どんな運転状態での(運転モード)」「過去にどんな保全をした(保全履歴)」などのデータを紐づけて、蓄積できる状態にしておく必要があります。

状態を分析し、異常の兆候を通知する
蓄積したデータは、固定したしきい値との比較や、統計手法、機械学習などで分析します。温度が設定値を超えた場合に通知する単純なしきい値判定は、判断根拠を説明しやすい方法です。
一方、複数のデータの関係や通常時のパターンを学習する方法は、単独の数値では見つけにくい変化を捉える用途に使われます。
分析結果は、異常度のスコア、注意・警告の段階表示、メールや画面への通知などで示されます。通知は故障の確定診断ではなく、点検や確認を始めるための情報です。どの通知を誰が確認し、現場点検、停止判断、部品手配のどこまで進めるかを運用として定めて初めて、保全業務につながります。
予知保全システムを比較する4つの観点
製品を比べる前に、比較する観点を揃える必要があります。予知保全システムは対象範囲が広いため、機能数や知名度だけでは適切に比較できません。対象設備とデータ、分析方式、設置・連携、PoC(Proof of Concept:概念実証)・費用・支援の4つ観点で確認します。
対象設備と取得できるデータ
比較の1つ目の観点は、製品が自社の対象設備に対応しているかです。モーターの軸受異常を振動で監視したい場合と、化学プラントの圧力・温度・流量の関係から異常兆候を探したい場合では、必要なセンサーも分析方法も異なるため、対象外の設備向けに作られた製品を選んでも成果は出ません。
そこで、対象設備・検知したい故障モード・候補データの3つを一組にして整理すると、自社に必要な条件が具体的になります。例えば「ポンプの軸受摩耗を振動で捉える」「熱交換器の閉塞兆候を圧力・流量・温度から捉える」といった形です。
ただし、対象設備と故障モードが合っていても、「データを取得できる状態」でなければ、製品は機能しません。
既設センサーの有無、PLCなどからの出力方法、サンプリング周期、保存期間、データ形式、設備メーカーの制約、外部サービスへ送信できるかを確認します。
必要なデータが存在しない、粒度が足りない、設備IDと紐付かない場合は、分析ソフトウェアだけを導入しても運用できないため、対象設備への対応とデータが取得できるかは、必ず確認しましょう。

対象設備と取得できるデータの確認フロー
分析方式と必要な故障データ
観点の2つ目は、分析方式と自社の故障データの状況です。機械学習を使う製品を比較するときは、教師あり学習と、教師なし学習を含む異常検知に分けて考えると、自社にどのデータが必要かが見えやすくなります。両者の違いは、平たく言えば「故障データを前提とするか、正常データだけで始められるか」です。
教師あり学習は、入力データに正常、故障、故障原因などの正解ラベルを付けて学習します。過去に十分な故障事例があり、設備条件とラベルの対応が明確なら、特定の故障や原因を分類する設計が可能です。一方、故障がまれな設備では、同じ条件の故障データを必要量そろえにくいという制約があります。
これに対して教師なし学習は、正解ラベルのないデータから通常のまとまりやパターンを学び、そこから外れる変化を探します。故障データがそろっていない設備でも、正常運転データさえあれば始められる点が教師あり学習との大きな違いです。
ただし、出力された変化が実際に設備の異常を意味するかどうかは、人が検証する必要があります。
ここで重要なのは、教師ありと教師なしのどちらかが常に優れているわけではないという点です。自社に故障データがどれだけあるか、運転モードがいくつあるか、検知後にどこまで具体的な判断を求めるか、という状況に応じて選ぶことが比較の要点になります。
目安としては、故障がまれで履歴が少ない設備は教師なし学習(異常検知)を採用する製品が候補になり、同型設備が多く故障データが蓄積している設備は教師あり学習で原因まで分類できる製品も検討できます。どちらの方式を採用しているかは、次の比較表や製品紹介で確認できるポイントの1つです。
設置方式と既存システムとの連携
比較すべき観点の3つ目は、設置方式と既存システムとの連携です。分析処理を設備の近くで行うエッジ型と、データをクラウドへ集約するクラウド型では、得意な運用が異なるため、自社がどちらの用途を優先するかで選ぶ製品が変わります。
エッジ型は、低遅延の処理や、設備側での即時判断が必要な場合に向きます。製品と構成によっては、クラウドとの通信が不安定な間も現場側の処理を継続し、データを一時保存して再接続後に送信できます。ただし、すべてのエッジ製品が無条件でオフライン運転に対応するわけではないため、保存容量、再送、時刻同期、通知方法まで確認が必要です。単一設備・単一ラインでの即時停止判断を重視するなら、エッジ型が比較の起点になります。
一方でクラウド型は、複数の設備・拠点からデータを集め、同じ画面や指標で比較・管理する用途に向きます。工場から外部への通信、データの保管場所、アクセス権限、通信断時の動作などを情報システム・セキュリティ部門と確認する必要はありますが、多拠点を横断して保全状況をそろえたい場合は、クラウド型が候補になります。
この設置方式の違いは、既存システムとの連携方式にも影響します。エッジ型はPLCやDCSなど現場の制御系データと直結する構成が多く、クラウド型は保全履歴を持つCMMSやEAM、作業指示を管理するシステムとの連携を前提にした設計が多くなります。
標準コネクターやAPIがあっても、自社のデータ形式に合わせた変換やマスター整備が必要になる場合があるため、対象のPLC・DCS・SCADA・ヒストリアン・CMMS・EAMそれぞれとの接続方法を具体的に確認しましょう。
PoC・費用・導入後の支援
4つ目の観点は、PoCの進め方と費用、導入後の支援範囲です。ここでいうPoCとは、本番導入の前に、対象設備を絞って実際のデータで製品を試し、現場で運用できるかを確認する検証段階を指します。
予知保全システムの費用は、ソフトウェア利用料だけでは判断できません。センサーの設置からPoC、運用後の保守まで、次の7項目に費用が発生し得ることを前提に比較します。
費用項目 | 主な内容 | 見積もりを左右する条件 |
|---|---|---|
センサー・計測機器 | 振動、温度、電流、音などのセンサー | 台数、測定項目、防水・防爆などの設置環境 |
ゲートウェイ・エッジ機器 | データ収集、変換、一時保存、現場側の分析 | 接続台数、通信方式、必要な処理能力 |
設置・通信工事 | センサー取り付け、配線、ネットワーク整備 | 設備停止の要否、高所作業、既存ネットワーク |
ソフトウェア | ライセンス、クラウド利用、データ保存 | 設備数、ユーザー数、拠点数、保存期間 |
データ整備・連携 | 前処理、設備マスター整備、API・既存システム連携 | データ品質、形式、連携先の数 |
PoC・導入支援 | 対象選定、分析、モデル作成、効果検証 | 検証期間、対象設備、分析の難易度 |
運用・保守 | 問い合わせ、モデル更新、しきい値調整、機器保守 | 支援範囲、対応時間、現地対応の有無 |
予知保全システムで費用が発生する項目と見積もりに影響する条件
この表からも分かるとおり、費用は構成要素が多く、共通条件で比較できる一般的な価格帯を一次情報だけで示すことは難しいのが実情です。
センサーを後付けする構成と、既存データを分析するソフトウェアでは費用の範囲が異なるため、金額だけを横並びにせず、対象設備数、含まれる機器と作業、PoC後の本番費用、保守範囲をそろえて見積もりを取ることをおすすめします。
見積もりと並行して、表の「PoC・導入支援」にあたる部分は、実際にPoCを進めながら評価します。検知できたかだけでなく、データ欠損、誤検知、通知から現場確認までの時間、担当者が判断できる表示かを確認します。
あわせて、表の「運用・保守」に関わる部分として、ベンダーがデータ取得、前処理、モデル調整、運用設計のどこまで支援するかも確認しておくと、本番移行後の追加工数を見積もりやすくなります。
予知保全システムの検討候補を比較
ここまでの4つの観点を踏まえ、予知保全システムの検討候補を、対象設備とデータ、分析・提供形態、導入前の確認事項で整理しました。
掲載順は推奨順位ではなく、対象設備が明確な専用機器(K6CM、MELFA Smart Plus)から、複数設備・複数データを扱う汎用の分析ソフトウェア(HiPAMPS〜Impulse)、資産管理やクラウド統合まで含む製品(Senseye〜OpreX)、ノーコードの予測ツール(Prediction One)、プロセス産業特化の製品(Aspen Mtell)へと並べています。各製品の仕様、提供範囲、価格は変更される可能性があるため、検討時には公式情報と個別見積もりを確認してください。
製品・サービス | 主な対象とデータ | 分析・提供形態 | 導入前の確認事項 |
|---|---|---|---|
K6CM/オムロン | 三相インダクションモーター。型式により電流、振動・温度、絶縁抵抗 | 設備へ取り付ける状態監視機器。しきい値で異常を通知 | 対応モーター、必要な型式、センサー取り付け位置、上位システムとの接続 |
MELFAロボットの減速機、エンコーダー、バッテリーなど | ロボットの駆動系部品の異常兆候を検知 | 対応機種・軸・部品、必要なオプションや保守契約 | |
HiPAMPS/日立パワーソリューションズ | 機械・設備の各種センサーデータ | 複数の診断エンジンを選択。正常状態データを使うモデルレス方式にも対応 | 正常データの期間、運転状態の変動、保守履歴の整備、導入支援 |
設備異常予兆監視支援サービス/NEC | プラントなどの複数の時系列データ | データ間の関係から通常状態のモデルを作り、関係の崩れを検知 | 対象データの種類と品質、データ収集基盤、分析・運用支援の範囲 |
Impulse/ブレインズテクノロジー | センサー、PLC、検査機器の数値、音声、画像 | AIによる異常検知。オンプレミスとクラウドの構成を相談可能 | データ取得方法、前処理、PoCの評価条件、運用時のモデル調整 |
Senseye Cloud Application/Siemens | 既存センサー、ヒストリアン、IoT基盤などから取得する設備データ | 既存の設備データを活用し、メーカーを問わず複数の機械を監視できるクラウド型ソフトウェア | 既存のデータ取得元との接続、対象設備数・拠点数、提供地域、支援範囲 |
生産ライン、設備、車両などの資産データと保全情報 | EAM・APMを含む統合スイート。遠隔監視や予知保全にも対応 | 既存EAM・CMMSとの役割分担、導入範囲、データ移行、運用体制 | |
センサー、PLC、DCS、SCADA、ヒストリアンなど、複数拠点・設備に分散した運転データ | クラウドにデータを集約し、AI・機械学習で異常検知やアラート通知を行う | 対象拠点、接続機器、既存センサーの利用可否、セキュリティ、支援範囲 | |
Prediction One/ソニーネットワークコミュニケーションズ | CSVなどの表形式データ。故障分類や部品寿命予測など | ノーコードで分類・回帰モデルを作成。デスクトップ版とクラウド版 | 設備データの収集と前処理は別途必要。予測する項目と学習用データの設計、常時監視への組み込み |
Aspen Mtell/AspenTech | プロセス産業を含む設備の運転・状態データ | AIで故障パターンを早期検知し、推奨対応を示す。EAMとの連携にも対応 | データ基盤、対象資産、故障モード、既存EAMとの連携、展開規模 |
予知保全システム一覧
表には、専用機器、汎用分析ツール、資産管理スイートなど異なる種類の製品・サービスが含まれます。K6CMやMELFAのように対象設備が明確な製品は適合条件を確認しやすい一方、対象外の設備には使えません。
HiPAMPSやNEC、Impulseのように複数のデータを分析する製品では、利用できるデータの種類・品質と、PoCでの評価方法を先に確認します。SenseyeやMaximo、OpreXのように資産管理や既存システムとの連携まで含む製品では、連携先、導入範囲、運用体制を先に整理しておく必要があります。
設備・目的別に予知保全システムを選ぶ方法
製品を一覧で見ても、自社にどれが合うかをすぐに判断するのは難しいものです。対象設備と導入目的から絞り込むと、自社に近い製品群が見えてきます。ここでは代表的な5つの場合に分け、それぞれどの条件がそろえば候補になるかを整理します。
モーターや回転機の状態を常時監視したい場合
まず、モーター、ポンプ、ファン、コンプレッサーといった回転機を常時監視したい場合です。これらは振動、温度、電流、絶縁抵抗などを継続的に測れる製品が候補になります。
たとえばK6CMのようなモーター向けの状態監視機器なら、対象が三相インダクションモーターか、監視したい故障モード(軸受摩耗やアンバランスなど)に対応する型式かを確認します。
一方、同じ回転機でも産業用ロボットは、汎用の回転機監視だけでなく、メーカー純正の機種専用機能が候補に入ります。MELFA Smart Plusの予知保全機能は対応ロボットの駆動系部品を対象にするため、既設ロボットの機種・軸・部品と、必要なオプションや保守契約まで照合します。
候補を絞る分かれ目は、モーターやポンプなら「監視したい故障モードに型式が対応しているか」、産業用ロボットなら「機種と部品が対応し、契約条件を満たすか」です。専用機器は、適合条件さえ合えば導入を判断しやすい反面、対象外の設備には使えません。まず自社設備がその製品の想定範囲に入るかを、最初に確かめます。
プロセス産業の重設備を監視したい場合
化学、石油・ガス、電力などのプロセス産業では、ポンプやコンプレッサー単体の振動だけでなく、圧力、温度、流量、運転モードなどの関係を扱う場面があります。
設備や計装データがDCSやヒストリアンに蓄積されている場合は、それらを取り込める分析製品や資産性能管理製品が候補です。
そこで、Aspen MtellやOpreX Asset Health Insightsのような分析製品・資産性能管理製品を比較するときは、対象資産に合った故障モードやテンプレートがあるか、既存のEAM・DCS・ヒストリアンとどう連携するか、複数部門で通知と作業指示をどう扱うかを見ます。
防爆、ネットワーク分離、データ保管場所など、工場固有の要件も初期段階で整理しておきます。 これらを踏まえると、既存の計装データをそのまま活用でき、工場のセキュリティ要件と既存システム連携を満たせる製品が、現実的な候補として残ります。
多変量データから設備の異常兆候を捉えたい場合
一つのセンサー値では判断しにくい異常を、複数のデータを組み合わせて捉えたい場合です。時系列データ同士の関係や通常時のパターンを分析する製品が向き、HiPAMPS、NECのインバリアント分析を用いたサービス、Impulseなどが候補になります。
比較時には、正常データだけで開始できるか、過去の故障データが必要か、運転モードの変化をどう扱うかを確認します。また、異常度だけを表示するのか、関係したセンサーや過去の類似事例まで確認できるのかによって、通知後の調査工数が変わります。
複数設備・複数拠点を横断管理したい場合
設備や拠点を横断して状態を確認したい場合は、クラウド型やEAM・APMを含む製品が候補です。Senseye Cloud Application、Maximo Application Suite、OpreX Asset Health Insightsなどは、複数資産の管理を前提に検討できます。
ただし、横断管理は画面を一つにまとめれば済む話ではありません。設備名称、重要度、故障分類、アラートレベルといったマスターを拠点間でそろえないと、各拠点のデータを同じ基準で比較できないためです。
一方で、設備条件の違いを無視して同じ基準値を当てると判断を誤るため、共通で管理する項目と、設備ごとに設定する基準は分けて設計します。
専任担当者を置かずノーコードで始めたい場合
機械学習のコードを書ける担当者を置かず、手元の表形式データで予測モデルを試したい場合は、Prediction Oneのようなノーコード型の予測分析ツールが候補です。CSVを取り込んで分類や回帰モデルを作成でき、故障予測や部品寿命予測の用途例も示されています。
ただし、ノーコードであることと、設備データの収集や運用設計が不要であることは別です。センサー、データ収集、欠損処理、正解ラベル、予測結果の通知や作業指示への連携は、自社で準備するか別の仕組みと組み合わせる必要があります。
そのため、設備専用の常時監視システムと同列に置かず、すでに使える表形式データがあり、限定したテーマで分析を試したい場合に検討します。
自社に合う予知保全システムの選び方
候補の種類を絞ったら、次は具体的な選定です。対象設備の優先順位づけ、故障モードとデータの棚卸し、PoC、本番運用の順に進めると抜けなく判断できます。
停止影響の大きい設備を優先する
初めから全設備を対象にすると、センサー設置、データ整備、PoCの範囲が広がり、効果を検証しにくくなります。まずは、停止時の生産損失、安全・品質への影響、代替設備の有無、修理時間、部品の納期を基準に重要な設備を絞ります。
故障頻度が高い設備だけが優先対象とは限りません。故障頻度が低くても、停止すると工程全体が止まり、復旧部品の調達に長期間かかる設備は優先度が上がります。一方、予備機へすぐ切り替えられ、交換費用も小さい設備は、予知保全への投資効果が出にくい場合があります。
検知したい故障モードと使えるデータを整理する
対象設備を決めたら、過去の故障記録、点検記録、保全担当者の知見から、検知したい故障モードを具体化します。「ポンプの異常」のような広い表現ではなく、軸受摩耗、芯ずれ、キャビテーション、閉塞などに分けます。
次に、各故障モードの兆候を捉えられるデータがあるかを確認します。既設データを使う場合は、正常時と異常時の期間、欠損、測定間隔、設備IDとの紐付けを点検します。新たにセンサーを設置する場合は、取り付け位置、電源、通信、防水・防塵・防爆、校正、設備停止の要否も検討します。
故障モードとデータの対応が曖昧なまま製品を選ぶと、導入後に「測っているデータでは目的の異常を捉えられない」と判明しかねません。そこで製品選定の前に、検知対象と必要なデータ条件を、設備メーカー・センサーメーカー・保全担当者・分析ベンダーの間で合意しておきます。ここまで整理できて初めて、次のPoCで何を確かめるかが決まります。
現場利用者を含むPoCで評価する
PoCの対象は、代表的な一設備または一系統に絞ります。評価期間には、通常運転だけでなく、負荷や品種の切替え、計画停止など想定される運転状態をできるだけ含めます。
そのうえで評価するのは、異常を検知できたかだけではありません。誤検知の件数、見逃し、通知までの時間、データ欠損、原因調査に必要な情報、現場確認の工数まで記録します。故障が起きない期間は、過去データでの再現検証や、保全担当者が既知の状態変化を検出できるかで評価する方法もあります。
また、PoCの画面は、実際に通知を受ける保全担当者や現場責任者にも使ってもらいます。分析担当者には読めても、現場が次の行動を判断できない表示では、運用に定着しないからです。
PoCでは、評価軸を先にそろえておくと、複数の製品を同じ条件で比較できます。検知精度だけでなく、現場での使いやすさ、導入にかかる工数、既存システムとの連携、費用・支援まで、下の表の観点で確認します。
評価軸 | 確認すること | 合格条件の例 |
|---|---|---|
対象適合 | 対象設備・故障モード・運転条件に対応するか | 優先設備と検知対象を事前に明記 |
検知 | 検知の早さ、誤検知、見逃し、根拠の分かりやすさ | 実データで評価し、期間・件数を記録 |
現場運用 | 担当者が通知を理解し、点検・停止判断へ進めるか | 実際の利用者が評価 |
導入負担 | センサー設置、通信、データ整備、教育の工数 | 本番展開時の工数を見積もれる |
連携・安全 | PLC、IoT、保全管理、権限、閉域・クラウド条件 | 情報システム・OT担当も確認 |
費用・支援 | 初期・運用総額、PoC後の支援、モデル・しきい値更新 | 責任分担と追加費用を明文化 |
PoC(Proof of Concept、概念実証)段階での評価軸の例と確認すること、合格条件例
この表の各項目を事前に「合格条件」として決め、検知できることに加えて、現場が通知を判断に使えることまで確認できた製品を本番導入の候補にします。
本番運用の責任者と支援範囲を決める
本番移行前に、データ、分析、設備、保全作業の責任分担を決めます。具体的には、センサーの保守、通信障害の確認、データ欠損への対応、モデルやしきい値の見直し、通知の一次確認、現場点検、停止判断の担当です。
また、ベンダーの支援範囲も書面で確認します。PoCまでは分析担当者が伴走しても、本番後のモデル更新やデータ追加は別契約になることがあるためです。問い合わせ方法、対応時間、現地支援の有無、障害時の切り分け、教育、定例レビューの範囲まで、見積もり条件に含めます。
予知保全システム導入で失敗しないための注意点
製品を選定したあとも、導入しただけで故障を防げるわけではありません。誤検知、データ品質、現場対応をどう運用するかを、事前に決めておく必要があります。ここでは特に見落としやすい4点を挙げます。
誤検知を許容する基準としきい値調整の運用ルールを事前に決める
異常判定のしきい値を厳しくすると、軽微な変化も拾える一方で、正常な状態を異常と判定する誤検知が増えます。反対に緩めると通知は減りますが、見逃しが増えます。機械学習の分類でも、しきい値の変更は偽陽性と偽陰性のバランスに影響します。
そこで、許容基準は故障の重大度と、通知後の確認にかかる負担に応じて決めます。安全や品質に直結する設備では見逃しを抑えることを優先し、確認が容易な設備では一定の誤検知を許容するという判断です。少人数で多数の設備を監視する場合は、誤検知が多いと通知への反応が鈍り、重要な警告が埋もれる点にも注意します。
そのうえで本番前に、注意と警告の区分、許容する誤検知と見逃し、確認期限、しきい値を変更できる担当者、変更記録、見直しの時期まで決めておきます。しきい値は「一度決めて終わり」にせず、重大度に応じた許容基準を先に定め、設備の修理・センサー交換・運転条件の変更に合わせて更新していくものと考えてください。
検知精度には限界がある
予知保全システムが検知できるのは、取得したデータに兆候が表れ、分析方法がその変化を捉えられる故障です。突発的な破損、測定していない部位の異常、学習データにない運転状態などは、検知できない場合があります。
さらに、PoCで良い結果が出ても、季節、負荷、原料、品種、設備の経年変化によってデータ分布は変わります。検知精度を固定値として捉えず、誤検知と見逃し、現場点検の結果を継続的に記録し、モデルやしきい値を見直します。
そのため、通知を故障の確定診断として扱わず、現場点検や追加測定と組み合わせることが大切です。従来の巡回点検や法定点検を一律に廃止するのではなく、システムで代替できる範囲と、人が確認すべき範囲を分けます。
センサー設置とデータ整備にも工数がかかる
分析ソフトウェアの導入前に、対象設備から必要なデータを取得できるかを確認します。既設センサーがあっても、データを外部へ出力できない、測定間隔が粗い、時刻がずれている、設備IDと紐付いていないといった問題が起こり得ます。
また、新しいセンサーを取り付ける場合は、設置工事だけでなく、計測位置の選定、電源、通信、保護等級、校正、交換周期、設備停止の調整が必要です。クラウドへデータを送る場合は、ネットワーク分離やデータ持ち出しの社内ルールも確認します。
そこで、PoCに入る前にデータ棚卸しを行い、データ名、取得元、単位、測定間隔、欠損率、保存期間、利用権限を一覧にします。追加工事と前処理にかかる工数まで見積もったうえでPoCの対象設備と製品を決めると、あとから費用が膨らむのを防げます。
通知後の対応を決めないと定着しない
異常通知を受けても、確認方法と判断権限が決まっていなければ対応は進みません。「誰かが見る」状態ではなく、通知レベルごとに担当者と行動を決めます。
例えば、注意レベルでは次回巡回時に振動・温度を再測定し、警告レベルでは保全責任者が過去データと現場状態を確認する、といった手順です。停止が必要な場合の承認者、交換部品の手配、作業記録の残し方までつなげます。
このように、通知、現場確認、原因、実施した保全、結果を記録していくと、その記録が誤検知の評価やモデルの見直しにも使えます。予知保全システムの運用を分析担当者だけに閉じず、保全計画と作業指示の流れに組み込むことが定着につながります。
予知保全システムは対象設備を絞って比較しよう
予知保全システムには、モーター向けの状態監視機器、複数データを分析するAI、複数拠点の資産と保全情報を管理するクラウドサービスなど、対象範囲の異なる製品があります。だからこそ、製品名や機能数で比べるのではなく、対象設備・故障モード・取得できるデータ・分析方式・設置と連携・PoCと支援範囲の順にそろえて比較することが、遠回りに見えて確実です。
費用はソフトウェア料金だけでなく、センサー、ゲートウェイ、設置、データ整備、連携、PoC、運用保守を含めて確認します。まずは停止影響の大きい設備を一つ選び、現場担当者を含むPoCで、誤検知・見逃し・現場確認にかかる時間まで確かめてみてください。そこで得た手応えが、本番導入をどこまで広げるかの判断材料になります。






















