今更だけどMQTTとAWS IoT Coreに入門してみる

はじめに

AWS IoT Core、10周年おめでとうございます！

普段はIoTの分野とは無縁だったのですが、先日たまたま業務で携わる機会がありまして...
その際に一からMQTTやAWS IoT Coreを入門したので、自分なりにまとめてみたいと思います。

MQTT とは？

MQTTは「Message Queuing Telemetry Transport」の略称です。

Message Queuing
一時的にデータをためて、順番に処理する仕組み。
(※Queuingとありますが、MQTTはキューでは無いです）

Telemetry
遠隔からデータを収集し、そのデータを分析・監視を行う技術全般。

Transport
データの転送。

つまり...
MQTTは「遠隔地などからデータを収集し、中継地点に一時的にためて、別のシステムへデータを転送する」ような通信プロトコルです。(ムズイ...)

少しずつ踏み込んでみます。

MQTTは「Pub/Sub型」のメッセージングプロトコル

MQTTは、「Publish/Subscribe型 (Pub/Sub型)」のメッセージングプロトコルに対応しています。
メッセージングプロトコルは、システム間でメッセージをやり取りするための決まり事です。

■ 構成要素

説明に登場する構成要素の説明です。

パブリッシャー
メッセージを送る人です。

サブスクライバー
メッセージを受け取る人です。

トピック

トピックは、メッセージを仕分け・分類する入れ物のようなものです。
入れ物には「world/japan/sapporo」のように識別するタグが付いています。

特徴1. 通信が疎結合になる

Pub/Subでは、「パブリッシャー」はメッセージを「トピック」に送信します。
「サブスクライバー」はそのトピックにメッセージが到着するのを待ちます。

つまり、メッセージの送受信は、「トピック」を介して行われ、パブリッシャーとサブスクライバーが直接やり取りしません。

これにより送信側（パブリッシャー）と受信側（サブスクライバー）は互いの存在を意識する必要がなくなり、システムが疎結合になります。

仮にパブリッシャーとサブスクライバーが直接メッセージをやり取りする構成だった場合、以下の点でやり取りが複雑になります。

• パブリッシャーは、送信先（受信者）を明示的に指定する必要がある
• サブスクライバーは、受信の準備や接続状態の維持が必要になる

特徴2：多 対 多の通信ができる

Pub/Subでは、多 対 多の通信も可能です。
「パブリッシャー」は、ただ「トピック」へメッセージを送るだけで、該当トピックを参照している全ての「サブスクライバー」に届きます。

一方、HTTPなどのように送信先を指定する通信であれば、複数の受信者にメッセージを届けるには、それぞれに対して個別に接続・送信する必要があります。

結果的に、通信の構成が複雑になり、送信側の負担も増加します。

特徴3：双方向通信ができる

Pub/Subでは、双方向通信にも対応しています。
パブリッシャーとサブスクライバーの役割は固定ではなく、送信も受信も行うことが可能です。

MQTTは「IoT」の分野で大活躍

MQTTは「Publish/Subscribe型」のメッセージングプロトコルであり、疎結合・多対多通信・双方向通信といった特徴を持っています。

この特徴を活かして、MQTTは「IoT」の分野で活躍しています。

IoT とは？

IoTは「Internet of Things」の略称です。直訳すると「モノのインターネット」です。

ここで指す「モノ」とは、スマホ、家、車などを指します。何気なく使っている車、家の照明といった身近なものから、工場の温度、振動といったセンサーといった「モノ」もあります。

これらの「モノ」が「インターネット」と繋がる仕組みが「IoT」です。

例えば、「モノ」を操作したり、データを分析したり、監視したりといったように、身近な生活を便利にしたり、仕事に使われたりします。

改めてMQTTとは

MQTTは、主にIoTの分野で活躍し、Publish/Subscribeでメッセージをやり取りする通信プロトコルです。

MQTTクライアント

メッセージを送信(パブリッシュ)するIoTデバイスなどが該当します。
センサーやスマート家電などが、メッセージをMQTTブローカーに送信します。

MQTTブローカー

MQTTクライアントから送られたメッセージをトピックごとに仕分けし、そのトピックを参照しているサブスクライバーへメッセージを配信します。

MQTTトピック

メッセージの分類・仕分けに使われる入れ物です。

MQTTクライアントはこのトピックにメッセージをパブリッシュし、
サブスクライバーはそのトピックをサブスクライブすることでメッセージを受け取ります。

MQTTの仕組み

メッセージを送る大まかな流れ

大きくは以下のステップを踏んで、メッセージをやり取りが行われます。

1. MQTTクライアント ⇔ MQTTブローカー間の接続を確立する
2. トピックをSubscribeして受け取る準備をする
3. トピックへメッセージをPublishする
4. 最後はDisconnectで接続を終了する

1. MQTTクライアント ⇔ MQTTブローカー間の接続を確立する

MQTTクライアントは、TCP/IPプロトコルを用いて、MQTTブローカーへ接続します。

• 接続時のリクエストではCONNECTパケットを送信します
• 接続が問題なければレスポンスとしてCONNACKパケットが返ります

また接続の際、TLS/SSLによる暗号化や証明書などによる認証・認可することも可能です。
(このあたりはMQTTブローカーが提供している機能に依存しますが、基本的には使えると思います)

2. トピックをSubscribeして受け取る準備をする

メッセージを受け取るMQTTクライアントは、トピックをSubscribeして、メッセージを受け取る準備をします。

• SubscribeのリクエストでSUBSCRIBEパケットを送信します
• 問題が無ければレスポンスでSUBACKパケットが返ります

Subscribeを止める時
リクエストでUNSUBSCRIBEパケットを送信します
レスポンスでUNSUBACKパケットが返ります

3. トピックへメッセージをPublishする

MQTTクライアントは、該当のMQTTトピックへメッセージをPublishします。
Publishされたメッセージは、Subscribeしている全てのMQTTクライアントへ届きます。

• PublishのリクエストでPUBLISHパケットを送信します
• Publishでは特にレスポンスは返りません

4. 最後はDisconnectで接続を終了する

MQTTクライアントはMQTTブローカーとの接続を終了します。

• リクエストでDISCONNECTパケットを送信します
• 特にレスポンスは返りません

そのほかMQTTが提供する機能達

そのほかMQTTには以下のような機能があります。(これでも一部です)

MQTT自体はプロトコルなので接続のお約束事です
そのため、実際にこれらの機能を実現・管理してくれるのは、MQTTブローカーになります。

■ QoS (Quality of Service)

QoSは、MQTTで送信するメッセージの品質を決めるMQTTの機能です (0～2まである)

• QoS 0： 1回だけ送信するよ
• QoS 1：絶対に１回は届くように送信するよ。でもごめん！重複するかも…
• QoS 2：絶対に１回は届くように送信するよ。重複もないよ！でも通信が遅くなっちゃうかも…

■ Retained Messages

Retained Messagesは、MQTTブローカーが最後に届いたメッセージを残しておいて、誰かがSubscribeしてきたら残ったメッセージを送信するMQTTの機能です。

■ LWT（Last Will and Testament）

日本語訳すると「遺言」という意味です。
遺言を書いておくと、Publisherの接続が消えたら、Subscriberへ遺言を届けるMQTTの機能です。

■ Keep Alive

コネクションは生きてるけど、何らかの理由で通信できない場合、自動で切断してくれるMQTTの機能です。

AWSではMQTTブローカーにAWS IoT Coreが使える

AWSには、IoT向けのユースケースに対応するため、様々なサービスが存在します。
その中でも「AWS IoT Core」は、先ほど説明したMQTTブローカーの役割を、クラウド上でマネージドサービスとして提供しています。

AWS IoT Coreでは以下のコンポーネントがMQTTブローカーの役割を担っています

• DveiceGateway
  • デバイスからメッセージを受け取るゲートウェイです。
  • MQTTのみならず、下記の通信プロトコルに対応しています。
    • HTTPS
    • MQTT
    • MQTT over WebSocket
• Topic
  • 先ほど話したMQTTトピックです。
  • 実際には、メッセージの宛先を示す階層構造の文字列です。

さらに、AWS IoT Coreでは、Topicに届いたメッセージを他のAWSサービスに連携することも可能です。

• Rule Engine
  • トピックに届いたメッセージに対して条件を設定し、処理するためのSQLベースのルールです。
  • ィルタリング、日時を付与するなどメッセージを加工することもできます。
• Action
  • Rule Engineに基づいて実行され、条件に一致したメッセージを、S3、DynamoDB、Lambda、SNSなどのAWSサービスへ転送します。

ざっくりと必要最低限の要素を説明しましたが、要素や機能はまだまだあります。

そのほか補足

MQTTのバージョン (最新は5.0)

MQTTには、バージョンがあり、2025/9/29(月)時点で「5.0」が最新です。
MQTTの仕様については「OASIS」というところが定めており、詳細な「5.0」の仕様は以下になります。
(公開が「2019/3/7」なので結構前から変わっていないようですね)

過去分

どうやら最初は1990年代の後半には開発されていたようで、意外と歴史あるプロトコルのようです。

最後に

IoTやMQTTの初心者ではありますが、ひとまず勉強したことをまとめてみました。

初めは戸惑いますが、意外と手を動かすと楽しくて奥深いです！
近々、ラズパイなども買って自宅でIoTとかやってみたいと思ってます。

これからも業務で携わる機会が増えそうなので、新しく覚えたことは記事にしていきたいと思います！

参考情報