社内資料を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で使う前に
- お問い合わせ
よくある質問
RAGは資料に書いてあることだけ答えさせれば安全ですか？
資料に書いてある内容でも、古い資料、矛盾する資料、権限外の資料、担当者判断が必要な内容は注意が必要です。資料の有無だけでなく、回答してよい範囲と人へ回す条件を決めることが大切です。
禁止質問リストはどこまで細かく作るべきですか？
最初から完璧に作る必要はありません。個人情報、契約・人事・法務判断、資料に根拠がない質問、権限外の質問、顧客へ送る文面の確定など、事故になりやすいものから始めると運用しやすいです。
回答できない場合は「分かりません」と返せばよいですか？
「分かりません」だけでは、次に何をすればよいか分かりにくくなります。確認できなかった理由、参照した資料、追加で必要な情報、担当者へ確認すべき内容を短く返す方が実務では使いやすいです。
ローカルLLMでも回答ルールは必要ですか？
必要です。ローカル環境で動かしていても、資料にない内容を断定したり、権限外の情報を出したりするリスクは残ります。PCやモデルの構築だけでなく、回答範囲、ログ、引き継ぎ先を決めておくと安全です。
