予知保全システムの選び方｜構成6ブロックと費用・生産管理連携で決める導入判断

予知保全システムの検討が止まる原因は、製品の数ではありません。センサーを付けて異常を検知するところまでは各社の製品が揃っているのに、その検知を誰がどう受け取り、保全計画に戻すのかが決まらないまま比較表を眺めることになるからです。この記事では、ISO 13374-1が定める6つの処理ブロックで予知保全システムの構成を切り分け、自社に必要な範囲を先に決める手順を示します。そのうえで、設備メーカー純正・センサーベンダーのパッケージ・汎用IoT基盤・受託開発という4つの調達類型の向き不向き、公開料金から試算したクラウド費用の実額、設備保全管理システムと生産管理システムへの連携設計、そしてパッケージで足りる条件と受託開発に踏み込む境界線まで踏み込みます。金額と日付は2026年8月7日にAWS公式料金ページとISO 13374の規定内容を確認したものです。

まとめ｜予知保全システムは構成ブロック単位の調達判断で決まる導入の成否

結論を先に置きます。予知保全システムは、製品を選ぶ前に「6つのブロックのうち、どこを買い、どこを自社で組むか」を決めてください。データ収集から状態検知までは既製品が成熟していて、ここを自作する理由はほとんどありません。判断が要るのは後ろ半分、つまり健全性評価から保全指示の生成までです。検知結果を保全担当者の作業指示に変換し、実施結果を戻す往復が設計されていない導入は、アラート画面だけが残ります。

費用の重心も、多くの人が想定する場所とずれています。クラウド基盤の従量課金は、50設備を1分値で監視しても月額数十ドルの規模に収まります。実際に効いてくるのは、センサーの設置工事と、誤報に対応する保全担当者の工数です。だからこそ、パッケージで足りるか受託開発が要るかの分岐は、価格表ではなく連携要件と設備の多様性で判断します。監視対象が回転機中心で単独運用に収まるならパッケージ、既存の保全管理システムや生産管理システムと双方向でつなぐ必要があるなら受託開発。この線引きを以下で具体化していきます。

予知保全システムの構成｜ISO 13374の6ブロックと自社に要る範囲の見極め

状態監視システムの構成には国際規格があります。ISO 13374-1（2003年発行）は、機械の状態監視・診断システムのアーキテクチャに関する一般指針として、処理を6つの機能ブロックに分けました。MIMOSAが策定したOSA-CBM（状態基準保全のためのオープンシステムアーキテクチャ）を源流とする枠組みで、製品選定の共通言語として使えます。

データ収集(DA)｜後付けセンサーと制御盤からの取得で分かれる初期費用

最初のブロックは、センサー出力をタイムスタンプと品質情報つきのデジタル記録に変換する層です。ここで選択肢は2つに分かれます。振動・温度センサーを設備に後付けする経路と、既にPLCやプロセスヒストリアンに溜まっている運転データを引く経路。初期費用の差は大きく、後者はセンサー費用と設置工事がまるごと不要になります。まず制御盤側に何が残っているかを棚卸ししてください。確認するのは記録の粒度、保存期間、欠測の頻度の3点です。1時間平均値しか残っていない設備では、軸受の初期異常のように短時間で立ち上がる兆候を捉えられないため、後付けセンサーが要ります。予知保全そのものの仕組みと保全方式の違いは予知保全とは？仕組みと予防保全との違いから費用対効果までで整理しました。

信号処理と状態検知(DM・SD)｜しきい値で足りる範囲と多変量が要る範囲

2番目のデータ処理(DM)は、生の波形を状態判定に使える特徴量へ変換する層です。振動なら実効値、周波数分析による回転数成分や軸受周波数成分の抽出がここに当たります。3番目の状態検知(SD)は、正常か異常かを判定する層。この2つが既製品の主戦場で、センサーベンダーの製品はほぼ例外なくここまでを内包しています。判断が要るのは判定方式です。単一の値が上下限を超えたかを見るしきい値判定で足りる設備と、複数センサーの関係が崩れたことを捉える必要がある設備では、要求される製品が変わります。連続運転のポンプやファンは前者で始めて構いません。段取り替えが頻繁で運転条件が振れる設備は、モードごとに判定基準を分ける設計を最初から要求してください。

