AI・自動化

RAGは検索件数固定では失敗する：回答信頼度とAPI費用を同時に見る設計

2026年7月8日29分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

5分で自社の状況を診断する

GXO COLUMN

AI・自動化

先に結論

RAG（社内文書を検索してAIに答えさせる仕組み）を「毎回かならず上位◯件を引く」という固定設定で組むと、簡単な質問では検索とトークンの無駄が出て、難しい質問では根拠が足りないまま断定してしまいます。うまく設計されたRAGは、質問ごとに「どのくらい検索するか」「答えてよいか、保留するか」を回答信頼度とAPI費用で動かします。AB-RAGの研究（末尾参照）が指摘するのも、検索の量を質問の難しさに合わせて変える「適応的な検索予算」の考え方です。

社内検索・FAQ・カスタマーサポート（CS）自動化にRAGを入れる前に、次の3点を先に決めておくと、PoCで動いたものが本番でも壊れにくくなります。

信頼度のしきい値：根拠と回答が食い違うとき、AIに「わかりません」と言わせる基準。
検索予算の上限：1問あたり何回まで検索して、いくらまで使ってよいか。
回答不可のときの逃がし先：保留した質問を有人対応・追加検索・未回答ログのどこへ流すか。

RAG導入の要件整理やPoCの本番化を相談したい場合は、RAGの要件定義を発注前に整理するからご連絡ください。

AI ASSESSMENT

PoC の前に「そもそも使えるか」を30分で見極めませんか？

対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。

30分壁打ちを予約

この記事を読むべき会社

社内文書FAQ、問い合わせ一次対応、CS自動化にRAG・チャットボットを入れたい会社
ベクトル検索やLLMのAPI費用が「使うほど増える」構造で、予算が読めず不安な会社
PoCでは賢く答えたのに、本番で誤回答・根拠のない断定・「それらしい嘘」が出て止まっている会社
DX責任者、情シス、RAG/社内検索導入担当、CS責任者で、要件定義・費用・権限・ベンダー選定に不安がある会社

この記事の根拠と最新性

次に挙げる公式情報を2026年7月10日時点で確認して執筆しました。研究の数値・価格・ガイドラインの表現は、公開前に再確認する前提で扱います。出典の一覧は末尾の「参考・出典」にまとめています。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

なぜ「検索件数固定（top-k固定）」で失敗するのか

RAGはふつう、質問文をベクトル化して、社内文書の中から「近いチャンク（文書の断片）」を上位k件引き、それをLLMに渡して答えさせます。このkを一律の固定値（たとえば常に5件）にすることが、多くの現場でそのまま使われています。ここに2種類の失敗が同時に潜みます。

簡単な質問での無駄。「営業時間は？」「返品は何日以内？」のような一問一答は、正解が1つのチャンクに書いてあります。それでも毎回5件引けば、関係ない4件ぶんの検索とトークンが積み上がります。問い合わせが月に数万件あるCSでは、この「引きすぎ」がAPI費用の相当部分を占めます。しかも無関係なチャンクが混ざるほど、LLMがどれを根拠にすべきか迷い、かえって回答がぶれます。

難しい質問での根拠不足。「A規程とB規程が矛盾する場合はどちらが優先か」「昨年度の例外承認はどの条件で下りたか」のような質問は、複数の文書をまたいで初めて答えが組み立てられます。ところがk=5で足りなければ、AIは「手元の5件」だけで無理に答えを作ります。これがハルシネーション（もっともらしい嘘）の温床です。検索を増やせば答えられたはずの質問に、根拠不足のまま断定してしまう。

つまり固定kは、易しい側で「払いすぎ」、難しい側で「調べなさすぎ」という、費用と信頼性を両方悪くする設定です。正しい発想は、質問の難しさと今の手応え（信頼度）を見て、検索の量と答え方を変えることです。

RAGが「それっぽい嘘」を返す構造

