MQTT プロトコル徹底解説：公開/購読モデル、3段階の QoS、5.0 の新機能

zeruns · 2026 年 7 月 23 日午後 1:55

IoTプロジェクトを少しでもやったことがあるなら、まず間違いなく目にする言葉があります。MQTTです。家庭のスマート電球から畑の土壌センサー、工場の工作機械、道端のシェアサイクルまで、何十億台ものデバイスがこの1999年に生まれたプロトコルで互いに通信しています。なぜMQTTはIoTの事実上の標準になったのでしょうか。HTTPと比べて、いったい何が強いのでしょうか。この記事では、Pub/SubモデルからQoS 3段階、遺言メッセージ、MQTT 5.0の新機能までを解説し、プロトコル比較とそのまま実行できるPythonコードも紹介します。MQTTを一度で整理して理解できるよう、丁寧に紐解いていきます。

一、スマート温室の例から考える：なぜIoTではHTTPだけでは足りないのか

典型的なスマート農業温室を想像してみましょう。田畑に数百個の温湿度センサー、照度センサー、土壌水分センサーが点在し、それらはバッテリーと太陽光パネルで動作しています。安定しない4Gネットワークを通じてデータをクラウドにアップロードし、クラウド側はリアルタイムデータをもとに、カーテン、ファン、灌漑バルブを遠隔操作します。

設計レビューで、開発チームが最初に思いつくのはたいてい「HTTPでいいじゃん。POSTすれば終わりでしょ」という発想です。考え方自体は間違っていません。しかし、通信品質が弱い環境、数百台から数千台のデバイス、さらに24時間365日オンラインである必要がある現実の場面では、HTTPの弱点がすべて露呈します。

クラウド側から能動的にプッシュできない。HTTPはリクエスト／レスポンス型です。クラウド側が「ファンを回して冷却せよ」という命令を下したい場合、デバイスが次にポーリングしてくるまで待たなければなりません。ポーリング間隔を長くすると命令の遅延が気になりますし、短くすると数千台のデバイスが一斉にポーリングするため、サーバーとネットワークが無意味なリクエストで埋め尽くされます。
ヘッダのオーバーヘッドが大きすぎる。HTTPリクエストはヘッダだけで数百バイトになることがあります。一方、デバイスが本当に送りたいデータは十数バイトだけかもしれません。たとえば温度値「26.5」を送るだけなのに、まるで大きな段ボール箱で紙切れを宅配するようなものです。
電力消費に耐えられない。通信のたびに完全なTCP＋TLSハンドシェイクが必要になると、バッテリー駆動のセンサーにとっては、無線モジュールが1秒多く動作するだけでコスト増につながります。

これは農業シーンだけの問題ではなく、IoT業界全体に共通する課題です。大量のデバイス、弱いネットワーク環境、低消費電力の制約、双方向のリアルタイム通信。HTTPは人がウェブページを閲覧するために設計されたもので、機械同士がおしゃべりするために設計されたものではありません。そしてMQTTは、まさにそのために生まれました。

二、MQTTとは何か：「節約」のために生まれたプロトコル

MQTTはもともと、Message Queuing Telemetry Transport（メッセージキューイング・テレメトリ・トランスポート）の略でした。ただし現在では、公式にはこれを略語として扱っていません。プロトコル内部には、従来の意味でのメッセージキューは存在しないため、この名前はむしろ歴史的な名残です。

その出自を見ると、MQTTが何のために生まれたのかがよく分かります。1999年、IBMのAndy Stanford-ClarkとArcom社のArlen Nipperが、このプロトコルを設計しました。当時のユースケースは、衛星回線を使って荒野を横断する石油パイプラインを監視するというものでした。衛星通信は従量課金で、帯域は極めて狭く、遅延も大きい。さらに沿線の監視デバイスはバッテリーで動作していました。そのため設計目標は非常に素朴でした。メッセージは小さく、プロトコルは省電力で、ネットワークが切れても耐えられること。この3つの素朴な目標が、MQTTの現在まで続くDNAを形作りました。

