こんにちは、シニアネットワークエンジニアの私です。
現場でインフラの設計やWebシステムの運用に携わっていると、「なぜか特定のIoTデバイスが頻繁に切断される」「オフィスのフロアを移動した瞬間に、スマホのAPI通信が数秒間フリーズする」といった、無線特有の泥臭いトラブルに直面することがよくあります。
アプリケーション層のエンジニアからは「APIのタイムアウトです」と報告が上がってくるものの、パケットキャプチャを開いてみると、原因はアプリでもサーバーでもなく、レイヤー2の無線空間――すなわち、クライアントがどのアクセスポイント（AP）にしがみつき、どのタイミングでローミング（ハンドオフ）を行ったかという、Wi-Fiの基礎的な挙動に行き着くことが少なくありません。
今回は、私たちが普段何気なく接続しているWi-Fiの裏側で、パケットと電波がどのようにやり取りされているのか。SSIDとBSSIDの定義から、クライアントが裏で計算しているRSSI（Received Signal Strength Indicator）の閾値、そして実務で役立つローミング制御の仕組みまで、現場の知見を交えて徹底的に解説します。
—
1. SSIDとBSSIDの正体：論理的な「名前」と物理的な「個体」
無線LANの設計やトラブルシューティングを行う際、最初に頭に叩き込んでおくべきなのは、私たちが普段目にする「SSID」と、ハードウェアレベルの「BSSID」の決定的な違いです。
SSID (Service Set Identifier): 論理的なネットワーク識別子
SSIDは、人間が認識するためのネットワークの名前です。最大32オクテットの文字列で構成され、BeaconフレームやProbe Responseフレームを通じて空間にブロードキャストされます。
アプリケーションやOSのネットワーク設定画面で表示される「おうちのWi-Fi」や「オフィス用SSID」の正体がこれです。
BSSID (Basic Service Set Identifier): 物理的なAPのMACアドレス
一方で、BSSIDは各無線APの物理インターフェース（無線チップのMACアドレス、48ビット）そのものです。
IEEE 802.11の規格上、1つの物理的なAPが複数の仮想AP（マルチSSID）をホストしている場合、SSIDごとに異なるBSSIDが割り当てられます。さらに、メッシュWi-Fiや企業向けのマルチAP環境では、「同じSSIDを持ちながら、異なるBSSIDを持つ複数のAP」が空間に存在することになります。
> 【現場のTips】
> ここがインフラエンジニアの腕の見せ所です。クライアントデバイスは、人間のように「あ、あそこのルーターの電波が強そうだな」と目視で判断しているわけではありません。デバイスは、空間飛び交うBeaconフレームに含まれる「SSID（名前）」ではなく、各AP固有の「BSSID（MACアドレス）」単位で電波を受信し、接続先を個別に評価・選択しています。
—
2. クライアントがAPを選ぶ基準：RSSI、プロアクティブローミング、そして閾値
では、スマートフォンやIoTデバイスなどのクライアント（STA: Station）は、どのようにして接続先やローミング先を決定しているのでしょうか。
RSSIとフレームの往来
クライアントは、周囲のAPから定期的に送信されるBeaconフレーム（または自ら能動的に送るProbe Requestに対するProbe Response）を受信し、その際の電波強度をRSSIとして測定します。
一般的なクライアントOS（iOS, Android, Linux, Windowsなど）のファームウェアは、以下のような基準でローミングのトリガーを引きます。
1. カレントAPの劣化: 現在接続しているBSSIDのRSSIが、あらかじめベンダーがハードコードまたは設定で定めた閾値（例: -70 dBm や -75 dBm）を下回る。
2. スキャン動作: カレントAPの品質低下を検知すると、クライアントはバックグラウンドでチャネルスキャン（アクティブスキャン／パッシブスキャン）を実行し、同じSSIDを持つ別のBSSIDを探す。
3. 候補の評価とアソシエーション（Association）: 発見した候補の中から、より強いRSSIを持つBSSIDを選び、Re-association Requestフレームを送信して接続先を切り替える。
ローミング遅延のジレンマ
ここで問題になるのが、ローミングにかかる時間（ローミング遅延）です。単なるレイヤー2の切り替え（Re-association）だけでなく、WPA2/WPA3の4ウェイハンドシェイク（4-Way Handshake）や、企業向け環境での802.1X認証（RADIUS）が挟まると、数十〜数百ミリ秒の通信断が発生します。リアルタイム性の高いWebsocket通信や音声通話アプリを利用している場合、この瞬間にパケットロスやセッション切断が発生し、ユーザー体験が著しく損なわれます。
これを解決するために現代のWi-Fi規格では、IEEE 802.11r（Fast BSS Transition）などの規格が使われ、事前の鍵共有によってローミング時のハンドシェイクを極限まで短縮しています。
—
3. 実務で役立つ：無線環境のモニタリングとPythonによるRSSI収集スクリプト
インフラエンジニアやIoT開発者が現場で「どのAPに、どれくらいの電波強度で繋がっているのか」をプログラムから把握したい場合、OSのネイティブコマンドやAPIを叩くことになります。
以下に、Linux環境（NetworkManagerやiwコマンドが利用可能な環境）を想定し、現在接続しているWi-FiのSSID、BSSID、およびRSSIを定期的に取得してログ出力するPythonスクリプトのサンプルを提示します。実務でのデバッグや、エッジデバイスの電波環境モニタリングにご活用ください。
Pythonスクリプト例 (wifi_monitor.py)
import subprocess
import re
import time
import sys
def get_wifi_status():
"""
Linuxの iwconfig コマンドを実行し、現在の接続先SSID、BSSID、RSSIをパースする。
※実運用環境では権限やOSディストリビューション（nmcli等）に応じた調整が必要です。
"""
try:
# iwconfig の実行結果を取得
result = subprocess.run(
['iwconfig'],
stdout=subprocess.PIPE,
stderr=subprocess.PIPE,
text=True,
check=True
)
output = result.stdout
# 接続先がない場合の簡易チェック
if "Not-Associated" in output:
return None
# 正規表現によるパース処理
# 例: ESSID:"MyHome_WiFi"
essid_match = re.search(r'ESSID:"([^"]+)"', output)
# 例: Access Point: AA:BB:CC:DD:EE:FF
bssid_match = re.search(r'Access Point:\s+([0-9A-F:]+)', output, re.IGNORECASE)
# 例: Signal level=-55 dBm
signal_match = re.search(r'Signal level=(-?\d+)\s*dBm', output, re.IGNORECASE)
ssid = essid_match.group(1) if essid_match else "Unknown"
bssid = bssid_match.group(1) if bssid_match else "Unknown"
rssi = int(signal_match.group(1)) if signal_match else 0
return {
"ssid": ssid,
"bssid": bssid,
"rssi": rssi
}
except subprocess.CalledProcessError as e:
print(f"[Error] iwconfigの実行に失敗しました: {e.stderr}", file=sys.stderr)
return None
except Exception as e:
print(f"[Error] 予期せぬエラーが発生しました: {e}", file=sys.stderr)
return None
def main():
print("=== Wi-Fi 接続モニタリングを開始します (Ctrl+Cで終了) ===")
print("Timestamp\t\tSSID\t\t\tBSSID\t\t\tRSSI")
print("-" * 75)
try:
while True:
status = get_wifi_status()
timestamp = time.strftime("%Y-%m-%d %H:%M:%S", time.localtime())
if status:
print(f"{timestamp}\t{status['ssid']}\t{status['bssid']}\t{status['rssi']} dBm")
# 現場の運用アラートの例：RSSIが -75 dBm を下回ったら警告を出す
if status['rssi'] < -75:
print(f" -> 【警告】電波強度低下を検出しました！ローミング不全またはAP配置の見直しが必要かも知れません。")
else:
print(f"{timestamp}\t[切断状態 - Wi-Fi未接続またはスキャン中]")
time.sleep(5) # 5秒ごとにポーリング
except KeyboardInterrupt:
print("\nモニタリングを終了します。お疲れ様でした！")
if __name__ == "__main__":
main()コードのポイント
iwconfigまたはnmcliの活用: LinuxサーバーやラズベリーパイなどのIoTデバイスで現場検証を行う際、OSレベルで現在のBSSIDとRSSIをリアルタイムに引けるようにしておくことは、デバッグの初手として極めて有効です。- アラート閾値の設定: スクリプト内の
-75 dBmという数値は、一般的なスマートデバイスやVoIP端末が「ローミングを真剣に検討し始める」境界線付近の経験則的な値です。この値を下回り続ける場合、物理的なAPの追加や出力調整（チャネルプランニング）が必要になります。
—
4. インフラ・開発現場で陥りがちなトラブルシューティングの知見
最後に、現場で実際に遭遇したトラブルと、そのアプローチについていくつか共有しておきます。
1. 「スティッキー（執着）クライアント」問題
- 症状: 近くに強力なAPがあるにもかかわらず、遠くのAPのBSSIDにしがみつき続け、通信速度が極端に低下する現象。
- 原因: クライアント側のOSやWi-Fiチップのローミングアルゴリズムが保守的で、電波が微弱になってもなかなか自発的に離れようとしないため。
- 対策: AP側（コントローラー側）で「Min RSSI（最小電波強度）」や「Client Steering（強制切断機能）」を設定し、規定のしきい値（例:
-78 dBm）を下回ったクライアントをAP側から強制的に切断（De-authentication）させ、より近いBSSIDへの再接続を促すのが定石です。
2. メッシュWi-FiのバックホールとBSSIDの錯綜
- 症状: メッシュ親機と子機の間にクライアントが挟まった際、頻繁にBSSIDが切り替わり、TCPセッションがリセットされる。
- 原因: 2.4GHz帯と5GHz帯のバンドステアリングが過剰に働き、クライアントが意図しない周波数やAPを行き来しているケースが多い。
- 対策: 固定配置の据置型デバイス（スマート家電やPCなど）では、可能であればバンドステアリングを無効化し、特定の帯域やBSSIDに固定（あるいはAP側のMACアドレスフィルタリングや優先接続設定）する設計が求められます。
—
まとめ
SSIDという「人間向けの看板」の裏側では、BSSIDという「機械向けの識別子」が複雑に絡み合い、RSSIという物理的な電波の減衰をベースに、クライアントが必死に最適な接続先を選び続けています。
Webアプリケーションのパフォーマンスチューニングを行う際にも、レイヤー7のコードだけでなく、その土台を支えるレイヤー1・2の無線挙動に思いを馳せることで、トラブルシューティングの視野はぐっと広がります。
皆さんの現場でも、もし「原因不明の通信の揺らぎ」に遭遇したら、まずは今回ご紹介したBSSIDとRSSIの挙動をパケットやログから疑ってみてください。ネットワークの神様は、細部に宿るものです。
コメント