RAGで社内文書検索を作る前に決めること｜権限・更新頻度・正答率の考え方

社内規程、手順書、FAQ、議事録、製品仕様、営業資料が散らばっていて、必要な文書をすぐ見つけたい という相談はかなり増えています。
その流れで、生成AIとRAGを使った社内文書検索を作りたい、という話も自然に出てきます。

ただ、ここでよくあるのが、まずベクトル検索を入れよう とりあえず全部食わせよう から始めてしまうことです。
実際には、社内文書検索で先に決めるべきなのはモデル名や検索基盤の製品名より、公開範囲、元文書の権限、更新ルール、評価方法、正答率の見方です。

この記事では、RAGで社内文書検索を作る前に決めておきたいことを、権限、更新頻度、正答率、運用責任の観点から整理します。
まずRAGそのものの意味やコンテキストとの関係から見たい場合は、AIのコンテキストとは？プロンプト・会話履歴・RAGとの違いを整理 を先に読むとつながりやすいです。
社内FAQ用途に絞った注意点は、生成AIで社内FAQを作るときの注意点｜情報整理・権限・更新ルール でも整理しています。

この記事では、2026年4月22日時点で Microsoft、Google Cloud、AWS、Databricks の公開情報を確認しながら整理しています。Microsoft Learn では、文書レベルのアクセス制御は検索時にユーザーごとのフィルターで実現する設計が説明されています。Google Cloud でも評価セットを使った RAG の評価が案内され、Databricks でも本番前に retrieval の品質と answer quality を分けて評価することが勧められています。ここではツール比較ではなく、社内文書検索を実務で回す前提の判断軸に絞ります。

結論：RAGは「検索AI」ではなく「権限付き文書運用」の延長で考える

RAGという言葉だけ見ると、AIの賢さの話に見えます。
でも社内文書検索で本当に効くのは、次の3点です。

• 元文書が正しいか
• その人に見せてよい文書だけが出るか
• 文書更新が検索結果へ反映されるか

ここが弱いと、モデルが強くても意味がありません。
逆にここが強ければ、最初はそこまで派手な構成でなくても実用になります。

社内文書検索のRAGは、AIが何でも答える仕組み より、正式情報へたどり着きやすくする仕組み として設計する方が安定します。
特に、根拠URL、更新日、文書種別、公開範囲を一緒に扱えるようにしておくと、運用でかなり助かります。

先に決めたい全体項目

まずは全体像です。作り始める前に、最低限このくらいは決めておくとぶれにくいです。

1. まず用途を絞る

社内文書検索と言っても、中身はかなり違います。
よくあるのは次の4パターンです。

• 人事・総務向けの規程検索
• 情シス向けの手順書検索
• 営業向けの提案資料検索
• サポート向けのFAQ補助

この違いを曖昧にしたまま 社内ナレッジ検索 として全部まとめると、評価基準がぶれます。
たとえば規程検索では、答えの自然さより 正式な文書を誤らず引けること が大事です。
一方、FAQ補助なら言い換え耐性や会話のしやすさが重要になります。

最初は1用途に絞った方が安全です。
規程検索と営業資料検索を同じ精度要求でまとめるより、まずは 就業規則と経費精算ルールだけ のように範囲を狭めた方が成功しやすいです。

2. どの文書を正式情報として使うか決める

社内には、正式文書、ドラフト、議事録、Slackログ、個人メモが混ざっています。
全部入れた方が賢く見える気がしますが、実務では逆です。

特に最初は、次のように分ける方が扱いやすいです。

• 正式文書
• 参考文書
• 下書き・議事録
• 個人メモ

正式文書だけで答えるのか、参考文書まで使うのかを決めないと、たまたま見つかった会議メモ が正式回答のように返ることがあります。
これはかなり危ないです。

おすすめは、最初の公開範囲では 正式文書のみ に寄せることです。
参考文書や議事録を使うなら、回答文に 参考情報 と明示するか、そもそも別インデックスに分ける方が安全です。

3. 権限は「検索後に隠す」ではなく「最初から見せない」で考える

ここはかなり重要です。
社内文書検索では、検索精度より先に権限事故を防ぐ必要があります。

Microsoft Learn でも、文書レベルのアクセス制御は、検索時にユーザーやグループごとの権限フィルターを使う設計で説明されています。
つまり、検索結果に出た後で隠す より、その人に見せてよい文書だけを検索対象にする 方が自然です。

実務では次を決めておくと安全です。

• 元文書のアクセス権をそのまま引き継ぐか
• 役職や部署単位で絞るか
• 一時的な権限付与をどう扱うか
• 退職、異動、委託終了時にどう権限を外すか

RBAC のように役割ベースで権限を整理しているなら、RAG側もその考え方へ寄せた方が運用しやすいです。
逆に、もともとの文書権限がガタガタなのにRAGだけきれいに作ろうとしても、検索側で苦しみます。

よくある権限事故

• 管理部門向け文書を全社員が検索できる
• 経営会議資料が抜粋だけ見えてしまう
• 退職者アカウントの権限が残る
• 委託先が他部署の文書まで検索できる

社内文書検索は便利なほど、見せすぎ の被害が広がりやすいです。
最小権限で始めて、必要に応じて広げる方が安全です。

さらに、社内向けAI検索では、文書に埋め込まれた命令で挙動をずらすプロンプトインジェクションも無視できません。
この論点を独立して整理した記事として、社内向けAI検索でプロンプトインジェクションをどう防ぐ？RAGの信頼境界と防御策を整理 もあわせて読むとつながりやすいです。

4. 更新頻度を決める

