トップ > ネットワーク > ネットワーク運用自動化におけるSLMの活用検証

ネットワーク運用自動化におけるSLMの活用検証

ネットワーク インフラ AI NRE

サムネイル

1. はじめに

ネットワーク運用自動化、進めてますか？

ITインフラ本部インフラ部ネットワークグループ NRE（Network Reliability Engineering） チームの佐々木です。

NREと言う言葉に馴染みが無い方もいらっしゃると思いますが、簡単に説明すると「運用の自動化をしたり監視メトリクスの取得や活用を進めることでネットワークの安定運用に努める」といった仕事です。

IaCなど、実務的な言葉に置き換えるとよりわかりやすいかもしれません。

前書きはこの辺で終えて、本題に進みたいと思います。

2. SLMってなんですか？

そもそもAI活用が話題に上っている中、LLMと言う言葉は耳にタコが出来るほど目にする(耳なのに目…？変だな)かと思いますが、SLMと言う言葉についてはLLMほど耳にする機会がないと思います。

そこで、AIにLLMとSLMについて聞いてみましょう。

---　ここからAI回答 ---

AIにおけるSLM (Small Language Model) とLLM (Large Language Model) の主な違いは、その名前が示すとおり、モデルの規模にあります。

一般的に、LLMは数千億から数兆のパラメータを持ち、膨大な量のインターネット上のデータを学習することで、多様なタスクに対応できる汎用的な能力を持っています。一方、SLMは数億から数百億のパラメータを持ち、特定の分野や目的に特化したデータを学習することで、その分野では高い性能を発揮する専門的な能力を持っています。

SLMとLLMの比較

SLMとLLMの主な違いを以下の表にまとめました。

特徴 SLM (小規模言語モデル) LLM (大規模言語モデル)
パラメータ数 数億〜数百億 数千億〜数兆
学習データ 特定の分野に特化したデータ インターネット上の膨大なデータ
得意なタスク 特定分野の専門的なタスク 幅広い分野の汎用的なタスク
計算リソース 比較的少ない (PC、エッジデバイスで動作可能) 大規模 (高性能なGPUクラスターが必要)
開発・運用コスト 低い 高い
応答速度 速い 比較的遅い場合がある
ハルシネーション 少ない 比較的発生しやすい

--- ここまで ---

SLMとLLMの使い分け

SLMとLLMは、その特性から異なる用途で使い分けられます。

LLMの利点と用途 🌐

LLMは、膨大なデータを学習しているため、一般的な知識や常識に基づいた多様な質問に答えたり、文章を生成したりするのが得意です。例えば、カスタマーサポートのチャットボット、文章作成の支援、プログラミングコードの生成など、幅広いタスクに利用されます。

SLMの利点と用途 🎯

SLMは、特定の分野に特化しているため、その領域ではLLMよりも高精度な回答を生成できる場合があります。また、モデルが軽量なため、計算リソースが限られたスマートフォンや組み込み機器（エッジデバイス）でも動作させることが可能です。

これにより、ローカル環境でのデータ処理が可能となり、セキュリティ面でも優れています。例えば、医療分野に特化したAIアシスタントや、企業の機密情報を扱う社内用のチャットボットなどに活用されます。

応答速度を重視したいときやリソースを小さく済ませたい時にはSLMの利用が有効であると言えます。

3. どうやって使う？

SLMについてもさらっと認識したところで、本題のネットワーク運用自動化におけるSLMの活用検証について記載します。

まず、なぜSLMを運用自動化で利用しようと思ったのか？で言うと下記の通りです。

  • GPUリソースがなくても軽量モデルであれば動作する
  • AIに任せたい仕事が明確

これらを踏まえ、複雑な処理でもないしSLMの利用で問題ないのでは？と考えたからです。

検証アーキテクチャ

検証アーキテクチャ

と言うことで、このような構成で実際にテストしてみます。

弊社はマルチベンダーで構成を組んでいるため、showコマンドの結果の形式がベンダー単位で違うものをどのようにしてparseするのかが課題となっています。

