通信技術

MQTTとは何か——IoTとエッジAIをつなぐ軽量メッセージングプロトコルの仕組みから、QoS・トピック設計・セキュア運用まで徹底解説

open claw

• 16 min read
Share

はじめに——なぜIoTの「共通言語」がMQTTなのか

自宅の温度センサー、工場の設備、クラウド上のAIモデル——IoTの世界では、性格の異なる無数のデバイスが生み出すデータを、いかに低コストで確実に運ぶかが常に問われます。その答えとして、多くの現場で共通言語のように使われているのがMQTT（Message Queuing Telemetry Transport）です。

MQTTの歴史は、想像以上に過酷な環境から始まっています。1999年、MQTT公式FAQによれば、IBMのAndy Stanford-ClarkとArlen Nipperが、砂漠地帯を横断する石油パイプラインの遠隔監視システムのためにこのプロトコルを考案しました。現場と管制室を結ぶのは衛星回線。帯域は狭く、コストは高く、通信は不安定で、現場の機器は限られた電力で動かなければなりません。「乏しい帯域と電力でも確実に動く」——この厳しい制約の中で鍛えられた設計思想が、最小ヘッダわずか2バイトという徹底した軽量性として結晶しています。

その後、2014年にMQTT 3.1.1がOASIS標準となり（のちにISO/IEC 20922としても批准）、2019年には機能を大きく強化したMQTT 5.0が標準化されました。そして2026年現在、MQTTはIoT分野で広く採用される標準プロトコルの一つとなっています。スマートホームの定番Home AssistantはMQTT統合で対応機器を自動検出し、AWS IoT CoreはデバイスゲートウェイにMQTTを採用しています。産業IoTではSparkplug Bという運用規約がMQTTの上に定義され、ロボット分野でもROS 2とのブリッジに活用されています。25年前に砂漠のパイプラインのために生まれた発明が、いまや自宅のRaspberry Piからクラウドの大規模プラットフォーム、工場の現場までを同じ言葉でつないでいるのです。

本記事の到達目標は二つです。第一に、MQTTの仕組みを体系的に理解すること。パブリッシュ/サブスクライブモデルとブローカーの役割、QoS 0/1/2の到達保証レベル、トピック階層の設計、TLSとACLによるセキュア運用まで、「なぜそう設計されているのか」の根拠まで踏み込んで解説します。第二に、Raspberry Piに軽量ブローカーのMosquittoを立てて、実際にメッセージを送受信できるようになること。理論と実践の両輪で、読者のホームラボや開発環境にそのまま持ち帰れる知識をお届けします。

MQTTとは何か？——pub/subモデルとHTTPとの違い、軽量性の秘密

flowchart LR
    P1["温度センサー<br/>（Publisher）"] -- "publish: home/livingroom/temperature" --> B["MQTTブローカー"]
    P2["エッジAIデバイス<br/>（Publisher）"] -- "publish" --> B
    B -- "subscribe: home/+/temperature" --> S1["スマホアプリ<br/>（Subscriber）"]
    B -- "subscribe: home/#" --> S2["Home Assistant<br/>（Subscriber）"]

MQTT（Message Queuing Telemetry Transport）は、限られた帯域と電力で動くIoTデバイスのために設計された、軽量なメッセージングプロトコルです。その核心にあるのが「パブリッシュ/サブスクライブ（pub/sub）モデル」です。

HTTPがクライアントのリクエストに対してサーバーがレスポンスを返す1対1の対話であるのに対し、MQTTでは送信側（パブリッシャー）と受信側（サブスクライバー）が直接通信しません。間に立つ「ブローカー」と呼ばれる中継サーバーが、「トピック」という文字列のアドレスをキーにメッセージを振り分けます。たとえば温度センサーが home/livingroom/temperature というトピックへ値をpublishすれば、このトピックを購読（subscribe）しているクライアントすべてに同じメッセージが届きます。送信側は誰が受け取るかを、受信側は誰が送ったかを知る必要がなく、疎結合なシステムが自然に構築できます。