健全性評価と余寿命予測(HA・PA)｜診断まで持つかを分ける設備の条件

健全性評価(HA)は現在の状態を健全度として評価し、故障の内容まで診断する層。余寿命予測(PA)は、次に大きな状態変化が起きるまでの残り時間を予測する層です。ここから先は、どの設備にも要るわけではありません。故障モードが実質的に1つで、検知したら止めて分解するという運用なら、健全度スコアだけあれば十分に回ります。逆に、部品が単調に摩耗して寿命に至る設備で、交換部品の調達に数週間かかるなら、余寿命の推定値が調達判断そのものになります。この2ブロックを持つかどうかで、必要な学習データの量と保全記録の整備水準が変わるため、判断は導入前に済ませてください。モデルの型ごとに必要となる故障履歴の条件は予知保全のAI導入｜故障予測モデルの型の選び方で扱っています。

保全指示の生成(AG)｜検知を作業に変換できない構成で起きる典型的な失敗

最後の保全指示生成(AG)は、設備の寿命や工程を守るために何をすべきかという実行可能な情報を出す層です。規格が独立したブロックとして定義しているのに、製品選定の場では最も軽く扱われます。検知が出た後の流れを書き出してみてください。誰に通知が届き、誰が一次確認し、どの帳票に作業指示として起票され、実施結果はどこに戻るのか。この経路が既存の保全業務とつながっていないと、検知は画面上の色の変化で終わります。導入から半年で運用が止まる事例の大半は、精度の問題ではなく、この変換が設計されていないことに起因します。

予知保全ソリューションの4類型｜調達形態ごとの向き不向きと選定の分岐

市場に出ている予知保全ソリューションは、機能の細部より調達形態で分けたほうが判断しやすくなります。4類型に整理します。

設備メーカー純正の監視サービス｜対象機種が限られる代わりに立ち上がりが速い型

工作機械メーカー、コンプレッサーメーカー、産業用ロボットメーカーが自社製品向けに提供する監視サービスです。センサーの取り付け位置と正常時の挙動をメーカー自身が把握しているため、しきい値の初期設定に悩む期間がほぼ発生しません。制約は対象機種です。同じ工場に他社製の設備が混在していると、設備ごとに別の画面と別の契約が並ぶことになります。監視したい設備の7割以上が単一メーカー製に寄っていることが、この型を最短の入口とみなせる目安です。複数メーカーが混在する現場では、統合画面を後から作る費用が積み上がるため、初期の速さが相殺されます。

センサーベンダーのパッケージ｜振動と温度の定番構成で小さく始める条件

振動センサー、ゲートウェイ、クラウド画面までを一式で提供する型です。回転機の状態監視という定番用途に絞られている代わりに、設置してから数日で数値が見えます。この型を選ぶ条件は明確で、監視対象がモーター、ポンプ、送風機、コンプレッサーといった回転機であること、そして当面は監視画面を見る運用で足りることです。注意すべきはサービスの継続性で、この領域は事業者の入れ替わりが起きています。Amazon Monitronは2024年10月31日に新規顧客の受付を終了し、AWSは後継デバイス・後継サービスを予定せず、パートナー製品を代替として案内する方針に切り替えました。センサーの生データを自社側に取り出せる契約かどうかを、導入前に確認してください。

汎用IoT基盤に載せる構成｜多拠点・多設備へ広げるときに効く拡張性

