Marketechlabo

生成AIの嘘を減らすプロンプト手法集

概要

生成AIの嘘を減らすプロンプト手法集

AIが事実と異なる情報を生成してしまう現象は「ハルシネーション」と呼ばれ、AIを活用するうえで常に意識すべきリスクのひとつである。本稿では、このハルシネーションのリスクを低減するための実践的なプロンプト手法を、カテゴリ別に整理して紹介する。各手法にはチャットUIですぐに使えるプロンプト例を付した。

なお、いずれの手法もリスクを「低減」するものであり、完全に防止するものではない点に留意されたい。重要な情報は必ず人間が一次ソースで確認すること。また、手法の効果はモデルや状況によって異なる。

1. 情報源・根拠を求める手法

1-1. 出典・ソースの明記を要求

AIに対して、回答に含まれる情報の出典や根拠を必ず示すよう求める方法である。URL、書籍名、論文名などの具体的な出典を併記させ、出典が見当たらない情報については「出典不明」と明記させることで、回答の信頼性を判断しやすくする。

プロンプト例

以下について教えてください。ただし、各情報には必ず出典(URL、書籍名、論文名など)を併記してください。出典がない情報は「出典不明」と明記してください。

[質問内容]

この手法の長所は、後から人間が事実確認を行う際の手がかりになる点と、出典を意識させることで無根拠な情報の生成を抑制する傾向がある点である。

一方で、短所として見過ごせないのは、LLMが架空の出典をもっともらしく生成してしまう問題である。存在しないURLや架空の論文タイトルが自然な文体で出力されることは珍しくなく、出典を要求すること自体が架空出典の生成を誘発するリスクがある。出典が付いているとつい信頼してしまいがちだが、出典自体が捏造である可能性を常に疑う必要がある。

ニュース、統計データ、学術的情報の確認といったタスクで効果を発揮するが、効果の大きさとしては5段階中2程度である。この手法は単独で使うと逆効果になりうるため、必ず出典の実在を人間が確認するワークフローとセットで運用すること。

1-2. 直接引用の要求

情報源からの逐語的な引用を求める方法である。引用部分を「」で囲んで提示させ、引用ができない場合にはその旨を明記させる。

プロンプト例

回答には必ず原文からの直接引用を「」で囲んで含めてください。引用できない場合は、その旨を明記してください。

長所としては、引用部分を独立して検証しやすいことと、引用形式にすることでユーザーが「ここは検証すべき箇所だ」と意識しやすくなることが挙げられる。

短所としては、LLMは架空のテキストを引用符の中に流暢に生成できるため、引用を求めるだけでは捏造を防げない点がある。また、引用可能な情報が限られるという制約もある。文献調査や法律文書の確認といったタスクに向いており、効果の大きさは5段階中2程度である。

2. 不確実性を明示させる手法

2-1. 「わからない」と言わせる

AIに対して、確実でない情報については素直に「わからない」と答えさせる方法である。すべての手法の中で最も基本的かつ重要な手法であり、他の多くの手法と組み合わせて使うべきものである。

プロンプト例

以下について答えてください。ただし、確実でない情報や知らないことについては「わかりません」「情報がありません」と正直に答えてください。推測で答えないでください。

[質問内容]

長所は、誤情報のリスクが大幅に減ること、そして信頼できる情報だけが得られるようになることである。

短所としては、得られる情報量が減る可能性があることと、AIが過度に慎重になり、実際には知っていることまで「わかりません」と答えてしまうことがある点が挙げられる。

医療相談、法律相談、重要な意思決定など、誤情報の影響が大きい場面全般で効果を発揮し、効果の大きさは5段階中5と最も高い。

2-2. 確信度の数値化

各情報にどの程度確信があるかを数値で示してもらう方法である。0.0から1.0までのスケールで確信度を付記させることにより、情報ごとの確実性の濃淡をユーザーが意識できるようにする。

プロンプト例

回答する際、各情報の後に確信度を(確信度: 0.0〜1.0)の形式で付けてください。
- 1.0 = 100%確実
- 0.8以上 = かなり確実
- 0.5〜0.7 = やや不確実
- 0.5未満 = 推測レベル