そこで、IP Clos環境やバックボーンで使われがちなBGPの単一neighbor状態を表示するコマンドの結果を共通のjsonフォーマットに変換できるのか？と言うことを検証しました。

検証するSLMを動かす環境はMacbook Proで、CPUはApple M3 Pro、メモリは36GBです。

このマシン上でDockerを動かしGPUアクセラレーションを無効にすることでGPUのない環境を作成します。

4. 検証環境と構成

今回の検証では、以下の3つの環境でSLMの性能を比較しました。

検証環境

  1. localhost:11434 (GPUあり環境)
    • Apple M3 Pro GPU使用
    • ネイティブOllama環境
  2. localhost:11435 (GPUなし環境)
    • Docker環境（CPU8コア、メモリ18GB割り当て）
    • CPU処理のみ、GPUアクセラレーション無効
  3. Amazon Bedrock
    • openai.gpt-oss-20b-1:0
    • openai.gpt-oss-120b-1:0

検証データ

3つのベンダーのBGP showコマンド出力を使用します。

  • Arista: show ip bgp neighbors 出力
  • Juniper: show bgp neighbor 出力
  • Cisco IOS-XR: show bgp neighbors 出力

目標JSON形式

各ベンダーの異なる出力形式を、以下の統一JSONスキーマに変換します。

[
  {
    "neighbor_ip": "192.0.2.1",
    "remote_as": 64496,
    "state": "Established",
    "uptime": "12:07:44",
    "address_families": [
      {
        "afi_safi": "ipv4-unicast",
        "received_prefixes": 100,
        "accepted_prefixes": 95,
        "advertised_prefixes": 50
      }
    ],
    "description": "Example BGP Peer",
    "last_state_change": "2025-08-20T12:00:00Z"
  }
]

5. 検証結果

5.1 SLM（10b以下）の厳しい現実

5.1.1 検証条件と成功基準

項目4で述べた検証環境に加えて、以下の成功基準で評価を行いました。

成功条件

  1. JSON解析成功: 有効なJSON形式での出力
  2. スキーマ準拠: 定義されたBGPNeighborスキーマに適合
  3. データ抽出成功: BGPネイバー情報の正確な抽出

成功率の計算方法

成功率 = (両言語で成功したベンダー数 / 総ベンダー数) × 100%

各モデルに対して3ベンダー（Arista、Juniper、Cisco IOS-XR）× 2言語（日本語・英語）でテストを実行し、両言語で成功したベンダー数を基に成功率を算出しています。

失敗パターンの分類

  • JSON解析エラー: 無効なJSON出力
  • バリデーションエラー: スキーマ違反（無効なAFI/SAFI値等）
  • データ欠損: 必須フィールドの不足

5.1.2 小型SLMの検証結果

今回検証した真のSLMと呼べる10b以下のモデルの結果は、正直に言って期待を大きく下回るものでした。

モデル パラメータ数 成功率 日本語対応 英語対応 主な問題
tinyllama:latest ~1.1B 0% ❌ 完全失敗 ❌ 完全失敗 JSON生成不可
gemma3:latest ~2B 0% ❌ 完全失敗 ❌ 完全失敗 JSON生成不可
llama3.2:latest ~3B 33% ❌ 完全失敗 ⚠️ 部分成功 日本語で破綻
granite3-moe:latest ~3B 33% ⚠️ 部分成功 ⚠️ 部分成功 不安定

5.2 日本語vs英語プロンプトの決定的な差

もっとも衝撃的だったのは、日本語プロンプトでの壊滅的な失敗率です。

llama3.2:latestの言語別結果

  • 英語プロンプト: Arista/Cisco IOS-XRで成功（2/3ベンダー）
  • 日本語プロンプト: 全ベンダーで完全失敗（0/3ベンダー）
  • エラー例: AFI/SAFI値でinet-unicast（無効値）を出力

典型的な失敗パターン

# 日本語プロンプトでの出力例（llama3.2）
{
  "neighbor_ip": "192.0.2.1",
  "address_families": [{
    "afi_safi": "inet-unicast"  // ← 無効値（正しくは"ipv4-unicast"）
  }]
}

