社内ナレッジ検索AI(RAG)の導入準備｜整えるべき文書・FAQ・権限設計

社内文書検索や社内FAQに生成AIを使いたいとき、よく出てくるのがRAGです。RAGは、AIが回答を作る前に社内文書やFAQを検索し、その内容をもとに答える仕組みです。 ただ、RAGは「社内資料を全部入れれば、AIが何でも答えてくれる」仕組みではありません。AIに渡す前のナレッジが古い、重複している、責任者が分からない、権限が整理されていない状態だと、古い規程を引用したり、部署ごとに違う手順を返したり、回答の根拠を確認できなかったりします。 シンプレクス株式会社の社内ドキュメント検索RAGの構成資料でも、文書分割、検索、アクセス権限制御、回答根拠リンクが論点として挙げられています。SMBCグループは2025年10月6日、まずは三井住友銀行の従業員向けに、社内向けAIアシスタント「SMBC-GAI」にRAG技術を活用した社内情報検索機能を導入し、社内規程・通達・業務マニュアルなど約130万件のファイルを体系的にインデックス化したと発表しました。みずほ証券も2024年12月16日、RAGを活用した社内文書検索システムを全役職員向けに導入し、社内ルール検索や問い合わせにかかる時間削減を狙っています。 この記事では、RAGの技術構成よりも、検索対象にする文書やFAQをどう集め、どう更新し、どの範囲で検索させるかを整理します。RAG導入の前に必要なのは、ツール選定だけではなく、社内ナレッジを業務で使える形に整えることです。

多くの会社では、社内情報が一つの場所にまとまっていません。Google Drive、SharePoint、Notion、Slack、Box、ファイルサーバー、メール添付、個人のExcelに分かれています。形式もPDF、Word、PowerPoint、スプレッドシート、議事録、チャットログなどばらばらです。 人間なら「これは古そうだな」「この資料は正式版ではなさそうだな」と判断できることがあります。しかしRAGでは、検索対象に入っている文書は候補になります。古い規程、途中版のマニュアル、個人メモ、似た内容のFAQが混ざっていると、AIはその中からもっともらしい断片を拾って回答します。 特に問題になりやすいのは、次のような情報です。

RAGの検索対象にできる文書やFAQを作るには、「どれが正しい情報か」「誰が見てよい情報か」「いつ更新された情報か」を整理する必要があります。ここを飛ばしてAIだけを導入すると、回答精度だけでなく、情報漏洩や誤回答のリスクも残ります。

RAG導入で最初に決めるべきことは、ツールではなく対象業務です。「社内のことを何でも聞けるAI」を最初から目指すと、文書範囲も権限範囲も広がり、検証が難しくなります。 最初は、質問の種類を絞ります。

質問を絞ると、必要な文書、FAQ、問い合わせ履歴を選びやすくなります。経費精算なら、経費規程、申請マニュアル、承認フロー、FAQ、問い合わせ履歴が候補になります。営業資料検索なら、提案書、事例、業界別資料、失注理由、商談メモが候補になります。 「何をAIに入れるか」から考えるより、「誰のどんな質問に答えたいか」から考える方が、検索対象にする文書を決めやすくなります。

RAGに向いているナレッジには、いくつかの共通点があります。

たとえば、AIに渡しやすい文書には、更新日、責任部署、対象読者、業務名、参照元リンク、閲覧権限が入っています。経費精算マニュアルであれば、「営業部向け」「2026年4月更新」「経理部管理」「関連規程へのリンクあり」のように、文書の位置づけが分かる状態です。 反対に、AIに渡しにくい文書は、情報の意味を人間の記憶に頼っています。「最新版」「最終版」「修正版」のようなファイル名だけでは、どれが有効か分かりません。「いつもの申請方法で対応」と書かれていても、初めて読む人やAIには分かりません。 RAG用のナレッジ整備では、担当者だけが知っている判断や例外を、FAQや手順書に残していきます。完璧な文書を作るというより、AIと社員が同じ根拠に戻れるようにする作業です。

FAQや手順書を管理する場所は、NotionでもSharePointでもGoogle Driveでも構いません。大事なのは、置き場所よりも記録の型です。 最低限、次の項目を持たせます。

問い合わせ履歴をそのまま入れるより、「よくある質問」と「正式回答」に整理してから入れる方が、RAGでは扱いやすくなります。Slackのやり取りも、判断の根拠になる発言だけをFAQや手順書に転記した方が、後から検索しやすくなります。 つまり、文書やFAQを残すとは、情報を保存することだけではありません。後から別の社員が読んでも判断できる形にして残すことです。

検索対象にする文書が決まったら、次の順番で整えます。

対象業務に関係する文書を一覧化します。最新版、古い版、部署ごとのコピー、FAQ、問い合わせ履歴を分けます。最初から全社分を対象にせず、経費精算、社内IT問い合わせ、営業資料検索など、1つの業務に絞る方が進めやすくなります。

同じ内容の文書が複数ある場合、RAGはどれを優先すべきか判断できません。最新版だけを検索対象にし、古い版はアーカイブします。削除できない場合でも、検索対象から外すルールを作ります。

長い文書をそのまま入れると、AIが必要な箇所を拾いにくくなります。手順書は章立てし、FAQは「質問」と「回答」の単位に分けます。表や画像PDFは、必要に応じてテキスト化します。

文書ごとに、業務カテゴリ、更新日、責任部署、閲覧範囲を付けます。権限は特に後回しにしない方がよいです。PoCの段階から、全社向け、部門限定、管理職限定などの区分を決めておくと、本番化するときの手戻りを減らせます。権限や情報漏洩まわりの基本は生成AIセキュリティ対策の基本で整理しています。

