RAGの設計は「分ける・探す・絞る・引用する」の4段で決める：公式資料で、各段の決めどころを確かめる

3行でいうと

RAGは「資料を小さく切る→意味の数値にして保存→質問に近い部分を探す→AIに渡す」の流れ。
決めどころは、チャンクの大きさと重なり、検索の方式、渡す件数、並べ替えの有無、引用の出し方。
Anthropicの試験では、検索の取りこぼしを、文脈の付与と並べ替えで約3分の1に減らせた（5.7％から1.9％）。
資料が少量なら、RAGを使わず全文を入れる手もある。ただし長くなると精度が落ちる研究もある。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。

先に結論

RAGの品質は、AIの賢さだけでなく、探す段階でちゃんと見つかるかに左右されます。見つからなかった情報は、AIに渡せません。
そのため、設計の中心は「何を、どの大きさで、どう探し、いくつ渡し、どう出典を示すか」です。この記事は、その決めどころを4段に分けます。
数字は会社の試験や公式の既定値です。自分の資料で測り直す前提で読んでください。Anthropicも「必ず評価を行うこと」と書いています。

前提：RAGと用語

RAG（Retrieval-Augmented Generation、検索拡張生成）は、Lewisらの論文（NeurIPS 2020）が提案した枠組みです。論文は、言語モデル自身が持つ知識（パラメーターの中の記憶）と、外部の検索できる記憶を組み合わせる、と説明しています。論文ではWikipediaをベクトルの索引にしていました。
チャンクは、資料を切った小さな断片です。
埋め込み（ベクトル）は、文章の意味を数字の並びにしたものです。意味が近い文は、数字の並びも近くなります。
ベクトルデータベースは、その数字の並びを保存して、近いものを素早く探すための入れ物です。
top-Kは、検索で上位K件を取ることです。
APIは、アプリからAIや検索を呼び出す窓口です。

全体の流れ

Anthropicの記事（2024年9月19日）は、RAGの標準的な流れを次のように説明しています。

資料（コーパス）を、通常は数百トークン以下のチャンクに分ける。
埋め込みモデルで、各チャンクをベクトルにする。
ベクトルデータベースに保存する。
質問が来たら、質問に意味が近いチャンクを探す。
見つかったチャンクを、AIへの入力に足す。

この記事では、これを「分ける（1〜3）」「探す（4）」「絞る（4の後）」「引用する（5と出力）」の4段に分けて、段ごとの決めどころを見ます。

第0段：そもそもRAGが要るか

Anthropicの記事は、知識ベースが20万トークン未満（約500ページ）なら、RAGなしで全体をプロンプトに入れてよい、と書いています。プロンプトキャッシュ（同じ前置きを安く読む仕組み）と組み合わせると、速くて安い、とも述べています。これは2024年当時の記述で、当時のClaudeの入力が20万トークンだったことが背景にあると思います（僕らの読みです）。

見立てです。今は100万トークンのモデルが増えました。ただし、長い入力では精度が落ちうることが、論文や公式文書で報告されています（別記事「長いコンテキストの実力」）。「入るからRAGは不要」とは限らず、資料の量、更新の頻度、費用、必要な精度で決めるのが現実的です。

第1段：分ける（チャンク）

ここで決めるのは次の3つです。

決めること	公式資料に書かれていること
大きさ	OpenAIのベクトルストア（Retrievalの文書）の既定は1チャンク800トークン、重なり400トークン。大きさは100〜4096の範囲で、重なりは大きさの半分以下。Googleの文書の例は、1チャンク200トークン、重なり20トークン（コード例の設定値で、既定値は読んだ範囲では書かれていませんでした）。Anthropicの記事は「通常は数百トークン以下」で、試算の例は800トークン
重なり	隣り合うチャンクの重複。切れ目で意味が分断されるのを減らす。OpenAIの既定は大きさの半分
切れ目	Anthropicの記事は、大きさ・切れ目・重なりが検索の性能に影響しうる、と注意している

最適な値は資料によって違い、公式資料に「これが正解」という数字はありません。OpenAIやGoogleの値は、あくまで既定値や例です。

チャンクが文脈を失う問題。 Anthropicの記事は、従来のRAGの弱点として、チャンクだけを見ても、何の話か分からないことを挙げています。例として、「その会社の売上は前の四半期から3％伸びた」というチャンクは、どの会社のいつの話か書かれていないので、質問「ACME社の2023年第2四半期の売上の伸びは」に結びつけにくい、と説明しています。

文脈つき検索（Contextual Retrieval）。 各チャンクの前に、全体の中での位置づけを説明する短い文を足してから、埋め込みと検索の索引を作る方法です。説明文はClaudeに書かせ、通常50〜100トークンです。Anthropicの記事によると、文書全体をキャッシュしておくことで、費用は100万文書トークンあたり1.02ドル（800トークンのチャンク、8千トークンの文書などの仮定。当時の条件）でした。ただし、一般的な文書要約をチャンクに足す方法は、得られる改善が限られていた、とも書かれています。

メタデータ。 OpenAIの文書は、ファイルに属性（メタデータ）を付けて、検索結果を絞り込めると説明しています。Googleのファイル検索も、ファイルに任意のメタデータを付けられます。

第2段：探す（検索の方式と件数）

