MQTT Sparkplug B導入｜タイ工場の検収・90日実証

タイ工場で「MQTT Sparkplug Bを導入したい」と相談すると、複数のベンダーが「MQTT対応」「Sparkplug対応」と答えるでしょう。しかし、その二つの表示だけでは、PLCの値が同じ意味と状態でMESや監視画面に届くかは分かりません。調達で問うべきことは、指定した設備と信号について、起動・停止・通信断・復旧・変更時に何を送受信し、何を証拠として残せるかです。本稿は、購買、OT、IT、生産技術が同じ表で判断できるよう、RFP、FAT、SATと90日パイロットの書き方を具体化します。

MQTT Sparkplug B 導入の結論：製品名より受入条件を先に決める

SparkplugはMQTTにおけるトピック名前空間、ペイロード、セッション状態の扱いを定義する仕様です。MQTT自体はメッセージを運ぶプロトコルであり、トピック名や値の意味、設備が生きているかどうかの共通表現を工場向けに一式定めるものではありません。Sparkplugはこの間を埋めるための取り決めで、監視・制御HMIなどの要求も意識して設計されています。Eclipse Foundationの仕様ページでは、Sparkplug 3.0の改訂日を2022年10月21日と記載しています。「2026年に新標準が出た」という説明は避け、発注時には適用する仕様の版を明記してください。Sparkplug仕様と3.0.0本文を参照します。

発注書には少なくとも四つを分けて書きます。第一は仕様上の振る舞い。第二は候補製品の互換性主張と、その対象バージョン。第三は自社のOTネットワーク・PLC・MESとの統合設計。第四はFAT/SATで再現する試験と提出物です。前二つを満たす製品でも、設備側の時刻ずれ、タグ命名の揺れ、回線分断、権限設定は現場ごとに異なります。採用可否は実際の境界条件で判断します。

この記事が扱うのは「Sparkplugを採る場合の購買仕様と検収」です。PLCから何をどう取得するかはPLCデータ収集の設計を、ゲートウェイ機種の耐環境性や保存機能をどう選ぶかはIoTゲートウェイ選定を先に確認してください。本稿は取得済みデータを複数の利用先へ公開するときのデータ契約、セッション状態、相互運用性を調達可能な形にします。

まず「どの設備から、誰が使うか」を一枚にする

RFPの冒頭に対象を具体的に書きます。たとえばタイの一工場の組立ライン二本、PLCメーカーが異なる設備三台、稼働・停止・良品数・不良数・品種コード・アラームを対象とし、受信側は監視画面とMESの二系統、といった形です。この台数と信号は説明用の例であり、標準の要求値でも推奨規模でもありません。対象外も重要です。制御指令、品質判定、法定記録に使わない実証なら、その境界を書けば設計と承認が早くなります。

設備側の責任者は元の値と意味を定義し、ネットワーク担当は接続経路と許可通信を定義し、アプリ担当は受信後の保存・表示・欠損扱いを定義します。購買担当は成果物と支払条件を対応させます。「PLCには値がある」「ブローカーには届いた」「MESでは見えない」という分断を避けるため、信号ごとに発生元、単位、データ型、正常範囲、更新契機、イベント時刻、欠損時の扱い、業務上の所有者を記します。運転停止の判定をどのビットで行うか、カウンターを再起動で初期化するかは、プロトコルだけでは決まりません。

工場が複数国にある場合、拠点コード、設備ID、表示名、時刻の表記を契約します。現場画面はタイ語でも、共有する技術識別子には一貫した英数字を使うなど、変更に耐える名前にします。識別子を後で変えると、履歴の結合や権限設定に影響するため、パイロット対象だけでも命名規則と変更承認者を固定します。

Sparkplug Bの構成要素を購買言語へ訳す

典型的な構成では、PLCやセンサーの値をMQTT Edge Nodeが取得し、MQTT Serverを経てSparkplug Host Applicationなどの利用先へ届けます。仕様の役割名と、ベンダー製品の箱やライセンス名は一致しないことがあります。RFPには、どの製品がEdge Node、Server、Hostの役割を担うか、冗長構成を採る場合に誰がフェイルオーバーを制御するか、図と表の両方で示すよう求めます。ブローカー単体がSparkplugの業務上の意味を検証するとは限りません。役割ごとの機能と責任を見ます。

