ハルシネーション対策プロンプト集｜コピペで使える雛形とRAG・検証・運用の手順【2026年版】

この記事は、ハルシネーションを実際に減らす手順に絞って説明します。コピーして使えるプロンプトの雛形から、RAGの検索設計、生成後の検証、組織の運用ルールまでを、着手しやすい順に並べました。意味や種類はハルシネーションとは？、なぜ起きるのかはハルシネーションの仕組み・原因、誤りの見つけ方と測り方はハルシネーションの検出・評価をご覧ください。

ハルシネーションとは？対策を考える前の基礎知識

ハルシネーション（幻覚）とは、生成AI（大規模言語モデル・LLM）が、事実に基づかない情報を、あたかも根拠があるかのように断定的な文章で出力してしまう現象です。誤字脱字のような単純なミスではなく、文法的にも文脈的にも自然な文章で出てくるため、読み手が気づきにくいことが問題になります。

なぜ起きるのか：対策を選ぶための原因の整理

• 次の語を確率で選ぶ仕組み：LLMは「次に来る確率が高い語」を選び続けて文章を作ります。事実を調べて答えているわけではなく、「事実かどうか」を確かめる工程がありません。
• 学習データの不足・偏り・誤り・古さ：学習データに少ない話題はもっともらしく補われ、学習時点より後の出来事は知りません。
• 自信過剰：確信が低い内容でも口調は断定的になりやすく、受け取る側が見抜きにくくなります。

この3つのうち、モデルそのものは利用者が直せません。一方で、与える資料（学習データの穴を補う）と、指示の書き方と、出力の確認は利用者の側で変えられます。以降の4ステップは、この3つに対応しています。原因の詳しい仕組みはハルシネーションの仕組み・原因、実際の失敗例はハルシネーションの事例（実在しない判例を提出した弁護士、規定と違う運賃を案内した航空会社のチャットボットなど）にまとめています。

ハルシネーションが起きているかをどう確かめるかは、ハルシネーションの検出・評価（精度を測る方法）で解説しています。

関連記事ハルシネーションの仕組み・原因は？

ハルシネーション対策の全体像：4つのステップを重ねる

ハルシネーションは仕組み上ゼロにできないため、1つの対策に頼らず層を重ねます（多層防御）。着手しやすい順に次の4つです。

ステップ	効くこと	難しさ	特に有効な場面
1 プロンプト	断定的な誤情報の抑制、根拠なし回答の抑制	低	事実確認・リサーチ・要約
2 RAG	内部知識への依存を減らし、最新の資料に縛る	中〜高	社内文書Q&A・法改正や製品仕様
3 生成後の検証	出た誤りを次の工程で拾う	中	重要度の高い回答・数値・固有名詞
4 組織の運用	確認の抜けを手順で防ぐ	低〜中	全社でAIを使うとき

ステップ1：プロンプトで予防する（コピペで使える雛形つき）

結論として、「与えた資料に書かれた内容だけを根拠に答え、書かれていないことは『資料に記載がありません』と答える」とシステムプロンプトで明示し、RAGなどで取得した文書の本文をプロンプトに埋め込んで、その範囲で答えさせます。

基本の雛形（資料に縛る型）

あなたは事実に忠実なアシスタントです。以下のルールを厳守してください。
1. 回答は【参考資料】に記載された内容のみを根拠にすること。
2. 資料に記載がない事項は推測せず「資料には記載がありません」と述べること。
3. 各主張の末尾に、根拠とした資料番号を [1] のように付けること。
4. 不確かな場合は断定せず、確認が必要である旨を明記すること。
【参考資料】
[1] （出典名）：（取得した本文）
[2] （出典名）：（取得した本文）
【質問】
（ユーザーの質問）

この雛形は、回答範囲を資料内に限定し、出典を強制し、不明なときの逃げ道（「記載がありません」）を用意する3点で成り立っています。資料と質問の境界を明確に分けると、混同が減ります。

数値・固有名詞を作らせない型

「不確実なら『わかりません』と答えて」と書くだけでは、人名・社名・実績の数値などを作ってしまうことがあります。数値と固有名詞には、出典がなければ出力させない制約を足します。

あなたは提供された資料の内容のみに基づいて回答するアシスタントです。
1. 資料に明記されていない情報は、推測や一般知識で補完しない。
2. 該当する記述が資料内にない場合は「該当箇所なし」と明記する。
3. 数値・固有名詞（人名・社名・実績など）を出力する際は、必ず資料内の出典番号を [1] のように付ける。
4. 出典番号を付けられない数値・固有名詞は出力しない。