5.3 「SLM」と呼べるのか？大型モデルの検証

一方で、今回「SLM」として検証したモデルの中には、実際にはかなり大型のものも含まれていました。

大型モデルの結果

  1. gpt-oss:latest（推定20B+パラメータ）
    • GPU環境: 53.5秒、成功率100%
    • CPU環境: 410秒、成功率100%
    • 特徴: SLMとしては確実に大きすぎるサイズだが、挙動自体は極めて優秀。
      CPUのみでも安定動作し、GPUがあれば大幅な高速化を実現。果たしてSLMと呼べるのか？
  2. phi4:latest（推定14Bパラメータ）
    • GPU環境: JSON解析エラーで全て失敗（31-74秒）
    • CPU環境: JSON解析エラーで全て失敗（139-307秒）
    • 問題: 大型でも構造化データ生成に失敗
  3. gemma3:12b（12Bパラメータ）
    • GPU環境: JSON解析エラーで全て失敗（33-53秒）
    • CPU環境: JSON解析エラーで全て失敗（33-53秒）
    • 問題: パラメータ数に関係なく失敗

5.4 SLMの根本的な課題

検証を通じて、今回の要件でSLMを使用する場合の根本的な問題が明らかになりました。

  1. 構造化データ生成能力の不足
    • JSONスキーマの理解が困難
    • 複雑な変換ルールの適用ができない
  2. 日本語処理の脆弱性
    • 英語に比べて日本語での性能が著しく劣化
    • 多言語対応の限界が露呈
  3. 一貫性の欠如
    • 同じ入力でも異なる結果を出力
    • 本番運用には不適切なレベル

5.5 ちなみに：Amazon Bedrockでの検証結果

一方で、参考として検証したAmazon Bedrockの結果は対照的でした。

Bedrockモデルの性能

モデル 平均実行時間 成功率 コスト/1000出力トークン 特徴
gpt-oss-20b 4.6秒 100% $0.0003 最高速・高精度
gpt-oss-120b 4.6秒 100% $0.0006 高精度・安定性

Bedrockの優位性

  • 安定性: 100%の成功率を維持
  • 速度: ローカルGPU環境より91%高速
  • 言語対応: 日本語・英語ともに完璧
  • 運用性: インフラ管理不要、スケーラブル

5.6 SLMの典型的な失敗パターンと技術的課題

検証を通じて、SLMたちは予想以上に「個性的」な失敗を見せてくれました。エンジニアとして笑うに笑えない、でも技術的に興味深い失敗例を分析してみましょう。

言語の壁：llama3.2の「二重人格」現象

もっとも衝撃的だったのは、同じモデルが言語によって全く異なる性能を示す現象でした。

驚愕の成功率格差

  • 英語プロンプト: 67%の成功率（Arista/Cisco IOS-XRで成功）
  • 日本語プロンプト: 0%の成功率（全ベンダーで完全失敗）

同じモデル、別人格の出力例

// 英語プロンプト（成功例）
{
  "neighbor_ip": "192.0.2.101",
  "address_families": [{
    "afi_safi": "ipv4-unicast"  // ← 正しいBGP規格値
  }]
}

// 日本語プロンプト（失敗例）
{
  "neighbor_ip": "192.0.2.101", 
  "address_families": [{
    "afi_safi": "inet-unicast"  // ← 存在しない創造的な新規格
  }]
}

技術的背景の深掘り

  • 訓練データの言語バイアス: 技術文書の多くが英語中心のため、日本語での技術的推論能力が著しく劣る
  • トークン効率の圧倒的差: 英語436トークン vs 日本語1010トークン（57%の効率差）
  • 多言語処理時の内部表現劣化: 言語切り替え時にモデルの技術的理解が失われる現象

実運用への示唆: 日本企業でのSLM導入時、日本語での運用を前提とした場合の隠れたリスクが明確になりました。

その他の「個性的」失敗パターン