この差はHTTPとの対比でより明確になります。HTTPは基本的にクライアント主導のリクエスト/レスポンス型なので、サーバー側からデバイスへのプッシュ配信ができず、最新データを得るにはポーリングという非効率な繰り返しが必要です。一方MQTTはTCPコネクションを常時接続し、ブローカーから即時にプッシュ配信できます。1対多・多対多の配信はもちろん、購読側からトピックへコマンドをpublishする双方向通信も自然に書けます。さらにデバイス同士が互いのアドレスを知らなくてよいためNAT越えに有利で、Keep-Aliveによる接続維持と合わせてモバイル回線でも安定します。

軽量性の根拠はプロトコル設計そのものにあります。制御パケットの最小ヘッダはわずか2バイトで、HTTPのヘッダと比べてオーバーヘッドが極めて小さくなっています。公式にも「クライアントは非常に小さく最小限のリソースで動くため小型マイコンでも利用でき、非効率なネットワークでの使用に最適」と説明されており、リソースの限られたマイコンからRaspberry Pi、クラウドのマネージドサービスまで、同じプロトコルで横断できるのです。

歴史は1999年にさかのぼります。IBMのAndy Stanford-ClarkとArcom（現Eurotech）のArlen Nipperが、衛星回線でつながれた石油パイプラインの遠隔監視のために考案したのが始まりです。2014年にはv3.1.1がOASIS標準となり（ISO/IEC 20922として国際標準化）、2019年には理由コードや共有サブスクリプションといった拡張を含むv5.0が標準化されました。四半世紀以上の時を経て、IoTからエッジAIまでをつなぐ、広く普及した標準プロトコルへと育ったのです。

メッセージは確実に届くのか？——QoS・トピック設計・Retained・LWT・Keep-Alive

pub/subモデルでは、送ったメッセージが必ず届くとは限りません。電波状況の悪化や一時的な接続断でパケットは失われる可能性があります。MQTTが用意するのが、到達保証のレベルを3段階から選べるQoS（Quality of Service）です。

  • QoS 0（最大1回）: PUBLISHを送りっぱなしで、確認応答なし。最も軽量ですが、届かなければ諦めます。1件欠けても実害の少ない高頻度センサー値向きです。
  • QoS 1（最低1回）: PUBLISH→PUBACKの応答を確認し、未着なら再送します。その代わり重複が起こり得るため、アプリ側での冪等化（重複除去）が必要です。
  • QoS 2（厳密に1回）: PUBLISH→PUBREC→PUBREL→PUBCOMPの4ウェイハンドシェイクで、プロトコル上のメッセージ配送が厳密に1回となるよう設計されています。そのぶん往復が増えてオーバーヘッドは最大です。課金や制御コマンドなど、配送の重複・欠落ともに許されないデータ向きですが、アプリケーション側の処理（決済確定など）が確実に一度だけ実行される保証まではないため、業務処理の冪等性設計は別途必要です。
sequenceDiagram
    participant C as クライアント
    participant B as ブローカー
    Note over C,B: QoS 0（最大1回）: PUBLISHのみ・応答なし
    C->>B: PUBLISH
    Note over C,B: QoS 1（最低1回）
    C->>B: PUBLISH
    B-->>C: PUBACK（未受領なら再送）
    Note over C,B: QoS 2（厳密に1回）
    C->>B: PUBLISH
    B-->>C: PUBREC
    C->>B: PUBREL
    B-->>C: PUBCOMP

使い分けの指針はシンプルです。欠落より重複がマシならQoS 1、配送の重複も欠落も不可ならQoS 2、次の値がすぐに来るならQoS 0。ただしQoS 2が保証するのはプロトコル上の配送フローに対するもので、アプリケーション処理の重複排除（冪等化）は利用側の責任で設計してください。実際の配送には送信側とブローカー側の低い方が適用される点にも注意してください。電力も帯域も限られるエッジデバイスでは、QoS 2の多段応答がトラフィックと電力を圧迫するため、QoS 0/1中心の設計が一般的です。

