【実務・中級編】 Wi-Fiにおける電波伝搬特性：周波数帯ごとの減衰と回折特性（2.4GHz、5GHz、6GHz） – 家庭用ネットワーク・IoT・モバイル通信実践ガイド

こんにちは。日々、数々のオフィスネットワークやスマートホームの現場に潜り込み、壁の向こうで消えていくパケットの亡霊たちと格闘しているシニアネットワークエンジニアです。

皆さんは、自宅やオフィスのデスクで「あれ、なんだか最近やけにWeb会議がカクつくぞ」「APIのレスポンスが妙に遅延するな」と感じたとき、真っ先に何を疑うでしょうか？ 光回線の速度テスト？ それともルーターの再起動？

もちろんそれらも大切ですが、ちょっと待ってください。見えない電波という物理媒体は、私たちが想像している以上に気まぐれで、そして厳格な物理法則に支配されています。どれだけ契約上の回線速度が10Gbpsであっても、端末とルーターの間にある「空間」の物理特性を無視しては、高速なパケットを届けることはできません。

今回は、Wi-Fiの根幹をなす「周波数帯ごとの電波伝搬特性（2.4GHz、5GHz、6GHz）」に焦点を当て、障害物への回り込みや減衰のメカニズム、そしてインフラ設計における実務的なセル設計指針を、現場の泥臭い知見を交えて解説していきます。教科書をただなぞるような退屈な話はしません。さあ、電波の物理世界へダイブしましょう。

—

1. 電波の物理学：なぜ周波数が高くなると「障害物に弱く」なるのか？

Wi-Fiルーターのスペック表を見ると、2.4GHz、5GHz、そして近年の規格である6GHzという数字が並んでいます。この周波数の違いは、単に「チャンネルの番号が変わる」だけの話ではありません。電波という「電磁波」が持つ、根本的な物理特性の差です。

ここで、基本に立ち返って波の性質を思い出してください。電波は波です。波には「波長（wavelength）」という概念があり、周波数が高くなればなるほど、波長は短くなります。

  • 2.4GHz帯: 波長は約12.5cm
  • 5GHz帯: 波長は約6.0cm
  • 6GHz帯: 波長は約5.0cm

この「波長の長さ」が、障害物に直面したときの運命を決定づけます。

回折（Diffraction）と減衰（Attenuation）のジレンマ

物理学において、障害物の大きさに対して波長が同等かそれ以上である場合、波は障害物の背後に回り込む性質（回折）を発揮します。
2.4GHz帯の波長（約12.5cm）は、人間の身体や木製の柱、あるいは一般的な間仕切り壁の構造体に対して、比較的「回り込みやすい」サイズです。そのため、隣の部屋や廊下の角を曲がった先であっても、何とかリンクを維持してくれます。

一方で、5GHz帯（約6cm）や6GHz帯（約5cm）はどうでしょう。波長が短いため、障害物にぶつかったときに回り込むことができず、その場で反射するか、あるいは素材にエネルギーを吸収されて熱に変わってしまいます（これが減衰です）。特にコンクリートの壁や、ペアガラス、断熱材が入った現代の住宅の壁は、高周波帯の電波にとって文字通り「鉄壁の要塞」となります。

—

2. 周波数帯ごとの特性比較：現場エンジニアが直面する現実

それぞれの周波数帯が持つメリット・デメリットを、実務の現場感覚ベースで整理してみましょう。