Sparkplugにはトピック名前空間と、ノード・デバイスのBirth、Data、Deathなどのメッセージ種別が定義されています。Birthは単に「最初の一件」ではなく、受信側が当該セッションのデータモデルを把握するための材料です。Deathや状態の変化を受ける側は、最後の値をそのまま「現在値」と表示し続けないルールが必要です。ここで決めるのは電文の有無だけでなく、画面、アラート、MES連携の動作です。仕様はメッセージ構造を示しますが、設備停止と通信途絶の業務判断は発注者が定義します。

役割を一つの製品へまとめる場合も、将来別製品へ分ける場合も、依存関係を説明させます。ライセンス失効や証明書期限、ネットワーク機器の変更がメッセージ配信へどう影響するか、どの画面で検知できるかを質問してください。「Sparkplug対応」という一行だけで構成上の単一障害点は消えません。

「対応」「互換性掲載」「現場合格」は別の証拠

Eclipse FoundationはCompatible Productsの一覧を公開しています。一覧に載る製品には、対象製品と版を確認する価値があります。一方、一覧に見当たらないことだけで非対応と断定しないでください。公式のGet Listedには、TCKの実行、参加、契約、掲載申請などの手続きが記されています。掲載はベンダーの自己申告の一語と同じではなく、また導入先のネットワーク・データ定義・運用手順まで自動的に保証するものでもありません。

購買表には「主張」「証拠」「対象版」「導入現場での確認」を別欄にします。候補がCompatibleという語やロゴを使うなら、公式掲載先、製品・版、試験結果、利用条件の参照先を求めます。単に「MQTT v5を話せる」ことはSparkplug適合の証明になりません。逆に特定のブローカーが一覧にあることだけで、組み合わせるEdge NodeとHostの全体が合格になるわけでもありません。仕様、互換性プログラム、実装構成、現場受入の層を混ぜないことが重要です。

EclipseのTCKプロセスは、仕様が最優先の根拠であること、互換性評価や掲載申請の扱いを説明しています。発注者はTCKを自社SATの代わりに使わず、製品側の適合主張を評価する一つの材料として扱います。製品のメジャー版更新時に再確認が必要かも契約に含めます。

RFPで回答させる12の項目

RFPは「機能あり／なし」だけでは採点できません。各行に要求、応答形式、デモ方法、合格条件、提出証拠、保守責任を書きます。以下は製品を指名するリストではなく、導入側が比較可能な回答を得るためのテンプレートです。

各項目の数値閾値は発注者が設備と業務用途から決めます。たとえば「遅延5秒以内」と書くなら、どの時刻間を測るのか、通常・バースト・切断復旧のどの条件で判定するのかを明記します。この5秒は例示で、Sparkplug仕様が保証する性能ではありません。候補比較ではカタログ上の最大点数より、実際のデータ型、通信周期、同時接続、障害条件での観測値を使います。

データ辞書を購買添付資料にする

パイロット開始時からMetric辞書を作ります。一行に、設備識別子、Metric名、業務名、データ型、単位、値の由来、更新条件、タイムスタンプの由来、品質判定、画面表示先、MES格納先、変更承認者を入れます。正常値だけでなく、不明、未接続、測定範囲外、メンテナンス中の表現を決めます。Booleanの0を「停止」と見なすのか「センサー異常」と見なすのかは現場の意味付けであり、Sparkplugの一般機能では解決しません。

命名は設備の表示名に引きずられないようにします。たとえば設備移設やライン改称があっても変えない不変IDと、人が読むラベルを分けます。グループ名やノードIDに個人名や一時的なプロジェクト名を埋め込まない方が、運用引継ぎが容易です。多言語の説明欄を持たせても、機械識別子は一つに保ちます。データ辞書の版と公開設定の版を対応させ、どの時点の履歴にどの意味が適用されたか追えるようにします。

辞書を誰が承認するかを曖昧にしないでください。設備メーカーが電文を定義しても、その値を生産実績や品質指標へ転用する責任は利用部門にあります。RFPの成果物としてデータ辞書の初版を納め、SAT後に発注者が保守できる形式で引き渡すことを条件にします。専用画面に閉じた設定だけでは、将来の移行時に再現性を失います。

FATは正常デモではなく状態遷移を再現する

FATはベンダー環境で行う工場受入前の試験として、正常な一連の値表示だけで終わらせません。まずEdge Nodeを起動してBirthを受け、Metricの型・単位・初期値とデータ辞書を照合します。次に値を変えてDataを受け、受信側の履歴と画面を照合します。続いて通信を遮断し、利用先がオフラインを識別するか、最後の値に時刻と状態が付くかを確認します。復旧時は初期状態が再構成され、同じ設備を別設備として重複登録しないかを見ます。これは試験設計例であり、仕様の各要求項目は参照版の本文で確認します。