条件を具体的に指定する（主語・期間・対象）

質問の条件があいまいだと、モデルは空白を自分で埋めます。主語・期間・対象・形式を指定して、埋める余地を減らします。

あいまいな指示	条件を具体的にした指示	減らせる誤り
「この会社の最近の状況を教えて」	「提供した2026年度の決算資料の範囲で、売上と利益の増減だけを答えて」	資料にない数値の創作
「関連する法律を教えて」	「個人情報保護法のうち、提供した条文に書かれた範囲だけを要約して」	存在しない条文の引用
「おすすめの論文を挙げて」	「提供した論文リストの中から、テーマに合うものを3件選んで」	実在しない論文の生成

その他の書き方

手法	書き方の例	効果と注意
逃げ道を作る	「確証がなければ『わかりません』と答える」「推測の場合はその旨を明記する」	指示がないと、AIは沈黙より何かを生成する方向に動く。無理な断定が減る
出典を求める	「回答の根拠となる情報源を明記する」	示された出典やURL自体が虚偽のこともあるため、必ず原典で確認する
手順を分けて考えさせる（CoT）	「順を追って考えてから回答する」	推論の途中が見え、矛盾や飛躍に気づきやすい。複雑な計算・論理に向く
正解例を示す（Few-Shot）	入力と望む出力の例を2〜3組示す	形式と精度が安定する。定型業務・専門分野に向く
出力形式を固定する	JSONや項目指定で答えさせ、埋められない項目は空欄にする	自由記述の余白が減り、埋めるための創作の余地が減る

ステップ2：RAG（検索拡張生成）で根拠を外から渡す

RAGは、信頼できるデータベースや文書を検索して取り出し、その内容を根拠に答えさせる構成です。ハルシネーション対策で最も効果的とされる構成のひとつですが、渡す根拠がずれれば生成もずれます。本丸は、生成側のプロンプトより先に検索側の精度です。

「検索が外すと、LLMも外す」を前提に組む

• チャンクの粒度：機械的に文字数で切ると文脈が途切れ、根拠が半分だけ渡って残りを作り話で補いやすくなります。見出し＋本文など意味が完結する単位で分け、必要なら前後のチャンクも一緒に渡します。
• リランキング：ベクトル検索の上位数件をそのまま投入せず、再ランクして質問に答える文書を上位に上げます。無関係な文書が混ざるほどノイズに引きずられます。
• メタデータで絞る：日付・製品バージョン・部署・言語で先にフィルタします。古い版の仕様を最新として断定する取り違えを抑えられます。

失敗パターン	起きること	検索側の対策
該当文書を拾えない	空の根拠から推測で回答	「根拠なし時は回答不可」を明示し、クエリを書き換えて再検索
古い版が上位に来る	旧仕様を最新として断定	日付・versionで絞る、新しい版を優先
似た別トピックが混入	隣の情報を接ぎ木した作り話	リランキングと類似度のしきい値で足切り
長文を丸ごと投入	中ほどの根拠を無視（中間忘れ）	関連箇所だけ抜き出して短く渡す

検索を整えたら、生成を根拠に縛ります（グラウンディング）。「渡した文脈のみを根拠に答え、含まれない場合は『資料に記載なし』と答える」と指示し、回答には出典（チャンクIDやURL）を必須で入れさせます。出典を出せない主張は出力から落とします。

ステップ3：生成しっぱなしにしない（検証の層）

RAGを組めない場面や、RAGの上に重ねる二段目として、生成後に検証する工程を挟みます。モデルを賢くするのではなく、誤りを出しにくい形に誘導し、出た誤りを次の工程で拾う考え方です。

対策	具体的なやり方	効く場面
自己検証（2段）	生成のあと、別のステップで「先ほどの回答に誤りや不確実な点があれば指摘して」と点検させる（Self-Refine）	重要度が高い回答
複数生成の突合	同じ質問を複数回生成し、食い違いを検出する（Self-Consistency）	数値・固有名詞・日付
外部ソースとの自動照合	固有名詞・数値・URLを公式API・社内DBと自動で照合する	企業情報・法令・薬品名
低い温度	語の選び方のばらつきを抑える	質疑応答・仕様回答
人のレビュー	法的文書・医療情報・財務予測などは、AIの出力を最終判断にせず専門家が確認する	高リスクの判断

運用上の勘所は、事実系のタスクと創造系のタスクで設定を分けることです。アイデア出しは温度を上げてよい一方、確定情報として社外へ出す前には、数値・固有名詞・日付だけでも人が一次資料と突き合わせる工程を1つ挟みます。「年号」「法律名」「統計数値」の3点は、特に誤りが出やすい項目です。出力を疑うべきサインと、検出の自動化はハルシネーションの検出・評価で詳しく扱っています。