メッセージが極めて小さい：固定ヘッダは最小2バイト。HTTPが数百バイト単位のテキストヘッダを使うのと比べると、極限まで省いています。
軽量：TCP上で動作します（デフォルトポートは1883、TLS暗号化時は8883）。数十KBのメモリを持つマイコンでもMQTTクライアントを動作させられます。
不安定なネットワーク向けに設計されている：ハートビート、遺言メッセージ、段階化されたQoSなど、「切断しても身を守る」仕組みを一通り備えています。

2013年ごろ、IBMはMQTTをOASIS標準化団体に提出しました。2014年にはMQTT 3.1.1がOASISの正式標準となり、後にISO国際標準（ISO/IEC 20922）にも採用されました。現在の主流バージョンはMQTT 3.1.1とMQTT 5.0（2019年公開）です。5.0が現在の推奨バージョンであり、後ほど詳しく説明します。

eeClub-電子エンジニアコミュニティ：https://bbs.eeclub.top/

電子／マイコン技術交流QQグループ：2169025065

三、中核アーキテクチャ：「電話」ではなく「新聞購読」

MQTTを理解するには、その通信モデルである**Pub/Subモデル（Publish/Subscribe、発行／購読モデル）**を理解するのが最も重要です。

HTTPのリクエスト／レスポンスモデルは、電話をかけるようなものです。相手の番号に電話をかけて直接会話します。双方が同時にオンラインである必要があり、互いの「番号」を知っている必要があります。

一方、Pub/Subモデルは新聞を購読するようなものです。新聞社（発行者）が新聞を印刷して郵便局（Broker）に届けます。あなた（購読者）は事前に郵便局で「私は科学面を購読します」と登録しておきます。毎日新聞が届くと、郵便局は登録リストに従って配達します。新聞社は読者が誰なのか知らず、読者も新聞社の電話番号を知る必要がありません。双方は完全に結合が外れ、郵便局だけが唯一のハブになります。

このモデルには、次の3つの中核的な役割があります。

Publisher（発行者）：メッセージを生成するデバイスまたはプログラム。たとえば温度を報告するセンサーです。
Broker（仲介サーバー）：システム全体の「郵便局」です。メッセージを受け取り、トピックに応じてすべての購読者に配信します。接続、セッション、保持メッセージなども管理し、パブリックネットワークから到達できる必要がある唯一の存在です。
Subscriber（購読者）：特定の種類のメッセージに関心を持つデバイスまたはプログラム。たとえばスマホアプリやデータダッシュボードです。

なお、発行者と購読者は論理的な役割にすぎません。同じデバイスが発行者と購読者の両方を兼ねることも十分に可能です。カメラがクラウドにアラートを公開しながら、クラウドから下される制御命令を購読する、といったケースです。また、デバイスはBrokerへ外に向けて接続するだけでよく、自分自身がパブリックIPを持つ必要も、ポートを開放する必要もありません。そのため、NATやファイアウォールの問題を自然に回避できます。これも、MQTTが「デバイスがポートを開いて接続を待つ」ような方式よりも人気になった大きな理由です。

Topic：郵便局の「 mailbox番号」

メッセージはどうやって配信されるのでしょうか。答えは**Topic（トピック）**です。TopicはUTF-8文字列で、/によって階層化されます。ファイルパスのように見えます。

home/livingroom/temperature
home/livingroom/humidity
home/bedroom/temperature

購読時には、2種類のワイルドカードを使えます。

+ 単層ワイルドカード：ちょうど1階層にマッチします。たとえばhome/+/temperatureなら、リビングと寝室の温度をどちらも受け取れます。
# 多層ワイルドカード：その後の任意の階層にマッチしますが、末尾にしか置けません。たとえばhome/#なら、home配下のすべてのメッセージを受け取れます。

四、主要機能を1つずつ理解する

MQTTが弱いネットワーク環境でも通用するのは、巧妙に設計された一連の仕組みのおかげです。以下の機能は、面接でも実務でも最も頻繁に問われるポイントです。

1. QoS：メッセージ配送の3種類の「宅配サービス」

MQTTでは、メッセージ配送品質（Quality of Service）を3段階に分けます。宅配便の種類に例えると分かりやすいでしょう。

