1. はじめに — なぜローカルLLMだったか #

BASTION の中核はローカル LLM(Qwen2.5-14B)です。GPT-4 や Claude のような最先端の外部 LLM API ではなく、自前のGPUサーバーで動かす Qwen2.5 を選びました。

「精度が高い方を使えば良いのに、なぜわざわざ性能で劣るローカルモデルを?」という疑問は当然です。本記事では、その選択の背景と、実際にどう動かしているかを書きます。

結論を先に書くと、ローカルLLMには「精度」とは別の3つの強い利点があり、インフラ運用というドメインではそれらの方が重要だった、という話です。

2. クラウドLLMの3つの障壁 #

BASTION を開発する初期、当然のように OpenAI API や Anthropic API の利用を検討しました。しかし、次の3つの障壁にぶつかります。

2.1 データ主権の壁 #

BASTION が扱うログには、顧客の機微な情報が含まれます。攻撃元IP、内部システム構成、ユーザー名、認証失敗の詳細など。これらを外部 LLM API に送信することは、多くの顧客契約では認められません。

特に金融・官公庁・医療分野では、「ログを外部に送信した時点で契約違反」という顧客も珍しくありません。クラウドLLMは、そもそも「使えない」のです。

2.2 コストの不透明さ #

外部 LLM API は従量課金です。AWS の DevOps Agent などは秒単位で課金されます。BASTION のように常時動き続けるシステムでこれを使うと、ログ量に比例して費用が線形に増加。月額予算が読めません。

「攻撃が増えた月は予算オーバー」「平和な月は使い切れずに無駄」という形で、コスト最適化が極めて難しい構造です。

2.3 ネットワーク依存性 #

クラウドLLMはインターネット接続が前提です。閉域環境(専用線で隔離されたネットワーク等)では、そもそも利用できません。

BASTION のターゲットには「インターネットに繋がっていない環境でも動く監視システムが欲しい」という顧客が含まれます。ここを取れるかどうかは差別化の鍵でした。

3. BASTION の LLM 活用方針 — 3つの原則 #

これらを踏まえて、BASTION は次の3つの方針で LLM を活用しています。

つまり、LLM は「賢い秘書」として使い、判断は決定論的なコードに任せるのが BASTION の基本姿勢です。これは LLM 業界の主流の使い方とは少し違います。

4. アーキテクチャ — GPUStack + Qwen2.5-14B #

BASTION の LLM 基盤は、シンプルな構成で動いています。

BASTION 中央サーバー (AI-SLOG)
  │
  ├── rsyslog で各機器からログ受信
  ├── シェルスクリプト群で前処理・要約
  │     │
  │     ↓ HTTP API call (OpenAI互換)
  │
  └── GPUStack クラスタ
        ├── Qwen2.5-14B (主力モデル)
        ├── 軽量モデル (フォールバック用)
        └── 自動ロードバランス + 自動再起動

選定理由を簡単に書きます。

4.1 なぜ Qwen2.5-14B か #

BASTION では、ログの要約と自然言語レポート生成が主な仕事です。これに必要なのは:

• 日本語の自然な出力 — 顧客向けレポートが英語混じりだと使えない
• 14B 程度のサイズ — 24GB GPU 1枚で量子化なしでも動く
• 長文対応 — ログ要約のため、コンテキスト長は十分にほしい
• オープンライセンス — 商用利用が明確に許諾されている

Llama 3 系も検討しましたが、日本語の自然さで Qwen2.5 が勝りました。これは社内での比較評価の結論です。

4.2 なぜ GPUStack か #

GPUStack は、複数の GPU サーバーをクラスタとして扱える OSS です。BASTION では:

• OpenAI 互換 APIで外部からアクセス可能
• モデル切替が容易(主モデル落ちた時のフォールバック)
• 分散運用が可能(複数 GPU サーバーで並列処理)
• 運用ダッシュボード付き(モデル稼働状態が一目で確認できる)

これらが商用環境に必要な要件を満たしていました。

5. パイプライン — ログから通知まで #

BASTION の LLM 利用は、複数のステップに分かれています。

1. 機器ログ受信        (rsyslog)
        ↓
2. 機器別に分類保存    (シェル + ファイルシステム)
        ↓
