AIは"嘘をつく"から世間に広まった――？

ChatGPTやClaude、Geminiといった大規模言語モデル（LLM）が業務に浸透するなか、もっとも頭を悩ませる問題のひとつが「ハルシネーション」だ。日本語では「幻覚」「もっともらしい嘘」と訳され、しばしばAIの“バグ”のように語られる。だが、本当にバグなのだろうか――。

今回はChatGPT登場以前から自然言語処理・情報検索を専門とし、現在は国立情報学研究所（NII）の大規模言語モデル研究開発センターで日本語LLMの構築にも携わる、NIIの相澤彰子教授に話を伺った。ハルシネーションの本質、研究者が分ける4つの類型、現場で語られる抑制プロンプトの本当の効き目、RAGの限界、そして「AIを信頼するために人間が持つべき"見積もり力"」まで。エンジニアやAIを業務で使う人にとって、生成AIとの距離感を測り直す手がかりになれば幸いだ。

 

自然言語処理の研究者が、LLMを“自分たちで作る”理由

――まずは先生のご専門について伺えますでしょうか。自然言語処理がご専門と伺っていますが、いまのChatGPTのようなLLM、そして本題のハルシネーションとは、どのように関わっておられるのでしょうか。

相澤：もともと自然言語処理は、研究テーマとしてみなさんに分かっていただくのが本当に難しい分野で、困った時には「たとえば機械翻訳です」と言ったりもしていたんです。でもChatGPTが現れてからは、「ChatGPTのような研究をしています」と言えば大体分かったつもりになっていただけるので、すごく楽になりました。

コンピューターに人間の言語を分からせるにはどうすればいいか――これを、計算機が登場した1950年代から面々と考え続けてきたのが、自然言語処理のコミュニティです。私もその延長線上で、計算機で人間の言語をうまく扱っていくにはどうすればいいか、という研究をしています。

――現在は、2つの活動を並行しておられると伺いました。

相澤：はい。一つは国立情報学研究所にある私のラボで、学生と一緒にやっていることが中心で、こちらは「評価」が多いかもしれません。もう一つは、国立情報学研究所（NII）にある大規模言語モデル研究開発センターでの活動で、こちらは実際に大規模言語モデル、つまりChatGPTのようなものを自分たちで作るということに、2024年から取り組んでいます。論文を書くよりも、「ものを作る」という観点のプロジェクトですね。

ChatGPTのような言語モデルは海外から降ってきたわけですが、自分たちで作るということをしていないと、中身が分からないし、技術も獲得できないし、研究もできない。そして次の世代の研究者も育たない。商用モデルは本当に中身が分からないので、開かれたオープンな形で、中身が分かる、誰でも参照できる透明性の高いモデルを作ろう――というのが、我々の活動です。

 

そもそも、なぜLLMは「もっともらしい嘘」をつくのか

――作る側と評価する側、両方の視座から見ておられる先生だからこそ、伺いたい根本の問いがあります。そもそも、なぜLLMはハルシネーションを起こすのでしょうか。

相澤：「LLMはなぜ嘘をつくのか」が論文のタイトルになるほど、研究者の興味を引いてきた問題ですが、根は深いんです。LLMの仕組みそのものが、もともと「正しい出力」を出すように設計されてはいなくて、「流暢でそれらしい答え」を出すように設計されているからです。

LLMは、これまでに見てきた膨大な文書から「次に来そうな単語（トークン）」の確率分布を計算し、その分布に従って一つトークンを選び、また次のトークンを選ぶ、ということを繰り返しています。基本動作のなかに「正しさの判定」は入っていません。何十億・何千億ものパラメータが注ぎ込まれていますが、原理的に最大化しているのは「もっともらしさ」だけなんです。

ですから、ハルシネーションは「振る舞いとしてもともと組み込まれているもの」と考えるのが妥当です。

 

「事実誤り」だけじゃない――研究者が分ける4つのハルシネーション

――ひと口にハルシネーションと言っても、いろいろなタイプがありそうです。研究の世界ではどう整理されているのでしょうか。

相澤：ChatGPT登場のかなり初期から注目されていたテーマで、分類やサーベイ論文も多数出ています。例えば大きく四つに分けると、まず①事実誤認型（factuality）。世界知識や外部事実と照らして正しいかどうか、いわゆる事実性に関わる問題です。

②根拠不一致型（faithfulness）。AIに与えた参照文書や外部根拠の内容と、出力が食い違ってしまう問題。③文脈不忠実型（fidelity）。ユーザーの意図、入力条件、タスク仕様といった指示に対して忠実かどうか。

