MQTTとは？仕組みやPublish/Subscribe、HTTPとの違いを初心者向けにわかりやすく解説

まず結論：MQTTとは？

MQTTとは、IoT機器などが、小さなデータを効率よく送受信するための通信プロトコルです。

送る側と受け取る側が直接通信するのではなく、Broker（ブローカー）と呼ばれる仲介役を通してメッセージをやり取りします。

特に、センサーの温度情報や機器の状態などを、多数の端末から集める用途に向いています。

一言でいうと、MQTTは「IoT向けの軽量なメッセージ配送サービス」です。

MQTTはどういう仕組み？

MQTTでは、主に3つの役割を理解すれば十分です。

• Publisher
• Broker
• Subscriber

Publisherとは？

Publisher（パブリッシャー）は、メッセージを送る側です。

例えば、

• 温度センサー
• 湿度センサー
• 工場の機械
• スマート家電

などです。

温度センサーなら、

「現在の温度は25℃です」

というデータを送信します。

Brokerとは？

Broker（ブローカー）は、送られてきたメッセージを必要な相手へ届ける仲介役です。

PublisherはSubscriberへ直接送信しません。

まずBrokerへ送ります。

Publisher
   ↓
 Broker
   ↓
Subscriber

Brokerが間に入るため、送信側は、

「誰がこの情報を受け取るのか」

を細かく意識する必要がありません。

Subscriberとは？

Subscriber（サブスクライバー）は、メッセージを受け取る側です。

例えば、

• 管理者のスマートフォン
• 監視システム
• データ分析システム
• 別のIoT機器

などです。

PublishとSubscribeとは？

MQTTでは、

Publish（発行）

と

Subscribe（購読）

という言葉を使います。

Publisherがメッセージを送ることをPublishといいます。

Subscriberが、

「この種類の情報を受け取りたい」

と登録することをSubscribeといいます。

Topicとは？

「どの種類の情報か」を表す名前

MQTTでは、メッセージをTopic（トピック）ごとに分類します。

例えば、工場に温度センサーと湿度センサーがあるとします。

factory/temperature
factory/humidity

というTopicを作ります。

温度情報を受け取りたいSubscriberは、

factory/temperature

をSubscribeします。

すると、そのTopicへPublishされたメッセージだけを受け取れます。

Brokerに全部のデータが集まったら、ごちゃごちゃにならない？

そこでTopicを使うんだ。情報に名前を付けて分類するんだよ。

メールのフォルダーみたいなもの？

近いイメージだね。『温度の情報だけ欲しい』という受け取り方ができるんだ。

具体例：スマートホームで考える

家に温度センサーがあるとします。

温度センサーは、5分ごとに部屋の温度を測ります。

25℃

という情報を、

home/living/temperature

というTopicへPublishします。

Brokerがそのメッセージを受け取ります。

そのTopicをSubscribeしている、

• スマートフォン
• エアコン制御システム

へ情報を届けます。

温度センサー
     ↓
「25℃」
     ↓
Topic:
home/living/temperature
     ↓
   Broker
   ↓    ↓
スマホ  エアコン

スマートフォンでは現在温度を表示できます。

エアコン側では、

「28℃を超えたら冷房を入れる」

という処理もできます。

なぜIoTでMQTTが使われるの？

MQTTは、小さなデータを少ない通信量でやり取りしやすいように作られています。

IoT機器では、

• CPU性能が低い
• メモリが少ない
• 通信回線が遅い
• バッテリーを節約したい

といった条件があります。

例えば、温度センサーが送りたい情報は、

25.3℃

のような小さなデータです。

そのため、毎回大きな通信処理を行うよりも、軽量なMQTTが適している場合があります。

MQTTは多対1・1対多・多対多を実現できる

MQTTではBrokerが中央にいるため、多数の機器をつなぎやすい特徴があります。

例えば、多くのセンサーから一つの監視システムへ情報を集められます。

センサーA ─┐
センサーB ─┼→ Broker → 監視システム
センサーC ─┘

これは多対1です。

逆に、一つのセンサー情報を複数のシステムへ届けることもできます。

              → スマホ
