タグ: 社内AI

社内資料を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や社内AIチャットを作ったあと、見落とされやすいのがバックアップです。

動いている間は問題がなくても、次のような場面で「元に戻せない」ことがあります。

• RAGを動かしていたPCやSSDが故障した
• OSやツールを更新したら起動しなくなった
• 別のPCやサーバーへ移行することになった
• ベクトルDBのデータが壊れた
• 作った担当者が退職し、設定が分からなくなった
• 文書を再登録したら、以前より回答品質が落ちた

このとき、ベクトルDBのフォルダだけをコピーしていても、同じ状態に戻せるとは限りません。

RAGは、原本文書、文書の分割方法、検索設定、モデル、権限、プロンプトなど、複数の要素で動いているからです。

この記事では、小規模事業者や少人数チーム向けに、RAGのバックアップで何を残すべきか、何は再生成できるか、復旧後に何を確認するかを整理します。

RAGのバックアップは「データのコピー」ではなく「再現できる状態」を残す

バックアップの目的は、ファイルをどこかへコピーすることではありません。

障害や移行が起きたあとに、次の状態まで戻せることが目的です。

• 必要な社内文書を検索対象へ戻せる
• 文書ごとの権限や有効・無効の状態を戻せる
• 以前と近い条件で検索と回答を実行できる
• 代表的な質問に対し、必要な根拠を返せる
• 誰が、どの手順で復旧するか分かる

つまり、RAGのバックアップは「保存」だけでなく「再構築」と「確認」まで含めて考える必要があります。

ベクトルDBだけでは戻せない理由

ベクトルDBには、文書を検索しやすい数値データへ変換した結果や、文書の一部、メタデータなどが保存されます。

ただし、そのデータが残っていても、次の情報が分からなければ、別環境で同じ状態を再現しにくくなります。

• どの原本文書から作ったか
• どの埋め込みモデルを使ったか
• 文書をどの長さで分割したか
• 表や見出しをどのように処理したか
• どの部署・利用者に見せる設定だったか
• 検索結果を何件取得していたか
• どのプロンプトで回答を作っていたか
• 以前の品質を何で判定していたか

ベクトルデータは重要ですが、RAG全体から見ると「検索用に加工した結果」の一部です。

原本と設定が残っていれば、時間はかかっても再生成できる場合があります。一方、原本や権限情報が失われると、ベクトルDBが残っていても正しい状態へ戻せないことがあります。

最低限残したい7つの要素

1. 原本文書

最優先で残すのは、RAGへ登録したPDF、Word、Excel、テキスト、Webページの保存データなどの原本です。

ただし、ファイルを一つのフォルダへコピーするだけでは不十分です。次の情報も一緒に管理します。

• 文書ID
• ファイル名
• 元の保存場所
• 文書の担当者
• 更新日
• 利用対象の部署・グループ
• 有効、期限切れ、削除予定などの状態
• RAGへ登録した日

同じファイル名で内容が違う資料や、「最新版」と書かれた古い資料が混ざると、復旧後に誤った文書を登録する原因になります。

2. 文書台帳とメタデータ

文書台帳は、どの資料を検索対象にするかを判断する一覧です。

最低限、次の列を持つと復旧作業を進めやすくなります。

項目	役割
文書ID	ファイル名変更後も同じ文書を追う
原本パス	元資料の場所を確認する
更新日	古い資料を判別する
所有者	内容の確認先を決める
閲覧グループ	権限を戻す
状態	有効・停止・削除予定を分ける
登録日	RAGへ反映した時点を確認する
備考	OCR、表処理、例外設定などを残す

文書台帳があれば、ベクトルDBをそのまま復元できない場合でも、対象文書を選び直して再登録できます。

3. 前処理と分割の設定

RAGの品質は、文書をどのように読み取り、どの単位に分けたかで変わります。

残したい設定には、次のようなものがあります。

• PDFや画像にOCRを使ったか
• ヘッダー、フッター、ページ番号を除外したか
• 表をテキスト化したか
• 文書を分割する長さ
• 分割部分をどれだけ重ねたか
• 見出しやページ番号をメタデータへ入れたか
• 対象外にするフォルダやファイル形式

