はじめに：なぜ、現代のスマートホームは「あれ、なんか遅い」現象に陥るのか
こんにちは。シニアネットワークエンジニアの私です。
夜、リビングのソファでくつろぎながら、ふとスマホでスマートホームのアプリを開く。リビングのスマート照明、ベランダの温湿度センサー、玄関のスマートロック、そして天井で静かに佇む見守りカメラ。これら十数台のIoTデバイスが、我が家の小さな無線空間で「ただいま、異常なし」と絶えず小さなパケットを母艦であるWi-Fiルーターへ投げ続けています。
しかし、ふと気づくと、最新のWeb APIを叩くスマートフォンや、数メガバイトのJSONペイロードをやり取りするエッジサーバーとの通信で、妙な「一瞬の引っかかり（ジッターの悪化）」を感じたことはありませんか？
「うちの回線は1Gbpsの光ファイバーなのに、なんで？」
「ルーターも、ちょっと前に入れた高価なフラッグシップモデルなのに……」
現場でインフラやWeb APIの設計に携わるエンジニアなら、このモヤモヤの正体が帯域幅（Bandwidth）の枯渇ではなく、「トラフィックの非効率な多重化とパケットスケジューリングの限界」にあることにお気づきでしょう。
従来のWi-Fi 5（802.11ac）までの世界では、ルーターの電波（チャンネル）は、たとえ数バイトの小さなIoTセンサーからのデータであっても、その瞬間は「1つの巨大なトラック」を丸ごと1台に占有させていました。これでは、細かな荷物が無数に走り回るスマートホームの現場において、道路のキャパシティがいくらあっても大渋滞が起きて当然です。
この構造的なボトルネックを根本から粉砕したのが、Wi-Fi 6（802.11ax）で導入された OFDMA（Orthogonal Frequency Division Multiple Access） と、その中核技術である RU（Resource Unit：リソースユニット）割当 です。
今回は、パケットが電波空間を駆け巡る物理層の挙動から、それが私たちのWeb APIやIoTインフラのレイテンシにどう直結しているのか、現場のリアルな視点を交えて徹底的に解説します。
—
1. OFDMAとRU（リソースユニット）の基本概念
従来のOFDMから、直交周波数分割多元接続（OFDMA）への進化
OFDM（Orthogonal Frequency Division Multiplexing）は、Wi-Fi 4（802.11n）から使われてきた伝統的な変調技術です。1つのチャンネル（例えば20MHz幅）を多数の直交するサブキャリアに分割し、そこにデータを分散して乗せることで、マルチパス干渉に強い高速通信を実現していました。
しかし、決定的な弱点がありました。それは 「一度に電波を占有できるのは1台のデバイスだけ」 という時分割（TDMA的アプローチ）の制約です。
Wi-Fi 6で導入された OFDMA は、このサブキャリアの束をさらに縦横（周波数軸×時間軸）に細かくメッシュ状に切り刻みます。この切り刻まれた周波数と時間の最小ブロックこそが RU（Resource Unit） です。
RUのサイズと物理的意味
IEEE 802.11axの仕様書（RFCではなくIEEE規格ですが）を紐解くと、20MHzのチャンネル幅の中には、サブキャリアが256個存在します。これをどのように分割するかによって、いくつかのRUサイズが定義されています。
- 26トーン RU: 最も小さな単位。IoTセンサーなどの「数バイトのステータス送信」に最適。1つの20MHzチャンネル内に最大9つ配置可能。
- 52トーン RU: 中規模のデータ用。最大4つ配置可能。
- 106トーン RU: やや大きめのパケット用。最大2つ配置可能。
- 242トーン RU: 20MHz幅を丸ごと1つのデバイスに割り当てる（従来のOFDM挙動に近い）。
現場のエンジニア視点でこの構造を見ると、まるで 「大規模なKubernetesクラスタで、Podのサイズに応じてCPUとメモリ（この場合は周波数と時間）を動的にスライスして割り当てている状態」 そのものです。
小さな「ヘルスチェック」を投げるだけのIoTデバイスには最小の 26トーン RU を、重いREST APIのレスポンスを待つPCには 242トーン RU を、アクセスポイント（AP）のMACレイヤー（MAC層のスケジューラ）が瞬時に割り振る。これがOFDMAの本質です。
—
2. 通信フロー：ダウンリンク（DL）およびアップリンク（UL）OFDMAの裏側
では、実際に空中で何が起きているのか。APと複数のクライアント間で行われる制御とデータ転送のシーケンスを見てみましょう。
特に注目すべきは、Wi-Fi 6で初めて実装された 「アップリンク（UL）OFDMA」 です。従来のWi-Fiでは、上り方向（クライアントからAP）の通信は完全に各クライアントの「早い者勝ち（CSMA/CA：キャリア感知多重アクセス）」であり、これが競合によるパケットロスとレイテンシ増大の元凶でした。
シーケンス図（概念）
[AP (ルーター)] [Client A (IoT)] [Client B (PC)]
│ │ │
│──(1) Trigger Frame (DL) ─────►│ │
│ (RU割当情報を通知) │ │
│──(1) Trigger Frame (DL) ─────────────────────────►│
│ │ │
│◄──(2) UL Data (RU 26) ────────│ │
│◄──(2) UL Data (RU 242) ───────────────────────────│
│ │ │
│──(3) Multi-STA BlockAck (DL)─►│ │
│──(3) Multi-STA BlockAck (DL)─────────────────────►│
│ │ │1. Trigger Frame（トリガーフレーム）の送信
APのMAC層スケジューラは、接続されている各端末のバッファ状況（Buffer Status Report: BSRなど）を把握した上で、どの端末にどのRU（例：Client Aには RU 26、Client Bには RU 242）を割り当てるかを記した制御パケット Trigger Frame を一斉ブロードキャスト/マルチキャストします。
2. 同期されたアップリンク送信（UL OFDMA）
Trigger Frameを受け取った各クライアントは、指定された正確なタイミングと周波数位置（RU）を使って、一斉にデータをAPへ送り返します。競合（コリジョン）は起きません。
3. 一括ACK応答（Multi-STA BlockAck）
APは受信した複数のパケットに対する確認応答を、1つの Multi-STA BlockAck フレームにまとめて各クライアントへ返します。
この一連のフローにより、ネットワーク全体のオーバーヘッドが劇的に削減され、スマートホーム環境で頻発する「多数のデバイスからの微小な上りパケットの衝突」が綺麗に解消されます。
—
3. IoT環境における遅延削減効果とWeb APIへの影響
インフラエンジニアやWeb API開発者にとって、無線区間のレイテンシ改善はアプリケーション層の挙動に直結します。
IoTデバイスからのHTTP/MQTTリクエストの変貌
例えば、自宅の温湿度センサーが数秒おきに、AWS上のIoT CoreやローカルのHome AssistantへJSONデータを送るシーンを考えてみます。
- Wi-Fi 5（従来）:
センサーが起きる ➔ 空きを待つ（バックオフ制御で待たされる） ➔ 電路を確保する ➔ 数十バイトのJSONを送信する。
*この「待たされる時間（ジッター）」が数ミリ秒〜数十ミリ秒に及び、時には再送が発生して数百ミリ秒の遅延になっていました。*
- Wi-Fi 6（OFDMA）:
APのスケジューラが常に目を光らせており、センサーの微小なバッファを検知した瞬間、次のTrigger Frameで最小の 26トーン RU を即座にアサイン。
*待ち時間がほぼゼロになり、パケットが即座にバックボーンへ抜けていく。*
Web API設計者への実務的示唆
自宅内のローカルサーバーやクラウドAPIと通信するスマートデバイスの遅延が安定すると、以下のような実務上のメリットが生まれます。
1. TCPコネクションの維持とタイムアウトの減少:
無線区間での無駄なパケット破棄や再送が減るため、HTTP keep-aliveのセッションが安定し、APIのレスポンスタイム（P99レイテンシ）が劇的に改善します。
2. リアルタイム性の向上:
見守りカメラのストリーミング映像や、スマートロックの解錠リクエストといった「一刻を争うコマンド」が、他のデバイスのバックグラウンド通信（クラウドへの写真バックアップなど）に邪魔されなくなります。
—
4. 実務での設定・デバッグTipsとコード例
さて、ここからは現場のエンジニアリングの話です。「理論はわかった、じゃあ自宅やオフィスの無線環境、あるいはLinuxベースのカスタムAP（OpenWrt等）やパケット解析で、どうやってこれを検証・設定するのか？」という疑問にお答えします。
パケット解析（Wireshark）でのOFDMA/RUの確認
Wi-Fi 6のOFDMAパケットを空中でキャプチャ（モニターモード）する場合、通常の無線アダプターではキャプチャできないことがあります。Intel AX200/AX210などのWi-Fi 6対応NICを搭載したLinuxマシンで、tcpdump や Wireshark を使用します。
フィルターで wlan.fc.type_subtype == 0x002c （Trigger Frameのサブタイプ）を指定すると、APがどのようにRUを割り当てているかの制御情報を覗き見ることができます。
また、Pythonを用いて、ローカルのAPIサーバー（FastAPIなど）でスマートデバイスからのリクエストの到着間隔（レイテンシの揺らぎ）を計測する簡単なスクリプトの例を見てみましょう。
PythonによるAPIレイテンシ・ジッター測定スクリプト
import time
import requests
from statistics import mean, stdev
# 測定対象のエッジAPIエンドポイント（スマートホームのローカルハブなど）
API_ENDPOINT = "http://192.168.1.100:8123/api/states"
HEADERS = {"Authorization": "Bearer YOUR_LONG_LIVED_ACCESS_TOKEN"}
def measure_latency(trials=50):
latencies = []
print(f"[*] 測定開始: {trials}回のリクエストを送信します...")
for i in range(trials):
start_time = time.perf_counter()
try:
response = requests.get(API_ENDPOINT, headers=HEADERS, timeout=2.0)
end_time = time.perf_counter()
if response.status_code == 200:
# 往復遅延をミリ秒で算出
latency_ms = (end_time - start_time) * 1000
latencies.append(latency_ms)
else:
print(f"[!] HTTPエラー: {response.status_code}")
except requests.exceptions.RequestException as e:
print(f"[!] 接続エラー: {e}")
# 実際のIoTデバイスの送信間隔を模倣するために少しウェイトを入れる
time.sleep(0.1)
if latencies:
print("\n--- 測定結果 ---")
print(f"サンプル数: {len(latencies)}")
print(f"平均レイテンシ (Mean): {mean(latencies):.2f} ms")
print(f"標準偏差 (Jitter/StDev): {stdev(latencies):.2f} ms")
print(f"最大レイテンシ (Max): {max(latencies):.2f} ms")
print(f"最小レイテンシ (Min): {min(latencies):.2f} ms")
if __name__ == "__main__":
measure_latency()このスクリプトを、Wi-Fi 5のルーター環境と、OFDMAが正しく有効化されたWi-Fi 6/7のルーター環境でそれぞれ実行してみてください。標準偏差（Jitter）の値に明確な差が現れるはずです。
ネットワーク機器（OpenWrt等）での調整・デバッグTips
もしご自宅のメインルーターやアクセスポイントに、OpenWrtや企業向けのプロシューマー向け機器（UbiquitiやMikroTikなど）を導入している場合、以下のパラメーターに注意してください。
1. OFDMAの有効化（DL/UL双方）:
無線設定ファイル（例：/etc/config/wireless）やWeb UIにおいて、he_ofdma や he_ul_ofdma といったパラメータが有効（1 または enable）になっていることを確認します。
# OpenWrtの無線設定例 (wireless)
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option band '5g'
option htmode 'VHT80' # または HE80 (Wi-Fi 6)
option ieee80211ax '1'
option he_ofdma '1' # ダウンリンクOFDMAの有効化
option he_ul_ofdma '1' # アップリンクOFDMAの有効化（これが重要）2. ビームフォーミングとTWT（Target Wake Time）の併用:
OFDMAの効果を最大化するためには、TWT（デバイスが次に起きる時間をAPとネゴシエーションする機能）も同時に有効にすると、IoTデバイスのバッテリー寿命が劇的に伸びると同時に、電波空間上の競合トラフィックそのものを削減できます。
3. レガシーデバイスの分離（バンドステアリングの弊害に注意）:
Wi-Fi 4（802.11n）やそれ以前の古いスマート家電が同じチャンネルに混ざっていると、APのOFDMAスケジューラがレガシー機への対応にリソースを取られ、効率が低下することがあります。可能な限り、IoT専用のSSIDを分離し、Wi-Fi 6以降対応デバイスだけでRU割当の恩恵を受けられるクリーンな空間をデザインするのが、シニアエンジニアとしての実務的なベストプラクティスです。
—
おわりに
パケットが目に見えない電波の海を駆け抜け、ルーターのMAC層で美しくスライスされ、必要な分だけ正確にRUとして割り当てられていく。その一連のミクロな挙動を想像できるようになると、日頃何気なく使っているスマートホームやWeb APIの挙動が、より立体的に、そしてエキサイティングに見えてこないでしょうか。
「ただ速いだけのWi-Fi」から、「混雑に強く、遅延が揺るぎないWi-Fi」へ。
OFDMAとRU割当の仕組みを正しく理解し、適切なインフラ設定とデバッグを行うことで、私たちの開発・運用するシステムはより一層堅牢なものになります。
次回のネットワーク構築の際には、ぜひこの「周波数と時間のメッシュ細分化」に思いを馳せてみてください。現場からは以上です。
コメント