常駐型AIエージェントの「もっともらしい嘘」を送信前に止める設計パターン

対話型のチャットボットなら、ハルシネーション(もっともらしい誤情報)が混じっても人間がその場で「それ違うくない?」と突っ込めます。しかし常駐型エージェントは、誰も見ていない間に自発的にチャットへ発言します。その場に検証してくれる人間がいないため、誤った要約や存在しない数値をそのまま送ってしまうと、気づかれるまで社内に誤情報が残り続けます。この記事では、常駐エージェントの発言を送信する前に機械的にガードする設計パターンを整理します。

なぜ「送信前チェック」が常駐型エージェント特有の課題なのか

対話型チャットボットのハルシネーション対策は、多くの場合「回答精度を上げる」方向に投資されます。誤答が出ても、質問した本人がその場で違和感に気づける可能性が高いからです。

一方、常駐型エージェントは次のような性質を持ちます。

• 発言のトリガーが人間の質問ではなく、監視対象の変化(イベント駆動)である
• 発言内容を事前にチェックする人間が、発言の瞬間には存在しない
• 「進捗率80%」「先方は前向き」のような数値や断定を含む要約を自発的に生成しやすい

つまり精度をどれだけ上げても取りこぼしはゼロにならない前提に立ち、間違った内容を検知して止める仕組みを発言経路に組み込む必要があります。

パターン1: 根拠のない断定・数値を検出してから送る

LLMの出力をそのままチャットに流すのではなく、送信前に「元データに存在しない情報が混入していないか」を機械的に照合します。

async function verifyBeforeSend(draft: AgentMessage, sourceDocs: SourceDoc[]) {
  const claims = extractClaims(draft.text); // 数値・固有名詞・断定表現を抽出

  const unverified = claims.filter(
    (claim) => !sourceDocs.some((doc) => supports(doc, claim))
  );

  if (unverified.length > 0) {
    return { blocked: true, reason: "unverified_claims", claims: unverified };
  }
  return { blocked: false };
}

ここでのsupportsは、厳密な自然言語推論である必要はありません。まずは「その数値・固有名詞が元データのどこかに文字列として存在するか」レベルの単純な照合でも、明らかな捏造(元データに一切登場しない数字を出す等)はかなり検出できます。

パターン2: 断定と推測を言い分けさせ、推測は目立たせる

すべての誤りを検出で止めるのは現実的ではありません。検出できなかった分は、表現のレベルで誤解を招かないようにするアプローチを併用します。

• 元データに明記されている事実 →「〜です」と断定して書かせる
• LLMが複数の情報から推測した内容 →「〜と考えられます(推測)」と明示させる

プロンプト側で出力形式を分離しておくと、後段のチェックでも「推測ラベルの付いた文に数値が含まれていないか」など、断定文より緩いルールで済ませられます。

{
  "facts": ["A社との商談は3/15に実施された"],
  "inferences": ["先方の反応から、価格面での懸念がある可能性があります"]
}

パターン3: 「分からない」を出力できるようにしておく

意外と見落とされがちですが、LLMに沈黙・保留という選択肢を明示的に許可するだけでハルシネーションはかなり減ります。「必ず要約してください」という指示は、材料が不足していても無理に文章を作らせる方向に働きます。

const systemPrompt = `
情報が不足していて判断できない場合は、無理に結論を出さず
"status": "insufficient_data" を返してください。
不確かな情報を断定的に書くことは絶対に避けてください。
`;

insufficient_data を受け取った場合は、エージェントは黙って何も送らないか、「情報が揃っていないため今回は見送ります」という定型メッセージだけを送るようにします。

パターン4: 誤送信が起きた前提で「訂正」を一級市民にする

どれだけガードを重ねても、検出をすり抜ける誤りはゼロになりません。設計としては、誤送信の発生自体を防ぐことと同じくらい、誤送信に気づいたときに訂正しやすくすることに投資すべきです。

• 送信したメッセージには内部IDを持たせ、後から「先ほどの◯◯という発言は誤りでした」と紐づけて訂正発言を送れるようにする
• ブロックされた発言(パターン1・3で止まったもの)はログに残し、なぜ止まったかを人間が後から確認できるようにする

訂正の導線を先に作っておくことで、ガードの精度に対する心理的なプレッシャーも下がり、過剰に保守的な(何も発言しない)チューニングを避けられます。

まとめ

• 常駐型エージェントはその場での人間チェックが効かないため、発言の「送信前」に機械的なガードを挟む設計が要る
• 元データに存在しない数値・断定を検出する、事実と推測を出力形式で分離する、「分からない」を許可する、の3つは実装コストの割に効果が大きい
• ガードをすり抜けた誤りは必ず起きる前提で、訂正を後から送れる導線もセットで設計する

「勝手に発言する」設計は価値の源泉である一方、誤情報のリスクも自発的に背負うことになります。発言の自由度を上げる前に、この4パターンを一度当てておくと事故を減らせます。

---

筆者は Slack / Teams / Chatwork に常駐する法人向けAIスタッフ「HACH」を開発しています。まさにこの送信前ガードの設計で日々運用しています。同種のエージェントを開発・運用している方の参考になれば幸いです。