機械が壊れる前にAIで知らせる：設備停止と緊急修理のコストをどう減らすか

要点

緊急修理は、計画した修理の何倍もお金がかかります。ラインの停止と納期遅れが一緒についてくるからです。
すべてを一度に予測しようとせず、まずは「前もってわかる」故障をいくつかに絞って始めます。
誰も引き受けない警告には価値がありません。担当者と日時が実際に決まった修理の作業指示書に変える必要があります。

「前もってわかれば手を打てる」故障から始める

すべての故障を事前に知らせられるわけではありません。前ぶれなく突然壊れるものもあります。始めるべきなのは、自社の保全担当者がすでに「こういう音がしたら、あと2週間でだめになる」と言える故障です。こうした知識なら、システムが学び取れます。

開発チーム向け · 技術的な詳細

安全、品質、スループット、コストの観点から設備の重要度（Asset Criticality）を整理し、前兆があって手を打つだけのリードタイムがある故障モードを選びます。たとえばベアリングの振動、温度の上昇、モーター電流の変化です。前兆なく突然起きる損傷には、AIよりも冗長化や予備品の在庫のほうが向いている場合があります。

現場で使えるFMEAを作り、症状は何か、どこで測るか、どの負荷のもとで測るか、警告が出たら何を点検するか、停止を判断するのは誰か、部品の手配にどれくらいかかるかを書き出します。センサーがたくさん付いているという理由で設備を選ぶのはやめましょう。警告によって作業計画を変えられる設備を選びます。

目標：緊急の作業を計画的な作業に変えることです。ダッシュボードの上で故障日を正確そうに予測して見せることは目標ではありません。

状態データと保全データの話を通じさせる

開発チーム向け · 技術的な詳細

センサーのデータには、タイムスタンプ、単位、文脈が必要です。文脈とは回転数、負荷、製品、起動・停止、周囲温度などです。作業指示書の履歴には、症状、原因、見つかったこと、使った部品、実際にかかった時間を記録します。「修理済み」とだけ書かれた記録は、システムの学習には使えません。分析の前に、PLC、ゲートウェイ、CMMSの時計がそろっているかを確認してください。

データ	答えられる問い	よくある間違い
振動・温度	状態がいつ変わったか	負荷と結びつけていない
アラーム・PLCの状態	設備がどのモードにあるか	タイムスタンプがずれている
作業指示書	実際に何が見つかり、何を直したか	故障コードがない
生産の状況	どの製品のときに変化が起きたか	段取り替えを記録していない

故障の記録が少ないなら、異常検知を使って通常の状態との違いを示し、保全担当者に点検してもらいます。根拠もないのにスコアを故障日に読み替えてはいけません。人が判断できるように、トレンドと文脈を表示します。

アラートが作業指示書につながるように設計する

誰も引き受けない通知は、2週間もすれば雑音になります。システムが警告を出すたびに、誰が、いつまでに、何をするのか、やらなければ何が起きるのかに答えられなければなりません。

注視（Watch）、点検（Inspect）、対処（Act）の3段階に分け、それぞれに基準とSLAを決めます。アラートには、設備、症状、始まった時刻、深刻度、証拠、点検方法を示します。保全担当者が確認して認めたときも否定したときも、その理由を記録してしきい値の調整に使います。システムはCMMSとつなぎます。チャットグループにメッセージを流すだけで終わらせないようにします。

開発チーム向け · 技術的な詳細

シャドーモードで始め、すべてのアラートとすべての故障を数えます。システムが警告しなかったものも含めます。適合率（Precision）が低ければチームはアラームに疲れ、再現率（Recall）が低ければリスクは残り、リードタイムが短すぎれば計画が立てられません。そのため、この3つの値を、設備停止時間や保全コストと合わせて見る必要があります。

アラートを生産計画に反映させる前に

保全担当者が証拠を理解し、点検につなげられる
生産部門が、止めるコストと止めずにリスクを負うコストを比べられる
最終的に判断する人がはっきりしている
センサーが途切れたり値がおかしくなったりしたときの手順がある
実際に対応できる部品と人員がそろっている

モデルの精度より、設備の信頼性を測る

開発チーム向け · 技術的な詳細

計画外停止時間、計画保全の比率、MTBF、MTTR、緊急購買、残業、誤報、見逃し、対処に使えるリードタイム（Actionable Lead Time）を追跡します。比較の相手は、似た設備か、稼働時間で補正したベースラインです。アラートの確認とセンサーの保守にかかる費用もコストに含めます。

開発チーム向け · 技術的な詳細

広げるときは、故障モードごとにテンプレートを作ります。同じしきい値を全設備にコピーするのは避けます。校正、データドリフト、運転範囲（Operating Envelope）の変化は、最初のうちは毎月、システムが安定してからはリスクに応じて確認します。新しいモデルのバージョンは、過去データとシャドーモードでの検証を通過してから旧版と入れ替えます。

