LLMが事実と違う内容を自信満々に答える場面は、コーディングエージェントでも社内チャットでも珍しくありません。多くは「モデルが悪意を持って嘘をついている」というより、正確性だけの評価が「分からない」より推測を有利にしている結果です。封じるにはプロンプト一文の追加だけでは足りず、検証パスと採点インセンティブの再設計まで含めて考える必要があります。
📑目次
本記事では、OpenAIの公式解説、Nature系の査読付き研究、ACLのChain-of-Verification、臨床ドメインの mitigation 研究、および独立メディアの解説を横断し、開発・MLOpsチームが今日から触れる判断軸に落とします。発見のきっかけになった記事は参考にとどめ、事実は独立ソースで確認しています。
なぜ LLM は「わからない」と言えないのか
結論から言うと、事前学習は「もっともらしい次トークン」を予測する最適化であり、事実判定そのものではありません。 そのうえで、主要なベンチマークが正答率だけを見ると、「分からない」は0点、運の良い推測は満点になり得ます。棄権より推測が合理的な戦略になるのは、性格の問題というより採点と学習目標の設計問題です。
公式・査読ソースの整理
OpenAIの公式解説（Why language models hallucinate）は、accuracy-only の scoreboard が guessing を奨励し、適切な不確実性表明を不利にすると整理しています。
査読付きの Nature 論文（Kalai / Nachum / Vempala ら、2026-04-22）も、次単語予測と正確性ベース評価が不当な推測を報い、主要メトリクスが不確実表明を罰しやすい、と論じています。
実務で使える言い換え
実務で使える言い換えは次のとおりです。
- 「モデルが嘘つき」ではなく「棄権が採点上損をする」
- 知識ギャップだけの問題ではなく、スコア設計が行動を歪める
- 専用のハルシネーション試験を横に置くだけでは不十分で、既存 scoreboard 側のインセンティブも直す
誕生日のようなスパースな事実では、「分からない」より当てずっぽうの方が期待スコアが高くなりやすい、という説明は日本語の実務解説（Qiita: tsubasa_k0814）でも繰り返し使われています。チーム内の説明では、この「期待値の歪み」を共有すると対策の優先順位が揃いやすくなります。
プロンプトでできることと限界
誠実さ指示・反ハルシネーション指示は有効ですが、完全制御ではありません。 temperature を 0 にするだけでは代替できません。
臨床研究で見えた効果と限界
Communications Medicine（Omar ら、2025-08-02）の臨床 adversarial 研究では、植え付けられた虚偽詳細をモデルが elaboration する割合が 50–82% に及びました。
明示的な mitigation prompt 後、平均はおよそ 66% から 44% へ低下し、最良例（GPT-4o）では 53%→23% でした。一方 temperature=0 には有意な低減がなく、温度設定は誠実さ指示の代わりになりません。
現場でまず入れる文言パターン
現場でまず入れる文言パターンは次です。
- 根拠がなければ推測せず「わからない／要確認」と書く
- 出典・tool 結果のない断定を禁止する
- 自信度や検証状態（未検証／検証済）を明示する
- 高リスク領域（法務・医療・顧客への確約）では人間レビューを必須にする
⚠️ 残余リスクは残ります。プロンプト改善を「封じ込み完了」と誤認すると、エージェントが長文で自信満々に誤る経路が残ります。プロンプトは入口であり、検証と採点が本丸です。
第二パス検証（Chain-of-Verification）
一発の「丁寧な回答」より、下書きと検証を分離した方が嘘を減らせます。 ACL Findings 2024 の Chain-of-Verification（CoVe、Dhuliawala ら）は、次の4段を示します。
- draft … まず回答案を書く
- verification questions … 主張ごとに独立した検証質問を作る
- answer without looking back … 初稿の主張に引きずられず検証質問へ答える
- final verified response … 検証結果だけを根拠に確定回答を書く
エージェント／RAGへの写像
エージェント／RAGへの写像例:
| CoVe 段 | 実装イメージ |
|---|---|
| draft | 通常の生成ノード |
| verification questions | 主張抽出 → 検索／コード実行クエリ生成 |
| independent answers | tool 呼び出し・引用取得（初稿本文をコンテキストから外す） |
| final | 検証ログのみを条件に再生成／ゲート通過 |
コストが心配な場合は、全ターン dual-pass にせず、引用必須・顧客確約・変更差分が大きい回答だけ第二パスにする段階導入が現実的です。RAG運用では、検索品質そのものの設計も並行して見直すと効果が出やすいです。関連して、知識取得の運用設計は Agent Searchで知識を運用する実践 も参考になります。
評価・採点インセンティブの直し方
なぜ scoreboard を直すのか
本番の正しさだけを見る scoreboard を放置したままプロンプトだけ直しても、モデル選定と回帰評価は再び推測側に傾きやすいです。 OpenAIや Ledge.ai の整理が指摘するように、専用ハルシネーション試験の横置きだけでなく、既存の accuracy 系 scoreboard に uncertainty credit を埋め込む発想が必要です。
設計候補
代表的な設計候補:
| 方式 | ざっくりした採点 | ねらい |
|---|---|---|
| behavioral calibration（Arize / Vempala 解説） | correct=1、IDK=0、wrong=−t/(1−t) | 目標正答率 t に応じて自信誤りの罰を調整 |
| 実務向け簡易例（Qiita） | 正解 +1 / 自信誤り −3 / 不明 0 | 棄権が当てずっぽうより得になる閾値を作る |
| open-rubric・部分点（Nature 系） | 不確実表明に部分点、自信誤りを重罰 | 主要ベンチの見出し指標そのものを修正 |
最短の next action
読者の最短 next action は、「社内オフライン評価に 不明を許す1本 を追加し、自信誤りを不明より重く罰する」ことです。モデル比較やエージェント回帰でも、正答率だけを並記すると“当てにいくモデル”が上位に見えます。評価設計の継続運用は MLOpsの継続的学習とエージェント評価 とセットで考えると、Demo Hell を避けやすくなります。
運用比較表と導入チェックリスト
手段の比較
手段を並べると、層でリスクを下げる発想がはっきりします。
| 手段 | 主な効果 | 残余リスク | 導入コスト | 向く場面 |
|---|---|---|---|---|
| 誠実さ・反ハルシネーションプロンプト | 自信過剰な捏造を抑制（臨床研究で半減級の例あり） | 残存ハルシネーション | 低（文言追加） | チャットUI・即時改善 |
| 第二パス検証（CoVe 系） | 主張単位の自己検証・tool 照合 | 手順省略・検証質問の質 | 中（レイテンシ増） | エージェント・長文回答 |
| 評価・採点の再設計 | 推測最適を構造的に崩す | 既存ベンチ互換・ラベルコスト | 中〜高 | モデル選定・社内 eval |
| 組み合わせ | 層でリスク低減 | 運用複雑化 | 段階導入 | 本番 RAG / コードエージェント |
出典
出典（表の定量・手法の根拠）:
- OpenAI
- Nature 2026-04-22
- Communications Medicine 2025-08-02
- ACL CoVe
- Arize AI（2025–2026年時点の公開資料）
今日からのチェックリスト
今日からのチェックリスト
- システムプロンプトに「不明なら推測せず棄権／要確認」を明示したか
- 重要主張に引用・tool・第二パス検証を必須化したか
- オフライン評価で「自信誤り」を「不明」より重く罰しているか
- temperature=0 だけに頼っていないか
- 人間レビューが必要な領域（法務・医療・顧客向け確約）を切り分けたか
- 1週間、自信誤り率と棄権率を測るダッシュボードまたはログ集計があるか
プロンプト設計の粒度（どこまで system に書くか、tool 境界をどう切るか）は、GPT-5.6プロンプト設計の実務ガイド と組み合わせると実装に落としやすいです。
関連記事:
- MLOpsの継続的学習とエージェント評価｜Demo Hellを避ける実務設計
- Open Knowledge Format（OKF）とは？エージェント向けMarkdown知識仕様の導入判断
- エージェント向け検索の設計｜どう探させ、何を返すか
よくある質問（FAQ）
「わからないと言え」と書けば十分ですか？
有効ですが不十分です。臨床 adversarial 研究でも mitigation prompt 後に残余があり、検証パスと採点設計の併用が必要です。
温度を 0 にすればハルシネーションは消えますか？
いいえ。同研究では temperature=0 に有意な低減はなく、誠実さ指示の代替になりません。
なぜベンチマークで高得点なモデルが平気で嘘をつくのですか？
正確性だけの採点では棄権が 0 点、運の良い推測が満点になり得るため、学習・選抜が推測側に傾く構造があります（OpenAI / Nature）。
開発チームが最初にやるなら何が最短ですか？
(1) 棄権指示プロンプト (2) 重要回答の検証ステップ (3) 社内 eval に「不明可・自信誤り罰」を1本入れる、の順が現実的です。
Chain-of-Verification は追加 API コストが心配です
全ターンではなく、引用必須・高リスク・ユーザー確約が絡む回答だけ dual-pass にする段階導入が現実的です。
まとめと次のアクション
LLMの「平気な嘘」の主因は、モデルの性格というより 評価と学習インセンティブ にあります。プロンプトはすぐに効く入口ですが、検証パスと採点再設計まで進めて初めて構造が変わります。
次の一歩は、上記チェックリストを自サービスの1ワークフローに適用し、1週間の自信誤り率と棄権率を測ることです。数字が見えれば、どこに dual-pass を置き、どこで人間レビューを残すかの議論が具体になります。
著者
krona23
IT業界20年以上の実務経験を持ち、日本国内有数のPVを誇る大規模Webサービスで事業部長・CTOを複数社で歴任。Windows/iOS/Android/Webと技術の変遷を経験し、現在はAIネイティブへの変革に注力。DevGENTでは、AIコードエディタ・自動化ツール・LLMの実践的な使い方を日英西3言語で発信中。
コメントを残す