センサーデータの時刻がずれると何が起きる？設備分析で重要なタイムスタンプ統一

設備データ分析では、振動、温度、電流などの値そのものに注目しがちです。しかし、PLC、IoTセンサー、クラウド、保全履歴など複数のデータを組み合わせる場合、「いつ取得されたデータなのか」も同じくらい重要です。

例えば、保全履歴には設備故障が10:00に発生したと記録されている一方、センサーデータ側の時計が15分ずれていたとします。この状態で10:00直前のデータを「故障直前」として抽出すると、実際の故障とは別の時間帯を分析してしまう可能性があります。

時刻ずれは、単にグラフの位置がずれるだけの問題ではありません。故障前データの抽出、複数設備のイベント順序、異常検知モデルの教師ラベルなど、分析の前提そのものへ影響する場合があります。

本記事では、設備データで発生する時刻の問題を、固定オフセット、クロックドリフト、通信遅延、記録時刻の意味の違いに分け、PLC・IoT・保全履歴を同じ時間軸で扱うための考え方を解説します。

なぜ設備データでは「時刻」が重要なのか

時系列データを統合する際には、タイムスタンプを共通のキーとして利用することがあります。

例えば、ある時刻の振動値に対して、同じ時刻の設備負荷、回転数、生産品種、PLCアラーム、保全履歴を紐付けることで、設備状態を多面的に分析できます。

しかし、システムごとの時計が一致していなければ、本来対応していないデータ同士を結合する可能性があります。

• 故障後のデータを故障前として抽出する
• 正常運転データを異常直前としてラベル付けする
• 設備Aより設備Bが先に変化したと誤認する
• アラームとセンサー変化に関係がないように見える
• 本来存在していた故障兆候を見落とす

ただし、「何秒ずれたら分析できない」という共通の基準があるわけではありません。数週間単位の温度傾向を見る場合と、数秒単位のイベント順序を見る場合では、必要な時刻精度が異なります。

故障記録とセンサーデータが15分ずれた仮想例

説明用の仮想例として、保全履歴に「10:00 異常停止」と記録されている設備を考えます。

分析担当者は故障直前30分を確認するため、09:30～10:00のセンサーデータを抽出しました。しかし、センサー側の時計が実際の時間より15分進んでいた場合、センサーデータに記録された10:00は、実際には09:45に相当します。

この場合、表面上10:00付近を比較して「故障前にセンサー変化はなかった」と判断する前に、各データの時刻が何を表しているのか確認する必要があります。

「時刻ずれ」には4種類ある

設備データの時間が合わない場合、すべてを「時計がずれている」と考えると原因を誤る可能性があります。少なくとも次の4種類に分けて考えると整理しやすくなります。

1．時計が一定時間ずれている固定オフセット

常に15分進んでいる、常に数秒遅れているなど、一定の差が続いている状態です。

原因と補正量を確認できれば一定量を補正できる場合がありますが、タイムゾーン差やイベント定義の違いを時計ずれと誤認しないよう注意します。

2．時間とともにずれが広がるクロックドリフト

開始時にはほぼ一致していた時計が、時間の経過とともに少しずつずれていく状態です。

この場合は「全期間を15分戻す」といった単一の補正では対応できません。複数時点で基準となるイベントを比較し、時間とともに差が変化していないか確認します。

3．通信・バッファリングによる遅延

センサー自体は10:00に正しく測定していても、ネットワーク障害やゲートウェイのバッファリングによって、サーバーへ10:05に届く場合があります。

これはデバイス時計のずれとは別の問題です。データ発生時刻とサーバー受信時刻の両方が残っていれば、両者を区別しやすくなります。

4．記録している時刻の意味の違い

時計自体が正しくても、比較しているイベントが違えば時刻は一致しません。

• PLCアラーム発報時刻
• 設備が実際に停止した時刻
• 作業者が異常を確認した時刻
• 保全担当者が作業を開始した時刻
• 保全管理システムへ記録を入力した時刻

これらはすべて正しい時刻であっても、意味するイベントは異なります。そのため「10:00」という値だけではなく、「何が10:00だったのか」を確認する必要があります。

データ発生時刻とサーバー受信時刻を区別する

設備データ基盤では、一つの値に複数種類の時刻が存在することがあります。

例えばOPC UAでは、値のデータソース側で付与されるSourceTimestampと、サーバーが値を受信した、または値が正しいと認識した時刻を示すServerTimestampが区別されています。SourceTimestampはUTCで扱われ、データ源にできるだけ近い位置で付与することが想定されています（OPC Foundation, 2026）。

この考え方は、OPC UAを利用していない設備でも参考になります。

ネットワーク遅延を含む受信時刻だけを使うと、実際の設備イベント順序とは異なる場合があります。利用可能であれば、分析目的に応じてどのタイムスタンプを基準にするかを明確にします。

PLC・IoT・保全履歴のタイムスタンプをそろえる方法

基準となる時間軸を決める

最初に、各データがどのタイムゾーンを使用しているかを確認します。

クラウドや複数拠点を扱う場合には、保存時の基準をUTCにし、表示時にJST等へ変換する設計が一つの選択肢です。ただし、既存システムをすべてUTCへ変更する必要があるという意味ではありません。

重要なのは、どのタイムゾーンか分かること、同じ基準へ変換できること、元の情報を失わないことです。

時計の同期方法を確認する

NTP（Network Time Protocol）は、ネットワーク上のコンピューター時計を同期するため広く利用されているプロトコルです（Mills et al., 2010）。

より高い時刻精度が要求される計測・制御系では、PTP（Precision Time Protocol）が利用される場合もあります（IEEE, 2019）。ただし、設備分析でどの方式が必要かは、対象現象と要求精度によって異なります。

