MQTT（Message Queuing Telemetry Transport）は、Pub/Sub型のメッセージ配信プロトコルです。1999年にIBMのAndy Stanford-Clark氏とCirrus LinkのArlen Nipper氏が、石油パイプラインの監視用に低帯域・低消費電力を狙って設計しました。ヘッダがわずか2バイトと極めて軽量で、衛星回線や2G/3Gといった細い回線でも信頼性の高い通信を実現できる点が大きな特徴です。2014年にOASISで標準化され、2019年にMQTT 5.0が公開されました。AWS IoT Core、Azure IoT Hub、Google Cloud IoT Core（2023年終了）など主要クラウドや、Home Assistant、Node-REDが採用し、IoTの事実上の共通言語となりました。
この記事の目次
- Broker中心の3ピース構造
- 石油パイプラインからクラウドへ
- 工場・スマートホーム・車両
- HTTPやAMQPとの使い分け
- まとめ
Broker中心の3ピース構造
MQTTの登場人物はPublisher、Subscriber、Brokerの3者です。PublisherはセンサーやデバイスがTopicと呼ばれる文字列の階層パスにメッセージを送る役割で、SubscriberはそのTopicを購読し、メッセージが届いたら通知を受け取ります。両者は互いの存在を知らず、Brokerだけが配送経路を持つ点が大きな特徴で、デバイスを増減しても他のクライアントに影響を与えません。
Brokerは中央に立つ仲介サーバーで、Eclipse Mosquitto、HiveMQ、EMQX、VerneMQなどの実装が広く使われています。Topicは「factory/line1/temperature」のようにスラッシュ区切りで階層化でき、「factory/+/temperature」（1階層ワイルドカード）、「factory/#」（後段全部）といったワイルドカード購読も可能です。メッセージにはQoS（0/1/2）の指定があり、QoS 0は送りっぱなし、1は最低1回到達、2は重複なし1回到達を保証します。用途と回線の品質に応じて使い分けることで、軽量さと信頼性のバランスを調整できる柔軟さを備えています。
石油パイプラインからクラウドへ
MQTTは1999年にIBMのAndy Stanford-Clark氏（IBM Hursley研究所）と、Cirrus LinkのArlen Nipper氏が共同で開発しました。発端はアメリカの石油パイプライン監視で、衛星回線で遠隔地から数値データを集めるための低帯域・低消費電力プロトコルが求められていました。Pub/Sub型・固定2バイトヘッダ・接続維持(Keep Alive)・遺言メッセージ(LWT)といった、当時としては斬新な要素が組み込まれました。
2010年にIBMが仕様をロイヤリティフリーで公開し、Eclipse Foundationの「Paho」プロジェクトが各言語向けクライアントを整備します。2014年10月にOASISでMQTT 3.1.1が国際標準化され、IBM以外のベンダーも安心して採用できるようになりました。2019年3月にはMQTT 5.0が公開され、Reason Code・Topic Alias・User Properties・共有サブスクリプションといった企業向け機能が追加され、AWS IoT、Azure IoT Hub、Alibaba Cloud IoTなど主要クラウドが対応を発表しました。20年余りで「ニッチな産業プロトコル」から「IoTの共通言語」へと立場を変えた稀有な存在です。
工場・スマートホーム・車両
MQTTは工場のセンサーデータ収集で特に強みを発揮します。PLC・温度計・流量計・振動センサーを「factory/line1/sensor」のようなTopicでBrokerに集め、MES（製造実行システム）やSCADAがSubscriberとして購読する構成が一般的になりました。OPC UAと組み合わせて使うケースも多く、SiemensやBoschが対応ゲートウェイを提供しています。
家庭ではHome Assistantが標準でMQTT Brokerに対応し、ZigbeeやZ-Waveのゲートウェイから取り込んだセンサー状態をMQTT経由で配信します。コネクテッドカーの分野ではトヨタやBMWが車両テレメトリ収集にMQTTを利用していることが公表されており、数百万台規模の車両を1つのBrokerで束ねる事例もあります。農業IoTでは圃場の土壌水分・気温データを衛星回線でMQTTで送り続ける構成が定着しています。WebアプリでもRedisのPub/Subと並んでMQTT over WebSocketsが利用され、ダッシュボードのリアルタイム通知に使われるようになりました。
HTTPやAMQPとの使い分け
HTTPはWebの標準プロトコルで、JSON/ProtobufでRESTやgRPCのリクエスト・レスポンス型通信を行います。ステートレスで簡単に組めますが、デバイス側からのプッシュ通信や常時接続には向かず、ペイロードに加えてヘッダが数百バイトかかるため、細い回線では非効率です。MQTTはこのギャップを埋める軽量プロトコルとして、デバイスからクラウドへの常時接続・少量データ送信に特化しています。
もう一つの比較対象がRabbitMQやKafkaが代表するAMQP系の重量プロトコルで、こちらは企業内のメッセージング基盤として強力ですが、クライアントが大きく、IoTデバイスに直接載せるには重すぎます。そのため実際の現場では、IoT側はMQTT、クラウド内部はKafkaやAMQP、Web/モバイル側はHTTPS、とプロトコルを役割で組み合わせる構成が定番になっています。MQTTを採用する際はBroker運用の責任が発生するため、自前構築するかマネージドサービス（AWS IoT Core、HiveMQ Cloudなど）を選ぶかの判断が最初のポイントです。
まとめ
MQTTは1999年にIBMのAndy Stanford-Clark氏らが石油パイプライン監視用に設計した軽量Pub/Subプロトコルで、2014年にOASIS標準、2019年にv5.0が公開されました。工場・スマートホーム・車両・農業など多様な現場で「IoTの共通言語」として採用され、HTTPやAMQPと使い分けて利用されています。Brokerを中心に置くシンプルな構造が、20年を超えて愛され続ける理由です。
※本記事はIT用語辞典の手書きドラフトです。公開前に最新情報・出典を確認のうえ加筆修正してください。
コメント