ハルシネーション対策｜誤り5類型を止める関門4か所

「この文章、AIに下書きさせたんですけど、どこまで疑えばいいですか」。社内でそう聞かれて、答えに詰まったことはないでしょうか。

「全文を読み直しておいて」で片づけたくなります。ただ、読み直せば気づける誤りと、読み直しでは気づけない誤りが、同じ文面の中に混ざっています。前者だけを何度も潰していると、後者だけが公開物に残ります。

この記事は、ハルシネーション対策を「気をつける」から「仕組みで捕まえる」へ移し替えます。やることは2つです。AIの誤りを型で分けること。そして、自己検証・独立照合・機械検証・人間ゲートという4か所の関門へ、型ごとに検査を配ることです。素材にするのは、本メディア自身の品質ラインで実際に検出された誤りです。

検出したあと、誰が承認して止めるかは本記事の範囲外です。そこはAIエージェントの承認ゲート｜止める操作4種と3層の選び方が引き受けます。

進行役は3人です。若葉さん（Web担当2年目）が言葉のそもそもを聞き、高梨課長が自分の手で回す方法を確かめ、鈴木さん（本誌監修）が答えます。

01AIエージェントのハルシネーション対策は、ファクトチェックをどこに置けばいいんですか？

若葉さん

若葉さんの発言

ハルシネーション対策って、結局「よく読む」以外に何かあるんでしょうか。

鈴木さん

鈴木さんの発言

空港の保安検査を思い浮かべてください。金属探知機とX線と、係員の目視は別のものを見ていますよね。どれか1台を高性能にしても、他が見ている種類は拾えません。文章の検査も同じ形にします。

先に結論を書きます。ハルシネーション対策は、検査の回数を増やす作業ではありません。誤りを型で分け、その型を捕まえやすい場所へ検査を配る設計です。

言い換えると、置き場所の話です。同じ検査でも、置く場所が違えば拾えるものが変わります。逆に置き場所を決めないまま「よく読む」を足しても、読んで気づける型が二重に潰れるだけで、読んでも気づけない型はそのまま残ります。

配る先は4か所です。生成直後の自己検証、執筆担当とは別の担当による独立照合、数えられるものを判定する機械検証、そして公開前の人間ゲート。この4つに、5つの誤りの型を割り当てていきます。

02AIエージェントのハルシネーションとは、そもそも何のことですか？

ハルシネーションとは、AIが事実と違うことを、事実のような書きぶりで出してしまう現象のことです。英語で「幻覚」を意味する言葉が、そのまま使われています。

いちばん誤解されやすいのは、これを「AIの故障」だと思ってしまうことです。壊れているわけではありません。文章としては筋が通っていて、日本語としても自然で、書きぶりも自信に満ちています。おかしいのは中身だけです。だから読み流すと通ってしまいます。

もうひとつ、「AIが嘘をついている」という言い方も、対策を考えるうえでは邪魔になります。嘘には、本当のことを知っていて別のことを言う、という前提があります。AIエージェントの場合、その前提がありません。知らないということ自体を、AIは知らないのです。人間なら「ここは自信がないな」と手が止まる場面で、AIの手は止まりません。

この違いは、対策の置き場所を変えます。嘘なら、正直に書くよう指示すれば減るはずです。ところがハルシネーションは、指示を足しても消えません。本人に自覚がない誤りは、本人の外側でしか捕まらないからです。この記事が「気をつける」ではなく「仕組みで捕まえる」に寄っているのは、そのためです。

03生成AIのハルシネーションは、なぜ起きるんですか？

理由は、AIの文章の作り方そのものにあります。AIは事実を調べて書いているのではなく、次に来そうな言葉を選び続けて書いています。

たとえば「日本の首都は」と書き出せば、次に来る言葉として「東京」がふさわしい、と判断します。これは、ものすごい量の文章を読んできた結果として身についた「言葉の並びの感覚」です。辞書を引いているわけでも、どこかの資料を確認しているわけでもありません。

この作り方は、よく知られたことを書くときには強く働きます。同じ並びを何度も見てきているからです。ところが、あまり書かれてこなかったことや、そもそも存在しないことを聞かれると、話が変わります。それでもAIは、次に来そうな言葉を選び続けます。空欄のまま止まるという選択肢を、AIは持っていないのです。

