IoTの通信トラフィックの特性｜IoT中級の要点

IoTの通信トラフィックとは、センサや機器がネットワークに流すデータの量・向き・タイミングの特徴のことです。一言でいうと、「小さなデータを、非常に多くの端末が、上り中心に、そろったタイミングで送りやすい」通信です。

3GPPは5Gのシステムの概要で、利用場面の1つとして mIoT（Massive Internet of Things） を挙げ、「いくつかの場面では、5Gのシステムが非常に高い密度の機器のトラフィックを支える必要がある」と説明しています。同じ概要では、高速な通信（eMBB）や、遠隔制御のように極めて高い信頼性と低遅延を求める通信（Critical Communications・URLLC）とは別の要件として整理されています（2026年9月27日確認）。

つまり、IoTの通信は「速さ」よりも、数の多さ・省電力・確実さのどれを重視するかで設計が変わります。NB-IoTやLTE-M、LoRaWANなどのLPWAが「低速でよいから多数を省電力でつなぐ」方向に作られているのは、この性質に合わせるためです。

スマートフォンでの動画視聴やWeb閲覧と、センサの定期送信を同じ軸で比べます。

このため、IoTでは1回あたりの付随データ（ヘッダ、接続の手続き）の割合が大きくなりやすい点に注意が必要です。測定値が数十バイトでも、毎回TCPの接続を張り、大きなヘッダを付けて送ると、本体より手続きのほうが重くなります。MQTTの固定ヘッダが最小2バイトであることや、CoAPがUDPの上で4バイトの固定ヘッダを使うことは、この事情への対応と考えると覚えやすくなります。

また、遅延への要求は一律ではありません。電力量の検針値は数分遅れても困りませんが、工場の設備の非常停止の指示は即座に届く必要があります。「IoTの通信はすべて遅れてよい」「すべて低遅延が必要」のような一律の言い切りは、選択肢として疑ってください。

同じ製品を大量に設置すると、同じ設定のまま動くため、多くの機器が同じ時刻に通信を始めることがあります。停電からの復旧直後に全機器が一斉に再接続する、サーバの障害のあと全機器が同じ間隔で再送を繰り返す、といった場面でも同じことが起きます。こうした集中は、基地局やゲートウェイ、サーバの処理を一時的に詰まらせます。

IETFの文書には、こうした同期を避けるための考え方が書かれています。

ポイントは、「タイミングを散らす」「失敗したら待つ」「回数を減らす」の3系統に分けて覚えることです。サーバや回線を増強するのも対策の1つですが、機器側の送り方を変えずに増強だけで対応すると、台数が増えるたびに同じ問題が起きます。

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

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

• IoTのトラフィックの特徴として適切な組合せ（小さい・多い・上り中心など）を選ぶ
• 一斉接続を和らげる対策として適切なもの・適切でないものを選ぶ
• 用途ごとの遅延の要求の違い（検針と遠隔制御など）を問う
• トラフィックの性質から、適した通信方式やプロトコルを選ぶ

トラフィックの性質に合わせて作られた携帯系の方式は NB-IoTとLTE-Mの違い、プロトコルの選び方は HTTPとMQTTの使い分け で確認できます。届いた大量のデータをどう処理するかは ストリーム処理とバッチ処理の違い で扱います。

人のスマートフォンの通信と比べた、センサを中心とするIoTの通信トラフィックの特徴として、最も適切なものはどれか。

1. 11回のデータが大きく、少数の端末が下り中心に通信する
2. 21回のデータが小さく、多数の端末が上り中心に通信する
3. 31回のデータが大きく、多数の端末が下り中心に通信する
4. 41回のデータが小さく、少数の端末が常時接続で通信する

正解：2。センサの定期送信は1回のデータが小さく、端末の数が非常に多く、端末から送る上りが中心になりやすいのが特徴です。

1は「大きい・少数・下り中心」で、動画視聴のような人の通信に近い説明です。3も1回のデータの大きさと向きが逆です。4は「小さい」は合っていますが、IoTの特徴は端末の数の多さで、多くの機器は短い送信のあと長く休む間欠的な通信をします。

同じ設定の電力センサ1万台が、毎時0分ちょうどにサーバへ測定値を送っており、その時刻だけサーバの応答が遅れる。機器側の設定で行う対策として、最も適切なものはどれか。

1. 1全台の送信時刻を毎時0分ちょうどにそろえ直す
2. 2応答が遅れたら同じ間隔ですぐに再送を繰り返す
3. 3送信のたびにQoSを上げて確認応答を必ず求める
4. 4送信時刻に機器ごとのランダムなずれを加える

正解：4。機器ごとにランダムなずれ（ジッタ）を加えると、送信が時間の中に散らばり、同じ時刻への集中を和らげられます。IETFのRFC 8085も、死活確認の送信にわずかなランダムな変動を加えて同期を減らすことを推奨しています。

1は集中をかえって強めます。2は、再送も全台で同期してしまい、混雑を長引かせます。再送するなら待ち時間を倍々に延ばす指数バックオフを使います。3は確認応答のやり取りが増える分、通信量が増え、同じ時刻への集中そのものは解消しません。

IoTの通信における遅延の要求についての説明として、適切でないものはどれか。

1. 1電力量の検針値は、数分遅れて届いても困らないことが多い
2. 2設備の非常停止の指示は、即座に届くことが求められる
3. 3IoTの通信は小さいので、遅延は考えなくてよい
4. 4同じシステムでも、データの種類で求める遅延が変わる

正解：3。データが小さいことと、遅延に寛容であることは別の話です。遠隔制御や非常停止のように、小さなデータでも即座に届く必要がある用途があります。

1は、検針値のように後でまとめて使うデータは多少の遅れを許容できるため適切です。2は、安全に関わる指示は低遅延が求められるため適切です。4も、同じ工場のシステムの中で、定期の測定値と警報とで求める遅延が違うことはよくあるため適切です。

通信方式の問題にほかの分野も混ぜて、本番に近い形式で解くなら IoT中級の無料お試し20問 へ。登録なしで全問の解説まで確認できます。