「AIの回答は毎回違う」をデータで制する：LLMの不確実性を定量化し、導入リスクを管理可能なコストに変える実装ガイド

はじめに：AIの「自信のなさ」を数値化する

「このAIの回答は、100%正しいと言い切れますか？」

医療AI開発の現場において、医師や規制当局から頻繁に寄せられる切実な疑問です。人の命に関わる臨床現場や、患者のQOL（生活の質）を左右する医療判断において、AIの「もっともらしい嘘（ハルシネーション）」は決して許容されません。しかし、確率論に基づいて動くLLM（大規模言語モデル）にとって、「100%」という数字は原理的にあり得ないものです。

多くのDX推進担当者やCTOが、これと同じ壁に直面し、苦悩されています。医療に限らず、金融、法務、あるいは企業の基幹業務において、経営層は「確実性」を求めますが、AIは「可能性」しか提示できません。このギャップこそが、PoC（概念実証）死の谷を生む最大の要因となっています。新しい技術を社会実装しようとする際、こうした不安を抱かれるのは当然のことです。

では、私たちはどうすべきでしょうか？

答えは、AIを「完璧にする」ことではなく、AIの「不確実性を定量化する（Uncertainty Quantification）」ことにあります。AIがどの程度自信を持って回答しているのか、その「迷い」を数値として可視化できれば、それは管理可能なビジネスリスクへと変わります。

本記事では、大手医療機器メーカーやスタートアップにおける医療AI開発の最前線で実践されている手法をベースに、LLMの不確実性を統計学的に計測し、システムに組み込むための具体的な実装ステップを解説します。プロンプトエンジニアリングといった定性的なアプローチから一歩踏み込み、コードと数式を用いてAIのリスクを倫理的かつ安全に制御する「エンジニアリング」の世界へご案内します。

---

1. ブラックボックスの数値化：なぜ「不確実性」の定量化がAI導入の決定打になるのか

AI導入プロジェクトにおいて、多くのステークホルダーは「正解率」という指標に固執する傾向があります。しかし、生成AIにおいて単純な正解率（Accuracy）はあまり意味を持ちません。なぜなら、生成されるテキストは無限のバリエーションを持ち、文脈によって正解の定義が変わるからです。

ここで重要になるのが、「不確実性（Uncertainty）」という概念です。

「なんとなく正しい」からの脱却

従来のAI評価は、人間が生成結果を見て「良さそう」「変だ」と判断する定性評価が主でした。しかし、これでは数千、数万件の処理を自動化する際の品質保証（QA）になりません。特に医療分野などの高い精度と倫理的配慮が求められる領域では、この定性的な判断が致命的なリスクにつながることもあります。臨床現場のニーズに応える安全なソリューションを提供するためには、客観的な指標が不可欠です。

不確実性の定量化とは、モデルが出力するトークンごとの確率分布を解析し、モデル自身がその回答にどれだけ「確信」を持っているか、あるいは「迷っているか」をスコア化することです。これにより、「この回答はリスクが高いので人間が確認すべき」という判断を自動化できます。

ビジネスにおける2種類の不確実性

データサイエンスの世界では、不確実性を主に2つに分類します。この区別は、ビジネス対策を講じる上で非常に重要です。

1. Aleatoric Uncertainty（データ固有の不確実性）

   • 定義: データそのものが持つノイズや曖昧さに起因する不確実性。
   • 例: 「昨日の天気は？」という質問に対し、地域が指定されていなければ回答は確定しません。また、医療画像解析において画像自体が不鮮明な場合や、患者の主訴が曖昧な場合もこれに当たります。
   • 対策: データの品質向上や、コンテキストの明確化（プロンプトの改善）で低減可能です。

2. Epistemic Uncertainty（モデルの知識不足による不確実性）

   • 定義: モデルが学習していない、あるいは知識が不足していることに起因する不確実性。
   • 例: 最新の診療ガイドラインや、学習データに含まれていない専門的な医学用語に関する質問。
   • 対策: 外部知識を補完するRAG（検索拡張生成）の導入が有効です。近年は情報のつながりを構造化して理解するGraphRAGが注目されています。ただし、GraphRAGは発展途上の技術であり、公式リポジトリ等での継続的な動向追跡が推奨されます。例えば、Amazon Bedrock Knowledge Basesではプレビュー段階としてGraphRAGサポート（Amazon Neptune Analytics対応）が追加されるなど、クラウド各社の対応が進みつつあります。本番環境への全面導入を急ぐのではなく、まずは標準的なベクトル検索ベースのRAGで基盤を固め、検証環境でプレビュー機能を試しながら移行の準備を進めるアプローチが安全です。

