予知保全 導入事例｜タイ工場の90日PoC・RFP実践ガイド

予知保全 導入事例を調べる目的は、派手な削減率を自社の稟議書へ貼ることではありません。公表事例から「どの設備を選び、何を基準値にし、どの故障モードを、どの信号で捉え、誰が行動し、効果をどう承認したか」を読み解き、自社で受け入れ可能な90日PoCとRFPへ変換することです。本稿では、タイ工場の工場長、保全部門、生産技術、IT/OT、購買、経理が同じ判断表を使えるよう、事例比較からFAT・SAT、KPI、TCO・ROIまでを一つの流れにします。

予知保全 導入事例から最初に得るべき結論

Siemensが公表するBlueScope、グローバル自動車メーカー、Sachsenmilchの事例には大きな成果が記載されています。しかし、3事例の本当の共通点は数値の大きさではありません。いずれも、単にセンサーを設置してダッシュボードを見たのではなく、異常の兆候を担当者が確認し、計画停止や部品交換などの保全行動へ変えています。

したがって、買うべきものは「高精度AI」だけではなく、次の閉ループです。

1. 対象設備を重要度と実行可能性で選ぶ。
2. 稼働、停止、負荷、品種、保全履歴のベースラインを固定する。
3. 予測したい故障モードと観測可能な兆候を結ぶ。
4. 既存PLCデータを優先し、必要な場合だけ振動・温度・電流などを追加する。
5. アラートに根拠、優先度、担当、期限を付ける。
6. 点検・作業指示・結果をアラートへ戻す。
7. 合意済みの反実仮想と計算式で効果を検証する。

この7段階のうち一つでも欠けると、PoCは「グラフが見えた」で止まります。逆に、故障を一度も予知できない90日間でも、データ品質、アラート再現、対応手順、効果計算が受け入れられれば、次の投資判断に使えるPoCになります。

予知保全 導入事例3件を比較する

これらはすべてSiemensが公表したベンダー事例・顧客発言です。第三者監査済みの業界平均ではありません。BlueScopeについてSiemensの顧客事例ページは、1,950時間の内訳をオーストラリア1,200時間、その他の国750時間と示していますが、この記事では合算値を自社の削減率へ換算しません。Siemens BlueScope事例

匿名の自動車メーカーについて、Siemensの現行事例ページは10,000台超、3か月未満のROI、ダウンタイム損失の大規模削減を記載しています。別のSiemens公式ブログでは100種類の機械、650人超の技術者・保全担当者も記載されています。ここで学ぶべきなのは「3か月で必ず回収できる」ではなく、既存データ、共通の設備分類、利用者教育、複数拠点の運用標準がスケールに必要だという点です。Siemens自動車メーカー事例

Sachsenmilchについては、Siemensの2025年6月の発表が、ポンプの寿命末期を早く見つけ、計画交換へ変えたことを説明しています。低い6桁という金額はSachsenmilchの技術責任者による発言として掲載されたものです。通貨換算や「ポンプ1台当たりの標準効果」は作りません。Siemens Sachsenmilch発表

WEF Lighthouseの数値も「その拠点のその用途」に限定する

World Economic Forum（WEF）のGlobal Lighthouse Network playbookには、LG Electronics Changwonの予知保全用途で設備ダウンタイム50%、Bosch Automotive Changshaの用途で保全費25%という影響値が掲載されています。これらも、その拠点の変革ストーリーと用途に結び付いた値です。タイ工場のPoC目標を機械的に「停止50%削減」「保全費25%削減」にしてはいけません。WEF Lighthouse playbook

ベンチマークは「可能性を示す材料」、PoCの目標は「自社のベースラインから承認可能な変化を測る約束」と分けます。

事例比較を自社のDo/Buy判断へ変える5つの質問

1. その数字の分母は何か

「停止を1,950時間回避」と聞いたら、対象期間、対象拠点、対象設備、停止時間の定義、計画停止の扱い、推定と実測の区別を確認します。「50%削減」なら、削減前の時間、比較期間、生産量・品種・操業日の差を確認します。分母がない数字は、方向性の参考にはなっても投資計算には使えません。

2. 反実仮想は誰が承認したか

予知保全では「警告がなければ故障していた」と証明するのが難しい場合があります。そこで、ベアリング交換後の分解所見、振動傾向、温度、潤滑状態、メーカー所見、過去の同様故障、残存寿命推定を証拠として残し、保全責任者と経理が回避損失の計上ルールを事前承認します。ベンダーだけが回避額を決める方式は避けます。

3. 警告から作業まで何が起きたか

