LLMsは明示的な指示にもかかわらず、構造化された出力に推論を漏洩させる

問題点：LLM検証プロセスでの推論漏れ

Claudeへの並列API呼び出しを行い、各呼び出しの構造化出力を解析するツールを開発している開発者は、断続的な問題に遭遇しました。各呼び出しは[COVER]、[SLIDE 1]、[CAPTION]などの特定のマーカー内にコンテンツを返します。第二のLLMパスが出力をルールに対して検証し、違反があれば書き直します。

検証プロンプトには明確に「修正されたテキストのみを全く同じ形式で返してください。解説なし。推論なし。違反リストなし。」と記載されています。

それにもかかわらず、検証モデルは時折、修正内容の前に推論を出力します。例としては：「このテキストの違反を確認する必要があります…これらの文は純粋に効果を狙った積み重ねられた劇的なペアを形成しています。以下が書き直しです：」に続いて実際の修正テキストが来るパターンです。

下流への影響

この推論テキストはそのままパーサーに渡されます。パーサーは[COVER]で始まるコンテンツを期待していますが、代わりにメタ解説を受け取ります。これにより下流でフィールドの位置ずれが発生します。あるケースでは、検証器の推論テキストが画像プロンプトフィールド内に収まってしまいました。なぜならパーサーが推論を本文コンテンツとして消費し、すべてを数行分ずらしてしまったからです。

プロンプトの厳格化だけでは問題は解決しませんでした。指示をより明確にすること、「あなたの出力は最初のコンテンツマーカーで始まらなければならない」と追加すること、「決して推論を含めない」と追加することは頻度を減らしましたが、完全には排除できませんでした。モデルは時折、特に修正すべき違反を見つけた場合に指示を無視します。つまり、自分の作業過程を示したがるのです。

解決策：二層防御

効果があった修正は二つの層を含みます：

• 第一層： プロンプトの厳格化。問題が発生する頻度を減らすため、依然として行う価値があります。
• 第二層： あらゆる解析が行われる前に、すべての検証出力に対して実行される防御的な除去関数。構造化フォーマットの場合、最初に認識されたマーカーを基準とし、その前のすべてを破棄します。プレーンテキストフォーマットの場合、「このテキストを確認させてください」や「これは制約に違反しています」などの既知の検証器解説パターンに一致する行を除去します。

解析前の除去という順序が鍵です。すべての下流パーサーは、既に無害化された出力に対して動作します。これにより、フィールドごとの除去ロジックを維持したり、新しい推論フォーマットに対していわゆる「モグラ叩き」をしたりすることを避けられます。

実装上の考慮点

プレーンテキスト除去パターンについては、注意深い設計が必要です。「これは違反です」を捕捉する正規表現は、正当なコンテンツ内の「これはよくある間違いです」も捕捉してしまう可能性があります。パターンは、「これはルール/制約に違反しています」のように、検証器固有の言語のみに一致するよう厳格化すべきであり、「これは」や「これは使用する」のような広範な一致は避けるべきです。各パターンは、デプロイ前に実際のコンテンツに対して監査が必要です。

LLMからの構造化出力を解析する場合、プロンプト指示はベストエフォートの第一パスとして扱い、パーサーの前には常にコードレベルの防御を設けてください。モデルは95%の確率で従いますが、従わない5%の場合、下流ロジックを断続的で再現が難しい方法で破壊することになります。