1. 発端 ― AIが「639件」と書いた。実際は0件だった #

以前、私たちのローカル LLM が、自動生成した監視レポートに「認証失敗 639件」と書いたことがあります。実際にログを確認すると、その時間帯の認証失敗は 0件 でした。LLM が、もっともらしい数字をそのまま作り出したのです（この顛末は「ローカルLLMが監視レポートの数値を捏造した話と、その対策」に書きました）。

これは LLM の不具合ではなく、性質です。LLM は「文脈的にもっともらしい文章」を生成するのが得意で、「事実として正確な数字」を保証する仕組みは、もともと持っていません。普段は正しい数字を書くこともありますが、それは「正しさが保証されている」のではなく「たまたま当たっている」だけです。

AI Ops において、これは見過ごせません。信じられない監視レポートは、無いのと同じか、むしろ危険です。「認証失敗639件」を信じて誰かが対処に動けば、存在しない問題に時間を使う。逆に、本当の異常が埋もれるかもしれない。

そこで私たちは、「LLM が書いた数字を、そのまま信じない」仕組み ―― ハルシネーション監査 ―― を組み込みました。本記事はその実装の考え方です。

2. 原則 ― 「事実」は LLM が作らない。ログが作る #

監査の出発点は、役割の分離です。

監視レポートに出てくる 数字・件数・IPアドレス・時刻 といった「事実」は、LLM の文章生成からではなく、実機ログに対する決定論的なクエリから取得します。LLM の役割は、確定した事実を、人間が読みやすい文章にまとめることに限定する。

• 事実（数字・対象・時刻） → ログへのクエリが作る（ground truth）
• ナラティブ（要約・説明・文章） → LLM が作る

この分離だけで、捏造の入り込む余地は大きく減ります。LLM に「ログを読んで件数を数えて」と頼むと数え間違い（＝捏造）が起きますが、件数を先に集計して確定値を渡し、LLM には「この数字を使って状況を説明して」と頼めば、数字はもう動きません。

3. それでも残る捏造を「監査」で捕まえる #

役割を分離しても、LLM が文章を書く過程で、渡していない数字を勝手に補ったり、対象を取り違えたりすることはあります。そこで、LLM が生成したレポートを、出力後にもう一度、元ログと突き合わせる監査ステップを置きます。

おおまかな流れはこうです。

1. ログを集計して「確定した事実」を作る        ← ground truth
2. LLM に確定値を渡してレポート文を生成させる
3. 生成されたレポートから、定量的な主張を抽出する
   （例: 「ホストA で認証失敗が N 件」）
4. 各主張を、元ログ（1の確定事実）と照合する
5. 裏付けの無い主張・矛盾する主張を検出したら、
   確定値へ置換 or レポートを再生成する
6. 検出した不一致は記録する（いつ・どこで・何を捏造したか）

ポイントが2つあります。

照合は決定論的に行う。 突き合わせを別の LLM にやらせません。ハルシネーションを、ハルシネーションしうるもので監査しても意味がない。照合は、元ログという動かない事実に対する、機械的なチェックです。

「主張」を検証単位にする。 自由文の中から後で数字を拾うより、LLM の出力を最初から検証しやすい構造（「対象・指標・値」の組）で受け取るほうが、照合が堅くなります。文章の体裁ではなく、主張の一つひとつが ground truth に裏付けられているかを見ます。

照合の様子のイメージ（値は説明用）:

[AUDIT] report_id=████
  claim: host=A  metric=auth_fail  value=639
  truth: host=A  metric=auth_fail  value=0
  => MISMATCH  （確定値へ差し替え or 再生成）

  claim: host=B  metric=port_scan  value=47
  truth: host=B  metric=port_scan  value=47
  => OK

4. これは「LLMを賢くする」話ではない #

ここが設計思想として大事なところです。ハルシネーション監査は、LLM をより賢く・より正確にしようとするアプローチではありません。「LLM は間違えるもの」という前提を変えずに、出力を構成上（by construction）信頼できるものにするアプローチです。

LLM が間違った数字を書いても、監査で ground truth に突き合わされるので、最終的に出るレポートの数字は担保される。LLM の賢さに信頼を預けるのではなく、検証の仕組みに預ける。

5. 設計上のトレードオフ（正直に） #

万能ではありません。

1. コストが増える。 集計・生成・監査と、パスが増えます。ただし本番の監視レポートで「信じられること」の価値は、このコストに見合うと判断しています。
2. 捕まえられるのは「事実・定量」の捏造。 「認証失敗の件数」のような検証可能な主張は照合できますが、「この傾向は危険に見える」といった主観的なナラティブの妥当性までは機械照合しにくい。だからこそ、LLM の役割を要約・整形に限定し、判断はさせない設計にしています。
3. ground truth が正しい前提。 監査は「元ログが事実」という前提に立ちます。ログ収集や機器判定そのものの正確性が土台になります（収集・自動判定の仕組みは別記事で扱っています）。

6. BASTION の根っこと同じ原則 #

この「LLM が書いた数字を信じない」という姿勢は、BASTION 全体の設計と地続きです。

攻撃 IP の最終判定や、ファイアウォールへのブロック実行といった、システムを実際に動かす判断は、LLM ではなく実機ログに基づく決定論的な判定で行っています（多層相関キャンペーン検知の仕組み）。LLM が得意なのは自然言語の要約や整形であって、本番の意思決定ではない ―― この線引きは、「美しい設計ほど、実データで疑う」で書いた検証規律そのものです。

ハルシネーション監査は、その同じ原則をレポート層に適用したものです。LLM も、（侵害されうる）Agent も、私たちにとっては「信用せず、検証する」対象です。

7. まとめ #

AI に任せる範囲が広がるほど、「AI の出力をどう検証するか」が、製品の信頼を決めます。

• 事実（数字）は LLM に作らせず、ログから取る
• LLM が書いた主張は、出力後に ground truth と突き合わせる
• 照合は決定論的に。ハルシネーションをハルシネーションで監査しない
• LLM の役割は要約・整形に限定し、判断はさせない

LLM が書いた数字を、鵜呑みにしない。地味ですが、本番で AI Ops を安心して回すための土台です。