MQTTが決めていること、決めていないこと
MQTTは、軽量なクライアント・サーバ型のpublish/subscribe（発行・購読）プロトコルです。MQTT 5.0は2019年3月7日にOASIS標準になり、v3.1.1はISO/IEC 20922:2016として標準化されています。クライアントはブローカー（サーバ）に接続し、トピックを指定してメッセージを発行し、関心のあるトピックを購読します。
MQTTが決めているのは、主に通信の仕組みです。
- 配信品質（QoS）：0は「最大1回」（失われることがある）、1は「最低1回」（重複の可能性がある）、2は「正確に1回」
- Will Message：クライアントが異常切断したとき、ブローカーが代わりに発行するメッセージ
- 保持メッセージ：最新の値をブローカーが保持し、新しい購読者にすぐ渡す仕組み
一方、ARC Advisory Groupが指摘するように、素のMQTTはトピックの名前空間もペイロードの符号化も定めていません。トピック名を「factory/line1/temp」にするか「plant01.L1.temperature」にするか、値をJSONで送るかバイナリで送るか、単位やタイムスタンプをどこに入れるかは、使う側が決める必要があります。決めずに使い始めると、設備ごと・ベンダーごとにばらばらの形式でデータが流れ、購読側で変換が必要になります。
Sparkplugが補うもの
Sparkplugは、Eclipse Foundationが策定したMQTT上の仕様で、ISO/IEC 20237として国際標準になります（2023年11月発表）。Eclipse Foundationによれば、OT向けのトピック名前空間、産業プロセス変数のペイロード定義、リアルタイムSCADA向けのMQTTセッション状態管理を定めています。
| 項目 | 素のMQTT | Sparkplug |
|---|---|---|
| トピック構造 | 自由 | spBv1.0/group_id/message_type/edge_node_id/[device_id] |
| ペイロード | 自由 | Protocol Buffersで符号化したメトリクス（名前・型・値・時刻） |
| メッセージの種類 | 区別なし | NBIRTH・DBIRTH（起動通知）、NDATA・DDATA（データ）、NDEATH・DDEATH（切断）、NCMD・DCMD（命令）など |
| 状態管理 | Will Messageのみ | エッジノード・デバイスのオンライン状態と、起動時の全メトリクス定義 |
| 変化時のみ送信 | 自分で実装 | 仕様に組み込まれている（Report by Exception） |
Sparkplugの大きな利点は状態管理です。エッジノードが起動するとBIRTHメッセージで自分が持つ全メトリクスの名前と型を通知し、切断されるとDEATHメッセージが流れます。購読側（SCADAなど）は、どのデバイスがオンラインで、どんなデータを持っているかを自動で把握できます。データが変化したときだけ送る仕組みも組み込まれており、通信量を抑えられます。
Sparkplugの弱点と、独自規約という選択肢
Sparkplugにも弱点があります。トピック構造が group_id/edge_node_id/device_id に固定されているため、ISA-95の資産階層（企業・拠点・エリア・ライン・セル）をトピックで直接表すことができません。group_idやedge_node_idの命名で階層を表現するか、メトリクスの名前で表現するかの工夫が必要です。また、ペイロードがProtocol Buffersのバイナリなので、汎用のMQTTツールではそのまま読めず、Sparkplug対応のツールが必要です。
このため、トピック階層をISA-95で自由に設計し、ペイロードをJSONで統一する独自のUNS規約を選ぶ企業もあります。MQTTブローカー大手のHiveMQは、2023年にSparkplugとUNSを組み合わせた構成を解説した記事を公開しましたが、その後、Sparkplug前提よりも柔軟なUNSのアプローチを推す方向へ見解を変えたと同記事の中で明記しています（2026年2月更新）。どちらが正解というより、目的によって選ぶものだと考えるべきです。
判断基準
| 状況 | 向いている選択 | 理由 |
|---|---|---|
| SCADAとの連携が主目的で、対応製品を使う | Sparkplug | 状態管理とメトリクス定義が自動で連携される |
| エッジ機器・ゲートウェイがSparkplugに標準対応している | Sparkplug | 設定だけで使え、規約を自作する手間がない |
| ISA-95階層で全社のデータを横断的に購読したい | 独自UNS規約（またはSparkplugとの併用） | トピックで階層を直接表現できる |
| MESの文脈やAIの推論結果も同じ名前空間に流したい | 独自UNS規約 | 設備データ以外の情報も同じ規約で表現しやすい |
| 汎用ツールやクラウドサービスで直接データを読みたい | 独自UNS規約（JSON） | バイナリのデコードが不要 |
実際には、両方を併用する構成もあります。設備に近い層（エッジからSCADA）はSparkplugで流し、ブローカーやエッジ基盤でISA-95階層のトピックに変換して上位（MES・AI・データ基盤）に配信する形です。
AIの観点では、推論結果を名前空間に書き戻し、MESやアンドンが購読する使い方が重要です。この用途では、設備データ以外の情報を柔軟に表現できる独自UNS規約のほうが扱いやすい場面が多いと考えます。UNSの全体像はUnified Namespace（UNS）とは、OPC UAとの使い分けはOPC UAかMQTTかで扱っています。
よくある質問
Sparkplug BとSparkplug 3.0は違うものですか？
トピックの接頭辞「spBv1.0」はSparkplug Bペイロード形式を示しています。Eclipse Foundationで仕様の版（3.0など）が更新され、それがISO/IEC 20237として標準化される流れです。導入時は、製品がどの版に対応しているかを確認してください。
QoSはどれを使えばよいですか？
プロセス値のように頻繁に更新され、1件欠けても次の値で補えるデータはQoS 0か1で十分です。AIの判定結果やイベントなど、欠落や重複が業務に影響するものはQoS 1以上とし、受信側で重複を処理できる設計にしてください。
MQTTブローカーはクラウドとオンプレミスのどちらに置くべきですか？
工場内の設備・MES・エッジAIをつなぐブローカーは工場内（オンプレミス）に置くのが基本です。ネットワークが切れても工場内の連携が止まらないためです。クラウドへは、工場内のブローカーから必要なデータだけをブリッジします。
- MQTT Version 5.0（OASIS）
- The Eclipse Foundation Announces Sparkplug as an International Standard（Eclipse Foundation, 2023年11月7日）
- Sparkplug Now an Official ISO/IEC Standard（ARC Advisory Group, 2023年11月7日）
- Semantic Data Structuring with MQTT Sparkplug and Unified Namespace（HiveMQ, 2023年6月21日、2026年2月23日更新）
この記事に出てくる用語
AIは「データ基盤」で決まる
PoCは成功したのに本番で止まる。原因の多くはモデルではなく、MESと設備データの側にある 全130本
- MESとAIの関係：ロット・作業指示・品質判定がAIの精度を決める理由
- 製造業AIが本番で止まる7つの理由：PoCは成功したのにラインに載らない構造
- 製造業のAI-OCR：紙の検査記録・点検表・ミルシートをデータ化する手順
- データ基盤の段階的導入ロードマップ：ユースケースから逆算する8ステップ
この記事を書いた人
DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成と、製造業向けAIの調査・開発・教育を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES・データ基盤・AI導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。
