専門家一覧
RAG（検索拡張生成）によるLLMのハルシネーション抑制技術と実装手法

RAGの嘘を封じるプロンプト設計図：ハルシネーションを抑制する実装テンプレート集

約12分で読めます
文字サイズ:
RAGの嘘を封じるプロンプト設計図：ハルシネーションを抑制する実装テンプレート集
目次

この記事の要点

  • RAGによるLLMハルシネーション抑制の基本原理
  • 外部知識源を活用した回答のグラウンディング
  • プロンプトエンジニアリングによるハルシネーション制御

PoCで直面する「AIの嘘」という壁

「社内Wikiを検索させているはずなのに、存在しない社内規定をAIが勝手に作り出してしまった」

RAG（Retrieval-Augmented Generation：検索拡張生成）システムの概念実証（PoC）を進める中で、このような経験をされていないでしょうか。ドキュメントをベクトル化し、検索システムを構築し、いざLLM（大規模言語モデル）に回答させると、AIは驚くほど流暢に、しかし致命的な嘘をつくことがあります。

これが、いわゆるハルシネーション（幻覚）です。

システムを構築する際、一般的に「検索結果（Context）」をLLMに渡せば、それに基づいて正確に答えてくれると期待されます。しかし、LLMの本質は「確率的に次の単語を予測するマシン」であり、事実を述べるマシンではありません。彼らは空白を埋めるのが得意すぎるあまり、情報が不足していれば、事前学習した膨大な知識や、単なる確率的なつながりから「もっともらしい答え」を捏造してしまうのです。

顧客対応や社内業務支援において、この「嘘」は顧客体験（CX）の低下や業務効率の悪化を招くため許容できません。誤った手続きの案内や、存在しない製品仕様の回答は、企業の信頼を損なうリスクに直結します。

AI導入コンサルタントの視点から見ると、この課題に対しては「モデルのファインチューニング」ではなく、「プロンプトエンジニアリングによる制約」が有効な解決策となります。適切な指示（プロンプト）を与えれば、LLMは「おしゃべりな知恵袋」から「厳格な事務員」へとその振る舞いを変えることができます。

本記事では、実務の現場で活用されているハルシネーション抑制のためのプロンプトテンプレートを具体的に解説します。これらは、情報の範囲を限定し、根拠を明示させ、分からないことは分からないと言わせるための設計図です。ぜひ、RAGシステムのコードに組み込み、その変化を体感してください。

本テンプレート集の活用目的とRAGにおけるプロンプトの役割

なぜ、単に検索結果を渡すだけでは不十分なのでしょうか。まずは「敵」を知ることから始めましょう。RAG（Retrieval-Augmented Generation）においてハルシネーション（もっともらしい嘘）が発生するメカニズムを理解すれば、プロンプトで何を制御すべきかが見えてきます。

なぜ検索結果を渡すだけでは不十分なのか

LLM（ChatGPTやClaudeの最新モデルなど）は、インターネット上の膨大なテキストデータで事前学習されています。彼らはすでに「一般的な知識」を大量に持っています。

RAGシステムで特定のドキュメント（コンテキスト）を渡したとしても、LLMにとってそれは「入力の一部」に過ぎません。デフォルトの状態では、「自身が持つ事前知識」と「今回入力されたコンテキスト」のどちらを優先すべきか、明確な区別を持っていないのです。

さらに、昨今のRAGは従来の単純なテキスト検索から、知識グラフを活用したGraphRAGや、画像や図表を含むマルチモーダルRAGへと進化しており、扱う情報の複雑性が増しています。高度な検索技術で関連情報を取得できたとしても、最終的に回答を生成するのはLLMです。

例えば、「A社の就業規則について教えて」と聞いた時、コンテキストに該当情報がなくても、LLMは一般的な企業の就業規則の知識を使って回答を生成してしまう可能性があります。これが知識の混同です。検索精度がいかに向上しても、生成側の制御が甘ければ誤回答は防げません。

ハルシネーションが発生する3つのメカニズム

