LLMハルシネーション対策の実務｜業務用AIで誤情報を防ぐ運用設計
ChatGPT、Microsoft Copilot、Google Gemini、Claudeといった業務用AIを日常的に使うようになって、多くの企業で**「もっともらしいが事実と違う回答」にぶつかった経験があるはずです。これがLLM（大規模言語モデル）の構造的な弱点であるハルシネーション（Hallucination）**です。
存在しない法律の条文番号を引用する、実在しない論文を出典として挙げる、書類の数字を微妙に違えて要約する、社内の同名別人を取り違える――これらはすべてハルシネーションの典型例です。
「ハルシネーションは技術が進めばなくなる」という期待がありますが、現時点では完全にはなくならない前提で運用設計をするのが現実的です。本記事では、業務AIのハルシネーションを最小化する4つの運用設計（RAG構成・引用必須化・確信度しきい値・人間レビュー）を整理します。
ハルシネーションの基本：なぜLLMは「もっともらしい嘘」を返すのか
LLMの動作原理から見たハルシネーションの必然性
LLMは「直前の文脈から次に来る単語を確率的に予測する」モデルです。事実検証の機構は内蔵されておらず、学習データの統計的傾向に従ってもっともらしい続きを生成します。
このため、LLMは以下のような状況で誤情報を出します。
- 学習データにない事項：訓練後に発生した事実、限定的な情報、社内独自の知識
- 学習データに揺らぎがある事項：同名の別人、似た製品名、似た条文
- 質問が曖昧：具体性の不足、推論を要する問い
- 「答えがない」と返すよりも回答することを優先する設計：多くのモデルが「分からない」と返すより、もっともらしい回答を生成する傾向
つまり、ハルシネーションは「賢くなれば消える」ものではなく、LLMが「分からない」を表現できない範囲で起き続ける現象です。
業務でハルシネーションが起こす被害
中小企業の現場で実際に起こりうる被害を挙げます。
- 法令解釈の誤りで対応漏れが発生（存在しない条文への準拠を信じる）
- 契約レビューで重要条項を見落とす（要約から条項が消える）
- 取引先情報を取り違える（同名の別会社の情報を答える）
- 数字の改ざんに気づかず提案書に貼り付ける（5,000円が500円になる）
- 過去の議事録を要約する際、決定事項が捏造される
これらの多くは**「結果を見ても気づかない」**性質を持ちます。回答が文法的に正しく、業務文脈に合致しているため、ファクトチェックなしに使うと誤りが流通します。
対策1：RAG構成で「答えの根拠」を限定する
RAGとは
RAG（Retrieval-Augmented Generation：検索拡張生成）は、LLMが回答を生成する前に特定のデータソースから関連情報を検索し、その情報を踏まえて回答する仕組みです。
LLM単独だと「モデルの記憶」だけから答えるため、社内情報には弱く、誤情報も混ざります。RAGなら社内のドキュメント、データベース、特定のWebサイトから取得した情報を回答の根拠にできます。
主要なRAGプラットフォーム
中小企業が利用しやすいRAG構成の主な選択肢です。
| プラットフォーム | 特徴 | データソース |
|---|---|---|
| Microsoft Copilot for M365 | M365データに対するRAG | SharePoint、OneDrive、Teams、Outlook |
| Copilot Studio | カスタムRAGエージェント | 任意のドキュメント、URL、API |
| Azure AI Foundry | エンタープライズRAG基盤 | Blob Storage、SQL、Cosmos DB等 |
| Google NotebookLM Plus | 指定ソースに対するQ&A | アップロードされた文書、URL |
| Google Vertex AI Agent Builder | カスタムRAGエージェント | Cloud Storage、BigQuery等 |
RAG導入時のポイント
- データソースを明確に限定：「会社の信頼できる情報源」だけをRAGの参照先にする
- データの更新頻度を管理：古い情報のままRAGに残らないよう定期更新
- 重複・矛盾の解消：同じ情報が複数のソースに違う形で存在すると、RAGも混乱する
- アクセス権限の継承：ユーザーが本来見られない情報をRAG経由で見せない権限設計
中小企業の場合、まずM365 CopilotならSharePoint・OneDriveの整理から、Google環境ならDriveの整理から始めるのが現実的です。RAGはゴミを入れればゴミが出てくるため、データの整備が前提条件になります。
対策2：引用と根拠リンクを必須化する
引用付き回答の重要性
ハルシネーション対策で最も効果的なのが、**「回答に必ず引用元を付ける」**運用です。引用がある回答は、ファクトチェックが圧倒的に容易になります。
- Copilot for M365：標準で参照したファイルへのリンクを表示
- NotebookLM：ソース内の該当箇所へのジャンプリンクを表示
- Perplexity：Web情報の引用リンクを表示
- Bing Chat / Copilot in Bing：参照URLを表示
- カスタムRAG：プロンプト設計で引用付き回答を強制
逆に、引用なしのChatGPT・Geminiの汎用回答は、業務利用では原則として裏取りが必要です。
引用を「効かせる」運用ルール
引用付き回答を効果的に使うには、以下の運用ルールが必要です。
- 業務判断に使う回答は、必ず引用元の原文を確認
- 引用箇所と回答内容の整合性をチェック（引用はあっても、内容が誇張・改変されていることがある）
- 複数ソースが矛盾する場合は元情報の優先順位を決めておく
- 引用がない回答は「参考情報」として扱い、外部に出さない
「引用があるから安心」ではなく、「引用があるからチェックできる」という整理が正確です。
対策3：確信度しきい値と「分からない」の許容
確信度に応じた回答の出し分け
LLMは内部的に「次の単語の確率」を計算しています。これを利用して、確信度が低い場合は**「分からない」と答えさせる**設計が可能です。
- API利用時：プロンプトに「根拠が不明な場合は『情報が不足しています』と回答してください」と明記
- 温度パラメータ（Temperature）の下げ：確率上位の単語のみ選ばせ、創造性を抑える（0.0〜0.3）
- RAGの「検索結果ゼロ件」の扱い：関連情報がない場合は推測せず、その旨を返す設計
- Guardrails系ツール：NVIDIA NeMo Guardrails、Guardrails AI、Azure AI Content Safety等で確信度の低い回答をフィルタ
「分からない」を許容する組織文化
ハルシネーション対策で見落とされがちなのが、**「AIが『分からない』と答えることを業務として許容する」**文化です。「何か回答してくれないと使い物にならない」という現場の声に押されて、Temperature を上げて何でも答えさせる運用になると、結局ハルシネーションが増えます。
「AIが分からないなら、人間が調べる」「AIが分からない領域は、別の情報源を当たる」という前提を組織で共有することが、安全な運用の基盤になります。
対策4：人間レビューの設計
レビューが必要なアウトプット
業務AIのアウトプットすべてにレビューを入れるのは現実的ではありません。リスクと用途に応じてレビュー要否を決める設計が必要です。
| 用途 | リスク | レビュー要否 |
|---|---|---|
| 個人メモ・アイデア出し | 低 | 不要 |
| 社内向けドラフト・要約 | 中 | 利用者が確認 |
| 外部送信文書（メール・提案書） | 高 | 上長または専門家レビュー |
| 法的判断・契約解釈 | 最高 | 必ず法務・弁護士レビュー |
| 数値の引用 | 中〜高 | 必ず原典確認 |
| 公開コンテンツ（Web、SNS） | 高 | 編集者レビュー |
レビューの実装方法
- ワークフローツール：Power Automate / Apps Scriptでアウトプットを承認フローに乗せる
- ペアレビュー：AIを使った業務は、必ず本人＋もう1人がチェックする
- チェックリスト化：「数値」「固有名詞」「日付」「条文番号」は必ず原典確認、を明示
- 抜き取り監査：高リスク業務は定期的にサンプル監査
業務シナリオ別の推奨アプローチ
議事録の自動要約
- RAG：Copilot for Teams / Geminiでの議事録要約は、元動画・元トランスクリプトに必ずリンク
- 引用：要約の各項目に、議事録のどこからの記述かを明示
- レビュー：会議の進行役またはオーガナイザーが確認後、共有
- 確信度：要約のうち「決定事項」だけは特に厳格にレビュー（誤った決定の流通を防ぐ）
法令・規程の調査
- RAG：NotebookLMやCopilot Studioに条文・規程を直接ソースとして登録
- 引用：条文番号と該当箇所のリンクを必須に
- レビュー：重要な解釈は必ず法務担当または弁護士に確認
- 確信度：「該当条文が見つからない場合は『該当なし』と返す」プロンプト設計
顧客対応文書のドラフト
- RAG：過去の対応事例・FAQをRAG基盤に
- 引用：似た事例の引用を明示
- レビュー：外部送信前に上長または営業担当が確認
- 確信度：固有名詞・金額・期限はAIに書かせず、人間が入力する運用にする
中小企業のためのチェックリスト
業務AIのハルシネーション対策として、最低限実施すべき項目を整理します。
設計時
- AIに業務を任せる範囲を定義しているか
- 高リスク業務（金銭・法的判断・公開コンテンツ）には人間レビューを必須化しているか
- RAGの参照範囲・データ更新ルールが定まっているか
- 「分からない」と答えさせる仕組みがあるか
運用時
- 業務利用のアウトプットは必ず引用元を確認する運用か
- 数値・固有名詞・日付は必ず原典確認のルールがあるか
- AIのアウトプットをそのまま社外に出さないルールがあるか
- ハルシネーションが見つかった場合の報告窓口があるか
教育・周知
- 社員にハルシネーションの存在と典型パターンを共有しているか
- 「AIが間違える前提」での業務設計を説明しているか
- 業務領域ごとのAI利用ルールが明文化されているか
ハルシネーションを見抜くコツ
最後に、現場で「これはハルシネーションかも」と気づくためのチェックポイントを挙げます。
- 数字が「キリの良い数値」になっている：実データはキリの良い数字が少ない
- 法令・規格の条文番号が古いまたは存在しない：信頼ソースで条文確認
- 固有名詞が微妙に違う：「○○株式会社」と「株式会社○○」、「コーポレーション」と「カンパニー」
- 言い回しが過度に断定的：「必ず」「絶対に」「決して」などの強い断定はLLMが過信している可能性
- 引用が抽象的：「公式ガイドラインによると」だけで具体的なURL・ページ番号がない
- 複数モデルで聞くと回答が変わる：CopilotとGeminiで同じ質問をして矛盾する場合は要注意
まとめ
LLMのハルシネーションは、業務AIを使う以上**「ゼロにはできない」前提で運用設計をする**ものです。技術の進化を待つのではなく、現時点で取れる対策を組み合わせて、許容できるレベルまでリスクを下げます。
中小企業が押さえるべき4つの対策は次のとおりです。
- RAG構成：信頼できるデータソースに参照範囲を絞る
- 引用必須化：根拠リンクを必ず付け、ファクトチェック可能にする
- 確信度しきい値：「分からない」を組織として許容する
- 人間レビュー：リスクに応じて承認・抜き取り監査を設計する
情シス365では、Copilot・Gemini・ChatGPTを業務利用する企業向けに、ハルシネーション対策を含むAI運用設計をご支援しています。「AIを使い始めたが、ファクトチェックの運用が定まっていない」「過去にAIの誤回答で困った経験がある」といったご相談があれば、お気軽にお問い合わせください。