ハルシネーション対策｜誤り5類型と関門4か所の対応表

AIの出力に混ざるハルシネーションは、放置すると公開物にそのまま残ります。本記事は、ハルシネーション対策としてのファクトチェックを、仕組みとして設計します。誤りを5類型に分解し、生成直後の自己検証から公開前の人間ゲートまで、4つの関門へ検出の役割を割り当てます。1つの関門に検査を集中させないのが要点です（2026-07-28時点の自社記録）。

01結論：ハルシネーション対策は、誤りの型ごとにファクトチェックの関門を割り当てる

結論は3点です。

1. ハルシネーションは1種類ではありません。出典の捏造・数値のすり替え・仕様の一般化・時制のずれ・単位のずれで、検出方法が変わります。
2. 関門は4か所（自己検証・独立照合・機械検証・人間ゲート）に分け、型ごとの得意不得意を対応表で管理します。
3. 全文を人が読むのではなく、断定文の周辺・自社実績の記述・初出の固有名詞に検査コストを寄せます。

このハルシネーション対策は、本メディア自身の品質ライン（執筆→独立ファクトチェック→機械検証→批評→修正）をそのまま構造として開示するものです。同じラインの実物開示は『AIが書いた記事をAIが差し戻す｜公開前チェック5段階の中身』で扱っています。本記事はその実物を、読者が自社の公開・提出フローへ移植できる設計論として抜き出します。

検出したあとの止め方（誰が承認し、何を記録するか）は、本記事の範囲外です。そこは『AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み』で扱っています。

02ハルシネーションの5類型｜AI出力に混ざる誤りを分解する

ハルシネーションという言葉は「事実と違うことをもっともらしく書く」現象全体を指しますが、対策を設計するには型で分ける必要があります。型が違えば、効く検出方法も違うからです。

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

台帳のどこにもその内訳は存在せず、独立ファクトチェック工程が原典と突合して捏造を検出しました。合計が実在しても、その内訳まで実在するとは限りません。

03ハルシネーション対策の4つの関門｜誤り型とファクトチェックの対応表

4つの関門は、それぞれ得意な誤りの型が異なります。

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

Anthropicは、自己検証の具体策を3つ挙げています。根拠が見つからない主張は取り下げること、引用元の文を直接抜き出してから書くこと、最終回答の前に段階的な推論を確認することです（出典: Anthropic公式ガイド）。①の自己検証はこの水準までしか担保できません。書いた本人の推論そのものが誤っていれば、本人による見直しでは気づけないからです。

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

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

5類型と4関門を突き合わせると、次の対応表になります。

表からわかるのは、②独立ファクトチェックがほぼ全ての型に強いという事実です。これは②が万能という意味ではなく、③機械検証がまだ弱い型（出典の実在性・数値の主体・仕様の適用範囲）を、現状は②が肩代わりしているという意味です。③を拡充すれば、②の負荷は下がります。

04数字のハルシネーションはSSOT突合でしか防げない

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

本メディアの姉妹メディアの公開本数は、3段階で数字が変わりました。

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

189という数字は、体裁のうえでは「本番URLで確認した」ものに見えます。しかし確認の中身が要約ツールの出力を信じただけであれば、それは一次情報ではなく二次情報です。数字の裏取りにおける最大の罠は、確認した「つもり」の数字を、確認済みの数字と区別できないことです。

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

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

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

05出典管理でハルシネーションを外に出さない仕組み

出典管理は、ハルシネーションを検出するだけでなく、検出できる状態を先に作っておく仕組みです。3つの実装が要ります。

引用範囲の逸脱は、原文が長いほど語数の実感が薄れて起きます。公式ドキュメントの英文をそのまま引用すると、20語という連続引用の上限を越えていることに気づかないまま初稿へ残りやすくなります。この型は語数を数え直さない限り気づけないため、①自己検証では捕まりにくく、②独立ファクトチェック工程が原文と本文を語数まで突合して初めて検出できる型です。

この点検は、字数のカウントさえできれば機械化できます。次のような判定関数を機械検証に追加する設計です。

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

出典管理でハルシネーションを外に出さない仕組みは、検出を人の注意力に頼らない設計でもあります。Googleは、自動化やAI生成の利用を訪問者に対して自明にしているかを、コンテンツの自己点検項目に挙げています。その使われ方の背景を説明しているかも、あわせて問う項目です（出典: Google公式ガイドライン）。出典を構造として持たせることは、この自己点検に答える手段でもあります。

06検査コストの配分｜事実誤認をどこに寄せて検査するか

全文を同じ密度で人が読むのは、記事数が増えるほど現実的ではありません。検査コストは、事実誤認が起きやすい箇所へ寄せます。

判断軸は3つです。

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

この3軸を使う理由は、ハルシネーションが記事全体に均等に発生するわけではないからです。一般的な説明文よりも、自社の実績を語る一文・断定的な結論・その記事で初めて出す固有名詞に集中して発生します。

読者が自社の公開・提出フローへこの設計を移すときは、次の3手順で置き換えます。

1. 自社の誤りやすいパターンを、ハルシネーションの5類型に当てはめて洗い出す
2. 既存の校正・レビュー工程を、4つの関門のどこかに割り当て直す
3. 対応表で「弱い」に分類された組み合わせだけ、新しい検査を足す

ゼロから作り直す必要はありません。

07ハルシネーション対策でつまずきやすい点｜見落としやすい2つの誤りの型

ハルシネーション対策の仕組みは、作った時点では完成しません。第1弾の量産工程では、独立ファクトチェック工程が検出した誤りが実際に1件あり、同じ関門設計で捕まえるべき誤りの型がもう1つあります。

1つ目は、前述の「数値の主体すり替え」です。事故ファイル記事の初稿は、フック誤爆233回という実在する合計値の下に、日別の内訳表を追加していました。台帳のどこにも日別の数字は記録されておらず、独立ファクトチェック工程が原典照合で捏造を検出し、内訳表は除去されました。詳しい経緯は『AI運用の障害切り分け｜更新時刻を犯人にしない4段の手順』で扱っています。

2つ目は、前述の引用範囲の逸脱です。原文が長い引用ほど語数の実感が薄れて起こるため、①自己検証では気づきにくく、②独立ファクトチェック工程が原文と語数まで突合して初めて検出できる型です。

2つに共通するのは、書いた本人には見えにくい点です。日別内訳は「合計が本物だから作ってもいい」という思い込みが起点になり、引用超過は語数を数え直さない限り気づけません。どちらも①自己検証では捕まりにくく、②独立ファクトチェックが原典・語数との突合で初めて検出できる型です。

検出そのものより、検出したあとに誰が承認するかで揉めることのほうが多いのも実情です。承認の仕組みは前述のとおり別記事で扱っているため、本記事では検出関門の設計に絞ります。

08チェックリスト

• ハルシネーションを5類型（出典の捏造・数値の主体すり替え・仕様の無断一般化・現在形化・単位や期間のずれ）に分けて洗い出したか
• 4つの関門（自己検証・独立照合・機械検証・人間ゲート）に、担当と手順をそれぞれ割り当てたか
• 独立ファクトチェックの担当を、執筆担当とは別の人・別のエージェントにしているか
• 数字を書く前に、正本SSOTを1つに決めているか
• 「確認した」という記述に、確認の手段（何を・どう数えたか）まで書いているか
• 一次情報URLを記事の構造（frontmatter等）として持たせているか
• 引用範囲の制限（著作物の連続引用の上限）を、機械的に検査する計画があるか
• 検査コストを、断定文の周辺・自社実績の記述・初出の固有名詞に優先して配分しているか

09FAQ