RAGとは？小規模企業のAIチャットボットで自社情報を回答させる仕組みと導入判断

01

RAGは、AIチャットボットに自社の資料を参照させる仕組み

RAGはRetrieval-Augmented Generationの略で、日本語では検索拡張生成と呼ばれます。NISTは、生成AIモデルと独立した情報検索システム、または知識ベースを組み合わせ、質問に関係する情報をモデルへ文脈として渡す仕組みと説明しています。2020年に発表された原論文では、モデル内部の知識と、検索できる外部の知識を組み合わせる考え方が示されました。

一般的な生成AIは、学習時に得た知識だけでは、ある会社の最新商品、送料、返品条件、社内ルールを正しく把握できません。RAGを使うと、質問を受けた時点で自社のFAQ、商品説明、利用規約などを検索し、見つかった部分を回答材料として渡せます。資料の変更を知識ベースへ反映すれば、モデルを一から学習し直さずに情報を更新できる点も実務上の利点です。

企業サイトのAIチャットボットでは、利用者の質問、知識ベースの検索、関連箇所の選択、回答生成、根拠の表示、必要に応じた問い合わせへの引き継ぎ、という順に動きます。RAGはこのうち『自社情報を探して渡す』部分を担います。会話画面だけでは見えにくいものの、回答品質を左右する中心的な仕組みです。

02

RAGで改善しやすいことと、RAGだけでは解決しないこと

RAGが役立つのは、回答に必要な情報が自社資料にあり、その中から質問に合う箇所を探せる場合です。たとえば『この商品は屋外で使えるか』『返品できる期間は何日か』『法人向けプランには何が含まれるか』といった質問では、商品ページや規約の該当箇所を参照して回答を組み立てられます。回答の根拠となったページを案内すれば、利用者自身も詳細を確認できます。

一方、知識ベースに正しい情報がなければ、RAGを追加しても正答は作れません。古い料金表と新しい料金表が混在していれば、検索時に古い方を選ぶ可能性があります。検索が正しくても、生成AIが内容を取り違えることもあります。そのため『RAGを使えばハルシネーションがなくなる』とは言えません。検索対象、検索結果、最終回答の三つをそれぞれ管理する必要があります。

在庫、注文状況、予約枠のように頻繁に変わる情報は、資料検索よりもECや業務システムとのAPI連携が適する場合があります。また、返金の承認や契約判断など、人の権限が必要な処理は、回答ではなく担当者への引き継ぎを設計します。RAG、システム連携、人の対応を役割分担することが大切です。

• RAG向き：FAQ、商品仕様、サービス内容、配送・返品条件、操作ガイド
• 別の連携を検討：リアルタイム在庫、注文状況、顧客別の契約内容
• 人へ引き継ぐ：例外対応、承認、専門判断、苦情、個別の交渉

03

小規模企業でRAGを選ぶべき三つのサイン

第一のサインは、同じ質問でも言い方が多いことです。固定キーワードだけでは拾いにくい質問を、意味の近さで資料から探したい場合にRAGが候補になります。第二は、商品やサービスが複数あり、回答に複数ページの情報が必要なことです。第三は、情報が定期的に変わり、更新のたびに会話シナリオを作り直す負担が大きいことです。

逆に、質問が十数種類に限られ、回答文もほとんど変わらないなら、最初は登録済みFAQを返す単純な方式で十分なことがあります。RAGにはデータ整理、検索設定、評価、運用が必要です。技術の新しさではなく、質問の幅と更新負担に見合うかで選びます。

判断に迷う場合は、直近の問い合わせを分類します。回答が一つの定型文で済む質問、複数の資料を横断する質問、顧客ごとの確認が必要な質問に分けると、RAGで扱う範囲が見えてきます。最初から全問い合わせを対象にせず、一つの商品群や一つのサポート業務に限定すると、必要性と効果を確かめやすくなります。

04

ステップ1：知識を『公開』『限定』『登録しない』に分ける

RAG導入の最初の作業は、ファイルを集めることではなく、誰に何を見せてよいかを決めることです。公開サイトのチャットボットなら、すでにWebで公開している商品情報、FAQ、規約、店舗案内などから始めるのが安全です。顧客ごとの契約内容、未公開の価格、営業秘密、個人情報を同じ知識ベースへ混ぜてはいけません。

IPAはRAG利用時の注意点として、公開情報と社内情報など、アクセス権限の異なる情報を混在させる危険を説明しています。検索の段階で閲覧権限を確認しなければ、生成AIへの指示だけでは情報流出を防げない可能性があります。小規模な公開チャットボットでは、まず公開情報専用の知識ベースに分離する方法が分かりやすいでしょう。