🎨 tinyllamaの「スペルミス芸術家」

{
  "accpeted_prefixes": 95,        // ← "accepted"の創造的解釈
  "adveterised_prefixes": 50,     // ← "advertised"がまさかの変身  
  "descripiont": "Main BGP peer"  // ← "description"の斬新な表記
}

小型モデルの語彙制限とトークン化の問題が如実に現れた例です。

🤯 granite3-moeの「物理法則チャレンジャー」

{
  "state": "OpenSend",              // ← "OpenSent"の独自解釈
  "received_prefixes": 179,
  "accepted_prefixes": 180          // ← 受信より承認が多い奇跡の現象
}

BGPの基本的な論理関係（accepted ≤ received）すら理解できていない状況が露呈しました。

😴 phi4 & gemma3の「大型なのに無言」現象

  • phi4: 14Bパラメータを持ちながら、31-307秒かけて何も出力しない
  • gemma3: 12Bパラメータなのに、JSON生成すら不可能

パラメータ数と実用性が必ずしも比例しないことを示す興味深い事例です。

技術的示唆

これらの失敗パターンは、SLMの現在の技術的限界を示しています。

  1. 構造化データ生成能力の不足: JSONスキーマの理解が困難
  2. 規格知識の欠如: 業界標準への理解が不十分
  3. 言語依存性の課題: 多言語環境での性能格差
  4. 論理整合性の欠如: 基本的な数値関係の理解不足

特に多言語環境や厳密な規格準拠が求められるネットワーク運用では、信頼性の観点から大型モデルやSaaSサービスの利用が現実的な選択肢となります。

5.7 gpt-oss-20b: 大型だが優秀なモデルの詳細分析

今回の検証でもっとも注目すべきは、gpt-oss-20bの圧倒的な性能でした。SLMとしては確実に大きすぎるサイズですが、その挙動は極めて優秀で、実用性の高さを証明しました。

サイズ vs 性能のジレンマ

gpt-oss-20bは推定20B+パラメータを持ち、従来のSLMの定義（数億〜数百億）を大きく超えています。
しかし、その性能は他のモデルを圧倒しています。

環境 実行時間 成功率 特徴
CPU環境 410秒 100% GPUなしでも確実に動作
GPU環境 53.5秒 100% 87%の高速化を実現
SaaS環境 4.6秒 100% 91%の超高速化

実用性の観点から見た優位性

1. 安定性の高さ

  • 全ベンダー（Arista/Juniper/Cisco）で100%成功
  • 日本語・英語プロンプト両方で安定動作
  • 構造化データ生成において一貫した品質

2. 柔軟な動作環境

  • CPU環境: GPUがない環境でも確実に動作（時間はかかるが）
  • GPU環境: 大幅な高速化でより実用的に
  • SaaS環境: 最高速度でインフラ管理不要

3. コストパフォーマンス

SaaSとして利用した場合のコスト効率については以下の通りです。

  • gpt-oss-20b: $0.0003/1000出力トークン
  • 典型的なタスク: $0.00003-0.00006/リクエスト
  • 月間1万リクエスト: わずか$0.3-0.6

「SLM」の定義を問い直す

従来のSLMの定義では、gpt-oss-20bは明らかに「Large」の範疇に入ります。

従来の分類

  • SLM: 数億〜数百億パラメータ
  • LLM: 数千億〜数兆パラメータ

しかし、実用性の観点から考えると次のような分類も検討できます。

実用性による新しい分類の提案

  • Practical SLM: 20B程度、実用的な速度と精度を両立
  • Enterprise LLM: 100B+、最高精度だが高コスト
  • Massive LLM: 1T+、研究用途や特殊用途

運用における現実的な選択

gpt-oss-20bは「SLMとしては大きすぎる」が、運用の現実を考えると最適解と言えます。

  1. 開発段階: ローカルGPU環境で検証（53.5秒）
  2. 本番運用: SaaS環境で高速処理（4.6秒）
  3. 緊急時: CPU環境でも動作保証（410秒）

