EMQXとは？OSS版の無償範囲とMosquittoとの違い【6.3対応】

EMQX（イーエムキューエックス）は、EMQ Technologiesが開発するMQTTブローカーです。Erlang/OTPで書かれた分散アーキテクチャを持ち、複数ノードでクラスタを組んで大量のIoTデバイスをつなぐ用途で選ばれます。2026年10月時点の現行版は6.3.1（LTS）で、5.9.0からはオープンソース版とエンタープライズ版が1つに統合され、ライセンスはBusiness Source License（BSL）1.1に変わりました。この記事では、EMQXが何をするソフトウェアか、どこまで無償で使えるか、Dockerで動かす手順、既定設定の落とし穴、軽量ブローカーのMosquittoとの選び分けを順に説明します。

まとめ：EMQXの要点とMosquittoとの選び分け

• EMQXとは：Erlang/OTP製の分散MQTTブローカー。MQTT 5.0／3.1.1に加え、MQTT over QUIC、SQLのルールエンジン、データベースやKafkaへのデータ連携、Webダッシュボードを1製品で持つ。
• 現行版：6.3.1（LTS）。6系でメッセージキュー（$queue/）とMQTT Streams、6.3でセキュリティプロファイルが入った。
• 無償の範囲：5.9.0以降は開発・検証と、単一ノードの本番利用が無償。2ノード以上のクラスタ、第三者へのホスティング提供、第三者に提供する製品・ソリューションへの組み込みは商用ライセンスかEMQX Cloudの契約が必要。
• 既定設定の落とし穴：6.3の既定（legacy）は認証を設定しないと匿名接続を通す。本番はEMQX_SECURITY_PROFILE=hardenedから始める。
• Mosquittoとの選び分け：1台で足りるならMosquitto、冗長化やクラスタ、ルールエンジン、ダッシュボードが要るならEMQX。ただしEMQXのクラスタは有償なので、費用を見込めないなら単一ノードのまま設計するかマネージドサービスと比べる。

EMQXとは：Erlang製の分散MQTTブローカー

MQTTブローカーは、センサーやゲートウェイが送るメッセージを受け取り、同じトピックを購読しているアプリへ配る中継サーバーです。仕組みそのものはMQTTブローカーの仕組みと主要ブローカー比較で、プロトコルの基礎はMQTTのPub/Subの仕組みとMQTT 5.0の実装で扱っています。EMQXはその中継役を、Erlang/OTPの並行処理と分散機構で大規模に動かすことを狙った実装です。

開発元と版の流れ

EMQXの前身は、2012年12月にGitHubでリポジトリが作られたemqttdで、現在はEMQ TechnologiesがGitHubのemqx/emqxリポジトリでソースを公開しています。GitHubのリリース一覧で主要な版の公開日を並べると次のとおりです。

6.3系はLTS（長期サポート）と銘打たれているので、これから入れるなら6.3.1を選びます。READMEによると6.4は出ず、6系は6.3で終わって次は7.0です。Apache 2.0のOSS版として最後に出たのは2025-12-31公開のv5.8.9で、その後の5.8.10と5.8.11はEnterprise版（商用）だけのリリースです。

6系で増えた機能と5系からの非互換

EMQXの新機能一覧によると、6系ではMQTTのPub/Subに非同期のキューと再生可能なストリームが加わりました。メッセージキューは、トピックフィルタに一致したメッセージを名前付きのキューに保存し、購読側は$queue/<名前>の形式で後から受け取ります。有効にすると$queue/の接頭辞はキュー専用になり、旧来の共有サブスクリプションの書き方には使えなくなります。MQTT Streams（6.1.0）は、一致したメッセージを名前付きストリームに保持し、購読側が位置を指定して読み直せる仕組みです。

5系から上げるときは6.0の非互換変更を先に読んでください。永続セッション（durable sessions）を有効にしていたクラスタは、6.0への移行時にまっさらな状態から作り直す必要があり、6.0より前に作られた永続セッションの状態は失われます。Ubuntu 20.04やCentOS 7向けのパッケージ配布も止まりました。6.0〜6.2から6.3へ上げる場合も、MQTTのパーサが既定で厳格モードになり、Prometheusのスクレイプに認証が必須になるなどの6.3の非互換変更があります。

