Merakiの情報を確認したいときに、ダッシュボードへのログインを手間に感じていませんか？

あるいは、作業手順書とMerakiのデバイス情報を行き来するのに手間を感じていませんか？

私たちはMeraki専用のMCP（Model Context Protocol）サーバーを開発し、日常の確認作業の多くをダッシュボードなしで完結させることを目指しました。

はじめに

こんにちは、Sansan株式会社コーポレートシステム部末次です。コーポレートシステム部は、いわゆる情報システム部門にあたります。

部のミッションとして掲げているのが「EX（従業員体験）をシンプルにする」というものです。その中で私たちは、社内インフラの効率化と自動化を推進しています。今回は、ネットワーク管理のためのCisco Merakiの情報取得を、ClaudeなどのAIツールから効率的に行うMCP（Model Context Protocol）サーバーの開発についてお伝えします。

OpenAPIを元にMCPサーバーを構築した方法、Cursorのみでの開発体験、および実際の活用事例までを紹介します。

背景と課題

Merakiでの情報取得の現状

Cisco Merakiは、クラウドベースのネットワーク管理プラットフォームです。スイッチ、ワイヤレスアクセスポイント、セキュリティアプライアンスなどのデバイスを一元管理できる強力なツールですが、私たちがネットワーク品質を求めて運用業務を行っていく中では、情報取得に課題がありました。

現在、ネットワークの状態確認やデバイス情報の取得は、Merakiダッシュボードにログインして手動で確認する必要があります。また、APIを使用する場合でも、都度APIリクエストを構築し、レスポンスを解析する必要がありました。このため、以下のような課題がありました。

情報取得の非効率性: ネットワークの状態確認やトラブルシューティングの際に、複数の画面を行き来する必要がある
API利用の複雑さ: 各エンドポイントの仕様を理解し、適切なリクエストを構築する必要がある
AIアシスタントとの連携不足: ClaudeやCursorなどのAIツールから直接Merakiの情報にアクセスできない

解決策の検討

現在、MerakiダッシュボードにはMeraki AIアシスタントが用意されており、仕様や自社環境に合わせて自然言語で回答してくれます。これはこれで非常に便利で、Merakiサポートに問い合わせする代わりに一旦AIアシスタントに聞いてみる、などの使い方では非常に有効です。

一方で、他のMCP（NotionやGitHubなど）と組み合わせられないことや、利用のたびにダッシュボードにログインする必要があるといった制約があり、より利便性の高い形でMerakiの情報をAIを通して得たいというニーズが出てきました。

そういった背景からMCPサーバーの開発を検討し始めました。MCPは、AIアシスタントが外部システムと連携するためのプロトコルで、Claude DesktopやCursorなどのAIツールから利用できます。Meraki向けのリモートMCPサーバーは公式には提供されておらず、コミュニティで作成されたものも限定的であったため、独自のMCPサーバーを開発することに至りました。

概念実証（PoC）のアプローチ

CursorとOpenAPI仕様を活用した実装

MCPサーバーの開発にあたり、まずは実現可能性とコストが課題となります。ネットワークエンジニアとしてインフラ運用の定常的な業務に取り組む我々には、開発スキルもなければ、開発にかける時間もありませんでした。

そのため私たちは、Cursorを使ったAIバイブコーディング、OpenAPI仕様を活用した自動生成で開発を進めていきました。開発はAIに頼りつつ、Merakiが公式に提供しているOpenAPI仕様を活用することで、私たちでも現実的に、そして素早く実装できると考えました。

実装のアプローチ

実装は以下のステップで進めました。開発はCursorでのバイブコーディングで、コーディングからデバッグまで一貫して行いました。

OpenAPI仕様の取得: Meraki公式のOpenAPI仕様を取得
FastMCPによる自動生成: OpenAPI仕様を読み込んでMCPツールを自動生成
セキュリティ設定: 読み取り専用（GETメソッドのみ）に制限
カスタマイズ: 日本語タグの追加や説明文の改善

FastMCPによる自動生成

FastMCPは、OpenAPI仕様から自動的にMCPツールを生成する機能を提供しています。これにより、以下のメリットが得られました。

開発時間の短縮: 手動で各エンドポイントを実装する必要がなく、OpenAPI仕様を読み込むだけで自動生成される
保守性の向上: Meraki APIが更新された場合、OpenAPI仕様を更新するだけで対応できる
一貫性の確保: すべてのエンドポイントが同じパターンで実装されるため、一貫性が保たれる

プロトタイプの実装結果

実現できたこと

バイブコーディングにてまずプロトタイプが完成し、以下のような構成を実現できました。

AIアシスタント

(Claude / Cursor)

MCP Protocol

Meraki MCP Server

(FastMCP)

HTTP / HTTPS

Meraki API

(api.meraki.com)

約50個のMCPツール（ホワイトリスト方式）

当初はOpenAPI仕様の全GETエンドポイントをそのままMCPツールとして公開していましたが、ツール数が多すぎてAIツールの応答が遅くなることが判明しました。他MCP（GitHubなど）とCursor上で同時利用する際にも負荷がかかっていたため、ホワイトリスト方式に切り替え、日常運用に必要な約50個に厳選しました。

Meraki APIのOpenAPI仕様には数百のGETエンドポイントが含まれますが、以下の理由から必要なエンドポイントのみを許可しています。

ツールを減らしたりまとめたりする方法は他にもあると思いますが、なるべくOpenAPIをそのまま利用し、必要なエンドポイントの追加・削除をしやすい形にしました。

主なカテゴリとツール数は以下の通りです：

カテゴリ	件数	主な内容
管理者	1個	自分の情報
組織	11個	組織一覧、ネットワーク一覧、デバイス一覧、クライアント検索、VPN状態、アラート
ネットワーク	10個	ネットワーク詳細、クライアント一覧、イベント、アラート履歴、ヘルスアラート
デバイス	5個	デバイス詳細、LLDP/CDP、管理IF、接続統計
ワイヤレス	7個	SSID一覧、FWルール、RF設定、接続統計
スイッチ	9個	ポート一覧・状態、ルーティング、スタック、STP
アプライアンス	9個	FWルール、VLAN、VPN、アップリンク、HA、DHCP

主要コンポーネント

OpenAPI仕様読み込み: meraki-openapi.jsonからOpenAPI仕様を読み込み
認証付きHTTPクライアント: Meraki APIキーをX-Cisco-Meraki-API-Keyヘッダで送信
FastMCPサーバー: OpenAPI仕様から自動生成されたMCPツールを提供
ルートマッピング: ホワイトリスト方式で約50個のエンドポイントのみ許可（GETメソッドに限定）
レート制限ミドルウェア: Meraki APIの制限（5リクエスト/秒/組織）に合わせてRateLimitingMiddlewareを適用

実装のポイント

ホワイトリストはroute_mapsで実現しています。FastMCPのRouteMapで、許可するエンドポイントのパス（正規表現）をひとつずつ列挙し、最後にMCPType.EXCLUDEで「上記以外は全て除外」と指定します。エンドポイントの追加や削除は、get_custom_route_maps()内のRouteMapの追加・削除だけで行えます。

# OpenAPI仕様から自動生成（ホワイトリスト方式）
mcp = FastMCP.from_openapi(
    openapi_spec=openapi_spec,
    client=client,
    name="meraki",
    timeout=60.0,  # クライアント検索など時間がかかるAPIに対応
    tags={"meraki", "cisco", "api-v1"},
    route_maps=get_custom_route_maps(),  # 許可するGETエンドポイントのみ列挙、それ以外はEXCLUDE
    mcp_component_fn=customize_components,  # 日本語タグ追加、output_schema無効化
)

# Meraki APIのレート制限（5 req/sec）に対応
mcp.add_middleware(
    RateLimitingMiddleware(max_requests_per_second=5.0, burst_capacity=5)
)

ホワイトリストの例（get_custom_route_maps()の一部）:

