RAG 実装パターン

この記事の目的

検索拡張生成(RAG外部の知識ソースを検索し、結果を LLM の入力に加えて回答の根拠にする手法。検索の判断を Agent に任せる構成は Agentic RAG と呼ばれる。)を「概念として知っている」から「本番品質で実装できる」に進むための、取り込み・検索・生成・評価の各段の設計判断を扱います。チャンキング戦略、検索方式(ベクトル・キーワード・ハイブリッド)、リランキング、Agentic RAG、引用の提示、権限反映までを自分のシステムに合わせて選択できるようになります。

対象読者

• 固定 RAG または Agentic RAG の実装・改善を担当するエンジニア
• 「作った RAG の精度が上がらない」段階で、どの段を直すべきか切り分けたいエンジニア

前提知識

• RAG と Agent の関係・使い分け — 固定 RAG / Agentic RAG / 検索なしの構成選択(本記事は構成決定後の実装編)
• Agent 評価の基礎 — 検索品質と回答品質を分けて測る前提
• ライブラリ外の前提: ベクトル検索(埋め込みテキストや画像を、意味的な近さが距離に対応する数値ベクトルに変換したもの。RAG・記憶・分類の土台で、「何が近いか」はモデルで変わるため自社データで評価して選ぶ。モデル変更は全チャンクの再インデックスを伴う。の類似度検索)のごく基本的な仕組み

本文

概要: RAG は 4 段のパイプライン

RAG の品質問題は「どの段の問題か」を切り分けないと直せません。本記事では次の 4 段に分けて設計判断を整理します。

図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

経験則として、体感品質の問題の多くは生成(プロンプト)ではなく取り込みと検索に根があります。「必要な文書がそもそも上位に来ていない」状態でプロンプトを磨いても改善しません。

取り込み: チャンキング(chunking)とメタデータ

チャンキング(chunking)とは、文書を検索・投入の単位に分割することです。分割の設計が検索品質の上限を決めます。

設計時の考え方は次のとおりです。

• チャンクサイズはトレードオフです。小さいほど検索の的中は鋭くなるが文脈が欠け、大きいほど文脈は保たれるがノイズが増えて「どこが答えか」がぼやけます。文書タイプごとに評価セットで比較して決めます(勘で固定しない)
• 分割の境界で意味を切らないことが原則です。表の途中・手順の途中で切れたチャンクは、検索にヒットしても使いものになりません。構造ベース分割を優先し、長すぎる節だけ二次分割します
• チャンク単体で意味が通るかを確認します。「前述の設定を〜」だけのチャンクは検索しても文脈不明です。見出しパスや要約をチャンク先頭に付与する(コンテキスト付きチャンク)と、検索・生成の両方が安定します
• メタデータ(出典文書・セクション・更新日・部署・アクセス権限ラベルなど)を必ず付けます。検索時のフィルタ(後述の権限反映・鮮度優先)と、引用の提示の両方で必須になります

埋め込みと検索方式

埋め込みモデルの選定では、対象言語(日本語の検索品質)・入力長・次元数(ストレージと速度)・コストを見ます。注意すべきは、埋め込みモデルの変更は全チャンクの再インデックスを意味することです。モデル選定のやり直しは高くつくため、評価セットで比較してから決め、インデックスにモデル名とバージョンを記録しておきます(選定の一般論は モデル選定ガイド)。

検索方式は 3 択です。

実務の初期値は ハイブリッド検索です。「ベクトル検索だけ」で始めると、型番・エラーコード・固有名詞の質問(業務システムでは頻出)で静かに失敗します。

リランキングとハイブリッド検索の組み立て

リランキング(reranking)とは、一次検索で広めに取った候補(例: 上位 50 件)を、より精密なモデルで並べ直して上位数件に絞る 2 段目の処理です。一次検索は再現率(取りこぼさない)を、リランキングは精度(上位の質)を担当する、という分業になります。

• 効果: コンテキストに入れる件数を絞れるため、生成品質とコストの両方に効きます。「上位 20 件を全部入れる」より「リランキング後の上位 5 件」の方が良い結果になることが多いです
• コスト: リランキングは候補件数に比例した追加レイテンシ・費用がかかります。まずハイブリッド検索のみで評価し、上位の質がボトルネックだと確認できてから追加します
• 順序: 利用者の権限条件を確定 → その条件を検索時に適用して候補取得 → リランキング → 上位 k 件をコンテキストへ、を基本候補にします。権限条件はモデルが省略・変更できないようツール実装側で強制します

件数制限の後で権限フィルタを掛ける方式では、上位候補が権限外に偏ると、下位にある閲覧可能な文書を取りこぼします。基盤の制約などで後フィルタを選ぶ場合は、候補数の拡張・追加取得を設計し、利用者が閲覧可能な正解文書を母集団とした再現率を測ります。いずれの方式も、権限外の候補を生成モデルや外部のリランキングサービスへ渡してはいけません。検索基盤によるフィルタ時点の違いは Azure AI Search の解説 に具体例があります。

Agentic RAG の実装

クエリの言い換え、複数ソースの検索、取得値の計算は、固定された多段ワークフローでも実装できます。例えば「クエリ書き換え → 2 つの索引を並列検索 → 統合 → 計算 → 回答」は、各ステップに LLM を含めても経路は事前に定義できます。途中結果に応じてモデルが検索先・再検索・次の操作を動的に選ぶ必要がある場合に Agentic RAG を検討します。操作数だけを採用理由にしません(Anthropic の Workflow / Agent の区別 、RAG と Agent の関係・使い分け)。

検索の制御を Agent に渡すと決めた場合は、次を設計します。

