製造現場の「Semantic Field Node」とは何か — OPC UA、AAS、そして現場に意味・判断・信頼を置くための設計 —

🎥 YouTubeでも公開しています

製造現場の異常を「判断可能な文脈」へ変える｜Semantic Field Runtime × System Twin

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

製造現場のデジタル化は、長く「データを集める」ことを中心に進んできた。PLC、SCADA、MES、IoTプラットフォームによって、設備の稼働率、停止理由、温度、電力、品質値は見えるようになった。

しかし現場で必要なのは、数値の可視化や単発のアラームだけではない。

この異常は、いつ、どの関係の変化から始まったのか。何に影響している可能性があるのか。現場は次に何を確認・隔離・復旧すべきか。そして、その対応は有効だったのか。

設備保全、品質、生産技術、製造管理が本当に必要とするのは、異常を検知すること自体ではなく、予兆を意味のある文脈で捉え、影響範囲を追跡し、対処と回復を速く確実にすることである。この問いに答えるための現場側の単位を、ここでは Semantic Field Node（SFN） と呼ぶ。

SFNは、特定の設備、空間、製品、人、安全境界を代表し、限定された意味・Evidence・Capability・Boundaryを持つ、Semantic Digital Twinの現場主体である。

SFNはIoT Gatewayと何が違うのか

通常のIoT Gatewayは、センサやPLCからデータを取得し、上位システムへ転送する。これは必要な機能だが、それだけではデータの意味、判断根拠、実行権限は中央側に閉じる。

SFNは、データを次の問いに接続する。

• これは何についての観測か
• どの設備・空間・ロット・人に関係するか
• いつ、どのような根拠で観測されたか
• その観測は、いまも有効か
• 自分は何を実行でき、何を決められないか
• 実行には誰のAuthorizationが必要か

つまりSFNは、現実への接点であり、かつ責務の境界である。

OPC UAとAASはSFNの競合ではない

SFNを考えるとき、OPC UAやAsset Administration Shell（AAS）を置き換える必要はない。むしろ両者はSFNの重要な接続面になる。

OPC UA：設備の情報を相互運用可能にする

OPC UAは、センサ、機器、制御系、MES、ERPをまたぐ情報交換のための共通基盤と情報モデルを提供する。SFNにとってOPC UAは、現場の事実を取得し、既存の制御系と接続するためのAdapter になり得る。

PLC / CNC / ロボット
       ↓ OPC UA / Modbus / GPIO
SFN Adapter
       ↓
Evidence + Semantic Event

重要なのは、OPC UAの値をそのまま「判断」にしないことだ。たとえばトルクの微小な変動や GuardDoorClosed = true は重要な事実だが、それ単独で異常原因や対処を意味しない。SFNは、値をEvidenceとして保持し、材料Lot、工程条件、段取り替え、保全履歴などとの関係で使う。

AAS：設備・製品のTwinを標準的に表す

AASは、産業資産のDigital Twinを表現・交換するためのメタモデル、API、サブモデルの枠組みである。デジタル銘板、技術仕様、Capability、文書、品質などを、資産に結びつけるために使える。

SFNにとってAASは、自分が何を代表しているのかを、他組織や他システムにも通じる形で記述するための語彙と構造になる。

Asset: TorqueStation-01
  ├─ AAS Digital Nameplate
  ├─ Technical Data
  ├─ Capability: torque-tightening
  ├─ Calibration Certificate
  └─ SFN Local Twin
       ├─ currentState: Idle
       ├─ localEvidence: guard door / torque value
       └─ executableAction: start_one_cycle

OPC UAが「設備が何を伝えるか」の接続面なら、AASは「設備が何者か」を共有する表現面である。SFNは両者の上に、いま何が変化し、何に影響し、何を確認・対処すべきか、その根拠をどう残すかを加える。

SFNの具体例：製造セルでの異常の予兆と影響範囲を追跡する

小規模な組立セルを考える。締結機、部材箱、作業エリアにそれぞれField Nodeを配置し、PLC／CNC、センサ、RFID／バーコードリーダーから工程のEvidenceを取得する。狙いは「設備を自動で止めること」ではなく、トルクや振動の変化を起点に、影響範囲と確認すべき仮説を人へ示すことだ。

System Twin：SFN群を意味的な協働構造にする