そして④推論誤謬型（fallacy／fallacious reasoning）。根拠から結論への推論が妥当かどうかという問題で、論理学や認知心理学、社会心理学、哲学の分野で古くから研究されていて、数十種類から100種類以上の分類があるとも言われます。

ひと口にハルシネーションと言っても、タイプが異なるというのは重要なポイントです。

※ハルシネーションの主な4類型：①事実誤認型（factuality）＝世界知識・外部事実として正しいか／②根拠不一致型（faithfulness）＝外部根拠・参照文書への忠実性／③文脈不忠実型（fidelity）＝入力条件・ユーザー意図・タスク仕様に従っているか／④推論誤謬型（fallacy reasoning）＝根拠から結論への推論が妥当か

 

――「Aさんの担当はBさん」と覚えたAIが、逆に「Bさんの担当は？」と聞かれると答えられない、というのもよく知られていますね。

相澤：はい、それは「推論誤謬型」にあたります。我々が日々触れているニュースや報道、SNSの情報を眺めても、こうした誤謬はいたるところにあって、人間自身もよくやってしまう。そういう人間のコンテンツを学習しているLLMが間違えるのは、ある意味しょうがない部分もあります。

ただ、最新のフロンティアモデルで試してみると、本当に驚くほど分かっている。「人間より賢いんじゃないか」と思う場面も少なくないです。ゼロにはならないにしても、いったん推論誤りを犯しても「見直してください」と言えば気づく、というレベルまで来ています。

 

「ハルシネーションしないで」と書くだけで、本当に効くのか

――現場ではプロンプトに「ハルシネーションしないでください」「根拠も示してください」と書きます。あれは本当に効果があるのでしょうか。

相澤：効果はあります。タスク依存ではありますが、何もしないよりは確実に効きます。「根拠とともに示してください」「ソースが見つからない場合は『なし』と答えてください」「もう一度見直してください」といった具体的な指示を重ねるほど、出力はそちらに引っ張られていきます。

一般論で言えば、漠然と「ハルシネーションしないで」と書くより、「根拠となるソースを必ず提示してください。根拠が見つからない場合は『根拠なし』と回答してください」と詳細化したほうが、回答を受け取る側でも判断がしやすくなります。

 

――裏返せば、LLMはデフォルトでは「知らなくてもそれっぽく答える」ようになっている、ということですよね。なぜサービス側は最初からそうしてくれないのでしょうか。

相澤：かなりの部分、LLMを構築し、訓練し、評価する側の設計に根ざした問題だと思います。たとえばOpenAIが2025年9月に出した「Why Language Models Hallucinate」というペーパーでは、通常の標準的な訓練や評価では「分からない」と言うよりも、推測して当てにいくほうが点数上有利になりやすい、つまり訓練段階でLLMはそのように動機づけられてしまう、という説明がされています。

評価データセットは採点しやすい形、多肢選択問題などの形になっています。その際に「分からない」という選択肢を含んでいなかったことも大きい。最近、それがハルシネーションの原因として無視できないと分かってきたので、「分からない」を含む形に少しずつ変わってきていますが、そうしたベンチマーク設計のバイアスも一因です。

 

「最新の賢いモデル」＝「安全」ではない――量がハルシネーションを呼ぶ

――多くの人は「最新の、一番賢いモデルを使えば間違いない」と考えがちです。性能が高いほどハルシネーションは少ない、と単純に言えるのでしょうか。

相澤：「最新の、一番賢いモデルを使う」気持ちは、私自身もよく分かります。ただ「良いサービス＝間違えない」ではない点には注意が必要です。

モデルが賢くなるほど、文章は自然になり、もっともらしく説明する力も高くなる。その結果、間違いが含まれていても人間が気づきにくい場面が出てきます。「賢いモデルを使えば安全」という単純な話ではない、ということです。

さらに、私が最近特に問題だと感じているのは、モデルが賢いほど、人間が読み解ける量を超えた大量の応答を返してくるケース。その内容を確認するためにさらにLLMの支援が必要になり、結果として人間は要約だけを見る、という状況も出てきます。出力量の多さや検証負荷の高さも、ハルシネーションを見落としやすくする要因として、真剣に考えるべきだと思います。

 

――「コーディングが強い」「数学が強い」「軽量で速い」など、モデルの個性も増えています。これからは自分のタスクに合ったモデルを選ぶことが重要になりそうですね。

