ハルシネーションを防ぐプロンプト設計10選｜業務投入前の検証手順まで解説

こんにちは！株式会社雲海設計の技術部です。

「LLMが存在しない社内規程を堂々と回答してきた」「見積もり計算で、参照しろと言った表を無視して数字を創作された」「RAGを入れたのに、取得したチャンクと違う答えが返ってきた」——2025年に生成AIの業務導入が一気に広がった結果、2026年に入ってからハルシネーションを防ぐプロンプトに関する相談が、週に複数件入ってくるようになりました。本記事では、業務システムに組み込んで壊れないハルシネーションを防ぐプロンプトの設計パターンを、指示制約・根拠提示要求・RAG併用などの10パターンと、本番投入前の検証手順までまとめて整理します。

• TL;DR

• ハルシネーションを防ぐプロンプトは「根拠の固定・出力の制約・逃げ道の用意」の3本柱で設計する

• 「知らない場合はI don't knowと答えよ」の一文だけで、業務ドメインの幻覚率は体感で3〜5割減る

• RAG併用時は「提供されたコンテキストのみを根拠にせよ」+ 引用ID要求がセット。片方だけでは漏れる

• プロンプトだけで幻覚はゼロにならない。評価セット＋自動検証＋Human-in-the-Loopの三層で詰める

• 本番投入前は「敵対的入力・境界ケース・長文」の3種の検証セットを最低30件ずつ用意する

なぜ2026年もハルシネーション対策が最優先課題なのか？

結論から言うと、モデルが賢くなっても、業務ドメインの固有情報に対する幻覚は消えないからです。2025年末に各社からリリースされた最新モデルは、一般知識の精度は大きく向上しましたが、社内規程・顧客マスタ・過去案件の数値といった学習に含まれていない情報については依然として平然と捏造します。Stanford HAIの2026 AI Indexでも、業務ドメイン特化タスクの幻覚率は汎用タスクの2倍以上というデータが示されています。

現場で起きている典型的な事故

• RAG無視型：取得したチャンクを渡しているのに、モデルが学習データ側の古い情報で答える

• 数値捏造型：売上・納期・見積額といった数字を「それっぽく」生成して返す

• 存在しない規程の引用：「就業規則第12条により〜」のように、ありもしない条文を堂々と出力

• 過剰な自信：根拠がないのに断定口調で答え、ユーザーが誤信してしまう

OpenAIが2025年に公開した技術レポートでも、「ハルシネーションは根絶できない現象」と明言されています。我々エンジニアに求められるのは、発生率を業務許容水準まで下げ、残ったリスクを検知・抑制する仕組みを入れることです。

この前提は、AIセキュリティ対策実装ガイド2026で整理した権限設計と同じ考え方で、「ゼロにはならない、だから多層で守る」という姿勢です。

ハルシネーションを防ぐプロンプトの3本柱とは？

実務で効くプロンプト設計は、「根拠の固定」「出力の制約」「逃げ道の用意」という3本柱に分解できます。10のパターンはすべてこの3柱のいずれか（または複数）に属します。

実務で効くプロンプト設計パターン10選

パターン1: コンテキスト限定（Closed-book制約）

最も効果が大きく、最も忘れられがちなパターンです。RAGで取得したチャンクを渡す際は、必ず「提供されたコンテキストのみを根拠にせよ」と明示します。

あなたは社内ドキュメントに基づいて回答するアシスタントです。
以下の【コンテキスト】のみを根拠として回答してください。
コンテキストに記載のない事項については「資料内に該当情報がありません」と答えてください。
あなたの事前知識は使用しないでください。

【コンテキスト】
{retrieved_chunks}

【質問】
{user_question}

パターン2: 引用ID要求

チャンクにIDを振り、回答末尾に使用したIDを必ず列挙させます。IDが空なら「根拠なし」と判定でき、後段のバリデーションが効きます。

パターン3: JSONスキーマ固定

自由回答をやめ、型と列挙値を縛ります。Pydanticなどでスキーマ検証を通し、壊れたら再試行させます。

{
  "answer": "string",
  "confidence": "high | medium | low",
  "source_ids": ["string"],
  "is_answerable": true
}

パターン4: I don't know許可

「分からない場合はI don't knowと答えてよい」と明示するだけで、業務ドメインの幻覚は体感3〜5割減ります。多くの現場で抜けています。

パターン5: 信頼度の自己申告

confidenceを3段階で出力させ、lowなら人間にエスカレーションします。完璧な自己評価はできませんが、閾値判定の入口としては十分使えます。

パターン6: Chain-of-Verification

回答後にモデル自身に「上記の回答に含まれる事実主張を列挙し、コンテキストで裏取りせよ」と実行させます。2段階にするだけで数値系の捏造が大きく減ります。

パターン7: Few-shotで「答えない例」を入れる

回答例だけでなく、「情報不足で答えない例」を意図的に混ぜるのがコツです。モデルは模倣するので、答えない行動も学習します。

パターン8: 役割と対象範囲の明示

「あなたは経理規程の範囲のみを扱うアシスタントです。人事・法務の質問には答えないでください」のようにスコープを絞ります。越境質問への捏造が止まります。

パターン9: 数値・日付の再計算強制

計算が絡む場合は、式を書かせてからコード実行（Function CallingやCode Interpreter）に投げます。LLMに暗算させると必ず間違えます。