トピック設計も運用の要です。トピックはスラッシュ区切りのUTF-8文字列で階層構造を持ちます。building1/floor2/room203/temperatureのように「対象→場所→種別→測定値」と意味単位で階層化するのが定石で、大文字小文字は区別されます。スペース・非ASCII・先頭スラッシュは避け、devices/{device_id}/...の形でデバイスIDを階層に含めると、トピック単位のアクセス制御（ACL）が書きやすくなります。

購読側だけはワイルドカードが使えます。+は1階層のみに一致（sensors/+/temperature）、#はそれ以降の全階層に一致し（sensors/#）、必ずトピック末尾に置きます。パブリッシュでのワイルドカード使用は禁止です。また$SYS/broker/...のような$始まりのトピックはブローカー内部用で、ワイルドカードのマッチ対象からは除外されます。

最後に、信頼性を支える3つの仕組みです。Retainedメッセージは、retainフラグ付きでパブリッシュするとブローカーがそのトピックの「最新値」を保持し、後から接続したサブスクライバーにも即時配信してくれます。現在の設定値や最終センサー値の共有に必須で、空ペイロードをretain付きで送ると削除できます。LWT（Last Will and Testament）は、接続時に「異常切断時にブローカーが代理で配信してほしいメッセージ」を登録しておく「遺言」です。そしてKeep-Aliveでは、接続時に秒数を指定し、クライアントはアイドル中もPINGREQを送り続けます。ブローカーは1.5×Keep-Alive秒以内に何も届かなければ切断と判定し、LWTを発火させます。デバイスの死活監視・オフライン検知にそのまま活用できる仕組みです。なお、cleanSession（v3.1.1）／セッション有効期限（v5.0）でオフライン中のメッセージ保持（永続セッション）を切り替えることもできます。

MQTT 5.0で何が変わったのか？——新機能と3.1.1からの移行ポイント

MQTT 5.0は2019年3月にOASIS標準となった、OASIS標準としては最新のバージョンです。多くの新機能は、実は「3.1.1で現場が困っていたこと」への回答という形で追加されました。代表的なものを「課題→解決」の対応で見ていきましょう。

「切断・拒否の理由が分からない」→理由コード（Reason Code）。 3.1.1では、接続やPublishがブローカーに拒否されても、クライアントには「なぜ失敗したのか」が伝わらず、デバッグに難がありました。5.0ではCONNACKやPUBACK、DISCONNECTといった応答に失敗理由を示すコードが付き、障害調査が格段に楽になります。

「セッション保持の制御が雑」→セッション有効期限。 3.1.1ではcleanSessionフラグのON/OFFでしか制御できませんでしたが、5.0ではオフライン中のメッセージ保持（永続セッション）の期間を秒単位で明示指定できます。

「長いトピック名が帯域を食う」→トピックエイリアス。 「factory/line-a/cell-03/temperature」のような長いトピック名を短い整数IDに置き換えて送信し、2回目以降はIDだけを送れます。繰り返し送信が多いセンサーデータでヘッダーを削減でき、低帯域回線で特に効果が大きくなります。

「複数ワーカーで消費できない」→共有サブスクリプション。 「$share/{group}/topic」の形式で購読すると、同じグループに属する複数サブスクライバーへメッセージがロードバランス配信されます。ワーカー消費パターンが実現し、MQTTがメッセージキュー的にも使えるようになりました。

このほかにも、ペイロードがUTF-8テキストかどうかの指定とMIMEタイプによるコンテンツタイプ付与、HTTPヘッダーのように任意のkey-valueペアを複数付けられるユーザープロパティ、相関データ（Correlation Data）とレスポンストピックを組み合わせたリクエスト/レスポンスパターン（MQTT上でのRPC的な往復）、未処理のQoS 1/2メッセージ数の上限を双方向で制限するフロー制御（Receive Maximum）と最大パケットサイズのネゴシエーションなどが加わり、プロトコルとしての成熟度が一段と上がっています。

