生成AIのハルシネーション対策。事実検証を仕組みにする運用

生成AIのハルシネーション対策とは、AIがもっともらしい嘘を事実のように出力する前提に立ち、人の注意力ではなく検証の仕組みで事故を防ぐ運用のことです。プロンプトの工夫だけでは防げません。僕は自社ブログの記事をAIでつくって毎日公開しており、公開済みの記事は2026年8月23日時点で50本あります。この記事では、その運用で毎回通している事実検証の手順を、そのまま公開します。

生成AIのハルシネーション対策はなぜ「注意して使う」では足りないのか

生成AIを業務に入れた会社で、ほぼ必ず出てくる掛け声があります。「AIの出力は必ず確認してから使うこと」。この掛け声自体は正しいのですが、これだけでは対策として機能しません。

人の注意力は、量が増えた瞬間に負ける

導入直後の1週間は、みんな真剣に確認します。ところがAIを使うと出力の量が一気に増えます。週1本だった提案書が毎日出るようになり、確認すべき文書が10倍になる。注意力は「状態」であって「仕組み」ではないので、疲れれば途切れ、急ぎの日には飛ばされます。

「注意して使う」は対策ではなく、対策がまだ無い状態の言い換えです。

全部を人が調べ直すなら、AIを使う意味がない

逆に「ダブルチェック」を真面目にやりすぎると、今度は別の問題が起きます。AIの出力を結局ぜんぶ人が調べ直すことになり、AIで書く時間より検証する時間のほうが長くなる。現場は「最初から自分で書いたほうが早い」に戻ります。

必要なのは、注意の徹底でも全数の再調査でもなく、疑うべき箇所を絞って検証を工程にすることです。この記事の残りは、その工程の作り方です。

ハルシネーションはなぜ起きるのか。原因の理解は3つで足りる

ハルシネーションとは、生成AIが事実でない内容をもっともらしい文章で出力する現象のことです。原因を深追いする必要はありませんが、対策を設計するのに必要な理解は3つだけあります。

1. 仕組みの問題。生成AIは「次に来る確率が高い言葉」を並べて文章を作ります。知らないことを聞かれても、それらしい言葉の並びは作れてしまう。嘘をつく意図があるのではなく、そもそも正誤という概念を持っていません。

2. 材料の問題。学習データに誤りや古い情報が混ざっています。2年前の料金や仕様を、今日の事実のような顔で答えることがあります。

3. 指示の問題。曖昧な質問や誘導的な聞き方は、辻褄合わせの回答を引き出しやすくなります。

重要なのは1つ目です。確率で言葉を並べる仕組みそのものに由来する以上、プロンプトやツールの工夫で発生を完全にゼロにすることは期待できません。だから対策の目標を「嘘を出させない」に置くと失敗します。目標は「嘘が混ざっていても事故にならない工程を作る」に置きます。

対策の考え方。出力を疑うのではなく「検証を通ったものだけ使う」

僕の運用の背骨は、発想の転換が1つだけです。「AIの出力を信じるか、疑うか」という問いをやめて、「検証を通ったものだけが次の工程に進める」という一方通行の流れを作ります。僕はこれを検証ゲートと呼んでいます。

信じる・疑うは人の状態の話なので、忙しさや慣れで簡単に崩れます。ゲートは工程の話なので、誰がいつ回しても同じ基準で動きます。僕のブログ運用では、この原則を先に文章で固定しました。

確認できない数字は書かない。実測していないことを、実測したこととして書かない。確認した事実と推測を、分けて書く。

経営者の感覚に翻訳すると、これは部下への任せ方と同じです。部下の報告を毎回ぜんぶ疑い直す経営者はいません。稟議や経理の突合のようなチェックの仕組みがあるから、疑わずに任せられる。AIも同じで、検証ゲートがあるから、出力を安心して業務に流せるようになります。

検証を通ったものだけが公開・提出に進む。通らないものは、どれだけ出来が良さそうでも止まる。

業務で回る事実検証の手順5ステップ

ここからが現物です。僕のブログは記事をAIが書きますが、公開までに次の5ステップの検証を毎回通します。ブログ以外の文書（提案書・見積もり・顧客向け資料）でも、そのまま流用できる形にしてあります。

ステップ4の機械検査は「使ってよい数字の台帳」とセット

僕のブログでは、公開前の機械検査が2026年8月時点で21項目あります。誇大表現の禁止語が入っていないか、数字に出典と時点が添えてあるか、構成が規格を満たしているか。これを人の目ではなくスクリプトが毎回同じ基準で検査し、1つでも落ちれば公開に進めません。

数字については、claims-ledger（クレームズ・レジャー）という台帳運用も組み合わせています。中身は単純で、確認済みの数字だけを載せた台帳を作り、対外的な文書ではそこにある数字しか使わないというルールです。台帳に無い数字を使いたければ、先に確認して台帳に載せるしかない。この一方通行が数字の捏造を工程で止めます。

