RAGの回答精度は「何を答えさせないか」で変わる — システムプロンプト設計に関する6つの観点

組織で生成AIを導入すると、このような問題が発生したことはありませんか？

「社内規程にはない連絡先を、AIがもっともらしく案内してしまった」

「“今後のイベント”を聞いたのに、去年の開催案内が返ってきた」

「同じ制度について新旧2つの資料が見つかり、古いほうを根拠に回答した」

RAGは、組織が指定した社内の情報を参照し、生成AIが文章を作る仕組みです。AIを使う以上、ハルシネーションのリスクは完全にはなくなりません。とくに、参照情報の扱い方についての指示が曖昧な場合、AIが意図しない解釈をして誤った案内をする可能性はあります。

つまりこうした問題は、RAG（検索拡張生成）の検索精度だけが原因とは限りません。検索で適切な資料を見つけられても、その資料をAIにどう扱わせるかが曖昧であれば、適切な回答が得られるとは限りません。

そこで重要になるのが、RAG向けのシステムプロンプトです。

一般的なLLMチャットでは、役割や口調、出力形式を整えるためにシステムプロンプトを使うことが多いでしょう。一方、RAGではそれに加えて、「検索された参照情報をどう読み、どこまで答え、どのような場合に答えないか」を決める必要があります。

企業向けRAGプラットフォーム「AskDona」を提供するGFLOPSは、理化学研究所のスーパーコンピュータ「富岳」のサポートサイトや、国立情報学研究所のウェブサイト、金融業界を含む民間企業にRAG基盤を提供しています。こうした導入・運用支援を通じて、組織がRAGを安定して活用するための知見を蓄積してきました。

本記事では、実際の運用から得られた知見をもとに、企業や組織におけるRAGのシステムプロンプト設計で重要となる6つの観点を、実践的なプロンプト例とともに紹介します。

1. そもそも、システムプロンプトとは何か

システムプロンプトとは、利用者との会話に先立って、AIの役割や守るべき条件を設定する指示です。利用者がチャット入力画面で記入する質問（ユーザープロンプト）とは区別して扱われます。

たとえば、次のような指示です。

あなたは社内制度に関する問い合わせ担当です
回答は400文字以内にまとめてください
個人情報は出力しないでください
根拠が見つからない場合は、推測せずにその旨を伝えてください

現在のチャット型LLMにつながる技術的な発展は、大きく2つに分けて捉えるとわかりやすくなります。

1つは、人間の指示に沿うようモデルを訓練する流れです。OpenAIが2022年3月に公開したInstructGPTの論文では、人が望ましいと判断した応答を用いてモデルを調整する手法が示されました。[1]

もう1つは、指示を「誰から与えられたものか」によって構造化する流れです。OpenAIが2023年3月1日に公開したChat Completions APIでは、会話をメッセージとロールに分けて渡す形式が採用され、アプリケーション側の指示と利用者の入力を区別して扱えるようになりました。[2]

さらに2024年4月、OpenAIの研究チームは、上位の指示と下位の指示が衝突したときに上位を優先する「Instruction Hierarchy」を提案しました。同論文で扱われた基本関係は、システムメッセージ、ユーザーメッセージ、ツールなどから取得した第三者コンテンツの順です。[3] 続く同年5月のModel Spec初版では、優先順位が Platform > Developer > User > Tool と整理されました。[4]

ただし、ここで押さえておきたい点が3つあります。

システムプロンプトは、100%守られる絶対命令ではない

指示の優先順位を定めても、モデルが常に期待どおりに動くとは限りません。プロンプトは重要な制御手段ですが、それだけで安全性や正確性を保証するものではないため、実際の質問を使った評価と改善が必須です。

システムプロンプトだけでは解決できない問題もある

RAGでは、利用者の質問に加えて、一定量の参照情報や回答形式、禁止事項などをLLMが同時に処理します。こうした入力への対応力や指示への従いやすさは、モデルの学習方法や特性によって異なります。

そのため、システムプロンプトを丁寧に設計しても、使用するモデルによっては、参照情報を適切に扱えない場合や、複数の指示を安定して守れない場合があります。

指示は、長さよりも優先順位と具体性が重要

ルールを増やすほど性能が必ず落ちるわけではありませんが、似た指示や矛盾する指示を詰め込むと、何を優先すべきかが曖昧になります。長いプロンプトほど、重複や例外条件の衝突も起きやすくなります。

「何を書くか」と同じくらい、「何を最優先にするか」「何を削るか」が大切だということです。

2. 通常のLLMチャットと、RAGの違い

一般的なLLMチャットのシステムプロンプトでは、次のような設定がよく使われます。

役割を与える：「経験豊富な人事担当者として回答する」
出力形式を決める：文字数、見出し、箇条書き、文体などを指定する
例を示す：判断基準を言葉だけで伝えにくい場合に、質問と回答の例を添える
禁止事項を決める：「医療上の診断は行わない」「個人情報を出力しない」

もちろん、これらはRAGでも有効です。ただしRAGには、もう1つの重要な要素があります。検索によって外部の知識データベースから取得した「参照情報」です。

RAGは、質問に関連する文書を検索し、その一部を参照情報としてLLMに渡し、回答を生成します。原型となった2020年のRAG論文でも、モデル内部の知識に加え、外部の文書インデックスを検索して生成に利用する構成が示されています。[5]

したがってRAGのシステムプロンプトでは、表現だけでなく、次の判断も設計しなければなりません。

参照情報にない内容を補ってよいか
根拠が不足しているときにどう応答するか
複数の資料が矛盾したとき、どれを優先するか
過去の情報と現在有効な情報をどう区別するか
どの資料を根拠にしたか、利用者へどう示すか

ここを曖昧にしたまま、通常のチャット向けプロンプトを流用すると、RAGらしい「根拠に基づく回答」が崩れやすくなります。

図1　通常のLLMチャットとRAGの違い

RAGでは、通常のチャットの設定に加えて「検索された参照情報をどう扱うか」を決める必要があります。

Chat LLM

通常のLLMチャット

質問 → モデル内部の知識 → 回答

主に、役割・表現・出力形式を制御

役割を与える：「経験豊富な人事担当者として回答する」
出力形式を決める：文字数、見出し、箇条書き、文体
例を示す：判断基準を言葉だけで伝えにくい場合に、質問と回答の例を添える
禁止事項を決める：「医療上の診断は行わない」「個人情報を出力しない」

RAG

RAG（検索拡張生成）

質問 → 検索 → 参照情報 → 回答

左の4項目は、RAGでも同じように有効

役割／出力形式／例示／禁止事項

＋参照情報の採用・棄却・優先順位・根拠提示を制御

参照情報にない内容を補ってよいか
根拠が不足しているときにどう応答するか
複数の資料が矛盾したとき、どれを優先するか
過去の情報と現在有効な情報をどう区別するか
どの資料を根拠にしたか、利用者へどう示すか

右側の5項目を曖昧にしたまま、通常のチャット向けプロンプトを流用すると、RAGらしい「根拠に基づく回答」が崩れやすくなります。

3. RAGのシステムプロンプトで押さえるべき6つの要点

3-1. 参照情報の外側を、勝手に補わせない

RAGを導入する目的の1つは、回答の根拠を組織が管理する資料に寄せることです。しかしLLMは、参照情報にない部分を学習済みの一般知識で補う場合があります。

一般論としては正しくても、自社の制度としては誤っている。企業や組織が導入するRAGでは、このズレが大きな問題になります。

「正確に答えてください」だけでは、何をしてはいけないのかが曖昧です。生成されると困る情報を具体的に指定します。

【参照情報の範囲】
- 回答は、提示された参照情報に基づいて作成する。
- 参照情報にないメールアドレス、URL、数値、日付、制度名、手続きは生成しない。
- 質問に答える根拠が参照情報にない場合は、推測や一般知識で補わず、
  「参照情報からは回答を確認できませんでした」と伝える。