EMQXの主な機能：認証・ルールエンジン・クラスタ・QUIC

Mosquittoと比べたときにEMQXを選ぶ理由になるのは、次の4つです。いずれもEMQX公式ドキュメントの記載に基づきます。

認証・認可のバックエンド

認証方式はユーザー名とパスワード、JWT、X.509証明書、TLS-PSK、MQTT 5.0の拡張認証（SCRAM・Kerberos）に対応し、資格情報の保存先として内蔵DB、MySQL、PostgreSQL、MongoDB、Redis、LDAP、HTTPを選べます。認可（ACL）も同じ保存先からクライアントID・ユーザー名・IPアドレス単位でトピックごとのpublish／subscribeを制御できます。既存の会員DBやIDaaSへの委譲を標準機能として持つのがMosquittoとの差です。Mosquittoでも同じことはできますが、標準はパスワードファイルか動的セキュリティプラグインで、DBやHTTPへ委ねるにはmosquitto-go-authなどサードパーティのプラグインが要ります。TLSの8883番や証明書認証の設計はMQTTセキュリティ：TLS 8883番・証明書認証・トピックACLの設計にまとめています。

SQLのルールエンジンとデータ連携

受け取ったメッセージをSELECT payload.temp FROM "sensor/#" WHERE payload.temp > 30のようなSQLで抽出・変換し、コネクタ経由でデータベース、Kafka、クラウドのストレージへ送れます。6.0ではBigQuery、Redshift、AlloyDB、CockroachDBへの連携が、6.3.0ではGoogle Bigtableへの連携が追加されました。Mosquittoで同じことをするには、購読用のアプリを別に書いてDBへ書き込む必要があります。

Mriaによるクラスタ

5.0以降のクラスタはMriaと呼ぶ複製機構で動き、ノードはデータを持つCoreと、接続を受け持つReplicantに役割を分けます。接続数を増やすときはReplicantを足せばよく、Coreの台数を増やさずに横へ伸ばせます。EMQは23ノードの1クラスタで1億の同時接続を公称しています。ただし後述のとおり、5.9.0以降でクラスタを組むには商用ライセンスが要ります。

MQTT以外のプロトコルとQUIC

MQTT-SN、CoAP、LwM2M、STOMPをゲートウェイで受けてMQTTのトピックへ変換でき、移動体向けにMQTT over QUICも実装しています。QUICはTCP/TLSより接続の確立が速く、切断後も0-RTTで素早く張り直せます。EMQのQUIC対応クライアントは、QUICが使えない網ではTCP/TLS 1.2へ自動で切り替える設計です。工場の機器をMQTTで扱う規約が必要ならSparkplug BによるMQTT上の産業データ規約も参照してください。

EMQXのライセンス：OSS版はどこまで無償で使えるか

「emqx oss」で検索される理由はここです。5.9.0で無償のオープンソース版は独立した製品としては無くなり、全機能を含む1つの製品がBSL 1.1のLICENSEで配布されています。BSLはソースを公開しつつ本番利用を条件付きにするライセンスで、EMQXの場合は「追加利用許諾（Additional Use Grant）」で無償の本番利用の範囲を定めています。

無償で本番運用できる条件

LICENSEの追加利用許諾は、単一ノードの本番利用を認めたうえで、第三者へホスティングまたは組み込みの形で提供する使い方を除外しています。EMQXのライセンスFAQは、除外の例として、EMQXをマネージドMQTTとして売るサービスと、販売する産業用ゲートウェイへの同梱を挙げています。自社工場の設備監視のように社内で閉じる用途で1台を動かす使い方は無償の範囲です。顧客に提供するサービスやソリューションの一部としてEMQXを動かす場合は、LICENSEの除外条件に当たるかをEMQの窓口で確認してください。READMEは、5.9.0以降で2ノード以上のクラスタを組む場合はライセンスファイルの読み込みが必要だと明記しています。