機械検査そのものの作り方は、別記事で仕組みごと公開しています。

関連記事AI記事作成の品質管理——公開前に自動で守る機械ゲートの作り方AIに記事を書かせたいが品質が心配で任せきれない。その答えは人力チェックの強化ではなく、公開前に自動で合否を判定する機械ゲートです。僕のブログ全記事が通っている検査項目の実物と作り方5ステップを公開します。→

ステップ3の「書かない」は実演済みです

「確認できない数字は使わない」を実際にやるとどうなるかは、MiniMax H3の記事が実例です。発表直後の動画生成AIを扱った記事で、僕はまだ実測していないという事実を冒頭に明示し、生成品質の感想を一切書かずに、ライセンス原文で確認できた事実だけで構成しました。書けることが減るように見えて、読者からの信頼と後日の検証可能性はむしろ上がります。

AIの出力をAIに疑わせる。敵対的ファクトチェックの回し方

「AIのファクトチェックの方法」を探している人に、僕が毎日回している答えを正面から書きます。結論は、書いたAIとは別のAIに、反証の役割を与えて疑わせることです。

書いた本人に「合ってる？」と聞いても意味がない

同じ会話の中でAIに「今の回答は正確ですか」と聞くと、高い確率で自己弁護が返ってきます。自分の出力との一貫性を保とうとするからです。だから検証は、文脈を共有していない別のAIに、最初から「疑う側」として仕事をさせます。

僕の運用では deep-verify という自作の検証の仕組みを使っています。中身は、主張ごとに根拠のURLを出させて、別のAIに反証させる仕組みです。原稿や調査結果から事実の主張を切り出し（僕の設定では1回の検証で最大16件）、主張1件ごとに「事実として正確か」「出典は信頼できるか」の2つの観点で反証を試みさせ、生き残った主張だけを使います。

今日から真似できる最小構成

自作ツールが無くても、チャットが2つ開ければ今日から同じ構造を作れます。書かせたAIとは別の新しいチャットに原稿を貼り、次の3つを順に指示するだけです。

• この文章に含まれる事実の主張を、数字・固有名詞・仕様・日付を中心にすべて列挙してください

• 主張ごとに、確認できる公式の情報源と確認方法を挙げてください。確認できないものは「未確認」と明記してください

• 未確認の主張を本文から削るか、未確認であると分かる書き方に直してください

ここで大事な線引きがあります。最後に公式サイトを開いて確認するのは人間の仕事です。AIのファクトチェックは、AIを信じるためではなく、人が確認すべき箇所を数件まで絞り込むために使います。全部を人が調べる運用には戻さず、確定の一手だけを人が握る。この分担なら検証は毎日回ります。

対策プロンプトとRAGの限界と使いどころ

ハルシネーション対策として検索されることが多いのが、対策プロンプトとRAGです。どちらも使っていますが、位置づけを間違えると事故のもとになります。

対策プロンプトは「発生率を下げる前段」

「わからない場合は、わからないと答えてください」「回答には出典を示してください」といった指示は、当てずっぽうの回答を減らす方向に働きます。入れる価値はあります。ただし限界も明確で、出典のURLごと、それらしく捏造されるケースがあります。プロンプトは生成側の努力目標であって、検証の代わりにはなりません。

僕の使い方は、検証ゲートの前段です。生成の段階で「確認できないことは書くな」と拘束しておくと、後段の検証で落ちる件数が減り、検証のコストが下がります。

RAGは「答えが資料にある業務」で効く

RAGとは、AIに手元の資料を読ませてから答えさせる方式のことです。社内規程や自社の料金表のように、正解が手元の資料に書いてある業務では、回答の根拠を資料に固定できるので有効です。

一方で、資料に無い質問をされれば結局は推測で埋めますし、資料そのものが古ければ、古い答えを堂々と返します。RAGを入れたから検証は不要、にはなりません。

よくある質問

まとめ。ハルシネーション対策はツールではなく運用

生成AIのハルシネーション対策を、この記事の順番でまとめます。

• 「注意して使う」は対策ではない。注意力は量に負ける

• 原因は仕組み・材料・指示の3つ。発生ゼロは目標にしない

• 目標は「検証を通ったものだけ使う」一方通行の工程を作ること

• 手順は5ステップ。主張の切り出し、一次情報の確認と時点明記、確認できない数字は使わない、機械検査、公開後24時間の人間レビュー

• ファクトチェックは別のAIに疑わせて絞り込み、確定だけ人がやる

• プロンプトとRAGは発生率を下げる前段。検証の代わりではない

最初の1工程は「確認できない数字は使わない」を全員のルールにすることからで十分です。事故が起きたら責めずに、その事故を検査項目に昇格させる。この育て方はAIの事故を再発させない仕組みの記事に書きました。