RAG構築の実践ガイド｜社内データを活用したAI検索システムの作り方

RAG（Retrieval-Augmented Generation：検索拡張生成）とは、LLMが回答を生成する前に外部のデータソースから関連情報を検索・取得し、その情報をもとに回答を生成するアーキテクチャです。社内ドキュメントやCRMデータを活用したAI検索システムの構築に最適であり、ハルシネーション（事実と異なる回答）の大幅な抑制と、常に最新情報に基づいた回答を実現します。構築には「データ前処理」「ベクトルDB」「検索+生成パイプライン」の3層を順に整備するのが定石です。

「社内に大量のドキュメントがあるのに、必要な情報を探すのに時間がかかる」「AIチャットボットを導入したが、社内固有の情報に正確に回答できない」――こうした課題の解決策として、RAGが注目されています。

本記事では、RAGの基本アーキテクチャから、実装の具体的なステップ、CRMデータとの連携パターンまでを実務視点で解説します。

この記事でわかること

• RAGの基本アーキテクチャと仕組み：検索→拡張→生成の3ステップとベクトル検索の原理
• ベクトルDBの選定と構築方法：Pinecone・Weaviate・pgvectorの比較と用途別の選び方
• 社内ドキュメント×CRMデータの統合設計：複数データソースを横断する検索システムの設計パターン
• 実装の5ステップと品質改善のポイント：チャンキング戦略からリランキングまでの実践テクニック

RAGは「作って終わり」ではなく、検索精度を継続的に改善するプロセスが成否を分けます。本記事では、構築だけでなく運用フェーズまで見据えた設計指針を提供します。

RAGの基本アーキテクチャ――なぜLLM単体では不十分なのか

LLM単体の回答には、2つの本質的な制約があります。

制約1：学習データのカットオフ

LLMは事前学習時点のデータしか持っていません。「昨日の会議で決まった方針」「先月更新された製品仕様」といった最新情報には対応できません。

制約2：ハルシネーション

LLMは統計的なパターンに基づいて回答を生成するため、自信がある口調で事実と異なる回答を生成することがあります。社内の正確な情報（価格、規約、手順）を扱う場面では、これは致命的な問題です。

RAGはこれらの制約を「外部知識の検索」で解決します。

RAGの3ステップ処理フロー

RAGの処理は以下の3ステップで構成されます。

ステップ1：Retrieval（検索）

ユーザーの質問を受け取ったら、まず外部データソース（ベクトルDB）から関連するドキュメントの断片（チャンク）を検索します。

ステップ2：Augmentation（拡張）

検索で取得したチャンクをLLMへのプロンプトに付加します。「以下の情報を参考にして回答してください」という形式で、コンテキストとしてLLMに渡します。

ステップ3：Generation（生成）

LLMが、ユーザーの質問と検索結果のコンテキストを組み合わせて回答を生成します。回答にはソース（参照元ドキュメント）を併記し、根拠の透明性を確保します。

ベクトル検索の基本原理

RAGの検索で使われるのが「ベクトル検索」です。これは、テキストを数百〜数千次元の数値ベクトル（Embedding）に変換し、ベクトル間の類似度で検索する手法です。

従来のキーワード検索が「完全一致」「部分一致」で検索するのに対し、ベクトル検索は「意味の近さ」で検索します。たとえば「CRMの導入効果」と「顧客管理システムを入れるメリット」は、キーワードが異なっていても意味的に近いため、ベクトル検索ではヒットします。

ベクトルDBの選定――Pinecone・Weaviate・pgvector比較

RAGの中核を担うベクトルDBの選定は、システム全体のパフォーマンスとコストに直結します。

Pinecone

マネージドサービスとして提供されるベクトル専用DBです。

• 特徴：インフラ管理不要。APIでベクトルの追加・検索が完結する
• 料金：無料プラン（10万ベクトルまで）あり。有料プランはPodベースで月額70ドル〜
• 向いている企業：インフラ運用に工数を割きたくない中小企業。PoC（概念実証）から始めたい場合

Weaviate

オープンソースのベクトルDBで、セルフホストとクラウドマネージドの両方に対応しています。

• 特徴：ハイブリッド検索（ベクトル検索+キーワード検索の組み合わせ）をネイティブサポート
• 料金：セルフホストは無料。Weaviate Cloudはサンドボックス（14日間無料）あり
• 向いている企業：検索精度を細かくチューニングしたい企業。セルフホストでコスト最適化したい場合