クラウド事業者のIoT基盤に、センサーとゲートウェイを自社で組み合わせる型です。AWS IoT SiteWiseやAzureのIoTサービスが該当し、設備の種類や台数が増えても構成が破綻しにくい設計になっています。AWS IoT SiteWiseには2025年7月に多変量の異常検知機能が追加され、基盤側で状態検知まで賄える範囲が広がりました。この型が向くのは、拠点が複数あり、設備の種類も混在していて、データを一箇所に集める必要がある場合です。逆に単一工場で数台の監視から始める段階では、構築の手間に見合いません。

受託開発で組む構成｜既存システム連携と設備の多様性が要件に入る場合

センサーと基盤は既製品を使いながら、収集の仕組み、判定ロジック、画面、既存システムとの連携部分を個別に開発する型です。全部を一から作るという意味ではありません。実際の案件では、データ収集から状態検知までは既製品に任せ、健全性評価から保全指示生成までを自社の業務に合わせて作ります。専用設備や改造機が多い現場、保全管理システムや生産管理システムと双方向でつなぐ必要がある現場が対象です。判断基準は後段の章で示します。

予知保全システムの費用構造｜センサー・通信・クラウド・運用の4費目と試算

見積書は製品ごとに項目名が違い、比較になりません。費目を4つに揃えてから並べてください。

初期費用の内訳｜センサー1点あたりの単価より設置工事が読みにくい理由

初期費用は、センサー本体、ゲートウェイと通信機器、設置工事、初期設定の4つに分解できます。このうち見積りが振れるのは設置工事です。センサー本体の単価はカタログで比較できますが、工事費は現場条件で変わります。防爆エリアかどうか、電源をどこから取るか、有線を引くか無線にするか、設備を止められる時間帯がいつか。同じ50台の監視でも、稼働中に取り付けられる現場と、年次の定期停止に合わせるしかない現場では、工期が半年単位で変わります。相見積りを取る前に、対象設備の設置環境と停止可能な時間帯を一覧にしておくと、各社の見積りが比較可能な形で揃います。食品工場の洗浄区画や化学プラントの防爆エリアなど、業種ごとに変わる設置条件は工場の予知保全｜業種別の設置制約と対象設備の選び方で整理しました。

クラウド従量課金の試算｜50設備・1分値で月額がどこまで積み上がるかの計算

クラウド費用は公開料金から試算できます。AWS IoT SiteWiseの公開料金は、メッセージング1.00USD／100万メッセージ、データ処理0.50USD／100万計算、データストレージ0.30USD／GB月、監視画面のSiteWise Monitorが10.00USD／アクティブユーザー月、エッジ側の処理パックが200USD／月です（2026年8月時点・リージョンにより差、最低料金なしの従量制）。ここに50設備×5センサーを1分間隔で流すと、1信号あたり月43,200件、合計で月1,080万件になります。メッセージング料金は約10.8USD。監視画面を5人が使って50USD。エッジ処理を入れなければ、月額100USDに届きません。

この試算が示すのは、クラウド基盤の従量課金は費用の主役ではないという事実です。数百万円規模の見積りが出てくるとき、その内訳はセンサーと工事、そして構築と連携の人件費に寄っています。ベンダーの提示額を評価するときは、クラウド利用料の項目ではなく、構築工数と連携範囲を確認してください。

運用費の見落とし｜誤報対応とモデル保守に消える保全担当者の工数

見積書に載らない費用が2つあります。1つは誤報への対応工数です。導入初期のしきい値は保守的に設定されるため、警報が出るたびに現場が確認に走ります。1日1件の確認が15分でも、月に約5時間。設備が増えれば比例して増えます。もう1つは判定基準の見直しです。設備の改造、部品交換、生産品目の変更があるたびに、正常とみなす範囲がずれます。この見直しを誰が担うかを決めずに導入すると、警報が信用されなくなり、やがて誰も見ない画面になります。年間の運用工数として、対象設備1台あたり数時間を初年度の見込みに入れておくと、判断を誤りません。

生産管理・設備管理システムとの連携設計｜検知から保全指示までのデータの流れ

