たきびAIラボ TAKIBI · AI · LAB
💻AI開発 ハウツー 公開 2026.05.17

LLMハルシネーション検出手法の選び方ガイド【2026年版】

SelfCheckGPT・Koopman・UQ・FactSelfCheckを実務で使い分ける

LLMハルシネーション検出の3系統(サンプリング一貫性・Koopman/DMD・不確実性定量化)をAPIアクセス制約・コスト・精度・実装難易度の4軸で比較。ユースケース別の選択フローと実務での組み合わせ戦略を解説する。

読了 約12分
LLMハルシネーション検出手法の選び方ガイド【2026年版】:SelfCheckGPT・Koopman・UQ・FactSelfCheckを実務で使い分ける

「ハルシネーション検出ライブラリをいくつか試したけど、結局どれを本番に使えばいいんだろう?」——LLMアプリの品質管理に取り組むエンジニアなら、一度は抱える悩みだ。SelfCheckGPT、Koopman/DMD系、UQLM/LM-Polygraph系とそれぞれ特徴があり、ベンチマーク数値だけ見ていても「自分のユースケースに合っているか」は判断できない。

この記事では、APIアクセス制約・コスト(推論回数)・精度・実装難易度の4軸で3系統の手法を比較し、チャットボット・RAG・コード生成・医療/法務といったユースケース別に「どれを選ぶか」の意思決定フローを示す。また、コストを抑えながら精度を担保する「実務での組み合わせ戦略」も解説する。

なお、Koopman/DMD手法(arXiv 2605.05134)の仕組みや数学的背景については別記事「ブラックボックスLLMのハルシネーションをKoopman演算子で検出する」で詳細に解説している。本記事では仕組みの詳細には立ち入らず、「選択・運用判断」に特化する。

3手法の概要

SelfCheckGPT系(サンプリング一貫性ベース)

2023年3月にManakul et al.が発表したSelfCheckGPTは、同じプロンプトで複数回サンプリングし、出力間の一貫性を測定することでハルシネーションを検出する。考え方はシンプルで「本当のことなら何度聞いても同じ答えが返ってくるはず」という直感に基づく。

実装面では、複数サンプリングを使う検出戦略(BERTScore、NLIモデル、n-gramなど)がすべてライブラリとして整備されており、pip install selfcheckgptで即座に導入できる。GPT-4やClaudeなどクローズドAPIでも動作する点が強みだ。

ただし、正確な検出には5〜10回のサンプリングが推奨されており、コストが比例して増加する。レイテンシも跳ね上がるため、リアルタイムチャットには不向きな場合がある。後継として2025年3月に発表されたFactSelfCheckは文単位の検出精度を向上させているが、基本的なコスト構造は変わらない。

Koopman/DMD系(動的システム理論ベース)

2026年5月にDan WilsonとMohamed Akrout(University of Tennessee)が公開したarXivプレプリントarXiv 2605.05134(査読前)が提案する手法。LLMのトークン生成過程を「動的システム」としてモデル化し、Koopman演算子理論とDynamic Mode Decomposition(DMD)を組み合わせることで、APIレスポンスのみからハルシネーションの兆候を検出しようとするアプローチだ。

最大の特徴は単一サンプル・単一API呼び出しで動作する点。複数サンプリングが不要なため、コストはSelfCheckGPTの5〜10分の1以下に抑えられる。さらに、モデル内部状態(トークン確率など)へのアクセスを必要としないため、クローズドAPIのみの環境でも使える。

ただし、本手法は2026年5月時点では査読前のarXivプレプリントであり、独立した再現実験や大規模ベンチマークでの検証はこれからの段階だ。仕組みと実装の詳細はKoopman手法の専用解説記事を参照してほしい。

UQLM/LM-Polygraph系(不確実性定量化ベース)

不確実性定量化(UQ)は、LLMの出力トークンに付随するソフトマックス確率分布を利用して、生成テキストの信頼スコアを0〜1で数値化するアプローチ。UQLM(CVS Health提供)とLM-Polygraphの2つが代表的なPythonライブラリだ。

