%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
RAG構築では、社内データを検索し、回答の根拠として使える状態に整えます。検索結果と回答を分けて確かめ、情報の更新と権限管理まで業務に組み込むことが重要です。
RAG構築では、社内データを検索し、回答の根拠として使える状態に整えます。検索結果と回答を分けて確かめ、情報の更新と権限管理まで業務に組み込むことが重要です。
「必要な資料がどこにあるか分からず、毎回人に聞いている」
「スプレッドシートや共有フォルダの情報が分かれ、更新箇所を探しにくい」
「AIに質問しても、社内固有のルールや顧客状況を踏まえた回答にならない」
RAGとは、質問に関連する外部データを検索し、その情報をLLMに渡して回答を生成する仕組みです。社内文書やCRMの情報を参照させる場合も、検索対象が古い、正本が決まっていない、閲覧権限が曖昧といった状態では、回答の根拠として使えません。
導入の判断は、まず業務上の質問と正解を確認できる資料を結び付けるところから始まります。資料が見つからないなら情報管理を整え、資料は見つかるのに回答がずれるなら回答生成の設定を見直します。社内固有の情報を扱う方法の違いは「ファインチューニングの企業活用ガイド」でも解説しています。
この記事でわかること
この記事では、社内検索やCRM活用を検討する際に、対象業務の選定から文書の準備、検索方式の比較、回答評価、運用への引き継ぎまでを順に説明します。各段階で何を確認し、どの状態になれば次へ進めるかも示します。
- RAGの基本構造 — 検索結果と生成回答を分けて確認し、問題が起きた工程を特定する方法を整理します。
- 検索方式と保存先の選び方 — 同じ質問と資料でキーワード検索とベクトル検索を比べ、構成を選ぶ手順を説明します。
- 社内文書とCRMの統合設計 — 正本、更新、関連付け、閲覧権限を確認し、情報ごとに取得方法を決めます。
- 構築後の評価と改善 — 根拠の有無、回答の解釈、旧版の扱いを確かめ、見直す条件を紹介します。
RAGは、ナレッジを登録すれば完成する仕組みではありません。回答を業務で使う前に人が確認する範囲も含め、運用手順を決めます。確認と責任分担の考え方は「責任あるAI実装ガイド」でも解説しています。
RAGの構造と、LLM単体では答えにくい質問
LLM単体では、社内で更新された手順や個別顧客の状況を、そのまま把握できません。RAGは質問の都度、関連情報を取得して回答に渡します。ただし、必要な情報を検索できたかどうかと、取得した情報を正しく解釈したかどうかは別の確認事項です。
検索、情報追加、回答生成の流れ
RAGの処理は、検索、情報の追加、回答生成という流れで組み立てます。質問を受けると、検索対象から関連する文書やCRM情報を取得します。次に取得内容を質問と合わせてモデルに渡し、回答を生成します。
検証時には、質問、取得した資料、回答、回答が示した根拠を並べて記録します。
- 必要な資料が取得されていない ── 対象資料の登録状況、検索語、分割方法を調べる
- 資料は取得されているのに条件や例外が回答から抜ける ── その箇所がモデルへ渡されているかを確認し、回答形式や指示文を見直す
キーワード検索とベクトル検索
キーワード検索は、質問文に含まれる語句を手掛かりに文書を探します。ベクトル検索は、テキストを数値表現に変換し、語句の一致ではなく意味の近さを使って候補を探します。
| 比較項目 | キーワード検索 | ベクトル検索 |
|---|---|---|
| 手掛かり | 語句の一致や部分一致 | 文や語句の意味的な近さ |
| 得意な場面 | 固有名詞、型番、正確な用語 | 言い換えを含む自然文の質問 |
| 主な調整対象 | 同義語、表記揺れ、検索語 | 分割方法、埋め込み、類似度 |
| 注意点 | 表記が違うと候補から漏れることがあります | 似た内容を広く拾い、不要な候補が混ざることがあります |
| 多言語対応 | 言語別インデックス | 多言語Embeddingで複数言語の文書を検索できます |
| ベクトル検索の計算コスト | 低い | Embeddingの計算コストがかかる |
比較する際は、同じ検索対象と閲覧権限の下で、正式名称を含む質問と、利用者が普段使う言い換えの質問を試します。正本が見つかったかに加え、似ているだけの別資料や旧版が混ざったかを記録します。
- 正式名称では見つかるのに言い換えで漏れる ── 意味検索を検討する
- 固有名詞を取り違える ── キーワード検索との組み合わせを検討する
回答の根拠を追えるようにする
回答から参照した文書やCRMレコードへ辿れるようにします。確認するのは資料名だけではありません。回答の各要点について、参照先のどの箇所がその内容を支えるのか、適用条件や例外まで一致するかを見ます。
引用が表示されても、別の顧客レコードを参照していたり、現行資料の見出しの下に旧手順が残っていたりすれば、業務判断には使えません。根拠が足りない場合は回答を確定させず、資料の管理者や業務担当者に確認します。根拠が適切で解釈だけが違う場合は、検索対象を増やす前に回答生成の工程を調整します。
検索対象の整理とチャンキング
検索対象を選ぶ段階では、資料の量よりも正本と管理責任を明確にすることを優先します。改訂前後の手順が同時に検索される状態では、分割方法やモデルを変えても、どちらを使うべきか判断できません。
先に検索対象と管理責任を決める
資料ごとに、用途、更新頻度、閲覧できる人、管理責任者を整理します。スプレッドシートや個人フォルダに同じ情報がある場合は、どこを更新すれば現行情報になるのかを確認します。正本を決められない資料は、登録を急がず、業務側で管理方法を決めます。
| 確認項目 | 確認する内容 | 判断の分かれ目 |
|---|---|---|
| 正本 | 現行の情報を記録する場所 | 一つに特定できれば登録候補、決められなければ整理を先行 |
| 更新頻度 | 内容が変わるタイミング | 頻繁に変わる情報は同期方式や更新担当を先に決定 |
| 閲覧権限 | 部門や担当者ごとの閲覧範囲 | 権限を分ける必要があれば検索時の制御方法を検討 |
| 情報の用途 | 問い合わせ対応、営業準備、社内手続きなど | 用途を絞れるなら小さく開始し、評価後に広げる |
次に進めるのは、質問に答える資料、その資料を更新する担当者、改訂時に旧版を検索対象から外す方法が決まったときです。担当者が不明な資料は、回答根拠としての扱いを保留します。
文書を検索しやすい単位に分割する
チャンキングは、文書を検索に適した断片に分ける処理です。分割の良し悪しは長さだけで決まりません。例えば手順書なら、「適用条件」「操作」「例外」が離れた断片になったとき、検索結果だけで正しい手順を判断できるかが分かれ目です。
| 分割方法 | 向いている文書 | 注意点 |
|---|---|---|
| 固定長で分割 | 構造が単純な長文 | 文の途中や条件の前後で切れる場合があります |
| 見出しや段落で分割 | 手順書、FAQ、説明資料 | 一つの節が長い場合は追加の分割が必要です |
| 階層を保って分割 | 見出しと詳細説明が対応する資料 | 検索結果に親見出しなどの文脈を含める設計が必要です |
| 前後を重ねて分割 | 重要な条件が隣接段落にまたがる資料 | 重複した情報が検索結果に並ぶことがあります |
| 分割方法 | 検索結果の重複を抑える | 重複分割では保存容量が増えます |
最初に文書の見出しと段落を確認し、質問に答える箇所を特定します。その箇所を検索したときに条件と例外を一緒に読めるなら、その分割を評価対象にします。条件が切れるなら見出しの保持や分割位置を見直し、無関係な内容まで広く取得するなら単位を狭めます。変更後は同じ質問で再検索し、必要な文脈が残ったかを比較します。
分割サイズを製品仕様と自社文書で検証する
Amazon Bedrock Knowledge Basesでは、データの取り込み時に文書やコンテンツを分割します。対応する分割方法はAmazon Bedrock「How content chunking works for knowledge bases」で確認できます。
検証では、同じ質問に対し、分割方法を変えた検索結果を見比べます。正本の該当箇所が見つかっても、適用条件が別の断片にあるなら、そのまま回答生成へ進めません。条件と回答に必要な説明を一緒に確認でき、無関係な節が判断を妨げない状態を次に進む条件とします。
データの鮮度とメタデータを管理する
文書名、分類、更新日、所有部門などの属性は、検索対象の絞り込みと改訂時の確認に使います。更新日だけを見て新しい資料を選ぶのではなく、正本として承認された資料かを確認します。
CRM情報では、コンタクト、会社、取引、活動履歴の関連付けを保ちます。質問が特定の顧客についてなら、検索結果がその顧客のレコードに結び付くかを確かめます。関連付けが曖昧な情報は回答に使わず、元データの管理方法を見直します。
ベクトル検索基盤と構成を選ぶ
ベクトルDBは、文章を数値表現に変換したベクトルと、その関連情報を保存して検索する基盤です。選定では検索機能に加え、既存環境、運用担当、アクセス制御、更新方法を確認します。構成を決める前に、どの質問に答えられれば業務で使えるのかを定義します。
要件から保存先を比較する
専用のマネージド型サービス、セルフホスト型、既存のリレーショナルデータベースの拡張など、構成には複数の選択肢があります。個別サービスの機能や料金は変わるため、必要な要件を定めてから公式資料で現行仕様を確認します。
| 選定軸 | 確認すること | 判断の例 |
|---|---|---|
| 運用 | バックアップ、監視、障害対応の担当 | 専任運用が難しければ管理範囲の小さい構成を優先 |
| 既存環境 | 既存データベースやクラウドとの接続 | 既存環境で要件を満たせれば新たな構成を増やさない |
| 権限 | 部門・ユーザー単位の絞り込み | 権限を分けられない候補は対象情報を限定 |
| 更新 | 差分更新、削除反映、再取り込み | 更新頻度が高ければ同期の仕組みを先に検証 |
| 検索品質 | キーワードと意味検索の組み合わせ | 固有名詞の誤検索が課題なら両方式を評価 |
比較では、検索品質だけが良くても採用を決めません。例えば必要な資料が見つかっても、閲覧できないはずの利用者に表示されるなら、その構成で対象情報を扱えるかを先に見直します。改訂や削除を検索側へ反映する担当と手順を決められない場合も、運用開始の条件を満たしません。
小さな検証から構成を決める
対象業務を絞り、実際に寄せられる質問と、その答えを確認できる正本を用意します。正式名称、言い換え、条件付きの質問を同じ資料に対して試し、各方式で何が見つかったかを記録します。
比較する順序は、正本が検索対象にあるか、該当箇所を取得できたか、不要な資料が混ざるか、利用者の権限で結果が変わるかです。既存環境でこれらを満たせるなら、その構成で回答評価へ進みます。満たせない項目が残るなら、設定や資料の整理で解決できるかを調べてから保存先を再検討します。
モデルや保存先だけで精度を決めない
Embeddingモデルは、文章をベクトルへ変換する処理に使います。日本語の資料を扱う場合も、製品の評判だけで判断せず、自社の略語、正式名称、利用者の言い換えを含む質問で確かめます。
設定を変えるときは、同じ質問、同じ正本、同じ権限で結果を比較します。正本が登録されていない、旧版が残っている、条件が分割で切れているといった問題が見つかったら、モデルの比較を続ける前にその問題を修正します。
社内文書とCRMをつなぐ設計
社内文書とCRMデータは、更新の仕方や閲覧権限が異なります。情報ごとに、検索用に取り込むのか、回答時に元の場所から取得するのかを決めます。CRMではコンタクト、会社、取引、活動の関係が回答の意味に関わるため、文章だけを切り出して扱わないようにします。
静的な資料と変化するCRM情報を分ける
手順書やFAQなど比較的変化の少ない資料は、検索用に取り込み、改訂時に再処理する設計が考えられます。顧客の担当状況や進行中の取引など変化する情報は、回答時にCRMから取得する方法と、変更を検索側へ反映する方法を比較します。
| データ | 取得方法の候補 | 設計上の確認 |
|---|---|---|
| 社内手順書、FAQ | 検索用インデックスへ登録 | 改訂時に旧版を外す責任者と手順 |
| コンタクトや会社 | CRM参照または同期 | レコードの関連付けと閲覧権限 |
| 取引や活動履歴 | CRM参照または更新を反映する同期 | 回答時点の状態と更新時刻 |
| 提案資料 | 文書検索 | 対象顧客や用途のメタデータ |
取得方法を選ぶ際は、利用者が判断する時点で必要な状態を確認できるかを基準にします。同期するなら、更新だけでなく削除や権限変更が検索結果へどう反映されるかを確かめます。確認できない情報は、回答時に元の記録を開いて照合する運用にします。
取得から業務判断までの流れをつなぐ
担当者が顧客との過去のやり取りを確認し、関連する提案資料を探す場面を考えます。まず対象の顧客レコードを特定し、そのレコードに紐付く活動と、用途が合う資料を取得します。次に資料が現行版であることと、担当者に閲覧権限があることを確認します。そのうえで回答を参考に次の対応を決め、対応後の記録はCRMに残します。
検索結果をCRMに書き戻す場合は、どの項目を誰の確認後に更新するのかを先に決めます。回答の生成とデータの変更を別の工程として扱えば、参照内容を確かめる前に記録が変わることを防げます。経営データの可視化では、情報を業務判断に使う際の別の視点も紹介しています。
マネージド型のAI機能を候補にする
CRMやSaaSに用意されたAI機能を使う場合も、必要な質問と正本を用意して評価します。設定できる検索範囲、根拠の表示、閲覧権限、更新時の反映方法を対象アカウントで確認します。必要な資料が参照できない、または権限に応じた結果を確認できない場合は、扱う情報や構成を見直します。
HubSpotのBreeze Assistantを検討する際は、対象アカウントで参照できる情報、回答の根拠、利用者ごとの権限を実際の質問で確かめます。利用条件や操作方法は公式案内と対象アカウントの設定で確認します（出典：Use Breeze Assistant）。
以下の画面は、社内ナレッジをPDFやURLとして取り込み、CRM上のAIエージェントの回答ソースに登録した構成を示しています。資料の登録に加え、回答から参照元を確かめられるか、更新後も適切な資料が使われるかを評価します。
自社のアクセス権と運用に合わせる
顧客情報や社内限定資料を含む場合は、元データを閲覧できない利用者が検索結果や回答から内容を知ることがないか確認します。閲覧できる利用者とできない利用者の両方で、同じ質問を試すことが必要です。
必要な権限制御を確認できれば、その範囲の情報から運用を始めます。確認できなければ対象データを限定し、元データの権限と検索側の設定を見直します。権限変更後も同じ質問を試し、以前の結果が表示され続けないか確かめてから対象を広げます。
RAG構築を段階的に進める
RAGを導入するときは、対象業務を決め、検索、回答、権限、更新の順に確かめます。各工程で判断の根拠を残せば、問題が起きたときも資料と設定のどちらを直すべきか分かります。
業務課題と対象データを定義する
最初に、誰がどんな質問をし、回答を何に使うのかを書き出します。質問ごとに、答えを確認できる資料やCRMレコードと、その管理者を紐付けます。答えが資料に書かれていない質問は、検索設定で解決しようとせず、業務上の判断基準を整える必要があります。
次に進める条件は、利用者、質問、正本、回答を使う場面が明確なことです。正本や管理者が決まらない情報は、検索対象への登録を保留します。
取り込みと検索をつなぐ
データソースから情報を取得し、重複や旧版を整理してから分割します。各チャンクに文書名、分類、更新日などの属性を付け、元資料へ辿れるようにします。質問を受け取ったら、利用者の権限に応じて関連情報を取得し、回答生成へ渡します。
| 段階 | 作業 | 次に進む条件 |
|---|---|---|
| 対象決定 | 業務、質問、正本を選ぶ | 正解の根拠となる資料が特定できている |
| 前処理 | 重複や旧版を整理し、分割と属性付与を行う | 文書の出所と更新日を確認できる |
| 検索 | 質問に対する候補文書を取得する | 期待する根拠が検索結果に含まれる |
| 回答 | 検索結果を使って回答を生成する | 根拠と回答の内容を人が照合できる |
| 運用 | 更新、評価、改善を担当者と手順に結び付ける | 更新漏れや誤回答を追跡できる |
前処理を終えたら、まず回答生成を介さず検索結果を読みます。必要な条件や例外が取得できていなければ、その段階で資料や分割を修正します。検索結果が妥当になってから、回答が根拠を正しく使うかを確かめます。
検索品質と回答品質を分けて評価する
評価には、通常の質問だけでなく、言い換え、条件付きの質問、正本に答えがない質問を含めます。質問ごとに期待する根拠を先に記録し、検索結果と回答を別々に照合します。
| 評価観点 | 確認方法 | 改善の方向 |
|---|---|---|
| 検索の妥当性 | 質問に答える根拠が候補に含まれるか | 分割、属性、検索方式を見直す |
| 回答の根拠 | 回答の各要点を出典で確認できるか | 根拠提示と回答ルールを調整 |
| 情報の鮮度 | 現行版や最新のCRM状態を参照しているか | 更新処理と旧版の扱いを見直す |
| 業務での使いやすさ | 利用者が次の対応を決められるか | 質問例、回答形式、対象範囲を調整 |
正本が検索結果にない場合は検索対象と取得方法を見直します。正本はあるのに回答が条件を落とす場合は、渡す文脈と回答形式を見直します。根拠が存在しない質問に断定的な回答を返す場合は、回答を保留して担当者へ確認を促す運用を整えます。どの問題も、対象範囲を広げる前に同じ質問で再確認します。
改善を引き継げる仕組みにする
質問、期待する根拠、実際の検索結果、回答、修正内容を記録します。文書の改訂、権限変更、検索設定の変更があったときは、影響する質問を再確認します。
担当者だけが知る略語や例外は、説明資料に反映して管理者の確認を受けてから検索対象に加えます。データ所有者、更新の合図、確認手順を明文化し、担当者が変わっても現行資料を維持できるようにします。
RAG運用で起きやすい問題と対処
回答に問題があったときは、質問と回答だけを見るのではなく、次を順に確認します。
- 元資料
- 検索結果
- 生成時に使った根拠
- 利用者の権限
原因を特定してから変更し、同じ質問で結果を見比べます。
古い情報や矛盾する資料が検索される
現行資料と旧版が同時に見つかったら、先に正本と管理責任者を確認します。
- 正本が分かる ── 旧版を検索対象から外す手順を実行し、同じ質問で旧版が出ないか確かめる
- 正本を特定できない ── その内容を回答の根拠にせず、業務側で判断を確定する
回答が自然でも根拠が不足する
参照先を開き、回答の各要点に対応する記述があるかを確認します。
資料名だけが一致し、必要な条件が書かれていない場合は根拠不足です。
- 検索で該当箇所を取得できていない ── 検索側を修正する
- 取得できているのに回答へ反映されない ── 生成側を修正する
根拠が確認できない質問は担当者へ回します。
権限やデータの境界が曖昧になる
元資料を閲覧できない利用者で質問し、検索結果と回答の両方に情報が現れないか確かめます。表示される場合は、その情報を検索対象から外すか、検索時の権限制御を見直します。権限を修正した後も同じ質問を試し、対象情報を扱える状態か確認します。
検索方式やモデルだけを頻繁に変える
変更前の質問、期待する根拠、検索結果を残してから設定を変えます。変更後に同じ条件で比較し、改善した質問と悪化した質問を確認します。正本の欠落や分割の問題が残るなら、モデルの調整を続ける前に資料の構造を直します。
よくある質問
RAGを導入すれば誤回答をなくせますか？
誤回答をなくせるとは限りません。旧版の取得、根拠の取り違え、回答時の解釈違いなど、原因を分けて確認します。出典に答えがない場合は回答を確定せず担当者に確認し、原因を修正した後に同じ質問で再評価します。
ベクトル検索だけで社内情報を探せますか？
質問と文書の種類によります。固有名詞やコードを含む質問と、言い換えの多い質問を同じ資料に対して試します。前者で取り違えが起きるならキーワード検索を、後者で見落としが起きるなら意味検索を含めて比較し、必要に応じて組み合わせます。
CRMデータはベクトルDBに複製すべきですか？
更新時点の状態が判断に必要なら、まずCRMから取得する方法を検討します。同期する場合は、レコードの関連付け、更新、削除、権限変更が検索結果へどう反映されるかを確認します。確認できない項目があれば、対象データを絞るか、回答時に元のレコードを照合する運用にします。
Breeze AssistantはRAG構築の代わりになりますか？
扱いたい質問を対象アカウントで試し、必要な情報を参照できるか、回答の根拠を辿れるか、利用者の権限が反映されるかを確認して判断します。要件を満たせばその範囲から始め、満たせない情報については対象を限定するか、別の取得方法を検討します。
まとめ
RAG構築では、質問に答える正本と管理者を決め、必要な条件を保てる単位で文書を分割し、検索結果と回答を別々に評価します。CRM情報を使う場合はレコードの関連付け、更新、閲覧権限を確認し、回答時点の業務判断に必要な情報を取得できるようにします。
まずは、社内で繰り返し質問される業務を選び、次の順序で確かめます。
- 質問、利用者、回答に使う場面を決め、正本と管理者を特定します。
- 同じ質問で検索方式や分割方法を比べ、必要な条件と例外を取得できるか確認します。
- 回答と根拠を照合し、更新担当、権限、根拠がない場合の対応を決めてから対象を広げます。
企業様によって最適な形は異なります。CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
