LLMの出力は、よく「幻覚」と呼ばれます。しかし現場では、もっと厄介な現象が起きています。モデルが迷いなく、体裁の整った文章で、根拠のない主張を返す——いわゆる「確信を持った誤り」です。
この記事では、OpenAIとAnthropicのAPIを使い、1日およそ1,000回の推論を回すプレゼン生成システムを運用するGourav Singla氏の実践記（SD Times）をもとに、LLM出力の信頼性を上げる具体策を整理します。
この記事でわかること
- モデルが自信満々に間違える構造的理由
- スキーマ検証・RAG・温度設定など、現場で使える5つのパターン
- よく勧められるが効果が薄い3つのアプローチ
- 本番運用に最低限必要な信頼性スタック
なぜモデルは正しそうに聞こえるのか
LLMは、人間が高品質と評価しやすい「断定的な文体」を学習します。一方で推論時には真偽を判定する手段がありません。正しく記憶した事実も、その場で補間したもっともらしい文も、モデル内部では同じ感覚で処理されます。
特に問題になりやすいのは次の3つです。
- 数値の主張 — 入力ではなく学習分布から統計や日付を生成する
- 固有名詞 — 人名・企業名・製品名の綴りが微妙にずれたり、別人格が混ざる
- 構造化出力 — JSONスキーマなどの形式指定に、たいていは従うが学習上の癖と衝突すると崩れる
信頼性対策は、この「正しそうに見える誤り」を前提に組み立てる必要があります。
パターン1：プロンプト説明よりスキーマ強制
「title、bullets、summaryを持つJSONを返せ」と文章で書くだけでは不安定です。余計なキーが増えたり、Markdownのコードフェンスで包まれたり、不要と判断したキーが消えたりします。
信頼性の高い方法は、APIの構造化出力モードを使うか、推論直後にスキーマ検証を走らせ、失敗時に1回だけ自動リトライすることです。Singla氏のシステムでは、構造化コンテンツの推論をすべてPydanticモデルで検証し、エラー内容をプロンプトに追記して再試行しています。これによりフォーマット失敗率はおおよそ8%から0.5%未満に下がったと報告されています。
OpenAIのStructured Outputsも、JSON Schemaへの準拠をAPI側で保証する機能として位置づけられています。ただし公式ドキュメントでも、スキーマ準拠でも内容の誤りは起こり得ると注意されています。
原則はシンプルです。欲しい形式を説明するのではなく、出力空間そのものを制約することです。
パターン2：事実はプロンプトに埋め込む
入力テキストのトピックだけ渡し、詳細をモデルに補完させると、トピックは合っていても中身が捏造されます。対策は積極的なグラウンディングです。
Singla氏の方式では、システムプロンプトに「出力のすべてが提供ソースに直接裏付けられること」「ソースにない統計や主張を足さないこと」「裏付けがなければ省略すること」を明示します。さらにソース全文をタスク指示より前に置きます。コンテキストの前半ほど注意が向きやすいため、順序の入れ替えだけでも作り話は減るとされています。
パターン3：温度は正確さではなくばらつきを制御する
温度（temperature）を下げても、事実の正確さは上がりません。最も確率の高い出力が誤りなら、低温でも一貫して誤ります。温度が効くのは出力の多様性です。
Singla氏の運用目安は次のとおりです。
- 構造化出力タスク：0.2〜0.4
- クリエイティブな文章：0.7〜0.9
- 提供ソースからの事実抽出：0.1（同じ事実を毎回同じように抜き出すため）
top-p（核サンプリング）も重要です。温度0.1でもtop-p 0.95だと、候補トークンの幅が広く低温の恩恵が薄れます。一貫性重視では温度0.1・top-p 0.1の組み合わせを使い、やや不自然な文体と引き換えに安定性を取るとしています。
パターン4：Chain-of-Thoughtを信頼性シグナルに使う
Chain-of-Thought（段階的推論）は、推論精度向上だけでなく、推論トレースの検査材料になります。推論中に不確かさを示しながら、最終出力では断定的に書くケースは危険信号です。
Singla氏は高リスク出力に限り、推論トレースを別プロンプトで採点し、不確かさが出た主張を人間レビュー対象に振り分けています。レイテンシとコストは増えますが、品質がユーザー維持率に直結する本番機能では妥当な投資と位置づけています。
パターン5：RAGで原本をアンカーにする
長文をそのままコンテキストに入れられないとき、要約や切り詰めは新たなリスクを生みます。要約は「何が重要か」の判断をモデルに委ね、切り詰めは必要な段落を無作為に捨てます。
RAG（Retrieval-Augmented Generation、検索拡張生成）は、原文をインデックスに保持し、推論時に関連チャンクだけをコンテキストへ引き込みます。モデルは自分の要約ではなく、取得したテキストに接地します。Singla氏の実装ではチャンクにソース位置のメタデータを付け、生成された主張を原文の位置まで遡ってスポットチェックできるようにしています。
効果が薄いとされるよくある手法
現場でよく勧められる次の3つは、Singla氏の運用では信頼性向上に結びつきにくいと報告されています。
自己一致投票 — 同じプロンプトを複数回実行し多数決する方法です。学習時の系統的バイアスで誤答が固定されている場合、誤答が毎回勝ちます。ランダムなばらつきは拾えても、構造的な偏りは拾えません。
モデル自身への信頼度評価 — 誤答にも高信頼度を付ける頻度は、正答と大差ないため、校正されていません。
ネガティブプロンプト — 「幻覚するな」「事実をでっち上げるな」といった禁止指示は、測定可能な効果がないとされています。モデルには、指示一つで切り替えられる別モードが存在しないためです。
本番で組む最低限の信頼性スタック
個別の対策だけでは不十分です。Singla氏が推す最小構成は次の5層です。
- スキーマ強制 — 構造化出力モード、または検証失敗時の自動リトライ1回
- 明示的グラウンディング — ソースをプロンプトに含め、未裏付けの主張を禁止
- チャンクの位置メタデータ — 取得コンテンツを監査可能にする
- 温度の使い分け — 構造化・事実抽出は低温、創造性が要る場面だけ高温
- 人間レビュー導線 — スキーマ失敗や低信頼ヒューリスティックに引っかかった出力を、そのまま配信せずレビューキューへ
これらを重ねると、確信を持った誤りは「頻発する事象」から「管理できる例外」へ移せます。LLM出力の信頼性はオンオフの属性ではなく、周辺インフラで段階的に上げるものです。
モデルを神託にしない設計が前提
モデルは改善を続けています。しかし「自分が知っていることと、今生成していること」を区別できない点は、アーキテクチャ上の制約であり、次のリリースで消えるバグではありません。
信頼できるAI機能を出荷しているチームは、モデルを単体の答え役ではなく、システムの一コンポーネントとして扱います。検索、検証、グラウンディング、レビュー振り分け——モデルが担えない信頼性は周辺で補い、モデルには得意な変換と生成だけを任せる。この分業が、デモでは動くが本番で崩れるギャップを埋める実務の型です。