メールアドレスやURLを名指しするのは、形式が決まっていて「それらしい文字列」を作りやすく、利用者が真偽を見分けにくいためです。

なお、「根拠がない」場合と「検索やシステムが失敗した」場合は分けて扱う必要があります。後者まで同じ定型文で覆い隠すと、障害に気づけません。検索結果が0件だったのか、検索処理そのものが失敗したのかをアプリケーション側で判定できる設計が理想です。

3-2. 「答えない」と「聞き返す」を正常な動作にする

通常のチャットでは、何らかの答えを返すことが期待されがちです。しかしRAGでは、根拠がなければ答えないことも正しい動作です。

さらに、質問が曖昧なときは、無理に回答するより聞き返したほうが解決は早くなります。

【聞き返し】
- 参照情報に複数の候補があり、回答を一意に決められない場合は、推測しない。
- 対象、時期、症状、制度名など、回答の特定に必要な情報を1つずつ質問する。
- 聞き返す場合は、通常の回答テンプレートを使わない。

たとえば「PCが動かない」という質問だけでは、電源が入らないのか、ログインできないのか、操作中に固まるのかがわかりません。最初に状況を確認したほうが、誤った手順を長々と案内せずに済みます。

聞き返しの判断は、文章だけで定義しにくいことがあります。その場合は、1〜2件の例を添えるfew-shotが有効です。

例：
利用者「PCが動きません」
回答「どの状態に近いですか。①電源が入らない ②ログインできない ③操作中に固まる ④その他」

ただし、例を増やしすぎると、個別の例に引っ張られたり、重要なルールが埋もれたりします。組織内での質問傾向を把握し、まずは質問頻度や聞き返しニーズの高いケースに絞ることを推奨します。

3-3. 参照元とリンクの出し方を決める

RAGの大きな利点は、回答の根拠を利用者がたどれることです。ただし、参照元の表示は自動的に整うとは限りません。回答に渡されるメタデータと、出力ルールの両方を設計する必要があります。

【参照元の表示】
- 回答に使用した資料名を、回答末尾の「参照元」に表示する。
- URLが参照情報に含まれる場合のみリンクを付ける。
- リンクは [資料名](URL) のMarkdown形式で出力する。
- 参照情報にないURLは生成しない。

リンク形式を固定しておくと、生のURLが長く表示されたり、リンクが途中で切れたりする問題を減らせます。

外部サイトの記事を自社サイト経由で収集している場合は、どのURLを案内するかも決めておきましょう。元記事へ直接案内するのか、自社内の詳細ページへ案内するのかは、AIに推測させるのではなく運用ルールとして指定します。

3-4. 複数資料が競合したときの優先順位を決める

社内の知識データベースには、同じテーマの資料が複数存在します。たとえば、旧規程と改定版、正式な規程と説明会の議事録です。検索結果には両方が含まれる可能性があります。

どちらを主たる根拠にするかは、LLMに判断を任せるのではなく、組織のルールとして定義する必要があります。

【参照情報の優先順位】
回答の根拠が複数ある場合は、次の順で優先する。

1. 現在有効な規程・規則
2. 公式の通知・手続き文書
3. FAQ・説明資料
4. 議事録・その他の資料

- 同じ種類の資料が複数ある場合は、施行日または更新日が新しいものを優先する。
- どの資料が現在有効か判断できない場合は、断定せず、その旨を伝える。
- 有効な資料同士に不整合がある場合は、矛盾を隠さず、資料名と日付を示す。

単に「新しい文書を優先」とするだけでは不十分な場合があります。古い規程が現行で、新しい文書が単なる説明会資料ということもあるからです。なお、文書種別、施行日、有効期限、改廃関係などをメタデータ（知識データベースに含まれる資料に付与するカテゴリーやタグなど）として持たせると、プロンプトだけに頼らず安定して判定できます。