ステップ4：組織の運用ルールと、用途別の確認の深さ

技術の対策と並行して、使う人の側のルールを整えることが、組織としての最後の防衛線です。個人の注意だけでは、忙しいときに確認が抜けます。東京都産業労働局のポータルや東京都デジタルサービス局の「生成AI利用の手引き」は、確認を組織の手順として決めておくことを勧めています（2026年10月19日確認）。

ルール	内容
一次情報の確認を業務フローにする	法律の条文・税務・医療情報・統計・固有名詞を含む出力は、人が公式の原典に遡って確認する工程を決める
「そのまま信じない・そのまま出さない」を冒頭に置く	自分で公式の情報源に当たって確認することを、社内ガイドラインの第1条に近い位置で明記する
必要に応じて複数人でチェックする	他のサイトでの事実確認に加え、必要に応じて複数の担当者で確認する
最終判断と説明責任は人が負う	承認者を決めておき、AIへの過度な依存（自動化バイアス）を避ける
事例とヒヤリハットを共有する	定期的な研修で、安全な指示の書き方や誤りの事例を共有し、更新する

用途のリスク別に、確認の深さを変える

すべての用途に同じ検証コストをかけるのは非効率です。リスクを分けて重点を決めます。

リスク	用途例	推奨する対策
高	法的文書・医療情報・財務予測・公式発表	専門家レビュー必須・一次資料の照合・RAGと人の確認
中	社内報告書・顧客向け提案・技術説明	自己検証プロンプト・部分的な事実確認
低	ブレインストーミング・下書き・アイデア出し	プロンプトの工夫と最終確認で完結

分野別の重点

• 医療・ヘルスケア：薬品名・用量・治療法の誤りは健康被害に直結します。AI単独での最終判断を避け、最新のガイドラインをRAGで参照させたうえで専門家が確認します。
• 法律・コンプライアンス：存在しない条文・判例の引用が法的リスクになります。法令DBや判例DBとのRAGが有効ですが、法改正への追随（データの鮮度管理）も必要です。
• カスタマーサポート：製品仕様・価格の誤回答はクレームに直結します。回答範囲を社内ナレッジに限定し、分からない場合は有人対応へ引き継ぐ設計にします。
• コンテンツ制作・マーケティング：統計・事例・引用の正確性を確認します。不正確な統計を広告に使うと景品表示法上のリスクにもなり得ます。

フィードバックループを作る

現場で起きた誤りを記録して集めると、特定のモデル・分野での傾向が見え、プロンプトや検索設計の改善につながります。

モデル選定とファインチューニング：プロンプトやRAGで足りないとき

ハルシネーションの傾向はモデルによって異なるため、用途・コスト・精度のバランスを踏まえたモデル選定も対策の一部です。比較はAIモデルの比較（LLM比較）をご覧ください。特定分野のデータで追加学習（ファインチューニング）すると、その分野の語彙と知識を強化できますが、学習データの質が悪いと誤りを固定化するため、高品質なデータの準備と学習後の定量評価が必要です。人の評価による調整（RLHF）はモデル提供側が行うもので、真実性が向上した一方で単純な誤りは残ると報告されています（Ouyang ほか, 2022, arXiv:2203.02155）。

ハルシネーションの種類と分類：タイプで打ち手が変わる

ハルシネーションを正しく対策するには、それが一種類ではないことを理解しておく必要があります。研究者やエンジニアの間では、主に以下の軸で分類されています。どのタイプが起きているかを切り分けられると、打つべき対策（RAG・プロンプト設計・出力検証など）の優先順位も判断しやすくなります。

分類	内容	具体例
事実的ハルシネーション	実世界の事実と異なる情報を生成する	架空の論文引用、人物の誤った経歴
忠実性ハルシネーション	入力した文書・文脈に忠実でない内容を生成する	要約で原文にない内容を追加する
内部矛盾ハルシネーション	同一の回答内で前後が矛盾する	段落1と段落3で異なる年号を記述
存在しないエンティティの生成	架空の人物・企業・製品などを実在するように記述	存在しない法律・規格番号の明示

たとえば社内文書をRAGで参照させているのに要約が原文とずれる場合は「忠実性ハルシネーション」であり、検索データソース自体ではなく生成側の制御に課題があるといった切り分けができます。タイプを見極めることが、効果的な対策選択の第一歩です。

ハルシネーションを見分ける方法（検出のポイント）