個人情報を扱う可能性がある場合は、入力内容、保存先、保存期間、利用目的、サービス提供者の規約やプライバシーポリシーを確認します。個人情報保護委員会も、生成AIサービスへ個人情報を入力する際は、利用規約等と入力情報を踏まえて適切に判断するよう注意を示しています。問い合わせフォームとチャット欄の役割を分け、チャットには不要な個人情報を書かせない案内も検討します。

• 公開：Web掲載済みのFAQ、商品仕様、送料、返品条件、営業時間
• 限定：社内手順、取引先資料、顧客別条件。必要なら権限別の別環境で管理
• 登録しない：利用目的のない個人情報、不要な営業秘密、出所不明の資料

05

ステップ2：検索しやすい資料へ整える

人には読みやすい資料でも、検索には向かない場合があります。長いPDFに複数商品の旧情報が混在している、表の見出しがなく数値だけが並ぶ、画像内にしか重要事項がない、といった状態では、質問に合う箇所を選びにくくなります。まず重複と旧版を除き、一つのテーマごとに正しい情報をまとめます。

資料は意味が途切れない単位に分けます。これを一般にチャンク分割と呼びます。細かすぎると条件や例外が欠け、長すぎると関係の薄い情報まで検索結果へ入りやすくなります。FAQなら質問と回答を一組にし、商品説明なら商品名、対象者、仕様、注意事項を同じまとまりで扱うなど、利用者の質問単位から設計します。

各情報には、ページURL、商品名、カテゴリ、公開範囲、更新日、版、担当者などのメタデータを付けます。検索候補の絞り込み、古い情報の除外、回答への出典表示に使えるためです。特に料金・規約・キャンペーンは、有効期間や現行版を区別できる状態にします。

• 重複資料と旧版を除き、どれが正本かを決める
• 見出しだけで内容が分かるようにし、主語や対象商品を省略しない
• 質問と回答、条件と例外を途中で分断しない
• 出典URL、更新日、公開範囲、担当者を記録する

06

ステップ3：回答の根拠、答えない条件、次の行動を設計する

良いRAGチャットボットは、文章が自然なだけではなく、何を根拠に答えたかを確認できます。回答の末尾に関連ページを示す、重要な条件は原文ページへ案内する、根拠が見つからない場合は推測しない、といったルールを決めます。利用者が詳細を確認でき、運営側も誤回答の原因を調べやすくなります。

検索結果の関連性が低い場合、資料同士が矛盾する場合、個別契約や専門判断が必要な場合は、無理に答えず『確認できませんでした』と伝えます。そのうえで、問い合わせフォーム、商品ページ、担当窓口など次の行動を示します。回答不能を失敗として隠すより、安全な引き継ぎとして設計する方が実用的です。

ECでは、質問へ答えたあとに商品ページ、比較ページ、カート、メール相談などへつなげます。ただし、根拠資料にないおすすめ理由や効果を作らせてはいけません。回答ルールと事業導線を同時に設計すると、FAQ対応にとどまらない接客へ発展させられます。

07

ステップ4：公開前は『検索』と『回答』を分けて評価する

テストでは、最終回答だけを見て合否を決めないことが重要です。まず質問に対して正しい資料が検索されたかを確認し、次に検索された内容に沿って回答できたかを確認します。正しい資料が見つからない問題と、見つかった資料を誤って要約する問題では、修正する場所が異なるためです。

評価用の質問は、実際の問い合わせを中心に作ります。通常の質問だけでなく、言い換え、誤字、条件を二つ含む質問、対象外の質問、答えが資料にない質問、古い商品名を含む質問も用意します。正しい回答、許容できる回答、答えずに引き継ぐべき回答を事前に定義しておくと、担当者の感覚だけに頼らず判定できます。

小さく始めるなら、まず優先度の高い30問程度を用意し、修正後に同じ質問集で再テストします。件数は対象範囲に応じて増やします。AISIの評価観点も、AIシステムのリスクや利用目的を踏まえた評価の重要性を示しています。公開前だけでなく、資料やモデル、設定を変えた後にも再確認できる質問集を残します。

• 検索：正しい資料と該当箇所を選べたか
• 回答：検索した根拠に沿い、条件や例外を落としていないか
• 拒否・引き継ぎ：根拠がない時に推測せず、適切な窓口へ案内できたか
• 安全性：公開対象外の情報や個人情報を返さないか
• 導線：回答後に利用者が次の行動へ進めるか

