1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

セルフホストの監視サーバーにローカル LLM(Ollama)でインシデント説明を付ける — 根拠リンクと承認フロー

1
Posted at

はじめに

監視システムは「何が起きたか」を大量に記録できます。しかし、複数の製品から同じ機器についてアラートが届いたとき、「どれが先で、何が原因らしく、次に何を確認すべきか」を組み立てる作業は人に残ります。

この作業に LLM を使う場合、単にアラート一覧をプロンプトへ入れて要約させるだけでは不十分です。もっともらしい説明と、監視データで確認できる説明を区別できないからです。また、モデルに操作権限まで渡すと、説明の誤りがそのまま状態変更につながります。

本稿では、セルフホストの監視サーバーに Ollama などのローカル LLM を組み込む際の設計原則を整理します。

1. モデルには「サーバーが実際に保持している情報」だけを渡す

最初の境界は入力です。モデルが参照できる情報を、監視サーバーが保持している次のような項目に限定します。

  • 1 行のアラート要約
  • 機器名
  • 重要度
  • タイムスタンプ
  • インシデントとアラートの識別子

監視サーバーに届いていない生ログ、設定ファイル、証明書、パケットキャプチャを、モデルが読んだかのように扱ってはいけません。入力の境界を明確にすると、「モデルが知り得ること」と「推測にすぎないこと」を分けやすくなります。

ローカル LLM を同じサーバーで動かす場合、監視データを外部へ送らずに説明を生成できます。Ollama を別の社内サーバーで動かす構成でも、通信先を自分のネットワーク内に保てます。

2. 回答を文章だけで終わらせず、根拠の識別子を要求する

LLM の回答形式には、説明文だけでなく、各主張が参照するアラートまたはインシデントの識別子を含めます。たとえば「設定変更の直後に DNS の宛先が変わった」という主張なら、設定変更アラートと DNS アラートの両方を参照させます。

重要なのは、モデルが返した識別子をそのままリンクにしないことです。監視サーバー側で、その識別子が現在のデータに本当に存在するかを照合します。

  • 存在する参照: 実データへのリンクとして表示
  • 存在しない参照: unverified と明示

これはハルシネーションを消す仕組みではありません。モデルの推論と、サーバーが確認できる根拠の境界を UI 上で見えるようにする仕組みです。利用者はリンクを開き、時刻・重要度・元製品の情報を自分で確認できます。

3. 読み取りと変更を別の経路にする

「このアラート群を確認済みにして」と質問された場合でも、LLM が直接変更 API を呼ぶ設計にはしません。モデルが返せるのは、対象と理由を含む提案までです。

実際の変更は次の流れに分けます。

  1. LLM が確認対象を提案する
  2. UI が対象一覧と操作内容を表示する
  3. 権限を持つ人が承認する
  4. サーバーが変更を実行する
  5. 承認した人の名前で監査ログへ記録する

閲覧者には承認ボタン自体を出さず、オペレーターまたは管理者だけが承認できるようにします。これにより、「説明を生成する権限」と「状態を変える権限」を分離できます。

4. 外部モデルを選べる場合は、マスキングと送信前確認を入れる

ローカル LLM だけでなく外部 API も選択肢にするなら、送信前に識別情報を置き換えます。対象には、機器名、ホスト名、IP/MAC アドレス、メールアドレス、ユーザー名、インシデント ID などがあります。

単にマスキングするだけでなく、実際に送信されるリクエストを画面に表示し、人が確認してから送る形が望ましいです。また、送信した内容をログとして保持すると、後から「何を外部へ渡したか」を監査できます。

マスキングは万能ではありません。1 行要約の自由文に固有情報が含まれる可能性も考え、外部モデルを使う組織は送信内容を目視できる設計にしておくべきです。

5. MCP は読み取り専用・標準入出力に限定する

監視データを MCP クライアントから参照できるようにする場合も、書き込みツールを公開しない方が安全です。インシデント、アラート、機器の読み取りだけを提供し、既定で名前をマスキングします。

さらに、MCP サーバーをネットワーク待受にせず、コンテナの標準入力・標準出力で起動すれば、追加の TCP ポートや常駐公開 API を増やさずに接続できます。LLM の会話経路と監視状態の変更経路を分離する、という原則をここでも維持できます。

6. 運用時に確認すること

  • Assistant は初期状態で無効にする
  • ローカルモデルの CPU・メモリ要件は監視コンソールとは別に見積もる
  • 回答の品質と待ち時間は選んだモデルに依存すると明記する
  • unverified をエラーとして隠さず、利用者に見せる
  • 承認操作と外部送信内容を監査できるようにする
  • 監視製品は AI サーバーに接続できないときも単独で監視を続けられる構成にする

実装例: MeshWatch AI

MeshWatch AI 1.0.0 は、上記の境界を採用したセルフホスト製品です。Ollama または自分の API キーを選べ、根拠リンク、unverified 表示、人による承認、外部送信時のマスキング、読み取り専用 MCP を備えています。実画面の流れは 9 画面のデモ と 製品動画 で確認できます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?