RAG構築の手順——社内文書を検索して回答するAIの作り方

RAG構築とは、社内文書やFAQを検索し、その検索結果を生成AIに渡して回答させる仕組みを作ることです。単にPDFをAIに読ませるだけではなく、文書の分割、埋め込み、ベクトルDB、検索、プロンプト、出典表示、評価、権限管理までを設計します。本記事では、RAG構築の手順を、概念ではなく実装順で整理し、Dify、Chroma、pgvector、OpenAI APIなどで作る場合の判断軸を扱います。

RAGとは何かという概念整理や、Notion AI・Copilot Studio などSaaS型RAGの製品比較は中小企業のRAG実装——社内データ活用とハルシネーション回避で扱っています。本記事はその先にある「自分たちの手で組む場合の手順」に焦点を当てます。

011. RAG構築の全体手順——8工程で考える

RAG構築は、ツール選定から始めるより、回答品質を決める8工程で考える方が失敗しにくくなります。最初に対象文書を決め、不要文書を除き、見出しや段落でチャンク分割し、埋め込みモデルでベクトル化し、ベクトルDBに保存します。利用者の質問が来たら、質問もベクトル化して類似文書を検索し、その結果をプロンプトに入れて回答を生成し、最後に出典と評価ログを残します。

中小規模の社内検索なら、DifyやFlowiseのようなノーコード基盤に、Chroma、pgvector、Pinecone、Azure AI SearchなどのベクトルDBを組み合わせる構成が現実的です。最初からフルスクラッチにするより、質問ログを集めて「どの文書が足りないか」「どのチャンクが拾えていないか」を確認し、必要になった範囲だけ実装を深くする方が堅実です。

中核になる選定理由は、Difyがオープンソースのまま自社サーバーにも乗せられること、Chromaが組み込み型でDB運用負荷が極小であること、gpt-4o-miniが入力100万トークンあたり0.15ドル・出力0.6ドルと小規模運用の経済性を担保していることの3点です。Pinecone のような専用ベクトルDBやLangChain によるフルスクラッチ実装は、後から必要に応じて差し替えれば良く、最初から重い構成を組むほうが頓挫リスクは高くなります。

拡大

コスト内訳の現実

社員30名・1日200質問・1質問あたり平均3,000入力トークン／500出力トークンの想定で試算すると、gpt-4o-miniの月額APIコストは概算1.5万円前後に収まります。これに OpenAI Embeddings（text-embedding-3-small、100万トークン0.02ドル）の文書取り込み時の一括処理が初回数千円、Dify ホスティング（自社サーバーまたはDify Cloud Sandbox）が月額0〜3万円、Chromaは自社サーバー同居でゼロ円というレンジになります。合算すると3〜7万円帯で、構成にPineconeなどマネージドDBを足すと7〜10万円帯に上がります。

業界相場として、ベンダー実装のフルスクラッチRAG構築は数百万〜1,000万円規模、月次のランニングは5〜20万円が多いと整理されており、自分たちで最小構成を組む選択肢のコスト優位性は大きい構造です。

出典：OpenAI API 公式料金／Dify 公式ドキュメント／Chroma 公式ドキュメント。

022. ベクトルDB選定——pgvector・Chroma・Pineconeの分水嶺

中小企業のRAG構築でベクトルDBを決めるとき、判断軸は「想定チャンク数」「既存DB資産」「マネージド志向」の3つに集約されます。数千〜数万チャンク規模で既存にPostgreSQLが動いていれば pgvector、PoCで素早く立ち上げたいなら Chroma、運用を任せて事業に集中したいなら Pinecone Serverless というのが2026年5月時点の現実的な選定パターンです。

ベクトル次元数は OpenAI の text-embedding-3-small で1,536次元、text-embedding-3-large で3,072次元、Cohere embed-multilingual-v3 で1,024次元といったレンジで、いずれのDBもこの規模では実装上の差は限定的です。性能差より、運用負荷と既存資産との接続性で選ぶほうが中小企業には合理的です。

pgvectorが中小企業に効く理由

社員数十名〜数百名規模で1社あたり数千〜数万チャンクが現実的なボリュームで、この規模では pgvector のレイテンシ・精度はPineconeと体感差がほぼありません。既に Supabase や Neon、AWS RDS を使っている組織であれば、追加サービスを増やさずに同じDB管理画面で運用でき、バックアップ・権限管理・障害対応の手順も既存運用に統合できます。新しいSaaSを増やすことのIT管理コストは、中小企業では月額数千円のSaaS費用以上に重い構造があります。

Pinecone Serverlessを選ぶ場面

検索レイテンシが厳しい（顧客向けチャット）、チャンク数が数十万を超える、複数リージョン展開が必要、といった要件が出てきた段階でPinecone Serverlessが現実解になります。Serverlessプランは保存量と読み取り量の従量課金で、小規模利用なら月数千円から始められるため、PoC段階でも採用可能な価格設計です。ただし「将来必要になるかもしれない」という理由で最初から採用する判断は、運用負荷とベンダーロックインのリスクを増やすだけで、PoC段階では避けるのが定石です。

出典：pgvector GitHub／Pinecone 公式料金／Qdrant 公式料金。

033. チャンク分割と埋め込みモデル——精度を決める2つの実装判断

RAGの回答精度は、ベクトルDBの選定よりもチャンク分割（chunking）と埋め込みモデル（embedding model）の組み合わせで決まります。日本語の社内文書では、500〜1,000文字を上限に意味単位で区切り、隣接チャンク間で50〜100文字のオーバーラップを取る再帰的分割が起点になります。

固定長で機械的に区切ると、文の途中で分割されて文脈が失われたり、見出しと本文が別チャンクに分かれて検索結果から外れたりします。LangChainの RecursiveCharacterTextSplitter や LlamaIndex の SentenceSplitter のように、改行・句点・段落の境界を優先する分割器を使い、Markdown形式の文書では MarkdownHeaderTextSplitter で見出し階層を保持するのが、日本語社内ナレッジでは現実的な実装です。

埋め込みモデル選定——OpenAI vs Cohere vs オープンソース

中小企業のRAGで最も無難な選択は OpenAI の text-embedding-3-small（100万トークン0.02ドル、1,536次元）です。日本語と英語の混在文書で十分な精度が出て、APIのみで完結する運用負荷の軽さが効きます。多言語業務や特定領域に特化したい場合は Cohere の embed-multilingual-v3（100万トークン0.10ドル）が選択肢に上がり、データを外部に出したくない要件ではオープンソースの multilingual-e5-large や intfloat/multilingual-e5-base を自社GPUで動かす選択肢もあります。

text-embedding-3-largeは精度が一段上がりますが、料金が5倍（100万トークン0.13ドル）でベクトル次元が3,072になるためベクトルDBのストレージ消費も増えます。中小企業のRAGで最初に小モデルから始め、精度に不満が出てから大モデルに切り替える順序が、コストと精度のバランスを取りやすい設計です。

検索品質を底上げするハイブリッド検索

ベクトル検索だけでは固有名詞や型番（商品コード・社内ID）の一致が弱く、キーワード一致のBM25と組み合わせるハイブリッド検索を実装すると精度が一段上がります。Difyでは標準機能として、Qdrantではネイティブ機能として、pgvectorでは tsvector との組み合わせで実装可能です。「請求書番号 INV-2024-0512 の対応履歴」のような固有名詞中心の質問が多い社内ナレッジでは、ハイブリッド検索の導入が体感差を生む現実があります。

出典：LangChain Text Splitters／OpenAI Embeddings Guide／Cohere Embeddings。

044. 実装ステップ——1〜2週間で社内検索を立ち上げる進め方

ここから3つの章は、上位記事の概念解説や製品比較を超えて、中小企業がRAGを実装に落とすときの実務レイヤーの切り口を提示します。最初に整理するのは、最小構成での実装ステップです。

Dify＋Chroma＋OpenAI APIの構成では、社員30〜50名規模の社内検索なら準備に1週間、運用テストに1〜2週間という時間軸が現実的です。「3ヶ月かけて完璧な要件定義をする」アプローチより、最小スコープで動かして使いながら磨くほうが、中小企業の組織体力に合います。

「分からない時は分からないと答える」プロンプト設計

RAG実装で最も見落とされるのが、LLMに「参照源にない情報は推測せず分からないと回答する」と明示するシステムプロンプトです。これがないと、社内文書に該当箇所がなくてもLLMは一般知識で埋めてしまい、社員は「RAGが答えているのに間違っている」と誤解します。プロンプトには、参照したチャンクのみから回答する制約、出典のファイル名と該当箇所の明示、信頼度が低い場合は人間に確認を促す挙動を明文化するのが必須です。

社内パイロットで見るべき3指標

正式リリース前の社内パイロットでは、(1)回答精度（5段階の人手評価で平均4.0以上が目安）、(2)応答時間（質問送信から回答完了まで10秒以内）、(3)カバー率（実際の質問のうちRAGで回答できた割合、60%以上が立ち上げ初期の目安）の3指標で判定します。カバー率が低い場合は、対象文書の追加よりも質問パターンの分析（よくある質問が文書に書かれていない）が真因のことが多く、文書整備の優先順位付けに使えます。

出典：Dify Docs／Flowise 公式。

055. 内製と外注の分水嶺——中小企業が判断するための4軸

RAG構築を内製で進めるか外注するかの判断は、組織のIT人材・対象データ規模・業務インパクト・運用継続性の4軸で整理できます。社員30〜100名規模・社内ナレッジ検索が目的・既存のSaaSと組み合わせて運用する、というシナリオでは内製（ノーコード基盤＋自社運用）が現実解で、外注は限定的なスコープに留めるのが効率的です。

内製で進める場合のチーム構成

内製でRAG構築を進める場合、IT担当者1名（Python基礎・SQL・SaaS管理ができる）と、業務側のオーナー1名（対象文書の選定・回答品質のレビューができる）の2名体制が最小単位です。ノーコードのDifyを使えば、IT担当者の専任度は週1〜2日で済み、業務側オーナーが回答品質の管理を主導する役割分担になります。専任のAIエンジニアを採用する必要はなく、既存の情シス・DX推進担当の業務範囲で十分賄える構造です。

外注スコープを限定する設計

外注を入れる場合でも、丸ごと委託せずに「初期構築のみ外注、運用は内製」「インフラ構築のみ外注、プロンプト調整は内製」のようにスコープを限定するのが、運用負荷とコストの両方を抑える定石です。中小企業向けの本格RAG構築の業界相場は要件定義からPoCまで数百万円、本番稼働まで500〜1,000万円超のレンジが多く、すべてを外注すると初期費用が膨らみます。FULLFACTでは、社内ナレッジの棚卸しから内製・外注スコープの設計まで、中小企業の実情に合わせて伴走しています。

業務全体のAI活用の俯瞰は中小企業の生成AI活用4領域、Microsoft 365基盤の組織であれば中小企業のMicrosoft Copilot、実用に値するAIツールの全体選定軸は実用に値するAIツールで整理しています。

出典：AQUA「中小企業向けRAG構築ガイド」／ripla「RAG開発・構築のコストと費用の相場」。

066. 構築後の運用設計——精度を維持する3つの運用ループ

RAGの精度は構築完了時点が最高で、運用とともに低下していくのが構造的な特徴です。社内文書が更新されないまま参照され続ければ、半年も経たないうちに古い情報を返すRAGに退化します。中小企業が精度を維持するには、ナレッジ更新・利用ログ分析・プロンプト調整の3つのループを月次〜四半期で回す運用設計が必要です。

ナレッジ更新ループ

社内文書の更新タイミング（規程改訂・FAQ追加・新製品リリース）に合わせて、RAGの参照ソースを再取り込みする運用が起点です。Difyでは外部DataSource接続でNotion・Google Drive・SharePointの更新を自動同期する機能があり、文書管理基盤と一体化させると更新漏れが減ります。手動運用の場合は、月1回の棚卸しを業務側オーナーの定例業務に組み込むのが現実解です。

利用ログ分析ループ

「どの質問にRAGが答えられなかったか」「どの回答に低評価がついたか」のログを分析し、対象文書の追加・修正・分割粒度の見直しに反映します。Difyには会話履歴のエクスポート機能があり、月次でCSVを抽出して傾向分析するだけでも、文書整備の優先順位が大きく変わります。「精度が低い」と感じたときに最初にやるべきは、モデル変更でもベクトルDB変更でもなく、利用ログの分析です。

プロンプト調整ループ

新しい質問パターンが出てきたとき、システムプロンプトの調整で対応できる範囲は意外に広く、文書を増やすより先に試す価値があります。「専門用語を社内用語に置き換えて回答する」「回答の最後に関連する別文書を3件提案する」のような挙動は、プロンプトのテンプレート修正で実装でき、ベクトルDB側の変更は不要です。

出典：Dify Datasets 機能。

077. 結論——中小企業のRAGは「最小構成で始め、運用で磨く」が現実解

中小企業のRAG構築は、最小構成で素早く立ち上げ、運用で磨きながら必要な範囲だけ拡張する進め方が、組織体力と事業インパクトの両面で合理的です。本記事の骨子を整理すると、次の3点に集約されます。

1. 最小構成はノーコードDify＋Chroma/pgvector＋OpenAI APIで月3〜7万円・1〜2週間。最初から本格構築（Pinecone+LangChain）に踏み込むより、最小構成で動かして使いながら判断するほうが頓挫しにくい。
2. ベクトルDBは規模と既存資産で選ぶ。数千〜数万チャンクならpgvectorかChromaで十分、Pinecone Serverlessは検索レイテンシや規模要件が出てから採用する。
3. 精度を決めるのはチャンク分割と運用ループ。500〜1,000文字の意味単位分割、ハイブリッド検索、月次のナレッジ更新と利用ログ分析の3点が、構築後の精度維持に直結する。

RAGは「導入すれば終わり」ではなく、社内ナレッジの整備・更新・運用と一体化させて初めて業務に効く仕組みです。技術選定よりも、対象文書の棚卸しと運用設計のほうに、中小企業の成否は大きく依存します。

FULLFACTでは、中小企業の経営層・現場責任者と一緒に、社内ナレッジの棚卸しから最小構成RAGの設計、内製と外注スコープの判断まで伴走しています。軽い課題なら数週間で論点が見えることもあり、構造的な再設計が必要なら腰を据えて磨き込みます。スコープと進め方は貴社のペースで。

08よくある質問

RAGを中小企業が構築する最小費用はいくらか？

ノーコードの Dify＋Chroma＋OpenAI API（gpt-4o-mini中心）の構成なら、初期費用ゼロ、月間ランニング3〜7万円程度から立ち上げられます。社員30名・1日200問程度の社内検索なら、API利用料・ベクトルDB・ホスティングを合わせて月5万円前後が現実的なレンジです。

ベクトルDBは何を選べばよいか？

PoC段階は組み込み型のChromaかQdrant、本番に持ち込むならPinecone Serverless（月数千円〜）かAzure AI Searchが定番です。中小企業の数千〜数万チャンク規模なら、PostgreSQL拡張のpgvectorで十分賄え、既存のSupabaseやNeonに乗せれば追加サーバーも不要です。

ノーコードツール（Dify、Flowise）と自前実装はどちらが現実的か？

社員30〜100名規模で社内ナレッジ検索が目的なら、まずノーコードのDifyかFlowiseでPoCを組むのが現実的です。顧客向けに独自UIで提供する、複数システムを跨ぐ複雑な検索ロジックを実装する、といった要件が出てきた段階で、LangChainやLlamaIndexによる自前実装に移行します。

チャンク分割（chunking）はどう設計するか？

日本語の社内文書では、500〜1,000文字を上限に意味単位で区切るのが起点になります。固定長で機械的に切ると文の途中で分割されて精度が落ちるため、見出し・段落・箇条書きの境界で区切る再帰的分割（recursive chunking）を採用し、隣接チャンク間で50〜100文字のオーバーラップを持たせるのが定石です。

RAG構築を外注すべき場合はどんな状況か？

顧客向けに独自UIで提供する、既存基幹システム（販売管理・ERP）と統合する、業界特化の専門用語が多くSaaS型では精度が出ない、社内に開発リソースが全くない、のいずれかに該当する場合です。中小企業向けの本格構築の業界相場は数百万〜1,000万円超のレンジで、判断は事業インパクトとの照らし合わせが前提になります。