AIで深堀！「Wi-Fiが固まる」の正体を30分で切り分ける ― レイヤー別トラブルシューティング完全ガイド

wTokyoWireless
6月10日
読了時間: 11分

「Wi-Fiが固まるんだけど、なんとかして」――情シス担当者なら誰もが受け取ったことのある問い合わせではないでしょうか。

しかし「固まる」という症状の裏には、電波の干渉からVPNの設計、TeamsやOutlookの仕様まで、まったく異なる層の原因が潜んでいます。やみくもにAPを再起動しても、原因の層を外していれば症状は再発します。

本記事では、「Wi-Fiが固まる」問題を 5つのレイヤー に分解し、それぞれの典型原因・切り分け方法・対処法を、中小企業のIT担当者の実務目線で整理します。最後に症状から原因を逆引きできる「切り分けマトリクス」も用意しました。

レイヤー1：電波（RF）層 ― 目に見えない最下層

同一チャネル干渉と隣接チャネル干渉は別物

近隣のアクセスポイント（AP）との干渉には2種類あります。

同一チャネル干渉（CCI）：他のAPと同じチャネルを使っている状態。Wi-Fiの仕組み（CSMA/CA）により「順番待ち」が発生するため、遅くはなりますが完全には止まりにくい干渉です。
隣接チャネル干渉（ACI）：チャネルが部分的に重なっている状態（2.4GHz帯のch3やch8など）。互いの送信を検知できず衝突→再送が多発し、瞬間的なフリーズの主因になります。

2.4GHz帯では ch1 / 6 / 11 以外を使わない のが鉄則です。中途半端なチャネルを使うAPが1台あるだけで、周囲全体の再送率が悪化します。

非Wi-Fi干渉源：プロトコル解析では絶対に見えない敵

電子レンジ、Bluetooth機器、ワイヤレスカメラ、そして意外なところでは USB 3.0機器 も2.4GHz帯の干渉源になります。USB 3.0の高速信号から発生するブロードバンドノイズが2.4〜2.5GHz帯に重なり、近くの無線受信機の感度を低下させることは、Intelが2012年のホワイトペーパーで公式に文書化している既知の問題です（出典1）。

ここで重要なのは、これらのノイズはWi-Fiのパケットとして存在しないため、パケットキャプチャやWi-Fiアナライザアプリでは原理的に検出できないということです。検出できるのはスペクトラムアナライザだけです。「設定はすべて正しいのに固まる」「再起動しても直らない」というケースでは、この不可視領域に原因が潜んでいることが少なくありません。

DFS：突然1分固まって自然復旧する怪現象の正体

5GHz帯のW53（ch52〜64）とW56（ch100〜144）は、気象レーダー・航空レーダーと周波数を共用しています。日本ではレーダー保護のため、これらのチャネルを使うAPには DFS（Dynamic Frequency Selection） の搭載が法律で義務付けられています（出典2）。

APがレーダー波を検知すると、即座にそのチャネルの使用をやめて別チャネルへ移動します。移動先がまたW53/W56だった場合、使用開始前に約1分間レーダーの有無を傍受（CAC：Channel Availability Check）する必要があり、その間は通信できません。さらにレーダーを検出したチャネルは30分間使用禁止になります（出典3）。

「1日に数回、全員のWi-Fiが1分ほど固まって勝手に復旧する」――この症状はほぼDFSです。空港・港湾・気象レーダー施設の近くのオフィスで頻発します。対処はW52（ch36〜48）への固定、または屋内ならDFSイベントのログ確認です。

レイヤー2：ネットワーク（L2/L3）層

ローミング不全：「移動すると固まる」の本丸

オフィス内を移動すると固まる場合、最有力容疑者は Sticky Client（スティッキークライアント）問題 です。どのAPに接続するかの判断は端末側に主導権があり、端末は電波が極端に弱くなるまで元のAPにしがみつきます。結果、「アンテナ表示は立っているのに実質通信不能」という状態に陥ります。

対策は階層的に行います。

802.11k/v/r（高速ローミング支援規格）の有効化
APの送信出力を下げる（直感に反しますが、出力過剰はSticky Clientを悪化させる定番要因です）
最低RSSI設定で弱い端末を強制的にローミングさせる

バッファブロート：スピードテストでは絶対に見つからない原因

バッファブロートとは、ルーターなどのネットワーク機器が過剰なバッファにデータを溜め込むことで生じる望ましくない遅延のことです。ボトルネック回線に送りきれないパケットがバッファに滞留し、後続のトラフィックがその後ろで詰まることで、全トラフィックに数秒単位の巨大な遅延が発生することもあります。ユーザーにはゲームのラグ、ビデオ通話の途切れ、「なんとなくネットが遅い」として体感されます（出典4）。

恐ろしいのは、帯域（Mbps）は正常値が出ることです。スピードテストの数値は良好なのにTeams会議だけ崩壊する場合、まずこれを疑ってください。Waveform社が提供する無料のバッファブロートテスト（waveform.com/tools/bufferbloat）では、負荷時のレイテンシ増加をA+〜Fで判定でき、平均レイテンシ増加が5ミリ秒未満ならA+、400ミリ秒以上ならFといった基準で評価されます（出典5）。対策はSQM（Smart Queue Management）/fq_codel対応ルーターの導入や上りQoS設定です。

DNSとDHCP：地味だが頻出

固まった瞬間に ping 8.8.8.8 は通るのに名前解決だけ遅い → DNS障害 確定
固まった瞬間にIPアドレスが 169.254.x.x になっている → DHCP障害 確定

この2つのコマンド確認だけで、かなりの切り分けができます。

レイヤー3：AP・ハードウェア層

時間相関で犯人を絞る

ハードウェア起因の問題は、症状の出方に時間的なパターン が現れるのが特徴です。

時間パターン	容疑者
再起動直後は快調 → 数日〜数週で劣化	ファームウェアのメモリリーク
夏の午後だけ固まる	熱（天井裏設置のAPは要注意）
始業直後・昼休み明けだけ	同時接続集中・ログオンストーム
高負荷時だけ5GHzが不調	PoE給電不足の可能性

特にPoE給電不足は見落とされがちです。Wi-Fi 6対応APの多くはPoE+（30W）以上を要求しますが、旧式のPoE（15.4W）スイッチに接続すると、起動はするものの片方のバンドを無効化したり性能を制限したりする機種があります。

レガシー機器の「エアタイム泥棒」

Wi-Fiの帯域は「時間」の奪い合いです。802.11bの低速端末（古いプリンタ、ハンディターミナル、IoTセンサーなど）が1台いるだけで、同じデータ量の送信に最新端末の数百倍の電波占有時間を消費します。対策は11bの無効化と最低ベーシックレートの引き上げです。どの端末がエアタイムを占有しているかは、パケットキャプチャ解析で可視化できます。

レイヤー4：クライアント（端末）層

Windows Updateとドライバ：定番中の定番

Windows Updateの際にWi-Fiアダプタのドライバが汎用版に置き換わり、不具合が出るのは古典的なパターンです。デバイスマネージャーでドライバーの日付を確認し、数年前であればチップセットベンダー（Intel / Realtek / MediaTek）の最新版への更新を試してください。

省電力設定：在宅ワークPCで特に多い

デバイスマネージャー → Wi-Fiアダプタのプロパティ → 電源の管理 →「電力の節約のために、コンピューターでこのデバイスの電源をオフにできるようにする」の チェックを外す
電源オプション → ワイヤレスアダプターの設定 → 最大パフォーマンス

省電力機構による復帰遅延は、後述するVDIのような常時双方向通信で最も顕著に「カクつき」として現れます。

レイヤー5：ソフトウェア・クラウド層 ― VPN / VDI / Teams / Outlook

ここからが本記事の核心です。リモートワーク時代の「Wi-Fiが固まる」問い合わせの多くは、実はこの層と無線層の 複合問題 です。

VPN：物理層の1秒断が体感1分のフリーズに化ける

TCP-over-TCP問題：SSL-VPN（TCP 443）でトンネルを張ると、外側TCPと内側TCPの再送制御が干渉し合い、無線区間のわずかなパケットロスが指数的に増幅されます。「VPN経由だけ異常に遅い」の古典的原因で、DTLS/UDPモードへの切り替えが定石です。

MTU問題：VPNのカプセル化オーバーヘッドで実効MTUが縮小します。「VPN接続は成功する、pingも通る、しかしファイル転送だけ固まる」という特異な症状はほぼMTUです。トンネルMTUの明示設定（1350〜1400程度）とTCP MSS調整で対処します。

スプリットトンネル：Microsoftは、Teamsのメディアトラフィックを含む「Optimize」カテゴリのエンドポイント（M365トラフィック量の約70〜80%を占める）について、VPNトンネルから除外して直接インターネットへ抜けさせるスプリットトンネル構成を公式に推奨しています（出典6）。在宅勤務者だけTeams会議が固まる場合、フルトンネルVPN設計が最有力容疑者です。

VDI：無線品質に最も敏感なアプリケーション

VDI（仮想デスクトップ）は「操作→サーバー→画面更新」のラウンドトリップがそのまま操作感になるため、帯域よりも レイテンシとジッタ（遅延の揺らぎ） に敏感です。

実務上の最大の落とし穴は TCPフォールバック です。Citrix HDX（EDT）、VMware Blast、RDPはいずれもUDPベースの転送で品質を確保していますが、ファイアウォールやVPNでUDPが阻害されると、気づかないうちにTCPのみで動作します。正常時は気づきませんが、無線品質が少しでも劣化した瞬間、TCP再送の増幅効果で盛大に固まります。「VDIだけ異常にカクつく」場合は、まずセッションがUDPで張れているかを確認してください。

また、Wi-Fiローミングの瞬断がVDIセッション切断→再ログインに発展するケースもあります。Citrixの Session Reliability のようなセッション継続機能の設定次第で、瞬断を「数秒の固まり」で済ませられるかが分かれます。

Teams：チャットは正常なのに通話だけ崩れる理由

Teamsの通話・会議のメディアトラフィックは、UDPポート3478〜3481 を使用します（3478=STUN、3479=音声、3480=映像、3481=画面共有）。Microsoftはこれらのポートの開放を必須要件としています（出典7）。

このUDPがファイアウォールやVPNで塞がれていると、TeamsはTCP 443にフォールバックして動作を継続します。繋がるので誰も気づきませんが、リアルタイム性は大きく劣化し、無線品質の揺らぎがそのまま音声の途切れ・映像のフリーズになります。

症状から層を逆引きできます。

音声がブツブツ途切れる → パケットロス／ジッタ（無線層を疑う）
会話が被る・反応が遅い → レイテンシ（バッファブロート、VPN経由を疑う）
画面共有だけ固まる → 帯域不足

Outlook：「Wi-Fiの濡れ衣」の代表格

Outlookの「応答なし」はネットワークのせいにされがちですが、ローカル要因も多くあります。

OSTファイルの肥大化：Microsoftの公式ガイドラインでは、OSTファイル（キャッシュモードのローカルデータ）は 5GBまでなら大半のハードウェアで良好、5〜10GBはハードウェア依存 とされており、それを超えると動作の引っかかりが生じやすくなります（出典8）。また1フォルダあたり10万件を超えるアイテムがあると特定操作が遅くなることも公式に文書化されています（出典9）。同期スライダーでキャッシュ期間を3〜12ヶ月に短縮するのが定石です。

アドイン：outlook.exe /safe でセーフモード起動して再現しなければアドイン確定。これもMicrosoftの公式トラブルシューティング手順です（出典8）。

SSL検査プロキシ：Microsoftは、M365の主要エンドポイント（Optimize/Allowカテゴリ）について、TLS復号・パケット検査・プロキシ認証をバイパスすることを推奨しています（出典10）。セキュリティアプライアンスでM365トラフィックをフル検査に通している環境では、その処理遅延が「Outlookが固まる」「Teamsが重い」として現れます。

症状から原因を逆引きする切り分けマトリクス

症状の出方	第一容疑者	確認方法
移動すると固まる	ローミング不全（Sticky Client）	固まった時のRSSI・接続先APを確認
突然約1分固まり自然復旧	DFSレーダー検知	APログ、使用チャネルがW53/W56か
VPN経由だけ遅い・固まる	TCP-over-TCP、MTU	DTLSモード確認、ping -f -l でMTU探索
VDIだけカクつく	TCPフォールバック、ジッタ	セッションのプロトコル（UDP/TCP）確認
Teams通話だけ崩れる	UDP 3478-3481ブロック	Teams通話品質ダッシュボード、FW設定
在宅勤務者だけ固まる	フルトンネルVPN	スプリットトンネル設定確認
Outlookだけ重い	OST肥大、アドイン	OSTサイズ確認、/safe起動
スピードテスト正常なのに固まる	バッファブロート	Waveformバッファブロートテスト
再起動で直り徐々に悪化	APメモリリーク	稼働時間と症状の相関、ファーム更新
夏の午後だけ	APの熱	設置場所の温度確認
名前解決だけ遅い	DNS	ping 8.8.8.8 と nslookup の比較
設定は完璧なのに原因不明	非Wi-Fi干渉（不可視領域）	スペクトラムアナライザでの調査

最後の砦：「見えない層」を可視化する

ここまでの切り分けで多くの問題は特定できますが、最後に残るのが 電波層の不可視問題 です。

非Wi-Fi干渉（電子レンジ、ワイヤレスカメラ、USB3.0ノイズなど）は、OSの電波強度表示にもパケットキャプチャにも一切現れません
再送率やエアタイム占有は、管理画面の「接続台数」「電波強度」だけでは見えません
「Teamsが固まる→実はTCPフォールバック→その引き金は無線区間の再送多発→真因は隣のテナントのワイヤレスカメラ」のような因果チェーンは、計測なしには辿れません

こうした領域の調査には、スペクトラムアナライザ（Wi-Spyなど）による物理層の可視化と、パケット解析ツール（Eye P.A.など）による再送率・エアタイム分析が必要になります。当サイト（wi-t.com）では、OSCIUM（METAGEEK）社のWi-Fi電波・パケット解析ツールを正規代理店として取り扱っており、導入のご相談も承っています。「再起動しても直らないWi-Fiトラブル」でお困りの際は、お気軽にお問い合わせください。

まとめ

「Wi-Fiが固まる」は単一の問題ではなく、電波・ネットワーク・ハードウェア・端末・ソフトウェアの5層にまたがる症状の総称です。

まず 症状のパターン（いつ・誰が・何が）を記録する
切り分けマトリクスで 層を絞る
その層の定番原因から順に潰す
それでも残る「見えない問題」は 計測ツールで可視化 する

この順序を守るだけで、トラブルシューティングの時間は劇的に短縮できます。

出典一覧

Intel「USB 3.0* Radio Frequency Interference Impact on 2.4 GHz Wireless Devices」White Paper（2012年、Document 327216） https://www.usb.org/sites/default/files/327216.pdf
ASUS「[WiFiルーター] DFS（Dynamic Frequency Selection）とは？」 https://www.asus.com/jp/support/faq/1045936/
アライドテレシス AT-TQシリーズユーザーマニュアル「無線設定（W53/W56のレーダー検出動作）」 https://www.allied-telesis.co.jp/support/list/wireless/at-tq/rel/7.0.1-2.1/613-002942_F/user/doc00028.html
OPNsense Documentation「Fighting Bufferbloat with FQ_CoDel」 https://docs.opnsense.org/manual/how-tos/shaper_bufferbloat.html
Waveform「Bufferbloat and Internet Speed Test」 https://www.waveform.com/tools/bufferbloat
Microsoft Learn「Microsoft 365 の VPN スプリットトンネリングの概要」 https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-vpn-split-tunnel
Microsoft Learn「Microsoft Teams call flows」（TCP 80/443、UDP 3478〜3481の要件） https://learn.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows
Microsoft Support「How to troubleshoot performance issues in Outlook」（OSTサイズガイドライン） https://support.microsoft.com/en-us/topic/how-to-troubleshoot-performance-issues-in-outlook-7ac5402d-c4eb-ed6b-9545-b26dde618755
Microsoft Learn「Outlook performance issues in a Cached Exchange Mode .ost or .pst file」 https://learn.microsoft.com/en-us/troubleshoot/outlook/performance/performance-issues-if-too-many-items-or-folders
Microsoft Learn「Managing Microsoft 365 endpoints」（プロキシ／TLS検査バイパスの推奨） https://learn.microsoft.com/en-us/microsoft-365/enterprise/managing-office-365-endpoints