資料に答えがあるのにAIが「見つかりません」と言う:RAGの検索漏れの原因切り分け
AIを使いこなすClaudeで執筆し、GPTで自動校閲・修正しています。

結論から言うと、原因は「正解の文章が、AIに渡るまでの道のりのどこかで消えている」ことがほとんどです。道のりは、取り込み、権限、分割、検索語、件数上限の順に並びます。最後に、渡されたのに答えない生成側の問題も加わります。 最短の切り分け方は、AIの回答文を眺めるのをやめることです。代わりに、答えが書いてある原文の一文を先に決めます。そして各段階で、その一文が生き残っているかを順に確認します。生き残っていない最初の段階が原因です。 この記事では、症状から原因を絞る診断フローと、段階別のチェックリスト、検索ログをAIに整理させる依頼文を示します。内容は2026年10月27日時点で確認した公式ドキュメントと、編集上の整理に基づいています。例に出す文書や数値は、すべて説明用の例です。実際に動かして得た結果ではありません。
最初に用意するもの:落ちる質問の「正解の一文」
調査を始める前に、次の3点を1セットにして、3〜5問分そろえます。
- 質問文(ユーザーが実際に打つ言い回しのまま)
- 答えが書いてある原文の一文(コピーしたもの)
- その文書名とページ、または見出し
説明用の例です。
- 質問、内容:出張のホテル代はいくらまで出ますか?
- 正解の一文、内容:宿泊費の上限は1泊12,000円(東京23区は15,000円)とする。
- 場所、内容:出張旅費規程.pdf 第4条
「答えが書いてあるはず」という記憶だけで調べ始めると、そもそも資料に無かった、という落ちになりがちです。正解の一文を先に固定すると、以降の確認がすべて「この一文は今どこにいるか」という問いになります。
診断フロー:症状から原因を絞る
上から順に、最初に「いいえ」になった段階が原因です。検索の確認は、AIの回答ではなく、検索結果そのもの(チャンク一覧)で行います。
Q1. 権限やフィルターを外した状態で、正解の一文の特徴的な語句で
キーワード検索すると、その一文を含むチャンクが見つかる?
└ いいえ → 【A 取り込み】
Q2. 質問者と同じ権限・同じフィルター条件で、同じ検索をしても見つかる?
└ いいえ → 【B 権限・フィルター】
Q3. 見つかったチャンクを読んで、答えが全部入っていて、
何の話か分かる?(表が崩れていない、条件が別チャンクに分かれていない)
└ いいえ → 【C 分割】
Q4. 質問文そのままで検索したとき、そのチャンクが上位に入る?
(まず絞り込み前の候補を多めに取って確認する)
└ いいえ → 【D 検索語・検索方式】
Q5. 入るが、最終的にAIへ渡す件数の外に出ていない?
└ 外に出ている → 【E 件数上限・順位】
Q6. チャンクは確かに渡されているのに「見つかりません」と答える?
└ はい → 【F 生成側】Q1とQ2を分けるのが肝心です。管理者として見つかるのに利用者として見つからないなら、検索の質ではなく権限の問題です。
段階別チェックリスト
A 取り込み:そもそも索引に入っているか
- [ ] 対象ファイルが取り込み対象のフォルダ・データソースに含まれている
- [ ] 取り込みが失敗やスキップになっていない(ログ・ステータスを確認)
- [ ] 取り込み後のテキストに、正解の一文が文字として存在する
- [ ] 画像だけのPDF、スキャン資料、図や表の中の文字が、テキストになっている
- [ ] 文書の更新後に再取り込みをした。古い版だけが索引に残っていない
OpenAIのファイル検索では、text/ MIMEタイプのファイルはUTF-8、UTF-16、ASCIIのいずれかのエンコーディングが必要と案内されています(OpenAI File search)。文字コードの異なる古いテキストが混ざっていないか、という観点で見られます。
画像を含む資料は、画像の説明文を作ってチャンク化する方法などが、Microsoftの設計ガイドで紹介されています(Chunking Phase)。取り込み後のテキストは、人の目で読んで確認します。
B 権限・フィルター:見えているのに見せていないか
- [ ] 管理者権限で見つかり、質問者の権限では見つからない、という差が再現する
- [ ] 文書に付けた権限情報(グループ名など)が空でない、または古くない
- [ ] 質問者のグループ情報が、検索時のフィルターに正しく渡っている
- [ ] 部署、年度、文書種別などのメタデータ絞り込みが、意図せず厳しくなっていない
Azure AI Searchのセキュリティフィルターの例では、文書側に権限を示す文字列のフィールドを持たせ、検索時にその値で絞り込みます。権限の文字列は、結果を含めるか除外するかの条件に使われるだけで、認証そのものではないとも説明されています(Security Filter Pattern、ページ内の記載日は2026年8月)。つまり、権限情報が文書に付いていない、または質問者の値が渡っていないと、正しい文書でも結果から外れます。
OpenAIのファイル検索にも、メタデータによるフィルターがあります。絞り込みは精度を上げる反面、条件が合わないと正解ごと消えます。
C 分割:答えがチャンクの中で壊れていないか
- [ ] 答えの文と、その条件(「東京23区は」など)が同じチャンクに入っている
- [ ] 表が行や列ごとにばらばらになっていない
- [ ] チャンクに、文書名や見出しなど「何の話か」を示す手がかりが付いている
- [ ] 分割サイズが小さすぎて文脈が切れていない(または大きすぎて話題が混ざっていない)
Microsoftのガイドは、小さすぎるチャンクは質問に答える文脈を欠きうること、関連する文脈が複数のチャンクにまたがると拾えない場合があることを指摘しています(Chunking Phase)。サイズと重なり(オーバーラップ)は文書の種類で最適値が変わるため、実際の分割結果を目で見て調整する方法が勧められています。
分割を変えたら、全文書の再取り込みが必要になる点に注意してください。ガイドも、分割方式の変更は後工程に大きく影響すると述べています。
D 検索語:質問と資料の言葉が合っているか
- [ ] 質問の言い回しと資料の用語がずれていない(例:ホテル代と宿泊費)
- [ ] 略語、旧名称、社内用語、型番などの固有の語が、意味検索だけで取りこぼされていない
- [ ] 資料側に前処理(小文字化など)をしたなら、質問側も同じ前処理をしている
- [ ] 質問の埋め込みに、資料と同じ埋め込みモデルを使っている
- [ ] 1つの質問に複数の論点が混ざっていないか、混ざるなら分けて検索している
Microsoftのガイドは、質問を埋め込む前に、チャンクと同じクリーニング処理をかけることと、同じ埋め込みモデルを使うことを求めています。また、意味検索(ベクトル)とキーワード検索を組み合わせるハイブリッド検索や、曖昧な質問の書き換え・補強も紹介しています(Information-Retrieval Phase、2026年6月更新と記載)。
固有名詞や型番に弱いと感じたら、まずキーワード検索を併用できるか確認します。意味検索一本の構成で起きがちな取りこぼしです。
E 件数上限・順位:正解が候補にいるのに渡されていない
- [ ] AIへ渡す件数(top-k、最大結果数)を確認した
- [ ] 正解チャンクの順位を、候補を多めに取って確認した(例:上位30件)
- [ ] 同じ文書の似たチャンクが上位を占めていない
- [ ] 並べ替え(リランク)を使う場合、その入力候補の件数が十分である
OpenAIのファイル検索では、検索結果の最大件数を絞るとトークン使用量と遅延を減らせる一方で、回答品質が下がる可能性があると説明されています。検索結果の中身は、リクエストの include に file_search_call.results を指定すると応答に含められます(OpenAI File search)。これで「何件、どのチャンクが渡ったか」を確認できます。
Microsoftのガイドは、候補を広めに取って再順位付けし、最後に上位N件へ絞る流れを例示しています。最終件数は、少なければコストと雑音が減り、多ければ関連情報を逃す可能性が下がるという関係です。候補は20〜50件から始めて評価指標に応じて調整する目安が示されています。これはガイド上の出発点で、自社の資料に当てはまる値ではありません。
F 生成側:渡されているのに答えない
Q5までで正解チャンクが渡されているなら、検索ではなく指示文の問題です。次を見ます。
- [ ] 「資料に無ければ『見つかりません』と答える」という指示が強すぎないか
- [ ] 渡したチャンクの量が多すぎて、肝心の文が埋もれていないか
- [ ] 正解チャンクの表記が崩れていて、読み取れないのではないか(Cに戻る)
症状別の判断表
- 新しく追加した文書だけ答えられない、疑う段階:A、最初の一手:取り込みログと索引内のテキストを確認
- 管理者の画面では答えるが、一般利用者だと答えない、疑う段階:B、最初の一手:同じ検索を管理者と利用者で比べる
- 条件つきの金額や例外だけ抜ける、疑う段階:C、最初の一手:条件文と本文が同じチャンクにあるか確認
- 表の数値だけ聞くと外れる、疑う段階:A・C、最初の一手:取り込み後の表がテキストで読めるか確認
- 言い換えると答える、元の言葉だと答えない、疑う段階:D、最初の一手:資料の用語と質問の語を並べて比べる
- 型番、略語、固有名詞に弱い、疑う段階:D、最初の一手:キーワード検索の併用を試す
- 上位を見ると正解は4位なのに、AIは知らない、疑う段階:E、最初の一手:渡す件数を一時的に増やして比べる
- チャンク一覧には正解があるのに回答は「ない」、疑う段階:F、最初の一手:指示文と渡し方を見直す
検索ログをAIに整理させる依頼文
ログの読み解きはAIに任せられますが、判定の根拠になるチャンク本文は人が読んで確かめてください。AIに渡す前に、社名、個人名、金額、顧客情報は、説明用のダミーに置き換えます。
次の依頼文は、そのまま使える雛形です(実際には未実行の例です)。
あなたはRAGの不具合調査の補助役です。
下の「調査メモ」だけを根拠に、検索漏れの原因が
取り込み/権限/分割/検索語/件数上限/生成のどれに当たるか、
可能性の高い順に最大3つ挙げてください。
出力形式:
1. 原因の候補(段階名)
2. そう考える根拠(メモのどの行か)
3. 追加で人が確認すべきこと(1つだけ)
メモに書かれていないことは推測せず、「不明」と書いてください。
【調査メモ】
質問:出張のホテル代はいくらまで出ますか?
正解の一文:宿泊費の上限は1泊12,000円(東京23区は15,000円)とする。
管理者権限でのキーワード検索:「宿泊費の上限」でヒットした
利用者権限での同じ検索:ヒットした
ヒットしたチャンクの内容:「…第4条 宿泊費の上限は1泊12,000円(」で終わり、
東京23区の例外は次のチャンクにある
質問そのままでの検索結果(上位10件):正解チャンクは7位
AIに渡している件数:5件このダミーのメモなら、AIが挙げる候補は「分割」と「件数上限」になるはずです。答えが2つのチャンクに割れていて、さらに7位が渡す件数の外にあるためです。ただしAIの回答は仮説です。実際のログで、どちらが主因かは、件数を増やす、またはチャンクの区切りを変えるなど、片方ずつ変えて比べて確かめます。
直した後の確認方法
直したら、落ちていた質問だけでなく、前は答えられていた質問も一緒に再確認します。分割や件数の変更は、他の質問の結果も変えるからです。
Microsoftのガイドは、検索の評価で想定質問を用意し、実データに対して検索方法を試して最適化することを勧めています。落ちる質問3〜5問と、答えの無い質問2〜3問を、毎回同じ表で回すと、変更の良し悪しを比べやすくなります。
出典・参考資料
- Develop a RAG Solution on Azure - Information-Retrieval Phase - Azure Architecture Center | Microsoft Learn(新しいタブで開く)
- Develop a RAG Solution on Azure - Chunking Phase - Azure Architecture Center | Microsoft Learn(新しいタブで開く)
- Security Filter Pattern - Azure AI Search | Microsoft Learn(新しいタブで開く)
- File search | OpenAI API(新しいタブで開く)

