社内ナレッジをRAGで対話可能にする — 企業向け実装ガイドとベクトルDB選定

序文 — なぜRAGが企業で最も実装されるLLM用途になったのか

生成AIを業務に活用する際、もっとも実装事例が蓄積しているのがRAG（Retrieval-Augmented Generation）です。Stanford AI Index Report やMcKinseyのState of AI調査でも、企業での生成AI用途として「社内ナレッジ検索・Q&A」「問い合わせ対応」は常に上位に位置づけられています¹²。

理由は単純です。社内には膨大なドキュメントが眠っており、それらを「検索して読む」ことに人は多くの時間を費やしています。RAGはこの認知的なコストを下げます。

一方で、RAG導入の現場では「検索精度が出ない」「幻覚（ハルシネーション）が減らない」「権限違反の情報が漏れる」といった失敗事例も数多く観察されます。本記事では、Farleap（ファーリープ）が実装現場で蓄積した判断基準を、公開標準と併せて整理します。

RAGの基本構造 — 何が検索精度を決めるのか

RAGは、以下の5ステップで構成される基本パイプラインを持ちます。

1. Ingestion：元ドキュメントをテキスト化・構造化して取り込む
2. Chunking：検索単位にテキストを分割する
3. Embedding：各チャンクをベクトル空間にマッピング
4. Retrieval：質問ベクトルと類似するチャンクを取得
5. Generation：取得したチャンクを文脈としてLLMに回答を生成させる

精度を決定する要素は、多くの場合「Generation」より前の4ステップに存在します。ユーザーが「AIが答えてくれない」と感じる失敗のほとんどは、LLM自体の能力ではなく、前段の取得フェーズで必要な情報が引けていないことが原因です。

Ingestion — ドキュメント前処理の地雷原

RAG実装でもっとも時間を消費するのは、意外にもIngestionフェーズです。社内ドキュメントの典型的な状態は以下の通りです：

• PDFスキャン画像（OCR必要）
• パワーポイント（図表が多く、テキストのみでは意味が通らない）
• Excel（表構造を保持した抽出が必要）
• Wiki / Confluence / Notion（API経由での定期同期）
• 議事録（話者識別と要約の前処理が有効）

特にPDFは、ツールによってテキスト抽出結果が大きく異なります。同一ドキュメントで複数の抽出ツールを比較するという地味な工程が、最終精度に効きます。

加えて、抽出段階でメタデータ（文書種別、部署、更新日、機密レベル）を付与しておくことが、後段の権限制御と検索精度の両方に効きます。

Chunking戦略 — 「切り方」で検索精度が決まる

チャンキングは、RAG設計で最も議論の対象になる工程です。代表的な戦略を整理します：

戦略	特徴	向くケース
固定長分割	単純・実装容易	構造化されたテキスト
文単位分割	文脈保持に優れる	自然文中心の文書
段落単位分割	論理単位を保持	技術文書・マニュアル
見出し階層分割	文書構造を反映	マークダウン・構造化文書
セマンティック分割	意味の切れ目で分割	長文レポート
親子分割	小チャンク検索＋親文脈返却	精度と文脈の両立

推奨は「親子分割」です。検索は小さなチャンク（200〜400トークン）で行い、LLMへ渡す文脈は親段落（1000〜2000トークン）を返すことで、検索精度と文脈保持を両立できます。

Embedding — モデル選定の判断基準

埋め込みモデルの選定は、言語特性・コスト・ドメイン適合性で判断します。日本語RAGでの主な選択肢：

• 多言語汎用モデル：OpenAI text-embedding-3 系、Cohere Embed v3、Google Gecko 系
• 日本語特化モデル：multilingual-e5、BGE-M3 等のOSSモデル
• ドメイン特化ファインチューニング：金融・医療・法務など専門用語比率が高い領域

まずは汎用モデルで運用し、精度が出ない場合に日本語特化・ドメイン特化への切り替えを検討する順序が現実的です。ドメイン特化ファインチューニングは効果が大きい一方で実施コストも大きいため、精度測定の仕組みを先に用意することが前提となります。

Retrieval — ハイブリッド検索で精度を底上げする

ベクトル検索単体では取りこぼしが発生します。「型番」「固有名詞」「日付」などはキーワード一致が強く、ベクトル類似度では下位に沈むことがあります。

実務で有効なのはハイブリッド検索です。ベクトル検索とBM25（キーワード検索）のスコアを重み付けし、再ランキングで統合します。

さらに、Rerankerモデル（Cohere Rerank、Jina Reranker 等）を追加することで、候補上位の並び替えを行い、LLMに渡す文脈の質を高めることができます。

ベクトルDB選定 — 規模と運用要件で判断する

データ規模・更新頻度・ホスティング要件で判断します。代表的な選択肢：

