タグ: 回答ルール

社内資料をAIに読ませて質問できるようにしたい。マニュアル、FAQ、規程、手順書、過去の問い合わせ履歴をRAGに入れて、必要なときにすぐ答えを探せるようにしたい。

このような相談では、「どの文書を入れるか」「どのモデルを使うか」「PCスペックは足りるか」に目が向きがちです。

もちろん、文書整理や環境構築は大切です。けれど、社内AIチャットやRAGを業務で使うなら、もうひとつ先に決めておきたいことがあります。

それは、AIが答えてはいけない質問をどう扱うかです。

RAGは、資料を検索して回答に使う仕組みです。しかし、質問の内容によっては、資料に書いていないこと、古い資料と新しい資料で矛盾すること、担当者の判断が必要なこと、そもそもAIに答えさせるべきではないことがあります。

この記事では、小規模事業者や少人数チーム向けに、RAGや社内AIチャットを導入する前に決めたい「答える質問」「答えない質問」「人へ引き継ぐ質問」の分け方を整理します。

結論：RAGには「回答できない」と言える設計が必要

RAGを便利に使うには、良い回答を出すことだけでなく、答えない判断も重要です。

たとえば、次のような質問が来たとします。

• この契約条件で受注してよいですか？
• この顧客には割引してよいですか？
• 退職予定者の情報を確認できますか？
• 古い手順書にはAと書いてあり、新しい資料にはBとあります。どちらが正しいですか？
• 資料にはないですが、普通はどうしますか？

これらをAIが自信ありげに答えてしまうと危険です。

社内AIチャットは、検索窓のように見えても、業務判断の入口になります。だからこそ、「資料にある範囲だけ答える」「判断が必要なものは人に回す」「アクセス権限がない情報は出さない」「根拠がない場合は保留する」という境界線が必要です。

まず質問を3種類に分ける

RAGの回答ルールは、最初から細かく作り込みすぎる必要はありません。

まずは質問を、次の3種類に分けます。

質問の種類	AIの扱い	例
答えてよい質問	根拠資料を示して回答する	手順、社内ルール、FAQ、公開済みの料金説明
答えてはいけない質問	回答せず、理由を短く伝える	個人情報、権限外情報、資料にない断定、法務・人事判断
人に確認する質問	回答保留にして担当者へ回す	資料が矛盾する、例外判断が必要、最新情報の確認が必要

この3種類が曖昧なままだと、AIの振る舞いも曖昧になります。

「分からないなら分からないと言う」だけでは足りません。何をもって分からないと判断するのか、どこへ回すのか、質問者にはどう見せるのかを決める必要があります。

RAGが答えてはいけない質問の例

禁止質問は、業種や扱う資料によって変わります。ただし、小規模チームでも共通して注意したいものがあります。

資料に根拠がない質問

RAGは資料を参照して答える仕組みです。

資料にない内容を、一般論やAIの推測で補ってしまうと、社内資料を使っている意味が薄れます。

たとえば、「このケースは返金できますか？」という質問に対して、返金規定が資料にないのに一般的な商習慣で答えると危険です。

この場合は、次のように返す方が安全です。

手元の資料では返金可否を確認できません。返金規定または担当者への確認が必要です。

担当者の承認が必要な質問

見積、割引、契約、納期、例外対応などは、資料に条件が書いてあっても、最終判断を人が行う場合があります。

AIが「対応できます」「割引できます」「受注して問題ありません」と断定すると、実際の運用とずれる可能性があります。

RAGには、判断を確定するのではなく、確認に必要な情報を整理させる方が向いています。

個人情報や権限外の質問

顧客情報、従業員情報、評価、給与、契約詳細、個別案件の内部メモなどは、誰が質問しているかによって出してよい範囲が変わります。

アクセス権限を分けずにRAGへ入れると、本来見られない人に情報が出るおそれがあります。

この領域は、文書を入れる前に、利用者、文書範囲、ログ、権限を分ける必要があります。

古い資料と新しい資料が矛盾する質問

RAGでは、古いマニュアル、更新前のFAQ、過去の社内メモが残っていると、矛盾した回答が出ることがあります。

「AとBの資料が見つかりました。どちらもあり得ます」と返すだけでは、業務では使いにくいです。

資料に更新日、版数、管理者、優先順位を持たせ、矛盾時は回答を保留して人へ回すルールが必要です。

外部向けにそのまま使う文章

社内確認用の回答と、顧客へ送る回答文は別物です。

RAGが社内資料をもとに顧客返信文を作る場合も、「そのまま送ってよい」ではなく、「下書き」「要確認」「担当者承認後に送信」と分ける方が安全です。

回答保留の文面を先に決める

RAGの回答保留は、ただ「分かりません」と返すだけでは不十分です。

質問者が次に何をすればよいか分からないと、AIチャットは使われなくなります。

回答保留の文面には、次の要素を入れます。

• 確認できなかった理由
• 参照した資料の範囲
• 人に確認すべき内容
• 追加で必要な情報
• 引き継ぎ先または次の行動

たとえば、次のように分けます。