3-5. 「今後」「現在」「最新」の基準日を渡す

時間軸は、見落とされやすい一方で影響の大きい論点です。

知識データベースには、過去のイベント、終了した募集、旧年度の案内が蓄積されています。「今後の予定」を尋ねても、「予定」「開催」という言葉を含む過去の記事が検索されることがあります。

【日付の扱い】
- 基準日は {CURRENT_DATE} とする。
- 「今後」「次回」「これから」と質問された場合は、基準日より後の日付の情報のみを候補にする。
- 終了したイベントや募集を、今後の予定として案内しない。
- 将来の情報が参照情報にない場合は、公開済みの予定を確認できない旨を伝える。
- 日付は参照情報に記載されている場合のみ、YYYY年M月D日形式で表示する。

重要なのは、{CURRENT_DATE} に実行時の正しい日付を渡すことです。「現在は2026年です」のような固定文をプロンプトへ直接書くと、更新漏れが起きます。可能であれば、アプリケーション側で毎回、現在日時とタイムゾーンを注入できる設計が理想です。

また、記事の公開日が新しくても、そこで案内されている制度が現在有効とは限りません。「公開日」と「開催日」、「更新日」と「施行日」を区別できるメタデータ設計なども、有効かもしれません。

3-6. 組織固有の用語と略称を対応づける

どの組織にも、正式名称よりよく使われる略称、システムの通称、部署の旧称があります。利用者は普段の呼び方で質問しますが、資料には正式名称しか書かれていないことがあります。

【用語対応表】
- {システムA}（略称：{略称A}）：{用途}
- {システムB}（通称：{通称B}）：{用途}

利用者が略称や通称で質問した場合は、対応する正式名称として解釈する。
複数の正式名称に該当する略称は、推測せずに聞き返す。

対応表は長くなりやすいため、最優先ルールと同じ欄へ詰め込まず、背景知識や用語集として分けて管理するのが基本です。また、システムプロンプトではなく、知識データベースに用語集としてアップロードすることも有効です。

また、例文や対応表には実在しそうな部署名、メールアドレス、URLを不用意に書かないようにします。例示した文字列が、回答の根拠として再利用される可能性があるためです。置き換え箇所は {部署名} のように明示します。

4. すべてを「絶対厳守」にしない

ここまで6つの要点を紹介しましたが、すべてを同じ強さで並べればよいわけではありません。重要度に濃淡をつけることが推奨されます。

段階	役割	例
最優先ルール	誤ると業務上の影響が大きい中核ルール	架空情報の禁止、根拠不足時の応答、必要な聞き返し
厳守ルール	通常は守るべき運用ルール	参照元の表示、文字数、リンク形式、分類タグ
推奨ルール	品質を整える補助的なルール	言い回し、見出し、注意書き、文体

最優先ルールは、用途に応じて1〜3個程度から始めると管理しやすくなります。失敗したときの影響が大きいものを上位に置き、チャット履歴と回答の評価結果を見ながら調整し、運用しながら改善していくことが重要です。

AskDonaでは、ルールと背景知識を分けて設定する

AskDonaでは、システムプロンプトに関する設定を2つのフィールドに分けています。

フィールド	文字数	主に記載する内容
システム環境設定	2,000文字以内	優先ルール、回答テンプレート、参照情報の扱い、出力形式
AIパーソナリティ設定	制限なし	AIの役割、組織の説明、用語集、問い合わせ先の対応表など

イメージとしては、システム環境設定が「業務ルール」、AIパーソナリティ設定が「役割と背景知識」です。重要な指示は前者へ、長い定義や対応表は後者へ分けることで、優先すべき内容を見失いにくくなります。

複数の設定がある場合、AskDonaでは次の順に適用され、後にある設定ほど後から反映されます。

AskDonaのデフォルト設定（利用者からは参照・変更不可）
組織単位のシステム環境設定
組織単位のAIパーソナリティ設定
個人単位のシステムプロンプト

