RAG導入の進め方｜社内文書検索で決める7項目

「社内規程やマニュアルを生成AIに読ませて、質問に答えさせたい」「RAGという仕組みがあると聞いたが、何から手を付ければよいか分からない」「試しに作ってみたものの、回答がずれていて現場で使われない」。社内文書のAI検索について、こうした声をよく耳にします。この記事では、RAG（検索拡張生成）の仕組みを押さえたうえで、導入前に決めておくべき7つの項目と、検証から本番運用までの進め方を、業務の側と技術の側の両方からお伝えします。

RAGとは：検索した情報を根拠に答える仕組み

RAG（Retrieval-Augmented Generation、検索拡張生成）は、生成AIが回答をつくる前に、外部の情報源から質問に関係する情報を検索し、その内容を根拠として回答させる仕組みです。検索する先は、社内の文書に限りません。データベースや業務システムのデータ、Webの情報なども対象にできます。

生成AIは学習した内容しか知らないため、自社の規程や製品資料について聞いても、もっともらしい一般論を返すことがあります。RAGでは「答えの材料」を毎回検索して渡すため、情報源に沿った回答になり、何を根拠にしたかを示すこともできます。

この記事では、社内文書（規程・マニュアル・仕様書・FAQなど）を検索先にするRAGを中心にお話しします。

処理の流れ

Google Cloud の RAG Engine の概要では、RAGの処理を次の順に説明しています。製品によって呼び方は違いますが、どの仕組みもおおむね同じ流れです。

段階	何をするか
取り込み	ファイルサーバーやクラウドストレージなどから文書を読み込みます
変換	文書を検索しやすい単位（チャンク）に分割します
エンベディング	文章の意味を数値のベクトルに変換します。意味が近い文章ほど近い値になります
インデックス登録	検索できる形で保存します
検索	利用者の質問に近い部分を探し出します
生成	探し出した部分を質問と一緒に生成AIへ渡し、それを根拠に回答させます

ここから分かるとおり、RAGの回答の質は「どの文書を、どう分けて、どう検索するか」で大きく変わります。生成AIのモデルを高性能なものに替えても、渡す材料が古かったり的外れだったりすれば、回答はよくなりません。

社内検索・ファインチューニングとの違い

RAGと混同されやすいものに、従来の社内検索と、生成AIの追加学習（ファインチューニング）があります。

方法	利用者が受け取るもの	向いている場面
従来の社内検索	文書の一覧（読むのは利用者）	目当ての文書名や用語が分かっている場合
RAG	文書を根拠にした回答と、その出典	質問の答えが文書のどこかに書いてあり、探して読むのに手間がかかる場合
ファインチューニング	学習させた傾向に沿った回答	文体や判断の型をそろえたい場合。中身が頻繁に変わる情報には向きません

社内規程・業務マニュアル・製品仕様・過去の提案書のように、「答えは文書に書いてあるが、探すのに時間がかかる」情報には、RAGが合っています。文書を更新すれば回答も変わるため、内容の入れ替わりが多い情報にも対応できます。

一方で、文書に書かれていない判断（「この取引は受けてよいか」など）は、文書を検索するRAGでは答えられません。また、数値の集計（「先月の売上は」など）は、文書ではなく業務システムやデータベースを検索先にする仕組みが別に必要です。RAGに何を任せるか、どの情報源を検索させるかを先に線引きしておくと、後で「思っていたのと違う」となりにくくなります。

RAG導入で決める7項目

RAGは、作り始めること自体は難しくありません。クラウド各社のサービスを使えば、文書を登録するだけで短期間に試せます。それでも本番で使われずに終わる例が多いのは、作る前に決めておくべきことが決まっていないためです。次の7項目を、構築に入る前に決めておくことをおすすめします。

#	決める項目	決めないと起きること
1	対象業務と質問の範囲	何でも答えようとして、どの質問にも中途半端な回答になります
2	効果の定義	試した後に、続けるかやめるかを判断できません
3	読ませる文書と整理の方法	古い版や重複した文書から、誤った回答が出ます
4	アクセス権限の扱い	見せてはいけない文書の内容が回答に混ざります
5	構築方法	要件に合わない方式を選び、後で作り直しになります
6	精度の評価方法	「なんとなく使えない」で終わり、改善の手が打てません
7	運用の体制	文書が更新されず、回答が少しずつ古くなります

1. 対象業務と質問の範囲

最初に、どの業務の、誰の、どんな質問に答えさせるかを決めます。「全社の文書を全部読ませて、何でも聞けるようにしたい」という出発点は、うまくいかないことがほとんどです。文書の種類が増えるほど、似た内容の文書どうしが検索で競合し、回答の根拠がぶれるためです。

最初の対象には、次の条件がそろう業務が向いています。

同じような質問が繰り返し来ている（総務・人事・情報システム部門への社内問い合わせ、営業から技術部門への製品仕様の確認など）
答えが文書に書いてある（規程、手順書、FAQ、仕様書が存在する）
間違えたときの影響が限定的で、担当者が確認できる