結果として起きるのが、もっともらしい形だけが先にできあがるという現象です。出典の体裁をした文字列、表の形をした数字、条文らしい言い回し。形は本物そっくりで、中身だけが裏づけを持っていません。この記事で扱う誤りの型が、どれも「読んだだけでは気づきにくい」のは、形の側が先に正しくなっているからです。

ここから、対策の順番が決まります。書き手に注意を求めても、形の正しさは変わりません。変えられるのは、形が正しいものを本当に裏づけがあるかどうかで選り分ける工程です。次の節から、その工程をどこに置くかを見ていきます。

04AI社員が書いた文章のハルシネーションは、どんな型に分かれるんですか？

ハルシネーションという言葉は、「事実と違うことをもっともらしく書く」現象をまとめて指します。たとえば、道を聞かれた人が、行ったことのない場所を、まるで毎日通っているかのように自信満々で説明してしまう場面を思い浮かべてください。本人には、嘘をついている自覚がありません。AIのハルシネーションも、これに近い動き方をします。悪意があって間違えるのではなく、もっともらしい形を先に作ってしまうのです。

ただ、対策を設計する側から見ると、この一語は粗すぎます。型が違えば、効く見つけ方が変わるからです。「よく読む」だけで対策した気になると、読んで気づける型ばかりを何度も潰し、読んでも気づけない型を見逃したままになります。

本メディアの品質ラインで実際に扱ってきた誤りを、5つに分けています。分けるのは、犯人探しのためではありません。型ごとに、どの関門を厚くすればよいかを決めるためです。

この5つは、並べ替えると2つの軸に載ります。書いた本人が気づけるかどうかと、機械で判定できるかどうかです。この2軸に置くと、どの関門を厚くすればいいかが、型ごとに決まります。

2つ目の「数値の主体すり替え」は、本メディアで実際に起きました。案件台帳には、3日間で233回フックが発火したという合計値だけが記録されていました。ところが記事の初稿は、この合計を80回・118回・35回という日別の内訳として表にしていたのです。

起きた順番をたどると、こうなります。まず執筆担当が「3日間で233回」という合計を台帳で見つけました。次に、読者に伝わりやすいよう、日ごとの推移が分かる表にしようと考えました。ここで、台帳には無いはずの日別の数字が、文章の流れを埋めるように差し込まれました。書いた本人の中では、「合計が本物なのだから、内訳もだいたいこのくらいだろう」という程度の感覚だったはずです。ところが独立ファクトチェックの担当が台帳を開き直したところ、日別の内訳はどこにも見つかりませんでした。合計233回という記録があるだけで、80・118・35という内訳は、どの資料にも存在しなかったのです。指摘を受けて、内訳表はその場で取り除かれました。

台帳のどこにも、その内訳はありません。独立ファクトチェックの工程が原典と突き合わせ、内訳表は取り除かれました。合計が実在しても、その内訳まで実在するとはかぎりません。

05AI導入のとき、ハルシネーション対策のファクトチェックは誰が担当するんですか？

高梨課長

高梨課長の発言

うちは私ともう1人で回しています。関門を4つに分けるとして、担当は分けられるものでしょうか。

鈴木さん

鈴木さんの発言

人数ではなく、視点を分けます。同じ人でも、書いた直後の自分と、原典を開きにいく自分は別の役です。分けにくいのは時間のほうで、間を空けるだけでも見え方は変わりますよ。

4つの関門は、それぞれ得意な型が違います。担当を割り当てるときは、この得意不得意を先に見ます。

• ①生成直後の自己検証：書いた本人（AI）が、提出する前に自分で見直す
• ②独立ファクトチェック：執筆担当とは別の担当が、一次情報の原典に当たって突き合わせる
• ③機械検証：字数・リンク切れ・引用語数など、数えられるルールをスクリプトで判定する
• ④公開前の人間ゲート：残った違和感と文脈の判断を、人が最終確認する

06AI社員のハルシネーションは、4つの関門のどこで捕まえるのが弱いんですか？

担当を割り当てたら、次は取りこぼしの場所を見ます。5つの型と4つの関門を突き合わせると、次の対応表になります。

表から読み取れるのは、②独立ファクトチェックがほぼ全ての型に強いという事実です。ただ、これは②が万能だという意味ではありません。③機械検証がまだ弱い型を、いまは②が肩代わりしているという意味です。③を足していけば、②の負荷は下がります。

もうひとつ読み取れるのは、①の列がほぼ「弱い」で埋まることです。ここが、次の章の話につながります。

07AIエージェントの自己検証だけでは、なぜハルシネーションが残るんですか？

①の自己検証は、置く価値があります。ただし、どこまで担保できるかには天井があります。

Anthropicは、自己検証の具体策を3つ挙げています。根拠が見つからない主張は取り下げること、引用元の文を直接抜き出してから書くこと、最終回答の前に段階的な推論を確認することです（出典: Anthropic公式ガイド）。

①で担保できるのは、この水準までです。書いた本人の推論そのものがずれていれば、本人による見直しでは気づけません。前章の日別内訳がそのまま残ったのも、この天井にぶつかった結果でした。

だからこそ②が要ります。Anthropicは、一方のLLM呼び出しが応答を作り、別のLLM呼び出しが評価とフィードバックを返す構成を挙げています。評価の基準がはっきりしているタスクに向くパターンです（出典: Anthropic公式）。

ただし、評価する側が同系統のモデルだと、評価そのものに偏りが出ます。LLMを評価者に使う研究では、位置バイアスや、自分の出力を甘く評価するバイアスが指摘されています（出典: LLM-as-judge論文）。

08生成AIが出した数字のハルシネーションは、どうやって止めるんですか？

高梨課長

高梨課長の発言

数字がいちばん怖いです。文章のおかしさは何となく分かるんですが、数字は見た目では分かりません。

鈴木さん

鈴木さんの発言

見た目では分からないので、読む前の段取りで決めます。どこを正本にするかと、どう数えたかを書き残すか。この2つを先に決めておくと、あとから疑えるようになります。

数値のハルシネーションは、読み直しでは止まりません。文章として自然であれば、誤った数字もそのまま通り抜けるからです。

本メディアの姉妹メディアの公開本数は、3段階で数字が変わりました。同じ問いに、3つの答えが出たことになります。

1. 最初の報告は「1本も公開されていない」でした。案件台帳の古い表記だけを根拠にしていて、本番サイトを一度も見ていませんでした
2. 次の報告は「189本」でした。本番URLは開いたものの、ページ全体を要約するツールが返した数字をそのまま採っており、数えた値ではありませんでした
3. 最終的な値は「251本」でした。sitemap.xmlを取得し、/articles/を含むURLの数をスクリプトで数え直した結果です

189という数字は、体裁のうえでは「本番URLで確認した」ものに見えます。しかし確認の中身が要約ツールの出力を信じただけなら、それは一次情報ではなく二次情報です。

数字の裏取りで最大の罠は、ここにあります。確認した「つもり」の数字と、確認済みの数字が、見た目でまったく区別できないことです。

この罠を外す手順は3つです。

1. 正本を先に決める：数字を確定させる情報源（台帳・sitemap・実行ログなど）を、書く前に1つ選びます
2. 二次情報を根拠にしない：要約ツールの出力、伝聞、他の記事に書かれていた数字は、それ自体を裏取りの根拠にしません
3. 確認の手段まで書く：「確認した」ではなく「sitemap.xmlを取得し、/articles/を含むURL数を数えた」まで、本文か記録に残します

3を省くと、次に読む担当者が確認の精度を再現できません。189という数字も、手段が記録されていれば、その場で疑えたはずです。

09AIエージェントの出典管理は、ファクトチェックの手間をどう減らすんですか？

出典管理は、誤りを見つける仕組みであると同時に、見つけられる状態を先に作っておく仕組みでもあります。②の担当が原典に当たれるかどうかは、出典がどう保管されているかで決まります。

必要な実装は3つです。

3つ目だけが空いています。引用範囲の逸脱は、原文が長いほど語数の実感が薄れて起きます。公式ドキュメントの英文をそのまま引くと、20語という連続引用の上限を越えたことに気づかないまま初稿へ残りやすくなります。

この型は、語数を数え直さないかぎり気づけません。だから①では捕まらず、②が原文と本文を語数まで突き合わせて、はじめて検出できます。

一方で、この点検は数えるだけの作業です。つまり③へ移せます。次のような判定を機械検証に足す設計になります。

def check_citation_length(quote: str, max_words: int = 20) -> bool:
    """20語を超える連続引用を検出する（社内規約準拠）"""
    return len(quote.split()) <= max_words

Googleは、自動化やAI生成の利用を訪問者に対して自明にしているかを、コンテンツの自己点検項目に挙げています。その使われ方の背景を説明しているかも、あわせて問う項目です（出典: Google公式ガイドライン）。出典を構造として持たせることは、この自己点検に答える手段でもあります。

10AIエージェントのファクトチェックで、一次情報と二次情報はどう見分けるんですか？

若葉さん

若葉さんの発言

一次情報とか二次情報とか、言葉としては聞くんですが、実際の記事のどこで区別すればいいのか分かりません。

鈴木さん

鈴木さんの発言

自分が最後に見たものが何かで判断します。台帳やsitemapのように、数字が生まれた場所そのものを見たなら一次情報。誰かがまとめた結果だけを見たなら二次情報です。

前の章で見た「189本」という数字は、この見分けがつかないまま公開に近づいた例でした。本番URLは開いています。手順としては裏取りをしたように見えます。ただし、実際に見たのはページ全体を要約するツールの出力で、URLを1件ずつ数えた記録ではありませんでした。

見分け方は、次の1問に集約できます。自分が最後に見た画面は、数字が生まれた場所そのものか、それとも誰かがすでにまとめた結果か。台帳の記入欄・sitemap.xmlのURL一覧・実行ログの出力は、数字が生まれた場所そのものなので一次情報です。要約ツールの返答、他の記事に書かれていた数字、人づての報告は、すでに誰かの手を経ているので二次情報です。

厄介なのは、二次情報が一次情報の顔をして出てくることです。要約ツールは、本番URLを見たうえで答えを返します。見た対象そのものは本物でも、見た人（ツール）が間に入った時点で、その出力は二次情報に変わります。あいだに人やツールが1つでも挟まれば、そこから先は二次情報だと考えてください。

11AI活用の現場で、ファクトチェックのコストはどこに寄せればいいんですか？

高梨課長

高梨課長の発言

記事の本数が増えると、全文を同じ密度で読むのは無理です。どこから手を抜けばいいんでしょうか。

鈴木さん

鈴木さんの発言

手を抜く場所を探すより、寄せる場所を決めるほうが早いです。誤りは文章全体に均等には出ません。出やすい場所が決まっているので、そこへ寄せます。

誤りは、記事全体へ均等に発生するわけではありません。一般的な説明文よりも、自社の実績を語る一文、言い切りの結論、その記事で初めて出す固有名詞に集中します。

だから、検査の手間もそこへ寄せます。判断軸は3つです。

1. 言い切りの直後：「〜すべきです」「〜は危険です」のような断定の直後2文以内に、出典・実測・失敗例のどれかが隣接しているかを重点的に見ます
2. 自社の実績を語る一文：稼働中・公開済みのような状態を語る文は、実測日の記録があるかを毎回確認します
3. 初めて出す固有名詞とURL：その記事で初出の製品名・数値・URLは、既出のものより誤りが混ざりやすいため優先します

この3軸は、読む順番の指定でもあります。頭から均等に読むのではなく、まず該当箇所へ飛び、隣に根拠があるかだけを見る。そのうえで残った時間を通読に充てます。

12AI社員のハルシネーション対策で、いちばん見落とすのはどこですか？

仕組みは、作った時点では完成しません。第1弾の量産工程では、②が実際に検出した誤りが1件ありました。そして、同じ設計で捕まえるべき型がもうひとつ残っていました。

1つ目は、前述の数値の主体すり替えです。実在する合計値の下に、日別の内訳表が足されていました。②が原典照合で検出し、内訳表は取り除かれました。詳しい経緯はAI運用の障害の原因切り分け｜証跡で追う4段の順序で扱っています。

2つ目は、引用範囲の逸脱です。原文が長いほど語数の実感が薄れるため、①では気づきにくく、②が原文と語数まで突き合わせて、はじめて検出できます。

2つに共通するのは、書いた本人には見えにくいという点です。日別内訳は「合計が本物だから作ってもいい」という思い込みが起点になり、引用超過は語数を数え直さないと気づけません。どちらも、本人の注意力を増やしても減りません。

13AI社員の対策は、5つの誤りの型のどれから優先すればいいんですか？

高梨課長

高梨課長の発言

5つの型と4つの関門を並べられても、正直どこから手をつけていいか迷います。優先順位はあるんでしょうか。

鈴木さん

鈴木さんの発言

対応表の中で「弱い」が並んでいる型から見ています。特に、①だけでなく②も薄い型があれば、そこが最優先です。

前に出した対応表をもう一度見ると、優先順位は自然に決まります。見るのは「弱い」の数ではなく、弱さが重なる組み合わせです。

