予知保全のAI導入｜故障予測モデルの型の選び方と実装先の判断基準

設備の振動が上限値を超えてから鳴るアラームと、複数センサーの関係が普段と違うことを捉えるAIの検知は、拾える異常の種類が異なる仕組みです。この記事では、予知保全に機械学習を持ち込むと何が変わるのかを整理したうえで、異常検知型・故障分類型・RUL推定型という故障予測モデルの3つの型を、手元の故障履歴とデータ量から選び分ける基準を示します。あわせて、保全記録を学習ラベルに変換する手順、Amazon MonitronやAmazon Lookout for Equipmentといったマネージドサービスが相次いで終了した2026年8月時点の実装先の選び方、PoCから本番運用までの工程と評価指標の決め方まで踏み込みます。数値と日付はAWS公式ドキュメントとMicrosoft Learnを2026年8月6日に確認したものです。

まとめ：AI予知保全は故障履歴の有無とデータ量でモデルの型が決まる

先に結論を置きます。予知保全にAIを入れるかどうかで悩む前に、手元にあるデータを見てください。過去の故障が記録として残っていないなら、選べるのは正常時のデータだけで学習する異常検知型の一択です。故障の日時と原因が保全記録として残っていて、同型機が複数台あるなら故障分類型が視野に入り、部品が単調に摩耗して寿命に至る設備であればRUL推定型が成立します。この順で選択肢が広がる構造になっていて、逆順にはなりません。

実装先の判断は2026年に入って様変わりしました。Amazon Monitronは2024年10月31日に新規受付を終了し、Amazon Lookout for Equipmentは2026年10月7日でサポートが切れます。Azure AI Anomaly Detectorも2026年10月1日に提供を終えます。予知保全のマネージドサービスを前提に設計すると、数年で載せ替えが発生する前提で組む必要が出てきました。だからこそ、生データと特徴量の定義を自社側に残す設計が効いてきます。そして精度の目標は、見逃しと誤報のどちらを許容するかを先に決めないと設定できません。以下、しきい値監視との分岐点、モデル3型の選び分け、学習データの要件、実装先の選定、PoCから本番の工程、見送り条件という順に具体を示していきます。

AI予知保全がしきい値監視と分かれる点｜多変量の相関崩れを捉える仕組み

センサーを付けて上下限を決めるだけなら、機械学習は要りません。それでも取りこぼす異常があるから、AIが持ち込まれます。

上下限しきい値では拾えない異常｜複数センサーの関係が崩れる兆候

従来の状態監視は、振動値が3.5mm/sを超えたら警報、といった単変量のしきい値判定で組まれてきました。この方式が取りこぼすのは、個々の値はどれも正常範囲に収まったまま、値どうしの関係だけが変わる異常です。モーターの電流が普段よりわずかに高く、同時に軸受温度も少し上がり、しかし回転数は変わっていない。1つずつ見れば警報に届かず、3つの関係で見ると初めて逸脱が見えます。Microsoftが提供していたAzure AI Anomaly Detectorの多変量検知は、最大300シグナルの相互相関をGraph Attention Networkで扱う設計になっていました。これが機械学習を持ち込む実質的な理由です。保全方式そのものの違いや費用対効果の考え方は予知保全とは？予防保全との違いと費用対効果の判断で整理しています。

AI予知保全が扱うデータ｜振動・温度・電流と稼働ログの組み合わせ

学習に使うのはセンサー値だけではありません。回転機であれば振動加速度と速度、軸受温度、モーター電流、回転数が主軸になります。ここに制御システム側の稼働ログ、つまり運転モード、負荷率、段取り替えの記録、停止指令の履歴を合わせると、モデルは「負荷が高いから振動が大きい」という正常な変動と、「負荷は同じなのに振動が大きい」という異常を切り分けられるようになります。AWSはLookout for Equipmentの入力として、プロセスヒストリアンやSCADAからのデータを想定していました。新規にセンサーを敷設する前に、制御盤やヒストリアンに何年分のデータが溜まっているかを先に棚卸ししてください。