事前の予防策をどれだけ講じても、ハルシネーションをゼロにすることはできません。そのため「出力を受け取った側が誤りに気づけるかどうか」が最後の防衛線になります。AIの出力に慣れていても肉眼での判別は難しいため、次のチェックポイントを習慣化することでリスクを大幅に下げられます。

出力を疑うべきサインを知る

• 具体的すぎる数字（統計値・年号・金額）が登場する
• 引用・出典がついているが、URLや書誌情報が細かすぎる
• 普段あまり見かけない固有名詞（人名・企業名・制度名）が出てくる
• 「〜と報告されています」「〜によれば」など権威を匂わせる表現が多い
• 回答が質問の想定を超えて詳細・断定的すぎる

実践的な一次確認の手順

1. 検索エンジンで固有名詞・数値を単独検索する：引用された論文タイトルや人名をそのまま検索し、実在するかを確認する。
2. 複数のモデルに同じ質問をする：異なるLLMで回答が一致するか確認する。ただし複数のモデルが同じ誤りを共有している場合もあるため過信は禁物。
3. 「情報源を教えて」と追加質問する：モデルが具体的なURLや文献を提示した場合、それが実在するか必ず確認する。
4. 一次情報と照合する：重要な用途では、公式サイト・学術データベース・政府統計など一次情報源と照合する。

2026年時点の最新トレンドと今後の展望

ハルシネーション対策の技術は急速に進化しています。現在注目されている方向性を押さえておくことで、自社の対策ロードマップに活かせます。

グラウンディング強化技術（Grounding）

Googleの「Grounded Generation」に代表されるように、モデルの回答を外部ソース（Google検索・公式文書など）に明示的に紐づける技術が普及しつつあります。出典付きの回答が標準化されることで、ユーザー側での検証が容易になります。

不確実性の定量的提示（Calibrated Confidence）

「この回答の確信度は70%です」といった形でモデルが自己の不確実性を数値で提示するアプローチが研究・実装段階で進んでいます。確信度が低い領域を明示することで、ユーザーが重点的に確認すべき箇所を判断しやすくなります。

Agentic AIにおけるファクトチェックエージェント

複数のAIエージェントが協調するシステムでは、生成エージェントが出力した内容を別のファクトチェックエージェントが検証する分業構造が実装されるケースが増えています。これはRAGの発展形ともいえる方向性で、複雑な業務フローへの組み込みで特に威力を発揮します。

---

よくある質問

ハルシネーション対策のプロンプトはどう書けばよいですか？

「以下の【参考資料】に書かれた内容だけを根拠に答える」「資料にないことは推測せず『資料には記載がありません』と答える」「各主張の末尾に根拠の資料番号を付ける」の3点をシステムプロンプトの冒頭に置きます。雛形は本文の「ステップ1」にあります。

プロンプトだけでハルシネーションを防げますか？

防ぎきれません。プロンプトは最も早く着手できる層ですが、「不明なら不明と言って」と指示するだけでは数値や固有名詞を作ってしまうことがあります。資料を渡すRAG、生成後の検証、人の確認と重ねます。

RAGを入れればハルシネーションはなくなりますか？

なくなりません。検索で必要な文書を取り損ねれば根拠のないまま答え、取れた文書を読み違えても誤ります。法律分野の有料AI調査ツールを検証した研究では、いずれも17%から33%の割合でハルシネーションが報告されています（Magesh ほか, 2024）。

社内でAIを使うとき、最低限決めておくべきことは何ですか？

数値・法令・固有名詞を含む出力は一次資料で確認する、AIの出力をそのまま社外に出さない、最終判断と説明責任は人が負う、の3つです。用途ごとに確認の深さを決める方法は「ステップ4」にあります。

まとめ：ハルシネーション対策は多層防御が基本

ハルシネーションは、LLMの確率的な文章生成という性質から完全に排除できません。そのため、プロンプト（範囲の限定・出典の強制・逃げ道）、RAG（根拠を外から渡す）、生成後の検証、組織の運用の4つを、用途の重要度に応じて重ねます。まず今日からできるのは、上の雛形をシステムプロンプトの冒頭に置き、数値・固有名詞だけでも一次資料で確かめる習慣をつけることです。

• プロンプトで「資料の範囲だけで答える」「出典を付ける」「分からなければ不明と答える」を明示する
• RAGでは生成より先に検索の精度を整え、根拠に拘束する
• 事実系の出力には検証の工程を挟み、高リスクの判断は人が最終確認する
• 確認の深さを用途のリスクで分け、組織のルールにする

最終更新日：2026年11月2日