選択肢	データ規模目安	特徴
pgvector（PostgreSQL拡張・OSS）	〜100万チャンク	既存DBに同居可能、運用負荷低
マネージド型ベクトルDB（Weaviate／Qdrant 等）	〜1000万チャンク	マネージド／セルフホスト選択可
エンタープライズ向けマネージド（Pinecone 等）	〜数億チャンク	SLA保証、大規模運用
分散検索基盤（Vespa／Elasticsearch 等）	大規模・複雑クエリ	高度な検索機能が必要な場合

記載した製品・サービス名は各社の商標または登録商標であり、仕様・価格・機能レンジは随時変更されます。選定時は各社公式情報の確認が必要です。既に PostgreSQL を運用している組織であれば pgvector から始めるのが低コストで、スケール要件が顕在化したタイミングで専用ベクトルDBへの移行を検討する順序が実務的です。

権限制御とセキュリティ — 設計フェーズで組み込むべき

RAG特有のセキュリティ論点は以下の通りです：

• アクセス制御：ユーザー権限に応じて検索対象を絞り込む
• プロンプトインジェクション：取得文書内に埋め込まれた悪意ある指示への耐性
• 機密情報の漏洩：学習データや検索結果に含まれる個人情報・企業秘密
• 監査ログ：誰が何を問い合わせ、何が引かれ、何が回答されたかの記録

OWASP Top 10 for LLM Applications では、プロンプトインジェクション、機密情報漏洩、過剰なエージェンシー付与などが主要リスクとして整理されています³。RAG実装時は、これらの観点を設計段階で盛り込むことが必須です。

アクセス制御は「ベクトルDB側のメタデータフィルタ」と「LLMに渡す前のアクセス検証」の二重化が基本です。権限外情報をLLMコンテキストに入れないことで、構造的にリークリスクを抑えます。

失敗パターンと改善アプローチ

現場で頻出する失敗と、改善手法を整理します。

パターン1 — 「答えてくれない」問題

検索で正しい文書を引けていないケースです。対処：

• チャンキング戦略を見直す（親子分割への切替）
• ハイブリッド検索を導入する
• Rerankerを追加する
• 検索ログを分析し、引けていないクエリタイプを特定する

パターン2 — 「もっともらしい嘘」問題

検索結果が乏しくてもLLMが答えてしまうケースです。対処：

• プロンプトに「引用元が不十分な場合は答えない」を明示
• 引用元の可視化をUIで義務化
• 信頼度スコアを返し、閾値未満は人間にエスカレーション

パターン3 — 「古い情報」問題

更新されたドキュメントが検索に反映されないケースです。対処：

• Ingestion パイプラインの定期実行
• 文書更新イベントでの即時再エンべディング
• 「最終更新日」メタデータの活用

効果測定 — 運用に乗せるための指標

RAGは導入して終わりではありません。以下のKPIを継続的にモニタリングすべきです：

1. Retrieval Hit Rate：質問に対して正解文書が上位N件に含まれる割合
2. Answer Relevance：生成された回答の関連性（人手評価 or LLM評価）
3. Hallucination Rate：引用元にない情報を生成した割合
4. User Satisfaction：👍/👎 等のフィードバック収集
5. Coverage：問い合わせ対象ドメインへの回答可能率

これらの計測基盤を運用開始と同時に稼働させることで、継続的な改善サイクルが回ります。

現場で効いた実装原則 — チャンキング戦略を業務文脈で決める

RAG実装は「技術選定」と誤解されがちですが、実態は業務文脈への適応です。Farleapでは、ドキュメント前処理、メタデータ設計、プロンプト設計、UI設計を一体で提供することで、「動くRAG」ではなく「使い続けられるRAG」を目指しています。

技術スタックの詳細は現場条件で変わりますが、設計判断のフレームワークは業種を問わず共通して適用できます。

まとめ — RAGは「検索とLLMの中間層」の設計品質で決まる

RAGの成否は、LLMモデルの選択よりも、前段の取得層の設計品質で決まります。チャンキング、埋め込み、検索、権限制御 — 各工程に業務文脈を織り込むことが、使い続けられるRAGを作る唯一の道です。

LLMセキュリティ全般については LLMセキュリティ設計ガイド、画像・文書を組み合わせた活用は マルチモーダルAI活用ガイド、AI導入の全体ロードマップは エンタープライズAI導入の成功法則 を併せて参照してください。

出典

本記事は一般的な情報提供を目的としたもので、法的・税務的助言に代わるものではありません。詳細は利用規約をご確認ください。

Footnotes

1. Stanford University HAI, “AI Index Report 2024” ↩

2. McKinsey & Company, “The state of AI in early 2024: Gen AI adoption spikes and starts to generate value” (2024年5月) ↩

3. OWASP, “OWASP Top 10 for Large Language Model Applications” ↩