最も重要な質問です。異常スコアが上がっただけではダウンタイムは減りません。誰が確認し、何時間以内に現場を見るか、どの測定で再確認するか、部品をどう確保するか、どの停止枠で交換するか、作業後に何を測るかまで確認します。

4. 既存データと追加センサーの割合はどうか

自動車事例のように既存データを利用できる設備もあれば、Sachsenmilchのように振動計測を追加する設備もあります。PLCの電流、速度、トルク、温度、アラーム、運転モードが使えるなら、まず品質と文脈を評価します。故障モードに必要な物理量が無い場合だけ追加します。

5. 導入後の運用主体は誰か

ベンダーが毎週分析を報告するサービス型か、工場が日々判断する内製型かで、必要な教育、SLA、権限、費用が変わります。Do/Buy判断では、モデル精度だけでなく、夜間・休日の対応、タイ語・英語・日本語の連絡、担当交代、設備追加、契約終了時のデータ移行を比較します。

Step 1：対象設備を「重要度×検知可能性×行動可能性」で選ぶ

予知保全 システムのPoCを全設備へ広げるのは得策ではありません。最初の候補は、故障影響が大きく、兆候を観測でき、警告後に行動できる設備です。次の項目を5段階などで評価してもよいですが、点数より根拠を残します。

安全保護を予知保全で置き換えてはいけません。監視は保護層を補助するものであり、非常停止、インターロック、保護リレー、法定検査を省略する根拠にはなりません。必要な変更は正式なリスク評価とManagement of Change（MOC）で管理します。

対象候補としては、連続運転のポンプ、ファン、ブロワー、コンプレッサー、ギアボックス、コンベヤーモーターなどが考えられます。ただし、設備種類ではなく故障モードで選びます。同じポンプでも、キャビテーション、ミスアライメント、軸受劣化、シール漏れ、閉塞では必要な信号と対応が異なります。

Step 2：ベースラインを先に固定する

効果検証が失敗する最大の理由の一つは、導入前の状態が曖昧なことです。最低限、次をDay 30までに凍結します。

• 対象設備ID、部品階層、設置場所、ラインとの関係。
• 稼働、待機、段取り、故障停止、計画停止、品質停止の状態定義。
• 生産品種、速度、負荷、温度、季節、シフトなどの運転文脈。
• 直近の停止履歴、故障記録、点検、部品交換、作業時間。
• センサー/PLCタグ、単位、サンプリング、時刻源、品質フラグ。
• KPIの分子、分母、除外、締め時点、承認者。

「ダウンタイム 削減」を測る場合、予定停止を含むか、上流待ちを除くか、短停止を何秒から数えるかを決めます。設備が停止してもラインがバッファで生産を続けた場合、設備停止時間と生産損失時間は異なります。両方を分けて記録します。

保全計画システムの設計と接続する場合は、点検周期、作業指示、部品、技能、停止枠のマスターも同時に確認します。予知保全の価値は、警告を「実行可能な仕事」へ変えられるかで決まるからです。

Step 3：設備 故障 予知を故障モード仮説に分解する

「AIが故障を予知する」は要件ではありません。要件は、どの部品の、どの劣化を、どの観測量と確認方法で判断するかです。

DOEのO&M Best Practices Guideは、振動監視が回転機械のアンバランス、偏心、ミスアライメント、共振、機械的緩み、ローター接触、すべり軸受、転がり軸受などの診断に利用できると説明しています。これは「振動センサーを1個付ければ全て分かる」という意味ではありません。センサー方向、固定、測定点、周波数帯域、サンプリング、回転数、負荷が適切であることをFAT/SATで確認します。U.S. DOE O&M Best Practices Guide

Step 4：既存PLCを優先し、振動センサー 設備診断を必要箇所へ追加する

既存PLCやドライブに、運転/停止、速度、トルク、電流、温度、アラーム、バルブ状態が残っている場合、それらは故障兆候を運転文脈と結ぶ有力なデータです。ただし、次を確認せずに取得を始めてはいけません。

• 読取専用権限であること。
• 許可タグ、読取周期、同時接続、PLC負荷の上限。
• ネットワーク分離、アカウント、証明書、ログ、更新責任。
• PLC時刻と収集時刻の差、通信断時のバッファと再送。
• スケーリング、単位、品質フラグ、タグ変更履歴。
• 制御ロジック・安全機能へ書き込まない構成。

