Wi-Fiの品質確認では、画面のアンテナ本数や「接続済み」という表示だけで判断せず、無線区間、IP設定、宛先までの通信を順番に切り分けます。PowerShellからWindows標準のnetsh wlan show interfacesを呼び出すと、現在接続しているSSID、信号、チャネル、送受信速度などを読み取れます。ただし信号の百分率はインターネット速度そのものではありません。本記事では、設定を変えずに現在値を集め、遅い、途切れる、特定サービスだけ使えないといった症状を安全に調べる手順を解説します。
最初に症状と測定条件を固定する
「Wi-Fiが悪い」という申告を、接続できない、頻繁に切れる、応答が遅い、転送速度が低い、会議の音声だけ途切れる、社内VPN接続中だけ遅い、のように具体化します。測定する端末、時刻、部屋、アクセスポイントまでのおおよその距離、電源接続、VPNの有無、同時利用アプリも記録します。一回だけの値では偶然の混雑やローミングを見落とすため、正常な場所と問題が出る場所を同じ手順で比べます。
無線品質は端末側だけで決まりません。アクセスポイントの負荷、周波数帯、チャネル混雑、遮蔽物、電子レンジなどの干渉、ドライバー、電源管理、回線、DNS、VPN、接続先サービスが関係します。最初からルーター交換や設定初期化へ進まず、無線リンク、ローカルネットワーク、インターネット、アプリのどの層で差が出るかを確認します。会社や学校の端末では、管理者が定めた無線設定を利用者判断で変更しません。
netsh wlan show interfacesで現在の無線接続を読む
netsh wlan show interfacesは、Windowsが認識している無線LANインターフェースと現在の接続情報を表示します。PowerShellでそのまま実行し、インターフェース名、状態、SSID、BSSID、無線の種類、チャネル、受信速度、送信速度、信号などを確認します。複数の無線アダプターや仮想アダプターがある端末では、目的のインターフェースのまとまりを取り違えないようにします。
netsh wlan show interfaces表示される項目名はWindowsの表示言語やバージョンで異なることがあります。そのため、日本語の「シグナル」や英語の「Signal」を前提にした正規表現を全端末へ配ると、別言語環境で空欄になり得ます。まず人が元出力を保存せず画面で読み、スクリプト化する場合は対象OSと言語を明示して試験します。SSIDやBSSIDは組織・設置場所を推測できる情報なので、結果を外部へ貼る前に伏せます。パスフレーズを表示するコマンドは品質確認には不要です。
信号の百分率とリンク速度を正しく解釈する
Signalとして示される百分率は、端末が報告する受信信号品質の目安です。値が高いほど一般には受信条件が良いと考えられますが、メーカーやドライバー、測定タイミングの差があり、異なる端末間の絶対比較には向きません。特定の境界値だけで合否を決めず、同じ端末で場所や時刻を変えたときの傾向、切断時刻との一致、アクセスポイント側の記録を合わせて見ます。
受信速度と送信速度は、その時点で無線リンクが合意している物理層の速度であり、ファイル転送やWeb閲覧で得られる実効速度ではありません。暗号化、再送、チャネル共有、プロトコルのオーバーヘッド、回線帯域、サーバー負荷で実効値は下がります。リンク速度が高くてもパケット損失が多ければ体感は悪化します。逆に低めでも業務に必要な帯域と遅延を満たす場合があります。用途別の基準を先に決めます。
Get-NetAdapterで対象アダプターを特定する
Get-NetAdapterは、Windowsが認識するネットワークアダプターの基本プロパティを取得します。まず全体を表示して、Wi-Fiに対応するName、InterfaceDescription、Status、LinkSpeed、ifIndexを記録します。表示名が必ず「Wi-Fi」とは限らず、利用者が名前を変更している場合もあります。説明とインターフェース番号を使うと、IP設定や統計との対応を追いやすくなります。
Get-NetAdapter |
Select-Object Name, InterfaceDescription, Status, LinkSpeed, ifIndexStatusがUpでも、IPアドレス、既定ゲートウェイ、DNS、外部サービスが正常とは限りません。LinkSpeedもネットワーク全体の実効速度ではありません。非表示の仮想アダプター、Bluetooth、VPN、Hyper-Vなどが並ぶ端末では、実際に通信へ選ばれたインターフェースをIP構成や経路と照合します。障害調査のためにアダプターを無効化、再起動、削除する操作は、現在値の取得とは別の承認された作業にします。
Get-NetAdapterStatisticsで増加量を見る
Get-NetAdapterStatisticsでは、受信・送信したバイト数、ユニキャストやマルチキャストのパケット数、破棄やエラーに関係する統計をアダプター単位で確認できます。単一時点の累積値だけでは問題の発生時刻が分からないため、同じコマンドを一定間隔で二回実行し、その間に症状を再現して増加量を比べます。端末再起動やアダプターのリセットでカウンターが変わる可能性も記録します。
Get-NetAdapterStatistics -Name "Wi-Fi" |
Format-List *エラーや破棄が一件でもあれば必ず障害というわけではなく、累積期間と通信量が重要です。短時間に急増し、同時に会議音声が途切れるなら有力な手掛かりになります。プロパティはドライバーやWindows版により利用できる範囲が異なるため、存在しない列をゼロと扱いません。Wi-Fiの無線再送をすべてこの統計だけで把握できるとも限らないので、アクセスポイントの管理情報やWindowsイベントと照合します。
IPアドレス、ゲートウェイ、DNSを別に確認する
無線リンクが接続済みでも、DHCPから正しいアドレスを得られない、既定ゲートウェイがない、DNS設定が想定外ということがあります。Get-NetIPConfigurationで対象インターフェースのIPv4・IPv6アドレス、既定ゲートウェイ、DNSサーバーを確認します。Get-NetAdapterのifIndexや名前と対応させ、EthernetやVPNの情報をWi-Fiの情報と取り違えないようにします。
Get-NetIPConfiguration -InterfaceAlias "Wi-Fi"169.254.0.0/16のIPv4アドレスが見える場合は、一般にDHCPからアドレスを取得できなかった状況が疑われますが、直ちにルーター故障と決めません。会社ネットワークの固定設定、接続認証、VLAN、DHCP範囲、重複、VPNの経路を管理者と確認します。DNSサーバーが表示されても名前解決の成功を保証しません。IP設定の再作成やDNS変更は利用中の通信へ影響するため、確認段階では実施しません。
ゲートウェイと業務サービスまで段階的に試す
Test-NetConnectionは、名前解決、選択されたインターフェース、送信元アドレス、ICMP応答、指定TCPポートへの接続などの診断情報を表示できます。まずGet-NetIPConfigurationで得た既定ゲートウェイを確認し、次に組織がテストを許可しているDNS名や業務サービスのTCPポートを少数回試します。例のホスト名をそのまま使わず、管理者が用意した監視先へ置き換えます。
Test-NetConnection -ComputerName "service.example.com" -Port 443 -InformationLevel DetailedPingSucceededがFalseでも、相手や途中の装置がICMPを応答しない方針の場合があります。TcpTestSucceededがTrueでも、TLS、HTTP、認証、アプリ処理まで正常という意味ではありません。無線リンクの数値が良く、ゲートウェイへ届き、特定サービスだけ失敗するなら、DNS、プロキシ、VPN、サーバー側へ調査範囲を移します。短時間に多数の宛先やポートを走査しません。
複数回サンプリングして瞬断を見つける
瞬断やローミングは一回の表示では捕まらないため、利用者の同意を得た短い時間だけ、時刻とnetsh wlan show interfacesの出力を繰り返し画面へ表示します。ファイルへ保存しなくても、信号、BSSID、チャネル、送受信速度が症状の直前に変わるかを観察できます。長時間の高頻度監視は端末負荷やログ量を増やすので、目的、間隔、終了時刻を決めます。
1..6 | ForEach-Object {
Get-Date -Format o
netsh wlan show interfaces
Start-Sleep -Seconds 10
}BSSIDが変わった時刻に短い切断が起きるならローミングが関係する可能性がありますが、BSSID変更自体は複数アクセスポイント環境の正常動作でもあります。チャネルが混雑しているか、帯域幅が適切か、アクセスポイント側で再認証や切断が記録されたかを確認します。端末側から勝手に接続先を固定したり、社内SSIDの優先順位を変えたりせず、無線管理者へ時刻と観測値を渡します。
よくある誤判定を避けて次の担当へ渡す
信号が100%なら問題なし、リンク速度が高ければ高速、pingが通ればアプリも正常、という判断はいずれも不十分です。反対に、信号が一時的に低い、ICMPが返らない、統計に少数の破棄があるだけで障害とも断定できません。観測値を「無線リンク」「IPと経路」「名前解決」「TCP」「アプリ」の層へ分け、成功した最後の地点と失敗した最初の地点を示します。
問い合わせには、SSIDを必要な範囲で伏せた上で、端末・アダプター名、ドライバー版、時刻、場所、Signalの推移、BSSIDやチャネルの変化、LinkSpeed、統計の増加、IP構成、Test-NetConnectionの対象と結果を添えます。認証情報、無線キー、社内IPの全一覧を一般公開しません。再起動やドライバー更新が必要と判断した場合も、業務影響と復旧手順を確認して別作業として扱います。
確認結果を判断するときのチェックリスト
- 症状、場所、時刻、VPNと同時利用アプリをそろえて測定したか
- netsh wlan show interfacesで対象インターフェース、SSID、Signal、チャネルを確認したか
- Signal、リンク速度、実効速度、遅延、パケット損失を混同していないか
- Get-NetAdapterとGet-NetAdapterStatisticsで状態と増加量を分けて見たか
- Get-NetIPConfigurationでWi-Fi側のアドレス、ゲートウェイ、DNSを確認したか
- Test-NetConnectionの結果をICMP、TCP、アプリの成功へ正しく限定したか
- SSID、BSSID、社内IP、認証情報を外部へ公開しない形で記録したか
確認結果には、実行日時、端末名、Windowsのエディションとビルド、PowerShellの版、対象インターフェース、接続場所を添えて残します。同じ数値でも端末の移動、ドッキング、VPN、スリープ復帰、ドライバー更新で意味が変わるためです。設定変更や再接続へ進む場合は確認作業と分け、利用者への影響、管理ポリシー、元の状態、戻し方を確かめてから実施します。
コメント