MQTTブローカーとは？仕組み・主要ブローカー比較・構築手順を解説

MQTTブローカーは、IoTのデバイス間通信でメッセージを仲介する中継サーバーです。センサーが送ったデータを、それを必要とする機器へ振り分ける「郵便局」のような役割を担います。この記事では、MQTTブローカーの役割と仕組みを整理したうえで、Mosquitto・EMQX・HiveMQ・AWS IoT Coreといった主要ブローカーの比較と選び方、無料で試せるパブリックブローカー、Mosquittoでの構築手順、TLSや認証によるセキュリティ対策までを、実務で判断できる粒度でまとめます。

まとめ：MQTTブローカー選定と構築の要点

先に結論を示します。詳細は各セクションで解説します。

• 役割：MQTTブローカーはPub/Sub方式の中継点。送信側（パブリッシャー）と受信側（サブスクライバー）を直接つながず、トピック単位でメッセージを振り分ける。
• 用語の区別：「MQTT」は通信プロトコル、「MQTTブローカー」「MQTTサーバー」はそのプロトコルを処理する中継ソフトウェアを指す。ブローカーとサーバーはほぼ同義で使われる。
• 小規模・学習用途：軽量なEclipse Mosquitto。Raspberry Piでも動き、数コマンドで構築できる。
• 大規模・本番：EMQX（1クラスタ最大1億接続）やHiveMQ（商用サポート）。運用を任せたいならAWS IoT Coreなどマネージド型。
• 試すだけ：test.mosquitto.orgやbroker.hivemq.comのパブリックブローカーが無料。ただし認証なし・通信内容が他者に見えるため本番利用は不可。
• セキュリティ：平文1883番ではなくTLSの8883番を使い、ユーザー認証とトピック単位のアクセス制御（ACL）を必ず設定する。

MQTTブローカーとは：IoT通信を仲介する役割と仕組み

MQTT（Message Queuing Telemetry Transport）は、帯域や電力に制約のある環境向けに設計された軽量な通信プロトコルです。1999年にIBMとArcom（現Eurotech）が開発し、2013年にOASISで標準化、2016年にはISO/IEC 20922として国際標準になりました。最新仕様のMQTT 5.0は2019年に公開されています。このプロトコルの中心で通信を捌くのがMQTTブローカーです。プロトコル自体の歴史と仕組みはMQTTの概要とその歴史：プロトコルの基本的な仕組みと進化で詳しく解説しています。

ブローカーの役割：Pub/Sub方式でメッセージを仲介する中継点

MQTTは「パブリッシュ／サブスクライブ（Pub/Sub）」というモデルを採ります。データを送る側（パブリッシャー）と受け取る側（サブスクライバー）は互いの存在を知らず、すべてのやり取りはブローカーを経由します。パブリッシャーは「トピック」を指定してメッセージをブローカーへ送り、ブローカーはそのトピックを購読しているサブスクライバーだけにメッセージを配信します。

この仲介があるため、送信側と受信側の数や接続タイミングが揃っている必要がありません。センサー1台が送ったデータを複数のシステムが同時に受け取る、受信側が一時的に切断していても再接続時に受け取る、といった柔軟な構成が成立します。多数のデバイスが断続的に通信するIoTで、HTTPのような1対1のリクエスト／レスポンスではなくMQTTが選ばれる理由がここにあります。

MQTTブローカー・MQTTプロトコル・MQTTサーバーの違い

用語が混同されやすいので整理します。「MQTT」は通信の取り決め（プロトコル）そのものを指す言葉です。これに対し「MQTTブローカー」は、そのプロトコルに従って接続を受け付け、メッセージを振り分けるサーバーソフトウェアを指します。「MQTTサーバー」もほぼ同じ意味で、MQTT 5.0の仕様書では「Server」という語が使われますが、実務では「ブローカー」と呼ぶのが一般的です。つまりMQTTサーバーとMQTTブローカーは同じものと考えて差し支えありません。

整理すると、プロトコル（ルール）がMQTT、そのルールを処理する実体がブローカー（＝サーバー）、ブローカーに接続してメッセージを送受信する各デバイスがクライアントです。

