ネットワーク運用、まだ手動ですか？SansanがMeraki API × AIで定義する次世代の運用スタイル

はじめに

こんにちは、コーポレートシステム部の正木です。コーポレートエンジニアとして社内システムやインフラに関連する設計・開発・運用を担当しています。

はじめに部門について簡単に紹介させていただきます。私が所属するのはコーポレートシステム部という部門で、いわゆる情報システム部門（情シス）です。部のミッションとして掲げているのが「EXをシンプルにする」というものです。EXとはEmployee Experience（従業員体験）のことです。

前回の記事では「6GHz SSID導入への挑戦：高密度オフィスWi-Fiの混雑をどう解消したか」というテーマで、本社における最新規格の導入と電波品質改善のプロセスについてお話ししました。

今回は、それらのネットワーク基盤を「いかに安定させ、効率的に運用しているか」という運用の舞台裏にスポットを当ててご紹介します。

現代のネットワークエンジニアには、従来のConfigやネットワークプロトコルの知識に加えて、API連携やツール開発などの開発スキル、そしてAI/LLMを活用した運用自動化まで、幅広いスキルセットが求められる時代になっています。私たちのチームでも、そうした技術トレンドを積極的に取り入れながら運用の進化に取り組んでいます。

具体的には、標準機能だけでは届かない課題を解決するために自作した内製ツールや、LLMを活用したトラブルシューティングの自動化、そして拠点への横展開について触れていきます。

ネットワークエンジニアとしての経験を軸にしながら、Sansanのコーポレートエンジニアとしてどのように「攻守」のバランスを持って技術に向き合っているか、その一端をお伝えできればと思います。

本記事が、ネットワークエンジニアとしてキャリアの幅を広げたい方や、最新技術を用いた運用自動化に興味がある方にとって、少しでも参考になれば幸いです。

基本の運用：Merakiの活用

Sansanのネットワーク基盤は、基本的にCisco Meraki製品で統一されています。本社だけでも膨大な数のアクセスポイント（AP）やスイッチが稼働していますが、これらをクラウド上のシングルダッシュボードで一元管理できる点は、やはり運用者として非常に大きなメリットです。

具体的には、以下のような標準機能をフル活用して日々の安定稼働を支えています。

電波・チャネル設計の最適化:管理画面から各フロアの混雑状況を俯瞰し、動的なチャネル割り当てや出力調整をリアルタイムに実行。
直感的なトラブルシューティング:クライアントごとの接続状況、パケットロス、信号強度の推移がタイムラインで可視化されるため、一次切り分けのスピードが格段に向上。
ネットワークヘルススコアによる可視化:Meraki Assuranceでは、ネットワーク全体の健康状態をスコア化し、クライアント、ネットワークデバイス、インフラの接続性の状態を一覧で確認できます。

上記の画面では、ネットワークヘルススコアが100/100で「良好」と表示されています。このスコアは、クライアント（ワイヤレス・有線・リモート）、ネットワークデバイス（アクセスポイント・スイッチ・セキュリティアプライアンス）、インフラの接続性（LAN・WAN・VPN・RF）の全てを包括した総合評価です。スコアの下では、それぞれのカテゴリごとの詳細な状態を確認でき、特にRF（電波）のスコアは無線LAN環境の品質を把握する上で日常的に最も活用している機能の一つです。問題が発生している箇所を素早く特定できるため、運用効率が大幅に向上しています。

このように、Merakiの標準機能だけでも非常に高度な運用が可能ですが、多くの接続デバイスを抱える高密度な環境においては、標準機能だけでは解決しきれない「もう少し踏み込んだ可視化」や「定型作業の自動化」が求められる場面が増えてきました。

内製ツール開発

Merakiは非常に優れた製品ですが、大規模かつ高密度なオフィス運用を突き詰めると、標準の管理画面だけでは解決が難しい課題に直面することがあります。そこで私たちは、Meraki APIを活用した自作ツールの開発に取り組んでいます。

ユースケース①：チャネル使用率の可視化とデータ蓄積による改善

前回のブログで紹介した通り、私たちは「6GHz帯の導入」という技術的なアプローチで混雑解消に挑みました。しかし、運用フェーズではさらに一歩踏み込み、「なぜそのフロア、その時間帯で通信品質が低下したのか」を定量的に分析する必要がありました。

課題：リアルタイム性の限界と分析の難しさ

Merakiのダッシュボードでもチャネル使用率は確認できますが、表示されるのは主に「今、この瞬間」のデータです。過去に遡って複数のAPの状態を横断的に分析したり、一時的なスパイク（突出した混雑）を特定したりするには、データの蓄積が不可欠でした。

事業会社の情シス（ネットワーク）でよくある課題として、定量化されたデータが取りづらく、メンテナンスや設定変更を実施しても「本当に改善されたのか」という判断がつきにくいという点があります。私たちも以前は同様の課題を抱えていましたが、今回紹介する仕組みにより、定量的なデータに基づいた判断が可能になりました。

対策：API × Notion DBによるモニタリング基盤の構築

そこで、各フロアの5GHz/6GHz帯のチャネル使用率をMeraki API経由で定期取得し、Notionデータベースへ自動蓄積する仕組みを構築しました。単にデータを蓄積するだけでなく、設定した閾値を超過した場合にはSlackへアラート通知を飛ばす実装も行っています。

チャネル使用率の平均値（5GHz/6GHz）

チャネル使用率の閾値超過回数（5GHz）

実例：6GHz帯の仕様変更に伴うトラブルの早期検知

