MQTTとは

MQTT（Message Queuing Telemetry Transport）は、IoTデバイス向けに設計された軽量なメッセージングプロトコルです。1999年にIBMのAndy StanfordClark氏とEurotech（現Cirrus Link）のArlen Nipper氏が、石油パイプラインの監視用に衛星回線経由でセンサーデータを送るために原案を考案したのがルーツとされます。その後2013年にOASISへ仕様が寄贈されて標準化が進み、現在はOASIS標準であると同時にISO/IEC 20922としても国際標準化されています。低帯域幅・不安定な回線・低消費電力という制約の強い環境でのデバイス間通信に最適化されており、スマートホーム、産業用センサー、コネクテッドカー、物流トラッキングなど幅広いIoTシステムの中核プロトコルとして使われています。

技術仕様の要点は次のとおりです。トランスポート層には基本的にTCP/IPを使用し、非暗号化接続はポート1883、TLS/SSLによる暗号化接続はポート8883を使うのが慣例です。パケットのヘッダーは最小2バイトからと非常にコンパクトで、HTTPのようなテキストベースのヘッダー（数百バイト〜）と比べてオーバーヘッドが桁違いに小さいのが最大の特徴です。理論上のペイロード最大サイズは約256MBですが、実運用ではセンサー値やJSON形式のテレメトリなど数バイト〜数KB程度の小さなメッセージを高頻度に送るケースが大半です。MQTT自体は特定の無線規格や周波数帯を規定しない「アプリケーション層」のプロトコルであり、下位のネットワークにはWi-Fi（2.4GHz/5GHz帯）、Bluetooth Low Energy、セルラー通信（4G/5G）、Ethernetなど任意の伝送路を利用できます。回線の実効速度が数kbps程度しかないような狭帯域・省電力の無線（LoRaWAN等）向けには、後述のMQTT-SNという派生仕様が用意されています。

MQTTの基本的な仕組み

MQTTはPublish-Subscribe（パブサブ）モデルを採用しています。HTTPのようにクライアントが送信先のアドレスを直接指定するのではなく、送信側と受信側は「ブローカー」というハブを介して間接的につながる点が最大の設計思想です。

Broker（ブローカー）：全メッセージを仲介する中央サーバー（Eclipse Mosquitto、EMQX、AWS IoT Core等）。Publisherから届いたメッセージをトピック単位で管理し、該当トピックをSubscribeしている全クライアントに配信する
Publisher（発行者）：トピックに対してメッセージを送信するデバイス（温湿度センサー、GPSモジュール等）
Subscriber（購読者）：特定トピックのメッセージを受信するクライアント（監視サーバー、モバイルアプリ、ダッシュボード等）
Topic（トピック）：メッセージの宛先を表す階層構造の文字列（例：factory1/line3/sensor/temperature）。「/」区切りで階層化し、ワイルドカード+（1階層のみ一致）や#（それ以下すべてに一致）で柔軟な購読ができる

接続時の流れは、クライアントがブローカーへTCP接続を確立した後にCONNECTパケットを送り、ブローカーがCONNACKで応答して確立します。以降はPUBLISH（発行）、SUBSCRIBE/UNSUBSCRIBE（購読・解除）、そして接続維持のためのPINGREQ/PINGRESPという定期的なキープアライブ（既定では60秒間隔が多い）でやり取りされます。

実務で押さえておくべき補助機能が3つあります。1つ目はRetained Message（保持メッセージ）で、ブローカーがトピックの最新メッセージを保持しておき、新たに購読したクライアントへ即座に配信する機能です。センサーの「現在値」をすぐに取得したい場合に使います。2つ目はLWT（Last Will and Testament、遺言メッセージ）で、クライアントが正常切断せずに接続が切れた場合にブローカーが代理で送信する事前登録メッセージです。デバイスの異常切断・オフライン検知の定石として使われます。3つ目はClean Session/Session Expiryで、再接続時にサブスクリプションや未配信メッセージの状態を引き継ぐかどうかを制御します。MQTT 5.0ではSession Expiry Intervalとして秒単位で保持期間を指定できるようになりました。

MQTTのQoSレベル

MQTTでは、メッセージの到達保証レベルを送信ごとに選べるQoS（Quality of Service）という仕組みがあります。回線の不安定なIoT環境では、確実性と通信コスト・処理負荷はトレードオフになるため、用途に応じて使い分けます。

QoS 0（At most once）：最大1回送信。送達確認（ACK）を行わないため、パケロス時にメッセージが失われる可能性がある。最軽量・最速で、1秒間隔で送られる温度データのように多少の欠損が許容できる用途に向く
QoS 1（At least once）：最低1回送信。PUBACKによる受信確認を行うが、確認が届く前に再送されると受信側で重複する可能性がある。実運用で最もよく使われるバランス型で、重複排除はアプリ側でメッセージIDや冪等性設計により吸収するのが一般的
QoS 2（Exactly once）：正確に1回の送信を保証。PUBREC・PUBREL・PUBCOMPを含む4方向ハンドシェイクを行うため、通信回数と処理負荷が最も大きい。決済処理や制御コマンドなど、重複実行が業務上致命的な場面に限定して使うのが定石

なお、PublisherとSubscriberはそれぞれ異なるQoSを指定でき、実際に配信されるQoSは両者の設定のうち低い方に制限される点に注意が必要です。ブローカーの性能や回線品質を踏まえ、まずはQoS 1を既定にして、要件に応じてQoS 0・2を選択する設計が現実的です。

具体例・ユースケース

MQTTは業種を問わず「多数の末端デバイスから中央へテレメトリを集める」「中央から多数のデバイスへ一斉に指示を送る」という双方向多対多の通信が必要な場面で採用されています。代表的なユースケースを挙げます。

スマートホーム：Home Assistantなどのホームオートメーション基盤は、Eclipse Mosquittoをブローカーとして各種スマート照明・スマートプラグ・温湿度センサーとの通信に標準対応している。各デバイスがトピックへ状態をPublishし、アプリやハブがSubscribeして画面表示や自動化ルールに反映する構成が一般的
産業用IoT（IIoT）・工場の予知保全：工作機械やPLCの振動・温度・稼働状況をセンサーで収集し、MQTT経由でSCADA/historianへ送る構成が広がっている。Sparkplug Bという仕様は、MQTT上に統一されたペイロードフォーマットと状態管理（デバイスのオンライン/オフライン、タグの型）を定義し、Ignition等のSCADAソフトウェアとの相互運用性を高めている
コネクテッドカー・車両テレマティクス：走行データ・診断情報（DTC）・位置情報を、セルラー回線経由でクラウドのMQTTブローカーへ送信し、フリート管理やOTA（Over The Air）アップデートの起点として使われる
メッセージングアプリのリアルタイム通信：Facebook Messengerがバックエンドのプッシュ配信基盤としてMQTTを採用していたことは有名な事例で、モバイル回線でのバッテリー消費と通信量を抑えつつ即時性を確保する狙いだったと語られている
農業・環境モニタリング：圃場に設置した土壌水分・気象センサーの値を、LoRaWANゲートウェイ経由でMQTT-SN／MQTTブリッジを介してクラウドに集約し、灌漑の自動制御に利用するケースが増えている
物流・コールドチェーン管理：輸送コンテナや保冷車の温度・位置情報を定期送信し、規定温度からの逸脱をLWTやアラートトピックで即座に検知する運用が行われている

メリット・デメリット（注意点）

MQTT導入を検討する際は、以下のような特性を踏まえて設計する必要があります。

観点	メリット	デメリット・注意点
通信効率	ヘッダーが最小2バイトと軽量で、低帯域・パケロスの多い回線でも動作しやすい	大容量データ（画像・動画等）の転送には不向きで、通常は制御情報やセンサー値に限定される
配信効率	1つのPublishで多数のSubscriberへ一斉配信でき、多対多通信のオーバーヘッドが小さい	ブローカーが単一障害点になりやすく、クラスタリングや冗長構成の設計が別途必要
即時性	常時接続（TCPコネクション維持）のため、ポーリング不要でリアルタイムに近い配信ができる	常時接続を維持するためモバイル回線ではバッテリー・通信量消費が増える。keep-alive設定の調整が必要
信頼性	QoSレベルを選択でき、確実な配信が必要な処理にも対応できる	QoS 1では重複配信が起こり得るため、アプリケーション側で冪等な処理設計が必要
セキュリティ	TLS暗号化、ユーザー名/パスワード認証、クライアント証明書、ACLによるトピック単位のアクセス制御に対応	デフォルト設定（ポート1883・認証なし）のまま公開するとメッセージが平文で流れるため、初期設定のまま本番運用しないことが重要
ファイアウォール適合性	クライアントからブローカーへのアウトバウンド接続のみで済むため、NAT配下・企業ファイアウォール環境でも構成しやすい	一部の企業プロキシ環境ではポート8883自体がブロックされることがあり、WebSocket経由（443番ポート）での代替が必要になる場合がある

混同されやすい用語・類似技術との違い

MQTTはIoT通信でよく比較される他のプロトコルと、通信モデルや適用範囲が異なります。選定を誤ると、後から再設計が必要になることもあるため、違いを整理しておきます。

プロトコル	通信モデル	トランスポート	ヘッダー/オーバーヘッド	主な用途
MQTT	Publish/Subscribe	TCP（常時接続）	最小2バイトと非常に軽量	多数デバイスからの継続的なテレメトリ収集・一斉配信
HTTP/HTTPS	リクエスト/レスポンス	TCP（都度接続が多い）	テキストヘッダーで数百バイト以上	Web API連携、単発のデータ送信・取得
CoAP	リクエスト/レスポンス（HTTPライク）	UDP	4バイトからと軽量	BLE・LoRaWAN等の超省電力ネットワークでの単発通信
AMQP	メッセージキューイング（ルーティング機能が豊富）	TCP	MQTTより大きい	エンタープライズ基幹システム間のメッセージ連携
WebSocket	双方向ストリーム（プロトコル自体は自由）	TCP（HTTPでハンドシェイク）	接続確立後は軽量	ブラウザからのリアルタイム通信（MQTT over WebSocketの下位層としても利用）
MQTT-SN	Publish/Subscribe（MQTT準拠）	UDP等（TCP不要）	トピックをIDに置換しさらに軽量	Zigbee・LoRaWAN等、TCP/IPスタックを持たない超省電力機器

特に混同されやすいのはHTTPとの違いです。HTTPはクライアントが能動的にリクエストするため、最新値を得るには一定間隔でのポーリングが必要になり、更新頻度が高い・デバイス数が多いほど無駄な通信が増えます。MQTTはブローカーが変化をプッシュ配信するため、ポーリングが不要でネットワーク負荷と電力消費を抑えられます。また「MQTT vs WebSocket」という比較もよく見られますが、両者は本来レイヤーが異なり、実際にはMQTTのペイロードをWebSocketの上に載せて運ぶ「MQTT over WebSocket」という組み合わせがブラウザ対応のために広く使われています。

導入時の実務ポイント

ブローカー選定：自前ホスティングならEclipse Mosquitto（軽量・小規模向け）かEMQX（大規模・水平スケール向け）が定番。マネージドサービスならAWS IoT Core、Azure IoT Hub、HiveMQ Cloudが選択肢になる。デバイス数・接続数（コネクション数）・スループット要件から逆算して選ぶ
トピック設計：「拠点/ライン/機器種別/機器ID/測定項目」のように階層を固定し、ワイルドカードでの購読範囲を設計段階で決めておく。トピックをフラットにしすぎるとACL設定やルーティングが複雑化する
セキュリティ設定：ポート8883でのTLS接続を既定にし、デバイスごとにクライアント証明書またはユニークな認証情報を発行する。共通の1つのユーザー名・パスワードを全デバイスで使い回すのは、漏えい時の被害範囲が全台に及ぶため避ける。ブローカー側のACLで、各デバイスが自分のトピック以外へPublish/Subscribeできないよう制限するのが定石
可用性・スケーラビリティ：ブローカーをクラスタ構成にし、単一障害点を避ける。接続数が数万〜数十万台規模になる場合は、EMQXやクラウドマネージド型IoTプラットフォームのようなスケールアウト前提の製品を検討する
死活監視：LWT（遺言メッセージ）とRetained Messageを組み合わせ、「オンライン/オフライン」ステータスをトピックで管理すると、デバイスの異常切断をブローカー側だけで検知できる
バージョン選定：新規構築であればMQTT 5.0対応クライアント・ブローカーを選ぶのが基本だが、組み込み機器や既存ライブラリの制約でMQTT 3.1.1のみ対応というケースも多く、混在環境での後方互換性を確認する

2025年の最新動向