「社内文書を参照させているのだから、嘘は出ないはず」という前提が、RAG導入でもっとも多い判断ミスです。LLMは「渡された文書から答えを探す」のではなく、「渡された文書らしきものと質問から、それらしい文章を生成する」仕組みです。参照が失敗しても、生成そのものは止まりません。誤回答が起きる経路は、大きく次の3つに分けて考えると対策が立ちます。

根拠が見つからないのに答えてしまう。検索で関連文書がヒットしなくても、LLMは「該当なし」とは言わず、学習済みの一般知識や近そうなチャンクをつなぎ合わせて回答を作ります。利用者から見ると、社内規程を参照した公式回答のように見えるため、間違いに気づきにくい。ここが有人対応との最大の違いで、人なら「資料が見当たらない」と言えるところを、RAGは黙って埋めてしまいます。

古い文書を正典として引く。旧版の就業規則、失効した価格表、前年度の運用ルールがインデックスに残っていると、検索は「質問に近い」という理由でそれを引きます。文書の新旧はベクトルの近さには表れないため、内容が正しくても時点が誤っている、という最も発見しにくい誤りが生まれます。

複数文書の矛盾を平気で混ぜる。A部署の手順とB部署の手順、本則と例外規定のように、社内には両立しない記述が同居します。LLMは矛盾を検知して立ち止まる設計にはなっておらず、両方をなめらかに1つの回答へ合成します。読み手には整合した1つの答えに見えるため、どちらが正しいかを問い直す機会すら失われます。

この3つは「モデルが賢くない」から起きるのではなく、検索の失敗や文書側の不備を、生成が黙って上書きすることから起きます。だからこそ次章の「信頼度の信号」で、生成する前に手応えを測る必要があります。

回答信頼度を「どの信号で」見るか

「信頼度」を感覚ではなく、運用で使える信号に落とします。実務で扱いやすいのは次の4つです。

横にスクロールして確認できます

信頼度の信号	何を見るか	低いときの意味
検索スコアの高さ	引いたチャンクと質問の類似度の最大値	そもそも関連文書が社内に無い可能性
検索スコアのばらつき	上位数件のスコア差。1件だけ突出か、団子か	団子なら決め手が無く、迷いやすい
回答と根拠の一致	生成した答えが、引用チャンクに実際に書いてあるか	一致しないなら「文書に無いことを言っている」
自己整合性	同じ質問を数回・別の言い方で聞いて答えがそろうか	ばらつくなら答えが安定していない

このうち「回答と根拠の一致（グラウンディング確認）」が中小企業のCS・FAQでは特に効きます。生成した回答文を、引用したチャンクと突き合わせて「この主張の出どころが引用内にあるか」を判定し、無ければ回答を出さずに保留へ回す。これだけで「文書に書いていない断定」を大幅に減らせます。

信頼度は0か1かではなく、しきい値を2段構えにすると運用しやすくなります。たとえば高信頼なら即回答、中程度なら追加検索して再判定、低信頼なら回答不可にして有人・未回答ログへ。この3分岐が、固定kを「信頼度で動くRAG」に変える最小の骨格です。

「確信度スコア」を鵜呑みにしない

ツールやモデルが出す0〜100%のような「確信度スコア」を、そのまま正しさの保証と受け取るのは危険です。理由は2つあります。第一に、多くのスコアは「モデルがどれだけ自信を持って生成したか」を表すもので、「答えが社内文書に照らして正しいか」とは別物です。堂々と自信満々に間違えることは、人間と同じく起こります。第二に、スコアの数値は使うモデルやプロンプト、質問文の言い回しで動くため、ある環境の「80%」を別の環境の「80%」と同じ意味で扱えません。

実務では、スコアを絶対的な合否ラインとして信じるのではなく、前章の表で挙げた複数の信号（検索スコア、根拠との一致、答えの安定性）を組み合わせ、自社の質問と正解データで「このあたりを超えたときは実際に正答が多い」というしきい値を実測で決めます。スコアは意思決定の入力の1つであって、それ自体が答えの正しさではない——この距離感が、確信度設計の肝です。

