「社内の議事録や規定をRAGに入れれば、AIが何でも答えてくれる」——そう考えて導入したが、実際には的外れな回答が続き、半年で使われなくなった。このパターンに陥っている企業が思いのほか多い。
Gartner（2025年調査）によれば、RAGを導入した企業のうち「期待通りの精度が出た」と回答したのは37%にとどまる。残りの63%は「検索精度が低い」「ハルシネーションが減らない」「維持コストが予想より高い」という理由で評価を下げている。
問題はRAGという技術にあるのではない。「何を入れるか・どう管理するか」という設計思想が抜け落ちているのだ。この記事では、Lat91が自社のAIエージェントシステム構築で直面した壁と、機能するRAGを設計する3原則を共有する。
RAGとは何か（非エンジニア向けに1分で）
RAGはRetrieval-Augmented Generation（検索拡張生成）の略だ。簡単に言えば、「ChatGPTなどのAIが回答する前に、あなたの社内ドキュメントを検索して、関連情報を見つけてから答える」仕組みを指す。
AIそのものの知識は学習データで固定されているが、RAGを使えばAIが最新の社内資料を参照できるようになる。「先月改訂した就業規則を踏まえて、残業申請の手順を教えて」といったことが可能になる。
ファインチューニング（AIに特定の知識を学習させること）との違いは大きく2点ある。ファインチューニングは「AIの思考パターン」を変えるのに対し、RAGは「回答前に参照する情報」を変える。更新が必要な情報（社内規定、マニュアル、議事録）にはRAGが向いており、コスト面でも大きな差がある。
図1: RAGの動作フロー — 質問→検索→取得→回答の4ステップ
ただし、この「参照する情報」の設計こそが、成否を分ける核心だ。
なぜ63%のRAGは期待外れで終わるのか
理由1: 全社ドキュメントを無差別に投入する
最も多い失敗パターンだ。「とりあえず全部入れれば使えるはずだ」という発想で、5年前の会議メモ、廃止された旧規定、部署ごとにバラバラな書式の報告書を一括投入する。
AIの検索モデル（埋め込みモデルと呼ばれる）は、意味的な類似度でドキュメントを検索する。ノイズ——つまり関連性の低い情報——が多いほど、精度は下がる。10万件のドキュメントから正確な回答を引き出すより、1,000件に絞った精選コーパスから引き出す方が、はるかに高精度になる場合がほとんどだ。
米国の金融大手Morgan Stanleyもこの罠に陥った。2023年に10万件超の調査レポートを一括投入したところ精度が低下し、3か月後に「ファイナンシャルアドバイザーが実際に参照するドキュメント」だけに絞り込んだ。その結果、回答速度は従来比5倍、担当者の業務準備時間は週4時間削減されたという（Wall Street Journal, 2024年1月）。「入れる量を増やす」より「入れるものを絞る」——これが第一の原則だ。
理由2: 情報の鮮度管理を設計しない
RAGは「入れたら終わり」ではない。社内規定が改訂されたとき、古い版と新しい版が両方コーパスに入っていたら、どちらが参照されるかわからない。最悪、廃止されたルールをAIが自信満々に答えることになる。
Lat91で自社のAIエージェントチームを構築した際、まさにこの問題に直面した。複数のエージェントに参照させるナレッジベースを作ったのだが、週次で情報を更新するプロセスを設計しなかった結果、1か月後には古い戦略メモを参照したエージェントが時代遅れな判断をするようになった。
情報の「賞味期限」は文書の種類によって異なる。法的文書・規定は改訂のたびに即時更新、業務マニュアルは月次、業界動向レポートは四半期ごとの見直しが目安だ。RAGには「更新の仕組み」が必ず必要だ。
理由3: チャンク設計を軽視する
RAGはドキュメントを小さな断片（チャンク）に分割し、それぞれをベクトル（数値）に変換して保存する。このチャンクの切り方が精度を大きく左右する。
日本語の場合、英語より難しい問題がある。英語は単語が空白で区切られているため、意味の境界を機械的に判断しやすい。日本語は形態素解析が必要で、敬体（です・ます）と常体（だ・である）が混在する文書では、同じ意味の文がベクトル空間上で大きく離れる場合がある。
よくある失敗は、文字数だけで機械的に切ることだ。「1チャンク300文字」と設定すると、文章の途中で切れた断片が検索され、文脈のない半端な情報が回答に使われる。適切なチャンク設計は「意味のまとまり」を単位とする必要がある。
図2: チャンク設計の良悪比較 — 意味の切れ目でなく文字数で切ると文脈が断絶する
海外の先進企業は何が違うのか
フィンテック企業Klarna（スウェーデン）は2024年にカスタマーサポートへのRAG組み込みで65%の自動解決率を達成した。方法は意外とシンプルで、RAGの対象を「FAQ文書約200件のみ」に限定した。社内の全マニュアルや議事録は入れていない。そして、2名の専任スタッフがFAQを常時更新する体制を整えた。
「小さく、精選して、管理する」——これがKlarnaのアプローチだ。AIの賢さより、入れる情報の質と鮮度で勝負した。
米国のNotionもRAGでユーザーのワークスペースを検索する機能を提供しているが、興味深い知見を公開している。「ユーザーが整理されていないメモをワークスペースに大量保存していると、AI検索の精度が下がる」という問題だ。高性能なAIモデルも、ノイズだらけのデータの上では機能しない。
日本でRAGが難しいもう一つの理由は、情報の分散だ。欧米企業ではドキュメントがNotion・Google Docs等に比較的集約されているケースが多い。日本企業ではメール、Word、Excel、紙のスキャン、チャットと情報が分散し、統一されたナレッジ管理の文化が薄い。RAGを導入する前に「情報の整理」が必要になる場合が多く、これが導入コストを押し上げる。
機能するRAGを設計する3原則
原則1: ユースケースから逆算してドキュメントを絞る
最初に問うべきは「RAGを使って何ができるようにしたいか」だ。「社内規定の問い合わせ対応」ならHR関連文書だけ。「営業資料の提案内容確認」なら製品仕様書と提案書だけ。最初のコーパスは50〜200文書の規模で始めることを推奨する。精度が確認できてから拡張する。全社展開を先に決めてはいけない。
原則2: 更新プロセスを設計してから本番導入する
「誰が・いつ・どの情報を更新するか」を明確にしないまま本番運用に入ると、3か月後には鮮度の低いゴミ情報の塊になる。更新担当者・更新頻度・廃止文書の削除ルールを最初に設計する。これは技術の問題ではなく、運用設計の問題だ。
原則3: 回答の根拠（引用元）を必ず表示させる
RAGの最大のリスクは「もっともらしいが間違っている回答」を自信満々に返すことだ。実務での対策は、RAGシステムに「参照したドキュメントと該当箇所」を必ず回答に添付させることだ。ユーザーが一次ソースを確認できれば、AIへの過信を防げる。これはシステムの実装要件として最初から設計に組み込む必要がある。
よくある疑問への回答
「ファインチューニングの方が精度が高いのでは？」
用途が違う。ファインチューニングは「AIの回答スタイルや思考パターン」を変えるもので、「うちの会社の文体で回答させたい」ときに有効だ。最新の社内情報を参照させたいだけなら、RAGの方が低コストで更新も容易だ。ただし、両者を組み合わせる企業も増えている。
「ChatGPTのMyGPTやCopilot for M365で十分では？」
既製品ツールは導入が手軽だが、社内の既存システムとの連携・セキュリティ要件・カスタマイズの自由度が制約される場合が多い。機密性の高い情報を社外サービスに送ることへの法務チェックも必要だ。自社でRAGを構築する場合と既製品を使う場合、どちらが最適かは業種・規模・セキュリティ要件によって異なる。
「中小企業には過剰な技術では？」
議事録・規定・マニュアルが50文書以上あり、毎月それらへの問い合わせで担当者の時間が取られているなら、ROIは出始める。2025年以降、Dify・LangChain・Bedrock Knowledge Basesなど、ローコードでRAGを構築できるツールが充実しており、技術的ハードルは大幅に下がっている。
2026年: RAGはどこへ向かうのか
現在のRAGはテキストが中心だが、2026〜2027年に向けて3つの進化が起きている。
マルチモーダルRAG: テキストだけでなく、図表・画像・動画も検索対象に加わる。製造業なら図面、医療機関ならレントゲン画像を参照した回答が可能になる。
GraphRAG: 文書間の「関係性」をグラフ構造で表現し、複数の情報を組み合わせた複雑な質問に対応する。Microsoftが2024年にオープンソース化したGraphRAGがエンタープライズ領域で注目されている。
Agentic RAG: AIエージェントが自律的に「どの情報が必要か」を判断し、必要なドキュメントを取得・組み合わせる。人間がクエリを考えなくても、エージェントがナレッジベースを自在に活用する世界だ。
IDCの予測では、RAG関連ツール市場は2026年に12億ドル、2028年には42億ドルに達する見込みだ（IDC Worldwide AI Market Forecast, 2025）。この市場成長が示すのは、企業のAI導入が「モデルを使う」段階から「自社情報をAIで活用する」段階に移行しつつあることだ。
まとめ
RAGが期待外れで終わる会社に共通するのは、「入れれば使える」という思い込みだ。機能するRAGを作る3つの原則は以下の通りだ。
- 絞る: 全ドキュメントではなく、具体的なユースケースに必要な文書だけ入れる
- 管理する: 更新プロセスと廃止ルールを運用の一部として設計する
- 根拠を示す: 引用元を表示させ、ユーザーが確認できる設計にする
技術的なセットアップより、これらの設計判断の方が精度に与える影響は大きい。RAGは「導入したら完成」ではなく「運用して育てるもの」だ。その前提で設計に入ると、期待値のコントロールも正しくできる。
Lat91では、RAGを含むAIエージェントの設計・導入から運用まで、一気通貫でサポートしています。
「自社の情報をうまくAIに使わせたい」「RAGを試してみたいが何から始めればいいか」という方は、まずは無料相談からお気軽にどうぞ。社内の情報構造を整理するところから、一緒に考えます。