【実務・中級編】無線物理層の変調方式と多値変調技術（QPSK、16QAM、64QAM、256QAM、1024QAM）の比較 – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

なぜ「アンテナピクト」は満タンなのに遅いのか？――変調方式の深淵とエンジニアが知るべき物理層のリアル

「アンテナは立っているのに、なぜかAPIのレスポンスが極端に遅い」。現場でインフラを触るエンジニアなら、一度は経験したことがあるでしょう。その原因の多くは、単なる基地局の混雑だけでなく、実は物理層の「変調方式（Modulation Scheme）」が、電波環境の悪化によって極端に低速なものへフォールバックしていることにあります。

今回は、我々が普段意識しない「QAMの深淵」について、Webエンジニアやインフラ担当者の視点から紐解いていきます。

—

多値変調（QAM）の進化：1bitをどこまで詰め込めるか

無線通信の物理層における変調とは、ざっくり言えば「波の振幅と位相を組み合わせて、一度に何ビットの情報を乗せるか」というゲームです。

QPSK: 2bit/シンボル（堅牢だが低速）
16QAM: 4bit/シンボル
64QAM: 6bit/シンボル
256QAM: 8bit/シンボル
1024QAM: 10bit/シンボル（5Gにおける高効率化の鍵）

変調多値数が上がれば上がるほど、一度に運べるデータ量は増えます。しかし、そこには残酷なトレードオフが存在します。星座図（コンステレーション）上の点が密集するため、少しのノイズ（SINRの低下）でビット誤りが発生し、パケット再送の嵐に見舞われるのです。

SINR（信号対干渉雑音比）との戦い

モバイル通信では、端末と基地局間の通信品質に応じて、この変調方式がリアルタイムで決定されます。これを「適応変調（AMC: Adaptive Modulation and Coding）」と呼びます。

例えば、オフィスビル内で電波が乱反射し、SINRが低い状態で無理に 1024QAM を叩き込むと、エラー訂正が追いつかず、実効スループットは QPSK に戻した時よりも遥かに低下します。これが「アンテナは立っているのに遅い」の正体です。

—

現場で役立つ：スループット劣化のデバッグTips

Web APIのレスポンスタイムが不安定なとき、ネットワーク層よりも下の「物理層の揺らぎ」を疑う必要があります。Pythonを使って、モバイル回線越しにパケットの往復時間を監視し、統計的な揺らぎを確認する簡単なスクリプトを紹介します。

import time
import subprocess
import statistics

# 接続先のAPIエンドポイント（パブリックなヘルスチェック等）
TARGET_URL = "https://api.example.com/health"

def monitor_latency(count=20):
    latencies = []
    for _ in range(count):
        # curlでレスポンス時間のみを抽出（ミリ秒）
        cmd = ["curl", "-o", "/dev/null", "-s", "-w", "%{time_total}", TARGET_URL]
        start = time.time()
        result = subprocess.run(cmd, capture_output=True, text=True)
        end = time.time()
        
        if result.returncode == 0:
            latencies.append(float(result.stdout) * 1000)
        time.sleep(0.5) # 0.5秒間隔で計測
        
    return latencies

# 実行して変動係数を計算
data = monitor_latency()
if data:
    print(f"平均レイテンシ: {statistics.mean(data):.2f} ms")
    print(f"標準偏差: {statistics.stdev(data):.2f} ms")
    # 標準偏差が大きい場合、電波状況による物理層再送の可能性が高い

このコードで標準偏差が極端に大きい場合、TCPレベルでの再送（TCP Retransmission）が発生している可能性が高いです。Wireshark でパケットをキャプチャし、tcp.analysis.retransmission フラグが頻発していないか確認してください。

—

API設計者が知っておくべき「モバイル最適化」の鉄則

モバイル環境が 256QAM や 1024QAM を維持できるのは、あくまで理想的な電波環境下だけです。我々エンジニアは、常に「低速な変調方式にフォールバックしても死なない設計」を心がけるべきです。

1. ペイロードサイズの削減: 1回のHTTPリクエストで巨大なJSONを返すと、パケットロス発生時の再送コストが跳ね上がります。Gzip や Brotli 圧縮は必須です。
2. TCPコネクションの維持: Keep-Alive を活用し、物理層の再送の影響を最小限にするためのコネクション確立コストを減らします。
3. 断続的な切断を許容する: 5G のエリア境界線では、ミリ波（28GHz帯）から Sub6 や LTE へハンドオーバーが発生し、瞬断します。クライアント側のロジックでリトライ間隔を指数バックオフにするのは基本中の基本です。

サーバー側の推奨設定（Nginx例）

モバイルユーザーが物理層の不調に直面しても、HTTP層で極力粘れるようにするための設定例です。

# クライアントとのコネクションを維持し、再接続のオーバーヘッドを減らす
keepalive_timeout 65;

# 物理層の揺らぎによるパケットロスに備え、バッファを適切に設定
client_body_buffer_size 128k;
client_max_body_size 10m;

# 圧縮を有効化し、変調方式が低い時でも転送効率を稼ぐ
gzip on;
gzip_types application/json text/plain;

—

最後に：ネットワークを「信じない」ことが強さになる

技術の進化により 1024QAM が実現し、理論上の通信速度は劇的に向上しました。しかし、どれだけ規格が進化しても、電波は生き物です。壁を通り抜け、反射し、干渉し合います。

私たちエンジニアの役割は、物理層が完璧であることを祈ることではなく、「物理層がいつ崩れても、アプリケーションが耐えられるような設計」を実装することです。

次に「遅い」という報告が上がった時、まずはその場所が 256QAM で維持できる環境なのか、それとも QPSK まで落ちるような過酷な環境なのかを想像してみてください。その視点こそが、シニアエンジニアへの第一歩です。