予知保全システムを単独で置くか、既存システムとつなぐか。ここが構成全体の分かれ目になります。

設備保全管理システムとの連携｜作業指示と実績を戻す往復の設計

検知の出口として最も自然なのが、設備保全管理システム（CMMS/EAM）です。異常の検知が保全作業の起票につながり、実施した作業の内容と交換部品が記録として戻る。この往復ができると、予知保全の検知精度を後から評価できるようになります。作業実績が戻らない構成では、警報が正しかったのか誤報だったのかを判定する材料が残りません。既に保全管理システムを持っているなら、まずそのAPI仕様を確認してください。まだ持っていない場合、予知保全と保全管理を同時に立ち上げるのは負荷が高く、台帳側を先行させたほうが安定します。製品タイプごとの選定軸は設備保全管理システム（CMMS/EAM）の比較｜製品タイプ別の選定軸に整理しました。

生産管理システムとの連携｜停止予測を生産計画へ反映するときの粒度

もう一方の出口が生産管理システムです。設備が数週間以内に停止しそうだという予測を、生産計画の負荷配分に反映できれば、予知保全の投資回収の幅が広がります。ただし粒度の設計が要ります。生産計画は日単位や週単位で動くのに対し、状態監視のデータは分単位。そのまま流し込んでも計画側は使えません。実務では、健全度が一定の水準を下回った設備を「要保全枠確保」として週次で連携する程度の粒度が扱いやすくなります。連携先の生産管理システム側の機能構成については生産管理システムとは？機能・ERP／MESとの違いから選び方までを参照してください。

連携方式の選択｜API連携とCSV連携で分かれる更新頻度と運用負荷

連携方式は、更新頻度から逆算して決めます。作業指示の起票のように即時性が要る経路はAPI連携。週次で計画に反映する経路なら、ファイル受け渡しでも運用は回ります。CSV連携を選ぶ判断は、手抜きではありません。連携先が古いパッケージでAPIが用意されていない場合、無理にAPIを作らせるより、出力ファイルの取り込みで確実に動かすほうが保守しやすくなります。判断の分かれ目は、連携の失敗に誰がいつ気づけるかです。ファイル連携を選ぶなら、取り込み結果の通知だけは自動化してください。

パッケージ導入と受託開発の分岐点｜連携要件と設備の多様性で決める判断基準

ここは言い切ります。価格差で選ぶ判断は外れます。分岐は連携要件と設備の多様性の2軸です。

パッケージで足りる条件｜監視対象が回転機中心で単独運用に収まる場合

次の3つを満たすなら、パッケージを選んでください。監視対象の8割以上がモーター、ポンプ、送風機、コンプレッサーといった回転機であること。検知の出口が保全担当者への通知で完結し、他システムへ自動連携する必要が当面ないこと。そして拠点が1か所であること。この条件下では、受託開発に踏み込んでも得られるものが画面の細部だけになり、投資に見合いません。パッケージで運用を1年回してから、足りない部分を特定して拡張するほうが、要件の精度が上がります。

受託開発を選ぶ条件｜既存システム連携と独自設備が要件に入る境界線

逆に、受託開発を選ぶべき条件も明確です。既存の保全管理システムや生産管理システムと双方向で連携する要件がある場合。専用機や改造機が多く、市販センサーの標準的な取り付け方が通用しない設備が対象に含まれる場合。複数拠点のデータを1つの基準で比較したい場合。このいずれかに該当すると、パッケージの制約が要件に先に当たる構図です。特に双方向連携は、既製品の連携機能が片方向の通知に限られていることが多く、実績を戻す経路を作る段階で個別開発が発生します。実際の要件整理や既存システムとの接続設計については、生産管理システム開発の受託としてご相談を承っています。

受託開発を見送る場面｜PoC前に作り込む判断が失敗に終わる2つの理由

