目次
- この記事の立ち位置
- ハルシネーションとは何か
- 3層で考える：検知・抑制・運用
- 検知層：誤りに気づく仕組み
- 検査そのものが壊れている場合
- 確率は較正されているか
- 基準率と比べないと評価できない
- 抑制層：誤りを減らす
- 事例：AI検索に自社がどう見えているか
- 評価データそのものを疑う
- 運用層：誤りが通っても被害を出さない
- 導入時に決めておく5つのこと
- 出典が付いていても、出典を確かめないと検証にならない
- まとめ
この記事の立ち位置
ハルシネーションの解説記事は多い。定義と発生原因、そして「プロンプトを工夫する」「RAGを使う」といった対策の一覧は、すでに広く共有されている。
本記事はそこから一段進めて、対策を入れたあとに何が起きるかを扱う。編集部は自社で判定層を運用しており、その過程で「対策を入れたのに効いていない」「検査が機能しているつもりで機能していない」という状況に繰り返し当たった。
本文中の数値は2026年9月20日時点の自社実測である。対策のカタログではなく、対策が効いているかを確かめる方法に分量を割く。
多くの記事が「こうすれば減る」を並べるのに対し、本記事は「減ったと言えるか」を扱う。減ったかどうかを判定する仕組みを持たないまま対策を重ねると、効いている対策と効いていない対策が区別できないまま運用が複雑になっていく。編集部はこの状態を一度作ってしまい、検査の側を作り直すことで抜け出した。その経緯を書く。
ハルシネーションとは何か
生成AIが、事実と異なる内容をもっともらしい形で出力する現象を指す。存在しない論文を引用する、実在しない機能を説明する、数値を実際と違う値で述べる、といった形で現れる。
なぜ起きるのか
言語モデルは、次に来る語として確からしいものを選んでいく仕組みで動いている。「正しい答えを探す」のではなく「自然な続きを作る」ため、知識が欠けている領域でも自然な文章が生成される。
したがって、出力の自然さと内容の正しさは独立している。読みやすい文章ほど正しいという関係は成り立たない。
実務上やっかいな性質
3つある。
1つ目は、誤りが部分的に混ざることである。全体の8割が正確で、2割に誤りが混ざる形が多い。全部が誤っていれば気づけるが、部分的だと見落とす。
2つ目は、誤りに確信の揺らぎが見えないことである。人間なら曖昧な部分は言い淀むが、モデルの出力は正しい部分と誤った部分が同じ調子で書かれる。
3つ目は、出典が付くと権威づけられることである。後述するが、検索で文書を取得して回答する仕組みを入れると、的外れな文書に沿った誤りが「出典つき」で出てくる。
3層で考える：検知・抑制・運用
対策を「ハルシネーションを減らす方法」として一列に並べると、優先順位が付けられない。編集部では3つの層に分けている。
検知層 — 誤りが起きたことに気づく仕組み。ここが無いと、他の層が効いているかも分からない。 抑制層 — 誤りの発生率を下げる仕組み。プロンプト設計、参照文書の付与、モデルの選択。 運用層 — 誤りが通り抜けても被害を出さない設計。人の確認、影響範囲の限定、記録。
順序が重要である。検知層を先に作らないと、抑制層の効果が測れない。編集部の経験では、検知を後回しにして抑制から入ると、「何となく良くなった気がする」で止まる。
検知層：誤りに気づく仕組み
出力を人が読む以外の方法
すべての出力を人が読むのは現実的でない。編集部で使っている検知の手段を挙げる。
引用元との照合。 出力に含まれる固有名詞や数値が、参照した文書に実際に存在するかを機械で確かめる。存在しなければ、モデルが補完した可能性が高い。
編集部が都道府県ごとの公的制度を調べた際は、この方式で9件の誤りを事前に弾いた。検証したのは、出典のURLが実際に応答を返すか、その本文に制度名が含まれるか、公的なドメインか、そして順位の主張が混ざっていないか、の4点である。
形式の検査。 出力が満たすべき形式を定めて機械で確かめる。日付の形式、数値の範囲、必須項目の有無といったものである。内容の正しさは見られないが、明らかな崩れは捕まる。
複数回の出力を比べる。 同じ問いを複数回投げて、答えがぶれる箇所を洗い出す。ぶれる箇所は、モデルが確信を持っていない領域である可能性が高い。
検知の限界を把握する
どの手段にも見えない範囲がある。編集部の運用で重要にしているのは、何が見えていないかを書き出しておくことである。
引用元との照合は、引用元そのものが誤っている場合には効かない。形式の検査は、形式が正しい誤りには効かない。複数回の比較は、モデルが一貫して同じ誤りを出す場合には効かない。
見えない範囲を書き出しておくと、後から「この対策では捕まらない類の誤りだった」と切り分けられる。
書き出す形式は簡単でよい。検査の名前、何を見ているか、何を見ていないか、の3列で足りる。編集部では検査スクリプトの冒頭にこの3つをコメントとして書いており、後から読む人が「この検査を通ったから安全」と読み違えるのを防いでいる。
実務では、検査を増やすほど安心感が増す一方で、何を見ていないかは曖昧になっていく。検査の数ではなく、覆えている範囲で語れるようにしておきたい。
検査そのものが壊れている場合
ここが本記事で最も伝えたい部分である。
検知の仕組みを作ると、そこから先は検査結果を信じて運用することになる。しかし検査が対象に届いていない場合、欠陥があってもなくても同じ「問題なし」が返る。
実際に起きたこと
編集部が2026年9月20日の1日で踏んだものを挙げる。いずれも検査は正常終了し、エラーを出していない。
対象が空だった。 ページの重複を検出する検査を、存在しないディレクトリに向けて実行した。検査は「0群 / 0ページ / 問題なし」と表示して終了コード0を返した。検査するものが無かっただけである。
観測の窓が短かった。 計測タグが発火しているかをブラウザで確認する際、2.5秒で判定していた。3サイトが「発火していない」と出たが、9秒に広げると3サイトとも正常だった。
検査が走っていなかった。 ある自社サイトで解析が一度も発火していないことが分かったが、それを確認する自動テストは以前から存在していた。実行されていなかっただけである。
一覧が途中で切れていた。 管理対象を一覧で取得して10件と数えたが、実際は26件あった。既定のページサイズで打ち切られていた。
検査用データ側に欠陥があった。 配信文にHTMLが混入していないかを検査したところ94件が該当した。原因は、検査用に取得したデータを文字数で切り詰めた際、HTMLタグの途中で切れていたことだった。全文で測り直すと0件だった。
見分ける方法
空振りを失敗として扱う。 検査対象が0件のとき、合格ではなく失敗にする。編集部では検査スクリプトにこの判定を組み込んだ。存在しないパスを渡すと、合格ではなくエラーで止まるようになった。
壊れた対象を対照に使う。 新しい検査を書いたら、欠陥のある対象に当てて落ちることを確かめる。編集部では、過去に配信した壊れたバージョンが記録として残っていたため、それを対照にした。新しい検査を当てると4件が失敗し、正常版では15件すべてが成功した。区別できていることが確認できた。
正常値を先に知る。 ある数値が異常かどうかは、正常値を知らなければ判断できない。解析タグの例では、データ層に積まれる要素が2件なら外部スクリプトが読めていない状態、4件から5件が正常だった。
確率は較正されているか
判定を自動化する際、モデルが出す確信度を使って「確信が高いものは自動処理、低いものは人に回す」という設計をしたくなる。
この設計が成り立つのは、確率が較正されている場合に限られる。較正とは、確率0.9と出力したもののうち実際に9割が正しい、という対応が成り立っている状態を指す。
較正されていない場合に起きること
編集部が運用する判定層では、確率が較正されていないことを前提にしている。実測でその根拠が出ている。
判定の境目を0.5から0.9に上げたところ、指した割合は0.973から0.838に落ちた。ここまでは想定どおりである。しかし指したときの的中率は0.681から0.645に下がった。確信が高いものだけを残したのに、精度が落ちている。
これは確率の順位が正誤を分けていないことを意味する。この状態では、境目をどこに置いても得るものが無い。
では何が効いたか
同じ判定層で、問いの文面を変えたときは上位1件の的中率が0.473から0.595に上がった。抽象的な言い方ではなく、観測に出てくる具体名を並べる形にしたときである。
効くのは閾値ではなく文面だった。 編集部ではこの経験から、判定の精度を上げたいときは、まず問いの書き方を疑うようにしている。
較正の確かめ方
確率の帯ごとに実際の正解率を出して並べる。0.9から1.0の帯で実際に9割が正しいか、0.5から0.6の帯で5割強が正しいか。ずれていれば較正されていない。
なお、登録した設定が実際に適用されているかも別に確かめる必要がある。編集部では、較正の設定が停止済みのモデル名で登録されており、判定層が黙って未較正の値を使っていた、という事例があった。設定を登録したことと、それが効いていることは別の量である。
基準率と比べないと評価できない
検知の成績を数字で出すとき、分母と基準率を書かないと意味を持たない。
実際に誤読した例
編集部は、自社サイトの一群について「625ページ中、検索表示があるのは16ページ、2.6%だけ」と報告したことがある。この数字を根拠に、そのページ群に問題があると判断した。
測り直すと2つの誤りがあった。まず16は「表示が10回以上あるページ」の数で、表示が1回以上あるページは267、43.7%だった。次に、同じ条件でサイトの他の部分を測ると43.6%で、差が無かった。
2.6%という数字は単体では壊滅的に見えるが、比較対象を置くと同じ桁だった。差は「表示があるかどうか」ではなく「1ページあたりの厚み」にあった。
実務上の規則
編集部では次を守るようにしている。
件数や割合を根拠にする前に、分母を書く。書けないなら、その数字はまだ証拠ではない。基準率と並べる。全体が7%のところでの2.6%と、全体が0.1%のところでの2.6%は意味が違う。そして、閾値を変えて数えた数を、閾値なしの数として書かない。
抑制層：誤りを減らす
検知層ができてから、抑制に進む。
プロンプトでの抑制
分からないときに分からないと言わせる。 出力の選択肢に「該当なし」「情報が不足している」を明示的に含める。これが無いと、モデルは何かを埋めようとする。
否定形で書く。 編集部の実測では、害を名指しする判定を作る際、肯定形で書くと見逃しが多く、否定形にすると精度が上がった。「〜でなくても該当する」「言い切れなければ該当する側に倒す」といった形にすると、判定が保守的に働く。
観測できる言葉で書く。 抽象的な性質（「自己完結しているか」）を尋ねると、すべての対象に同じ値が返る現象が起きた。欠陥の有無（「他の箇所を参照させる表現があるか」）を尋ねる形に変えたところ、判別するようになった。
参照文書を付ける場合の注意
検索で文書を取得して回答させる構成では、取得した文書が適切だったかを別に評価する必要がある。的外れな文書を渡されたモデルは、その文書に沿ったもっともらしい誤りを返す。
編集部の運用では、回答の評価とは別に、取得された文書が問いに対応しているかを見る指標を持っている。回答が誤っていたとき、モデルの問題か取得の問題かを切り分けるためである。
出力の形を縛る
自由記述で答えさせると、モデルは文章を成立させるために不足を埋める。選択肢や数値など、取りうる値が決まっている形式にすると、埋める余地が減る。
編集部の判定層では、問いを真偽値で答えられる形に分解している。「この文章は適切か」ではなく「他の箇所を参照させる表現があるか」「数値の出典が同じ段落にあるか」のように、観測できる事実を1つずつ尋ねる。分解すると、どの部分で判断が割れたかも分かる。
一度に尋ねる量を減らす
長い文脈を一度に渡して総合判断を求めると、見落としが増える。編集部の経験では、判定対象を節単位に切り、節ごとに同じ問いを投げる形にしたほうが、見逃しが減った。
ただし切りすぎると、前後の文脈が必要な判断ができなくなる。どこで切るかは対象による。切る単位を変えて成績を測り、良かった単位を採用するのが確実である。
辞書と生成の使い分け
既知のパターンは、生成に任せず辞書で判定するほうが確実である。編集部の実測では、名前の付いた既知のパターンは見逃しが0.2%だったのに対し、名前の無い新しいパターンは24%だった。
この差は、同じ種類の事例を学習データに追加しても縮まらなかった。既知のパターンを増やしても、未知のパターンには効かない。生成に期待するのは未知の側で、既知の側は辞書で固めるほうが安定する。
モデルの選択
課題によって適するモデルは変わる。ただし、モデルを替えて成績が上がったと判断する前に、比較の条件が揃っているかを確かめる必要がある。
編集部では、学習を伴う手法と伴わない手法を比べた際、無作為に分割した検証で前者が0.997、後者が0.929という結果が出た。しかし同じ種類の事例が学習側と検証側の両方に入っていたためで、種類ごとに分けると前者は0.713に落ちた。結論が逆転した。
学習を伴う比較では、同じ性質の事例をまとめて分ける。分けないと、記憶した内容を実力として読むことになる。
事例：AI検索に自社がどう見えているか
ハルシネーションは、自社が利用する側だけの問題ではない。自社について生成AIが誤った説明をするという形でも現れる。
実際に起きたこと
編集部が2026年8月に測定したところ、生成AIが自社サービスを「申請代行・成功報酬型」と説明していた。事実と異なる。
原因を調べると、AIの幻覚ではなかった。自社が機械向けに配信していた説明文に、その文言が書かれていた。AIはそれを逐語で引用していた。法令上の線引きから避けてきた表現が、人が読む面ではなく機械が読む面に載っていたことに、誰も気づいていなかった。
空白は一般論で埋められる
同じ測定で、料金に関する説明が業界の一般論で補完されていることも分かった。機械向けの面に料金の記載が無かったためである。
書かれていないことは、AIが周辺の情報から補う。 自社について正確に説明されたいなら、提供することと提供しないことの両方を、機械が読む面に明示する必要がある。
現在の測定結果
2026年9月20日に再測定した。検索を伴う生成AIに、一般的な業務上の問い8問を投げて、自社が引用されるかを見た。
結果は0件だった。対照として自社名を含む問いを4問投げると4件すべてで引用されたため、測定そのものは機能している。指名すれば出るが、一般的な問いでは候補に入っていない。
引用されていたのは、その分野を生業にしている事業者の記事だった。規模の大小は問わず、小規模な事業者も含まれていた。
評価データそのものを疑う
判定の精度を測るとき、評価用のデータに問題があると、モデルの改善では解決しない誤りを追うことになる。
材料を読まずに当たる近道
編集部が判定器の評価集合を点検したところ、文章の長さだけで判定して高い精度が出る状態になっていた。本来判定してほしい内容とは無関係の特徴で正解が予測できてしまうと、モデルの改善が成績に現れない。
評価集合を作ったら、素朴な特徴だけで解いてみる。文字数、特定の語の有無、出現順といった表層的な情報でどこまで当たるかを測る。当たりすぎる場合、その評価集合は目的の能力を測っていない。
集計から消えている型
もう1つの点検は、評価集合に含まれていない型を洗い出すことである。編集部の場合、判定対象になりうる27の分類のうち、評価集合に登場するのは12だけだった。残りの15は一度も検査されていない。
このとき「被覆率」のような数字を出すと誤解を生む。指した割合と、対象の広さを覆った割合は別の量である。
基準線を必ず併記する
成績を報告するときは、何もしない場合の水準を並べる。編集部の判定層では、上位1件の的中率が0.568だった。単体では実力があるように見えるが、最も多い分類を常に答えるだけで0.446になる。判定器が実際に買っているのは0.122である。
基準線を書かないと、次に読む人が数字を過大評価する。
運用層：誤りが通っても被害を出さない
検知と抑制を尽くしても、誤りは通る。最後の層は、通ったときに被害を限定する設計である。
人の確認を残す場所を決める
すべてを人が確認すると自動化の意味が無くなる。編集部では、確認が必要な操作を有限の一覧で定めている。不可逆な操作、対外的に届く操作、費用や権限に関わる操作である。
一覧を有限にしたのが要点である。「重要なものは確認する」という書き方だと、何が重要かの判断が毎回発生する。一覧に載っているかだけで判定できる形にすると、載っていないものは進めてよいと決まる。
出力が外に出る経路を把握する
編集部では、自社サイトの機械向け配信面に書かれた説明が、そのまま生成AIに引用され、事実と異なる説明として流通していた事例があった。AIが誤ったのではなく、こちらが書いていた文言が逐語で運ばれていた。
対外的に出る面には、提供することだけでなく提供しないことを書いておく。AIは書いてあることを運ぶので、書かれていない部分は一般論で補完される。
記録を残す
問いと出力を記録し、後から追えるようにする。誤りが見つかったとき、同種の誤りが他にどれだけあるかを調べる材料になる。
記録が無いと、1件の誤りが例外なのか傾向なのかを判断できない。
導入時に決めておく5つのこと
生成AIを業務に入れる際、着手前に決めておくと後の手戻りが減るものを挙げる。
1つ目、誤りが起きたときに誰が気づくか。人が読むのか、機械で検査するのか、利用者からの指摘を待つのか。
2つ目、検査が機能していることをどう確かめるか。壊れた対象を1つ用意しておく。
3つ目、確率を使うなら、較正を確認したか。確認していないなら、確率は使わずに別の判断材料を探す。
4つ目、成績を出すときの分母と基準率。何と比べて良いのか悪いのかを先に決める。
5つ目、人の確認を残す操作の一覧。有限の列挙にする。
決めた内容を残す場所
この5つを決めたら、口頭ではなく文書に残す。編集部では、判断の根拠と「この判断が成り立たなくなる条件」を1行で添えるようにしている。
条件を添える理由は、前提が変わったときに見直せるようにするためである。「確率が較正されていないので閾値は使わない」という判断は、較正が確認できた時点で見直すべきものになる。条件が書かれていないと、判断だけが残って理由が失われる。
見直しの間隔を決める
モデルもデータも更新される。一度決めた設計が、半年後に同じ根拠で成り立つとは限らない。
編集部では、評価集合を使った測定を定期的に実行し、成績が一定の水準を下回ったら止まるようにしている。水準は現在値から一定幅を引いた値に置いている。絶対値で置くと、良くなったときに更新し忘れる。
測定を自動で走らせるのが要点である。手で実行する運用にすると、忙しい時期に止まり、止まったことに気づかない。編集部の実例では、発火を確認する自動テストが存在していたのに実行されておらず、計測が止まっていることに数週間気づかなかった。
出典が付いていても、出典を確かめないと検証にならない
根拠のない生成への対策として、検索結果を参照させて出典を付けさせる方法がある。だが出典が付いていることと、出典が正しいことは別の量である。
中継用の住所を数えていた
編集部では、生成AIが何を引用しているかを測る仕組みを作った際に、この落とし穴を踏んだ。
利用した仕組みが返す出典は、そのままでは引用元の名前ではなく、中継用の短縮された住所だった。見かけ上は出典が付いているが、その住所を実際にたどらない限り、どの媒体を引用したのかは分からない。
最初の集計は、この中継用の住所をそのまま数えていた。結果として、すべての引用が同じ場所を指しているように見え、引用元の分布がまったく取れていなかった。住所を解決する処理を足して初めて、実際の媒体名が出た。
数えていた間、集計は正常に動いているように見えていた。件数は出るし、エラーも出ない。間違った量を、正しく数えていた。
同じことは人が読むときにも起きる
この構造は、人が出典つきの回答を読むときにも起きる。出典が付いていると、確かめた気になる。しかし脚注の数と、脚注が主張を支えているかは別である。
生成AIが付ける出典には、実在するが主張と関係のないページ、実在するが主張と逆のことが書かれているページ、そして実在しないページが混ざり得る。
確かめ方は3つ
出典を開く。 開いた先に、主張に対応する記述があるかを見る。開かずに信じると、出典は飾りになる。
日付を見る。 古い情報が現在の記述として使われていないか。制度や料金は変わる。
発行元を見る。 引用元が一次情報か、それとも別の記事を引用した二次情報か。二次情報を辿ると元がなかった、という例がある。
全部は確かめられないので絞る
3つの確認をすべての主張に対して行うのは現実的ではない。誤ると影響の大きい主張に絞る。
金額、日付、固有名詞、法令の条文。この4つに限れば、確認は短時間で済む。逆に言えば、この4つを確かめずに公開する文書は、出典が付いていても検証されていない。
まとめ
ハルシネーションはゼロにできない。実務の目標は、起きたと分かること、分からない範囲を把握していること、通り抜けても被害が出ないことの3つである。
検知・抑制・運用の順で作る。検知が無い状態で抑制から入ると、効果が測れない。
そして検知層を作ったら、検知の仕組み自体が機能しているかを確かめる。編集部の実測では、1日のうちに検査が対象に届いていない事例が複数出た。いずれもエラーを出さず、正常終了して「問題なし」を返した。合格は「欠陥が無い」ことを意味するとは限らない。
確率を使うなら較正を確認する。成績を出すなら分母と基準率を書く。この2つを省くと、数字があるのに判断できない状態になる。
最後に1つ。ハルシネーション対策で最も費用対効果が高いのは、高度な検知手法の導入ではなく、既にある検査が本当に走っているかを一度確かめることだった。編集部の場合、必要な検査はすでに書かれており、実行されていなかっただけである。新しい仕組みを足す前に、手元にあるものが動いているかを見てほしい。
編集部では、AI導入時の検証設計や、導入後に効果が測れているかの点検も行っている。本記事で挙げたような「検査はあるが機能していない」箇所の洗い出しについては、サービス案内を参照してほしい。
参考にした一次資料
- Claudeのツール利用に関する公式ドキュメント — モデルに外部情報を参照させる仕組みの解説
- OpenAIのFunction calling公式ガイド — 出力を構造化された形式に縛る仕組みの解説
- 総務省 AIネットワーク社会推進会議 — AIの社会実装に関する国内の検討会議体
- 情報処理推進機構（IPA） — 情報システムの信頼性・セキュリティに関する公的機関
- デジタル庁 — 行政のデジタル化・AI活用に関する政府機関
よくある質問
ハルシネーションはゼロにできますか。
現在の技術ではゼロにはできません。確率的に出力を生成する仕組みである以上、誤りの可能性は残ります。実務上の目標は根絶ではなく、誤りが出たときに検知できること、検知できない範囲を把握していること、そして誤りが致命的になる経路に人の確認を残すことです。本記事はその3点を実装する方法を扱います。
ハルシネーションを検知する仕組みを作れば安心ですか。
検知の仕組みそのものが機能しているかを確かめる必要があります。編集部の実測では、検査が対象に届いていないまま「問題なし」と合格を返していた事例が1日で複数ありました。合格は「欠陥が無い」ことを意味せず、「検査が届いていない」だけかもしれません。壊れた対象を用意して、検査が実際に落ちることを確かめる手順を本記事に載せています。
モデルが出す確信度（確率）は信用できますか。
較正されているかを確認するまで信用できません。編集部が運用する判定層では、出力される確率が較正されていないことを前提に、判定の境目を呼び出す側が持つ設計にしています。確率の順位が正誤を分けていない場合、閾値をいくら調整しても精度は上がりません。実際に閾値を0.5から0.9に上げると、指した割合が落ちるのに的中率はむしろ下がる、という測定結果が出ています。
RAGを入れればハルシネーションは減りますか。
減る場面はありますが、別の失敗が増えます。検索で取ってきた文書が的外れだった場合、モデルはその文書に沿ったもっともらしい誤りを返します。出典が付くぶん、誤りが権威づけられて見える分だけ厄介になることもあります。RAGを入れたら、取得した文書が適切だったかを別に評価する必要があります。