RouteMap(methods=["GET"], pattern=r"/administered/identities/me$", mcp_type=MCPType.TOOL),
RouteMap(methods=["GET"], pattern=r"/organizations$", mcp_type=MCPType.TOOL),
RouteMap(methods=["GET"], pattern=r"/organizations/\{organizationId\}/networks$", mcp_type=MCPType.TOOL),
RouteMap(methods=["GET"], pattern=r"/organizations/\{organizationId\}/devices$", mcp_type=MCPType.TOOL),
RouteMap(methods=["GET"], pattern=r"/organizations/\{organizationId\}/clients/search$", mcp_type=MCPType.TOOL),
RouteMap(methods=["GET"], pattern=r"/networks/\{networkId\}$", mcp_type=MCPType.TOOL),
RouteMap(methods=["GET"], pattern=r"/networks/\{networkId\}/devices$", mcp_type=MCPType.TOOL),
# ... 他にもスイッチ・ワイヤレス・アプライアンス等を同様に列挙 ...
RouteMap(methods=["GET"], pattern=r"/networks/\{networkId\}/appliance/vlans$", mcp_type=MCPType.TOOL),
RouteMap(methods=["GET"], pattern=r"/networks/\{networkId\}/appliance/vpn/siteToSiteVpn$", mcp_type=MCPType.TOOL),
# 最後に上記以外を全て除外
RouteMap(methods=["GET", "POST", "PUT", "DELETE", "PATCH"], pattern=r".*", mcp_type=MCPType.EXCLUDE),

動作検証

実装後、以下の動作検証を行いました。

基本的な情報取得: 組織一覧、ネットワーク一覧の取得が正常に動作することを確認
デバイス情報の取得: 各種デバイス情報の取得が正常に動作することを確認
AIツールとの連携: Claude DesktopとCursorから正常に利用できることを確認
エラーハンドリング: APIキーが設定されていない場合や、無効なリクエストの場合のエラーハンドリングを確認

活用事例

プロトタイプを本番運用に移行した後、以下のような活用を進めてきました。

💡 現時点では読み取り専用（GETのみ）として設計しています。
また、AIが取得した情報は判断の材料として活用しつつ、最終判断は人が行う運用にしています。

1.自然言語による情報検索

「〇〇ネットワークのオフラインになっているデバイスを教えて」「この組織のVPNサイト間接続の状態は？」といった問いかけに対して、AIアシスタントが適切なMCPツールを選択し、Meraki APIを呼び出して結果を返します。

また特に便利なのが、作業後に「デバイスがオフラインになっていないか」「VPN接続が正常か」「異常なログが出ていないか」といった作業後の正常性確認も、同じく自然言語で依頼でき、情報取得と事後確認をまとめて行ってくれます。

作業時にかかっていた正常性確認に関しては、月4時間（1時間×4回） → MCP活用後 月40分（10分×4回）となり、約83%の工数削減に成功しています。

2.ネットワーク構成図の作成・検証

全国各地の拠点およびWAN全体（AutoVPN）のネットワーク構成図を、MCPツールを活用して作成・維持できるようにしました。

データ形式と構成要素:
構成データはtopology.jsonとして管理し、ノード（Internet、PE Router、MX、スイッチ、APなど）とリンク（WAN、uplink、trunk、access）を階層ごとに定義します。各拠点のMeraki Network名に合わせたフォルダに、topology.jsonと可視化用のnetwork-diagram.htmlを配置し、ドキュメントとして共有しています。

活用する主なツール:

getDeviceLldpCdp: スイッチ・MX間の接続先デバイスとポート番号を取得
getDeviceSwitchPorts / getDeviceSwitchPortsStatuses: ポート設定とリンク速度を確認
getNetworks / getNetworkDevices: ネットワークとデバイス一覧を取得

ワークフロー:

Cursor等のIDEから「〇〇拠点の構成図を作成して」と自然言語で依頼、MCPが実機のLLDP/CDPの情報を取得
取得したLLDP/CDPデータをもとに、実接続に基づいたtopology.jsonを作成
HTMLテンプレートで構成図を可視化し、ドキュメントとして共有

