ハルシネーションの多層制御設計

種別：設計原則 / リスク制御 / 評価方法適用対象：生成AI、RAG、QAチャット、AIエージェント、コード生成対象工程：予防 / 検出 / 拒否 / 採用 / 実行

ハルシネーションを業務システムのリスクとして捉えます。

ハルシネーションは、モデル単体の異常ではない。

不完全な情報と確率的生成を含むシステム全体で発生する、設計上のリスクである。

では、そのリスクをどのように制御すればよいのでしょうか。

現実的な目標は、ハルシネーションを完全に消すことではありません。

発生確率を下げ、誤りを検出し、危険な出力を止め、発生した場合の影響を限定する。

このページでは、これを確率制御設計と呼びます。

ここでいう制御は、プロンプトで回答候補を狭めることだけではありません。検索、検証、回答拒否、人間への移管、実行権限まで含むシステム設計です。

制御対象は「誤答の発生」だけではない

ハルシネーション事象を $H$ とします。

単純に考えれば、下げたいのは次の確率です。

P(H)

しかし、業務上の損害が生じるのは、誤答が生成された瞬間とは限りません。

誤答が検出されず、利用者に受け入れられ、後続処理へ使われたときに、初めて影響が顕在化する場合があります。

誤答を検出した事象を $D$ 、回答を採用または実行した事象を $A$ とすると、危険な流出は次の事象として表せます。

H \cap \neg D \cap A

その確率は、連鎖律を使うと次のように分解できます。

P(H \cap \neg D \cap A) = P(H) P(\neg D \mid H) P(A \mid H,\neg D)

つまり、制御できる箇所は少なくとも三つあります。

誤答を生成しにくくする
生成された誤答を検出しやすくする
未検出の誤答がそのまま使われないようにする

生成前の対策だけで、すべてを解決する必要はありません。

確率と影響を分けて考える

同じハルシネーションでも、影響は用途によって異なります。

例えば、社内FAQでリンクを一つ間違えることと、支払金額や本番操作を誤ることは、同じ一件として扱えません。

簡略化したリスクは、次のように考えられます。

Risk = P(\text{危険な流出}) \times Impact

複数種類の誤りを区別するなら、誤りの種類 $k$ ごとに期待損失を足し合わせます。

Expected\ Loss = \sum_k P(H_k \cap \neg D_k \cap A_k) I_k

$I_k$ は、その誤りが生じた場合の影響度です。

この考え方から、用途ごとの制御強度が決まります。

用途	誤答時の影響	主な制御
アイデア出し	小さい	利用者による確認
社内情報検索	中程度	根拠表示、回答拒否、フィードバック
顧客向け回答	大きい	根拠検証、人間承認、記録
金額・権限・本番操作	非常に大きい	決定論的検査、実行権限制限、人間承認

ハルシネーション率が同じでも、許容できる用途と許容できない用途があります。

制御は多層化する

ハルシネーション対策を一つのプロンプトに集約すると、その指示が機能しなかった場合に防御がなくなります。

そこで、制御を複数の層へ分けます。

質問・入力
    ↓
1. 対象範囲と入力条件
    ↓
2. Knowledge・検索
    ↓
3. 生成
    ↓
4. 根拠検証
    ↓
5. 回答・拒否・人への移管
    ↓
6. 採用・実行の制御

各層は、異なる失敗を扱います。

制御層	下げたいもの	例
入力制御	情報不足による誤推定	必須項目、対象外判定、追加質問
検索制御	不十分・誤った根拠の取得	検索評価、版管理、再ランキング
生成制御	根拠外の補完	根拠限定指示、短い回答、引用
検証制御	誤答の見逃し	主張分解、根拠照合、ルール検査
選択制御	不確実な回答の提示	閾値、回答拒否、人への移管
実行制御	誤答による実害	権限制御、承認、監査ログ

これらは同じ対策の言い換えではありません。

検索漏れは生成プロンプトだけでは直せず、権限の誤操作は文章の根拠表示だけでは防げません。

1. 入力段階で、答えられる条件を確認する

正しい回答に必要な条件を $Q$ とします。

例えば、製品QAなら次のような条件です。

製品名
バージョン
契約または権限
利用環境
発生している現象

必要条件が揃った事象を $S$ とすると、一般には次の関係を期待します。

P(H \mid \neg S) > P(H \mid S)

