RAG導入、63%が期待外れに終わる構造的理由
「自社のマニュアルや過去の提案書をAIに読ませて、自動で答えてほしい」——この要望に応える技術として、RAG（検索拡張生成）がここ数年で急速に注目を集めています。カスタマーサポートの自動化、社内ナレッジの活用、契約書照会の効率化。用途は多岐にわたり、大手から中小まで導入事例が積み重なっています。
ところがGartner（2025年）の調査によれば、RAGを試みた企業のうち63%が「当初の期待値を下回った」と回答しています。10社中6社以上が失望している計算です。
失敗の理由は「AI技術が難しすぎる」ではありません。問題はもっと古典的な場所にあります。本記事では、失敗の構造を3層に分解し、成果を出すための設計思想を整理します。
RAGとは何か — 3分で理解する仕組み
RAG（Retrieval-Augmented Generation）は、LLM（大規模言語モデル）の回答精度を高めるアーキテクチャです。日本語では「検索拡張生成」と訳されます。
通常のLLMは、学習時のデータしか知らない状態で質問に答えます。「弊社の就業規則では有給は何日か」と聞いても、社内文書は学習していないので答えられません。RAGはこの問題を、「質問を受けたら、まず関連文書を検索し、その文書をLLMに読ませてから回答させる」という仕組みで解決します。
図1: 通常のLLMとRAGの処理フロー比較
RAGの利点は明確です。自社固有の情報で正確に回答でき、LLMをファインチューニング（追加学習）するよりも低コストで実装できます。また、文書を更新するだけで最新情報が反映される運用のしやすさも魅力です。
RAG市場は年成長率25〜38%で拡大しており、2030年には1兆円超の規模になると複数の調査機関が予測しています。それでも、なぜ63%が期待外れに終わるのでしょうか。
失敗の構造 — 3層で分解する
RAG導入が期待を下回る理由は、技術の難しさではありません。問題は3つの層に積み重なっています。
図2: RAG導入失敗の3層構造（底層ほど根本的な原因）
L1: データ品質の問題（最大の原因）
Gartner（2025年）によれば、RAGを試みた組織のうち63%が「適切なデータ管理体制を整備していなかった」と報告しています。現場で起きる典型例は次のようなものです。
- 重複文書: 同じ規程の旧版と新版が混在し、どちらが最新かシステムが判断できない
- 古い情報: 3年前の製品仕様書が最新版として検索にヒットする
- 機密の混在: 全社向けシステムのインデックスに役員報酬や人事評価データが含まれている
- 非構造化データ: スキャンPDFや手書きメモがOCR処理なしで投入され、テキストが文字化けしている
RAGは「ゴミを入れるとゴミが出てくる」システムです。LLMがいくら賢くても、検索で取得する文書が古かったり矛盾していたりすれば、回答の質は上がりません。これはAI以前の、情報管理の問題です。
L2: 検索精度の問題
RAGの「検索」はGoogleのようなキーワード検索ではありません。ベクトル検索と呼ばれる、文の意味的な近さをもとに関連文書を引っ張る方式です。
ここに落とし穴があります。「意味が近い」と「答えとして正確」は別物です。たとえば「有給の取得手続き」と「有給の残日数の計算方法」は意味が近く、両方が検索結果に混入する可能性があります。回答に必要なのは前者だけだったとしても、後者が混入することで回答が混乱します。
この問題の解決には、文書のチャンク（分割単位）設計、埋め込みモデルの選択、リランキング（再順位付け）の実装など、検索システム側の地道な作り込みが必要です。しかしこの作業は「AIの導入」とは見なされにくく、軽視されがちです。
L3: LLMの活用不足
検索で取得した文書をLLMに渡す際、プロンプトの設計が甘いと精度が落ちます。「以下の文書を参考に答えてください」だけでは、LLMは取得文書を無視して学習データに頼って回答することがあります。
特に問題になるのが、取得情報とモデルの事前知識が矛盾する場面です。社内で独自の業界用語を使っている場合、LLMは一般的な意味で解釈し直してしまう。これはL1・L2を改善しても残る問題で、システムプロンプトとプロンプト設計の工夫が別途必要になります。
成功するRAGの設計思想
失敗の3層を踏まえると、成功するRAG導入の原則が見えてきます。
「AIを賢くする前に、検索を賢くする」——これが実務から得た最も重要な原則です。
RAGはAI技術として語られますが、その成否の70%は検索エンジニアリングと情報アーキテクチャで決まります。これはAI以前から存在してきた課題で、エンタープライズサーチが2000年代から悩み続けた「社内文書検索の精度問題」が、RAGという文脈で再登場しているにすぎません。技術が新しくなっても、問題の本質は変わっていません。
実践的な手順として、次の3段階を推奨します。
- データ棚卸しを先行する（最初の1ヶ月）: 投入する文書をリストアップし、古い文書・重複・機密情報の整理を先行する。ここを省くと後で必ず詰まります。
- 小さな領域で精度を検証する（2〜3ヶ月目）: 全社展開ではなく、特定のFAQや特定業務（例:契約書照会）に絞ってRAGを構築し、回答精度を定量評価する。正解率70%未満なら原因を特定してから拡大する。
- フィードバックループを最初から設計する（継続的に）: 「この回答は正しかったか」をユーザーがフィードバックできる仕組みを最初から組み込む。フィードバックデータがないと改善の方向性が見えません。
海外企業の先行事例から学ぶ
RAGの活用で先行する海外の状況を見ると、日本との差が浮き彫りになります。
Glean（エンタープライズ向け検索AI）の2026年調査によれば、企業のAIユースケースの30〜60%にRAGが採用されています。最もROIが高い領域はカスタマーサポート、法務コンプライアンス、社内ナレッジ管理の3分野とされています。注目すべきは、これらが「単一のRAGシステム」で実現されているわけではないという点です。領域ごとに異なる文書ベース、異なるチャンク戦略、異なる評価指標が設計されています。
ニューヨークの金融データ分析系スタートアップの事例（Squirro State of RAGレポート）では、グラフ構造でコンテキストを付与するRAGを実装した結果、AIアナリストの回答精度が最大5倍改善されたと報告されています。この「5倍改善」の大半がモデルのアップグレードではなく、コンテキスト構造の再設計から生まれた点が重要です。
日本と海外の最大の差は「検索精度の定量評価」にあります。海外の先進企業ではRAGASなどの評価フレームワークを適用し、継続的に改善しています。「なんとなく動いている」と「数字で改善している」では、半年後の完成度が大きく変わります。
Lat91の実体験: エージェントとRAGの交差点
私たちLat91は、社内業務を自動化する10体のAIエージェントチームを構築・運用しています。エージェント設計を進める中で、RAG的なアプローチが必要な場面は予想以上に多くありました。
具体的には、SEOエージェントが記事を書く際に「公開済み記事との重複チェック」を行うための知識参照システムがその一例です。最初のバージョンは単純な全文テキスト照合でしたが、「同じテーマを別の切り口で書いた記事」を重複と誤検知するケースが頻発しました。ベクトル検索に切り替えてからも、チャンクの粒度が粗すぎて「記事Aの第3段落と記事Bの第2段落が意味的に近い」という判定が誤って出るケースがありました。
この経験から実感したのは、RAGにおける最難関は技術実装ではなく「何を検索の正解とするか」の定義だということです。ビジネスにおける「正確な回答」の定義は、技術よりも業務の文脈に深く根ざしています。それを明確にしないままシステムを構築しても、改善の方向性が定まりません。
よくある誤解と反論への回答
「RAGさえ導入すれば、社内のどんな質問にも答えられるようになる」——この期待が最も多く見られます。現実には、RAGが得意なのは「文書の中に答えが書いてある質問」に限られます。「なぜあの案件は失注したのか」「競合が次に仕掛けてくる戦略は何か」のような判断・推論を要する問いには、RAGは答えられません。RAGを「万能の社内AI」として期待すると、失望は必然です。
「コストが高すぎる」——これは半分正しく、半分間違いです。OpenAI EmbeddingsなどのクラウドAPIを使うと従量課金が積み重なりますが、pgvector（PostgreSQLの拡張機能）を使えばオンプレミスまたはレンタルサーバーで低コストに構築できます。真のコストは技術選定よりも、データ整備と評価サイクルの人件費です。「導入して終わり」ではなく継続的な改善が必要なシステムだという認識が、コスト設計を正確にします。
「セキュリティが不安」——これは正当な懸念です。最もリスクが高いのはアクセス制御の設計です。「Aさんが閲覧できない機密文書がRAGの検索インデックスに含まれており、Aさんの質問への回答にその内容が使われてしまう」という事故は実際に起きています。文書ごとのアクセス権を検索インデックス側でも管理するメタデータフィルタリングは、後から追加しようとすると大規模な設計変更を要します。最初から組み込むことが必須です。
2028年のRAG: Agenticへの進化
現在のRAGは「質問 → 検索 → 回答」という1往復の構造が基本です。次のステージがAgentic RAGで、AIエージェントがRAGの検索戦略そのものを動的に制御します。
具体的には、「最初の検索結果が不十分と判断したら別のクエリで再検索する」「複数の文書を組み合わせて推論する」「必要なら外部APIも参照する」といった、自律的な情報収集と推論のループです。
2028年には、このAgentic RAGが企業AIの標準アーキテクチャになると予測されています。ただし前提条件があります。「L1のデータ品質」と「L2の検索精度」が整備されていることです。基盤を作らずにAgenticに進んでも、精度の低い検索を何度ループさせても答えは出てきません。今のうちにデータ基盤を整備しておくことが、2年後の差を生みます。
まとめ
- RAGは自社文書をAIの回答に活用する技術で、ファインチューニングより低コストで実装できる。
- 導入企業の63%が期待外れに終わる最大の原因は、AI技術ではなくデータ品質と検索精度（L1・L2）にある。
- 「AIを賢くする前に、検索を賢くする」が成功の基本原則。最初の1ヶ月はデータ棚卸しに充てることを推奨する。
- 海外では企業AIユースケースの30〜60%にRAGが採用されており、定量評価フレームワークによる継続改善が先行組織の共通点。
- 2028年のAgentic RAGに備えるためにも、今のうちにデータ基盤を整備しておくことが戦略的に重要。
Lat91では、AIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
「RAGを試したいが何から始めればいいかわからない」「構築したが精度が出ない」という方は、まずは無料相談からお気軽にどうぞ。