トピックとワイルドカード（+・#）による配信制御

メッセージの宛先を決めるのがトピックです。トピックは home/livingroom/temperature のようにスラッシュ区切りの階層構造で表現します。購読側はこの階層を使い、ワイルドカードで範囲指定ができます。単一階層を表す + を使った home/+/temperature はすべての部屋の温度を、複数階層を表す # を使った home/# は home配下のすべてを購読します。

この階層設計を最初に決めておくことが、後の運用を左右します。設備や場所の構造を反映した命名（building/floor1/room1/temperature など）にしておくと、ワイルドカードでの一括購読やアクセス制御の設定が素直になります。

QoS・Retain・LWTが支える配信信頼性

不安定なネットワークでもメッセージを届けるため、MQTTには配信品質を制御する仕組みがあります。中心となるのがQoS（Quality of Service）で、3段階から選びます。

QoSのレベルが上がるほど確認の往復が増え、オーバーヘッドも大きくなります。すべてをQoS 2にするのではなく、データの重要度に応じて使い分けるのが実務の基本です。このほか、新規購読者へ最後の値をすぐ渡す「Retain（保持メッセージ）」、クライアントが異常切断した際に代理通知する「LWT（Last Will and Testament）」、再接続時に購読状態を引き継ぐ「セッション管理」も、ブローカーが提供する信頼性機能です。

主要MQTTブローカーの比較と用途別の選び方

MQTTブローカーには、軽量なオープンソースから大規模向け、クラウドのマネージド型まで幅があります。代表的な選択肢を実装や規模感で比較します。

主要ブローカー5種の比較表

いずれもMQTT 5.0に対応します。Mosquittoは最新の2.0系（2.0.22が2025年7月公開）と2.1系が並行し、MQTT 5.0/3.1.1/3.1をサポート。EMQXはErlang/OTPの並行処理を生かして1クラスタあたり最大1億接続をうたい、MQTT-SNやCoAP、WebSocketもブリッジします。なおEMQXは5.9.0以降でライセンス体系が変更されているため、バージョンや料金・ライセンスは変動します。導入前に各公式サイトで最新情報を確認してください。EMQXとMosquittoをより細かく比べたい場合はEMQXとMosquittoの基本的な違いとは？を参照してください。

規模・運用体制から見た選び方の判断基準

選定はスペック表の優劣ではなく、扱う接続数と運用にかけられる人員で決めるのが現実的です。判断の目安は次の通りです。

学習や数十～数百デバイスの小規模なら、迷わずMosquittoでよいでしょう。導入が数コマンドで済み、リソース消費も小さく、Raspberry Piのような小型機でも動きます。逆に、ここで初手からEMQXやHiveMQのクラスタを組むのは過剰で、Erlangやクラスタ運用の学習コストが見合いません。

同時接続が数万を超える、あるいは可用性のためにクラスタ構成が要るなら、EMQXやHiveMQが本命です。社内に運用チームを置けず、サーバー管理自体を避けたいのであれば、AWS IoT Coreなどマネージド型を選び、ブローカーの冗長化やスケールをクラウドへ委ねるのが妥当です。なお「とりあえず大は小を兼ねる」で大規模ブローカーを小規模案件に持ち込むと、運用負荷だけが先に膨らむ典型的な失敗になります。必要規模から逆算して選ぶのが鉄則です。

無料で試せるパブリックMQTTブローカーと接続ポート

自前でブローカーを立てる前に、動作確認や学習だけならインターネット上で公開されているパブリックブローカーを使えます。クライアントの接続先（ホスト名）とポートを指定するだけで、すぐにPub/Subを試せます。

主要パブリックブローカーと接続先一覧

ポート番号はMQTTの慣例に沿っています。1883が暗号化なしの平文MQTT、8883がTLSで暗号化したMQTT、WebSocket経由はブローカーごとに8080や8000、8083などが割り当てられます。test.mosquitto.orgはクライアント証明書認証用の8884番も公開しています。broker.hivemq.comは公開デモ用途のためTLSポートを提供していませんが、これはHiveMQ製品自体がTLS非対応という意味ではなく、製品版は当然TLSに対応します。接続先のポートはクライアント設定時に取り違えやすいので注意してください。

パブリックブローカーを本番利用してはいけない理由

パブリックブローカーは便利ですが、本番システムに使ってはいけません。多くは認証なしで誰でも接続でき、同じトピックを購読すれば送信内容が第三者にそのまま見えてしまうためです。ワイルドカード # で全トピックを購読すれば、他人が流しているデータを覗けてしまう状態は珍しくありません。

用途は、クライアントライブラリの動作確認、トピック設計の試行、研修やデモに限るべきです。実データを扱う段階に入ったら、後述のMosquittoで自前のブローカーを立てるか、認証付きのマネージドサービスへ移行してください。

MosquittoによるMQTTブローカー構築手順（Ubuntu）

もっとも手軽に自前のブローカーを立てられるのがMosquittoです。ここではUbuntu系Linuxでの構築手順を示します。

インストールと起動

パッケージマネージャでブローカー本体と動作確認用のクライアントツールを導入します。

sudo apt update
sudo apt install mosquitto mosquitto-clients

インストール後、Mosquittoはサービスとして自動起動し、初期状態では1883番ポートで待ち受けます。systemctl status mosquitto で稼働状態を確認できます。この時点ではローカルからの接続で疎通確認が可能です。

認証とアクセス制御の設定

初期設定のままでは匿名接続を許してしまうため、本番に近づける最初の一歩として認証を有効にします。まずユーザーとパスワードを登録します。

sudo mosquitto_passwd -c /etc/mosquitto/passwd user1

次に設定ファイル（/etc/mosquitto/mosquitto.conf、または /etc/mosquitto/conf.d/ 配下）に、匿名接続の禁止とパスワードファイルの指定を追記します。

listener 1883
allow_anonymous false
password_file /etc/mosquitto/passwd

編集後に sudo systemctl restart mosquitto で再起動すると設定が反映されます。さらにトピック単位で接続元ごとの読み書き権限を制限したい場合は、ACL（アクセス制御リスト）ファイルを acl_file で指定します。

mosquitto_sub／mosquitto_pubによる動作確認

同梱のコマンドラインツールで疎通を確認します。ターミナルを2つ開き、片方で購読、もう片方で送信します。まず購読側を起動します。

mosquitto_sub -h localhost -t test/topic -u user1 -P パスワード

別のターミナルから同じトピックへメッセージを送信します。

mosquitto_pub -h localhost -t test/topic -m "hello mqtt" -u user1 -P パスワード

購読側のターミナルに hello mqtt が表示されれば、ブローカーが正しくメッセージを仲介できています。Raspberry Piを使ってクラウドと連携させる構成はラズパイをAWS IoTと連携させるための基本手順と設定方法も参考になります。

MQTTブローカーのセキュリティ対策

IoTでは多数のデバイスが外部ネットワークにさらされるため、ブローカーのセキュリティは構築とセットで考える必要があります。対策は「通信の暗号化」「接続元の認証・認可」「ネットワーク防御」の3層で組み立てます。

TLS暗号化とポート8883への切り替え

平文の1883番ポートは、通信内容を経路上で傍受・改ざんされるリスクがあります。本番ではTLSを有効にし、暗号化された8883番ポートで待ち受けます。サーバー証明書をブローカーに設定し、クライアント側で証明書を検証することで、なりすましと盗聴を防ぎます。さらに、クライアントにも証明書を持たせる相互TLS認証にすれば、許可した端末以外は接続自体ができなくなります。MQTT 5.0/3.1.1いずれもTLSに対応しているため、プロトコルバージョンを問わず適用できます。

認証・認可（ACL）とネットワーク防御

暗号化だけでは「誰が接続してよいか」「どのトピックを操作してよいか」は制御できません。クライアントID＋パスワード認証や証明書認証で接続元を絞り、ACLでトピックごとに読み取り・書き込みの権限を分けます。たとえばセンサー端末には自分の送信トピックへの書き込みだけを許可し、購読は許さない、といった最小権限の設計が有効です。

加えて、ファイアウォールやセキュリティグループで接続元IPを限定し、不要なポートを閉じます。VPN経由でのみブローカーへ到達させる構成も、外部公開を避ける有効な手段です。これらを組み合わせ、暗号化・認証認可・ネットワーク制限を多層で重ねることが、実運用での基本姿勢です。

クラウドのマネージドMQTTブローカーという選択肢

ブローカーの冗長化やスケール、証明書管理を自前で運用する負担を避けたい場合は、クラウドのマネージドサービスが選択肢になります。代表例がAWS IoT Coreで、サーバーを一切構築せずにMQTTエンドポイントを利用でき、デバイス認証やTLSが標準で組み込まれています。接続数の増減に応じて自動でスケールし、Lambda・S3・分析サービスなど他のクラウド機能と連携できる点が、自前ブローカーとの大きな違いです。機能や利点の詳細はAWS IoT Coreの特徴と利点 – クラウドベースのIoTソリューションで解説しています。オフライン端末向けにメッセージを保持する仕組みはAWS IoT Coreの新機能「Message Queuing」の全体概要と活用意義が参考になります。Azure IoT Hubなど他社クラウドもMQTTベースのマネージドIoT機能を提供しており（対応するMQTTバージョンや機能範囲はサービスごとに異なります）、運用人員を割けない組織ほどマネージド型の優位が大きくなります。

よくある質問

MQTTブローカーとは何ですか？

MQTTプロトコルでやり取りされるメッセージを中継するサーバーソフトウェアです。データを送る側（パブリッシャー）と受け取る側（サブスクライバー）を直接つなぐのではなく、トピック単位でメッセージを振り分けます。送信側と受信側が互いを意識せず通信できるため、多数のデバイスが断続的に接続するIoT環境に適しています。

MQTTブローカーとMQTTサーバーは違うのですか？

ほぼ同じものを指します。MQTT 5.0の仕様書では「Server」と表記されますが、実務では「ブローカー」と呼ぶのが一般的です。一方「MQTT」はプロトコル（通信ルール）そのものを指す言葉で、ブローカー／サーバーはそのルールを処理する実体です。混同しやすいので、ルール＝MQTT、中継する実体＝ブローカー（サーバー）と整理すると分かりやすくなります。

MQTTブローカーは無料で使えますか？

無料で使えます。Eclipse MosquittoやEMQX、HiveMQ Community Editionはオープンソースで無償利用でき、自分のサーバーに導入できます。動作確認だけなら、test.mosquitto.orgやbroker.hivemq.comといった公開のパブリックブローカーを使えばサーバー構築すら不要です。ただしパブリックブローカーは認証がなく通信内容が他者に見えるため、本番システムには使えません。

MosquittoのMQTTブローカーはどう始めればよいですか？

Ubuntu系Linuxなら sudo apt install mosquitto mosquitto-clients でブローカー本体とクライアントツールを導入できます。インストール後は自動起動し1883番で待ち受けるので、mosquitto_sub と mosquitto_pub で送受信を確認できます。実運用に移す際は匿名接続を禁止し、パスワード認証とTLSを設定してください。

MQTTブローカーのセキュリティは安全ですか？

初期設定のままでは安全ではありません。多くのブローカーは初期状態で匿名接続を許可し、平文の1883番で待ち受けるためです。TLSを有効にして8883番で暗号化通信を行い、ユーザー認証や証明書認証で接続元を限定し、ACLでトピックごとの権限を絞ることで、実用的な安全性を確保できます。ファイアウォールでの接続元制限も併用してください。

関連記事

• MQTTの概要とその歴史：プロトコルの基本的な仕組みと進化
• EMQXとMosquittoの基本的な違いとは？
• AWS IoT Coreの特徴と利点 – クラウドベースのIoTソリューション
• AWS IoT Coreの新機能「Message Queuing」の全体概要と活用意義
• ラズパイをAWS IoTと連携させるための基本手順と設定方法