😎

ローカルLLMで一次トリアージを自動化：SD-WAN時代のヘルプデスク設計

に公開
Datadog
ヘルプデスク
llm
運用設計
SD-WAN
tech

はじめに

SD-WANやSASEが普及し、ネットワークとアプリケーションの境界が曖昧になると、障害発生時に「どのチームにエスカレーションすべきか」の一次切り分け（トリアージ）が難しくなっています。
ユーザーからの「Salesforceが遅い」「Teamsがつながらない」といった問い合わせに対して、従来のPing疎通チェックやブラウザ確認だけでは原因が特定できません。

本記事では、ローカルLLMを活用して一次トリアージを自動化する設計を紹介します。

現場の痛み

  • 境界の曖昧化
    SD-WANのオーバーレイ経路、ゼロトラストのポリシー、DNS制御、SaaS障害が複雑に絡み合い、「NW起因かアプリ起因か」が切り分けにくい。
  • ヘルプデスクの負担増
    各チームごとにRunbookや質問票がバラバラで、問診だけで時間を浪費。
  • たらい回し問題
    ネットワークチームとアプリチームの責任境界が不明瞭で、エスカレーションが迷子になりやすい。

運用で効く設計：ローカルLLMの出番

ローカルにLLMを配置し、ヘルプデスクと可観測性ツールの間に「インテリジェントな問診係」を置きます。

1. 症状インテークの標準化

  • LLMがオペレータに適応的に質問し、欠落情報を自動補完
  • 出力はJSONやYAMLなど構造化データで、次のチームに渡しやすい

2. 証跡の自動収集・要約

  • Datadog API, SD-WANコントローラ, DNSログなどを読み取り専用で照会
  • LLMが「NW疑い/アプリ疑い/端末疑い」をスコアリング

3. 責任分界点に沿ったディスパッチ

  • SLAや事前定義ルールとマッチングして、自動で担当チームにチケットを振り分け
  • Runbookの該当部分だけ添付し、対応開始を早める

4. ローカル運用の利点

  • 機密ログを外に出さない
  • 外部SaaS障害時でも継続可
  • 低遅延で即応できる

チーム横断での導入ステップ

いきなりLLMやRAGに頼るのではなく、まずは人間の合同対応から始めるのが現実的です。

  1. 合同対応フェーズ

    • ヘルプデスク・NW・アプリ各チームが一緒にユーザー問い合わせに対応
    • 実際のやり取りを通じて「共通の質問票」を磨き上げる

  2. 知識ベース化フェーズ

    • 質問票・対応パターンを整理して、RAGの知識ベースに投入
    • 過去のインシデント記録やRunbookも併せて格納

  3. 運用開始フェーズ

    • LLMが質問票に基づいて問診し、収集結果をRAG参照してトリアージを補助
    • ヘルプデスクはその出力を確認してエスカレーション

  4. 継続的改善フェーズ

    • 定期的に各チームが集まり、RAGへの落とし込みをアップデート
    • 新しい障害パターンやSaaS仕様変更を反映し、LLMの回答精度を高める

この「人間による共通化 → 知識ベース化 → LLM活用 → 継続改善」という流れが、実運用で成功させるポイントです。

再現できる最小セット（PoC例）

  1. RAG（知識ベース）
    • 過去インシデント報告や質問票をMarkdownで集約 → FAISS＋SQLiteに投入
  2. API連携（2本だけ）
    • Datadog（Synthetics, APM要約）
    • SD-WANコントローラ（トンネル状態）
  3. Slackボット
    • /triage "Slackが重い" → JSON一次診断＋担当案を返す
  4. 監査ログ
    • エスカ先が修正した結果を記録し、次回の学習に反映

JSON出力サンプル

{
  "severity": "P2",
  "symptom": "Salesforceが断続的にタイムアウト",
  "scope": {"users": 23, "sites": ["Tokyo-Office"]},
  "evidence": {
    "synthetics": {"http_latency_p95_ms": 2400, "timeout_rate": 0.12},
    "sdwan": {"ipsec_tunnel_flaps_1h": 3}
  },
  "triage": {"llm_guess": "network", "confidence": 0.78},
  "dispatch_to": "NW-Team",
  "next_actions": [
    "Tokyo-OfficeのWAN回線Bへフォールバック確認",
    "SD-WAN QoSポリシー recent change の有無を確認"
  ]
}

まとめ

  • SD-WAN時代、一次トリアージは人力では限界
  • ローカルLLMにより、問診標準化・証跡要約・担当ディスパッチを自動化できる
  • 最初は合同対応＋質問票作成から始め、RAG化し、定期的に改善を続けることが成功の鍵
  • 最小構成なら「RAG＋Datadog＋SD-WAN API」だけでPoC可能

“ヘルプデスクが迷子にならない世界”をローカルLLMと継続的改善で作っていきましょう。

Discussion