LLM 監査ゲートの誤検知を直す — 「どのルールが弾いているか」を数えてから直す／AI 自身は直せなくなる

AI エージェントの出力を、別の安い LLM に監査させて止める「ゲート」を作ったあとの話。 誤検知が出はじめた時に、正しい直し方と、踏んではいけない罠が2つある。

前提とする構成

よくある形はこうなっている。

1. 規則を Markdown（audit-rules.md）に番号付きで書く
2. ゲートのコードがそのファイルを丸ごと読んでプロンプトへ埋め込む
3. 監査 LLM が {"verdict":"block","violations":[{"rule":番号,...}]} を返す
4. 同一セッションで N 回 block したら retry-cap で解除（無限ループ防止）
5. 判定結果は JSONL の台帳に追記される

// 規則ファイルは「パース」されず、生テキストとして注入される
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 が入っている。実測で数える。

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つ書くほうが小さく済む。

**例外（限定・拡大禁止）**: <条件> に当たる操作は、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 で前後比較する。ここでモックを使うと意味を失う。

// 監査関数が 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 が毎回再現するか