この記事の目的：Wi-Fiが遅いという症状だけから無線機器の故障と決めつけず、通信経路を層に分けてボトルネックを特定するための手順を整理します。
「Wi-Fiが遅い」は結果であって原因ではない
端末からWebサイトまでの通信には、端末の無線LAN、アクセスポイント、メッシュのバックホール、有線LAN、ルーター、ONU、インターネット回線、DNSなど複数の要素が関係します。どこか一つが遅ければ利用者からは同じ「Wi-Fiが遅い」に見えます。そのため機器交換より先に、正常な区間と異常な区間を分けることが重要です。
切り分けは上流から行う
1. 回線とルーター直下
可能なら有線接続でルーター近くの速度と遅延を確認します。ここで既に遅ければ、APを増設しても根本改善にはなりません。時間帯による変動、WANリンク速度、ルーター負荷も確認します。
2. 有線LAN
100Mbpsでリンクしていないか、ケーブルやスイッチのポートに問題がないかを確認します。Wi-Fi 6/7のAPでも上流が100Mbpsなら、それ以上のインターネット速度は期待できません。
3. AP・Mesh
APの設置位置、接続クライアント数、チャネル、帯域幅、バックホールを確認します。メッシュでは端末―子機だけでなく子機―親機の品質が重要です。有線バックホールが利用できる環境では安定性を高められる場合があります。
4. 電波
RSSIだけでなく、干渉、SNR、利用チャネル、2.4GHz/5GHz/6GHzのどこへ接続しているかを見ます。強い電波でも同一チャネルが混雑していれば性能は落ちます。
5. クライアント端末
一台だけ遅いならAPより端末固有の可能性が高まります。無線LANドライバー、省電力設定、対応規格、VPN、セキュリティソフト、古い接続情報などを比較します。
測定値は同じ条件で比較する
速度測定は一回の数字だけで判断せず、同じ端末・同じ測定先で、親機付近、問題地点、有線接続など条件を変えて比較します。下り・上りだけでなくPingやパケットロスも確認します。Web会議では最大速度より遅延や安定性が問題になることがあります。
実案件：1階だけ通信性能が低下したケース
2階にルーターとメッシュ側のコントローラー、1階にクライアント機器がある環境で、1階側の通信が十分に機能していないケースがありました。上流側だけを交換するのではなく、1階クライアントの状態を点検・調整した結果、通信速度が回復しました。このように「1階が遅い」という症状でも、回線全体の交換が必要とは限りません。実測値を記録していない数値はここでは掲載していません。
避けたい対処
- 測定せず高価なルーターへ交換する
- 電波が弱い場所そのものへメッシュ子機を置く
- 複数ルーターを無計画にルーターモードで接続する
- 速度測定一回だけで回線障害と断定する
- 有線LANがあるのに配線状態を確認しない
専門調査で見る項目
WAN、有線リンク速度、DHCP、DNS、NAT、RSSI、SNR、チャネル利用、APごとの接続数、ローミング、バックホール、端末側無線情報を組み合わせます。目的は「電波を強くする」ことではなく、通信経路のどこが性能を制限しているかを特定することです。
参考資料
周波数帯ごとの特徴を分けて考える
2.4GHz帯は壁などを越えて届きやすい一方、Bluetoothや家電を含む周辺機器の影響を受けやすく、利用できる非重複チャネルも限られます。5GHz帯は一般に広い帯域を利用しやすいものの、距離や遮蔽物による減衰が大きくなります。6GHz帯を使えるWi-Fi 6E/7環境では新しい帯域を利用できますが、端末側も対応している必要があります。規格名だけでなく、実際に端末がどのバンド・チャネルへ接続しているかを確認します。
APを増やせば必ず改善するわけではない
アクセスポイントを増設するとカバー範囲は広げられますが、設置密度や送信出力、チャネル設計が不適切ならAP同士が競合することがあります。小規模オフィスでも、人数だけでなく端末台数、Web会議の頻度、間取り、壁材、既存配線を確認して台数を決めます。AP一台あたりの最大接続可能数と、快適に同時通信できる台数は同じ意味ではありません。
DHCP・DNS・二重ルーターも確認する
Wi-Fiへは接続済みなのに「インターネットなし」と表示される場合、無線区間が正常でもDHCPでIPアドレスやデフォルトゲートウェイを取得できていない可能性があります。Webサイト名だけ開けないならDNSも候補です。また回線事業者ルーターの下へ市販ルーターをルーターモードで追加すると、意図しない二重NATになることがあります。二重ルーターが直ちに故障を意味するわけではありませんが、ポート転送、VPN、機器発見などを複雑にするため構成を把握します。
ローミングは端末側の判断も関係する
複数APを同じSSIDで運用していても、端末が常に最も近いAPへ瞬時に移動するとは限りません。802.11k/v/rなどの支援機能が利用できる構成でも、最終的な接続判断にはクライアント実装が関係します。遠いAPへ端末が残り続ける、移動時だけWeb会議が途切れるといった症状では、接続先BSSIDやローミング時の挙動を確認します。
法人環境では利用者数より端末数を見る
利用者10人でも、一人がPC、スマートフォン、タブレット、プリンター、会議機器など複数台を使えば接続端末は大きく増えます。始業時だけ不調になる場合は、多数端末の同時接続、DHCPリース、クラウド同期、OS更新など時間帯に連動する要因も候補です。「平常時の速度」だけでなく問題が起きる時間帯に測定することが重要です。
改善案は原因が分かってから選ぶ
原因が回線なら契約や回線側、ルーター性能ならルーター、電波設計ならAP位置や台数、バックホールなら有線化、端末固有なら端末設定というように対策は変わります。現地調査の価値は、最初から特定製品を売ることではなく、現在の設備を活かせる部分と変更すべき部分を分けることにあります。
速度だけでなく安定性を評価する
最大速度が高くても、短時間の切断や遅延変動が大きければWeb会議やリモート操作では使いにくくなります。一定時間のPing、複数回の速度測定、実際の会議アプリ利用などを組み合わせ、瞬間的な最高値ではなく業務に必要な安定性を評価します。問題が始業時だけ発生するなら、その時間帯に同じ条件で再現を取ることが重要です。
なお、改善前後は同じ端末・同じ場所・同じ測定条件で比較し、設定変更の効果を確認します。これにより偶然の速度変動と実際の改善を区別しやすくなります。