ENTRY TYPE · definition

RAG（検索拡張生成）とは

By Marius Bughiu Last updated 2026-07-27 RevOpsLegal OpsRecruiting & TACustomer Success

RAG（Retrieval-Augmented Generation、検索拡張生成）とは、AI ツールが回答する前にまず文書群を検索し、学習時に取り込んだ知識からではなく、検索で見つかった文章から回答を書く方式です。質問が入ると検索ステップが関連度の高いと判断した数個の文章を返し、その文章がモデルのプロンプトに貼り込まれ、モデルはそれをもとに回答します。買い手にとって重要なのは、「根拠に基づいている」「出典を示す」「御社のデータで学習済み」というベンダーの主張のほぼすべてが RAG という仕組みの上に成り立っているからです。そしてベンダーがその 3 つのどれを意味しているかによって、契約前に検証すべき内容が変わります。

RAG は学習ではありません。あなたの文書がモデルの重みに入ることはなく、質問のたびに読まれ、その後は破棄されます。「モデルが御社の契約書を学習します」と言うベンダーは、RAG を不正確に説明しているか、あるいはあなたのデータが最終的にどこへ行くのかを直接問いただすべきことをしています。RAG はハルシネーションの解決策でもなく、そもそもモデルの性質ですらありません。モデル自体は変えないまま、その周囲に巻き付けたパイプラインです。同一のモデルを動かす 2 つの製品でも、このパイプラインの検索精度次第で挙動はまったく別物になります。

2 つの半分と、デモに出てくるのは一方だけ

あらゆる RAG システムは、検索側の半分（コーパスをインデックス化し、チャンクに分割し、検索し、返ってきたものを順位付けする）と、生成側の半分（前半が渡したものから文章を書く）に分かれます。

ベンダーのデモが動かしているのは生成側です。見栄えがするのはその部分ですが、エラーが始まるのはそこではありません。検索ステップが外したとき、モデルはそのことを知りません。間違った 3 つの文章から、流暢で出典付きの回答を書き、何の問題も報告しません。**必要だった文章が渡されなかったことを、モデルはあなたに伝えられません。**この事実ひとつでパイロットの設計は変わるはずです。ツールがうまく答えられる質問で出力品質を測っても、ほとんど何もわからないということだからです。

「根拠に基づく」は配管の話であって、正確さの話ではない

最も強い公開エビデンスは法律分野から出ています。主張が最も大きく、実際に測定した人がいた領域だからです。Stanford の RegLab は、LexisNexis と Thomson Reuters が販売する RAG ベースの法務リサーチツール（Lexis+ AI、Westlaw AI-Assisted Research、Ask Practical Law AI）について事前登録済みの評価を実施し、これらが 17% から 33% の頻度でハルシネーションを起こすことを示しました。LexisNexis は「ハルシネーションのない」リンク付き引用をうたっており、Thomson Reuters は信頼できるコンテンツに依拠することでハルシネーションを回避していると説明していました。どちらの主張も過大でした。ただし公正に読めば、RAG が失敗したという話ではありません。これらのツールは同じ質問で汎用の GPT-4 を上回っています。読み取るべきは、キュレーションされたコーパスに対する検索はエラー率を下げるがゼロにはしない、つまり「根拠に基づく」はアーキテクチャの説明であって保証ではない、ということです。

そこから 2 種類の失敗が生まれますが、危険度は同じではありません。ひとつは明らかに誤った回答で、これは領域の専門家が気づきます。もうひとつは根拠の取り違えで、内容は誤っているのに実在する引用が付いており、その引用先の実在する文書には回答が主張する内容が書かれていません。こちらはレビューを通過してしまいます。忙しいレビュアーが「この回答は確認済みだ」と判断する手がかりが、まさにその引用だからです。

ベンダーに投げる診断質問

最初の 2 つで大半の仕事が終わる順に並べています。

