LumeGuard AI 誤検知ゼロ・見逃しゼロ

前回の記事では、ファインチューニングにより精度95%を達成したLumeGuard AIの3つのアドバンテージについて解説しました。今回は、v1.3からv1.4への進化で 精度100%（60/60） を達成した技術的改善を説明します。

何が変わったのか

v1.3の時点で目標の95%を達成していましたが、2件のFalse Negative（見逃し）と1件のFalse Positive（誤検知）が残っていました。v1.4では、これらすべてを解消し、60件のテストケースを 全てパス しています。

指標	v1.3	v1.4
正解率	95.0%（57/60）	100.0%（60/60）
True Positive	33件	34件
True Negative	24件	26件
False Positive	2件	0件
False Negative	1件	0件

この結果は、単一の改善ではなく、4つの技術的アプローチの組み合わせ によって達成されました。

1. 学習データの大幅拡充

250件から340件へ

v1.3では250件だった学習データを、v1.4では 340件 まで拡充しました。単純な量の増加ではなく、モデルが誤判定しやすいエッジケースを重点的に追加しています。

項目	v1.3	v1.4
総サンプル数	250件	340件
Positive（リスクあり）	87件（34.8%）	145件（42.6%）
Negative（安全）	163件（65.2%）	195件（57.4%）
日本語	139件（55.6%）	153件（45.0%）
英語	111件（44.4%）	187件（55.0%）

データセットの構成

340件の学習データは、3つの検知カテゴリと安全な入力の4グループで構成されています。

リスクカテゴリの内訳

カテゴリ	件数	割合	内容
PII（個人情報）	86件	25.3%	氏名、メール、電話番号、住所、SSN、クレデンシャル等
Injection（プロンプトインジェクション）	38件	11.2%	ジェイルブレイク、情報抽出、権限昇格等
ForbiddenRule（禁止ルール）	21件	6.2%	未公開の財務情報、売上目標、M&A情報等
Safe（安全）	195件	57.4%	公開情報、一般的なビジネスリクエスト等

PII（個人情報）の詳細分類

PIIカテゴリ86件は、さらに以下のサブグループに分類されます。

サブグループ	件数	含まれるデータ
クレデンシャル	33件	APIキー、トークン、パスワード、シークレット、Webhook URL
個人識別情報	31件	氏名、住所、マイナンバー、パスポート、免許証、SSN
金融情報	13件	クレジットカード、口座番号、給与情報
連絡先情報	11件	メールアドレス、電話番号
医療・人事情報	7件	病歴、保険証番号、人事評価
ビジネス機密	6件	プロジェクト名、法務情報

Safe（安全）エントリの構成

195件のSafeエントリは、モデルが 過検知しやすいパターン を意図的にカバーしています。

トピック	件数	例
プレースホルダー	41件	`YOUR_API_KEY`、`<your-token-here>` 等のテンプレート変数
サポート質問	31件	パスワードリセット方法、アカウント復旧の問い合わせ
公開情報	23件	公共施設の住所、上場企業の決算情報、ランドマーク
SQLクエリ例	15件	教育目的のSQL構文（`SELECT`、`CREATE TABLE` 等）
ビジネス業務	12件	プロジェクト進捗報告、会議アジェンダ等
その他	73件	一般知識、技術質問、セキュリティベストプラクティス等

特にプレースホルダー（41件）は、APIキーのような "見た目は機密情報だが実際はダミー値" というパターンを集中的に学習させています。また、SQLクエリ例（15件）は、DROP TABLE = 攻撃 と短絡的に判断しないよう、教育目的のSQLコード例を学習データに含めています。

複数PII検知

全Highエントリのうち 37件（25.5%） が、1つの入力に対して複数のPIIを同時に検知するケースです。例えば「氏名＋メール＋電話番号」のように、複合的な個人情報の漏洩パターンを学習させることで、実際のビジネスシーンに近い複雑な入力にも対応できるようにしています。

言語バランス（カテゴリ別）

各カテゴリにおいて日英のバランスを保つことで、バイリンガル対応の精度を確保しています。

カテゴリ	日本語	英語
PII	45件	41件
ForbiddenRule	11件	10件
Injection	21件	17件
Safe	103件	92件

対照学習の導入

v1.4で最も効果が高かった手法は 対照学習（Contrastive Learning） の考え方です。Safe と High のペアを同時に追加することで、モデルに "境界線" を明確に学習させました。

Safe: "Summarize the project status report."
  → 一般的なビジネスリクエスト（機密タグなし、具体的金額なし）

High: "Project Alpha acquisition deal valued at $150M."
  → 未公開M&A情報（具体的な買収額を含む）

この方法により、「プロジェクト」という単語自体への過剰反応（過学習）を防ぎつつ、本当に機密性の高い情報は確実に検知できるようになりました。

`<think>` タグ内の推論プロセス強化

学習データの <think> セクションにおいて、判断に至るロジックをより詳細に記述しました。特に "なぜ Safe なのか" を明示的に説明するステップを追加しています。

<think>
1. 入力をスキャン
2. 「project status report」は一般的なビジネス用語
3. 機密タグ（confidential, secret）なし
4. 具体的な金額・日付・人名なし
5. 通常の進捗報告の要求
</think>

この推論プロセスの強化により、モデルはキーワードの表面的なマッチングではなく、文脈に基づいた判断 ができるようになりました。

2. 量子化の変更

より高精度な量子化方式を採用

v1.3では Q4_K_M（4ビット量子化）を使用していましたが、v1.4では Q6_K（6ビット量子化） に変更しました。