UQLMはブラックボックスUQ・ホワイトボックスUQ・LLM-as-a-Judge・アンサンブルの4カテゴリのスコアラーを統一インターフェースで提供し、数行のコードで既存パイプラインに組み込める。LM-Polygraphは10種以上のUQアルゴリズムのベンチマーク環境も提供しており、精度比較に便利だ。

前提条件として、トークンレベルの確率情報(logprobs)へのアクセスが必要。OpenAIのAPIはlogprobs=Trueで取得できるが、Anthropic Claude APIは現時点で非対応。オープンソースモデルやHugging Face経由のモデルでは問題なく使える。

4軸比較表

評価軸SelfCheckGPT系Koopman/DMD系UQLM/LM-Polygraph系
APIアクセス制約クローズドAPI可クローズドAPI可logprobs取得必須(Claude APIは非対応)
コスト(推論回数)高(5〜10回/質問)低(1回/質問)低〜中(1回+スコアラー処理)
精度高(実績あり)中〜高(査読前、検証中)高(ホワイトボックス環境)
実装難易度低(pip一発)中(行列演算実装が必要)中(logprobs取得設定が必要)
レイテンシ高(並列化で緩和可)
主な制約コスト・速度査読前・再現性未確定モデルアクセス要件

ユースケース別選択フロー

チャットボット(汎用Q&A)

リアルタイム応答が求められ、コストも無視できない。Koopman/DMD系が第一候補。クローズドAPIで動作し、単一サンプルなのでレイテンシ増加を最小化できる。

ただしKoopman手法はまだ査読前段階のため、本番採用を検討する際は社内でのABテスト(SelfCheckGPTとの比較)を推奨する。精度要件が特に高くないユースケースであれば、しきい値チューニングで十分実用になる可能性がある。

RAG(検索拡張生成)

検索ドキュメントとの整合性チェックが主な目的になるため、NLIベースのSelfCheckGPT系が有効。FactSelfCheckは文単位の検出に強く、RAGの段落引用チェックに使いやすい。

コストが許せばUQLM系(ホワイトボックス)を組み合わせると、検索結果との一貫性スコアとトークン信頼スコアの二重チェックが実現できる。

コード生成

コードの正確性チェックはテスト実行(ユニットテスト)が最も確実だが、テスト実行前の粗いフィルタとしてSelfCheckGPT系かKoopman系を併用するとよい。コードの場合、同じロジックで複数サンプリングしても出力が安定しやすく、SelfCheckGPTの検出精度が出やすい。

医療・法務などの高信頼性要求

誤情報のコストが高く、見落としが許されないドメイン。Koopman系を第一フィルタ、UQLM系を第二検証とする二段構えが現実的だ。

具体的には、Koopman系でスコアが閾値以下の回答を「要確認フラグ」として仕分け、フラグが立ったケースだけUQLM系(またはSelfCheckGPT)で詳細評価する。こうすることで、全件に高コストな手法を適用することなく、高リスクケースへの精度を確保できる。

実務での組み合わせ戦略

ハルシネーション検出で最も現実的な落とし所は「安価な手法を第一段階フィルタとして使い、スコアが低い(怪しい)ケースだけ高精度手法へ回す」という段階的アプローチだ。

# 概念コード例:二段階ハルシネーション検出フロー
def detect_with_cascade(prompt: str, response: str) -> dict:
    # 第一段階:Koopman系で低コスト評価
    koopman_score = koopman_detector.score(prompt, response)

    if koopman_score > 0.8:
        # 高信頼と判定 → そのまま通過
        return {"verdict": "pass", "stage": 1, "score": koopman_score}

    # 第二段階:Koopman評価が低いケースのみSelfCheckGPTで詳細評価
    selfcheck_score = selfcheck_detector.score(
        prompt, response, num_samples=5
    )

    return {
        "verdict": "pass" if selfcheck_score > 0.7 else "flag",
        "stage": 2,
        "scores": {"koopman": koopman_score, "selfcheck": selfcheck_score},
    }

このカスケード戦略のポイントは以下の3点だ。

  1. 第一フィルタはコスト最小化を優先する: Koopman系のような単一サンプル手法、またはUQLMのブラックボックス版を使う
  2. 閾値は精度要件に合わせてチューニングする: 医療・法務なら第一フィルタを厳しく(高スコアのみ通過)、コスト優先なら緩く設定
  3. フラグのみ人間レビューに回す設計: 全件フラグではなく「疑わしいもの」だけを人間が見る導線を作る

また、EdinburghNLPのawsome-hallucination-detectionリポジトリには最新の検出手法が継続的にリストアップされており、新しい手法のキャッチアップに活用できる。

次に読むおすすめ

LLMアプリの品質管理については、noteでも実践的な情報を公開しています。概念を理解した後の「実装に踏み込むフェーズ」に役立てていただければと思います。

noteで続きを読む

FAQ

よくある質問

LLMハルシネーション検出手法の選び方

SelfCheckGPTのサンプリング回数は何回が推奨ですか?

原論文(Manakul et al., 2023)では5〜10回のサンプリングが推奨されています。回数を増やすほど検出精度は上がりますが、コストも比例して増加します。実務では予算とレイテンシを見て5回から始め、精度不足なら増やす調整が現実的です。並列API呼び出しでレイテンシは短縮できます。

ClaudeのAPIでUQLMは使えますか?

現時点(2026年5月)ではAnthropicのClaude APIはlogprobsを返さないため、ホワイトボックス型のUQLMは使えません。ClaudeでUQLMを使う場合はブラックボックス型スコアラー(LLM-as-a-Judgeや複数サンプリングベース)を選択するか、OpenAIモデル(logprobs=True対応)やオープンソースモデルを利用する必要があります。

Koopman/DMD手法はどのLLMで動作しますか?

arXiv 2605.05134(Wilson & Akrout)の手法はAPIレスポンスのテキストのみを使うため、原理的にはGPT-4・Claude・Geminiなど主要なクローズドAPIすべてで動作します。ただし2026年5月時点では査読前のプレプリントであり、各モデルでの詳細な検証実験の結果は公開されていません。本番採用前に自社ユースケースでの評価を行うことを強く推奨します。

医療・法務ドメインでの推奨構成は何ですか?

高信頼性要求ドメインでは「Koopman系を第一フィルタ → 疑わしいケースにSelfCheckGPT系かUQLM系を適用 → それでも低スコアは人間レビュー」という三段構えが推奨されます。全件に重い手法を使うとコストが爆発するため、段階的なフィルタリングが実用的です。また、どの手法も完全なハルシネーション排除を保証するものではないため、「最終的な責任判断は人間が担う」設計を維持してください。

複数の手法を組み合わせるとき、スコアはどう統合しますか?

最も簡単なアプローチは「どちらか一方でもフラグが立ったら要確認とする(OR結合)」です。精度を上げたい場合は「両方がフラグを立てた場合のみ要確認とする(AND結合)」や、各スコアに重み付けした加重平均を使う方法もあります。どのアプローチが最適かはユースケースの偽陰性(見逃し)と偽陽性(過剰フラグ)のコストバランスによって変わります。

関連記事

参考リンク

  • Manakul, P., et al. (2023). “SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models.” arXiv:2303.08896
  • Zhou, J., et al. (2025). “FactSelfCheck: Fact-Level Black-Box Hallucination Detection for LLMs.” arXiv:2503.17229
  • Wilson, D. & Akrout, M. (2026). “Koopman-Based Hallucination Detection for LLMs.” arXiv:2605.05134(査読前arXivプレプリント、2026年5月公開)
  • UQLM: Uncertainty Quantification for Language Models. arXiv:2510.12040
  • EdinburghNLP. “Awesome Hallucination Detection.” GitHub
  • Maxim. “How to Detect Hallucinations in Your LLM Applications.” getmaxim.ai