この柔軟性こそが、gpt-oss-20bの真の価値であり、サイズよりも実用性を重視すべきという重要な示唆を与えています。

5.8 GPU効果とクラウドの圧倒的優位性

GPU効果の劇的な差

  • gpt-oss: 410秒(GPUなし) → 53.5秒(GPUあり) = 87%高速化
  • granite3-moe: 12.3秒(GPUなし) → 2.5秒(GPUあり) = 80%高速化

クラウドvs ローカルの圧倒的差

  • Bedrock gpt-oss-20b: 4.6秒
  • ローカル gpt-oss (GPU): 53.5秒
  • 91%の高速化

言語効率性

  • 英語プロンプト: 436トークン
  • 日本語プロンプト: 1010トークン
  • 57%のトークン削減効果

6. プロンプト設計と実装

6.1 プロンプト例（日本語版）

あなたは、ネットワーク機器のshowコマンド出力を解析し、BGP neighbor情報をJSONに変換する専門家です。

以下のshowコマンド出力を解析し、指定されたJSONスキーマに従ってBGP neighbor情報を抽出してください。

BGP Neighbor JSON Schema:
{
  "neighbor_ip": "<IP_ADDRESS>",
  "remote_as": <AS_NUMBER>,
  "state": "<BGP_STATE>",
  "uptime": "<UPTIME_STRING>",
  "address_families": [
    {
      "afi_safi": "<AFI_SAFI_NAME>",
      "received_prefixes": <NUMBER>,
      "accepted_prefixes": <NUMBER>,
      "advertised_prefixes": <NUMBER>
    }
  ],
  "description": "<DESCRIPTION_STRING>",
  "last_state_change": "<ISO8601_TIMESTAMP>"
}

Valid BGP States: Idle, Connect, Active, OpenSent, OpenConfirm, Established
Valid AFI/SAFI Types: ipv4-unicast, ipv6-unicast, ipv4-multicast, ipv6-multicast, vpnv4-unicast, vpnv6-unicast, l2vpn-evpn, evpn

## 変換ルール:
1. 出力は有効なJSONリスト形式である必要があります
2. IPアドレスは文字列として記録してください  
3. AS番号は整数として記録してください
4. uptimeは元の形式を保持してください
5. 不明な値は適切なデフォルト値を使用してください
6. タイムスタンプはISO8601形式で記録してください

6.2 プロンプト例（英語版）

You are an expert in analyzing network device show command outputs and converting BGP neighbor information to JSON format.

Please analyze the following show command output and extract BGP neighbor information according to the specified JSON schema.

BGP Neighbor JSON Schema:
{
  "neighbor_ip": "<IP_ADDRESS>",
  "remote_as": <AS_NUMBER>,
  "state": "<BGP_STATE>",
  "uptime": "<UPTIME_STRING>",
  "address_families": [
    {
      "afi_safi": "<AFI_SAFI_NAME>",
      "received_prefixes": <NUMBER>,
      "accepted_prefixes": <NUMBER>,
      "advertised_prefixes": <NUMBER>
    }
  ],
  "description": "<DESCRIPTION_STRING>",
  "last_state_change": "<ISO8601_TIMESTAMP>"
}

Valid BGP States: Idle, Connect, Active, OpenSent, OpenConfirm, Established
Valid AFI/SAFI Types: ipv4-unicast, ipv6-unicast, ipv4-multicast, ipv6-multicast, vpnv4-unicast, vpnv6-unicast, l2vpn-evpn, evpn

## Conversion Rules:
1. Output must be in valid JSON list format
2. Record IP addresses as strings
3. Record AS numbers as integers
4. Preserve uptime in original format
5. Use appropriate default values for unknown information
6. Record timestamps in ISO8601 format (use current time if unknown)
7. Set description to null if unknown

6.3 日本語vs英語プロンプトの比較分析

検証を通じて明らかになった、言語選択がSLMの性能に与える決定的な影響について詳しく分析します。

6.3.1 トークン効率性の圧倒的な差