| 周波数帯 | 波長 | 回折性（回り込み） | 減衰・直進性 | 干渉・混雑度 | 主なユースケース・実務での評価 |
| :— | :— | :— | :— | :— | :— |
| 2.4GHz帯 | 約12.5cm | 高（障害物に強い） | 低い（遠くまで届く） | 極めて高（電子レンジ、Bluetooth、近隣のAPと競合） | スマート家電（IoT）、遠隔センサー、初期セットアップ用。速度は出ない。 |
| 5GHz帯 | 約6.0cm | 中（壁1枚が限界） | 中程度 | 中（DFSバンドのレーダー回避問題あり） | PCでのWeb会議、大容量ファイルの送受信。現在のメインストリーム。 |
| 6GHz帯 | 約5.0cm | 低（見通し内通信が基本） | 高（障害物に弱い） | 極めて低（まだ空いている高速道路） | Wi-Fi 6E/7世代の超高速通信、VR/AR、低遅延が命のAPI通信。 |

ここで特筆すべきは、2.4GHz帯の「干渉の地獄」です。使えるチャンネルが実質的に3つ（1, 6, 11ch）しかなく、おまけに電子レンジやBluetoothと同じ帯域を使っているため、集合住宅などでは「繋がるけれどパケットロスが多発する（＝APIのタイムアウトが頻発する）」という最悪の環境になりがちです。

—

3. インフラ運用者必見：電波特性を考慮したセル設計（AP配置）の指針

では、これらの特性を踏まえて、私たちはどのようにWi-Fi環境を設計・構築すべきなのでしょうか？ 「とりあえず最強のルーターを部屋の中央に1台置けばいいや」という考え方は、今すぐ捨ててください。

実務におけるWi-Fiアクセスポイント（AP）の設計（セル設計）では、以下の鉄則を守る必要があります。

① 6GHz / 5GHzは「見通し内（LoS: Line of Sight）」で設計する

6GHz帯（Wi-Fi 6E/7）や5GHz帯をメインで使うエリア（オフィスデスクやリビング）では、APとクライアント端末の間に遮蔽物がない、あるいは最小限になるようにレイアウトします。

  • 悪い例: APを廊下の物置や、テレビ台の裏の低い位置に設置する。
  • 良い例: 天井面、または遮蔽物の少ない高い位置にAPを設置し、端末との間に物理的な障害物を極力排する。

② バンドステアリングの罠に気をつける

最近のルーターには、2.4GHzと5GHz/6GHzを同じSSIDで統合し、自動で切り替える「バンドステアリング機能」が標準搭載されています。一見便利ですが、賢くないアルゴリズムの製品だと、電波の減衰が大きいにもかかわらず「見かけ上の電波強度（RSSI）」だけで5GHzにしがみつき続け、結果としてリンク速度が低下してパケットロスを引き起こす原因になります。
クリティカルなIoTデバイスや、安定した通信が求められる開発用PCでは、あえてSSIDを分離（2.4GHz専用、5GHz/6GHz専用）して手動で固定する方が、現場のトラブルシューティングでは圧倒的に安定します。

—

4. 現場でのトラブルシューティング：電波環境を数値で捉える

「なんだか通信が遅い・不安定だ」と感じたとき、感覚で話を進めるのはエンジニアの恥です。しっかりとメトリクスを測定し、定量的なデータに基づいてボトルネックを特定しましょう。

例えば、Linux環境やmacOSのターミナルから、現在のWi-Fiリンク状態をリアルタイムで確認するには、以下のようなコマンド（CLI）が役立ちます。

# macOSの場合：現在のWi-Fiインターフェースの詳細な電波状態（RSSI, ノイズ, リンク速度）を監視する
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -s
# または、より詳細な接続情報をリアルタイムで確認
wdutil info
# Linux (Ubuntu等) の場合：ネットワークインターフェースの無線リンク品質を確認する
iwconfig wlan0
# または、より詳細なスキャン結果とリンク情報を取得
nmcli dev wifi

ここで確認すべき主要なパラメーターは以下の通りです。

  • RSSI (Received Signal Strength Indicator): 受信信号強度。一般的に -60 dBm 付近であれば非常に良好ですが、-75 dBm を下回るとパケットロスが顕著になり、APIコールのリトライ（再送制御）が頻発します。
  • Noise: 周囲の電波ノイズフロア。
  • Tx Rate / Rx Rate: 現在ネゴシエーションしている送受信の物理速度。

