HTTPとMQTTの使い分けとは？一言でいうと？
基本の比較は、HTTPの要求・応答と、MQTTのブローカーを使うpublish/subscribeです。ただしHTTPにも応答を開いたまま通知を送るSSEなどがあり、「HTTPなら必ず定期ポーリング」とは限りません。
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が使われる、という役割分担が生まれます。
HTTP
要求・応答型
- つながる相手クライアントがサーバの URI を知っていて要求を送る
- データの流れサーバが要求に応答する
- 1対多の配信受け手ごとに要求・応答が必要
- サーバ側からの送信新しい指示は定期的な問い合わせ（ポーリング）で知る
MQTT
publish/subscribe 型
- つながる相手送り手も受け手もブローカーとだけつながる
- データの流れ送り手がトピックに発行し、ブローカーが購読者へ配る
- 1対多の配信1回の発行で購読者全員に届く
- サーバ側からの送信接続を保っていれば、指示が出た時点で届く
「必要なときに聞きに行く」なら HTTP、「変化があったら配ってもらう」なら MQTT。
通信モデル・ヘッダの重さ・双方向はどう違う？比較表
| 比較軸 | HTTP | MQTT |
|---|---|---|
| 規格 | IETF。意味はRFC 9110、HTTP/1.1はRFC 9112、HTTP/2はRFC 9113、HTTP/3はRFC 9114（いずれも2022年6月） | OASIS MQTT 5.0（2019年3月7日）。3.1.1はISO/IEC 20922:2016 |
| 通信モデル | 要求・応答（クライアントが聞き、サーバが答える） | publish/subscribe（ブローカーが購読者へ配る） |
| 相手を知る必要 | クライアントがサーバのURIを知っている | 送り手も受け手もブローカーだけを知っていればよい |
| 1対多の配信 | 受け手ごとに要求・応答が必要 | 1回の発行でブローカーが購読者全員に配る |
| サーバ側からの送信 | 基本はクライアントの要求への応答として返す | 接続を保ったまま、ブローカーからいつでも配信できる |
| ヘッダの重さ | 名前と値の組のヘッダ（HTTP/2はHPACK、HTTP/3はQPACKで圧縮） | 固定ヘッダは最小2バイト |
| 下位の通信 | HTTP/1.1・HTTP/2はTCP、HTTP/3はQUIC（UDPベース） | TCP/IP、TLS、WebSocketなど順序どおり欠けずに届く通信 |
| 既定ポート | http 80、https 443 | 1883（TLSなし）、8883（TLS） |
| 確実さの調整 | アプリケーション側で再送などを作る | QoS 0・1・2で選べる |
表と既存図のHTTP側は、通常の問い合わせやポーリングを代表例として読んでください。HTTPでは応答の中でイベントを継続送信するSSEも使えます。MQTTでは、接続を保った購読者へブローカーが配信します。到着の遅延や接続断への扱いは、それぞれの設計条件で確認します。
双方向の通信が必要なブラウザ向けには、WebSocket（RFC 6455、2011年12月）があります。WebSocketはTCPの上で、サーバとの双方向の通信を、複数のHTTP接続を開かずに実現するためのプロトコルです。MQTTの仕様書は、MQTTを運ぶ手段としてWebSocketも使えるとしています。
POINT
HTTP/3は、HTTPの意味（メソッドやステータスコード）をQUICの上に載せたものです。QUIC（RFC 9000、2021年5月）はUDPを使う、多重化と暗号化を備えたトランスポートです。HTTPの版が変わっても、要求・応答型という通信モデルは変わりません。
HTTPの応答を開いたまま受け取るSSEもある
WHATWGのHTML Standardは、EventSourceでHTTPを使ったサーバからのイベント配信を定めています。応答はtext/event-streamで送り、複数イベントを流せます。ブラウザが毎回新しい値を取りに行くポーリングだけがHTTPの使い方ではありません。
たとえば監視画面の値を更新するなら、サーバから画面への通知をSSEで受け、利用者の設定変更は別のPOSTで送る構成を考えられます。MQTTを不要とする一般則ではなく、通知方向、購読者の数、端末、再接続などの条件を比較する例です。
| 方法 | 更新を受け取る流れ | 別途確かめること |
|---|---|---|
| HTTPポーリング | 画面側から繰り返し問い合わせ | 間隔と通信回数 |
| HTTP上のSSE | 開いた応答でサーバ→画面へイベント | 接続断・再接続、操作用の要求 |
| MQTT | ブローカーがトピックの購読者へ配信 | 購読・QoS・接続状態 |
SSEの再接続やイベントIDがあっても、業務処理の重複が自動的に消えるとは限りません。方式名と、アプリ側で必要な確認を分けてください。
用途からどう選ぶ？判断の手順
設計の場面や事例型の4択では、次の順に条件を確かめると選びやすくなります。
- 1
複数の相手に配るか
はい → MQTT（1回の発行で配れる）
- 2
端末へすぐ指示を届けるか
はい → MQTT（接続を保って配信を受ける）
- 3
回線が細い・不安定・機器が非力か
はい → MQTT。さらに軽くするなら CoAP も候補
- 4
既存の Web API とつなぐか
はい → HTTP（HTTPS）で直接呼ぶ
- 5
まとまったデータを一度に送るか
はい → HTTP（画像・ログ・ファームウェア）
区間ごとに選ぶ。現場の機器とクラウドの間は MQTT、クラウドと外部サービスの間は HTTP のような使い分けも多い。
判断の順番は当サイトの整理です。
- 同じデータを複数の相手に配るか：監視画面・記録サーバ・分析システムなど受け手が複数なら、1回の発行で配れるMQTTが有利。
- 通知の方向・接続・遅延を確認する：MQTTの購読配信、HTTPのポーリング、SSE等を比較する。ポーリングでは問い合わせ間隔の待ち時間が生じるが、HTTP全体に一律の間隔があるわけではない。
- 回線が細い・不安定・機器が非力か：ヘッダが小さく、QoSで確実さを選べるMQTTが扱いやすい。さらに軽くしたい場合は、UDPで動くCoAPも候補になる。
- 既存のWeb API・クラウドのサービスとつなぐか：REST APIとして公開されている相手なら、HTTP（HTTPS）で直接呼ぶのが素直。
- まとまったデータを一度に送るか：画像・ログ・ファームウェアのファイルなど、1回の要求で大きなデータを受け渡すならHTTP。
実際のIoTシステムでは、現場の機器とゲートウェイ・クラウドの間はMQTT、クラウドと外部サービスの間はHTTPのように、区間ごとに使い分けることも珍しくありません。どちらか一方が常に優れている、という選択肢には注意してください。
IoT中級ではどこで、どう問われる？
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の通信トラフィックの特性 にまとめています。
どこで取り違えやすい？つまずき別の見直し表
| 取り違え | 正しい整理 | 見直す手がかり |
|---|---|---|
| HTTP/3もTCPで動くと思う | HTTP/3はQUIC（UDPベース）の上で動く。TCPを使うのはHTTP/1.1とHTTP/2 | RFC 9114＝QUICの上のHTTP |
| MQTTも要求・応答型だと思う | MQTTはpublish/subscribe型。ブローカーが購読者へ配る | 「購読」「トピック」ならMQTT |
| MQTTはHTTPより常に優れていると思う | Web APIとの連携や大きなファイルの送信はHTTPが素直 | 区間ごとに使い分ける |
| HTTPは状態を持つと思う | RFC 9110はHTTPを状態を持たないプロトコルと定義。状態はクッキーなどで別に扱う | ステートレス |
| MQTTでは端末どうしが直接つながると思う | 送り手も受け手もブローカーとだけ接続する | 中継役はブローカー |
確認問題1
多数の画面へ同時に配るならどれ？
工場の設備の稼働状態を、事務所の監視画面、保守担当者のタブレット、記録用サーバの3か所へ、変化のたびに同時に届けたい。最も適した方法はどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：3。MQTTなら、設備が1回発行するだけで、ブローカーがトピックを購読している3か所すべてに配ります。受け手が増えても設備側の設定は変わりません。
1は変化がなくても問い合わせが続き、問い合わせの間隔の分だけ届くのが遅れます。2は受け手ごとに送り直す必要があり、受け手が増えるほど設備の負担が増えます。4は記録用サーバにしか届かず、「3か所へ同時に」という条件を満たしません。
確認問題2
HTTP/3の下位で使われるのは？
RFC 9114で規定されたHTTP/3が、HTTPの意味を載せて運ぶために使うトランスポートとして、最も適切なものはどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：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）などに使われます。
確認問題3
IoTでの使い分けとして適切でないものは？
IoTシステムでのHTTPとMQTTの使い分けの説明として、適切でないものはどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解：4。MQTTはpublish/subscribe型で、1回の発行をブローカーが複数の購読者に配るため、1対多の配信に向きます。「要求・応答型」「1対多に向かない」の2点とも誤りです。
1は、接続を保っておけばブローカーからすぐに配信を受けられるので適切です。2は、REST APIとして公開された相手にはHTTP（HTTPS）で直接つなぐのが素直なので適切です。3も、まとまったファイルを1回の要求で受け取る用途にHTTPが向くため適切です。
プロトコルの使い分けに慣れたら、IoT中級の無料お試し20問 で、データ活用やセキュリティも含めた本番に近い形で試してください。登録なしで全問の解説まで読めます。
通信方式を選んだ後の再送設計
通信方式の違いを理解したら、再送時の重複登録と冪等性で、通信の到達と業務処理の完了を分けて考えます。タイムアウトは、サーバーで処理されなかった証拠とは限りません。