はじめに
こんにちは、コーポレートシステム部の正木です。コーポレートエンジニアとして社内システムやインフラに関連する設計・開発・運用を担当しています。
まずは部門について簡単に紹介します。私が所属するのはコーポレートシステム部という部門で、いわゆる情報システム部門（情シス）です。部のミッションとして掲げているのが「EXをシンプルにする」というものです。EXとはEmployee Experience（従業員体験）を指し、従業員が働く上での体験価値を高めることを目指しています。
前回の記事では「ネットワーク運用、まだ手動ですか？SansanがMeraki API × AIで定義する次世代の運用スタイル」というテーマで、API・LLMを活用した運用自動化についてお話ししました。今回は、オフィスネットワークの診断と改善にどのように向き合っているかを紹介します。ネットワークエンジニアとしての経験を軸にしながら、Sansanのコーポレートエンジニアとしてどのようにネットワーク品質の維持・改善に取り組んでいるか、その裏側をお伝えします。
本記事が、NWエンジニアとしてキャリアの幅を広げたい方や、事業会社の情シスでの取り組みに興味がある方にとって、少しでも参考になれば幸いです。
1.オフィスネットワークの「あるある課題」
2.原因を読むための診断指標
「つながってるのに遅い」：RSSIとSNR
「特定エリアだけ遅い」：チャネルと干渉
「突然Wi-Fiが切れる」：DFS
「ピーク時だけ遅い」：AP使用率とクライアント数
3.Sansanでの見方：ツールと仕組み
Merakiダッシュボード
チャネル使用率の時系列蓄積（Meraki API × Notion）
Ekahauによる電波サーベイの「定期運用」
4.改善アクション：データをもとに何をするか
日常的な最適化：RFプロファイルの調整
抜本的な対策：AP増設・再配置と6GHz帯への誘導
1.オフィスネットワークの「あるある課題」
「会議室に入ったら急にWi-Fiが遅くなった」「特定のフロアだけつながりが悪い」「朝のピーク時だけ重い」「突然Wi-Fiが切れる」——
オフィスを持つ会社の情シスやネットワーク管理者なら、こうしたSOSを一度は受けたことがあるはずです。Sansanも例外ではありません。
無線LANの電波は目に見えないため、トラブルシューティングが難航しがちです。よくあるのが、「とりあえずAPを再起動する」「むやみにAPを増やす」といった対症療法です。しかし、無計画なAP増設は電波干渉を悪化させ、かえって逆効果になることもあります。「なんとなく」の対応では根本解決には至りません。症状の裏にある原因を特定し、データに基づいてアプローチすることが不可欠です。
2.原因を読むための診断指標
症状ごとに確認すべき指標は異なります。ここでは、よくある症状ごとに「何が起きているか」「何を見るべきか」「どう対策するか」を整理しました。
- RSSI（受信信号強度）：端末が受け取る電波の強さ。これが低いと「電波が弱い」状態になります。
- SNR（信号対雑音比）：ノイズ（雑音）に対して、本来の信号がどれくらいクリアに届いているかの割合。
- ローミング：移動しながら通信する際、接続するAP（アクセスポイント）を自動で切り替える仕組み。
- チャネル：Wi-Fiの電波が通る「道路」のようなもの。同じ道路が混むと通信が遅くなります。
- DFS（動的周波数選択）：気象レーダーなどの電波を検知した際、干渉を避けるためにAPが自動でチャネルを切り替える仕組み。切り替え中は一時的に電波が止まります。
「つながってるのに遅い」：RSSIとSNR
- 発生事象：扇マークは立っているのに通信が遅い、動画や音声が途切れる。
- 起きていること：RSSI不足、またはSNRの悪化。移動後も遠いAPを掴んだまま（スティッキー・クライアント）で、ローミングが追いついていないケースも多い。
- よくある原因：APの送信出力が高すぎて端末が適切なAPへ切り替わらない、チャネルの住み分けが悪いなど。
- 見る指標：RSSI・SNR、接続先AP、クライアント健全性、RFヘルス。
- 対策の方向：RFプロファイル（送信出力・受信閾値）とチャネル設計の見直し。
壁の材質やAPとの距離によって値は変わります。「つながっているのに再送が増えている」状態は、数値を見ないと見落としがちです。
「特定エリアだけ遅い」：チャネルと干渉
- 発生事象：特定のフロアやゾーンだけ遅い、混雑時に品質が落ちる。
- 起きていること：同一チャネル上で複数の通信が重なり、順番待ちが発生している（同一チャネル干渉）。
- よくある原因：自社AP同士や近隣オフィスのWi-Fiとのチャネル重複。通信速度を上げようとチャネル幅を広げすぎたことによる干渉の増幅。
- 見る指標：チャネル使用率、干渉のサーベイ（Ekahau等）。
- 対策の方向：チャネル計画の見直し、チャネル幅の縮小、Auto/固定の運用判断。
Wi-Fiは「チャネル」と呼ばれる周波数帯を使って通信します。Sansanが入居する渋谷サクラステージのような高層ビルや複数テナントが入るオフィスでは、近隣からの干渉は無視できない課題です。
「突然Wi-Fiが切れる」：DFS
- 発生事象：突然Wi-Fiが切れる、一瞬だけ断線する。
- 起きていること：5GHz帯でDFSが起動し、APがチャネルを切り替える準備の間、電波が一時停止する。
- よくある原因：気象レーダー等の検知に伴うチャネル変更。
- 見る指標：イベントログでのDFSイベント、どのチャネルでDFSが多いかの集計。
- 対策の方向：問題の起きやすい周波数帯を避けたチャネル設計、他帯の併用（6GHz等）。
5GHz帯のDFSは、気象レーダーなど特定の電波を検知した際、干渉を避けるためにAPが自動的にチャネルを切り替える仕組みです。切り替え中はAPが一時的に電波を停止するため、「通信が途切れる」という形でユーザーに体感されます。
2026年4月時点では、MerakiのダッシュボードにはDFS専用のアラート機能がありません。そのため、SansanではSplunkでMerakiのイベントログを収集し、DFSイベント発生時にSlackへ自動通知する仕組みを構築しています。さらに「どのチャネルでDFSが多いか」を分析し、安定したチャネル設計に生かしています。
「ピーク時だけ遅い」：AP使用率とクライアント数
- 発生事象：朝や特定時間帯だけ遅い、イベント時だけ重い。
- 起きていること：チャネル使用率が高い、1台のAPにクライアントが集中している。
- よくある原因：席の集中、会議の偏り、古い規格の端末が多く接続される（レガシー端末が通信帯域を占有してしまう）問題。
- 見る指標：APの使用率、クライアント数、Meraki上の負荷。
- 対策の方向：APの増設・再配置、6GHz帯への誘導、RF調整。
弊社のオフィスでも、「窓際の席に人が集中する」「特定スペースでの大人数の会議で特定のAPに負荷が偏る」といったことが頻繁に起きます。1台あたりのクライアント数が多すぎると通信が渋滞し、APの使用率が跳ね上がります。
3.Sansanでの見方：ツールと仕組み
Sansanでは、Terraformを用いたIaC（Infrastructure as Code）や、Splunkへのログ集約による高度なダッシュボード化、さらには過去の記事で紹介したようなAPIを活用した自動化ツールなど、様々な内製ツールを駆使してネットワークを運用しています。
今回はその中でも、「現場の課題を診断・可視化する」という目的に絞って、私たちが普段どのようにツールを使い分けているか紹介します。役割分担は以下の通りシンプルです。
- Merakiダッシュボード：「今」の状態を把握する（初動の切り分け）
- Meraki API × Notion：「過去からの時系列」を追う（長期トレンドの分析）
- Ekahau：「現場の電波状況」を可視化する（定期サーベイ）
Merakiダッシュボード
Sansanのネットワーク基盤はCisco Merakiで統一されており、APやスイッチの状態はクラウド管理画面から一元的に確認できます。Meraki Assuranceのネットワークヘルススコアを見れば、クライアントやインフラの状態が数値でわかるため、ユーザー申告があった際の「全体傾向か、局所的な問題か」の初動切り分けに重宝しています。
チャネル使用率の時系列蓄積（Meraki API × Notion）
ダッシュボードは「今」を見るのには適していますが、「先週の特定時間帯に何が起きたか」といった長期トレンドを追うのには限界があります。
そこで私たちは、Meraki APIで各フロアのチャネル使用率（5GHz/6GHz）を定期取得し、Notionデータベースへ自動蓄積しています。これにより、「なんとなく良くなった」ではなく「数値として10%改善した」などと定量的に説明できるようになり、AP増設やレイアウト変更の判断にも明確なエビデンスを持てるようになりました。
APIや運用自動化の考え方そのものは、前回の記事「ネットワーク運用、まだ手動ですか？SansanがMeraki API × AIで定義する次世代の運用スタイル」でも詳しく紹介しています。
Ekahauによる電波サーベイの「定期運用」
「数値上は正常なのに、特定の場所だけ遅い」といった課題を可視化するため、Ekahauを使った電波サーベイを定期的に実施しています。
直近のサーベイ結果では、過去の改善施策（チャネル設定の変更など）がヒートマップ上で明確な効果として表れ、5GHz帯の干渉が大幅に減少していることが確認できました。また、6GHz帯についても、高密度環境下で安定して機能していることが実証されています。
このように「前回と比べてどう変わったか」を数値と図で確認できることは、自分たちの改善アクションの手ごたえにつながると同時に、次の施策を打つための強力な根拠となっています。
4.改善アクション：データをもとに何をするか
診断で見えてきた課題に対して、私たちは「コスト（手間や影響範囲）が低く、効果が高いもの」を日常的なチューニングとして回しつつ、それでも解決しない構造的な問題に対しては抜本的な対策を打つ、というアプローチをとっています。
日常的な最適化：RFプロファイルの調整
私たちが何度も設計・修正・サーベイを繰り返して最適化しているのが、MerakiのRFプロファイルによる設定チューニングです。現場で手を入れることが多いのは、大きく分けて次の2点です。
- 電波の調整：エリアごとに送信出力や受信感度の閾値を調整し、ローミングやカバレッジを最適化する。
- チャネルの設計：隣接APで同一チャネルを避けるよう設計し、干渉を抑える。必要に応じて一時的なチャネル固定も活用する。
たとえば、高密度な執務エリアではあえてAPの送信出力を絞り、RX-SOP（受信感度の閾値）を調整する打ち手があります。これにより、遠くのAPに繋がってしまうスティッキー・クライアントを防ぎ、チャネルの住み分けを改善できます。逆に、広い会議室やカフェスペースではカバレッジを優先して出力を上げる場合もあります。「デフォルト設定のまま運用していないか」——この見直しだけで劇的に改善するケースは意外と多いです。
抜本的な対策：AP増設・再配置と6GHz帯への誘導
RF調整を繰り返しても埋められない電波の谷や、特定APへの集中負荷（キャパシティ不足）が明らかな場合は、より大きなカードを切ります。
物理的なテコ入れ（AP増設・再配置）
過去のサーベイ結果やダッシュボードの負荷状況をもとに、APの増設や再配置を実施したこともあります。本来であれば増設前にEkahau Pro等のシミュレーション機能でカバレッジを予測したいところですが、現状は一度もシミュレーションを実行できていません。この「事前シミュレーションの確立」は、今後の私たちの課題の一つです。
アーキテクチャの変更（6GHz帯への誘導）
5GHz帯の混雑が構造的に解消しづらい場合は、6GHz帯（Wi-Fi 6E）への誘導を抜本策として実施しました。6GHz帯はDFSの制約がなく、利用可能なチャネル数も多いため、5GHz帯の混雑緩和にも直結します。
本社への導入や、MDMから手動接続へ切り替えた経緯については、過去記事「6GHz SSID導入への挑戦：高密度オフィスWi-Fiの混雑をどう解消したか」で詳しく紹介しています。
本記事について
本記事に記載の内容は、Sansanにおける独自の調査・社内検証に基づく事例や一般論です。すべての環境に当てはまる正確な手順書ではありません。特にRX-SOPなどの調整は専門的な知識を要するため、設定変更はCisco Merakiなどの公式ドキュメントを確認のうえ、組織の承認と自己責任のもとで慎重に行ってください。
おわりに
今回は、オフィスネットワークの診断と改善について、「よくある課題」「診断指標」「Sansanでの見方」「改善アクション」という流れで紹介しました。
前回の記事でお話ししたような「APIやAIを活用した自動化」といった先進的な話題に目が向きがちですが、その土台にあるのは「定期的なサーベイ」「データの蓄積」「現場で実際に測る」という地道な姿勢です。
Splunkでの傾向分析や、Ekahauでの定期サーベイ、Meraki APIを用いた時系列データの蓄積。こうした泥臭い積み重ねがあるからこそ、「なんとなく快適」ではなく「データに基づいて快適」なネットワーク環境を提供でき、さらにその先の「高度な自動化」へとつながっていくと考えています。
Sansanのコーポレートシステム部では、ネットワークの深い知識を軸にしながら、プログラミングやデータ分析など新しい技術領域にも越境し、自らの手で環境を創り上げていく面白さがあります。こうした「データに基づく泥臭い運用」と「先進的な自動化」の両輪に共感していただけた方、あるいはネットワークエンジニアとして「もう一歩先のキャリア」に挑戦したい方は、ぜひ一度カジュアルにお話ししましょう。
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
