検索を捨てた瞬間、LLMは賢くなる: プロンプト設計とRAGの本当の接点

May 30, 2026

1 min read

2 views

84%

なぜ「いい質問」をしても、答えがズレるのか

生成AIを使っていると、こんな違和感にぶつかります。指示は明確にした。文脈も足した。例も入れた。なのに、なぜか答えが浅い、古い、あるいは会社の事情をまるで知らない。多くの人はこの失敗を「プロンプトが下手だった」と考えますが、問題はもっと根深いところにあります。

実は、LLMに必要なのは「うまい聞き方」だけではありません。何を聞くべきかを、どこから持ってくるかです。ここに、プロンプトエンジニアリングとRAGの本質的な接点があります。前者はモデルの思考を整える技術、後者はモデルの記憶を外部化する技術です。つまり、1つは問いの設計、もう1つは知識の供給設計。この2つを混同すると、いつまでも「会話は上手いのに、実務では弱いAI」のままになります。

良いプロンプトは、良い答えを引き出す。だが、正しい知識がなければ、どれだけ良い質問でも正しい答えには届かない。

この当たり前のようで見落とされがちな事実が、AI活用の成否を分けます。

プロンプトは「思考の型」、RAGは「記憶の型」

プロンプト設計の基本には、明確な指示、コンテキスト、例示、ペルソナ、ステップ分解、出力形式の指定などがあります。これらはすべて、モデルの出力を安定させるための工夫です。たとえば、単に「契約書を要約して」と頼むのと、「法務担当者向けに、争点、リスク、修正候補を箇条書きで整理して」と頼むのでは、出力の精度がまるで違います。

これは、人に仕事を依頼する時と似ています。優秀な人でも、目的も条件も不明なままでは期待外れの成果になります。逆に、役割、目的、制約、望むフォーマットが揃うと、同じ人でも成果が一段上がる。プロンプトエンジニアリングは、まさにこの認知の足場かけを行う技術です。

一方でRAGは、別の問題を解決します。モデルが内部に持っていない情報、あるいは持っていても信用できない情報を、検索で取りに行ってから答えさせる。ここで重要なのは、LLMは検索エンジンの代用品ではないという点です。LLMは「知っていることを思い出す」のは得意でも、「膨大な社内文書から正しい根拠を探す」のは苦手です。なぜなら、生成モデルは本質的にもっともらしい文章を作る装置だからです。

つまり、両者は役割が違います。

プロンプトは、思考の方向を整える
RAGは、思考の材料を整える

この違いを理解すると、AI導入の議論は一気にクリアになります。精度が悪い時に、プロンプトだけをいじっても改善しないことがあるのは、答えの問題ではなく、入力知識の問題だからです。

LLMにキーワード検索をさせると失敗しやすい理由

「社内FAQをLLMに聞けばいい」「検索窓の代わりにチャットを置けばいい」という発想は、一見合理的に見えます。しかし、ここに大きな落とし穴があります。LLMはキーワードの一致を前提にした情報探索が得意ではないのです。

キーワード検索は、たとえば「旅費精算　上限」「有給　申請　締切」のように、語の一致や近さを頼りに候補を絞ります。これはルールが単純なので強い。一方LLMは、文脈から意味を補って自然な答えを作ることに優れています。ところが、この「意味を補う」性質が、検索には裏目に出ます。つまり、検索ではなく補完をしてしまう。

たとえば、社内規定に「出張時の宿泊費上限は地域区分ごとに異なる」と書いてあるとします。ユーザーが「大阪出張のホテル代はいくらまで？」と聞いた時、キーワード検索なら文書内の該当箇所を正確に見つける可能性があります。しかしLLMだけに聞くと、一般論としてそれらしい数字を作ってしまうかもしれない。ここで怖いのは、答えが完全な嘘ではなく、半分正しく半分違うことです。人は半分正しい答えを最も信じやすいからです。

この問題は、単なる技術上の制約ではありません。むしろ、LLMを「知識の倉庫」と誤解することから生まれる構造的な失敗です。LLMは倉庫ではなく、言語で推論する編集者に近い。編集者に原稿を渡さずに「社内ルールを調べて」と頼んでも、まともな仕事はできません。

そこでRAGが必要になります。まずベクトル検索で関連文書を取り出し、その上でLLMに「この文書群だけを根拠に回答せよ」と指示する。すると、LLMは知識を創作する役ではなく、与えられた証拠を要約し、整形し、判断可能な形に変える役に変わります。

検索の失敗は、答えの失敗ではなく、材料調達の失敗である。

この視点を持つと、AIの精度問題を「プロンプト改善だけ」で片づけなくなります。

本当に重要なのは「問い」ではなく「証拠の流れ」を設計すること

ここで、プロンプトエンジニアリングとRAGを統合するための、より深い見方が必要になります。多くの人は、AIへの入力を1回きりの質問だと考えています。しかし実際には、AIに答えさせるプロセス全体は、証拠の流れとして設計しなければなりません。

この流れは次のように考えると整理しやすいです。

何を知る必要があるかを定義する
その答えに必要な根拠は何かを決める
根拠をどこから取得するかを選ぶ
その根拠をどう読ませるかを設計する
最終的にどの形式で出すかを固定する