これは常に成立する数学的法則ではありません。対象業務で検証すべき仮説です。

設計では、条件不足時にAIへ推測させず、次のいずれかへ分岐させます。

不足項目を質問する
対象外として回答を拒否する
担当者へ移管する

2. RAGでは「検索できたか」を別に測る

回答に必要な根拠を取得できた事象を $R$ とします。

RAG全体の誤りは、検索が失敗した場合と、検索に成功した後の生成が失敗した場合に分解できます。

P(H) = P(R)P(H \mid R) + P(\neg R)P(H \mid \neg R)

このため、最終回答だけを評価しても、改善箇所を特定できません。

少なくとも次を分けて測ります。

必要な文書が検索対象に存在したか
必要な文書を上位 $k$ 件へ取得できたか
取得文書は現在有効だったか
取得文書同士に矛盾がなかったか
AIは取得文書に沿って回答したか

最終回答だけでなく、根拠の取得漏れ、順位、鮮度、権限を検索段階で確認する。検索と回答の測定方法はQAチャット評価設計思想で扱う。ここでは、検索が失敗したときに生成へ進まず、再検索・追加質問・移管へ戻す制御を置く。

3. 生成段階では、回答を根拠へ結び付ける

根拠を取得できても、AIが根拠にない内容を補う場合があります。

そこで、回答を検証可能な単位へ分解します。

出力 $Y$ に含まれる原子的な事実主張の集合を $A(Y)$ とし、根拠 $E$ が支持する主張数の割合を次のように定義します。

Groundedness(Y,E) = \frac {\left|\{a \in A(Y): Supported(a,E)\}\right|} {|A(Y)|}

これはFActScoreの考え方に近い、簡略化した指標です。

回答全体を「正しい・誤り」の二値で見るのではなく、どの主張が根拠に支持されているかを確認します。

実装上は、次のような出力形式が考えられます。

回答中の主張	根拠	判定
機能AはVersion 3.2以降で利用可能	仕様書2.1節	支持あり
管理者権限が必須	根拠なし	未支持

引用が付いていることと、その引用が主張を本当に支持していることも別です。

したがって、引用の有無だけでなく、主張と引用の含意関係を評価します。

4. 回答拒否は、精度と回答率の交換になる

必要な根拠がない場合に回答を止めれば、誤答の流出を減らせる可能性がある。一方、正しく回答できる入力まで止めると利用価値が失われる。

回答条件はAIの自己申告の自信ではなく、対象業務の評価データから決める。回答した割合と、回答した範囲での誤りを分けて測る方法はなぜ回答範囲を制限した方がよいのかで扱う。制御設計では、拒否後の追加質問・担当窓口・移管先も用意する。

5. 誤答検出器にも誤りがある

誤りを受け入れる見逃しと、正しい回答を拒否する過剰拒否の両方がある。検証器を置いただけで安全とみなさず、対象業務の入力で評価する。受理・拒否の誤りと検証器の限界はガードレールの数学的説明で扱う。

検証不能な出力は、そのまま次工程へ通さない。情報不足なら取得へ戻し、判断が必要なら根拠と未解決事項を人へ渡す。人間の確認対象と責任はAI出力の責任境界とHITLで決める。

6. 複数の検証を重ねる場合の注意

独立した検出器が複数あり、誤答を見逃す確率がそれぞれ $m_1,m_2,\ldots,m_n$ だとします。

誤答に対する各検出器の成否が条件付きで独立という強い仮定を置けば、すべてが見逃す確率は次のようになります。

P(\text{全検出器が見逃す} \mid H) = \prod_{i=1}^{n}m_i

しかし実際には、同じモデル、同じ根拠、同じプロンプトを使う検証器の誤りは相関しやすくなります。

生成AIに回答させ、同じ生成AIへ「正しいですか」と聞くだけでは、独立した検証にならない可能性があります。

検証経路を分ける例として、次があります。

生成AIとは別の検索クエリで根拠を取得する
数値やIDを決定論的なプログラムで照合する
データベースの原本を直接参照する
高リスク案件だけ専門家へ移管する
本番操作の権限を生成AIから分離する

検証器の数より、失敗原因が異なる検証を組み合わせることが重要です。

7. 確率的制御と決定論的制御を分ける

すべての制御が、同じ強さを持つわけではありません。

確率的制御