各SFNは、自身の境界で起きた事実を確かに記録できる。しかしMachine Nodeだけでは「このトルク変化がどのLotや製品に関係するか」は分からず、Material Nodeだけでも「そのLotに関係する設備の挙動が変わったか」は分からない。Nodeを並べるだけでは、データは分散したままである。

System Twinは、SFNから受け取るEvidenceを、共通のEntity ID、工程、設備、製品、Lot、場所、時間で結び直す意味統合層である。単なるダッシュボードや時系列DBではなく、次の機能を担う。

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

したがって、System TwinがなければSFNは高品質な現場データ源、あるいは意味付けされたIoT Gatewayに留まる。System Twinがあることで初めて、複数のSFNは共通の世界像を参照し、異常を「一つのセンサ値」ではなく、設備・材料・工程・空間・時間の関係の変化として扱える。

普通のIoTでは、Machine Nodeのトルク値、Material NodeのLot履歴、Zone Nodeの環境値は別々に可視化されることが多い。SFNとSystem Twinの組み合わせでは、それらを同じ製造コンテキストへ束ね、なぜこの個体群を検査対象にしたのか、なぜこの仮説を優先したのかまで辿れるようにする。

3つのField Nodeをどう実現するか

3つのField Nodeは、推測ではなく、いつ・何を・どのように観測したかというEvidenceを残すものとして構築される。

SFN-Machine-01：設備の変化を時系列で残す

実設備と接続することで、PLCやCNCのOPC UA／Modbusから稼働状態、トルク、振動、アラーム、設定変更を読み取る。

このNodeは、設備の状態を「正常／異常」と早合点して決めるのではない。たとえば、cycle_started、torque_observed、fixture_changed、cycle_completed を、出所と時刻を付けて連続記録する。System Twinは、この時系列を正常時の分布と比較して、変化点や異常候補を出す。

10:01:43  cycle_started       product=P-1024
10:02:02  torque_observed     value=12.4 Nm
10:02:10  cycle_completed     result=pass
10:02:11  anomaly_candidate   feature=torque_variance

SFN-Material-01：Lotと個体製番を工程実績として結び付ける

Material NodeにはUSBバーコードリーダー、またはRFIDリーダーをつなぐ。部材箱には LOT-A17、製品には個体シリアル番号 P-1024 のようなラベルを付ける。ここでの製番は製品型式ではなく、個々の製品を識別する番号である。

作業者は、部材を補充した時にLotを読み、組み立てを開始する時に製品個体を読む。Machine Nodeの開始・完了イベントと結び付けることで、Material Nodeは「どの個体が、どの工程で、どのLotと結び付いたか」を工程実績として残せる。

09:45:12  lot_loaded          lot=LOT-A17  station=TorqueStation-01
10:01:40  product_bound       product=P-1024  process=Assembly-20
10:01:43  cycle_started       product=P-1024
10:02:10  cycle_completed     product=P-1024  result=pass
10:25:30  lot_replaced        from=LOT-A17  to=LOT-A18

この記録があれば、10:02から10:25の異常候補に対して、System Twinは「この時間帯にTorqueStation-01でLot-A17と結び付いた個体」を検索できる。P-1024〜P-1041 は原因確定品ではなく、まず追加検査・追跡の対象となる影響確認候補である。

最初はLotの補充時刻と工程時刻を突き合わせるだけでもよい。ただし、その場合は「Lot-A17を使った可能性」としか言えない。個体番号とLotを工程開始時に読取り、Machine Nodeのサイクル実績と結ぶ方式にすると、「この工程でLot-A17を使用した」という根拠の強いTraceになる。

SFN-Zone-01：変化が起きた時の工程文脈を残す

Zone Nodeには、段取り替え用ボタン、人感センサ、扉センサ、温湿度センサを接続する。作業者IDは、NFCカード、バーコード、または最初は手入力でもよい。

このNodeが示すのは、個人を監視するための情報ではない。異常の前後に、治具交換、作業者交代、扉の開放、温湿度変化、設備周辺の作業があったかという工程文脈である。

09:58:30  fixture_changed     fixture=JIG-04
10:00:00  operator_changed    role=assembly_operator
10:03:15  environment_observed temperature=27.1C humidity=68%
10:08:20  door_opened         zone=Cell-A