pgvector（PostgreSQL拡張）

既存のPostgreSQLにベクトル検索機能を追加する拡張モジュールです。

• 特徴：既存のPostgreSQL環境にそのまま追加可能。RDB（リレーショナルデータ）とベクトルデータを同一DBで管理できる
• 料金：オープンソース（無料）。クラウドDBのコストのみ
• 向いている企業：PostgreSQL/Supabaseを既に使用している企業。ベクトル専用DBを別途運用したくない場合

選定の判断基準

PoC段階ではPineconeの無料プランで検証し、本番環境への移行時にWeaviateやpgvectorを検討する、という段階的アプローチが多くの企業で採用されています。

データ前処理とチャンキング戦略

RAGの検索精度は、データの前処理品質に大きく依存します。「ゴミを入れればゴミが出る（Garbage In, Garbage Out）」は、RAGにおいても鉄則です。

チャンキングとは何か

チャンキングとは、社内ドキュメントを検索に適したサイズの断片（チャンク）に分割する処理です。チャンクのサイズと分割方法が、検索精度を左右する最も重要なパラメータです。

チャンキング戦略の比較

実務上の推奨は、オーバーラップ付きセマンティック分割です。ドキュメントの見出し（H2・H3）を境界として分割し、前後のチャンクと10〜20%のオーバーラップを持たせることで、文脈の一貫性と検索精度のバランスが取れます。

Embedding生成の選択肢

チャンクをベクトルに変換するEmbeddingモデルの選択も重要です。

• OpenAI text-embedding-3-small：コスト効率が高く、多くのユースケースで十分な精度。100万トークンあたり約0.02ドル
• OpenAI text-embedding-3-large：より高精度。100万トークンあたり約0.13ドル
• Cohere Embed v3：多言語対応が強力。日本語ドキュメントの処理精度が高い
• Sentence-Transformers（オープンソース）：無料で利用可能。セルフホストが必要だが、ランニングコストを最小化できる

日本語の社内ドキュメントを扱う場合、CohereのEmbed v3またはOpenAIのtext-embedding-3-largeが精度面で推奨されます。

CRMデータとの統合設計パターン

RAGの真価が発揮されるのは、社内ドキュメントだけでなくCRMデータを統合したときです。営業担当者が「この顧客の過去のやり取りと、関連する提案事例を教えて」と質問すれば、AIがCRMの活動履歴とナレッジベースを横断検索して回答する――そんなシステムが実現できます。

パターン1：CRM APIリアルタイム検索型

HubSpotやSalesforceなどのCRM APIを、RAGの検索パイプラインに組み込む方式です。

• 仕組み：ユーザーの質問に含まれる企業名・担当者名をエンティティ抽出し、CRM APIで該当レコードを取得。取得した情報をコンテキストとしてLLMに渡す
• メリット：常に最新のCRMデータを参照可能
• デメリット：API呼び出しのレイテンシが加算される

HubSpotではBreeze Copilotがこの方式を採用しており、CRMのコンタクト・取引・チケット情報をリアルタイムに参照しながら回答を生成します。

パターン2：CRMデータ定期同期型

CRMデータを定期的にエクスポートし、ベクトルDBにインデックスする方式です。

• 仕組み：日次または週次でCRMデータをエクスポートし、Embeddingに変換してベクトルDBに格納
• メリット：検索パフォーマンスが安定。APIの呼び出し制限を気にしなくてよい
• デメリット：データの鮮度にタイムラグが生じる

パターン3：ハイブリッド型

静的ドキュメント（マニュアル・ナレッジベース）はベクトルDBで管理し、動的データ（顧客情報・取引状況）はCRM APIをリアルタイムで参照する方式です。

多くの企業では、このハイブリッド型が最もバランスの取れたアーキテクチャです。

ファインチューニングとの使い分けについては「ファインチューニングの企業活用ガイド｜RAGとの使い分けと実装ステップ」で詳しく解説しています。

実装の5ステップ

RAGシステムの実装は、以下の5ステップで進めます。

ステップ1：対象データの棚卸しとスコープ定義

まず、RAGで検索対象とするデータソースを洗い出します。

