予知保全システムの選び方｜対象設備と故障モードから整理する7軸の選定フレームワーク

予知保全システムの選び方で多くの保全部門が手を止めるのは、製品名やセンサーの種類は調べがついても「どの軸で評価すれば自社設備に合うか」というフレームワークがないためです。検索すると「予知保全とは」「予防保全との違い」を説明する解説記事は多い一方で、対象設備や故障モードから逆算して選定軸を整理した記事は手薄なまま残されています。その結果、デモで見た高度なAI機能に惹かれて契約したものの、現場のセンサー配線や既存PLCとの接続でつまずき、PoCのまま塩漬けになるケースが後を絶ちません。

この記事は予知保全システムを選ぶうえで外せない選定軸を順に整理し、対象設備と故障モードの切り分け、データ取得方式、AI・分析手法、既存設備・PLC・SCADA連携、スモールスタートの進め方、現場運用体制、コスト・ROIまで踏み込みます。個別製品のスペック比較表は別記事「予知保全システム比較」で扱うため、本記事は選定フレームワークに特化します。予知保全そのものの定義や予防保全・事後保全との違いを先に押さえたい場合は「予知保全とは」を参照してください。

結論：まず押さえる選定基準は、対象設備の故障モードと、その兆候を捉えるセンサー・データ取得方式の二つです。回転機の軸受劣化を狙うのか、加工機の精度劣化を狙うのか、生産ライン全体の異常を広く見たいのかで、必要なシステムの系統がほぼ決まります。そのうえでAIの分析手法（異常検知か余寿命予測か）、既存PLC・SCADAとの連携方式、スモールスタートの可否、現場の保全体制、3年TCOとROIを順に確認すれば、候補は2〜3製品に絞れます。高度なAIから入るのではなく、止めたくない設備と捉えたい故障から入るのが、手戻りを最小化する選び方です。

編集部はこの「対象設備・故障モード／データ取得方式／AI・分析手法／既存設備・PLC・SCADA連携／スモールスタート・PoC／現場運用と保全体制／コスト・ROI」という7軸の観点で整理しました。以下、各軸を上流から順に解説します。

予知保全システムの選定は、上流の軸ほど後戻りのコストが大きい順に並べると漏れと手戻りが減ります。対象設備・故障モードの特定→データ取得方式→AI・分析手法→既存設備連携→スモールスタート→現場運用→コスト・ROIの順で各軸を確認し、候補製品を2〜3に絞り込んでから比較記事に進む流れです。最初に「どの設備のどの故障を、何ヶ月先まで読みたいか」を言語化できていないと、どんなに高機能な製品を入れても評価軸がぶれて定着しません。

編集部コメント：7軸は独立ではなく連動しています。とくに「対象設備・故障モード」と「データ取得方式」を曖昧にしたままAIの賢さや価格だけで選ぶと、後からセンサー構成ごと組み直す事態になりやすい点に注意してください。上の2軸が決まれば、残りの軸は要件の確認作業に近づきます。

選定の出発点は、守るべき設備と狙う故障モードの特定です。すべての設備を等しく監視するのは現実的でなく、止まると生産・安全・コストへの影響が大きい設備から優先順位をつけます。一般には、代替の効かない単一設備、停止時の復旧に時間がかかる設備、突発故障の実績がある設備が候補になります。

狙う故障モードによって有効なアプローチは変わります。回転機（モーター・ポンプ・ファン・コンプレッサー）の軸受劣化やアンバランスは振動・温度の傾向監視が定石で、後付けセンサーで取り組みやすい領域です。工作機械の主軸やボールねじの精度劣化は振動に加え電流・加工結果のデータが手がかりになります。生産ライン全体の「いつもと違う」を広く捉えたい場合は、特定の故障を狙うより、稼働データ全体から異常検知で外れを見つける方式が向きます。

ここを曖昧にすると、兆候が現れにくい箇所にセンサーを置いてしまい、データは溜まるのに予兆が出ないという結果になりがちです。「どの設備の・どの部位が・どう壊れ・どんな物理量に兆候が出るか」を一文で書けるかどうかが、最初の関門になります。

回転機の軸受・劣化を狙う場合