古い設備では外付けセンサーが必要な場合があります。老朽設備のIoTレトロフィットで扱うように、クランプ電流、外付け振動、表面温度などをread-only監視として追加できます。しかし、設置位置と固定方法が変われば値の意味も変わります。センサー個体ID、方向、位置写真、締結方法、校正、交換履歴を設備マスターへ結びます。

状態基準保全システムへつなぐ際も、絶対閾値だけでなく、運転モード別ベースライン、傾向、複数信号、確認点検を組み合わせます。低負荷時と高負荷時の振動を同じ母集団で比較すると、正常な負荷変化を異常と誤認します。

Step 5：アラートを作業指示へ変える

アラート画面の完成をPoC完了としないでください。各アラートには次を持たせます。

重要なのは、誤報を削除しないことです。誤報、重複、既知イベント、データ不良、対応不要を分類し、閾値やルールの改善へ戻します。「現場が無視した」ではなく、根拠が弱かったのか、通知が多すぎたのか、部品が無かったのか、権限が無かったのかを分けます。

NISTのPHMCプロジェクトは、堅牢なセンシング、診断、予知、制御のために、実装、検証、妥当性確認、性能指標、参照データ、意思決定支援が必要だと説明しています。予知保全PoCも「モデルを作ったか」ではなく「判断可能な情報を再現し、現場で検証できるか」を評価します。NIST PHMC

30・60・90日のPoCゲート

Day 0〜30：対象・ベースライン・データ品質ゲート

Day 30の目的は、予知を当てることではありません。何を測り、どの条件で比較し、データを信頼できるかを受け入れることです。

• 対象設備、故障モード、責任者、除外範囲が承認済み。
• 資産ID、タグ、センサー、単位、時刻、運転モードが対応している。
• 欠測、重複、時計ずれ、範囲外、センサー脱落の検出ができる。
• ベースライン期間と比較条件が承認されている。
• 安全・制御変更が監視PoCから分離され、必要なMOCが完了している。
• KPIと効果計算式の所有者が決まっている。

ゲート判定は「継続」「条件付き継続」「設計変更」「停止」です。センサーの位置が不適切なら、AI調整を続けず設置を直します。設備IDと作業履歴が結べないなら、モデル追加よりマスター整備を優先します。

Day 31〜60：アラートから作業までのゲート

実故障を待たず、過去波形、許可された模擬信号、センサー取り外し、通信断、閾値越えの再生などで、端から端まで試験します。危険な故障を意図的に発生させてはいけません。

• アラートが設備、故障モード、根拠、優先度とともに届く。
• タイ語/英語/日本語の担当者が、決めた時間内に確認できる。
• 確認結果が作業指示または監視継続の判断へ変わる。
• 夜間、休日、担当不在時のエスカレーションを再現できる。
• 誤報、重複、欠測、再送の扱いが記録される。
• 作業前後のデータと所見が同じ事象IDへ戻る。

Day 61〜90：運用・経済・安全の投資ゲート

Day 90では、精度一つで判定しません。技術、運用、経済、セキュリティ、安全の証拠を束ねます。

90日で故障が起きなければ、無理に「回避損失」を計上しません。信号品質、再生試験、運用時間、アラート処理工数、導入TCOを確定し、故障頻度の不確実性を感度分析へ残します。

予知保全 システムRFPに必須の項目

RFPは製品機能一覧ではありません。受入証拠を明確な契約条件へ落とすための要求仕様として、最低限、以下を求めます。

1. 目的・範囲・除外

• 解決する停止・保全課題と経営KPI。
• 対象設備、部品、故障モード、拠点、言語、シフト。
• 安全制御、PLC書込み、自動停止などPoC外の範囲。
• 90日後の拡張、延長、終了の判断者。

2. データとセンサー

• 既存PLC/SCADA/ドライブ/CMMSの接続方式と読取制約。
• 振動、温度、電流等の測定点、方向、範囲、サンプリング、校正。
• timestamp、quality、sequence、欠測、重複、再送の仕様。
• 資産、運転モード、品種、作業履歴とのコンテキスト結合。

3. 分析と説明可能性

• 閾値、ルール、統計、機械学習の役割分担。
• 学習期間、更新、バージョン、変更承認、ロールバック。
• アラートに表示する根拠と推奨確認。
• 誤報・未検知の記録、レビュー、改善手順。

4. ワークフローと連携

• アラート確認、承認、作業指示、完了、再評価の状態遷移。
• CMMS/ERP/メール/モバイル等のインターフェース。
• 夜間・休日・多言語の通知とエスカレーション。
• API、データ出力、監査ログ、事象IDの保持。

5. OTセキュリティ・可用性