QoS 0 —— 最大1回（At most once）：普通郵便のようなものです。送ったらそれっきりで、確認も再送も行いません。失われる可能性はありますが、重複は絶対にありません。毎秒1回報告するリアルタイム値のように、高頻度で、多少失われても構わないデータに向いています。このフレームを逃しても、次の秒には新しい値が来るからです。
QoS 1 —— 少なくとも1回（At least once）：書留郵便のようなものです。受信側はPUBACKで確認を返す必要があり、送信側は確認を受け取れなければ再送します。到達は保証されますが、重複する可能性があります。確認パケットが途中で失われると、送信側がもう一通送るからです。アラートや状態変化など、「重複してもよいから失ってはいけない」メッセージに向いています。受信側では冪等処理を行う必要があります。
QoS 2 —— ちょうど1回（Exactly once）：双方が受領確認を行う専門配送のようなものです。PUBREC、PUBREL、PUBCOMPの4段階ハンドシェイクにより、重複も欠落も防ぎます。ただし、その分オーバーヘッドが最大で、速度も最も遅くなります。料金計算など、「1円でも多く引いたら事故になる」ような場面に適しています。

ルールは非常に単純です。QoSが高いほど信頼性は高まりますが、オーバーヘッドと遅延も大きくなります。エンジニアリング上は、デフォルトでQoS 1を選ぶのが最もコストパフォーマンスの良い折衷案であることが多いです。

見落としがちな重要な点として、QoSは発行側と購読側がそれぞれ宣言するもので、Brokerが実際に配信する際は両者の低い値を取ります。発行側がQoS 2を使っていても、購読側がQoS 0で購読していれば、最終的にはQoS 0で配信されます。そのため、「なぜ自分の高QoSメッセージが失われるのか」といった問題を調査する際は、必ず両端を確認してください。

2. 保持メッセージ（Retained）：郵便受けに貼られた付箋

通常のメッセージは「読んだら終わり」です。購読者がオンラインでなければ、メッセージは送られた後に消えてしまいます。しかし、公開時にRetainフラグを設定すると、BrokerはそのTopicの最後の1件の保持メッセージを保存します。その後、新しい購読者がそのトピックを購読すると、すぐにそのメッセージを受け取れます。

典型的な使い方としては、デバイスがオンラインになった後、自分の状態（「online」や現在のオン／オフ状態など）をRetained形式で公開します。こうすれば、アプリがいつ開かれても、デバイスの最新状態をすぐに見られます。次にデバイスが報告するまで待つ必要がありません。なお、保持メッセージはトピックごとに1件だけ保存され、新しいものが古いものを上書きします。あるトピックの保持メッセージを消したい場合は、そのトピックに空のペイロードを持つRetainedメッセージを公開すれば済みます。

3. 遺言メッセージ（LWT）：デバイスが残す「遺言」

**Last Will and Testament（遺言メッセージ）**は、MQTTの中でも最も人間味のある設計です。クライアントはBrokerに接続する際、事前に登録できます。「もし私がよく分からない形で死んだら（異常切断）、このメッセージを送っておいてください」と。

たとえばカメラが接続時に、遺言としてcamera/01/status = "offline"（Retained）を登録します。その後、デバイスが電源落ちしたりネットワークが切れたりして接続が異常に切れると、Brokerが代わりに遺言を公開します。するとすべての購読者はすぐに「このデバイスは落ちた」と分かります。Retainedと組み合わせれば、後からアプリを開いたユーザーにもオフライン状態が見えます。

4. Keep Alive：互いにまだ生きていることを確認する心拍

TCPは相手が「見せかけ上死んでいる」状態を感知するのが遅いため、MQTTはアプリケーション層にハートビートを追加しています。クライアントは接続時にKeep Alive間隔（たとえば60秒）を合意し、アイドル時には非常に小さいPINGREQメッセージを送ります。BrokerはPINGRESPで応答します。BrokerがKeep Alive時間の1.5倍以内にクライアントからのメッセージを一切受け取れない場合、そのクライアントは死亡したと判定し、接続を切断して遺言メッセージを発火します。