実務上、特に注意すべきハルシネーションのパターンは以下の3つです。

  1. 知識の混入（Knowledge Intrusion）: コンテキストに含まれない外部知識（事前学習データ）を使って回答してしまう現象。
  2. 事実の捏造（Fabrication）: コンテキストにも外部知識にもない情報を、文脈の整合性を保つために勝手に作り出す現象。
  3. 推論の飛躍（Reasoning Error）: コンテキスト内の情報を誤って解釈し、間違った結論を導き出す現象。

プロンプトによる『制約』が品質を担保する

これらを防ぐために不可欠なのが、System Prompt（システムプロンプト）による厳格な役割定義と制約です。

近年のエージェント型RAGの潮流においても、AIに対して「あなたは親切なアシスタントです」という曖昧な指示ではなく、「あなたは提供されたドキュメントのみに基づいて回答する厳格な検索エージェントです。ドキュメントにない情報は一切回答してはいけません」というように、人格と行動範囲を明確に定義する必要があります。

今回紹介するテンプレートは、この「制約」をコードレベルで実装するためのものです。Pythonのf-string形式を想定していますが、あらゆる言語やプロンプト管理ツール、あるいはGitHub Copilotのエージェント機能などで応用可能です。

【基本編】情報の『範囲』を限定するグラウンディング・テンプレート

本テンプレート集の活用目的とRAGにおけるプロンプトの役割 - Section Image

まずは基本中の基本、Strict Context Pattern（厳格なコンテキスト制限）です。これは「提供された情報のみを使用せよ」という指示を徹底させるものです。

外部知識の遮断とコンテキスト依存の強制

多くのケースで「以下の情報を参考に答えてください」と指示されますが、これでは弱すぎます。「参考に」ではなく「のみを使用し（strictly based on）」、「外部知識の使用を禁止する」と明記する必要があります。

テンプレート解説：Strict Context Pattern

以下は、ベースとして推奨されるプロンプトテンプレートです。

strict_context_template = """
# Role
あなたは提供されたコンテキスト情報のみに基づいて質問に回答するAIアシスタントです。
あなたの知識ベース（事前学習データ）は使用せず、必ず以下の[Context]内の情報だけを情報源としてください。

# Rules
1. [Context]に記載されていない情報は、たとえ事実であっても回答に含めないでください。
2. [Context]から回答が導き出せない場合は、正直に「提供された情報からは回答できません」と答えてください。
3. 回答は客観的なトーンを保ち、推測を含めないでください。

# Context
{context}

# User Question
{query}
"""

ポイント:

  • # Role で「事前学習データを使用しない」と明言しています。
  • # Rules でコンテキスト外の情報の使用を禁止（Negative Constraint）しています。
  • 情報の欠落時には「回答できない」と答えるよう指示しています（これについては後述のセクションで詳しく掘り下げます）。

実装例と出力比較

悪いプロンプト例:
以下の情報を参考に質問に答えて: {context} 質問: {query}

結果（悪い例）:
コンテキストにない情報でも、もっともらしい一般論を混ぜて回答してしまう。

良いプロンプト（上記テンプレート）の結果:
「コンテキストにはその記述がありません」と、情報の境界線を守った回答が得られる。

まずはこのテンプレートをシステムのデフォルトとして設定することをお勧めします。適切に導入した場合、ハルシネーションの発生率を60〜70%程度抑制できる傾向があります。

【応用編】回答の『根拠』を可視化する引用明示テンプレート

次に、回答の信頼性をさらに高めるためのテクニック、Citation（引用）の実装です。

信頼性を担保するCitation（引用）ルール

人間がレポートを書くときに出典を明記するように、AIにも「どのドキュメントの記述に基づいているか」を示させます。これにより、以下の2つの効果が期待できます。

  1. ユーザーによる検証可能性（Verifiability）: ユーザーが元ドキュメントを確認できる。
  2. ハルシネーションの抑制: 「ソースを示せないことは書けない」という制約が働き、AIの捏造が減る（Chain-of-Thought効果）。

テンプレート解説：Source Attribution Pattern

検索システム側で、各ドキュメントチャンクにIDやファイル名を付与して渡すことが前提となります。

