製造業の時系列データ異常検知
IoTで実現する仕組み・活用・導入例
IoTミドルウェアで解決
工作機械、センサー、PLC、IO機器。製造現場には、メーカーも通信プロトコルもバラバラな機器が混在しています。それぞれが異なるタイミングでデータを吐き出し、環境によっては、ネットワークに繋がっていない機器も少なくありません。「データを活用したい」と思っても、データ収集後の統合の壁に阻まれてしまう。そんな経験はないでしょうか。
センサーやPLC、各種機器から収集される膨大な時系列データは、現場でバラバラに散在したまま活かしきれていない。
また、「異音がしていたのに、止まるまで気づかなかった」「品質不良の原因が、結局わからないまま再発した」製造現場では、止まらない生産体制を維持していくために、こうした問題に時間をかけて取り組む事が難しいケースも少なくありません。
設備の予知保全や品質異常の早期検知は、多くの製造業が抱える目下の課題ですが、現場データが散在したままでは、異常検知の向上は期待できず、熟練担当者の勘と経験に頼る運用にならざるを得ません。
この記事では、製造業におけるIoTミドルウェアによる時系列データを使った異常検知の仕組み、データをつなぐIoTミドルウェアの役割、そして現実的に取り組める導入の進め方のヒントを解説します。設備の予知保全・品質安定・人手不足といった課題に向き合う方に、ぜひ読んでいただきたい内容です。「異常を検知できる現場」をつくるための、最初の一歩としてご活用ください。
なぜ製造現場で異常検知が求められるのか？
製造現場では、安定した機器の稼働、良質な製品の供給が求められます。突発的な設備故障、繰り返す品質不良、原因不明のチョコ停などは、組織全体のコスト管理、品質管理につながるため、これらの課題は現場だけの問題に留まりません。異常を検知し事前に対策を講じるため、また発生した異常の早期解決には、いつ何が起きたかを正確に把握する必要があります。だからこそ、時系列で整理されたデータが製造現場では求められます。
異常検知とは何を指すのか
『異常』は、通常では観測されない、または以前に観測したデータ群からは予測されていないある特異点もしくはデータ群のことを指します。異常値には、ノイズ、機器の誤作動、通信エラー等の影響、人員的なミスに起因するもの、故障や経年劣化によるデータ兆候の変化、突発的な変異的異常の発生など、様々な要因が考えられます。異常検知とは、通常時のデータ傾向から外れた値や変化を検出し、設備故障・品質不良・工程異常などの兆候を早期に把握するための仕組みです。
製造業で注目される理由
1. 突発停止・品質不良が引き起こすコスト管理の課題
予期しない機器故障などによるライン停止は、機器の最適な稼働率や製品の品質などコストに絡む問題に直接関係します。そのため、稼働監視、エネルギーの異常検知、ライン停止時の早急な要因把握・解決は製造現場に留まらず、組織全体の課題と言えます。
2. 「気が付いた時には手遅れ」が繰り返される
突発的なラインのチョコ停や、気が付いた時には対応が手遅れとなる『異常』への対応として遠隔監視をはじめ、異常を検知した際の機器の制御、異常発生時のログ確認、該当機器の異常データ収集、カメラ録画の確認など、異常の把握、即時対応ができる現場の環境作りへのニーズは高まっています。
3. 予知保全・品質安定化への期待が高まる背景
設備故障の予知保全、品質異常の早期発見は、人手による監視では対応に限界があります。改善が難しいため、原因の解明がされない状態のまま運用体制が続き、現行のサイクルから脱却するのが困難なケースが多々見受けられます。また熟練の技術者による知見の継承、世代交代による課題、属人化が常態となってしまう現場固有の問題、深刻な人手不足など、早急に対応が求められているこれらの課題の解決策として、近年「保全」に対する対応が注目されています。
製造現場で発生する多様な時系列データ
時系列データとは、時間軸で管理されるデータのことです。製造現場では、様々な種類のデータが発生します。多岐にわたるこれらのデータは一定の周期で収集され、設備の稼働監視や異常検知に活用されます。生産データや作業データなど、異なる周期タイミングでも、時系列のデータであれば時間を軸にしたデータ管理が可能です。
| データ種別 | 取得するデータ例 |
|---|---|
| 設備の稼働 | 稼働率・電流・電圧・圧力・振動・速度 など |
| 環境 | 温度・湿度・照度・粉塵・クリーン度 など |
| 品質 | 寸法・重量・硬度・ロット番号・検査データ など |
| 作業 | 人感・侵入、作業時間実績 など |
異なるメーカーの工作機械、センサー、PLC、IO機器、その他、集塵機や散水機といった現場環境特有の機械など、製造業で使用される機器は多岐にわたります。そのためデータの集約には、多様な通信プロトコルやファイルからのデータ取得に対応する必要があります。
異常検知が難しい本当の理由
1. OT側（現場）のデータがバラバラに散在している
『多様なデータがバラバラに散在しておりデータの集約ができていない』
『機種が古くアナログデータの取り込み方がわからない』
『IT側へつなぐ手法がわからない』
データの活用には、現場で取得したデータを人が見てわかりやすいデータとして扱えるようにする必要があります。
そのためには、OT側のデータ環境の整備が必要です。
2. OT領域と IT領域の分断
取得したデータを人が見てわかりやすいデータとして表示、活用するには、OT側のデータを IT側でも取り扱う必要があります。データを意味のあるものとして活用するためにはOTとITのシームレスな連携が重要ですが、工場とIT環境が分断されているために、データを活用できていないケースが多くあります。
3. 製造現場における通信プロトコルの多様性
製造現場では、設備メーカーごとの採用規格や用途に応じた性能要件、導入時期の違い、設備の長期運用、さらには業界ごとに異なる標準規格など、さまざまな要因が存在します。そのため、機器ごとに最適な通信方式が異なり、多様な通信プロトコルが共存しています。また、設備の更新には多大な時間とコストを要することから、こうしたプロトコルの多様性は今後も継続すると考えられます。
以下は、製造における多様な通信プロトコルとそれらを使う機器の例です。
| PLC | 一般的に利用されているメーカー例 |
|---|---|
| 国内 | 三菱電機、オムロン、キーエンス、ジェイテクト、パナソニックなど |
| 海外 | Siemens（シーメンス）、Rockwell（ロックウェル）、Schneider（シュナイダー）など |
| 通信プロトコル | 一般的に対応する機器の例 |
|---|---|
| Modbus RTU シリアル通信 | PLC（シリアルポート搭載モデル） インバータ・モータードライブ 電力メーター・マルチメーター 温調器・調節計 環境センサー（CO₂、温湿度など） バーコードリーダー・スキャナー |
| Modbus TCP | PLC インバータ・サーボドライブ 電力メーター・電力計測器 温調器・調節計 センサー・計測器（圧力、流量、温度など） ビル管理システム（BMS）機器 |
| MQTT | IoTセンサー・エッジデバイス ゲートウェイ機器 スマートメーター 環境モニタリング機器 産業用エッジコンピューター クラウドプラットフォーム（AWS IoT Core、Azure IoT Hubなど） スマートホーム機器 |
| EtherNet/IP | PLC ロボットコントローラー インバータ・サーボドライブ I/Oモジュール・リモートI/O 安全コントローラー（セーフティPLC） バーコードリーダー・ビジョンシステム |
| Bluetooth | スマートフォン・タブレット ウェアラブルデバイス（スマートウォッチなど） ワイヤレスセンサー（BLE搭載） 携帯型計測器・ハンディターミナル ビーコン（位置情報システム） スマートロック・スマートホーム機器 |
| RFID | 電子タグ |
関連記事 こちらもご参照ください。
多様な通信プロトコルに対応
工場設備や各種センサーのデータをITシステムへ連携するには、機器ごとの通信プロトコル対応が不可欠です。弊社はマルチプロトコルに対応し、OTとITをつなぐデータ収集・可視化・エッジ分析基盤を提供します。
OTとITをつなぐIoTミドルウェア
IoTミドルウェアは何をするのか
製造現場「OT側」には、PLCやセンサー、産業用ロボットなど、多様なプロトコル（OPC UA、MQTT、Modbus、 EtherNet/IP等）で動く機器が多くあります。 一方の「IT側」は、ERPやMES、クラウドでのデータ監視、分析基盤など、APIでの通信や、サーバー、各種データベースから情報を取得し動く世界です。
この「ふたつの異なる文化・言語の世界」をつなぐ手段を担うのが、IoTミドルウェアです。
例えば、以下の内容を実行します。
- データ収集：OT機器からの多種多様なプロトコルでデータを吸い上げる
- 変換：バラバラなデータ形式を統一フォーマットに揃える
- ルーティング：「この温度データはファイル出力でローカルに保存、この稼働ログはクラウドへ」と振り分けて外部へ送信する
- バッファリング：ネットワーク断絶時にデータを取りこぼさない（停止した時点から再送）
ただし、その役割は単にデータをつなぐことではありません。設備監視、異常検知、品質改善、予知保全など、「収集したデータを何のために活用するのか」によって、求められる機能や果たすべき役割は異なります。
IoTミドルウェア利用イメージ
つなぐ・ためる・いかす
- 突発故障によるライン停止リスク（予測保全の未整備）
- 各設備の稼働状況が可視化出来ていないために稼働率の最適化が困難
- 手作業による点検・報告・記録が多く、人件費や対応時間が削減できない
製造現場では、OTとITの断絶やマルチプロトコルへの対応の他、このような多くの課題が山積している中、「つなぐ」「ためる」「いかす」を軸に、IoTミドルウェアは、現場データのリアルタイム収集から集約・保存、分析、送信・連携、さらには制御・通知までをシームレスな連携を実現する役割を担うことができます。
データ収集
コレクタ
Modbus TCP／Modbus RTU PLC EtherNet/IP RTSPカメラ連携 MQTT
リソース（稼働マシン状態） 演算（結果データ） カスタム（Python／C言語)
集約・分析・制御
シリアライザ
JSONシリアライザ CSVシリアライザ カスタム（Python／C言語)
ロジック
イベントデータ・トリガ 基本統計 FFT 移動平均
データ変換（配列分解・ビット変換・データ名変更） カスタム（Python／C言語)
Web-API
SQL （Grafana／Excel連携）
送信・連携
エミッタ
MQTT File保存 AWS IoT Core送信 Azure IoT Hub送信
FTP/FTPS/SFTP送信 カスタム（Python／C言語)
アクション
シェルコマンド メール送信 PLC書き込み Modbus書き込み EtherNet/IP書き込み
MQTTクライアント カスタム（Python／C言語)
接続先例
接続先例
クラウド連携 オンプレ連携 BIツール連携 AIツール連携 生成AI・LLM連携
制御例
アラート通知 信号灯点灯 機器のオン・オフ制御など
IoTミドルウェアで異常検知の向上が期待できる理由
注）エッジ処理機能搭載のミドルウェア製品であることが前提です。
1. データ品質の向上
ノイズ除去・データのフィルタリング
デバイス・センサー等から収集される生データにはノイズデータや通信エラー等による外れ値など不要なデータなども多く含まれます。ミドルウェアで、基本統計（中央値など）のフィルタをリアルタイムなデータ収集に適用するなど、データの取捨選択を実施することで、データ判定の基になるデータの品質が上がります。
取りこぼしの補完
通信断などで生じるデータ欠損が連発すると、取得データに偏りが生じます。ミドルウェア側にデータを取りこぼさない仕組み（データのリングバッファ機能など)があれば、データの取りこぼしをカバーし、時系列の連続性を保つことが可能です。
2. データの統合・標準化
異なる機器データの統合
温度・振動・電流などデバイスによって異なるプロトコル（MQTT、Modbus、メーカーの異なるPLCなど）からデータを取得し、JSONやCSVなどの統一フォーマットに変換して集約します。これにより複数センサーから取得したデータ分析が可能になり、単一機器のデータ取得では捉えられない複合的なデータによる異常の検出が可能になります。
時刻同期
デバイスごとのタイムスタンプではなく、ミドルウェアにデータを取り込む時点で機器間の時系列アライメントを揃えます。
3. エッジでの前処理によるコスト・レイテンシ削減
前処理
FFT・移動平均などのエッジコンピューティング機能を搭載したIoTミドルウェアであれば、エッジ側で取得したデータの前処理を行い、データ送信コストの削減、遅延等の課題に対応が可能です。
- クラウドへの転送データ量を削減
- リアルタイム性が要求される異常検知には、エッジ側で迅速な対応を完結
4. コンテキスト情報の付加
負荷情報
デバイス・センサー等から取得する数値データと併せて、設備の稼働状態・環境条件などのデータも時系列で併せて取得すると、「通常の高負荷状態」や「異常な高負荷状態」などを区別しやすくなります。
システム構築へのアプローチ
目的で選ぶ
異常検知の仕組みは「ソリューション／製品」を導入すれば一気に解決するほど単純ではありません。現場の規模、データの種類、処理の場所、目的の違いによって、最適な選択肢は異なります。ソリューションや製品選定の前に、自社の環境をできるだけ正確に把握することが改善の成否を分けます。
異常検知ソリューションの選択肢は大きく分けて3パターンが考えられます。
- 既製品をそのまま使う
- 既製品をベースに、自社環境にあわせて一部カスタマイズする
- フルスクラッチで自社システムを開発する。
既製品を使う場合は、「とりあえず大手の製品なら大丈夫だろうから試してみよう」と飛び込み、後になって「自社の環境に合わない」と気がつくケースもよくあります。だからこそ、自社の「異常検知の位置づけ」を明確にすることが重要です。位置づけが曖昧なままソリューションツールを選ぶのではなく、まずは以下の「7つの問いかけ」で自社の状況を確認してみましょう。
７つの問いかけ
- どこでデータを処理するのか – エッジかクラウドか？
チェックポイント
製造ラインや設備から収集するデータは、処理場所によって要件が変わります｡
- リアルタイム性が求められるか
- 通信環境は安定しているか
- セキュリティ上クラウドに出せないデータはあるか
エッジ処理が向く場合
- ライン停止を即座に防ぎたい
- 通信が不安定な工場
- 機密性の高い製造データを扱う
クラウド処理が向く場合
- 拠点を横断分析
- 大量の履歴データを残したい
- IT運用リソースを抑えたい
- どんなデータが、どれくらい存在するのか？
チェックポイント
センサー値、画像・映像、振動・ログデータなど、異常検知の手法はデータの種類で異なります。また、過去に異常と判定している「モデルデータがどれくらいあるか」によっても、閾値設定の有効性を左右します。
- 時系列データの種別（数値データ、画像データ、データの種類など）
- 異常サンプルの有無
- データ品質（欠損・ノイズ）の状況
- 現場の規模はどのくらいか？
チェックポイント
ライン数、設備台数、拠点数によって、必要なスケーラビリティが変わります。単一ライン向けのPoCで有効だったソリューション構成でも、必要な機器台数の規模によりゲートウェイ機器などのハードウェアの配置は再検討が必要です。
規模感の目安：
- 小規模（〜10台）：既製品で十分対応できることが多い
- 中規模（10〜100台）：既製品＆一部カスタムが現実的
- 大規模（100台〜）：スケール設計を含む開発投資が必要
- 何を「異常」と定義するのか？
チェックポイント
『品質不良の早期発見』『設備の予知保全』『工程の効率低下の検出』
目的によって、どの条件を使うか、何をアラートにするのかが変わります。
「異常を検知したい」という曖昧な定義だけでは、効果的な運用は期待できません。
目的の違い：
- 予知保全：設備が壊れる前に兆候を捉える
- 品質管理：製品の不良を工程内で発見する
- 工程監視：稼働率低下・工程異常をリアルタイムで把握する
- 異常を検知した後、誰が何をするのか？
チェックポイント
例えばアラートが鳴っても、現場が何をすればいいか分からなければ意味がありません。異常検知はあくまで「入口」であり、その後のオペレーション設計とセットで考える必要があります。既存の現場システムやERPなどとの連携が必要なのか等も、事前に確認しシステムを設計する必要があります。
- 誰がアラートを受け取るのか
- どのシステムに通知・連携するのか。
- 誤検知があったときの対応ルールなど、運用ルールとの連携
- 社内の技術リソース
チェックポイント
フルスクラッチでの開発は柔軟性が高い反面、開発・保守コストが大きくなります。
また社内にシステムエンジニアがいない場合、保守を維持できないシステムを作っても運用ができません。
既製品のみでは、自社の特殊なデータ形式に対応できない場合もあります。
- 技術者なし → 既製品 or ベンダー／開発委託の検討
- 部分的なIT人材あり → 既製品＋カスタム開発の併用
- 自社で開発部署／チームがいる → フルスクラッチでの開発も選択肢に
- どこから始めて、着地点はどこか？
最初から全設備・全工程に導入しようとすると、失敗時のリスクは重大です。
「最も課題が明確な1ライン」から始めて、効果を確認しながら展開するアプローチが現実的です。そのために、最初の選択肢が将来の拡張に対応できる設計かどうかも事前に確認しておく必要があります。
段階設計の例
Phase 1
PoCで1ライン
「最も課題が明確な1ライン」から始めて、効果を確認しながら展開する
Phase 2
同種ライン横展開
Phase 3
他工場など拠点で展開を拡張
異常検知の導入を成功させるには、最初に「自社の環境・目的・リソース」を整理することが重要です。
上記の７つのポイントが揃ったとき、最適なアプローチは自然と絞り込まれてきます。
「完璧なシステム」を最初から作ろうとするのではなく、「今の自社に合った最初の一手」を選ぶことが、持続可能な異常検知基盤への近道です。
弊社では、時系列のデータベースをエンジンにしたエッジコンピューティングができる IoTミドルウェア SpeeDBee Synapse（スピードビーシナプス）をご提供しています。
異常検知は「データをつなぐ」
ことから始まる
IoTミドルウエアでデータ収集の基盤を整える
IoTミドルウェア
SpeeDBee Synapse
データを価値に変える！
対応プラットフォーム
- Ubuntu24 (amd64, arm64)
- Ubuntu22 (amd64, arm64)
- RaspberryPiOS (bookworm 64bit)
- Windows11 (64bit 23H2〜)
- Windows Server 2022 Standard (Desktop Experience) 64bit 21H2以上
検証済みのIoTゲートウェイ機器
| オムロン株式会社 | データフローコントローラ DX1 （※ライセンス適用済みでオムロン社から販売） |
| センチュリーシステムズ 株式会社 | MA-Xシリーズ |
| コネクシオ株式会社 | CONEXIOBlackBear |
| 株式会社アットマークテクノ | Armadillo-IoT A9E （※標準のArmadillo Base OSへの移植対応は未実施、Ubuntu22で動作確認） |
| ペンギンソリューションズ 株式会社 | Stratus ztC Edgeシリーズ |
まずはご相談から
御社に合わせた最適なアプローチをご提案します
お気軽にご連絡ください！