edge.yaml と cloud.yaml、2本で何が立ち上がるか
kubectl apply を2回。OPC Foundationが2026年9月にGitHubで公開した「Cloud Initiative Reference Solution」の導入手順は、READMEの説明ではこれで終わります。1本目の edge.yaml が工場側の部品と模擬生産ラインを、2本目の cloud.yaml が受け手側の部品を立ち上げ、ハードウェアを1台も買わないうちにGrafana上でライブデータが流れる、という作りです。ライセンスはMIT。OPC Foundationの会報OPC Connectの9月号「Cloud Corner」はデプロイにかかる時間を「1分未満」と書き、READMEは300ドル未満の産業用PCで全体が動くとしています。
中身を並べると次のとおりです。設備側では、UA Edge TranslatorがModbus、BACnet、Siemens S7、三菱電機、Rockwell、Beckhoff、IEC 61850などOPC UA以外のプロトコルをOPC UAに正規化します（READMEの列挙による）。変換の定義にはW3CのWeb of Things（WoT）Thing Descriptionを使います。UA Cloud PublisherはOPC UAのデータをOPC UA PubSubのJSONメッセージにしてMQTTで送り出し、逆方向ではUA Cloud CommanderがクラウドからのコマンドをOPC UAのRead・Write・メソッド呼び出しとして実行します。受け手側はMosquitto（MQTTブローカー、TLS付き）、Telegraf、InfluxDB 2.9、Grafana 13.1.1という、オープンソースの定番どころで固められています。
ここまでなら、IIoTのチュートリアルでよく見る構成です。今回の公開で目を引くのは、その上に載っている4つの部品のほうです。
MESの側から見て、入っている部品と入っていない部品
この参照実装はMESではありません。それでも、MESの周辺で毎回作り直しているものがいくつも含まれています。対応関係を表にすると、どこまで流用でき、どこからが自前なのかがはっきりします。
| 参照実装の部品 | MES周辺でいま担っているもの | 判定 |
|---|---|---|
| UA Edge Translator | 設備接続ゲートウェイ、プロトコル変換 | そのまま比較対象にできる |
| UA Cloud Publisher＋Mosquitto | データ収集基盤、UNSのブローカー | 構成を参考にできる |
| InfluxDB＋Grafana（「Production Line OEE」画面同梱） | ヒストリアン、OEE見える化 | PoC用。長期保存・監査は別途 |
| UA Cloud Action / Commander | 設備への条件書き込み、レシピ配信 | 承認と記録の仕組みが別途必要 |
| i3x4influx（ISA-95階層のREST） | MESの設備マスタ参照API | 階層定義を誰が持つかの設計が要る |
| UA Data Processor | DPP・PCFのデータ作成 | MESの実績との突合が必要 |
| （該当なし） | 作業指示、ロット・シリアルの系譜、品質判定、作業者・電子署名 | MESの領分のまま |
最後の行が要点です。指図（ワークオーダー）を発行し、ロットやシリアルの系譜を確定させ、検査結果で合否を決め、誰がいつ承認したかを残す。この参照実装はそのどれも持っていません。テレメトリ（設備から上がる時系列データ）を集めて、見せて、閾値で設備へ指令を返すところまでが守備範囲です。
裏返すと、MES導入プロジェクトの初期に毎回発生する「設備データをどう集めるか」の議論には、たたき台として使えるということです。設備接続の設計では、ブローカーの選定、証明書の配布、トピック設計の3つが毎回の論点になり、ここで初期の時間を取られがちです。参照実装はこの3つに一つの答え（Mosquitto、OPC UA GDSのServer Pushによる証明書配布、OPC UA PubSubのJSONエンコーディング）を出しているので、比較の基準線として置けます。各部品の考え方はMESとヒストリアンの役割分担やUnified NamespaceとMESの関係の記事と合わせて読むと位置づけがつかみやすくなります。
DPPを「テレメトリから計算する」設計が問いかけること
構成のなかで最もMESに近いのは、UA Data Processorです。READMEによれば、生産テレメトリを読み、工程ごとのエネルギー消費を製品単位に割り付けて製品カーボンフットプリント（PCF）を計算し、ライン末端の寸法・品質データから電池パスポートを作ります。できあがったデジタルプロダクトパスポート（DPP）はOPC UAの情報モデルとしてUA Cloud Libraryに保管され、欧州規格EN 18222とEN 18223に沿うとしています。この2規格は、CEN/CENELECの合同技術委員会JTC 24が策定したDPP関連の欧州規格8本に含まれます。CEN-CENELECの一覧ではEN 18222が「ライフサイクル管理のためのAPI」、EN 18223が「システム間の相互運用性」と紹介されている一方、READMEはEN 18222を「データモデルと一意識別子」、EN 18223を「システムアーキテクチャとデータ交換」と説明しており、規格の範囲の書き方が一致していません。採用時には規格本文での確認が必要です。
OPC Foundation会長のStefan Hoppe氏は、同じ9月号の巻頭言で、EUのバッテリーパスポートの130パラメータをOPC UA情報モデルに落とす作業に半日、JTC 24の仕様に沿ったRESTインタフェースの実装に半日しかかからなかったと書きました。氏はこれを「生産データからライフサイクル情報へ」という、OPC UAの捉え方の転換だと位置づけています。
速さは本物でしょう。ただ、MESを運用している側から見ると、気になる点が一つあります。DPPに載る値のうち、どの工程を通り、どの部材ロットを使い、検査に合格したかという部分は、多くの工場でMESが「正」として持っている記録です。参照実装はそれをテレメトリから組み立てます。両方が並立すると、DPPに書かれたPCFとMESの実績から計算したPCFが一致しない、という事態が起こりえます。手直し品や再検査品のように、設備データだけでは経路が追えない製品ほどずれやすいはずです（推測）。
DPPを「MESの新しい出力仕様」として捉えた記事で書いたとおり、系譜の確定はMESの仕事です。参照実装のDPP部分を試すなら、テレメトリ由来の値とMES由来の値のどちらを正とするかを先に決め、もう一方を照合用に回す設計にしておくのが安全です。EUのDPPレジストリが2026年7月20日に稼働を始めた経緯はレジストリ稼働の記事にまとめています。
i3XとMCP、上位アプリの入口が2つ用意された
もう一つの新しさは、上位アプリケーションに向けた入口が2系統あることです。
1つ目の i3x4influx は、InfluxDBに溜まったテレメトリをISA-95の階層（READMEの表記では enterprise・site・area・line・station）でたどれるREST APIとして公開します。名前のとおり、米国の製造業研究機関CESMIIが2026年6月18日に1.0を公開したi3X（Industrial Information Interoperability eXchange）に沿ったものです。CESMIIの発表では、i3Xは名前空間の探索、型定義の参照、インスタンスの取得、関係のたどり、現在値・履歴値の照会、変更の購読を一つのAPIにまとめたもので、44社超の技術プロバイダーが支持しています。1.0には適合性テストとMCPサーバーも含まれています。
2つ目の UA Cloud AI は、MCP（Model Context Protocol、AIエージェントが外部ツールやデータを呼び出すための共通規約）のエンドポイントです。OPC Foundationは2026年4月に、430超のOPC UA仕様をAIエージェント向けに再整備する計画を打ち出しています。今回はその方向が、仕様文書ではなく動く部品として出てきた形です。
MES側にとって厄介なのは、ISA-95の設備階層を返すAPIがMESの外にもう一つ生まれることです。MESのマスタで「ライン3」と呼んでいる単位と、i3X側の階層の「ライン3」が同じ設備群を指している保証はありません。どちらの階層定義を正とし、どちらが追随するのかを決めずにAIエージェントを両方につなぐと、エージェントは食い違う2つの工場像を受け取ることになります。
同時に出ていたモデリングエディタと、今後の確認点
Hoppe氏の9月号巻頭言は、Cloud Initiativeが無償のOPC UAモデリングエディタをOPC FoundationのWebサイトで公開したことも伝えています。情報モデルを定義し、そのインスタンスを作り、通信方式に依存せずに意味づけされた情報を扱える、という説明です。
参照実装は2026年9月に公開されたばかりで、i3x4influx のコンテナイメージも main タグを参照する構成になっています。業務で採用を検討するなら、少なくとも次の3点は追いかける必要があります。部品の版がどの頻度で上がるのか（InfluxDBやGrafanaの版はREADMEに明記されています）、EN 18222/18223の改訂にどう追随するのか、OPC Foundationの公式サポートがどこまで及ぶのか。最後の点について、今回確認した範囲の公式資料は何も述べていません。
日本の工場で確かめたいのは、変換定義を誰が書くかです。READMEは三菱電機を含む多くのプロトコルを対象に挙げていますが、同梱の模擬設備はModbus TCPの1台で、それ以外は設備ごとにWoTのThing Descriptionを用意する必要があります。数百台規模のブラウンフィールド工場では、この記述作業の量と、機種が変わったときの保守を誰が担うのかが、ゲートウェイ製品との比較で効いてくる論点です。
この参照実装をそのまま本番のIIoT基盤として使えますか？
READMEにはSTRIDEによる脅威分析と本番向けの強化策が付いていますが、冗長化・バックアップ・監査ログ保全は利用者側の仕事です。公開されたばかりで、部品の更新頻度や公式サポートの範囲も明らかになっていません。PoCや比較の基準線としての利用が妥当で、本番採用には自社での強化と保守体制の検討が必要です。
MESの代わりになりますか？
なりません。テレメトリの収集・可視化・閾値による設備指令とDPP生成が守備範囲で、作業指示、ロット・シリアルの系譜確定、品質判定、電子署名といったMESの中核機能は含まれていません。MESの前段や横に置くデータ基盤の参考実装と捉えるのが正確です。
DPPをこの構成で作る場合、MESとの関係はどうなりますか？
参照実装は生産テレメトリからPCFや電池パスポートを計算します。工程経路や部材ロット、検査結果をMESが記録している工場では、両者の値がずれる可能性があります。どちらを正とするかを先に決め、もう一方を照合用に使う設計にしておくことを勧めます。
i3XとOPC UAは競合する規格ですか？
CESMIIはi3XをOPC UA、MQTT、ISA-95の上に載り、それらを補完するAPIと位置づけています。参照実装でもOPC UAで集めたデータをInfluxDBに溜め、その上にi3X準拠のREST APIを置く構成で、両者は層が異なります。
- Cloud-Initiative-Reference-Solution リポジトリとREADME（OPC Foundation、GitHub、2026年9月確認）
- Cloud Corner – September 2026（OPC Connect、OPC Foundation、2026年9月）
- Presidential Welcome – September 2026（Stefan Hoppe、OPC Connect、2026年9月）
- CESMII Releases i3X 1.0（CESMII、2026年6月18日）
- Digital Product Passport, the cornerstone for the implementation of sustainability and circularity on the European Single Market（CEN-CENELEC、2026年7月）
この記事に出てくる用語
この記事を書いた人
DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。
