LumeGuard AI v1.6 マルチベースモデル対応で広がる選択肢
前回の記事では、v1.4で 精度100%（60/60） を達成した4つの技術的改善を解説しました。今回は、v1.6で対応した Gemma 4 ベースモデル と、Qwen3 / Gemma 4 の横並び評価から見えた PII 検知精度のさらなる引き上げ について説明します。
何が変わったのか
v1.6では、これまで唯一の本番モデルであった Qwen3-1.7B に加え、Gemma 4 E2B（Beta） をベースとしたバリアントを新たに提供できるようになりました。さらに、両モデルを横並びで評価する過程で見つかった2つの潜在課題を解消し、複数 PII を含む数百文字テキストの一括検知でも GPU 上で精度100%（20/20） を達成しています。
| 指標（マルチPIIベンチマーク・GPU） | v1.5（Qwen3のみ） | v1.6 Qwen3 | v1.6 Gemma 4 |
|---|---|---|---|
| 正解率 | 17/20 程度 | 20/20（100%） | 20/20（100%） |
| 平均レスポンス | 2.0 秒 | 1.27 秒 | 1.25 秒 |
| 最遅ケース | 11.5 秒（退化ループ） | 2.74 秒 | 1.98 秒 |
| Safe ケース TN | 7/10 | 10/10 | 10/10 |
この結果は、ベースモデルの多様化 と クロスモデル評価で見つかった2点の改善 の組み合わせによって達成されました。
1. なぜ Gemma 4 対応が必要だったのか
1.1 ベースモデル単一依存からの脱却
LumeGuard AI の検出精度は、ベースモデル × 学習データ × プロンプト × 生成パラメータ の積で決まります。本番が長らく Qwen3-1.7B 一本だったため、「精度100%」はあくまで「Qwen3 という特定アーキテクチャ上での結果」であり、レシピそのものの普遍性は検証できていませんでした。
ベースモデルを変えて同じパイプラインで再学習し、同等の性能が得られるかを確認することは、「学習データとプロンプト設計が base-model-agnostic に効いているか」 の重要な検証です。これが確認できれば、将来のベースモデル更新（次世代 Qwen / Gemma）にも同じレシピを横展開できます。
1.2 デプロイ要件の多様化に応える
実利用面でも、ベースモデルを選べることには明確な意味があります。
- 導入企業ごとのライセンス・運用ポリシーに合わせて選べるベースモデルが複数あること
- Gemma ファミリーで社内 SLM を統一したい組織への展開オプションが提供できる
- VRAM・モデルサイズ・レイテンシの制約に応じて「軽い方／速い方」を選べる
- アーキテクチャの違い（Gemma 4 E2B は Per-Layer Embeddings 採用、有効パラメータ 2.3B / 総 5.1B）の特性差を、お客様のワークロードで実測できる
1.3 「比較がないと見えないバグ」を炙り出す
これは事後的に得られた、しかし最も大きな収穫でした。後述する 退化的な <think> ループ問題 は、Gemma 4 を組み込んでベンチマークを回し始めて初めて顕在化したものです。ところが原因を追っていくと、Qwen3 でも特定ケース（人事評価シート、システム設計書）で 同じ症状が無言で発生していた ことが判明しました。
Qwen3 単独運用の頃は、最遅 11.5 秒という値を「ちょっと遅いケース」として流していたのです。観点を変える2つ目のモデルを入れることで、1つ目のモデルのバグも見えるようになる。 これは複数バリアント運用の副次的な、しかし見逃せない効果でした。
2. 共通レシピでの再学習：Gemma 4 E2B ファインチューン版
Gemma 4 バリアントは、Qwen3 とまったく同じ条件で学習しています。
| 項目 | 値 |
|---|---|
| 手法 | LoRA（r=16, α=32） |
| 学習率 | 2e-4（Cosine scheduler） |
| エポック数 | 5 |
| 学習データ | 370 件（Qwen3 と完全共通） |
| 出力形式 | <think>...</think>{JSON} 形式（共通） |
| 量子化 | GGUF Q6_K（共通） |
| ベースモデル | Qwen3-1.7B Instruct / Gemma 4 E2B IT |
Gemma 4 E2B は Google Gemma 4 ファミリーの軽量版で、Per-Layer Embeddings という工夫により有効パラメータ 2.3B（総 5.1B）で動作します。Qwen3-1.7B と比較するとファイルサイズはやや大きい（Q6_K で 3.6 GB vs 1.4 GB）ものの、推論性能は同等水準です。
PII 特化テスト（50件・日本語のみ・20種類の PII カテゴリ）の結果は以下の通りです。
| 指標 | Qwen3-1.7B | Gemma 4 E2B |
|---|---|---|
| Accuracy | 100.0%（50/50） | 98.0%（49/50） |
| Precision | 1.00 | 0.97 |
| Recall | 1.00 | 1.00 |
| F1 Score | 1.00 | 0.98 |
| False Positive | 0 | 1 |
| False Negative | 0 | 0 |
Gemma 4 で唯一残っている誤判定はプレースホルダー形式 090-XXXX-XXXX の境界ケースで、これは Qwen3 の初期版でも苦戦していたパターンです。同じレシピで別ベースモデルが 98% 以上の高精度を再現できた こと自体、レシピの普遍性を裏付ける結果と言えます。
3. クロス評価で見つかった2つの潜在課題
両モデルを共通の マルチPIIベンチマーク（PII 含有10ケース・Safe 10ケース・各3試行）に通したところ、両モデルに共通する2つの問題 が浮かび上がりました。
3.1 課題A：一般ビジネス文書を PII 扱いする False Positive
症状: 「2025年度第1四半期の売上報告書をお送りします…」のような PII を一切含まないビジネス文書 が、4 構成中3 構成で False Positive になっていました。検出されていたのは「2025年度第1四半期」「売上報告書」のような 文書種別ラベルや会計期間表記 で、モデルが「組織のメタ情報＝個人情報」と過剰般化していたのが原因です。
最初に試して失敗したアプローチ: System prompt の Safe セクションに「文書種別名（売上報告書、月次レポートなど、文書のタイプを示す一般語）／会計年度・四半期表記（2025年度第1四半期、上半期 など、組織の時間軸ラベル）」のように 詳しい説明と具体例を盛り込む やり方。
結果は モグラ叩き でした。SAFE-01 は通るようになっても、別ケースで新規 False Positive が出たり、PII 取りこぼしが発生したりと、副作用が次々に漏れ、詳述版2種類はいずれも19/20止まりで決定打になりませんでした。
最終的に効いたアプローチ: Safe セクションへの ラベル列挙1行のみの追加。
- 業務上の依頼（議事録作成、データ整理）
- 攻撃意図のないSQL/コード
+ - 文書種別名, 帳票名, 会計期間
- Work requests (meeting minutes, data processing)
- SQL/Code without malicious intent
+ - Document Type, Form Name, Accounting Period
説明も括弧書きの例示も置かず、ラベル名を3つ並べただけ。これだけで全4 構成で SAFE-01 が解消し、副作用ゼロでした。
3.2 なぜ「最小限のラベル列挙」だけが効くのか
これは LumeGuard AI 固有というより、ファインチューニング済み小型モデル全般に当てはまる経験則 だと考えています。
- ファインチューニングで挙動の大部分は固定されており、system prompt はもはや「ヒント」程度の影響しか持たない
- にもかかわらず、長く詳細な追記は推論経路を非線形に摂動し、別の関係ない場所 で False Positive・PII 取りこぼし・退化的
<think>ループを引き起こす - ファインチューニングされた語彙の中で「Safe 側に寄せたい概念のラベル」を1行でピン留めすると、副作用なく重みが掛かる
教訓として、ファインチューン済みモデルの system prompt 調整は、まず語のラベル1行で試す。 プロンプトをさらに詳細化したくなる前に、生成パラメータか後処理側で対応できないかを先に検討すべきです。
3.3 課題B：退化的な <think> ループ問題
症状: 技術文書や HR 系プロンプトに対して、<think> 内で同じ文章を延々と繰り返し、トークンバジェットを使い切ってフォールバックする現象。例えば MULTI-04（人事評価シート） で 11.5 秒 かかっていたケースです。
最初は Gemma 4 固有の癖と考えていましたが、ベンチマークを Qwen3 にも横展開したところ、Qwen3 でも MULTI-04 や SAFE-03（システム設計書）で同種のループが一定確率で発生 していることが判明しました。
解決策: SLMClient の生成パラメータを下記のように変更しました。
- REPEAT_PENALTY_DEFAULT = 1.0 # No-op for Qwen3
+ REPEAT_PENALTY_DEFAULT = 1.1 # Anti-loop pressure for Qwen3
REPEAT_PENALTY_GEMMA4 = 1.1 # Same value for Gemma 4
加えて、Gemma 4 は <think> 推論が長くなりがちなため、トークンバジェットも引き上げています（DEFAULT_MAX_TOKENS_GEMMA4 = 1024、オーバーフロー時のリトライは 2048）。
バリアントは GGUF ファイル名から自動判別され、利用側は device と n_gpu_layers だけ指定すれば適切な値が自動適用される設計です。
結果:
| ケース | 改善前 | 改善後 |
|---|---|---|
| MULTI-04（人事・Qwen3 GPU） | 11.5秒（退化ループ） | 1.54秒 |
| SAFE-03（技術文書・Gemma 4 GPU） | 退化ループ発生 | 1.56秒 |
temperature=0 を維持したまま決定論性は保てます。repeat_penalty=1.1 は確率分布の頭打ち補正であり、greedy decode と矛盾しません。「決定論性のために penalty 系は 1.0 に置くべき」という思い込みは、ここで明確に否定されました。
4. ベンチマーク結果
PII 含有 10 ケース・Safe 10 ケース - 各3回試行
GGUF Q6_K- コンテキスト長: 4096
- temperature: 0.0
- RTX 2070 SUPER（8 GB VRAM）
4.1 平均レスポンスタイム（秒）
| バリアント | デバイス | PII | Safe | 全体 |
|---|---|---|---|---|
| Qwen3-1.7B | CPU | 5.505 | 3.127 | 4.316 |
| Qwen3-1.7B | GPU | 1.733 | 0.816 | 1.275 |
| Gemma 4 E2B | CPU | 5.385 | 2.780 | 4.082 |
| Gemma 4 E2B | GPU | 1.563 | 0.942 | 1.252 |
4.2 検出精度
| バリアント | デバイス | 全体（20） | PII (TP) | Safe (TN) |
|---|---|---|---|---|
| Qwen3-1.7B | CPU | 19/20（95.0%） | 9/10 | 10/10 |
| Qwen3-1.7B | GPU | 20/20（100%） | 10/10 | 10/10 |
| Gemma 4 E2B | CPU | 20/20（100%） | 10/10 | 10/10 |
| Gemma 4 E2B | GPU | 20/20（100%） | 10/10 | 10/10 |
4.3 読み取れること
- GPU での Accuracy は両モデルとも100%。 インタラクティブな PII 監査用途として実用域に到達。
- GPU 化の効果は明確で 3〜4 倍速。 32 物理コアの Threadripper を相手にしてもこの差で、コア数の少ない一般的な CPU 環境では GPU の優位はさらに広がります。
- Qwen3 GPU と Gemma 4 GPU はほぼ同性能。 平均で Gemma 4 が約11% 速いものの、誤差レベル。
- 唯一の不一致は Qwen3 CPU の MULTI-03（医療情報）。 同じ Qwen3 でも GPU では PASS。
temperature=0でも CPU/GPU 間の浮動小数点演算経路の違いが、判定境界ケースで差を生むことが確認されました。本番想定の GPU では問題なし。 - VRAM は十分余裕あり。 Qwen3 Q6_K で 1.4 GB、Gemma 4 Q6_K で 3.6 GB のモデルファイルに対し、実測オフロード時の使用量は約 2 GB。8 GB VRAM のミドルレンジ GPU で十分動作します。
5. バリアントの選択指針
両バリアントとも GPU 上で精度100%・1.3 秒前後のレスポンスとほぼ等価ですが、現場での選択指針は以下の通りです。
| 状況 | 推奨バリアント |
|---|---|
| 本番運用、最小 VRAM・モデルサイズ重視 | Qwen3-1.7B（Production） |
| Gemma ファミリーで社内モデルを統一したい | Gemma 4 E2B（Beta） |
| CPU-only 環境で動かす可能性がある | Gemma 4 E2B（CPU でも100% を維持した唯一の構成） |
| ベースモデル横断のロバスト性評価 | 両方を併走させて差分監視 |
導入時はモデルファイルを切り替えるだけで完結する設計です。バリアント別の生成パラメータ（repeat_penalty や max_tokens）は SLMClient がモデルファイル名から自動判別して適用するため、利用側で切り替えロジックを書く必要はありません。
まとめ：マルチベース対応が広げた可能性
LumeGuard AI v1.6 は、以下の3つの取り組みにより、ベースモデル選択の自由度 と 検知精度のさらなる向上 を同時に実現しました。
| 改善 | 内容 | 効果 |
|---|---|---|
| 1. Gemma 4 E2B 対応 | Qwen3 と共通レシピでファインチューン | デプロイ選択肢の多様化、レシピの普遍性を実証 |
| 2. System prompt 最小調整 | Safe セクションにラベル1行追加 | 一般ビジネス文書の False Positive を完全解消 |
3. repeat_penalty 引き上げ |
1.0 → 1.1（両モデル共通） | 退化ループを根絶、最遅 11.5 秒 → 2.7 秒 |
重要なのは、これらの改善が ベースモデルを増やしたからこそ見えた という点です。Qwen3 単独運用では「ちょっと遅いケース」として流されていた退化ループ問題は、Gemma 4 比較の中で初めて優先度高く修正対象になりました。観点を変えるモデルを足すことが、既存モデルのバグも顕在化させる という、SLM 多バリアント運用の副次効果は、今後のベースモデル選定にも活かしていきます。
LumeGuard AI は、「オンプレミスで完結」「GPU 不要でも動作」「1秒台応答」という3つのアドバンテージに加え、マルチベースモデル対応 という新たな選択肢を獲得しました。次のステップとして、ベンチマークケースの多言語・多業種への拡張、そして次世代ベースモデル（Qwen4 系・次期 Gemma など）への同レシピの再適用を進めていきます。
企業の AI 活用を安全に支える守りの盾として、引き続き進化を続けます。
(c) Lions Data, 2026