LLM に「捏造の判定」を任せると正直な開示まで落とす：合否はコードで照合する

LLM に捏造審査を任せるな：事実照合はコードに持たせ、LLM は修正指示役へ

審査役の LLM に「捏造判定」を任せた場合、正直な開示や作業前提さえも捏造と誤判定され、全提案が不合格になるリスクがある。qwen3.5:35b-a3b では実案件 40 件の提案が全て不合格となった事例がある。この問題を防ぐには、最終的な合否判定を「許可された事実の一覧との照合」を行うコードに委ね、LLM の役割を品質点の付与と修正指示の提示に限定する必要がある。

起きたこと：審査役の誤判定が全提案を止めた

実案件で 40 件の提案に対し、審査役として qwen3.5:35b-a3b を使用した際、「実務経験はありません」という正直な開示と「いただいた原稿をもとに」という作業の前提が捏造と判定された。その結果、実案件 40 件の提案が全て不合格になった。

これは、LLM が「捏造」を検出する際に、事実確認が不十分なまま否定文や開示を誤って検知してしまう現象である。審査役の誤指摘を「止める理由」として扱った場合、審査役が誤るたびに全提案が落ちる構造になっていた。

なぜそうなるか：LLM の推論と事実照合の混在

LLM は文脈から「捏造」を推測する能力はあるが、特定の事実（例：「実務経験があるかないか」）について、許可された事実一覧との厳密な照合を行うには向いていない。LLM が「経験がある」という主張を検出しようとする際、否定文や開示のニュアンスまで含めて判断しようとし、結果として誤判定が発生する。

この仕組みの問題は、LLM が「推論」に頼りすぎており、「事実の存在・非存在」を確定させる役割を担うべきではない点にある。LLM は「品質点」と「修正指示」を出すことで価値を発揮し、合否の最終判定は、定義された事実一覧と照合するコード（正規表現等）が行うべきである。

確認手順 / チェックリスト

1. **YAML による事実構造化の確認** 自環境で「能力」「持っていないもの」「確認済み事実」「未確認事項」を ID 付きで YAML 形式に構造化しているか確認する。これは LLM が参照すべき唯一の事実源となる。

2. **正規表現による主張検出の実装** コード上で、「確認した」「経験がある」型の主張を検出する正規表現を実装し、否定文を除外するロジックが動作しているか確認する。これが最終権限として機能していることを検証する。

3. **審査役の役割変更** 現在の LLM 審査役が「合否判定」を行っている場合、それを「記録して上書きする理由」の提示に限定し、合否はコード側の照合結果に基づいて出すように変更する。

4. **モデル選定の検証（任意）** 別系統モデルを審査役に使用する検討を行う場合、gemma3:12b と qwen3.5:35b-a3b の比較基準（正直な開示の扱い、未確認主張の検出）でテストする。gemma3:12b は約 2 倍速く、サイズは約 1/3 で、2 問中 2 問正解した実績がある。

適用範囲の限界

この手法は、「許可された事実の一覧」が事前に整備されている環境に限定される。一覧がない場合や、事実の定義が動的に変化するケースでは、YAML 構造化とコードによる照合が機能しない可能性がある。

また、本手法は「捏造判定」をコードに持たせることで解決するものであり、LLM の推論能力そのものを否定するものではない。LLM は依然として品質点や修正指示の生成には有効であるが、最終的な合否判定においては、事実照合の精度が最も重要となる。

実案件での Shadow Run 結果（捏造 0 件、合格提案 5 件、合格率 83%、要確認率 8%）は、人間による採点なしに合否を出せたことを示しているが、これは「事実一覧の整備」と「コードによる最終判定」が機能した場合の結果である。一覧の整備が不十分な環境や、事実定義が複雑すぎるケースでは、同様の結果が得られない可能性がある。