RAGとは：中小企業が社内データをAIに使わせる現実的な方法
「社内の資料をAIに食わせれば、何でも答えてくれるようになる」。そう思って検討を始めた経営者は多い。契約書、マニュアル、議事録、商談履歴。10年分のデータが眠っているのに、AIは一切それを知らない。この矛盾を解消する技術がRAG（Retrieval-Augmented Generation、検索拡張生成）だ。
ただし、現実はそう単純ではない。エンタープライズ向けRAGプロジェクトの70〜85%が、本番稼働に至る前に頓挫している（Analytics Vidhya, 2025年）。そして失敗の原因のほとんどは、AIモデルの性能ではない。
この記事では、RAGの仕組みと実際のコスト、日本企業の現状、そして中小企業が現実的に始めるためのステップを解説する。技術的な詳細より、どう判断するかに焦点を当てた。
RAGとは何か — 仕組みと本質
RAGは検索と生成を組み合わせた技術だ。名前から難しそうに聞こえるが、動作原理はシンプルに説明できる。
通常のChatGPTやClaudeに質問すると、モデルは学習データ（主に2023〜2024年までのインターネット情報）を基に回答を生成する。当然、自社の社内データは学習していないため、「弊社の与信審査プロセスはどうなっていますか？」と聞いても答えられない。
RAGはこの問題を次の手順で解決する。
まず、社内文書を細かいチャンク（塊）に分割し、それぞれを数値ベクトルに変換してデータベースに保存する。これがインデックス作成のフェーズだ。次に、ユーザーが質問を入力すると、その質問も同様にベクトルに変換され、類似度の高い文書チャンクを高速に検索する。最後に、検索で見つかったチャンクをAIのプロンプトに付加した状態で回答を生成させる。AIは追加で渡されたコンテキストを参照しながら答えを作る。
図1: RAGの処理フロー。事前準備（文書のインデックス作成）と実行時（検索+生成）の2フェーズで構成される
この仕組みの核心はモデルを変えないという点にある。高価なファインチューニング（モデルの重みを書き換える訓練）なしに、外部の知識を活用できる。知識ベースは随時更新でき、モデルの再学習は必要ない。
ただし、ここに重大な誤解が潜んでいる。多くの経営者は文書を入れれば終わりと思っているが、実際にはそこからが本番だ。
70〜85%が頓挫する理由：AIの問題ではなかった
エンタープライズRAGプロジェクトの失敗率は70〜85%という数字は、過小評価ではない。DEV Communityが2025年にまとめた分析と、Analytics Vidyaの調査が同じ水準を指し示している。
問題の所在を正確に把握するために、失敗パターンを分解してみる。
最も頻繁な失敗1：プロトタイプと本番データの乖離
テスト環境では整備された文書を使い、精度95%以上を達成する。ところが本番環境に移すと精度が78%以下に落ちる。現実の社内データは汚いからだ。
スキャンされたPDF、手書きのメモが混在するExcel、社員ごとにフォーマットが違う提案書。テストで使ったきれいなデータとは別物だ。Faktion社の分析によれば、本番データとテストデータのこの差が、失敗案件の最大の原因として一貫して挙げられている。
最も深刻な失敗2：データ準備コストの過小評価
RAGプロジェクトにかかるコストの30〜50%はデータ準備が占める（stratagem-systems.com調査）。ところがプロジェクト開始時の予算計画では、ベクトルデータベースの費用やAPIコストだけが見積もられ、人件費の大半を占めるデータ整備作業が抜け落ちる。
10年分の社内文書を読めるAIを作るためには、まず10年分の文書を整理・構造化する人間の作業が必要だ。ここで予算が2〜3倍にふくらむ案件が多い。
静かに起きる失敗3：情報の鮮度問題
ベクトル検索は意味的な類似度でランキングを決める。更新日時はデフォルトでは考慮しない。つまり、2年前に廃止された手順書が、最新の手順書より高スコアで返ってくることが起きる。この問題は、ログを見なければ検知できない。評価フレームワークを最初から組み込まなかったプロジェクトが、この種の問題で静かに死んでいく。
日本の現状：17.8%が示す遅れとチャンス
Digeon社が2025年12月に国内517社を対象に行った調査によれば、RAGを導入済みの企業は17.8%にとどまる。一方でFortune 500では同時期に67%が本番導入済みだ（Ailog RAG, 2026年）。
導入したいが未着手の企業は約35%存在する。この層が抱える課題のトップ2は活用場面の特定困難（29.1%）と技術人材不足（27.5%）だった。多くの企業がRAGの有効性を認識しながら、何から始めればよいかわからない段階で止まっている。
国内で先行する企業の事例を見ると、用途の共通点が見えてくる。トヨタシステムズは富士通と共同で、コアシステム更新業務に生成AIを活用し、作業時間を50%削減した（2025年1月本番稼働）。NTTデータは碧海信用金庫に、行内文書を参照するRAGシステムを導入し、1日約4,000件の問い合わせ処理を実現している。三菱UFJ銀行は2024年7月、社内業務向けの手順書検索支援システムを稼働させた。
共通点は用途の具体性だ。社内データ全般をAIで検索するという曖昧な定義ではなく、コアシステム更新業務、行内問い合わせ応答、手順書検索と、適用範囲を絞っている。
モルガン・スタンレーの事例から逆算する成功条件
RAGで最もよく引用される成功事例の一つが、モルガン・スタンレーの社内知識アシスタントだ（ZenML, Vectara）。
規模感を先に示す。16,000人のウェルス・マネジメント・アドバイザーが対象で、参照する文書は35万件超。GPT-4ベースのRAGシステムを、OpenAIとの提携で構築した。成果として語られる数字は、情報検索時間の30分以上から数秒への短縮だ。
しかし、この事例で最も注目すべき数字は別にある。アドバイザーの採用率98%。
AIシステムで98%の採用率は異常値に近い。多くの企業向けAIは、現場で使われずにプロジェクトが終わる。なぜモルガン・スタンレーはこの数字を達成できたのか。同社が公表している情報を分析すると、2つの要因が見えてくる。
一つは、文書が元々構造化されていたこと。金融機関のレポート・ガイドラインは標準フォーマットがある。データ整備が他業界より低コストで実現できた。もう一つは、用途が明確だったこと。アドバイザーが顧客提案を準備する際の情報取得という、日常業務に直結するユースケースに絞った。
翻って、頓挫する企業に多いパターンは社内データを全部入れれば何でもできるという設計だ。用途が曖昧なまま構築を始めると、誰のどんな問いに答えるべきかが定まらない。評価のしようもない。
RAG・ファインチューニング・プロンプトエンジニアリング、何が違うのか
社内AIの選択肢を整理するために、3つのアプローチの違いを把握しておく価値がある。
図2: 3アプローチの比較。社内データの活用にはRAGが最適だが、コストと用途を正確に把握した上で判断する
プロンプトエンジニアリングは最もシンプルだ。ChatGPTやClaudeに対して、指示の文章を工夫することで精度を高める。コストはほぼゼロで、今日から始められる。ただしコンテキストウィンドウ（一度に処理できる文字量）の制約がある。数十ページの文書なら入るが、数万ページは無理だ。
ファインチューニングはモデルの内部パラメータを書き換える学習だ。特定の文体や専門用語への適応、特定フォーマットの出力に向いている。ただし、事実情報を教え込む用途には向かない。自社製品の仕様を覚えさせたいというニーズにファインチューニングを使うと、ハルシネーション（事実と異なる回答の生成）が増えることが多い。事実はRAGで参照させる方が正確だ。
RAGは私的データや頻繁に更新されるデータに向いている。社内ドキュメント、契約書、製品マニュアル、議事録。これらをリアルタイムに検索して参照させる用途がRAGの本領だ。
実務的な判断基準はシンプルだ。答えに必要な情報がAIの学習データに含まれていないなら、RAGかプロンプトへの直接付加のどちらかを選ぶ。文書量が少なければプロンプトに入れる。大量ならRAGを構築する。
中小企業がRAGを始める現実的な3ステップ
予算数千万円を用意してシステムを構築することだけが選択肢ではない。小さく始めて、段階的に拡張する道がある。
ステップ1：まずノーコードで効果を確認する
Claude Projectsに社内文書を数十件アップロードして、試しに質問してみる。NotebookLMに議事録や資料を入れて、社内勉強会の準備をさせてみる。コストは無料または月数千円のサブスクリプション費用だけだ。
ここで確認するのは、社内の人間がこれを使うかどうかだ。技術的に動くことと、業務に使われることは別問題だ。現場担当者が毎日使いたいと思うユースケースを特定することが、本格導入の前提になる。
ステップ2：データの棚卸しから始める
どのデータをRAGに入れるかではなく、今の社内データが何でどこにあるかを先にマッピングする。
多くの中小企業では、重要な情報が担当者の個人PCのフォルダ、社内チャット、共有ドライブの奥に散在している。RAGはデータを整理してくれる魔法ではない。整理されたデータを検索可能にする技術だ。データの棚卸しと構造化なしに構築を始めると、前述したプロトタイプと本番のギャップがそのまま再現される。
ステップ3：スコープを最小に絞ってPoCを行う
全社導入を目指すのではなく、受注管理チームの問い合わせ対応や、営業担当が顧客に説明する製品仕様の質問など、明確に定義した一つの用途から始める。
3ヶ月のPoCで測定するのは3つでよい。利用率（現場は使っているか）、精度（答えは正しいか）、工数変化（何時間の作業が減ったか）。この3つが改善されていれば、次の用途に展開する根拠になる。
Lat91でも、10体のAIエージェントを構築・運用する過程で同じ問題に直面した。エージェントに社内情報を参照させるにあたり、全文書をベクトル化する前に、最もよく参照される情報が何かを徹底して絞り込む作業に時間をかけた。範囲を広げるのは、狭い範囲が機能した後でよい。この順序を逆にすると、データ整備の段階で頓挫する。
よくある反論に正面から答える
「うちの規模ではデータが少なすぎてRAGは使えないのでは？」
データ量が少ないこと自体は問題ではない。むしろ少ない方が構築・管理コストが下がる。問題は質だ。50件のきちんと整備された文書は、5,000件の雑多な文書より価値があることが多い。
ただし、一度に処理できるトークン数の範囲内に収まる文書量であれば、RAGを構築せずにプロンプトに直接貼り付ける方が早くて安い。RAGが必要かどうかの判断がまず重要になる。
「ROIがわからないと稟議が通らない」
340%というROIの平均値は本番稼働した企業の数字だ。頓挫した70〜85%は含まない。この数字を稟議に使うのは適切ではない。
現実的な投資判断は、どの業務がどれだけの時間を使っているかから逆算する。営業担当が社内情報を探すために週5時間使っているなら、それが週1時間になったとき、何人月の工数削減になるか。この計算が可能なユースケースを最初に選ぶことが、ROIの見通しを立てるための前提だ。
「生成AIが社内の機密情報を学習してしまうのでは？」
RAGの場合、情報は学習されない。検索時に一時的にコンテキストとして渡されるだけで、モデルのパラメータには影響しない。ただし、クラウドAPIを使う場合、文書チャンクがAPIプロバイダーのサーバーに送信される点は事実だ。データ機密性が最優先の場合、オンプレミスのベクトルDBとローカルモデルの組み合わせを検討する必要がある。コストと精度のトレードオフは避けられない。
まとめ
- RAGは社内データをAIに検索させて回答に使わせる技術で、モデルの再学習なしに社内専用AIを実現できる
- 70〜85%のプロジェクトが本番稼働に至らない最大の原因は、AIの問題ではなくデータ整備という人間側の問題だ
- 日本企業の導入率は17.8%で海外に比べ大きく遅れているが、用途を絞り込むことで先行できる余地がある
- 中小企業が取るべき順序はノーコードで効果確認、データ棚卸し、スコープを絞ったPoCだ
- ファインチューニングは事実情報の付加には向かない。社内ドキュメントを参照させるならRAGが適切だ
RAGは社内データを入れれば解決する魔法の箱ではない。整理されたデータを検索可能にする技術だ。データを整理する作業は、AIではなく人間がやる必要がある。この認識から始める企業だけが、本番稼働まで到達できる。
Lat91では、AIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
RAGを導入すべきか、まず何から始めればいいか、という段階のご相談も承っています。自社の業務フローに合った現実的な選択肢を一緒に考えます。