Raspberry PiとVirtual Agentsでつくる製造現場のSemantic Field Runtime — Chinoba PFの異常予兆・影響範囲・対処Traceデモを構築しました —

🎥 YouTubeでも公開しています

Raspberry PiとMacでつくる Semantic Digital Twin｜製造現場の信号を「判断できる文脈」へ

Books: Physical AIを支えるSemantic Digital Twin実践ガイド: Chinoba PFで構築するOntology・Knowledge Graph・DSL・Decision Trace

製造現場のAIで重要なのは、異常を一つ言い当てることだけではありません。

設備の状態、部材Lot、製番、治具交換、作業環境、保全履歴。現場には多くの信号と記録があります。しかし、それらが別々の画面や別々のデータベースに分かれていると、異常が起きた時に次の問いへすぐ答えることは難しくなります。

いつから、何が変わり始めたのか。
どの製品・Lot・工程に影響している可能性があるのか。
次に何を確認し、誰がどの対処を選ぶべきか。
そして、その対処は本当に有効だったのか。

この問いを扱うために、Chinoba PFのデモとして Semantic Field Runtime Studio を構築しました。

このデモは、3台のRaspberry Piを異なる現場の事実を記録するSemantic Field Node（SFN）として配置し、Mac上のSystem TwinとVirtual Agentsが、そのEvidenceを意味的なContext、影響範囲、確認仮説、Decision Traceへ変換するものです。

3つのRaspberry Piは、異なる現場の主体である

このデモでは、Piを小型サーバのクラスタとして扱いません。それぞれが、現場の異なる境界を代表するField Nodeです。

たとえばMaterial Nodeでは、部材箱のLot番号と製品個体の製番をバーコードまたはRFIDで読み取ります。Machine Nodeのサイクル開始・完了イベントと結び付けることで、「どの製品が、どの工程で、どのLotと結び付いたか」という工程実績を残せます。

ここで重要なのは、Nodeが原因を推測しないことです。Field Nodeが担うのは、いつ、何を、どのように観測したかという出所付きのEvidenceです。

System Twinが、分散したEvidenceを一つの製造Contextにする

Machine Nodeだけでは、トルクの変化がどのLotや製品に関係するかは分かりません。Material Nodeだけでも、そのLotに関係する設備挙動が変化したかは分かりません。

そこでSystem Twinが、設備、製品、Lot、治具、工程、空間、時間を結びます。

Machine SFN ── 設備の変化 ──┐
Material SFN ─ 個体・Lot実績 ─┼─→ System Twin ─→ 影響範囲・確認仮説・Trace
Zone SFN ─── 工程の文脈 ────┘

System Twinは、単なるダッシュボードではありません。少なくとも次の役割を持ちます。

• Evidenceの出所、時刻、鮮度、欠損を確認する
• 設備、Lot、製番、工程、場所の関係をKnowledge Graphとして解決する
• 正常時との比較から、変化点や異常候補を抽出する
• 異常候補から、影響を受けた可能性がある製品・Lot・工程を逆引きする
• 人の対処と、その後の結果をDecision Traceとして結び付ける

通常のIoTでは、トルク値、Lot履歴、環境値は別々のグラフとして表示されがちです。System Twinは、それらを同じ製造Contextへ束ねます。これにより、「なぜこの個体群を確認すべきなのか」まで辿れるようになります。

Virtual Agentsは、推測を事実に見せないために分かれる

デモでは、AIを一つの万能な判断者として扱いません。役割を分離したVirtual Agentsとして構成しています。

この分離には理由があります。AIが「原因は治具である」と自然な文章で述べても、それは観測事実とは限りません。

Chinoba PFでは、情報を次のように分けて表示します。

この区別は、説明可能性だけでなく、現場でAIを安心して使うためのTrust Infrastructureになります。

デモで起こること

デモでは、締結工程 Assembly-20 でトルクばらつきが徐々に大きくなるシナリオを扱います。

単一の値がしきい値を超えたわけではありません。しかし、正常時の分布と比べると、変化が始まっています。

09:58  治具 JIG-04 を交換
10:02  トルクばらつきが上昇し始める
10:05  LOT-A17を用いてP-1024を処理
10:25  LOT-A17をLOT-A18へ交換

System Twinは、異常候補を次のような関係として表示します。

TorqueVariation-01
  ├─ observedAt → TorqueStation-01
  ├─ follows → FixtureChange JIG-04
  ├─ overlaps with → MaterialLot LOT-A17
  ├─ may affect → P-1024 ... P-1041
  └─ occurs in → Assembly-20 / Cell-A

ここで P-1024 から P-1041 は、不良確定品ではありません。異常候補が観測された時間帯に、同じ設備とLotに結び付いた 影響確認候補 です。

AIは、次のような仮説を提示します。

• 治具交換後の機械的ずれ
• Lot-A17の部材特性差
• 設定値または作業手順の変更

ただし、仮説は原因ではありません。現場が次に確認すべき候補です。

人が対処を選び、結果から学ぶ

デモのHuman Gateでは、品質担当者がEvidence、Context、影響確認候補、仮説を確認し、次の対処を選びます。

• 追加検査
• Lot保留
• 治具点検
• 継続監視

たとえば「追加検査」と「治具点検」を選ぶと、判断者、根拠、対象範囲、実施内容がDecision Traceとして残ります。

その後、治具を再調整し、トルクばらつきが正常域へ戻ったかを確認します。

Evidence → Context → Impact → Human Decision → Outcome → Trace

ここで初めて、異常検知は単発のアラームではなくなります。現場の変化を早く捉え、影響範囲を説明し、人の対処を支援し、結果から次の判断を改善する学習ループになります。

可視化したもの

デモアプリには、次の5画面を用意しています。

このアプリの狙いは、派手なAIの自動化を見せることではありません。AIがどの事実を参照し、どこまでが導出された文脈で、どこからが確認前の仮説なのかを、誰でも辿れるようにすることです。

Semantic Field Runtimeとは何か

Semantic Field Runtimeは、現場の信号をクラウドへ集めるだけの仕組みではありません。

現実の境界ごとにEvidenceを持つField Node、関係を意味として統合するSystem Twin、推測と事実を分けるTrust Runtime、人が責任を持って対処を選ぶHuman Gate、そして結果を残すDecision Trace。

これらを一つの実行構造として扱うことで、Semantic Digital Twinは可視化の先へ進みます。

AI is not prediction. It is decision.

予測は重要です。しかし現場で価値になるのは、予測を根拠ある対処と回復へつなげ、その結果を次の判断へ戻すことです。

Chinoba PFは、そのための実験・実装プラットフォームとして、Semantic Field Runtimeを育てていきます。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance