AIの「迷い」を数値化する：Logprobs活用によるハルシネーション検知と信頼度スコア実装

生成AIを活用したシステム開発において、AIがもっともらしい嘘をつく「ハルシネーション」は、避けて通れない深刻な課題です。社内文書を検索して回答を作るRAG（検索拡張生成）や、顧客対応のチャットボットが事実と異なる情報を出力すれば、ビジネス上の大きなリスクにつながります。

もちろん、「不確かな場合は『わかりません』と答えてください」とプロンプト（指示文）で制御することも有効なアプローチの一つです。しかし、それだけでは完全に防ぎきれないケースが珍しくありません。なぜなら、AI自身が「自分の回答は正しい」と誤って認識している場合や、テキストを生成する仕組みそのものに確率的なゆらぎが含まれているためです。

このような課題に対して、AIモデルの「内部の声」に直接耳を傾ける、より確実で論理的なアプローチがあります。
それが、Logprobs（対数確率）の活用です。

Logprobsは、主要な生成AIのAPIが標準で提供している非常に強力な機能ですが、実際の開発現場では十分に活用されていないケースが少なくありません。

最新の動向として、旧世代のモデルが段階的に廃止され、より高度な推論能力を持つ新モデルへの移行が進んでいます。このように基盤となるAIモデルが刷新されても、出力の信頼性をシステム的に担保する仕組みの重要性は変わりません。むしろ、新しいモデル環境へ安全に移行するタイミングにおいてこそ、Logprobsは回答のブレを定量的に検知するための重要な指標となります。

この対数確率の値を適切に読み解くことで、高コストな外部評価システムを別途構築せずとも、低遅延かつ低コストで回答の信頼度をスコアリングし、システム全体を安全に制御することが可能になります。

本記事では、統計学の深い専門知識がなくても直感的に理解できるよう、Logprobsの基本概念から具体的な実装ロジック、そして実際のビジネス現場における制御フローへの落とし込み方までを、論理的かつ明快に解説していきます。

なぜAIは平気で嘘をつくのか？確率論から見る生成の裏側

技術的な実装に入る前に、まず「なぜAIは嘘をつくのか」、そのメカニズムを確率論の視点から整理しておきましょう。ここを理解することで、Logprobsが何を意味しているのかが直感的に掴めるようになります。

「もっともらしい回答」が生まれる仕組み

私たちが普段使っている大規模言語モデル（LLM）は、本質的には「次に来る単語（トークン）を予測するシステム」です。これを Next Token Prediction（次トークン予測） と呼びます。

AIは、学習した膨大なテキストデータに基づいて、「今までこういう文脈が来たら、次はこの単語が来る確率が高い」という計算を常に行っています。AIにとっての「回答」とは、事実に基づいた真実の記述ではなく、確率的に最も繋がりが良い言葉の連鎖に過ぎません。

例えば、「日本の首都は？」という入力に対して、AI内部では次のような確率計算が行われていると考えられます。

• 「東京」：99.9%
• 「大阪」：0.05%
• 「京都」：0.02%

この場合、AIは迷わず「東京」を選びます。これは非常に信頼度が高い状態です。

一方で、「2024年の架空のSF映画『ギャラクシー・ウォー』の監督は？」というような、学習データに存在しない（あるいは曖昧な）質問をされた場合、AI内部の確率は大きく揺らぎます。

• 「スティーブン」：30%
• 「クリストファー」：25%
• 「ジェームズ」：20%
• 「リドリー」：15%

ここでAIは、僅差で1位になった「スティーブン」を選択し、さらにそれに続くそれっぽい苗字を生成し始めます。ユーザーから見れば、AIは「スティーブン・〇〇監督です」と断定的に答えているように見えますが、AIの内部では「かなり自信がないけれど、とりあえず確率が一番高いこれを選んだ」という状態なのです。

決定論的プログラムと確率論的モデルの違い

従来のITシステム（決定論的プログラム）であれば、データベースに答えがなければエラーを返します。しかし、生成AI（確率論的モデル）は、確率が低くても何かしらの言葉を出力しようとする性質があります。

