予知保全と異常検知の違い｜故障事例の件数から導入可否を判断する方法

「予知保全をやりたい」という相談の中身をうかがうと、実際に必要なのは異常検知だったというケースが多くあります。両者は目的も必要なデータも異なるため、混同したまま進めると、途中で「データが足りない」という壁に突き当たります。

本記事では、2つの違いを整理したうえで、自社がどちらに取り組むべきかを判断する具体的な手順を解説します。

予知保全と異常検知の違い

まず定義を分けます。

異常検知は、正常時のデータから通常の変動範囲を学習し、そこから外れた状態を知らせる仕組みです。「いつもと違う」ことは分かりますが、何が起きているかは分かりません。原因の特定は人が行います。

予知保全は、故障の発生を事前に捉える仕組みの総称で、実際には難易度の異なる3段階に分かれます。

この表で注目すべきは、必要なものがデータの量ではなく故障事例の件数である点です。故障は起きてほしくない事象なので、稼働の良い設備ほど事例が少ないという構造的な難しさがあります。

なぜ「データの蓄積年数」で判断してはいけないのか

「3年分のデータがあるので予知保全ができるはず」という前提は、実務では成立しません。理由は、機械学習が学習できるのはラベル付きの事例だからです。

3年間で故障が2回しか発生していない設備の場合、学習に使える故障の事例は2件です。この2件から一般化できるパターンを学ぶことはできません。一方、正常な状態のデータは膨大にあるため、「正常の範囲」を学ぶことは可能です。これが異常検知が成立する理由です。

判断の第一歩は、次の3つを数えることです。

1. 過去3年間に、対象設備で計画外停止が何回発生したか
2. そのうち、原因が記録として残っているのは何件か
3. 同一の故障モードごとに分類すると、最も多いモードで何件か

3番目の数字が、実現可能な範囲を決めます。ここが5件であれば、そのモードの判別モデルを作るのは困難です。

同一機種が複数台ある場合は件数が稼げる

1台あたりの故障が少なくても、同一機種が複数台あれば合計の事例数を確保できます。20台の同型設備で年3件ずつ故障していれば、3年で180件です。

この場合の条件は、設備間で運転条件と計測点が揃っていることです。設置環境や負荷条件が大きく違うと、1台のデータを他台に一般化できません。導入前に、稼働条件のばらつきと、センサーの取り付け位置が統一されているかを確認します。

異常検知は「故障事例を貯める仕組み」として設計する

故障事例が足りない段階で取り組む異常検知は、単体の効果だけで評価すると物足りなく見えます。「いつもと違う」と言われても、現場は何をすべきか分からないためです。

しかし、位置づけを変えると価値が変わります。異常検知を、故障事例を構造化して蓄積する仕組みとして設計するという考え方です。

具体的には、異常が検知されたときに次の情報を記録する運用をセットで作ります。

• 検知時刻と、そのときのセンサー値
• 現場が確認した結果（何が起きていたか、または問題なかったか）
• 対応内容（部品交換、調整、様子見）
• その後実際に故障に至ったか

この4項目を1年間蓄積すると、2年目には故障モードの判別に必要なラベル付きデータが揃います。異常検知の導入時点で、この記録の運用まで設計できているかどうかが、2年目以降の選択肢を決めます。

多くのプロジェクトは、異常検知を「精度が物足りない仕組み」として1年で終わらせてしまい、蓄積されたはずのデータを残しません。

センサーを増やしても、推定できる範囲は広がらない

導入検討でよく出るのが「センサーを増やせば精度が上がるのではないか」という問いです。答えは条件付きでノーです。

センサーの追加で改善するのは、現象を観測できているかという問題です。振動が原因の故障を電流値だけで捉えようとしているなら、振動センサーの追加には意味があります。

一方、故障事例が2件しかないという問題は、センサーを10個増やしても解決しません。観測の解像度が上がっても、学習に使える事例の件数は変わらないためです。

投資判断としては、まず既存データで異常検知を構築し、捉えられなかった故障がどのような種類だったかを確認してから、必要なセンサーを特定する順序が無駄になりません。

対象設備の選び方

全設備への一括導入は、効果検証を難しくします。最初の対象は次の条件で1機種に絞ります。

5番目は軽視されがちですが、実際には決定的です。異常検知の結果を確認し、何が起きていたかを記録するのは保全担当者です。この協力が得られない設備を対象に選ぶと、データが蓄積されず、翌年の改善につながりません。

投資回収の見積もり方

予知保全の効果は、次の式で上限を把握できます。

削減余地の上限 = 対象設備の年間計画外停止時間 × (1時間あたりの逸失利益 + 緊急対応の人件費)