AIが効く設備と効かない設備｜回転機と変動運転設備で分かれる線引き

効く設備には共通点があります。運転条件の変動が小さく、常時同じような使われ方をする設備です。AWSはLookout for Equipmentの適用対象を「運転条件の変動が限られた固定式の産業機械」と定義し、ポンプ、コンプレッサー、モーター、CNC工作機械、タービン、熱交換器、ボイラー、インバーターを具体例に挙げていました。逆に、多品種少量で段取りが頻繁に変わる設備や、屋外で環境条件が大きく振れる設備は、正常パターンそのものが定義しにくくなります。この場合は運転モードごとにモデルを分けるか、モードを説明変数として明示的に与える設計が必要です。設計を省くと、段取り替えのたびに誤報が出続けます。

故障予測モデルの3つの型｜異常検知・故障分類・RUL推定の選び分け

「予知保全AI」と一括りにされますが、実装される中身は3つに分かれます。必要な学習データが違い、出力も違います。

正常データだけで組む異常検知型｜故障履歴が無い設備で選べる条件

もっとも導入しやすいのがこの型です。正常に動いていた期間のデータだけを与え、そこからの逸脱度をスコアとして出します。故障のラベルが1件も無くても成立するため、保全記録が紙の日報しか無い現場でも導入の入口となる方式です。手法としてはIsolation Forest、One-Class SVM、オートエンコーダの再構成誤差あたりが定番で、多変量時系列であればLSTMベースの再構成誤差も選択肢に入ります。弱点は出力が「いつもと違う」までしか言わないことで、何が壊れかけているかも、あとどれくらい持つかも答えません。手法ごとの向き不向きは異常検知の手法と仕組みの整理にまとめています。

故障ラベルを使う分類型｜必要な故障発生件数と保全記録の粒度の壁

故障の種別まで当てにいくのがこの型です。「軸受の摩耗」「ベルトの緩み」「潤滑不足」といった原因ラベルを教師データに与え、直前のセンサー波形から分類します。実務で壁になるのは件数です。1つの故障モードにつき数十件の実例が欲しいのに、重要設備ほど故障が起きていません。同型機を横断して集める、系列工場のデータを合わせる、といった手を打って初めて足ります。AWSの公式ベストプラクティスも、対象の選定と結果の評価に現場の技術専門家を関与させることを強く推奨していました。ラベルの質は、現場を知る人の手でしか上がりません。

RUL推定型が成立する設備｜劣化が単調に進む部品と精度の読み方

RULは残存耐用寿命の略で、あと何時間、あと何サイクル使えるかを数値で返します。保全計画に直結するため現場の要望は強いのですが、成立条件は厳しめです。故障に至るまでの劣化過程が丸ごと記録された履歴が、複数本必要になります。切削工具の摩耗、フィルタの目詰まり、バッテリーの容量低下のように、劣化が単調に進む部品では現実的です。突発破損が主因の設備では、そもそも予測すべき劣化曲線が存在しません。精度は「何時間ずれたか」ではなく「部品調達と保全枠の確保が間に合う猶予を残して警告できたか」で読むと、実務の判断に噛み合います。

3つの型の選び分け基準｜故障履歴の件数と蓄積データ量で決まる入口

入口はほぼ自動的に決まります。まず保全記録を開いて、直近3年で対象設備に何件の故障が記録されているかを数えてください。ゼロなら異常検知型、原因まで書かれた故障が数十件あるなら故障分類型、故障に至る経過が連続データで残っているならRUL推定型が候補に上がります。段階的に上の型へ移ることは可能で、異常検知型を先に回してアラート発報の履歴を溜め、それを教師データに育てる進め方が現実的です。

学習データの要件と前処理｜センサー点数・保全記録のラベル化・欠測の扱い

モデルの型が決まったら、次はデータ側の工事です。ここが工数の大半を占めます。

センサー点数とサンプリング周期｜300センサーという上限と実運用の粒度

点数の上限は意外と余裕があります。Lookout for Equipmentは単一モデルで最大300センサー、1つのデータセットで最大3000センサーを扱う設計でした。実運用で問題になるのはむしろ周期の側です。AWS IoT SiteWiseの推論スケジュールでは、後処理後のサンプリングレートとしてPT1S（1秒）からPT1H（1時間）までを指定します。軸受の初期異常を捉えるなら数秒から1分粒度、温度やプロセス値の緩やかな逸脱なら5分から15分粒度で足ります。全センサーを1秒粒度で集めても通信量とストレージが跳ね上がるだけなので、粒度は異常の進行速度に合わせて決めてください。

保全記録のラベル化｜作業日報から故障期間を切り出す3段階の手順

教師データを作る工程は、多くの現場で手作業になります。故障期間のラベルは、Lookout for Equipmentの場合もS3に置く任意入力という位置づけで、与えれば精度が上がる代わりに作るのは利用側の仕事でした。

1. 保全日報から、対象設備の異常対応と部品交換の記録を日付順に抽出する
2. 各記録について、異常が始まったと考えられる時刻と、復旧した時刻を現場の技術者と突き合わせて確定する
3. 確定した区間を開始と終了のタイムスタンプに直し、故障モードの分類を付けて保存する

詰まるのは2段階目です。日報には「異常音のため停止」としか書かれておらず、いつから兆候が出ていたかは残っていません。この場合は復旧時刻から遡って一定期間を異常区間と置く割り切りが要り、その幅の決め方こそ現場の技術者に聞くべき論点になります。

正常モデルを汚す3つのノイズ｜欠測・計画停止・設定変更の除外設計

正常時のデータをそのまま学習させると、モデルは高い確率で誤報を吐きます。原因は3つに絞れます。1つ目は通信断による欠測で、値がゼロで埋まった区間をモデルが正常パターンとして覚えてしまう問題です。2つ目は計画停止と休日の非稼働区間で、稼働中と混ぜると分布が二山になります。3つ目は設定変更と部品交換です。交換の前後では正常パターンそのものが変わるため、学習期間をまたぐと境界が引けなくなります。対策は単純です。欠測区間は補間せず除外し、非稼働区間は稼働フラグで切り分け、大きな設定変更があった日付以降だけを学習期間に取る。この3つを守るだけで、初回の誤報はかなり減ります。

予知保全AIの実装先の選び方｜マネージド終了が相次いだ2026年の現在地

ここが2026年時点でもっとも判断を分ける論点です。数年前の記事が薦めていたサービスは、いま新規では選べません。

マネージド予知保全サービスの提供終了｜3サービスの終了日と代替先

主要クラウドの専用サービスは、そろって畳まれる方向に動きました。2026年8月6日時点の公式告知を整理すると、次のとおりです。

Lookout for Equipmentは終了後にコンソールもリソースも参照できなくなるため、既存利用者には移行期限が迫っています。AWSはIoT SiteWiseへの移行スクリプトをGitHubで公開し、同サービスには2025年7月に多変量の異常検知機能が入りました。Monitronの代替としてAWSが名前を挙げたのはTactical Edge、IndustrAI、Factory AIの3社です。Azure側はMicrosoft Fabricのリアルタイムインテリジェンス、またはOSS版のanomaly-detectorへの移行が案内されています。

マネージド前提で組むときの移行耐性｜データと特徴量を自社に残す

この流れから引き出すべき教訓は、サービス選定の巧拙ではありません。予知保全のマネージドサービスは3年から5年で載せ替えが起きうる、という前提で設計する必要がある、ということです。移行コストを決めるのは、モデルそのものではなくデータ側の資産です。生の時系列データを自社のストレージに保持し、特徴量の定義（どの窓幅で何を計算しているか）をコードとして自社に置き、ラベル済みの故障区間を汎用フォーマットで持つ。この3点が自社側にあれば、推論エンジンの載せ替えは数週間の作業に収まります。逆にベンダーのコンソール上でしか特徴量を定義していないと、終了告知が出た時点で作り直しになります。

内製・受託開発でモデルを持つ判断｜継続運用の体制で分かれる境界