これらを数値化して区別できれば、「プロンプトの記述を具体化すべきか」「RAGの検索ロジックを段階的にアップグレードすべきか」「追加学習が必要か」という意思決定が、勘ではなくデータに基づいて行えるようになります。

定量化がもたらすROI試算の精緻化

不確実性をスコア化（例：0〜1のリスクスコア）できれば、以下のようなROIシミュレーションが可能になります。

• 高信頼度回答（スコア0.9以上）: 完全自動化（コスト削減効果：大）
• 中信頼度回答（スコア0.6〜0.9）: 人間によるサマリー確認（コスト削減効果：中）
• 低信頼度回答（スコア0.6未満）: 回答拒否または専門家へエスカレーション（リスク回避）

このように、全件自動化を目指して現場に負担をかけるのではなく、リスクスコアに応じたトリアージを行うことで、現実的かつ安全性の高いAI運用フローを設計できるのです。

---

2. 統合アーキテクチャ：LLMパイプラインに「品質監視モニター」を組み込む

不確実性の定量化を実システムに組み込む場合、単にLLMを呼び出すだけでなく、その出力を評価するサブシステムが必要です。医療AI開発の現場でも重視される、安全性と信頼性を担保するための推奨アーキテクチャの全体像を定義します。

評価ループを含むシステム構成図

基本的なLLMアプリケーション（RAG等）に、「Uncertainty Evaluator（不確実性評価器）」を追加します。この評価器は、LLMの推論プロセスに介入、あるいは並行して動作し、出力の信頼度をスコアリングします。

1. Input Layer: ユーザーからのプロンプトを受け取ります。
2. LLM Inference: LLMが回答を生成します。この際、単なるテキストだけでなく、トークンごとの対数確率（Logprobs）も取得可能なモデルを選定します。例えばOpenAI APIを利用する場合、GPT-4oやGPT-4.1などの旧モデルは2026年2月13日をもって廃止されたため、現在主力となっているGPT-5.2（InstantまたはThinking）などの新モデルへ移行し、確実なデータ取得基盤を整える必要があります。
3. Uncertainty Evaluator:
   • Token-level Analysis: 出力されたLogprobsからエントロピーを計算し、モデルの「迷い」を数値化します。
   • Semantic Analysis: 必要に応じて複数回サンプリングを行い、回答内容の意味的な一貫性を検証します。
4. Decision Gate: 算出された不確実性スコアに基づき、回答をユーザーにそのまま提示するか、警告（ディスクレーマー）を付与するか、あるいは回答を拒否して人間にエスカレーションするかを決定します。
5. Output Layer: 最終的なレスポンスを返します。

リアルタイム評価とバッチ評価の使い分け

チャットボットのようなリアルタイム性が求められるシステムでは、計算コストの低い「トークンレベルの分析」を主軸にします。ここでGPT-5.2 Instantのような応答速度に優れたモデルを活用すれば、レイテンシを抑えつつ効果的なリスク検知が可能です。

一方、医療レポート生成や複雑な医療画像解析の補助業務など、多少の待ち時間が許容される場合は、複数回推論を行う「意味レベルの分析」を取り入れることで、より高精度な幻覚（ハルシネーション）検知が可能になります。長い文脈理解や汎用的な推論能力が向上したChatGPT Thinkingなどをバッチ処理に組み込むことで、より深い意味的検証を実現できます。

主要な技術スタック

信頼性の高い評価システムを構築するために、以下の技術スタックが推奨されます。各ツールは急速に進化しているため、最新の仕様に合わせた選定が重要です。

