AIは魔法ではなく確率である

堀田昂佑（NarAI 開発・執筆）・公開 2026-07-26

プロンプトの末尾に「わからないことは、わからないと答えてください」と書いたことのある人は、たぶん多い。私たちも書いたことがある。そして、その一文を入れたあとで、AIに堂々と間違ったことを言われた経験も、たぶんある。

奇妙なのは、指示が無視されているわけではない、ということだ。同じプロンプトの中の、口調の指定や出力形式の指定は、きちんと守られている。守られる指示と、守られない指示がある。だとするとこれは、指示の書き方が悪いという話ではない。指示で直せる種類の問題ではない、ということになる。では、何の問題なのか。

この問いの裏には、もう一つの期待が貼りついている。「今のモデルの不具合なのだから、次の世代では直っているだろう」という期待だ。この記事は、この二つ——プロンプトで直せるという期待と、次世代で直るという期待——を、確率の側から解いていく。

先に言葉の整理をしておく。AIが事実と異なることを述べる現象は、ハルシネーションと呼ばれる。ただ、この語は二つの違う現象に使われている。世の中の事実と食い違うことを言う場合（事実性の誤り）と、こちらが渡した資料に書いていないことを言う場合（忠実性の誤り）だ。業務での実害はむしろ後者が多いのだが、この記事で主に扱うのは前者——なぜAIは、知らないことを知らないと言わずに、もっともらしい誤りを作るのか——のほうである。

間違いは、どこで生まれているか

言語モデルの事前学習は、大量のテキストから「次に来る言葉の確率分布」を学ぶ工程だ。重要なのは、この工程に「事実を覚える」と「文らしさを覚える」の区別がないことである。モデルが学んでいるのは、どちらもただの分布だ。

ここを確率と統計の言葉で説明した先行研究がある。2025年9月に公開されたプレプリント「Why Language Models Hallucinate」（arXiv:2509.04664）。著者はOpenAIのKalaiとNachum、ジョージア工科大学のVempala、ハーバード大学のZhangの4名だ。査読前の論文であることは踏まえておく必要があるが、この現象の説明として、私たちはこれをいちばん見通しがいいと考えている。

論文の前半の主張はこうだ。文の生成という難しい問題の底には、「この文は事実として正しいか」を判定する二値分類の問題がある。そして、この分類を統計的に間違えざるをえない条件があるかぎり、生成の誤りは——訓練データが完全に正しくても——自然に発生する。条件の典型は、訓練データに一度しか現れない種類の事実だ。論文が例に挙げるのは人物の誕生日である。データ中に一度しか出てこない誕生日には、学びとれるパターンがない。パターンがない情報は統計的に「当てられない」ので、その出現割合が、そのまま誤り率の下限になる、と論じている。

逆に、パターンのある知識——文法、定型的な計算、繰り返し登場する事実——の誤りは、学習が進めば減っていく。モデルが世代を重ねて明らかに賢くなっているのに、特定の種類の間違いだけが残り続けるのは、この非対称のためだと説明できる。「次の世代では直る」という期待は、パターンで学べる誤りには当たっており、そうでない誤りには当たらない。

つまり、もっともらしい誤りは、学習の失敗や実装の不具合ではない。「次に来る言葉の分布」を忠実に学んだ結果として、分布のいちばん高い山が事実とずれることがある、というだけのことだ。

では、検索させて根拠を出させればいいのか

分布が当てにならないなら、根拠を外から与えればいい。そう考えた人は正しい。検索を接続して根拠文書を渡す（いわゆるRAG）、出典の提示を義務づける、同じ質問を複数回生成させて答えの一致を確認する。どれも実際に有効で、誤りは減る。私たちも全部使っている。

ただし、減るのであって、なくなるのではない。検索が正しい文書を取ってきても、モデルがそれを読み違えることはある。実在する出典に、そこに書かれていない内容を帰属させることもある。出典のURLは合っているのに、要約の最後の一文だけが原文のどこにもない、という形の誤りを、私たちは教材のレビューで何度か見つけている。根拠を「引く」工程も「まとめる」工程も、結局は同じ確率的な生成を通るからだ。

