RAG（Retrieval-Augmented Generation）は、生成AIに自社固有のドキュメントを参照させる技術として、2025〜2026年にかけて多くの企業が導入を進めました。しかしその大半は、PoC段階で「思っていたより精度が出ない」「期待した回答が返ってこない」という壁にぶつかります。RAGの精度問題は、モデルの性能ではなくほぼ全てのケースで「実装パイプラインのどこかでデータが壊れている」ことが原因です。本記事では、RAGが失敗する原因を5つのフェーズ（前処理／チャンキング／埋め込み／検索／生成）別に分解し、各フェーズの典型的なハマりどころと改善手法を整理します。
RAGの精度問題は「Garbage In, Garbage Out」の問題
RAG構築の失敗を語るとき、最も重要な原則は「ゴミを入れればゴミが出る」です。多くのチームはモデル選定やプロンプト調整に時間を使いますが、実際にはデータクレンジングに投じる工数がRAGプロジェクト全体の40〜60%を占めるのが現実です。LLMが優秀でも、与えられた情報が壊れていれば優秀な回答は出ません。
以下、5フェーズに分けて典型的な失敗パターンと対策を見ていきます。
フェーズ1：前処理（データの取り込みとクレンジング）
失敗パターン1-1：PDFを生のまま投入する
PDFは見た目はテキストですが、実際には複雑な座標情報・複数カラム・表・画像・ヘッダー/フッターが混在する構造です。生のテキスト抽出では、表が崩れ、カラムが順番通りに読まれず、ヘッダーが本文に混入します。これだけで精度が大幅に下がります。
改善策：レイアウト認識ライブラリ（Document Intelligence、unstructured、PyMuPDF等）でレイアウトを保持したまま抽出する。表は表として、見出しは見出しとして構造化してから後段に渡す。
失敗パターン1-2：ノイズ・冗長情報を残したまま投入する
社内Wiki・議事録・古いドラフト・テンプレート文・規程の前文など、検索ノイズになる情報が大量に混入していると、LLMは「正解の文書」と「ノイズ文書」の区別がつきません。
改善策：ドキュメントの種類別に保持/廃棄ルールを決め、メタデータでフィルタできる状態にしてから取り込む。古いドラフトと最新版が混在する状態は最も危険です。
失敗パターン1-3：更新フローが設計されていない
初回投入時には精度が出ても、ドキュメントが更新されない・古い情報が残り続けることで、3か月後には現場の信頼を失います。
改善策：取り込み・更新・削除の自動化フローを最初から設計する。手動運用は半年で破綻します。
フェーズ2：チャンキング（文書分割）
失敗パターン2-1：すべてを一律サイズで分割する
「とりあえず500トークンで区切る」というアプローチは、最も多い失敗です。同じドキュメント内でも、章・節・段落・表・コード・FAQの粒度はまちまちで、一律分割は文脈を破壊します。
改善策：構造（見出し階層・段落・表・FAQ）を保持したセマンティックチャンキングを採用する。可能であれば、ドキュメントの種類別にチャンキング戦略を切り替える。
失敗パターン2-2：チャンクの中に複数のトピックが混在する
1つのチャンクに「料金の話」と「導入手順の話」と「サポート体制の話」が混ざると、LLMはどれを根拠にすべきか判断できず、回答が薄くなります。
改善策：チャンクは「1チャンク=1トピック」を原則にする。長いチャンクより、短くて意味が完結したチャンクのほうが検索精度が上がります。
失敗パターン2-3：オーバーラップを設定していない
チャンクの境目で文脈が途切れると、関連情報が複数のチャンクに分断されてしまい、検索時に取りこぼしが発生します。
改善策：チャンク間に20〜30%のオーバーラップを設定する。これだけで取りこぼしによる精度劣化が大きく改善します。
フェーズ3：埋め込み（ベクトル化）
失敗パターン3-1：日本語性能を考慮せずに埋め込みモデルを選ぶ
英語データで評価が高い埋め込みモデルが、日本語データで同じ性能を出すとは限りません。日本語の専門用語・略語・カタカナ表記揺れに弱いモデルを選ぶと、検索段階で関連文書を取り逃がします。
改善策：自社のサンプルデータで日本語埋め込みモデルを複数比較してから選定する。OpenAI text-embedding-3-large、Cohere embed-multilingual、日本語特化モデル等の比較が推奨されます。
失敗パターン3-2：メタデータを埋め込み対象に含めない
本文だけをベクトル化し、タイトル・見出し・タグ・更新日・部門等のメタデータを無視すると、検索時の絞り込み力が大きく落ちます。
改善策：本文+タイトル+見出し+タグを組み合わせて埋め込み対象を構成するか、メタデータをハイブリッド検索のフィルタとして活用する。
フェーズ4：検索（リトリーブ）
失敗パターン4-1：ベクトル検索だけに頼る
ベクトル検索は意味的類似度に強い一方、固有名詞・型番・コード・略号などの完全一致では弱い場合があります。「型番A-1234の仕様」のような検索では、ベクトルだけだと類似品の文書を返してしまうことがあります。
改善策：ベクトル検索（意味検索）とキーワード検索（BM25等）を組み合わせたハイブリッド検索を実装する。これがAdvanced RAGの基本です。
失敗パターン4-2：取得件数（top-k）を固定する
top-kを固定すると、本来3件で十分な質問に10件返したり、10件必要な質問に3件しか返せなかったりします。前者はLLMが情報過多で焦点を失い、後者は情報不足で薄い回答になります。
改善策：類似度スコアによる動的な件数調整、または再ランキング（reranker）モデルを併用して上位件数を絞る。
失敗パターン4-3：質問の意図を事前分類しない
「料金が知りたい」「手順が知りたい」「比較したい」「定義を知りたい」では、検索すべきDB・参照すべきドキュメント・回答の出し方がまったく異なります。すべての質問を同じパイプラインに流すと、精度の上限が決まってしまいます。
改善策：Intent-First（意図優先）アーキテクチャを導入し、Routerで質問の意図を分類してからリトリーブを切り替える。これにより検索範囲が劇的に絞られ、精度が向上します。
フェーズ5：生成（LLM呼び出し）
失敗パターン5-1：プロンプトに「根拠を示せ」と書いていない
LLMに「根拠となる文書を引用せよ」「根拠がない場合は『情報なし』と答えよ」と明示しないと、ハルシネーションが量産されます。
改善策：システムプロンプトに、根拠の引用ルール、情報なし時の応答ルール、語尾・文体ルールを明文化する。
失敗パターン5-2：モデルの選定を後回しにする
LLMの性能差は2025〜2026年で大きく開いています。安価なモデルで構築したRAGは、検索フェーズの設計を完璧にしても回答品質に上限が出ます。
改善策：本番LLMはGPT-4系・Claude Sonnet以上・Gemini Pro以上から選定する。コスト最適化はキャッシュ・モデルルーティングで対応する。
RAG精度を継続的に改善する評価サイクル
RAGは「一度作って終わり」ではなく、「評価と改修を繰り返し続けるシステム」です。改善サイクルを回すには、評価データセットと自動評価基盤が必要です。
- 評価データセットの作成：質問・正解回答・正解参照文書のセットを最低50〜100件整備する
- 定量評価指標の選定：Faithfulness（根拠忠実度）、Answer Relevancy（回答関連度）、Context Recall（文脈再現率）等のRAGAS系指標を採用
- 人手評価との併用：定量指標だけでは見えない品質は、人手スコアリングを月次で実施
- 改修サイクルの高速化：1施策につき数日以内で評価結果を出せる体制を作る
renueがRAG構築で必ず徹底している3つの原則
- 前処理に時間を投資する：モデル選定やプロンプトより、データの取り込み・クレンジング・チャンキングに最初の時間を集中させる
- Intent-Firstアーキテクチャを最初から設計に入れる：質問意図のRouter機構をPoC段階から組み込み、後付けにしない
- 評価データセットをPoC初期に作る：精度を主観で判断せず、最初から定量評価できる状態を作る
FAQ
Q1. RAGの精度はどこまで上がりますか？
適切な前処理・チャンキング・ハイブリッド検索・Intent-First設計を組み合わせれば、社内FAQ・社内ヘルプデスク・契約書照会などの実用的なユースケースで「人間の業務に組み込める水準」まで到達します。完璧（100%）を目指すのではなく、「人間の二重チェックを前提にしたドラフトレベル」を初期目標にし、段階的に精度を上げるのが現実的です。
Q2. RAGで一番効果が大きい改善施策はどれですか？
多くの現場で最も効果が大きいのは、前処理とチャンキング戦略の見直しです。次にハイブリッド検索の導入、Intent-Firstアーキテクチャの導入、再ランキングの追加と続きます。プロンプト微調整やモデル変更は最後の1〜2割の改善をもたらしますが、前段が壊れていると限界があります。
Q3. RAGとファインチューニングはどちらが良いですか？
「最新情報を参照したい」「ドキュメントが頻繁に更新される」「出典を明示したい」場合はRAGが優位です。「特定のスタイル・口調に揃えたい」「業界固有のナレッジをモデル内部に持たせたい」場合はファインチューニングが向きます。多くの企業ユースケースではRAGが先で、ファインチューニングは追加の選択肢として検討します。
Q4. RAG構築の費用感はどれくらいですか？
PoCで数百万円〜1,000万円程度、本番運用化で年間数百万円〜数千万円規模が一般的なレンジです。最大の変動要因は、対象データの量と前処理の複雑さ、Router・評価基盤の整備度合いです。データが綺麗で量が少なければ安く、データが汚くて量が多ければ高くなります。
Q5. 自社にRAG構築の知見がない場合、どう進めれば良いですか？
外部パートナーに伴走を依頼しつつ、自社側ではPoCの当初から「データ整備」と「評価データセット作成」を内部で進めるのが効率的です。前処理と評価の知見は社内に残る資産になり、後の本番運用と改善サイクルを支えます。
RAG構築・精度改善の伴走相談
renueは、社内ナレッジ・契約書・帳票・専門文書のRAG構築を、PoCから本番運用までの複数の現場で伴走してきました。「前処理パイプラインの設計」「Intent-Firstアーキテクチャの実装」「評価データセットの整備」「精度改善の施策優先度付け」など、RAG構築で陥りやすい論点を整理する場としてご活用いただけます。30分でrenueが他社と何が違うかをご説明します。