ではフルスクラッチで持つべきか。判断の軸は開発力ではなく、運用を続けられる体制の有無です。予知保全のモデルは作って終わりにならず、設備更新や季節変動のたびに再学習が要ります。社内にデータを見続ける担当を置けないなら、内製は数か月で止まります。判断の目安を置くと、対象設備が数台で故障モードも限られるならマネージドとパートナー製品の組み合わせで足り、対象が数十台以上に広がる、既存の生産管理システムや設備台帳と双方向に連携させたい、モデルの判断根拠を社内基準として説明する必要がある、のいずれかに当てはまるなら自社で持つ設計に寄せてください。センサーデータの前処理から故障予測モデルの実装、再学習の仕組みまでを一貫して外部に任せる場合は、AI予測分析開発・需要予測開発のような受託開発を検討先に入れると、既存システムとの接続まで含めて設計できます。

PoCから本番運用までの工程｜精度指標の決め方と再学習・ドリフト対策

予知保全AIは、PoCで良い数字が出ても本番で使われないまま終わる典型例が多い領域です。工程の切り方で結果が変わります。

PoCの設計｜対象1設備・過去故障2件以上から始める現実的な入口

PoCの対象は欲張らないでください。停止損失がもっとも大きい設備を1台選び、その設備で過去に2件以上の故障記録が残っている期間のデータを使う。この条件を満たさないPoCは、精度を評価する材料がありません。検証すべきは「モデルが異常を検知できるか」ではなく「実際の故障の何日前にスコアが立ち上がったか」です。3日前に立ち上がっても部品調達に2週間かかるなら、その予知は保全計画に使えません。目標値の置き方とデータ準備の順序はAI PoCの精度目標の決め方とデータ準備で詳しく扱っています。

評価指標の決め方｜見逃しと誤報のどちらを許容するかを先に決める

精度は単一の数字になりません。予知保全で見るのは、実際の故障のうち事前に検知できた割合（再現率）と、正常なのに異常と判定した割合（誤報率）の組み合わせです。この2つは片方を上げると片方が悪化する関係にあり、しきい値をどこに置くかで自由に振れます。だから先に決めるべきは目標値ではなく、どちらを許容するかという方針です。停止すると数千万円の損失が出る基幹設備なら、点検の空振りを許容して再現率に寄せる。予備機がある設備なら、誤報を抑えて現場の信頼を保つ。この方針を保全部門と合意しないまま数字だけ追うと、運用開始後に必ずもめます。

本番移行後の再学習とドリフト｜季節変動と設備更新への追従の設計

本番で最初に起きるのは、季節による誤報の増加です。夏場の外気温上昇で軸受温度の分布が変わり、冬に学習したモデルが逸脱と判定します。1年分で学習できていれば緩和されますが、設備更新や生産品目の変更のたびにパターンは動きます。運用設計としては、月次でスコア分布と誤報件数を確認し、分布が明らかにずれたら再学習を回す仕組みを最初から組み込んでください。学習データのバージョン管理とモデルの入れ替え手順を仕組みにする考え方はMLOpsで機械学習の運用を支える仕組みが土台になります。

AI予知保全を見送るべき設備の条件｜失敗する導入に共通する2つの型

導入しないほうがよい設備は確実に存在します。ここを曖昧にしたまま全社展開すると、投資は回収できません。

AI予知保全を見送るべき3つの条件｜定期交換で足りる設備の線引き

次のいずれかに当てはまる設備では、AIによる予知保全を見送る判断が妥当です。

• 部品の寿命がばらつかず、定期交換で突発故障がほぼ起きていない設備
• 予備機や冗長構成があり、1台停止しても生産が止まらない設備
• 停止1時間あたりの損失が、センサー敷設と開発・運用の年間費用を下回る設備

3つ目の判断は数字で出せます。停止1時間の損失額に年間の想定停止時間を掛けた金額が、投資額の上限です。この額がセンサー費用と開発費、そして毎年かかる運用工数の合計を下回るなら、そこにAIを入れる理由はありません。予知保全は全設備に広げるものではなく、損失が集中する数台に絞って初めて成立します。