モーターやポンプの軸受劣化を主目的とするなら、振動・温度を後付けセンサーで取得し、機械学習で正常状態からの逸脱を検知する構成が出発点です。OMRON i-BELT / AI予知保全ライブラリのように回転機向けの知見をライブラリ化したサービスは、現場でのセンサー設置と分析の立ち上げを短縮しやすい選択肢です。

生産ライン全体の異常を広く捉えたい場合

特定故障の狙い撃ちではなく、多数のセンサー値の関係性が崩れる「いつもと違う」を広く検知したい場合は、相関構造の崩れから異常を捉える手法が向きます。NEC Advanced Analytics インバリアント分析は、多数のセンサー間の不変的な関係をモデル化し、その崩れを異常として検知するアプローチで、対象を一品種に絞りにくいプラント・ライン全体の監視に適します。

既存のIoT基盤・上位システムと統合したい場合

すでに設備IoTのデータ収集基盤を持ち、その上で予兆分析や運用最適化まで一気通貫で組みたい場合は、製造IoTプラットフォーム上のソリューションが候補です。Lumada Manufacturing Insightsのような基盤型は、データ収集・蓄積・分析・可視化を同一基盤で扱えるため、点の予知保全から面のデータ活用へ広げたい企業に向きます。

狙う故障モードが決まったら、その兆候を捉える物理量とセンサーを選びます。代表的なのは振動・温度・電流・電圧・音響・回転数・圧力で、軸受劣化なら振動と温度、モーターの異常なら電流、エア漏れや異音なら音響というように、故障モードと物理量の対応を外さないことが重要です。必要な物理量が取れていなければ、後段のAIがどれほど高度でも予兆は出ません。

センサーの取り付け方式は、後付け可否を左右する実務上の論点です。設備に新規センサーを貼り付ける後付け型は、既存設備を改造せず始められる反面、設置箇所・固定方法・サンプリング周期で精度が変わります。一方、設備が元から持つPLCやインバーターの内部データ（電流値・トルク・アラーム）を吸い上げる方式は、追加配線を抑えられる利点があります。どこまで既設のデータで賄い、どこに新規センサーを足すかの線引きが、初期コストとデータ品質の両方に効きます。

編集部コメント：「とりあえず全部のセンサーを付ける」発想はコストと運用負荷を押し上げます。狙う故障モードに対して必要十分な物理量に絞り、足りなければ後から追加する設計のほうが、初期投資を抑えつつ精度を確保しやすいというのが実務的な順序です。

分析手法は大きく「異常検知」と「余寿命予測」に分かれ、両者で前提となるデータが異なります。異常検知は正常時のデータから外れを見つける方式で、故障事例がほとんどなくても始めやすいのが利点です。多くの現場では故障データが乏しいため、まず異常検知から入るのが現実的な選択になります。一方、余寿命予測（あとどれくらいで壊れるか）は、劣化の進行と故障に至った履歴データが一定量ないと精度が出にくく、ハードルが上がります。

学習データの要否と現場での扱いやすさも見極めの論点です。専門のデータサイエンティストがいない保全現場では、ノーコードで学習・運用できるツールが定着しやすく、Prediction Oneのように予測モデルの作成を画面操作で完結できるツールは、まず自社データで予兆分析を試したい段階に向きます。より高度な異常検知のアルゴリズムを既存システムへ組み込みたい場合は、Impulseのような異常検知エンジンを評価対象に加えると、検知精度と組み込み柔軟性の観点で比較がしやすくなります。

デメリットも直視しておく必要があります。異常検知は「異常らしさ」を出せても原因や残り時間までは断定できず、誤報（実際は問題ないのに警報）と見逃しのトレードオフを運用でチューニングし続ける手間が残ります。余寿命予測は魅力的ですが、学習に足る故障履歴がないまま導入すると、もっともらしいが当たらない数字を出し続けるリスクがあります。自社にどちらのデータが揃っているかを冷静に棚卸ししてから手法を選ぶことが、過剰な期待による失敗を防ぎます。

予知保全システムは単体で完結せず、既存の制御盤やPLC、上位のSCADA・MESと接続して初めて現場で機能します。連携で確認すべきは、データの取得経路（PLCのプロトコル対応、OPC UAなど標準規格への対応）、既存ネットワークへの影響、そして取得したデータを保全担当が見る画面までの導線です。ここが弱いと、せっかく集めたデータが分析サーバーの中に孤立し、現場の判断に使われないまま終わります。