受託開発を見送るべき場面が1つあります。まだ1台も監視していない段階で、いきなり全社展開を前提にしたシステムを設計する場合です。理由は2つ。第一に、監視項目と判定基準は現場のデータを数か月見てからでないと決まりません。設計段階で決めた項目の半分は、運用開始後に差し替えになります。第二に、検知の出口となる保全業務のフロー自体が、警報を受け取る運用を始めてから変わるからです。作り込みを先行させると、変更のたびに改修費が積み上がります。対象1設備から始めて、正常時のデータを3か月分ためる。この順序を飛ばした導入で、投資が回収できた例をほとんど見ません。

予知保全システムの選び方でよくある質問と導入前の疑問への回答

検討段階で受ける質問のうち、判断に直結するものを5つ挙げます。

予知保全システムはどこまでの構成をそろえる必要がありますか？

全ブロックを最初からそろえる必要はありません。ISO 13374-1が定める6ブロックのうち、データ収集から状態検知までの3つがあれば監視は始まります。健全性評価と余寿命予測は、故障モードが複数ある設備や、交換部品の調達に時間がかかる設備で追加してください。逆に省略できないのが最後の保全指示生成で、通知を誰が受けて何をするかという運用設計は、規模にかかわらず初回から決めておく必要があります。

予知保全システムと設備保全管理システム（CMMS）は何が違いますか？

担当する範囲が違います。予知保全システムは設備の状態データを集めて異常の兆候を検知する仕組み、設備保全管理システムは保全作業の計画・指示・実績・部品在庫を管理する仕組みです。前者が出すのは「何かが起きそうだ」という兆候で、後者の役割は「誰がいつ何をしたか」の記録です。片方だけでも成立しますが、検知の精度を後から評価するには両方の記録が要ります。導入順としては、保全記録が紙やExcelのままなら台帳側を先に整えたほうが、予知保全の立ち上がりが速くなります。

既存の生産管理システムと連携させるには何が必要ですか？

確認する項目は3つです。生産管理システム側にAPIが用意されているか、無い場合にファイル取り込みの口があるか。連携する情報の粒度をどこに置くか（日単位の保全枠確保なのか、設備別の停止予測なのか）。そして更新頻度をどこまで落とせるか。多くの現場では週次のファイル連携で実務が回ります。即時連携を要件に入れると、開発費と障害時の運用負荷が一段上がるため、本当に必要かを先に検討してください。

予知保全システムの導入にはどのくらいの期間がかかりますか？

センサーベンダーのパッケージで回転機を数台監視する構成なら、機器の調達から設置、画面で数値が見えるまで1か月から2か月が目安です。ただし判定基準を実運用に耐える水準へ調整するには、正常時のデータが3か月程度は要ります。既存システムとの連携を含む受託開発では、要件定義から本番稼働まで半年から1年を見込んでください。設備を止められるタイミングが年次の定期停止しかない場合、その日程が全体の工期を決めます。

製造業以外の設備でも予知保全システムは成立しますか？

成立します。ビル設備の空調機やポンプ、上下水道の送水ポンプ、物流施設のコンベアやソーターは、いずれも連続運転する回転機を含むため、振動と温度の監視が機能します。判断基準は業種ではなく、停止したときの損失額が監視費用を上回るかどうか、そして正常時の運転条件が安定しているかどうかの2点です。運転条件が季節や需要で大きく振れる設備では、条件ごとに判定基準を分ける設計が前提になります。

関連記事

• 設備保全とは？予防保全・予知保全・事後保全の違いと製造業の進め方：保全方式の全体像と、予知保全を置く位置の整理
• 設備管理システムとは？CMMS・EAMの機能とExcel台帳との違い：保全記録を管理する台帳側の機能と導入判断
• 異常検知とは？機械学習の手法・仕組みと製造業での導入判断：状態検知ブロックで使う手法の総論
• 製造業のDX事例｜工程改善・予知保全・品質・在庫で見る成果指標：予知保全を含む施策の成果指標と失敗パターン