5. Clean Session：再接続後、私のことを覚えていますか

クライアントはClean Sessionフラグによって、Brokerにセッションを保持するかどうかを伝えます。0（永続セッション）に設定すると、Brokerはそのクライアントの購読関係と、オフライン中に逃したQoS 1/2のメッセージを記憶し、再接続後に追補して配信します。1に設定すると、再接続後はすべてゼロからやり直しになります。

MQTT 5.0では、この仕組みをClean Start（まったく新しく開始するかどうか）とSession Expiry Interval（セッション有効期限）に分割し、より正確に表現できるようになりました。たとえば、単に「永続／非永続」とするのではなく、セッションを24時間だけ保持する、といった指定が可能です。

6. パケット構造：2バイトから始まる極限圧縮

MQTTのパケットは、固定ヘッダ＋可変ヘッダ＋ペイロードの3部構成です。固定ヘッダの1バイト目の上位4ビットがパケットタイプ（CONNECT、PUBLISH、SUBSCRIBE、PINGREQなど、全部で14種類）を示し、下位4ビットがフラグです。その後には、可変長エンコードされた「残りの長さ」フィールドが続きます。これは最小1バイトで済みます。つまり、ハートビートパケットは合計2バイトで済むのです。これこそがMQTTの「軽さ」の根拠です。

五、MQTT 5.0：誠意あふれるアップグレード

2019年に公開されたMQTT 5.0は、軽量さを保ちながら、多くのエンジニアリング上の弱点を補いました。

Reason Code（理由コード）：ほぼすべてのレスポンスパケットに標準化された理由コードが付くようになりました。接続拒否や購読失敗が、あいまいな「失敗」ではなく、なぜ失敗したのかを明確に示します。
Properties（プロパティシステム）：パケットに柔軟なメタデータのキーバリューペアを付けられるようになりました。多くの新機能はこの仕組みを土台にしています。
Shared Subscription（共有購読）：複数の購読者が消費グループを形成します（例：$share/group1/topic）。同じメッセージはグループ内の1人にだけ配信されるため、負荷分散が自然に実現できます。これは3.1.1の時代にはかなり回りくどいことをしないと実現できませんでした。
Message Expiry Interval（メッセージ有効期限）：公開時にメッセージの有効期限を設定できます。期限切れのオフラインメッセージは追補配信されないため、デバイスがオンラインになった瞬間に古い命令の嵐で襲われるのを防げます。
その他の改善：トピックエイリアス（長いトピック名の代わりに短い番号を使って通信量を節約）、Receive Maximumによる流量制御、サーバー側からの能動的な切断通知、Response Topicに基づくリクエスト／レスポンスモデルのサポートなど。

一言でまとめると、3.1.1は十分使える、5.0は使いやすい、新規プロジェクトでは最初から5.0を選ぶのがおすすめです。

六、横比較：MQTT vs HTTP vs CoAP vs WebSocket

MQTTが良いと言うだけでは不十分です。プロトコルの山の中で比較して初めて、その位置づけがはっきりします。

観点	MQTT	HTTP	CoAP	WebSocket
通信モデル	発行／購読	リクエスト／レスポンス	リクエスト／レスポンス（REST風）	フルデュプレックスデータストリーム
転送層	TCP	TCP	UDP	TCP
最小パケットオーバーヘッド	2バイト	ヘッダ数百バイト	4バイト	フレームヘッダ2バイトから
クラウド側からの能動的プッシュ	標準対応	非対応（ポーリング改造が必要）	Observeと組み合わせが必要	対応
メッセージ信頼性機構	内蔵の3段階QoS	TCPに依存	任意のACK／再送	なし、自作が必要
低消費電力対応	優秀	劣る	優秀（UDPの方が省電力）	普通
典型的な適用シーン	デバイスのクラウド接続、テレメトリ、遠隔制御	ウェブ、オープンAPI、ファイル転送	極めてリソース制約の大きいセンサーネットワーク	ウェブのリアルタイムインタラクション、チャットルーム

一言で位置づけるなら、HTTPは人向け、WebSocketはブラウザ向け、CoAPは極限まで制約の大きいデバイス向け、MQTTは「大量のデバイス＋弱いネットワーク＋双方向リアルタイム」のシーン向けです。