MQTT 5.0の普及：MQTT 3.1.1からの正式な後継バージョンで、セッション有効期限（Session Expiry Interval）、切断・接続失敗時の理由コード、共有サブスクリプション（Shared Subscription、複数コンシューマでの負荷分散）、ユーザープロパティ（メタデータの付加）などが追加されている。主要ブローカー・クライアントライブラリの対応が一般に進んでいる
MQTT over WebSocket / MQTT over QUIC：ブラウザから直接MQTTブローカーへ接続するWebSocket経由の利用が一般化しており、ダッシュボードやWebアプリでのリアルタイム表示に使われている。低遅延・コネクション確立の高速化を狙ったQUICトランスポート上でのMQTT利用も一部のブローカー実装で提案・検証されている
Sparkplug Bの採用拡大：産業用途では、MQTT上に統一データモデルとデバイス状態管理を定義するSparkplug B仕様の採用が広がっており、SCADA/MESとの相互運用性向上に寄与している
マネージドIoTプラットフォームの活用：AWS IoT Core、Azure IoT Hubなど、MQTTをベースにしたマネージド型サービスを使い、ブローカー運用の負荷を下げつつデバイス管理・ルール処理・データ分析基盤まで一体で構築する構成が一般的になっている

よくある質問（FAQ）

Q. MQTTとは何ですか？

MQTTはIoTデバイス向けの軽量メッセージングプロトコルです。Publish-Subscribeモデルで、低帯域幅・低消費電力環境でのデバイス通信に最適化されています。スマートホーム・センサーネットワーク・自動車IoT等で広く使われます。

Q. MQTTとHTTPはどう違いますか？

HTTPはクライアントがサーバーにリクエストするリクエスト-レスポンス型で、頻繁な通信にはオーバーヘッドが大きいです。MQTTはブローカーを介したPublish-Subscribe型で、デバイスが常時接続して超軽量なメッセージを送受信します。IoTデバイスの常時監視・センサーデータ送信にはMQTTが適しています。

Q. MQTTブローカーには何を使えばよいですか？

オープンソースではEclipse Mosquitto（最も一般的・軽量）、EMQX（大規模・高性能）が人気です。クラウドマネージドサービスではAWS IoT Core、Azure IoT Hub、HiveMQ Cloudがあります。個人検証用途ならMosquittoをDockerで動かすか、HiveMQ CloudやEMQX Cloudの無料枠から始めるのが手軽です。

Q. MQTTとCoAP、AMQPはどう違いますか？

CoAPはUDPベースでHTTPライクなリクエスト-レスポンス型プロトコルで、単発の問い合わせや省電力ネットワーク（BLE、LoRaWAN等）に向きます。AMQPはエンタープライズ向けのメッセージキューイングプロトコルで、トランザクション保証やルーティングが高機能な反面ヘッダーが大きく、サーバー間連携で使われます。MQTTはこの中間に位置し、軽量さと多対多配信効率を両立するため、多数の末端デバイスからのテレメトリ収集に最も広く使われています。

Q. MQTTの通信は暗号化されていますか？

MQTT自体はプロトコル仕様として暗号化を必須にしておらず、デフォルトのポート1883は平文通信です。実運用ではTLS/SSLを使うポート8883での接続、クライアント証明書またはユーザー名・パスワードによる認証、ブローカー側のACL（トピック単位のアクセス制御）設定が必須と考えるべきです。

Q. MQTT-SNとは何ですか？

MQTT-SN（MQTT for Sensor Networks）は、TCP/IPスタックを持たない超省電力・低メモリのセンサーネットワーク（Zigbee、LoRaWAN等）向けにMQTTの概念をUDPやその他の下位層に適合させた派生仕様です。トピック名を短いIDに置き換えるなどしてさらにオーバーヘッドを削減しています。

外部リンク・参考資料

MQTT.org（公式サイト）：仕様書、対応クライアント/ブローカー一覧、公式ドキュメント
OASIS MQTT Technical Committee：MQTT標準仕様の策定を行うOASIS技術委員会のページ
Eclipse Paho：主要言語向けMQTTクライアントライブラリを提供するEclipse Foundationのプロジェクト
Eclipse Mosquitto：オープンソースの軽量MQTTブローカー実装。ドキュメントと設定リファレンスを公開

この用語についてもっと詳しく

mqttに関するご質問や、システム導入のご相談など、お気軽にお問い合わせください。

お問い合わせサービス一覧

mqtt