このツールが間違える質問を見せてください。そして原因が検索側か生成側かを教えてください。 自社の検索失敗を一度も分析していないベンダーは、システムではなくデモを評価しただけです。
引用が指すのは文章単位ですか、文書単位ですか。 文書単位の引用は実運用の量では検証不能です。1 文を確認するために 60 ページの MSA を読む人はいません。レビューを実際に回せるほど安くするのは、文章単位または条項単位の引用です。
答えがコーパスに存在しないとき、どう振る舞いますか。 挙動は「該当情報がありません」と、ベースモデルの一般知識への無言のフォールバックの 2 つです。自信満々の誤りが入り込むのは後者で、料金ページに書かれていることはまずありません。
権限は検索時に適用されますか、生成後に適用されますか。 正解は検索時です。質問したユーザーが元々閲覧権限を持つ文書だけがモデルに渡されます。Glean がインデックス設計を権限フィルタ付き検索の上に組み立てたのは、まさにこのためです。モデルが制限文書を読んだ後で回答を絞り込むのはアクセス制御ではなく、漏れのあるマスキングです。
文書が更新されてから、新しい版が回答に使われるまでどれくらいかかりますか。 数分、1 時間ごと、夜間バッチ、いずれも妥当です。把握していないことだけが妥当ではありません。
書かれた回答だけでなく、何が検索されたかを見られますか。 その画面がなければ誤答のデバッグはできず、それは先方のサポートも同じです。

コンテキストウィンドウが大きくなれば RAG は不要になるのか

なりません。100 万トークンのコンテキストウィンドウを売るベンダー自身もそうは主張していません。検索がアーキテクチャに残り続ける理由は 3 つあります。数万件規模のコーパスは市場のどのコンテキストウィンドウにも収まりません。入力コストはトークン量に比例するため、質問のたびにナレッジベース全体をモデルに流し込めば、その費用は質問ごとに課金されます。そして 1 時間ごとに変わるコーパスは、送り直すより再インデックスするほうが安く済みます。

2026 年までに変わったのは配分です。機能する型は「検索してから推論する」——できる限り絞り込んだ 3 チャンクではなく、関連する材料を余裕をもって引き出し、長いコンテキストを扱えるモデルにその全体を処理させる形です。これは検索ステップに求める精度を緩めますが、検索そのものを取り除くわけではありません。「コンテキストウィンドウが大きいので検索は不要」という売り込みは、あなたのコーパス規模について詰め切っていない主張として扱ってください。

よくある落とし穴

ベンダーのコーパスでパイロットを回す。 数か月かけてサンプル文書に合わせ込まれたデモからわかるのは、そのサンプルの出来の良さだけです。

ガード: 自社の文書を持ち込み、最初のデモの前に実際の質問を 30 から 50 件書いてください。うち 5 件はコーパスに答えが存在しないものを意図的に含め、その拒否挙動を合否項目として採点してください。

引用を検証の代わりに読む。 根拠を取り違えた回答が「レビュー済み」に見えてしまう原因が、まさにその引用です。

ガード: パイロット期間中は固定サンプルで引用先の文章を実際に開いてください。週 20 件で足ります。そのうえで根拠取り違え率を誤答率とは別に記録します。誤答 5%・根拠取り違え 15% のツールは、誤答 15%・根拠取り違え 2% のツールよりチームにとって悪い選択です。

権限が元システムから自動で引き継がれると思い込む。 コネクタ経由のインデックス化はコンテンツを複製しますが、アクセス制御リストまで複製したかは別問題であり、答えはコネクタごとに異なります。

ガード: パイロット中に、権限レベルの異なる 2 名のユーザーとして同じ機微なクエリを 3 件実行し、結果を突き合わせてください。製品単位で 1 回ではなく、コネクタ単位で実施します。

本番投入後にコーパスを腐らせる。 失効したポリシー、期限切れの契約書、古い playbook が積み上がるにつれて検索品質は落ちます。検索ステップにはどれが現行版かを知る手立てがないからです。

ガード: 立ち上げ前にコーパスの責任者を指名し、アップロードだけでなく削除の権限を与えてください。四半期ごとに、その朝に編集した文書と、本来すでに削除されているべき文書の両方で再テストします。