対象を選ぶときは、業務を作業単位に分けて「手間×頻度×価値」で比べると判断しやすくなります。手順はAI化する業務の洗い出し方で詳しく説明しています。

質問の範囲も、あらかじめ書き出しておきます。実際に寄せられている問い合わせのメールやチャットを集め、よくある質問を数十件ほど並べてみると、どの文書が必要か、どんな言い回しで聞かれるかが見えてきます。この質問の一覧は、後の「6. 精度の評価方法」でもそのまま使えます。

2. 効果の定義

RAGで何をどれだけ減らしたいのか、あるいは何を増やしたいのかを、数字で決めておきます。たとえば次のような形です。

社内問い合わせへの回答にかかっている担当者の時間を、月に何時間減らすか
問い合わせから回答までの待ち時間を、何時間から何分にするか
若手が先輩に聞かずに自己解決できる割合を、どこまで上げるか

効果の定義がないまま試すと、「回答はそれなりに出たが、続けるべきか判断できない」という状態で止まります。生成AIの検証が本番に進まない原因の多くはここにあり、AIのPoC止まりの原因と本番移行の条件でも詳しく扱っています。RAGも例外ではありません。

3. 読ませる文書と整理の方法

RAGの精度を左右する一番の要素は、読ませる文書です。導入の相談を受けて文書を見せてもらうと、次のような状態であることが少なくありません。

同じ規程の旧版と新版が、別のフォルダに両方残っている
部署ごとに似た手順書があり、内容が少しずつ違う
正しい情報が、文書ではなく担当者の頭の中やチャットの履歴にしかない
重要な情報が、表・図・画像の中に入っている

旧版と新版が両方残っていれば、RAGは旧版を根拠に答えることがあります。生成AIには、どちらが正しいかを判断する材料がないためです。読ませる前に、次のことを決めておきます。

正本の置き場所：どのフォルダ（またはどのシステム）にある文書を正とするか
対象外にする文書：旧版、下書き、個人のメモ、廃止された制度の資料
形式ごとの扱い：PDF・Word・Excel・PowerPoint・画像のどれを読ませるか。表や図の多い文書は、文字だけを取り出すと意味が崩れることがあるため、最初は文章中心の文書から始めるのが無難です
足りない情報の補い方：文書に書かれていない答えは、FAQとして書き起こしてから読ませる

文書の整理は地味な作業ですが、ここを飛ばしてシステム側の調整で精度を上げようとしても、効果は限られます。

4. アクセス権限の扱い

社内文書には、全員が見てよいものと、一部の人しか見てはいけないもの（人事評価、給与、経営会議の資料、顧客との契約など）が混ざっています。RAGでは、検索した文書の内容がそのまま回答に使われるため、検索の段階で、質問した人が見てよい文書だけに絞る必要があります。

AIアプリケーションのセキュリティ上の注意点をまとめたOWASP の LLM08:2025 Vector and Embedding Weaknessesでも、RAGで使うデータベースは利用者のグループごとにアクセスを分け、権限に応じた制御を細かくかけるよう求めています。複数の部署が同じデータベースを共有すると、部署をまたいで情報が漏れるおそれがあるためです。あわせて、取り込む文書を信頼できる出どころのものに限ることや、検索の記録を残して不審な使われ方を見つけられるようにすることも挙げています。

具体的な方法は、使う製品によって違います。たとえばAzure AI Search のセキュリティフィルターパターンでは、文書ごとに閲覧できるユーザーやグループの識別子を持たせ、検索のたびに質問者の所属グループで絞り込む方法が説明されています。どの製品を使う場合も、次の点を決めておきます。

元の文書の閲覧権限（ファイルサーバーやクラウドストレージの権限）を、RAG側にどう引き継ぐか
権限が変わったとき（異動・退職・プロジェクトの終了）に、RAG側へいつ反映するか
最初の段階では、権限の区別が要らない文書（全社公開の規程やFAQ）だけに絞るか

最後の点は、最初の範囲を決めるうえで現実的な選択です。全社公開の文書だけで始めれば、権限の仕組みを作り込む前に効果を確かめられます。

5. 構築方法

RAGの作り方は、大きく分けて次の3つです。

方法	概要	向いている場面
SaaS型の製品を使う	文書を登録すれば、画面からすぐに質問できる製品を契約します	社内にエンジニアが少なく、標準的な使い方で足りる場合
クラウドのRAG機能を組み合わせる	クラウド各社の検索・生成AIの機能を使い、自社向けに組み立てます	社内のシステムとつなぎたい、権限や画面を自社に合わせたい場合
個別に開発する	検索の仕組みや文書の前処理から作り込みます	特殊な文書形式や、厳しいセキュリティ要件がある場合

クラウドのRAG機能には、たとえばAmazon Bedrock のナレッジベース、Azure AI Search の RAG 機能、Google Cloud の RAG Engine があります。Amazon Bedrock のナレッジベースでは、データソースから関連情報を取り出して回答を生成し、回答に引用を含めて元の文書を確認できるようにする機能が用意されています。