この5段階の中で、プロンプトは主に4と5を担当し、RAGは2と3を担当します。つまり、優れたAIシステムとは、賢い文章生成器ではなく、根拠を集め、比較し、要約し、判断できる形に変換する知的パイプラインです。

たとえば、営業チームが「この顧客に提案する最適なプランは何か」を聞くケースを考えましょう。表面的には単なる質問ですが、本当に必要なのは、以下の複数の情報です。

過去の商談履歴
顧客の契約プラン
料金表の最新版
競合比較資料
値引きルール

これらを持たずにLLMへ相談すると、もっともらしい提案は返ってきても、実務で使える提案にはなりません。逆に、これらの資料を適切に検索し、関連部分だけをLLMに渡し、「営業担当者向けに、提案理由と注意点を出せ」と指示すれば、出力は一気に実務化します。

つまり、AIの価値は答えの華やかさではなく、証拠に基づく再現性にあります。

直感に反するが、精度を上げるには「賢くさせすぎない」ほうがいい

ここが最も重要な転換点です。多くの人は、AIを賢く使うほど精度が上がると思っています。しかし実際には、賢さを足すだけでは精度は上がらない。むしろ、賢さに制約を与えるほうが実務では強い。

これは人間でも同じです。優秀な部下に自由に考えさせると、創造的な案は出ますが、社内ルールを逸脱することがあります。逆に、参照すべき資料、判断基準、出力形式を明示すると、自由度は下がるのに成果の質は上がる。LLMでも同様で、完全な自由回答より、根拠付き回答の方が強いのです。

この発想を突き詰めると、AI活用の目的は「万能な対話相手を作ること」ではなく、「限定された条件下で極めて信頼できる補助者を作ること」になります。ここで役立つのが、次のような設計原則です。

思考の形式を固定する: まず結論、次に根拠、最後に注意点
根拠の範囲を絞る: 参照してよい文書のみを渡す
不確実性を明示させる: 断定ではなく、条件付きで答えさせる
出力を用途に合わせる: メール、稟議、FAQ、要約で形式を変える

ここでの肝は、LLMを「何でも知っている存在」として扱わないことです。知識は外部化し、思考は構造化する。この役割分担ができたとき、初めてAIは業務の中で信頼される存在になります。

実務で使える発想転換: AIは答える前に「参照契約」を結ばせる

AI活用を本当にうまく進める組織は、単にプロンプトを磨いているわけではありません。彼らは無意識のうちに、AIとの間で参照契約を結んでいます。つまり、「何を根拠に答えるのか」「根拠が足りない時はどう振る舞うのか」「どの形式で返すのか」を先に決めているのです。

この考え方を現場に落とすと、導入はかなり明確になります。たとえば、社内ナレッジ検索のチャットボットなら、次のように設計できます。

質問の意図を分類する: 規程確認、手順確認、比較、要約
ベクトル検索で関連文書を取得する
取得文書をLLMに渡す前に、見出しと日付を添える
回答時に、必ず参照した箇所を短く引用させる
文書にない内容は「見当たりません」と言わせる

これだけでも、LLMの挙動は驚くほど安定します。なぜなら、AIに自由作文をさせるのではなく、証拠ベースの編集作業をさせているからです。

たとえば、法務、経理、人事のような領域では、この設計が特に重要です。間違った答えのコストが高いからです。逆に、アイデア出しや文章の下書きのような領域では、プロンプトの工夫がより効いてきます。つまり、用途によって、プロンプトとRAGの比重は変わる。この使い分けを理解すると、AIは一気に道具になります。

最高のAIシステムとは、最も雄弁なシステムではなく、最も根拠をたどれるシステムである。

Key Takeaways

プロンプトは思考を整え、RAGは知識を整える。この役割分担を意識すると、失敗の原因を切り分けやすくなる。
LLMにキーワード検索を任せすぎない。検索は意味の補完ではなく、根拠の回収として設計する。
答えの精度は、問いの巧さだけでなく材料の質で決まる。まず何を根拠にするかを定義する。
根拠のない自由回答より、根拠付き回答のほうが実務で強い。出力の自由度を下げるほど信頼性は上がる。
AIとの参照契約を明文化する。何を参照し、何を参照しないか、足りない時はどう答えるかを先に決める。

結論: AI活用の本質は「賢い対話」ではなく「正しい委任」

生成AIを使いこなすとは、上手に話すことではありません。もっと本質的には、何をAIに考えさせ、何を外部から与え、どこで止めるかを決めることです。ここに、プロンプト設計とRAGの深い共通点があります。両者は別々の技術ではなく、AIに「知っているふり」をさせないための補完関係にある。

これからのAI活用で問うべきなのは、「どう聞けばうまく答えるか」ではなく、「どうすれば答えが現実に耐えるか」です。検索を捨てて賢くなるのではなく、検索を正しく組み込んでこそ、LLMは本当に賢くなる。その意味で、AI時代の競争力とは、モデルの大きさではなく、知識をどのように流し込み、どのように制約し、どのように検証するかの設計力なのです。