「社内の情報をAIに学ばせたい」という相談は、今や毎週のように届く。多くの場合、担当者がイメージしているのは「社内データを丸ごと食わせた、うちの会社専用のGPT」だ。その要望に応える技術として名前が上がるのが、RAG（Retrieval-Augmented Generation：検索拡張生成）である。
ところが実情を見ると、RAG導入プロジェクトの初年度頓挫率は7割に迫るとも言われる。市場規模がCAGR 38.4%で急拡大しながら（2025年：約19.4億ドル→2030年：約98.6億ドル、MarketsandMarkets調べ）、なぜこれほど多くのプロジェクトが成果を出せずに終わるのか。
原因は技術にない。検索エンジン設計の欠如にある。この記事では、RAGの本質的な仕組みから、失敗の構造的な理由、そして中小企業が今週から始められる具体的な一手まで、実務者の視点で解説する。
RAGとは何か — AIへの記憶移植という誤解を解く
まず定義から整理したい。RAGとは、生成AI（LLM）が回答を生成するときに、あらかじめ外部のデータベースから関連情報を検索して引っ張り出す仕組みだ。
通常のLLMは、学習時点（カットオフ）までの知識しか持っていない。かつ、社内の固有情報（製品仕様書、社内規定、過去の商談履歴）はそもそも学習データに含まれていない。RAGはこの制約を、記憶の置き換えではなく必要な時に自分で検索するという仕組みで解決する。
プロセスをシンプルに説明すると：
- ユーザーが質問する（例：A社向けの見積もり条件を聞く）
- システムが社内ドキュメントの中から、質問に関連する文書を検索する
- 検索結果を文脈としてLLMに渡す
- LLMが文脈を踏まえて回答を生成する
図1: RAGの処理フロー
ここで重要なのが、LLM自体のパラメータ（記憶）は一切変わらないという点だ。RAGはAIを賢くする技術ではなく、AIが正しい情報にアクセスできる環境を整える技術だ。この違いを理解しないまま導入を進めると、後述する失敗パターンにはまる。
社内データをRAGにつなぐと、何が変わるのか
通常の生成AIとRAGありの生成AIでは、実務的なアウトプットが大きく変わる。具体的なシナリオで考えてみる。
従業員80名のシステムインテグレーター、B社を例にとる。営業担当がよく使う問いは2種類だ。過去に同業種の顧客へ提案した資料はあるか。この顧客の対応履歴で気をつけるべき点は何か。
RAGなしの場合、担当者は社内のファイルサーバーを手作業で検索し、20〜30分かけて関連資料を探す。見つかっても最新版かどうかが不明なまま使うことも多い。
RAGありの場合、〇〇業界で昨年度にした提案内容を問いかければ、システムが関連する提案書・議事録・メールを検索し、LLMが要約して返す。処理は数秒。ただし前提がある。社内の文書が整理されており、RAGが正しい文書を正しく検索できる状態になっていることだ。
ここが、多くの企業がつまずく地点になる。
7割が失敗する3つの構造的原因
RAG導入が機能しない理由は、ほぼ例外なく以下の3つに収束する。技術の問題ではない。
原因1：データが検索に耐えられる状態になっていない
RAGの精度は、入力するデータの品質に直接依存する。よくある問題：
- スキャンしたPDF（テキスト抽出不可）が多数混在している
- 同じ情報の複数バージョンが並存している（最新版が不明）
- ファイル名が「提案書_最終版_修正2_final.docx」のような状態
- メタデータ（作成日・担当者・対象案件）がない
RAGにとって、粗雑なデータは粗雑な回答の素材だ。ゴミを入れればゴミが出る（GIGO: Garbage In, Garbage Out）は、RAGでも変わらない。
原因2：検索の設計が曖昧なまま構築している
RAGの核心は検索だ。ところが多くの導入プロジェクトが、ベクトルDBを立ち上げて文書をインポートすれば完成という認識で動いている。
現実には、ユーザーの質問の仕方と、文書内の表現が一致しないことが頻繁に起きる。A社の予算感を聞く質問に対して、文書内にA社の年間投資計画と書かれていれば、単純なキーワード検索ではマッチしない。意味的な類似度で検索するベクトル検索も、専門用語や社内固有の用語に弱い。
検索精度を担保するには、ハイブリッド検索（ベクトル検索+キーワード検索の組み合わせ）の設計や、チャンク（文書の分割単位）の最適化が必要になる。これは技術的な作業だが、何をどう検索させたいかというビジネス要件の理解なしには設計できない。
原因3：評価の仕組みがない
最も見落とされがちな失敗原因だ。RAGシステムを構築した後、本当に正しい情報を返しているかを確認するプロセスがないプロジェクトが大半を占める。
ハルシネーション（AIの作り話）はRAGでゼロにはならない。検索でヒットした文書の内容が古かったり、部分的に誤りが含まれていれば、LLMはそれを信じて回答する。定期的な評価と改善のサイクルがない限り、RAGシステムは時間とともに劣化する。
図2: RAG失敗の3つの構造的原因
RAGが得意なこと・苦手なこと
RAGを適切に使うには、その能力の輪郭を正確に知る必要がある。
得意な場面：
- 社内規定・ポリシーへの問い合わせ（「育児休業の申請期限は？」）
- 製品仕様・マニュアルの検索（型番ごとの技術仕様の照会など）
- 過去の事例・議事録の要約（特定顧客の商談履歴の抽出など）
- FAQの自動応答（問い合わせ文と文書の表現が近い場合）
苦手な場面：
- 複数の文書を横断して推論が必要な質問（Q1とQ2の比較から原因を推測するような複合的な問い）
- 最新情報が時々刻々と変わる領域（リアルタイムデータは別途設計が必要）
- 文書に書かれていない暗黙知（担当者の性格・人間関係など、どこにも記録されていない情報）
- 質問自体が曖昧な場合（「なんかいい感じの提案書」はRAGでは答えられない）
RAGはすべてを解決する魔法ではない。文書に書いてあることを正確に引き出すことに特化した技術だ。それ以外のニーズには別のアプローチ（Fine-tuning、AgenticRAG、人間のレビューフロー）が必要になる。
Fortune 500の65%が先行する — 海外の実践事例
Fortune 500企業の65%がRAGベースの社内知識管理システムのパイロットを実施している（業界調査）。ただしパイロットであり全社展開ではない点に注目したい。先進企業ですら、まだ試行錯誤の段階にある。
実際にRAGを本番運用で成果を出している事例として、金融業界のJPMorganが参考になる。同社は数百万件の法的契約書を検索できるシステムを構築し、弁護士が通常数時間かけて行うデューデリジェンスの初期調査を数分に短縮したとされる。重要なのは、同社が全文書を対象にした網羅的なRAGではなく、特定用途の文書群に絞ったRAGから始めた点だ。スコープを絞ることで、データ品質の管理と検索精度の担保が現実的になった。
英国の保険会社Aviva（従業員3万人超）は、社内のHRポリシー問い合わせにRAGを導入した。導入初期はハルシネーション率が高く、多くの誤回答が発生した。原因を調査すると、古いバージョンのポリシー文書が新しいものと並存していたことが判明した。文書のバージョン管理を整備し直した後、回答の正確性が大幅に向上したという。技術の問題ではなく、データ管理の問題だったという典型的な事例だ。
これらの事例に共通するのは、導入して終わりではなく、導入してから改善サイクルを回し続けたという姿勢だ。RAGは構築より運用の方が難しい。
Lat91の実体験 — AIエージェントとRAGの組み合わせ
私たちLat91は、社内業務を自動化する10体のAIエージェントチームを構築・運用している。その過程で、RAG的な仕組みの設計に何度も向き合ってきた。
率直に言うと、最初の試みは失敗に近かった。社内の知識フォルダ（リサーチ結果・投稿パターン・SEO実績など）をエージェントに参照させようとしたとき、エージェントが存在するはずの情報を見つけられないという問題が頻発した。
原因を特定するまでに時間がかかったが、最終的には2つの問題が重なっていた。1つ目は、ファイルの命名規則がバラバラで、同じ内容のドキュメントが複数の場所に異なるフォーマットで存在していたこと。2つ目は、どのエージェントがどの情報を参照すべきかの設計が曖昧だったことだ。
改善後は、各エージェントごとに参照すべき知識ベースを明確に分離し、ファイルには必ずメタ情報（作成日・用途・参照条件）を付与するルールを設けた。単純な変更に見えるが、これだけでエージェントの回答精度が体感で大きく改善した。
教訓：RAGの精度は、AIの賢さより、人間によるデータ管理の規律に依存する。
2028年のRAG — AgenticRAGという次のステップ
現在主流のシンプルRAG（1回検索して1回回答）の限界は明らかになってきている。複雑な質問には複数回の検索が必要だし、質問が曖昧な場合は逆質問するロジックも必要だ。
この課題を解決するのがAgenticRAG（エージェント型RAG）だ。単純な検索→生成の1往復ではなく、エージェントが自律的に何を調べるかを決め、複数の検索を繰り返しながら回答を組み立てる。
例えばQ1とQ2の売上差の主因を問う質問に対して、シンプルRAGはQ1の売上文書とQ2の売上文書を別々に返すだけかもしれない。AgenticRAGは、両方を取得したうえで差の原因に関する仮説文書まで検索し、総合的な分析を返すことができる。
2026年時点でAgenticRAGはまだ実用化フェーズの初期にある。一部の先進企業が試験導入を始めているが、評価手法や運用コストの課題が残る。ただし方向性は明確で、2028年までにRAGとAIエージェントの統合は主流になると予測される。GraphRAG（知識グラフとRAGの組み合わせ）の実用化も進んでおり、社内の人間関係や組織構造をAIが理解したうえで回答する未来が近づいている。
今RAGを導入するなら、シンプルRAGで確実に成果を出すことを優先しつつ、AgenticRAGへの移行を見据えた設計（文書の構造化・メタデータ設計・評価基盤の整備）を進めておくことが賢明だ。
中小企業がRAGを始める5つのステップ
大企業の事例を聞いて難しいと感じる必要はない。RAGは規模に関係なく導入できる。ただし、小さく始めることが重要だ。
Step 1：問いを1つ決める（スコープを絞る）
社内の全情報をAIで検索できるようにしたい、という目標設定は失敗の始まりだ。まずどの質問に答えられるようにしたいかを1つに絞る。新入社員からのHR問い合わせに自動回答したい、といった具体的な問いから始める。スコープが小さければ、データの整備範囲も小さくなる。
Step 2：対象文書を棚卸しする（データ整備）
スコープが決まったら、対象となる文書を全部洗い出す。スキャンPDFはOCRでテキスト化する。バージョン管理されていない文書は最新版を確定する。これが最も時間のかかる工程であり、最も重要な工程だ。
Step 3：小さなプロトタイプを動かす（PoC）
Claude API、OpenAI API、LlamaIndex、LangChainなどのツールを使えば、技術者でなくてもPoCを1週間程度で動かすことができる。最初は文書20〜30件程度で十分だ。精度の確認より仕組みが動くことを確認する段階だ。
Step 4：評価基準を決めて測定する
正しい回答率を測定する仕組みを作る。テスト用の質問集（20〜50問）と正解例を用意し、RAGが返す回答と比較する。自動化が難しければ、週1回の人手チェックでも構わない。測定なしの改善はできない。
Step 5：使いながら改善する（運用ループ）
実際のユーザーに使わせながら、回答がおかしかった質問を記録する。その質問を使って文書の不備を特定し、修正する。このサイクルを月1回以上回すことで、システムは徐々に改善される。
よくある反論への誠実な回答
RAGよりFine-tuningの方が精度が高くなるのでは
この問いは正当だ。Fine-tuning（モデルの追加学習）はLLMのパラメータ自体を更新するため、特定の文体やドメイン知識に深く最適化できる。ただし、Fine-tuningには大量の高品質なトレーニングデータが必要で、コストも高い。また学習後にデータが更新されると、再学習が必要になる。最新の社内情報に即座に対応したい、コストを抑えたいという大半の中小企業には、RAGの方が現実的な選択だ。両者を組み合わせるRAG + Fine-tuningというアプローチも存在するが、それはさらに複雑になる。
RAGを入れてもハルシネーションは防げないのでは
完全には防げない、これは正直に認める。ただし、フィールド調査ではRAGパイプライン導入後にハルシネーションが70〜90%削減されるという結果が出ている。ゼロにするのではなく大幅に減らすという期待値で臨むべきだ。また、RAGはLLMが参照した文書を明示できるため、どのドキュメントをもとに回答したかのトレーサビリティが確保できる。これがハルシネーションの検知を容易にする。
小規模な会社には費用対効果が合わないのでは
規模による。問い合わせ対応に月20時間以上かかっている場合、PoCの構築コスト（エンジニア工数10〜20時間程度）は数ヶ月で回収できることが多い。ただし、文書整備のコストは過小評価されがちだ。技術の費用対効果よりデータ整備の工数の方が大きいケースが多い。まず対象スコープを絞り、小さく始めることが費用対効果を最大化する近道だ。
まとめ
- RAGはAIに知識を記憶させる技術ではなく、AIが知識を自分で検索できる環境を作る技術だ
- 導入の7割が失敗するのは技術の問題ではなく、データ品質・検索設計・評価の仕組みの欠如が原因
- RAGは文書に書いてあることを正確に引き出すことに特化している。それ以外を期待してはいけない
- 海外先進企業も特定用途に絞ったRAGから始め、改善サイクルを回している
- AgenticRAGとGraphRAGの台頭で、2028年頃にはRAGの姿が大きく変わる。今はシンプルRAGで確実に成果を出すことに集中する
RAGは正しく設計すれば中小企業でも現実的なROIが出る技術だ。一方で社内GPTを夢見て飛びつくと、高額なシステムが自信満々に間違いを返すAIになる。その境界線は、検索エンジン設計への理解にある。
Lat91では、AIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
RAGを試してみたいが、どこから手をつければいいかわからないという方は、まずは無料相談からお気軽にどうぞ。御社の業務と既存データに合った、現実的な導入設計をご提案します。