RAG（Retrieval-Augmented Generation：検索拡張生成）とは、LLMが回答を生成する前に外部のデータソースから関連情報を検索・取得し、その情報をもとに回答を生成するアーキテクチャです。社内ドキュメントやCRMデータを活用したAI検索システムの構築に最適であり、ハルシネーション（事実と異なる回答）の大幅な抑制と、常に最新情報に基づいた回答を実現します。構築には「データ前処理」「ベクトルDB」「検索+生成パイプライン」の3層を順に整備するのが定石です。
「社内に大量のドキュメントがあるのに、必要な情報を探すのに時間がかかる」「AIチャットボットを導入したが、社内固有の情報に正確に回答できない」――こうした課題の解決策として、RAGが注目されています。
本記事では、RAGの基本アーキテクチャから、実装の具体的なステップ、CRMデータとの連携パターンまでを実務視点で解説します。
RAGは「作って終わり」ではなく、検索精度を継続的に改善するプロセスが成否を分けます。本記事では、構築だけでなく運用フェーズまで見据えた設計指針を提供します。
LLM単体の回答には、2つの本質的な制約があります。
制約1：学習データのカットオフ
LLMは事前学習時点のデータしか持っていません。「昨日の会議で決まった方針」「先月更新された製品仕様」といった最新情報には対応できません。
制約2：ハルシネーション
LLMは統計的なパターンに基づいて回答を生成するため、自信がある口調で事実と異なる回答を生成することがあります。社内の正確な情報（価格、規約、手順）を扱う場面では、これは致命的な問題です。
RAGはこれらの制約を「外部知識の検索」で解決します。
RAGの処理は以下の3ステップで構成されます。
ステップ1：Retrieval（検索）
ユーザーの質問を受け取ったら、まず外部データソース（ベクトルDB）から関連するドキュメントの断片（チャンク）を検索します。
ステップ2：Augmentation（拡張）
検索で取得したチャンクをLLMへのプロンプトに付加します。「以下の情報を参考にして回答してください」という形式で、コンテキストとしてLLMに渡します。
ステップ3：Generation（生成）
LLMが、ユーザーの質問と検索結果のコンテキストを組み合わせて回答を生成します。回答にはソース（参照元ドキュメント）を併記し、根拠の透明性を確保します。
RAGの検索で使われるのが「ベクトル検索」です。これは、テキストを数百〜数千次元の数値ベクトル（Embedding）に変換し、ベクトル間の類似度で検索する手法です。
従来のキーワード検索が「完全一致」「部分一致」で検索するのに対し、ベクトル検索は「意味の近さ」で検索します。たとえば「CRMの導入効果」と「顧客管理システムを入れるメリット」は、キーワードが異なっていても意味的に近いため、ベクトル検索ではヒットします。
| 比較項目 | キーワード検索 | ベクトル検索 |
|---|---|---|
| 検索方式 | 文字列の一致 | 意味の類似度 |
| 同義語対応 | 辞書登録が必要 | 自動対応 |
| 多言語対応 | 言語別インデックス | 多言語Embeddingで統合可能 |
| 精度 | リコール率が低い傾向 | セマンティックな関連性が高い |
| コスト | 低い | Embedding計算コストが必要 |
RAGの中核を担うベクトルDBの選定は、システム全体のパフォーマンスとコストに直結します。
マネージドサービスとして提供されるベクトル専用DBです。
オープンソースのベクトルDBで、セルフホストとクラウドマネージドの両方に対応しています。
既存のPostgreSQLにベクトル検索機能を追加する拡張モジュールです。
| 判断基準 | Pinecone | Weaviate | pgvector |
|---|---|---|---|
| 運用負荷 | 低い | 中程度 | 低い（既存DB利用） |
| 検索精度 | 高い | 非常に高い | 中〜高 |
| スケーラビリティ | 高い | 高い | 中程度 |
| 既存インフラとの統合 | API連携 | 柔軟 | PostgreSQL一体化 |
| 初期コスト | 無料枠あり | セルフホスト無料 | 無料 |
PoC段階ではPineconeの無料プランで検証し、本番環境への移行時にWeaviateやpgvectorを検討する、という段階的アプローチが多くの企業で採用されています。
RAGの検索精度は、データの前処理品質に大きく依存します。「ゴミを入れればゴミが出る（Garbage In, Garbage Out）」は、RAGにおいても鉄則です。
チャンキングとは、社内ドキュメントを検索に適したサイズの断片（チャンク）に分割する処理です。チャンクのサイズと分割方法が、検索精度を左右する最も重要なパラメータです。
| 戦略 | チャンクサイズ | メリット | デメリット |
|---|---|---|---|
| 固定長分割 | 500〜1,000トークン | 実装が簡単 | 文脈が途中で切れる |
| セマンティック分割 | 段落・セクション単位 | 文脈の一貫性が高い | 実装が複雑 |
| 階層型分割 | セクション+サブセクション | 広い文脈と詳細の両方を検索 | インデックスサイズが増大 |
| オーバーラップ分割 | 固定長+前後20%重複 | 文脈の欠落を軽減 | ストレージ使用量が増加 |
実務上の推奨は、オーバーラップ付きセマンティック分割です。ドキュメントの見出し（H2・H3）を境界として分割し、前後のチャンクと10〜20%のオーバーラップを持たせることで、文脈の一貫性と検索精度のバランスが取れます。
チャンクをベクトルに変換するEmbeddingモデルの選択も重要です。
日本語の社内ドキュメントを扱う場合、CohereのEmbed v3またはOpenAIのtext-embedding-3-largeが精度面で推奨されます。
RAGの真価が発揮されるのは、社内ドキュメントだけでなくCRMデータを統合したときです。営業担当者が「この顧客の過去のやり取りと、関連する提案事例を教えて」と質問すれば、AIがCRMの活動履歴とナレッジベースを横断検索して回答する――そんなシステムが実現できます。
HubSpotやSalesforceなどのCRM APIを、RAGの検索パイプラインに組み込む方式です。
HubSpotではBreeze Copilotがこの方式を採用しており、CRMのコンタクト・取引・チケット情報をリアルタイムに参照しながら回答を生成します。
CRMデータを定期的にエクスポートし、ベクトルDBにインデックスする方式です。
静的ドキュメント（マニュアル・ナレッジベース）はベクトルDBで管理し、動的データ（顧客情報・取引状況）はCRM APIをリアルタイムで参照する方式です。
多くの企業では、このハイブリッド型が最もバランスの取れたアーキテクチャです。
ファインチューニングとの使い分けについては「ファインチューニングの企業活用ガイド｜RAGとの使い分けと実装ステップ」で詳しく解説しています。
RAGシステムの実装は、以下の5ステップで進めます。
まず、RAGで検索対象とするデータソースを洗い出します。
初期スコープは1〜2種類のデータソースに絞り、効果を検証してから拡大するのが鉄則です。
各データソースからのデータ抽出→クレンジング→チャンキング→Embedding生成を自動化するパイプラインを構築します。
PythonのLangChainやLlamaIndexといったフレームワークを使えば、PDF・HTML・Markdownなど多様な形式のドキュメントの取り込みとチャンキングを効率的に実装できます。
チャンクのEmbeddingをベクトルDBに格納し、検索インデックスを構築します。メタデータ（ドキュメント名、更新日、カテゴリ）を付与しておくと、フィルタリング検索が可能になります。
ユーザーの質問を受け取り、ベクトルDBで検索→取得したチャンクをプロンプトに組み込み→LLMで回答生成、という一連のパイプラインを実装します。
検索精度を高めるポイントは「リランキング」です。ベクトル検索で上位20件を取得した後、Cohereのリランカーなどを使って関連度の高い順に再順位付けし、上位3〜5件をLLMに渡す構成が効果的です。
RAGの品質評価は以下の指標で行います。
社内のナレッジマネジメントとRAGの活用については「AI時代のナレッジ共有｜組織の暗黙知をAIで形式知化する方法」も参考になります。
PoCレベルであれば2〜4週間、本番環境へのデプロイまで含めると2〜3ヶ月が目安です。コストはデータソースの規模に依存しますが、Pineconeの無料プラン+OpenAI APIの組み合わせであれば、月額100ドル以下でPoCを開始できます。本番環境では月額500〜2,000ドル程度を見込むのが現実的です。
完全にゼロにすることは困難ですが、大幅に抑制できます。検索結果にソースドキュメントが含まれない場合は「回答できません」と返す設計にすること、複数のチャンクで裏付けが取れた情報のみを回答に含めること、回答と同時にソースURLを提示すること、の3つの施策を組み合わせることで、実用上問題ないレベルまでハルシネーションを低減できます。
HubSpotの場合、CRM APIを使ってコンタクト・取引・チケットなどのデータを取得し、ベクトルDBに格納する方式が一般的です。HubSpotが提供するBreeze Copilotは、すでにRAGベースの検索機能を内蔵しており、追加開発なしでCRMデータに基づいた回答を生成できます。より高度なカスタマイズが必要な場合は、HubSpot APIとLangChainを組み合わせた独自のRAGパイプラインを構築します。
はい、LangChainやLlamaIndexなどのフレームワークの成熟により、エンジニア1〜2名で構築可能です。マネージドサービス（Pinecone + OpenAI API）を組み合わせれば、インフラ運用の負荷も最小限に抑えられます。まずは社内FAQなど、データ量が限られた領域からPoCを始めるのが推奨です。
RAGは、LLMのハルシネーション問題を解決し、社内の既存データ資産を活用するための実践的なアーキテクチャです。構築にあたっては、「データ前処理の品質」「チャンキング戦略」「検索パイプラインの精度向上（リランキング等）」の3点が成否を分けるポイントとなります。
CRMデータとの統合やAI検索システムの設計にお悩みの方は、StartLinkまでお気軽にご相談ください。HubSpot認定パートナーとして、CRM×AIの実装支援を行っています。