LLM にコード監査させるときは、静的解析メモの主張を別の呼び出しでコードと照合させる（verify-show）
静的解析のメモに「ここは安全チェック済み」と嘘が書かれていると、LLM の脆弱性検出率が最大 19 ポイント落ちる。偽の「危険」は疑うのに偽の「安全」は鵜呑みにする傾向があるため、監査とは別の LLM 呼び出しでメモの各主張をコードと照合し、矛盾を明示してから監査側へ渡す。
分かったこと（PrimeVul の関数 916 組、計 16,572 回の監査）
- 偽の安全保証で、glm-5.2 と kimi-k3 の検出率が 19 ポイント低下。修正済み関数に偽の危険警告を付けても、11 構成いずれも精度は有意に下がらなかった。
- deepseek-chat がメモに異議を唱えた割合は、偽の危険警告で 80%、偽の安全保証で 28%。照合だけを別の呼び出しで頼むと、偽の安全保証の 76% を反証できた。誤りの主因は「確認できない」より「確認しない」こと。
- 正しいメモをすべて見せても、DeepSeek の 2 構成で精度は +2 ポイントにとどまり有意差なし。
対策：verify-show
- 監査の前に、別の LLM 呼び出しで「メモの各主張がコードで成り立つか」だけを判定させる。
- 矛盾した主張も消さずに「コードと矛盾」と明示して、監査側のプロンプトへ渡す。
- 監査側は通常どおり脆弱性を探す。
最終試験（未使用の 300 組で 1 回だけ）で、偽の安全保証が付いた脆弱な関数 141 件では deepseek-chat の検出率が 54% → 66% に改善（有意）し、正しいメモの条件の精度も維持。qwen-plus は 78% → 84% だが有意差なし。
注意点
- 監査プロンプトの中で「メモを確認せよ」と書くだけでは、別データで有意な改善を再現できなかった。照合は呼び出しを分ける。
- 評価は研究者の自作解析器のメモと、単独で監査した C/C++ 関数。実際の解析ツール出力での検証は今後の課題。
- 自分のパイプラインでは、コメント・コミットメッセージ・PR 説明など「コード以外の主張」も同じく監査 LLM の判断をゆがめる入力として扱う（外部入力の扱いは プロンプトインジェクションを多層で検知する（ルール→分類器→LLM 判定））。