本記事は、新設部署のインフラ出身エンジニアと新人エンジニアのチームによる、現場での知見習得の記録として執筆しています。Agentic AIにまつわる周辺キーワードの解説から実際の構築環境・検証結果の紹介まで、導入前提を一つずつ確かめながら進めた足跡を共有します。

本シリーズは全5回:
 第1回_そもそもAgentic AIとは何なのか
 第2回_MCPがなぜポイントになるのか
 第3回_Agentic AI検証環境を作ってみた
 第4回_検証環境の評価をしてみた
 第5回_手を動かして見えてきた、導入までに考慮が必要なこと
をお届け予定です!

Index

1.イントロダクション

ネットワーク運用では依然としてCLIが中心であり、

・ベンダーごとに異なる構文
・長い設定コマンド
・誤操作のリスク

といった課題から、学習コストと作業負荷が増えがちです。

さらに、ネットワーク情報は機密性が高く、クラウド型 LLM へ送信できないケースも多く存在します。そこで本記事では、GPU サーバー 1 台のみで完結するローカルAI 運用環境を構築し、自然言語でネットワーク装置を安全に操作できる環境について解説します。

自然言語でネットワーク装置を安全に操作
拡大
自然言語でネットワーク装置を安全に操作

2.オンプレミス構成にした目的

今回の構成をオンプレミスにこだわった理由をご紹介します。

1.機密情報を外部に出さないため

・LLMに投げる入力には、ネットワーク構成、機器情報など機微な情報が含まれる場合があるため、クラウドLLMに送信するのは情報管理上リスクがあり、推論処理・データ保管をすべてオンプレミスに閉じることが要求されることがあるためオンプレミスに完結させました。

2.ネットワーク機器へのアクセスを安全に接続するため

・今回の仕組みでは、オンプレミス環境内で稼働するローカルAI(LLM)がJuniperスイッチにSSHで接続します。外部クラウドからネットワーク機器にコマンドを送らせるのは
   ・到達性
   ・セキュリティガバナンス
   ・運用ガバナンス
の面で適していないと判断しました。ローカルAI(LLM)とスイッチが同一L2/L3領域にある構成は、シンプルかつ安全に利用することができると考えました。

3.推論性能とコストの両立

・gpt-oss-20bをGPUで動かすために十分な性能が必要ですが、クラウドGPUを常時利用する場合、検証など様々なクエリを試す場合従量課金によって高コストとなる場合があると考えました。
・オンプレミスGPUサーバーなら初期投資のみで月額コストが低いかつモデルの自由な調整ができ、運用コストと制御性で理想的でした。
※GPUの世代が古くなるとこれに限りません。

4.オンプレミス機器との連携が容易

・NetBox、Zabbix、Syslogサーバーなどの管理ツールと直接連携できる点が大きなメリットです。これにより、
  機器情報(IP、ロール、配線情報など)を NetBoxから即座に参照。
  監視アラート(Zabbix)を LLM に渡して 原因解析や一次対応の自動化
  ログ(Syslog)を LLM に直接渡して 異常検知精度を向上
  追加のVPN/クラウド連携設定が不要で、構成がシンプル
といった、オンプレならではの 低遅延・高セキュリティ・高い統合性を実現できます。

3.システム環境

・GPUサーバー:HPE DL385 Gen10 Plus
   CPU:AMD EPYC 7313 16-Core *2
   MEM:256GB (64GB *4)
   NIC:100GE 1P NIC&2-Port10GbSFP+
   GPU:NVIDIA A40
   OS:Ubuntu 22.04 LTS
・対象ネットワーク機器
   JuniperQFXおよびEXシリーズ
・使用ソフトウェア
   OpenWebUI(対話UI:ブラウザから自然言語で操作)
   Ollama(GPT-OSS20B)(LLM実行:GPU 上で高速推論)
   MCPO+netmiko-mcp(機器操作レイヤ:LLM がネットワーク機器へアクセスする中間層)

4.全体構成

全体の流れ
1.ユーザーがブラウザでOpenWebUIにアクセス
2.OpenWebUIがプロンプトをOllamaへ送信
   モデル:gpt-oss-20B(NVIDIA A40 上で実行)
   役割:プロンプト解釈/ツール呼び出し判断(mcpo+Netmiko-mcp)
3.Ollama(LLM)が必要に応じてツール(mcpo + Netmiko-mcp)を呼び出し
   例:{"tool": "run_cli", "host": "qfx5100-01", "commands": ["show interfaces terse"]}
4.MCPOがNetmiko経由で ネットワーク機器に対して操作
   対象:show系/設定変更(commitなど)
   戻り:生テキスト(端末出力) or 構造化データ(JSON) 
5.LLMがコマンド結果を解釈・変換し、回答分の生成
   正規化・パース(例:インターフェース状態を表に整形)
   要約・洞察(障害の有無、影響範囲、対処候補)
   根拠トレース(どのコマンド結果に基づくか)
6.LLMが生成した結果がOpenWebUIに戻り、自然言語で表示
   付随情報の表示:原文ログ、表、グラフ、差分(before/after)等