• 社内マニュアル・FAQ（PDF、Confluence、Notion）
• CRMの顧客情報・活動履歴（HubSpot、Salesforce）
• 営業提案資料（Google Slides、PowerPoint）
• 過去の問い合わせ対応履歴（メール、チャット）

初期スコープは1〜2種類のデータソースに絞り、効果を検証してから拡大するのが鉄則です。

ステップ2：データ前処理パイプラインの構築

各データソースからのデータ抽出→クレンジング→チャンキング→Embedding生成を自動化するパイプラインを構築します。

PythonのLangChainやLlamaIndexといったフレームワークを使えば、PDF・HTML・Markdownなど多様な形式のドキュメントの取り込みとチャンキングを効率的に実装できます。

ステップ3：ベクトルDBの構築とインデックス作成

チャンクのEmbeddingをベクトルDBに格納し、検索インデックスを構築します。メタデータ（ドキュメント名、更新日、カテゴリ）を付与しておくと、フィルタリング検索が可能になります。

ステップ4：検索+生成パイプラインの実装

ユーザーの質問を受け取り、ベクトルDBで検索→取得したチャンクをプロンプトに組み込み→LLMで回答生成、という一連のパイプラインを実装します。

検索精度を高めるポイントは「リランキング」です。ベクトル検索で上位20件を取得した後、Cohereのリランカーなどを使って関連度の高い順に再順位付けし、上位3〜5件をLLMに渡す構成が効果的です。

ステップ5：評価と継続的改善

RAGの品質評価は以下の指標で行います。

• 検索精度（Retrieval Precision）：検索結果に含まれる関連チャンクの割合
• 回答の正確性（Answer Accuracy）：人間の評価者が回答を5段階評価
• ハルシネーション率：ソースドキュメントに記載のない情報を含む回答の割合
• レイテンシ：質問から回答までの応答時間

社内のナレッジマネジメントとRAGの活用については「AI時代のナレッジ共有｜組織の暗黙知をAIで形式知化する方法」も参考になります。

よくある質問（FAQ）

Q1. RAGの構築にはどのくらいの期間とコストがかかりますか？

PoCレベルであれば2〜4週間、本番環境へのデプロイまで含めると2〜3ヶ月が目安です。コストはデータソースの規模に依存しますが、Pineconeの無料プラン+OpenAI APIの組み合わせであれば、月額100ドル以下でPoCを開始できます。本番環境では月額500〜2,000ドル程度を見込むのが現実的です。

Q2. RAGでハルシネーションを完全にゼロにできますか？

完全にゼロにすることは困難ですが、大幅に抑制できます。検索結果にソースドキュメントが含まれない場合は「回答できません」と返す設計にすること、複数のチャンクで裏付けが取れた情報のみを回答に含めること、回答と同時にソースURLを提示すること、の3つの施策を組み合わせることで、実用上問題ないレベルまでハルシネーションを低減できます。

Q3. 既存のCRM（HubSpot等）とRAGを連携させるにはどうすればよいですか？

HubSpotの場合、CRM APIを使ってコンタクト・取引・チケットなどのデータを取得し、ベクトルDBに格納する方式が一般的です。HubSpotが提供するBreeze Copilotは、すでにRAGベースの検索機能を内蔵しており、追加開発なしでCRMデータに基づいた回答を生成できます。より高度なカスタマイズが必要な場合は、HubSpot APIとLangChainを組み合わせた独自のRAGパイプラインを構築します。

Q4. 小規模なチームでもRAGを構築・運用できますか？

はい、LangChainやLlamaIndexなどのフレームワークの成熟により、エンジニア1〜2名で構築可能です。マネージドサービス（Pinecone + OpenAI API）を組み合わせれば、インフラ運用の負荷も最小限に抑えられます。まずは社内FAQなど、データ量が限られた領域からPoCを始めるのが推奨です。

まとめ

RAGは、LLMのハルシネーション問題を解決し、社内の既存データ資産を活用するための実践的なアーキテクチャです。構築にあたっては、「データ前処理の品質」「チャンキング戦略」「検索パイプラインの精度向上（リランキング等）」の3点が成否を分けるポイントとなります。

CRMデータとの統合やAI検索システムの設計にお悩みの方は、StartLinkまでお気軽にご相談ください。HubSpot認定パートナーとして、CRM×AIの実装支援を行っています。

お問い合わせはこちら