HTTPとMQTTの使い分け｜IoT中級で問われる点

一言でいうと、「必要なときに聞きに行く」ならHTTP、「変化があったら配ってもらう」ならMQTTです。

HTTPは、IETFのRFC 9110（2022年6月）で「状態を持たないアプリケーション層のプロトコル」と定義され、クライアントが送った要求にサーバが応答する形が基本です。各要求はそれだけで理解できるように扱われます。MQTTは、OASIS標準のMQTT 5.0（2019年3月7日）で定められたpublish/subscribe型で、センサなどが発行したメッセージを、ブローカー（サーバ）がそのトピックを購読しているクライアントに配ります（2026年9月27日確認）。

IoTでは、センサの値を1か所に集めて複数の画面やシステムに配る、クラウドから現場の機器へ指示を送る、といった流れが多くなります。この「配る」「押し出す」の場面でMQTTが選ばれやすく、クラウドのWeb APIとのやり取りや大きなファイルの送信ではHTTPが使われる、という役割分担が生まれます。

表で差が大きいのは、1対多の配信とサーバ側からの送信の行です。HTTPで「サーバから端末へ新しい指示があるか」を知るには、端末が定期的に問い合わせる（ポーリングする）必要があり、指示がなくても通信と電力を使います。MQTTでは端末がブローカーとの接続を保っておけば、指示が出た時点で届きます。

双方向の通信が必要なブラウザ向けには、WebSocket（RFC 6455、2011年12月）があります。WebSocketはTCPの上で、サーバとの双方向の通信を、複数のHTTP接続を開かずに実現するためのプロトコルです。MQTTの仕様書は、MQTTを運ぶ手段としてWebSocketも使えるとしています。

設計の場面や事例型の4択では、次の順に条件を確かめると選びやすくなります。

1. 1同じデータを複数の相手に配るか：監視画面・記録サーバ・分析システムなど受け手が複数なら、1回の発行で配れるMQTTが有利。
2. 2サーバから端末へ、すぐに指示を届けるか：遠隔操作や設定変更を待たせたくないなら、接続を保って配信を受けるMQTT。HTTPでは問い合わせの間隔の分だけ遅れる。
3. 3回線が細い・不安定・機器が非力か：ヘッダが小さく、QoSで確実さを選べるMQTTが扱いやすい。さらに軽くしたい場合は、UDPで動くCoAPも候補になる。
4. 4既存のWeb API・クラウドのサービスとつなぐか：REST APIとして公開されている相手なら、HTTP（HTTPS）で直接呼ぶのが素直。
5. 5まとまったデータを一度に送るか：画像・ログ・ファームウェアのファイルなど、1回の要求で大きなデータを受け渡すならHTTP。

実際のIoTシステムでは、現場の機器とゲートウェイ・クラウドの間はMQTT、クラウドと外部サービスの間はHTTPのように、区間ごとに使い分けることも珍しくありません。どちらか一方が常に優れている、という選択肢には注意してください。

HTTPとMQTTの使い分けは、IoTシステム技術検定 中級の出題カテゴリ「センサ／アクチュエータ技術と通信方式（デバイス、ネットワーク、LPWA、プロトコル）」の「プロトコル」に当たります。公式ページの図では比率が25〜30%です（MCPC公式ページ、2026年9月27日確認）。公式テキスト『IoT技術テキスト 第4版』では第4章「IoT通信方式」に当たる範囲です（章とカテゴリの対応は当サイトの推定）。

出題数は公表されていません。4択では、次のような観点が考えられます（当サイトの予想で、出題の再現ではありません）。

• 要求・応答型とpublish/subscribe型の特徴を入れ替えた記述を見抜く
• 用途の条件（1対多、遠隔操作、細い回線）から適したプロトコルを選ぶ
• 各プロトコルの下位の通信（HTTP/3はQUIC、MQTTはTCP、CoAPはUDP）の組合せ
• ヘッダの大きさや、サーバからの送信の可否など、IoT向きの理由を問う

MQTTのQoSや保持メッセージは MQTTとは、UDPで動くREST型の選択肢は CoAPとは で詳しく扱います。小さなデータが大量に届くというIoTの通信の性質は IoTの通信トラフィックの特性 にまとめています。

工場の設備の稼働状態を、事務所の監視画面、保守担当者のタブレット、記録用サーバの3か所へ、変化のたびに同時に届けたい。最も適した方法はどれか。

1. 1各画面が数秒ごとにHTTPのGETで設備に問い合わせる
2. 2設備が各画面へ順番にHTTPのPOSTで送り直す
3. 3設備がMQTTで発行し、3か所がトピックを購読する
4. 4設備がCoAPのNONで記録用サーバにだけ送る

正解：3。MQTTなら、設備が1回発行するだけで、ブローカーがトピックを購読している3か所すべてに配ります。受け手が増えても設備側の設定は変わりません。

1は変化がなくても問い合わせが続き、問い合わせの間隔の分だけ届くのが遅れます。2は受け手ごとに送り直す必要があり、受け手が増えるほど設備の負担が増えます。4は記録用サーバにしか届かず、「3か所へ同時に」という条件を満たしません。

RFC 9114で規定されたHTTP/3が、HTTPの意味を載せて運ぶために使うトランスポートとして、最も適切なものはどれか。

1. 1TCPの上のTLS 1.2
2. 2UDPを使うQUIC
3. 3TCPの上のWebSocket
4. 4UDPを使うDTLS

正解：2。HTTP/3は、HTTPの意味をQUIC（RFC 9000）の上に載せたものです。QUICはUDPを使い、多重化と暗号化を備えたトランスポートです。

1はHTTP/1.1やHTTP/2をHTTPSで使うときの組合せに近く、HTTP/3ではありません。3のWebSocketはTCPの上で双方向の通信を行うプロトコルで、HTTP/3の土台ではありません。4のDTLSはUDP向けのTLSで、CoAPの暗号化（coaps）などに使われます。

IoTシステムでのHTTPとMQTTの使い分けの説明として、適切でないものはどれか。

1. 1遠隔操作の指示をすぐ届けたいので、端末はMQTTで接続を保つ
2. 2外部のREST APIを呼び出す区間は、HTTPSで通信する
3. 3ファームウェアのファイルは、HTTPSでまとめて取得する
4. 4MQTTは要求・応答型なので、1対多の配信には向かない

正解：4。MQTTはpublish/subscribe型で、1回の発行をブローカーが複数の購読者に配るため、1対多の配信に向きます。「要求・応答型」「1対多に向かない」の2点とも誤りです。

1は、接続を保っておけばブローカーからすぐに配信を受けられるので適切です。2は、REST APIとして公開された相手にはHTTP（HTTPS）で直接つなぐのが素直なので適切です。3も、まとまったファイルを1回の要求で受け取る用途にHTTPが向くため適切です。

プロトコルの使い分けに慣れたら、IoT中級の無料お試し20問 で、データ活用やセキュリティも含めた本番に近い形で試してください。登録なしで全問の解説まで読めます。