このように、3台のSFNは別々の事実を記録する。System Twinは、それらを時間・工程・製品・Lot・設備という関係で結び、初めて「何が変わり、どこまで影響し得るか」を示せる。

ここで具体的なユースシーンについて述べる。

製品 P-1024 の工程20で、締結トルクのばらつきが徐々に大きくなったとする。単一の値が即座にしきい値を超えたわけではない。しかし過去の正常時の分布と比べると、変化が始まっている。

• Machine Nodeは「10:02以降、トルクばらつきが上昇し、直前に治具交換があった」とEvidenceを出す。
• Material Nodeは「同時期にLot-A17の部材が使われ、対象製品はP-1024からP-1041までである」と結び付ける。
• Zone Nodeは「段取り替え、作業者交代、温湿度変化があったか」を同じ時間軸で示す。

System Twinは、三つのEvidenceを一つのContextに解決する。

Anomaly Candidate: TorqueVariation-01
  ├─ observedAt → Machine: TorqueStation-01
  ├─ affectsPossible → Product: P-1024 ... P-1041
  ├─ correlatedWith → MaterialLot: A17
  ├─ follows → Event: FixtureChange-03
  └─ occursIn → Zone: Cell-A

AIはここで「原因は治具である」と断定しない。候補仮説と必要な確認を提示する。

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

確認候補：
  1. P-1024〜P-1041を追加検査対象として抽出
  2. 治具交換前後のトルク分布を比較
  3. Lot-A17を使用した別設備・別工程を照会
  4. 校正・段取り替え・設定変更のTraceを確認

現場の人は、この根拠をもとに「追加検査」「Lot保留」「設備点検」「継続監視」を選ぶ。Trust RuntimeとHuman Gateは、判断者、判断根拠、対象範囲、実施した対処を残す。対処後にトルク分布が正常域へ戻ったか、再発したかまで追跡して初めて、予兆検知は現場の学習になる。

SFNの共通仕様

SFNの実装は、少なくとも次の九つの契約からなる。

1. Identity — Node自身と代表対象の一意なID、鍵、署名
2. Scope — 何を代表し、何を知らず、何を決定できないか
3. Local Twin — Entity、State、Capability、Constraint、Boundary
4. Evidence — 生データ、時刻、出所、品質、証拠参照
5. Semantic Projection — 値を意味イベント、状態変化、異常候補へ変換する規則
6. Capability Contract — 観測・照会・実行できるActionと必要条件
7. Local Policy Cache — 通信断時にも守る停止・失効・隔離候補の規則
8. Guarded Executor — 必要な場合だけAuthorizationを照合して限定実行する機構
9. Local Trace — 観測、文脈、対処判断、実行、結果を失わず記録する台帳

SFNにはLevelが必要である

すべての設備に、同じ重いTwinやTrust機能を載せる必要はない。SFNは、ハードウェア性能ではなく、意味・責務・自律性の深さによって段階化するべきである。

このLevelは性能表ではない。たとえばRaspberry Pi 4はL2にもL3にもなり得る。違いはCPUやメモリの数値ではなく、署名鍵、Policy Cache、Trace、Authorization検証、通信断時のSafe Stateを実装しているかにある。

失敗時の振る舞いを先に決める

SFNの信頼性は、正常時の機能一覧ではなく、失敗時の扱いに現れる。

ここでいう安全側制御は、既存の安全PLC、安全リレー、非常停止回路を代替するものではない。SFNはそれらの上に、意味・権限・Traceを扱うDecision Control Planeとして重ねる。

おわりに

製造現場に必要なのは、すべてを中央AIに集めることではない。設備、モノ、空間、人が、それぞれの立場から信頼できるEvidenceを出し、異常の予兆と影響範囲を辿り、対処の結果をTraceとして残すことだ。

Semantic Field Nodeは、そのための最小単位である。

OPC UAで現場の情報をつなぎ、AASで資産の意味を共有し、SFNでEvidence・Context・Impact・Traceを現場へ持ち込む。これが、Semantic Digital Twinを可視化の先、すなわち 予兆を早く捉え、影響範囲を説明し、対処と回復を学習できる基盤へ進める道筋になる。

参考

• OPC Foundation, OPC Unified Architecture Part 1: Overview and Concepts.
• Industrial Digital Twin Association, Asset Administration Shell Specifications.
• International Society of Automation, ISA-95 Series of Stand

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance