こんにちは。ITインフラチームのH.K.です。
皆さまのオフィスでは、Web会議中に映像が固まったり、Wi-Fiが不安定になったりすることはありませんか？
今回は、私たちがオフィスで直面した課題についてご報告します。それは「Zoom利用時の途切れ」や「Wi-Fiの不安定さ」です。この課題に対し、どのように調査・改善を行ったのか、そのプロセスと結果をご紹介します。
はじめに：今回のWi-Fi改善までに取り組んできたこと
ことの発端は、社員から「Zoom会議中に途切れる」という声が多数寄せられたことでした。
本社オフィスでは、ほとんどの業務がWi-Fi接続で行われています。Zoomの利用頻度も非常に高い状況です。お客様との大切な会議が中断することは、業務に大きな支障をきたしていました。
過去、Zoomの音声や映像が途切れる解決策として以下の施策を実施してきました。
・ルーター、回線の増設：特定の通信（ZoomのLBOやAzure）を迂回させ、システム遅延を解消しました。
調査の結果、特定の通信が経路に集中していると判明しました。具体的には、ZoomやAzureなどの通信です。そこで、このボトルネックを解消し、システム遅延を改善するために別の回線とルーターの増設、LBO（Local Break Out：ローカルブレイクアウト）を実施しました。
・全社員のPC交換：最新機種（VAIO）への交換で、社員の体感速度や操作性が向上しました。
ネットワーク環境とは別に、PC自体の性能不足も課題でした。 経年による性能低下が、体感速度を損なう一因となっていたのです。このため、ネットワークの問題とは別に、PC環境そのものを改善し、社員がより快適に操作できる状態を目指しました。
以上の対策により、もともと1日あたりの平均切断数が5件だったところ、4.2件へ減少しました。
そこで私たちは、平均4.2件をさらに減らすべく、オフィス全体の電波環境を改善することにしました。より快適で安定した業務環境を実現するため、専門的な調査に基づく改善プロジェクトを開始しました。
調査で明らかになった複数の問題点
詳細な電波調査と分析の結果、以下の問題点が明らかになりました。
周辺の電波環境と技術的な問題
- Co-Channel Interference (CCI) の発生
ArubaのARM (Adaptive Radio Management) による動的なチャネル調整は機能していましたが、高速化を目的とした「80MHz幅チャネルボンディング(複数のWi-Fiチャネルを1つに束ねて通信速度を向上させる技術)」により使用可能なチャネルが枯渇。結果的に、隣接するAP間で同一チャネルが選択され、CCI（同一チャネル干渉）が多発していました 。 - 過剰なセルオーバーラップとスティッキー端末問題
APの送信出力が最大値に設定されており、本来は分離すべきAPのセル（電波範囲）どうしが広範囲で重なっていました 。これにより、クライアント端末が最適なAPに切り替わらず、遠くのAPに接続し続ける「スティッキー端末問題」や、前述のCCIをさらに助長していました。 - 許容値を超えるチャネル使用率（Duty Cycle）
Duty Cycle調査の結果、特に利用者が密集するエリアの5GHz帯でチャネル使用率が常時60%を超える時間帯が確認されました 。これは高密度Wi-Fi環境における推奨値（30～40%）を大幅に上回り、通信遅延の直接的な原因となっていました 。 - Band Steeringの機能不全
端末を5GHz帯へ誘導する「Band Steering」が「優先（Prefer 5GHz）」モードで動作していましたが、2.4GHz帯の電波強度が強いエリアでは、クライアント端末が混雑しがちな低速の2.4GHz帯を選択してしまうケースが散見されました 。
ここで、「なぜこのような設定でこれまで運用できていたのか？」という疑問が浮かぶかもしれません。いくつかの理由があります。
【補足】では、なぜ以前の設定で問題なかったのか？
- 「エリア確保」の優先 構築当初の目的は、電波の「品質」よりも「執務エリアの隅々まで電波を届けること」が最優先でした。そのため、「強すぎる電波」や「電波の重なり」は、むしろ接続が安定している証拠と見なされ、問題視されていませんでした。
- パフォーマンス悪化の指標を測定していなかったため 初期調査では電波の「強さ」は測っていましたが、電波の「混雑度（Duty Cycle）」までは測定していませんでした。当時は利用者が少なく、高負荷な業務も多くなかったため、潜在的な問題が表面化していなかったのです。
- 「速度」を優先し、高密度環境への配慮が不足していたため 1台あたりの最高速度を上げるため、「80MHz幅チャネル（チャネルボンディング）」を設定していました。しかしこの設定は、多くのAPが密集する高密度環境において干渉リスクを高めるものであり、導入当初はその可能性が十分に認識されていませんでした。
- 不調の原因：「外部」への思い込み 問題が発生した際、その原因はモバイルルーターなど「外部からの電波干渉」にあると推測されがちでした。そのため、自分たちのAP設定に起因する「内部干渉」の可能性が見過ごされていました。
これらの設定は「間違い」ではなく、AP導入当初の利用状況や目的に対しては最適だったのです。しかし、利用者の増加やWeb会議の急増といった環境の変化により、見直しが必要な時期を迎えていました。
私たちが実施した改善策
これらの問題に対し、私たちは以下の改善策を順次実施しました。
- Band Steering機能のモード変更
デュアルバンド対応クライアントを意図通り5GHz帯へ接続させるため、Band Steering機能を「Force 5GHz」モードへ設定しました 。
- SSIDごとの利用周波数帯の制御
特定のSSID（RaceAP2〜RaceAP4）において、2.4GHz帯の電波を無効化し、5GHz帯専用のSSIDとして運用するよう変更しました 。 - チャネルボンディングの無効化
高密度環境におけるチャネル干渉を抑制するため、チャネルボンディングを無効化しました。具体的には「80MHz幅サポート」を無効にし、ArubaのARM機能が選択するチャネルを20MHz幅に限定しました 。
これらの設定変更により、APの使用チャネルは適切に分散されました。結果として、電波干渉が大幅に低減されたことを確認しています。
まとめ：改善はまだ道半ば
今回の改善ポイントは「チャネルボンディングを無効化したこと」と「基本的なチャネル幅（20MHz幅）に限定したこと」の2点です。
これにより、AP1台あたりの通信速度の上限は下がります。しかし、オフィス全体の通信は格段に安定したと考えています。実際に、今回の設定変更で平均切断数は50％以上（日平均が4.2件から1.9件）改善され、Zoom以外の遅延に関する報告もありません。
もちろん、これで終わりではありません。今後、より高い通信速度が必要になった際の対応も検討しています。再度チャネル幅を広げることや、APの設置場所を含めたセルサイズの調整も視野に入れています。 私たちの「改善」はこれからも続いていきます。今回の取り組みが、皆さまの業務効率と生産性向上に少しでも貢献できれば幸いです。
レイスシステムソリューションズ株式会社のソフトウェア開発や、
採用に関するお問い合わせについては、下記のリンクにてお問い合わせください。