なぜ、LLM AIは一般的な機能を持たないアプリの操作質問に、嘘の回答ばかりするのか？

はじめに

近年、LLM（大規模言語モデル）を用いたAIが、質問応答や文章生成、要約、翻訳などの幅広いタスクで活躍するようになっています。しかし実際に使ってみると、意外な弱点に直面することがあります。そのひとつが、「通常のアプリには実装されているが、特定のアプリには事情があって存在しない機能」について質問した際に、AIがその機能が存在するかのように 嘘の説明（ハルシネーション） をしてしまうという現象です。

たとえば、ある機能Xがほとんどのブラウザに実装されているものの、ブラウザBだけは設計上の理由で搭載していない場合、「ブラウザBには機能Xはあるか」と尋ねると、AIは自信たっぷりに「あります」と答え、さらに存在しない設定手順やメニュー名まで説明することがあります。これは単なる勘違いではなく、構造的な問題です。

本稿では、このような「本来存在しない機能をあると答えてしまう」現象がなぜ起きるのかを、LLMの仕組みと情報分布の観点から分析し、最後にこの問題にどう向き合うべきかを考察します。

LLMは統計的生成モデルであり、真偽を判断していない

LLMは、人間のように事実を理解しているわけではありません。大量のテキストデータをもとに、単語や文の並び方の確率的なパターンを学習したモデルです。質問に答えるときも、「最も確率が高い単語列」を出力しているに過ぎず、その内容が真実かどうかを内部的に確認する機能は持っていません。

この性質は、人間で言えば「よく聞く言い回しをそれっぽく繋げて答える」ようなものです。
たとえば学習データ中で「ブラウザ」「機能X」が頻繁に一緒に登場していれば、AIは「ブラウザB」でも同じように「機能X」があるという文脈を推論せずに、確率的に「ある」と出力してしまいます。

つまり、LLMの根本的な目的は「正確性」ではなく「もっともらしさ」であり、そのため存在しないものをあるかのように語るという挙動が起きやすいのです。

「無い」という情報はそもそも学習されにくい

もう一つ重要なのは、インターネットやマニュアルなどにおける情報分布です。人間は、存在する機能については積極的に書きますが、「存在しない機能」については基本的に書きません。
たとえば、「ブラウザBには機能Xが無い」と明言する記事はごくわずかですが、「ブラウザAやCで機能Xを使う方法」といった記事は大量に存在します。

このような情報環境では、LLMは「機能Xが存在する」というパターンばかりを学び、「無い」という希少な情報を見逃してしまいます。
その結果、例外的なアプリについて質問した際も、多数派のパターン（＝ほとんどのブラウザにはある）を優先して生成してしまい、誤答を返すのです。

ここには「ベイズ的事前確率」が働いています。LLMは明示的な確率推論をしているわけではありませんが、学習過程で「ほとんどのブラウザには機能Xがある」という統計を取り込んでいるため、黙っていても「ある」と仮定してしまうという偏りを持ちます。

バグや例外挙動は文脈依存で再現性が低い

さらに、標準的でないアプリの機能欠如やバグは、そもそも文脈依存で再現性が低いため、LLMには扱いづらい情報です。バグ情報や機能差分は、特定のバージョンや環境条件に依存していることが多く、またそれらは時間とともに修正・変化します。

LLMは実際にアプリを動かして観察できないため、現時点での挙動を検証できません。そのため、学習時に得た古い情報や、他のアプリの情報を組み合わせて「もっともらしい嘘」を生成してしまうのです。

人間であれば、「そのブラウザはレンダリングエンジンが違うから、機能Xを載せるのが難しかったのでは？」と因果的推論ができますが、LLMはそうした推論を行わず、単に似た事例を繋ぎ合わせているだけです。このため、機能が欠けている理由や背景を理解できず、虚構で埋め合わせるという現象が起きます。

「分からない」と答えるインセンティブが無い

LLMは設計上、「分からない」と答えることが少ない傾向があります。ユーザーが求めているのは「答え」であり、AIが何も返さなければ「役に立たない」と感じられるからです。そのため、LLMには「沈黙より誤答を選ぶ」ような傾向が内在しています。

また、学習データ中でも「分からない」と書かれた例は少ないため、統計的にも「何か答える」ほうが確率的に優位になります。
その結果、たとえ内部的に確信度が低くても、自信ありげに間違った情報を生成するという現象が起きるのです。

対策と今後の展望

この問題に対処するには、いくつかの現実的な方法があります。

まず、ユーザー側が出典を求めることが有効です。「根拠を挙げてください」「公式ドキュメントのリンクも示してください」と指示することで、LLMは生成ではなく検索ベース（RAG）のモードに切り替わりやすくなり、誤答の確率が減ります。

また、モデル設計側でも、「存在しない」情報の学習を強化する取り組みが行われています。たとえば、特定の製品やバージョンに関する「非対応機能一覧」などを人手で整理して与える、もしくはWeb検索と併用して動的に確認させる手法です。

将来的には、LLMに論理的推論モジュールや実行環境との連携機構を組み込むことで、「本当に動くか」を確認させる仕組みも導入されつつあります。これにより、単なる言語生成ではなく、現実に基づいた回答が可能になると期待されています。

まとめ

LLM AIが「標準的には存在するが特定のアプリには無い機能」について質問された際に嘘をついてしまうのは、単なる偶然や設計ミスではありません。それは、LLMが本質的に 「もっともらしさ」に基づいて動く統計モデル であり、

• 「無い」という情報がそもそも少なく学習されにくい
• バグや機能欠如は再現性が低く、文脈依存で扱いづらい
• 「分からない」と答えるインセンティブが無い
  という構造的な理由によって起こる現象です。

この性質を理解して使えば、LLMに「事実そのもの」を聞き出すのではなく、「事実を調べる手がかり」を出させるという発想に切り替えることができます。
つまり、LLMは百科事典ではなく統計的に文章を模倣する道具であると捉えることが、誤答と上手く付き合うための第一歩です。
今後、推論や実行環境との連携が進むことで、こうした問題は徐々に解消されるでしょうが、現時点ではLLMの特性を理解した上で使いこなすことが求められます。