API費用を信頼度とセットで設計する

RAGのAPI費用は、主に「埋め込み（ベクトル化）」「検索（ベクトルDBの読み取り）」「生成（LLMの入力トークン＋出力トークン）」で決まります。費用が読めなくなる典型は、リランクや多段検索、追加検索を無制限に回す構成です。信頼度で分岐させると、費用は「難しい質問にだけ多く払う」形になり、総額が予測しやすくなります。

費用設計で先に決めておく項目は次の通りです。

1問あたりの検索予算上限：追加検索は最大何回まで。上限に達したら回答不可へ倒す。
文脈長の上限：LLMに渡すチャンク数・トークン数の天井。長文脈は精度が上がるとは限らず、費用だけ膨らむ。
キャッシュ方針：よくある質問の回答・検索結果を再利用し、同じ質問に毎回フルで払わない。
モデルの使い分け：一次判定は軽量モデル、難所だけ上位モデル。全部を高価なモデルで回さない。
月次の費用上限と停止条件：想定を超えたら誰に通知し、どこで止めるか。

費用を「使った分だけ後で請求」に任せると、問い合わせが増えた月に予算が跳ねます。信頼度の高い質問は安く即答し、低い質問だけコストをかけて丁寧に扱う。この配分がAB-RAGの言う「予算に基づく適応検索」の実務版です。

コストが膨らむ4つの経路

費用が想定を超えるとき、犯人はたいてい次のどれかです。設計段階でこの4つに歯止めを入れておくと、後から驚く請求を避けられます。

毎回大量の文書を渡す。固定kが大きい、チャンクが長い、リランク前の候補を全部投げる。入力トークンは渡した分だけ課金されるため、精度に効かない文書まで渡すと純粋な無駄になります。
再検索を繰り返す。一次回答の信頼度が低いたびに言い換え・再検索を回す構成で、回数上限が無いと、難問1件が想定の何倍もの検索と生成を呼びます。
長いコンテキストを常用する。会話履歴や参照文書を毎ターン丸ごと積み増すと、ターンが進むほど1回あたりの入力が肥大します。長文脈は精度が上がるとは限らず、費用だけが線形に増える場面が多い。
エージェント化で呼び出しが増える。「AIが自分で考えて検索・再検索・要約を繰り返す」エージェント型は、1つの質問の裏で複数回のLLM呼び出しが連鎖します。賢く見える一方、1問あたりの呼び出し回数が読みにくく、費用のばらつきが最も大きい構成です。導入するなら1問あたりの呼び出し上限を必ず設けます。

コストを抑える設計と、その代償

費用を下げる手は複数ありますが、多くは精度や鮮度と引き換えです。「何を犠牲にしているか」を理解して選ぶことが重要です。

横にスクロールして確認できます

コスト削減策	効果	犠牲になりうるもの
検索を絞り込む（kを小さく・フィルタを強く）	入力トークンと検索負荷を削減	難問で根拠が足りず取りこぼす
回答・検索結果をキャッシュ	同じ質問への再課金を回避	文書更新後に古い回答を返す恐れ（失効管理が必要）
渡す量に上限を設ける	1問あたりの費用が予測可能に	長い文脈が要る質問で情報不足
安いモデルへ振り分ける	大半の易問を低単価で処理	難問を安いモデルに回すと誤回答が増える

要は、全部を安く・全部を正確に、は両立しません。だからこそ信頼度で分岐し、「易しい質問は安いモデル・少ない検索・キャッシュで即答、難しい質問だけコストをかける」という配分にします。キャッシュを使うなら、文書が更新されたらそのキャッシュを捨てる仕組みを必ずセットにします。ここを怠ると、コスト削減策そのものが古い回答を返す原因になります。

追加検索・回答不可・有人引き継ぎの運用ルール

