デジタルスレッド — システムをまたいでも途切れない«同じ名前»
デジタルスレッドとは、データを1か所に集めることではありません。 分散したシステムが同じ対象を同じ名前で呼び、その対象間の関係と時間をたどれるようにすることです。集めるだけではデータスワンプになり、名前がつながっていれば、分散していてもスレッドになります。
この記事では、スレッドを識別・関係・時間の3本に分け、それぞれがどこで途切れ、どのようにつなぐのかを技術的に整理します。例はPlantPulseプラットフォームの実装に基づいていますが、論点はあらゆる工場、あらゆるスタックに当てはまります。
MES・ERP・ヒストリアン・CMMSの連携を担当するエンジニア、工場のデータモデルを設計する方、そして「データはすべて揃っているのに、なぜ答えが出ないのか」を経験した方。あわせて製造AI — 工場データがモデルに求めるものもご覧ください。
1. デジタルスレッドとは何か、何ではないか
1つの製品が設計され、工程が決まり、作業指示として作成され、検査を受け、設備が故障して保全を受けます。各段階は異なるシステムに記録されます。デジタルスレッドは、それらの記録を逆方向にたどれる糸です。
「このロットの不良率がなぜ上がったのか」という問いをスレッドで解くと、次のようになります。
불량 로트 ─(어느 작업지시?)─▶ 워크오더 ─(어느 설비, 언제?)─▶ 설비 · 시간 구간
─(그때 그 설비의 신호는?)─▶ 태그 시계열 ─(상류는?)─▶ 공급 설비 · 유틸리티
─(그 설비의 정비 이력 · 절차서는?)─▶ 문서
各矢印が、システム境界を越える1回の結合です。1つでも途切れると、問いはそこで止まり、人が複数のExcelファイルを開いて目視で突き合わせることになります。
| 混同されやすい用語 | 違い |
|---|---|
| デジタルツイン | ツインは1つの対象の状態モデルです（このポンプは今どうなっているか）。スレッドは対象間と時間をつなぐ参照です（このポンプは何に供給し、どの作業指示で使用され、その時に何があったか）。ツインが複数あっても、スレッドがなければ互いを知らない孤島です |
| データレイク | レイクは保存です。すべてのデータを1か所に集めても、IDが異なれば結合できません |
| 統合プラットフォーム | 1つの製品がすべての機能を担うことと、複数のシステムが同じ名前を使うことは別です。スレッドは後者です |
2. どこで途切れるのか
現場でスレッドが途切れる形態は、ほとんどが次の4つのいずれかです。
| 途切れる形態 | 例 |
|---|---|
| 名前が異なる | 同じポンプをSCADAではP-101A、CMMSではPUMP_101_A、ERPでは資産番号400123と呼ぶ |
| 関係がない | 階層（どのラインに属するか）はあるが、フロー（何に供給するか）と依存（どのユーティリティに依存するか）がどこにも記述されていない |
| 時間がずれる | 設備の時計・サーバーの時計・記録時刻が異なり、回線が切断後に復旧すると、遅延データが一度に到着する |
| コピーが分岐する | 設備マスターをシステムごとにコピーした結果、一方で設備を移動しても、もう一方には反映されない |
4番目が最も厄介です。コピーは当初は同一なので問題が見えず、分岐した後はどちらが正しいかを判定する根拠がありません。
3. 1本目 — 識別：正本は1つ、残りは派生
原則は1つです。マスターデータの正本（SSOT）を1か所に置き、その他すべての表現をそこから派生させます。 派生物はいつでも再作成できるため、分岐しても判定できます。正本が優先されます。
PlantPulseでは、PostgreSQLメタストアがその正本です。エンタープライズ・サイト・資産ツリー・タグ・アラーム設定・コマンド定義がここにあり、以下で説明するグラフ・トピックパス・AIが参照する構造は、すべてこれを読み取って生成される派生物です。
外部IDは«マッピング列»で受け取る
他のシステムのIDを自システムのIDに置き換えてはいけません。2つのシステムが、それぞれ異なるルールでIDを生成するためです。代わりに、自システムのIDは自システムのルールに従い、相手側のIDを別途記録する列を設けます。
| エンティティ | 自システムのID | 相手システムのID |
|---|---|---|
| 顧客 | customer_id — 英字・数字・_のみ | external_customer_id（MES・ERP） |
| 製品 | 製品ID | 外部製品ID |
こうすれば、ERPがコード体系を変更しても自システム側の結合は1つも壊れず、マッピング列を修正するだけで済みます。
人が使う呼称もIDに変換する
「3ラインのコンプレッサー」はIDではありません。人が使う名前を正本のIDに解決する段階を別途設ける必要があります。PlantPulse AIが質問を受けると、最初に行うのがこの処理です（search_domains）。この段階を誤ると、その後の分析がどれほど正確でも、別の設備についての正確な回答が返されます。
4. 2本目 — 関係：階層だけでは足りない
階層は«どこにあるか»に答える
ISA-95階層はスレッドの骨格です。
Enterprise ─ Site ─ Area ─ Line ─ Equipment ─ Tag ─ 값
このツリーがあれば、「3ラインの全設備」「サイト単位のOEEロールアップ」といった問いに答えられます。PlantPulseのKPIロールアップがライン・エリア・サイト・エンタープライズ単位で集約されるのも、このツリーに沿っているためです。
そして、メッセージングのアドレスもこのツリーから生成されます。 UNS（Unified Namespace）のMQTTトピックは、階層パスをそのまま使用します。
pp/{site_id}/{area_id}/{line_id}/{equipment_id}/{tag_id}/point
トピック名を見るだけで、値がどこから来たかが分かります。サブスクライブ側が別途照会しなくてもコンテキストが付随します。つまり、スレッドがメッセージ内に組み込まれているということです。
タグを別の設備へ移動すると、そのタグのMQTTトピックが変わります。旧トピックをサブスクライブしていた外部システムは、エラーを出さず、静かに値を受信できなくなります。階層を変更する前に、そのパスをサブスクライブしているシステムがないか確認する必要があります。そのため階層は、最初は慎重に設計し、その後は必要最小限に変更します。PlantPulseでは、トピックパスをUNS画面で事前に確認し、コピーできます。
方向を持つ関係は«何に影響するか»に答える
「この設備が停止すると、どこまで止まるか」は階層だけでは分かりません。同じラインにあるからといって互いに供給しているとは限らず、別エリアのエアコンプレッサーがライン全体を停止させる場合もあります。そのため、階層とは別に方向を持つ関係を定義します。
| 関係 | 意味 | たどると分かること |
|---|---|---|
FEEDS | 上流から下流へ流れる | 下流方向：停止の影響範囲・上流方向：品質異常の原因候補 |
DEPENDS_ON | 電力・エア・冷却などのユーティリティに依存する | 1つのユーティリティが停止したとき、どの設備が同時に停止するか |
PRODUCES | 何を生産するか | 設備から製品へ |
製品側にも同じチェーンを構築します。製品ルート（製品が通過する単位工程の順序）→ 単位工程（工程の定義と所属設備）→ 接続図（設備間のフローと依存関係）です。工程画面の「この工程を使用する製品」が読み取り専用なのは、製品ルートから導出された値だからです。2か所で個別に記述できるようにすると、コピーが分岐します（第2節の4番目）。
グラフは派生物である
関係をたどる問いにはグラフが便利です。しかし、グラフDBを第2の正本にすると、第3節の原則が崩れます。設備マスターが2か所に存在することになり、同期パイプラインがスレッドの最も弱い部分になります。
PlantPulseでは逆の方式を採用しています。
- グラフはプラットフォーム内のインメモリRDFモデル（Apache Jena）であり、メタストアを読み取って全体を再作成します。 同期用のストレージはありません
- 再作成するのは、照会時にTTL（デフォルト10分）を超過していた場合です（
semantic.graph.refresh.minutes）。複数の照会が同時に発生しても、再作成を行うのは1つだけで、残りは直前のモデルを受け取ります - トレードオフは明確です。登録直後の設備は、次回の更新までグラフに存在しない場合があります。 その代わり、グラフが正本から分岐したまま固定化されることは、構造上ありません
同期方式のコピーが誤っている場合、いつまで誤ったままなのか分かりません。 定期的に再作成する派生物は、誤っていても最大1周期までです。スレッド設計では、この違いが重要です。遅延は待てば解消しますが、分岐は人が見つけなければ解消しません。
5. 3本目 — 時間：結合キーとしての作業指示
識別と関係は、何が、どこにあるかをつなぎます。しかし、工場での問いにはほぼ必ずいつが含まれます。「そのロットを製造したとき」「故障前の2週間」などです。
ワークオーダーが時間軸の結合キーになる
作業指示（ワークオーダー）は、スレッドの中で特別な位置を占めます。1件のワークオーダーが設備・製品・顧客・担当者を同時に参照し、さらに計画開始・終了時刻と目標数量が紐づきます。つまり、1つのワークオーダーがそのまま
「この設備の、この時間帯の時系列は、この製品・この顧客に属する」
という結合条件になります。ワークオーダー単位のOEEを計算できることも、設備画面で「この設備のワークオーダーのみ」に絞り込めることも、この結合によるものです。逆に、ワークオーダーなしで時系列だけが存在すると、値は大量にあっても、その値が何を製造していたときのものかが分かりません。
保存された状態と導出された状態を分ける
時間が関係すると、状態は2種類に分かれます。
| 例 | どこにあるか | |
|---|---|---|
| 保存された状態 | 待機・進行中・一時停止・完了・異常終了 | データベース |
| 導出された状態 | 遅延（開始予定を過ぎても開始していない）・キャンセル（開始せずに終了予定を過ぎた） | 画面が現在時刻を基準に計算 — データには存在しない |
導出された状態を保存しないのには理由があります。「遅延」を保存すると、誰がいつその状態を解除するのかという新たな問題が生じ、その更新が一度でも遅れると、データが事実と異なる状態になります。その代わり、APIやDBでDELAYを検索しても存在しません。 スレッドを通じて外部システムへ状態を渡す場合は、導出ルールもあわせて渡す必要があります。
発生時刻と到着時刻は異なる
エッジは回線が切断されると、値を内部に蓄積し、復旧後にまとめて送信します。値が欠落しない代わりに、数時間前の値が今到着することになります。スレッドで時間を基準に結合するときは、必ず**発生時刻（event time）**を使用します。到着時刻で結合すると、復旧直後のワークオーダーに関係のない値が紐づき、切断中のワークオーダーは空のまま残ります。
6. 値はグラフに入れない — ポインターを入れる
スレッドをグラフで表現すると、時系列値までグラフに格納したくなりますが、格納してはいけません。時系列は際限なく蓄積し、「1つのタグの一定期間」という単位で読み取られるデータなので、その用途に特化したストレージ（時系列DB）に格納する必要があります。
代わりに、グラフのタグノードは、自身の値がどこにあり、どのように読み取るかを示します。
| プロパティ | 意味 | 例 |
|---|---|---|
seriesKey | 時系列照会キー | タグID |
seriesStore | どのストレージのどのテーブルか | 時系列ストレージ識別子 |
seriesTool | どのツールで読み取るか | get_tag_history |
lastValue・lastTimestamp | 最新値のスナップショット | 照会せずに«現在»を確認可能にする |
seriesToolは興味深い位置づけです。グラフが**データだけでなく«読み取り方»**まで保持するため、グラフをたどった側（人でもAIエージェントでも）が、次に呼び出すツールをグラフから直接取得できます。 設備のタイムラインも同じ方式（timelineKey・timelineStore）で参照します。
これはスレッドの一般原則でもあります。スレッドはデータを移動させるのではなく、データへの経路をつなぎます。
7. 標準は«境界»で使用する
UNS・Sparkplug B・OPC-UA・AAS（Asset Administration Shell）などの標準は、スレッドをシステムの外部へ公開するための共通言語です。
| 標準 | 何を標準化するか | PlantPulseでの利用 |
|---|---|---|
| UNS（MQTT） | 階層パスをトピックアドレスとして使用 | 階層からトピックを生成・プレビュー |
| Sparkplug B | MQTTペイロードと状態（birth・death） | エッジで有効化して使用（デフォルトは無効） |
| OPC-UA | 設備情報モデルとアクセス | ドライバ・標準UI（:12780） |
| AAS V3 | 資産の«デジタル銘板» — サブモデルとして技術情報をまとめる | 標準UI（:8091） |
標準を内部モデルとして使用しようとすると、多くの場合は不利になります。標準は複数企業が合意した最大公約数であるため、各工場固有の関係（何が何に供給するか）をすべて表現できず、標準が改訂されるたびに内部モデルが影響を受けます。内部では自社の正本を使い、外部には標準で公開する。境界で変換する方が、スレッドは途切れにくくなります。
8. AIはスレッド上でのみ正確に動作する
言語モデルに「3ラインのコンプレッサーは最近どう？」と尋ねた場合、モデルが行う処理は、最終的にはスレッドをたどることです。
① 「3라인 압축기」 → 설비 ID 식별
② 이 설비의 상류 · 하류 · 의존 관계 (그래프)
③ 태그 노드의 seriesTool 로 이력 조회 시간 (포인터)
④ 해당 기간의 워크오더 · 알람 · 문서 시간 + 식별
スレッドが途切れていると、モデルは途切れた部分をもっともらしい言葉で補います。 名前を解決できなければ類似する設備を選び、関係がなければ同じラインにあるという理由だけで影響を推測します。そのため、製造AIの精度は、モデルの規模より先にスレッドの完全性に制約されます。グラフ照会ツールが、深度制限に達するとtruncatedを表示し、集計不能な合計はtotal_tag_count_unknownとして«不明»を示すのも同じ理由です。途切れた部分を明示的に途切れていると伝えなければ、モデルが補完してしまいます。ツール一覧はオントロジーにあります。
設計チェックリスト
スレッドを構築または点検するときに、スタックを問わず確認すべき項目です。
| 質問 | 望ましい回答 |
|---|---|
| 設備マスターの正本はどこにあるか | 1か所。 その他はそこから派生し、再作成できる |
| 外部システムのIDをどのように受け取るか | 自システムのIDを変更せず、マッピング列で受け取る |
| 人が使う呼称をIDに変換する段階があるか | ある。そして、それは分析より先に実行される |
| 階層以外に、方向を持つ関係があるか | フロー（FEEDS）・依存（DEPENDS_ON）を別途記述する |
| グラフは正本か、派生物か | 派生物。 同期用ストレージを使わず再作成する。鮮度の上限を把握している |
| 時系列値がグラフにコピーされるか | コピーしない。ポインターと読み取り方のみを保持する |
| 時間結合に何を使用するか | 発生時刻。 ワークオーダーの開始・終了が結合条件になる |
| 導出された状態を保存するか | 保存しない。外部へ渡すときは、導出ルールもあわせて渡す |
| 階層を変更すると何が壊れるか | トピックアドレスが変わることを把握し、先にサブスクライバーを確認する |
| 標準をどこで使用するか | 境界で使用する。 内部は自社の正本、外部は標準 |
関連項目
製造AI — 工場データがモデルに求めるもの・ 1つの値が画面に届くまで — エッジから画面まで・ UNS — 階層から生成されるトピック・ オントロジー — 関係をたどるツール・ データベースモデル — 正本のテーブル・ 全体構成