RAGとは？社内の資料を参照して答えるAIの仕組みと導入前に確認したいこと

社内の規程やマニュアルについて質問すると、該当する資料をもとに回答が返ってくる。そのようなAIの仕組みとして、よく名前が挙がるのがRAGです。RAGはRetrieval-Augmented Generationの略で、日本語では「検索拡張生成」と訳されることがあります。

一般的な対話型のAIは、学習に使われた情報をもとに文章を作ります。そのため、自社の就業規則や商品の仕様のように社内にしかない情報は、そのままでは答えられません。RAGは、こうした社内の情報を回答に使うための設計の一つです。

この記事では、RAGの仕組みを専門知識がない方にも分かるように説明します。あわせて、導入を考えるときに確認したい点を整理しました。

RAGは「検索してから答える」仕組み

RAGを短く説明すると、質問に関係する社内資料を先に探し、その内容を材料にしてAIが回答文を作る仕組みです。AIのモデルそのものに社内の情報を覚えさせるわけではありません。質問のたびに資料を探し、見つかった文章をAIへ渡します。

元になった研究では、文書の検索と文章の生成を組み合わせる方法が示されています（RAGの原論文）。現在は、この考え方をもとにした様々な構成が使われています。

たとえば「出張の日当はいくらか」という質問なら、RAGの仕組みではまず出張旅費規程の該当箇所を探します。次に、その条文と質問をあわせてAIに渡し、条文の内容に沿った回答文を作らせる流れです。

資料を差し替え、検索用データへの反映が完了すれば、新しい内容を検索の対象にできます。AIのモデルを作り直さなくても、回答に使う情報を更新できる点が、RAGの特徴です。

質問から回答までの流れ

RAGを使ったアプリは、おおむね次の順序で動きます。

1. 事前に、社内の資料を小さなまとまりに分けて検索用に登録する。
2. 利用者が質問を入力すると、質問に近い内容の文章を探す。
3. 見つかった文章と質問をあわせてAIに渡す。
4. AIが資料の内容をもとに回答文を作り、参照した資料名とあわせて表示する。

1の「小さなまとまり」は、見出しや段落の単位で区切ることが多いです。長い資料を丸ごと渡すより、関係する部分だけを渡したほうが、回答の根拠をたどりやすくなります。

2の検索には、言葉の一致で探す方法と、意味の近さで探す方法があります。後者はベクトル検索と呼ばれ、文章を数値の並びに変換して、内容が近いものを探す方法です。「休暇の申請方法」と「有給の取り方」のように、言い方が違っても関係する文章を見つけやすくなります。両方を組み合わせる構成もあります。

どの方法が合うかは資料の種類や質問のされ方によって異なり、一概には決められません。開発の初期に、実際の質問例を使って検索結果を確かめておくと判断しやすくなるでしょう。

RAGが向いている業務

RAGが向いているのは、答えの根拠が社内の文書にあり、その文書を毎回探している業務です。たとえば、社内規程や手続きに関する社員からの問い合わせ、製品資料をもとにした顧客への回答案づくりが挙げられます。過去の提案書や報告書から似た事例を探す作業も、対象の一つです。

反対に、答えが文書にまとまっていない業務では、RAGだけでは効果が出にくくなります。担当者の経験や判断に頼っている業務なら、先に手順や判断基準を文書にする作業が必要です。

社内マニュアルの検索に絞った活用方法は、社内マニュアルや規程の検索をAIで改善する方法で詳しく説明しています。

RAGを使っても誤回答はなくならない

RAGは、資料を参照しない場合と比べて、根拠のある回答を作りやすくする方法です。ただし、誤った回答が出なくなるわけではありません。

誤回答が起きる理由は一つではありません。検索で関係の薄い文章が選ばれた場合、AIはその文章をもとに答えてしまいます。資料そのものが古ければ、回答も古い内容のままです。資料に答えが書かれていないときに、AIが一般的な知識で補った文章を作ることもあります。

このため、RAGのアプリでは、回答と一緒に参照した資料名や該当箇所を表示する設計がよく使われます。利用者が元の資料を開いて確認できれば、誤りに気づきやすくなるからです。資料が見つからない場合は「該当する資料が見つかりません」と返すように指示しておくことも、対策の一つになります。