古い文書が混ざる問題は、本番運用でかなり効きます。
たとえば就業規則、経費精算、価格表、手順書は、1回古い情報を返すだけで現場が混乱します。

そのため、更新頻度は 後で考える ではなく、最初に決める方がよいです。

考え方はざっくり次です。

大事なのは、どの文書は即時、どの文書は日次でよいか を分けることです。
全部リアルタイム同期にすると運用が重くなりやすいですし、全部日次にすると重要ルールが遅れます。

また、更新日の見せ方も大事です。
検索結果や回答に 最終更新日 が見えるだけでも、利用者はかなり判断しやすくなります。

5. 正答率は「何％ならOKか」だけで決めない

RAGの相談でよく出るのが、正答率を何％にすればいいですか という話です。
でも実務では、1つの数字だけで見ると危険です。

最低限、次を分けて見た方がよいです。

• そもそも関連文書を取れているか
• 取った文書から正しく答えているか
• 答えられないときに無理に答えていないか
• 根拠リンクが妥当か

Databricks の評価ガイドでも、retrieval quality と answer quality を分けて見る考え方が示されています。
これはかなり重要で、回答が悪いのか、検索が悪いのかを分けないと改善できません。

正答率だけで見ない方がよい理由

• 1文違いでも重大事故になる質問がある
• 多少言い換えても意味が合っていればよい質問もある
• 分からない と返す方が正しい場面がある
• 根拠文書が古いと、答え方だけ直しても意味がない

たとえば社内規程検索なら、自然な言い回しより 正式ルールに沿っているか の方が重要です。
一方、サポート補助なら、多少の言い換えより 必要な手順にたどり着けるか を見る方が現実的です。

6. 評価セットを先に作る

Google Cloud でも RAG の評価には評価セットを使う考え方が案内されています。
これは社内文書検索でもかなり有効です。

おすすめは、最初に20〜50問くらいでもよいので、実際に聞かれそうな質問セットを作ることです。

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

• よくある質問
• 言い換え質問
• あいまい質問
• 権限的に見せてはいけない質問
• 文書に答えがない質問

この中に、答えない方が正しい質問 を入れるのが大事です。
社内文書検索は、答える精度だけでなく、答えるべきでないときに止まれるかも重要です。

7. 根拠リンクと文書メタ情報を返す

社内文書検索で、回答文だけ返す設計はあまりおすすめしません。
少なくとも、次は返した方が実務では使いやすいです。

• 根拠文書へのリンク
• 文書タイトル
• 最終更新日
• 文書種別
• 抜粋箇所

これがあると、利用者は AIがそう言っている ではなく この文書にこう書いてある で判断できます。
結果として、正答率が多少揺れても運用しやすくなります。

逆に、根拠なしで断定口調だけきれいな回答は危ないです。
特に人事、法務、価格、契約、障害対応のような話では、元文書へ戻れることが大事です。

8. 失敗時の扱いを決める

RAGは、毎回完璧に答えるものではありません。
だからこそ、失敗時の挙動を先に決めておく方が安全です。

たとえば次のようなルールです。

• 根拠文書が弱いときは回答を控える
• 上位文書の関連度が低いときは 該当文書を特定できませんでした と返す
• 人事、契約、金額、権限の質問は公式窓口へ誘導する
• 古い文書しか見つからないときは更新日を強調する

この設計がないと、分からない場面でもそれらしく答えてしまいます。
社内文書検索では、うまく答えることより、危ない場面で止まることの方が大事なことがあります。

9. 運用責任者を決める

ここも地味ですが重要です。
RAG基盤は作れても、誰も文書を整えず、更新も監視もせず、評価もしないと、すぐに劣化します。

最低限、次は役割を分けた方がよいです。

• 文書の正式責任者
• 検索基盤の管理者
• AI回答の評価担当
• 問い合わせや改善要望の受付担当

1人で全部持つと回りにくいので、少なくとも 文書責任 と 検索システム責任 は分けた方が整理しやすいです。

よくある失敗

全文書を最初から入れる

便利そうに見えますが、権限、ノイズ、古文書、ドラフト混入で一気に不安定になります。
まずは正式文書だけ、しかも1用途から始める方が安全です。

正答率を感覚で見ている

なんとなく使えそう では改善しにくいです。
質問セットを作り、retrieval と answer を分けて見た方が改善ポイントが分かります。

元文書の権限と切り離している

RAG側だけ別管理にすると、異動、退職、委託終了の反映漏れが起きやすいです。
元文書の権限体系とどう合わせるかを先に決める方が安全です。

更新頻度を決めていない

価格表、規程、運用手順が古いままだと、使うほど信用を失います。
即時・日次・週次のどれで回すかを用途ごとに決める必要があります。

まとめ

RAGで社内文書検索を作る前に決めることは、モデルやベクトルデータベースより先に、用途、対象文書、権限、更新頻度、正答率の見方、評価セット、根拠表示、運用責任です。
特に大事なのは、誰に何を見せてよいか、どの文書を正式情報とするか、どの頻度で更新を反映するか を先に決めることです。

社内文書検索のRAGは、AIを賢く見せる仕組みというより、正式文書へ安全にたどり着きやすくする仕組みとして考える方が実務ではうまくいきます。
まずは1用途、正式文書、根拠リンク付き、評価セットあり、最小権限で始める。この形がかなり堅い出発点です。

参考リンク

• Microsoft Learn: Document-level access control in Azure AI Search
• Microsoft Learn: Advanced Retrieval-Augmented Generation
• Google Cloud: Evaluate retrieval augmented generation (RAG) applications
• AWS Prescriptive Guidance: Access control for vector stores and retrievers in RAG applications
• Databricks: A Guide to Evaluating RAG Pipelines