「NTPとPTPのどちらが高性能か」ではなく、何秒・何ミリ秒程度の差が分析結果へ影響するのかを先に整理することが重要です。

元タイムスタンプを残す

既存データを補正する場合、元の日時を上書きせず、補正前後を分けて残すと検証しやすくなります。

• timestamp_raw：取得元に記録されていた時刻
• timestamp_corrected：確認した根拠に基づく補正後時刻
• correction_reason：補正理由
• correction_offset：補正量

こうしておけば、後から補正方法を変更する場合にも元データへ戻れます。

既存データの時刻ずれをどう確認するか

すでに蓄積されているデータでは、まず複数システムに共通して残っているイベントを探します。

• 設備の起動・停止
• PLCアラーム
• ライン停止
• 電源投入
• 製品切替
• 作業者が記録した保全イベント

同じイベントが各データソースで何時に記録されているかを比較すると、一定のオフセットなのか、時間とともに差が広がっているのかを確認しやすくなります。

あわせて、タイムスタンプの重複、時刻の逆転、不自然な空白、一定間隔からの急な逸脱なども確認します。

ただし、センサー波形同士が似ているからといって自動的に時刻を合わせるなど、高度な補正処理を安易に行うべきではありません。補正根拠を説明できることが重要です。

保全履歴の時刻は「点」と決めつけない

センサーデータは秒単位・ミリ秒単位で記録されていても、保全履歴は人が入力することがあります。

例えば保全記録に「10:00 故障」と記載されていても、実際には「10時ごろ異常に気付いた」「作業開始時刻を記録した」「後から10分単位で丸めて入力した」という可能性があります。

そのため、保全履歴の時刻を常に秒単位で正確な教師ラベルとして扱うのではなく、記録ルールや入力方法を確認します。

特に「故障直前5分」のような短い区間を学習データとして利用する場合、数分の記録誤差がラベルへ大きく影響する可能性があります。一方、数週間単位の劣化傾向を見る分析であれば、同じ時刻差でも影響は小さい場合があります。

時刻補正を行うときの注意点

固定オフセットの原因と補正量が確認できた場合には、分析用データとして補正時刻を作ることができます。

import pandas as pd

df["timestamp_raw"] = pd.to_datetime(df["timestamp_raw"])

# 15分の固定オフセットである根拠を確認できた場合の例
df["timestamp_corrected"] = (
    df["timestamp_raw"] - pd.Timedelta(minutes=15)
)

df["correction_reason"] = "device_clock_offset"
df["correction_offset"] = "-15min"

import pandas as pd

df["timestamp_raw"] = pd.to_datetime(df["timestamp_raw"])

# 15分の固定オフセットである根拠を確認できた場合の例
df["timestamp_corrected"] = (
    df["timestamp_raw"] - pd.Timedelta(minutes=15)
)

df["correction_reason"] = "device_clock_offset"
df["correction_offset"] = "-15min"

このコードは説明用の一般例です。実データについて、見かけ上15分差があるという理由だけで補正してよいわけではありません。

時刻差の原因がタイムゾーン、通信遅延、手入力、イベント定義の違いであれば、単純な一括補正では正しくならない可能性があります。

また、時計ドリフトがある場合は補正量自体が時間によって変化します。期間全体へ一つの補正値を適用する前に、複数時点で時刻差を確認します。

設備データ統合前の時刻チェックリスト

このチェックリストの該当数だけでデータ品質を判定するものではありません。

必要な時刻精度は、設備現象の時間スケール、サンプリング周期、分析目的、複数設備間のイベント順序を扱うかなどによって変わります。

センサーデータと保全履歴が合わない場合は、すぐにセンサーや分析手法を疑うのではなく、まず両方のタイムスタンプが何を表しているかを確認します。時計の固定ずれ、ドリフト、通信遅延、手入力時刻の違いを分けて整理することで、補正可能な問題かを判断しやすくなります。

まとめ

設備データ分析では、「何を測ったか」だけでなく「いつ測ったか」を正しく扱うことが重要です。

PLC、IoTセンサー、クラウド、保全履歴等の時計が一致していなければ、本来対応していないデータを故障前後のデータとして結合する可能性があります。特に短い故障前ウィンドウを教師ラベルとして使用する場合には、数分のずれでも影響が大きくなる場合があります。

一方、時刻問題には固定オフセットだけでなく、クロックドリフト、通信遅延、タイムゾーン、イベント定義の違いがあります。見かけ上の時刻差を一律に補正するのではなく、まず原因を切り分けることが重要です。

既存データを補正する場合も、元タイムスタンプを上書きせず、補正後時刻、補正量、補正理由を別に保持すると、後から検証しやすくなります。

SCI総合研究所株式会社のMIRASENTでは、「センサーデータと故障履歴の時刻が合わない」「PLC・IoT・保全データを統合したいが、どのタイムスタンプを使えばよいか分からない」「既存データを予兆保全へ利用できる品質か確認したい」といった段階から、データ取得方法、タイムスタンプ、設備イベント、保全履歴等を整理しながら分析可能性を検討します。

新しいセンサーやAIモデルの導入を前提とせず、まず既存データが同じ時間軸で比較できる状態かを確認し、必要に応じてデータ整備やPoCの方向性を整理します。

参考文献

• OPC Foundation. 2026. OPC Unified Architecture – Part 4: Services. OPC 10000-4. Version 1.05.07. https://reference.opcfoundation.org/specs/OPC-10000-4
• Mills et al. 2010. Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force. RFC 5905. https://doi.org/10.17487/RFC5905
• IEEE. 2019. IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems. IEEE Std 1588-2019. https://sagroups.ieee.org/1588/public-documents/