金額や契約条件のように間違いが許されない内容は、AIの回答をそのまま使わず、人が確認する手順を残してください。誤回答への備え方は、AIの誤回答（ハルシネーション）に備える設計でも整理しています。

導入前に確認したい3つのこと

RAGの回答の質は、参照する資料の状態に大きく左右されます。開発を始める前に、次の3点を確認しておくと進めやすいでしょう。

1つ目は、資料の最新版がどれかです。同じ規程の古い版と新しい版が共有フォルダに並んでいると、古い版が検索される可能性があります。スキャンした画像のPDFや、表が多い資料は、文字を取り出す処理が別に必要になることもあります。

2つ目は、閲覧権限です。人事評価の資料のように一部の社員しか見られない文書を登録すると、AIの回答を通じて他の社員に内容が伝わるおそれがあります。誰がどの資料を見られるかを整理し、検索の段階で権限を反映させる設計が必要です。

3つ目は、資料を更新する担当者です。規程が改定されたときに、誰がいつ登録内容を差し替えるのかを決めておきましょう。公開後の運用まで決めておくと、回答の内容を新しい状態に保てます。

備品の申請方法を質問した場合の具体例

架空の会社で、「在宅勤務用のモニターを借りたい」と社員が質問したとします。備品管理の手順書には「所属長の承認後、備品申請フォームから申し込む」と書かれており、個人で購入した物の精算方法は記載されていない想定です。

検索では、「モニター」「貸与」「備品申請」などの関係する記述を探します。回答生成では、その文章を使い「所属長の承認後、備品申請フォームから申し込んでください」と案内します。出典として手順書の見出しとリンクを示せば、社員は必要に応じて全文を読めます。

続けて「先に自分で買って、後で精算してよいか」と聞かれた場合、同じ資料だけでは答えが出ません。このときは精算できると推測せず、「参照した手順書では確認できないため、備品管理担当へ確認してください」と返す設計にします。質問に関連した資料が見つかることと、その質問の答えが載っていることは別です。

検索と回答生成を分けて評価する

回答が間違っていたら、最初に検索された文章を確認します。正しい資料を見つけていないなら、文章の書き方を変える前に検索の対象や方法を見直します。根拠を拾えているのに違う答えを返す場合は、生成時の指示や資料の渡し方を調べます。

表にある改善は一例です。原因を調べずに資料を増やし続けると、似た文章が増えてかえって選びにくくなる場合があります。まず、間違った質問について何が検索されたかを確認できる状態にしましょう。

試験用の質問は例外も含めて作る

試験では、手順書の見出しをそのまま質問するだけでは不十分です。社員が使いそうな話し言葉、略称、条件の足りない質問も用意します。モニター貸与の例なら、「画面をもう一枚ほしい」「家用の備品はどう頼むか」などです。

さらに、資料に答えがない質問、廃止された手順についての質問、閲覧できない部署の資料に関する質問を用意します。業務担当者が期待する答えと根拠を先に記録し、AIの回答を見てから正解を変えないようにします。

試用後には、正しく答えた割合だけでなく、出典へたどれたか、答えがない場合に止まれたかを確認します。利用者が結局いつも担当者へ聞き直しているなら、回答の内容や表示方法に改善の余地があります。

RAGを選ぶ前によくある疑問

社内資料はすべて登録する必要がありますか

最初は一つの業務で使う承認済み資料に絞れます。対象を増やす際は、閲覧権限と更新担当を確認してから追加します。資料量だけで導入の出来を判断しないことが大切です。

資料を更新すればすぐ回答も変わりますか

反映される時期は、アプリの取込みや検索用データの更新方法によって異なります。元ファイルを差し替えただけで更新が完了するとは限りません。更新完了の記録と、変更した箇所への質問を使って確かめる手順が必要です。

まとめ

RAGは、社内の資料を検索し、その内容をもとにAIが回答を作る仕組みです。モデルを作り直さずに社内の情報を使えるため、規程や製品資料の問い合わせ対応などで検討されています。

一方で、検索の精度、資料の新しさ、閲覧権限の扱いは、アプリ側で設計する必要があります。まずは対象にしたい業務を一つ選び、使う資料と質問例を集めるところから始めてみてください。

e-Grantsでは、RAGやLLMを使ったアプリケーションについて、課題の整理から設計・開発、公開後の保守運用まで対応しています。社内資料を使ったAIの活用を考えている方は、AIアプリケーション受託開発のページをご覧ください。