RAGとは？自社データをAIが検索する仕組みと、85%が本番化に失敗する理由
「AIに社内マニュアルを読み込ませれば、何でも答えてくれる」——この期待は正確には半分正しく、半分は危険な単純化だ。
RAG（Retrieval-Augmented Generation、検索拡張生成）という技術が、この期待に最も近い実現手段として急速に注目を集めている。市場規模は2025年の約3,000億円から2030年には約1.5兆円超へ成長すると予測される（出典: MarketsandMarkets, 2025年）。三井住友銀行は130万件の社内文書を横断検索するRAGシステムを構築し、行員の調査工数を大幅に削減した。
一方で、RAGのパイロット導入を経験した企業の85%以上が本番展開に到達していないというデータもある（出典: ragaboutit.com, 2026年）。技術的なハードルは確実に下がっているのに、なぜこれほどの失敗率なのか。
本記事ではRAGの仕組みを実務的な視点で整理し、失敗の構造的な原因と、中小企業が具体的に何から始めるべきかを論じる。RAGは「AIを賢くする技術」ではなく「企業の情報資産を使える形に整える工程」だ。この認識の違いが、成否を分ける出発点になる。
RAGが解決しようとしている問題
ChatGPTやClaudeに「当社の就業規則を教えて」と入力しても、正確な答えは返ってこない。これは当然だ。非公開の社内情報は学習データに含まれていない。
同様に、独自の商品仕様・過去の商談記録・社内のナレッジベース——これらの企業固有情報は、どのLLM（大規模言語モデル）にも存在しない。モデルの学習データが締め切られた日以降の最新情報も、同じ理由で参照できない。
ここで多くの企業が「ならばAIに学習させればいい」と考え、ファインチューニングやRAGに向かう。だが重要なのは、AIが「知らない」ことより深い問題にある。
LLMが的外れな回答をする最大の原因は、参照範囲の狭さではなく、「今の質問に何が関係するか」を判断できないことだ。1万ページの社内文書を全部与えたとしても、LLMのコンテキストウィンドウには収まらない。質問に関連する部分だけを的確に抽出して渡す仕組みが必要で、これがRAGの核心的な役割だ。
RAGの仕組みを正確に理解する
RAGの処理は事前準備と実行時の2フェーズで構成される。
図1: RAGの2フェーズ処理フロー
事前準備のフェーズは一度だけ実行する。社内文書をチャンク（断片）に分割し、埋め込みモデルでベクトル数値に変換してデータベースに保存しておく。人間が「意味的に近い」と判断する文章が、数値的にも近いベクトルになるのがポイントだ。
実行時のフェーズは質問が来るたびに動く。ユーザーの質問をベクトルに変換し、事前に保存したベクトルDBから意味的に近いチャンクを検索・取得する。そのチャンクを「文脈情報」としてLLMに与え、それを踏まえた回答を生成させる。
重要な点を一つ強調する。RAGはLLM自体を変えていない。ChatGPTやClaudeをそのまま使いながら、毎回の回答生成時に関連文書を注入するだけだ。「AIの記憶を増やす」のではなく、「回答ごとに関連情報を手渡す」という構造だ。
ファインチューニングとの違い：どちらを選ぶか
RAGを検討し始めると、必ず「ファインチューニングとどう違うのか」という問いが出る。混同されやすいが、解決する問題が根本的に異なる。
ファインチューニングとは、LLM自体を自社データで追加学習させることだ。特定のトーンで答えるよう調整したり、業界特有の専門用語を正確に扱えるよう訓練したりする。「AIの話し方と専門知識の質を変える」のがファインチューニングだ。
RAGは「AIが参照できる情報の範囲と精度を変える」ことに特化している。IBMの技術ドキュメントにはこう整理されている。「ファインチューニングは情報が静的な場合にのみ有効だ。RAGは動的に変化するコンテンツに強く、スピードとコストの両面で優位性がある」（出典: IBM Think, 2025年）。
図2: RAG・ファインチューニング・標準LLMの比較
実務での判断はシンプルだ。「社内文書・マニュアル・議事録を参照して質問に答えさせたい」ならRAG。「特定の文体や専門用語の精度を上げたい」ならファインチューニング。多くの企業では、まずRAGで価値を検証し、必要と判断してからファインチューニングを加えるという順序が正解に近い。ファインチューニングはGPUリソースと高品質の学習データが必要で、コストと時間がかかる。RAGなら既存のLLM APIを使いながら、文書準備ができれば数日でプロトタイプが動く。
85%が本番化に失敗する、構造的な理由
RAGの技術的な仕組みは難しくない。LangChainやLlamaIndexといったOSSフレームワークを使えば、エンジニアが1週間もあれば動くプロトタイプを作れる。にもかかわらず、なぜ本番化に届かないのか。
答えは一言に集約できる。RAGは「AIの問題」ではなく「検索の問題」だ。この認識がないまま導入しようとするから失敗する。
失敗パターン1：データ品質の軽視
失敗実装に共通する最大の問題が「データハイジーンの欠如」だという（出典: Medium, 2025年）。典型的なケースは、既存文書をそのままベクトルDBに投入しようとすることだ。
企業の文書は、RAG向けに整理されていない。ExcelのセルにまたがるPDF、フォーマットが統一されていない議事録、複数バージョンが混在したマニュアル。これらを固定サイズで機械的にチャンクに切ると、表の行が途中で分断され、前後の文脈を失ったチャンクが大量に生まれる。
ある製薬会社のエンジニアが報告したケースは象徴的だ。業界標準のベンチマーク（MTEB）でスコア92という優秀なembeddingモデルを使ったにもかかわらず、実際の社内文書に対する検索精度は61%にとどまった（出典: ragaboutit.com, 2026年）。モデルの性能ではなく、ドメイン固有のデータ構造がボトルネックだった。
失敗パターン2：コストの爆発と品質劣化の見えなさ
月200ドルで始まったパイロットが、9ヶ月後に月1万4,000ドルへ膨張したケースが報告されている（出典: ragaboutit.com, 2026年）。RAGはLLMへのAPI呼び出しとベクトル検索処理を組み合わせるため、利用量に応じてコストが急増する構造を持つ。
同時に、品質の劣化が見えにくいという問題もある。プロトタイプで正確に答えられていた質問が、本番環境では誤った回答を返すようになる。しかし「静かに劣化」するため、クレームや明示的なエラーが出るまで気づかれない。これが「本番化したものの、数ヶ月で使われなくなる」という結果を招く。
失敗パターン3：検索戦略の単純化
RAGの回答品質は、LLMの性能ではなく検索精度で9割が決まる。「関連する文書チャンクを正しく引き出せるか」がすべてだ。
典型的な失敗は、ベクトル検索一本に依存することだ。ベクトル検索は意味的な類似性を捉えるのが得意だが、固有名詞や型番のような完全一致が必要なケースで精度が落ちる。実際には、従来のキーワード検索とベクトル検索を組み合わせた「ハイブリッド検索」が精度を大幅に改善する。また、取得するチャンク数を増やせば精度は上がるが、LLMへのコンテキスト量とコストも増える。このトレードオフを管理し続けることが、本番運用の本質的な難しさだ。
中小企業の現実的な導入判断基準
RAGは大企業だけの技術ではない。ただし「すべての企業が今すぐ取り組むべき技術」でもない。
Lat91では、10体のAIエージェントチームを設計・構築する過程で、ナレッジ検索の問題に繰り返し直面してきた。社内ドキュメント、商談記録、Slackの過去ログ——これらを横断参照できるエージェントを作ろうとした際、RAGの品質がエージェント全体のパフォーマンスを左右することを実感した。
私たちが最も予想外だったのは、文書の前処理工数だ。PDFから正確にテキストを抽出するだけで、当初想定の3倍の時間がかかった。テーブルの読み込み、ページをまたぐ段落の結合、不要なヘッダー・フッターの除去——これらは自動化が難しく、手動での調整が必要だった。「文書をベクトルDBに入れれば動く」という期待は、初期の数日で完全に裏切られる。
導入を検討する企業が、事前に自問すべき問いを3つ整理する。
問1：誰がどんな質問を、今よりうまく答えられるようにしたいか。「社内情報を活用したい」という漠然とした目的ではなく、具体的なユースケースを1つ特定する。「新入社員が就業規則を調べる時間を週2時間から15分に縮めたい」「商談前に業界事例を30秒で引き出したい」——この解像度がなければ、プロトタイプの合否判定基準すら設けられない。
問2：対象となる文書はどのくらい整理されているか。PDFで保存されているか、Excel混在か、複数バージョンが共存しているか。文書の前処理コストはRAG全体の工数の50-70%を占めることが多い。「文書を整理する工程をどこに組み込むか」を先に決めておかないと、プロジェクトはデータ整理の段階で止まる。
問3：運用フェーズに回せるリソースはあるか。RAGは作って終わりではない。文書が更新されれば再インデックスが必要で、精度モニタリングと定期的な改善サイクルが続く。月に数時間でも担当者を確保できるかを事前に確認する。
この3問に具体的に答えられるなら、RAGへの投資対効果は高い。「なんとなく」の段階なら、まず社内でChatGPTの活用を広げ、生成AI利用の土台を整える方が優先順位は高い。
実際に試し始めるなら、次の手順が現実的だ。まずPineconeやChromaDBなど無料プランのあるベクトルDBを使い、社内文書10-20件で小さなプロトタイプを作る。質問10問を手動で評価し、精度の感覚をつかむ。「これは使える」と判断できたら、文書整備の工数を見積もって本格導入に進む。段階を踏まずに「まず全社導入」を目指すと、データ整備の工数に圧倒されて止まる。
2028年のRAG：AIエージェントとの融合が変えること
RAGは現在、「単発の質問応答」から「エージェントによる継続的な情報活用」へと形を変えつつある。
「Agentic RAG」と呼ばれるアーキテクチャでは、AIエージェントが自律的に「次に何を調べるか」を判断し、複数の検索を繰り返しながら複雑な問いを解く。「来月の新規顧客向けに、過去の商談記録から成約パターンを抽出して提案書の草案を作れ」という複合タスクをこなせる。これは静的な文書参照ではなく、動的な情報収集と推論の組み合わせだ。
LINEヤフーはすでにRAGを社内問い合わせ対応で実用化し、現在はGraph RAGやマルチモーダル検索への移行フェーズに入っている（出典: admina.moneyforward.com, 2026年）。Graph RAGは文書の内容だけでなく「文書間の関係性」もグラフ構造で保持し、より複雑な推論を可能にする。
2028年ごろには、RAGが「特別な技術的取り組み」ではなく、業務システムのデフォルト機能になっていると予測する。根拠は2点ある。クラウドプロバイダーがベクトルDBをマネージドサービスとして展開し、実装ハードルが急速に下がっていること。そして、AIエージェントがタスク実行に外部情報検索を必要とする場面が増えるにつれ、RAGがエージェントの標準コンポーネントとして組み込まれていくことだ。
中小企業にとっての含意は、「今は土台づくりの段階だ」ということだ。今、社内文書を整理し、ベクトル検索の感覚をつかんでおくことが、2028年のAIエージェント活用の土台になる。3年後に慌てて追いかけるより、今の小さなプロトタイプが長期的な優位性に変わる。
まとめ
- RAGは「AIを賢くする技術」ではなく、「企業の情報資産を使える形に整える工程」。LLM自体は変えず、質問のたびに関連文書を動的に注入する。
- ファインチューニングとの使い分け：動的に変化するデータへの質問応答はRAG、文体や専門用語の精度向上はファインチューニング。まずRAGで価値を実証する順序が合理的。
- 85%が本番化に失敗する根因は「技術」ではなく「データ品質」と「検索精度の管理不在」。文書前処理が工数全体の50-70%を占める現実がある。
- 中小企業の導入判断は3問：具体的なユースケースがあるか、文書の整理状態はどうか、運用リソースを確保できるか。
- 2028年にはRAGがAIエージェントの標準コンポーネントになる。今の小さなプロトタイプが3年後の競争力に変わる。
Lat91では、AIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
「自社データをAIに活用したいが、まず何から手をつければいいかわからない」という方は、まずは無料相談からどうぞ。社内文書の整理方法から、具体的な構成設計まで、御社の状況に合わせてご提案します。