• LLM API:
  • OpenAI API: logprobsパラメータを利用してトークン確率を取得します。前述の通り、GPT-4oなどの旧モデルはすでに廃止されています。システムの突然の停止を防ぐため、APIの呼び出し先を速やかにGPT-5.2へ移行してください。新モデルは文章作成の構造化やツール実行能力も向上しているため、評価システムの精度向上も期待できます。特定のタスクに特化したモデル（ヘルスケア向け機能など）の活用も合わせて検討します。
  • Google Vertex AI: Geminiなど、構造化出力や確率取得に対応したモデルを利用します。
• Orchestration:
  • LangChain: 最新のアーキテクチャではlangchain-core（中核機能）とlangchain-community（外部連携）が分離されています。評価チェーンの構築には、従来のrun等ではなく、型安全性と統一性が向上したinvoke()メソッドの使用が推奨されます。また、シリアライズ処理に関する脆弱性（CVE-2025-68664等）が報告されているため、必ずセキュリティパッチが適用された最新バージョンを使用してください。
• OSS Model Integration:
  • Hugging Face: オープンソースモデル（LlamaやmmBERT等）を利用する場合は、transformersライブラリを経由してロードします。オンプレミス環境でデータを外に出さずに評価を行いたい場合に有効です。
• Vector Database:
  • 意味的な一貫性を測る際、回答同士の類似度計算に使用します（Pinecone, Weaviate, Qdrant等）。
• Statistics Library:
  • scipy, numpy。エントロピーや分散の計算に使用します。

---

参考リンク

• Hugging Face - Models

3. 前提条件と環境準備：確率論的評価のための土台作り

実装に入る前に、不確実性定量化に必要な環境と前提条件を整理しましょう。ここを見落とすと、後続の実装が機能しません。

Logprobs（対数確率）へのアクセス権限設定

LLMがテキストを生成する際、内部では次に続く単語（トークン）の候補に対し、それぞれの確率を計算しています。通常、APIは最も確率が高い（あるいはサンプリングされた）トークンのみを返しますが、不確実性を計算するには、この「確率分布」そのものが必要です。

OpenAIのAPI（GPT-3.5-turbo/ChatGPT）では、logprobs=True パラメータを指定することで、選択されたトークンの対数確率と、その他の候補トークンの情報を取得できます。

• 注意点: すべてのモデルやAPIバージョンが logprobs をサポートしているわけではありません。選定するモデルがこの機能を提供しているか、技術仕様書（Documentation）で必ず確認してください。

サンプリングパラメータ（Temperature）の設定戦略

不確実性を正しく評価するためには、生成時のパラメータ設定も重要です。

• Temperature: 通常は0.7程度に設定されますが、不確実性を評価するための「複数サンプリング（後述）」を行う場合は、あえて1.0程度に上げて回答の多様性を出し、モデルの迷いを顕在化させる手法も取られます。
• Top_p: 核サンプリングの設定も、確率分布の裾野をどう扱うかに影響します。

評価用データセットとGround Truthの準備

システムが算出した不確実性スコアが本当にリスクを表しているか検証するために、少量の「正解データ（Ground Truth）」と、意図的に間違えやすい「敵対的データ」を用意します。これにより、スコアのしきい値（Threshold）を調整します。

---

4. 実装ステップ1：トークンレベルの「言語的不確実性」を計測する

ここからは具体的な実装に入ります。まずは、最も低コストで実装可能な「トークンレベルのエントロピー」を用いた手法です。

エントロピー（情報量）の計算アルゴリズム

情報理論におけるエントロピー（Shannon Entropy）は、情報の「乱雑さ」や「不確かさ」を表す指標です。LLMにおいて、次に来る単語の予測確率が特定の単語に集中していればエントロピーは低く（自信がある）、多くの単語に分散していればエントロピーは高く（迷っている）なります。

数式で表すと以下のようになります。

[ H(X) = -\sum_{i} P(x_i) \log P(x_i) ]

ここで ( P(x_i) ) は各トークンの出現確率です。

回答の「迷い」を数値化するコード実装

以下は、PythonとOpenAI APIを使用して、生成された回答の不確実性を計算するサンプルコードです。

import math
from openai import OpenAI
import numpy as np

client = OpenAI(api_key="YOUR_API_KEY")

