RAGとは｜社内文書をAIに答えさせる仕組みと、導入前に決めること

結論から言うと、RAGは「社内の文書を検索して、ヒットした部分だけをAIに読ませてから答えさせる」という、それだけの仕組みです。名前が難しいので身構えていましたが、中身を分解すると検索と要約の組み合わせでした。

私がRAGという言葉を意識したのは、社内の問い合わせ対応を減らせないかと考えたときです。規程やマニュアルは揃っているのに、どこに書いてあるか分からないので結局人に聞かれる。この状態を何とかしたい、という動機でした。

結論

RAGを入れれば社内の質問が自動で片づく、という期待で始めると、たいてい「それらしいが微妙に違う回答」が返ってきて止まります。原因はAI側ではなく、読ませている文書側にあることが多いです。

RAGが何をしているか

RAGは Retrieval-Augmented Generation の略で、日本語にすると「検索で補強した生成」です。処理の流れはこうなります。

1. 利用者が質問を入力する
2. その質問に関係しそうな文書を、社内の文書群から検索する
3. ヒットした文書の該当部分（抜粋）を取り出す
4. 「この抜粋を根拠にして答えて」という指示と一緒に、AIへ渡す
5. AIが抜粋の範囲で回答を作る

ポイントは4です。AIが元から知っている知識ではなく、その場で渡された抜粋を読んで答えているだけです。つまり、抜粋に書かれていないことは答えられません。

この理解があると、「なぜ社内のあの規程を答えてくれないのか」という疑問の切り分けが早くなります。多くの場合、AIが賢くないのではなく、2の検索でその文書が拾えていません。

チャットに資料を貼るのと何が違うか

やっていることは、資料をチャットに貼り付けて質問するのとほぼ同じです。違いは、どの資料を貼るかを人ではなく検索が決めている点だけです。

だから、貼る資料が自分で分かっている状況ではRAGは要りません。私も、手元にPDFが1本あるだけなら、そのままチャットに投げます。RAGが意味を持つのは、資料が数百・数千に増えて「どこに書いてあるか分からない」が問題になってからです。

うまく答えられないときの原因

導入してみて詰まるのは、だいたい次のどれかでした。

症状	起きていること	対処の方向
関係ない文書を根拠にする	検索が的外れなものを拾っている	対象文書を絞る・分割の仕方を見直す
「分かりません」ばかり返る	検索でヒットしていない	表記ゆれ・用語の言い換えを補う
古い内容で答える	旧版の文書が残っている	対象から除外する運用を決める
一般論に流れる	抜粋が薄く、AIが知識で補っている	根拠が無ければ答えない指示にする

いちばん厄介なのは最後です。抜粋がほとんど役に立たないとき、AIは黙らずに一般論で埋めてきます。見た目は自然な文章なので、読む側が「社内規程にそう書いてある」と誤解しやすい。

このあたりの誤りの出方は、通常のチャット利用と同じ性質です。生成AIのハルシネーション対策で書いた「根拠を出させる」「聞き方を分ける」といった工夫は、RAGでもそのまま効きます。

対象文書の準備でほぼ決まる

私が一番時間を使ったのは、AIの設定ではなく文書の側でした。

揃っていない文書は入れない

とりあえず共有フォルダを丸ごと対象にする、という発想が最初に出ますが、これはやめたほうがいいです。共有フォルダには、下書き、旧版、個人メモ、誰かの作業ファイルが混ざっています。それらを根拠に回答が作られると、間違いの原因が追えなくなります。

最初は範囲を狭くして、次の条件を満たすものだけを入れるほうが結果的に早いです。

• 最新版がどれか決まっている
• 誰が更新するか決まっている
• 全社員が見てよい内容である

版管理されていない文書は害になる

「2024年版」「最新版_修正済」「最新版_修正済_final」が同居しているフォルダを対象にすると、AIは平気で古いほうを根拠にします。人間なら日付を見て判断しますが、検索は文章の近さで拾うので、そこは見ていません。

これは技術で解決するより、対象から外すほうが確実でした。

表記のゆれを吸収する

社内用語と、社員が実際に検索するときの言葉はよくずれます。規程には「特別休暇」と書いてあるのに、みんなが検索するのは「慶弔休暇」だった、という具合です。