• 検索をツールとして定義する: 「クエリ」「フィルタ(文書種別・期間)」「件数」をパラメータにした検索ツールを渡します。ツール説明文には「どんな知識が入っているか」「どういうときに検索すべきか」を書きます(ツール定義の設計)
• クエリの再構成を任せる: 必要に応じて、会話履歴を踏まえた具体化・分解をモデルに行わせます。クエリ書き換え単体は固定ワークフローにも置けるため、その効果と動的な経路選択の効果を分けて評価します
• 反復の上限を決める: 検索 → 結果確認 → 再検索のループに回数・トークンの上限を設けます。「見つからないときに諦めて『わからない』と言う」条件も指示します
• 検索結果の要約投入: 長いチャンクを複数往復で扱うとコンテキストが膨らみます。ヒット結果の要約や抜粋をループに返し、全文は最終生成時のみ投入する構成でコストを抑えられます(コンテキストエンジニアリング)

引用・根拠の提示

回答には出典を必ず付けます(RAG と Agent の関係・使い分け のアンチパターンでも触れた原則の実装編です)。

• チャンクに安定した ID を振り、生成時に「使用したチャンク ID」を構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。で返させ、アプリ側で文書名・リンクに解決します(モデルに URL や文書名を直接書かせると幻覚モデルが事実でない内容をもっともらしく生成する現象。「もっともらしい続きを生成する」という学習目的の自然な帰結であり、対策は指示の強化ではなく、根拠の外部供給(RAG)・出典要求・検証という構造側にある。の余地が生まれます)
• 「引用された文書が実際に回答内容を支持しているか」は忠実性(faithfulness)の評価対象になります。引用付きでも中身が違う「見せかけの根拠」があるため、評価で検証します(LLM-as-a-Judge)
• 回答に使えるチャンクがなかったときは「見つからなかった」と答えさせます。「検索結果に基づいてのみ回答し、なければその旨を述べる」という指示 + 検索ヒットなし時のガード(コード側)の 2 段構えにします

権限反映と運用

• 権限反映(ACL)検索: 社内文書には閲覧権限があります。インデックスを 1 つに統合するなら、チャンクのメタデータに権限ラベルを持たせ、検索時に必ず利用者の権限でフィルタします。生成後のフィルタでは手遅れです(権限外文書の内容が回答に混入してから消すことはできません)。この設計を怠ると、RAG が権限バイパス経路になります(データ漏えい対策)
• 鮮度と再インデックス: 文書の更新をどう反映するか(定期全再構築 / 差分更新)、古い版をいつ消すかを最初に決めます。「規定は改定されたのに回答が古い」は RAG の典型的な信頼失墜パターンです
• インデックスのバージョニング: チャンキング設定・埋め込みモデルを変えたら別インデックスとして構築し、評価で比較してから切り替えます(ロールバック可能に。バージョニング・デプロイ・モデル更新追従 と同じ考え方です)

RAG の評価: 検索と生成を分けて測る

RAG の評価は最終回答だけを見ると切り分けができません。段ごとに測ります。

「検索は当たっているのに回答が悪い」なら生成(プロンプト・チャンク投入方法)を、「検索から外している」なら取り込み・検索(チャンキング・方式・クエリ書き換え)を直します。評価セットの作り方自体は 評価データセットの構築と保守 を参照してください。

実務での注意点

アンチパターン

チェックリスト

関連トピック

• RAG と Agent の関係・使い分け — 固定 RAG / Agentic RAG / 検索なしの構成選択(本記事の前段)
• 評価データセットの構築と保守 — 検索・生成の評価セットの作り方
• コンテキストエンジニアリング — 検索結果をコンテキストへ組み込む設計
• ツール定義の設計 — Agentic RAG の検索ツール定義
• データ漏えい対策 — 権限反映検索を怠った場合の漏えい経路
• モデル選定ガイド — 埋め込み・生成モデルの選定軸
• 埋め込み(embeddings)の選定と運用 — 埋め込みモデルの選定・評価・再インデックス(本記事の埋め込み層の詳解)
• ベクトルデータベースの選定と運用 — 検索基盤(ベクトル DB)の選定・運用
• LLM 向けデータ前処理パイプライン — チャンキング以前の抽出・クリーニング・メタデータ設計
• GraphRAG とナレッジグラフ — 関係たどり・全体集約に強いグラフ型の別方式(まず通常の RAG で足りるかを判断)
• マルチモーダル RAG — 画像・図表・PDF を含む知識源への拡張(本記事のマルチモーダルテキスト以外の入力(画像・音声など)を理解できるモデルの能力。コンピュータ操作型 Agent の前提となる。差分)
• ドキュメント AI(帳票・PDF の構造化) — 文書を検索可能な構造化データに取り込む前段
• 新興攻撃パターンの体系 — 知識源ポイズニング(細工された文書の混入)の防御面
• ディープリサーチ型エージェントの設計 — 多段検索・出典管理・レポート生成(本記事の検索基盤を自律調査に組み上げる応用)
• 検索体験の再設計 — 本記事の検索基盤を人間向けの回答型検索プロダクトに載せる応用
• examples/python/rag-basics/ — ベクトル DB を使わない純 Python の最小 RAG(検索と根拠付き生成・モック実行可)

参考資料

• Azure AI Search: Vector query filters  — 検索前・検索後のフィルタ適用と、候補件数による取りこぼしの関係(アクセス日: 2026-09-10)
• Building effective agents(Anthropic)  — 事前定義のワークフローとモデルが動的に経路を選ぶ Agent の区別(アクセス日: 2026-09-10)
• Introducing Contextual Retrieval(Anthropic)  — チャンクに文脈を付与して検索精度を上げる手法と、BM25 併用(ハイブリッド)・リランキングの効果測定(アクセス日: 2026-07-06)
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks  — RAG の原論文(アクセス日: 2026-07-06)

TODO・未確認事項