予知保全がうまくいったと言えるのは、保全担当者の緊急作業が減り、計画が立てやすくなったときです。モデルが一度も「7日以内に故障」と予測しなかったとしても構いません。説明のつく兆候を、点検が間に合うタイミングで出すことのほうが、チームが信じない派手な予測よりも価値があります。

RELIABILITY TIP · アラートを安売りしない

しきい値より先に、アラートの上限（Alert Budget）を決める

点検が必要なアラートを1週間に何件まで受けられるか、チームと合意しておきます。システムがその処理能力を超えて送ってくれば、そこそこ正確でも無視されます。しきい値は最初やや厳しめに設定し、見逃しを記録しながら、故障のコストに合わせて少しずつ調整します。アラームを連発させて保全担当者に我慢を求めるより、このやり方のほうが信頼を保てます。

架空のケース：あるモーター群では、回転数を上げるたびに強い振動の信号が出ていました。以前のモデルは毎朝警告を出していたため、保全担当者は見なくなりました。運転状態のデータを加え、負荷が一定の期間だけで比べるようにすると、アラートは数回に減りました。そのうちの1回では、緊急停止が必要になる前に芯ずれの始まりを見つけています。モデルは新しくしておらず、変えたのは正しい文脈を与えたことでした。

アラートカードに必要な5項目

設備、症状、トレンドという証拠、運転の文脈、次の点検とその実施時期です。最後の項目が欠けていれば、アラートはまだ保全の仕事とつながっていません。

ヒント：保全担当者が「誤報」ボタンを押すたびに、長い記入欄の代わりに4〜6種類の理由から選べるようにします。書類仕事を増やしすぎずに、システムの調整に使える一貫したデータが集まります。

DNA MAKER · SOLUTION BLUEPRINT

知識を、現場で使える問題解決の仕組みへ

問題の核心

アラートがリードタイムに間に合わなかったり、部品がなかったり、保全担当者が実際に使う作業指示書とつながっていなかったりすれば、予測モデルに価値はありません。

段階を踏んだ解決の進め方

重要度と対処に使えるリードタイムから、設備と故障モードを選ぶ
センサー、運転状態、修理履歴のデータを突き合わせてそろえる
横展開の前に、アラートカード、しきい値、フィードバック、CMMSのワークフローを作る

アラートが保全担当者の手元まで届き、対処できる仕事になるようにする

予知保全は、モデルが異常を見つけた時点では終わりません。保全担当者は、何を、いつ点検するのか、そのデータをどこまで信頼できるのかを知る必要があるからです。DNA Makerはお客様の信頼性エンジニアや保全チームと一緒に、故障モード、運転の文脈、対応の手順を洗い出し、実際に使えるアラートカードとワークフローにまとめます。設備の診断を専門家に代わって行うことはしません。専門家の知識がセンサーのデータや作業指示書と一緒に届くようにして、いくつもの画面を開く手間と、担当者のいないアラートを減らします。

仕組みとしては、状態監視ポータル、点検用のモバイルアプリ、時系列データとCMMSをつなぐAIエージェントなどが考えられます。AIエージェントは点検の作業を作成し、保全担当者からフィードバックを受け取り、データとモデルの健全性を見守ります。DNA Makerはお客様のOT・ITチームと一緒に、データフロー、現場のUX、API、エッジ・クラウドのアーキテクチャ、ソフトウェア開発、モデルの監視を設計します。設備のデータはすでにあるのに保全の仕事に生かせていないなら、兆候から判断までのどこに隙間があるのかを一緒に調べ、本格的に投資する前に保全担当者が試せるプロトタイプを作りますので、ご相談ください。

SOFTWARE ENGINEERING GLOSSARY

ソフトウェア開発用語集

この表は、経営層、業務の責任者、開発チームが同じ言葉を別々の意味に取らずに話し合うためのもので、暗記する必要はありません。意味と例に加えて、右端の質問も読んでください。こうした質問から、開発を始める前に隠れていた範囲、リスク、コストが見えてくることがよくあります。

用語	意味	わかりやすい例	開発チームへの質問
Anomaly Detection	通常のパターンと違う値を見つけること	同じ負荷の範囲で、いつもと違う振動を見つける	どんな異常なら、実際の対応につなげられますか？
CMMS	保全作業を管理するシステム	アラートから作業指示書を作る	アラートを作業指示書にするとき、作業の重複をどう防ぎますか？
Threshold	通知を出し始める境目となる値	温度が基準を10分間超え続ける	基準はリスクから決めますか、平均値から決めますか？承認するのは誰ですか？
Time-series Data	時間の順に並んだデータ	毎秒の振動の値	時刻、単位、運転状態はそろっていますか？
Model Monitoring	モデルがきちんと働き続けているかを見守ること	センサーのデータの傾向が変わったら知らせる	モデルやデータの品質が落ちたとき、通知を受けるのは誰ですか？

明日試せること：重要な設備を1グループ選び、それを支えるデータがあるかを確かめる前に、故障モードと対処に使えるリードタイムを書き出してください。センサーの追加から始めるのは避けてください。