ベクトル検索（意味で探す）： 言葉が違っても意味が近いものが見つかります。OpenAIの文書は、言葉が一致しない場合も見つけられる、と説明しています。
キーワード検索（言葉で探す）： Anthropicの記事は、埋め込みは意味の関係に強い一方で、正確な一致を見逃すことがあり、「Error code TS-999」のような固有の文字列にはBM25（言葉の一致で順位をつける古典的な方法）が効く、と説明しています。
両方を組み合わせる（ハイブリッド）： 詳しくは別記事「ハイブリッド検索とリランキング」。OpenAIのファイル検索は「意味とキーワードの検索」を備える、と書かれています。
取る件数（top-K）： Anthropicは5、10、20件を試し、20件が最も良かった、ただし多すぎる情報は邪魔にもなるので使う場面で試すこと、と書いています。
質問の書き換え： OpenAIの検索には、質問を検索向けに自動で書き直す設定（rewrite_query=true）があります。
スコアのしきい値： OpenAIは score_threshold（0.0〜1.0）で、関連の低いものを除けます。上げると、使えそうなものまで落ちることがある、と書いています。

日本語の場合、キーワード検索には単語の切り方（分かち書き）が関わります。Elasticsearchには、日本語用の分析プラグイン（kuromoji）と、空白で区切らない言語向けのn-gram（文字を一定の長さで重ねて切る方法）の機能があります。どれが良いかは、資料と質問で変わると思います（見立てです。この点を比べた研究は読んでいません）。

第3段：絞る（並べ替え）

検索で数十〜数百件を取り、並べ替えのモデルで本当に関係の深い上位だけを残す方法があります。Anthropicの試験では、上位150件を取り、並べ替えて、上位20件を渡しました。効果と仕組みは別記事で扱います。並べ替えは追加の処理なので、遅延と費用が少し増える、とAnthropicも書いています。

第4段：渡して引用する

渡し方： Anthropicの記事は、文脈つきのチャンクを渡すとき、「文脈」と「チャンク本体」を区別して渡すと、回答が良くなる場合がある、と述べています。
長い資料の置き方： Claudeの文書は、長い資料は先頭、質問は末尾に置く、と勧めています（別記事「長いコンテキストの実力」）。
引用： Claudeの引用機能（Citations）は、文書を渡すと、回答の各主張に対して根拠の箇所を返します。文書は、平文とPDFでは自動で文（センテンス）に区切られ、カスタム内容の文書では、渡した区切りがそのまま引用の単位になります。文書は、RAGのチャンクの中の個々の文を引用したいなら、チャンクごとに平文の文書にし、チャンク単位より細かく区切りたくないなら、カスタム内容の文書にする、と説明しています。引用される原文（cited_text）は出力トークンに数えられません。ただし、構造化出力（出力の形を決める機能）とは同時に使えません。
OpenAIとGoogle： OpenAIのファイル検索は、出力に file_citation の注釈（どのファイルか）を付けます。Googleのファイル検索も、同様の file_citation を返します。

設定を見るときの目安（見立てです）

見立てです。以下は、読んだ資料から組み立てた確認項目です。

症状	まず疑う段
資料にあるはずの答えが出ない	第1段（分け方、文脈の欠落）、第2段（検索方式、件数）
固有名詞や型番が見つからない	第2段（キーワード検索の不足）
関係ない内容が混ざる	第3段（並べ替え）、第2段（しきい値、メタデータ）
出典が示せない／確かめられない	第4段（引用の仕組み）
費用が高い	件数、チャンクの大きさ、並べ替えの数、キャッシュ

つまずきやすい点

検索の評価と回答の評価を分けない。 検索で取れていないのに、回答の文章だけ直しても効きません。Anthropicの試験は、「上位20件に正解が入らなかった割合（1から再現率@20を引いたもの）」で、検索だけを測っています。
チャンクを小さくしすぎて文脈を失う。 文脈つき検索のような補い方があります。
件数を増やしすぎる。 Anthropicは、情報が多すぎるとAIの気を散らすこともある、と書いています。
更新の反映を忘れる。 資料が変わったら、チャンクと埋め込みを作り直す必要があります。

気をつけること

この記事は、実際に使って確かめた記録ではありません。上記は公式文書と論文の記述です。
Anthropicの数字（5.7％から1.9％など）は、同社の試験（コード、小説、論文など複数の領域、2024年当時のモデル）の結果です。日本語の資料や、現在のモデルでの結果は確認できていません。
OpenAI・Googleの既定値（800/400トークン、200/20トークンの例）は、変わることがあります。Googleの文書は、ファイル1件が100MBまで、ストアは20GB未満が推奨、と書いています（2026年10月22日確認）。
日本語の分かち書きとRAGの精度の関係を、一次資料で確かめられていません。
「資料が少なければ全文を入れてよい」は、2024年の記事の記述です。現在の長い入力の精度については、別記事を参照してください。
費用の数字は変わります。使う前に、各社の最新ページを確認してください。
出典のうち、Lewisらの論文とElasticsearchの2ページ（kuromoji、n-gram）は、10月22日に取り直していません。確認日は10月8日のままです。

出典

更新履歴

2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した
2026年10月22日 公式の資料を読み直して、次の点を直しました。
- 前：OpenAIのファイル検索の既定は800トークン、重なり400トークン → いま：OpenAIのベクトルストア（Retrievalの文書）の既定として書き直した
- 前：Googleの1チャンク200トークン、重なり20トークンは例として書いた → いま：コード例の設定値で、既定値は読んだ範囲では書かれていない、と明記した