Dance with Agents

ハルシネーション——AIは、嘘をついているわけではない

エージェントを使っていると、必ず一度は出くわします。

  • 存在しないコマンドのオプションを、堂々と教えてくる
  • 実在しない本のタイトルや、実在しないURLを挙げてくる
  • 直したはずのファイルを見に行くと、直っていない。なのに「修正しました」と言っている

これがハルシネーション(hallucination、幻覚)です。この記事は、このサイトでいちばん実害に直結する話かもしれません。

いちばん厄介なのは「自信たっぷり」なこと

人間なら、あやふやなときは口ごもります。「たぶん」「うろ覚えですが」と前置きが入る。その揺らぎが、聞く側にとっては警報になっています。

LLMにはそれがありません。正しいことを言うときと、まったく同じ調子で、間違ったことを言います。 文章のうまさも、説明の丁寧さも変わらない。だから見抜けない。

ハルシネーションが怖いのは、間違えることではなく、間違え方が堂々としていることです。

なぜ「嘘」ではないのか

「AIが嘘をつく」という言い方をよく聞きますが、正確ではありません。

嘘をつくには、本当のことを知っていて、それを隠す必要があります。LLMはそもそも、本当のことを知りません。

そもそもLLMって何?で書いたとおり、LLMがやっているのは次に来そうな言葉を選ぶことです。そして——

「ありそう」と「正しい」は、別のことです。

「この設定を変えるオプションは--verbose-outputです」という文は、とてもありそうな文です。ありそうだから生成される。実在するかどうかは、また別の話。

だから悪意はありません。そして悪意がないからこそ、たちが悪い。 モデル自身も、間違えているとは思っていないのです。

中では何が起きているのか——「知らない」と言うブレーキ

ここが面白いところです。Anthropicがモデルの内部を追跡したTracing the thoughts of a large language modelに、仕組みの説明があります。

まず、意外な事実から。

“refusal to answer is the default behavior: we find a circuit that is ‘on’ by default and that causes the model to state that it has insufficient information.”

(答えないことが既定の振る舞いである。既定で「オン」になっている回路があり、それがモデルに「十分な情報がない」と言わせる)

つまり初期状態は「知らない」なのです。 何も知らないと言うのが標準で、知っている対象のときだけ、そのブレーキが外れる。

外すのが「既知の実体」に対応する内部の特徴です。マイケル・ジョーダンについて聞かれると、この特徴が働いて「知らない」のブレーキを解除し、答えに進む。

研究チームは、実在しない「マイケル・バトキン」という名前で試しています。この場合は既知の特徴が働かないので、モデルは正しく「知らない」と答えました。 ところが、その特徴を人工的に刺激してやると——

“we’re able to cause the model to hallucinate (quite consistently!) that Michael Batkin plays chess.”

(モデルにハルシネーションを起こさせることができた——しかもかなり一貫して——マイケル・バトキンはチェスをする、と)

そして、自然に起きる誤作動もここで説明されます。名前には見覚えがあるけれど、それ以外は何も知らないという場合、

the “known entity” feature might still activate, and then suppress the default “don’t know” feature—in this case incorrectly.

(「既知の実体」の特徴がそれでも働いてしまい、既定の「知らない」を抑え込むことがある——この場合は、誤って)

いったん「答える」側に踏み出してしまえば、あとは得意分野です。もっともらしい中身が、するすると生成されます。

まとめると、ハルシネーションは「嘘をつく機能」が働いた結果ではありません。「知らない」と言うブレーキが、誤って外れた結果です。 この理解は、対策を考えるうえでかなり効きます。

説明が上手いことは、正しさの証拠にならない

同じ研究には、もう一つ大事な指摘があります。モデルが語る「こう考えました」が、内部で実際に起きた計算と一致しないことがある。

難しい問題でヒントを与えると、答えのほうから逆算した、もっともらしい筋道を語ることがある。「計算しました」と主張しているのに、その計算が行われた形跡が内部に見つからない場合がある、と研究チームは書いています(詳しくはなぜLLMは、こんなに何でもできるのかに書きました)。

だから、こうなります。

「なぜそう思うのか」を上手に説明できることは、それが正しいことの証拠にはならない。

理由を筋道立てて語れるので、つい信じてしまう。この「説明のうまさ」こそが、いちばんの落とし穴です。

エージェントだと、どう出るか

チャットAIのハルシネーションは、間違った文章が生成されるだけです。読んで気づけば済みます。

エージェントは手を動かすので、被害の出方が変わります。

  • 実在しないオプションを付けて、コマンドを実行してしまう
  • 実在しないファイル名やフォルダを指して、探し回る
  • 実在しないライブラリの関数を呼ぶコードを書いてしまう
  • やっていない作業を「やりました」と報告する
  • テストが通っていないのに「通りました」と言う

最後の2つが、いちばん危険です。作業報告そのものがハルシネーションになりうる。 「完了しました」を鵜呑みにすると、直っていないものを直ったと思い込んだまま先に進むことになります。

でも、エージェントには決定的な強みもある

