AIで深堀！Wi-Fiが頻繁に切れる「フラッピング」の原因と対策 ― ローミング設計の実践ガイド

wTokyoWireless
6 日前
読了時間: 14分

「Wi-Fiが時々切れる」「Teamsの音声が途切れる」「VPNが勝手に再接続される」――社内からこんな申告が上がってくるものの、調べてみるとpingは通るし、電波も「強」と表示されている。そんな経験はないでしょうか。

完全に切れるわけではなく、断続的な瞬断を繰り返す。この症状の背後によく潜んでいるのが、本記事のテーマである 「フラッピング(flapping)」 です。

フラッピングは原因が複数のレイヤにまたがるため、「とりあえずAPを再起動」「電波を強くする」といった対症療法では解決しないどころか、悪化することすらあります。本記事では、中小企業のIT担当者・情シス担当者の方を対象に、フラッピングの仕組みを「クライアントがどう判断して切り替えるのか」というレベルまで掘り下げ、設定値・設計値の具体的な目安とともに対策を整理します。

1. フラッピングとは何か ― 4つのパターン

ネットワーク用語のフラッピングは、本来「安定すべき状態が短時間に行ったり来たりを繰り返す」現象全般を指します。Wi-Fiの文脈では、症状が似ているために混同されがちな4つのパターンがあります。まずはここを切り分けることが診断の第一歩です。

① AP間フラッピング(ローミングフラッピング)

クライアント端末が複数APのカバレッジ境界に位置し、接続先APを数秒〜数十秒単位で頻繁に切り替える現象。最も典型的な「Wi-Fiフラッピング」です。再接続(再アソシエーション)のたびに短い通信断が発生し、Web閲覧では気づきにくい一方、VoIP・Web会議・VDIといったリアルタイム系アプリでは顕著な品質劣化として現れます。

② バンド間フラッピング

同一APの中で2.4GHz帯と5GHz帯(環境によっては6GHz帯)を行き来する現象。AP側のバンドステアリング機能(5GHzへの誘導)とクライアント側の判断が衝突すると、「APが5GHzへ誘導 → クライアントが電波の届きやすい2.4GHzへ戻る → 再誘導」というループに陥ります。

③ 接続/切断フラッピング

アソシエーション → 認証失敗 → 切断 → 再試行のループ。RADIUSサーバーの応答遅延、証明書の不整合、DHCPアドレス枯渇などが原因で、無線品質ではなく上位レイヤの問題であることが多いパターンです。

④ 有線側のポートフラッピング

APのアップリンクポートがリンクアップ/ダウンを繰り返すケース。LANケーブルの不良や、PoE給電能力の不足(消費電力の大きいWi-Fi 6/6E対応APを旧来のPoEで給電している場合など)が典型です。無線の問題に見えて実は有線側、という落とし穴です。

本記事では、このうち設計で解決すべき①と②を中心に掘り下げます。

2. クライアントのローミングは「2段階」で動く

フラッピングを理解する鍵は、「クライアントはいつ・どうやって接続先を切り替えるのか」という判断ロジックです。多くのクライアント実装は、常時すべてのAPを比較しているわけではなく、2段階で動いています。

第1段階:トリガー(スキャンを始めるか)

現在接続中のAPの受信強度(RSSI)が絶対しきい値を下回って初めて、周辺APのスキャンを開始します。スキャン自体が通信を中断しバッテリーを消費するため、必要になるまでやらない設計です。

このしきい値はApple社が公表しており、具体的には iPhone/iPadは −70dBm、Macは −75dBm を下回るまで現在の接続を維持し、それを越えてからローミング候補のスキャンを始めます(出典1)。

第2段階:判定(どこへ移るか)

スキャンの結果、候補APが「現在のAPより一定値以上強い」場合に切り替えます。この「一定値」が次章で解説するヒステリシスです。こちらもAppleが具体値を公表しており、macOSは802.11k非対応のネットワークでは「現在のAPより12dB以上強い候補」を選択します(出典2)。

重要なのは、ヒステリシスは第2段階の判定値であり、第1段階のトリガーが引かれない限り出番がないということです。両方のAPを−55dBmで受信できるような強電界ゾーンでは、そもそもスキャンが走らないため、受信強度起因のフラッピングは原理的に起きにくい――この性質は、後述する「受信強度帯による原因切り分け」につながります。

3. ヒステリシス ― フラッピングとスティッキーのトレードオフ調整弁

ヒステリシスとは「切替に要求する信号差のマージン」です。具体的な数字で動きを見てみましょう。

ヒステリシスなし(差0dBで即切替)の場合

AP-Aを−68dBm、AP-Bを−67dBmで受信している境界席を想定します。人の移動や扉の開閉、什器の反射(マルチパス)の影響で、RSSIは静止していても常時±3〜5dB程度揺れます。すると両APの優劣が数秒ごとに逆転し、そのたびに切替が発動――これがAP間フラッピングの正体です。

ヒステリシス8dBの場合

同じ席でも、AP-Bが「AP-Aより8dB以上強い」状態(例:A=−72dBm、B=−64dBm)にならない限り切り替えません。±5dB程度の揺らぎでは逆転条件に届かず、接続は安定します。

実務上の目安

一般的な実装・設定の標準レンジは 5〜10dB 前後
小さすぎると揺らぎに負けてフラッピング
大きすぎる(目安として12dB超)と、今度は劣化したAPを掴み続けるスティッキークライアント問題に転化し、「繋がっているのに遅い」症状になります。実際、macOSの12dBという比較的大きい判定値と−75dBmという低いトリガー値の組み合わせは、「Macは想定よりも長く元のAPに留まる」挙動としてApple自身がドキュメントで注意喚起しています(出典2)
多くの実装は信号差に加えて時間条件(逆転状態が数秒継続したら切替、など)も併用します

ポイントは、ヒステリシスがフラッピングとスティッキーのトレードオフ調整弁だということです。片方を潰すともう片方が顔を出すため、「どちらの症状のほうがビジネス影響が大きいか」で寄せる方向を決めます。インフラ側(無線コントローラのローミング閾値やクライアントステアリング設定)で調整できる製品もありますが、まずはデフォルト値で運用し、ログでフラッピング端末を特定してから動かすのが安全です。

4. ローミング積極性 ― クライアント側で調整できる数少ないパラメータ

ヒステリシスやトリガー閾値の多くはOS・ドライバに埋め込まれていてユーザーは触れませんが、Windows + Intel無線アダプタという最も普及した組み合わせには、調整可能な「ローミングの積極性(Roaming Aggressiveness)」設定があります。

Intelアダプタの設定(遭遇頻度が最も高い)

デバイスマネージャー → Wi-Fiアダプタのプロパティ → 詳細設定タブにあり、5段階(最低/中低/中/中高/最高)で調整します(出典3)。

設定値	挙動
1. 最低(Lowest)	現在のAPの信号が著しく劣化するまでスキャン・切替しない
3. 中(Medium)	デフォルトかつIntel推奨値。信号と品質のバランスで判断
5. 最高(Highest)	わずかでも良い候補があれば積極的にスキャン・切替

なおIntelによれば、この判断は単純な受信強度(dBm)だけでなく、送受信レート・パケットロス率・信号劣化などを加味した品質指標ベースのアルゴリズムで行われます(出典4)。「○dBになったら必ず切り替わる」という単純な動きではない点は押さえておきましょう。

推奨値は「症状」で分岐する

フラッピング(頻繁な切替)が問題 → 「1〜2」に下げる。境界エリアの固定席PCで効果が出やすい
逆にスティッキー(掴んだまま離さない)が問題 → 「4〜5」に上げる。倉庫のハンディターミナルや移動カートのPCなど、動き回る端末向け
全社一律変更は避け、まず問題端末で検証するのが鉄則です。企業展開する場合は、PowerShellの Set-NetAdapterAdvancedProperty(レジストリキーワード RoamAggressiveness)でキッティング時に配布できます(出典5)

その他のプラットフォーム

Apple(macOS/iOS):ユーザー設定不可。前述の公表値(トリガー −70/−75dBm、判定差分)が固定の前提条件になります
Android:メーカー依存で原則設定不可

つまり、クライアント側で調整できない端末が多数派です。ここから導かれる結論は明快で、フラッピング対策の本丸はクライアント設定ではなく、インフラ側のセル設計にあります。

5. セル設計 ― AP間距離と電波強度の考え方

基準は「距離」ではなく「セル境界の受信強度」

設計の出発点を「APを何メートル間隔で置くか」にしてはいけません。電波の届き方は建材・遮蔽物・天井高で大きく変わるためです。正しい順序は、先にセル境界(セルエッジ)の信号強度目標を決め、それを満たす配置を実測で求めること。

セル境界の目標値

音声・リアルタイム通信を収容する無線LANの設計値として広く参照されているのが、Ciscoの設計ガイドラインです。セル境界で −67dBm 以上、SNR(信号対雑音比)25dB以上、パケットエラー率1%以下、セル重複15〜20%(2.4GHzは20%)が推奨されています(出典6、7)。SNR 25dBという数字は、典型的なノイズフロア −92dBm に対して −67dBm の信号を確保すると成立する関係です(出典7)。

用途	セル境界のプライマリAP受信強度	SNR
データ用途のみ	−70dBm以上	20dB以上
VoIP / Web会議 / VDI	−67dBm以上	25dB以上
高密度・高スループット	−65dBm以上	25dB以上

−67dBmという目標値には、ローミングの観点からも意味があります。iPhone/iPadのスキャン開始しきい値(−70dBm)より手前で次のAPが用意されている状態を作る、ということです。Apple自身も「−67dBmのセル重複で設計されたネットワーク」を設計例として挙げています(出典1)。

セカンダリAP(隣接AP)の考え方

ローミングを成立させるには、セル境界に立ったとき:

プライマリAPが −67dBm 以上で受信でき、かつ
次の候補(セカンダリ)APも −67〜−70dBm 程度で受信できること

つまり「どの地点でも2台のAPが実用強度で見える」状態が理想です。これがないと、ローミング先が見つからず瞬断が長引きます。一方で3台以上が強い電波で拮抗すると、今度は候補が多すぎて切替判断が迷走し、フラッピングや同一チャネル干渉を誘発します。「2台は見える、3台目は弱い」が黄金バランスです。

距離の目安(あくまで初期配置の仮置きとして)

一般的なオフィス(石膏ボード間仕切り、5GHz、出力控えめ)で AP間隔12〜18m 程度が出発点
遮蔽の少ないオープンフロアなら15〜20m、会議室密集エリアや高密度収容なら10〜12mまで詰める
最終決定は必ずサイトサーベイの実測ヒートマップで行います。図面上の等間隔配置と実際の電波分布は、ほぼ確実に一致しません

送信出力の設計 ― 「最大出力」が事故のもと

セル境界の目標値を「APの送信出力を最大にして」達成してはいけません。理由は2つあります。

クライアントとの出力非対称:スマートフォンの送信出力はAPの最大出力より小さいことが多く、出力差が大きいと「APの声は届くがクライアントの声が返らない」片方向リンクが生まれます。Ciscoのサーベイガイドラインでも、APの送信出力をクライアント端末が出せる出力に合わせるよう明記されています(出典7)。足りなければ出力を上げるのではなく、APを増やすのが正解です。
セルの過剰重複:出力を上げるほどセルが重なり、境界で複数APが拮抗するフラッピング地帯と同一チャネル干渉(CCI)を広げます。同一チャネルの隣接APは十分弱く(一般的な設計目安として−75dBm以下、音声設計ではさらに厳格な分離が理想とされます)しか聞こえない配置が望まれます(出典6)。

また、2.4GHzは5GHzより減衰しにくいため、同一出力では2.4GHzのセルだけ肥大化し、バンド間フラッピングの温床になります。2.4GHzは5GHzより出力を一段(目安6dB程度)下げる、高密度配置では一部APの2.4GHz無線を無効化する、といった調整が定石です。

6. コラム:「両方のAPが強ければフラッピングは起きない」は本当か

第2章の2段階モデルから、「両APとも強電界なら、スキャン自体が走らないのでヒステリシスは関係なく、フラッピングも起きないのでは?」という推論が成り立ちます。これは概ね正しいのですが、実務では4つの例外があります。

ローミング積極性が高い端末は第1段階を飛ばす:Intel設定の「最高」付近は、しきい値を待たず頻繁なスキャン+相対比較で動く挙動に近くなり、強電界でもヒステリシス判定が常時働きます
RSSI以外のトリガー:再送率の急増・ビーコンロスなど品質劣化でスキャンを起動する実装があります。強電界でも干渉やAP過負荷で品質は落ちるため、「−55dBmなのにローミング」は実際に起きます(IntelのアルゴリズムがRSSIだけでなく品質指標を見るのは前述のとおり。出典4)
インフラ側からの強制移動:802.11vによる移動指示、ロードバランシング等のステアリング機能は、クライアントの都合と無関係に「移れ」と指示します。強電界ゾーンは複数APから見えるため、むしろステアリング起因のフラッピングの主戦場になりえます
DFSによるチャネル退避:後述

ここから、受信強度帯で原因系統を切り分けるという実践的な診断視点が得られます。

強電界(−60dBm以上)なのに切替が頻発 → RSSI起因ではない。積極性設定・ステアリング/負荷分散・品質劣化(干渉)・DFSを疑う
−70dBm前後で切替が頻発 → 教科書どおりのRSSIフラッピング。セル設計とヒステリシスの問題

ログに残るRSSI値とフラッピング発生の相関を見るだけで、調査の方向が大きく絞れます。

7. 見落とされがちな日本特有の要因:DFS

5GHz帯のうち W53(52〜64ch)とW56(100〜140ch) は気象レーダー・航空レーダー等と周波数を共用しており、APはレーダー波を検出するとそのチャネルの使用をやめて退避することが義務付けられています(DFS:Dynamic Frequency Selection)。新チャネルでは利用可否の確認(CAC)に最短60秒かかるため、機種によっては1分前後の全クライアント切断が発生します(出典8)。

重要なのは、これが珍しい事象ではないことです。IIJのエンジニアによる都内オフィスでの実測でも、外来レーダー波によるDFSとチャネル移動は無線LAN運用上の現実的な懸念として観測・報告されています(出典9)。「信号強度は十分なのに、不定期に全員まとめて切れる」という症状はDFSの典型で、フラッピングと誤認されやすいパターンです。

対策は、影響が許容できない場合はW52(36〜48ch)中心のチャネル設計にする、またはレーダー検出時の切断を緩和する機能(各社のFast DFS/Zero-Wait DFS等)を持つAPを採用することです。ただしW52は4チャネルしかなく混雑しやすいため、AP台数が多い環境ではチャネル再利用設計(=前章のセル設計)とセットで検討する必要があります。

8. 診断の進め方 ― ログ → スペクトラム → サーベイの順で

フラッピングの診断は、安価な手順から順に潰していくのが効率的です。

Step 1:ログでパターンを特定する

AP・無線コントローラのログで、切断(Deauth)と再接続(Reassociation)の頻度・Reason Codeを確認します。「特定クライアントだけか」「特定エリアか」「特定時間帯か」で原因系統が大きく絞れます。あわせて発生時のRSSI値を記録すれば、第6章の「受信強度帯による切り分け」が適用できます。

Step 2:スペクトラムアナライザで非Wi-Fi干渉を排除する

電子レンジ・Bluetooth・コードレス電話・監視カメラなどの非Wi-Fi干渉源は、断続的にSNRを悪化させてクライアントの再スキャンを誘発しますが、SSID一覧を表示するだけのツールには一切映りません。物理層(電波そのもの)を可視化するスペクトラムアナライザが必要です。

PCのUSBポートに挿して使える OSCIUM WiPry シリーズなら、2.4/5GHz帯の電波占有状況をリアルタイム表示でき、「Wi-Fi以外の何かが帯域を埋めている」状況を数分で確認できます。より本格的な調査には AirMagnet Spectrum XT のような専用ツールで干渉源の種類の自動分類まで行う方法もあります。

Step 3:サイトサーベイでセル境界を可視化する

AirMagnet Survey 等のサーベイツールでフロアを歩いて実測ヒートマップを作成し、複数APのRSSIが拮抗するエリア(2台以上が−65〜−70dBmで並ぶゾーン)を特定します。フラッピング多発地点とこのゾーンは、ほぼ一致するはずです。Ciscoのサーベイガイドラインでも、−67dBm境界とSNR 25dBの検証手段としてAirMagnet Surveyによるヒートマップ分析が紹介されています(出典7)。

Step 4:(必要に応じて)パケットキャプチャ

Probe Requestの頻度や再アソシエーションの間隔を見れば、「クライアントが迷っている」様子を定量的に確認できます。

9. 対策の優先順位

ここまでの内容を、実施すべき順に並べます。

送信出力を下げてセルの過剰重複を削減する(最大出力運用の見直し。クライアント出力との対称性を確保)
最低データレートを引き上げる(2.4GHzの1/2Mbpsを無効化)。低速レートで遠くまで「つながってしまう」状態をなくし、セル境界を事実上引き締めて、クライアントの切替判断を早める
2.4GHz帯の整理(5GHzより出力を下げる/高密度エリアでは一部APの2.4GHzを無効化)でバンド間フラッピングを抑制
クライアント側ローミング積極性の調整(症状が特定機種・特定席に偏る場合の個別対応)
DFSが疑われる場合はW52中心のチャネル設計、またはDFS対策機能つきAPの採用
802.11k/v/r(ローミング支援・高速ローミング)はクライアント世代の対応状況を確認のうえ段階導入。古い端末と802.11rの組み合わせは認証ループの定番原因です

まとめると、3つの要素は独立ではなく連動しています。セル設計で「2台が−67dBmで見える境界」を作り、ヒステリシス(5〜10dB相当の判定マージン)で揺らぎを吸収し、それでも残る問題端末だけローミング積極性で個別調整する――この順序が、インフラ側から潰していく王道です。

そして、セル境界の実態は図面上では決して分かりません。実測こそが設計の起点です。スペクトラムアナライザとサーベイツールという「電波を見る道具」を一度導入しておくと、フラッピングに限らず、無線トラブル全般の調査時間が桁違いに短くなります。機種選定にお悩みの際は、TokyoWireless(wi-t.com ) までお気軽にご相談ください。

出典一覧

Apple「Wi-Fi roaming support in Apple devices」(Appleサポート) — iPhone/iPad のローミングトリガー −70dBm、Mac −75dBm、−67dBmセル重複の設計例 https://support.apple.com/en-us/HT203068
Apple「macOS wireless roaming for enterprise customers」(Appleサポート) — macOSのトリガー閾値 −75dBm、802.11k非対応時の候補選択基準 +12dB https://support.apple.com/HT206207
Intel「Wi-Fi Roaming Aggressiveness Setting」 — 5段階設定の挙動と推奨値(Medium) https://www.intel.com/content/www/us/en/support/articles/000005546/wireless.html
Intel Community(公式サポート回答)「Roaming aggressiveness and Signal strength」 — 判定がdBm単独でなく品質指標ベースである旨 https://community.intel.com/t5/Wireless/Roaming-aggressiveness-and-Signal-strength/td-p/462734
Microsoft Learn「Roaming aggressiveness」関連Q&A — PowerShellによる RoamAggressiveness の設定方法 https://learn.microsoft.com/en-us/answers/questions/3183375/roaming-aggressiveness-doesnt-change-anything
Cisco「Enterprise Mobility Design Guide — VoWLAN Design Recommendations」 — セル境界 −67dBm、SNR 25dB、PER 1%、セル重複の推奨値 https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Mobility/emob41dg/emob41dg-wrapper/ch9_Voic.html
Cisco「Understand Site Survey Guidelines for WLAN Deployment」 — −67dBm/SNR 25dB/ノイズフロア −92dBm、AP出力をクライアントに合わせる設計、AirMagnet Surveyによる検証手順 https://www.cisco.com/c/en/us/support/docs/wireless/5500-series-wireless-controllers/116057-site-survey-guidelines-wlan-00.html
ヤマハ「Fast DFS機能」(WLX313 技術資料) — W53/W56でのレーダー検出時のチャネル変更義務と60秒の確認時間 https://www.rtpro.yamaha.co.jp/AP/docs/wlx313/fastdfs.html
IIJ Engineers Blog「IIJ飯田橋オフィスでDFSはどれくらいおきているのか?」 — オフィス環境におけるDFS発生の実測 https://eng-blog.iij.ad.jp/archives/4972

※受信強度・SNR等の数値は設計上の一般的な目安であり、実際の最適値は環境(建材・干渉状況・収容端末)によって変わります。導入・変更の前に必ず実環境での測定・検証を行ってください。