素のMQTTには「3つの未定義」がある
MQTTは軽量なpublish/subscribe型のメッセージングプロトコルで、産業IoTの通信基盤として広く使われています。しかしMQTT自体は転送の仕組みであって、何を・どういう形式で・どんな名前のトピックに載せるかを一切定めていません。このため、素のMQTTで複数ベンダーの機器をつなぐと、次の3つが実装者ごとにバラバラになります。
- トピック構造：
factory1/line3/tempかline3/factory1/temperatureか。命名は自由 - ペイロード形式：JSONかバイナリか、単位やタイムスタンプの持ち方も自由
- 状態管理：publisherが落ちたとき、subscriberは「最後に受けた値が今も有効か」を判断できない
Sparkplugは、この3つをMQTT（OASIS標準）の上に定義する仕様です。Eclipse Foundationの下で開発され、現行版はバージョン3.0（2022年10月21日リリース）。そして2023年11月7日、ISO/IEC 20237として国際標準になりました。仕様の系譜は1.0（2016年5月）→2.1→2.2→3.0で、3.0では規範文（normative statements）が明確化され、互換性テストを可能にする形へ再構成されています。
トピック名前空間──命名の自由を「奪う」ことが価値
Sparkplugのトピックは次の形に固定されます。
spBv1.0 / group_id / message_type / edge_node_id / [device_id]命名の自由を奪うことこそがこの仕様の価値です。どのベンダーの機器でも、トピックを見ただけで「どのグループの、どのエッジノード配下の、どのデバイスの、どの種類のメッセージか」が機械的に判別できます。message_typeには次の種類があります。
| message_type | 意味 |
|---|---|
| NBIRTH / NDEATH | エッジノードの誕生証明・死亡証明 |
| DBIRTH / DDEATH | 配下デバイスの誕生証明・死亡証明 |
| NDATA / DDATA | ノード／デバイスのデータ（変化時に発行） |
| NCMD / DCMD | ノード／デバイスへの書き込み・コマンド |
| STATE | ホストアプリケーション（SCADA等）の稼働状態 |
ペイロードはProtocol Buffersベースのバイナリ形式で、メトリクス名・値・データ型・タイムスタンプ・プロパティを構造化して運びます。「温度の値だけ」ではなく「この値は何で、いつのもので、どんな属性を持つか」まで含めて標準化されている点が、後段のシステムにとって効きます。
BIRTH/DEATH──「いまの値は信用できるか」を仕様で保証する
Sparkplugの設計で最も産業的なのが状態管理です。
接続時、エッジノードはMQTTのWill（遺言）機能にNDEATHメッセージを預けてからNBIRTHを発行します。以後は変化があったメトリクスだけを送り（Report by Exception）、ノードが不意に落ちればブローカーが預かっていたNDEATHを自動配信します。つまり購読側は、「値が来ない」ことと「発信元が死んでいる」ことを区別できます。製造データを意思決定に使うシステムにとって、この区別は品質保証そのものです。
MES接続設計での使いどころと、仕様の外側
Sparkplugが効くのは、多数の設備・センサーからのデータをUnified Namespace型の構成に集約する場面です。エッジノードの自己記述（BIRTH）によって、新しい設備の追加が「つないでBIRTHを受ける」だけで完了し、ホスト側の設定作業が最小化されます。設備接続のコストが下がるのはこの仕組みによります。
一方で、仕様の外側も明確です。
- 意味の標準化はしない：Sparkplugはメトリクスの形式を定めますが、「良品数」「OEE」といった製造語彙の意味は定めません。意味論を持つのはOPC UAの情報モデルや各種コンパニオン仕様（工作機械ならMTConnectも）の領域で、実務ではSparkplugと併用されます
- コマンド系は補助的：NCMD/DCMDはありますが、作業指示・可否判定・インターロックといったMESの実行ロジックは仕様の範囲外です
- ブローカー依存の可用性：pub/sub構成はブローカーが単一障害点になり得るため、冗長化設計は別途必要です
よくある質問
SparkplugとOPC UAはどちらを選ぶべきですか？
役割が違うため二者択一ではありません。Sparkplugは「軽量に・疎結合に・大量のデータ点を集める」ことに強く、OPC UAは「装置・工程の意味構造（情報モデル）を厳密に表現する」ことに強い仕様です。実務では、フィールドからの収集をSparkplug/MQTTで行い、意味付けや企業間交換の語彙にOPC UAのモデルを使う併用構成が増えています。どちらか一方を「標準」として全社に強制するより、層で使い分けるのが2026年時点の現実解です。
Sparkplug「B」とは何ですか。AとBがあるのですか？
初期にSparkplug Aと呼ばれるペイロード定義が存在しましたが、現在使われているのは事実上Sparkplug B（Protocol Buffersベースのペイロード）のみです。現行仕様書はバージョン3.0で、トピック名前空間の接頭辞にも「spBv1.0」としてBの系譜が残っています。製品選定で「A対応」を気にする必要はありません。
