MQTTとは？IoT通信プロトコルとブローカー

「工場内のセンサー値をクラウドに送りたいが、HTTPで毎秒アクセスさせると通信量もサーバ負荷も気になる」。

IoTや設備監視の設計では、このような悩みがよく出てきます。

温度、電流、振動、稼働状態、アラーム履歴など、現場で発生するデータは小さくても数が多く、しかも常に発生し続けます。

そのような小さなデータを、軽く、継続的に、必要な相手へ配るために使われる通信プロトコルがMQTTです。

MQTTは、IoTやM2M通信向けに使われる軽量なメッセージングプロトコルです。

本記事では、MQTTの基本、ブローカーの役割、Publish/Subscribeの仕組み、QoS、トピック設計、HTTPやModbusとの違い、製造業での使い方までを実務目線で解説します。

1. MQTTとは何か

MQTTとは、センサー、マイコン、PLC、ゲートウェイ、クラウドなどの間で小さなメッセージをやり取りするための通信プロトコルです。

正式には「Message Queuing Telemetry Transport」と呼ばれます。

現在では、IoT向けの代表的な通信プロトコルとして広く使われています。

最大の特徴は、通信の中心にブローカーと呼ばれる中継サーバを置き、送信側と受信側を直接つながないことです。

送信側はブローカーへデータを送ります。

受信側は、自分が欲しい種類のデータだけをブローカーから受け取ります。

この仕組みにより、機器同士を一対一で複雑に接続しなくても、多数のデバイスへ柔軟にデータを配信できます。

たとえば、温度センサーが「設備Aの温度は45℃です」というデータをブローカーへ送るとします。

監視画面、データベース、異常検知プログラムが同じ温度データを必要としていれば、それぞれがブローカーから受け取れます。

送信側のセンサーは、誰が受け取るかを知る必要がありません。

MQTTが向いている場面

MQTTは、小さなデータを頻繁に送る用途に向いています。

特に、通信帯域が限られる環境、デバイスのCPUやメモリが小さい環境、常時接続しながら状態変化を送る用途で使いやすい方式です。

用途	MQTTが合う理由	具体例
設備監視	小さな状態データを継続的に送れる	温度、振動、電流、稼働状態
IoTデバイス	軽量で低帯域でも扱いやすい	環境センサー、遠隔監視端末
クラウド連携	デバイスとアプリを疎結合にできる	データ収集、ダッシュボード表示
イベント通知	状態変化を必要な相手へ配れる	異常通知、アラーム、稼働開始通知

製造現場で使う通信方式には、Modbusのように機器のレジスタを読む方式もあります。

設備内のPLCや計測器との通信を理解したい場合は、Modbusとは？RTUとTCPの違いを解説もあわせて確認すると、MQTTとの役割の違いが見えやすくなります。

2. MQTTの基本構成

MQTTの基本構成は、クライアント、ブローカー、トピック、メッセージの4つで考えると理解しやすいです。

難しい言葉に見えますが、役割はシンプルです。

クライアント

MQTTで通信する機器やプログラムをクライアントと呼びます。

センサー、マイコン、PLCゲートウェイ、エッジPC、クラウドアプリ、監視画面などがクライアントになります。

クライアントは、データを送る側にも、受け取る側にもなれます。

同じクライアントが、あるデータを送信しながら、別のデータを受信することもあります。

ブローカー

ブローカーは、MQTT通信の中継役です。

クライアントから届いたメッセージを受け取り、そのメッセージを必要としている別のクライアントへ配信します。

メールで例えるなら、ブローカーはメールサーバのような存在です。

送信者はメールサーバへ送信し、受信者は自分宛てのメールをサーバから受け取ります。

トピック

トピックは、メッセージの種類や宛先を表す名前です。

たとえば、次のような階層名でデータを分類します。

factory1/lineA/machine01/temperature

factory1/lineA/machine01/alarm

factory1/lineB/machine03/status

受信側は、自分が欲しいトピックを指定して購読します。

これにより、「設備Aの温度だけ受け取る」「ライン全体のアラームを受け取る」といった選択ができます。

メッセージ

メッセージは、実際に送るデータ本体です。

温度値、ON/OFF状態、アラームコード、稼働時間、JSON形式のデータなどを送れます。

MQTT自体は、メッセージの中身を細かく決めません。

そのため、設計者側で「どの形式で送るか」「単位をどう表すか」「タイムスタンプを入れるか」を決める必要があります。

3. Publish/Subscribeの仕組み

MQTTの中心となる考え方が、Publish/Subscribeです。

日本語では、発行/購読モデル、またはPub/Subと呼ばれます。

Publishは「メッセージを発行すること」です。

Subscribeは「特定のトピックを購読して受信すること」です。

送信側と受信側を直接つながない

従来の通信では、送信側が受信側のIPアドレスや接続先を知っている必要があります。

しかしMQTTでは、送信側はブローカーへメッセージを送るだけです。

誰がそのメッセージを受け取るかは、ブローカー側が購読情報を見て判断します。

この仕組みによって、送信側と受信側の関係を疎結合にできます。

送信側のプログラムを変更しなくても、新しい監視画面や分析アプリを追加しやすくなります。

製造現場での例

たとえば、設備のゲートウェイが次のトピックへデータを送るとします。

plant1/press/line1/machine05/status

このデータを、監視画面、異常検知システム、稼働率集計プログラムがそれぞれ購読すれば、同じデータを複数の用途で使えます。

設備側は、監視画面の数や分析システムの数を意識しません。

これは、設備データ活用を段階的に広げたい現場にとって大きなメリットです。

組込み機器やセンサー端末側の構成を理解したい場合は、組込みシステムとは？特徴と開発・用途を解説も参考になります。

4. MQTTブローカーの役割

MQTTでは、ブローカーの設計が全体の安定性を左右します。

ブローカーは単なる転送装置ではありません。

接続管理、購読管理、メッセージ配信、認証、ログ管理、保持メッセージ、QoS制御など、多くの役割を持ちます。

接続管理

ブローカーは、各クライアントが接続しているかどうかを管理します。

MQTTでは、デバイスが常に安定したネットワーク環境にあるとは限りません。

無線通信、遠隔地の回線、工場内のノイズ環境では、接続が一時的に切れることがあります。

ブローカーは、そのような接続状態を管理し、クライアントの再接続を受け入れます。

購読管理

ブローカーは、どのクライアントがどのトピックを購読しているかを覚えています。

メッセージが届くと、そのトピックに一致する購読者を探し、必要な相手へ配信します。

このため、トピック設計が雑だと、不要なデータを多くのクライアントへ配ってしまうことがあります。

逆に、トピック設計が整理されていれば、データの流れを非常に管理しやすくなります。

認証とアクセス制御

ブローカーは、誰でも接続できる状態にしてはいけません。

ユーザー名、パスワード、証明書、TLS、アクセス制御リストなどを使い、接続できる機器や購読できるトピックを制限します。

製造現場では、設備データやアラーム情報が外部に漏れると大きな問題になります。

MQTTを使う場合は、通信方式だけでなく、ブローカーの認証設計もセットで考える必要があります。

5. トピック設計の考え方

MQTTを実務で使うときに最も重要なのがトピック設計です。

トピックは単なる名前ではなく、データ構造そのものです。

ここを曖昧にすると、後からデータを探しにくくなり、システム拡張時に混乱します。

階層構造で表す

トピックはスラッシュで区切って階層構造にできます。

たとえば、工場、ライン、設備、データ種別の順に並べると、次のようになります。

plant1/lineA/machine01/temperature

plant1/lineA/machine01/current

plant1/lineA/machine01/alarm

このように決めておけば、同じ設備の複数データをまとめて扱いやすくなります。

また、ライン単位、設備単位、データ種別単位で購読範囲を切り替えやすくなります。

ワイルドカードを考慮する

MQTTでは、トピック購読時にワイルドカードを使えます。