このずれは、文書に別名を書き足しておくか、質問側を言い換えて検索する仕組みで埋めます。ここを放置すると「何も出てこないAI」になって、誰も使わなくなります。

導入前に決めておくこと

技術検証より先に、これを決めておかないと途中で止まります。

誰が何を見てよいか

社内文書には、全社公開のものと、部署限定のものが混ざります。RAGは検索してきた内容をそのまま回答に出すので、権限設計を先にやらないと、見えてはいけない情報が答えの中に出ます。

安全側に倒すなら、最初は全社員が見てよい文書だけを対象にすることです。人事評価、給与、採用、法務案件のような機微な文書は、権限を分けられる目処が立つまで入れない判断をしました。

情報の扱い全般については、生成AIの情報漏洩対策と社内AI利用ガイドラインの作り方のほうで整理しています。

更新を誰がやるか

文書が更新されたのに、AIが読む側が古いままだと、間違った回答が出続けます。「誰がいつ反映するか」を決めていないと、半年後には誰も信用しないシステムになります。

担当が決められないなら、対象文書を減らすほうがいいです。維持できない範囲まで広げても、精度が落ちるだけでした。

出典を必ず出す形にする

回答だけを表示する作りにしないでください。「どの文書の、どのあたりを根拠にしたか」を必ず添える。これがあると、利用者が自分で確認でき、間違いにも気づけます。

出典が無いと、便利なうちは使われますが、一度誤りが見つかった瞬間に全面的に信用されなくなります。

答えられないときの挙動を決める

根拠が見つからないときに、無理に答えさせない。「該当する記載が見つかりませんでした」と返す方が、それらしい嘘より役に立ちます。ここは指示の書き方で調整できる部分です。

RAGを使わないほうがよい場面

全部をRAGにしようとすると、かえって手間が増えます。私が向いていないと感じたのは次のケースです。

• 文書が数十件しかない：必要なものを直接貼るほうが速く、確認も楽
• 答えが文書に書かれていない：判断や交渉の余地があるものは、そもそも検索で出てこない
• 正確さが絶対に必要：契約や申請の可否は、要約ではなく原文を読むべき
• 文書がまだ整っていない：整備前に入れると、散らかった状態がそのまま回答に出る

最後が一番多い落とし穴です。RAGの導入は、文書整備をやらずに済ませる方法ではありません。むしろ、整備されていない状態が可視化されます。

ファインチューニングとの違い

よく比較されますが、目的が違います。

	RAG	ファインチューニング
やること	検索した文書を読ませる	モデル自体を追加学習させる
内容の更新	文書を差し替えれば反映	学習をやり直す必要がある
向く用途	事実・規程・マニュアルの参照	文体や出力形式の固定
出典の提示	できる	難しい

社内文書のように中身が変わっていくものは、RAGのほうが素直です。文書を直せば答えも変わるので、運用の見通しが立ちやすい。

小さく試すなら

いきなり全社向けに作らず、次の順で試すのが現実的でした。

1. よく聞かれる質問を20個書き出す（ここが評価基準になる）
2. その答えが書いてある文書だけを対象にする（10〜30件程度）
3. 20問を投げて、正解・出典あり・誤りの3分類で数える
4. 誤りの原因が検索側か文書側かを見る
5. 文書を直してから、対象を広げる

3をやらずに広げると、良くなったのか悪くなったのかが分からなくなります。数を数えるだけでも判断がかなり楽になりました。

こうした仕組みの検討や、業務プロセスへの落とし込みまで含めて体系的に学びたい場合は、講座を使って一度整理する選択肢もあります。独学だと、動くものは作れても運用設計まで手が回りにくいところです。

私の結論

RAGは、社内文書を検索してAIに読ませるだけの仕組みです。技術的な難しさより、どの文書を対象にするか、誰が見てよいか、誰が更新するかを決めるほうが大変でした。

逆に言うと、文書が整っていて、範囲が決まっていれば、想像よりずっと素直に動きます。まずは質問20個ぶんの狭い範囲から始めて、答えられなかったものを一つずつ潰していく。この進め方が、遠回りに見えて一番確実でした。