5.構築方法

GPUサーバーの準備
   Ubuntu 22.04 LTS(24.04でも可)をインストール。
   Dockerの利用できる状態へ。(Ubuntu | Docker Docs)
   インストール後以下を実施
      sudo apt update
      sudo apt upgrade -y

      その後NVIDIAGPUドライバ+CUDA+CotainerToolkitをインストール(Installing the NVIDIA Container Toolkit — NVIDIA Container Toolkit)
      インストール後、”nvidia-smi”を実行し、GPUが利用できる状態であることを確認します。

コンテナ上でGPUが利用できる状態となった後にOllamaやOpenWebUI等を構築していきます。

本環境は、本件以外の検証なども行っており、管理の容易さから、Dockercomposeにて実行するようにしました。DockercomposeファイルにOpenWebUI,Ollama,mcpoの起動を含めています。

以下では弊社環境での構築手順や設定を示します。なお、より詳細な構築手順・方法については各READMEなどの公式ドキュメントを参照してください。

/home/ubuntu/
├─ openwebui/ ※OpenWebUI,Ollama,mcpo
│  └─ docker-compose.yml
│  └─ mcp-netmiko-server/
│  └─ config.json等々netmiko-mcp関連ファイル

docker-compose.ymlファイル

version: '3.8'

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    volumes:
      - openwebui-data:/app/backend/data
    extra_hosts:
      - "host.docker.internal:host-gateway"
    depends_on:
      - ollama
    restart: unless-stopped

  ollama:
    image: ollama/ollama
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama-data:/root/.ollama
    restart: unless-stopped
    environment:
      - OLLAMA_KEEP_ALIVE=-1
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

  mcpo:
    build:
      context: ./mcp-netmiko-server
    container_name: mcpo
    ports:
      - "8000:8000"
    volumes:
      - ./mcp-netmiko-server:/app


volumes:
  openwebui-data:
  ollama-data:

netmiko-mcp(https://github.com/upa/mcp-netmiko-server)
gitクローンし、my-devices.network.tomlに自身の利用予定デバイス情報を記載しておきます。

例:
[default]

username = "rouser"
password = "rouserpassword"

[qfx1]

hostname = "172.16.0.40"
device_type = "juniper_junos"

[nexus1]

hostname = "nexus1.lab"
device_type = "cisco_nxos"

Dockercomposeファイルのあるディレクトリにて以下を実行

docker compose up -d

起動後Ollamaコンテナへログイン

docker exec -it ollama bin/bash 

コンテナ内に入った後、利用するモデルをダウンロード
例: ※利用したいモデルの記載は以下を参照(https://ollama.com/search)

ollama pull gpt-oss:20b

ダウンロード後モデルを実行します。

ollama run gpt-oss:20b

OpenWebUIにログインし、MCPを有効化していきます
http:// <your-server-address>:3000

OpenWebUI→管理者パネル→設定→External Tools→“接続を追加“からmcpoのエンドポイントを指定します。
例:
http:// <your-server-address>:8000/mcp-netmiko-server

新しいチャットなどからツールの利用ができるようになります。

netmikoの有効化ボタン

有効化の上、自然言語で対象機器に対して自然言語でのやり取りが可能になります。
※なお、本記事では一部工程を省略している場合があります。各構築手順は公式ドキュメントを参照ください。

6.まとめ

今回紹介した構成により、GPU サーバー 1 台だけで以下が実現できました
   完全オンプレで LLM 推論が完結(情報漏洩リスク低減)
   自然言語で Juniper を操作(CLI の暗記不要)
   安全な読み取り専用アクセス(mcpoおよびNetmiko-mcp による制御)
   運用効率と標準化の向上

次回は作成できた環境をもとにAIやMCPを活用した際の評価手法や結果の紹介をします。

益行 隼平

益行 隼平

STech I入社後、HPEストレージエンジニアとしてPrimera、Alletraを中心としたストレージ基盤の設計・導入に従事。
2023年よりNutanixおよびAzure IaaS、Azure Virtual Desktop領域を担当し、オンプレミス基盤からクラウド環境まで幅広いインフラ領域に対応。
エンタープライズ、サービスプロバイダ、学術公共など多様な顧客様向けに技術支援を行い、国内導入事例が限られるNutanix機器の導入にも携わる。
2025年以降はAI・自動化領域に注力し、Ansibleやスクラッチ開発を組み合わせたソリューションにより、業務効率化・運用自動化および技術検証の推進に取り組んでいる。

カテゴリー

タグ

お気軽にご相談ください。

Exhibitions & Seminarsイベントセミナー

資料ダウンロード

関連ソリューション・関連製品

ProLabs(プロラボス)
ProLabs(プロラボス)
ProLabsは高品質かつ低価格のサードパーティ製光トランシーバーを提供いたします。業界標準規格品やベンダー互換品など豊富な製品ラインナップを揃えております。

ProLabsは高品質かつ低価格のサードパーティ製光トランシーバーを提供いたします。業界標準規格品やベンダー互換品など豊富な製品ラインナップを揃えております。