+ は1階層分を表し、# はそれ以下の階層をまとめて表します。

購読例	意味	用途例
plant1/lineA/+/temperature	lineA内の全設備の温度を受け取る	温度監視
plant1/lineA/#	lineA配下の全データを受け取る	ライン監視
+/+/machine01/status	複数工場・複数ラインのmachine01状態を受け取る	同型設備の比較

ワイルドカードは便利ですが、広く取りすぎると不要データが大量に流れます。

監視画面、ログ保存、アラーム通知など、用途ごとに適切な粒度で購読することが重要です。

トピック名に入れるべき情報

トピックには、後から検索・集計しやすい情報を入れます。

工場名、ライン名、設備ID、信号種別、データ種別などです。

一方で、時刻や測定値のように毎回変わる情報はトピック名ではなく、メッセージ本文に入れる方が扱いやすいです。

6. QoSとは何か

MQTTの重要機能のひとつがQoSです。

QoSはQuality of Serviceの略で、メッセージ配送の保証レベルを表します。

MQTTには、QoS 0、QoS 1、QoS 2の3段階があります。

QoS 0：最大1回配信

QoS 0は、メッセージを一度だけ送信し、届いたかどうかを厳密には確認しない方式です。

最も軽く、通信負荷が小さい反面、通信状態が悪いとメッセージが失われる可能性があります。

温度のように次の値がすぐ来るデータ、多少欠けても全体傾向に影響しにくいデータに向いています。

QoS 1：少なくとも1回配信

QoS 1は、メッセージが少なくとも1回届くことを目指す方式です。

送信側は、受信確認を受け取るまで再送します。

そのため、メッセージが重複して届く可能性があります。

設備の状態変化やアラーム通知など、欠落を避けたいが重複処理で吸収できるデータに向いています。

QoS 2：正確に1回配信

QoS 2は、メッセージを正確に1回だけ届けることを目指す方式です。

最も保証が強い一方で、通信手順が増えるため負荷も大きくなります。

すべてのデータをQoS 2にすればよいわけではありません。

重要度、通信量、システム規模、重複許容性を考えて使い分けます。

QoS	考え方	メリット	向く用途
QoS 0	届けばよい	軽い	周期データ、傾向監視
QoS 1	最低1回届ける	欠落を減らせる	状態変化、アラーム
QoS 2	重複なく1回届ける	保証が強い	重要イベント、確実性重視

7. RetainとLast Willの使い方

MQTTでは、通常のメッセージ送受信に加えて、RetainとLast Willという便利な仕組みがあります。

どちらも設備監視やIoT運用では重要です。

Retainメッセージ

Retainは、ブローカーがそのトピックの最後のメッセージを保持する機能です。

新しく購読したクライアントは、購読した瞬間に最後の状態を受け取れます。

たとえば、設備の稼働状態が「RUN」なのか「STOP」なのかを監視画面に表示したいとします。

Retainがなければ、監視画面を開いた直後は、次の状態変化が来るまで現在状態が分かりません。

Retainを使えば、監視画面を開いた瞬間に最新状態を表示できます。

Last Will

Last Willは、クライアントが異常切断したときに、ブローカーが代わりに送信するメッセージです。

たとえば、設備ゲートウェイが正常に切断処理をせず突然通信断になった場合、ブローカーが「offline」というメッセージを配信できます。

これにより、監視側は単にデータが来ていないのか、機器が落ちているのかを判断しやすくなります。

設備監視では、「値が正常か」だけでなく「通信が生きているか」も重要です。

Last Willを使うことで、デバイス死活監視をMQTTの仕組みの中に組み込めます。

8. MQTTとHTTPの違い

MQTTとHTTPは、どちらもネットワーク上でデータを送るために使われます。

ただし、考え方は大きく異なります。

HTTPは、クライアントがサーバへ要求し、サーバが応答するリクエスト/レスポンス型です。

MQTTは、ブローカーを介してメッセージを配るPublish/Subscribe型です。

HTTPが向く用途