では、3.1.1と5.0のどちらを採用すべきでしょうか。 両者は接続時のプロトコルレベルネゴシエーションで区別され、相互運用はレベル単位（5.0クライアントは5.0対応ブローカーへ接続）です。ただし公式ドキュメントで両対応が確認できるMosquittoや、AWS IoT Core（開発者ガイドにMQTT 5対応機能の節あり）をはじめ、主要なブローカーやマネージドサービスは多くが両方のバージョンに対応しています。新規開発では5.0を選び、理由コードによるデバッグ性の向上や、共有サブスクリプションによるワーカーのロードバランシング・水平スケールを活用するのがおすすめです。既存の3.1.1クライアントが残る環境でも、ブローカーが両対応していれば段階的な移行が可能です。

MQTTはどうセキュアに運用するのか？——TLS・クライアント証明書・ACL

MQTTはデフォルト設定では平文で動作するため、本番環境では多層防御が不可欠です。標準的なのは「三段構え」のセキュリティです。

第一段階は、TLSによる通信の暗号化です。 ブローカーの8883ポート（IANA登録済み）でTLS 1.2以降——近年はTLS 1.3——を有効にし、盗聴と改ざんを防ぎます。平文の1883ポートは閉域網や動作検証などの限定用途に留めるべきです。

第二段階は、クライアント認証です。 X.509クライアント証明書によるmTLS（相互TLS）なら、デバイス単位の強い認証を実現できます。AWS IoT Coreでは、このX.509証明書ベースの認証が基本となっています。証明書運用の負担を避けたい場合は、ユーザー名/パスワードによる簡易認証も選択できます。Mosquittoならpassword_fileとmosquitto_passwdコマンドで管理し、EMQXはDB・LDAP・JWT・OAuth2など複数の認証ソースをチェーンできます。ただしパスワードは必ずTLSと併用してください。MQTT 5.0のEnhanced Authを利用すれば、SCRAMなどのチャレンジ・レスポンス方式で、パスワード自体を平文送信せずに認証できます。

第三段階は、ACL（アクセス制御リスト）によるトピック単位の認可です。 接続を許したデバイスにも、必要最小限のトピックだけを読み書きさせる「最小権限」の設計が原則です。たとえば温度センサーにはsensors/room1/#へのpublishのみを許可し、他トピックの購読や書き込みは禁止します。

Mosquittoでの設定例は次のとおりです。

listener 8883
certfile /etc/mosquitto/certs/server.crt
keyfile  /etc/mosquitto/certs/server.key
allow_anonymous false
password_file /etc/mosquitto/passwd
acl_file /etc/mosquitto/acl

ACLファイルでは、デバイスごとに公開範囲を絞り込みます。

user sensor-room1
topic write sensors/room1/#

運用面では、デバイス個別の証明書発行と失効の仕組みづくり、ブローカー管理ポートの分離、$SYSトピックの保護も忘れないでください。ここで示した設定はあくまで推奨パターンの例であり、ポート番号のIANA登録（1883/8883）の確認を含め、実際の設定要件は各ブローカーの公式セキュリティドキュメントを参照してください。EMQXの認可モジュールやAWS IoTのポリシー（iot:PublishのトピックARN指定）など、実装ごとのACL機構を組み合わせれば、一台一台のデバイスに「何を・どこまで」許すかを厳密に制御できます。

どのブローカーを選ぶべきか？——Mosquitto/EMQX/HiveMQ/NanoMQ徹底比較

MQTTシステムの心臓部となるのがブローカーです。pub/subモデルではすべてのメッセージがブローカーを経由するため、実装の選定はシステム全体の信頼性とスケーラビリティを左右します。ここでは代表的な4つのブローカー——Eclipse Mosquitto、EMQX、HiveMQ、NanoMQ——を比較します。

Eclipse Mosquittoは、Eclipse Foundationが保守するC実装の定番ブローカーです。EPL/EDLデュアルライセンスで提供され、「軽量」を最大の武器に、Raspberry Pi級のマシンでも快適に動作します。MQTT 3.1.1と5.0の両方に対応しており、ドキュメントや事例も豊富。クラスタリングは基本的に単一ノード構成ですが、ブリッジ機能で上位ブローカーとの連携が可能です。

