現場エンジニアが主役のRUL予測：Pythonと決定木で挑む「納得できる」予知保全の始め方

導入

「また夜中に呼び出しですか？」

製造現場のエンジニアにとって、突発的な設備故障ほど対応に苦慮するものはありません。生産ラインが止まり、納期へのプレッシャーがかかる中、原因究明と復旧に追われる時間は、大きな負担となります。

経営層から見ればダウンタイムは直接的な利益損失ですが、現場からすれば心身の疲弊に直結する深刻な問題です。「いつ壊れるかが分かれば、もっと計画的に動けるのに」という切実な願いは、実務の現場で共通して聞かれる声です。

現場には、すでに多くのセンサーデータが蓄積されているはずです。温度、振動、圧力、電流値。しかし、それらはCSVファイルとしてサーバーの片隅で眠っていたり、Excelの行数が限界に達して開けなくなっていたりしませんか？

「AIで予知保全」と聞くと、高額な専用ツールを導入するか、データサイエンティストに依頼しなければならないと思われがちです。あるいは、中身のよく分からない「ブラックボックス」なAIが予測を出し、現場が対応に苦慮するのではないかと懸念されているかもしれません。

ここで提案したいのは、現場エンジニアである皆さんが主導権を握り、Pythonという強力なツールを使って、自分たちの手で「設備の寿命」を可視化するアプローチです。

目指すのは、世界最高精度のモデルではありません。まずは動くプロトタイプを作り、現場のベテランが「なるほど、そういうことか」と納得し、実際の保全計画に組み込める「使える」モデルを最速で組み上げることです。難解な数式は脇に置いて、データの裏にある物理現象を読み解いていきましょう。

なぜ「いつ壊れるか」を知るだけで現場は変わるのか

技術的な話に入る前に、少し視座を上げて「なぜRUL（Remaining Useful Life：残存有効寿命）予測に取り組むのか」を整理しておきましょう。これは単なる技術トレンドへの追随ではなく、現場の負担を軽減し、ビジネスの連続性を担保するための戦術です。

TBM（時間計画保全）からCBM（状態基準保全）への転換

多くの現場では、TBM（Time Based Maintenance）が主流です。「半年ごとに部品を交換する」「3000時間稼働したらオーバーホールする」といったルールです。これは管理が楽な反面、まだ使える部品を捨ててしまう「過剰保全」や、交換時期の直前に故障してしまう「ダウンタイム」のリスクを孕んでいます。

一方、目指すのはCBM（Condition Based Maintenance）です。設備の状態（Condition）を監視し、「そろそろ危ない」という兆候を捉えて処置をする。RUL予測は、この「そろそろ」を「あと○日」や「あと○サイクル」という具体的な数値に落とし込む技術です。

RUL（残存有効寿命）予測がもたらすコスト削減

「あと1週間は持つ」と分かっていれば、週末の計画停止に合わせて部品交換をスケジュールできます。緊急発注による高額な航空便輸送費も、深夜残業代も削減できると考えられます。経営層には「コスト削減」として響きますが、現場にとっての最大のメリットは「計画の主導権を取り戻せること」です。設備に振り回されるのではなく、設備をコントロール下に置く。この安心感が、エンジニアの創造性を本来向けるべき改善活動へと向かわせます。

本記事のゴール：高精度なモデルより「使える」モデルを作る

AIプロジェクトでよくあるのは、最初から高い精度を目指して実現できず終わってしまうことです。しかし、実務の現場では「精度70%でも、何もしないよりは良い」ケースも存在します。例えば、「故障の予兆を3日前に検知できる確率が70%」あれば、点検頻度を上げるなどの対策が可能です。

今回は、複雑なニューラルネットワークではなく、解釈しやすい手法を使って、スモールスタートで成果を出す方法をお伝えします。まずは仮説を即座に形にして検証する、プロトタイプ思考で進めていきましょう。

準備編：AIに食わせる「美味しいデータ」の揃え方

AI開発において「ゴミを入れればゴミが出てくる（Garbage In, Garbage Out）」は原則です。しかし、完璧なデータがなければ何もできないわけではありません。既存データで、いかに早く検証サイクルを回せるかを考えましょう。