状況	回答例
資料に根拠がない	手元の資料では確認できません。該当する規程または担当者への確認が必要です。
資料が古い可能性がある	参照資料に更新日の古いものが含まれます。最新の運用確認が必要です。
権限外の可能性がある	この質問には権限確認が必要です。閲覧可能な資料の範囲では回答できません。
判断が必要	条件整理はできますが、可否の判断は担当者確認が必要です。
外部回答に使う文章	下書きとして整理できますが、送信前に担当者確認が必要です。

このような定型文を用意しておくと、AIが無理に答えるよりも、利用者にとって安心できる入口になります。

人に引き継ぐときの情報を決める

回答保留にした質問は、そこで止めてしまうと業務に乗りません。

重要なのは、人に引き継ぐための情報を残すことです。

最低限、次の項目をログに残すと確認しやすくなります。

• 質問文
• 質問者または部署
• 質問日時
• AIが参照した資料
• 回答できなかった理由
• 足りない資料や確認事項
• 想定される担当者
• 緊急度
• 最終対応結果

小規模チームなら、最初から大きなシステムを作る必要はありません。スプレッドシート、チャット通知、簡易フォーム、小型Webツールのどれかで十分です。

ただし、質問が増えてきたら、「未対応」「確認中」「回答済み」「資料更新が必要」といった状態管理があると便利です。

禁止質問リストは、最初から完璧にしない

RAGの禁止質問リストを作ろうとすると、最初から大量のパターンを考えたくなります。

しかし、現実には使ってみないと分からない質問も多くあります。

最初は、次のような小さなリストで十分です。

• 個人情報や評価に関する質問
• 契約、法務、税務、人事の判断を求める質問
• 最新情報が必要な質問
• 資料に根拠がない質問
• 権限外の資料を必要とする質問
• 顧客へそのまま送る文章の確定
• 金額、納期、例外対応の確定

運用を始めたら、回答保留になった質問を見直し、禁止質問リストと回答文を更新します。

この更新ルールがないと、RAGは導入直後だけ整っていて、数か月後には現場の質問とずれていきます。

評価質問にも「答えないテスト」を入れる

RAGの精度確認では、正しく答えられる質問ばかりをテストしがちです。

しかし、業務で重要なのは、答えてはいけない質問を止められるかです。

評価質問には、次のようなものを混ぜます。

• 資料にない内容を聞く質問
• 古い資料と新しい資料が矛盾する質問
• 権限外の情報を求める質問
• 判断や承認を求める質問
• 顧客へ送る文面の確定を求める質問
• あいまいな条件で断定を誘う質問

このテストで、AIが無理に答えてしまう場合は、プロンプト、検索対象、文書整理、権限設計、回答保留文を見直します。

RAGの評価は「当たったか」だけではなく、「止まるべきところで止まったか」も見る必要があります。

小型ツール化するなら、回答ログと資料更新をつなげる

回答保留が増えることは、必ずしも悪いことではありません。

むしろ、社内資料の不足やルールの曖昧さが見えている状態です。

たとえば、同じ質問が何度も回答保留になるなら、次のどれかが必要かもしれません。

• FAQを追加する
• 手順書を更新する
• 料金や例外条件を明文化する
• アクセス権限を見直す
• 担当者への確認フローを決める
• 回答文テンプレートを追加する

この見直しをスプレッドシートで管理してもよいですし、小型ツールで「保留質問」「担当者」「対応状況」「資料更新要否」を管理してもよいです。

RAGは、文書を入れて終わりではありません。質問ログから資料を直し、回答範囲を更新していくことで、社内で使いやすくなります。

導入前チェックリスト

RAGや社内AIチャットを導入する前に、次の項目を確認しておくと、回答事故を減らしやすくなります。

確認項目	決めること
回答範囲	AIが答えてよい業務、文書、利用者
禁止質問	個人情報、判断、権限外、資料なし、外部回答など
回答保留文	資料にない、矛盾する、確認が必要な場合の文面
引き継ぎ先	誰に、どの方法で確認依頼を出すか
ログ項目	質問、参照資料、保留理由、対応結果
資料更新	保留質問を見て、どの資料を直すか
評価質問	答えるテストだけでなく、答えないテストも入れる
権限	利用者ごとに見える資料を分ける必要があるか

最初から完璧なルールを作る必要はありません。

まずは、1業務、少人数、代表的な資料、代表的な質問から始める方が安全です。

YOSHIO.devで相談できること

YOSHIO.devでは、ローカルLLM・RAG環境構築、業務自動化、小型ツール開発について相談できます。

「社内資料をAIで検索したいが、答えてはいけない質問が不安」「RAGの評価質問や回答保留ルールを作りたい」「保留質問を担当者へ回す小さな管理画面がほしい」といった段階でも、今ある資料や運用に合わせて小さく整理できます。

まずは、RAGに入れたい資料、よくある質問、答えさせたくない質問、確認が必要な判断をメモするところから始められます。

関連リンク

• ローカルLLM・RAG環境構築
• 業務自動化
• RAGの精度をどう評価する？社内AIチャットの質問テスト集の作り方
• RAGの回答に根拠を表示するには？
• 社内AI検索とRAGのアクセス権限設計
• ローカルLLMを共用PCで使う前に
• お問い合わせ

よくある質問