信頼度と費用で分岐させると決めたら、分岐先の運用を具体化します。ここを言語化しないまま本番化すると、現場が「AIが変な答えを出した」ときに逃がし場所が無く、結局全部を人が見直す羽目になります。

追加検索。一次検索で信頼度が中程度なら、質問を言い換える・検索範囲を広げる・別インデックスも引く、といった追加検索を1〜2回だけ許可します。ここに回数上限を必ず置きます（無制限にすると費用が読めなくなる）。

回答不可ルール。追加検索しても根拠がそろわなければ、AIに答えさせません。「社内文書では確認できませんでした。担当へおつなぎします」と返し、質問と検索結果を未回答ログに残します。誤った断定より、正直な保留のほうがCSの信頼を守ります。

有人引き継ぎ。回答不可・高リスク質問（解約、クレーム、契約条件、個人情報）は、最初から人へ回すルートを用意します。誰が受けるか、どのチャネル（チャット・メール・電話）へ渡すかを決めておきます。

月次ナレッジ改善。未回答ログは「文書に無かった質問」の宝の山です。月に1回、頻度の高い未回答を拾い、FAQ・社内文書を追記し、次月の回答率を上げます。RAGは作って終わりではなく、この改善ループで賢くなります。

中小企業でのRAG運用設計（社内検索・FAQ・CS）

社内文書FAQ、問い合わせ一次対応、CS自動化にRAGを入れるとき、現場責任者がツール名より先に棚卸しすべきものを挙げます。RAG固有の観点に絞っています。

文書の鮮度と権威づけ：古い規程・重複した手順書が混ざると誤回答の原因になる。どれを正典とするか決める。
チャンク分割と粒度：長すぎる断片は費用を食い、短すぎる断片は文脈が切れる。文書の構造に合わせて分ける。
アクセス権限の反映：全社員が見てよい文書と、部署限定・役職限定の文書を分け、検索段階で権限フィルタをかける（RAGの情報漏えいはここで起きやすい）。
回答に出典を添える：AIの回答に「参照した文書名・リンク」を必ず付け、利用者が原典を確認できるようにする。
禁止トピックの明示：法的判断、医療・健康、個人の処遇など、AIに答えさせない領域を先に決める。

RAGの権限設計や情報漏えいの観点はOWASP GenAI Security Project、AI利用の全社ルールは経済産業省・総務省のAI事業者ガイドラインと個人情報保護委員会の資料が出発点になります。まずは「AIに渡してよい文書・マスキングが必要な文書・渡してはいけない文書」の3分類から始めると、現場でも運用に乗ります。RAGの前段となるデータ整備は、RAG導入前のデータ品質管理や自動化の前にナレッジベースを整える手順も参考にしてください。

導入前の費用試算：まず実測から始める

「月いくらかかるか」を先に断定するのは危険です。RAGの費用は質問の内容と件数、使うモデルで大きく動くため、机上の単価だけでは当たりません。試算は次の順で、自社の数字を測りながら詰めます。

件数を洗い出す：対象業務の質問が「1日に何件」「月に何回」来るか。CSなら過去の問い合わせログ、社内FAQなら想定利用者数から見積もります。ピーク月とオフ月の差も押さえます。
1回あたりの入出力量を実測する：代表的な質問を20〜50問用意し、実際にRAGへ通して、1問あたりの入力トークン（渡した文書＋質問）と出力トークンを計測します。ここは推定せず、必ず使うモデルとチャンク設定で実測してください。日本語は文字数とトークン数が一対一ではなく、モデルによって換算も変わるため、「1文字＝何トークン」という一律の換算で見積もらないことが大切です。
単価を掛ける：計測した1問あたりトークンに、使うモデルの最新の公開単価を掛け、埋め込み・検索・生成の内訳で足し上げます。単価はモデル提供元の価格表で公開前に必ず再確認します。
件数×1問費用で月額を出し、上振れを見込む：追加検索やエージェント化がある構成では、難問が呼び出しを増やすぶんを上振れ幅として別に見込みます。最後に月次上限と停止条件を決め、超えたら誰に通知しどこで止めるかまでを試算書に書きます。