HTTPは、人が画面を開く、設定値を取得する、APIを呼ぶ、ファイルをダウンロードするような用途に向いています。

要求と応答がはっきりしており、Webシステムとの相性が良い方式です。

一方で、大量のデバイスが短周期で状態データを送り続ける場合は、接続やリクエストのオーバーヘッドが気になることがあります。

MQTTが向く用途

MQTTは、デバイスが常時接続し、状態変化やセンサーデータを継続的に送る用途に向いています。

受信側を増やしても、送信側の設計を大きく変えなくてよい点も強みです。

比較項目	MQTT	HTTP
通信モデル	Publish/Subscribe	リクエスト/レスポンス
中心となる相手	ブローカー	Webサーバ、APIサーバ
得意分野	状態通知、センサーデータ、IoT	画面表示、API、ファイル取得
受信者追加	購読者を増やしやすい	API利用側の設計が必要
実務上の注意	トピック設計、QoS、認証	API設計、レスポンス設計、認証

9. MQTTとModbus・OPC UAの違い

産業ネットワークでは、MQTTだけでなく、ModbusやOPC UAもよく登場します。

これらは競合する場面もありますが、実務では役割を分けて組み合わせることが多いです。

Modbusとの違い

Modbusは、PLCや計測器のレジスタを読み書きする用途で使われることが多い通信プロトコルです。

データの場所をアドレスで指定して読み取る考え方が中心です。

一方、MQTTは、メッセージをトピックに発行し、必要な相手へ配信する考え方です。

設備の近くではModbusでデータを集め、上位システムやクラウドへはMQTTで送る、という構成はよくあります。

OPC UAとの違い

OPC UAは、設備データの意味や構造を扱いやすくするための標準的な仕組みとして使われます。

変数、オブジェクト、データ型、メソッドなどを含め、設備情報を体系的に表現できます。

MQTTは、軽量なメッセージ配信に強い方式です。

そのため、OPC UAで設備データの意味を整理し、MQTTでクラウドやアプリへ配信するような組み合わせも考えられます。

項目	MQTT	Modbus	OPC UA
主な役割	軽量メッセージ配信	機器レジスタの読み書き	設備データの構造化
通信モデル	Pub/Sub	要求/応答	クライアント/サーバ、Pub/Subなど
向く範囲	IoT、クラウド連携	現場機器との接続	設備情報モデル、上位連携
注意点	データ意味は別途設計	アドレス管理が必要	設計が重くなりやすい

MQTTとModbusは対立関係ではありません。

現場機器から値を取る通信と、取得した値を上位へ配る通信として、役割を分けると理解しやすくなります。

10. 製造業でのMQTT活用例

製造業でMQTTを使う代表例は、設備データ収集、遠隔監視、異常通知、エネルギー監視、予知保全です。

特に、既存設備のデータを少しずつ集めて可視化したい場合に使いやすい方式です。

設備稼働データの収集

設備のRUN/STOP、サイクルカウント、アラーム、タクトタイムなどをMQTTで送れば、上位システム側で稼働率を集計できます。

全設備を一気に更新しなくても、ゲートウェイを追加しながら段階的にデータ収集範囲を広げられます。

この「段階導入しやすい」という点は、工場IoTでは大きなメリットです。

状態監視と異常通知

振動、温度、電流、圧力などを一定周期で送ると、設備の状態変化を監視できます。

しきい値を超えたときだけアラームトピックへ発行すれば、監視側は異常をすぐ検知できます。

ただし、MQTTはあくまで通信の仕組みです。

異常判定ロジック、しきい値設定、誤報対策、保全アクションとの接続は別途設計する必要があります。

マイコンを使った簡易IoT

小型のマイコンに温度センサーや電流センサーを接続し、Wi-Fiや有線LAN経由でMQTTブローカーへ送る構成もあります。

この場合、マイコン側のCPU、メモリ、I/O、通信モジュールの制約を考える必要があります。