def get_completion_with_uncertainty(prompt, model="ChatGPT"):
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        logprobs=True,      # Logprobsを有効化
        top_logprobs=5      # 上位5つの候補を取得
    )
    
    content = response.choices[0].message.content
    logprobs = response.choices[0].logprobs.content
    
    uncertainties = []
    
    for token_logprob in logprobs:
        # 各トークン位置での確率分布を取得
        # top_logprobsに含まれる候補からエントロピーを近似計算
        probs = [math.exp(lp.logprob) for lp in token_logprob.top_logprobs]
        
        # 確率の合計が1になるように正規化（近似のため）
        prob_sum = sum(probs)
        normalized_probs = [p / prob_sum for p in probs]
        
        # エントロピー計算
        entropy = -sum(p * math.log(p) for p in normalized_probs if p > 0)
        uncertainties.append(entropy)
    
    # 文全体の不確実性スコア（平均エントロピー）
    mean_uncertainty = np.mean(uncertainties)
    
    return content, mean_uncertainty

# 実行例
prompt = "2024年の日本のGDP成長率予測について教えて"
answer, score = get_completion_with_uncertainty(prompt)

print(f"回答: {answer[:50]}...")
print(f"不確実性スコア: {score:.4f}")

予測エントロピーの解釈

• 低スコア（例: < 0.2）: モデルは回答に高い自信を持っています。定型的な挨拶や、よく知られた事実について述べる場合に見られます。
• 高スコア（例: > 0.8）: モデルは単語選びに迷っています。これは、知識が曖昧であるか、質問自体が難解であることを示唆します。

このスコアを監視するだけでも、明らかに「適当なことを言っている」ケースを弾くことができます。

---

5. 実装ステップ2：意味レベルの「一貫性スコア」を算出する

トークンレベルのエントロピーには弱点があります。それは、「自信満々に嘘をつく」場合です。モデルが間違った情報を確信を持って出力する場合、トークン確率は高くなり、エントロピーは低くなります。

これを防ぐために、Semantic Consistency（意味的一貫性）の評価を行います。

同じ質問をN回投げて回答のばらつきを見る手法

人間でも、自信がないときは聞かれるたびに答えが微妙に変わることがあります。LLMも同様です。同じプロンプトで複数回生成を行い（Temperature > 0.7）、その回答群の内容がどれだけ一致しているかを計測します。

Self-Consistencyの実装

回答の一致度を測るには、単純な文字列一致ではなく、Embedding（ベクトル化）を用いた意味的類似度を使用します。

from sklearn.metrics.pairwise import cosine_similarity

def get_semantic_consistency_score(prompt, n=5):
    # 1. 同じプロンプトでN回回答を生成
    responses = []
    for _ in range(n):
        response = client.chat.completions.create(
            model="gpt-3.5-turbo",
            messages=[{"role": "user", "content": prompt}],
            temperature=1.0  # 多様性を出すために温度を上げる
        )
        responses.append(response.choices[0].message.content)
    
    # 2. 回答をベクトル化（Embedding）
    embeddings = []
    for text in responses:
        emb_response = client.embeddings.create(
            input=text,
            model="text-embedding-3-small"
        )
        embeddings.append(emb_response.data[0].embedding)
    
    # 3. ベクトル間のコサイン類似度行列を計算
    sim_matrix = cosine_similarity(embeddings)
    
    # 4. 類似度の平均値をスコアとする（1に近いほど一貫性が高い）
    # 対角成分（自分自身との類似度=1）を除いて平均をとる
    off_diagonal_elements = sim_matrix[~np.eye(sim_matrix.shape[0], dtype=bool)]
    consistency_score = np.mean(off_diagonal_elements)
    
    return consistency_score, responses

# 実行例
score, texts = get_semantic_consistency_score("日本の首都はどこ？")
print(f"一貫性スコア: {score:.4f}") # 高い値になるはず

score_bad, texts_bad = get_semantic_consistency_score("架空の生物『モグモグ』の生態について教えて")
print(f"一貫性スコア: {score_bad:.4f}") # ハルシネーションにより低い値になる傾向

クラスタリングによる回答の分散検知

