RAGとは？社内ナレッジをAIに活用させる仕組みと導入の現実
ChatGPTを社内で試した多くの企業が、最初に同じ壁にぶつかる。「自社の製品仕様を聞いても答えられない」「先週改訂した就業規則を知らない」。このギャップを埋める技術がRAG（Retrieval-Augmented Generation、検索拡張生成）だ。しかし「RAGを入れれば解決する」と期待して失敗した企業は少なくない。エンタープライズRAG実装の72%が初年度に失敗するか期待を大幅に下回るという調査もある（ragaboutit.com）。本記事ではRAGの仕組みから、失敗の構造、中小企業が実際に始める方法まで、実践者の視点で整理する。
RAGを3行で理解する
RAGを一言で言えば、「AIが回答する前に、関連するドキュメントを検索し、それを文脈として読んでから回答する」仕組みだ。
普通のAI（ファインチューニングなし）は、学習データを「記憶」として持っている。その記憶は学習完了時点で固定されていて、自社の最新マニュアルや先週の会議議事録は含まれていない。ChatGPTに「うちの製品スペックを教えて」と聞いて答えられないのは当然で、あなたの製品情報は学習データに存在しないからだ。
RAGはこの問題を別のアプローチで解く。回答する前に「今手元にあるドキュメント」を高速で検索し、それをAIに読ませてから答えさせる。図書館で資料を調べてから回答する司書、そのイメージに近い。
AIが「知らない」状態を正確に理解する
一般的なLLMの知識には2つの限界がある。第一に知識のカットオフ。モデルには学習終了日があり、それ以降の情報を知らない。第二に非公開情報へのアクセス不能。社内規定、顧客情報、独自の業務マニュアルはインターネットに公開されていないため、AIは最初から知る手段がない。
ファインチューニング（追加学習）でこの問題を解決しようとする企業もある。だが、コストが高く（数百万円〜）、情報を更新するたびに再学習が必要になる。RAGはこの問題を、もっとシンプルな構造で解く。
RAGの仕組み：検索から生成までの3フェーズ
図1: RAGの処理フロー。準備フェーズは一度だけ、質問への対応は毎回実行される。
RAGが動く仕組みは大きく3つで構成される。
インデックス化（準備フェーズ） 社内のドキュメントを細かな「チャンク」に分割し、それぞれを「エンベディング」と呼ばれる数値ベクトルに変換してベクトルDBに格納する。エンベディングとは、文章の意味を数値の配列で表したもので、「在庫管理の方法は？」と「倉庫の在庫確認手順」のように表現は異なるが意味的に近い文章を「近い数値」として扱える。
検索フェーズ ユーザーが質問すると、質問文もエンベディングに変換される。次にベクトルDBから意味的に近いチャンクを高速で取得する（類似度検索）。この処理は通常0.1秒以内で完了する。
生成フェーズ 取得した関連チャンク（3〜10件）をユーザーの質問と合わせてLLMに渡す。LLMは「渡された情報」を根拠に回答を生成する。
ここが核心的な点だ。RAGは「AIを賢くする」技術ではない。「AIが参照できる情報の範囲を広げる」技術だ。 この認識のズレが、導入後の期待外れを生む。
RAGが解決することと、解決しないこと
RAGには明確な得意・不得意がある。導入前にここを整理しておかないと、期待値と結果の間に大きなギャップが生まれる。
| RAGが解決すること | RAGが解決しないこと |
|---|---|
| 社内固有情報（マニュアル・FAQ・議事録）への対応 | 文書品質が低ければ、回答品質も低い |
| 知識カットオフ問題（最新文書を常に参照） | AIの基礎的な推論能力は変わらない |
| 問い合わせ対応の一次自動化 | ハルシネーションを完全には排除できない |
| 根拠文書の提示（回答の信頼性向上） | 設計次第で情報漏洩リスクが生まれる |
特にハルシネーションについては注意が必要だ。2025年のGalileo調査によれば、RAGを導入した企業でも実環境クエリの10%以上でハルシネーションが発生し、法律・医療領域では20〜33%に達したという。RAGはハルシネーションを「減らす」技術ではあっても、「なくす」技術ではない。
72%が初年度に失敗する現実
ragaboutit.comの分析によれば、エンタープライズRAG実装の72%が初年度に失敗するか期待を大幅に下回る。本番環境に到達するのは15%以下で、実測のROIが出るのは10〜20%にすぎない。
なぜこれほど失敗するのか。4つの主要パターンを順に見ていく。
失敗パターン1: データ品質問題（最多）
古い情報、矛盾するバージョンの文書、管理されていないファイルが混在すると、RAGはそれを根拠に誤回答を自信満々に生成する。Atlanの調査では、ガバナンスが整ったデータではRAGの検索精度が85〜92%だったのに対し、未整備のデータでは45〜60%まで落ちた。
図2: データ品質によって検索精度は最大40ポイント以上変わる。差を生むのはAIの性能ではなくデータ管理の質だ。
この差を生んでいるのは、AIの性能ではなくデータ管理の質だ。
失敗パターン2: チャンクサイズの設計ミス
文書を分割する「チャンクサイズ」の設計を軽視すると、精度が劇的に落ちる。2025年の研究では、固定長のチャンク分割では検索精度が13%だったのに対し、文章の意味的な区切りを考慮した適応型チャンクでは87%を達成した（Towards AI）。チャンクの境界で文脈が断ち切られると、正しい文書を取得しても正しい答えが返らない。
失敗パターン3: サイレントハルシネーション
RAGを入れると「根拠のある回答」が返ってくる。だが、その根拠文書が古い情報や低品質なドキュメントだった場合、誤回答は確信を持って返ってくる。しかもエラーシグナルが出ないため、週〜月単位で誰にも気づかれずに使われ続けることがある。これをサイレントハルシネーションと呼ぶ研究者もいる。
失敗パターン4: 全社一括のナレッジベース
全社のドキュメントを1つのベクトルDBに入れると、HR情報、技術仕様、法務契約が混在する「セマンティックノイズ」が発生する。無関係なチャンクが回答に混入するだけでなく、アクセス権限の制御が困難になり、情報漏洩リスクが生まれる。
日本の中小企業事例：問い合わせ70%削減の現実
日本の製造業（従業員50名規模）の事例がある。FAQ・就業規則・業務マニュアル・議事録をRAGでインデックス化し、Slack連携で社内問い合わせに自動一次回答するシステムを構築した。
成果は明確だった。月間問い合わせ件数が50件から15件に（70%削減）、人的対応工数が月20時間削減された。
だが、うまくいかなかった部分も二つある。一つ目は古い規則文書の混在問題だ。改訂前の就業規則が残っていたため、RAGが古いルールを根拠に誤回答を返した。ファイル名への日付管理とアーカイブ化で解決した。二つ目は機密文書の全社公開問題。役員向け資料がナレッジベースに含まれていたため、一般社員が閲覧できる回答に機密情報が含まれた。ナレッジベースを全社公開・部署別・機密の3階層に分離して対処した（出典: DXKing）。
この事例が示すのは、RAGの導入は「技術の問題」ではなく「情報管理の問題」だということだ。RAGは社内の情報整備レベルをそのまま可視化する鏡になる。
大規模事例が教える成功の構造
規模は違うが、Morgan Stanleyの事例は参考になる。同社は1.6万人のファイナンシャルアドバイザーのために、10万件の投資戦略・市場調査・アナリストレポートをRAGでインデックス化した（GPT-4使用）。結果、ドキュメント検索効率は20%から80%に向上し、アドバイザーの98%が日常的に使うシステムになった（出典: ZenML / OpenAI Case Study）。
この成功の裏には「金融文書という高品質・高構造化されたデータ」がある。法的・コンプライアンス要件で整理されていた文書群を使ったからこそ、初期から高精度が出た。
中小企業がこの事例から学べることは一つだ。「まず情報を整理してからRAGを入れる」。この順番を守ること。
中小企業がRAGを始める3ステップ
Lat91では社内業務を自動化する10体のAIエージェントチームを構築・運用しているが、社内ナレッジ活用で最も時間を費やしたのは技術選定ではなく「どのドキュメントを入れるか」の設計だった。
Step 1: 文書の棚卸し（技術より先に）
最初にすべきことはツール選定ではない。どの文書をナレッジベースに入れるかの設計だ。
- 頻繁に更新される文書（就業規則、料金表、商品スペック）の更新責任者は誰か
- 古い文書を識別するルール（ファイル名に日付を入れる等）は存在するか
- 全員が見ていい情報と、部署限定・機密にすべき情報の区分けはできているか
この棚卸しを省くと、前述した4つの失敗パターンにほぼ確実に陥る。
Step 2: ツール選定（中小企業向け3択）
技術知識が限定的な中小企業には、まず3つの選択肢を検討することを勧める。
- Dify（ディファイ）: セルフホスト版は完全無料。GUIでRAGパイプラインを構築できる。DockerがインストールできるPCかVPSがあれば始められる。インフラコストはVPS代（月1,000〜3,000円程度）とLLM APIコストのみ。日本語UIにも対応している。
- Flowise: 完全オープンソース。LangChainベースのノーコードツールで、ドラッグ&ドロップでRAGパイプラインを視覚的に構築できる。
- n8n + Dify連携: 既存の業務フロー（Slack、メール、CRM等）と連携させたい場合に有効。n8nで全社ワークフローとRAGを統合できる。
ベクトルDBについては、小〜中規模（数千ドキュメントまで）ならChromaのローカル版が完全無料で使える。エンベディング生成のAPIコストは、OpenAI text-embedding-3-smallで100万トークンあたり0.02ドルと現実的な範囲だ。
Step 3: 1部署・1ユースケースから始める
最初から全社展開はリスクが高い。1つの部署、1つのユースケースに絞って3ヶ月のパイロットを回す。始めやすいテーマとして、人事部のよくある質問（有給申請方法、交通費精算手順）、製品の技術FAQへの自動回答、過去の提案書・議事録の検索、の3つを挙げておく。
3ヶ月のパイロットで精度・工数削減・コストを測定し、全社展開の判断材料にする。
よくある疑問と反論
「RAGは大企業向けでは？」 かつてはそうだった。しかし2024〜2025年にかけてDify、Flowise、n8nなどのオープンソースツールが成熟し、技術的なハードルが大幅に下がった。従業員50名以下の企業でも、月数千円のインフラコストで本番稼働しているケースが国内外で増えている。
「ChatGPTのカスタムGPTがあればRAGは不要では？」 用途によっては正しい。ただしカスタムGPTにはファイルのアップロード上限や検索精度の限界がある。自社システム（CRM、Slack、基幹系など）と連携したい場合や、数万件以上のドキュメントを扱う場合は、独自のRAG構築が適切になる。
「まず試してみたいが何から始めればいいか？」 まず社内で最も問い合わせが多い30〜50件のFAQをWord or Notionに書き出す。それをDifyに入れて社内テスト版を作る。これを2週間でできれば、RAGの基礎的な感触はつかめる。
まとめ
- RAGはAIを賢くする技術ではなく、参照できる情報の範囲を広げる技術だ。 ドキュメントの品質がそのまま回答の品質になる。
- 72%が初年度に失敗する主因は技術ではなくデータ管理にある。 チャンクサイズの設計、アクセス権限の設計、文書の鮮度管理が成否を分ける。
- 中小企業でも始められる環境は整っている。 Difyのセルフホスト版（無料）とLLM APIを組み合わせれば、月数千円のインフラコストで動く。ただし、最初に文書の棚卸しをしてから技術に入ること。
「まず社内情報を整理してから、RAGを入れる」。この順番さえ守れば、問い合わせ対応の大幅な削減は現実的なゴールだ。生成AIを社内で使いこなすための前提として、ナレッジ管理の見直しを今から始めることを勧める。
なお、生成AIを社内定着させるための組織面での課題については、ChatGPTを社内で使わせるな — 生成AIが定着しない3つの理由で詳しく解説している。
Lat91では、AIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
「自社でもRAGやAIエージェントを活用したいが、何から始めればいいかわからない」という方は、まずは無料相談からお気軽にどうぞ。御社の業務フローとドキュメント管理の状況をヒアリングしたうえで、現実的な第一歩をご提案します。