「社内データをAIに渡せば、あとはAIが賢く答えてくれる」と多くの企業が期待する。実際、2025年時点で企業AI活用の63%がRAGを採用しており（Gartner, 2025）、関心は急速に高まっている。だが同年、別のデータが静かに示していた。RAGを導入した企業の72%が、1年以内に実用化を断念しているという事実だ。（出典: ragaboutit.com, 2025）
「AIに渡す」のではなく、「AIが使える形で整備する」——この違いを理解しないまま走り出した企業が、ほぼ必ず失敗する。なぜそうなるのか、何をすれば突破できるのか。実際にRAGを活用したAIエージェントを運用するLat91の経験をもとに、構造的に解説する。
RAGとは何か：3分で理解する本質
RAGは「Retrieval-Augmented Generation（検索拡張生成）」の略で、2020年にMeta AI Researchが発表した手法だ。仕組みは次の通りシンプルだ。LLM（大規模言語モデル）が回答を生成する前に、外部のデータベースから関連情報を検索し、それを文脈として追加してから回答させる。
なぜ必要か。LLMは学習データのカットオフ以降の情報を知らない。自社の製品マニュアル、社内規定、過去の商談記録——こうした非公開情報は、どれだけ優秀なモデルでも知りえない。RAGはこのギャップを埋める技術だ。
図1: RAGの基本フロー — 外部ドキュメントを検索してLLMに渡し、根拠のある回答を生成する
RAGを使えば、社内ドキュメントに基づいた回答が可能になる。「この契約書の支払い条件は？」「先週の商談でXX社が言っていた懸念点は？」——従来のキーワード検索では見つけられなかった情報を、自然言語で引き出せる。
ここまでは多くの解説記事が書いていることだ。問題はここからにある。
72%が失敗する：5つの構造的理由
「RAGを入れたのに全然使えない」と導入から数ヶ月後に多くの担当者が語る。失敗には共通したパターンがある。
理由1：データを「投入」するだけで終わる
最も多い失敗だ。社内にある議事録、マニュアル、契約書などをそのままベクトルDBに流し込む。フォーマットは不統一、重複情報だらけ、古いバージョンが混在している——そのままRAGシステムを作っても、検索結果は信頼できるものにならない。
あるシステム開発会社（従業員150名）が体験談を共有していた。技術仕様書4,000件を一括投入したところ、「最新版」と「2年前の旧版」が混在し、旧版の情報が回答に混じって顧客対応でトラブルになった。データ品質の確認に3ヶ月を費やし、最終的に有効なドキュメントは当初の30%に絞られた。
理由2：チャンキング設計の欠如
チャンキングとは、ドキュメントを検索可能な断片に分割する処理だ。多くの初期実装では「固定サイズ」でテキストを切り分けるが、これが問題を引き起こす。
例えば契約書の「支払い条件は30日以内、ただし以下の場合を除く」という文を固定サイズで切ると、「ただし以下の場合を除く」の続きが別チャンクに入り、文脈が分断される。LLMは不完全な情報で回答するしかなく、誤った内容を自信満々に返す。これがいわゆるハルシネーションの主要な発生源だ。
理由3：導入後の管理体制がない
RAGは一度作れば終わりではない。ドキュメントは更新される。製品価格が変わる。規定が改訂される。だが多くの企業で、RAGシステムへの更新作業は属人化し、気づけば3ヶ月前の情報で回答し続けている状態になる。
「知識ベースの鮮度管理」を誰が、どの頻度で行うか——この設計なしにRAGは機能しない。
理由4：パイロット成功後の放置
パイロット段階ではうまく動いた。チームの熱量も高く、手動でドキュメントを整備し、チャンキングも丁寧に行った。本番リリース後、担当者が別プロジェクトに異動した——これが全てを狂わせる。
パイロットの成功は「整備されたデータ」と「熱心なメンテナンス」によるものだが、本番運用ではその前提が崩れる。72%の失敗の多くは、この「パイロット後の放置」から生まれている。
理由5：可観測性の欠如
RAGシステムは「動いている」ように見えても、回答品質が劣化し続けていることがある。検索精度はどうか。ハルシネーションはどのくらい発生しているか。ユーザーが実際に満足しているか——これらを測定する仕組みなしに、問題は発見されない。
あるFintech企業では、RAGシステムを6ヶ月運用した後に初めて「回答の正確率が74%から52%に落ちていた」ことに気づいた。劣化の原因は知識ベースの陳腐化だったが、モニタリングがなかったため誰も気づかなかった。
図2: RAG導入から1年後の生存率イメージ — 各段階で異なる理由による脱落が起きる
本番稼働に到達した企業の共通点
失敗する企業と成功する企業は、何が違うのか。海外の先進事例が示唆的だ。
Morgan Stanley（米金融大手）は、ウェルスアドバイザー向けに社内RAGシステムを導入した。AzureとAWS BedrockなどマルチクラウドのRAG基盤を組み合わせ、数万件の投資調査レポートをリアルタイムで検索できる。現在、アドバイザーの98%がシステムを日常業務に使っている。成功の鍵は「コンテンツキュレーションチーム」の設置だ。ドキュメントの品質管理と更新を専任チームが担い、知識ベースの鮮度を保つ仕組みが整備されている。（ZenML LLMOps Database, 2024）
Glean（エンタープライズ知識検索SaaS）はFortune 500企業に広く採用され、Gartnerのエマージングリーダーに選出された（2025年）。同社のデータによると、エンタープライズRAG検索を持つ企業の従業員は情報探索に週0.7時間を費やすのに対し、持たない企業の従業員は週8.2時間かかっている。11倍の差だ。（Glean / Gartner, 2025）
両社に共通するのは「RAGをシステムとして捉えるのではなく、知識管理のプロセスとして捉えている」点だ。技術的な実装は比較的短期間で完了する。難しいのは、組織の知識を常に「検索可能な状態」に保つ人・プロセス・ルールを整備することだ。
Lat91でも同様の経験がある。AIエージェントチームに社内ナレッジをRAGで提供する試みをした際、最初に直面したのは「技術的な問題ではなく、知識の所有者が誰かわからない問題」だった。誰が書いたかわからないドキュメントは更新もできないし、内容の正確性を保証できない。RAG導入は、必然的に「社内情報のオーナーシップの整理」を迫る。これを最初から設計に組み込んでいた企業だけが、1年後も動かし続けられる。
RAGを機能させる4つの最低条件
では具体的に何を準備すれば本番稼働に到達できるのか。
条件1：データの棚卸し（導入前3週間）
既存ドキュメントを「使用中」「廃止すべき」「更新が必要」の3種に仕分ける。全部入れようとしない。最初は「このユースケースで最もよく聞かれる質問30件」を答えられるドキュメントだけに絞る。スコープを小さく保つことが、最初の成功体験につながる。
条件2：構造に沿ったチャンキング設計
固定サイズではなく、文書の構造に沿って分割する。製品マニュアルなら「章」単位、FAQ文書なら「Q&Aペア」単位だ。チャンクサイズは200〜500トークンが実績値として多く報告されている。前後20〜50トークン分をオーバーラップさせると文脈切断を防げる。
条件3：更新プロセスのルール化
「誰が、何をトリガーに、どのドキュメントを更新するか」を明文化する。製品仕様が変わったら、誰がRAGの知識ベースも更新するか。これがないと3ヶ月後に陳腐化する。月次レビューをカレンダーに入れ、ドキュメント更新と知識ベース更新を同じタスクとして扱う。
条件4：評価の仕組み（常に測る）
「回答の正確率」「ユーザー満足度（Thumbsアップ/ダウン）」を定期的に測定する。週次でレポートを確認し、品質が下がれば即座に原因を特定する仕組みを作る。LangSmithなどのObservabilityツールの活用も検討する価値がある。
月曜日から試せる最小ステップ
RAGを大規模に始める必要はない。まず「この部署で最もよく同じ質問を受けるシナリオは何か」を1つ特定する。そのシナリオに関連するドキュメントを5〜10件整備する。ClaudeのプロジェクトやOpenAI Assistants APIを使えば、技術者なしでもRAGの原理的な動作を試せる。スコープを小さくして実体験を積むことが、本格導入の前提条件だ。
2026年のRAG最前線：3つの変化
RAGの技術と市場は急速に変化している。2026年に知っておくべき変化を3点に絞って整理する。
Agentic RAGの台頭
従来のRAGは「1回の検索 → 1回の回答」だった。Agentic RAGは、AIエージェントが自律的に「どの情報が必要か」を判断し、複数回の検索を繰り返しながら段階的に回答を構築する。ServiceNowはこのAgentic RAGをITサービス管理に適用し、インシデント解決の自動化率を大きく向上させた。複合的な判断が必要な業務に強いが、検索の連鎖が増えるほどコストとレイテンシが増加する。現時点では「定型的な質問が多い業務」は通常のRAG、「複合的な判断が必要な業務」はAgentic RAGと使い分けるのが実践的な判断基準だ。
マルチモーダルRAG
テキストだけでなく、図面・画像・表・PDFなど非構造化データも検索対象にできるようになってきた。製造業の設備マニュアルには大量の図面が含まれるが、これまでテキスト検索では参照できなかった。マルチモーダルRAGは「図の中の部品番号」「設計図の寸法」を検索対象にできる。日本の製造業でのRAG導入が今後加速する可能性が高い理由の一つだ。
市場規模の急拡大
RAG市場規模は2025年の19.4億ドルから2030年には98.6億ドルへ、年率38.4%で成長すると予測されている（MarketsandMarkets, 2025）。クラウド大手（Azure AI Foundry, Google Vertex AI, AWS Bedrock）全てがマネージドRAGサービスを提供し、実装の技術的ハードルは1年前より大きく下がった。2028年には「RAGなしの社内AI活用」は競合比較で明確に不利になる可能性がある。先行企業と後発企業の間に、知識管理システムとしての差が積み上がっていくからだ。
よくある疑問への回答
「ファインチューニングではダメですか？」
この質問は正当だ。ファインチューニングはモデルの振る舞いを変えることに適しており、RAGはモデルに外部知識を参照させることに適している。社内知識の参照用途には、一般的にRAGの方が適切だ。理由は3つある。ファインチューニングは知識ベースが更新されるたびにコストがかかる。参照できる知識量に上限がある。知識の出典を示すことが難しい。「どのドキュメントを根拠に答えているか」が重要な業務（法務、コンプライアンス、契約管理）ではRAGを選ぶべきだ。
「中小企業にはコストが高すぎませんか？」
初期の技術的実装コストは下がっている。Pinecone, ChromaDB, WeaviateなどのベクトルDBは無料枠から始められる。マネージドサービスを使えば月額数万円規模でのスタートも可能だ。コストがかかるのは技術的な実装よりも「データ整備と運用体制の構築」で、これはツールではなく人のコストだ。外部に委託するか、内製するか、段階的に広げるかを現実的な規模感で決める方が重要だ。
「AIが嘘をつかないようにするには？」
RAGがハルシネーションを完全に防ぐわけではない。チャンキング設計の精度、チャンクサイズ、検索アルゴリズムの設定によってハルシネーション率は変わる。実務的な対策として有効なのは、「根拠ドキュメントの引用表示」を回答に義務付けること（ユーザーが出典を確認できる）と、定期的な回答精度の評価サイクルを設けることだ。完璧を求めるより、「劣化を素早く検知する仕組み」を整えることの方が実践的だ。
まとめ
- RAGを導入した企業の72%が1年以内に実用化を断念している
- 失敗の根本原因は「技術の問題」ではなく「データ品質とガバナンスの欠如」
- 本番稼働に到達した企業（Morgan Stanley、Glean）は、技術よりも知識管理のプロセスに投資している
- 最初のステップは大規模実装ではなく、スコープを絞った小さな成功体験の積み重ね
- Agentic RAGとマルチモーダルRAGは次のフロンティアだが、基盤となるデータ整備なしには機能しない
RAGの本質は「AIを賢くする技術」ではない。企業の知識を「検索可能な状態に整備することを強制する仕組み」だ。この整備を経ずに技術だけ導入した企業が、72%の失敗側に入る。逆に言えば、知識管理の整備さえできれば、残り28%の本番稼働企業に入れる。
Lat91では、AIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
「自社のドキュメントをRAGで活用したいが、何から始めればいいかわからない」という方は、まずは無料相談からお気軽にどうぞ。