この順で出した数字は、ベンダー提案の妥当性を判断する物差しにもなります。逆に、実測なしの「月◯万円」だけを鵜呑みにすると、本番で件数が伸びた瞬間に予算が崩れます。

「使える」をどう判定するか：評価データと評価頻度

PoCの合否を「賢く答えた」という印象で決めると、本番のロングテール質問で崩れます。使えるかどうかは、次の指標を数字で見て判断します。

正答率：正しく答えられた割合。
誤回答率：間違った内容を自信満々に返した割合（最も重い指標）。
保留率：回答不可・有人送りにした割合。高すぎれば使い物にならず、低すぎれば嘘を出している疑い。
1問あたり費用：上の品質をいくらで実現しているか。

これらを測るには「正解データ（評価セット）」が要ります。作り方は難しくありません。現場でよく来る質問を50〜100問集め、社内の有識者が「正しい回答」と「根拠となる文書」を人手で紐づけます。RAGの回答をこの正解と突き合わせれば、正答・誤答・保留を機械的に判定できます。網羅よりも、頻度の高い質問と過去に事故った質問を優先して入れるのがコツです。

評価は一度きりでは意味がありません。文書を更新したとき、モデルやしきい値を変えたとき、そして最低でも月に1回は同じ評価セットで測り直します。未回答ログから拾った新しい質問を評価セットに足し続けることで、評価の網が現場の実態に追いついていきます。RAGは「作って測って終わり」ではなく、「測り続けて調整する」運用で品質が保たれます。

文書の側を先に整える

RAGの精度は、モデルよりも先に「渡す文書の状態」で決まります。前章までで触れたとおり、次の3つは導入前に棚卸しすべき地雷です。

更新されていない文書：旧版が残っていると、検索は新旧を区別できず古い方を引きます。正典を1つに決め、失効した文書はインデックスから外すか明示的に旧版と印を付けます。
重複した文書：同じ内容の手順書が複数あると、どれが根拠か定まらず回答がぶれます。重複は統合し、参照先を一本化します。
権限のない文書が混ざる：部署限定・役職限定の文書が全社検索に出ると、そのまま情報漏えいになります。文書に機密区分を付け、検索の段階で権限フィルタをかけてから生成に渡します。

この整備は地味ですが、モデル選定より費用対効果が高い工程です。文書が濁ったままでは、どれだけ良いモデルを選んでも濁った答えしか返りません。

発注前チェックリスト（RAG特化）

ベンダーへ「できますか」と聞くのではなく、次の前提をどう扱うかを聞くと、提案の質と責任範囲の差が見えます。

検索件数は固定か、信頼度・難易度で可変か。可変ならどの信号で判定するか
回答と根拠の一致（グラウンディング）をどう検証し、不一致のとき何を返すか
回答不可・保留のしきい値は誰が調整でき、変更履歴は残るか
1問あたり・月あたりのAPI費用試算と、費用上限に達したときの挙動
チャンク分割・リランク・追加検索の有無と、追加検索の回数上限
文書の権限・機密区分を検索段階でフィルタできるか
回答に出典・参照リンクを付けられるか
未回答ログの蓄積と、月次ナレッジ改善の運用が提案に含まれるか

RFPに入れるべき質問

横にスクロールして確認できます

RFP項目	ベンダーへ求める回答	評価で見ること
検索方式	固定k/可変k、リランク、追加検索、文脈長の上限	費用と精度の両立を設計しているか
信頼度判定	使う信号、しきい値、回答不可の条件	根拠なき断定を止められるか
費用	埋め込み/検索/生成の内訳、月額試算、停止条件	TCOと予算超過時の挙動が明確か
権限・機密	文書区分、検索時フィルタ、ログの保全	情報漏えいを防げるか
運用改善	未回答ログ、月次ナレッジ更新、精度の再測定	作って終わりでないか
責任分界	AIが答える範囲、人が受ける範囲、事故時対応	顧客説明に耐えるか