相澤：そう思います。私も参加しているNTCIR-19という情報アクセス技術の評価基盤カンファレンスのなかにも、「ModelRetrieval」というパイロットタスクがあって、簡単に言えば「自分の目的に合ったAIモデルを探すこと」自体を研究対象にする取り組みです。

モデルの選択自体が「検索問題」になる、という見方はまだ身近ではないですが、コストを考えれば、オールマイティで賢くて重いモデルである必要はなくて、もっと小型で済めばそれに越したことはない。エンジニアにとっても、自分の作業に合ったモデルを探して選ぶ、という意識はますます大事になっていくはずです。

 

AIの「推論過程」を信じすぎるな――エージェント時代の検証作法

――モデル選びと並んで気になるのが、AI自身の"考え方"の中身です。先生は共同論文で「複数の手順を踏む複雑な質問では、最終的な答えが正しくても、途中の推論過程まで正しいとは限らない」という研究結果を発表されていますが、進化の速い最新の推論モデルでも、同じことは起きるのでしょうか。

相澤：はい、十分に起きうると思います。LLMやAIエージェントが扱うタスクの複雑さ、自律的に推論できる分量は急速に伸びています。このような状況では、モデルの推論過程を人間が1つ1つたどることは困難です。

さらに注意すべきは、モデルが出力する推論過程は、あくまで言語による説明であって、実際にモデルの内部で起きている計算過程や状態の変化を忠実に反映しているとは限らないということ。結論を先に出して、後付けでもっともらしい説明を出力している可能性も十分にあります。

「正解をしているように見えること」と「正解を裏付ける正しい推論過程を示すこと」は、分けて考える必要があります。

 

――実装の世界でも、ChatGPTやClaudeにコードを書かせたら、説明は通っているのに動くコードが返ってこない、ということが起きます。エンジニアはどう見抜けばいいでしょうか。

相澤：その勘どころこそが、エンジニアに求められるスキルだと思います。実践的には、まず「問題を分割する能力」、そして「検証する能力」でしょうか。

LLMに一括で長大なコードを生成させると、簡単に人間の認知能力のキャパシティを超えてしまう。適切な単位に分割しながら、1つ1つ検証する。あるいは、まず最小限に動くコードを作り、次に例外処理などの機能を追加していく、など、人間が理解できる単位に分割して進めることが重要です。

コードが動くことと、その説明が正しいことは別。さらに、主要なケースで動くことと、実運用で安全に動くことも別です。LLMを使うエンジニアにとって重要なのは、AIに全部を任せることではなく、AIの出力を検証できる小さな単位に分けて扱うことだと思います。

 

RAGも万能ではない――対策側に残る3つの落とし穴

――出力を細かく検証する話とも関連しますが、ハルシネーション対策として、外部資料を検索させて答えさせる「RAG（検索拡張生成）」が最も有力とよく言われます。「RAGを入れたから安心」と考えていい段階に来ているのでしょうか。

相澤：そこには釘を刺しておきたくて、いくつか技術的な課題があります。

まず①RAGの背後では検索システムが動いていますが、検索エンジンで検索しても、古い情報や間違った情報は出てきます。LLM側が適切なキーワードを出せず、情報を取ってこれなくても失敗します。

次に②必要な文書を見つけられても、その中の目当ての情報が容易に使えるとは限りません。長い文書のなかに重要な情報が埋もれていたり、検索で取り出された断片からは必要な文脈が失われたりしていることもあります。RAGは見つけた情報をプロンプトに追加してモデルに読ませるため、その情報が長すぎたり、断片すぎたりすると、モデルが正しく読み取れない場合があります。

そして③最後にハルシネーション。回答を生成する段階でも誤りが起きる可能性は残ります。これらが積み重なってRAGシステムが動かない、ということは十分にあり得ます。

 

――会計システムやSaaSのように、正確性が厳しく問われる領域では、RAGを入れても1%程度のミスは起こり得ますよね。「ほぼ正しいが時々間違える」システムを、業務でどこまで信頼してよいのでしょうか。

相澤：その場合は、LLMに会計処理そのものを任せるというより、会計システムやSaaSに対する「言語インタフェース」として使う、と考えるのが現実的だと思います。

自然言語による人間のリクエストを、システムのコマンドに翻訳するトランスレーターですね。たとえば「もう少し大きめに見積もって」という曖昧な指示を、実際には「5〜10%の範囲で増額する」といった数値条件に変換する、というイメージです。ユーザーが自然言語で言うことはとても曖昧なので、翻訳に曖昧性や誤りが起きるのは、どうしても避けられない部分があります。