• ネットワーク構成、通信方向、アカウント、最小権限、証明書。
• パッチ、脆弱性、SBOM、ログ、バックアップ、復旧、災害対策。
• 通信断、電源断、クラウド断でのバッファと自動回復。
• インシデント連絡、責任分界、リモート接続手順。

6. 所有権・費用・終了

• 生データ、特徴量、モデル、設定、作業所見の所有権と利用権。
• 初期費、年額、センサー、工事、通信、教育、支援、追加設備の単価構造。
• 契約終了時のデータ・設定出力、削除証明、機器撤去、移行支援。
• FAT/SAT不合格時の是正、再試験、費用負担。

FATとSATで受け入れる内容

FAT：現地設置前に再現できるか

Factory Acceptance Testでは、可能な限り実機と同じタグ、センサー、ゲートウェイ、分析、連携設定を使います。

• タグ/センサーと設備階層のマッピング。
• 単位、スケーリング、timestamp、quality、sequence。
• 正常、閾値越え、欠測、固定値、ノイズ、重複、順序逆転の再生。
• 通信断中のバッファ、復旧後の再送、二重計上防止。
• アラート根拠、優先度、通知、承認、作業指示連携。
• ユーザー権限、監査ログ、設定変更、バックアップ/復元。
• CSV/API等のデータ出力と契約終了時の可搬性。

「画面が開く」だけでは合格にしません。入力、処理、通知、作業、履歴、出力を事象IDで追えることを証拠にします。

SAT：タイ工場の運転条件で使えるか

Site Acceptance Testでは、現地の電源、ネットワーク、設備、品種、速度、シフト、言語、作業許可の条件を含めます。

• 設置位置、方向、配線、盤、ラベル、as-built図面。
• PLC負荷と制御影響が許容範囲で、書込み経路が無いこと。
• 実運転モードとデータの対応、負荷変化時の基準。
• 電源断、ネットワーク断、再起動後の自動復旧。
• 現場担当者によるアラート確認、点検、作業指示、完了登録。
• 誤報、既知イベント、センサー異常、欠測の分類。
• KPI計算と日次・週次レビューを購買側で再計算できること。
• 教育、手順書、保守、問い合わせ、エスカレーションが運用可能なこと。

KPIは「モデル」より「閉ループ」を測る

予測モデルのprecision、recall、リードタイムも重要ですが、真値ラベルが弱い段階では数字が安定しません。点検所見と交換部品の確認を蓄積し、ラベル品質を上げます。NISTIR 8012が示すように、PHMにはデータ収集・分析、データ管理、訓練、相互運用性を含む幅広い課題があります。単一の精度指標へ縮めないことが重要です。NISTIR 8012

TCO・ROIは自社の変数で計算する

相場金額を記事から埋めるのではなく、RFPの見積と社内原価を次の式へ入れます。

初期TCO ＝ センサー・計測器 ＋ ゲートウェイ・ネットワーク ＋ 連携・設定 ＋ 設計・工事 ＋ FAT/SAT・教育 ＋ OTセキュリティ・安全対応 ＋ 初期データ整備

年間TCO ＝ ライセンス・ホスティング ＋ 校正・電池・交換 ＋ 保守サポート ＋ ルール/モデル保守 ＋ 通信・データ保管 ＋ 社内運用工数 ＋ 追加教育

検証済み年間便益 ＝ 承認済みの回避ダウンタイム価値 ＋ 検証済みの部品・外注・点検工数削減 ＋ 承認済みの品質・エネルギー便益 − 誤報対応や新たな障害による費用

年間純便益 ＝ 検証済み年間便益 − 年間TCO

単純回収期間 ＝ 初期TCO ÷ 年間純便益

期間NのROI ＝（期間Nの累計検証済み便益 − 期間Nの累計TCO）÷ 期間Nの累計TCO

年間純便益がゼロ以下なら、単純回収期間を表示しません。分母を無視して「回収不能」を負の年数で示すのは誤りです。また、低位・基準・高位の感度分析を行います。故障頻度、警告成功率、回避可能時間、損失単価、年間費用を変え、どの仮定で投資判断が逆転するかを示します。

BlueScopeの1,950時間、匿名自動車メーカーの3か月未満、Sachsenmilchの低い6桁を、この式へ直接代入してはいけません。それらは事例企業の公表成果です。自社では、自社の停止分類、自社の限界利益、自社の残業・廃棄・復旧費、自社の承認ルールを使います。

予知保全の依頼先を比較する評価表

大手製品、専門診断会社、設備メーカー、SIer、内製にはそれぞれ長所があります。製品名で先に決めず、自社設備の故障モード、既存データ、運用能力、必要なSLAに合わせます。複数社へ同じ受入シナリオを提示すると比較しやすくなります。

よくある失敗と防止策

「全設備へセンサー」を目的にする

台数は導入量であって成果ではありません。重要度、故障モード、行動可能性で対象を絞り、価値が確認できた設備パターンだけ展開します。

正常データだけでAIを学習し、故障を説明できない

異常検知は開始点になりますが、運転モード、品種、洗浄、段取り、センサー異常との区別が必要です。現場所見をラベルとして戻します。

アラートがメールで終わる

受信者、期限、確認項目、部品、停止枠が無ければ行動できません。作業指示と事象IDで結びます。

効果額をベンダーだけで計算する

営業資料としては速くても、経理監査に耐えません。PoC開始前に工場と経理が計算式、証拠、承認者を決めます。

PoC後の費用と終了条件がない

本番の設備追加、利用者、保存期間、API、支援、モデル保守、校正、撤去を含めてTCOを比較します。データ出力と削除も契約に含めます。

FAQ：予知保全 導入事例をPoCへ変える疑問

予知保全 導入事例の削減率を自社目標に使えますか？

可能性の参考にはできますが、そのまま目標へ転用しないでください。対象設備、母数、期間、停止定義、稼働条件、費用範囲、反実仮想が異なります。自社ベースラインから低位・基準・高位を作り、Day 30で計算規則を承認します。

予知保全 システムは既存PLCだけで始められますか？

故障モードに必要な情報があり、品質・時刻・負荷文脈が十分なら可能です。運転、電流、トルク、温度、アラームなどを先に評価します。必要な物理量が無い場合は外付けセンサーを追加します。PLCへの書込みは監視PoCの範囲から分離します。

振動センサー 設備診断では何個付ければよいですか？

設備台数だけでは決まりません。対象部品、故障モード、測定方向、軸受位置、回転数、構造、測定帯域、配線・無線条件で決めます。ベンダーには測定点ごとの根拠、位置図、FAT/SAT試験を求めてください。

設備 故障 予知の精度は何%を求めるべきですか？

単一の精度目標より、故障モード別のprecision、recall、検知リードタイム、誤報、確認工数、閉ループ率を組み合わせます。真値ラベルが少ない初期は、過去データ再生と点検所見の蓄積を重視します。

ダウンタイム 削減は90日で証明できますか？

故障頻度によります。実故障が起きなければ、回避時間を創作しません。データ品質、再生試験、アラート対応、作業連携、運用工数、TCOを確定し、実故障効果は継続計測または感度分析に残します。

FATとSATの違いは何ですか？

FATは現地設置前に、タグ、センサー、計算、障害、通知、権限、出力を再現する試験です。SATはタイ工場の実設備、負荷、電源、ネットワーク、シフト、言語、作業手順で端から端まで使えるかを確認します。

90日後に本導入しない選択も成功ですか？

はい。対象の兆候が測れない、行動時間がない、TCOが便益を上回る、安全・運用条件が整わないと証拠で分かれば、停止または設計変更は妥当な成果です。続けることではなく、不確実性を減らすことがPoCの目的です。

まとめ：事例の数字ではなく、受入可能な判断ループを導入する

予知保全 導入事例は、成果の可能性と実装の選択肢を知る材料です。BlueScopeの1,950時間超と53回、グローバル自動車メーカーの10,000台超と3か月未満、Sachsenmilchのポンプ事例はいずれもSiemens公表値であり、自社への保証ではありません。タイ工場では、設備選定、ベースライン、故障モード、既存PLC/センサー、アラート、作業指示、効果検証を30・60・90日のゲートへ落とし、RFPとFAT/SATで証拠を受け入れることが重要です。TCO・ROIは相場や他社の削減率ではなく、自社の見積、履歴、損失単価、承認規則で計算します。

TOMAS TECHでは、まだ製品やセンサーを決めていない段階から、タイ工場の設備選定、故障モード整理、既存PLCデータ確認、90日PoC、RFP、FAT/SAT受入まで相談できます。「事例は集めたが自社の稟議と仕様に変換できない」という段階でも、お問い合わせページからご相談ください。

参考資料

• Siemens：BlueScope predictive-maintenance customer story
• Siemens：global automotive manufacturer case
• Siemens：Sachsenmilch press release
• NIST：Prognostics, Health Management, and Control
• NISTIR 8012：Standards Related to PHM for Manufacturing
• U.S. DOE：O&M Best Practices Guide, Release 3.0
• World Economic Forum：Global Lighthouse Network playbook