RAG（検索拡張生成）を導入したのに、「関係ない文書を引いてくる」「社内に確かにある情報が見つからない」「以前は答えられたのに最近ずれてきた」——こうした状態に心当たりはないでしょうか。RAGの回答品質は、LLMの賢さより先に、参照すべき文書を正しく引けているか（検索＝Retrieval）で決まります。なお、渡すデータそのものの品質が精度を左右する話はAIが間違った答えを出す原因は「データ品質」にあるで解説しているため、本記事は「データはある。なのに検索が当たらない」という一歩先の論点に絞ります。原因を5つに分けて、改善の打ち手まで整理します。
目次
RAGで的外れな回答が出るとき、原因の多くは生成側ではなく検索側にあります。 RAGは、質問に関連する文書を社内データから探し（検索）、それを材料としてLLMに渡して回答を作らせる（生成）仕組みです。つまり、材料として渡された文書が的外れなら、どんな高性能モデルでも正しい答えは作れません。逆に、正しい文書が渡っていれば、標準的なモデルでも十分な回答になります。だから改善の第一歩は、モデルを替えることではなく「どの文書が渡っているか」を確認することです。ここを見ないまま設定をいじっても、精度は安定しません。
改善のスタート地点は、回答そのものではなく、その回答の材料として何が検索されたのかを確認することです。多くのRAG基盤では、参照した文書やチャンクを確認できます。的外れな回答が出たとき、そもそも関係ない文書が渡っていたのか、正しい文書は渡っていたのに生成でずれたのかで、打ち手はまったく変わります。前者なら検索の改善、後者ならプロンプトや指示の改善です。原因の切り分けをせずに手を打つと、時間を無駄にします。
RAGでは文書を「チャンク」という単位に分割して検索します。この分割が粗すぎても細かすぎても、検索は当たりません。粗すぎると、1つのチャンクに複数の話題が混ざり、質問との関連度が薄まります。細かすぎると、前提や主語が切り離され、意味が通らない断片になります。とくに社内規程やマニュアルは、章・節の構造を無視して機械的に文字数で切ると、条件と結論が別のチャンクに分かれてしまいがちです。「〜の場合は」という条件だけのチャンクと、「〜とする」という結論だけのチャンクに割れてしまえば、どちらを引いても質問には答えられません。分割は前処理のごく一部の工程に見えますが、検索精度への影響は非常に大きい部分です。
文字数で機械的に切るのではなく、見出しや箇条書きといった文書の構造を手がかりに、意味のまとまりで分割します。あわせて、前後のチャンクを少し重ねる（オーバーラップ）と、境界で文脈が切れる問題を緩和できます。分割前に、見出し構造が壊れていないか、不要なヘッダー・フッターが混ざっていないかを整えることも効果的です。この「分割前の整形」は地味ですが、検索精度に直結します。ページ番号や社名フッターが各チャンクに混ざると、それらがノイズとして関連度計算に影響してしまうためです。取り込みの時点で不要な要素を落としておけば、以降の工程がずっと楽になります。
社内文書は正式名称や略語で書かれているのに、利用者は日常の呼び方で質問します。たとえば文書では「就業規則第12条」なのに、質問は「有休って何日もらえる？」という具合です。この語彙のズレがあると、検索は一致する箇所を見つけられません。とくに社内用語、製品コード、部署の通称、業界特有の略語が絡む場面で頻発します。人間なら文脈で補える差が、検索では致命的な取りこぼしになります。「経理部」と「経理課」、「PJ」と「プロジェクト」のような揺れも同じで、社内で当たり前に使い分けている表現ほど、システムから見ると別語として扱われます。まずは、うまく答えられなかった質問と、実際の文書の表現を並べて比べてみるとよいでしょう。
用語の対応表（同義語辞書）を用意し、質問側または文書側で表記をそろえます。文書に「別名」「関連キーワード」をメタ情報として付けておくのも有効です。あわせて、キーワード一致とベクトル検索（意味の近さ）を併用すると、表記が違っても意味で拾えるようになります。社内用語の多い企業ほど、この橋渡しの効果は大きく表れます。辞書はいきなり網羅を目指さず、実際に外した質問から順に足していくのが続けやすい方法です。運用しながら育てる前提で始めると、負担なく精度を積み上げられます。
対象文書が増えると、意味が似た文書が大量に候補に入り、肝心の文書が埋もれます。「最新版ではなく古い版を引いてきた」「他部門の類似規程を拾った」といった事象は、この典型です。文書の種類・部門・年度・有効/失効といったメタデータで絞り込めないと、検索は広い海から当てもの探しをすることになります。文書数が増えるほど、この問題は深刻になります。数十件なら埋もれなかったものが、数千件になると「似ているが正しくない文書」が上位を占めるようになるためです。PoCではうまくいったのに全社データを入れた途端に精度が落ちる、という失敗の典型的な原因でもあります。
文書に部門・文書種別・作成日・版・有効期限などのメタデータを付与し、検索時に絞り込めるようにします。「最新版のみ」「自部門のみ」といった条件を効かせるだけで、精度は大きく改善します。メタデータは手作業で付けると運用が続かないため、元システムの属性情報を自動的に引き継ぐ形にするのが現実的です。ここは連携の設計で解決できる部分です。文書管理システムやファイルサーバーが持っているフォルダ構成・更新日・作成部署といった情報を、そのまま検索用のメタデータへ引き継げれば、追加の入力作業なしに絞り込みが効くようになります。
料金表や仕様一覧のように、意味が「表の構造」に宿っている文書は、テキスト抽出でセルの対応関係が崩れると、内容が別物になります。PDFの段組みが混線して文が入り交じる、スキャン文書が画像のままでテキストがない、といったケースも同様です。この状態では、そもそも検索対象として正しく読めていないため、当たるはずがありません。「あるのに見つからない」の裏には、この読み取り崩れが潜んでいることが多くあります。とくに帳票や仕様書のように、罫線で意味を表している文書は要注意です。取り込んだテキストを一度目で見て、人が読んで意味が通るかを確かめるだけでも、多くの問題に気づけます。
表は行・列の対応を保った形（構造化データ）で取り込み、可能なら要点を文章として補記します。画像やスキャン文書はAI-OCRなどでテキスト化してから検索対象にします。取り込みの段階で構造を保てるかどうかが、後段の検索精度を決めます。ここは前処理の作り込みが効く領域で、非構造化データの活用の考え方が役立ちます。表を行単位のデータとして扱えるようにしておけば、「この製品の料金は」という質問にも、該当行を正確に引いて答えられるようになります。
「以前は正しかったのに、最近ずれてきた」という劣化は、元文書が更新されているのに検索用のインデックスが作り直されていない、というパターンが典型です。改訂された規程の旧版が残っていれば、検索は堂々と古い方を引いてきます。RAGは一度作れば終わりではなく、元データの変化に追従し続ける必要があります。運用に入ってからの精度維持は、この追従の仕組みで決まります。とくに規程やマニュアルは改訂が積み重なるため、公開直後は良好でも、半年後には旧版まみれになっていることも珍しくありません。「作ったあと誰が更新するのか」を決めずに始めると、この劣化はほぼ確実に起こります。
元文書の追加・改訂・廃止を検知して、インデックスを自動で更新する流れを作ります。旧版を確実に外す（論理削除やフラグ管理）ことも重要です。人手で棚卸しする運用は必ず抜けが出るため、データの流れとして仕組み化するのが現実的です。この更新の自動化が、RAGの精度を長期的に保つ生命線になります。全件を毎回作り直すのではなく、変更があった分だけを反映する差分の考え方にすると、処理時間もコストも抑えられます。
データ連携について詳しく学ぶ（無料ダウンロード）
データ連携基盤「ASTERIA Warp」（累計10,000社超）は、RAGの検索精度を左右する「取り込み前の整形」「メタデータ付与」「更新の自動反映」を、プログラミングなしで担えます。100種類以上のアダプターで基幹システム・SaaS・ファイルサーバー・DBから文書やデータを集め、表記の統一や不要部分の除去、元システムの属性をメタデータとして引き継ぐ処理を、画面上の設定で組み立てられます。更新分だけを定期的に反映する差分連携も設定でき、インデックスの鮮度を保てます。2026年8月25日提供開始予定の新版では、ファイルを生成AIに直接受け渡す生成AIアダプターの機能拡張（帳票のAI-OCR処理など）も予定されています。実際にアステリア自身が生成AI「Dify」やOpenAIと連携したAI回答システムを構築した事例があります。検索が当たるかどうかは、AIに渡す手前の工程で大きく変わります。
Q. RAGの回答がずれるとき、まず何を確認すべきですか？
A. 回答の材料として「どの文書・チャンクが検索されたか」です。関係ない文書が渡っていたなら検索側、正しい文書が渡っていたのにずれたなら生成側（指示）の問題で、打ち手が変わります。
Q. チャンクはどのくらいの大きさが適切ですか？
A. 一律の正解はありませんが、文字数で機械的に切るより、見出しや箇条書きといった文書構造の「意味のまとまり」で分けるのが基本です。境界で文脈が切れないよう、前後を少し重ねる（オーバーラップ）のも有効です。
Q. 社内用語や略語で検索が当たりません。どうすればよいですか？
A. 同義語の対応表を用意して質問側・文書側の表記をそろえるか、文書に別名をメタ情報として付与します。キーワード一致とベクトル検索を併用すると、表記が違っても意味で拾いやすくなります。
Q. 以前は正しかったのに最近ずれてきたのはなぜですか？
A. 元文書が更新されたのに検索用インデックスが更新されていない可能性が高いです。改訂前の旧版が残っていると、そちらを引いてしまいます。更新の検知と再インデックス、旧版の除外を自動化しましょう。
RAGで検索が当たらない原因は、チャンク分割の粒度、質問と文書の語彙ズレ、メタデータ・絞り込みの設計不足、表やPDFのレイアウト崩れ、更新反映の漏れという5つに整理できます。いずれもモデルを替えて解決する問題ではなく、AIに渡す手前の工程（取り込み・整形・メタデータ・更新）の設計で改善できます。まずは「何が検索されたか」を確認し、原因を切り分けましょう。取り込みと更新を自動化する土台づくりから始めるなら、データ連携基盤「ASTERIA Warp」が選択肢になります。
▼ ノーコードのデータ連携を、まずは触って確かめる ASTERIA Warpは全機能を試せる無料体験版をご用意。RAG向けのデータ取り込みや更新の自動化も、サーバー準備不要ですぐに体験できます。 |
PM・SE・マーケティングなど多彩なバックグラウンドを持つ「データ連携」のプロフェッショナルが、専門領域を超えたチームワークで「データ活用」や「業務の自動化・効率化」をテーマにノウハウやWarp活用法などのお役立ち情報を発信していきます。
ASTERIA Warp製品の技術情報やTips、また情報交換の場として「ADNフォーラム」をご用意しています。
アステリア製品デベロッパー同士をつなげ、技術情報の共有やちょっとしたの疑問解決の場とすることを目的としたコミュニティです。