複数回生成して一致を見る方法にも、同じ底がある。多数決が選んでいるのは分布のいちばん高い山であって、事実ではない。山そのものが事実とずれていれば——前の章で見た、パターンのない事実がまさにそうだ——何回引き直しても、多数決は同じ誤りに収束する。

そして、本当の問題はその先にある。かりに誤りが10件に1件から100件に1件へ減ったとしよう。それでも、いま目の前にある出力がその「1件」かどうかは、出力を眺めてもわからない。検索も引用強制も、誤りの率を下げる仕組みであって、目の前の一件を判定する仕組みではないのだ。率の改善と、個別の判定。この二つの区別が、次の問いを開く。

正しさは、出力の側から見分けられるのか

期待したくなるのは、こういう未来だ。モデルが十分に賢くなれば、正しいときは根拠を添えて明瞭に答え、怪しいときは口ごもるようになる。人間の専門家がそうであるように、答えの確からしさが、答え方に表れるようになる。つまり、出力の様子から信頼度が読み取れるようになる。

この期待は、方向として間違っているわけではない。自信の度合いと実際の正答率を一致させる研究は続いていて、改善の報告もある。ただ、いま私たちの手元にある事実は逆だ。流暢さと正しさは、独立に動く。もっともらしい誤りは、正しい答えと同じ文体、同じ確信の調子で書かれて出てくる。そうなる理由は前の章で見たとおりで、誤りは分布から自然に生まれるのだから、生まれた誤りだけが「誤りらしい見た目」をしている理由は、どこにもない。

見分けられないなら、どうするか。この問いは、いったん開いたままにしておく。その前に確かめておきたいことが、もう一つあるからだ。そもそもなぜ、モデルは「わからない」と答える方向に育っていないのか。

採点が、当てずっぽうを損にしていない

先ほどの論文の後半が、ここを扱っている。

モデルの性能は、ベンチマークと呼ばれる共通の試験で測られる。新しいモデルが出るたびに各社の点数が表で並ぶ、あの試験だ。順位が広報にも採用にも効く以上、開発はその点数を上げる方向に進む。そして論文が指摘するのは、広く使われているベンチマークの大半が、正解に1点、誤答に0点、「わからない」にも0点、という採点を使っている、という事実である。注意してほしいのは、誤答が減点されるのではない、という点だ。誤答と棄権が、同じ0点。問題はそこにある。

この採点のもとでは、正解の見込みがわずかでもあるかぎり、当て推量の期待値は棄権を上回る。2割の見込みしかなくても、埋めれば期待値0.2点、空欄なら確実に0点だ。埋めるほうが、常に得になる。学生が試験の空欄をとりあえず埋めるのと同じ構造である。モデルはこの種の試験で高得点を出すよう最適化され続けるので、「わからないと言わず、もっともらしく埋める」傾向は、学習が進むほど強められていく。冒頭の一文の指示が効かなかった理由が、ここにある。プロンプトに書いた一文は、この最適化の圧力に対して、あまりに軽い。

論文はここから、採点の側を直す提案をしている。試験の指示文に信頼度の基準を明示し、その基準に応じて誤答に減点を科す、という方式だ。誤解のないように書いておくと、この「誤答への減点」は論文の提案であって、現状の記述ではない。現状の問題は、誤答が罰されていることではなく、棄権に加点がないことのほうである。

ここまでの説明は、私たちの発見ではない。この記事の見出しの命題も、この章の中核も、先行研究がすでに言っていることだ。なお、この説明に異論がないわけではない。ハルシネーションの原因をめぐる議論は現在も進行中で、対立する説明も提出されている。本稿では立ち入らず、必要になれば追記する。私たちが自分の言葉で足せるものがあるとすれば、ここから先——この構造を踏まえて、個人と組織は明日から何を組めばいいのか——だけである。

出力の外に、判定する側を置く

開いたままにしていた問いに戻る。正しさは、出力の側から見分けられるのか。

見分けられない、というのが答えになる。誤りは分布から自然に生まれ、正しい答えと同じ顔で出てくる。しかも学習の圧力は、「わからない」より推測を強める方向にかかっている。この二つが揃っている以上、出力の見た目に判定を頼る方法は、原理的に立たない。だから、設計はこう反転する。正しさの判定を、出力の内側で探すのをやめて、出力の外側に置く。

大げさな仕組みの話ではない。個人が明日からできる形で書く。

