「社内文書を生成AIに読ませたい」
この要望が出ると、多くの検討会でRAGという言葉が登場します。
そして、いつの間にか「社内文書をすべて登録すれば、何でも正確に答える社内AIができる」という計画へ膨らんでいきます。
ここで一度、立ち止まる必要があります。
RAGを導入すれば、生成AIそのものが賢くなるわけではありません。
検索対象の文書が古ければ古い情報を使い、内容が矛盾していれば矛盾した資料のどちらかを根拠に回答します。
権限設計を誤れば、本人が本来見られない文書を回答へ混ぜる危険もあります。
つまり、RAGは社内情報の問題を解決する魔法ではなく、社内情報の状態をそのままAIの回答へ映し出す仕組みです。
「どの製品でRAGを作るか」は重要ではありません。
重要なのは、「誰が、どの業務で、どの情報を探す時間を減らしたいのか」です。
この問いに具体的に答えられなければ、RAGを構築しても使われない社内検索が一つ増えるだけです。
一方、問い合わせが繰り返し発生し、回答の根拠となる文書が管理されている業務では、RAGは大きな効果を発揮します。
必要なのは、「RAGを導入できるか」ではなく、「自社の課題はRAGでなければ解決できないか」という判断です。
本記事では、RAGの仕組みを初めて聞く方にも分かるように説明したうえで、導入すべき企業と不要な企業を分ける判断基準を整理します。
文書、権限、評価、運用、費用の前提条件と、GenUを使って小さく検証する方法も解説します。
関連記事：GenUとは？非エンジニアの決裁者が知るべき発注判断
RAGとは
RAGはRetrieval-Augmented Generationの略で、日本語では「検索拡張生成」と呼ばれます。
利用者の質問に関係する情報を社内文書などから検索し、見つけた情報を生成AIへ渡して回答を作る仕組みです。
たとえば、社員が「海外出張の宿泊費の上限はいくらですか」と質問したとします。
通常の生成AIは、一般的な知識や学習時点の情報を基に回答します。
自社の旅費規程は知らないため、答えられないか、一般論をそれらしく回答する可能性があります。
RAGを使う場合は、最初に社内の旅費規程を検索します。
関連する条文を見つけ、その内容を質問と一緒に生成AIへ渡し、「この資料を根拠に回答してください」と指示します。
生成AIは、検索された規程を基に回答し、構成によっては参照した文書や該当箇所も表示できます。
処理の流れは次のとおりです。
- 利用者が質問する
- 質問に関連する社内文書を検索する
- 見つけた文書の一部を生成AIへ渡す
- 生成AIが文書を根拠に回答する
- 参照元を表示し、人が確認できるようにする
重要なのは、社内文書を生成AIへ再学習させているわけではないことです。
回答するたびに必要な情報を検索し、その場で生成AIへ渡します。
そのため、モデルを再学習するよりも情報の追加や更新を反映しやすく、回答根拠も示しやすいという特徴があります。
RAGで解決できること
RAGが向いているのは、回答に必要な情報が社内に存在するものの、人が見つけるまでに時間がかかっている業務です。
社内固有の情報を使って回答できる
就業規則、製品仕様、保守手順、過去の提案書、問い合わせ履歴などは、一般向けの生成AIが知らない情報です。
RAGでこれらの文書を検索対象にすると、自社固有の情報を使った回答が可能になります。
特に、同じ質問が複数の部署や拠点から繰り返し寄せられている業務では、検索と一次回答を効率化できます。
更新された情報を回答へ反映しやすい
料金表、社内規程、製品仕様のように更新される情報は、モデルの学習時点に依存できません。
検索対象の文書を更新し、RAG側のデータを同期すれば、新しい情報を回答へ反映できます。
ただし、文書を更新しただけで自動的に検索結果へ反映されるとは限りません。
更新の検知、再取り込み、古い版の除外までを運用として設計する必要があります。
回答の根拠を確認できる
社内業務では、答えが自然に見えることより、何を根拠にしたかを確認できることが重要です。
RAGでは、回答とともに参照文書や該当箇所を表示できます。
Amazon Bedrock Knowledge Basesも、生成した回答に引用を含め、元の情報源を確認できる仕組みを提供しています。
人が最終判断を行う業務では、AIの回答だけでなく、根拠文書へすぐ戻れることが実用性につながります。
RAGでは解決できないこと
RAGには向いている課題がある一方、導入しても解決しない問題があります。
間違った文書を正しくすることはできない
RAGは、登録された情報から質問に近い文書を探します。
元の文書が間違っていても、その誤りを自動的に修正する仕組みではありません。
旧版の規程と新版の規程が両方残っていれば、旧版を検索して回答する可能性があります。
部署ごとに異なる手順書があり、どちらが正式版か決まっていなければ、AIにも判断できません。
RAGの回答品質の上限は、登録する情報の品質によって決まります。
社内に存在しない情報は回答できない
熟練者の頭の中にしかない判断基準や、会議で口頭合意しただけの情報は検索できません。
「ベテラン社員と同じ判断をさせたい」と考えても、その判断材料が文書になっていなければ、RAGへ登録するものがありません。
先に必要なのはRAG構築ではなく、暗黙知の聞き取りと文書化です。
数値集計や完全一致検索には別の仕組みが向く場合がある
「今月の売上はいくらか」「在庫が10個未満の商品をすべて出して」といった質問は、最新の構造化データを正確に集計する必要があります。
この用途では、文書を意味的に探すRAGより、データベース、BI、業務システムの検索機能へ接続する方が適切です。
RAGは文章から関連情報を探すことに向いていますが、会計数値や在庫数を確定する台帳の代わりにはなりません。
生成AIの誤回答を完全にはなくせない
関連文書を正しく取得できても、生成AIが内容を読み違えたり、複数の条件を取りこぼしたりする可能性があります。
反対に、必要な文書を検索できなければ、生成AIは不十分な材料で回答します。
RAGは誤回答を減らす方法の一つですが、回答の正しさを保証する仕組みではありません。
RAGを導入すべき企業
RAGを導入する価値が高いのは、次の条件が重なる企業です。
| 状況 | RAGが有効な理由 |
|---|---|
| 社内固有の情報を使う質問が多い | 一般向け生成AIでは回答できない |
| 同じ問い合わせが繰り返されている | 検索と一次回答の削減効果を測りやすい |
| 回答の根拠提示が必要 | 元文書へ戻って人が確認できる |
| 情報が定期的に更新される | モデルの再学習をせず、文書更新で対応しやすい |
| 正式な文書と管理者が決まっている | 回答に使う情報の正しさを維持できる |
| 部署や役職によって閲覧範囲が異なる | 文書単位の権限制御を前提に設計できる |
具体的には、社内規程への問い合わせ、製品マニュアルの検索、保守担当者の技術調査、営業資料の探索、過去事例の検索などが候補になります。
AWSが公開しているGenUの導入事例でも、社内情報の検索や技術調査への活用が確認されています。
アオラナウ株式会社の事例では、GenUを使った社内RAGにより、技術者の文書検索時間が従来の5分の1程度になったと報告されています。
ただし、この数字をそのまま自社の効果見込みには使えません。
対象文書の量、質問の難しさ、現在の検索時間によって効果は変わるため、自社の実測値で検証します。
RAGが不要、または導入を急ぐべきでない企業
社内で生成AIを使うからといって、すべての企業にRAGが必要なわけではありません。
文章作成や要約が主な用途ならRAGは不要
メールの下書き、文章の校正、議事録の要約、アイデア出しなどは、利用者がその場で材料を渡せます。
社内文書を横断検索する必要がなければ、通常の生成AI機能から始める方が簡単です。
RAGを追加すると、構築費と運用負担が増えます。
使わない検索機能へ投資する必要はありません。
問い合わせ自体が少ないなら投資を回収しにくい
月に数回しか発生せず、担当者が短時間で回答できる問い合わせでは、RAGを構築する効果が限られます。
技術的に実現できることと、投資する価値があることは別です。
現在かかっている検索時間、問い合わせ件数、回答者の人件費を確認してから判断します。
文書の正式版が決まっていないなら先に整理する
共有フォルダに「最終版」「最終版2」「確定版」といったファイルが並んでいる状態では、RAGも正しい版を選べません。
文書の管理者、正式版、改定日、廃止日を決める作業が先です。
この整理は遠回りに見えますが、RAG導入後の誤回答対応を減らします。
利用者ごとの閲覧権限を引き継げないなら見送る
人事資料、契約書、顧客情報、経営会議資料を同じ検索対象へ入れる場合、利用者ごとに見られる範囲を変える必要があります。
AIの画面へログインできることと、すべての登録文書を閲覧できることは同じではありません。
既存の権限をRAGへ反映できない場合は、対象文書を機密度の低い範囲へ限定するか、導入を見送るべきです。
RAG導入前に確認する文書と権限
RAGの製品選定に入る前に、検索対象となる情報を確認します。
最低限、次の項目を文書群ごとに整理してください。
| 確認項目 | 確認する内容 |
|---|---|
| 利用目的 | 誰が、どの業務で、何を質問するか |
| 正式性 | 回答根拠として使ってよい正式文書か |
| 更新 | 管理者、改定日、廃止版の扱いが決まっているか |
| 形式 | PDF、Word、表、画像などを正しく読み取れるか |
| 権限 | 部署、役職、案件ごとの閲覧制限を維持できるか |
| 機密性 | 個人情報、営業秘密、契約上の制限を含むか |
| 質問実績 | 実際に繰り返されている質問が存在するか |
Amazon BedrockのManaged Knowledge Baseは、SharePoint、Confluence、Google Drive、OneDriveなどとの接続や、検索時の文書単位の権限フィルタリングを提供しています。
ただし、製品側に機能があるだけでは不十分です。
元の文書管理システムで権限が正しく設定されていなければ、その誤りも引き継がれます。
「RAG用に全社文書をコピーする」のではなく、正式な保存場所と権限を基準に検索する構成が望ましいです。
RAGの精度をどう評価するか
RAGのPoCでは、数件の質問へ自然な回答が返っただけで成功と判断しないでください。
回答までには「正しい文書を見つける処理」と「見つけた文書を使って回答する処理」があります。
この二つを分けて評価しなければ、問題が検索にあるのか、生成AIの読み取りにあるのか判断できません。
主な評価項目は次のとおりです。
| 評価項目 | 見る内容 |
|---|---|
| 検索成功率 | 回答に必要な文書を検索できたか |
| 根拠との一致 | 回答内容が参照文書で裏付けられているか |
| 回答の完全性 | 必要な条件や例外を取りこぼしていないか |
| 引用の正確性 | 表示した出典が回答を本当に支えているか |
| 回答拒否 | 根拠がない質問へ無理に答えず、不明と言えるか |
| 権限の正確性 | 利用者が見られない文書を取得していないか |
| 業務効果 | 検索時間、問い合わせ件数、確認時間が減ったか |
評価用の質問は、開発者が考えた簡単な質問だけでは足りません。
実際の問い合わせ履歴や、現場担当者が検索に苦労した質問から作ります。
通常の質問だけでなく、情報が存在しない質問、古い名称を使った質問、複数文書を読まなければ答えられない質問も含めます。
最終的にはAIの点数ではなく、人が回答を探して確認する時間をどれだけ減らせたかで判断します。
RAGの導入費用と運用コスト
RAGの費用は、生成AIの利用料だけでは決まりません。
導入時と運用時に、次の費用が発生します。
| 区分 | 主な費用 |
|---|---|
| 導入時 | 対象業務の整理、文書調査、検索基盤、データ取り込み、認証・権限設定、画面、評価 |
| 運用時 | 文書同期、検索用データの更新、生成AI利用料、保存領域、監視、問い合わせ対応、再評価 |
| 改善時 | 検索方式の調整、文書分割の見直し、質問例の追加、モデル変更への対応 |
見落とされやすいのは、文書を管理し続ける人の費用です。
規程が改定されたときに誰がRAGへの反映を確認するのか、誤回答が報告されたときに誰が原因を調べるのかを決める必要があります。
全社文書から始めると、データ量だけでなく、権限確認と評価の範囲も一気に広がります。
まず一つの部署、一つの文書群、一つの問い合わせ業務へ絞った方が、費用と効果を把握しやすくなります。
GenUでRAGを小さく検証する方法
GenUは、AWSがオープンソースで公開している生成AIのユースケース集です。
通常のチャット、要約、議事録作成などに加え、Amazon KendraやAmazon Bedrock Knowledge Basesを使ったRAGチャットを利用できます。
GenUの利点は、RAGだけを単独開発する前に、社内向け生成AI環境の中で利用場面を検証できることです。
最初から全社文書を登録する必要はありません。
たとえば、情報システム部門の申請マニュアル、営業部門の商品資料、保守部門の作業手順書など、管理者が明確な文書群を一つ選びます。
その部署で実際に発生した質問を使い、検索できるか、回答根拠が正しいか、確認時間が減るかを測ります。
効果が確認できれば対象文書と利用者を広げ、効果がなければRAGを追加投資せずに通常の生成AI機能だけを使う判断もできます。
GenUが向いているのは、AWS環境で自社専用の生成AI利用基盤を持ち、RAGを段階的に追加したい企業です。
すでにMicrosoft 365やGoogle Workspaceの生成AIと検索機能で要件を満たしている場合は、GenUを追加する必要がないこともあります。
製品名から決めるのではなく、既存環境で不足している機能と、自社で維持できる運用体制から判断してください。
ネクスト株式会社の生成AIスターターパックでは、19万8,000円から自社AWS環境へGenUを構築し、通常の生成AI利用からRAGや業務連携へ段階的に拡張できる基盤を用意します。
自社にRAGが必要かを判断する
最後に、導入判断を整理します。
| 質問 | 「はい」の場合 |
|---|---|
| 回答に社内固有または最新の情報が必要か | RAGを検討する理由がある |
| 同じ検索や問い合わせが繰り返されているか | 投資効果を見込める |
| 回答根拠として使える正式文書があるか | PoCへ進める |
| 文書の管理者と更新方法が決まっているか | 運用可能性がある |
| 利用者ごとの閲覧権限を維持できるか | 対象範囲を広げられる |
| 実際の質問を使って評価できるか | 本番移行を判断できる |
最初の二つが「いいえ」であれば、RAGを導入する理由は弱いと考えられます。
社内情報が不要な文章作成や要約から、通常の生成AIを試す方が適切です。
社内情報は必要でも、正式文書、更新、権限の条件が整っていなければ、RAG構築より先に情報管理を改善します。
すべての条件が整っている必要はありませんが、未整備の項目を誰が、いつまでに補うかを決めてからPoCへ進みます。
まとめ
RAGとは、利用者の質問に関連する情報を社内文書などから検索し、生成AIの回答へ反映する仕組みです。
社内固有の情報、更新される情報、回答根拠が必要な業務では、大きな効果を期待できます。
一方で、RAGは間違った文書を修正せず、暗黙知を自動的に文書化せず、生成AIの誤回答も完全にはなくしません。
自社にRAGが必要かどうかは、社内情報を使う質問の量、正式文書の有無、更新体制、閲覧権限、評価方法から判断します。
RAGが必要と判断した場合も、最初から全社文書を対象にしないでください。
一つの部署、一つの文書群、一つの問い合わせ業務から始め、検索時間と確認時間が実際に減るかを測ることが重要です。
ネクスト株式会社の生成AIスターターパックでは、19万8,000円から自社AWS環境へGenUを構築し、通常の生成AI利用からRAGや業務連携へ段階的に拡張できる基盤を用意します。
RAGの構築を前提にせず、対象業務と文書の状態を確認し、「そもそもRAGが必要か」を整理する段階からご相談いただけます。
まだ社内向け生成AIの基盤選定から検討している場合は、GenUとは？非エンジニアの決裁者が知るべき発注判断もご覧ください。