七、代表的な利用シーン：実は毎日使っているかもしれない

スマートホーム：MQTT最大の基本盤です。オープンソースプラットフォームのHome Assistantでは、多数のデバイスがMQTT経由で接続されています。ご自宅の照明、コンセント、温湿度計も、今この瞬間どこかのBrokerと長時間接続を保っているかもしれません。
産業用IoT（IIoT）：工場のラインにあるPLC、工作機械、計測器がデータを工場レベルのBrokerにアップロードし、MESシステムや監視ダッシュボードが必要な分だけ購読します。Alibaba Cloud IoT、AWS IoT Coreなどのクラウドプラットフォームでも、デバイス接続層の主プロトコルはMQTTです。
車联网（コネクテッドカー）：車両管理プラットフォームはMQTTを通じて何万台もの車両に命令を下し、車両状態を収集します。QoSの段階化は、「位置報告は失われてもよいが、遠隔ロックは必ず届く必要がある」という差分ニーズにまさに合致します。
環境・農業モニタリング：畑の土壌センサー、貯水池そばの水質観測局はバッテリーと太陽光で稼働します。MQTTの低消費電力性と切断時のキャッシュ能力は、まさに必須要件です。

八、実践：10分で最初のMQTTメッセージを通す

机上で学ぶだけでは物足りません。実際の手間は、実は非常に低いです。

Brokerを選ぶ

EMQX：中国製のオープンソース。性能が非常に強く、ドキュメントも中国語にやさしく、さらにオンライン公開テストBroker broker.emqx.io もあります。練習用にはまずこれです。
Mosquitto：Eclipse財団のプロジェクト。C言語で書かれており、非常に軽量です。ラズパイでも動作するため、ローカルデバッグに向いています。
HiveMQ：Java系のエンタープライズ向けソリューション。商用サポートも充実しています。

クライアントツールを選ぶ

MQTTX：EMQが提供するクロスプラットフォームのデスクトップクライアント（CLI版、Web版もあり）。画面が直感的で、プロトコル調整には必須です。
mqtt-cli / mosquitto_pub、mosquitto_sub：コマンドライン派には使いやすいツールです。

そのまま動くPythonサンプル

依存関係をインストールします：pip install paho-mqtt

購読側（subscriber.py）：

import paho.mqtt.client as mqtt

def on_connect(client, userdata, flags, reason_code, properties):
    print("接続しました:", reason_code)
    client.subscribe("home/livingroom/temperature", qos=1)

def on_message(client, userdata, msg):
    print(f"受信 [{msg.topic}] {msg.payload.decode()}")

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.on_connect = on_connect
client.on_message = on_message
client.connect("broker.emqx.io", 1883, 60)
client.loop_forever()

公開側（publisher.py）：

import paho.mqtt.client as mqtt

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2)
client.connect("broker.emqx.io", 1883, 60)
client.publish("home/livingroom/temperature", "26.5", qos=1)
client.disconnect()
print("送信しました")

まず購読側を起動し、次に公開側を起動すると、購読側のターミナルに「26.5」というメッセージが表示されます。これが、IoTの世界で最小限の「心拍」です。

最後に一言。公開テストBrokerは全員で共有するものですから、機密データを絶対に送らないでください。本番プロジェクトでは、Brokerサービスを自前構築するか購入し、必ずTLS暗号化とアカウント認証を有効にしてください。

九、まとめ

MQTTの成功は、どれだけ先進的かという点にあるのではありません。その成功は、極めて抑制されていることにあります。「石油パイプライン＋衛星回線」という過酷な環境で鍛え上げられた、小さなメッセージ、低消費電力、弱いネットワークへの耐性は、まさに膨大なIoTデバイスの核心的な要求に命中しました。Pub/Subによる結合解除モデル、3段階QoSによる柔軟な信頼性、遺言メッセージや保持メッセージといった、「デバイスは落ちるもの」という現実を前提にした実務的な設計。それらが重なった結果、MQTTは今日のIoTにおける事実上の標準プロトコルになったのです。