長所は、情報ごとに確実性の濃淡をユーザーが把握でき、確信度が低い部分を優先的に検証する指針になることである。

短所としては、LLMが出力する数値は校正された確率ではなく、「確信度が高そうに見えるテキスト」を生成しているにすぎないという根本的な限界がある。ハルシネーションしている情報に確信度0.9を付けることは十分ありうる。さらに、数値が付いていると信頼感が増し、かえってユーザーの批判的検証が弱まるリスクもある。

リサーチや分析といったタスクで有効であり、効果の大きさは5段階中3程度である。確信度の数値そのものを信頼するのではなく、「ここは確認すべき」という目印として使うことが重要である。

2-3. 曖昧表現の禁止

「おそらく」「たぶん」「~と思われる」などの曖昧な表現を使わせず、確実なことと不明なことを明確に二分させる方法である。

プロンプト例

回答では「おそらく」「たぶん」「~と思われる」などの曖昧な表現は使わず、確実なことは断定的に、不確実なことは「不明」と答えてください。

長所は、情報の確実性が明確に二分される点にある。

短所としては、本来不確実な情報を断定調で述べてしまうリスクが挙げられる。曖昧表現を禁止すると、AIが「不明」と言うべき場面で断定に倒れることがある。また、ニュアンスや程度の差が伝わらなくなるという問題もある。

事実確認やデータ分析に向いているが、効果の大きさは5段階中2程度にとどまる。この手法は必ず2-1「わからないと言わせる」とセットで使うこと。単独で使うと逆効果になりうる。

3. 思考プロセスを構造化する手法

3-1. ステップバイステップ思考

結論に至るまでの思考過程を段階的に示してもらう方法である。まず確実に知っている事実を列挙し、それらから論理的に導ける結論を検討し、不確実な部分を明示したうえで、最終的な回答を提示させる。

プロンプト例

以下の質問に答える前に、次のステップで考えてください:
1. まず、確実に知っている事実を列挙
2. それらの事実から論理的に導ける結論を検討
3. 不確実な部分や推測が必要な部分を明示
4. 最後に、総合的な回答を提示

[質問内容]

長所は、論理の飛躍を防げることと、誤りがあった場合にどのステップで間違えたかを特定しやすいことである。

短所としては、回答が長くなることと、単純な質問に対しては過剰な手法となることが挙げられる。

複雑な分析、問題解決、推論が必要なタスクで効果を発揮し、効果の大きさは5段階中4である。

3-2. 反証・批判的視点の検討

自分の回答に対する反論や別の可能性を検討させる方法である。通常の回答を行った後に、別の立場(厳しい批評家や反対論者など)から問題点を指摘させるペルソナ切り替えの手法も含む。

プロンプト例(自己反証型)

質問に回答した後、以下も検討してください:
- この回答が間違っている可能性
- 別の見方や解釈
- 反対意見や例外ケース

プロンプト例(ペルソナ切り替え型)

まず通常通り回答してください。その後、厳しい批評家の立場から、その回答の問題点、誤りの可能性、不十分な点を指摘してください。

長所は、多角的な視点が得られることと、バランスの取れた回答になりやすいことである。

短所としては、回答が長くなることに加え、ペルソナを切り替えても同じモデルの知識限界は変わらないため、知識の欠如に起因するハルシネーションには効きにくいという点がある。

議論、分析、意思決定、企画立案、論文作成といったタスクに適しており、効果の大きさは5段階中3.5である。

4. 知識範囲を制限する手法

4-1. 提供情報のみで回答させる

ユーザーが与えた情報の範囲内だけで回答させる方法である。RAG(検索拡張生成)の考え方をチャットUI上で手動で行うものであり、参考情報をプロンプトに貼り付けたうえで、それ以外の知識は一切使わないよう指示する。

プロンプト例

以下の【情報】セクションに記載された内容のみを使って質問に答えてください。この情報以外の知識は一切使わないでください。情報にない場合は「提供された情報にはありません」と答えてください。