この上限に対して、実際に削減できる割合は導入初年度で2〜3割程度を見込むのが現実的です。全ての故障を事前に捉えられるわけではなく、捉えられても対応が間に合わないケースがあるためです。

見積もりで漏れやすいコストは次のとおりです。

• データ基盤の運用費（クラウド利用料、通信費）
• モデルの再学習と、条件変更への追従作業
• 現場の確認・記録にかかる工数（1件あたり数分×検知件数）
• 設備更新時の再構築

3番目は導入前に必ず試算します。1日10件の異常通知が出て、1件の確認に10分かかる設計であれば、1日100分の追加業務が発生します。この負荷が現場の許容範囲を超えると、通知が無視されるようになります。

段階を踏んだ進め方

この進め方の要点は、最初の3か月を分析ではなく棚卸しに充てることです。ここで故障事例の件数を把握しておくと、実現できない目標を掲げてプロジェクトが破綻する事態を避けられます。

保全記録の棚卸しは、実際に何を見るのか

「故障事例を数える」と書きましたが、実務では記録の形式がばらばらで、そのままでは数えられません。棚卸しで確認する項目を具体化します。

このうち発生時刻の粒度は、後の分析可否を分ける項目です。センサーデータと突き合わせるには、少なくとも時刻が必要になります。日付単位の記録しかない場合、その日の24時間のどこで異常が始まったかを特定できず、学習データとしての価値が大きく下がります。

現在の記録が日付のみであれば、今日から時刻を残す運用に変えるだけで、1年後のプロジェクトの前提が変わります。設備投資を伴わない、最も費用対効果の高い準備です。

「経年劣化」で片付けられた記録をどう扱うか

保全記録の原因欄が「経年劣化」で埋まっている工場は珍しくありません。これは事実上、原因が記録されていない状態です。

対処としては、部品伝票との突き合わせが有効です。修理時に交換された部品が分かれば、故障部位を逆算できます。「軸受を交換した」という記録があれば、軸受起因の故障として分類できます。伝票は経理側に残っていることが多く、保全記録より網羅性が高い場合すらあります。

この作業は地味ですが、新しいデータを取り始めるより早く事例数を確保できる方法です。過去3年分の伝票から故障モードを再構成できれば、当初「事例が5件しかない」と思われていた設備で、実は30件以上のラベルが作れることもあります。

異常検知の閾値をどう決めるか

異常検知の運用で最初につまずくのが閾値です。統計的な外れ値の基準をそのまま使うと、通知が多すぎるか、少なすぎるかのどちらかになります。

実務的な決め方は、現場が処理できる件数から逆算する方法です。

1. 現場が1日に確認できる件数を決める（例：5件まで）
2. 過去データに対してモデルを適用し、1日平均5件になる閾値を求める
3. その閾値で1か月運用し、確認結果を記録する
4. 見逃しがあれば閾値を下げ、空振りが多ければ確認手順を簡素化する

精度から閾値を決めるのではなく、運用可能な工数から決めるという順序です。これは安全管理AIの誤検知対策と同じ考え方で、現場が処理しきれない量の通知は、精度が高くても価値を生みません。

経営層への説明で使える整理

予知保全の投資判断を通すとき、技術的な説明より効果があるのは、次の3点を数字で示すことです。

2番目の「兆候が出ていた割合」は、保全担当者に過去の故障を振り返ってもらうと概算できます。「あの停止は前日から音が変だった」という証言が多いほど、予知の余地が大きいことになります。この定性的な情報は、モデルを作る前に投資判断の材料として使えます。

初年度の目標を保守的に置くことも重要です。上限値をそのまま目標にすると、達成できずにプロジェクトが打ち切られます。

まとめ

予知保全と異常検知の違いは、必要とするデータの種類にあります。判断すべきは蓄積年数ではなく、故障事例が何件記録されているかです。事例が少ない段階では異常検知から入り、その運用の中で事例を構造化して貯める。この順序を踏めば、2年目以降に選べる選択肢が確実に広がります。

Pactomでは、保全記録の棚卸しから適用範囲の見極め、異常検知の構築、故障事例の蓄積設計までを支援しています。

関連記事

• IoTセンサー導入の判断基準｜後付けで取れるデータ・取れないデータ
• 製造業のAI活用とは？予知保全・外観検査・生産計画の使い分けと導入手順を解説
• スマートファクトリーとは？段階別ロードマップと投資判断の基準

参考

• 独立行政法人情報処理推進機構（IPA）「DXの推進」https://www.ipa.go.jp/digital/dx/index.html
• 国立研究開発法人新エネルギー・産業技術総合開発機構（NEDO）https://www.nedo.go.jp/