BSLには版ごとの期限があり、各版の公開から4年後にApache License 2.0へ切り替わります。6.3.1であれば公開から4年後の2030年9月にApache 2.0へ切り替わる計算ですが、その時点で4年前の版を本番に使い続ける判断は現実的ではありません。

Apache 2.0の5.8系に留まる判断

5.8系以前はApache 2.0のままで、FAQも既存のApache 2.0版は無期限に使い続けてよいとしています。クラスタを無償で組みたいなら5.8系に留まる道はあります。ただし6系のメッセージキューやセキュリティプロファイルは入りません。新規の構築で5.8系を選ぶのは、クラスタが必須で商用ライセンスの予算が取れない場合に限るのが妥当です。

EMQXをDockerで動かす手順（6.3.1）

手元で試すならDockerが早道です。手順は公式のDockerインストール手順に沿っています。

コンテナの起動と5つのポート

docker run -d --name emqx \
  -p 1883:1883 -p 8083:8083 -p 8084:8084 \
  -p 8883:8883 -p 18083:18083 \
  emqx/emqx-enterprise:6.3.1

# 起動の確認
docker exec emqx /opt/emqx/bin/emqx ctl status
# Node '[email protected]' 6.3.1 is started

イメージ名に注意してください。Docker Hubの公式イメージemqx（Docker Official Image）は5.8系で止まっており、2026年10月時点でもlatestは5.8.8です。6系はemqx/emqx-enterprise（またはemqx/emqx）から取ります。公開するポートの役割は次のとおりです。

本番相当で使う場合は、公式手順のように/opt/emqx/dataと/opt/emqx/logをホストのディレクトリにマウントし、ノード名を固定します。マウントしないと、コンテナを作り直したときにダッシュボードで変えた設定や組み込みDBの認証ユーザー、ルールが消えます。

ダッシュボードへの初回ログイン

ブラウザでhttp://localhost:18083/を開き、初期ユーザー名admin、初期パスワードpublicでログインします。ダッシュボードの説明のとおり、初回ログインでパスワードの変更を求められ、publicは再設定できません。接続中のクライアント、購読、ルール、リスナーの状態はここから確認できます。

mosquitto_pubとmosquitto_subで疎通を確かめる

MQTTクライアントは何でも構いませんが、Mosquittoに付属するコマンドラインツールが手軽です。ターミナルを2つ開き、片方で購読、もう片方で送信します。この章と次の章の出力は、2026-10-11にemqx/emqx-enterprise:6.3.1で実行したときのものです。

# ターミナル1：sensor/以下をすべて購読
mosquitto_sub -h localhost -p 1883 -t 'sensor/#' -v

# ターミナル2：1件送信
mosquitto_pub -h localhost -p 1883 -t sensor/room1/temp -m 21.5

# ターミナル1の表示
sensor/room1/temp 21.5

ユーザー名もパスワードも指定していないのに受信できた点に注目してください。次の章で説明するとおり、これはEMQXの既定設定によるものです。Pythonから同じことをするならpaho-mqtt 2系のループ方式と再接続の実装が参考になります。

EMQXとMosquittoの既定のセキュリティの違い

EMQXとMosquittoは、既定設定のままクライアントをどう扱うかが正反対です。Mosquitto 2.xは閉じた状態で起動し、EMQX 6.3は既定のままだと匿名接続を通します。

EMQX 6.3のセキュリティプロファイル

6.3で入ったセキュリティプロファイルには、従来の挙動を保つlegacy（既定）と、安全側に倒したhardenedの2つがあります。hardenedにすると、ブローカーに認証器が1つも設定されていない（またはすべて無効の）状態ではクライアントの接続が拒否され、初期パスワードpublicのままのダッシュボードアカウントはログインできなくなり、既定のErlangクッキーを使うノードは起動しません。公式ドキュメントは、新規の構築ではhardenedを使うよう勧め、7.0で既定をhardenedに切り替える予定だと書いています。

docker run -d --name emqx \
  -e EMQX_SECURITY_PROFILE=hardened \
  -e EMQX_NODE__COOKIE=<推測されにくい文字列> \
  -p 1883:1883 -p 18083:18083 \
  emqx/emqx-enterprise:6.3.1