構築時に構成図を作成することが多いので、構築後に作成することができる本機能の活用は限定的ですが、新人のオンボーディングやさっと情報を視覚的に確認したいときに有効です。またdraw.io MCPも登場してきているので、より見栄えのいい形式などは模索中です。

構成図の工夫:

レイヤごとの色分け・階層管理: Internet、PE Router、MX、スイッチ、APなどをレイヤごとに色分けし、縦方向に階層を並べることで、ネットワーク構成を一覧で把握しやすくしています。
VLAN情報を枠外にリスト表示: 構成図本体をシンプルに保つため、VLAN一覧は図の外に別リストとして表示。必要なときに参照できるようにしています。
マウスオーバーで機器詳細を表示: 各ノードにマウスカーソルを乗せると、モデル名、IPアドレス、シリアル番号などの詳細情報がポップアップで表示され、構成図を見ながら機器情報を確認できます。

3.作業手順書の自動化（Meraki MCP × Notion MCP × Claude）

Meraki MCPとNotion MCPをClaudeに同時接続することで、Merakiから取得した情報をベースにNotionへ手順やドキュメントを自動で反映できます。例えば、デバイス一覧やポート設定をMeraki MCPで取得し、その結果を解釈したうえで「〇〇拠点のデバイス導入手順」「スイッチ設定変更のチェックリスト」などをNotionページとして作成・更新するといった活用が可能です。インフラ運用の作業手順書を、常に最新のMeraki情報に合わせてメンテナンスできるようになります。

各作業準備について、月12時間（1.5時間×8回） → MCP活用後 月3時間（0.5時間×8回）（約75%削減 / 月9時間削減）の工数削減に成功しています。

4.SlackからのMeraki情報取得（Meraki MCP Slack Agent）

更にAIツールだけでなく、メインで業務利用しているSlackからMeraki MCPを呼び出すべく、Amazon Bedrock AgentCoreを利用し、Slack上の@メンションを起点にMerakiの情報取得を行えるBotを構築しました。Slackで自然言語の依頼を投げると、BotがMeraki APIを呼び出し、同一スレッドに結果を返信します。

全体アーキテクチャ

Slack: app_mention を受けて、同一スレッドへ応答する
Lambda: from_slack: Event受信、challenge/リトライ対応、即時メッセージ投稿、処理用Lambdaを非同期起動
Lambda: Processing: 認可チェック、AgentCore Runtime呼び出し、ストリーム応答のパース、Slackへの結果投稿
AgentCore: Slack Agent（Strands Agent）: 依頼文を解釈し、Meraki MCPのツールを選択して実行
AgentCore: Meraki MCP（FastMCP Server）:Meraki APIをMCPツール化（読み取り専用、50 endpoints）

運用フロー（処理の流れ）

SlackでBotを@メンションして依頼文を送信
from_slackが受信し、即時に「🔍 Merakiを調べています…」を投稿
Processingを非同期起動（Slackには200を即時返却）
ProcessingがAgentCore Runtimeにpromptとcontextを送信
Slack AgentがMeraki MCPを呼び出して処理し、ストリーミングで応答
Processingが同一スレッドに結果を投稿

導入効果

実際に運用してみると、Slack上で「確認だけ」が完結できるようになり、Merakiのダッシュボードを開かずに済む場面が増えました。また、依頼と結果が同じスレッド上に残るため、判断材料を文脈ごと追えるようになりました。結果として、調査に入る前の情報収集が速くなり、問い合わせの一次対応としても使えるようになりました。

開発を通じて得られた知見と考察

運用業務での活用（精度とスピード）

運用業務では「いま必要な情報」を素早く取りにいく場面が多いのですが、Meraki MCPを使うことで、自然言語で依頼するだけで必要な情報にたどり着けるようになりました。ダッシュボードで画面遷移しながら探す時間が減り、確認から判断までのリードタイムが短くなったことで、日々の運用業務がかなり楽になりました。

Cursorによる開発の実感