試験台に二つの異なるベンダー製品を置けるなら、相互運用性を同じシナリオで測ります。互換性掲載の有無と、現場が必要とする機能の有無は別欄に残します。実験機材が用意できない場合は、候補の制約を明示し、SATでどのリスクが残るかを購買判断へ渡します。「製品Aで成功」という記録だけでは、ソフト更新や機器交換後の再検証条件を決められません。

FATの証拠束は、構成図、製品版、設定ファイル、メッセージトレース、操作時刻、投入したテスト値、期待値、実測値、差分、原因、再試験結果を一件ずつ紐づけます。タイムゾーンを揃え、画面録画だけでなく機械で読めるログも保存します。試験に使った証明書やアカウントを本番へ持ち込まない手順も添えます。合格判定者を契約上明確にし、ベンダー自己判定だけで検収しない構造にします。

SATはタイ工場の境界条件を試す

SATでは、実ネットワークのセグメント、ファイアウォール、DNS、時刻同期、電源、保守端末、交代勤務の運用を含めます。FATで動いた構成が現場で失敗するのは、製品の不具合だけとは限りません。OTとITの境界に許可されない通信がある、メンテナンス時間帯の再起動がブローカーへの再接続集中を起こす、PLC側のタグ名が実機で違う、といった条件があり得ます。SATの手順書には実機の停止許可、復旧条件、影響範囲、緊急連絡、元の構成に戻す方法を先に書きます。

現場での故障注入は安全と生産を優先し、制御系へ無断で影響を与えません。検証用のネットワーク経路や模擬信号から始め、生産設備の停止を伴う試験は保全・製造の承認後に実施します。回線断の長さや再送量は、取得周期と保存容量から決めます。標準が一律に「何時間の断線に耐える」と定めるわけではありません。停止してはいけない設備では、SATの一部を隔離した検証環境で行い、現場未確認の項目を未完了として残します。

SATは技術担当だけの会議で終えず、画面を見る班長やデータを使う生産管理者に「値が古い」「接続が切れた」「復旧中」の表示を確認してもらいます。オフライン設備の最後の値を現値として読んでしまう事故は、メッセージが正しくても起こります。アラートの宛先、夜間対応、翌朝の引継ぎ、障害票の項目まで含めて合否を決めます。

MQTTの機能とSparkplugの役割を混同しない

OASISのMQTT Version 5.0仕様は、接続、発行、購読、QoS、セッションなどメッセージ交換の仕組みを定めます。Sparkplugはその上で工業データの構造と状態の扱いを定めます。「QoS 1だから業務レコードは必ず一度だけ保存される」とは言えません。再送、受信アプリの再処理、データベース書込の失敗などを通るため、業務上の重複計上は受信側の一意キーや処理設計で防ぎます。どの層が保証するかをRFPで分けます。

同様に、MQTTのRetainやLast Willを使っていることと、SparkplugのBirth/Deathを仕様どおり扱うことは同義ではありません。製品ごとの実装と構成を確認し、何を受けて受信側が設備状態を「有効」から「不明」へ切り替えるのかを試験します。複数の受信者がいるとき、片方だけ再起動した場合に必要な初期状態を得られるかも問います。単一画面の正常デモでは、もう一方の利用先が古い値を読み続けるリスクは見えません。

ブローカーの冗長化も、受信アプリがモデルを再構築できることまで含めて確認します。フェイルオーバー時間の目標、切替時のメッセージ欠損・重複の許容、各接続の再認証、復旧後のアラート解除条件を記載してください。これらは工場のサービスレベルとして契約する値で、Sparkplugという名称から自動的に導ける値ではありません。

セキュリティはネットワーク図と運用手順で検証する

Sparkplugを採用しても、安全なOT運用は別途設計が必要です。NISTのSP 800-82 Rev.3はOTの脅威、制約、対策を扱うガイドです。ここから導く実務上の要点は、資産と通信の把握、ゾーン間の経路、認証・認可、変更管理、監視と復旧を導入構成に合わせて設計することです。NIST文書をタイの法的義務と誤解してはいけません。顧客契約や適用法令の確認は別途行います。

RFPには、Edge Node、Server、Hostそれぞれのアカウントを分けるか、購読・発行の許可範囲をどのトピック単位で制限するか、証明書を誰が発行・更新・失効するかを記載させます。資格情報を機器イメージに固定しないこと、バックアップに含まれる秘密情報をどう保護するかも質問します。管理用画面の権限とメッセージ経路の権限は別物です。保守会社のリモートアクセスには時間、目的、記録、解除の条件を設けます。

暗号化された通信でも、誤ったMetric名や認可された誤操作は防げません。設定変更のレビュー、投入前検証、ロールバック、操作ログ、定期的な証明書更新リハーサルをパイロットの成果物にします。保守終了時にアカウントを廃止し、工場側が構成と鍵管理の主導権を持てる契約にします。

費用見積は機器代でなく責任境界で分解する

「Sparkplug導入費用はいくらか」への一律回答はできません。既設PLCから値を読めるか、Edge Node機能が既設機器にあるか、ブローカーを誰が運用するか、Host側アプリで状態を解釈できるか、サイバーセキュリティ審査や停止調整が必要かで工数が変わります。見積依頼では、ハード、ソフトライセンス、通信、データ辞書作成、接続、画面・MES改修、FAT、SAT、教育、保守、将来の設備追加を行別にしてください。価格を見せずに「一式」とする提案は比較が難しくなります。

初期費用と運用費用も分けます。製品のサブスクリプション、保守契約、証明書更新、ログ保管、監視、バックアップ、障害対応、再試験、拠点追加時のライセンス条件を確認します。タイ国内で一次対応できるか、夜間休日は誰が受けるか、言語は何か、工場停止の承認は誰が取るかを見積条件にします。遠隔から直せるという説明だけでは、工場側の入場・安全・ネットワーク承認を代替できません。

ROIを先に断言するより、現在の手作業、停止理由の不明件数、データ欠損、復旧所要、レポート作成時間を測り、パイロット後に同じ測定法で比較します。改善率や回収期間の数字を仕様や記事に流用しないでください。それらは個別の設備・運用と投資額に依存します。経営判断に必要なのは、値上げ余地まで含む提案条件と、測定可能な成果です。

90日パイロット：日数は例示、出口条件を先に置く

以下の90日は調達計画の例であり、規格の要求や一律の標準期間ではありません。停止窓と調達リードタイムに合わせて延ばして構いません。重要なのは、試してから合格基準を変えないことです。開始前に、対象設備、信号、受信先、役割分担、ベースライン、試験時の安全条件、合否、失敗時の撤退条件を承認します。

各段階で次へ進む条件を一つの表に置きます。たとえばデータ辞書の所有者が未定ならFATへ進まない、工場停止の承認が取れないなら実機の故障注入は行わない、重大な欠損が未解決なら対象ラインを増やさない、という判断です。工程は日付より依存関係を優先します。購買契約では、未合格の試験、追加費用、再試験期限、成果物の引渡しを明記します。

観測期間には日中だけでなく、立上げ、品種切替、週末停止、保全後の再開など対象業務の変化を含めます。ただし90日に必ずすべての故障が発生するわけではありません。未観測の事象は故障注入で補うか、残余リスクとして投資判断に添付します。合格したら何台・何ラインへ増やすのか、誰が追加の命名や証明書発行を承認するのかまで決めておくと、実証が単なる展示で終わりません。

FAT/SATの合格条件を数値化するときの注意

閾値は「どこで測るか」「どの条件で測るか」「例外をどう扱うか」の三点が必要です。受信遅延ならPLCの変化時刻、Edge Node取得時刻、ブローカー到着時刻、Host保存時刻を分けます。通信断からの復旧なら、切断を開始した時刻、オフライン表示時刻、接続復旧時刻、データが追いついた時刻を分けます。タイムスタンプの同期が崩れたまま計算した差は、性能測定になりません。

欠損率も分母を定義します。変化時だけ送信するMetricに対して「毎秒一件」の想定分母を置けば誤判定します。対象信号ごとの期待イベント、テスト入力、送信・受信記録を突き合わせます。再送で同じイベントが二度届いても、業務記録の二重計上を避けられたかを別に見ます。合格値は品質用途か監視用途かで異なり、ここに全工場共通の百分率を置くことは適切ではありません。

契約には「測定不能」を合格としないルールも必要です。ログが足りず遅延や欠損を判定できないなら、観測設計の未完了です。証拠を後から再取得できない試験は、再実施条件を決めます。閾値の見直しが必要なときは、理由、影響する業務、費用、発注者承認を変更票に残します。

変更と拡張で壊れない契約にする