どれも地味だが、構造はすべて同じである。判定する側を、生成した側の外に置いている。

三つめの手順は、少し広げると組織でも使える。自分たちの業務から、答えのわかっている質問を十問ほど集めて、モデルやプロンプトを変えるたびに通す。それだけで、自家製の小さなベンチマークになる。組織のスケールでは、これが評価用の質問セットの整備や、エージェントの出力に対する回帰テストへ育っていく。規模が違うだけで、判定を生成の外に置くという原則は変わらない。そして冒頭の一文との違いは、ここにある。「わからないと言って」はモデルへの頼み事だが、手元の質問セットは、モデルが何を言おうと動じない採点表だ。

誰が採点するのか

判定を外に置く、と言ったとき、最後に一つ誘惑が残る。モデル自身に確認させればいいのではないか。「いまの答えは正しいですか」と聞き直す。あるいは、検証役のエージェントをもう一体立てる。

聞き直しで拾える誤りは、実際にある。計算の見直しや、文書との突き合わせは、二度目のほうが精度が出ることも多い。ただ、それを唯一の判定にはできない。同じモデルに聞き直すことは、同じ分布からもう一度引くことだからだ。生成する側と判定する側が同じ癖を共有していれば、共有された癖は、検証を二重にすり抜ける。別のモデルを検証役に立てれば癖の重なりは減るが、それでも最後に残る問いは消えない。その検証役の合否の基準は、誰が書いたのか。基準を書く手が生成の側にあるかぎり、採点者と受験者は、まだ同じ側にいる。

だから、運用の原則はこうなる。判定の仕組みは、判定される側が書き換えられない場所に置く。エージェントに仕事を任せるなら、何を実行してよいか、どの出力を確定として扱ってよいかの境界を、エージェントの外側で定義し、エージェント自身には変更させない。これは新しい概念ではない。permission boundary（権限境界）やguardrailといった名前で、ソフトウェアの運用に以前からある考え方だ。エージェントの時代に付け加わった事情があるとすれば、境界を越えようとするのが外部の攻撃者だけでなく、境界の内側で働いている本人にもなりうる、という点だけである。

そして、閉じる前に外しておきたいものがある。この記事は途中から、試験と採点の言葉で書いてきた。この比喩は、ここで外す。モデルは、合格を目指す受験者ではない。「当て推量が得になる」と書いてきたが、得を狙って選ぶ主体は、どこにもいない。採点表が示しているのは、学習の過程でどの出力傾向が強められるかであって、モデルの動機ではない。この比喩を持ったまま運用に入ると、「反省を促せば直る」「誠実さを求めれば直る」という、主体の存在を前提にした対処へ戻ってしまう。比喩を外したあとに残るのは、判定を外側に置くという設計だけだ。そして、それで足りる。

冒頭のプロンプトに戻る

「わからないことは、わからないと答えてください」。この一文を書いた判断そのものは、間違っていなかったと思う。出力を疑い、何か手を打とうとした。その方向は正しい。問題は、手を打つ場所だけだった。あの一文は、判定をモデルの内側に頼む言葉だ。頼む先が、内側にはなかった。

一文の指示の代わりに用意すべきだったのは、出力の後ろに置く検証の手順のほうだ。出典を開く。二度聞く。答えを知っている質問を混ぜる。確定の前にゲートを挟む。プロンプトの書き方を磨く技術より手前に、判定の置き場所を設計するという考え方がある。順序としては、こちらが基礎だ。

前回の記事で、エージェント本体は使い捨てでよく、育てるのは指示書や権限の境界といった環境の側だ、と書いた。今回の話は、その環境の中身を一つ具体的に指している。評価の基準と検証の手順は、エージェントが読み込む環境のうち、エージェント自身に書き換えさせない部分として育てていく資産である。

NarAIは、この基礎——AIエージェントに何を任せ、何を外側の仕組みに持たせ、何を人間の手に残すか——を、正しいメンタルモデルの側から学ぶための場所として作った。ブラウザ上のシミュレーション環境で、エージェントの計画・実行・承認の流れを実際に動かしながら、今日書いたような設計の考え方を順に組み立てていく。

関連する無料レッスン

全体像はClaudeの使い方 — 「聞く」と「任せる」を分けて覚えるにまとめています。

ほかの記事