1. 最優先にしなくてよい範囲：5つの型はどれも、②独立ファクトチェックに「強い」か「中」がついています。②を先に置くだけで、いちばん危ない組み合わせ（本人も気づけず、他の担当も気づけない）はひとまず避けられます
2. 次に厚くする範囲：「限定的な仕様の無断一般化」は、③機械検証が「効かない」型でした。文法的に正しい一文は機械では判定できないため、②の負荷をこの先も③へ逃がせません。②の担当時間を、この型だけ厚めに割り当てます
3. 最後に整えてよい範囲：「単位・期間のずれ」は③が「強い」型でした。語数や文字数のパターンで機械が拾えるので、検査のコードを書くところまで進めば、あとは仕組みが働き続けます

5つの型を同じ熱量で警戒する必要はありません。対応表の列を見て、②が薄い型から人の目を割り当て、③が効く型から機械に任せていくのが、手間のいちばん少ない順番です。

14うちのエージェント運用に、このハルシネーション対策の4つの関門はそのまま移せるんですか？

そのまま移せます。ゼロから作り直す必要はありません。すでにある校正やレビューの工程に、名前を付け直すところから始めます。

移し替えは3段です。

1. 自社で起きた失敗を並べる：思い出せるものを、記憶のまま書き出します。この段階では型に当てはめません
2. いまある工程に名前を付け直す：誰が・いつ見ているかを、①〜④の関門の名前で呼び直します。ここで空いている関門が見えます
3. 空いた枠だけを埋める：対応表で「弱い」に分類された組み合わせのうち、いまの体制で誰も見ていないものだけ、新しい検査を足します

3段目まで来ると、足すべき検査は思ったより少なくなります。多くの現場では、①と④はすでに存在していて、②と③のどちらかが空いているだけだからです。

15AI導入の前に、ハルシネーション対策で何を確認しておけばいいんですか？

移し替えに入る前の確認です。次の項目を上から見て、「いいえ」が1つでもあれば、検査を足すよりそこを先に埋めます。

• AIの誤りを5つの型に分けて、自社で起きたものを洗い出したか
• 4つの関門に、担当と手順をそれぞれ割り当てたか
• ②独立ファクトチェックの担当を、執筆担当とは別の視点に置いたか
• 数字を書く前に、正本を1つに決めているか
• 「確認した」という記述に、確認の手段まで書いているか
• 一次情報URLを、記事の構造として持たせているか
• 引用範囲の上限を、機械的に検査する計画があるか
• 検査の手間を、言い切り・自社実績・初出の3か所へ寄せているか

上から4つは、今日の会議でも決められます。下の4つは、記事や資料のひな形に欄を足す作業です。前者を先に決めておくと、後者の欄に何を書けばいいかが迷わなくなります。

16AIエージェントのハルシネーション対策は、どこまでやれば十分なんですか？

若葉さん

若葉さんの発言

4つ全部そろえたら、もう誤りは出なくなるんでしょうか。

鈴木さん

鈴木さんの発言

そこは正直に言うと、そうはならないと考えています。関門を増やすほど漏れは減りますが、ゼロになるという言い方は私にはできません。だから、漏れたときに直せる形にしておくほうを重く見ています。

十分の線は、検出率では引けません。関門をいくつ置いても、その先で誤りが出る可能性は残ります。

代わりに引ける線があります。漏れたときに、どこで漏れたかを言えるかです。型と関門の対応表を持っていれば、公開後に見つかった誤りを表のどのセルへ戻すかが決まります。戻す先が決まれば、次に足す検査も決まります。

たとえば、公開後に「限定的な仕様の無断一般化」型の誤りが見つかったとします。対応表を見ると、この型は②独立ファクトチェックだけが「強い」で、①③④はもともと弱い区画でした。②の担当がその原典を見落としていたのなら、担当を替えるか、確認する範囲をもう少し狭く指定し直します。反対に、②がそもそも置かれていなかったのなら、まずそこを埋めるところから直します。対応表は、直す場所を毎回この形で指し示してくれます。

もうひとつ、この記事で扱えていない範囲があります。誤りを見つけたあと、誰が承認して止めるかです。実務では、検出そのものより、そのあとの止め方で揉めることのほうが多いのが実情です。承認の仕組みはAIエージェントの承認ゲート｜止める操作4種と3層の選び方へ譲り、本記事は検出側の設計に絞りました。

17よくある質問

18まとめ｜今日やる3つのこと

型で分け、関門へ配り、空いた枠だけ足す。順番はこの3つだけです。手を動かす順に並べておきます。