最低限必要な3つのデータセット（正常、故障、ラベル）

RUL予測を行うためには、教師あり学習のアプローチが一般的です。そのために必要なのは以下の3要素です。

1. 時系列センサーデータ: タイムスタンプ付きの温度、振動、圧力などのログ。
2. 故障イベントの記録: 「いつ故障したか」という正確な日時。
3. Run-to-Failure（故障までの稼働）データ: これが最も重要です。新品またはメンテナンス直後の状態から、徐々に劣化して故障に至るまでの一連のサイクルデータです。

もし、現場で「壊れる前に交換している」ために、故障に至るまでのデータがない場合、RUL予測は困難です。その場合は、まず異常検知（正常からの逸脱検知）から始めるか、一部のラインで意図的に限界まで稼働させるテスト（破壊試験的なデータ収集）を検討する必要があるかもしれません。

「汚いデータ」でも大丈夫？前処理で救えるデータの境界線

「データは欠損だらけで...」と嘆く必要はありません。センサーの一時的な通信エラーによる欠損なら、前後の値から補完（線形補間など）すれば十分使えると考えられます。ノイズに関しても、後述する移動平均処理である程度滑らかにできます。

ただし、「データの意味が変わる変更」があった場合は注意が必要です。例えば、途中でセンサーの取り付け位置を変えた、制御パラメータを変更した、といった場合、それ以前のデータとは連続性がなくなります。こういった履歴情報は、データそのものには残っていないことが多いので、現場のベテランの知見が不可欠になります。

環境構築：Google Colabで始める0円分析環境

社内のセキュリティ規定で自由にソフトをインストールできない方もいるかもしれません。そこで、Webブラウザだけで完結する Google Colaboratory の利用をお勧めします。Googleアカウントがあれば無料で使え、Pythonの主要ライブラリ（pandas, scikit-learn, matplotlibなど）が最初から入っています。

Pythonは「プログラミング言語」ですが、データ分析においては「高機能なツール」として利用できます。Excelでは処理が難しいデータも、Pythonなら高速に処理し、即座にプロトタイプを動かすことが可能です。

ステップ1：データの「健康診断」で傾向を掴む

いきなりAIモデルを作り始めるのは、状態を確認せずに対応するようなものです。まずはデータを可視化（グラフ化）し、設備の「状態」を目で見て確認しましょう。

可視化で見つける「劣化のサイン」

まずやるべきは、センサーデータを時系列の折れ線グラフにすることです。故障した日の数週間前、数日前を見てください。温度が上がっていませんか？ 振動の振れ幅が大きくなっていませんか？

変化があれば、AIはそれを捉えることができる可能性があります。逆に、変化がない場合、そのセンサーデータだけで寿命を予測するのは難しいかもしれません。物理的な劣化とデータがリンクしているかを確認するのが、このフェーズの目的です。

相関分析：どのセンサーが故障に敏感かを見極める

工場には多くのセンサーがありますが、寿命予測に使えるのはその一部です。Pythonを使えば「相関行列（ヒートマップ）」を簡単に描けます。

# 概念的なコード解説：相関行列を描く
import seaborn as sns
import matplotlib.pyplot as plt

# データフレーム（表データ）の相関係数を計算
correlation_matrix = df.corr()

# ヒートマップとして表示
sns.heatmap(correlation_matrix, annot=True)
plt.show()

この図を見ることで、「温度センサーAと圧力センサーBは同じ動きをしている（相関が高い）」といったことが分かります。同じ動きをするセンサーを複数使う必要はありません。情報の重複を省き、モデルをシンプルに保つために、代表的なセンサーを選定します。

特徴量エンジニアリング入門：移動平均と分散の威力

生データ（Raw Data）はノイズが多い場合があります。そこで「特徴量エンジニアリング」という加工を行います。これは、AIにとって扱いやすい形にデータを加工する工程です。

RUL予測で特に有効なのが「移動平均」と「移動分散（標準偏差）」です。

