▼ この記事の内容
ハルシネーション防止プロンプトは、回答範囲を根拠資料に限定し、不明時は推測せず保留させる設計が基本です。完全防止ではなく、出典提示、人の確認、承認済みナレッジの更新運用まで組み合わせて、業務で使う範囲を判断します。
生成AIを社内FAQや問い合わせ対応に使うときは、回答の便利さよりも根拠確認の設計が重要です。誤回答率だけでなく、根拠提示率、不明時保留率、有人移管率まで見ると、業務利用の判断がしやすくなります。
プロンプト例を入れても、参照元が古いままでは誤回答は残ります。顧客対応や社内規程の案内で未確認情報が混ざると、担当者が正しい回答として転記してしまう恐れがあります。
この記事では、ハルシネーション防止プロンプトを根拠限定、不明時保留、出典提示、推測禁止に分けて整理します。コピペできる文言に加え、業務利用前に確認すべきナレッジ運用の論点まで判断できます。 生成AIの誤回答リスクを業務改善の論点として整理したい方は、まず営業組織の課題整理に使える資料をご確認ください。
商談数を変えずに成約率2.7倍。営業マネージャーが見るべきポイントを、10項目をチェックリスト付きで解説！
＞＞無料で『チームの数字が動かない営業マネージャーが陥る3つの罠』をダウンロードする
ハルシネーション防止プロンプトの基本形
ハルシネーション防止プロンプトは、回答範囲を根拠資料に限定し、不明時は推測せず保留させる指示です。出典提示と推測禁止を分けて書くと、業務利用時の確認漏れを減らしやすくなります。
回答範囲を根拠資料内に限定する
ハルシネーション防止プロンプトの基本は、AIの回答範囲を承認済み資料だけに限定することです。対象資料名と参照範囲を先に書くと、一般論の混入を抑えやすくなります。
社内FAQや問い合わせ対応では、AIが正しそうな表現で未確認情報を補う場面があります。根拠資料を限定しない依頼では、古い記憶や一般知識が回答に混ざる可能性があります。
最初に入れる文は、次のように単純で十分です。入力された社内ナレッジと添付資料だけを根拠に回答し、資料内に根拠がない内容は回答しないでください。
AI活用のリスク管理では、回答の便利さだけでなく、根拠確認と人の判断を組み合わせる視点が必要です。NISTのAIリスク管理フレームワークも、AIのリスクを特定し管理する考え方を示しています。
参考：AI Risk Management Framework｜NIST
運用へ落とし込む際は、開始条件、確認担当、利用する記録を一つずつ決めますが、判断の前提を文書化しておくと、担当者が変わっても同じ基準で見直しやすくなります。結果は、担当者、期限、会議で見る指標に結び付けます。次回会議で更新状況と未対応理由を確認すると、改善を継続しやすくなります。
不明な内容は回答を保留させる
不明時保留は、AIに無理な回答を作らせないための条件指定です。根拠がない場合は分かりませんと返すだけでなく、何を確認すべきかまで出させます。
顧客対応や社内規程の案内では、曖昧な回答がそのまま業務判断に使われる恐れがあります。担当者が急いでいる場面ほど、AIの断定文を確認済み情報と誤認しやすくなります。
保留条件は、資料内に該当箇所がない場合、更新日が確認できない場合、部署ごとの権限が不明な場合に分けます。保留時は確認先と不足情報を併記させると、実務に戻しやすくなります。
緊急対応では、AIが保留するだけでは業務が止まる場合があります。その場合は、有人確認へ戻す窓口や責任者をプロンプト外の運用ルールで決めておく必要があります。
運用へ落とし込む際は、開始条件、確認担当、利用する記録を一つずつ決めますが、判断の前提を文書化しておくと、担当者が変わっても同じ基準で見直しやすくなります。結果は、担当者、期限、会議で見る指標に結び付けます。次回会議で更新状況と未対応理由を確認すると、改善を継続しやすくなります。
出典提示と推測禁止を分けて指示する
出典提示と推測禁止は、別々の指示として書く必要があります。出典を出す指示だけでは、AIが誤った根拠をそれらしく結び付ける可能性があります。
出典提示は、回答を後から検証しやすくするための指示です。一方で推測禁止は、根拠が足りないときに回答を作らせないための制御です。
具体的には、回答ごとに根拠資料名と該当箇所を示すよう指定します。そのうえで、根拠資料から直接確認できない内容は推測せず、確認対象として保留するよう指定します。
ハルシネーションの基本的な意味を整理したい場合は、AIの誤回答が起きる仕組みを先に確認すると、出典提示と推測禁止の違いを理解しやすくなります。
営業AI・営業DX AIハルシネーションとは？原因と企業利用での対策
出典自体が古い、または承認前の資料である場合は、推測禁止だけでは防ぎきれません。次の段階では、用途別に使えるプロンプト例へ落とし込みます。
運用へ落とし込む際は、開始条件、確認担当、利用する記録を一つずつ決めます。判断の前提を文書化しておくと、担当者が変わっても同じ基準で見直しやすくなります。
すぐ使える防止プロンプト例
防止プロンプトは、根拠限定、不明時保留、出典提示、推測禁止の4型で使い分けます。社内FAQや問い合わせ対応では、すべてを一文に詰めず、用途ごとに分けるほうが確認しやすくなります。
根拠限定プロンプトの書き方例
根拠限定プロンプトは、参照してよい資料を明示してから回答を依頼します。社内FAQでは、資料名、対象期間、回答対象の部署を先に指定すると実務に合わせやすくなります。
根拠限定の例文は、次の形にしますが、『以下の社内ナレッジだけを根拠に回答します。資料に記載がない内容は回答に含めません』。営業資料、CS回答、社内問い合わせの一次回答で使いやすい形式です。
根拠限定は、AIの回答を短くするための指示ではありません。確認済みナレッジの外へ出ないようにするための制御として使います。
根拠範囲を決めるときは、資料名、版数、対象部署、除外資料を一枚の管理表に残します。回答後の確認では、AIの文章より先に、根拠資料の該当箇所と更新日を見ます。
結果は、担当者、期限、会議で見る指標に結び付けます。次回会議で更新状況と未対応理由を確認すると、改善を継続しやすくなります。
不明時に保留させるプロンプト例
不明時保留プロンプトは、回答できない条件と返答形式を先に決めます。分かりませんだけで終えるより、不足している根拠と確認先を出させるほうが業務に戻しやすくなります。
不明時保留の例文は、次の形にします。『根拠資料内で回答を確認できない場合は推測せず、確認が必要ですと明記します』。拒否は回答しない判断ですが、保留は確認すれば回答できる状態として扱います。
回答必須の業務では、AIが保留した後の移管先がないと現場が止まります。保留プロンプトは、確認者と対応期限を決める運用とセットで使います。
保留条件は、根拠なし、更新日不明、権限不明、顧客別条件ありの4つに分けます。保留後の移管先まで決めておくと、AIが止めた回答を現場が放置しにくくなります。
結果は、担当者、期限、会議で見る指標に結び付けます。次回会議で更新状況と未対応理由を確認すると、改善を継続しやすくなります。
出典提示を求めるプロンプト例
出典提示プロンプトは、回答の根拠を追える状態にするための指示です。資料名だけでなく、見出し名、更新日、該当箇所まで求めると確認しやすくなります。
出典提示の例文は、次の形にします。『回答の末尾に、根拠にした資料名、該当見出し、更新日を示します』。出典提示は装飾ではなく、担当者が原文を確認し、顧客対応や社内判断に使ってよいかを見極めるための設計です。
出典の権限や更新日は、プロンプトだけでは常に検証できません。業務利用では、参照元の管理者と更新ルールを別に確認する必要があります。
結果は、担当者、期限、会議で見る指標に結び付けます。次回会議で更新状況と未対応理由を確認すると、改善を継続しやすくなります。
推測を禁止するプロンプト例
推測禁止プロンプトは、根拠が薄いときにAIが自然な文章で埋める動きを抑える指示です。禁止事項を抽象的に書かず、何をしてはいけないかを列挙します。
推測禁止の例文は、次の形にします。『資料から直接確認できない内容を、推測、補完、一般論、経験則として回答しません』。創作用途では使いにくくなる場合があるため、社内FAQや顧客回答など事実性が必要な用途で強く指定します。
それでもAIが推測する場合は、禁止文言を増やすより、参照元と回答不可条件を見直します。次に、失敗しやすい書き方を表で整理します。
推測を禁止するプロンプト例を運用へ落とし込む際は、開始条件、確認担当、利用する記録を一つずつ決めます。判断の前提を文書化しておくと、担当者が変わっても同じ基準で見直しやすくなります。
ハルシネーション防止プロンプトの失敗パターン表
ハルシネーション防止プロンプトの失敗は、文言の丁寧さではなく制御条件の不足から起きます。根拠範囲、出典の扱い、回答不可条件を分けて確認すると、誤回答の混入箇所を見つけやすくなります。
失敗しやすい依頼文は、次の3つに分けて見直します。正確に答えてという抽象指示を、参照範囲と保留条件へ置き換えるのが実務上の起点です。
| 失敗パターン | 起きやすい誤回答 | 修正する指示 |
|---|---|---|
| 根拠範囲が曖昧 | 一般知識や古い情報が混ざります | 参照資料名、対象期間、除外範囲を指定します |
| 出典提示だけを求める | 出典らしい情報で回答を正しく見せます | 原文確認と推測禁止を別に書きます |
| 回答不可条件がない | 分からない箇所を自然な文章で埋めます | 保留条件と有人確認の戻し先を決めます |
表の中で最も先に直すべき箇所は、回答不可条件です。ここが曖昧なままだと、根拠限定や出典提示を足しても、AIが不足情報を補う余地が残ります。
根拠範囲を曖昧にしたまま依頼する
根拠範囲が曖昧なプロンプトは、社内資料と一般知識を混ぜた回答を招きます。社内FAQで使う場合は、参照してよい資料名と対象期間を最初に固定します。
正確に答えてくださいという依頼は、AIに品質目標を伝えるだけで、何を根拠にするかを制御しません。商品改定前の資料、過去の営業資料、公開情報が混ざると、担当者はどこを確認すべきか判断しにくくなります。
修正する場合は、添付した承認済みFAQと2026年8月時点の業務マニュアルだけを根拠にするよう指定します。公開情報の調査が目的なら、参照してよい外部情報と除外する情報を別に指定します。
出典提示だけで正確性を保証させる
出典提示だけでは、回答の正確性は保証されません。出典が付いていても、AIが原文の条件を読み違えたり、根拠と回答を強引に結び付けたりする可能性があります。
現場では、出典が表示されると確認済みの回答に見えやすくなります。特に顧客対応や社内規程の案内では、資料名があるだけで担当者が原文確認を省くリスクがあります。
出典提示を使う場合は、「回答ごとに該当箇所を示し、原文から直接確認できない内容は含めないでください」と続けます。公式資料であっても、適用条件や更新日が違う場合は人が確認します。
回答不可の条件を決めずに使う
回答不可条件がないプロンプトでは、AIは不足情報を自然な文章で埋めようとします。業務利用では、回答できない条件と有人確認へ戻す条件を先に決めます。
【支援現場の見解】
社内FAQの下書きで回答不可条件を置かないと、AIが更新日不明の規程と権限外の手順をつなぎ、担当者が顧客向け回答案として転記する事故が起きます。根拠なし、更新日不明、権限不明を保留に変えると、現場は回答作成ではなく確認依頼へ戻せます。
軽微な文章要約では、保留条件を厳しくしすぎると業務が進みにくくなります。一方で顧客影響、契約、料金、個人情報に関わる回答では、確認者と戻し先を決めてから次のセクションの限界確認へ進みます。
プロンプトだけでは防げないケース
プロンプトは誤回答リスクを下げますが、参照元が古い場合や権限が曖昧な場合は限界があります。RAGや人の確認と組み合わせて、回答してよい範囲を運用で決める必要があります。
古い文書を参照すると誤回答が残る
古い文書を参照するAIは、プロンプトが正しくても古い根拠に基づいて回答します。料金、契約条件、社内規程のように更新が多い情報では特に注意が実施条件になります。
あるCS部門では、過去の社内通知と最新FAQが混在し、担当者が回答根拠を確認し直す場面が発生します。この場合、プロンプトより先に参照対象の更新日を整理します。
履歴参照が目的なら、古い文書を残す意味があります。ただし現在の回答に使う文書と、過去経緯の確認に使う文書は分けて管理します。
RAGがあっても回答根拠は崩れる
RAGは関連文書を探して回答に使う仕組みですが、検索対象や文書管理が乱れていると根拠が崩れます。プロンプトは回答条件を縛り、RAGは参照候補を届ける役割です。
役割分担は、次のように見ると整理しやすくなります。RAGを入れても、回答不可条件と更新運用がなければ誤回答は残ります。
| 対策 | 主な役割 | 限界 |
|---|---|---|
| プロンプト | 回答範囲と禁止事項を決めます | 参照元の品質は直せません |
| RAG | 関連する社内文書を探します | 古い文書や権限混在に弱いです |
| 人の確認 | 高リスク回答を判断します | 確認対象を決めないと負荷が増えます |
RAGでハルシネーションが残る理由は、RAG利用時の誤回答リスクでも整理しています。精度改善の考え方は、社内文書検索の精度を上げる観点を確認すると補完できます。
営業AI・営業DX RAGでハルシネーションが残る原因｜社内AIの誤回答を防ぐ運用設計
営業AI・営業DX RAG精度向上の進め方｜検索・回答・評価・運用で原因を分解して改善
人の確認が必要な業務を切り分ける
高リスク回答は、プロンプトやRAGだけで自動化しないほうが安全です。契約、料金、個人情報、クレーム対応は、人の確認を通す条件を決めます。
低リスクFAQでは、営業時間、手続き場所、公開済み資料の要約などを自動回答できる場合があります。一方で、顧客ごとに条件が変わる回答は担当者確認へ戻します。
切り分けの基準は、間違えたときの影響で決めます。次の段階では、参照元、権限、更新日、レビュー責任者をチェックしてから業務利用に進みます。
業務利用前に見るチェックリスト
業務利用前には、参照元、閲覧権限、更新日、承認者、NG回答、レビュー責任者、ログを確認します。プロンプト例を配る前に、回答に使ってよい情報と止める条件をそろえることが判断条件になります。
参照元と閲覧権限を確認する
参照元と閲覧権限は、AIが回答してよい範囲を決める前提です。部署限定の資料や顧客別情報が混ざる場合は、回答対象を分けて設計します。
チェック項目は、資料名、保管場所、閲覧できる部署、顧客情報の有無です。公開FAQでは権限条件が負担を抑えてなりますが、社内ナレッジでは部署ごとの制御が実施条件になります。
- 承認済み資料だけを参照元にします。
- 閲覧権限が部署ごとに違う資料を分けます。
- 個人情報や契約条件を含む資料を除外します。
- 回答に使わない資料を明示します。
社内ナレッジをAIで扱う前提は、承認済み情報を活用する考え方を確認すると整理しやすくなります。参照元の管理が曖昧なままでは、プロンプトだけで権限問題を解消できません。
営業AI・営業DX 社内ナレッジAIとは｜承認済み情報で根拠付き回答する仕組みと導入条件
更新日と承認者を確認する
更新日と承認者がない情報は、運用中に回答品質を下げます。AIが正しく参照していても、根拠文書そのものが古ければ誤案内になります。
確認する項目は、最終更新日、承認者、次回見直し日、旧版の扱いです。過去事例を履歴として残す場合は、現在回答用の文書と分けます。
- 更新日が不明な資料は回答根拠から外します。
- 承認者がいない資料は下書き扱いにします。
- 旧版資料は履歴用としてラベルを付けます。
- 見直し日を過ぎた資料は保留対象にします。
料金改定前の資料が残ると、AIが古い条件を自然に回答することがあります。更新責任者を決めると、プロンプトの保留条件も現場で守りやすくなります。
誤回答テストの指標を決める
誤回答テストは、AIを業務利用してよいか判断するための確認です。誤回答率だけでなく、根拠提示率、不明時保留率、有人移管率を見ます。
設問数は業務リスクに応じて調整します。契約や料金に関わる質問が多い場合は、少数の成功例より失敗時の影響を負担が大きく見ます。 社内問い合わせの運用改善では、問い合わせ対応の見直し観点も合わせて確認すると、回答品質と運用負荷を分けて考えやすくなります。
営業AI・営業DX 社内問い合わせを効率化する方法｜FAQで止まらない原因と仕組み化の設計
社内説明に使う品質指標を先に整理すると、導入判断が感覚に寄りにくくなります。AI回答品質の確認観点を、現場で使う指標としてそろえておくことが判断条件になります。
「ヒアリング力を上げろ」では誰も育たない。トップ営業の暗黙知を測定可能なレベルまで分解した、6業種のスキルマップ・テンプレートを公開中！
＞＞無料で『業種別！営業の成果と育成を両立するスキルマップテンプレート集』をダウンロードする
導入前に確認すべき質問
導入前の確認では、回答根拠、回答不可条件、レビュー責任、改善ログを関係者で合意します。プロンプトを作るだけでなく、誰が運用し、どこで止めるかを決めます。
どの回答を人が確認するか決める
有人確認の対象を決めると、AI回答の責任範囲が曖昧になりません。契約、料金、個人情報、顧客影響がある回答は確認対象にします。
即時回答が必要な業務では、すべてを人に戻すと対応が遅れます。一次回答はAI、最終判断は担当者という分担にすると、速度と確認を両立しやすくなります。
運用責任者と更新ルールまで決めてから業務利用に進みます。確認対象が決まると、現場は迷わず保留や移管を選べます。
社内ナレッジを誰が更新するか決める
社内ナレッジの更新責任者がいないと、回答品質は時間とともに劣化します。FAQ、マニュアル、社内通知のどれを誰が直すかを先に決めます。
プロンプトを配っても現場で守られないと感じる方は多いです。原因は文言の弱さではなく、古い情報を誰が止めるか決まっていない点にあります。
対象ナレッジの種類とリスクで、使ってよい範囲を切り分けます。FAQ運用の比較観点は、FAQ管理の選定軸を確認すると整理しやすくなります。
営業AI・営業DX FAQシステム比較は機能数より回答根拠と更新運用で失敗を防ぐ
導入後に何を測定するか決める
導入後の測定指標がないと、改善すべき点を判断できません。回答数ではなく、根拠提示率、不明時保留率、有人移管率、更新漏れ件数を見ます。
初期運用では、定量指標だけで結論を急がないほうが安全です。現場レビューで、誤回答の原因がプロンプト、ナレッジ、権限、更新日のどれかを分類します。
情シス、CS、経営で見る論点をそろえると、業務利用前の不安を整理しやすくなります。プロンプト配布だけで始める前に、運用設計の確認材料として資料を参照できます。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
よくある質問
ハルシネーション防止プロンプトは、誤回答リスクを下げるための設計です。完全防止を前提にせず、根拠確認と人のレビューを組み合わせて運用します。
ハルシネーションはプロンプトで完全に防げますか
プロンプトだけでハルシネーションを完全に防ぐことはできません。根拠限定、不明時保留、出典提示でリスクを下げ、顧客影響がある回答は人が確認します。具体的な進め方は組織の現状に応じて調整します。
RAGを入れればプロンプト対策は不要ですか
RAGを入れてもプロンプト対策は必要です。RAGは参照候補を届ける仕組みであり、回答範囲、推測禁止、不明時保留はプロンプトと運用ルールで指定します。まずは現状の課題を整理することから始めます。
業務利用前に最低限テストすべきことは何ですか
業務利用前は、根拠どおりに回答するか、根拠がない質問を保留できるかを確認します。あわせて出典提示率、有人移管率、更新漏れの有無を見ます。定着には週次での振り返りが改善につながります。
まとめ
ハルシネーション防止プロンプトは、根拠限定、不明時保留、出典提示、推測禁止を分けて書くことで誤回答リスクを下げます。ただしプロンプトだけで完全に防げるわけではなく、参照元、権限、更新日、レビュー責任者まで確認する必要があります。
現状のまま生成AIを業務に使うと、古い社内文書や権限外の情報を根拠にした回答が顧客対応へ流れる可能性があります。担当者は出典らしい表示を見て安心し、あとから原文確認や責任範囲の整理に追われやすくなります。
次にRAGとの分担を整理したい場合は、RAG利用時の誤回答リスクを確認すると、プロンプトで止める範囲とナレッジ側で直す範囲を分けやすくなります。
営業AI・営業DX RAGでハルシネーションが残る原因｜社内AIの誤回答を防ぐ運用設計
誤回答リスクを運用で下げる設計を確認したい方は、営業改善プログラム「FAZOM」のサービス資料を業務利用前の確認材料としてご覧ください。担当者個人にとっても、情シス、CS、経営へ説明する論点をそろえやすくなります。
営業の型・商談振り返り・改善の流れを一連の仕組みにする営業改善プログラムはこちら！
＞＞無料で『3分でわかる「FAZOM」ご解説資料』をダウンロードする