これが、ハルシネーションの正体の一つです。

重要なのは、AIが「自信満々で答えているとき」と「迷いながら答えているとき」では、内部の確率分布が全く異なるという点です。テキストとして出力された結果（回答文）だけを見ていると、この違いには気づけません。

しかし、APIを通じてモデル内部の確率値を取得すれば、AIの「迷い」を数値として可視化することができます。それが Logprobs です。

Logprobs（対数確率）入門：AIの「迷い」を可視化する指標

では、具体的に Logprobs とは何でしょうか。開発者の視点で、APIから得られるデータをどう解釈すべきかを解説します。

Logprobsとは何か？直感的な理解

Logprobs（Log Probabilities）は、その名の通り「確率の対数」をとった値です。数学的な定義はさておき、実務上は以下の感覚を持っておけば十分です。

• 値は常に「0以下の負の数」になる（0が最大値）。
• 0に近いほど「自信がある」。
• 負の数が大きくなる（マイナス方向に進む）ほど「自信がない」。

具体的な数値のイメージを見てみましょう。

Logprobs値	確率（%）	AIの心理状態（イメージ）
0.0	100%	「これ以外ありえない！絶対の自信がある！」
-0.01	約99%	「ほぼ間違いないでしょう」
-0.1	約90%	「かなり自信があります」
-0.69	約50%	「半々かな...どっちだろう？」
-2.3	約10%	「全然わからないけど、あえて言うなら...」
-5.0	1%未満	「当てずっぽうです」

このように、Logprobsの値を見ることで、その単語がどれくらいの確信度で選ばれたのかが一目瞭然になります。

APIレスポンスに含まれる情報の読み解き方

主要な生成AIのAPIを利用する場合、リクエスト時に logprobs: true という設定を追加することで、生成されたテキストと共にこの数値を取得できます。

さらに、上位の候補を取得するパラメータ（例えば上位5件など）を指定すると、実際に選ばれた単語だけでなく、「選ばれなかったが候補に挙がっていた他の単語」の情報も含めることができます。

例えば、「日本の首都は？」に対して「東京」と答えた場合のレスポンスデータは、以下のようになります。

{
  "token": "東京",
  "logprob": -0.0001,  // 非常に高い自信
  "top_logprobs": [
    { "token": "東京", "logprob": -0.0001 },
    { "token": "京都", "logprob": -12.5 },
    { "token": "大阪", "logprob": -15.2 }
  ]
}

一方、AIが回答に自信を持てない場合のレスポンス例です。

{
  "token": "スティーブン",
  "logprob": -1.2,  // 自信がない（確率約30%）
  "top_logprobs": [
    { "token": "スティーブン", "logprob": -1.2 },
    { "token": "クリストファー", "logprob": -1.3 },
    { "token": "ジェームズ", "logprob": -1.5 }
  ]
}

後者の場合、1位と2位の差がほとんどありません。これはAIが選択肢の間で激しく迷っている証拠です。この「迷い」を検知することで、ハルシネーション（もっともらしい嘘）のリスクを事前に察知し、回答の信頼性をスコアリングすることが可能になります。

確率（Probability）と対数確率（Log Probability）の関係

「なぜ素直に確率（%）で扱わないのか？」と疑問に思うかもしれません。これには計算上の理由があります。

確率は0から1の間の小さな数になります。複数の単語が続く文章全体の確率を計算しようとすると、「0.9 × 0.8 × 0.95...」のように掛け算を繰り返すことになり、数値が極端に小さくなってコンピュータで扱いにくくなります（アンダーフローという現象です）。

対数（Log）を使うと、この掛け算を「足し算」に変換できます。つまり、文章全体の確率は、各単語のLogprobsを単純に足し合わせるだけで計算できるのです。これが、コンピュータ処理において対数が好まれる理由の一つです。

信頼度スコアリングの実装：不確実性を数値化する計算ロジック

