工場の現場は五つの方言を話している：OPC UAだけではプロトコルの分断は解決しない理由

稼働から十年を超える工場には必ずと言っていいほど、こう言う制御エンジニアがいる。「全部OPC UAに統一すれば、この問題は消えてなくなる」と。

消えてなくならない。この助言はもう十五年近く繰り返されてきたが、実際にそれに従った工場でも現場には依然として三つのプロトコルが残り、残りの部分はスプレッドシートが橋渡しをしている。

実際に持っている設備群と、ホワイトペーパーが想定する設備群の違い

OPC UAは本当に優れた統一規格だ。ベンダー中立で、設計段階からセキュアで、まさにこの課題のために作られている。問題は規格そのものではない。「全部OPC UAにすればいい」という助言の裏にある前提——現場のすべての機器がこの言語を話せるという前提——が問題なのだ。

実際の工場現場、特に増設や買収、あるいは「後でなんとかする」を十年続けてきた現場は、こんな構成になっていることが多い。

• 8年前に導入したCNCラインが、独自のプロトコルスタックを持つSiemens S7で稼働している
• やや古いプレス加工セルがAllen-Bradleyで、EtherNet/IPを話す
• イーサネットポートが存在しなかった時代の機械であるため、シリアル経由のModbus RTUで動く旧型PLCが数台
• OPC UAサーバーを標準搭載した新しめのセルが1〜2つ
• はかり、ラベルプリンター、バーコードスキャナーは、上記のどれとも話が合わない

このリストの前半をOPC UAに対応させるには、新しいファームウェア、新しいライセンス、あるいは新しいハードウェアが必要になる——それも、他は問題なく稼働していて、あと十年は使える機械に対してだ。ほとんどの工場にとって、これはもはやプロトコル移行ではない。本来必要のないデータアクセスの課題を解決するために、誰も予算を組んでいなかった設備投資プロジェクトになってしまう。

それでも「まず統一を」という助言がなくならない理由

これは悪意のある助言ではない。理論としては正しいが、実務では機能しない助言であり、その理由は三つある。

グリーンフィールドの現場を前提にしている点 新しい設備を選定する段階であれば、一つのプロトコルへの統一は簡単だ。しかし、既に設置され、生産を稼働させ、あと何年も更新予定のない設備が相手となると、まったく別の問題になる。

プロトコルがすべての問題だと捉えている点 現場が完全にOPC UAで統一されていたとしても、ルーティング、バッファリング、コンテキストは依然として必要だ——どの測定値がどの作業指示に属するのか、どの機械状態がどのOEE区分に対応するのか、シフト交代時にネットワークが4分間切れたらどうなるのか。プロトコルはバイト列を届けるだけで、それを整理はしてくれない。

実際に修正の責任を負うのが誰かを見落としている点 IT部門はきれいな単一インターフェースを望む。一方でOT部門が所有する機械は、変更管理プロセスとメンテナンスウィンドウを経ないと自由に触れない。プロトコルの議論はITの層で行われるが、制約はOTの層にある。誰もこのギャップを標準化だけで乗り越えることはできない——橋渡しをするしかない。

実際に機能する層

解決策は「正しい」プロトコルを選ぶことではない。機械が既に話している言語と、それ以外のシステムが必要としているものの間に立つ橋渡し層——OPC UAが使える場所ではそれを読み、そうでない場所ではModbusやS7を読み、下流のシステムが違いを意識する前にすべてを一つのストリームに正規化する層だ。