項目 日本語版 英語版 差異
プロンプトトークン数 1,010トークン 436トークン 57%削減
文字数 約1,200文字 約800文字 33%削減
処理効率 低い 高い 大幅改善

6.3.2 SLMにおける言語処理能力の格差

llama3.2:latest（3Bパラメータ）での検証結果

ベンダー 日本語プロンプト 英語プロンプト 性能差
Arista ❌ 完全失敗 ✅ 成功 100%の差
Cisco IOS-XR ❌ 完全失敗 ✅ 成功 100%の差
Juniper ❌ 完全失敗 ❌ 失敗 同等
総合成功率 0% 67% 67ポイント差

6.3.3 失敗パターンの言語依存性

日本語プロンプトでの典型的な失敗例

{
  "neighbor_ip": "192.0.2.1",
  "address_families": [{
    "afi_safi": "inet-unicast"  // ← 無効値（正しくは"ipv4-unicast"）
  }]
}

英語プロンプトでの成功例

{
  "neighbor_ip": "192.0.2.1",
  "address_families": [{
    "afi_safi": "ipv4-unicast"  // ← 正しい値
  }]
}

このように日本語で指示を行うと型定義などの解釈を間違えてしまうことがあるため、英語での指示が望ましいと思われます。

6.3.4 言語選択の実用的指針

SLM利用時の推奨事項

  1. 英語プロンプト優先: トークン効率と成功率の両面で優位
  2. 日本語は大型モデル限定: 20B+パラメータでのみ安定動作
  3. ハイブリッド戦略: 開発時は英語、ドキュメントは日本語

コスト効率の観点

  • 英語プロンプト: 436トークン × $0.0003/1000 = $0.0001/リクエスト
  • 日本語プロンプト: 1,010トークン × $0.0003/1000 = $0.0003/リクエスト
  • 年間コスト差: 約$2-3（1万リクエスト/年の場合）

6.4 技術的実装

  • Pydanticモデルによる厳密な検証
  • JSON自動修復機能でパース失敗時の自動回復
  • フォールバック機能でプロバイダー間の自動切り替え
  • AWS SSO認証によるセキュアなクラウドアクセス

7. 運用面での考察

7.1 コスト比較

  • Ollama: 完全無料（電力コストのみ）
  • Bedrock gpt-oss-20b: $0.0003/1000出力トークン
  • Bedrock gpt-oss-120b: $0.0006/1000出力トークン

7.2 レスポンス時間

  • クラウド（Bedrock）: 4.6秒
  • ローカル（GPU）: 53秒
  • ローカル（CPU）: 410秒

7.3 実用性評価

  • 本番運用: Bedrock推奨（速度・安定性）
  • 開発・テスト: ローカルGPU環境
  • コスト重視: ローカルCPU環境（時間に余裕がある場合）

8. 運用システムへの組み込みを考える

8.1 SLMの現実的な限界

今回の検証で明らかになったのは、真のSLM（10b以下）では本番運用に耐えうる品質を確保できないという厳しい現実でした。

本番運用での課題

  • 成功率の低さ: 最良でも33%という信頼性
  • 日本語対応の脆弱性: 多言語環境での運用困難
  • 一貫性の欠如: 同じ入力で異なる結果
  • デバッグの困難さ: 失敗原因の特定が困難

8.2 SaaS利用という現実解

一方で、Amazon BedrockのようなSaaSベースのLLMサービスは、運用システムへの組み込みにおいて圧倒的な優位性を示しました。

SaaS利用のメリット

  1. 安定性: 100%の成功率を維持
  2. 圧倒的な速度: gpt-oss-20bで4.6秒という実用的な速度を実現
    • ローカルGPU環境（53.5秒）より91%高速
    • ローカルCPU環境（410秒）より98%高速
    • SLMとしては大きすぎるサイズだが、SaaSなら最高速度で利用可能
  3. インフラ管理不要: GPU調達・管理の負担なし
  4. スケーラビリティ: 需要に応じた自動スケール
  5. メンテナンス性: モデル更新やバグ修正が自動