APIから取得した単語ごとのLogprobsを、実際のシステムに組み込むための具体的なスコアリング手法について解説します。

APIからは各単語の対数確率が返ってきますが、実運用で本当に知りたいのは「この回答文全体、あるいは重要な部分が信頼できるか？」という総合的な指標です。これを算出するために、いくつかの計算アプローチが存在します。用途に合わせて最適なものを選択することが、精度の高いシステム構築の鍵となります。

単純平均法 vs 最小確率法

最も直感的でよく使われるのは、文章内の全単語のLogprobsの平均値を取る方法です。しかし、これには一長一短があります。

1. 平均対数確率（Average Logprob）

• 計算式：全単語のLogprobsの合計 / 単語数
• 特徴：文章全体の「滑らかさ」や「自然さ」を測るのに適しています。全体的な生成の安定性を評価する際によく用いられます。
• 欠点：長い文章の中に1つだけ自信のない嘘（確信度の低い固有名詞など）が含まれていても、他の一般的な単語（「です」「ます」など）の高い確率によって平均値が押し上げられ、重大な誤りを見逃してしまうリスクがあります。

2. 最小対数確率（Min Logprob）

• 計算式：文章内で最も低いLogprobs値を採用
• 特徴：「鎖の強さは、最も弱い輪で決まる」という考え方に基づいています。文章中に一つでも自信のない単語があれば、全体のスコアを低く評価します。
• メリット：ハルシネーション検知において非常に強力な効果を発揮します。事実関係を問う質問において、AIが固有名詞や数値を捏造する場合、その部分のLogprobsだけが極端に下がることが多いため、この手法でピンポイントに異常を検知できます。

RAGやQAボットの信頼度判定においては、「最小対数確率」または「下位10%の平均」のような、低い値を重視するロジックを採用する方が、誤回答の流出を防ぐ効果が高いと考えられます。
また、APIのモデル移行期には注意が必要です。新しい標準モデルへ移行するようなタイミングでは、モデルの内部構造の変更によってLogprobsの出力傾向が変化する可能性があります。そのため、新しいモデルへの移行時には、必ず既存のプロンプトを再テストし、スコアリングの基準値が適切かどうかを実証的に再検証することが不可欠です。

トークン長による補正の必要性

文章が長くなればなるほど、Logprobsの合計値は必ず小さくなっていきます。対数は負の値をとるため、足し合わせるほど数値が減少するからです。そのため、単純な合計値で長文と短文を比較することはできません。

スコアリングを適正に行うためには、必ず単語数で割って平均化するか、前述のように最小値を見るアプローチが必要です。
また、非常に短い回答（「はい」「いいえ」など）は、必然的に確率が高くなりやすい傾向があります。そのため、回答の長さもある程度考慮に入れた評価軸を持つのが理想的です。極端に短い回答の場合は、別のルールベースの検証を組み合わせるなどの工夫も有効です。

Linear Probability（線形確率）への変換と解釈

エンジニア以外の担当者にシステムの精度を説明する際、Logprobs（-0.5など）の数値のままでは直感的に理解されにくいという課題がよく発生します。

そのような場合は、計算式を用いて通常の確率（0〜100%）に戻して提示すると、圧倒的に伝わりやすくなります。

• Logprob: -0.05 → 信頼度: 約95%
• Logprob: -0.69 → 信頼度: 約50%
• Logprob: -2.30 → 信頼度: 約10%

システム内部の判定ロジックでは精緻なLogprobsで計算を行い、管理画面での可視化やログ分析のレポートではパーセンテージで表示する、という使い分けが非常に有効です。これにより、技術チームとビジネスチームの間で、AIの「迷い」に対する共通認識を持ちやすくなります。

ユースケース解説：不確実性スコアに基づく制御フローの設計

スコアが計算できたら、次はその数値を活用してアプリケーションの振る舞いをどう制御するかが問われます。ここでは、具体的なシナリオに基づいた設計パターンと制御フローの構築方法を解説します。

シナリオ：社内QAボットでの回答フィルタリング

社内規定や業務マニュアルを検索して回答を生成するRAGシステムを想定してください。このようなシステムでは、誤った就業規則や手続きを案内するハルシネーションは重大なリスクにつながります。

この場合、以下のようなステップでフローを組むことで、誤情報の提供リスクを最小化できます。

1. 回答の生成とスコア取得: ユーザーの質問に対してAIが回答を生成する際、同時にLogprobsのデータを取得します。
2. 信頼度スコアの計算: 生成された各単語の確率から、回答全体の「最小対数確率」や平均スコアを算出します。
3. 閾値（Threshold）による条件分岐: 算出されたスコアを事前に定義した基準値（閾値）と比較し、システムのアクションを決定します。

【アクション分岐の具体例】

• 高信頼度（Score > -0.2）: AIが回答に強い自信を持っている状態です。生成されたテキストをそのままユーザーに表示します。
• 中信頼度（-0.2 >= Score > -1.0）: 一定の不確実性が含まれる状態です。回答を表示しつつ、リスクを軽減するための注釈を付与します。
  • 例：「確信度は中程度です。念のため、以下の参照ドキュメントリンクも併せてご確認ください。」
• 低信頼度（Score <= -1.0）: ハルシネーションの可能性が高い状態です。回答の出力をシステム側でブロックし、安全な代替対応を実行します。
  • 例：「申し訳ありません。確実な情報が見つかりませんでした。詳細は担当部署へ確認することをおすすめします。」

しきい値（Threshold）の設定とチューニング

「閾値を具体的にいくつに設定すべきか」という点は、システム実装において頻繁に議論されるポイントです。これには絶対的な技術的正解が存在するわけではなく、「誤検知」と「見逃し」のどちらを許容するかという、ビジネス要件に基づいた判断が求められます。

• 安全重視（厳格な設定）: 閾値を高く設定（例: -0.1）します。少しでも不確実な回答はすべて弾くため、ハルシネーションの流出を極限まで防ぎます。しかし、回答拒否の頻度が増加するため、ユーザーの利便性は低下する傾向があります。
• 利便性重視（寛容な設定）: 閾値を低く設定（例: -1.5）します。ある程度の不正確なニュアンスは許容し、とにかく何らかの回答を返すことを優先するアプローチです。

初期段階では、システムを稼働させながらデータをログとして蓄積することを強く推奨します。実際のユーザーからの質問、AIの生成テキスト、そしてLogprobsの値をセットで記録し、定期的にサンプリング評価を行います。「この程度のスコアであれば実用上問題ない」という実運用ラインを、机上の空論ではなく実証データに基づいて見極めることが最も確実なチューニング手法です。

低信頼度時のフォールバック戦略

スコアが低いと判定された場合、単に「わかりません」とエラーメッセージを返すだけでは、優れたユーザー体験とは言えません。より高度なAIシステムでは、以下のような自己修正プロセスや引き継ぎを自動的に走らせることが可能です。

1. 検索クエリの自動再構築: ユーザーの質問意図をAIが正確に捉えられていない、あるいは検索精度が低い可能性があります。AI自身に別の検索キーワードを生成させ、再度ドキュメント検索からやり直す処理を組み込みます。
2. モデルの動的変更（カスケード処理）: 通常時はコスト効率や応答速度に優れた軽量モデルを使用し、低スコアが検出された場合のみ、より高度な推論能力を持つ上位モデルで再生成を試みます。
   • 近年はAPIモデルの世代交代が急速に進んでいます。高度な推論機能を備えた新しい標準モデルを強力な代替手段として設定することで、コストと精度のバランスを劇的に最適化できます。また、開発関連の質問で低スコアが出た場合は、コーディング特化型のモデルへ処理を振り分けるといった柔軟な設計も有効です。
3. 人間へのシームレスなエスカレーション: チャットボットでの解決を諦め、これまでの会話履歴や検索ログを保持したまま、有人オペレーターへ対応を引き継ぎます。

Logprobsという客観的な数値をトリガーとして、こうした柔軟かつ堅牢な分岐ロジックを構築できることこそが、実用的なAIシステム開発における大きな利点と言えます。

導入の注意点と限界：Logprobsが万能ではない理由

ここまでLogprobsの有用性を説明してきましたが、AIソリューション設計の観点から重要な注意点をお伝えします。Logprobsはシステムの信頼性を高める強力な手法ですが、決して万能ではありません。その特性と限界を正確に理解した上で、適切なシステム構成に組み込む必要があります。

「確信を持ってつく嘘」は見抜けない

Logprobsが検知できるのは、あくまで「モデル自身が確率的に迷っている場合」のみです。

もし、モデルが学習段階で誤った情報を「正しい事実」として深く記憶してしまっている場合、モデルはその誤情報を非常に高い確率（自信満々）で出力します。これを「過信（Overconfidence）」と呼びます。

例えば、インターネット上で広く流布している都市伝説や、特定の偏った意見を絶対的な事実として学習している場合、生成される単語のLogprobsの値は「0」に極めて近くなります。つまり、モデル内部に迷いがないため、単一のスコアリングによるフィルタリングを容易にすり抜けてしまうという重大な落とし穴が存在します。

モデルのキャリブレーション問題

LLMは、人間のフィードバックを基に最適化するプロセスを経て継続的に進化しています。

この「人間に好まれる回答」を学習するプロセスにおいて、モデルの確率分布が変化し、実際よりも自信過剰な数値を出力する傾向が生じることが研究で指摘されています。モデルがユーザーの期待に応えようとするあまり、不確実な情報であっても高い確率値を割り当ててしまう現象です。

現在、こうした調整手法はモデルの基盤を支える継続的なプロセスとして位置づけられています。開発者自身がこのプロセスをコントロールできる環境も整いつつありますが、独自のチューニングを行う際は、意図しない確率分布の歪みが生じる可能性があるため、導入時には慎重なテストの実施が不可欠です。詳細な仕様や最新の推奨手順については、必ず公式ドキュメントを確認してください。

したがって、Logprobsの値が示す「90%の自信」が、実際の正答率の90%と完全に一致するとは限りません。数値は絶対的な正解率ではなく、あくまでそのモデル内部での「確信度合い」を示す相対的な指標として扱うことが重要です。

LLM-as-a-Judgeなど他手法との併用推奨

実用的なシステムにおいては、Logprobsを単独の評価基準とするのではなく、「第一の防衛線」として使うのが最も有効なアプローチです。

1. Logprobsチェック: 低コストかつ高速に実行可能。ここで明らかに自信のない回答や、基準値を下回る不確実な生成結果を即座に弾きます。
2. 事実確認（Fact Check）: Logprobsの基準を通過した回答に対して、さらに別のAIモデルを活用した評価手法（LLM-as-a-Judge）や、外部の検索APIを用いた事実確認を行います。これには追加の処理コストがかかりますが、最終的な出力精度は飛躍的に向上します。

このように多層的な安全網を構築することで、処理コストと出力精度のバランスが最適化された、堅牢なAIアプリケーションを実現できます。

まとめ

Logprobsを活用した信頼度スコアリングは、追加のコストをほとんどかけずに実装できる、非常に効率的な品質管理手法です。

• AIの回答は確率的な選択の結果であり、Logprobsでその「内部的な迷い」を可視化できる。
• 「最小対数確率」を見ることで、部分的な捏造やハルシネーションを検知しやすい。
• 閾値を設定し、低信頼度の回答をフィルタリングしたり、再検索させたりするフローの構築が有効。
• ただし、「確信犯的な嘘」は見抜けないため、他の検証手法と組み合わせるのがベストプラクティス。

これからAIプロダクトの品質を一段階上げたいと考えているなら、まずはAPIリクエストの設定に logprobs=true を追加し、実際のログデータを収集するところから始めることをお勧めします。AIが裏側でどれほど迷いながら回答を生成しているか、その「心の声」をデータとして分析することで、より確実なシステム改善の糸口が見えてくるはずです。