# 認証なしの送信は拒否される
mosquitto_pub -h localhost -p 1883 -t sensor/room1/temp -m 21.5
# Connection error: Connection Refused: not authorised
# Error: The connection was refused

# ダッシュボードは先にadminのパスワード変更が必要
docker exec emqx /opt/emqx/bin/emqx ctl admins passwd admin <新しいパスワード>

接続できるようにするには、認証器（組み込みデータベースのパスワード認証など）を作成してユーザーを登録し、mosquitto_pubに-uと-Pを付けて送ります。ダッシュボードの初期パスワードは、emqx ctl admins passwdの代わりに設定ファイルのdashboard.default_passwordで起動時に変えることもできます。

hardenedではMQTTとダッシュボードのリスナーが既定でループバックに閉じますが、公式のDockerイメージはEMQX_NODE__DEFAULT_LISTENER_ADDRESS=allを自動で設定するため、-pで公開したポートには外から届きます。コンテナで動かすときは、待ち受けアドレスではなく認証設定で守る前提で組んでください。

Mosquitto 2.xは設定なしだとローカル接続だけ

Mosquittoの2.0移行ガイドによると、設定ファイルなしで起動したMosquittoは127.0.0.1と::1だけで待ち受け、この場合に限って匿名接続を許します。listener 1883を書いて外部から受け付けるようにすると、今度は認証の設定が必須になり、allow_anonymousを明示しない限り匿名では入れません。1.x時代の寛容な既定をやめた結果で、何も考えずに立てたブローカーが外へ開いてしまう事故は起きにくくなっています。

EMQXを選ぶ場合は、この差を知ったうえでhardenedで立ち上げるか、legacyのまま使うなら認証器を最初に設定し、acl.confの最終行{allow, {security_profile, legacy}}.を{deny, all}.に変えてください。legacyの既定のacl.confは、この最終行のせいでどのルールにも一致しない操作を許可します。

EMQXとMosquittoの違い（比較表）

Mosquittoは、Eclipse Foundationが管理するC言語製のMQTTブローカーです。2026年10月時点の最新版は2026-02-09公開の2.1.2で、ライセンスはEPL-2.0とEDL-1.0（BSD-3-Clause）のデュアルライセンスです。主な違いを並べます。

Mosquittoの2.1.0（2026-01-29）では、acl_fileとpassword_file、per_listener_settingsが非推奨になり、3.0で削除されるとリリースノートに書かれています。同じ機能はプラグインへ移ったので、これからMosquittoを入れるならプラグイン形式で認証を設定しておくと3.0への移行で書き直さずに済みます。2.1.0ではmax_packet_sizeの既定値も2,000,000バイトに下がったため、画像などの大きなペイロードを流す構成は上げ直しが要ります。

性能値の読み方

EMQが2026-06-01付で公開した（同月22日更新）EMQXとMosquittoの比較記事は、1ノードあたりの接続数をEMQXが400万、Mosquittoが16万未満とし、QoS 0のメッセージ処理をEMQXが毎秒200万件、Mosquittoが毎秒12万件としています。これは開発元自身が出した数字で、第三者の検証ではありません。EMQの数字でもMosquittoの上限は1ノード16万接続弱なので、数千〜数万台の規模ならどちらでも接続数が先に詰まることはまずありません。性能の差が効いてくるのは数十万接続から先で、そこまで行くならクラスタとライセンス費用を込みで比べることになります。QoSの選び方が処理量に与える影響はMQTT QoSの0・1・2の違いと選び方で扱っています。

EMQXとMosquittoの選び方

判断の分かれ目は、ブローカーを1台で済ませられるかどうかです。

Mosquittoで足りるケース