失敗する導入に共通する2つの型｜誤報放置と保全計画に繋がらない検知

失敗の型は2つに集約されます。1つ目は誤報の放置です。運用開始直後は誤報が出るものですが、閾値の調整と除外設計を回さずに放っておくと、保全員は3か月ほどでアラートを見なくなります。こうなると本物の兆候も一緒に無視され、システムは形だけ残ります。2つ目は、検知が保全計画に接続されていないケースです。ダッシュボードにスコアは出るのに、誰がいつ点検指示を出すかが決まっていない。これでは検知の意味がありません。導入時に決めるべきは、スコアが基準を超えたときの一次確認者、確認の期限、点検を実施するかどうかの判断者。この3点を運用ルールとして文書化してから、本番に載せてください。

よくある質問

予知保全にAIを入れる検討でよく挙がる質問に、実務の判断基準から答えます。

予知保全AIと異常検知AIは何が違いますか？

異常検知は技術の名前で、予知保全は保全業務の方式の名前です。予知保全を実現する手段のひとつとして異常検知が使われる、という関係にあります。異常検知は製造ラインの外観検査や不正取引の検知にも使われるため、範囲としては予知保全より広くなります。逆に予知保全の側から見ると、異常検知だけでなく故障の種別分類や残存耐用寿命の推定も選択肢に入るため、こちらも異常検知に収まりません。

故障データが1件も無くても予知保全AIは組めますか？

組めます。正常に稼働していた期間のデータだけで学習する異常検知型を選べば、故障ラベルは不要です。Isolation Forestやオートエンコーダの再構成誤差といった手法が該当し、出力は「普段との違いの大きさ」を表すスコアになります。ただし出力は何が壊れかけているかまでは示さないため、スコアが立ち上がったときの一次確認は人が担う前提で運用を設計してください。運用しながらアラートと実際の点検結果を記録に残せば、それが次の段階の教師データになります。

予知保全AIの精度はどの指標で見ればよいですか？

正解率という単一の数字では判断できません。故障は全データのごく一部しか起きないため、常に正常と答えるだけでも正解率は99%を超えてしまいます。実務では検知できた割合と誤報の割合に加えて、「故障の何日前に検知できたか」という猶予時間で評価してください。部品調達と保全枠の確保に必要な日数より前に立ち上がっているかが判断基準になります。

既存の制御システムのデータだけで学習できますか？

できる場合があります。プロセスヒストリアンやSCADAに数年分の運転データが蓄積されていれば、それが学習データになります。AWSもLookout for Equipmentの入力として、これらのシステムからのデータを想定していました。確認すべきは3点で、記録の粒度（1分値なのか1時間平均値なのか）、保存期間（何年分残っているか）、そして欠測の頻度です。1時間平均しか残っていない場合、軸受の初期異常のように短時間で現れる兆候は捉えられないため、センサーの追加が要ります。

Amazon Monitronの終了後は何を使えばよいですか？

AWSが公式に案内した代替は、Tactical Edge、IndustrAI、Factory AIというパートナー3社の製品です。Monitronは2024年10月31日に新規顧客の受付を終了しており、これから導入する企業は選べません。AWS上で構成するなら、AWS IoT SiteWiseに2025年7月から入った多変量の異常検知機能が中心的な選択肢になります。センサーとゲートウェイをMonitronのような一体型で揃えたい場合はパートナー製品、既存のヒストリアンからデータを引ける場合はSiteWise側で組む、という切り分けが実務的です。

関連記事

• 設備保全とは？予防保全・予知保全・事後保全の違いと製造業の進め方：保全方式の全体像と、どこに予知保全を置くかの整理
• 製造業のDX事例｜工程改善・予知保全・品質・在庫で見る成果指標：予知保全を含むDX施策の成果指標と失敗パターン
• スマートファクトリーとは？定義と5階層の構成要素・投資判断の線引き：設備データを集める基盤側の設計と投資判断