既存設備が古く、外部にデータを出す口を持たない場合は、後付けセンサーとゲートウェイでデータを取り出す構成になります。逆に比較的新しい設備やSCADAが整っている工場では、既存のデータ収集経路に予知保全の分析を載せるほうが配線も運用もシンプルです。自社の設備年式と制御環境がどちらに近いかで、現実的な連携方式は大きく変わります。

注意点として、工場ネットワークはセキュリティと可用性の要求が高く、分析のためのデータ取得が生産系の通信を圧迫してはなりません。OT（制御）側とIT（情報）側の境界をどう設計するか、クラウドへデータを出す場合の経路をどうするかは、情報システム部門と早い段階で擦り合わせておくべき論点です。連携の検証を後工程に回すと、AIの精度が良くても画面までデータが届かず、現場で使われないまま終わるという典型的な失敗につながります。

連携方式は製品によって得手不得手があり、対応プロトコルや既存システムとの接続実績は選定段階で必ず確認すべき点です。とくに古い設備が混在する工場では、すべての設備から同じ方式でデータを取れるとは限らないため、設備ごとに後付けセンサー方式と既存データ吸い上げ方式を組み合わせる前提で要件を整理しておくと、後からの追加工事や手戻りを抑えられます。

予知保全は全社一括で導入するより、止めたくない設備の1ライン・数台から始め、効果を確認しながら横展開するスモールスタートが定石です。選定時には、少数台から契約・検証できる料金形態か、PoCで自社データを使った実証ができるかを確認します。最初から全工場分のライセンスやセンサーを抱えると、効果が出る前にコストが膨らみ、推進力を失います。

同時に見落とされがちなのが、現場運用と保全体制です。アラートが鳴ったときに「誰が・どの基準で・何を点検し・いつ部品を手配するか」という判断フローが決まっていないと、警報は出るのに行動につながらず、やがて無視されるようになります。予知保全は導入して終わりではなく、検知結果を保全計画に落とし込む運用ループが回って初めて停止削減につながります。

編集部コメント：PoCの合否は「AIの精度」だけで決めないことをおすすめします。検知できても現場が動けなければ意味がないため、運用導線とアラート対応フローまで含めて評価項目に入れると、本番で形骸化するリスクを大きく下げられます。

費用は初期費用（センサー・ゲートウェイ・設置工事・初期設定）と、月額・年額のソフトウェア利用料、そして運用工数の3つで構成されます。対象設備の台数やセンサー点数で大きく変動するため、一律の相場を当てはめるより、自社の対象台数で初期費用と3年分のランニングを積み上げて3年TCOとして把握するのが実務的です。スモールスタートなら初期費用を1ライン分に抑えられる反面、横展開時に台数比例で費用が増える点も織り込んでおきます。

ROIは「回避できた停止損失」で評価します。対象設備が突発停止したときの1時間あたりの逸失生産額・復旧費用・関連工程への波及を見積もり、年に何回の突発停止を未然に防げれば投資を回収できるかを逆算します。逆に、もともと突発停止がほとんど起きていない設備に高価なシステムを入れても、回避できる損失が小さくROIは出ません。費用対効果が成立するのは、停止インパクトが大きく、かつ予兆を捉えられる設備に絞った場合だという前提を外さないことが重要です。

クラウド型・基盤型サービスは初期投資を抑えやすい一方で、台数増加に伴いランニングが積み上がります。Senseye Predictive Maintenanceのような多数設備のスケール運用を想定したサービスは、台数が増えたときの管理性と費用構造をあわせて確認しておくと、横展開後のコスト見通しが立てやすくなります。デメリットとして、安価に見えるサブスクでも対象台数が増えれば総額は大きくなり得るため、3年・5年スパンでの総額試算を必ず行ってください。

これまでの7軸を踏まえ、自社のタイプ別に出発点となる方向を整理します。本記事で扱った範囲で、読者の立場ごとに先に検討すべき切り口を示します。具体的な製品スペックの横並び比較は「予知保全システム比較」で確認してください。

回転機の突発停止をまず減らしたい場合