EMQXは上海発のEMQ Technologiesが開発するErlang/OTP実装です。Erlangの耐障害性と並列性を活かしたネイティブな分散クラスタリングにより、大規模同時接続に強い設計になっており、公式が公表するベンチマークでは数百万〜数千万コネクション級の同時接続を報告しています（接続数はハードウェア・構成など測定条件に依存するベンチマーク値であり、保証値ではありません）。オープンソース版はApache 2.0ライセンスで、次世代トランスポートとして注目されるMQTT over QUICを先行実装している点も見逃せません。

HiveMQはドイツ発のJava実装で、エンタープライズ向けの商用製品です（Community Editionも提供）。ネイティブクラスタによる高可用性に加え、管理GUIやDynamoDBなど外部サービスとの統合が充実し、ミッションクリティカルな企業IoTを支えます。「MQTT Essentials」シリーズなどの教育コンテンツでも著名です。

NanoMQはEMQ系プロジェクトのひとつで、C（NNGベース）・MITライセンスの超軽量ブローカーです。完全非同期IOとマルチスレッド動作により、車載機器やゲートウェイなどリソース制約の強いエッジ環境でも高速に動作します。MQTT over QUICに対応し、クラウド側の上位ブローカーへのブリッジも担えます。

4つの特徴を整理すると次のとおりです。

項目 Eclipse Mosquitto EMQX HiveMQ NanoMQ
実装言語 C Erlang/OTP Java C（NNGベース）
ライセンス EPL/EDLデュアル Apache 2.0（オープンソース版） 商用（Community Editionあり） MIT
クラスタリング 基本単一ノード（ブリッジで拡張） ネイティブな分散クラスタ ネイティブクラスタ エッジ単体向け（上位ブローカーへブリッジ）
得意規模 小規模〜中規模 大規模（公表ベンチマークで数百万接続級） エンタープライズ級の大規模・高可用 単一エッジノード
向く用途 自宅・学習・ホームラボ・ゲートウェイ 大規模IoTプラットフォーム・API基盤 ミッションクリティカルな企業IoT 車載・ゲートウェイなどリソース制約の強いエッジ

選び方の指針はシンプルです。自宅での実験やHome Assistantとの連携といったホームラボ用途なら、まずMosquittoを選べば間違いありません。数百万接続級の大規模IoTプラットフォームやQUICの実験にはEMQX、エンタープライズ支援や外部サービス統合が必要な企業本番にはHiveMQが適します。車載・産業ゲートウェイなどメモリとCPUに厳しい制約があるならNanoMQが有力です。多くの場合はMosquittoで小さく始め、接続数や可用性の要件が明確になった段階でEMQXやHiveMQへの移行を検討するという、段階的な進め方が現実的でしょう。

実践：Raspberry Pi + Mosquitto + Home AssistantでMQTTを動かす

まずは動かしてみるのが一番です。以下の手順とコマンド例は執筆時点（2026年10月）のRaspberry Pi OS・Mosquitto・Home Assistantを想定した代表的なものであり、バージョンによってオプション名や画面構成が異なる場合があります。最新の手順は各公式ドキュメントを参照してください。Raspberry Piに定番ブローカーのEclipse Mosquitto（C実装・EPL/EDLライセンス、Piクラスのマシンでも軽快に動作し3.1.1/5.0対応）を導入し、5ステップで自宅LANのMQTT環境を立ち上げます。

Step 1: Raspberry PiにMosquittoを導入し、pub/subを体験する

Raspberry Pi OSなら2コマンドでブローカーとクライアントツールが入ります。

sudo apt update
sudo apt install mosquitto mosquitto-clients
sudo systemctl enable --now mosquitto

ターミナルを2枚開き、片方で購読、もう片方で発行します。

# ターミナル1（サブスクライバー）
mosquitto_sub -h localhost -t "home/livingroom/temperature" -v

# ターミナル2（パブリッシャー）
mosquitto_pub -h localhost -t "home/livingroom/temperature" -m "25.6"

ターミナル1に「home/livingroom/temperature 25.6」が表示されたら成功です。送受信者が互いを知らなくても、トピック経由で配信される仕組みが体感できます。

Step 2: RetainedメッセージとLWTを試すミニ演習

