画面の「20.0℃」は5分前の値。センサーデータの欠測・遅延・重複の見分け方

たとえば、10時に測った「20.0℃」が10時5分に届いたら、画面に表示された時点ですでに5分前の観測です。数値のない欄を0に置き換えると、測れていない状態と、本当に0℃を測った状態も区別できなくなります。

温湿度などの記録・集計を例にします。人命に関わる制御や安全装置は、別の基準で扱います。

10時10分の画面に何を出すかを、二つの架空記録で比べます。この例では、日報は到着の遅れが5分以内、今の表示は測定からの経過が5分以内という別の条件を使います。

観測記録	日報へ採るか	10時10分の表示候補にするか
10:00に測った20.0℃が10:05に届く（R01）	遅延5分なので採用	測定から10分経過しているため使わない
10:09に測った21.0℃が10:09:10に届く（R10）	時刻・値・IDを確認して採用	最新の採用済み測定で、経過1分なので候補にする

表示には測定時刻を添え、いつの温度かを分かるようにします。5分は説明用の設定で、対象の設備や用途に応じて決める条件です。

測定時刻と、届いた時刻は違う

測定時刻はセンサーが観測した時刻、受信時刻は連携先が受け取った時刻です。ここでは業務連携サーバーへの到着を受信とします。機器、ゲートウェイ、クラウドのどこで時刻を付けるかを仕様書に記し、経由地点が複数なら必要に応じて各地点の到着時刻も残します。

機器ID、観測ID、値、単位に加え、測定時刻、受信時刻、測定間隔、時計の同期状態を記録します。機器の設置先や交換履歴は機器台帳へひも付けます。時刻はUTCなどで統一して保存し、表示がJSTならUTC+09:00と明示します。受信順のグラフでは通信の遅れが温度変化に見えるため、時刻が有効な観測を測定順に並べ、欠けた区間は分かるように表示します。

遅延は「受信時刻−測定時刻」、鮮度を判断する経過時間は「判断時刻−測定時刻」です。昨日すぐ届いた値でも、今日の判断には古い値です。時計がずれていれば、差分には通信以外のずれも混ざります。負の遅延を0へ丸めず、元の時刻とともに確認待ちにします。

架空の温度ログを読むための条件

以下は機器T-01を使う想定例です。日付は2026年9月15日、全時刻はJST、測定予定は毎分です。時計同期済みであること、有効範囲が−20〜60℃であることを採用条件とし、値の急変判定はこの例では省略します。範囲内であるだけで実際の設備が正常とは判断しません。

日報は遅延5分以内なら自動採用、5分超なら人の確認待ちとします。現在値は、採用済みの有効な測定時刻のうち最新を選び、判断時点で5分超なら確認待ちにします。未着は予定時刻から5分経過した点検で欠測として記録します。5分はこの記入例に置いた条件です。自社で使う場合は、用途に合わせた時間を決めます。

遅れて届いた値を、どこへ戻すか

R04はR02と同じ観測が再送された行です。この例では「機器ID＋起動区分を含む観測ID」を照合キーとし、キーと観測内容が同じなら日報へ二度加えません。再送ごとに変わる受信時刻は観測内容の一致判定から外します。同じキーで値や測定時刻が違う場合は競合として保留し、新しい受信を無条件に正としません。

R03は10時2分のR02より後に届いた、10時1分の観測です。履歴には測定順で入れますが、最新値を10時1分へ戻しません。最新値の比較からは重複、同期していない時計、範囲外の値を除きます。受信原本と処理結果を分けて残し、同じ入力を再処理しても同じ業務記録を二重作成しない仕組みにします。

「値がない」と「値がおかしい」を見分ける

R05の空欄は、10時3分の予定枠について10時8分まで値が届かなかった記録です。存在しない受信データに値や観測IDを作らず、予定時刻、点検時刻、未着という事実を残します。「通信断が原因」とまではこの点検だけで断定しません。測定の停止予定や間隔変更がある場合は、期待する予定枠も変更します。

R06の0.0℃は値が届いた実測ゼロです。値が届いたかを見れば、実測ゼロと欠測を区別できます。R07の99.0℃は、例の有効範囲を外れた実測値です。機器故障、単位の食い違い、実際の温度変化のどれかは、この行だけでは確定できないため原値を保存して確認します。

10時10分にR08が届いたら、機器と10時3分の予定枠を照合し、その枠の状態を「欠測」から「遅着・確認待ち」へ移します。R05は点検の履歴として残し、別の温度観測として数えません。未着時点の状態を消さず、後から何が分かったかを追えるようにします。

補間を使う場合も原値とは別に保存し、補間方法、対象区間、処理時刻を付けて参考値と表示します。前回値の持ち越しは前回の測定時刻を保ちます。平均には実測件数、欠測枠数、対象期間を添え、補間を含めた集計とは区別します。件数の分母には、その期間に期待した観測枠を使います。

仕事に使える値になったら、次へ渡す

日報への採用と、今の状況を見る表示は別の判断です。R01は遅延がちょうど5分なので日報には採用しますが、10時10分には観測から10分経過しています。最後に届いたR08も7分前の観測です。同時点で現在値の表示候補になるのは、採用済みで測定が最も新しいR10の21.0℃です。表示には「10:09測定・10:10判定」を添え、現在の実測そのものとは呼びません。

新しい受信がなくても経過時間は増えます。表示時や定期処理で鮮度を再判定し、R10も10時14分を超えればこの例の5分条件を外れます。参考値、確認待ち、採用済みを文字でも示し、色だけで区別しないようにします。

