RAGとは何か社内資料検索AIで使われる仕組みを実務目線で解説

RAGという言葉を聞く機会が増えています。社内資料検索AI、ナレッジ検索、AIチャットボット、問い合わせ対応AIなどの説明でよく出てくる言葉です。

ただ、名前だけを聞くと少し分かりにくいです。AIに資料を覚えさせる仕組みだと思われることもありますが、実務ではそう理解すると判断を間違えます。

RAGは、AIが回答する前に必要な資料を検索し、その検索結果を材料にして回答する仕組みです。社内資料をすべてAIの頭の中に入れるのではなく、質問に関係する資料を都度探してから答えを作ります。

この違いを分かっておくと、社内資料検索AIを検討する時に、ベンダーや社内担当者へ聞くべきことが変わります。見るべきものは、AIの賢さだけではありません。どの資料をどう分けるか、どう検索するか、回答の根拠を見せられるか、古い資料を使わないか、見てはいけない資料を見せないか。RAGではこの部分が成果を左右します。

RAGは検索してから回答する仕組み

RAGは Retrieval Augmented Generation の略です。日本語では検索拡張生成と訳されることがあります。

流れは大きく分けると次のようになります。

利用者が質問する
システムが関係しそうな資料を検索する
検索で見つかった本文をAIに渡す
AIがその内容をもとに回答する
必要に応じて根拠資料へのリンクを表示する

通常の生成AIは、学習済みの知識や会話中に渡された情報をもとに回答します。RAGでは、その場で外部の資料を探してから回答します。社内ルール、製品仕様、見積条件、過去の議事録、問い合わせ履歴のように、会社ごとに内容が違う情報を扱う時に使われます。

この仕組みは、AIの回答を必ず正しくするものではありません。検索で関係ない資料を拾えば、AIも関係ない内容をもとに答えます。資料が古ければ、古い情報を使った回答になります。RAGは「AIが何でも知っている状態」を作る技術ではなく、「必要な資料へ戻りやすくする技術」と考えた方が実務に近いです。

ChatGPTにファイルを渡すだけの場合との違い

少量の資料なら、ChatGPTなどにファイルを渡して質問するだけでも十分役に立ちます。1つのPDFを要約する、数件の議事録から論点を抜き出す、提案書の下書きを整える。こうした作業なら、RAGを組む必要はないことも多いです。

RAGが必要になるのは、資料が増え、利用者が増え、継続的に使う時です。

たとえば、社内に数百件のPDFやマニュアルがあり、部署ごとに見られる資料が違い、資料も定期的に更新される。この状態で毎回ファイルを手で選んでAIに渡すのは現実的ではありません。利用者は、どの資料を選べばよいか分からないまま質問します。だからシステム側で関係資料を探す仕組みが必要になります。

RAGでは、資料をあらかじめ検索しやすい形にしておきます。質問が来たら、システムが候補資料を探し、その一部をAIに渡します。利用者から見るとAIチャットに質問しているだけでも、裏側では検索と回答生成が分かれています。

チャンクとは資料を分ける単位

RAGでよく出てくる言葉にチャンクがあります。チャンクは、資料を検索に使いやすい大きさへ分けた文章のかたまりです。

社内規程のPDFを丸ごと1つのデータとして扱うと、質問に関係する箇所だけを取り出しにくくなります。反対に、1文ずつ細かく分けすぎると、前後の文脈が足りなくなります。

たとえば、休暇申請のルールを検索したいのに、チャンクが大きすぎると就業規則全体が候補になります。小さすぎると「申請は3営業日前まで」とだけ返り、その対象が有給休暇なのか特別休暇なのか分からなくなります。

チャンクの大きさに絶対の正解はありません。マニュアル、議事録、FAQ、契約条件、製品仕様書では適した分け方が違います。RAGを導入する時は、AIモデル名だけでなく、資料をどの単位で分けるのかを確認してください。

埋め込みとベクトル検索は意味の近さを見るための仕組み

RAGでは、埋め込みやベクトル検索という言葉もよく出ます。

埋め込みは、文章の意味を数値の並びに変換する処理です。ベクトル検索は、その数値を使って意味が近い文章を探す検索方法です。

通常のキーワード検索では、言葉が一致しているかが強く効きます。たとえば「退職時の手続き」と検索した時に、資料側に「離職時の対応」と書かれていると見つかりにくいことがあります。ベクトル検索では、言葉が完全に一致しなくても、意味が近ければ候補に出せる可能性があります。

ただし、ベクトル検索だけで十分とは限りません。型番、顧客コード、日付、金額、規程番号のように、言葉の意味より完全一致が大事な情報もあります。社内利用では、キーワード検索とベクトル検索を組み合わせる設計が必要になることがあります。

「最新の料金表を出したい」「A社の2025年契約条件だけを見たい」「規程第12条を確認したい」といった質問では、意味の近さだけでは危ない場面があります。RAGの検索方法を確認する時は、意味検索だけでなく、日付、部署、版、顧客名、権限などの条件で絞れるかを見る必要があります。

根拠表示がないRAGは業務で使いにくい

社内利用でRAGを使うなら、回答だけでなく根拠資料へ戻れることが大切です。

AIが自然な文章で答えると、正しそうに見えます。しかし、どの資料をもとに答えたのか分からなければ、重要な判断には使いにくいです。特に、料金、契約条件、社内手続き、顧客対応方針、製品仕様のような情報では、原文に戻って確認できる設計が必要です。

根拠表示には、少なくとも次の情報がほしいです。