コスト面での現実性

検証データから、平均的なBGP変換タスクでは約100-200トークンの出力が想定されます。

  • Bedrock gpt-oss-20b: $0.00003-0.00006/リクエスト
  • Bedrock gpt-oss-120b: $0.00006-0.00012/リクエスト
  • 月間1万リクエスト: $0.3-1.2
  • 年間コスト: $3.6-14.4

これは、コーヒー1杯分程度の極めて低コストであり、自動化による効率化を考えれば圧倒的にペイする投資と言えます。

9. まとめ：SLMの理想と現実

9.1 検証で得られた知見

ネットワーク運用自動化におけるSLMの活用検証を通じて、以下の厳しい現実が明らかになりました。

  1. 真のSLMの限界: 10b以下のモデルでは実用レベルに達しない
  2. 日本語処理の脆弱性: 多言語対応は期待できない
  3. 構造化データ生成の困難さ: JSONスキーマの理解が不十分
  4. 一貫性の欠如: 本番運用には不適切なレベル

9.2 今後への期待

SLMの技術進歩に期待しつつも、当面は安定性と信頼性を重視したSaaS利用が、ネットワーク運用自動化の現実的な選択肢と言えるでしょう。

理想を追うより、まずは動くものを作る。これがエンジニアリングの基本であり、今回の検証が示した重要な教訓です。

10. あとがき

この記事を読んでいて何か違和感を感じませんでしたか？

その違和感はおそらく、項番4から9がAIが検証結果を参照しながらまとめているため元の私の文章感と異なることからくる違和感だと思います。

むしろ人間が書いているところがしょうもない前提とかだけということに驚くという人もいるかもしれません。驚かないかもしれませんが。

とはいえ、AIのドキュメント生成能力には驚くばかりです。普通に私が書くより一丁前な記事書いてくれます。ちょっとユーモアが足りてないですが。

そのうち書き手の言葉のチョイスの癖とかも真似しながらバレない執筆ができるようになるのでしょうか？それはそれで面白そうなのでちょっと期待です。

私としてはこの結果から、JSONのフォーマットさえ決めてしまえばマルチベンダー環境においてもほぼ均一な形でネットワーク運用の自動化が進められるな、という点を感じています。

これまではベンダーごとに異なるshowコマンドの出力を正規表現で抜き出すためにベンダー単位でモジュールを作ってデータを変換する、という作業が必要なうえ、バージョンアップなどを行うとshowコマンドの出力が変わりVersion単位でモジュールを作成する、など負担の大きい部分がありました。

ですが、SLM(gpt-ossはLLMのサイズでしたが)を活用することでとりあえずJSONのフォーマットを作ってLLMにその形に変換させるだけで済むようになります。

モジュールさえ作ってしまえば、下記の2stepでparseが完了するようになります。

  1. Hostとshowコマンドを渡して実行、戻り値を取得
  2. 戻り値をLLMで共通の形に変換

この2stepでparseが完了するようになりますし、既存と異なるベンダーの筐体を導入した際にもshowコマンドさえわかってしまえばあとは追加でモジュールを作成する必要もなくなると思います。

体感的には、もはやネットワーク運用の自動化のゲームチェンジャーたりえると感じました。

この記事をきっかけに敷居が下がったと言えるかもしれないネットワーク運用自動化、始めてみませんか？

11. ネットワークグループ NRE メンバー募集中！

DMM では、ネットワークグループの NRE（Network Reliability Engineering）チームの仲間を募集しています。
NRE はネットワークの信頼性を確保するだけでなく、自動化やソフトウェア的なアプローチで運用を改善していくことをミッションとしています。

  • ネットワークの知識をベースに、もっと自動化を取り入れてみたい方
  • コードやツールを駆使して「ネットワーク運用を進化させたい」と思っている方
  • インフラの改善に主体的に取り組みたい方
  • ネットワーク機器のメトリクスの収集や活用をしたいと思っている方

そんな思いを持った方は、ぜひカジュアル面談もやっているので気軽にどうぞ！

pitta.me