AIが嘘をつく #

BASTIONは15分ごとにインフラログをローカルLLMで分析し、Slackにレポートを送信します。ある日のレポートにこう書かれていました。

639件の認証失敗。239件のVPN認証エラー。数字だけ見れば「異常」と判断しそうな値です。

しかし実際のログを直接集計すると、認証失敗は81件、VPN認証エラーは102件でした。さらに調査を進めると、LLMに渡していた入力データには「認証失敗: 0回」「VPNエラー: エラーなし」と書かれていました。LLMは入力の「0」を「639」に書き換えていたのです。

抜き取り検査の方法 #

レポートの数値が正しいかを検証するため、実ログを直接集計してレポート値と突合する抜き取り検査を実施しました。

検査手順:
1. レポートに記載された数値を項目ごとに抽出
2. AI-SLOGサーバー上で実ログを直接grep/countして実測値を取得
3. レポート値と実測値の乖離率を計算
4. ±10%以内を「合格」、それ以上を「要調査」と判定

8項目を検査した結果：

項目	レポート値	実測値	判定
FWブロック（特定IP）	477件	489件	合格（+2.5%）
認証失敗	639件	81件	捏造（-87%）
アカウントロック	669件	66件	捏造（-90%）
認証エラー	239件	102件	捏造（-57%）
クラウドアプリ全項目	該当なし	0件	合格

8項目中4項目でハルシネーション（数値捏造）が検出されました。

2つの原因が併存していた #

原因を切り分けるため、「LLMに渡す前の入力データ」を確認しました。

原因Aはスクリプトのバグ（決定論的に修正可能）。原因BはLLMの本質的な限界です。

対策: 3層のフォールバック #

LLMのハルシネーションは「防ぐ」のではなく「検知して差し替える」アプローチを取りました。

第1層: 入力データの正確性を担保する #

スクリプトのバグを修正し、全期間累計ではなく直近60分のデータだけをLLMに渡すようにしました。入力が正しければ、LLMが正しい出力を生成する確率が上がります。

第2層: プロンプトで数値の捏造を禁止する #

LLMへのプロンプトに以下のルールを追加しました。

【数値の絶対ルール】
- 入力データに記載されていない数値は出力のどこにも書いてはならない
- 入力に「0件」と記載されている項目は出力でも0件とすること
- evidence セクションの数値は入力データからの直接転記のみ許可
- 推測・補完・概算は禁止

第3層: 出力の数値を入力と照合して検知する #

LLMの出力が生成された後、入力データと突合して矛盾を検知するフォールバック機構を実装しました。入力に「0回」と書かれている項目が出力で非ゼロになっていたら、自動的に安全な文面に差し替えます。

入力: 「認証失敗: 0回」
LLM出力: 「認証失敗が639件発生」
  → 照合: 入力は0回なのに出力が639 → 不一致検出
  → 差し替え: 安全な文面に自動置換

修正結果 #

3層のフォールバックを実装した後、同じ条件で再検証しました。

項目	修正前	修正後
認証失敗（入力: 0件）	639件（捏造）	0件（正確）
ロック（入力: 0件）	669件（捏造）	0件（正確）
認証エラー（入力: なし）	239件（捏造）	0件（正確）
ハルシネーション検出フォールバック	造語・記号のみ検出	数値捏造も検出可能

LLMがプロンプトルールに従って0値を維持し、ハルシネーション検出フォールバックの発火もなし。入力の正確性担保（第1層）+ プロンプト強化（第2層）の組み合わせで、第3層の検出フォールバックに頼る前に問題が解消しました。

まとめ #

ローカルLLMによるセキュリティ監視で、LLMが入力「0件」を「639件」に捏造するハルシネーションが発生しました。原因はスクリプトのバグ（全期間累計の混入）とLLMの数値捏造の2つが併存していました。

対策として、入力データの正確性担保→プロンプトによる数値制約→出力の事後照合検知の3層フォールバックを実装しました。修正後の再検証ではLLMが正確に0値を維持し、ハルシネーション検出フォールバックの発火もなく、対策の有効性を確認しました。

AI監視は万能ではありません。AIの出力を信頼するのではなく、制約し、検証し、フォールバックを用意する。この設計思想が、ローカルLLMでセキュリティ監視を実用化するための鍵です。