citation_template = """
# Role
あなたは提供された参考資料に基づいて質問に回答するドキュメント検索ボットです。
回答のすべての主張には、必ず参照元の[Source ID]を付記してください。

# Context Format
各情報は以下の形式で提供されます：
[Source: ID] テキスト内容

# Rules
1. 回答の各文の末尾に、根拠となった情報の[Source ID]を必ず記載してください。
   例: 「〇〇機能の設定は管理画面から行います[Source: doc_123]。」
2. 複数のソースに基づく場合は [Source: doc_123, doc_456] のように列記してください。
3. [Source ID]が特定できない情報は、回答に含めないでください。

# Context
{context_with_ids}

# User Question
{query}
"""

実装のコツ:
Python側でコンテキストを組み立てる際、単にテキストを連結するのではなく、[Source: file_name_01] 本文... のような形式に整形して {context_with_ids} に流し込むのがポイントです。

参照元がない場合の挙動制御

このテンプレートを使用すると、AIはソースIDを探そうと必死になります。もしソースが見つからなければ、ルール3に従ってその文の生成を諦めます。結果として、根拠のない曖昧な記述が回答から削ぎ落とされ、非常にソリッドで信頼性の高い回答が生成されます。

【リスク対策編】『分からない』と言わせる回答拒否テンプレート

【応用編】回答の『根拠』を可視化する引用明示テンプレート - Section Image

RAGにおいて重要なのは、AIに「分かりません」と言わせるエスカレーション設計です。無理やり捏造された回答よりも、正直な回答拒否の方が顧客体験を損なわず、ビジネス上のリスクも圧倒的に低くなります。

無理な回答生成を防ぐフォールバック戦略

検索結果（Retrieval）の精度が低く、回答に必要な情報が含まれていないケースは必ず発生します。この時、AIに「知識の穴埋め」をさせないためのRefusal & Clarification Patternを用います。

テンプレート解説：Refusal & Clarification Pattern

refusal_template = """
# Role
あなたは誠実なナレッジベースアシスタントです。
提供されたコンテキスト情報が質問に回答するのに不十分な場合、決して情報を捏造せず、回答不能であることを伝えてください。

# Rules
1. コンテキスト内の情報で質問に完全に回答できる場合のみ、回答を生成してください。
2. 情報が不足している、または関連する情報が見つからない場合は、以下の定型句で回答してください：
   「申し訳ありません。提供された社内ドキュメントの中には、そのご質問に対する情報が見つかりませんでした。」
3. 質問が曖昧な場合は、推測で回答せず、ユーザーに具体的な追加情報を求めてください。

# Context
{context}

# User Question
{query}
"""

曖昧な質問への切り返し方

さらに高度な実装として、単に拒否するだけでなく、「〇〇についての情報はありますが、××については記載がありません。どちらについて知りたいですか？」といった誘導尋問を行わせることも可能です。これにより、ユーザー体験を損なわずにハルシネーションを回避できます。

【品質評価編】AIにAIを監査させる『審査官』プロンプト

プロンプトを作り込んだとしても、毎回人間が全ての回答をチェックするのは不可能です。そこで、運用フェーズではLLM-as-a-Judge（審査員としてのLLM）というアプローチを採用します。

RAG回答の正確性を自動スコアリングする

回答生成用のLLMとは別に、評価用のLLM（より高性能なモデル、例えばChatGPTなど）を用意し、「生成された回答」と「コンテキスト」を比較させます。これによってハルシネーションを自動検知する仕組みを作ります。

テンプレート解説：RAG Evaluator Pattern

以下は、回答の忠実性（Faithfulness）を判定させるための評価用プロンプトです。