このツールが真価を発揮したのが、6GHz帯の仕様変更に伴うトラブルでした。国内でもまだ導入事例が少ない6GHz帯ですが、運用中にMeraki側の仕様変更により、自動チャネル割り当て（Auto Channel）の挙動が変わる事象が発生しました。具体的には、利用可能な多数のチャネルがあるにもかかわらず、特定のPSC（Preferred Scanning Channels）帯にのみ割り当てが偏ってしまい、結果として5GHz帯よりも混雑するという状況に陥ったのです。

通常であればユーザー申告があるまで気づきにくい変化ですが、蓄積していたデータのアラート検知により早期に異常を把握できました。結果、Merakiサポートへの迅速な問い合わせと、手動チャネル割り当てによる対策を即座に打つことができました。

現在は数字ベースの管理ですが、今後はこれらをオフィスレイアウト（マップ）上にマッピングし、視覚的に混雑状況を把握できる「ヒートマップの自動生成」も計画しています。

ユースケース②：Meraki API × Dify × LLM による「アラート調査bot」の内製

ネットワーク運用において、アラート検知後の「初動」は非常に重要です。しかし、アラートが発生するたびにダッシュボードを開き、複数のログを突き合わせ、原因を推測するという作業は、相応の経験値と時間を要します。

課題：トラブルシューティングの属人化と初動のコスト

Merakiからアラートが飛んできた際、ダッシュボード上で「イベントログの確認」「クライアントの接続状況」「周囲の電波干渉」など、確認すべき項目が多岐にわたります。これらを網羅的に判断する作業は定型的になりがちですが、人間が手作業で行うとどうしても初動に数分〜数十分のロスが発生していました。

対策：Difyを活用したトラブルシューティングの自動化

この課題を解決するため、Meraki APIとDifyを組み合わせた「アラート調査bot」を開発しました。

Difyは、LLM（大規模言語モデル）を活用したアプリケーション開発プラットフォームです。ワークフローを視覚的に構築でき、外部APIとの連携やナレッジベースの活用、複数のLLMを使った処理のオーケストレーションなどが可能です。今回のbotでは、Meraki APIから取得した情報をDify上でLLMに分析させ、過去の事例やマニュアルと照らし合わせて調査結果を生成しています。

仕組みの概要：

アラート検知:Merakiのアラートをトリガーにシステムが起動。
情報収集:Meraki APIを通じて、対象機器のイベントログやステータス情報を自動で取得。
LLMによる分析:取得したログの内容をLLMに読み込ませ、Dify上で構成したナレッジ（過去の事例やマニュアル）と照らし合わせて分析。「何が起きているか」「推奨される対策は何か」を要約。
Slack通知:調査結果をSlackに即座に投稿。

Difyの調査ワークフロー

上記のワークフローに従い、アラート発生からSlack通知まで自動で処理されます。実際の出力例は以下の通りです。

調査botの返答例

もちろん、最終的な判断や設定変更は人間が行いますが、「ネットワークのどこで、何が原因で、まず何をすべきか」がSlackを見た瞬間に把握できるため、調査の初動を大幅に短縮できました。

これまで「定型的ながらも職人芸」になりがちだったネットワークトラブルの切り分けにAIを取り入れることで、運用の平準化とスピードアップを両立させています。

実践：拠点への横展開（関西オフィスなど）

本社移転や自動化ツール開発で得られた知見は、決して本社だけのものに留めません。現在、私たちは関西拠点をはじめとする各拠点へ、最新のネットワーク基準を順次横展開しています。

本社の知見を拠点へ

まずは、本社で安定稼働の実績を作った6GHz帯（Wi-Fi6E）の環境を関西拠点にも導入しました。拠点は本社に比べてスペースやAPの数が限られますが、最新規格によるクリーンな通信環境を提供することで、拠点間のWeb会議の品質向上や業務効率化を図っています。

地道ながら効果絶大な「QoS」の適用

また、6GHz帯の導入に合わせて全拠点でのQoS（Quality of Service）設定の最適化も実施しました。特に、拠点によっては回線帯域が本社ほど太くないケースもあり、ビデオ会議（VoIP）のパケットがデータ通信に押し潰されてしまう課題がありました。音声・ビデオ通信の優先度を適切に制御することで、ネットワークの混雑時でも途切れない、ストレスフリーなコミュニケーション基盤を全社レベルで実現しています。

Ekahauによる現場主導の品質改善

さらに、今後の取り組みとして重視しているのが、無線サーベイツールEkahauを用いた継続的な改善です。全拠点で現状の電波状況の可視化（サーベイ）を完了しています。現在はそのデータをもとに、電波の死角や混雑しているチャンネルやエリアの特定、各拠点の特性（壁の材質やレイアウト）に合わせたAP配置の最適化やリプレイスといった具体的な対策案の検討を進めていく予定です。

本社で確立した「データに基づいた設計・運用」のサイクルを各拠点に持ち込むことで、どこにいても快適なネットワーク環境を目指しています。

おわりに

今回のブログでは、Sansanのネットワーク運用における「標準機能の活用」「内製ツールによる拡張」「拠点への展開」という3つの切り口でお話ししました。

ネットワークエンジニアのキャリアは、ともすれば「インフラを構築して終わり」になりがちです。しかし、事業会社のコーポレートエンジニアという立場であれば、今回ご紹介したようなAPIやLLMを活用した自動化、そして現場の課題をダイレクトに解決する仕組みづくりまで、自らの手で領域を広げていくことができます。

現状に満足せず、新しい技術を泥臭く、かつスマートに使い倒して、最高の従業員体験（EX）を一緒に作り上げていける仲間を募集しています。

「ネットワークのスキルを武器に、もっと広い世界へ挑戦してみたい」「Sansanのネットワークチームがどんな雰囲気か、もう少し詳しく聞いてみたい」

そう感じていただけたなら、ぜひ一度カジュアルにお話ししましょう。あなたの挑戦を、心よりお待ちしています。