実装をCursorのみで行ったことで、インフラ担当でもMCPサーバー開発に着手しやすい環境があると実感しました。FastMCPやRouteMapの仕様を都度確認しながら、AIと対話する形でコーディングを進められ、時間制約のある中でも実装まで到達できました。

他MCPとの連携が差別化になる

Meraki AIアシスタントにはできない、Notion MCPとの組み合わせによる作業手順書の自動化や、構成図作成時のLLDP/CDP取得といった活用が進んでいます。MCPサーバーとして切り出すことで、利用シーンを自由に組み合わせられる利点が明確になりました。

読み取り専用で十分なニーズがある

構成図作成、情報検索、正常性確認、Notionへのドキュメント反映といった実際の活用を見ると、現時点では読み取り専用の設計で十分ニーズを満たせています。セキュリティを保ちつつ、書き込みが本当に必要になった段階で権限管理などを検討する方針で問題ないと確認できました。

今後の展望

AIを活用したインフラ運用の変革

今回の取り組みを通じて、AIを活用したインフラ運用の可能性を実感しました。構成図作成やポート管理といった活用が進む一方、以下のような展開を検討しています。

AIエージェントと複数サービスの統合

現在、Meraki以外にもEntra Intune、Jamf Pro、OktaなどのMCPサーバーを開発しています。これらを統合してAIエージェントが自律的に複数のサービスから情報を取得し、より包括的な分析や提案ができるようにしていきたいと思っています。

さらなるツールの拡張

現在は読み取り専用ですが、将来的にはネットワーク設定の自動化、トラブルシューティングの自動化、レポート生成、構成図の定期更新などを検討しています。活用事例で触れた情報検索・構成図作成・手順書メンテナンスの効率化は、すでに実感できる段階にあります。

おわりに

ネットワーク運用では「状況を早く把握して、判断材料を揃える」ことが重要ですが、MCPサーバーとして情報取得を切り出すことで、日常の確認作業の多くをダッシュボードなしで素早く回せる場面が増えました。

このように、今は自分たちでやりたいことを実現できてしまう時代です。逆に言えば果敢にチャレンジを繰り返していかないとすぐに置いていかれてしまいます。私たちは今後も果敢にチャレンジしていきたいと思います。

この記事を読んで、私たちの取り組みに少しでも共感していただけたなら、ぜひ一度カジュアルにお話ししませんか？チームや業務内容、今後の展望について、ざっくばらんにご紹介できれば嬉しいです。
最後までお読みいただき、ありがとうございました。

Sansan技術本部ではカジュアル面談を実施しています

Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。

※ 本記事で紹介した実装は、セキュリティ上の理由から一部の情報を伏せています。実際の実装では、適切な認証・認可機能を実装し、セキュリティベストプラクティスに従ってください。

Sansan Tech Blog

Sansanのものづくりを支えるメンバーの技術やデザイン、プロダクトマネジメントの情報を発信

Merakiダッシュボードを開かないネットワーク運用を目指してーMCPサーバー自作と活用事例

はじめに

背景と課題

Merakiでの情報取得の現状

解決策の検討

概念実証（PoC）のアプローチ

CursorとOpenAPI仕様を活用した実装

実装のアプローチ

FastMCPによる自動生成

プロトタイプの実装結果

実現できたこと

約50個のMCPツール（ホワイトリスト方式）

主要コンポーネント

実装のポイント

動作検証

活用事例

1.自然言語による情報検索

2.ネットワーク構成図の作成・検証

3.作業手順書の自動化（Meraki MCP × Notion MCP × Claude）

4.SlackからのMeraki情報取得（Meraki MCP Slack Agent）

全体アーキテクチャ

運用フロー（処理の流れ）

導入効果

開発を通じて得られた知見と考察

運用業務での活用（精度とスピード）

Cursorによる開発の実感

他MCPとの連携が差別化になる

読み取り専用で十分なニーズがある

今後の展望

AIを活用したインフラ運用の変革

AIエージェントと複数サービスの統合

さらなるツールの拡張

おわりに

Sansan技術本部ではカジュアル面談を実施しています