evaluator_template = """
# Task
あなたはRAGシステムの回答品質を評価する監査官です。
以下の[Context]、[User Question]、[AI Answer]を確認し、AIの回答がコンテキストに基づいているか（ハルシネーションがないか）を判定してください。

# Input Data
[Context]: {context}
[User Question]: {query}
[AI Answer]: {generated_answer}

# Evaluation Criteria
1. Faithfulness (忠実性): 回答に含まれるすべての主張が、[Context]によって裏付けられているか。
2. Relevance (関連性): 回答は[User Question]に対して適切に答えているか。

# Output Format
以下のJSON形式のみで出力してください。
{{
  "score": 0から10の整数,
  "reason": "減点の理由やハルシネーションの具体的な指摘",
  "hallucination_detected": true/false
}}
"""

運用フローへの組み込みイメージ:
この評価プロセスを夜間のバッチ処理などで走らせ、スコアが低い（ハルシネーションの疑いがある）ログだけを人間が目視チェックします。これにより、品質管理の工数を大幅に削減しながら、継続的なプロンプト改善のサイクルを回すことが可能になります。

実装と改善のロードマップ

ここまで紹介したテンプレートは、あくまで「出発点」です。RAGシステムは生き物であり、ドキュメントの質やユーザーの質問傾向によって、最適なプロンプトは変化します。

プロンプトのバージョン管理

プロンプトはソースコードの一部として扱ってください。Gitでバージョン管理し、「v1.2では回答拒否が強すぎたので、v1.3で少し緩和した」といった履歴を残すことが重要です。

失敗ケース（エッジケース）の蓄積と修正

  • False Positive（誤検知）: 正しい情報なのに「情報なし」と答えてしまった。
  • False Negative（見逃し）: 嘘の情報を自信満々に答えてしまった。

これらの失敗ログを蓄積し、それをテストケースとして（Few-Shotプロンプティングの例として）プロンプトに追加していくことで、システムは徐々に賢くなっていきます。

本番導入に向けたチェックリスト

本番環境へデプロイする前に、以下の3点を確認してください。

  1. System Promptの強制力: ユーザーの入力によってプロンプトインジェクション（役割の書き換え）が起きないか。
  2. フォールバックの挙動: 検索結果が0件だった時に、エラーにならずに適切なメッセージを返せるか。
  3. 応答速度: 複雑なプロンプトや評価プロセスを入れることで、レイテンシが許容範囲を超えていないか。

ハルシネーションを100%ゼロにすることは、現在のLLM技術では困難です。しかし、適切なプロンプトエンジニアリングによって、ビジネス利用に耐えうる「99%の信頼性」と「残りの1%に対する安全策」を構築することは十分に可能です。

もし、自社のRAGシステム構築において、「どうしてもハルシネーションが消えない」「プロンプトの調整に行き詰まっている」という課題がある場合は、他社の成功事例を参照するのも一つの手です。同じような課題をどのように乗り越え、実運用に乗せたのか。具体的なアーキテクチャや工夫を知ることは、何よりのヒントになるはずです。

まとめ

Rules - Section Image 3

本記事では、RAGシステムにおけるハルシネーション対策として、以下の4つのプロンプト戦略を解説しました。

  1. Strict Context Pattern: 外部知識を遮断し、コンテキストのみに依存させる。
  2. Source Attribution Pattern: 回答の各文にソースIDを付記させ、根拠を可視化する。
  3. Refusal & Clarification Pattern: 情報不足時には潔く回答を拒否し、捏造を防ぐ。
  4. RAG Evaluator Pattern: AIによる自動評価で品質をモニタリングする。

これらは明日からすぐに使える具体的なテクニックですが、RAGの品質向上への道のりはここで終わりではありません。検索精度の向上（ハイブリッド検索やリランキング）、ドキュメントの前処理、そして継続的な評価プロセスの構築が必要です。

これらの技術課題を乗り越え、実際に業務効率化と顧客満足度向上を実現した導入事例は多数存在します。「理論はわかったけれど、実際の運用イメージをもっと具体的に知りたい」という場合は、専門家に相談するか、公開されている成功事例を参照することをおすすめします。プロジェクトを成功に導くための、次なるヒントが見つかるでしょう。

RAGの嘘を封じるプロンプト設計図：ハルシネーションを抑制する実装テンプレート集 - Conclusion Image

コメント

コメントは1週間で消えます
0 / 150
コメントを読み込み中...