接続が数千台以下で、ブローカーが止まっても再起動を待てる構成ならMosquittoで足ります。Raspberry Piやエッジゲートウェイの上で動かす、宅内や1工場で閉じる、データの保存は別のアプリが購読して行う、といった用途です。EMQ自身もEMQXのほうがCPUとメモリを多く使うと認めており、Mosquittoの設定ファイルはlistenerと認証の数行から始められます。冗長化が要るならMosquittoを2台並べてブリッジでつなぐ手もありますが、セッションの引き継ぎはできないので、クライアント側で再接続と再送を作り込む前提になります。

EMQXを選ぶケース

ブローカーの停止がそのまま業務停止になり、ノード障害でも接続を受け続けたい場合はEMQXのクラスタが候補です。既存の会員DBで認証したい、ルールエンジンでKafkaやデータベースへ直接流したい、運用担当がダッシュボードで状態を見たい、といった要件が重なるほどEMQXの価値が上がります。数十万台以上の車両や機器をつなぐ規模が、EMQXの想定する領域です。

EMQXを避けたほうがよい場面

クラスタが必須なのに商用ライセンスの予算が取れない場合は、EMQXを前提にした設計を見直してください。単一ノードの無償範囲で始めて後からクラスタ化しようとすると、その時点でライセンス費用が発生します。自前で運用する人手が無いなら、EMQXのマネージド版であるEMQX Cloud（Serverlessは同時1,000接続まで月0ドルから、Dedicated Flexは月234ドルから）や、AWS IoT Coreの機能・料金・MQTT接続方法と比べるほうが早く決まります。どのブローカーを選んでもデバイス側の再接続や証明書の配布は残るので、IoT全体の設計から相談したい場合は一想のAI/IoTソリューションで構成の検討から支援しています。

よくある質問

EMQXのオープンソース版（OSS版）はなくなったのですか？

5.9.0以降は、OSS版とEnterprise版が1つの製品に統合され、BSL 1.1で配布されています。ソースは引き続きGitHubで公開されており、開発・検証と単一ノードの本番利用は無償です（第三者へのホスティング提供と、第三者に提供する製品への組み込みを除く）。Apache 2.0のOSS版は5.8系として残っていますが、6系の新機能は入りません。

Mosquittoの読み方は？

Mosquittoは「モスキート」と読みます。プロジェクトはEclipse Foundationの管理下にあり、正式名称はEclipse Mosquittoです。

EMQXダッシュボードの初期ユーザー名とパスワードは？

初期ユーザー名はadmin、初期パスワードはpublicで、ポート18083で開きます。初回ログイン時にパスワードの変更を求められます。6.3でhardenedプロファイルを使う場合はpublicのままではログインできないため、先にemqx ctl admins passwdで変更します。

MosquittoからEMQXへ移行・併用できますか？

どちらも標準のMQTTを話すため、クライアントのコードはほぼそのまま使えます。ただしMosquitto側のユーザーとACLはEMQXの認証器と認可ルールとして作り直す必要があり、これを忘れるとlegacyでは匿名で通り、hardenedでは全クライアントが拒否されます。段階的に移すなら、Mosquittoのブリッジ機能でEMQXへメッセージを転送し、受信側から順にEMQXへ寄せる方法が使えます。エッジでMosquittoを動かし、ブリッジでクラウド側のEMQXに集約する併用構成は、EMQXのドキュメントにも手順があります。

EMQXとAWS IoT Coreはどう違いますか？

EMQXは自分でサーバーを用意して運用するソフトウェアで、AWS IoT CoreはAWSが運用するマネージドサービスです。AWS IoT CoreはQoS 2に対応していないなど、MQTTの仕様の一部をサポートしていません。運用の手間を減らしたいならAWS IoT Core、QoS 2やルールの細かい制御、オンプレミスでの稼働が必要ならEMQXが向きます。

関連記事

• MQTTブローカーとは？仕組み・主要ブローカー比較・構築手順を解説
• MQTTとは？Pub/Subの仕組み・QoS・MQTT 5.0の実装からHTTPとの使い分けまで実装者向けに解説
• MQTTセキュリティ｜TLS 8883番・証明書認証・トピックACLの設計を実装目線で解説
• MQTT QoSとは？0・1・2の違いと選び方をレベル別に解説
• AWS IoT Coreとは？機能・料金・MQTT接続方法をまとめて解説