3. 機器ごとに要約      (LLM 呼び出し #1)
        ↓
4. 全体相関分析        (LLM 呼び出し #2)
        ↓
5. 重大度判定          (決定論的ロジック)
        ↓
6. Slack 通知          (重大度がCRITICAL時のみ自動投稿)
        ↓
7. 詳細分析            (運用者がメンションで呼び出し)

重要なのは、各ステップで LLM の役割が明確に絞られていることです。

「LLMに判断させない、整形だけ任せる」という原則を一貫しています。

6. LLM に任せること、任せないこと #

これは BASTION 設計の核心部分なので、もう少し詳しく書きます。

BASTION では、LLM の出力を信用する場面と信用しない場面を、最初の設計段階で明確に分けました。

6.1 LLM に任せて良いこと #

• ログの自然言語要約 — 多少の表現ブレは許容範囲
• 複数機器の状況を1段落にまとめる — 人間が読むためのもの
• Slack 通知文面の整形 — 重要度に応じた絵文字や強調も任せられる
• 過去類似事案の参照 — 「これは先週も起きた」と提示

6.2 LLM に任せてはいけないこと #

• 攻撃IPかどうかの最終判定 — 数学的判定で決定的に決める
• ブロック実行の意思決定 — コードで条件を明示
• ブロック解除の意思決定 — 24時間自動失効 or 運用者操作のみ
• 本番設定の変更 — 運用者の手動操作のみ許可
• セキュリティ重大度の最終判定 — ルールベースで決める

「LLM の出力を読んで運用者が判断する」シーンは多いですが、「LLM の出力が直接システムを動かす」シーンは BASTION にはほぼ存在しません。

7. ハイブリッド LLM 戦略 — ローカル + 外部 API の使い分け #

2026年5月時点で、BASTION はローカル LLM だけでなく、Claude や GPT などの外部高性能 LLM API との連携も実験段階で構築中です。

ただし、これは「ローカル LLM を捨てて外部に乗り換える」という話ではありません。用途に応じて使い分けるハーネスを構築している、という話です。

閉域要件が厳しい顧客には、外部 LLM 連携を切り離してローカルのみで動く構成も従来通り提供します。「外部 LLM を必ず使う商品」ではなく、「使いたい時に使える拡張性を持った商品」というのが現時点の位置付けです。

8. 設計上の判断ポイント #

ローカル LLM 運用で、いくつかの重要な判断がありました。

1. プロンプトはバージョン管理する: LLM への問い合わせ内容(プロンプト)は、コードと同じくバージョン管理対象。プロンプトの変更で出力品質が大きく変わるため、変更履歴を残す。

2. JSON 出力を強制する: LLM の出力が「自由文」のままだと、後段のコードでパースできない。BASTION では、JSON 形式での出力を強制し、パースエラー時はリトライ。

3. temperature は低めに: 同じ入力に対して安定した出力を得るため、temperature は低い値(0.0〜0.3 程度)に固定。創造性は不要、決定性が重要。

4. プロンプトの「捏造防止」指示: 「与えられたログにない情報を作成しない」「不明な場合は明示的に “unknown” と返す」といった指示を必ず含める。これでもハルシネーションは完全に防げないので、後段でハルシネーション監査を行う(これは別記事で詳述予定)。

5. モデル落下時のフォールバック: メインモデル(Qwen2.5-14B)が応答しない時に備えて、軽量モデルへのフォールバック経路を実装。完全停止より、簡易な要約でも継続することを優先。

9. 運用実績 — ノイズ削減と決定性 #

BASTION が本番稼働を始めて約1ヶ月。LLM の運用実績を共有します。

• ログ分析の自動化率: 約 95%(従来は運用者が個別に Tail していたログを、LLM 要約に置き換え)
• Slack 通知のノイズ削減: CRITICAL 限定通知への切替で、定期通知の発生頻度が約 1/8 に
• 判定の決定性: 同一入力に対する判定結果は完全に一致(LLM の確率的出力は排除しているため)
• 誤検知率: 0%(自社IP/取引先IPの誤ブロック件数ゼロ)
• ハルシネーション検出件数: 監査ロジックで継続的に検出。検出された場合はイベントを破棄し再分析

特に 「決定性 100%」 が重要です。LLM を判断に使うと、同じ入力で違う結果が出ることがあります。BASTION では LLM を判断に使わないので、この種の「再現性のない誤動作」が物理的に発生しません。

10. 設計上のトレードオフ #

正直に書くと、ローカル LLM 運用にも制約があります。

1. 初期 GPU コスト: Qwen2.5-14B を快適に動かすには 24GB クラスの GPU が必要。最小構成でも数十万円〜。クラウド API のような「ゼロ円スタート」ではない。

2. 推論性能の上限: 14B クラスのモデルは、GPT-4 や Claude 3.5 Sonnet ほどの推論能力はない。複雑な多段推論が必要な場面では、外部 API へのフォールバックが必要。

3. モデル更新の追従: 新しいモデルが出るたびに評価・切替判断が必要。社内に技術的判断ができる人材が必要(これは BASTION の保守契約でカバー)。

4. プロンプト調整の継続性: 環境ごとに最適なプロンプトが異なる。導入時のチューニングと、運用中の継続改善が必要。

これらは「ローカル LLM を採用する以上、避けられないトレードオフ」です。ただし、データ主権・コスト予測性・閉域対応という3つの利点と引き換えに受け入れるべきコストだと判断しています。

11. 今後の発展 #

LLM 基盤は今後も継続的に進化させます。

• 新世代モデルへの追従: Qwen3 や次世代モデルの評価と切替
• ハイブリッド LLM 戦略の本格運用: 用途別の自動振り分けを定型化
• マルチモーダル対応: ネットワーク図やトラフィックグラフを LLM に読ませる用途
• 顧客環境別のチューニング: 各顧客のログ特性に合わせたプロンプト最適化の自動化

これらは順次取り組みます。