問題

LLM に候補の採用可否を判断させるとき、過去の否認例を毎回そのまま列挙すると、判断が個別事例への類推に寄りやすい。否認例が増えるほど、AI は「なぜ否認したか」よりも「似た候補かどうか」に引っ張られ、再利用可能な知識まで落とす可能性がある。

判断基準

否認履歴は事実ログとして保持し、候補抽出時に直接読む主入力にはしない。代わりに、定期的に否認履歴を分析し、短い判断ポリシーへ抽象化する。ポリシーには、採用する条件、拒否する条件、ユーザー確認に回す境界例、狭い候補を一般化するルール、最近の否認傾向を含めるとよい。

この分離により、履歴の詳細を毎回読み直さなくても、再現性のある判断基準として使える。事実ログは根拠の確認やポリシー更新に使い、日常の候補判定では抽象化されたポリシーを参照する。

適用場面

この考え方は、LLM がメモ候補、ナレッジ候補、レビュー指摘、分類ラベルなどを継続的に採用・否認するワークフローで有効。特に、否認理由が「重複」「一般化不足」「プロジェクト固有」「情報密度不足」のように再発しやすい場合に向いている。

一方で、少数の単純な除外条件だけで十分な場合は、履歴分析を別工程にする必要は薄い。その場合は、明示的なチェックリストだけで足りる。

注意点

抽象化したポリシーは完全なブロックリストではなく、判断補助として扱う。過去に否認された内容でも、文脈が変わったり、十分に一般化されたり、具体的な手順や検証観点が補われたりすれば、有用な候補になり得る。

そのため、ポリシーに抵触しそうな候補を機械的に捨てるのではなく、境界例としてユーザー確認に回す余地を残す。特に「薄いが改善すれば価値がある候補」は、即 discard ではなく本文を厚くできるかを先に検討する。

検証方法

次回以降の候補抽出で、AI が否認履歴そのものではなくポリシーを先に参照しているかを確認する。曖昧な候補が自動追加されず、ユーザー確認または本文改善に回るなら、ポリシーが機能している。逆に、結論だけの薄い候補が pending に追加され続ける場合は、ポリシーに Quality Bar や具体的な拒否条件を追加する。