第3節のRetainedとLWTも同じツールで確認できます。まずRetainedから。

mosquitto_pub -h localhost -t "home/livingroom/temperature" -m "25.6" -r
mosquitto_sub -h localhost -t "home/livingroom/temperature" -v

後から購読を始めたのに即座に「25.6」が届けば、ブローカーが最新値を保持して新規サブスクライバーに即時配信する動作の確認完了です（空ペイロードの発行で保持値を削除できます）。

次にLWT（異常切断時にブローカーが代理発行する遺言）です。Keep-Alive付きで接続したクライアントでは、PINGREQが「1.5×Keep-Alive秒」途絶えた時点で切断と判定され、遺言が配信されます。

# ターミナル1: 遺言トピックを購読
mosquitto_sub -h localhost -t "home/livingroom/status" -v

# ターミナル2: LWT登録＋Keep-Alive 5秒で接続
mosquitto_sub -h localhost -t "dummy/#" \
  --will-topic "home/livingroom/status" \
  --will-payload "offline" -k 5

# 別シェルからプロセスを一時停止（PINGREQが止まる）
kill -STOP $(pgrep -n mosquitto_sub)

約7.5秒後に「offline」が届けばLWT発火の観測完了です（再開はkill -CONT。プロセス停止の手法は環境により挙動が異なる場合があります）。この2つの仕組みの組み合わせで、センサーの死活監視が作れます。

Step 3: Home AssistantのMQTT統合＋Discoveryでセンサー値をダッシュボード化

Home Assistantは「MQTT」インテグレーションで多数のIoTデバイスを統合できます。設定→「デバイスとサービス」→「統合を追加」で、Mosquittoの動くホスト（例: raspberrypi.local:1883）を指定するだけです。

MQTT discovery対応機器は設定ファイルなしで自動検出・登録されます。機器側はhomeassistant/プレフィックスのトピックに、エンティティ種別や値トピックを記述した自己紹介メッセージを発行するだけ。自作センサーも1通で参加できます。

mosquitto_pub -h localhost -r \
  -t "homeassistant/sensor/livingroom_temp/config" \
  -m '{"name":"リビング温度","state_topic":"home/livingroom/temperature","unit_of_measurement":"°C"}'

これでダッシュボードに「リビング温度」エンティティが現れ、Step 1のトピックに流した値がリアルタイムで可視化されます。

Step 4: エッジAI・クラウド・産業システムでの使われ方

この構成はエッジAIの骨格にそのまま拡張できます。MQTTはセンサーデータの収集→集約→推論結果配信のバックボーンとして利用されます。たとえばPi上で人物検出を動かし、結果を edge/camera1/person_count のようなトピックに発行すれば、Home Assistantのオートメーションから直接トリガーできます。

クラウド連携の代表はAWS IoT Coreで、デバイスゲートウェイにMQTTを採用し、X.509証明書認証とポリシーでデバイス単位の認可を実現します。産業IoTではSparkplug B規約がペイロードとトピックを標準化し、unsubscribeセマンティクスで状態管理まで定義します。

Step 5: ロボット応用——ROS 2のDDSとの対比とmqtt_clientブリッジ

ROS 2の基本通信はDDSですが、コミュニティ提供のmqtt_clientパッケージでROS 2トピックとMQTTをブリッジできます。ロボット内部の高頻度通信はDDSのまま、クラウドや他システムとの連携だけMQTTに乗せる分担が現実的です。

これでブローカー導入からpub/sub、Retained/LWT、ダッシュボード化まで、動く環境が一通り揃いました。LANの外へ開放する前には、第5節のTLS・ユーザー認証（mosquitto_passwd）・ACLを必ず設定してください。今日から、あなたのホームラボでMQTTの運用が始まります。

よくある質問（FAQ）とまとめ——MQTTのこれから

Q1. MQTTとHTTPはどう使い分ける？