このような状況で重要なのは「システムコマンドのレベルで理解して、正しさを検証できること」だと思います。LLMが生成した操作内容を、検証可能な形式に落とし込み、重要な操作では実行前に確認できる設計にすること。たとえば「シニアな年代層」のような自然言語をSQLのクエリに変換してくれるのは便利ですが、その「シニア」が実際にどの年齢を指したのか、変換後の入力コマンドをしっかり確認できるスキルが大切だと思います。

――実装パターンの話で言えば、エンジニアの間でも「ふつうにチャットUIで使う／開発支援ツールに任せる／API経由で組み込む」と選択肢が分かれます。研究の現場では、どれを選んでおられますか。

相澤：ビジネスでの使い方は日々進化していて私は追いついていないような気がしますが、研究では間違いなくAPIです。

理由は、まず再現性の問題。そして、もう一つ大事なのは、自分が「何をしているのか」がわかること。普通にプロンプトに投げると、向こうが何をしているのかよく分からないんです。

API経由でやっていれば、少なくとも「どういうものを投げたか」をこちら側で把握できる。検証できる、追跡できる、というところがとても重要だと思っています。

――RAGで「出典付き」で答えさせても、モデルが出典をきちんと読まずに、自分の記憶で答えてから後づけで出典を貼っているケースもあるのでしょうか。

相澤：RAGの設計にもよりますが、おそらくあるのではないでしょうか。「出典付きだから安心」と受け取るのは危険です。

たとえばRAGの設計のなかには、いったん自分で回答を作成してから、それを検索クエリとして類似の文書を探しに行く方法もあります。その場合、まずLLMの知識を頼りにどんな答えが欲しいかを決めてから情報を探しに行くので、探索範囲は狭くなり、バイアスやハルシネーションも起こりやすくなると考えられます。

 

「豊かさとハルシネーションは、表裏一体」――"嘘"を消したLLMは、おそらく使いにくい

――ここまで、4類型、抑制プロンプト、モデル選び、推論の検証、そしてRAG――いずれもハルシネーションを“いかに減らすか”という方向のお話を伺ってきました。改めて根本的な問いとして、研究者の立場から見ると、ハルシネーションはやはり“なくすべきもの”なのでしょうか。

相澤：まず大前提として、ハルシネーションそのものは絶対にやってはいけないこと、というものではないんです。言語モデルにとっては、相談相手になってほしい、アイデアの壁打ちをしてほしい、といったさまざまなユーザーのリクエストがあるなかで、ハルシネーションが一切起きないシステムは、多分とても使いにくい。

アイデアを出したいときには、嘘でもいいからいろんな可能性を示してほしい、ということもありますよね。そういう意味では、LLMの“豊かさ”とハルシネーションは、ちょっと表裏一体のところがあると考えています。

ですからハルシネーション自体を「ミス」「誤り」と捉えるよりも、誤りが許されない場面でいかにそれらしく振る舞えるか、という問題として考えたほうがいいのかなと思います。

 

――ハルシネーションをゼロにしようとすると、LLMの良いところまで削ってしまう、ということですか。

相澤：そうですね。LLM本来の魅力である柔軟なレスポンスや、そういったものが失われてしまう可能性もあると。もともとLLMはハルシネーションを起こさないことを目的として設計されていないので、「ハルシネーションはダメ」と言われると、それはそれなりの仕掛けが必要になります。

“悪者”として一刀両断にするのではなく、振る舞いとしてもともとそういうものだという前提に立ったうえで、誤りが許されない場面に向けて仕掛けを足していく、という発想のほうが現実に合うと思います。

 

AIを信頼する条件――「気づける力」こそが専門家の専門家たるところ

――AIが進化してもハルシネーションがゼロにならないとすれば、人間側はどう向き合えばいいのでしょうか。

相澤：AIをどう活かすかというプロジェクトに関わって「なるほど」と思ったことが3つあります。

1つめは、AI側が、自分の自信のなさ、必ずしも確信を持って答えているわけではないこと、曖昧な部分を、ちゃんとそうだと見せること。そうすると人間側も判断の手掛かりにできます。

2つめは、人間の側が、AIの性能とは独立の次元で「このAIはこのくらい間違えるだろう」という、なるべく正確な見積もりを持っていること。AIが本当は正解しているのに「このAIはいまいち」と思い込んでいると、せっかく正解したものを捨ててしまう。逆に過信していると、AIが間違っているのにそのまま受け入れてしまう。

3つめが、AIがたまたま誤ってしまった場面で、人間がそれに気づくことができるかどうか。これが、これからの専門家の専門家たるところなのかなと思っています。

 