RAGの検証では、正しい文書を参照できるか、回答が業務で使える粒度になっているか、権限どおりに情報を返せるかを確認します。そのために、「この質問に正しく答えられたら合格」という質問を20〜30個用意します。総務、情シス、営業、CSなど、実際に問い合わせを受けている担当者に出してもらうと、検証しやすくなります。

RAGで回答精度が出ない、本番展開できない、利用者が回答を信じられないといった問題は、AIモデルの性能だけで起きるわけではありません。ナレッジの準備と運用が足りないと、どのツールを使っても似た問題が起きます。 よくあるのは、全資料を一度に投入する進め方です。検索対象を増やしても、正答率が上がるとは限りません。古い情報や関係ない資料が混ざると、回答が参照する文書もずれやすくなります。 次に、権限を後回しにする進め方です。PoCでは動いても、本番で人事情報、顧客情報、部門限定資料が混ざると、そのまま展開できません。 参照元リンクが出ない設計も避けたいところです。RAGの回答は、根拠文書に戻れるからこそ業務で使いやすくなります。回答だけが表示されると、利用者は正しいかどうかを確認できません。 もう一つは、更新担当が決まっていないことです。RAGは一度作れば終わりではありません。規程が変わった、FAQが増えた、古い資料を廃止した、という変化を検索対象に反映し続ける必要があります。

最初のRAGは、対象範囲が狭く、正解が確認しやすい業務から始めるのが現実的です。 社内FAQは始めやすい領域です。総務、人事、情シスに寄せられる問い合わせを整理し、よくある質問と正式回答を作ります。問い合わせ件数や自己解決率を見れば、効果も測りやすくなります。 規程検索は、根拠文書が比較的はっきりしているため、最初のRAGで試しやすい領域です。経費規程、就業規則、情報セキュリティポリシーなどを対象にする場合も、版管理と参照元リンクは先に整えます。 営業資料検索では、過去提案書や事例を探しやすくできます。営業部門での具体的な使いどころは営業で使える生成AI活用事例も参考になります。ただし、顧客名、金額、未公開情報が含まれることがあるため、匿名化や権限設計を先に確認します。 CS問い合わせでは、製品マニュアル、FAQ、過去の問い合わせをもとに、オペレーター向けの回答支援を作れます。顧客に直接AI回答を返す前に、まず担当者が参照する用途から始める方が安全です。問い合わせ対応そのものの効率化は生成AIで問い合わせ対応を効率化する方法で詳しく解説しています。 オンボーディング支援では、新入社員がよく聞く申請方法、ツールの使い方、社内ルールをまとめます。質問の種類が限られ、改善点も集めやすい領域です。

RAG導入では、どのLLMを使うか、どのベクトルデータベースを使うか、どの検索方式を使うかも検討します。ただし、その前に必要なのは、社内ナレッジの設計です。 どの業務の質問に答えるのか。正解となる文書はどれか。誰が更新するのか。誰が閲覧してよいのか。回答の根拠をどう確認するのか。 ここが決まっていないと、PoCでは一部の質問に答えられても、権限、更新担当、参照元、責任部署が未整理のままになり、本番展開の判断ができません。逆に、対象業務とナレッジの型が決まっていれば、ツール選定や実装の判断もしやすくなります。 RAGは検索システムの導入であると同時に、社内ナレッジを「探せる」「根拠に戻れる」「更新し続けられる」状態にする取り組みです。AIに答えさせる前に、AIが参照する情報の責任範囲を決めておくことが、本番利用では欠かせません。

どのツールを選ぶかは社内ナレッジ検索AIの選び方で、グループウェア内蔵型から自社構築型まで4タイプを比較しています。

外部支援会社に相談する場合は、RAGの構築だけでなく、業務棚卸し、ナレッジ設計、PoC設計、運用ルールまで扱えるかを確認します。社内側では、対象業務、文書の置き場所、更新担当、閲覧権限を整理しておくと相談が進めやすくなります。 特に確認したいのは、RAGを作って終わりではなく、回答精度の評価、権限設計、ナレッジ更新の運用まで一緒に見られるかです。社内FAQや規程検索は、導入直後よりも、利用ログと問い合わせ内容を見ながら改善していく段階で差が出ます。

Concretoでは、RAG製品の選定やプロンプト調整だけでなく、対象業務、文書の置き場所、更新担当、閲覧権限の確認から伴走します。最初に、どの部署のどの質問に答えるのかを決め、検索対象にする文書、FAQ、問い合わせ履歴を棚卸しします。 そのうえで、PoCで使うFAQ、評価用質問、権限表、運用ルールを作成します。RAG製品の選定より前の、業務と文書の整理から扱うことで、PoC後に本番化できない状態を避けやすくします。 支援範囲は、次のように段階化できます。

社内文書、FAQ、問い合わせ履歴を整理し、対象業務ごとに使えるナレッジ候補を分類します。

FAQや手順書をもとに、社員向け・担当者向けの一次回答案を作り、評価用質問で精度を確認します。

AIの回答案をそのまま使わず、責任部署や担当者が確認する運用を作り、承認済みの回答だけをナレッジに反映します。

権限、参照元リンク、更新担当、利用ログを管理しながら、限定された範囲で自動回答や問い合わせ削減まで進めます。 Concretoでは、レベル1の棚卸しから、レベル4の自動返信・継続運用までを一気通貫で扱います。最初から全社展開を狙うのではなく、社内FAQ、規程検索、営業資料検索、CS回答支援など、効果とリスクを確認しやすい範囲から始め、評価と改善を回しながら広げていきます。

※この記事は2026年5月21日時点の公開情報をもとにしています。RAG製品や生成AIサービスの仕様は変わるため、導入時には利用するツールの公式情報と契約条件を確認してください。