インストール不要のWi-Fiサイトサーベイツールを情シスが使う — 電波弱点をヒートマップで特定する

「Wi-Fiが繋がりにくい」という申告が上がってくる。現場を歩いて確認すると確かに電波が弱いエリアがある。ではAPをどこに追加すれば解決するのか——感覚と経験だけで決めるのは心もとないし、Ekahauのような本格的なサイトサーベイツールはライセンス料だけで数十万円かかる。1〜3人で情シスを回している中小企業では、そこまでの予算が下りることはまずない。

本記事では、追加インストール不要でWindows 10/11上で動作するオープンソースのWi-Fiサイトサーベイツール「SiteSurveyTool」を使って、フロアマップ上に電波計測結果をヒートマップ表示するまでの手順を解説する。Ping・スループット・VoIP品質の3モードを備えており、AP配置の検討や電波弱点の特定に実用的に使える。

なぜ専用ツールが買えないのか

Wi-Fiサイトサーベイの専用ツール市場は大きく二極化している。

「フロアマップ上に計測ポイントを設置してヒートマップ化する」という基本機能を無償で使えるツールは選択肢が限られる。SiteSurveyToolはその空白を埋めるために作られた実用ツールだ。

SiteSurveyToolとは

SiteSurveyToolは、Windows PCでZIPを解凍してStart.batをダブルクリックするだけで起動するWi-Fiサイトサーベイツールだ。バックエンドはPowerShell 5.1のSystem.Net.HttpListenerによる自前HTTPサーバー、フロントエンドはVanilla JS + Chart.jsで構成されており、Node.jsもPythonも不要。標準ブラウザ（Edge / Chrome等）がUIとなる。

主な機能は以下のとおりだ。

• PNG/JPGのフロアマップ画像またはグリッドエディタで作成した間取りへのピン設置
• Ping計測（デフォルトゲートウェイ＋外部IP宛RTT・パケットロス）
• スループット計測（HTTPダウンロードによる下り速度）
• VoIP/ビデオ会議品質計測（連続Pingによるジッター算出・簡易E-modelによるMOS値推定）
• 信号強度・Ping・ジッターの3種類のIDWヒートマップ表示
• PNG・CSV・PDF形式でのエクスポート
• Wi-Fi情報のリアルタイム自動取得（SSID・BSSID・信号強度・チャネル・無線規格・リンク速度）

動作要件と入手方法

動作要件

• OS: Windows 10 / 11（macOS・Linuxは非対応。netsh・System.Net.NetworkInformation.Ping等のWindows API依存のため）
• PowerShell: 5.1以上（Windows標準搭載）
• ブラウザ: Edge / Chrome / Firefox 等の標準ブラウザ
• Wi-Fiアダプタ: 内蔵または外付けの無線LANアダプタ（有線LANのみの環境ではWi-Fi情報取得不可）

入手方法

1. IroHive ToolsページからZIPをダウンロード（直接ダウンロード）
2. 任意のフォルダに解凍する（例: C:\Tools\SiteSurveyTool）
3. 解凍したフォルダ内のStart.batをダブルクリックして起動

起動から計測までの手順

① 起動

Start.batをダブルクリックすると、PowerShellサーバーが別ウィンドウ（最小化）で起動し、標準ブラウザでhttp://localhost:8080/が自動的に開く。サーバーの準備完了を確認してからブラウザを起動するため、最大20秒のポーリングが走る。

終了時はStop.batを実行する。Start.batウィンドウを閉じてもサーバープロセスは残り続けるため、必ずStop.batで停止すること。

② プロジェクト作成

1. ヘッダーの「＋ 新規プロジェクト」をクリック
2. プロジェクト名を入力（例: 本社2Fオフィス_2026-07）
3. プロジェクト設定でPingターゲットIP（デフォルト: 8.8.8.8）とスループット計測URL（デフォルト: http://speed.cloudflare.com/__down?bytes=10000000）を確認・変更する

③ フロアマップの準備

1. 「＋ フロア追加」でフロアを作成
2. マップ方式を選択：画像読み込み（PNG/JPGのフロアマップ画像。CAD出力PDFをPNG変換したものが最も使いやすい）またはグリッドエディタ（ブラウザ上で間取りを手描き）

④ ピン設置と計測

1. サイドバーの「📍 ピン設置モード」を有効にする
2. 計測したい場所（APの真下・電波が弱い疑いのある場所・各部屋の中央など）をマップ上でクリック
3. ラベル（例: 会議室A中央）と計測モードを指定して「計測開始」
4. 計測が自動実行され、結果がピンに蓄積される（同じピンで複数回計測を繰り返して平均を取ることも可能）

3つの計測モード詳解

Pingモード

デフォルトゲートウェイと指定IPへのRTT（ラウンドトリップタイム）・パケットロス率を計測する。System.Net.NetworkInformation.Pingを使用するため、icmp.exeは不要だ。

確認できる値:

• RTT最小値・平均値・最大値 (ms)
• パケットロス率 (%)

判断基準の目安: 平均RTTが20ms以下かつロス率0%なら問題なし。RTTが50msを超え始めたらAPとの距離が遠いか干渉が疑われる。

スループットモード

System.Net.Http.HttpClientを使ってHTTPダウンロード計測を行い、下り速度（Mbps）を算出する。デフォルトの計測URLは10MBのファイルを返すCloudflareのエンドポイントだ。

VoIP/ビデオ会議品質モード

連続Ping（デフォルト20回、20ms間隔）でRTTのばらつきからジッターを算出し、ITU-T G.107 E-modelを簡易実装したMOS値（Mean Opinion Score）を推定する。テレワーク環境でTeamsやZoomの通話品質が問題になっているエリアを特定するのに有効だ。

MOS値の読み方

※ MOS値は連続Pingによる簡易推定値であり、実際のVoIPコーデック品質とは異なる場合がある。傾向把握・エリア比較を目的として使用すること。

推定アルゴリズムの概要

ツールが内部で行っている計算は以下の通りだ（server/Server.ps1 のInvoke-VoipTest関数）。

1. 片道遅延を概算: latency = avgRTT / 2
2. 有効遅延を算出: effectiveLatency = latency + jitter × 2 + 10
3. 遅延劣化係数 Id を計算: effectiveLatency < 160ms → Id = effectiveLatency / 40 / effectiveLatency ≥ 160ms → Id = (effectiveLatency - 120) / 10
4. パケットロス劣化係数: Ie = lossPercent × 2.5（G.711相当）
5. R値を算出: R = 93.2 - Id - Ie
6. MOSへ変換: MOS = 1 + 0.035R + R(R-60)(100-R) × 7×10⁻⁶

概念は本物のE-modelに基づいており、大まかな傾向を掴むには十分な精度だ。「この会議室だけMOSが2台」という発見ができれば、APの追加・再配置の根拠として使える。

ヒートマップの読み方

ピンを3点以上設置すると、ヒートマップ表示セレクタで以下の3種類の分布を切り替えられる。

• 信号強度（dBm）: APの電波到達範囲と強度分布
• Ping遅延（ms）: RTTの地理的分布
• ジッター（ms）: VoIP品質劣化エリアの可視化

IDW補間とは

ヒートマップはピン設置点の間をIDW（Inverse Distance Weighting：逆距離加重補間）で補間して滑らかなグラデーションを生成する。計測点から遠い場所ほど、近傍の複数ピンの値を距離に反比例した重みで平均した値が使われる仕組みだ。

結果のエクスポート

計測が完了したらサイドバーのエクスポートボタンから出力できる。

CSVはBOM付きUTF-8のため、Excelで直接開いても文字化けしない。ダウンロード後にピボットテーブルでフロアごと・モードごとに集計するのが効率的だ。

設計判断：なぜPowerShellにしたのか

「なぜNode.jsやPythonではなくPowerShellなのか」は、このツールを評価する上で重要な判断基準だ。

「情シスが使うツール」として最も重要なのは導入の摩擦をゼロにすることだ。PowerShellを選んだことでランタイムインストール不要・依存パッケージなし・セキュリティ部門への申請なしで使えるツールが実現している。

トラブルシュート

① PowerShell実行ポリシーでブロックされる

企業PCではExecutionPolicyがRestrictedまたはAllSignedに設定されており、Start.batを実行しても何も起きない（またはエラーで終了する）ことがある。

Start.batは内部で以下のオプションを付けてPowerShellを呼び出しているため、通常はポリシーに関わらず起動する。

powershell -NoProfile -ExecutionPolicy Bypass -File “%SCRIPT_DIR%server\Server.ps1”

それでもブロックされる場合は、セキュリティ部門に-ExecutionPolicy Bypassでの実行許可を確認するか、スクリプトに署名を付ける対応が必要になる。

② Wi-Fi情報が文字化けする・取得できない

netsh wlan show interfacesの出力はWindowsのロケール設定に従って文字コードが決まる。日本語Windowsでは出力がShift_JISになるため、PowerShell側でUTF-8として読み取ろうとすると文字化けが発生する。

SiteSurveyToolは日本語版・英語版Windowsの両方に対応した正規表現パースを実装済みだが、UI上でWi-Fi情報が空欄または文字化けして表示される場合は以下を確認する。

• PCがWi-Fiに接続されているか（有線のみだとnetsh出力に情報が出ない）
• その他の言語OSを使用している場合はserver/Server.ps1内のGet-WifiInfo関数のパターンを調整する必要がある

③ ポート8080が競合して起動しない

他のアプリがポート8080を使用していると、サーバーが起動してもすぐに終了する。使用プロセスを確認するには以下を実行する。

netstat -ano | findstr :8080

出力されたPIDのプロセスを終了させるか、Start.batのPORT変数を変更して別のポートを使用する。

rem Start.bat の先頭付近
set “PORT=8081”

④ ブラウザが自動で開かない

Start.batはサーバーの起動確認後にstart "" “http://localhost:8080/“でブラウザを起動する。起動確認がタイムアウト（最大20秒）した場合でもブラウザ起動は試みるが、サーバーがまだ起動中の場合は「接続できない」エラーになる。数秒後に手動でURL（http://localhost:8080/）にアクセスすれば表示される。

⑤ スループット計測が失敗する

社内のプロキシサーバー経由でないとインターネットにアクセスできない環境では、デフォルトのhttp://speed.cloudflare.com/__down?bytes=10000000への直接接続が失敗する。この場合は社内サーバーにテスト用ファイルを置いてURLを変更するか、プロキシを経由するようServer.ps1のInvoke-ThroughputTest関数内でHttpClientHandlerにプロキシ設定を追加する必要がある。

まとめ

SiteSurveyToolを使うことで、専用ソフトウェアなしに「フロアマップ上のどこで電波が弱いか・Pingが遅いか・VoIPが厳しいか」を可視化できる。意思決定に必要なのは感覚ではなく数値と地図だ。

• APの追加配置を提案するとき: 信号強度ヒートマップのPNGを報告書に貼る
• 「Teams会議の声が途切れる」という申告を受けたとき: VoIPモードでMOS値が低いエリアを特定する
• 新オフィスのAP配置設計をするとき: フロアプランを読み込んでピンを格子状に置き、計測結果を根拠にベンダーに仕様を伝える

インストール作業がゼロなのは「とりあえず試してみる」ハードルを下げる。申請を出す前に自分のPCで動かして、使えると判断してから展開を考えればよい。