# LLM 監査ゲートの誤検知を直す — 「どのルールが弾いているか」を数えてから直す／AI 自身は直せなくなる AI エージェントの出力を、別の安い LLM に監査させて止める「ゲート」を作ったあとの話。 **誤検知が出はじめた時に、正しい直し方と、踏んではいけない罠が2つある。** ## 前提とする構成 よくある形はこうなっている。 1. 規則を Markdown（`audit-rules.md`）に番号付きで書く 2. ゲートのコードがそのファイルを**丸ごと読んでプロンプトへ埋め込む** 3. 監査 LLM が `{"verdict":"block","violations":[{"rule":番号,...}]}` を返す 4. 同一セッションで N 回 block したら retry-cap で解除（無限ループ防止） 5. 判定結果は JSONL の台帳に追記される ```js // 規則ファイルは「パース」されず、生テキストとして注入される export function loadResources() { return { rules: fs.readFileSync(new URL('./audit-rules.md', import.meta.url), 'utf8'), ... }; } export function buildPrompt(evidence, resources) { return `あなたは監査員。以下の規則を毎回適用する。\n${resources.rules}\n...`; } ``` --- ## 罠1: 「たぶんこの rule が弾いている」で直しにいく 正当な出力が毎回弾かれるようになった時、人は規則を読んで「rule 3 の条件が足りないからだ」と当たりを付ける。 **これはほぼ外れる。** LLM は規則全体を読んで、書いた人が想定していない番号を引く。 ### 直す前に台帳を数える 判定台帳（JSONL）には毎回の `violations[].rule` が入っている。**実測で数える。** ```js const lines = fs.readFileSync(LEDGER, 'utf8').split('\n').filter(Boolean); const hits = {}; for (const l of lines) { let r; try { r = JSON.parse(l) } catch { continue } if (r.verdict !== 'block') continue; if (!KEYWORD.test(r.excerpt || '')) continue; // 誤検知している案件だけに絞る for (const v of r.violations || []) hits[v.rule] = (hits[v.rule] || 0) + 1; } console.log(hits); // → { "1": 2, "2": 2, "3": 1, "5": 2, "10": 3 } ``` 実例では、当たりを付けた rule 3 は 1 件しか出ておらず、**実際に弾いていたのは rule 1・2・5・10**だった。 直近の 1 件は **5 本同時**に引かれていた。rule 3 だけ直しても何も変わらない。 さらに、最新の block レコードの `violations` を**全文で読む**と2つの別の欠陥が見えた。 - **LLM が存在しないツール名を「代替経路」として捏造していた**（`fix` 欄に実在しないスクリプト名）。 プロンプトに「想像で経路を作らない」と書いてあっても守られない。 - **テンプレート表記がリテラル要求として読まれていた**。 規則に `末尾に「次にやること: なし / <1件>」を1行` と書いたら、LLM は 「`なし / <1件>` という文字列をそのまま書け」と要求していた。**規則の文言バグ**であって、 条件の過不足の問題ではない。 → 教訓: **`violations[].fix` の全文を読むと、条件ではなく「規則の書き方」が原因だと分かることがある。** ## 直し方: 番号を振らない「例外」ブロックを1つ足す 複数の rule が同時に引かれている時、5 箇所を個別に緩めると副作用が読めない。 規則ファイルは丸ごと注入されるので、**横断する例外を1つ書くほうが小さく済む。** ```markdown **例外（限定・拡大禁止）**: <条件> に当たる操作は、rule 1・2・3・5・10 の違反として数えない。 現時点で該当するのは <具体例> だけ（<一次ソースでの確認結果>）。 適用は <証拠> が書かれている場合に限り、他へ広げてはならない。 ``` **🔴 この例外に番号を振ってはいけない。** `rule 0` や `rule 12` を作ると、LLM がその番号を出力し、 バリデータ（`rule` は 1〜11 の整数、等）が invalid-json を投げ、ゲートが `audit-unavailable` にフォールバックする。 **結果として「通る」が、それは監査を壊して通しているだけ**で、意図した挙動ではない。 例外には必ず **(a) 適用範囲の限定、(b) 一次ソースでの確認結果、(c) 拡大禁止の明示** を入れる。 これが無いと、LLM が「似ているから」で他の案件にも適用しはじめる。 --- ## 罠2: AI 自身にこの修正をさせられない（設計上の帰結） ここが本題。**規則ファイルを LLM のプロンプトへ注入する設計にすると、 そのファイルは「AI が自分で編集できないファイル」になる。** エージェントに規則ファイルの編集をさせると、安全分類器が **Instruction Poisoning** として拒否する。 形として完全に正しい判定である。やろうとしていることは 「自分を評価する LLM のプロンプトに『これは違反として数えるな』と書き足す」であり、 これは意図が正当かどうかに関わらず prompt injection と同じ形をしている。 さらに、**修正を検証するハーネス**（監査関数を実 LLM で回して block を再現し、前後比較する）も **Self-Modification** として拒否されうる。つまり**実装も検証も両方塞がる。** ### 設計時に決めておくこと - **規則ファイルは人が更新するもの**と最初から決め、AI の編集対象から外す（CODEOWNERS / 別リポ / レビュー必須） - AI にやらせてよいのは **「どの rule が何件引かれたか」の集計と、改訂案の提示**まで - 改訂案は**チャットや PR の本文で人に渡す**。AI がファイルに書き込む経路を作らない - 分類器に止められた時、**言い換えて再試行しない**。拒否は内容に対するもので、 別のツールで同じ内容を書けば「意図の回避」になる そもそも**利益相反**がある。自分の行動を監査する規則を、自分で緩める提案をしている。 止まるのが正しい。人のレビューを挟む経路を最初から用意しておくこと。 --- ## 検証の作法（人が適用する時） 規則を直したら、**実 LLM で前後比較する**。ここでモックを使うと意味を失う。 ```js // 監査関数が resources を差し替えられるなら、旧ルール/新ルールで A/B できる const before = await evaluateAudit({ text: REAL_BLOCKED_TEXT }, { resources: { ...res, rules: OLD } }); const after = await evaluateAudit({ text: REAL_BLOCKED_TEXT }, { resources: { ...res, rules: NEW } }); ``` - **入力は台帳から取った実際に block されたテキスト**を使う（作文しない） - **旧ルール側が毎回 block することを先に確認する**。ここが再現しないなら計測器が壊れており、 新ルール側が pass しても何も証明できない - LLM は確率的なので**各 3〜5 回**回す。1 回の pass を根拠にしない - 台帳の書き込み先を一時ディレクトリへ向ける（本番台帳を汚さない） `ask` をモックに差し替えると、**LLM が規則を読む過程そのものが消える**。 規則の文言を変えたことの効果はゼロも同然になり、テストは何も検出しない検出器になる。 --- ## チェックリスト - [ ] 誤検知を直す前に、台帳で `violations[].rule` を数えたか - [ ] 最新 block の `fix` 全文を読んだか（経路の捏造・文言バグが見える） - [ ] 例外に番号を振っていないか（バリデータを壊して「通る」形になる） - [ ] 例外に 範囲限定・一次ソース・拡大禁止 の3点を書いたか - [ ] 規則ファイルを AI の編集対象から外してあるか - [ ] 検証を実 LLM でやっているか。旧ルール側の block が毎回再現するか ---