生成AIに社内の稟議手順を尋ねると、整ったフローが5ステップで返ってきます。中身を確認すると、3番目と4番目の工程は社内規程に存在しませんでした。事実でない情報を、事実であるかのように生成するこの現象がハルシネーションです。
CSの一次回答に使えば、存在しない返金条件を顧客へ伝えてしまいます。社内利用でも誤った情報が稟議の判断材料に混ざり、決まった内容を事後説明できなくなります。
ハルシネーションをモデルの性能不足で片づけられる問題ではありません。発生の型を分類したうえで、出典管理・RAG・参照限定・レビュー承認・監視の5層で対策を重ねる必要があります。1層だけでも不十分で、前の層が次の層を成立させる前提条件になります。
本ガイドでは、4つの型と5つの発生原因を整理し、5層対策それぞれの実装手順、回答別の承認レベル、監視すべき指標、90日導入ロードマップまで実務でそのまま使える形でまとめます。
生成AIのハルシネーションとは｜4つの型と発生条件
生成AIのハルシネーションとは、モデルが学習済みのデータにない情報を推測で補完し、事実として断定して出力する現象を指します。出力の形式は完全に整っているため、表面上は正しい回答と区別がつかず、読む側の確認待ちという形になります。
発生の型は4つに分かれます。型が分かると、対策も的を定めやすくなります。
| 型 | 典型例 | 見えやすさ | 危険度 |
|---|---|---|---|
| 捏造型 | 存在しない社内規程を「規定通り」と断定して示す | 低い。形式が正しいため発見しにくい | 高 |
| 混同型 | 旧版の規程と新版を混ぜて1つの説明にまとめる | 中。どちらの版か記されない | 高 |
| 断定型 | 根拠を示さないまま数値・日付・社名を断定 | 中。例外規定ではない | 中 |
| 過剰型 | 断定できない偶発事象まで確実と表現する | やや高い | 中 |
5つの発生原因
ハルシネーションの原因は次の5つに分解できます。
- 参照先が存在しない：正しい社内文書がAIの検索範囲に入っていない
- 質問が曖昧：前提が示されず、もっともらしい仮定で補完される
- 出典を提示しない設計：生成した文章に参照リンクが付かない
- 検証の工程がない：確認する手順が規程にない
- 権限の混同：本来アクセスできない情報が文脈に混入している
5つのうち参照先と出典の2つが欠けた状態では、残りの対策も機能しません。根拠のない回答に承認を付けても、承認者は何を確認すべきか判断できません。
5層対策の全体像｜出典管理から監視まで
対策は5層で積み上げる前提で設計します。どれか1層を他で代替することはできません。前の層が次の層を成立させる前提条件になっているからです。
| 層 | 主な操作 | 塞ぐ綻び |
|---|---|---|
| ①出典管理 | 参照元の文書名・版・該当箇所を回答に紐づけ | 根拠不明の断定 |
| ②RAG | 社内文書を検索して根拠として渡す | 知識の空白 |
| ③参照限定 | 対象を部門・文書種別・期間で固定 | 対象外情報の混入 |
| ④レビュー承認 | 回答を用途別の承認工程へ載せる | 未確認のまま社外に出る |
| ⑤監視 | ログから誤回答の傾向を可視化 | 同じ誤りが繰り返される |
①と②は誤った回答の生成を減らし、③と④は外へ出る前に止め、⑤は再発に気づけるようにします。役割を分けて担当を決めると、対策設計が具体的になります。参照元の整備は情報管理部門、承認フローは業務部門、監視はIT部門が担う、という切り分けです。
対策①｜出典管理で根拠を必ず残す
出典として残す情報は3つです。文書名だけでは版が分からず、ページ番号だけでは文書が特定できません。
- 参照した文書名：正式名称と格納パス
- 版の識別：更新日または版番号
- 該当箇所：ページ、セクション名、見出し
運用の定め方は1つで足ります。「出典を提示できない回答は、社内判断の材料にしない」。回答の末尾に参照文書と該当箇所を列挙する指示は、固定ルールとしてプロンプト側に置きます。利用者ごとに指示を変える運用は、いつのまにか放置され、初期値へ戻っていきます。
出典は「開けること」が条件です。リンク先が存在しない、または本文に該当箇所が見つからない回答は、引用とは数えません。社内ナレッジの整備方法については生成AI ナレッジベースとは？社内知識を即座に検索・活用する次世代システムで解説しています。
対策②｜RAGで社内データを根拠として渡す
RAG（検索拡張生成）とは、社内のナレッジベースを検索し、根拠となる文書だけをモデルに渡して回答させる手法です。発生原因の1つ目「参照先が存在しない」を直接に解きます。
実装は4工程です。
- 分割：意味のまとまり（見出し単位）で文書を分割する。表を条件ごと切り離すと、前提条件が失われます
- 埋め込みと検索：略語・固有名詞・略号を検索語に反映させる
- 根拠の選定：質問に近い文書を複数選び、上位数件を回答に渡す
- 回答生成：渡した根拠だけを根拠に文章を組み立て、引用を必ず添える
RAGを入れても「誤った文書を引く」ことで別の誤りを作ります。古い版と新しい版が両方登録されていると、誤った版が引かれる確率が上がります。版管理は公開前の前提条件です。
精度設計のポイントは検索の精度と分割の粒度にあります。詳しくはRAGとは？検索精度を3倍にする仕組みと企業導入5ステップで解説しています。
対策③｜参照限定で回答の範囲を固定する
「答えられない質問」に答えないための設定です。参照範囲が全社に広がっていると、モデルは空欄を埋めるために推測します。
範囲は3軸で固定します。
- 組織：部門・チーム単位で対象を絞る
- 文書種別：規程、契約書、技術文書など、種別ごとに含める／含めないを決める
- 期間：最新N版のみを対象にする
範囲外の質問には、推測で答えさせず「社内規程に該当する記載が見つかりません」と返す指示を入れます。この1文を入れていない場合、モデルは「たぶんこの辺だろう」と埋めます。最新版のみを既定にすると、改定直後の混乱も減らせます。
参照範囲は権限と連動させます。役割に応じて見える範囲が変わる設計にしておくと、限定の範囲がそのままアクセス制御になります。
対策④｜レビュー承認で誤回答を社外へ出す前に止める
承認の要否は「答えの用途」で決めます。すべての回答に承認を付けると、承認自体が形骸化します。
| 用途 | 承認レベル | 確認する内容 |
|---|---|---|
| 社内の草案 | 作成者本人の自己確認 | 出典リンクが開き、該当箇所が本文にあるか |
| 社内共有の資料 | 直属上司の確認 | 固有名詞・数値の整合 |
| 顧客向けの回答 | 担当者と管理者の2段 | 引用した条件の原文一致 |
| 法務・財務に関わる回答 | 専門部門の判断 | 適用の可否と例外の有無 |
承認画面では原文と要約を並べます。原文を隠すと、承認者は何を確認すべきか判断できません。差し戻しにも却下にも理由を残すと、どの業務で誤りが多いかを後から分析できます。承認フローの組み立て方はグループウェア ワークフローとは？連携メリット・構築方法・AI活用で承認業務を効率化が参考になります。
対策⑤｜監視でハルシネーションの傾向を可視化する
監視は誤回答を抑止するためだけではありません。対策が効いているかどうかを数値で判断するための仕組みです。
| 監視指標 | 確認頻度 | 読み方の目安 |
|---|---|---|
| 出典なしの回答比率 | 週次 | 5%を超えると参照範囲や指示文を見直す |
| 承認での差し戻し率 | 月次 | 10%を超えると対象業務や教育を見直す |
| 同じ質問への回答のばらつき | 月次 | 大きいほど固定のナレッジが必要 |
| 参照リンクの到達率 | 月次 | 低い場合はナレッジ側の更新漏れ |
ログに残す項目は、質問・参照文書・生成回答・承認者・最終採用版の5つです。事後に「いつ誤った情報が社外へ出たか」を追えることが監視の目的です。生成AI全体のリスク整理は生成AI セキュリティの完全ガイド｜企業が押さえるべき5つのリスクと対策にまとめてあります。
5層対策を入れる順序｜90日ロードマップ
最初から5層すべてを入れようとすると、導入が終わりません。順番は次の3段階が現実的です。
STEP1（1〜30日）｜参照範囲と禁止事項を決める
回答させない対象を明記します。部門、文書種別、期間をそれぞれ定めます。参照できない場合は「該当なし」と返す指示を入れます。推測させないことが、この段階の到達点です。
STEP2（31〜60日）｜出典とRAGを仕込む
社内の正式な文書（規程、手順書、マニュアル）を1か所にまとめ、RAGで参照できるようにします。ここで初めて出典付きの回答が可能になります。
STEP3（61〜90日）｜承認と監視を制度化
回答の用途別に承認ルートを分け、ログを保存し、週次で出典なしの回答比率を確認します。ここまでで、誤回答は出ても社外へは出ない状態になります。
GBase Knowledgeなら、この課題を解決できます
製品の詳細や導入条件はGBase Knowledgeのサイトで確認できます。社内規程の作り方は企業向け生成AIガイドライン策定マニュアル｜リスク管理と活用促進の両立が骨組みを示しています。
よくある質問
Q1: ハルシネーションはゼロにできますか。
ゼロにはなりません。根拠を渡して回答させる方式に変えることで、根拠と回答の矛盾は大幅に減らせます。重要な回答は、承認者が原文を開いて確認する運用を前提に設計してください。完璧な精度を待つのではなく、誤った内容が出る確率を下げ、出たときに止められる仕組みを優先します。
Q2: RAGを入れても誤回答は出ますか。
出ます。RAGは「社内文書に根拠があれば正しく答えられる」という前提を扱える方式ですが、文書が古い、版が混在している、質問の表現が文書と離れている、判断が専門知識に依存する — こうした場合は依然として誤りが出ます。ナレッジの更新と引用確認はセットで行います。
Q3: 出典を表示させるだけで十分ですか。
表示できることと、表示された出典が正しいことは別問題です。リンク先が開いても、その記載が質問の前提と一致しているかは人が判断する必要があります。引用の関連性と版の確認までは自動化し、人は最終判断に集中する運用にしてください。
Q4: 小さなチームでも5層すべてが必要ですか。
全部を同じ厚さで揃える必要はありません。参照範囲の限定と出典の表示だけでも、誤回答の被害は大幅に減ります。承認と監視は、利用者が50名を超えてから段階的に厚くするのが現実的です。
Q5: 社外の生成AIサービスを使っていても同じ対策はできますか。
対策の中身は同じです。ただしログの保存と権限制御を、サービス提供側ではなく社内の仕組みとして持てるかどうかが変わります。社内で完結する構成にすることで、実行の記録と権限制御を自分の手で管理できます。ネットワーク分離が求められる場合は、オンプレミス型の運用も選択肢になります。