実証後に設備が増えると、同じ名前のMetric、異なる単位、古い装置の別解釈が現れます。新規設備を登録する手順、重複IDの検出、辞書レビュー、権限割当、性能再測定、受信アプリの回帰試験を標準作業にします。既存データの意味を変える場合は、単なる設定上書きでなく版変更として扱い、履歴をどう読むかを決めます。廃止設備のID再利用も避けます。

ソフト更新では、候補製品の対応するSparkplug仕様版と、相互接続した製品版の組合せを記録します。公式互換性掲載は対象版を見ます。試験した版から変えたら、自社で必要なFAT/SATの差分試験を再実施します。更新を永久に避けるのではなく、変更の影響範囲を小さくして計画的に行います。失敗時のロールバックには設定だけでなく、データ辞書と証明書の対応も含めます。

契約終了やベンダー変更時に、Metric辞書、構成図、設定エクスポート、履歴の持ち出し、アカウントの失効、ライセンスの扱いを決めます。標準採用だけで移行が自動的に安くなるわけではありません。出口で必要なデータと運用文書を、入口の契約で受け取れるようにしておくことが調達の役割です。

タイ工場の購買会議で使う最終チェック

購買会議では、①対象設備と利用先、②採用する仕様版、③各製品の役割と版、④互換性主張の証拠、⑤データ辞書の所有者、⑥Birth/Deathを含む状態遷移試験、⑦OTセキュリティと証明書更新、⑧FAT/SATの合格条件、⑨90日実証の出口、⑩保守・変更・撤退条件、を一枚で確認します。ひとつでも「後で決める」が残るなら、価格だけで採否を決めないようにします。

見積を比較するときは、同じテスト範囲で揃えます。ある候補はEdge Nodeだけ、別候補はBrokerとHostの設定まで含むなら、合計価格はそのまま比較できません。構成図と役割分担から見積の抜けを補正し、試験に参加する工場担当の工数も投資判断に入れます。最低価格が悪いわけではありませんが、未定義の責任が残るほど追加工数の見通しは弱くなります。

FAQ：MQTT Sparkplug B導入前によくある質問

MQTT対応ゲートウェイならSparkplug B導入は済みますか？

いいえ。MQTTで接続できることと、Sparkplug仕様のトピック、ペイロード、状態管理を必要な役割で実装することは別です。製品の対象版、構成内の役割、受信側が状態を扱えるかを確認し、FAT/SATで実データと故障条件を試してください。

公式Compatible Products一覧にあればSATは省略できますか？

省略できません。一覧は製品の互換性プログラムに関する情報です。設備信号の意味、工場ネットワーク、時刻、証明書、画面表示、運用対応は自社構成で検証します。掲載製品でも製品版と組合せを確認してください。

MQTT Sparkplug Bの導入費用は何で決まりますか？

接続対象、既設機器の能力、Edge Node・Server・Hostの調達範囲、データ辞書、画面とMES改修、OT審査、FAT/SAT、教育、保守で決まります。まず役割別と作業別の見積を取り、同じ対象信号・試験条件で比較します。この記事に一律の価格や削減率は置いていません。

90日で全工場展開を決められますか？

90日は例示したパイロット期間です。対象設備と業務に必要な変動を観測し、未観測の故障を試験で補い、残余リスクを明記して次段階を判断します。設備停止窓、調達、サイバーセキュリティ審査によって期間は変わります。

まとめ

MQTT Sparkplug Bの導入は、名前の付いた通信機能を買うだけでは完結しません。仕様版、役割、Metric辞書、セッション状態、互換性証拠、OT運用を一つの受入条件へ結び、FATとSATで再現できるかを確認します。90日パイロットは期間の長さより出口条件が重要です。異常時の振る舞いと責任を契約前に明確にできれば、タイ工場の実証から複数ラインへの展開を判断しやすくなります。

RFPの項目整理やFAT/SATの試験範囲を検討している段階でも、対象設備と利用先が分かる資料があればお問い合わせからご相談ください。現状の取得方式と運用制約を踏まえ、比較に必要な確認事項を一緒に整理できます。

参考資料

• Eclipse Foundation：Sparkplug Specification（仕様と改訂履歴）
• Eclipse Foundation：Sparkplug 3.0.0 Specification PDF（本文、2022年版）
• Eclipse Foundation：Sparkplug Compatible Products（掲載製品）
• Eclipse Foundation：Get Listed（掲載手続き）
• Eclipse Foundation：Sparkplug TCK Process（互換性評価の位置づけ）
• OASIS：MQTT Version 5.0（通信プロトコル）
• NIST：SP 800-82 Rev.3（OTセキュリティ指針）