設定した内容が期待どおりに反映されないときは、「どの層で競合または上書きされているか」という視点で原因を確認できます。

5. ユースケース別の設定例

5-1. 複数部署を横断する社内問い合わせ

人事、総務、経理などの情報が1つの知識データベースにあり、回答とあわせて担当部署も案内するケースです。

【最優先ルール】
- 質問の対象が曖昧、または複数の制度に該当する場合は、推測せずに聞き返す。
- 参照情報にないメールアドレス、URL、制度、手続きは生成しない。

【厳守ルール】
- 回答末尾に [担当部署] を必ず出力する。
- 担当部署は次のいずれかを完全一致で出力する。
  人事部 / 総務部 / 経理部 / 情報システム部 / その他
- 判断できない場合のみ「その他」とする。
- 問い合わせ先は、背景知識の「問い合わせ窓口対応表」から引用する。

部署判定の補助ルールや連絡先一覧は、AIパーソナリティ設定側に置きます。

回答末尾の [担当部署] を固定の分類タグにしておけば、チャット履歴を集計し、どの部署への問い合わせが多いかを分析できます。表記ゆれを許さないことがポイントです。

5-2. 公開Webサイトを知識データベースにしたチャットボット

自社サイトを自動収集し、知識データベースとして利用するケースです。過去記事が蓄積されるため、時間軸とリンク先の制御が重要になります。

【最優先ルール】
- 基準日は {CURRENT_DATE} とする。
- 今後の予定を尋ねられた場合は、基準日より後の日付を持つ情報のみを案内する。
- 過去の記事や終了済みのイベントを、今後の予定として案内しない。
- 未来の予定を参照情報から確認できない場合は、その旨を伝え、
  参照情報に含まれる場合のみ一覧ページを案内する。
- 外部サイトの情報を案内するときは、参照情報に含まれる元記事のURLを使用する。
- 参照情報にないURL、日付、事実は生成しない。

【リンク形式】
- [記事名（媒体名・主催者名）](URL) の形式で表示する。

現在日付は、AIパーソナリティ設定へ固定値で書くのではなく、実行時に更新される値として渡します。年をまたいでも古い設定が残らず、タイムゾーンも含めて基準を統一できます。

6. システムプロンプトは、運用しながら更新される

RAGのシステムプロンプトで制御すべきなのは、回答の口調だけではありません。検索された参照情報をどう扱うかが設計の中心になります。

参照情報にない事実を補わせない
根拠がないときは答えず、曖昧なら聞き返す
参照元とリンク形式を統一する
複数資料の優先順位を決める
過去、現在、未来を区別する
組織固有の用語や略称を対応づける

そして、すべてを同じ強さで書かないこと。業務上の影響が大きいルールを上位に置き、表現上の好みは下位に分けます。

最初から完璧なプロンプトを作る必要はありません。実際のチャット履歴には、想定していなかった質問、検索はできているのに回答で崩れたケース、聞き返すべきだったケースなど、想定しないクエリが複数現れます。それらを評価データとして蓄積し、プロンプト、検索設定、文書メタデータ、回答生成に使用するモデルの特性を切り分けて改善することが、安定したRAG運用への近道です。

AskDonaでは、ルールと背景知識を分け、適用順序を明確にすることで、組織の担当者自身がシステムプロンプトを管理できるようにサポートします。設計や改善に迷った場合は、チャット履歴を確認しながら調整方針をご案内します。カスタマーサクセス担当までご相談ください。

参考文献

Ouyang, L. et al., Training language models to follow instructions with human feedback, arXiv:2203.02155, 2022.
OpenAI, Introducing APIs for GPT-3.5 Turbo and Whisper, 2023年3月1日.
Wallace, E. et al., The Instruction Hierarchy: Training LLMs to Prioritize Privileged Instructions, arXiv:2404.13208, 2024.
OpenAI, Model Spec (2024/05/08), 2024年5月8日.
Lewis, P. et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020.
Anthropic, System Prompts - Claude Platform Docs.