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

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

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

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

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

1) 出典の明示：モデルはすべての回答に、ソース文書の ID または行番号を添えて返します。出典がなければ「分かりません」と返答。幻覚は約 80% 減少。

2) ルールによる事前チェック：出力が届く前にドメインルールで検証 — 注文番号は 8 桁か？請求書カテゴリは許可リストにあるか？日付フォーマットは正しいか？これらの安価な Python チェックが大半を捕捉します。

3) 人による事前承認：高リスクのアクション（返金、契約署名）は AI が提案し、人が承認します。AI は約 95% を独立で処理；残る 5% の例外がレビュー用にあなたへ。

3 つ合わせて：独立第三者監査では幻覚率は 2% 未満に下がります。

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

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

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

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

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

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

すべてのAIタスクが等しいリスクを持つわけではないため、ガードレールにかける予算も均等に配分すべきではありません。オープンエンドな生成——顧客宛メールの下書き、会議の要約、マーケティング文章の作成——は創造性の余地を残しますが、まさにその余地こそがハルシネーションの隠れ場所です。捏造された統計、架空の引用、会社が実際にはしていない約束などです。これは最もリスクの高いカテゴリです。照合すべき固定の「正解」出力が存在せず、許容できる範囲があるだけだからです。

数値・財務データの抽出は、それに次ぐリスクを抱えています。請求書から合計金額を抜き出す、割引を計算する、税番号を抽出するといった作業では、エラーは目立たず（数値はもっともらしく見える）、しかも高くつきます（それが直接お金の動きに反映されるため）。契約上の義務、コンプライアンス表明、用量や安全性に関する文言といった、法務・医療に近い主張も同じ高リスク層に属します。一度でも誤れば、その結果生じる害は単なる恥ではなく、法的責任になります。

一方の対極には、固定スキーマに対する構造化抽出があります。履歴書を氏名・メール・スキルに解析する、チケットを12カテゴリのいずれかに分類する、取引に加盟店コードでタグ付けするといった作業は、相対的にリスクが低くなります。出力空間が制約されており、機械的に検証しやすいため、モデルが創作する余地が少ないからです。カテゴリが実在するか、メールアドレスに@記号が含まれているか、値が12の選択肢のいずれかであるかを確認できます。小さな閉じた集合への分類も同様の振る舞いをします。モデルが間違えたとしても、定義した境界の内側で失敗するため、根本的に安上がりな失敗モードになります。

このグラデーションを使って、ガードレールにどれだけ労力を割くかを判断してください。低リスクでスキーマが閉じたタスクは、軽い検証とスポットチェックだけで運用できることが多いです。高リスクで、オープンエンドまたは数値・法務に関わるタスクは、自動化に顧客や帳簿を触らせる前に、前のセクションで述べたフルスタック——出典の引用、ルールチェック、ヒューマン・イン・ザ・ループ——に値します。