マイコン側の基本構成を押さえたい場合は、マイコンとは？CPU・メモリ・IOの基本を解説もあわせて確認すると、MQTTクライアントを動かす側のイメージがつかみやすくなります。

11. MQTT導入時の設計手順

MQTTは軽量で便利ですが、思いつきで導入すると後から運用しにくくなります。

最低限、データの目的、トピック、QoS、認証、保存先、障害時の動作を決めてから設計することが重要です。

Step 1：何を送るかを決める

まず、どの設備から、どのデータを、何のために送るかを決めます。

「とりあえず全部送る」は失敗しやすい考え方です。

温度を監視したいのか、稼働率を見たいのか、アラーム履歴を残したいのかで必要なデータは変わります。

Step 2：更新周期を決める

次に、データの更新周期を決めます。

温度なら数秒〜数十秒で十分な場合があります。

振動監視ではもっと短い周期が必要になることもあります。

更新周期を短くしすぎると、通信量、ブローカー負荷、保存容量が増えます。

必要な判断に対して十分な周期を選ぶことが重要です。

Step 3：トピックとメッセージ形式を決める

トピック名とメッセージ形式は、あとから変更しにくい部分です。

JSON形式で値、単位、時刻、設備ID、品質フラグを入れるのか、単純な数値だけを送るのかを決めます。

システムが小さいうちはどちらでも動きます。

しかし、設備数が増えるほど、データ形式の統一が重要になります。

Step 4：保存と可視化の流れを決める

MQTTで送ったデータは、ブローカーに届くだけでは業務価値になりません。

データベースへ保存するのか、ダッシュボードへ表示するのか、アラーム通知へつなげるのかを決めます。

最初から大規模システムにする必要はありません。

ただし、最終的に何へ使うかを決めておくことで、不要なデータ収集を避けられます。

12. MQTTで起きやすいトラブル

MQTTのトラブルは、プロトコルそのものよりも、設計や運用の曖昧さから起きることが多いです。

特に、接続断、トピック乱立、重複メッセージ、時刻ズレ、認証不備には注意が必要です。

トピックが増えすぎる

命名ルールを決めずに運用すると、似たようなトピックが乱立します。

たとえば、temp、temperature、Temperature、machine_temp が混在すると、受信側の処理が複雑になります。

大文字小文字、単位、設備名、階層順序を最初に決めることが重要です。

QoS 1で重複処理を忘れる

QoS 1では、メッセージが重複して届く可能性があります。

重複しても問題ないデータならよいですが、カウントアップやイベント登録では二重記録の原因になります。

必要に応じて、メッセージID、時刻、シーケンス番号などで重複除外を行います。

現在値と履歴値を混同する

MQTTで送るデータには、現在状態として使いたい値と、履歴として残したい値があります。

Retainを使うべき現在状態と、時系列データベースへ保存すべき履歴データを混同すると、監視画面や分析結果が分かりにくくなります。

状態表示用、履歴保存用、アラーム通知用でトピックを分ける設計も有効です。

通信できている前提で設計してしまう

工場内ネットワークでは、ノイズ、電源断、無線品質、ルータ障害などで通信が切れることがあります。

MQTTでは再接続、Last Will、Keep Alive、オフライン時の扱いを設計しておく必要があります。

止まってはいけない処理をMQTT通信だけに依存させるのは危険です。

リアルタイム性や安全制御が必要な領域では、別の制御設計と組み合わせて考えます。

13. MQTTを使うときのセキュリティ

MQTTは便利ですが、セキュリティを軽視すると危険です。

設備データ、アラーム、制御指令、稼働情報が外部へ漏れたり、不正なメッセージが注入されたりする可能性があります。

TLSを使う

ネットワークをまたぐ場合は、TLSによる暗号化を検討します。

特にクラウドブローカーへ接続する場合、平文通信のままユーザー名やメッセージを送るのは避けるべきです。

証明書管理は手間がかかりますが、長期運用する設備では重要な設計項目です。

ユーザーごとに権限を分ける

すべてのクライアントが全トピックへPublish/Subscribeできる状態は危険です。