パターン10: 出力前のセルフチェック項目

最後に「出力前に以下を確認せよ」とチェックリストを入れます。

• 回答がコンテキスト内に存在するか

• 数値・固有名詞がコンテキストと一致するか

• 該当なしの場合「該当情報がありません」と返したか

プロンプト全体のテンプレートはどう組み立てるか？

10パターンをすべて乗せた、業務投入向けのテンプレート例を示します。RAGを前提にしていますが、骨格はLLM API直叩きでも同じです。

## 役割
あなたは{domain}に関する社内アシスタントです。{domain}以外の質問には答えません。

## 回答ルール
1. 以下の【コンテキスト】のみを根拠としてください。事前知識は使いません。
2. コンテキストに記載がない場合は is_answerable=false として「該当情報がありません」と返してください。
3. 数値・日付はコンテキストからそのまま転記し、計算が必要な場合は式を明示してください。
4. 回答の根拠となったチャンクのIDを source_ids に必ず列挙してください。
5. 自信度を high / medium / low で自己申告してください。

## 出力形式（JSON）
{
  "answer": string,
  "is_answerable": boolean,
  "confidence": "high" | "medium" | "low",
  "source_ids": string[],
  "verification": string  // 回答内の事実主張をコンテキストと照合した結果
}

## コンテキスト
{chunks_with_ids}

## 質問
{user_question}

このテンプレートはナレッジ管理×生成AIの実装設計で扱ったRAG基盤と組み合わせて使う想定です。チャンクにID・出典メタデータが付いていないと、パターン2と10が機能しません。

プロンプトだけで足りない領域はどう補うか？

断言しますが、プロンプトだけで幻覚をゼロにはできません。2026年の業務運用で耐えるには、プロンプトの外側に検証層を重ねます。

多層防御の全体像

1. 入力層：質問分類器でスコープ外をリジェクト

2. プロンプト層：本記事の10パターンで抑制

3. 出力検証層：JSONスキーマ・引用ID存在チェック・数値の再計算

4. 自動評価層：評価セットでの定期回帰テスト

5. Human-in-the-Loop：confidence=low と高リスク業務は人間承認

評価層の作り込みはハーネスエンジニアリングのベストプラクティスで詳述しています。プロンプトを改修するたびに評価が回らない運用は、ほぼ確実に事故ります。

業務システム投入前の検証手順はどう組むか？

雲海設計で実案件に入る際は、本番投入前に以下の検証手順を必ず回しています。

特に重要なのは「境界ケース」

「該当情報がないとき、正しく該当なしと答えられるか」は、通常ケースの精度より重要です。ここが崩れると、ユーザーはLLMの回答を盲信するようになり、事故が顕在化しないまま積み上がります。

自社事例：経理問合せBotでの改善

ある中堅企業の経理問合せBot案件では、初期プロンプト（コンテキスト限定なし）でのハルシネーション率が約22%でした。本記事の10パターンを段階的に適用した結果、最終的に約3%まで低下し、残った3%もconfidence=lowで検知できるケースがほとんどでした。プロンプト改修だけで、評価・Human-in-the-Loopなしのケースです。

よくある質問

Q. 「I don't knowと答えよ」と指示すると、答えられる質問にも答えなくなりませんか？

A. 過剰防御は起こり得ますが、Few-shotで「答えるべき例」と「答えない例」を両方示せばバランスが取れます。実務では過剰防御より捏造のほうが事故が重いので、最初は厳しめに寄せて徐々に緩めるのが安全です。

Q. 最新モデルを使えばプロンプトの工夫は不要になりませんか？

A. なりません。モデルの汎用性能は上がり続けていますが、社内ドキュメントなど学習に含まれない情報の幻覚は構造的に消えません。プロンプト設計・RAG・評価の三点セットは、2026年以降も必須スキルです。

Q. JSON出力を強制するとクリエイティブな回答ができなくなりませんか？

A. 業務システムでは「クリエイティブな回答」はほぼ不要です。型を固定したほうが下流処理が安定し、バリデーションも効きます。ユーザーに見せる自然文はanswerフィールドに入れれば済みます。

Q. プロンプトに含めるコンテキストが長すぎると精度が落ちるのでは？

A. その通りです。Lost in the Middle問題があるため、RAG側で関連度上位5〜10チャンク程度に絞り、重要なものを先頭と末尾に配置するのが定石です。検索精度が低いとプロンプトでは救えません。

Q. どのモデルがハルシネーションに強いですか？

A. 2026年4月時点では、Anthropic ClaudeとGoogle Geminiが「I don't know」を素直に返す傾向が強く、OpenAI系はやや饒舌ですがFunction Callingとの相性が良いです。用途によって選び、評価セットで実測するのが唯一の正解です。

まとめ：次のアクション

ハルシネーションを防ぐプロンプトは、「根拠の固定・出力の制約・逃げ道の用意」の3本柱＋10パターン＋多層検証で組み立てます。プロンプト単体で完璧を目指さず、評価とHuman-in-the-Loopを含めた設計に倒すのが、2026年の業務運用に耐える姿勢です。

雲海設計では、業務システムへの生成AI組み込み・RAG設計・プロンプト評価ハーネスの構築まで、伴走型で支援しています。PoCで止まっている案件、本番運用で幻覚に困っている案件があれば、DXソリューションやITコンサルティングのページもご覧いただき、お気軽にお問い合わせください。