こんにちは。ネットワークの現場を渡り歩くシニアエンジニアの私です。
Web APIの設計やクラウドインフラの構築でどれほど美しいアーキテクチャを描いても、その土台である「物理層（Layer 1）」がノイズまみれであれば、アプリケーションは簡単に膝を屈します。特に、リモートワークやIoTデバイスの増加によって過密化の一途をたどる家庭用Wi-Fi環境は、インフラエンジニアにとっても頭の痛いブラックボックスです。
「APIのレスポンスがたまに数秒遅延する」「スマートロックの応答が不自然に悪くなる」。こうしたトラブルシューティングの現場で、アプリケーションのログばかりを追っていませんか？ もしかしたらその犯人は、隣家のWi-Fiがまき散らす電波干渉や、キッチンの電子レンジが生み出す凄まじいスペクトラムの荒波かもしれません。
今回は、Wi-Fi環境における物理層の干渉調査に焦点を当て、電波状況の可視化から、非Wi-Fi干渉波の特定、同チャネル干渉（CCI）や隣接チャネル干渉（ACI）の識別と対策まで、現場で即座に使える実践的なノウハウを解説します。
—
1. 物理層の可視化：スペクトラムアナライザが映し出す現実
Wi-Fiルーターの管理画面に表示される「チャンネル自動選択」を信じていませんか？ 多くの家庭用ルーターは、起動時に「一番空いているように見えるチャンネル」を選びますが、それはあくまで「その瞬間のWi-Fiパケットの少なさ」を見ているに過ぎません。
Wi-Fi以外の機器――例えばBluetooth、電子レンジ、ワイヤレススピーカー、さらには防犯カメラなどが発する電波は、通常のWi-Fiアナライザアプリでは「ただのフロアノイズ（背景雑音）」として処理され、正確な波形は見えません。ここで必要になるのが、ハードウェアベースのスペクトラムアナライザ（通称：スペアナ）です。
スペアナで見るべき3つの指標
現場でスペアナ（Wi-SpyやSDRドングル、専用のWi-Fiアナライザハードウェア）を起動した際、必ず確認すべきパラメーターは以下の通りです。
- RSSI (Received Signal Strength Indicator): 受信信号強度。パケットが届いているかどうかの指標です。
- NF (Noise Floor): ノイズフロア。干渉が何もない状態の背景雑音レベル（通常、家庭環境では -95dBm から -100dBm 程度が理想）。
- デューティサイクル (Duty Cycle): ある周波数帯において、電波が占有されている時間の割合。これが高いほど、その帯域は混雑し、パケットの衝突（コリジョン）リスクが跳ね上がります。
—
2. 非Wi-Fi干渉波の特定：身近に潜む「電波の暴れ馬」
2.4GHz帯は、IEEE 802.11b/g/n/axだけでなく、産業用・科学用・医療用（ISMバンド）として世界中で自由解放されている「コモンズの悲劇」の象徴のような帯域です。ここに潜む代表的な非Wi-Fi干渉波と、その波形の特徴を把握しておきましょう。
電子レンジ（マグネトロンの脅威）
電子レンジが稼働すると、2.4GHz帯のチャンネル3〜9あたり（特に2.45GHz付近）を中心に、連続的な高出力の山なりノイズが突如として出現します。
- 挙動: スペアナ上では、特定のチャンネルが綺麗に埋まるのではなく、帯域全体を持ち上げるような巨大なパワーバーストとして観測されます。
- 影響: この時間帯、TCPコネクションはパケットロスにより再送（Retransmission）の嵐となり、Web APIのタイムアウトが頻発します。
Bluetooth（周波数ホッピングの猛威）
Bluetoothは、1MHz幅のチャンネルを秒間1600回も高速でホッピング（移動）しながら通信する「FHSS（周波数ホッピングスペクトラム拡散）」を採用しています。
- 挙動: スペアナ上では、細いピークがパタパタと移動しているように見えます。
- 影響: 2.4GHz帯でWi-FiとBluetoothを同時に使用すると、お互いの電波が同じ空間を奪い合い、スループットが劇的に低下します。可能であれば、IoT機器やPC周辺機器は5GHz帯や6GHz帯へ積極的にオフロード（移行）させるべきです。
—
3. CCI（同チャネル干渉）と ACI（隣接チャネル干渉）の識別
Wi-Fi同士の干渉には、大きく分けて2つの種類があります。これらを混同すると、チャンネル設計を誤り、事態をさらに悪化させる原因になります。
同チャネル干渉 (CCI: Co-Channel Interference)
同じチャンネルを複数のアクセスポイント（AP）やクライアントが共有している状態です。
- メカニズム: CSMA/CA（キャリア感知多重アクセス/衝突回避）の仕組みにより、周囲の電波（BSSID）のエネルギー検出（ED）が一定の閾値を超えると、他のデバイスは送信を待機（バックオフ）します。つまり、「電波をゆずり合っている状態」です。
- 評価: 致命的なパケット破壊にはなりませんが、エアタイム（電波の占有時間）が分割されるため、全体のスループットが低下します。Wi-Fi 6の「BSSカラーリング」機能は、まさにこのCCIを効率よくハンドリングするための技術です。
隣接チャネル干渉 (ACI: Adjacent Channel Interference)
2.4GHz帯でよく見られる最悪の干渉です。2.4GHz帯のチャンネルは20MHz幅ですが、チャンネルの中心間隔はわずか5MHzしか離れていません（例: 1chと2ch、あるいは1chと6chの一部オーバーラップ）。
- メカニズム: 自分の使いたいチャンネルのすぐ隣で、別の強力な電波が発せられていると、受信側のフィルターがこれを完全に分離できず、「物理的な波形の歪み・パケット破損」を引き起こします。
- 評価: ACIが発生すると、CSMA/CAのゆずり合い機能が正常に機能せず、CRCエラー（フレームチェックシーケンスエラー）が多発します。2.4GHz帯で運用する場合、チャンネルは絶対に「1ch, 6ch, 11ch」の非オーバーラップチャンネル以外を選んではならないのはこのためです。
—
4. 現場で使える！ Pythonを用いた簡易パケット・電波メトリクス監視スクリプト
インフラエンジニアたるもの、感覚ではなくメトリクスで語るべきです。Pythonと標準ライブラリ、サードパーティのネットワークライブラリを組み合わせることで、定期的にWi-Fiのリンク品質やパケットロスをロギングし、干渉の兆候を検知するスクリプトを簡単に組むことができます。
以下のコードは、Linux環境（iw や subprocess を利用）において、接続中のWi-Fiリンクの電波強度（RSSI）やリンク速度を定期的に取得し、構造化ログとして出力する実用的なスニペットです。
#!/usr/bin/env python3
import subprocess
import time
import json
from datetime import datetime
# 監視対象のワイヤレスインターフェース名（環境に合わせて変更してください）
INTERFACE = "wlan0"
def get_wifi_metrics(interface):
"""
iwコマンドを使用して、現在のWi-Fiリンクの物理層メトリクスを取得する
"""
metrics = {
"timestamp": datetime.utcnow().isoformat() + "Z",
"interface": interface,
"rssi_dbm": None,
"link_speed_mbps": None,
"status": "disconnected"
}
try:
# 'iw dev <interface> link' の実行
result = subprocess.run(
["iw", "dev", interface, "link"],
capture_output=True,
text=True,
check=True
)
output = result.stdout
if "Not connected" in output:
return metrics
metrics["status"] = "connected"
# 出力結果から必要なパラメーター（信号強度やビットレート）をパースする
for line in output.splitlines():
line = line.strip()
if line.startswith("signal:"):
# 例: "signal: -65 dBm" から数値部分を抽出
parts = line.split()
if len(parts) >= 2:
metrics["rssi_dbm"] = int(parts[1])
elif "tx bitrate:" in line:
# 例: "tx bitrate: 573.5 MBit/s 80MHz HE-MCS 11..."
parts = line.split()
for i, p in enumerate(parts):
if p == "MBit/s":
metrics["link_speed_mbps"] = float(parts[i-1])
except subprocess.CalledProcessError as e:
metrics["status"] = "error"
metrics["error_message"] = str(e)
except Exception as e:
metrics["status"] = "exception"
metrics["error_message"] = str(e)
return metrics
def main():
print(f"[*] Starting Wi-Fi physical layer monitor on interface: {INTERFACE}")
print(f"[*] Press Ctrl+C to stop.\n")
try:
while True:
data = get_wifi_metrics(INTERFACE)
# 構造化ログ（JSON形式）として標準出力に出力（DatadogやFluentdなどで収集可能）
print(json.dumps(data))
# 5秒おめにサンプリング
time.sleep(5)
except KeyboardInterrupt:
print("\n[*] Monitoring stopped by user.")
if __name__ == "__main__":
main()このスクリプトをバックグラウンドで走らせつつ、例えばWeb APIの負荷テストやcurlによる疎通テスト（curl -w "%{time_total}\n" -o /dev/null -s https://api.example.com/health）を同時に実行してみてください。
RSSIが急激に悪化したり、リンク速度がフォールバック（低速化）した瞬間にAPIのレイテンシーが跳ね上がる相関関係が、きれいなデータとして見えてくるはずです。
—
5. 現場のシニアが教える、物理層トラブルへの処方箋
最後に、こうした電波干渉や物理層のトラブルに直面した際、現場のエンジニアとしてどのようなアクションを取るべきか、実践的な対策をまとめます。
1. 2.4GHz帯を「捨てる」勇気を持つ
IoTデバイスの多くはいまだに2.4GHz帯しかサポートしていませんが、電子レンジやBluetoothが飛び交うこの帯域で安定した高速通信を期待するのはナンセンスです。重要度の高いデバイスや、低レイテンシーが求められる機器は、可能な限り5GHz帯（Wi-Fi 5/6）や6GHz帯（Wi-Fi 6E/7）へ収容をシフトさせましょう。
2. チャンネル幅（Bandwidth）をあえて狭める
ルーターの設定で「40MHz幅」や「80MHz幅」に設定していませんか？ 帯域幅を広げれば理論上の速度は上がりますが、そのぶん周囲の干渉波を拾う確率（ノイズフロアの上昇）も高くなります。特に集合住宅など電波が密集した環境では、2.4GHz帯は20MHz幅固定、5GHz帯でも周囲の混雑状況に応じて適正な幅に制限することが、パケットロスを激減させる特効薬となります。
3. APの物理的な配置を見直す
電波は障害物（特にコンクリート、金属、水）に極めて弱いです。「ルーターをテレビの裏や金属ラックの奥に隠している」というケースを現場で本当によく見かけます。APは可能な限り遮蔽物のない高い位置に設置し、クライアントとの見通し（Line of Sight）を確保することが、最良のチューニングとなります。
アプリケーションのレイテンシーに悩んだとき、コードを書き直す前に、一度足元（物理層）の電波環境に目を向けてみてください。ネットワークの基本原則を知ることは、強固なシステムを作り上げるための確実な武器になります。
コメント