項目	`Q4_K_M`（v1.3）	`Q6_K`（v1.4）
量子化ビット数	4ビット	6ビット
モデルサイズ	約1.1 GB	約1.6 GB
推論精度	良好	より高精度

Q6_K は Q4_K_M と比較して、モデルの重みをより忠実に保持します。特にセキュリティ監査のような 微妙な文脈の違いを判別する必要があるタスク では、この差が精度に直結しました。モデルサイズは約500MB増加しましたが、1.6GBという軽量さはCPU環境での運用に全く支障のないレベルです。

3. プレースホルダー検知の実装

v1.3の課題：プレースホルダーの誤検知

v1.3では、Set API_KEY=<your-api-key-here> in the config. のようなプレースホルダー（テンプレート変数）を実際のAPIキーと誤検知する問題がありました。これは、学習データ内の「APIキー漏洩 = High Risk」というパターンが強すぎたことが原因です。

v1.4の解決策：多層的なプレースホルダーフィルタリング

v1.4では、SLMの出力に対する 後処理（Post-processing） として、プレースホルダーパターンの検知機能を実装しました。

検知対象パターン:

パターン	例
`YOUR_*` プレフィックス	`YOUR_API_KEY`, `YOUR TOKEN`
`*_HERE` サフィックス	`API_KEY_HERE`, `INSERT_KEY_HERE`
`<...>` 山括弧テンプレート	`<your-api-key-here>`, `<TOKEN>`
`INSERT/REPLACE` プレフィックス	`INSERT_KEY`, `REPLACE_WITH_TOKEN`
連続マスク文字	`xxxx`, `XXXXXXXX`

さらに、SLMが部分的なテキスト（例：API_KEY）をハイライトした場合でも、元のプロンプト内での前後のコンテキスト（例：YOUR_API_KEY）まで展開して判定する コンテキスト展開機能 も実装しました。

SLMの出力: "API_KEY" → リスクあり
コンテキスト展開: "YOUR_API_KEY" → プレースホルダーと判定 → Safe

このアプローチにより、モデル自体の再学習なしに プレースホルダーの誤検知を解消しています。

4. ハルシネーション対策の強化

証拠なき検知の排除

v1.4では、"detected = true だがハイライト（証拠）がない" というケースを 自動的に Safe に修正 するロジックを追加しました。

SLMの出力:
  detected: true
  risk_level: High
  highlights: []  ← 証拠なし

v1.4の後処理:
  detected: false  ← 証拠がないため Safe に修正
  risk_level: Safe

セキュリティ監査において、「何がリスクなのか」を具体的に示せない検知は、ユーザーにとって actionable（行動可能）ではありません。Human-in-the-Loopの設計思想に基づき、証拠を伴う検知のみを報告する 方針を徹底しました。

不正な型のフィルタリング

量子化モデルは、稀に学習データにない型（例："type": "fact"）を出力することがあります。v1.4では、有効な型（PII, ForbiddenRule, Injection）以外のハイライトを自動除去する仕組みも追加しました。

その他の改善

システムプロンプトのMarkdown化

SLMへの指示をプレーンテキストから Markdown形式 に変更しました。見出し、コードブロック、リストを活用した構造化により、モデルが指示をより正確に解釈できるようになっています。

GPU対応

SLMClient に device パラメータを追加し、CPU / GPU / Metal（Apple Silicon）を自動検出・切替できるようになりました。GPU環境では全レイヤーをオフロードすることで、さらなる高速化が可能です。

Regex検知パターンの精緻化

日本語電話番号の検知を、単一パターンから 4つの専用パターン に分割しました。

パターン	対象
携帯電話	070/080/090-XXXX-XXXX
IP電話	050-XXXX-XXXX
固定電話	市外局番対応（東京03、大阪06等）
フリーダイヤル	0120/0800

JSON出力API

audit_json() / detect_json() メソッドを追加し、統計情報を含む構造化されたJSON出力をサポートしました。API連携やログ分析がより容易になります。

パフォーマンス

精度100%を達成しながら、パフォーマンスも良好な水準を維持しています。

指標	結果
平均処理時間	1.49秒
最小	0.86秒
最大	2.65秒
総処理時間（60件）	89.3秒

Q6_K への変更に伴い、v1.3（平均1.26秒）と比較して若干の増加がありますが、すべてのプロンプトが平均1.5秒で処理完了 しており、実運用上の影響はありません。

まとめ：4つの改善が生んだ精度100%

LumeGuard AI v1.4 は、以下の4つの改善の相乗効果により、60件のテストケースで 誤検知ゼロ・見逃しゼロ を達成しました。

改善	内容	効果
1.学習データ拡充	250件 → 340件、対照学習の導入	過学習の解消、境界判定の精度向上
2.Q6_K量子化	4ビット → 6ビット	文脈判別精度の向上
3.プレースホルダー検知	後処理によるパターンフィルタリング	False Positiveの解消
4.ハルシネーション対策	証拠なき検知の排除	信頼性の向上

重要なのは、これらの改善が モデルの再学習だけに頼らない という点です。後処理 [3, 4] とモデル改善 [1, 2] を組み合わせることで、SLMの限界を補いながら高精度を実現しています。

LumeGuard AI は、「オンプレミスで完結」「GPU不要」「1秒台応答」という3つのアドバンテージに加え、精度100% という新たなマイルストーンに到達しました。次のステップとして、さらに多くのテストケースでテストを実施し、さらなる精度向上を目指します。

企業のAI活用を安全に支える守りの盾として、引き続き進化を続けます。

連絡先: contact@lions-data.com

(c) Lions Data, 2026