このスコアが低い場合、モデルの回答は定まっていません。これは「事実が存在しない」か「モデルが知識を持っていない」ことの強力なシグナルとなります。特にRAGシステムにおいて、検索結果に矛盾する情報が含まれている場合などにも、このスコアは敏感に反応します。

---

6. 統合と運用：スコアに基づく条件分岐とリスク回避フロー

2つの指標（トークンレベルのエントロピー、意味レベルの一貫性）を手に入れたら、次はそれを業務フローに組み込みます。

不確実性閾値（Threshold）の設定とチューニング

運用開始前に、テストデータを用いて適切な閾値を決定します。

• 安全ゾーン: エントロピー低 ＆ 一貫性高 → 自動回答
• 注意ゾーン: エントロピー中 程度 → 「参考情報として提示します」等の注釈付きで回答
• 危険ゾーン: エントロピー高 or 一貫性低 → 回答拒否 または 人間へエスカレーション

「回答しない」勇気を持つAIの設計

ビジネスや臨床現場での利用において最も危険なのは、もっともらしい嘘です。「申し訳ありませんが、確実な情報が見つかりませんでした」と回答することは、嘘をついて誤った判断を誘発するよりも遥かに価値があります。ユーザーの安全を守るためにも、この「回答拒否機能」を実装するためのロジックとして、不確実性スコアを活用します。

MLOpsダッシュボードでの可視化と監視

日々の運用の中で、不確実性スコアの平均推移をモニタリングします。もし特定のトピック（例：新製品に関する質問）で急激にスコアが悪化した場合、それはRAGの参照ドキュメントが古いか、新たな種類の問い合わせが増えている兆候です。これを検知し、ナレッジベースを更新するサイクルを回すことが、真の運用改善です。

---

7. 成果の証明：不確実性スコアを用いたSLAとROIの策定

最後に、技術的な実装を経営層向けの言葉に翻訳します。不確実性の定量化は、AI導入のROIを正当化するための強力な武器になります。

誤回答コストの削減効果シミュレーション

「AIが間違えたときのリスク」をコスト換算します。

• 従来: リスクが見えないため、全件人間がダブルチェックする必要がある。
  • コスト = AI利用料 + 人件費（全件）
• 導入後: スコアに基づき、高リスクな20%のみを人間がチェックする。
  • コスト = AI利用料 + 評価計算コスト + 人件費（20%）

この差分が、不確実性定量化技術導入による直接的なROIです。計算リソース（APIコール数や計算時間）は増えますが、人件費削減効果と比較すれば微々たるものです。

社内SLA（サービス品質合意）へのスコア適用

情報システム部門として、社内ユーザーに対しSLAを定義できます。

• 「信頼度スコア0.9以上の回答のみを『確定情報』として表示します」
• 「それ以外は『推論』としてマークし、ソースの確認を促します」

このように明文化することで、ユーザー側の過度な期待を抑制しつつ、安心してツールを使える環境を提供できます。

経営層へのレポートフォーマット例

• 当月のAI回答総数: 10,000件
• 高信頼度（自動処理）: 8,500件 (85%)
• 要確認（人間介入）: 1,500件 (15%)
• 阻止したハルシネーション（推定）: 300件

このように「どれだけのリスクを未然に防いだか」を数字で示すことが、AIプロジェクトの継続予算を獲得するための鍵となります。

---

まとめ：不確実性を味方につける

AIは魔法の杖ではありません。確率論で動く計算機です。その「不完全さ」を隠すのではなく、データサイエンスの力で数値化し、管理可能なプロセスに落とし込むことこそが、エンジニアの腕の見せ所であり、社会実装を推進するための鍵となります。

今回紹介した手法は、PythonとAPIさえあれば今日からでも試行可能です。まずは主要なユースケースで不確実性スコアを計測し、自社のAIがどれだけ「自信を持って」答えているかを確認してみてください。新しい技術に対する不安をデータで解消し、その数字は、次のDX戦略を描くための確かな羅針盤となるはずです。

より具体的な導入事例や、業界別の閾値設定のベンチマークについては、専門的な知見を参考にすることをおすすめします。適切に導入しているケースでは、AIの精度向上だけでなく、リスク管理の自動化に投資し、ユーザーのQOL向上に繋げています。