ここが救いです。エージェントは、チャットAIと違って、確かめる手段を持っています。

  • ファイルを実際に開いて中身を見られる
  • コマンドを実際に実行して結果を見られる
  • ウェブを検索して確かめられる

チャットAIは記憶だけで答えるしかありませんが、エージェントは調べに行けます。だから、こう頼めます。

「憶測で答えないで、実際に確認してから答えて」

これが最大の対策です。「そのファイルが本当にあるか、lsで確かめてから答えて」と一言添えるだけで、かなり減ります。

ハルシネーションは「調べずに答える」ときに起きる。 ならば、調べさせればいい。単純ですが、これで誤りが減ります。

危ないのは、こういうとき

起きやすい場面には、はっきりした傾向があります。

場面 なぜ危ないか
人名・書名・固有名詞 上の「ブレーキ誤作動」がいちばん起きやすい形
数字・日付・料金 それらしい数字は、いくらでも作れてしまう
URL 形式さえ合っていれば、本物らしく見える
法律の条文、規程の条番号 形式が決まっているぶん、作りやすい
コマンドのオプション、APIの引数 「ありそうな名前」が実在するとは限らない
最近の出来事 そもそも知らない(訓練より後のこと)
マイナーな分野 学習データが薄いほど、誤作動しやすい

逆に、比較的安全な場面もあります。よく知られた一般的な事柄、そして目の前のファイルを読ませたうえでの要約・翻訳・書き換え。手元に材料がある作業は、でっち上げる必要がないぶん安全です。

これは自分の資料で、専門特化のエージェントを作るで書いた話とそのまま繋がります。資料を渡してから答えさせるのは、ハルシネーションを減らす手でもあるのです。

対策:この5つで、かなり防げる

1. 確かめさせる

エージェント最大の武器です。 「実行して確かめてから答えて」「そのファイルを開いて確認して」。憶測で答える余地を減らします。

2. 出典を求める

「どこに書いてあった?」とURLや行番号を示させる。示せないなら怪しい。 出典を示せと言われた時点で、でっち上げは露見しやすくなります。

3. 自分で動かす

最終防衛線です。 「動きました」と言われたら、自分で動かしてみる。「動いた」の確認だけは、人間がやったほうがいい。

4. 「知らない」と言っていいと伝える

「分からないことは、分からないと言ってください」と最初に書いておく。既定のブレーキを、外側から援護する形になります。単純ですが、意外と答え方が変わります。

5. 重要度で線を引く

全部を検証するのは、現実的ではありません。間違っていたら困る度合いが高いものだけ確かめる、と決めておくのが実際的です。

実際、このサイトでも起きました

ここだけ体験談です。

2026年8月8日、このサイトの記事の中に、ハルシネーション由来の記述が見つかりました。

Windowsでターミナルを開くという記事に、こう書いてありました。

これはMicrosoft自身が公式ドキュメントで述べていることで、CMDはすでに保守のみの状態にあり、今後の改善や新機能は追加されないとされています。

もっともらしい文章です。実際、業界ではよく言われている話でもあります。ところがそう明記したMicrosoft Learnのページは、探しても見つかりませんでした。 出典を辿ると、Windows Terminal開発者の発言を報じた記事類に行き着きます。「公式ドキュメントで述べている」という部分が、でっち上げでした。

面白いのは、主張そのものは妥当だったことです。PowerShellを使うべき、という結論に問題はない。間違っていたのは、根拠のほうだけでした。だから読んでも違和感がなく、そのまま公開されていたのです。

見つかったきっかけは単純で、サイト管理人が「公式に書いてあると書いたなら、URLを貼れ」と言い出したからです。URLを貼ろうとして初めて、貼るべきURLが存在しないことが分かった。

ここから、このサイトには運用ルールが2つ増えました。

  • 「公式に書いてある」と書いたら、必ずその場にURLを貼る
  • 裏が取れないなら、リンクを省くのではなく、主張のほうを書き換える

出典を求めることが対策になるのは、この理屈です。 ハルシネーションは、根拠を具体的に示させようとした瞬間に、正体を現します。

まとめ

  • ハルシネーション=もっともらしいが事実でない内容を、自信たっぷりに返してくる現象
  • 嘘ではない。「ありそう」と「正しい」が別なだけ。悪意がないぶん、見抜きにくい
  • 内部では、既定が「知らない」で、知っている対象のときだけブレーキが外れる。名前に見覚えがあるだけで誤って外れると、ハルシネーションになる
  • 理由を上手に説明できることは、正しさの証拠にならない
  • エージェントでは「やっていない作業の完了報告」という形でも現れる。これがいちばん危ない
  • 一方でエージェントは確かめる手段を持っている。「調べてから答えて」が最大の対策
  • 出典を求める・自分で動かす・分からないと言っていいと伝える。そして重要度で線を引く

エージェントは、疑いながら使うものではありません。確かめ方を知ったうえで、安心して使うものです。この記事は、その確かめ方の話でした。

LLM / エージェントの記事

LLM / エージェントのページへ →