よくある失敗パターンと回避策

PoCの成功条件が「賢く答えた」だけ：本番はロングテールの質問で崩れる。回答率・誤回答率・保留率・1問費用で合否を定義する。
固定kのまま本番化：易しい質問で払いすぎ、難しい質問で根拠不足。信頼度分岐を最初から設計する。
回答不可を用意しない：AIが必ず何か答えるため、嘘の断定が出る。保留と有人ルートを先に作る。
文書の権限を無視：部署限定の文書が全社員の検索に出て情報漏えいになる。検索段階で権限フィルタをかける。
初期費用だけで判断：API従量、リランク、追加検索、保守、ナレッジ更新の運用費を見落とす。TCOで比較する。
未回答ログを捨てる：改善の材料を失い、回答率が上がらない。月次で拾い、FAQに反映する。

これらは技術力ではなく、導入前の問いが浅いことから起きます。RAGのコスト構造そのものを詳しく見たい場合は、中小企業向けRAGチャットボット開発費用ガイドも合わせて確認してください。

GXOの独自見解

RAGの失敗は検索精度だけの問題ではありません。簡単な質問にまで無駄に検索し、難しい質問には根拠不足で答える——この設計が、API費用と回答信頼性を同時に悪化させます。私たちがRAG案件で最初に見るのは、埋め込みモデルやベクトルDBの選定ではなく、「どの質問に、いくらまで払って、どこまで答えさせ、いつ人へ渡すか」というルールです。

この順番を間違えると、PoCは速く動いて見えても、本番で誤回答・費用超過・顧客説明の破綻が起きます。逆に、信頼度のしきい値・検索予算・回答不可・未回答ログの4点を先に決めておけば、要件定義からPoC、本番化、月次改善まで同じ設計図で進められます。RAGは「賢いモデルを選ぶ勝負」ではなく、「どこで諦めさせ、どこで人につなぐかを決める運用の勝負」です。

90日ロードマップ

いきなり全社導入や大規模開発に進めるのではなく、90日を3段に分けると、費用感と進め方を掴みながら判断できます。

横にスクロールして確認できます

期間	実施内容	確認する成果
1〜30日	対象業務・文書・権限・機密区分・費用上限を棚卸しし、正典文書を決める	導入可否、優先業務、危険な運用、重複コストが見える
31〜60日	1つの業務（例：FAQ一次対応）で、信頼度分岐・回答不可・出典表示を小さく検証する	回答率・誤回答率・保留率・1問費用が実測できる
61〜90日	しきい値と検索予算を調整し、権限フィルタ・未回答ログ・月次改善・有人ルートを固める	継続/拡張/停止の判断材料と本番運用の型がそろう

RAGにまつわるよくある誤解

導入判断の前に、次の思い込みを外しておくと事故を減らせます。どれも「一見正しそうで、実は逆」というものです。

「社内文書を入れれば正確になる」：文書を渡すことと、正しく引けることは別です。古い・重複・矛盾した文書が混ざれば、むしろ誤回答の材料を増やします。正確さは文書整備と検索設計で作るものです。
「確信度スコアが高ければ正しい」：スコアは多くの場合「モデルの自信」であって「答えの正しさ」ではありません。自信満々の誤答は普通に起こります。根拠との一致を別途検証してはじめて信頼できます。
「RAGならハルシネーションは起きない」：RAGはハルシネーションを減らす手段であってゼロにはしません。検索が外れれば、LLMは黙って埋めます。回答不可ルールが無ければ、嘘は必ず漏れます。
「一度作れば運用は要らない」：文書は更新され、質問は変わり、モデルも変わります。評価と未回答ログの改善を止めた瞬間から、回答率は静かに劣化します。RAGは作った後の運用が本体です。