どれを選ぶかは、すでに使っているクラウドや社内のシステム（文書がどこに置かれているか、社員のアカウントを何で管理しているか）との相性で決まることが多くあります。文書が置かれている場所と、権限の情報をどこから取るかを先に確認しておくと、選択を誤りにくくなります。

6. 精度の評価方法

「使ってみたら、なんとなく答えがずれる」という感想だけでは、何を直せばよいか分かりません。構築に入る前に、評価のやり方を決めておきます。

評価用の質問集をつくる：「1. 対象業務と質問の範囲」で集めた実際の質問に、正しい答えと、その答えが書かれている文書を対応させます
評価の観点を決める：答えが正しいか、根拠として示した文書が合っているか、文書に答えがないときに「分からない」と答えられるか
合格の基準を決める：本番に進む条件を、質問集での正答の割合などで決めます

とくに3つ目の「文書にないことを、分からないと答えられるか」は重要です。RAGでも、検索で関係の薄い文書しか見つからないと、生成AIがそれらしい答えをつくってしまうことがあります。答えられない質問には、担当者への問い合わせ先を案内するようにしておくと、利用者が誤った回答をそのまま信じる事態を避けられます。

評価で正答できなかった質問は、原因を次のどれかに分けて直していきます。

原因	主な直し方
そもそも文書に答えがない場合	FAQとして書き起こして追加します
文書はあるが、検索で見つからない場合	文書の分け方を見直します。社内の言い回し（略語・通称）を補い、キーワード検索と意味の検索を組み合わせます
古い版や別の文書を拾っている場合	文書を整理し、対象外の文書を外します
正しい文書を拾ったが、回答がずれている場合	生成AIへの指示（回答の形式、根拠の示し方）を見直します

経験上、正答できない原因の多くは上の3つ、つまり文書と検索の側にあります。生成AIのモデルを替える前に、まず文書と検索を見直すのが近道です。

7. 運用の体制

RAGは、作って終わりではありません。規程の改定、製品の追加、組織の変更があれば、読ませる文書も更新する必要があります。運用で決めておくことは次のとおりです。

文書の更新：誰が、どのタイミングで、RAGに読ませる文書を入れ替えるか（自動で同期するか、手動で登録するか）
利用ログの確認：どんな質問が来て、どれに答えられなかったかを、定期的に確認する担当
答えられなかった質問への対応：FAQの追加や文書の修正につなげる流れ
利用者からの指摘の受け口：回答が誤っていたときに、利用者が報告できる仕組み

答えられなかった質問は、社内の文書に何が足りないかを示す材料にもなります。ログを見て文書を足していくと、RAGの精度だけでなく、社内のナレッジそのものが整っていきます。

検証から本番までの進め方

7項目を決めたら、次の4つの段階で進めます。

段階	主な作業	次へ進む条件
1. 準備	7項目を決め、対象の文書を整理し、評価用の質問集をつくります	対象・効果・合格基準が文書になっていること
2. 検証	小さな範囲で作り、質問集で評価して、正答できない原因を直します	質問集での正答が合格基準を超えること
3. 試行運用	対象の部署で実際に使ってもらい、ログと利用者の声を集めます	業務で使われ、効果の数字が見込みに届くこと
4. 本番運用・拡大	運用体制を整え、対象の文書や部署を広げます	拡大した範囲でも評価と運用が回ること

ポイントは、検証の段階で「作れるか」ではなく「本番で使える精度が出るか」を確かめることです。2の段階で合格基準に届かなければ、3には進まずに原因を直します。逆に基準を超えたら、検証を繰り返さずに試行運用へ進みます。

範囲を広げるときも、一度に全社へ広げるより、部署や文書の種類を一つずつ足していく方が安全です。文書の種類が増えると、検索で拾われる文書の組み合わせが変わり、それまで正答できていた質問の精度が落ちることがあるためです。範囲を広げるたびに、評価用の質問集にも質問を足して、同じ基準で確かめます。

社内のナレッジを全員が使える形にする取り組みは、検索だけにとどまりません。営業のノウハウを共有し、提案や商談の準備を生成AIで支援した例など、私たちの取り組みは支援実績で紹介しています。

まとめ：RAG導入は「何を、どの文書で答えるか」を先に決める

RAGは、社内文書を検索して、その内容を根拠に生成AIが答える仕組みです。回答の質は、生成AIのモデルよりも、読ませる文書と検索の仕組みで決まります。
構築に入る前に、対象業務と質問の範囲、効果の定義、読ませる文書と整理の方法、アクセス権限の扱い、構築方法、精度の評価方法、運用の体制の7項目を決めておきます。
最初は、質問が繰り返し来ていて、答えが文書に書いてあり、全員が見てよい文書で足りる業務から始めると、効果を確かめやすくなります。
検証では、評価用の質問集と合格の基準を先に決め、正答できない原因を文書・検索・指示のどこにあるかに分けて直します。
本番に入った後も、ログを見て文書を足し、更新を続ける体制が必要です。

社内文書のAI検索をどの業務から始めるか、どの方式で作るかの検討から、構築・運用までご相談いただけます。進め方に迷われている段階でも、AI開発の支援の内容をご覧のうえ、お気軽にお問い合わせください。