資料名
該当箇所
更新日
版やバージョン
閲覧できる人
原文へのリンク

この情報があると、利用者はAIの回答をうのみにせず、必要な時に原文へ戻れます。回答の品質を上げるだけでなく、間違いを発見しやすくするためにも根拠表示は必要です。

RAGでも誤回答は起きる

RAGを入れると、AIが社内資料を参照できるようになります。それでも誤回答は起きます。

原因は主に3つあります。

1つ目は、検索で必要な資料を見つけられないことです。資料名が分かりにくい、古い資料が混ざっている、チャンクの切り方が悪い、質問文と資料の表現が離れている。こうした状態では、AIに渡す前の検索で失敗します。

2つ目は、検索で見つけた資料をAIが読み違えることです。前提条件を落とす、例外規定を一般ルールのように扱う、複数資料の優先順位を間違える。文章生成の段階で起きる失敗です。

3つ目は、資料そのものが間違っていることです。古い料金表、更新されていないマニュアル、現場で使われなくなった手順書を検索対象に入れていれば、RAGはそれを材料に回答します。

RAGの精度確認では、回答文だけを見ても不十分です。どの資料が検索されたか、その資料は正しいか、回答は資料の内容を正しく使っているかを分けて見る必要があります。

権限管理を後回しにしない

社内資料を扱うRAGでは、権限管理が大きな論点になります。

検索対象に給与資料、人事評価、個別の取引条件、経営資料、顧客の個人情報が含まれる場合、全員が同じように検索できる設計では危険です。AIが直接ファイルを開かなくても、検索結果として内容の一部を回答に混ぜてしまう可能性があります。

確認すべきことは、利用者の権限が検索段階にも反映されるかです。回答生成の直前だけで制限するのではなく、そもそも見てはいけない資料が検索候補に入らないようにする必要があります。

小さく始めるなら、最初は全社員が見ても問題ない資料だけを対象にする方が現実的です。FAQ、公開済みの商品説明、社内手続きの一般ルール、教育用マニュアルなどです。権限が複雑な資料は、RAGの便利さより先に管理ルールを確認してください。

RAGが向いている業務

RAGが向いているのは、資料を探す時間が多く、回答の根拠を確認したい業務です。

たとえば、次のような場面です。

社内規程や手続きの確認
製品マニュアルや仕様書の検索
問い合わせ対応の過去事例検索
営業資料や提案書の部品探し
新人向けの業務Q&A
店舗や拠点ごとのルール確認
保守対応で過去の対応記録を探す

一方で、RAGに向かない使い方もあります。

最新の在庫数や予約枠のように、リアルタイムの業務データを正確に更新し続ける必要があるものは、RAGだけで扱うより業務システムとの連携が必要です。最終的な契約判断、法務判断、金額承認のように責任が重いものも、AIの回答だけで完結させるべきではありません。

RAGは、資料を探して判断の入口を作る仕組みです。業務の最終判断や承認まで置き換える仕組みではありません。

ベンダーや社内担当者に聞くべき質問

RAGを導入する時は、デモ画面の回答が自然かどうかだけで判断しない方がよいです。最初に聞くべき質問は、AIの文章力より検索と運用に関するものです。

確認したい質問は次の通りです。

資料はどの単位で分けて検索されるのか
PDF、Word、スプレッドシート、Webページをどう扱うのか
版や更新日を検索条件に使えるのか
回答に使った根拠資料を表示できるのか
利用者ごとの閲覧権限を検索時点で反映できるのか
古い資料や重複資料をどう除外するのか
回答が間違っていた時に原因を追えるのか
よくある質問で精度を定期的に確認できるのか
社内で誰が資料の追加と削除を管理するのか

この質問に答えられないまま導入すると、最初のデモでは便利に見えても、実運用で「それらしいが確認できない回答」が増えます。

小さく試すなら評価用の質問を先に作る

RAGの試行では、先に評価用の質問を作ると判断しやすくなります。

たとえば、対象資料を30件ほどに絞り、現場で実際に聞かれそうな質問を10個から20個用意します。その質問に対して、正しい資料を検索できたか、回答に根拠が出たか、古い資料を使わなかったか、権限を守れたかを確認します。

質問は簡単なものだけでは足りません。言い換えを含む質問、日付や部署で絞る質問、似た資料が複数ある質問、答えてはいけない質問も入れます。

例としては、次のようなものです。

交通費精算の締切はいつか
出張申請と宿泊費精算の違いは何か
旧料金表ではなく最新版の料金条件を確認したい
A部署の担当者だけが見られる資料は回答に出ないか
資料にない内容を聞いた時に無理に答えないか

このような評価をすると、AIの文章がうまいかどうかではなく、業務で使える検索になっているかを見られます。

RAGを理解すると導入判断がしやすくなる

RAGは、社内資料検索AIの中心になることが多い仕組みです。ただし、RAGという言葉を知っているだけでは足りません。

実務で見るべきなのは、資料をどう分けるか、どう検索するか、根拠をどう出すか、権限をどう守るか、間違いをどう見つけるかです。ここを確認できると、AIツールの比較やベンダー相談で話が具体的になります。

まずは全社導入ではなく、1つの部署、1つの資料群、10個程度の質問から試すのが現実的です。そこで検索できない資料、答えがぶれる質問、権限上扱いにくい資料が見えてきます。

自社の資料でRAGを使えるか分からない場合は、資料の種類、更新頻度、権限、よくある質問を一緒に整理できます。社内資料検索AIやRAGの導入を検討している場合は、無料相談からご相談ください。