センサー → Broker → 監視システム
              → データ分析

これは1対多です。

複数の送信者と複数の受信者を組み合わせることもできます。

PublisherとSubscriberは直接通信しない

MQTTで特に重要なのがここです。

Publisherは、

「このデータをスマートフォンへ送ろう」

とは考えません。

単純に、

「このTopicへデータをPublishする」

だけです。

Subscriberも、

「あの温度センサーへ接続しよう」

とは考えません。

「このTopicをSubscribeする」

だけです。

Brokerが両者をつなぎます。

送る側と受け取る側を分離できる

この仕組みを利用すると、後からSubscriberを追加してもPublisherを変更しなくて済む場合があります。

例えば、

最初は、

温度センサー
    ↓
 Broker
    ↓
スマホ

だけだったとします。

後からデータ分析システムを追加しても、

温度センサー
    ↓
 Broker
   ↓    ↓
スマホ  分析システム

とできます。

温度センサー側は、その存在を知る必要がありません。

MQTTとHTTPの違い

MQTTと混同するというより、

「普通にHTTPで送ればいいのでは？」

と疑問に思う方も多いでしょう。

違いを一言でいうと、

HTTPは相手へ直接リクエストする通信

MQTTはBrokerへメッセージを預ける通信

です。

MQTTとTCPの違い

ここも重要です。

MQTTとTCPは競合するプロトコルではありません。

MQTTは通常、TCPの上で動作します。

MQTT
 ↓
TCP
 ↓
IP

イメージとしては、

TCP＝データを確実に運ぶ道路

MQTT＝その道路を使ってメッセージを配るルール

です。

MQTTとWebSocketの違い

WebSocketも双方向通信に使われるため、MQTTと似て見えることがあります。

ただし役割が違います。

MQTTをWebSocket上で利用する構成もあります。

そのため、必ずどちらか一方という関係ではありません。

QoSとは？

MQTTには、メッセージをどの程度確実に届けるかを指定する**QoS（Quality of Service）**があります。

初心者は3段階あることだけ押さえておけば十分です。

QoS 0

「できれば届ける」

という軽量な方式です。

通信量を抑えられます。

例えば、数秒ごとに送る温度データなら、一回程度欠けても問題が小さい場合があります。

QoS 1

「少なくとも1回は届ける」

方式です。

同じメッセージが複数回届く可能性があります。

QoS 2

「正確に1回届ける」

方式です。

最も確実ですが、通信処理も増えます。

MQTTのメリット

通信が軽い

小さなデータを効率よく送れます。

多数のIoT機器を扱いやすい

Brokerを中心に、多数のPublisherとSubscriberを接続できます。

送信側と受信側を分離できる

PublisherはSubscriberを直接知る必要がありません。

システムを追加・変更しやすくなります。

通信品質を選べる

QoSによって、通信量と確実性のバランスを調整できます。

まとめ

MQTTとは、IoT機器などが、小さなデータを効率よく送受信するための軽量な通信プロトコルです。

最大の特徴は、PublisherとSubscriberが直接通信せず、Brokerがメッセージを仲介するPublish/Subscribe方式を採用していることです。

Subscriberは受け取りたいTopicを登録し、そのTopicへPublisherがメッセージを送ると、Brokerが該当するSubscriberへ配送します。

結局MQTTとは、

「IoT機器から集まる小さなメッセージを、Brokerが必要な相手へ配る仕組み」

と理解すれば十分です。

MQTTって難しい通信方式かと思ったけど、Brokerにメッセージを預けて、欲しい人に配ってもらうだけなんだね。

そう。まずはそれで十分だよ。

送る人がPublisher、仲介するのがBroker、受け取る人がSubscriber。

バッチリ。さらに『TopicをSubscribeする』まで分かれば、MQTTの基本はつかめているよ。

クマノくらげ

X

難しいIT用語やビジネス用語を、できるだけ身近な例えで解説するブログです。 「専門用語を見ると眠くなる人」でも読めるように、画像や会話形式を多めにしています。 AWS12冠達成済み。