こんにちは。現場で数々の電波迷子やスループット低下のトラブルを救ってきたシニアネットワークエンジニアの私です。
現代のインフラ運用において、Web APIのレスポンスタイムが遅い、コンテナのビルドが途中でタイムアウトするという相談を受け、いざ現場に駆けつけてみたら、原因はAPIサーバーでもクラウドでもなく、「ルーターから3メートル先のクライアント端末が、なぜか激重な2.4GHz帯の死にかけの電波を掴んでいた」なんて笑えない話をよく耳にします。どれほどバックボーンやアプリケーション層を最適化しても、その最後の1メートルを担う無線空間（Wi-Fi）が泥沼であれば、すべては水泡に帰します。
今回は、Wi-Fi 6/6E/7といった最新規格のポテンシャルを現場で100%引き出すために避けて通れない「Wi-Fiサイトサーベイ（電波調査）」の極意を、予測サーベイ（シミュレーション）と実測サーベイ（バリデーション）の両面から徹底的に解説します。
—
1. なぜサイトサーベイが必要なのか？ Wi-Fiの「見えない壁」に挑む
Wi-Fiは空気という目に見えない媒体を共有する共有媒体（Shared Medium）です。見えないからこそ、なんとなくアクセスポイント（AP）を天井にポツリと配置しただけでは、コンクリートの壁、金属製の書架、断熱材、さらにはオフィスの人の動き（人体減衰）によって電波は無残に減衰します。
近年のWi-Fi 6EやWi-Fi 7では、新しく開放された6GHz帯の活用が鍵となりますが、この帯域は周波数が高いため直進性が非常に強く、障害物に対する透過損失が強烈です。つまり、「設計なしの無線環境は、確率論のギャンブルと同じ」なのです。
サイトサーベイには大きく分けて2つのアプローチがあります。
1. 予測サーベイ（Predictive Survey）: 図面を元にシミュレーター上でAPを配置し、電波の伝搬を予測する手法。
2. 実測サーベイ（Active/Passive Site Survey）: 実際に現地で物理的なAPを仮設置し、専用の測定ツールで電波を実測してヒートマップを描く手法。
それぞれの実務における正しい進め方を、現場のノウハウを交えて見ていきましょう。
—
2. 予測サーベイ：設計図面から電波の挙動をハックする
プロジェクトの初期段階、まだ現地に入れないオフィスの内装工事中などに活躍するのが予測サーベイです。ここでは、建築図面（CADやPDF）を取り込み、壁の材質（石膏ボード、コンクリート、ガラスなど）ごとの減衰値（dB）を正確に定義することが命運を分けます。
予測サーベイで重視すべき設計パラメータ
- RSSI（Received Signal Strength Indicator）: 受信信号強度。一般的にセルラーや音声通話を安定させるなら
-65 dBm以上、一般的なデータ通信であれば-67 dBm以上を設計ターゲットにします。 - SNR（Signal-to-Noise Ratio）: 信号と雑音の比率。電波が強くてもノイズフロア（バックグラウンドの電波雑音）が高ければ通信は崩壊します。SNRは最低でも
25 dB以上、できれば35 dB以上を狙いたいところです。 - カバレッジのオーバーラップ: ローミング（AP間の移動）を円滑に行うため、隣接するAPのセル同士を
15%〜20%ほど重複させ、かつ同一チャネル干渉（ACI）を防ぎます。
シミュレーションツール上でAPのチャネル幅（20MHz / 40MHz / 80MHz / 160MHz）や送信出力（dBm）を調整し、机上の空論ではなく「理にかなった初期配置」を導き出します。
—
3. 実測サーベイ：現実の電波環境を暴くパッシブとアクティブ
予測サーベイで机上の設計図ができたら、次は現実の物理空間へのアプローチ、すなわち「実測サーベイ」です。ここでの作業は、ネットワークエンジニアの腕の見せ所です。
実測サーベイには、主に2つのモードが存在します。
パッシブサーベイ（受動的測定）
測定端末がデータ通信を行わず、周辺の全APが発信するビーコンフレーム（Beacon Frame）を受信し続けることで、以下の要素をマッピングします。
- 電波強度（RSSI / AP Coverage）
- ノイズフロア（Noise Floor）
- チャネルの混雑度・干渉状況（Co-Channel Interference）
アクティブサーベイ（能動的測定）
測定端末が特定のAPと実際にアソシエーション（接続）を確立し、テスト用パケットを往復させることで、リンクの品質を直接測定します。
- ラウンドトリップタイム（RTT / レイテンシー）
- パケットロス率（Packet Loss）
- 実効スループット（Throughput）
ここで、現場で取得した実測データをプログラムやスクリプトで自動処理・監視したいケースを考えてみましょう。例えば、簡易的な死活監視や電波強度のログ収集を行うPythonスクリプトの例を以下に示します。
import subprocess
import re
import time
def get_wifi_metrics():
"""
macOSのairportユーティリティまたはLinuxのiwconfig等を利用して
現在のWi-Fi接続状態（RSSI、ノイズ、リンク速度）をパースする関数
"""
try:
# macOSの例: /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I
cmd = ["/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport", "-I"]
result = subprocess.run(cmd, capture_output=True, text=True, check=True)
output = result.stdout
# 正規表現によるパラメータの抽出
ssid_match = re.search(r"SSID: (.+)", output)
rssi_match = re.search(r"agrCtlRSSI:\s*(-?\d+)", output)
noise_match = re.search(r"agrCtlNoise:\s*(-?\d+)", output)
rate_match = re.search(r"lastTxRate:\s*(\d+)", output)
metrics = {
"ssid": ssid_match.group(1).strip() if ssid_match else "N/A",
"rssi": int(rssi_match.group(1)) if rssi_match else 0,
"noise": int(noise_match.group(1)) if noise_match else 0,
"tx_rate": int(rate_match.group(1)) if rate_match else 0,
}
# SNRの簡易計算 (RSSI - Noise)
metrics["snr"] = metrics["rssi"] - metrics["noise"]
return metrics
except subprocess.CalledProcessError as e:
print(f"[-] Wi-Fi情報の取得に失敗しました: {e}")
return None
if __name__ == "__main__":
print("[*] Wi-Fiサーベイ・モニタリングスクリプトを開始します（Ctrl+Cで終了）")
try:
while True:
data = get_wifi_metrics()
if data:
print(f"SSID: {data['ssid']} | RSSI: {data['rssi']} dBm | Noise: {data['noise']} dBm | SNR: {data['snr']} dB | TxRate: {data['tx_rate']} Mbps")
time.sleep(5)
except KeyboardInterrupt:
print("\n[*] モニタリングを終了します。")このように、現場では単に専用のヒートマップツール（EkahauやAirCheckなど）を歩き回らせるだけでなく、スクリプトを組み合わせることで特定の定点観測ポイントにおけるスループットの揺らぎを可視化できます。
—
4. 予測 vs 実測：乖離を埋めるトラブルシューティングの作法
予測サーベイをどれほど綿密に行っても、実測サーベイのヒートマップを生成すると「あれ、ここだけ電波が全く届いていない（デッドゾーン）」という乖離が必ず発生します。
この乖離の原因の多くは、「図面情報と現実の建材のギャップ」です。例えば、設計図上では「ただの軽量鉄骨の壁」とされていたものが、実際には内部に鉛入りの防音ボードが入っていたり、フロア中央に巨大な観葉植物（水分は2.4GHz/5GHz帯の電波を強力に吸収します）が置かれていたりします。
現場で直面する典型的な落とし穴と対策
1. フロアの反射とマルチパス問題
- ガラス張りの会議室やコンクリート打ちっぱなしの床は電波を乱反射させます。結果として、予測値よりも干渉波が増え、SNRが悪化します。
- *対策*: APの出力（Transmission Power）をあえて少し下げ、セルサイズを小さく設計し直すことで、反射波の影響を最小限に抑えます。
2. 隠れ端末問題（Hidden Node Problem）
- 障害物を挟んだ向こう側の端末同士がお互いの電波を検知できず、同時にAPへ送信してフレーム衝突が多発する現象です。
- *対策*: RTS/CTSハンドシェイクの閾値を適切に調整するか、APの配置を見直して相互に視認できる位置に再設計します。
—
5. まとめ：美しいヒートマップの裏にある泥臭い執念
Wi-Fiの設計とサイトサーベイは、数学的な電波伝搬モデルの計算と、現場を自分の足で歩き回り、壁の材質やオフィスのレイアウトという「現実の泥臭さ」を突き合わせる作業の融合です。
「とりあえず電波が入っていればいいや」という妥協は、やがて「なぜか特定の会議室だけWeb会議が切れる」というエンドユーザーからの冷たいクレームに直結します。予測サーベイで精緻な仮説を立て、実測サーベイという検証フェーズでその仮説を容赦なく叩き直す。このサイクルを回すことこそが、真に安定したエンタープライズ・ネットワークを構築するための唯一の王道です。
あなたの管理するネットワークも、次のデプロイの前にぜひ一度、足を使ったサーベイを実施してみてください。見えなかったパケットの息遣いが、きっと手に取るように分かるはずです。
コメント