• 移動平均: 過去10分間の平均値などを計算し、ノイズを消してトレンド（上昇傾向など）を浮き彫りにします。
• 移動分散: データの「ばらつき」を見ます。平均値が変わらなくても、故障前には振動のばらつきが大きくなることがよくあります。

# 概念的なコード解説：特徴量を作る
# 過去窓（ウィンドウ）を設定して平均と標準偏差を計算

# 10時点ごとの移動平均
df['sensor_rolling_mean'] = df['sensor_value'].rolling(window=10).mean()

# 10時点ごとの標準偏差（ばらつき）
df['sensor_rolling_std'] = df['sensor_value'].rolling(window=10).std()

このように、単なるセンサー値だけでなく、「値の動き方」をAIに教えることで、予測精度は向上する可能性があります。

ステップ2：解釈可能な「ホワイトボックス」モデルを作る

ここからがいよいよモデリングです。近年はディープラーニング（LSTMやTransformerの最新モデルなど）が注目されていますが、現場導入の第一歩としては決定木ベースのアルゴリズム（Random Forest や XGBoost）を推奨します。

なぜ最初はディープラーニングを避けるべきなのか

ディープラーニングは強力ですが、「なぜその予測値になったのか」を説明するのが非常に困難です。いわゆるブラックボックス問題です。現場に「AIがあと3日で壊れると言っています」と伝えたとき、「根拠は？」と聞かれても、明確な理由を示すのが難しい場合があります。これでは、現場の理解を得ることはできません。

一方、決定木ベースのモデルは「温度が80度を超え、かつ振動のばらつきが一定以上になったから、寿命が近いと判断した」というように、人間が理解できるロジックで説明（解釈）しやすいのが特徴です。

近年、AIの予測根拠を人間が理解できるようにする技術は「XAI（Explainable AI：説明可能なAI）」と呼ばれ、その重要性を増しています。特に製造業、金融、医療などの高リスクな判断が求められる環境では、EU AI Act（人工知能法）などによりAIの説明責任が義務化される動きも進んでおり、コンプライアンスの観点からも無視できません。現場の信頼を勝ち取るためには、単なる予測性能だけでなく、SHAPやLIMEといった特徴量の寄与度を可視化するツールと組み合わせた「納得感」のあるモデル構築が不可欠と言えます。

ランダムフォレスト/XGBoostで挑むベースライン作成

ここでは、XGBoostなどの勾配ブースティング決定木を使います。これは「弱い予測モデル（単純な条件分岐）」をたくさん作り、それらを組み合わせて賢くする手法です。

モデルに学習させるのは、「センサーの特徴量（入力）」と「RUL（正解：故障までの残り時間）」の関係です。

# 概念的なコード解説：モデルの学習
import xgboost as xgb

# モデルの定義（パラメータはデフォルトでもベースラインとして機能します）
model = xgb.XGBRegressor(objective='reg:squarederror')

# 学習実行（X_trainがセンサーデータ、y_trainが残存寿命）
model.fit(X_train, y_train)

# 予測実行
predictions = model.predict(X_test)

コード自体はこれだけです。scikit-learnやxgboostといったライブラリを使えば、わずか数行でAIモデルが動きます。重要なのはコードの複雑さではなく、そこに投入するデータの質と、結果をどのように解釈して現場にフィードバックするかという点です。まずは動くものを作り、検証を繰り返しましょう。

モデル学習の実行とパラメータの基本設定

学習させる際、「過学習（Overfitting）」に注意してください。これは、練習問題（学習データ）だけを暗記してしまい、未知のデータに対応できなくなる現象です。

これを防ぐために、データを以下の3つに分割します。

1. Train（学習用）: モデルを作るためのデータ（過去のデータ）。
2. Validation（検証用）: パラメータ調整や過学習のチェックに使うデータ。
3. Test（テスト用）: 最終的な性能評価に使うデータ（未来のデータと仮定）。

時系列データの場合、ランダムにシャッフルしてはいけません。「過去のデータで学習し、未来のデータを予測できるか」を検証する必要があるため、必ず時系列順にデータを分割するのが原則です。これにより、実際の運用環境に近い条件でモデルの汎化性能を評価することができます。

ステップ3：現場で運用するための「信頼区間」の設定

