MQTT｜軽量Pub/Sub通信規格

2025.10.04

MQTT

MQTTは軽量なpublish/subscribe型メッセージングプロトコルであり、低帯域・高遅延・不安定回線でも確実な収集・配信を狙う設計である。通信は通常TCP/IP上で動作し、中心にbroker（サーバ）があり、多数のclient（センサ、PLC、ゲートウェイ、クラウド機能）が非同期に接続する。clientはtopicに対してpublish（送信）またはsubscribe（購読）し、brokerが配送仲介を担う。小さなヘッダと選べるQoSにより、IoTや産業ネットワークで広く採用される。

Table Of Contents

基本構成と用語

中心要素はbrokerとclientである。clientはCONNECTでMQTTセッションを開始し、SUBSCRIBEでtopicを購読、PUBLISHでメッセージを送信する。topicは階層文字列（例：factory/line1/robot/pos）で、サーバ側はACLで発行・購読権限を制御する。QoSは0/1/2の3段階で配信保証度合いが異なる。retain、last will、sessionなどの機能が実運用の信頼性を補強する。

プロトコルの流れ

clientはTCP接続後にMQTT CONNECTを送り、brokerのCONNACKで合意される。運用中はkeep alive（PINGREQ/PINGRESP）で死活を検知し、ネットワーク断時は再接続と再送で回復を図る。clean start（v5）や旧来のclean sessionを用いて永続化の有無を選び、session expiry interval（v5）で保持期間を指定できる。disconnect時にはDISCONNECTで正常終了理由を伝える。

QoSと配信保証

  • QoS 0（at most once）：ベストエフォート。確認応答なしで最小オーバーヘッド。瞬時性重視のテレメトリに適する。
  • QoS 1（at least once）：PUBACKで確認し、重複配信の可能性がある。受信側は冪等処理が必要。
  • QoS 2（exactly once）：PUBREC/PUBREL/PUBCOMPの4段階ハンドシェイクで重複も欠落もしない。レイテンシとオーバーヘッドは最大。

retain・last will・永続セッション

retainは最新メッセージをbrokerに保持し、新規subscriberへ即時配布する。状態値（例：運転モード）に有効である。last willはclient異常切断時にbrokerが遺言メッセージを発行し、監視系が故障検知可能にする。永続セッションでは未達メッセージやSUBSCRIBE情報が保存され、再接続後に欠損なく受領できる。

トピック設計とワイルドカード

topicは階層を明確にし、装置ID・ライン名・信号種別・時系列を規則化する。ワイルドカードは「+」が1層、「#」が末尾以降全層にマッチする。命名はsnakeやkebabなどの一貫した規約を選び、メタデータはpayload側（JSON/CBOR/Protobufなど）に載せるとよい。過大payloadは遅延と再送コストを増やすため、分割や圧縮を検討する。

セキュリティと接続方式

本番運用ではTLSで暗号化し、ポート8883を用いるのが一般的である。認証はusername/password、X.509証明書、トークン方式などを組み合わせ、brokerのACLで発行・購読の粒度を制御する。ファイアウォール越しにはHTTPS互換のWebSocket（通常443/TLS）でMQTTをトンネリングでき、プロキシ環境でも接続性を確保しやすい。

産業用途での実装ポイント

工場ではゲートウェイがPLCやフィールドバスのデータをMQTTへブリッジする。store-and-forwardによりオフライン時に一時保管し、復帰後に整合を取って送出する。時刻同期（NTP）と単調増加タイムスタンプで重複・並び替えを判定し、QoS 1/2の選択と受信側の冪等化で再送の影響を抑える。冗長化はbrokerクラスタやフェイルオーバー、永続ストレージで担保する。

運用・監視とスループット設計

接続数、inflight window、メッセージサイズ、発行レートを事前容量設計する。バックプレッシャとレート制限で混雑を緩和し、再接続ストームを避ける。$SYS系統の監視トピックやログ、メトリクスで遅延・ドロップ・再送比率を可視化する。クライアント側は指数バックオフや再接続ジッタでbroker負荷を平準化する。

品質・可用性を高める設計パターン

重要データはQoS 1/2＋永続セッション、状態データはretain、心拍は短いkeep alive、イベントは小粒化が有効である。受信側は重複排除のためmessage idやpayload内シーケンスで冪等更新にする。帯域が細い場合は二段階topic（速報と確定）や差分配信、圧縮を組み合わせると効果が高い。

MQTT v5の主な拡張

MQTT v5ではreason codeとpropertiesが導入され、接続・発行・購読の結果を詳細に伝えられる。topic aliasでヘッダを削減し、最大パケットサイズ交渉や受信レート制御で混雑を抑制する。user propertiesでメタデータを拡張し、response topicとcorrelation dataによりREQ/RESPスタイルのやり取りが容易になった。shared subscription（$share/）は複数consumerで負荷分散を実現する。

ブローカ選定の補足

評価軸はスループット、永続化方式、クラスタ機能、ACL表現力、監視API、WebSocket対応、TLS終端、運用ツールの成熟度である。PoCでは単一ブローカで良いが、量産では水平スケールやディスク耐障害性、ロールアップグレードの手順まで検証し、SLAに沿って設定を固定化する。クラウド運用時はマネージドMQTTサービスの可用性・料金・地域冗長性を比較する。

コメント（β版）