【情報】
[ここに参考情報を貼り付け]

【質問】
[質問内容]

長所は、内部知識による捏造リスクを大幅に低減できることと、制御性が高いことである。

短所としては、事前に情報を用意する必要があること、AIの持つ知識を活用できないこと、そして提供情報の誤読や行間を補完した過剰推論のリスクが残ることが挙げられる。

文書要約、契約書分析、マニュアル参照といったタスクに特に有効であり、効果の大きさは5段階中5と最も高い。

4-2. 時期の明確化

情報の時期やモデルの知識の限界を明示させる方法である。時事的な情報には「〇年〇月時点」と付記させ、知識の範囲外と判断される最新情報についてはその旨を前置きさせる。

プロンプト例

回答する際、以下を明記してください:
- 時事的な情報には「〇年〇月時点」と付記
- 知識の範囲外と判断される最新情報については「私の知識は〇年〇月までです」と前置き

長所は、情報の鮮度が明確になることと、古い情報を最新と誤認するリスクが減ることである。

短所としては、最新情報が得られないことと、モデルが自身の知識カットオフを正確に認識していない場合があることが挙げられる。

ニュース確認、トレンド分析、制度や法律に関する質問に適しており、効果の大きさは5段階中3である。

5. 自己検証の手法

5-1. 自己チェックリスト

AIに自分の回答をチェックリストに照らして検証させる方法である。事実と推測の区別、数値や日付の正確性、論理的矛盾の有無、表現の慎重さなどの観点から自己点検を行わせる。

プロンプト例

回答を作成した後、以下のチェックリストで自己検証してください:
□ 事実と推測を明確に区別したか
□ 具体的な数値や日付は正確か
□ 論理的な矛盾はないか
□ より慎重な表現にすべき箇所はないか

長所は、自己修正の機会を与えることで、明らかな矛盾や不整合を検出できる場合があることである。

短所としては、自分の知識不足に起因する誤りは自己検証では検出できないことと、チェックリストを形式的にクリアするだけの出力になることがある点が挙げられる。

レポート作成や分析に適しており、効果の大きさは5段階中3である。

6. 出力形式を制御する手法

6-1. 確実性を区分した構造化出力

情報を確実性のレベルで区分して出力させることで、事実と推測の混在を防ぐ方法である。表形式や区分された箇条書きなど、出力の形式はタスクに応じて選択する。

プロンプト例(表形式)

以下の形式で情報を整理してください:
| 項目 | 内容 | 確実性(高/中/低) | 根拠 |
|------|------|-------------------|------|

プロンプト例(区分型)

回答は以下の区分で整理してください:
- 確実な事実:
- 推測・可能性:
- 不明な点:

長所は、情報の種類と確実性が視覚的に明確になることと、自由記述と比べて創作の余地が減ることである。

短所としては、柔軟な説明が難しくなること、すべての情報がこの形式に適するわけではないこと、そして区分自体をLLMが誤る可能性がある(推測を「確実な事実」に分類するなど)ことが挙げられる。

比較分析、データ整理、要約といったタスクに適しており、効果の大きさは5段階中4である。

7. 役割・立場を設定する手法

7-1. 慎重な専門家として

慎重で保守的な専門家の立場で回答させる方法である。確実でない情報は提供せず、推測が必要な場合には必ずその旨を明記させ、専門家として責任を持てる情報のみを提供させる。

プロンプト例

あなたは極めて慎重な専門家です。確実でない情報は提供せず、推測が必要な場合は必ずその旨を明記してください。専門家として責任を持てる情報のみを提供してください。

長所は、信頼性の高い情報のみが得られる傾向があることである。

短所としては、情報量が限定的になることと、「専門家」を演じることでかえって自信過剰な断定が増える場合もあることが挙げられる。

専門的アドバイスや重要な判断に適しており、効果の大きさは5段階中4である。

7-2. ファクトチェッカーとして

事実確認に特化した役割を与える方法である。提供された情報について、検証可能な事実、検証困難な主張、明らかに疑わしい点を区別して報告させる。

プロンプト例

あなたはファクトチェッカーです。提供された情報について:
- 検証可能な事実
- 検証困難な主張
- 明らかに疑わしい点
を区別して報告してください。

長所は、批判的視点が強化されることである。

短所としては、創造的な回答は期待できないことと、ファクトチェッカー役であっても知識の欠如に起因する誤りは避けられないことが挙げられる。

情報検証やニュース確認に適しており、効果の大きさは5段階中3である。

8. 質問の仕方を工夫する手法

8-1. 質問を分割する

一度に複数の論点を含む質問をするとハルシネーションが起きやすくなるため、質問を小さく分割して一つずつ確認していく方法である。

プロンプト例

(複数の論点がある場合、一度に全部聞かず、以下のように分けて質問する)

まず1点目の質問です:[質問A]

回答を確認した後に続ける。

ありがとうございます。次に2点目の質問です:[質問B]

長所は、各回答の正確性を個別に検証しやすいことと、モデルの注意が分散しにくく一つの論点に集中した回答が得られることである。

短所としては、やりとりの回数が増えることと、論点間の関係性が見えにくくなることがある点が挙げられる。

複雑な調査や多面的なテーマの質問に適しており、効果の大きさは5段階中4である。

8-2. 追加質問で深掘りする(マルチターン検証)

一度得た回答に対して追加質問を行い、ハルシネーションを検出する方法である。ハルシネーションは深掘りすると矛盾や曖昧さが露呈しやすいという特性を利用する。

プロンプト例

(最初の回答を得た後)
先ほどの回答の中の「〇〇」について、もう少し詳しく説明してください。その根拠は何ですか?
(さらに確認)
「〇〇」という部分は本当に正しいですか?別の解釈や可能性はありませんか?

長所は、ハルシネーションは深掘りすると辻褄が合わなくなることが多く検出率が上がることと、追加のコストや準備が不要であることである。

短所としては、やりとりの回数が増えることと、深掘りしても一貫したハルシネーションを維持する場合もあることが挙げられる。

あらゆる場面で汎用的に有効な手法であり、効果の大きさは5段階中4.5と非常に高い。

8-3. 望ましい回答例を示す(Few-shot)

「こう答えてほしい」という具体例を数個示すことで、回答形式や不確実性の表現方法をモデルに学習させる方法である。

プロンプト例

以下の形式で回答してください。まず例を示します。

質問:日本の人口は?
回答:総務省統計局の推計によると、2024年1月時点で約1億2400万人です。(ただし最新の数値は変動している可能性があります)

質問:火星に生命はいますか?
回答:2024年時点では、火星に生命が存在するという確定的な証拠は見つかっていません。

質問:〇〇の創業年は?
回答:確実な情報を持っていないため、わかりません。公式サイト等でご確認ください。

では、以下の質問に同じ形式で回答してください:
[質問内容]

長所は、「わからない場合の答え方」を具体的に示せるため遵守率が高いことと、指示文で長々と説明するよりも例示の方がモデルに意図が伝わりやすいことである。

短所としては、例の作成にやや手間がかかることと、例に引きずられて回答の幅が狭くなることがある点が挙げられる。

定型的な質問応答や繰り返し使うプロンプトのテンプレート化に適しており、効果の大きさは5段階中4である。

9. プログラミング・技術情報に特化した手法

プログラミングに関する質問では、一般的な質問とは異なる特有のハルシネーションが起きやすい。存在しない関数やメソッドの創作、間違ったimport文、存在しないパラメータの提案などがその代表例である。以下の手法はこうした技術特有の問題に対処するためのものである。

プロンプト例

[言語/フレームワーク名]で[やりたいこと]を実装する方法を教えてください。
ただし以下の点に注意してください:

1. 実際に存在する関数・メソッドのみを使用
2. 可能な限り公式ドキュメントのURLを併記
3. バージョン情報を明記(例:Python 3.9以降、React 18.x)
4. 不確実な場合は「要確認」「ドキュメントで確認推奨」と明記
5. 代替手段がある場合は併記