コードで処理している場合は、実行スクリプトだけでなく、設定ファイルと実行手順も残します。

担当者の記憶だけに依存すると、再インデックス後に分割単位が変わり、同じ質問でも違う根拠が返ることがあります。

4. モデルと検索設定

RAGで使うモデルや検索条件も記録します。

• 埋め込みモデル名
• 回答生成に使うモデル名
• モデルやツールのバージョン
• 取得する検索結果の件数
• 類似度のしきい値
• キーワード検索を併用しているか
• 再ランキングを使っているか
• 回答を作るプロンプト
• 「分からない」と答える条件

クラウドサービスや外部APIを使う場合、認証情報そのものを通常の設定ファイルへ書いてバックアップするのは避けます。

「どの秘密情報が必要か」と「どこから安全に取得するか」を復旧手順へ書き、実際のキーやパスワードは別の安全な管理方法を使います。

5. ベクトルDBとインデックス

利用しているベクトルDBに、スナップショットやエクスポート機能がある場合は、復旧時間を短くするために活用できます。

ただし、ベクトルDBのバックアップを唯一の復旧手段にしないことが重要です。

環境やバージョンの違いでそのまま読み込めない場合や、破損した状態まで保存している場合に備え、原本文書と設定から再インデックスできる状態も残します。

考え方は次のように分けると整理しやすくなります。

対象	基本方針
原本文書	失うと再現できないため、必ず保存
文書台帳・権限	正しい対象範囲を戻すため、必ず保存
前処理・検索設定	同じ条件を再現するため、必ず保存
ベクトルDB	復旧時間短縮のため保存し、再生成手段も持つ
一時キャッシュ	必要に応じて再生成
質問・回答ログ	利用目的と保存期間を決めて別管理

6. 権限と除外ルール

復旧できても、本来見えてはいけない資料が検索結果へ出る状態では成功とはいえません。

次の情報を残します。

• 部署・役割ごとの閲覧範囲
• 機密文書の除外条件
• 退職者・異動者の扱い
• 一時的に停止している文書
• 個人情報を含む文書の処理
• バックアップ自体を閲覧できる担当者

バックアップには、通常の検索画面では見えない原本文書がまとまって入ることがあります。そのため、RAG本体だけでなく、バックアップ先のアクセス権限も確認が必要です。

7. 評価質問と復旧手順

RAGが起動しただけでは、復旧完了とは判断できません。

以前から使っている代表質問と、確認したい根拠を残します。

例:

• 最新の申請手順を答えられるか
• 廃止済みの旧手順を回答しないか
• 回答に参照文書名やページを示せるか
• 権限のない利用者に機密文書を出さないか
• 資料にない内容を推測で断定しないか

復旧手順には、次の流れを書きます。

1. 新しい環境を用意する
2. 必要なソフトウェアとモデルをそろえる
3. 原本文書と文書台帳を戻す
4. 権限と除外ルールを設定する
5. ベクトルDBを復元するか、文書を再インデックスする
6. 代表質問で回答と根拠を確認する
7. 問題がなければ利用を再開する

「担当者なら分かる」ではなく、初めて見る人でも順番を追える粒度にします。

保存するものと再生成するものを分ける

すべてを同じ頻度で保存すると、運用が重くなります。

小規模な環境では、次の3種類に分けると管理しやすくなります。

失うと戻せないもの

• 原本文書
• 文書台帳
• 権限情報
• 手作業で補正したOCR結果
• 独自のプロンプトや例外ルール
• 評価質問と判定基準

これらは優先度を高くして保存します。

時間をかければ再生成できるもの

• ベクトルデータ
• 検索インデックス
• 一時的な変換ファイル
• キャッシュ

再生成できると判断するには、原本、モデル情報、設定、実行手順が残っている必要があります。

保存期間を決めるもの

• 質問・回答ログ
• 利用者情報
• エラー記録
• 古いスナップショット