08

ステップ5：一部のページから公開し、会話ログで改善する

公開は、対象商品やページを限定して始めます。質問の種類、検索された資料、回答できなかった質問、問い合わせへの移動を確認し、対象範囲を広げるか判断します。全サイトへ一度に設置するより、問題が起きた時に原因を特定しやすく、不要な費用も抑えられます。

会話ログでは、利用者の個人情報を必要以上に残さないことを前提に、回答できたかだけでなく、どの情報を探していたかを見ます。同じ質問が多ければFAQや商品ページへ説明を追加し、検索はできても購入へ進まない場合は、回答文やリンク先を見直します。RAGの改善とWebサイトの改善を分けないことが、顧客の声を事業に活かすポイントです。

月次では、登録資料の更新、期限切れ情報、未回答質問、検索精度、引き継ぎ先を確認します。更新が多い情報には担当者と期限を設定し、変更時に知識ベースへ反映する流れを通常業務へ組み込みます。担当が曖昧な知識ベースは、時間とともに回答品質が下がります。

09

RAG導入の効果は、正答率だけで測らない

RAGの技術評価では検索の正しさと回答の根拠性が重要ですが、事業評価には利用者の行動も必要です。たとえばECサイトなら、チャット利用後の商品ページ閲覧、比較、カート追加、問い合わせへの接続を確認します。サポート用途なら、自己解決、担当者への適切な引き継ぎ、対応時間の変化を見ます。

会話数が増えたこと自体は成果とは限りません。チャットを開いたが答えを得られなかった人が増えている可能性もあります。未回答率、同じ質問の繰り返し、低評価、直後の離脱を合わせて確認します。導入前の問い合わせ件数や主要ページの行動を記録しておくと、公開後の変化を比較できます。

検索データが少ない初期は、数値を急いで結論づけず、未回答質問と会話の質を見ます。一定期間ごとに『資料を直す』『検索設定を直す』『回答ルールを直す』『サイトの説明を直す』のどこに課題があるかを分類すると、改善が続けやすくなります。

• 品質：正しい根拠の検索、根拠に沿った回答、安全な回答不能
• 利用：自己解決、担当者への引き継ぎ、同じ質問の再入力
• 事業：商品閲覧、カート追加、問い合わせ、対応時間
• 改善：未回答から追加したFAQ、商品ページや導線の修正

010

発注前に確認したいRAGの質問リスト

RAGという言葉が提案書にあっても、実装と運用の範囲はサービスごとに異なります。ベクトル検索を使うかといった技術名だけで比較せず、自社の情報を誰が整え、どのように権限を分け、誤回答をどう見つけて直すのかを確認します。

特に小規模企業では、初期設定後の更新作業が重すぎないかが重要です。管理画面へ資料を追加するだけなのか、形式変換や分割が必要なのか、更新後に誰がテストするのかまで見積もりに含めます。外部AIサービスへ送られる情報、ログの保存場所と期間、契約終了時の削除方法も確認します。

• どの種類の資料を登録でき、画像や表をどう扱うか
• 公開情報と限定情報を、検索時にどう分離するか
• 根拠が弱い場合に回答を止める設定があるか
• 回答に参照元URLや資料名を表示できるか
• 評価用質問集と合格条件を誰が作るか
• 資料更新、再テスト、障害対応、ログ分析を誰が行うか
• 入力内容と登録資料が学習へ使われるか、保存・削除条件は何か
• RAG以外の連携や人への引き継ぎが必要な範囲はどこか

011

結論：公開情報の一業務から始め、根拠を確認できる状態にする

小規模企業のRAG導入では、資料を大量に登録することより、対象を狭く決め、正しい情報だけを保つことが重要です。まず公開済みのFAQや商品情報から一業務を選び、質問、検索結果、回答、次の行動を一つの流れとしてテストします。RAGが必要ない範囲は単純なFAQで済ませ、リアルタイム情報はシステム連携、人の判断が必要な内容は担当者へ渡します。

RAGは自社情報を活かす有力な手段ですが、品質は知識ベースと運用に左右されます。情報の公開範囲、更新担当、根拠表示、回答不能時の動作、評価用質問集を先に決めておけば、小さく始めながら改善できます。導入の相談では、機能名よりも『誰の、どの質問を、どの情報で解決するか』を最初に確認すると、必要な構成と費用を判断しやすくなります。