AI の幻覚を捕まえる：B2B チームの 3 つのガードレール

実際の B2B ワークフローでの AI 幻覚はどう現れるか

幻覚とは、モデルが自信ありげに見えるが間違っている回答を生成することです。B2B では 3 つの典型形があります：(1) サポートの問い合わせに対して存在しない注文番号を捏造する、(2) 契約を要約する際に契約書に存在しない日付を「引用」する、(3) 請求書分類で定義された集合の外にある新カテゴリを発明する。

3 つに共通するのは「実在のアンカーが見つからないと、モデルが穴を埋める」というパターン。問題は出力が自信ありげに見えること — 間違っていても。「AI が間違っている」だけでは行動に落ちません。どこで、なぜ間違ったかを掴む必要がある。以下の 3 つのガードレールがそれを担います。

3 つのガードレール：出典、ルール、人

出典の確認：回答を裏付ける文書と箇所を示し、引用が存在するだけでなく内容が主張を支えているか確認します。情報の欠落や矛盾があれば確認担当者へ回します。

ルールの確認：注文の存在、利用者の権限、金額、許可された分類をアプリ側で検証します。形式が正しくても事実が正しいとは限りません。

人の承認：支払いや返金、拘束力のあるメッセージの送信前に、権限を持つ人が確定した出力を確認します。変更後は再承認が必要です。これらの対策に共通の成功率はありません。正解、誤答、出典のないケースで、不正な出力が止まり、確認待ちの案件が担当者に届くことを試験します。

リリース前に評価プロセスを構築する

ハルシネーション率は出力を目視で確認するだけでは把握できません。テストセットが必要です。正解が分かっている実際の例を50〜200件集めたゴールデンセットを作成し、データ欠落、曖昧な問い合わせ、対象外のリクエストといったエッジケースを確実に含めてください。プロンプトやモデルを変更するたびに、リリース時だけでなく毎回このセットに対してモデルを実行してください。

精度（正しい答えを出せたか）と、棄権率（答えるべきでないときに正しく「わかりません」と言えたか）という2つの数値を別々に追跡してください。決して棄権しないモデルは自信があるように見えますが、リスクは高くなります。棄権が多すぎるモデルは煩わしいですが、その分安全です。適切なしきい値は、誤答のコストと、答えを見送ることのコストのどちらが高いかによって決まります。

敵対的テストは、通常ケースのテストと同じくらい重要です。存在しない実体についての質問、2つのレコードを混ぜ合わせるようなリクエスト、元の文書を超えて外挿させようとするプロンプトなど、意図的にハルシネーションを誘発するように設計したクエリをモデルに与えてください。管理されたテストで適切に失敗できないモデルは、本番環境でも適切に失敗できません。

これは一度限りの関門ではなく、継続的に運用するパイプラインとして扱ってください。プロンプトを変更するたび、モデルを入れ替えるたび、新しい文書ソースを追加するたびに、評価セットを再実行し、新しい精度と棄権率の数値を、デプロイ前にベースラインと比較してください。これは従来型ソフトウェアの回帰テストと同じ規律であり、対象がロジックではなく判断力であるという違いがあるだけです。

どのタスクが最もハルシネーションのリスクを抱えているか

自由文か構造化データかだけでリスクを決めないでください。正しい分類に入った誤った仕訳も損害を生みます。影響、取り消し可能性、データの機密性、結果を使う人を評価します。下書き作成と、顧客への連絡や資金移動に同じ権限を与えない設計が必要です。