ログには、質問者や社内情報が含まれる場合があります。「役立ちそうだから全部残す」ではなく、利用目的、保存期間、閲覧者、削除方法を決めます。

小規模チーム向けの始め方

最初から複雑なバックアップ基盤を作る必要はありません。

まずは次の最小構成から始めます。

1. RAGの原本文書を、一つの管理対象として特定する
2. 文書台帳をスプレッドシートで作る
3. モデル名、分割設定、検索設定を一枚にまとめる
4. 設定ファイルと実行スクリプトを版管理する
5. ベクトルDBの保存・エクスポート方法を確認する
6. 代表質問と期待する根拠を残す
7. 別フォルダや別端末で一度だけ復旧を試す

バックアップの頻度は、文書の更新頻度と「何日分の変更まで失ってよいか」で決めます。

毎日資料が追加されるRAGと、月に一度しか更新しないRAGでは、同じ頻度にする必要はありません。

復旧テストで確認すること

バックアップは、実際に戻せなければ意味がありません。

復旧テストでは、起動確認だけでなく、次を確認します。

• 文書件数が想定と合っている
• 最新文書が検索対象になっている
• 廃止文書が除外されている
• 文書名、ページ、更新日などの根拠が出る
• 権限ごとの検索範囲が正しい
• 代表質問への回答が以前と大きくずれていない
• 復旧にかかった時間が分かる
• 手順書だけで担当者以外も作業できる

モデルやツールの更新で回答文が完全に同じにならないことはあります。

文章の一致だけを見るのではなく、必要な情報が含まれるか、正しい資料を参照しているか、不要な断定をしていないかで確認します。

よくある失敗

ベクトルDBのフォルダだけコピーする

原本、モデル、分割設定、権限情報がなければ、別環境で同じ状態を再現できないことがあります。

原本文書とバックアップを同じPCだけに置く

端末やストレージの故障時に、RAG本体とバックアップを同時に失う可能性があります。少なくとも、同じ故障の影響を受けない保存先を用意します。

バックアップを一度も戻していない

保存処理が成功していても、ファイル不足、権限不足、バージョン違いで復元できないことがあります。

APIキーやパスワードも設定ファイルへ入れる

バックアップを見られる人が、そのまま外部サービスや社内システムへアクセスできる状態になります。秘密情報は分離し、復旧時の取得方法だけを手順に残します。

復旧後の品質を確認しない

文書件数が同じでも、分割や検索設定が変わると回答品質は変わります。評価質問と根拠確認までを復旧作業に含めます。

YOSHIO.devで相談できること

YOSHIO.devでは、小規模事業者や少人数チーム向けに、ローカルLLM・RAG環境の構築や運用整理を相談できます。

例えば、次のような段階から相談できます。

• 現在のRAGで何を保存すべきか棚卸ししたい
• 原本文書とベクトルDBの関係を整理したい
• 別PCや社内サーバーへ移行したい
• 再インデックスできる設定と手順を残したい
• 権限を維持したままバックアップしたい
• 評価質問を使って復旧後の品質を確認したい
• 担当者しか分からない環境を手順化したい

大規模な基盤を前提にせず、現在の文書量、利用人数、更新頻度、機密性に合わせて、小さく始める構成を検討できます。

まとめ

RAGのバックアップは、ベクトルDBをコピーするだけでは完了しません。

重要なのは、次の要素をそろえ、別環境で再現できる状態を残すことです。

• 原本文書
• 文書台帳
• 前処理と分割設定
• モデルと検索設定
• ベクトルDB
• 権限と除外ルール
• 評価質問と復旧手順

まずは、原本文書、文書台帳、設定一覧、代表質問の4点をそろえ、別フォルダや別端末で一度だけ戻してみると、足りない情報が見えます。

「保存しているから大丈夫」ではなく、「戻して質問できるから大丈夫」という状態を目標にしましょう。

関連リンク

• ローカルLLM・RAG環境構築の相談
• RAGへ入れる文書を棚卸しする方法
• RAG文書の追加・差し替え・削除ルール
• RAGの評価質問と採点ルールを作る
• RAGの閲覧範囲と権限を設計する

FAQ