モーター・ポンプ・ファンなど回転機の軸受劣化を主目的とするなら、振動・温度を後付けセンサーで取得し、現場主導で立ち上げやすいサービスから検討します。OMRON i-BELTのように回転機向けの分析知見を備えたサービスや、自社データで予兆分析を試せるPrediction Oneを、対象数台のスモールスタートで評価するのが現実的です。

専任のデータ人材がいない保全現場の場合

データサイエンティストを置けない現場では、ノーコードで予測モデルを作れるPrediction Oneのようなツールが定着しやすい出発点です。まず手元の稼働データで「予兆が見えるか」を小さく検証し、手応えが得られた領域から対象を広げていく進め方が、過剰投資を避けつつ社内の理解も得やすくなります。

生産ライン・プラント全体の異常を広く監視したい場合

特定故障の狙い撃ちが難しい多品種・連続プロセスでは、多数センサー間の関係性の崩れを捉えるNEC Advanced Analytics インバリアント分析のような手法が候補です。守るべき故障を一つに絞れない設備群で、まず「いつもと違う」を広く拾いたい段階に向きます。

既存のIoT基盤の上でデータ活用を広げたい場合

設備IoTのデータ収集基盤をすでに持ち、予知保全を起点に可視化・最適化まで広げたいなら、Lumada Manufacturing Insightsのような製造IoTプラットフォーム型が出発点になります。点の予知保全で終わらせず、収集データを生産・品質の改善にもつなげたい企業に向きます。多数設備へのスケールを前提にするならSenseye Predictive Maintenanceのような大規模運用志向のサービスも比較対象に加えると、横展開時の管理性で判断しやすくなります。

予知保全システム導入で失敗する企業には共通パターンがあります。事前に把握しておくと、稟議段階で対策をあわせて提示でき、社内の合意も得やすくなります。

第一は「目的不在」型です。狙う設備と故障モードを決めずに、デモで見た高度なAIに惹かれて導入し、何の予兆を捉えたいのかが曖昧なまま運用が始まるパターンです。回避策は、対象設備・故障モード・捉えたい物理量を一文で言語化してから製品選定に入ることです。

第二は「センサー過剰／不足」型です。とりあえず大量のセンサーを付けて初期費用が膨らむか、逆に必要な物理量を取らずに予兆が出ないパターンです。回避策は、狙う故障モードに必要十分な物理量へ絞り、PoCでデータ品質を実機検証してから台数を決めることです。

第三は「データ孤立」型です。分析サーバーにデータは溜まるのに、既存PLC・SCADAや保全現場の画面とつながっておらず、誰も見ないパターンです。回避策は、選定段階で連携方式とアラートの表示導線まで要件に含め、保全担当が日常的に見られる状態を作ることです。

第四は「運用断絶」型です。アラートは鳴るのに対応フローがなく、警報が無視され形骸化するパターンです。回避策は、検知から点検・部品手配・保全計画反映までの判断フローと担当を導入と同時に設計し、運用ループとして稟議に組み込むことです。

編集部コメント：四つの失敗パターンは、いずれも「選定軸のどこかを後回しにした」結果として生じます。本記事の7軸とPoC評価項目を稟議資料にそのまま落とし込むと、これらの典型的なつまずきを設計段階で先回りして潰せます。

予知保全システムの選定は、対象設備・故障モードの特定を起点に、データ取得方式・AI分析手法・既存設備連携・スモールスタート・現場運用・コストROIの順で評価すると失敗が減ります。止めたくない設備と捉えたい故障を一文で言語化し、その兆候が出る物理量とセンサーを選び、自社のデータ状況に合う分析手法（まずは異常検知）を選び、既存PLC・SCADAとの連携とアラート導線を確保し、1ライン・数台のスモールスタートで効果を確かめ、3年TCOと回避できる停止損失でROIを組み立てる流れです。

高度なAIから入るのではなく、止めたくない設備と捉えたい故障から入ること、そして検知結果を保全計画に落とし込む運用ループまで設計に含めることが、定着する予知保全とPoC止まりの分かれ目になります。

具体的な製品候補を横並びで比較したい場合は、別記事「予知保全システム比較」で各製品のスペックと適合タイプを確認できます。予知保全そのものの考え方を整理したい場合は「予知保全とは」を、関連サービスの一覧は予知保全・故障予測システムのカテゴリページをあわせてご覧ください。本記事の7軸で自社要件を整理してから比較に進むと、選定が短期間で完了します。