LLM が「つい」もっともらしい答えを作ってしまう場所に、狙い撃ちで訂正を仕込む

経緯

LP に設置しているサポートチャットボットは、ナレッジベースの内容をシステムプロンプトとして LLM に渡し、ユーザーの質問に答える仕組みになっている。運用する中で見えてきたのは、「正確に答えてください」という一般的な指示だけでは防ぎきれない、特定のパターンで繰り返し起きるもっともらしい間違いがあるということだった。

LLM は大量の一般的な技術知識を学習している。だからこそ、聞かれた瞬間にその一般知識を組み合わせて、いかにも本当らしい答えを作ってしまう。厄介なのは、その答えがもっともらしすぎて、間違っていることに気づきにくい点だ。

具体例 1: レンタルサーバーの SSH ホスト名を推測してしまう

ユーザーから「SSH のホスト名がわかりません」と質問が来ると、LLM は一般的な傾向から「〇〇のような形式が多いです」と、具体的な文字列パターンを提示したくなる。実際、いくつかのレンタルサーバーには典型的なホスト名の傾向がある。

しかし、これは危険な親切だ。ホスト名の形式は契約しているプラン・契約時期・サーバー会社によって細かく異なる。同じサーバー会社でも、プランが違えば形式が違うことがある。LLM が「よくある形式」を提示しても、それがそのユーザーの契約と一致する保証はどこにもない。むしろ違っていた場合、ユーザーは「アプリの案内どおりに探しても見つからない」という、元の疑問とは別の混乱に陥ってしまう。

正しい答えは「お使いのレンタルサーバー会社の管理画面で SSH 接続情報を確認し、表示されている文字列をそのままコピーして入力してください」であって、具体的な形式のサンプルを提示することではない。だが、この「答えない方が正しい」という判断は、一般的な「正確に答えよ」という指示だけからは導き出しにくい。

具体例 2: 「変換が必要」という、もっともらしいが誤った案内

もう一つの例が、さくらインターネットが発行する秘密鍵の形式に関するものだ。この鍵は PKCS#8 という形式で発行されるが、アプリの v1.6.3 以降はこの形式をそのまま読み込めるよう対応済みだ。

ところが、LLM に「秘密鍵が読み込めません」という質問だけを渡すと、一般的な SSH の知識から「PuTTY 形式（.ppk）への変換が必要かもしれません」という、もっともらしいが今のバージョンでは不要かつ的外れな案内をしてしまうことがある。これも「一見親切で技術的に筋が通っているが、実際には誤り」というパターンだ。正しい答えは「アプリを最新版に更新すれば、ダウンロードした鍵をそのまま指定するだけで動作します」というシンプルなものだが、LLM は一般論としての変換手順の方をもっともらしく感じてしまう。

なぜ一般的な指示だけでは足りないのか

「正確に答えてください」「わからないことは推測しないでください」という指示は、システムプロンプトの冒頭に一般論として書くことはできる。だが、こうした指示は抽象的すぎて、個別の落とし穴には効きにくい。LLM からすれば、SSH ホスト名の形式を答えることも、鍵の変換手順を答えることも、「一般的には正しそうな技術知識」であり、それがこの製品固有の事情によって間違っているということまでは、抽象的な指示からは読み取れない。

対策: 落とし穴のすぐそばに、狙い撃ちの訂正を置く

そこで採った方法が、ナレッジベースの中で、その質問・その事実が書かれているまさにその場所に、ユーザーには表示されない形の注記を添えることだった。「この質問が来たとき、こういうもっともらしい間違いをしがちだが、実際はこうだ」という訂正を、関連する FAQ 項目のすぐ隣に置く。

抽象的な「ハルシネーションするな」という一般則を 1 箇所に書くのではなく、間違いが実際に起きる場所ごとに、個別の予防接種を打っていくイメージだ。新しい落とし穴に気づくたびに、その該当箇所へピンポイントで注記を追加していく運用になっている。ナレッジベース全体を俯瞰した一般論よりも、局所的な訂正の積み重ねの方が、実際の応答品質には効きやすい。

まとめ

LLM の「もっともらしさ」は、しばしば正確さと見分けがつかない。ユーザーからすれば、自信を持って提示された具体的な情報ほど信頼したくなるが、それが的外れであれば信頼を裏切ることになる。汎用的な精度向上の指示だけに頼るのではなく、間違いが実際に起きる場所を特定し、そこに個別の訂正を置いていくという地道な積み重ねが、専門的で的確な回答を支える土台になっている。