---
title: "Qwen2.5-14B + GPUStack で精度と決定性を両立した実装記録"
description: "BASTION がクラウド LLM でなくローカル LLM（Qwen2.5-14B＋GPUStack）を選んだ理由と実装を解説。LLM の用途は要約やレポート生成に限り、重大度判定とブロック実行は決定論的ロジックに任せる設計と、JSON 出力の強制や低 temperature を紹介。"
url: "https://bestnetllc.co.jp/docs/qwen2-5-14b-gpustack-%e3%81%a7%e7%b2%be%e5%ba%a6%e3%81%a8%e6%b1%ba%e5%ae%9a%e6%80%a7%e3%82%92%e4%b8%a1%e7%ab%8b%e3%81%97%e3%81%9f%e5%ae%9f%e8%a3%85%e8%a8%98%e9%8c%b2/"
updated: "2026-10-14"
category: BASTION
---

# Qwen2.5-14B + GPUStack で精度と決定性を両立した実装記録

// BASTION 技術解説 2026-05-14

Qwen2.5-14B + GPUStack で精度と決定性を両立した実装記録

 著者: 珍田 秀幸 / ベストネット合同会社   **関連記事:** [多層相関キャンペーン検知の仕組み](https://bestnetllc.co.jp/docs/%e5%a4%9a%e5%b1%a4%e7%9b%b8%e9%96%a2%e3%82%ad%e3%83%a3%e3%83%b3%e3%83%9a%e3%83%bc%e3%83%b3%e6%a4%9c%e7%9f%a5%e3%81%ae%e4%bb%95%e7%b5%84%e3%81%bf/) ／ [DMZ Agent と検証エンジン](https://bestnetllc.co.jp/docs/%e4%be%b5%e5%ae%b3%e3%81%95%e3%82%8c%e3%82%8b%e5%8f%af%e8%83%bd%e6%80%a7%e3%81%ae%e3%81%82%e3%82%8b-dmz-%e7%92%b0%e5%a2%83%e3%81%a7%e3%80%8cagent-%e3%82%92%e4%bf%a1%e9%a0%bc%e3%81%97%e3%81%aa%e3%81%84/)

## 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 を基盤に | 機微なログは外部に出さない。Qwen2.5-14B を GPUStack で運用 |
| ② LLM に判断を委ねない | キャンペーン判定、ブロック実行は決定論的ロジックで処理 |
| ③ 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 の役割 |
| --- | --- | --- |
| 要約 | LLM | 大量のログから「何が起きたか」を自然言語化 |
| 相関分析 | LLM | 複数機器の要約を結合して全体傾向を文章化 |
| 重大度判定 | 決定論的コード | LLM は使わない (誤判定リスク回避) |
| ブロック実行 | 決定論的コード | LLM は使わない (取り返しのつかない動作) |
| 通知文面生成 | LLM | 運用者が読みやすい日本語に整形 |

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

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

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

  // 設計原則

#### 「LLMの判断にシステムの安全を委ねない」

LLM はハルシネーション(架空の事実を生成する)を起こします。これは技術が進歩しても完全には消えません。インフラ運用に LLM を組み込むなら、**ハルシネーションが起きても致命的な被害が出ない設計**を前提にする必要があります。

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 | 理由 |
| --- | --- | --- |
| 日常のログ分析 | ローカル (Qwen2.5) | 機微なデータを外部に出さない |
| 定型業務の自動化(レポート整理など) | 外部 API | 機微情報を含まず、構造化能力が高い |
| 想定外の問題発生時の高度推論 | 外部 API (必要に応じて) | 複雑なシナリオ解析が必要な場面 |
| 本番制御の判断 | 使わない | 決定論的ロジックで処理 |

閉域要件が厳しい顧客には、**外部 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 に読ませる用途
- **顧客環境別のチューニング**: 各顧客のログ特性に合わせたプロンプト最適化の自動化

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

## 12. 関連記事

- [多層相関キャンペーン検知の仕組み](https://bestnetllc.co.jp/docs/%e5%a4%9a%e5%b1%a4%e7%9b%b8%e9%96%a2%e3%82%ad%e3%83%a3%e3%83%b3%e3%83%9a%e3%83%bc%e3%83%b3%e6%a4%9c%e7%9f%a5%e3%81%ae%e4%bb%95%e7%b5%84%e3%81%bf/) — LLM が分析した結果をどう「決定論的判定」につなげるか
- [DMZ Agent と検証エンジン](https://bestnetllc.co.jp/docs/%e4%be%b5%e5%ae%b3%e3%81%95%e3%82%8c%e3%82%8b%e5%8f%af%e8%83%bd%e6%80%a7%e3%81%ae%e3%81%82%e3%82%8b-dmz-%e7%92%b0%e5%a2%83%e3%81%a7%e3%80%8cagent-%e3%82%92%e4%bf%a1%e9%a0%bc%e3%81%97%e3%81%aa%e3%81%84/) — LLM を信頼しないのと同様、Agent も信頼しない設計
- [BASTIONを「セキュリティ商品」から「AI Ops Platform」へ](https://bestnetllc.co.jp/docs/) — BASTION 全体の進化のストーリー
- Coming soon LLMハルシネーション監査の実装

## 13. お問い合わせ

BASTION の導入をご検討の企業様、共同実証プログラムにご興味のある方は、[お問い合わせフォーム](https://bestnetllc.co.jp/contact/) からご連絡ください。

ローカル LLM 基盤(GPUStack + Qwen2.5)の構築・運用支援も、BASTION 導入と合わせてご相談可能です。スコープに応じた個別見積でご提案いたします。

 [無料相談・お問い合わせ →](https://bestnetllc.co.jp/contact/)

**ベストネット合同会社**

〒989-6116 宮城県大崎市古川駅東2-7-23

[https://bestnetllc.co.jp](https://bestnetllc.co.jp) ／ TEL: 0229-25-8716