使える値がないときは、前回値を参考表示する、担当者が現地確認する、記録の確定を止める、という代替を用途ごとに決めます。日報を締めた後に遅着を採用する場合は、対象期間を指定して再集計し、訂正前後、承認者、理由、版を残します。古い値を採用し直しても、現在値の鮮度は回復しません。検針値を請求に使う場合の訂正やメーター交換の扱いは、検針値の訂正・メーター交換の請求への反映で例を挙げています。

図1　受信・点検記録を保存し、重複と採用条件を照合して業務へ渡す流れ。条件・時刻・判断の履歴を残して再処理します（想定例）。

保留を誰へ通知し、いつまでに判断するかを決めます。開発担当は機器・通信仕様と復旧手段、業務担当は許容時間と確定条件を受け持ち、判断の結果を記録へ戻します。

普段とは違う届き方を試す

検証用：10行の受信・未着点検ログを照合する

表には比較用として、9行の受信と1行の未着点検を抜き出しています。R番号は行を見比べるための番号です。受信した順は、受信時刻の列で追えます。観測IDのB01・B02は起動区分です。R05は実測時刻も観測IDも不明のため空欄とし、予定枠を別に残します。

行・観測ID	測定→受信（JST）	値（℃）	遅延（分）	日報への判断と理由
R01 / B01-0001	10:00:00→10:05:00	20.0	5.00	採用：遅延5分の境界。
R02 / B01-0003	10:02:00→10:02:10	20.4	0.17	採用：時刻・値・IDが有効。
R03 / B01-0002	10:01:00→10:03:00	20.2	2.00	採用：順序逆転。最新を戻さない。
R04 / B01-0003	10:02:00→10:03:20	20.4	1.33	除外：R02と同一観測の再送。
R05 / 空欄	空欄→空欄	空欄	空欄	保留：10:03予定枠を10:08に欠測点検。
R06 / B01-0005	10:04:00→10:04:10	0.0	0.17	採用：実測ゼロ。未取得とは別。
R07 / B01-0006	10:05:00→10:05:10	99.0	0.17	保留：有効範囲外。
R08 / B01-0004	10:03:00→10:10:00	20.6	7.00	保留：再接続後に到着。R05と照合。
R09 / B01-0007	11:08:00→10:08:10	20.8	-59.83	保留：未来の測定時刻。時計を点検。
R10 / B02-0001	10:09:00→10:09:10	21.0	0.17	採用：再起動後の新規ID。

自社の条件を書き込むには、照合用記入シートをダウンロードして使えます。

再起動後の番号と、機器の時刻を確かめる

再起動で連番が戻る機器では、連番だけでは過去の観測と衝突します。R10は起動区分B02を付け、B01のR01と分けます。一方、通信を再接続しただけのR08は元の観測IDを維持します。機器が一意なIDを出さない場合は、採番地点、再送で維持できる情報、判別できない場合の保留手順を先に決めます。

AWSの接続・切断イベントと、センサーの測定を区別する

公式仕様を読む際は、イベントの対象も読みます。AWS IoT Coreの「ライフサイクルイベント」は順序が前後したり重複したりする場合があると説明しています。接続・切断イベントのtimestampはイベント発生のおおよその日時で、センサーの測定時刻ではありません。この記載を、任意の計測データや他社機器の配送保証へ広げないでください。

AWSの接続・切断イベントではversionNumberを順序の推定に利用できますが、値の飛びやリセットがあり、同一接続のConnectとDisconnectは同じ番号です。この番号をセンサー観測の連続番号や、欠測数の根拠にはしません。

まず対象機器の時刻・ID・再送仕様と、通信経路の順序・重複・保持期間を分けて調べます。保存できる期間、再送できる期間、重複を覚えておく期間もそろえます。そのうえで次の入力と期待結果を、採用する機器・経路で試します。下表は、実機でこれから確かめる試験計画です。

ケース	入力・参照行	期待する結果
重複	R02の後に同じ内容のR04	日報は1観測分。再送履歴は残る。
遅着・逆順	R02の後にR03、最後にR08	履歴は測定順。古い値で最新を戻さない。
欠測	10:03枠を未着のまま10:08に点検（R05）	値は空欄。実測ゼロのR06と分かれる。
再接続・再起動	保存していたR08を送信、起動区分を変えたR10	元観測は同じID。新しい起動の観測は別ID。
時計ずれ	R09の未来時刻を入力	負の差分を保持し保留。最新候補にしない。

5分ちょうどのR01に加え、5分1秒なら保留になることも境界試験で確かめます。同一IDで内容が違う場合や、再処理の途中で止めて再開した場合も試します。結果欄には実施日、機器・通信構成、入力、実際の結果、確認者、証跡を残し、未実施は未実施のままにします。

連携の要件をさらに整理するには

認証、再試行、応答不明、復旧手順などAPI連携全体の条件は、API連携の要件｜待ち時間・再送・二重実行で説明しています。センサーの採用条件と、連携処理の完了条件を分けて整理してください。

取得済みのセンサーデータを、既存ツールだけでは業務台帳や判断の履歴につなげにくい場合は、NeoLogicの「IoTデータの業務連携・可視化」をご覧ください。機器の出力例、測定間隔、欠測時の代替、誰が記録を確定するかを相談材料にできます。案内の対象は取得できるデータの受け渡しと可視化で、機器設計・設置工事・通信環境の構築は別条件です。

電波が届かない場所で人が記録する業務もあるなら、端末保存と提出完了を分ける運用が参考になります（圏外での現場入力｜端末保存と同期の確認項目）。

IoTデータの業務連携・可視化を見る

参考出典

• AWS「ライフサイクルイベント - AWS IoT Core」