スマートハードウェアやバックエンド開発を手掛けているなら、私のアドバイスはこうです。まずは公開 Broker と MQTTX でパブリッシュ／サブスクライブを一通り試してから、QoS とセッションの仕組みを改めてきちんと読むこと。この2つをしっかり理解すれば、MQTT の8割は身につけたようなものです。

30年前、荒れ地を横断していたあの石油パイプラインは、おそらく思いもしなかったでしょう。自分のために設計された小さなプロトコルが、今日では数十億台のデバイス上で動いているとは。技術の生命力は、往々にして、この「ちょうどよい」設計の中に隠されています。

トピック	返信	表示
基于合宙Air700E的4G环境监测节点（温湿度、气压等数据），通过MQTT上传阿里云物联网平台开源项目 / Open-Source Project ESP32 , 4G , Air700E , MQTT , Open-Source	41	2025 年 10 月 30 日
Arduino读取DHT11,DHT22,SHTC3温湿度数据嵌入式系统 / Embedded Systems Arduino , Consumer-Electronics , Espressif , ESP , ESP8266	47	2025 年 10 月 29 日
ESP8266接入阿里云物联网平台上传温湿度数据嵌入式系统 / Embedded Systems Arduino , Consumer-Electronics , Espressif , ESP , ESP8266	30	2025 年 10 月 29 日
提问的智慧（How To Ask Questions The Smart Way）公告与规则 / Announcements & Rules QA	87	2025 年 10 月 30 日
Hermes Agent 部署全指南，手把手教你搭建你的第一个AI助手教程与文档 / Tutorials & Documents AI	76	2026 年 5 月 9 日

MQTT プロトコル徹底解説：公開/購読モデル、3段階の QoS、5.0 の新機能

一、スマート温室の例から考える：なぜIoTではHTTPだけでは足りないのか

二、MQTTとは何か：「節約」のために生まれたプロトコル

三、中核アーキテクチャ：「電話」ではなく「新聞購読」

Topic：郵便局の「 mailbox番号」

四、主要機能を1つずつ理解する

1. QoS：メッセージ配送の3種類の「宅配サービス」

2. 保持メッセージ（Retained）：郵便受けに貼られた付箋

3. 遺言メッセージ（LWT）：デバイスが残す「遺言」

4. Keep Alive：互いにまだ生きていることを確認する心拍

5. Clean Session：再接続後、私のことを覚えていますか

6. パケット構造：2バイトから始まる極限圧縮

五、MQTT 5.0：誠意あふれるアップグレード

六、横比較：MQTT vs HTTP vs CoAP vs WebSocket

七、代表的な利用シーン：実は毎日使っているかもしれない

八、実践：10分で最初のMQTTメッセージを通す

Brokerを選ぶ

クライアントツールを選ぶ

そのまま動くPythonサンプル

九、まとめ

関連学習リソース

おすすめ記事

MQTT プロトコル徹底解説：公開/購読モデル、3段階の QoS、5.0 の新機能

一、スマート温室の例から考える：なぜIoTではHTTPだけでは足りないのか

二、MQTTとは何か：「節約」のために生まれたプロトコル

三、中核アーキテクチャ：「電話」ではなく「新聞購読」

Topic：郵便局の「 mailbox番号」

四、主要機能を1つずつ理解する

1. QoS：メッセージ配送の3種類の「宅配サービス」

2. 保持メッセージ（Retained）：郵便受けに貼られた付箋

3. 遺言メッセージ（LWT）：デバイスが残す「遺言」

4. Keep Alive：互いにまだ生きていることを確認する心拍

5. Clean Session：再接続後、私のことを覚えていますか

6. パケット構造：2バイトから始まる極限圧縮

五、MQTT 5.0：誠意あふれるアップグレード

六、横比較：MQTT vs HTTP vs CoAP vs WebSocket

七、代表的な利用シーン：実は毎日使っているかもしれない

八、実践：10分で最初のMQTTメッセージを通す

Brokerを選ぶ

クライアントツールを選ぶ

そのまま動くPythonサンプル

九、まとめ

関連学習リソース

おすすめ記事

関連トピック