設備 稼働ログ 取得を始めても、同じ停止を翌日に再集計すると時間や原因が変わるなら、そのログは改善会議の証拠になりません。タイ工場で停止分析を再現可能にするには、稼働・停止の値を保存するだけでなく、状態遷移を時刻、品質、順序、理由、修正履歴と結び付け、通信断や再送まで含むreplay testをRFP・PoC・FAT・SATの受入条件にする必要があります。
結論：設備稼働ログは「値」ではなく再生できるイベントとして受け入れる
停止時間の円グラフが表示されたことは、停止分析が正しいことの証明ではありません。PLCが停止へ変わった時刻、収集側が受け取った時刻、値の品質、メッセージの順序、停止理由を付けた主体、適用された判定ルールを一つのイベントとして残して初めて、「当時何が起き、後から何が修正されたか」を説明できます。
本記事では最低限のイベント項目として、source timestamp、receive timestamp、quality/status、sequence、reason code、actor、rule versionを提案します。これは特定製品のデータモデルでも、規格が義務付ける唯一の形式でもありません。調達側が停止分析の再現性を受け入れるための実務的な共通言語です。
さらに重要なのは正常通信時の画面ではなく、通信断、設備時計のずれ、遅延到着、重複再送、順序逆転、手修正を試すことです。元データを同じルール版で再生したとき、停止区間と理由が同じになり、差異が説明できることをSATの証跡にします。
タイ工場で今、稼働実績 収集を証拠設計へ進める理由
タイ工業省工業経済局（OIE）の2026年8月27日公表文脈では、2026年7月の製造業生産指数は暫定94.80、前月比マイナス0.94％、前年同月比プラス0.46％です。これは個別工場の成果を示す数字ではありませんが、生産変動を月次結果だけで眺めず、設備イベントまで遡って説明できる運用が必要であることを考える背景になります。
BOIの2026年上期発表では、Smart and Sustainable Industryに132件、約172億THBの申請が報告されています。これは申請額であり、実投資、導入完了、改善効果ではありません。投資が活発な局面ほど、接続台数やダッシュボード画面数ではなく、どの証拠をもって検収し、運用後の変更をどう追跡するかを契約前に決める必要があります。
一般的な生産実績収集の設計は、品目、数量、工程、ロットや作業実績を業務へつなぐ話です。本記事はそこから範囲を絞り、設備状態の遷移が欠落・重複・修正されても停止分析を再現できるかに集中します。また、保全計画システムの周期、点検、作業指示を扱うのではなく、その前提となる停止証跡の品質を扱います。
値保存だけでは停止要因 分析が再現できない五つの理由
1. 一つの時刻で複数の事実を表そうとする
PLCやセンサーが値を観測した時刻と、ゲートウェイやサーバーが受信した時刻は同じとは限りません。通信断中にエッジへ蓄積したデータは、復旧後にまとめて到着します。受信時刻だけで並べれば停止開始が復旧時刻へ寄り、source timestampだけを無条件に信じれば時計ずれを見落とします。
OPC UA Part 4のDataValueはsource timestampとserver timestamp、Good・Uncertain・Badのstatusを扱えます。ただしserver timestampは、そのサーバーが値を認識した時刻であり、分析基盤が受け取ったreceive timestampと常に同義ではありません。どの層の時刻を何と呼ぶかをインターフェース仕様で固定することが第一歩です。
2. 現在値を上書きし、状態遷移を失う
「現在はRUN」というタグを一定間隔で読むだけでは、読み取り間隔の間にSTOPからRUNへ戻った短い遷移を失うことがあります。ポーリングを速くすれば必ず解決するわけでもありません。収集点数、ネットワーク、PLC負荷が変わり、同時刻イベントの順序問題は残ります。
重要なのは、値そのものより「前状態から新状態へ変わった」というイベントを不変の識別子と順序情報で残すことです。現在値テーブルは運転画面に便利ですが、履歴イベントの正本とは分けます。
3. 通信品質を設備状態と誤認する
通信不能を設備停止として埋めると、ネットワーク障害が生産停止に見えます。逆に最後の値を保持してRUN表示を続けると、実際の停止が隠れます。quality/statusを独立して持ち、「状態はSTOP」「品質はUncertain」「受信は遅延」のように別軸で表現しなければなりません。
4. 再送を新しい停止として数える
MQTT Version 5.0にはQoS、セッション状態、メッセージやセッションの有効期限に関する仕組みがあります。しかし輸送上の配送制御だけで、業務上同じ停止イベントを一度だけ数えられるとは限りません。送信側が再起動してsequenceを初期化する場合、別経路から同じイベントが届く場合、アプリケーションが再投入する場合を想定したbusiness-level deduplicationが必要です。
5. 手修正で元の判断根拠を消す
停止理由を現場が後から「材料待ち」へ修正する運用は有用です。しかし元の自動判定を上書きして消すと、翌月にルールを見直す材料がなくなります。修正前後、actor、時刻、理由、承認、rule versionを追加履歴として残します。OPC UA Historical Accessは履歴データ、イベント、修正や監査に関わる能力を扱いますが、実装が自動的に必要履歴を保存する保証ではありません。RFPで保存・出力・再生方法まで問います。
設備 稼働ログ 取得の最小イベントスキーマ
以下は製品依存の必須仕様ではなく、停止分析を再現するために調達側が検討すべき最小案です。名称や型は既存MES、SCADA、データ基盤へ合わせても、意味を削らないことが重要です。
| 項目 | 残す意味 | 受入で確認すること |
|---|---|---|
| source timestamp | 発生源が状態遷移を観測した時刻 | タイムゾーン、精度、時計異常時の扱い |
| receive timestamp | 収集サービスが受信した時刻 | 遅延、通信断、再送を後から識別できるか |
| quality/status | 値の信頼状態 | Good以外をゼロや停止へ暗黙変換しないか |
| sequence | 発生順序と欠番の手掛かり | 再起動、桁あふれ、複数経路時の規則 |
| reason code | 停止理由の管理値 | コード体系、未分類、親子分類、廃止履歴 |
| actor | 生成・判定・修正した主体 | device、rule、integration、personを区別できるか |
| rule version | 適用された判定ロジック | 過去データを当時のルールで再生できるか |
加えてevent ID、equipment ID、previous state、new state、ingest ID、correction linkを実装へ含めると、照合と監査が容易になります。ただし項目を増やすだけでは不十分です。NULL、欠番、重複、時計逆転を許したときの意味と処理をデータ契約として定義します。
状態モデルを先に決め、ログから都合よく推定しない
停止分析の不一致は、収集技術より状態定義の違いから生じることがあります。PLCのRUN信号、モーター電流、サイクル完了、良品排出のどれを「稼働」とするかで結果は変わります。AUTOだが材料待ち、主機はRUNだが下流詰まり、段取り中、計画停止、品質確認待ちを一つのSTOPへ潰すと、改善責任を誤ります。
まず設備、ライン、工程の粒度ごとに状態機械を決めます。各遷移には入口条件、出口条件、優先順位、最小継続条件、親子設備の集約規則を付けます。「複数信号が同時に成立したら安全停止を優先する」などの規則はrule versionの一部です。
ISA-95は企業と制御領域の情報交換を整理するモデルと用語を提供します。Part 1は2025年版が掲載されています。規格名を書くことが自動相互運用を保証するわけではありませんが、設備制御、製造運用管理、企業業務のどの層がイベントの正本を持ち、どこで理由を付与するかを明確にする助けになります。
ISO 22400-1:2014は製造運用管理KPIの概念と用語を扱い、ISOは2025年に確認済みの現行規格としています。ただし、個別工場の停止理由体系やKPI精度を決めるものではありません。KPI名称を先に掲げるのではなく、その分母・分子へ入るイベントの条件と除外を、サンプルログから追跡できるようにします。
source timestampとreceive timestampを使い分ける
時刻設計では「NTPを入れるから大丈夫」で終わらせません。RFC 5905はNTPv4を規定しますが、工場内で達成できる精度や、切断、再起動、設定ミス時の挙動を保証するものではありません。古いPLC、独立装置、ゲートウェイ、仮想サーバーが異なる時刻源を使うこともあります。
RFPでは少なくとも次を質問します。
- 時刻同期の権威源、同期経路、監視担当は誰か。
- 各機器が保持する時刻のタイムゾーンと精度は何か。
- source timestampがないデータへ誰が時刻を付けるか。
- 時計が後退、飛躍、未同期になったときquality/statusをどう変えるか。
- receive timestampはどのサービス境界で押され、再処理で不変か。
- 表示用の現地時刻と保存用の標準時刻をどう分離するか。
分析では、設備での発生順をsource timestampとsequenceから復元し、配送の健全性をreceive timestampとの差から観察します。差が大きいこと自体を設備停止へ変換せず、通信・収集品質の別指標として扱います。
通信断・再送・順序逆転をreplay testで受け入れる
正常運転デモだけではログ基盤の弱点は見えません。PoCとFATではテスト入力を保存し、同じ入力を再投入できるハーネスを用意します。SATでは実ネットワーク、実設備、実運用権限の条件で証跡を取ります。
通信断
接続を意図的に遮断し、エッジバッファが何を保持するかを確認します。復旧後、遅れて到着したイベントが発生時刻の正しい区間へ戻り、受信遅延として識別できることを確認します。保存容量を超えた場合は古いデータを黙って捨てず、gap eventまたは欠落アラームを残します。
重複再送
同じevent IDや同一性判定キーを持つイベントを再送し、停止区間が増えないことを確認します。deduplicationは受信時に削除するだけでなく、何を重複と判断し、どちらを採用したかを監査できるようにします。内容が異なる同一IDは単純上書きせず、競合として隔離します。
順序逆転
STOPの後に発生したRUNが先着するケースを投入します。分析エンジンが一定の待ち時間だけ並べ替えるのか、後着イベントで過去区間を補正するのか、確定済みレポートを再計算するのかを決めます。リアルタイム画面の低遅延と、確定帳票の完全性は同じSLAにしない方が現実的です。
時計ずれ
source clockを前後へずらし、sequenceとreceive timestampから異常を検出できるか試します。時計ずれを自動補正する場合は補正前の値、補正式、補正したactor、rule versionを残します。補正不能ならUncertainとして隔離し、現場が判断できるキューへ送ります。
手修正
停止理由を権限ある利用者が修正し、元の理由、修正理由、actor、承認、rule versionが残るかを確認します。同じ原始イベントを当時のルールでreplayした結果と、現行ルールで再分類した結果を混同しません。
リアルタイム モニタリング 工場画面と確定帳票を分離する
現場表示は速さが重要で、未確定データを含むことがあります。日次会議、顧客説明、原価や保全判断に使う確定帳票は、遅着、修正、未分類を締めた後の版管理が必要です。二つを同じ画面の同じ数字として扱うと、「朝見た停止時間と月報が違う」という不信につながります。
画面にはdata freshness、quality、未同期設備、未分類停止、締め状態を見える形で表示します。赤・黄・緑だけでなく、「何時点まで受信済みか」「速報か確定か」「再計算予定か」を示します。リアルタイム値は上書き可能でも、根拠となるイベントと帳票版は不変または追記型で管理します。
確定処理は、対象期間、適用rule version、理由コード版、除外条件、実行actor、出力ハッシュを一つのmanifestとして残すと再現しやすくなります。翌月にルールが変わっても、過去帳票を当時の条件で説明できます。
RFPで設備稼働ログ取得を比較可能にする質問
製品名や通信プロトコルだけを比較すると、提案各社が異なる前提で回答します。RFPでは「保存できますか」ではなく、失敗時にどの証跡を出せるかを質問します。
| RFP質問 | 必須回答・証跡 | 不十分な回答例 |
|---|---|---|
| 状態遷移の一意性をどう担保するか | event ID、sequence、再起動時規則、重複判定 | MQTTを使うので重複しない |
| 二つの時刻をどう保持するか | source/receiveの定義、時刻源、異常処理 | サーバー時刻で統一する |
| 通信断時に何が起きるか | バッファ、満杯時動作、再送、gap evidence | 復旧後に自動送信する |
| 品質不明値をどう扱うか | status mapping、隔離、表示、帳票除外 | エラー値は保存しない |
| 理由コードを誰が付けるか | 自動・手動のactor、承認、版管理 | オペレーターが選ぶ |
| 過去を再生できるか | raw export、rule package、manifest、比較結果 | 履歴画面で確認できる |
| 修正履歴を出せるか | before/after、actor、理由、承認、時刻 | 管理者なら編集できる |
| セキュリティをどう保つか | 権限、ログ、遠隔接続、更新、退役 | ファイアウォールがある |
NIST SP 800-82 Revision 3は、OTの性能、信頼性、安全性を考慮しながらセキュリティを扱います。ログ収集を理由に制御ネットワークへ無制限の双方向接続を持ち込まず、ゾーン、最小権限、監視、復旧をリスクに応じて設計します。2025年1月公表のSecure by Demand共同ガイドも、OT所有者が調達時にloggingなどの問いを投げる考え方を支えます。ガイド名や準拠表明ではなく、設定画面、出力例、テスト結果を証拠として求めます。
PoCは画面評価ではなく破壊的なログ評価にする
PoCのゴールを「三台つながり、ダッシュボードが動いた」にすると、正常系しか評価できません。対象設備は少なくてもよいので、状態定義、時刻、品質、順序、再送、修正、再生まで閉じた証拠ループを作ります。
PoC開始時にgolden inputを準備します。設備シミュレーターまたは安全に取得した匿名ログで、期待する状態区間、停止理由、欠落、重複、時計異常を定義します。ベンダー出力を期待値と機械比較し、不一致を分類します。差が出たとき画面を人が見て「だいたい合う」と判断するのではなく、event ID単位で説明できることを確認します。
PoC終了時に残すべき成果物は、接続デモではなく、データ辞書、状態遷移表、reason code表、時刻方針、異常テスト入力、期待結果、実結果、未解決差異、次ゲート条件です。このパッケージをRFP付属資料へ昇格させれば、本番提案の比較可能性が上がります。
FATで確認すること：配送前に再現性を証明する
FATでは実設備を完全再現できない場合があります。それでも、データ処理の決定論性と異常処理は供給者環境で試せます。
- 同じ入力と同じrule versionで、同じイベント区間と理由が生成される。
- 入力ファイル、設定、ソフトウェア版、rule version、出力、差分が一式で保存される。
- 重複、欠番、逆順、時計逆転、Bad/Uncertain、未知reason codeを投入できる。
- バッファ満杯、サービス再起動、ネットワーク再接続後の挙動を記録できる。
- raw eventと補正後eventを別にexportできる。
- 権限外の修正が拒否され、その試行がログに残る。
- FATで代替した設備・ネットワーク条件がSAT再試験項目へ紐付く。
「FAT合格」は全機能が完了したという意味ではなく、出荷してもSATで検証可能な状態であることです。代替条件を曖昧にせず、SATで閉じるowner、期限、証拠形式を記録します。
SATで確認すること：実工場の時計・通信・運用を証拠化する
SATは正常値が流れた瞬間では終わりません。実際のPLC、ゲートウェイ、ネットワークセグメント、サーバー、ユーザー権限、シフト引継ぎを使い、工場固有の故障モードを検証します。
SAT evidence gate
- RFPの各要求IDをテストケースへ追跡する。
- PoC/FATの代替条件を実設備条件で再試験する。
- 通信断、再送、順序逆転、時計ずれ、手修正を実行する。
- raw log、processed event、dashboard、確定帳票を同じevent IDから照合する。
- 同じ入力・同じrule versionのreplayで同じ結果になることを確認する。
- 差異はpassへ丸めず、原因、影響、owner、暫定策、再試験条件を残す。
- 運用者がログexportと証跡パック作成を自力で再現できて初めてacceptとする。
受入署名の添付には、テストケース、入力、システム版、設定、時刻同期状態、rule version、reason code版、raw export、処理後export、比較結果、例外一覧、承認者を含めます。スクリーンショットだけでは後日再計算できません。機械可読ファイルとmanifestを必須にします。
ドカ停 分析とチョコ停分析で同じ罠を避ける
長い停止は目立つため、開始・終了の欠落が一件あるだけで集計影響が大きくなります。短い停止は件数が多く、ポーリング間隔、デバウンス、最小継続条件、再送重複の影響を受けやすくなります。どちらも単純なduration順ランキングだけでは不十分です。
ドカ停 分析では、区間境界、計画・非計画の区分、親子設備の影響、復旧後の再停止を確認します。チョコ停では、信号チャタリング、同じ原因の連続発生、装置間の波及、理由未入力を確認します。二つの分類閾値は工場が決める管理ルールであり、外部の一般値を無条件にコピーしません。閾値を変えたらrule versionを更新し、過去結果を勝手に上書きしません。
停止理由のParetoは「多い原因」を示しますが、ログ品質が悪ければ収集しやすい原因が上位になります。未分類率、Uncertain期間、遅着件数、欠番、手修正件数をデータ品質指標として停止時間と並べます。改善会議では設備原因と計測原因を分けてownerを割り当てます。
運用開始後の変更管理と監査
設備追加、PLC改造、reason code変更、ネットワーク更新、ソフトウェア更新は、停止分析の意味を変える可能性があります。変更申請には影響設備、イベント項目、rule version、後方互換性、replay回帰試験、切戻しを含めます。
ログ保持では、raw、normalized、classified、corrected、reportedの層を区別します。容量削減でrawを早く消すなら、どの問い合わせに答えられなくなるかを事業側が承認します。バックアップがあることと、replay可能なことも同義ではありません。設定、ルール、参照マスタ、実行環境が復元できるかまで試します。
遠隔保守やベンダーアクセスは、時間制限、承認、最小権限、操作ログ、終了時失効を定義します。セキュリティログと生産イベントを混ぜず、相互参照できるIDを持たせます。異常な時刻変更や設定変更が停止分析へ影響した場合、誰が何をしたかを説明できます。
調達・実装・運用の役割を曖昧にしない
| 役割 | 主な責任 | ゲートで提出する証拠 |
|---|---|---|
| 工場責任者 | 利用目的、停止定義、accept/stop判断 | 要求承認、例外承認、受入署名 |
| 生産・保全 | 状態、理由、復旧作業、現場検証 | 状態表、理由表、シフト試験記録 |
| OT | PLC、時計、ネットワーク、エッジ | 接続表、同期状態、通信断試験 |
| IT/Data | 保存、権限、処理、replay、export | schema、manifest、比較結果 |
| 品質・監査 | 修正、版、追跡性、保持 | audit trail、承認履歴、保持方針 |
| 調達 | RFP、契約成果物、支払条件 | 要求回答表、未達と支払の連動 |
| SIer/vendor | 実装、試験、文書、教育、是正 | FAT/SAT証跡、as-built、教育記録 |
SIerに「正しい稼働率を出す」責任だけを渡しても、工場側が停止定義や理由ownerを決めなければ完成しません。一方、ベンダーが内部仕様をブラックボックスにすると、工場はrule versionやreplayを検証できません。双方の成果物と意思決定権をRACIだけでなく、受入証跡と結び付けます。
実装ロードマップ：接続台数ではなく証拠ゲートで進める
第一段階では対象工程を限定し、状態モデルとイベントスキーマを合意します。第二段階で正常・異常のgolden inputを作り、PoCでreplay差分を閉じます。第三段階でRFPに証跡要件を載せ、FATで処理の決定論性、SATで実工場条件を確認します。第四段階で確定帳票と変更管理を運用へ引き渡します。
進捗指標は「接続済み設備数」だけにしません。状態定義承認済み、異常ケース実行済み、差異解決済み、export再生可能、現地担当者が証跡作成可能という完了条件を使います。設備台数が増えても証拠ゲートを満たさなければ、次の展開へ進めません。
多言語工場では、画面表示をタイ語にしてもevent ID、equipment ID、reason codeは言語非依存にします。説明文は翻訳してよい一方、コードと版を共通に保つことで、日本本社、タイ現場、SIerが同じ停止を参照できます。
まとめ：停止分析の価値は再計算できることではなく再現して説明できること
設備 稼働ログ 取得の成否は、ダッシュボードが動くかでは決まりません。source timestampとreceive timestampを分け、quality/status、sequence、reason code、actor、rule versionを状態遷移イベントへ結び付けます。通信断、時計ずれ、再送、順序逆転、手修正をreplay testへ入れ、同じ入力とルールで同じ停止区間を再現できることをPoC、FAT、SATの証拠にします。速報画面と確定帳票を分離し、変更後も当時の判断を説明できる履歴を残すことで、停止分析は改善、保全、投資判断に使える共通基盤になります。
TOMAS TECHでは、特定製品を決める前の段階から、設備イベントスキーマ、RFP質問票、PoCの異常ケース、FAT/SATのreplay証跡まで整理できます。既存の稼働ログで停止時間が合わない、次期IoT基盤の受入条件を固めたい、といった検討段階でもお問い合わせください。
FAQ：設備稼働ログ取得と停止分析の受入
設備 稼働ログ 取得では何を最低限保存すべきですか？
状態遷移にsource timestamp、receive timestamp、quality/status、sequence、reason code、actor、rule versionを結び付けることを推奨します。実装ではevent ID、equipment ID、前後状態、修正リンクも有効です。項目名より、欠落・重複・修正時の意味を決めることが重要です。
稼働実績 収集と設備稼働ログはどう違いますか？
稼働実績収集は数量、工程、品目、作業など業務成果を広く扱います。設備稼働ログは、その根拠となる状態遷移、時刻、品質、順序に焦点を当てます。両者は連携しますが、同じレコードへ無理に統合せず、event IDやequipment IDで追跡できるようにします。
停止要因 分析でsource timestampだけでは不十分ですか？
source timestampは発生時刻の復元に重要ですが、設備時計がずれていたり、通信断後に遅着したりします。receive timestamp、sequence、quality/statusと組み合わせることで、設備の出来事と配送の問題を分けて説明できます。
MQTTのQoSを使えば重複排除できますか？
MQTTの配送機能は重要ですが、業務上同じ停止を一度だけ数える保証と同義ではありません。event ID、送信元、sequence、内容などによるアプリケーション側の同一性ルールと、再送replay testが必要です。
ドカ停 分析では何を受入試験すべきですか？
停止開始・終了の境界、計画・非計画区分、親子設備の集約、通信断をまたぐ区間、復旧後の再停止を確認します。長時間停止は一件の境界誤りの影響が大きいため、raw eventから帳票まで同じevent IDで追跡します。
リアルタイム モニタリング 工場画面と月報の数字が違ってもよいですか？
速報と確定の違いとして管理され、差の理由を説明できるなら成立します。画面にはfreshness、quality、締め状態を示し、月報には適用ルール、理由コード版、除外条件、実行履歴を残します。説明できない差は受入未達です。
FATとSATのreplay testは何が違いますか？
FATでは保存済み入力を使い、処理の決定論性、異常処理、exportを供給者環境で確認します。SATでは実PLC、ネットワーク、時計、権限、現場運用で同じ故障モードを試し、FATの代替条件を閉じます。
手修正を許すと監査性が下がりませんか？
上書きだけなら下がります。修正前後、actor、理由、承認、時刻、rule versionを追記履歴として保持し、raw eventを不変にすれば、現場知見を取り込みながら監査性を保てます。
参照した一次・公式情報
- Thailand OIE, July 2026 MPI context — https://www.oie.go.th/view/1/Home/en-us
- Thailand BOI, 1H 2026 Smart and Sustainable Industry applications — https://www.boi.go.th/index.php?_module=news&from_page=press_releases2&language=en&page=press_releases_detail&topic_id=139075
- OPC UA Part 4, DataValue — https://reference.opcfoundation.org/specs/OPC-10000-4/7.11
- OPC UA Part 11, Historical Access — https://reference.opcfoundation.org/specs/OPC-10000-11
- ISA-95 Standard — https://www.isa.org/standards-and-publications/isa-standards/isa-95-standard
- ISO 22400-1:2014 — https://www.iso.org/cms/%20render/live/en/sites/isoorg/contents/data/standard/05/68/56847.html
- NIST SP 800-82 Revision 3 — https://csrc.nist.gov/pubs/sp/800/82/r3/final
- MQTT Version 5.0 — https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html
- RFC 5905, NTPv4 — https://www.rfc-editor.org/info/rfc5905/
- Secure by Demand OT procurement guide — https://www.cisa.gov/sites/default/files/2025-01/joint-guide-secure-by-demand-priority-considerations-for-ot-owners-and-operators-508c.pdf
