TL;DR

社内に眠るドキュメント・議事録・マニュアルをRAG（Retrieval-Augmented Generation）で「対話可能なナレッジベース」に変換できます。しかし、チャンキング戦略、埋め込みモデル選定、権限制御の設計を誤ると「もっともらしいが誤った回答」を量産する装置になります。本記事では、企業実装における設計判断のポイントを体系的に整理します。

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

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

理由は単純です。社内には膨大なドキュメントが眠っており、それらを「検索して読む」ことに人は多くの時間を費やしています。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選定 — 規模と運用要件で判断する

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

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

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

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

• アクセス制御：ユーザー権限に応じて検索対象を絞り込む

• プロンプトインジェクション：取得文書内に埋め込まれた悪意ある指示への耐性

• 機密情報の漏洩：学習データや検索結果に含まれる個人情報・企業秘密

• 監査ログ：誰が何を問い合わせ、何が引かれ、何が回答されたかの記録

OWASP Top 10 for LLM Applications では、プロンプトインジェクション、機密情報漏洩、過剰なエージェンシー付与などが主要リスクとして整理されています3。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導入の成功法則 を併せて参照してください。

出典

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

よくある質問

RAGとは何ですか？

Retrieval-Augmented Generationの略で、LLMに外部の知識ソースを参照させて回答を生成する手法です。学習データには含まれない社内固有情報や最新情報を根拠にした応答が可能になり、企業利用で最も実用化が進んでいるLLM活用形態の一つです。

RAGとファインチューニングはどう使い分けますか？

頻繁に更新される社内情報の参照にはRAGが適しています。文体の統一や特定ドメインの用語理解にはファインチューニングが有効です。多くの企業ユースケースでは、RAG単体、もしくはRAGと軽量なプロンプトエンジニアリングの組み合わせで十分な精度が得られます。

ベクトルDBはどう選べばよいですか？

データ規模・更新頻度・ホスティング要件の3軸で判断します。小規模（〜100万チャンク）はPostgres+pgvectorで十分、中規模はWeaviate/Qdrant等のマネージドサービス、大規模はPinecone/Vespa等のエンタープライズ向け選択肢が現実的です。

検索精度が出ないときの主な原因は何ですか？

チャンキング戦略の失敗が最頻出原因です。単純な文字数固定分割では文脈が分断され、質問意図と合致する箇所を引けません。見出し階層や段落単位での分割、メタデータ付与、ハイブリッド検索（ベクトル＋キーワード）の組み合わせで大きく改善します。

社内文書の権限制御はどう実装しますか？

ベクトルDBに権限メタデータ（組織・プロジェクト・機密レベル）を付与し、検索時にフィルタを掛ける構成が標準です。LLMへ渡す文脈自体から権限外の情報を除外することで、プロンプトインジェクション等による漏洩リスクを構造的に抑えます。

RAGの導入期間はどれくらいですか？

PoCレベルなら2〜4週間、社内運用レベルで8〜16週間が目安です。ドキュメントの前処理（PDF→テキスト化、構造化）に想定以上の工数がかかるケースが多く、初期のデータ品質確保が全体スケジュールを左右します。

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" ↩