業務AIシステムを本番運用すると、必ず直面する課題がある——ハルシネーション（もっともらしい嘘の生成）である。国内の505名対象の調査では、35.2%の企業がハルシネーションを課題として挙げており、これはセキュリティリスク（42.2%）に次ぐ第2位の重要課題 となっている。注目すべきは、この数字が「導入できない理由」ではなく「導入してみて困っている理由」だという点だ。PoCを抜けて本番化した企業ほど、ハルシネーションが運用上の最大の壁として立ち上がってくる。スタンフォード大学の研究では、RAG技術を採用した法律系AIツール（Lexis+ AI、Ask Practical Law AI、ウェストロー）でさえ、調査対象質問の 17〜33%でハルシネーション を示したと報告されている。法律という、出典の正確さが商品価値そのものである領域で、専用設計されたツールがこの水準だという事実は重い。
ここから導かれる結論はひとつである。RAGを使えばハルシネーションが消える、という単純な期待は現実と乖離する。RAGは事実誤りを「減らす」技術であって「ゼロにする」技術ではない。本稿では、ハルシネーション対策を技術と運用の両面から整理し、業務AIで「もっともらしい嘘」を許容しない設計論を提示する。鍵になるのは、単一の万能策を探すのではなく、性質の異なる対策を重ねて漏れを塞ぐという発想だ。
業務AI実装の全体論はAIエージェント業務導入の設計論、RAGの基礎はRAGとはを併せて参照されたい。
ハルシネーションは一種類ではない — 種類によって効く対策が違う
「ハルシネーション」と一括りに語られがちだが、現場で起きる誤りは発生源が異なり、それぞれ効く対策も違う。一括りに「精度が悪い」と扱うと、効かない対策に投資して空回りする。対策設計の出発点は、まず自分のシステムでどの種類が出ているかを見分けることにある。
最も典型的なのが事実誤りである。LLMが学習した知識そのものが間違っている、あるいは知らない事柄を埋めてしまうケースだ。たとえば「日本の初代総理大臣は西郷隆盛だ」と返す（正しくは伊藤博文）、存在しない発表年を断言する、引用元の論文を丸ごと捏造する——こうした誤りがこれに当たる。発生源が「モデルの知識」にあるため、後述するRAGや出典検証で外部の正解を参照させる対策が比較的素直に効く。
次に厄介なのが推論誤りである。前提となる事実は正しく握っているのに、それらを組み合わせる過程で結論を踏み外す。計算の途中式は合っているのに最終値だけ違う、複数の条文を解釈する際に組み合わせを誤って逆の結論を導く、といった形で現れる。知識が正しいぶん出力はもっともらしく、人間のレビュアーも見落としやすい。Chain of Thought（CoT、AI技術用語統合ガイド参照）で推論過程を開示させる、あるいはo1やClaude Extended Thinkingのような推論特化モデルを使うと改善するが、これも完全には消えない。
三つ目が文脈逸脱で、RAGアプリで最も頻出する。検索で渡した社内文書を無視し、モデルが「もともと知っている」一般論で答えてしまう、あるいは聞かれてもいない補足を勝手に足す。RAGを入れた直後に「ちゃんと資料を見ていない回答」が混じるのはこのパターンであり、検索の精度ではなくプロンプト設計とガードレールで対処する性質のものだ。同じ「ハルシネーション」でも、事実誤りはRAGで、推論誤りは推論プロセスの開示で、文脈逸脱はプロンプトと出力検証で——というように処方箋が分かれることを押さえておきたい。
なぜ完全には消せないのか — 確率モデルという土台
対策を語る前に、なぜゼロにできないのかを構造から理解しておく必要がある。これを飛ばすと「いつか技術が解決する」という前提で運用設計を怠り、事故に至る。
LLMは本質的に「次に来る単語の確率」を計算して文を組み立てる装置である。この仕組み上、確率の低い正解よりも、確率の高い「もっともらしい誤答」を選びやすい。流暢で自信ありげな文章ほど誤っていることがある、というのはここに由来する。加えて、学習データに存在しない情報については、近い知識から推測で埋めるしかなく、「該当データがない」という状態と「自信を持って答えられる」という状態をモデル自身が明確に区別できない。さらに、人間のフィードバックで学習する過程で「役に立つ回答を返す」ことが強く報われる一方、「分かりません」と答えることへの学習は相対的に弱い。沈黙より誤答のほうが選ばれやすい構造的バイアスがある。
これらは新しいモデルで着実に軽減されているが、確率生成という土台がある限りゼロにはならない。したがって実務的に正しい構えは、「ハルシネーションは発生するもの」という前提で運用を設計することだ。発生を異常事態ではなく既定値として扱い、検知と回復の仕組みを先に用意する。この発想の転換が、後述するすべての層の前提になる。
多層防御という設計思想 — 層が互いを補い合う
単一の手法でハルシネーションを抑え込もうとすると、必ず取りこぼしが出る。前節で見たとおり誤りの発生源が複数あるからだ。そこで有効なのが、性質の異なる対策を重ねて、ある層が見逃した誤りを次の層が捕まえる多層防御である。本稿では、これをモデル・プロンプト・RAG・ガードレール・評価・運用という6つの層として整理する。重要なのは順番ではなく、上流の層ほど誤りの「発生を減らし」、下流の層ほど発生した誤りの「流出を止める」という役割分担だ。
最初の土台はモデルの選定にある。事実忠実性の高いLLMを選ぶことは、最も地味だが効果の大きい対策だ。GPT-5、Claude Opus 4以上、Gemini 2.5といったフラッグシップ級は、小型モデル（おおむね10B程度まで）と比べてハルシネーション率が低い傾向にある（ただしタスクやベンチマークによって差は大きく、銘柄名だけで判断しないこと）。推論誤りに対しては、o1やo3、Claude Extended Thinkingといった推論特化モデルが耐性を持つ。実務での定石は、まず強いモデルで精度の天井を確認し、その後にコスト最適化として小型化を検討する順序だ。最初から安いモデルで始めると、出ている誤りがモデルの限界なのか設計の不備なのか切り分けられなくなる。技術選定の詳細はFine-tuning vs RAG、業務AIインフラの技術選定を参照されたい。
次の層がプロンプトである。ここで効くのは、見栄えのする凝った指示ではなく、「答えられないときの振る舞い」を明示することだ。多くの文脈逸脱は、モデルに「資料になければ答えなくてよい」という退路を与えるだけで抑えられる。
あなたは社内のIT担当者として回答してください。
提供された資料から答えられる質問のみに回答してください。
資料に書かれていない内容については「資料に該当する情報がありません」と回答してください。
推測や一般知識での回答は行わないでください。
このプロンプトの肝は、最後の二行で「不知を許容し、推測を禁じる」点にある。人間は無意識に「役立とう」とするモデルの性質を放置しがちだが、ここを明文化するだけで沈黙より誤答を選ぶバイアスを部分的に打ち消せる。あわせて、回答に「参照した資料のセクション番号と該当ページを必ず明記する」よう求めると、出典を書けない＝資料にない内容を、モデル自身が出力しにくくなる。出典の明示は読み手の検証コストを下げるだけでなく、生成そのものを律する効果を持つ。推論誤りに対しては「最終的な答えを出す前に判断の根拠を順を追って示す」よう促し、途中の論理を可視化させることで誤りを早期に発見できる。いずれも一行二行の追加だが、効くのは文言の派手さではなく「どの種類の誤りを狙って書いているか」の解像度である。
その上に乗るのがRAGだ。文書をベクトル化し、質問との類似度で検索した結果をモデルに渡すことで、一般知識ではなく指定文書に基づいた回答へ誘導する。これだけで事実誤りは大きく減るが、繰り返すとおり17〜33%程度は残る。残りを詰めるために、2024年から2025年にかけてRAG自体を高度化する研究が進んだ。Google Cloud AI ResearchとUSCの研究者が2024年10月に提案したAstute RAGは、LLMの内部知識と外部知識を突き合わせ、検索結果の質が低いときでも破綻しにくくする。Self-RAGは、モデルが「リフレクショントークン」を生成して各ステップで自己評価しながら出力する。検索の前段では、質問から仮想的な理想回答を生成してそれで検索するHyDEが検索精度を底上げし、検索の後段では、初期結果を別モデルで並べ替えるRe-rankingが関連性の高い文書を上位に押し上げる。これらは実装の複雑さと引き換えに精度を稼ぐ手段であり、業務で高い正確性が求められる場合に段階的に導入する。RAGの一形態として、Web検索やAPIで最新情報を取得してから答えるグラウンディングもあり、Google Geminiの Grounding with Google Search やBing Search統合が代表例だ。
ここまでの三層は「誤りの発生を減らす」層だった。残りの三層は「発生した誤りの流出を止める」役割を担う。
流出を止める三層 — ガードレール・評価・運用
発生を減らす努力には限界がある以上、出てしまった誤りを業務に流さない仕組みが要る。ここからの三層は、上流をすり抜けた誤りに対する最後の関所として働く。
ガードレール層は、LLMの入出力を別の仕組みで検証する。入力側ではプロンプトインジェクションや、個人情報・機密・有害な質問の混入を検出する。出力側では、別モデルによる事実性チェック、不適切な内容のブロック、JSONなど構造化フォーマットの強制、機密情報の漏洩防止を行う。実務では、強いモデルで生成し、別の検証モデルで出力を点検し、運用ルールで最終的に弾く、という3層ガードレールの発想で、業務上許容できない出力を多段に止めるのが有効だ。代表的な実装には、NVIDIAのオープンソース実装でルールベースのNeMo Guardrails、バリデーションに特化したGuardrails AI、構造化出力やエラーハンドリングを内蔵するLangChain / LangGraphがある。どれを選ぶにせよ、ガードレールは「生成器とは独立した第三者」であることが要点で、同じモデルに自己採点させるだけでは見逃しが残る。
評価層は、実運用で発生する誤りを継続的に検知・分析する。後付けにすると運用初期の事故を取り逃すため、最初から組み込む層だ。自動評価では、より強いLLMで出力品質を採点するLLM-as-Judgeや、サンプリングによるハルシネーション率の定点観測を行う。各LLMの事実忠実性を比較したリーダーボードや、要約タスクのハルシネーション率を測る評価モデルも整いつつあり、本番投入前に自社ユースケースで通しておくとモデル選定の根拠になる。ただし自動評価だけでは拾えない誤りがあるため、ランダムサンプリングでの人手チェック、利用者からの良し悪し評価の収集、月次・四半期の品質レビューを組み合わせる。自動と人手は代替ではなく補完の関係にある。評価層の実装の詳細はAI評価フレームの実装論近日公開で扱う。
最後の運用層は、技術で防ぎきれない部分を人間とプロセスで受け止める。中核はHuman-in-the-Loop（HITL）で、AIの出力を人間が確認してから業務に使う、あるいは信頼度スコアに応じて高信頼は自動・低信頼は人間確認へ振り分ける。モデルが「分からない」と判定したケースや、異常パターンを検知したケースは担当者へエスカレーションする設計を組む。そして、誤りに起因するトラブルが起きたときに備え、検知から報告までの流れ、影響範囲の特定（誰がいつ何を見たか）、必要に応じた顧客通知や規制当局への報告、再発防止までの一連のインシデント対応を平時に定めておく。ここを整備しないと、後述するように「誤りを隠す」文化が生まれ、改善ループが止まる。運用・ガバナンスの全体像は企業のAIガバナンス実務ガイドで詳述している。
業務別の許容度 — ゼロ許容を全業務に求めない
6層をすべての業務に等しく適用するのは、過剰投資であり同時に過小投資でもある。業務によって、許容できる誤りの水準はまったく違うからだ。アイデア出しの誤りは創発の余地になり得るが、財務処理の誤りは即座に事故になる。設計判断の出発点は、業務ごとに「どこまでなら許せるか」を先に決めることにある。
| 業務 | 許容度 | 必要な対策層 |
|---|---|---|
| アイデア出し・ブレスト | 高 | 層1〜2のみで十分 |
| 文書ドラフト作成 | 中 | 層1〜3、人間レビュー必須 |
| 社内ナレッジ検索 | 中 | 層1〜4、出典表示 |
| 顧客向け回答（CS） | 低 | 全6層、HITL必須 |
| 法務契約レビュー | 極低 | 全6層、人間最終決定 |
| 医療判断補助 | 極低 | 全6層、医師の最終決定 |
| 財務・経理処理 | 極低 | 全6層、監査トレース |
この表が示すのは、対策の量を業務の重要度に比例させるという単純な原則だ。低リスク業務に全6層を被せれば応答は遅く高コストになり、現場は使わなくなる。逆に高リスク業務を浅い対策で回せば、一度の誤りが信用や法的責任に直結する。過剰は無駄、不足は事故という非対称な構造を理解した上で、業務ごとに必要な層だけを選ぶ。
ここはAX Boostが重視する「引き算の見極め」と地続きでもある。ハルシネーション対策は手数を増やすほど安全に見えるが、実際には許容度の高い業務まで重武装させると、AI活用そのものが現場で形骸化する。どの業務にどこまで対策を入れ、どの業務はあえて軽く回して人の判断を残すか——この線引きは、空いた工数を価値ある仕事へ振り向ける「足し算より引き算→再配置」の考え方そのものである。
段階的に積み上げる — 一度に完璧を狙わない
対策は、最初からフルスペックで作り込むものではない。低リスク業務なら最小構成で運用を始め、リスクと利用範囲の拡大に合わせて層を足していくのが現実的だ。逆に高リスク業務は、運用開始の時点で運用層まで設計してから本番に出す。同じ6層でも、業務によって「どこまで積むか」が変わる。
立ち上げ段階でまず固めるのは、強めのモデル選定、プロンプトでの不知の許容、そして全出力の構造化ログである。とりわけログは地味だが、後から評価層を作るときの素材になるため、初日から残しておく価値がある。利用が広がってきたら、業務文書を対象にRAG基盤を構築し、出典明示を徹底し、検索精度を継続的に測る。次に、入力側のプロンプトインジェクション検出と、出力側の事実性・形式・機密チェックを担うガードレールを差し込み、許容外の出力を弾けるようにする。そのうえで、LLM-as-Judgeによる自動評価と人手サンプリングを回す評価基盤を整え、最後にHITLワークフローとインシデント対応プロセス、規程・監査体制を敷いて運用へ載せる。
順序として大切なのは、評価とログを「後付け」にしないことだ。動いてから測ろうとすると、運用初期に最も起きやすい事故をまさに検知できない期間を作ってしまう。発生を前提に設計するという本稿の構えは、ここで具体的な実装順序として効いてくる。
つまずきやすい落とし穴
最後に、現場で繰り返し見られる失敗を、原因とともに整理しておく。いずれも「対策を入れたこと」自体が安心材料になり、検証が止まる点で共通している。
最も多いのが「RAGを入れたから大丈夫」という思い込みだ。スタンフォード研究が示すとおり、RAG採用後も17〜33%は残る。RAGは多層防御の一層であって完成形ではない、という前提を共有できていないと、残った誤りが放置される。次に多いのが評価基盤の後付けで、「動いてから測る」発想は運用初期の事故を構造的に見逃す。初期から自動評価と人手サンプリングを組み込むことでしか、この穴は塞げない。
設計面では、業務全体に同じ対策を一律適用してしまう誤りが目立つ。低リスク業務には過剰、高リスク業務には不足という偏りが同時に起きるため、前節の許容度設計が欠かせない。組織文化の面では、ハルシネーションの発生を「失敗」として隠す姿勢が改善を止める。誤りは必ず出るものとして検知・報告・対応のループに乗せなければ、対策は更新されない。そして経営判断としては、モデル選定をコスト最優先で決めるのも典型的なつまずきだ。安いモデルでハルシネーション率が上がれば、それを補う追加対策のコストで結局は高くつく。まず強いモデルで精度を確保し、そのうえで最適化する順序が、長期では安く付く。
業務で「もっともらしい嘘」を許容しない設計へ
業務AIのハルシネーション対策が目指すべきは、「完全に消す」ことではなく**「業務で許容可能な水準まで下げる」**ことである。確率生成という土台がある以上ゼロは望めないが、発生を減らす三層（モデル・プロンプト・RAG）と、流出を止める三層（ガードレール・評価・運用）を業務特性に応じて組み合わせれば、業務上許容できない誤りを実用的な水準まで抑え込める。重要なのは層の数ではなく、どの業務にどの層を、どの順序で積むかという設計判断だ。
AX Boostでは、業務AIのハルシネーション対策をFDE型コンサルティングで支援している。どの業務に過剰な武装を外し、どの業務に多層防御を寄せるかという許容度の見極めから、ガードレール・評価基盤の実装、運用への定着まで一貫して伴走する。技術の導入で終わらせず、現場で誤りが出ても回り続ける仕組みにするところまでを射程に置く。具体的な進め方はFDE型コンサルティング完全解説を参照されたい。
関連記事: