LLMに「根拠」を求めるプロンプト設計：正確性を上げる現実的アプローチ

「根拠を示して」だけでは精度が上がらない

生成AIに対して不安を感じる瞬間の多くは、もっともらしい文章が出るのに、どこまで信じてよいか分からないときです。そこで多くの人が最初に試すのが「根拠を示して」「理由も書いて」という指示です。しかし、これだけで正確性が劇的に上がることは少なく、場合によっては逆に危険になります。なぜなら、モデルは「根拠らしい説明」を作ることも得意だからです。

ここで押さえるべきは、生成AIの得意分野が「文章として筋が通る説明」を作ることであって、「外部世界の真偽を検証すること」ではない、という点です。入力に根拠が含まれていないのに根拠を要求すると、モデルは空白を埋めるために推測を混ぜてしまいがちです。結果として、誤った内容に説得力が付くという、いちばん厄介な形になります。説明が滑らかであるほど、人間は疑いにくくなります。根拠要求が誤りを見えにくくするのは、この心理とモデルの性質が噛み合ってしまうからです。

また「根拠」と一言で言っても、実務で求めるものは状況によって違います。入力文書に書かれている箇所を示してほしいのか、一般知識としての理由づけがほしいのか、計算や推論の過程がほしいのか、仮説としての説明がほしいのか。ここが曖昧なままだと、モデルはそのときどきで異なる種類の根拠を混ぜ、読者は「根拠があるように見えるが、どのタイプの根拠なのか分からない」状態になります。

さらに、根拠要求は文章を冗長にしやすい側面もあります。理由づけの段落が増え、結論が遅れ、読み手の意思決定に必要な情報が埋もれます。正確性を高めたいはずが、判断しにくい文書が出来上がる。これも現場でよく起きる失敗です。

結局、「根拠を書いて」という一文は、万能の安全策ではありません。安全に寄せたいなら、まず根拠の出所と範囲を決める必要があります。モデルにやらせるべきことは、根拠があるふりをすることではなく、根拠の種類を明確にし、推測が混ざるなら混ざると分かる形で提示することです。そのための設計が次の論点になります。

根拠の種類を分けると、設計が急に簡単になる

根拠の扱いを難しくしている原因は、「根拠」という言葉が幅広すぎることです。ここを分解すると、プロンプトに書くべき条件が見えてきます。実務で扱いやすい分け方として、少なくとも次の四つを意識すると整理が進みます。

一つ目は、入力文書に基づく根拠です。会議メモ、要件定義、FAQ、顧客の問い合わせ文など、手元のテキストに答えが含まれているタイプです。この場合の安全策は明快で、「与えた文書に書かれていることだけを根拠にする」「書かれていないことは推測しない」「不明なら不明とする」をルール化します。さらに強くするなら、根拠として使った文の引用や、該当箇所の要約を短く付ける形式にします。これにより、読み手は検証できますし、モデルが勝手に補完する余地も減ります。

二つ目は、一般知識に基づく根拠です。たとえば「良いプロンプトに必要な要素」「よくある失敗」「文章構成の定石」など、広く共有されている知識から説明する場合です。このタイプは便利ですが、最新情報や専門領域に入ると誤りが増えます。だからこそ、プロンプトで「一般的な範囲で述べる」「確度が低い場合は断定しない」「例外があり得ることを明記する」といった表現ルールを設計しておくと安全です。必要なら「どこが一般論で、どこが推測かを分けて書く」と指示すると、読み手の受け取り方が安定します。

三つ目は、計算や変換に基づく根拠です。数値の再計算、条件の整理、文章の変換、要約など、手順が明確な作業では、根拠は「計算結果」や「変換ルール」になります。この場合は、途中の計算や変換の要点を簡潔に示すことが有効です。ポイントは、細かい過程を長々と書かせるのではなく、重要な前提と結果の整合だけを確認できる形にすることです。読み手が検算できる程度の情報があれば足ります。

四つ目は、仮説としての根拠です。市場の反応、ユーザー心理、原因推定など、外部情報が不足しているのに結論を出したいときは、根拠は確定的なものではなく仮説になります。このタイプは、推測を推測として扱うことが何より重要です。そこで、プロンプト側で「仮説」「想定」「未検証」を明示し、確度や検証方法も添える形式にすると、誤解が減ります。仮説の根拠は、事実ではなく推論なので、断定調を避けるルールが効きます。

この四分類で考えると、プロンプトに書くべきことは「根拠の出所」「使ってよい範囲」「不明時の扱い」「出力での表示方法」の四点に収束します。根拠を求めるのではなく、根拠を管理する。そう捉えると、設計は急にシンプルになります。

安全な出力に寄せる言い方とフォーマット

根拠の扱いを設計しても、最後に読み手が誤解したら意味がありません。安全性を上げるには、言い方とフォーマットで「どこまで確かか」を見える化することが効果的です。ここでは、実務でそのまま使える考え方をまとめます。

まず言い方の基本は、断定の抑制です。特に根拠が入力文書にない場合、断言は避けるべきです。「必ず」「間違いなく」「唯一」などの強い表現は、読み手に誤解を与えやすい。代わりに「一般的には」「多くの場合」「可能性がある」「条件次第」といった限定を置き、どの条件で成り立つのかを添えます。文章が弱くなるのではなく、責任の範囲が明確になると考える方が実務的です。

次に有効なのが、事実と推測の分離です。混ざっていると危険ですが、分けて並べるだけで読み手は判断しやすくなります。たとえば「文書に書かれている事実」「そこから言える解釈」「追加で確認すべき点」という順序にすると、検証可能性が上がります。特に社内文書の要約や顧客対応文の下書きでは、この分離が事故を減らします。

また、根拠を示すときは“出典の範囲”を明示するのが効きます。たとえば「以下は提示された文章の範囲での整理」「外部情報は参照していない」「一般知識としての補足を含む」といった注記です。これがあるだけで、読み手はその文章をどう扱うべきか判断できます。逆に、どこまでが与件でどこからが補足かが不明だと、誤りが混ざっても見抜きにくくなります。

フォーマットの面では、長い説明よりも、短い根拠と結論のセットが有効です。結論を一文で置き、その直後に「根拠：」として根拠を一文か二文で添える。これだけでも、断定の暴走が減り、読み手の判断も速くなります。さらに安全に寄せるなら、「不確実性：」や「確認方法：」を短く添えます。こうすると、モデルが分からないことを分からないと言いやすくなり、読み手も次の行動に移れます。

最後に、プロンプトの設計方針として「分からない場合の振る舞い」を明記しておくのは非常に重要です。不明点を勝手に埋めない、必要な追加情報を質問として出す、仮説として出すなら仮説と明記する。この方針があるだけで、もっともらしい誤答の確率は下がります。根拠の設計とは、正確性を上げるというより、誤りが混ざったときにそれが見える形にすることでもあります。 生成AIに根拠を求めるとは、モデルに真偽判定能力を期待することではありません。根拠の種類と範囲を決め、推測は推測として扱い、読み手が検証できる形に整えることです。この運用を入れると、生成AIは「便利だけど怖い道具」から「使いどころが分かる道具」に変わります。まずは次に依頼するとき、根拠の出所を一つだけでいいので指定してみてください。そこから安全性は確実に上がります。