モデルができたら、現場への適用を考えます。しかし、AIが「あと120時間で壊れます」と予測しても、ぴったり120時間後に壊れるわけではありません。必ず誤差があります。

予測値は「点」ではなく「幅」で見る

予測結果を「点（ピンポイント）」で捉えると、外れたときに「AIは使えない」という印象を与えてしまう可能性があります。予測は「幅（区間）」で捉えるべきです。

「あと100時間〜140時間の間には壊れる確率が高い」という提示の仕方をしましょう。これなら、現場も「念のため100時間経過した時点検しよう」という判断ができます。この幅のことを信頼区間や予測区間と呼びます。

RMSE（二乗平均平方根誤差）の現場的解釈

モデルの精度評価にはRMSEなどの指標が使われますが、これを現場用語に翻訳する必要があります。例えばRMSEが「10時間」だった場合、「平均してプラスマイナス10時間くらいのズレはある」という意味です。

このズレが、業務上許容できる範囲かどうかが重要です。半年に一度のメンテナンス計画に対して10時間のズレは許容範囲ですが、1日3回交換する消耗品に対して10時間のズレは大きな問題となります。現場の状況に合わせて精度を評価しましょう。

アラート閾値の設定：狼少年にならないために

予測されたRULが「残り24時間」を切ったらアラートを出す、という設定をする場合、False Positive（誤検知：壊れないのにアラート）とFalse Negative（見逃し：アラートなしで故障）のバランスを調整します。

安全第一なら見逃しをゼロにすべきですが、誤検知が多すぎると「またAIが騒いでいる」と無視される可能性があります。最初は閾値を緩めに設定し、現場の信頼を得ながら徐々に厳しくしていくのが良いでしょう。

よくある落とし穴とリカバリー策

最後に、実務の現場で陥りやすい点と、その回避策を紹介します。

「データリーク」：未来の情報を学習させていませんか？

最も多いミスがこれです。例えば、特徴量を作る際に「データ全体の平均値」を使って標準化してしまうと、未来のデータ情報が過去のデータに漏れてしまいます（リーク）。

また、故障直前にしか発生しないアラームコードなどを入力データに入れてしまうと、AIは「このコードが出たら故障」と判断してしまい、正解率の高いモデルが出来上がります。しかし、これでは「予知」にはなりません。予測時点ですでに得られている情報だけを使うよう、厳密に管理しましょう。

「ドリフト」：設備の経年劣化でモデルが使えなくなる時

一度作ったモデルが永遠に使えるわけではありません。設備自体が経年劣化したり、季節変動（夏と冬の温度差）があったりすると、データの傾向が変わり、予測精度が落ちていきます。これをコンセプトドリフトと呼びます。

対策としては、定期的に（例えば1ヶ月に1回）最新のデータを使ってモデルを再学習（リトレーニング）させる仕組みが必要です。最初は手動で構いませんが、状況に応じて自動化を検討しましょう。

現場からの「当たらない」という声への対処法

運用開始直後は、どうしても予測が外れることがあります。その時、現場からのフィードバックをどう受け止めるかが重要です。「AIが間違えました」で終わらせず、「なぜ外れたのか」を現場と一緒に検証してください。

データにはない現場の状況が見えてくるはずです。その情報を新たな特徴量としてモデルに組み込めば、AIはさらに賢くなります。この人間とAIの対話ループこそが、より良い保全システムを作り上げるのです。

まとめ

RUL予測は、魔法ではありません。過去のデータという「事実」に基づき、未来のリスクを推論する技術です。

1. 目的の明確化: 現場の負担軽減と計画主導権を取り戻すために行う。
2. データ準備: 完璧でなくてもいい。傾向が見えるデータから始める。
3. スモールスタート: Pythonと決定木モデルで、解釈性を重視して小さく検証する。
4. 運用設計: 誤差を前提とした「幅」のある予測で、現場の運用ルールに適用する。

このステップを踏めば、データサイエンスの専門家でなくとも、現場エンジニアの皆さん自身の力で予知保全への取り組みを始めることができます。まずは手元のCSVファイルをGoogle Colabにアップロードして、グラフを描くところから始めてみませんか？