設備Aのゲートウェイは設備AのトピックにだけPublishできる、監視画面は必要なトピックだけSubscribeできる、というように権限を分けます。

誤設定や不正接続があっても影響範囲を小さくできます。

制御指令トピックは特に慎重に扱う

MQTTで制御指令を送る場合は、特に慎重な設計が必要です。

誤ったメッセージで設備が動くと、安全上の問題につながる可能性があります。

制御指令は認証、権限、確認応答、異常時停止、現場側インターロックを含めて設計します。

安全や順序制御の基本を整理したい場合は、シーケンス制御とは？PLC・ラダー図・資格までも参考になります。

14. MQTTを選ぶべきかの判断基準

MQTTは万能ではありません。

IoT通信に強い一方で、すべての産業通信を置き換えるものではありません。

選定時には、データの性質、リアルタイム性、接続台数、通信頻度、システム構成を確認します。

MQTTが向くケース

• 多数のデバイスから小さなデータを集めたい場合
• センサーデータや状態変化を継続的に送信したい場合
• 送信側と受信側を疎結合にしたい場合
• クラウド、ダッシュボード、分析アプリへ同じデータを配りたい場合
• ネットワーク帯域やデバイスリソースを抑えたい場合

MQTTだけでは不足しやすいケース

• ミリ秒単位の厳密なリアルタイム制御が必要な場合
• 安全停止やインターロックを通信依存にしたい場合
• 設備データの意味や型を標準化して扱いたい場合
• 既存PLCのレジスタ読み書きが中心の場合
• 通信断時も制御動作を絶対に継続させたい場合

このような場合は、フィールドバス、産業用Ethernet、OPC UA、Modbus、ローカル制御などと役割分担します。

MQTTは「現場データを上位へ軽く配る」用途で強みを発揮すると考えると、使いどころを間違えにくくなります。

15. よくある質問

Q1. MQTTとは簡単に言うと何ですか？

MQTTとは、センサーや機器が小さなデータを軽く送受信するための通信プロトコルです。

ブローカーを中心に、送信側がメッセージを発行し、受信側が必要なトピックを購読する仕組みです。

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

MQTTブローカーとは、クライアント同士のメッセージを中継するサーバです。

送信側から届いたメッセージを受け取り、そのトピックを購読している受信側へ配信します。

Q3. MQTTはPLC通信に使えますか？

使える場合があります。

ただし、PLC本体がMQTTに対応していない場合は、PLCからModbusやOPC UAなどでデータを取り、ゲートウェイでMQTTへ変換する構成が一般的です。

Q4. MQTTとHTTPはどちらを使うべきですか？

センサーデータや状態変化を継続的に送るならMQTTが向いています。

画面表示、設定取得、API呼び出しのように要求と応答が明確な処理ならHTTPが向いています。

Q5. MQTTはリアルタイム制御に使えますか？

状態通知や監視には使えますが、厳密なリアルタイム制御や安全制御の主経路にするには注意が必要です。

制御周期、安全停止、通信断時の動作を考えると、ローカル制御や専用の産業通信と組み合わせるのが一般的です。

16. まとめ

MQTTは、IoTや設備データ連携でよく使われる軽量な通信プロトコルです。

ブローカーを中心に、送信側がデータをPublishし、受信側が必要なトピックをSubscribeすることで、多数の機器やアプリを柔軟につなげます。

MQTTを理解するうえで重要なのは、ブローカー、トピック、QoS、Retain、Last Will、認証設計です。

これらを適切に設計すれば、設備監視、遠隔監視、異常通知、クラウド連携などで使いやすい仕組みを作れます。

一方で、MQTTは万能ではありません。

現場機器のレジスタ読み書きにはModbus、設備データの意味付けにはOPC UA、厳密なリアルタイム制御にはローカル制御や産業用ネットワークが必要になる場合があります。

MQTTは「軽く配る通信」として位置づけ、他の通信方式と役割分担して使うことが実務上のポイントです。