HTTPはクライアント主導のリクエスト/レスポンス型で、サーバーからデバイスへのプッシュが基本的にできず、ポーリングは帯域と電力の無駄になります。MQTTはTCP常時接続でブローカーから即時にプッシュでき、双方向・1対多の通信に向きます。最小ヘッダーが2バイトとHTTPよりオーバーヘッドが大幅に小さい点も違いです。API連携はHTTP、常時接続のテレメトリと制御はMQTTという使い分けが現実的です。

Q2. QoSはどれを使えばいい？

目安はデータの性質です。次の値がすぐ届く高頻度センサーデータなら、確認応答なしのQoS 0が適しています。欠落は許せないが重複は除去できるならQoS 1（少なくとも1回）で、再送による重複に備えて受信側を冪等に設計します。重複も欠落も許されない課金や制御コマンドだけ、4ウェイハンドシェイクのQoS 2（配送の厳密に1回）を使います。ただしQoS 2が保証するのはプロトコル上のメッセージ配送であり、アプリケーション処理の重複排除・仮等化は利用側で別途設計してください。実際に適用されるのは双方の低い方のQoSなので注意してください。

Q3. MQTT 3.1.1と5.0のどちらを採用すべき？

主要ブローカーとライブラリはすでに5.0対応が進んでおり、新規開発なら5.0が推奨です。理由コード、共有サブスクリプション、トピックエイリアス、拡張認証など運用に効く機能が揃います。3.1.1はISO/IEC 20922として標準化された枯れたバージョンで、古い機器との互換を優先する場面では依然有力です。接続先の対応状況を確認してから決めるのが安全です。

Q4. MQTTだけでセキュリティは足りる？

プロトコル単体では足りず、三段構えの運用が不可欠です。第一段階はTLSによる暗号化（ポート8883）、第二段階はクライアント証明書（mTLS）やユーザー名/パスワードによる認証、第三段階はACLによるトピック単位の読み書き制限です。温度センサーにはsensors/room1/へのpublishのみを許可すれば、鍵が漏れても被害を局所化できます。管理ポートの分離や$SYSトピックの保護も見直しましょう。

Q5. ブローカーはどれから始める？

学習と小規模運用なら定番のEclipse Mosquittoが最も手軽です。Raspberry Piでも動く軽量さで、ホームラボや小規模〜中規模なら十分機能します。本番は要件次第で、数百万コネクション規模やQUIC実験はEMQX、エッジゲートウェイはNanoMQ、エンタープライズ支援や外部サービス統合はHiveMQが候補です。まずMosquittoで感覚を掴み、要件が固まってから乗り換えるのが現実的です。

まとめ

MQTTの本質は、最小2バイトのヘッダーで動く軽量性、ブローカーが仲介するpub/subの疎結合、QoS 0/1/2で到達保証を選べる柔軟性です。トピック設計とTLS・mTLS・ACLのセキュア運用を組み合わせれば、ホームラボから産業IoT、エッジAIのデータバックボーンまで同じアーキテクチャで賄えます。今後はモバイル回線に強いMQTT over QUIC、UDP/QUICベースの次世代産業規約Sparkplug T、サーバーレス型のマネージドMQTTと選択肢が広がります。1999年に生まれたこのプロトコルは、IoTとエッジAIの時代にこそ本領を発揮するでしょう。

参考文献・出典

  • MQTT.org（公式サイト）: https://mqtt.org/
  • MQTT.org FAQ（考案者・標準化・ポート登録についての公式記述）: https://mqtt.org/faq/
  • IANA Service Name and Transport Protocol Port Number Registry: https://www.iana.org/assignments/service-names-port-numbers/
  • OASIS, MQTT Version 5.0 (OASIS Standard, 2019-03-07): https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html
  • OASIS, MQTT Version 3.1.1 (OASIS Standard, 2014-10-29): https://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html
  • Eclipse Mosquitto: https://mosquitto.org/
  • EMQX: https://www.emqx.com/
  • HiveMQ: https://www.hivemq.com/mqtt/
  • NanoMQ: https://nanomq.io/
  • Eclipse Sparkplug: https://eclipse.dev/sparkplug/
  • AWS IoT Core: https://aws.amazon.com/iot/
  • Home Assistant MQTT Integration: https://www.home-assistant.io/integrations/mqtt/

関連記事