もし該当する標準的な方法が存在しない場合は、その旨を明確に伝えてください。

特に効果的な組み合わせ

プログラミング関連のハルシネーションを抑えるには、上記のプロンプトに加えて、いくつかの要素を組み合わせると効果が高まる。公式ドキュメントの参照を求め「この機能は[公式ドキュメントURL]で確認できます」という形式で併記させること、「実際に動作確認することを推奨します」と動作確認を促す一文を添えること、「この関数はバージョンX.X以降で利用可能」のようにバージョン依存性を明記させること、そして「もし動作しない場合は、代わりに〇〇を試してください」と代替案の提示を求めることが有効である。

効果の大きさ

5段階中4である。

よくある捏造パターンと対策

LLMがプログラミングで起こしやすい典型的な捏造パターンを知っておくことも重要な対策となる。架空の便利メソッドが提案された場合には「標準ライブラリにこの機能はありますか?」と確認する。存在しないオプションやパラメータが出てきた場合には「このパラメータの公式ドキュメントでの説明は?」と問い返す。間違ったimport文が含まれている場合には「正確なimport文とパッケージ名を確認」するよう求める。こうした問い返しの習慣をつけることで、捏造されたコードをそのまま使ってしまうリスクを大幅に減らせる。

実際の捏造例と対策

具体的な例で見てみよう。「Pythonでリストをシャッフルする方法を教えて」という質問に対して、AIが list.shuffle() という存在しないメソッドを提案してしまう可能性がある。

悪い例:「Pythonでリストをシャッフルする方法を教えて」
→ AIが「list.shuffle()」という存在しないメソッドを提案する可能性

良い例:「Pythonでリストをシャッフルする方法を教えてください。
標準ライブラリの実在するメソッドのみ使用し、
正確なimport文も含めてください。動作確認済みのコードでお願いします。」
→ 正しく「import random; random.shuffle(list)」を提案

このように、プロンプトの段階で「実在するメソッドのみ」「正確なimport文を含める」といった制約を明示するだけで、正しいコードが得られる確率が大きく向上する。

手法の組み合わせ例

これらの手法は単独でも効果があるが、タスクの性質に応じて適切なものを選択し、組み合わせて使うことで効果が高まる。ただし、互いに矛盾する指示を同時に課さないよう注意が必要である。

たとえば「曖昧表現の禁止」(2-3)を「わからないと言わせる」(2-1)なしで使うと、不確実な情報が断定調で出力されるリスクがある。また「提供情報のみで回答させる」(4-1)と「出典の明記を要求」(1-1)を同時に使うと、提供情報の範囲外の知識で出典を補完しようとする矛盾が生じうる。

組み合わせの基本方針は、まずタスクの種類から主となる手法を選び、その手法の弱点を補う手法を併用するという考え方である。

組み合わせ例(重要な意思決定の場合)

以下について教えてください。ただし、次のルールを守ってください:

1. 確実でない情報は「わかりません」と答えること
2. 回答は「確実な事実」「推測」「不明」に区分して整理すること
3. 最後に、回答全体の限界や注意点をまとめること

[質問内容]

この例では「わからないと言わせる」(2-1)を軸に、「確実性を区分した構造化出力」(6-1)で事実と推測の混在を防ぎ、最後に自己検証的なまとめを加えている。いずれも「不確実性を明示する」という同じ方向を向いた手法であり、互いに矛盾しない。

状況別の使い分けガイド

状況おすすめの組み合わせ
重要な決定をする時「わからない」と言わせる + 提供情報のみで回答
調査・リサーチ出典要求 + 確実性区分の構造化出力 + 追加質問で深掘り
複雑な分析ステップバイステップ + 反証・批判的視点
事実確認提供情報のみで回答 + 確実性区分の構造化出力
学習・勉強ステップバイステップ + 質問分割
プログラミング公式ドキュメント要求 + 完全なコード要求 + バージョン明記
繰り返し使うテンプレートFew-shot例示 + 「わからない」と言わせる