プロンプトで推測を禁止する
RAGで根拠を与える
Temperatureを調整する
別のAIにレビューさせる
自己評価スコアを使う

これらは誤答確率を下げる可能性がありますが、意味的な誤答を完全には排除しません。

決定論的制御

JSON Schemaに合わない出力を拒否する
許可リスト外の値を受け付けない
データベースの値と一致しなければ停止する
利用者の権限外の操作を実行しない
人間の承認がなければ本番反映しない

これらは、定義した条件について強制できます。

ただし、決定論的制御も「回答内容が世界の事実として正しい」と保証するわけではありません。

保証できるのは、定義済みの形式、値、権限、遷移条件を満たしたことです。

QAチャットの制御例

社内QAチャットを例に、制御を組み立てます。

1. 質問を受け取る
2. 製品名・Version・対象機能を抽出する
3. 不足していれば追加質問する
4. 利用権限内の最新文書だけを検索する
5. 根拠が取得できなければ回答しない
6. 回答を原子的な主張へ分解する
7. 各主張が根拠に支持されるか検査する
8. 未支持の主張があれば削除または人へ移管する
9. 根拠と不確実性を付けて提示する
10. 高リスクな質問は担当部門の承認を求める

この設計では、モデルへ完全な正答を期待していません。

各段階で失敗を検知し、誤答がそのまま業務へ流れる確率を下げています。

評価データがなければ、閾値は決められない

「信頼度80%以上なら回答する」と決めても、その80%が実際の正答率と対応している保証はありません。

制御条件は、対象業務の評価データから決めます。

評価セットには、少なくとも次を含めます。

正常に回答できる質問
必要情報が不足した質問
対象範囲外の質問
正解文書が検索しにくい質問
古い文書と新しい文書が競合する質問
根拠が存在しない質問
誤った前提を含む質問
回答すると影響が大きい質問

評価する代表指標は次の通りです。

指標	確認すること
Retrieval Recall@k	必要な根拠を取得できたか
Groundedness	回答中の主張が根拠に支持されたか
Citation Precision	引用が主張を本当に支えているか
Coverage	どの程度の質問へ回答したか
Selective Risk	回答したものの誤答率
False Accept Rate	誤答を採用してしまった割合
Escalation Rate	人間へ移管した割合
Expected Loss	確率と影響を合わせた損失

モデル、Knowledge、検索対象、利用者の質問傾向が変われば、評価結果も変わります。

本番導入前の一度きりの評価ではなく、ログと事故事例から評価セットを更新します。

「ハルシネーション率ゼロ」を目標にしない

ゼロを掲げると、次のどちらかになりやすくなります。

実際には測れないゼロを宣言する
すべてを拒否し、利用価値をなくす

設計目標は、用途と影響に応じて具体化します。

例えば、次のように定めます。

対象範囲内の質問に対するCoverage：80%以上
回答した質問のGroundedness：98%以上
高リスク質問の自動回答：0件
最新版を取得できない場合の回答拒否率：100%
権限変更の自動実行：禁止

この数値は例であり、一般的な推奨値ではありません。

重要なのは、発生率だけでなく、検出、拒否、移管、影響まで測定可能な要件へ変えることです。

まとめ

ハルシネーションの確率制御とは、AIが持つ回答候補を狭めることだけではありません。

制御対象は、次の連鎖全体です。

\text{生成} \rightarrow \text{検出} \rightarrow \text{採用} \rightarrow \text{実行}

誤答が業務へ流出する確率は、概念的に次のように分解できます。

P(H \cap \neg D \cap A) = P(H) P(\neg D \mid H) P(A \mid H,\neg D)

したがって、実務で必要なのは次の設計です。

入力と回答範囲を定める
必要な根拠を取得する
回答を根拠へ結び付ける
誤答を検出する
不確実な場合は回答しない
高リスクな判断を人へ戻す
誤答が直接実行されないようにする
CoverageとRiskの両方を継続評価する

開かれた自然言語業務で、AIを常に完全に正しいと保証することはできない。

しかし、誤りが損害へ変わるまでの経路を分解し、それぞれに制御を置くことはできる。

それが、ハルシネーションを業務上のリスクとして扱うための確率制御設計です。

参考資料

Min et al., FActScore: Fine-grained Atomic Evaluation of Factual Precision in Long Form Text Generation
Kadavath et al., Language Models (Mostly) Know What They Know
Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile