RAG（検索拡張生成）に必要な機能は、インデックス化・検索・生成の3つのフェーズに分けて整理できます。さらに、各フェーズをつなぐワークフロー設計と、回答の品質を測る評価の機能が加わります。
機能の全体像を体系的に理解することが、構築を成功させる前提となります。そのため、機能を選ぶ前に把握しておきたい方は、RAG構築の完全ガイドもご覧ください。
▼全体ガイドの記事
・RAG構築の完全ガイド
AIシステム開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
インデックス化フェーズの必要機能
RAGパイプラインは「インデックス化」「検索」「生成」の3つの大きなフェーズで構成され、インデックス化はその起点です。文書の分割から保存基盤までを一続きに整え、社内文書を検索できる状態にする前処理を担います。地味に見えますが、ここでの設計が後続の検索精度を左右するため、欠かせない工程です。
チャンキング戦略の機能
長い文書をそのまま扱っても、質問に対応する箇所だけを正確に取り出すことはできません。そのため、意味のまとまりごとに文書を分割し、検索しやすい単位へ整えるチャンキング機能が、インデックス化フェーズの起点であり、回答精度の土台になります。
分割では、チャンクの大きさ、分割の手法、区切り方を決めることになります。
- チャンクサイズ：大きすぎると無関係な情報が混ざって検索のノイズになり、小さすぎると前後の文脈が失われ、断片的な情報しか取り出せません。
- 分割の手法：チャンク同士を一部重複させるオーバーラップや、見出しや段落といった文書構造に沿った分割が使われます。
- 区切り方：固定長で機械的に区切るか、構造を尊重して区切るかを、文書の性質に応じて選び分けます。
たとえば、マニュアルのように構造が明確な文書と、議事録のように文脈が連続する文書とでは最適な分割方針が異なるため、文書の種類ごとに戦略を変えられる柔軟さが精度を底上げします。
チャンキングは前処理にとどまらず、RAG全体の精度を決める戦略的な機能です。さらに、一度設定して終わりではなく、検索精度を見ながら調整していく対象なので、初期段階で完璧な設定を目指すより、調整しやすい構成を選んでおくのが現実的です。
埋め込み生成とベクトルデータベースの機能
分割した文書は、埋め込み生成（Embedding）によって、意味を数値で表したベクトルに変換されます。このベクトルは後続の検索で「意味の近さ」を計算するうえで欠かせず、ここでの設計が検索の速度と精度を左右します。ベクトルデータベースは、生成したベクトルを保存し、質問に近い意味の文書を瞬時に取り出せるようにする基盤で、埋め込みとあわせてRAGの「知識の保管庫」に相当します。
埋め込みモデルにはさまざまな種類があり、扱う言語や文書のドメインに合ったモデルを選ぶことが、検索精度を左右する最初の判断になります。なお、日本語文書を扱う場合は、日本語に対応した埋め込みモデルを選ぶことが前提です。ベクトルデータベースの代表的な選択肢には、専用サービスのPinecone、オープンソースのWeaviate、PostgreSQLの拡張機能であるpgvectorなどがあります。
ベクトルデータベースの選定は、扱うデータ量と運用体制、文書量の増加を見越した拡張性によって変わります。たとえば、すでにPostgreSQLを運用している組織であれば、pgvectorで既存の基盤を活かしながら導入でき、運用負荷を抑えられます。一方で、大規模なデータを高速に扱いたい場合や、運用をマネージドサービスに任せたい場合は、PineconeやWeaviateが選択肢となります。
検索フェーズの中核機能と検索アルゴリズムの選定
検索フェーズは、RAGの回答精度を最も大きく左右する中核工程で、インデックス化した文書群から、ユーザーの質問に関連性の高い箇所を取り出します。検索アルゴリズムは、質問の性質と求める精度に合わせて選びます。ここで的確な文書を取得できなければ、後続の生成フェーズがどれだけ優れていても、正しい回答は得られません。
ベクトル検索とハイブリッド検索の機能
検索アルゴリズムは、意味の近さで探すベクトル検索と、語の一致で探すキーワード検索に大きく分けられます。ベクトル検索は、「同じ意味だが言い回しが異なる」質問に強く、表現の揺れを吸収できる点が利点です。一方で、固有名詞や型番、製品コードのように文字列の一致が求められる質問には弱く、意味だけを頼りにすると特定の単語を含む文書を取りこぼすことがあります。
この弱点を補うのが、キーワード検索とベクトル検索を組み合わせたハイブリッド検索です。このため、語の一致と意味の近さの両面から候補を取得でき、固有名詞にも言い回しの揺れにも対応できます。実証データでは、ベクトル検索のみのF1スコアが56%だったのに対し、ハイブリッド検索にリランキングを加えた構成ではF1スコアが85%まで向上し、約52%の改善が確認されています。
特に、高い回答精度を求めるなら、ハイブリッド検索は標準機能として備えるべき要素です。取得する候補件数を示すTop-Kは重要な調整項目で、小さくすると関連文書を取りこぼし、大きくすると関連性の低い文書が混ざってノイズが増えます。どの値が最適かは文書量や質問の性質によって変わるため、検索結果を確認しながら調整できる構成にしておくのが望ましいといえます。
リランキング機能の必要性
リランキングは、検索で取得した候補を再評価し、本当に関連性の高い文書を上位へ並べ替える機能です。Top-Kを増やすと関連文書を取りこぼしにくくなる一方で、無関係な文書のノイズも混ざり、そのまま生成AIに渡すと回答の精度が下がります。そのため、取得した候補のなかから質の高いものだけを選り分けるリランキングが必要になります。
リランキングを担う機能としては、Cohere Rerankのような専用サービスや、Cross-Encoderと呼ばれるモデルが代表的です。
- 一段目（検索）：質問と文書を別々にベクトル化し、大まかに候補を絞ります。
- 二段目（リランキング）：Cross-Encoderが質問と各候補を一組ずつ突き合わせて、精緻に評価する役割です。
この二段構えにより、まず広めに取得し、次に厳密に絞り込むことで、検索の速度と精度を両立させられます。
リランキングは必須ではないものの、検索の質を一段引き上げたいときに効く機能で、高精度を求めるならハイブリッド検索とセットで検討すべきです。さらに、前述のF1スコア85%も、ハイブリッド検索とリランキングを組み合わせて得られた結果でした。特に、Top-Kを増やしてノイズが気になる場面では、リランキングの追加が有力な選択肢になります。
生成フェーズの機能とプロンプト構築
検索で関連文書を取得したら、次は生成フェーズに進みます。取得した文書とユーザーの質問を組み合わせ、生成AIに回答を作らせる工程です。
ここで必要になるのが、プロンプト構築の機能と、回答を生成する大規模言語モデル（LLM）の基盤です。検索で良い文書を取れていても、その渡し方を誤れば回答の質は下がります。
プロンプト構築機能
プロンプト構築機能は、検索で取得した文書（コンテキスト）と、ユーザーの質問を一つの指示文にまとめる機能です。たとえば「以下の参考文書だけを根拠に回答してください」といった指示を添えることで、文書に基づいた回答へ誘導します。この指示の組み立て方によって、回答が参考文書に忠実になるか、AIの一般知識に流れてしまうかが変わります。
そのため、プロンプトの設計は、ハルシネーション（事実と異なる生成）を抑えるための制御点になります。プロンプトに含める文書量にも配慮が必要です。多くの文書を詰め込めば情報量は増えるものの、LLMが一度に処理できるトークン数には上限があるため、無関係な情報が多いと回答がぼやけます。
プロンプトの設計では、文書の渡し方と根拠の示し方の2点を押さえておく必要があります。
- 文書の渡し方：リランキングで絞り込んだ質の高い文書を、過不足なく渡す設計が望まれます。
- 根拠の明示：出典を提示したい場合は、どの文書から回答を生成したかをプロンプトの構造に組み込んでおくと、回答に根拠リンクを添えられます。
生成LLMの基盤選定
回答を生成するLLMの基盤には、Azure OpenAI ServiceやAWS Bedrockといったクラウドプラットフォームが代表的です。
- Azure OpenAI Service：Microsoftのクラウド環境上でOpenAIのモデルを利用できる基盤です。
- AWS Bedrock：複数のモデル提供元のLLMを共通のインターフェースで扱える基盤で、用途に応じてモデルを切り替えやすい構成を取れます。
Azure OpenAI Serviceは既存のAzure資産と連携しやすい点が特長です。基盤を選ぶ観点は、扱うデータの機密性、既存のクラウド環境、そして必要なモデルの種類です。
社内文書を扱うRAGでは、外部の汎用サービスへデータを送らない構成が求められる場面があります。
Azure OpenAI ServiceやAWS Bedrockのような基盤は、自社のセキュリティ要件と既存基盤に合わせて選ぶことが大切です。
ワークフロー設計と評価フェーズの機能
インデックス化・検索・生成の各機能は、連結したパイプラインとして動かす必要があります。その連結を担うのが、ワークフロー設計の機能です。
構築したRAGがどの程度の精度で動いているかを測る評価フェーズも、品質を支えるうえで欠かせません。
ワークフロー設計機能（Difyの例）
RAGの各処理を視覚的につなぐツールとして、Difyのようなワークフロー設計プラットフォームが使われます。Difyでは、5種類のノードを組み合わせて、検索から生成までの流れを一本のワークフローとして組み立てます。
- 開始：処理の入口。
- LLM：回答を生成する処理。
- IF/ELSE：条件に応じた処理の分岐。
- コード：独自の処理の記述。
- 終了：処理結果の返却。
ノードベースのワークフロー設計の利点は、各処理の役割を画面上で把握できる点です。
IF/ELSEノードを使えば、質問の種類に応じて検索方法を変えるといった分岐処理を組めます。さらに、コードノードを使えば、標準機能では足りない独自の前処理や後処理を差し込めます。
RAGの構成要素を、ノードの組み合わせとして設計できます。そのため、プログラムを一から書く場合より、構築と調整の見通しを立てやすくなります。
評価フェーズの機能（Ragas・DeepEval）
RAGは構築して終わりではなく、回答の質を継続的に測り、改善していく対象です。感覚ではなく数値で品質を捉えられる点が評価フェーズの価値で、RagasやDeepEvalといった評価フレームワークが、その測定を担います。評価指標の代表例は、Ragasが提供するContext PrecisionとFaithfulnessです。
- Context Precision：検索フェーズで取得した文書が、質問に対してどれだけ的確だったかを測る指標です。
- Faithfulness：生成された回答が参考文書の内容にどれだけ忠実かを測る指標で、ハルシネーションの抑制度合いを把握するのに役立ちます。
前者は検索の質を、後者は生成の質を映すため、二つを併せて見ることで、パイプラインのどこに課題があるかを特定できます。
たとえば、Faithfulnessは高いのにContext Precisionが低い場合は、生成は忠実でも検索が的を外していると分かり、チャンキングや検索アルゴリズムの見直しに着手できます。逆に、Context Precisionが高いのにFaithfulnessが低ければ、検索は良いがプロンプト構築や生成側に課題があると判断できます。
評価機能は、RAGの改善サイクルを回すうえで、構築の初期段階から組み込んでおくことが望まれます。
まとめ
ここまで、RAG構築に必要な機能を、パイプラインの流れに沿って一覧にしてきました。
インデックス化フェーズでは、チャンキング戦略と埋め込み生成、ベクトルデータベース（Pinecone・Weaviate・pgvector）が中核です。検索フェーズでは、ベクトル検索・ハイブリッド検索・リランキング（Cohere Rerank・Cross-Encoder）が中核機能となります。
生成フェーズでは、プロンプト構築と生成LLMの基盤（Azure OpenAI Service・AWS Bedrock）が品質を支えます。
ワークフロー設計（Dify）と評価フェーズ（Ragas・DeepEval）も、機能を連携させて品質を支える要素です。
機能選定で押さえておきたいのは、検索精度がRAG全体の品質を大きく左右するという点です。たとえば、実証データでは、ベクトル検索のみのF1スコア56%から、ハイブリッド検索とリランキングを加えた構成では85%へと、約52%改善しました。そのため、回答精度に課題を感じたら、まず検索フェーズの機能構成を見直すのが定石です。
機能を選ぶ際は、すべての機能を最初から盛り込むのではなく、自社の文書量や精度要件、既存のクラウド環境に照らして必要な機能を見極めることが大切です。そのうえで、評価フェーズの指標（Context Precision・Faithfulness）を使って継続的に精度を測り、チャンキングや検索の設定を調整しながら育てていく構成を選ぶことをお勧めします。
ここで整理した機能の全体像を手がかりに、自社のRAGに必要な要素を選んでいただければ幸いです。
▼開発を相談する前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
各資料はリンクからご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。