トラブルシューティング：Pythonによる簡易的な遅延・パケットロス計測スクリプト

Wi-Fiの電波減衰や干渉によって、APIの疎通にどのような影響が出ているかを簡易的にモニタリングしたい場合、以下のよなPythonスクリプトを使ってレイテンシーの揺らぎ（ジッター）を観測すると、問題の切り分けがスムーズに行えます。

import time
import urllib.request
import urllib.error
import statistics

# ターゲットのエンドポイント（社内APIサーバーやゲートウェイ）
TARGET_URL = "http://192.168.1.1/health"
NUM_REQUESTS = 10
INTERVAL_SEC = 1.0

latencies = []
failures = 0

print(f"=== Wi-Fi環境影響テスト: {TARGET_URL} への疎通確認を開始 ===")

for i in range(NUM_REQUESTS):
    start_time = time.time()
    try:
        # Fetch APIのPython版のようなイメージでタイムアウト付きリクエスト
        req = urllib.request.Request(TARGET_URL, headers={'User-Agent': 'NetworkDebugger/1.0'})
        with urllib.request.urlopen(req, timeout=2.0) as response:
            status_code = response.getcode()
            elapsed = (time.time() - start_time) * 1000 # ミリ秒に変換
            if status_code == 200:
                latencies.append(elapsed)
                print(f"[{i+1}/{NUM_REQUESTS}] ステータス: {status_code} | 応答時間: {elapsed:.2f} ms")
            else:
                failures += 1
                print(f"[{i+1}/{NUM_REQUESTS}] 警告: 予期せぬステータスコード {status_code}")
    except urllib.error.URLError as e:
        failures += 1
        # 電波の減衰やパケットロスによるタイムアウトをここでキャッチする
        print(f"[{i+1}/{NUM_REQUESTS}] エラー: 接続失敗 ({e.reason}) - 電波干渉や遮蔽物によるロスの可能性あり")
    
    time.sleep(INTERVAL_SEC)

print("\n=== テスト結果サマリー ===")
if latencies:
    print(f"成功リクエスト数: {len(latencies)} / {NUM_REQUESTS}")
    print(f"平均応答時間: {statistics.mean(latencies):.2f} ms")
    print(f"最大応答時間 (ジッター大): {max(latencies):.2f} ms")
    print(f"最小応答時間: {min(latencies):.2f} ms")
print(f"失敗・タイムアウト数: {failures}")

このスクリプトを実行した際、平均応答時間は数ミリ秒であるにもかかわらず、特定のタイミングで数秒の遅延が発生したり、突然の URLError が発生する場合は、APとの間に一時的な障害物が入ったか、あるいは2.4GHz帯の強力な干渉波（電子レンジ等）によってパケットが破棄されている可能性が非常に高いと推測できます。

—

5. おわりに：物理層を制する者がネットワークを制する

どれほど上位レイヤーのプロトコル（HTTP/3やgRPCなど）が洗練されていろうとも、そのデータが流れる下層の物理層（Wi-Fiの電波伝搬特性）がデタラメであれば、システム全体としてのパフォーマンスは絶対に向上しません。

  • 2.4GHzは「遠くまで届くが、細い路地裏で常に渋滞している裏道」
  • 5GHz / 6GHzは「障害物に弱いが、一気に大量のデータを運べる片側10車線の高速道路」

それぞれの特徴を正しく理解し、デバイスの特性や室内のレイアウトに合わせて適切な周波数帯を選定・設計すること。それこそが、真に安定したインフラストラクチャを構築するための第一歩です。

現場のパケットたちは、今日もあなたの設計通りの道を走っています。彼らが快適に目的地（APIサーバー）に辿り着けるよう、ぜひ今回の知見を日々のネットワーク設計・運用に役立ててみてください。

スポンサーリンク

コメント

タイトルとURLをコピーしました