――その「気づける力」が、もっとも切実に問われるのが医療のような高度な専門領域だと思います。先生は医療領域のLLM研究にも携わっておられますが、現場ではどのようなことが起きているのでしょうか。

相澤：医療ドメインのLLMも少しやっていますが、専門医とそうでない医師では知識量がすごく違って、AIは「もう専門医を超えている」と多くの人が見ている水準にあります。

そこでAIが間違えたときにどちらが気づくかというと、専門医の先生だけが気づく。専門医でない人は、AIのほうが偉いと思っているから信じてしまう、という結果も見たことがあります。やはり、気づくことができることが重要なんだと改めて感じます。

――最後に、現役のエンジニアやAIを業務で使っている読者にメッセージをお願いします。

相澤：ハルシネーションはゼロにはなりません。「そういうものだ」という想定で、ほどよくAIを信頼して使い、AIの出力に自分が責任を持てるかを常に問い続けることが重要だと思います。

間違いに気づくことができることがイコール・プロフェッショナルだ、というふうになりつつあります。AIが出してきたものが正しいか正しくないか、自分はどうやって責任を持つのか――その問いに、ちゃんとイエスとかノーとか言えるようになることが、これからの教育の目的かもしれない、と考えています。

 

「ハルシネーションで世界は滅ばなかった」――それでも研究者が共有する"危機感"

――少し視点を変えて伺います。先生ご自身は、AIをどれくらい信用されていますか。

相澤：結構、AIを信用していますね。能力的にかなり。かなり使っている方だと思います。GPT-5が出てきたあたりから本格的に使い始めたんですけど、これは賢いなと感じています。

AIのおかげで、研究者同士の距離が再び近くなった感覚もあって。これまではどんどん専門が細分化していく一方だったのが、AIに聞けば他分野の話も翻訳してくれる。まったく分からなかった世界の話でも、こちらに分かる言葉に直してもらえるんです。

――それでも、研究コミュニティ全体としては、別の空気感も流れていると伺いました。

相澤：意外と、AIの研究者は、みんなかなりの危機感を持っていて、集まるとその手の話をしますね。

――どんな種類の危機感ですか？

相澤：……「人類滅びるかも」、ですね。

――そこまで極端な見方をされる方もいるんですか。

相澤：「本当にまずいことが起きるんじゃないか」という危機感を持っている人が、相当数いると思います。我々の仕事はいわば、AIを改善するための弱点をみつけることですから、それだけに、AIがどれだけ賢いかは切々と感じるんですよ。「本当にこれができるんだったら、もうここまで行くよね」と。

むしろ「AIって何？」みたいな感じで考えている社会のほうが、なんというか、のんびりしていて健全なのかもしれない、と思うこともあります。

――論文の世界でもすでに、AIが執筆した論文が混じり込むことが問題視されています。

相澤：科学も危ないんです。論文はAIが執筆できますので、論文そのものの信頼性をいかに保っていくかはとても重要なのですが、逆説的ともいえることに、そのためにもAIの技術が必要で。

ツールとしてAIが論文をレビューする、信頼性をチェックする――文章もそうです。人間ではとてもカバーしきれない。これも同じ問題を抱えていると思います。

ハルシネーションという事象が広く認知されたときに、AIの致命的な欠点だと思われたけれど、案外、世界はすぐには滅ばなかったから、もしかしたら何とかなるのかもしれないですけど――。

 

取材を終えて

「ハルシネーションで世界は滅ばなかったから、もしかしたら何とかなるのかもしれない」――取材の終盤、相澤教授がふと漏らした一言が印象に残りました。ハルシネーションは“バグ”ではなく、LLMが柔軟な知性として振る舞うための“仕様”そのもの――。今回の取材を通じて見えてきたのは、生成AIに対する対立軸の、静かな組み替えでした。撲滅すべき敵ではなく、性質を理解したうえで付き合う相手です。そして付き合うために必要なのは、AIの能力を性能とは独立に見積もる感覚と、誤りに気づける専門性、つまり「気づける力」だといえるでしょう。

冒頭に立てた「本当にバグなのだろうか」という問いに、相澤教授の答えは明確でした。“豊かさとハルシネーションは表裏一体”――この一言を腹落ちさせた瞬間から、エンジニアの仕事の重心は、コードを書く速さや量ではなく、AIの出力に対してイエスかノーかを言い切れるかどうかへと、静かに移り始めます。「正しさの測り方」を持っているか――。生成AIが業務の前提になる時代、その問いは、すべての作り手に投げかけられています。