flowchart LR
 classDef src fill:#0b1220,stroke:#334155,color:#e2e8f0
 classDef acq fill:#083344,stroke:#22d3ee,color:#cffafe
 classDef bridge fill:#3a1f0a,stroke:#f97316,color:#fed7aa
 classDef data fill:#082f49,stroke:#38bdf8,color:#e0f2fe
 classDef office fill:#052e16,stroke:#22c55e,color:#dcfce7

 subgraph FLOOR["実際の工場現場"]
 direction TB
 S7["Siemens S7 CNCライン"]:::src
 AB["Allen-Bradley プレスセル"]:::src
 RTU["旧型 Modbus RTU PLC"]:::src
 OPCUA["新しい OPC UAネイティブセル"]:::src
 PERIPH["はかり・プリンター・スキャナー"]:::src
 end

 subgraph BRIDGE["橋渡し層"]
 direction TB
 ADAPT["プロトコルアダプター  
S7 · EtherNet/IP · Modbus TCP/RTU · OPC UA"]:::bridge
 BUFFER["ストア＆フォワード  
オフライン耐性"]:::bridge
 NORM["単一イベントストリームへ正規化  
タグマップ・タイムスタンプ・単位コンテキスト"]:::bridge
 end

 subgraph DOWN["下流のすべて"]
 direction TB
 DB[("時系列DB / Postgres")]:::data
 MES[MESコア]:::office
 SPC[リアルタイムSPC]:::office
 ERP[ERP ロットリリース]:::office
 end

 S7 --> ADAPT
 AB --> ADAPT
 RTU --> ADAPT
 OPCUA --> ADAPT
 PERIPH --> ADAPT
 ADAPT --> BUFFER --> NORM
 NORM --> DB
 DB --> MES
 DB --> SPC
 DB --> ERP

どのプロトコルを橋渡しするにせよ、この層が果たすべき役割は三つある。

規格だけでなく方言も話すこと S7、EtherNet/IP、Modbus TCP/RTU、OPC UA向けのアダプターを並列で用意する——これにより、稼働15年のプレスセルと最新のCNCラインが、どちらも置き換えることなく同じストリームに乗る。

実際に持っているネットワークに耐えること 工場現場のネットワークは切断する。エッジでのストア＆フォワード方式のバッファリングがあれば、シフト交代時の4分間のネットワーク断は、失われたデータではなく、後から埋め戻せる欠落として扱える。

下流に届く前に正規化すること MES、SPC、ERPはそれぞれ自前でプロトコルを理解する必要はない。どこから来たデータであっても、タグ付けされ、タイムスタンプが打たれ、作業指示と機械コンテキストに紐づいた一本のクリーンなイベントストリームとして見えればよい。

私たちが構築する二つのシステムでの実装

この橋渡し層は仮説上の中間ステップではなく、私たちが提供する両方のシステムに実際に名前がついた構成要素として存在する。

simpliFactoryでは、これがsimpliInterfaceにあたる。RS-232、USB、Ethernet、Modbus、OPC UAを、ベンダーが混在する現場で話す接続層であり、測定値のルーティングを担うIMCSにデータを供給し、そこからリアルタイムSPCとERPのロットリリースへとつながる——問題なく稼働している機械には一切手を触れずに。

カスタムのMES構築では、これがTier 3のエッジ層にあたる。オフライン耐性のあるPythonゲートウェイ、MQTT/OPC UAブローカー、そしてModbus TCP/RTU、Siemens S7、Allen-Bradley向けのカスタムアダプター——まさに「全部OPC UAにすればいい」だけでは対応できない、混在した年式の設備群と不安定なネットワーク環境のために構築されている。

どちらが適しているかは、実際に解決したい課題による。喫緊の課題が測定データ——キャリパー、ゲージ、はかり——がSPCやERPに届く前にスプレッドシートに滞留していることなら、それはsimpliFactoryの話だ。課題がより広範で、作業指示、機械状態、OEE、ライン全体あるいは工場全体のトレーサビリティに及ぶなら、それはMESの話であり、プロトコルアダプター層はより大きな構築の一部分にすぎない。

何かを作り始める前に行う正直なテスト

アダプターを一行でも書く前に、現場を歩いて次の三つの質問に正直に答える必要がある。

1. 各機械が今日実際に何を話しているか ——スペックシートに書かれていることでも、再ファームウェアすれば理論上対応できることでもない。マニュアルを取り出し、ポートを確認し、実機で裏を取る。
2. 本当に読み取れないものは何か 古い密閉型の射出成形機や、ベンダーがすでに存在しない一部の輸入設備など、レトロフィットなしには読み取れない機械がある。タイムラインを約束する前に、どれがそれに該当するかを把握しておく。
3. 各ステーションの実際のネットワーク状況 無線のデッドゾーン、共有の産業用イーサネット、IT部門が管理していないネットワークセグメント上のPLC——これらすべてが、ストア＆フォワードが「あれば便利な機能」なのか、それともシステム全体の信頼性を支える要なのかを左右する。

このプロトコル調査は、アーキテクチャレビューとMESパイロットの両方で最初の成果物として扱われる。理由は同じで、実際の現場で機能する橋渡し層と、ホワイトペーパーが想定した現場でしか機能しない橋渡し層との違いを分けるのが、この調査だからだ。

経済安全保障推進法の対象となる特定重要物資・基幹インフラに関わる工場では、OT系ネットワークをIT系から明確に分離するこの橋渡し層の設計が、当局の審査で問われるネットワークセグメンテーションの説明にもそのまま使える。ERPとの連携先が勘定奉行や弥生であっても、橋渡し層が正規化を済ませたイベントストリームを渡す構造自体は変わらない。

よくある質問

OPC UAは気にしなくていいということか
いいえ。新規に選定する設備については、OPC UAは今も正しい目標だ。既に存在する場所からデータを橋渡しする際にも、最もクリーンな取得元であることに変わりはない。ポイントはOPC UAを避けることではなく、更新予定のない設備に対する移行計画としてOPC UAを扱うのをやめることだ。

プロトコル調査には実際どれくらい時間がかかるのか
単一ラインであれば、現場を歩く1〜2日と、文書化されていない機器のマニュアル確認で済む。年式が混在するフルプラントでは、1週間近くかかることが多い——だからこそ、提案の前提に埋め込むのではなく、明示的な最初のフェーズとして切り出す。

本当に読み取れない機械はどうするのか
無視するのではなく、フラグを立てる。短期的にはオペレーターHMIによる手入力でギャップを埋め、その機械は必要になった時点でPLCレトロフィットの候補リストに載せる——残りの展開を止める理由にはしない。

これはsimpliFactoryの課題なのかMESの課題なのか
多くの場合、両方にまたがる。正直な答えはスコープ次第であり、それを見極めるためにこそアーキテクチャレビューや30分の技術相談がある。

現場に、誰も認めたがらないほど多くのプロトコルが混在していないだろうか。 測定データがスプレッドシートに滞留している課題であればsimpliFactoryのアーキテクチャレビューを予約し、より広範な課題であればMESの30分技術相談を予約してほしい。いずれの場合も、hello@simplico.netの先にいるのは営業担当ではなく、実際に設計するエンジニアだ。