本ページは広告が含まれています。気になる広告をクリック頂けますと、サーバ運営費になります(^^
イベントで、319〜320台のスマートフォンが同時接続した結果、Wi-Fiが事実上パンク状態に陥りました。接続自体はできているのに、テキスト送信もアプリ通話もまともに動かない——そんな症状の原因を、TP-Link Omada ソフトウェアコントローラのログから特定した調査記録です。
同様のイベント運営をされている方や、Omada Controller の使い方を知りたい方の参考になれば幸いです。
- 目次
- 1. 問題の概要
- 2. 調査の進め方（ログを見る順番）
- 3. Step 1：まず「Events」ログで異常イベントを確認する
- 4. Step 2：「Dashboard」でトラフィックとAP密度を把握する
- 5. Step 3：「Reports → Wireless → Retry&Drop」で通信品質の劣化を数値化する
- 6. Step 4：「Reports → Wireless → 5GHz フィルタ」で帯域集中を確認する
- 7. Step 5：「Devices → Config → Wireless」で設定の根本問題を確認する
- 8. Step 6：「Dashboard → Channel Utilization」でチャンネルの偏りを目視する
- 9. 考察：なぜこうなったのか
- 10. 対策まとめ
目次
- 問題の概要
- 調査の進め方（ログを見る順番）
- Step 1：まず「Events」ログで異常イベントを確認する
- Step 2：「Dashboard」でトラフィックとAP密度を把握する
- Step 3：「Reports → Wireless → Retry&Drop」で通信品質の劣化を数値化する
- Step 4：「Reports → Wireless → 5GHz フィルタ」で帯域集中を確認する
- Step 5：「Devices → Config → Wireless」で設定の根本問題を確認する
- Step 6：「Dashboard → Channel Utilization」でチャンネルの偏りを目視する
- 考察：なぜこうなったのか
- 対策まとめ
1. 問題の概要
イベント会場（複数フロア）に9台のAP（TP-Link EAP683 / EAP613）を設置し、来場者向けに FreeWifi を提供していました。イベント当日、ピーク時に319〜320台のスマートフォンが同時接続したところ、以下の症状が発生しました。
- Wi-Fiへの接続自体は成功している
- テキストメッセージの送受信が極めて遅い、または失敗する
- アプリの音声・ビデオ通話が途切れる・繋がらない
- 一部の端末は突然接続が切れ、再接続できなくなる
後述のログ調査により、根本原因は以下の3点であることが判明しました。
- 5GHz帯のチャンネル幅が 160MHz に設定されていた（使えるチャンネルが実質1本になる）
- DFS チャンネルを使用していた（レーダー検知により強制チャンネル変更が発生）
- 送信電力が最大値（21dBm）のままだった（遠距離の電波品質の低い端末まで拾ってしまう）
2. 調査の進め方（ログを見る順番）
Omada Controller には複数のログ・統計画面があります。やみくもに見ても時間がかかるため、以下の順番で確認すると効率よく原因にたどり着けます。
- Logs → Events（異常イベントを最初に確認）
- Dashboard → Wi-Fi Activity（全体のトラフィックと接続数の流れを把握）
- Insights → Reports → Wireless → Retry&Drop（通信品質の劣化を数値で確認）
- Insights → Reports → Wireless → 5GHz フィルタ（帯域集中を確認）
- Devices → AP → Config → Wireless → 5GHz（設定値を確認）
- Dashboard → Channel Utilization（チャンネルの偏りを目視確認）
3. Step 1：まず「Events」ログで異常イベントを確認する
操作手順
左メニュー「Logs」→ 上部タブ「Events」をクリック。
確認ポイント
イベント一覧が新しい順に表示されます。以下の種類のイベントが記録されていないか確認します。
- EAP Detected Radar：DFS チャンネルで気象レーダーを検知（チャンネル強制変更の直前に記録される）
- EAP Channel Changed：チャンネルが強制変更された（この間、接続端末は一時的に切断される）
- Device Disconnected：AP 本体がコントローラーから切断された
- Device Reconnected：AP が再接続した（Disconnected の後に記録）
実際に記録されていたログ
| イベント種別 | 内容 | 日時 |
|---|---|---|
| EAP Detected Radar | 2階西イベントホール detected radar on channel 52 | Jun 08, 2026 08:13:12 am |
| EAP Channel Changed | 2階西イベントホール changed 5GHz channel from 52 to 36 | Jun 08, 2026 08:13:12 am |
| Device Disconnected | 会議ルーム１ was disconnected | Jun 08, 2026 06:14:58 am |
| Device Reconnected | 会議ルーム１ was reconnected in 7 minutes | Jun 08, 2026 06:17:22 am |
「EAP Detected Radar → EAP Channel Changed」の連続ログが最大の発見でした。DFS チャンネル（ch52 など）で気象レーダーが検知されると、APは使用中のチャンネルを強制的に変更します。切り替え中の最大60秒間、そのAPに接続していた端末はすべて通信不能になります。大規模イベントでこれが発生すると、一気に数十台が切れることになります。
4. Step 2：「Dashboard」でトラフィックとAP密度を把握する
操作手順
左メニュー「Dashboard」→「Overview」タブ（デフォルト）。
確認ポイント①：Wi-Fi Activity グラフ
ページ中央の「Wi-Fi Activity」グラフは、時系列でトラフィック量（Mbps）と接続台数を表示しています。ピーク時間帯（グラフが最も高い山になっている時間）がイベントのピークと一致しているか確認します。今回のケースでは、午前10時〜午後2時にかけてトラフィックが 470〜588 Mbps まで急上昇し、接続台数も300台近くに達していることが視覚的に確認できました。
確認ポイント②：AP Density グラフ
同ページをスクロールすると「AP Density」グラフがあります。これは各APが「どの電波強度範囲で何台の端末を拾っているか」を示します。多数のAPアイコンが -80〜-60dBm の範囲に集中しており、コントローラー自身が 「AP deployment density might need improvement（APの配置密度に改善が必要）」 と警告を出していました。電波強度が最大値のため、遠方の端末まで拾いすぎていることがこの警告から読み取れます。
5. Step 3：「Reports → Wireless → Retry&Drop」で通信品質の劣化を数値化する
操作手順
左メニュー「Insights」→「Reports」→ 上部タブ「Wireless」→ ページをスクロールして「Top 5 APs」セクション →「Retry&Drop」タブをクリック。
確認ポイント
Retry（再送率）と Drop（パケット廃棄率）が AP ごとに表示されます。Retry が 10% を超えると輻輳のサイン、20% 以上は重篤な状態です。
実際のデータ
| AP名 | Retry率 | Drop率 |
|---|---|---|
| 2F中央イベントホール | 30% | 16% |
| 2階東イベントホール | 26% | 12% |
| 2階西イベントホール | 23% | 14% |
| 2F中央2イベントホール | 13% | 6% |
| 会議ルーム１ | 5% | 0% |
2F中央イベントホール の Retry 30%・Drop 16% は深刻な状態です。送信した10パケットのうち3パケットは再送が必要で、さらに1.6パケットはそのまま廃棄されていることを意味します。テキスト送信やアプリ通話が失敗するのは、まさにこのドロップが原因です。
6. Step 4：「Reports → Wireless → 5GHz フィルタ」で帯域集中を確認する
操作手順
「Insights」→「Reports」→「Wireless」タブ → 上部の「5 GHz」ボタンをクリック。
確認ポイント
5GHz 帯だけのトラフィック量と Top 5 APs のクライアント数が表示されます。全体のワイヤレストラフィック 100.52GB のうち、5GHz だけで 43.41GB を占めており、さらにページをスクロールすると Top 5 SSIDs に「FreeWifi：トラフィック 98%・クライアント 22台」と表示されていました。
また Top 5 APs の「Traffic&Client」タブでは、2F中央イベントホール が単独で Client Number 68 台を抱えていることが確認でき、1台の AP に 68台が集中している異常な状態が数値で裏付けられました。
7. Step 5：「Devices → Config → Wireless」で設定の根本問題を確認する
操作手順
左メニュー「Devices」→ 上部タブ「APs (9)」→ 対象 AP の行をクリック → 右側パネル「Manage Device」→ 上部タブ「Config」→ 左サブメニュー「Wireless」→「5 GHz」タブをクリック。
実際の設定値（2F中央イベントホール を例に）
| 設定項目 | 現在の値 | 問題点 |
|---|---|---|
| Channel Width | 160 MHz | 5GHz で使えるチャンネルが実質1本になる |
| Channel | 36 / 5180MHz | 全 AP が ch36 に集中するリスク |
| Tx Power (EIRP) | 21 dBm（最大値） | 遠方の低品質端末まで拾い、帯域を圧迫する |
160MHz 設定の問題を詳しく説明します。5GHz 帯（日本の W52/W53/W56）で 160MHz 幅を確保するには、連続した 160MHz の空き周波数が必要です。しかし現実には W52（ch36〜64）と W56（ch100〜140）を合わせても連続 160MHz が取れる組み合わせは非常に限られており、結果として全 AP が事実上 1チャンネルに押し込まれます。300台が 1本の「車線」に詰まったのはこれが理由です。
8. Step 6：「Dashboard → Channel Utilization」でチャンネルの偏りを目視する
操作手順
左メニュー「Dashboard」→ ページ下部にスクロールすると「Channel Utilization」グラフが表示されます。
確認ポイント
2.4GHz 帯と 5GHz 帯のチャンネル使用状況がバーグラフで表示されます。緑色が「Good（良好）」、橙色が「Fair（普通）」、赤色が「High（高負荷）」を示します。今回の確認では、5GHz 側で ch36 のみがほぼ全 AP に使用されており、他のチャンネルがほとんど空いている状態が目視できました。これが「1本の車線」状態の視覚的証拠です。
9. 考察：なぜこうなったのか
今回の障害は、複数の設定ミスが重なったことで引き起こされた「複合障害」でした。それぞれの問題がどう絡み合っていたかを整理します。
①「160MHz設定」が引き起こした帯域の一本化
160MHz のチャンネル幅は、理論上は最大通信速度を引き上げます。しかしそれは「端末が1〜2台しかいない環境」での話です。多数の端末が同時接続する環境では、AP が使えるチャンネルが実質1本になるため、すべての通信が同じ周波数で順番待ちをすることになります。高速道路を1車線しか使えない状態で300台の車を捌こうとしているようなものです。
②「DFSチャンネル」が引き起こした突然の全員切断
DFS（Dynamic Frequency Selection）は、気象レーダーと電波が干渉しないよう、レーダーを検知したら即座にチャンネルを変更する仕組みです。切り替え中（最大60秒）はそのAPへの接続がすべて切断されます。今回は ch52 で実際にレーダーが検知され（「EAP Detected Radar」ログ）、ch36 に強制変更されています（「EAP Channel Changed」ログ）。この「突然の切断」が、接続できない端末を多数発生させた直接原因のひとつです。
③「最大送信電力」が引き起こした低品質接続の蓄積
送信電力を最大（21dBm）にすると、APは会場の端（電波が届きにくい遠い場所）にいる端末まで拾います。しかし遠距離の端末は電波品質が低いため（Signal値が -80dBm 以下など）、少ないデータを送るのにも多くの送信時間を消費します。これが近距離の端末の通信にも影響し、全体の「待ち行列」を長くします。AP Density グラフで -80dBm 以下のゾーンにも端末が集まっていた事実がこれを裏付けています。
結論
「速くなるはず」という意図で設定された 160MHz・最大送信電力が、多数同時接続という条件下では逆に全員の通信を遅くする結果になりました。大規模イベントのWi-Fi設計では、個々の端末の最大速度より「全員が最低限通信できること」を優先した設定が必要です。
10. 対策まとめ
| 問題 | 現在の設定 | 推奨設定 |
|---|---|---|
| チャンネル幅が広すぎる | 160 MHz | 40MHz または 80MHz（イベント時は40MHzを推奨） |
| DFSチャンネル使用 | ch52 など W53/W56 チャンネル | W52（ch36/40/44/48）のみ使用（DFS非対象） |
| 送信電力が最大 | 21 dBm（最大値） | 14〜17 dBm 程度に引き下げ（AP間で分散させる） |
| 接続台数の集中 | 1APに68台 | Band Steering・クライアント数制限を有効化（1APあたり30〜40台を目安に） |
なお、上記設定変更は Devices → Manage Device → Config → Wireless、またはサイト全体に一括適用したい場合は Device Config → AP Config → Radio Settings から変更できます。イベント前日に設定を変更し、当日は Logs → Events と Dashboard → Wi-Fi Activity をリアルタイムで監視することをお勧めします。
本記事はTP-Link Omada Controller（ソフトウェアコントローラ）の実際の管理画面をもとに作成しました。画面構成はファームウェアバージョンにより異なる場合があります。
