RAG構築の進め方｜4工程の手順・チャンク設計・動作確認まで【2026年8月】
結論: RAG（Retrieval-Augmented Generation）は、LLMに社内ドキュメントを参照させる技術であり、「LLMを再学習させる」のではなく「必要な文書を検索してから回答を生成する」仕組みです。この記事では、社内RAGを動かすまでの4工程（①チャンク分割・②embedding（＝テキストを数値に変換する処理）生成・③ベクトル（＝意味を数値の配列で表したもの）DB保存・④検索とreranking（＝検索結果の並べ直し））と、精度改善の考え方、ローカルとクラウドの選択基準、内製か外注かの判断フローを順に書きます。
この記事の要点
- RAGはRetrieval-Augmented Generationの略で、外部データを検索（Retrieve）してLLMの回答生成（Generate）を補強（Augment）する手法。LLMの学習データにない社内固有の情報を、文書を参照しながら事実に基づいて回答させるために使う（AWSをはじめ各クラウドプロバイダーが公式ページで解説している）
- LangChain公式が文書化している標準パイプラインはドキュメント読み込み・チャンク分割・embedding・ベクトルDB保存・検索・回答生成の流れに沿っており、この記事ではこれを4工程に整理して解説する
- 精度を左右するのは、チャンク（＝ドキュメントを検索しやすく切り分けた小さなまとまり）設計とembeddingモデル（＝テキストを意味を保ったベクトルに変換するAIモデル）の選択。ベクトルDBやrerankingはこの2つが整った後に最適化する
- pgvector（PostgreSQLへのベクトル検索拡張機能・PostgreSQLライセンス（＝無料で商用利用できるオープンソースの利用許諾））を使えば、既存のPostgreSQLをそのままベクトルDBとして使えるため、新たにDBを立てるコストと運用負荷を省ける
- 外注を検討する場合は、まず「RAGが自社の課題に合う手法かどうか」を切り分けることが先決。費用の目安はAI受託開発の費用相場で整理している
この記事は、社内ドキュメントをAIに検索させたい中小企業の情シス・DX担当・技術顧問に向けて書いています。「RAGをどう構築するか・内製か外注か・どこから始めるか」を決める材料です。対話型AIサービスを使える状態にあり、RAGを知った上で次の一歩を探している方が対象です。AIエージェント全体の仕組みやMCPとの違いはこの記事の範囲外です。RAGはエージェント構築の部品の一つでもあり、全体の作り方はAIエージェントの作り方｜非エンジニアの5ステップに書きました。
今日やることは1つです。まず「内製か外注かの判断基準」の節を読んでください。「Pythonエンジニアの有無」と「対象文書の整理状態」の2点で方向が決まります。決まったら、この記事の「4工程と必要なもの一覧」の表を見て、自社のドキュメントに当てはめてください。
RAG構築の全体像｜4工程と必要なもの一覧
RAGを動かすには、準備段階（工程①〜③）と利用段階（工程④）があります。準備段階は一度だけ実行すればよく、利用段階は質問のたびに動きます。この違いが分かると、計算コストがどこにかかるかも見えてきます。
RAG構築の4工程：準備段階で索引を作り、利用段階で検索・生成を回す
図の内容: 準備段階でドキュメントをチャンク分割・ベクトル変換してDBに保存し、利用段階では質問をベクトル化してDBを検索し、候補をrerankingで絞り込んでLLMに渡す。
準備段階の3工程を終えると、ベクトルDBに「意味で検索できる索引」ができあがります。利用段階では、ユーザーの質問をベクトルに変換し、索引から意味的に近いチャンクを引き出してLLMに渡します。LLMはチャンクの内容を根拠に回答を生成するので、学習データ外の情報でも事実に基づいた答えが返ります。
4工程に必要な主なコンポーネント（＝部品）と代表的な選択肢は次の表のとおりです。
| 工程 | コンポーネント | 役割 | 代表的な選択肢 |
|---|---|---|---|
| ① チャンク分割 | テキスト分割ライブラリ | ドキュメントを検索に適した単位に切り分ける | LangChainのTextSplitter（文字数・トークン数・見出し/HTML構造での分割に対応。意味ベースの分割は別パッケージ）、カスタム実装 |
| ② embedding生成 | embeddingモデル | テキストを意味を保ったベクトルに変換する | OpenAIのembeddingモデル、multilingual-e5シリーズ、クラウドプロバイダーの日本語対応モデル |
| ③ ベクトルDB保存 | ベクトルデータベース | ベクトルを保存し高速に類似検索する | pgvector（PostgreSQL拡張）、クラウドマネージドサービス、専用ベクトルDB |
| ④ 検索・reranking | 検索エンジン＋rerankモデル | 候補を絞り、精度の高い上位チャンクをLLMに渡す | ベクトル検索＋クロスエンコーダー、BM25ハイブリッド検索 |
確かめ方: 外注先や社内のエンジニアに「4工程のどの部品を何で実装しますか」と聞いてください。工程①〜④の区別が回答に入っているかを見てください。区別なく「まるごとやります」だけなら要注意です。
工程①｜チャンク分割の考え方と設定基準
チャンク分割とは、社内ドキュメントを検索しやすい小さなまとまりに切り分ける工程です。チャンクの設計が粗いと、正しい情報がDBに入っていても検索で引き出せなくなります。
分割が必要な理由は、LLMに渡せる情報量（コンテキストウィンドウ）に上限があるからです。全ドキュメントをそのまま渡せません。ドキュメント全体を1つのベクトルにすると「全体の平均的な意味」になり、特定の箇所を探す精度が落ちます。適切な粒度に分割することで、質問に関連する部分だけを正確に引き出せるようになります。
チャンク設計で決める主な要素は、チャンクサイズとオーバーラップです。チャンクサイズは「1つのまとまりに含めるテキストの量」、オーバーラップは「隣り合うチャンクが重なる部分の量」を指します。オーバーラップを設けることで、チャンクの切れ目で文脈が途切れるリスクを減らせます。
分割手法には大きく3種類があり、文書の性質によって使い分けます。
| 分割手法 | 仕組み | 向く文書 | 注意点 |
|---|---|---|---|
| 文字数・トークン数で分割 | 一定の文字数またはトークン（＝AIが数える文字の単位。日本語1文字が1〜3トークンになる）数で機械的に切り分ける（LangChainのTextSplitter・TokenTextSplitterが代表） | 均質な構造の文書（CSVのレコード形式、定型フォームなど） | 文の途中で切れる場合があるため、センテンスの境界を考慮したオーバーラップが重要 |
| セマンティック分割 | 意味的なまとまり（段落・セクション・見出し）を単位として切り分ける（AI言語モデルの一種を使ったセマンティック（＝意味のまとまりで区切る）分割も選択肢） | マニュアル・レポート・議事録など、見出しや段落構造がある文書 | 文書のフォーマットが整っていないと効果が出にくい。前処理で構造を整えておく |
| ハイブリッド分割 | 見出しや段落でまず大きく分け、その中でさらにトークン数で分割する | 長いマニュアルや規程集など、階層構造を持つ文書 | 実装が複雑になるが、精度は高くなりやすい |
エンジニア向けの参考情報です。外注する場合はこの設定値を相手に確認してください。separators には「段落の区切り→改行→句点→読点」の順に分割の優先順位を設定しています。LangChainでTextSplitter・TokenTextSplitterを使う場合の実装イメージです。日本語文書では当社が chunk_size=500（文字数）・chunk_overlap=50 を起点として置いています。実際に質問10件を投げ、回答を見ながらサイズを見直します。なお、トークン分割（TokenTextSplitter）には tiktoken の導入が要ります。
from langchain_text_splitters import RecursiveCharacterTextSplitter, TokenTextSplitter
# 文字数ベース（日本語文書の起点となる設定例）
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=500, # チャンクサイズ（文字数）
chunk_overlap=50, # オーバーラップ（文字数）
separators=["\n\n", "\n", "。", "、", ""] # 分割の優先順位
)
chunks = text_splitter.split_text(document_text)
# トークン数ベース（LLMのコンテキスト上限に合わせて管理したいとき）
token_splitter = TokenTextSplitter(
chunk_size=256, # チャンクサイズ（トークン数）
chunk_overlap=30 # オーバーラップ（トークン数）
)
token_chunks = token_splitter.split_text(document_text)設定後は「よく使われる質問10件」を実際に投げてみます。正しい情報がどのチャンクに入っているかを確認した上で、その情報が検索結果の上位に返ってくるかを見てください。返ってこない場合は、チャンクサイズかオーバーラップの調整が先決です。外注先に相談する際は、「チャンクサイズとオーバーラップをどう決めるか」の根拠を確認すると、RAG設計の経験の有無が分かります。
工程②｜embeddingモデルの選び方
embeddingモデルとは、テキストを意味を保ったベクトル（＝数値の配列）に変換するモデルです。「社長の承認が必要な経費はいくらからですか」という質問と「経費申請の上限金額」という文書は、表現は違っても意味が近い関係にあります。embeddingモデルが両者を似たベクトル空間（＝似た意味のテキストが近い位置に並ぶ数値の地図のようなもの）に配置するため、この引き合わせが成り立ちます。
モデル選択の判断軸は「精度・次元数・日本語対応・コスト」です。次元数（＝1つのテキストを表す数値の個数）はモデルによって異なります。次元が大きいほど意味表現は細かくなりますが、ストレージと検索コストも上がります。次元数はエンジニアが決める項目です。精度とコストのバランスを開発担当と確認してください。
| モデルの系統 | 代表モデルと次元数 | 日本語対応 | コスト感 |
|---|---|---|---|
| OpenAI embeddingモデル | text-embedding-3-small（標準で1,536次元）/ text-embedding-3-large（標準で3,072次元）。dimensions パラメータで次元数を短くでき、公式ドキュメントは text-embedding-3-large を256次元まで縮められると記載 | 対応（英語より精度が下がる場合あり） | API（＝外部のサービスをプログラムから呼び出す窓口）の従量課金。処理量が増えると費用が積み上がる |
| multilingual-e5シリーズ | multilingual-e5-base（768次元）/ multilingual-e5-large（1,024次元）。xlm-roberta由来の100言語に対応（低リソース言語は精度が落ちる場合がある）。ローカルで動かせるためクラウドに情報を出せないケースで選ばれる（HuggingFace公式モデルカード） | 良好。多言語検索を想定して学習されている | ローカル実行なら推論コストのみ。GPUがあれば低コストで動かせる |
| クラウドプロバイダーのマネージドサービス | クラウドインフラとの統合が容易。セキュリティ設定やアクセス制御がプロバイダー側で提供される | プロバイダーによって異なる | マネージドサービスの料金体系に依存 |
精度の比較にはMTEB（Massive Text Embedding Benchmark）が参考になります。検索・分類・クラスタリング・意味的類似度・rerankingなどのタスクで埋め込みモデルを比べる公開ベンチマーク（＝性能比較テスト）です。日本語タスクのスコアはモデルによって差があるため、自社の文書に近い日本語タスクでのスコアを確認するようエンジニアに依頼してください。次元数が大きいほどストレージとクエリ速度の負担は増えるため、扱う文書量や応答速度の要件が厳しい場合は、スコアと次元数をセットでエンジニアに確認してモデルを選んでください。
重要な制約が1つあります。embeddingモデルを途中で変更すると、ベクトルDBに保存したすべてのデータを作り直す必要があります。 ベクトルの空間はモデルごとに異なります。モデルAで作ったベクトルにモデルBの質問を混ぜると、正しく検索できません。モデルの選択は最初に固めておき、途中で変えないことを前提に設計してください。外注先には「このembeddingモデルを選んだ理由と、モデルを変更する場合のデータ移行コスト」を確認することをお勧めします。この2点を即答できるなら、embeddingの制約を理解した設計ができています。
工程③｜ベクトルデータベースの選択と保存
ベクトルDBは、embeddingで変換したベクトルを保存し、類似検索（＝意味的に近いものを高速に探す検索）を行うデータベースです。選択肢は大きく「PostgreSQL拡張型」「クラウドマネージド型」「専用ベクトルDB型」の3種類に分かれます。コスト・運用負荷・スケール（＝利用量の増減に合わせてシステムの規模を変えること）で選びます。
| 種別 | 代表例 | コスト | 運用負荷 | スケール |
|---|---|---|---|---|
| PostgreSQL拡張型 | pgvector（PostgreSQLライセンス・pgvector公式GitHub） | オープンソースで追加費用なし。PostgreSQLのホスト費用のみ | 既存のPostgreSQLに拡張を追加するだけ。既存の運用フローに乗せやすい | 大規模な同時検索には専用チューニングが必要。中小規模のRAGには十分 |
| クラウドマネージド型 | クラウドプロバイダーのマネージドベクトル検索サービス（複数の主要プロバイダーが提供） | 使った分だけの従量課金。初期費用ゼロ | インフラ管理不要。セキュリティ・スケールアップはクラウド側が担う | オートスケールで大規模にも対応。ただしコストが読みにくい |
| 専用ベクトルDB型 | ベクトル検索に特化したSaaSサービス（有料プランが多い） | 有料プラン中心。無料枠あり | ベクトル検索に最適化された設計で、導入後の調整が少ない | 大規模検索・高頻度アクセスに強い |
既存のシステムでPostgreSQLを使っている会社は、pgvectorから始めるのが早道です。pgvectorはPostgreSQLライセンスのオープンソース拡張で、PostgreSQLにベクトル類似検索機能を追加します（pgvector公式GitHubより）。DBをもう1つ立てることなく、ベクトル検索をすぐに試せます。
pgvectorでテーブルを作る際の基本的なDDL（＝テーブル定義のSQL）を示します。エンジニア向けの参考情報です。外注する場合は「メタデータ列を設けてほしい」という要望で伝えてください。VECTOR(1536) の次元数は選んだembeddingモデルの出力次元数に合わせます。メタデータ列（文書名・部門コード・更新日）を最初から設けておけば、アクセス制御や日付の絞り込みがSQLのWHERE句だけで済みます。
-- pgvectorの有効化
CREATE EXTENSION IF NOT EXISTS vector;
-- チャンクとembeddingを保存するテーブル
CREATE TABLE document_chunks (
id SERIAL PRIMARY KEY,
content TEXT, -- チャンクの本文
embedding VECTOR(1536), -- embeddingベクトル（モデルの次元数に合わせる）
doc_name TEXT, -- メタデータ: 文書名
dept_code TEXT, -- メタデータ: 部門コード（アクセス制御用）
updated_at DATE, -- メタデータ: 文書の更新日
created_at TIMESTAMP DEFAULT NOW()
);
-- ベクトル検索用インデックス（IVFFlat: 近似最近傍・大規模データに向く）
-- インデックスはチャンクを投入してから作る（pgvector公式）
CREATE INDEX ON document_chunks
USING ivfflat (embedding vector_cosine_ops)
WITH (lists = 100); -- listsは100万行までは行数÷1000、100万行超は√(行数)が出発点（pgvector公式）
-- メタデータフィルタリングの例（人事部門の文書のみ検索）
-- WHERE dept_code = 'HR' AND updated_at >= '2026-01-01'一方、社内情報のクラウド保存が難しい場合は、pgvectorをオンプレミス（＝自社のサーバー室で動かすこと）またはプライベートクラウドで動かすことで、情報をクラウドに出さずにベクトル検索を実現できます。外部のデータ連携手法との比較は、MCPとは｜3つの部品と10言語SDK・接続前の確認3点も参考になります。
確かめ方: 「なぜこのベクトルDBを選んだか、将来チャンク数が10倍になった場合の対応策はありますか」と聞いてください。スケール時の対策を持っているかで、設計の先読みが分かります。
工程④｜検索・reranking・回答生成のフロー
ベクトル検索で候補をN件取り、そのままLLMに渡すのではなく、rerankingで上位K件（K＜N）に絞ってから渡します。rerankingとは、ベクトル検索で取得した候補チャンクを再評価して、より関連性の高い順に並べ直す工程です。
ベクトル検索だけだと、「意味的に近い」チャンクを広く拾いすぎがちです。LLMに渡せるコンテキストの量には上限があるため、候補を絞り込んでから渡す方が回答の精度は上がります。rerankingはその絞り込みを担う工程です。
例を挙げます。「経費精算の上限金額を教えてください」という質問でベクトル検索をかけると、「経費申請フロー」「交通費規程」「上限金額一覧」「精算ソフトの操作手順」などが一緒に返ってきます。意味的に近いチャンクを広く拾うためです。rerankingモデルは質問とチャンクを直接比較して関連性スコアを再計算します。「上限金額一覧」を上位に引き上げ、「操作手順」を下位に落とせます。この絞り込みを経てLLMに渡すことで、的外れな情報を根拠にした回答が減ります。
rerankingで候補を絞り込んでからLLMに渡すことで、回答精度が上がる
図の内容: ベクトル検索でN件を取得し、rerankモデルで再スコアリングして上位K件（K＜N）に絞り込み、LLMに渡して回答を生成する。
RAGの有無で回答がどう変わるか、例を見てください。社内の育児休業規程を検索対象にした場合の例です。
| 項目 | RAGなし（LLMのみ） | RAGあり（社内規程を参照） |
|---|---|---|
| 質問 | 育児休業制度の対象期間は？ | 育児休業制度の対象期間は？ |
| 回答の内容 | 「取得できる期間は会社の規程によって異なるため、人事部門にご確認ください」 | 「育児休業規程第〇条により、子が〇歳に達する日まで取得可能です。延長の条件は同条第〇項に定めがあります」 |
| 問題点 | LLMの学習データに基づく一般論。自社固有の期間・延長制度・条番号が回答に含まれない | 実際の条番号・期間・条項を根拠にした回答。担当者への問い合わせが不要になる |
RAGなしの状態では「会社の規程によって異なる」と回答するしかなく、社内問い合わせが発生します。RAGを組むことで、社内規程の最新版を参照した具体的な回答が自動で出るようになります。（表内の〇は自社規程の値に置き換える箇所です）
rerankingの主な手法を比較します。
| 手法 | 仕組み | 精度 | 処理コスト |
|---|---|---|---|
| クロスエンコーダー（＝質問と候補文を対にして関連度を測るAIモデル） | 質問とチャンクを同時に入力して関連性スコアを算出する。ベクトル検索より文脈を深く見る | 高い | 候補件数が増えるほど処理時間が増える |
| LLMベース | LLM自身に「この質問に関連が高い順に並べて」と指示して再評価する | 高い | LLMのAPI呼び出しコストが増す |
| BM25（＝単語の一致度で点数をつける古典的な検索手法）ハイブリッド | ベクトル検索とキーワード検索（BM25）の結果を組み合わせてスコアを出す | 中程度（専門用語・固有名詞に強い） | 計算コストは低め。実装がシンプル |
最初からrerankingを入れる必要はありません。ベクトル検索の精度で十分なケースも多いです。「検索結果は返ってくるが、回答が的外れ」という状態が続いてから、rerankingを足すのが無駄のない順番です。
確かめ方: 「rerankingを実装しますか。しない場合は、ベクトル検索の結果をそのまま何件LLMに渡しますか」と聞いてください。件数と理由を答えられるかで、コストと精度のトレードオフを理解しているかが分かります。
精度を上げる7つの改善手法
RAGを動かし始めたら、実際に使いながら精度を上げていきます。精度改善は一発で完成せず、試して確かめる繰り返しです。発注側が要求してよい条件として整理した改善手法を7つ挙げます。
① チャンクサイズとオーバーラップの調整
「答えが途中で切れる」「関係ない情報が混じる」という場合はチャンクサイズが合っていません。答えが切れるならサイズを大きく、関係ない情報が混じるならサイズを小さくする方向で調整します。オーバーラップを増やすと文脈の連続性が上がりますが、保存するデータ量も増えます。調整の際は「よく使う質問10件」を基準にして、ビフォー・アフターで比べます。
② メタデータの付与
チャンクにメタデータ（文書名・更新日・部門名・文書種別など）を付けると、検索時の絞り込みが利きます。「人事部門の規程だけ探す」「2026年以降に更新した文書だけ参照する」といった使い方です。特に文書の種類が混在している場合（規程・議事録・製品仕様書が同じDBに入っている場合など）に効果が高いです。
チャンクに「閲覧対象」「部門コード」「役職区分」のメタデータを付けると、ロールベースのアクセス制御も同じ仕組みで実現できます。「管理職向け規程を一般社員の検索から外す」「人事部門の文書は人事部員にだけ返す」といった絞り込みを、メタデータフィルターで設定できます。社内文書に閲覧制限があるなら、チャンク設計の段階でアクセス区分をメタデータに入れておくことが欠かせません。
③ HyDE（仮説文書生成）の活用
HyDE（＝質問に対する仮の答えを先に作り、その仮の答えで検索する手法。Hypothetical Document Embeddingsの略）は、まず「仮の回答文書」をLLMに生成させ、その仮文書のembeddingで検索をかけます。質問文と答えが書かれた文書はベクトル空間で離れやすい一方、仮の回答文書と実際の文書は近くに並びます。この性質を利用した手法です。実装コストがかかるため、基本的な精度改善を試した後のステップとして検討します。
④ サブクエリ分割
「Aの費用とBの費用を比べたい」のような複合的な質問は、検索の精度が落ちやすいです。LLMに質問を複数のサブクエリ（＝元の質問を分解した小さな質問）に分解させ、それぞれで検索してから結果をまとめる方法が有効です。
例として「交通費と宿泊費の精算ルールと、それぞれの上限金額を同時に教えてください」という質問を考えます。単一クエリのままベクトル検索すると、両方の情報が混在した結果が返りやすくなります。サブクエリ分割を使うと、LLMが①「交通費の精算ルールと上限金額」②「宿泊費の精算ルールと上限金額」に分解します。それぞれ独立に検索してから結果を統合します。複雑な質問が多い業務用途（稟議書の比較・複数製品の仕様比較など）で検討します。
⑤ ハイブリッド検索
ベクトル検索は意味的な近さを捉えますが、製品名・型番・法令番号のような固有名詞の一致は苦手です。キーワード検索（BM25等）と組み合わせれば、両方の強みを活かせます。専門用語や固有名詞が多い技術系ドキュメントや法令・規程の検索で効果が高いです。
⑥ 会話履歴の管理
チャットUI付きのRAGでは、前の発言を前提にした質問が来ます。「さっきの話に戻りますが」「それは2023年の規程ですか、今年の規程ですか」などです。直前のやりとりを保存して次の検索クエリに含める設計がないと、文脈が切れた回答になります。直近N件の会話履歴をDBに保存し、検索クエリと合わせてLLMに渡すのが基本の構成です。履歴が長くなるほどコンテキストを消費します。要約してから渡す方式と組み合わせれば効率よく処理できます。
⑦ RAGの評価（RAGAS）
精度改善を進めるには、「何がどのくらい改善したか」を測る手段が必要です。RAGAS（＝LLMアプリの評価に使うPythonのオープンソースツールキット）を使うと、RAG向けの指標を自動で測れます。代表的なものは「正しい文書が上位に来ているか」（Context Precision）「抜け漏れがないか」（Context Recall）「根拠と矛盾していないか」（Faithfulness）「質問に合っているか」（Response Relevancy）です。最初は人手で「正解チャンクが検索上位に返っているか」を質問10〜20件で確認します。設計が安定してきたらRAGASの自動評価に切り替えるのが自然な流れです。評価なしに感覚だけで調整すると、どの変更が効いたかが分からなくなります。外注を検討する場合は、「精度を上げるためにどの手法をいつ試すか、スケジュールとコストの見積もりを教えてください」と確認することで、初期構築と精度改善フェーズを分けた現実的な計画を持っているかが分かります。
ローカルかクラウドかの選択基準
RAGはローカル環境でもクラウドでも動かせます。選択基準は「社内情報の機密度」と「運用リソースの有無」で決まります。
機密度と運用リソースでローカルとクラウドを選び分ける
図の内容: 左（ローカル）は情報を社外に出さないケースで選ぶ。右（クラウド）はインフラ管理を省いてスピードを優先するケースで選ぶ。
| 比較軸 | ローカル構成 | クラウド構成 |
|---|---|---|
| セキュリティ | 情報が社外に出ない。機密文書・個人情報を扱う場合に適する | クラウドプロバイダーのセキュリティ設定に依存。契約上の情報取り扱いを確認する |
| 初期コスト | サーバー調達・設定の初期費用が発生する。既存サーバーで動かせる場合は安く済む | 初期費用ゼロが多い。使った分だけの従量課金 |
| 運用負荷 | インフラ管理・モデルの更新・障害対応は自社が担う | インフラ管理はクラウド側。エンジニアリソースが少ない場合に向く |
| スケール | 文書数・同時アクセスが増えたとき、サーバーのスペックアップが必要 | オートスケールで対応しやすい。大規模化しても追加設計が少ない |
まず社内情報の機密度を確認してください。「社外のサーバーに情報を置けない」という制約がある場合は、ローカル構成が前提になります。その場合でも、ローカルで動かせるLLMとpgvectorを組み合わせてRAGを動かせます。制約がない場合は、クラウドマネージドサービスを使った方が構築スピードが速く、運用の手間も少なくなります。「社内のどの情報をRAGの対象にするか」と「その情報をクラウドに置けるか」の2点を先に決めると、構成が自然に絞れます。
内製か外注かの判断基準と費用の目安
Pythonエンジニアがいて文書が整理済みなら内製、そうでなければ外注が向きます。
内製できる条件は主に2つです。①Pythonを書けるエンジニアが社内にいること、②RAGの対象にするドキュメントが整理された状態にあることです。ドキュメントが散在・未整理の状態では、内製でも外注でも構築前の整備に時間がかかります。LangChainのチュートリアルに沿って試作する時間があれば、試作を動かすところまでは比較的短期間で進められます。
外注が向くケースは、①設計から任せたい、②社内に技術者がいない、③精度改善まで込みで頼みたい場合です。外注する場合は、まず「RAGが自社の課題に本当に合う手法か」を切り分けることが先決になります。費用の目安はAI受託開発の費用相場【2026年】で整理しています。「Pythonを書けるエンジニアが社内にいるか」「RAGの対象文書がどこにあり、どんな状態か（整理済みか散在か）」の2点を先に確認すると、内製か外注かの方向性はほぼ決まります。
RAG構築を今すぐ始めなくていい会社と、この記事に含まれないこと
次のいずれかに当てはまる場合は、RAGの構築より先にやることが残っています。
- リアルタイムの最新情報が必要なケース: 株価・在庫状況・ニュースのように数分単位で変わる情報は、RAGのインデックス更新が追いつきません。在庫管理システムのAPIを直接呼ぶなど、リアルタイムデータとの直接連携が適しています
- 検索対象が非テキストデータのみのケース: 画像・音声・動画だけを扱う場合は、テキストベースのRAGは直接的な解決策になりません。マルチモーダル（＝テキスト以外の画像・音声も扱える方式）のembeddingを別途検討します
- 検索対象ドキュメントが少量のケース: 数十ページ程度のドキュメントであれば、RAGを組まずにLLMのコンテキストウィンドウに直接入れる方がシンプルで確実な場合があります
- ドキュメントが整理されていない・存在しないケース: RAGはドキュメントの質に直結します。あいまいな内容・古い情報・誤った情報が混在したドキュメントをそのまま入れると、AIが誤った情報を根拠に回答します。RAGの前にドキュメントの整備が必要です
- 文書全体の傾向分析や文書間の関係把握が主目的のケース: RAGはチャンク単位で関連部分を検索する設計のため、「全社規程のうち○○に関する条項をすべて比較したい」のような大局的な分析は苦手です。チャンクに分割した時点で文書間の関係性が失われやすいという、RAGの構造的な限界です。この限界に対しては、文書間の関係を保つ形でデータを持たせる拡張手法もあります。初期構築で入れる必要はなく、基本の4工程を安定させた後の拡張候補として考えてください
この記事では扱わない話題です。
- AIエージェント全体の設計と作り方 → AIエージェントの作り方｜非エンジニアの5ステップ・費用・失敗例【2026年8月】
- 外部データ連携のMCPとの違い → MCPとは｜3つの部品と10言語SDK・接続前の確認3点【2026年8月】
- AI受託開発全体の費用相場 → AI受託開発の費用相場【2026年】
- 特定のRAGプラットフォーム・ツールの使い方の詳細手順
Summary in English
This article explains how to build a Retrieval-Augmented Generation (RAG) system for company documents, organized into four core steps. RAG lets a large language model (LLM) reference your internal documents — manuals, meeting notes, policies, product specs — without retraining the model. Instead, it retrieves relevant chunks at query time and passes them to the LLM as context.
The four steps are: ① chunk splitting (breaking documents into retrievable units), ② embedding generation (converting text to vectors using a model), ③ vector database storage (storing vectors for similarity search), and ④ retrieval, reranking, and answer generation. LangChain’s official documentation describes a standard pipeline covering all these steps.
Key design decisions: chunk size and embedding model choice determine most of the accuracy. For chunk splitting, LangChain’s RecursiveCharacterTextSplitter and TokenTextSplitter are the standard starting points; we use 500 characters per chunk with a 50-character overlap as our starting point for Japanese documents. Embedding models differ in output vector dimension size — OpenAI’s text-embedding-3-small outputs 1,536 dimensions and text-embedding-3-large outputs 3,072 dimensions; the dimensions parameter can shorten them (the docs give a text-embedding-3-large embedding shortened to 256 as the example), while multilingual-e5-base outputs 768 dimensions and multilingual-e5-large outputs 1,024 dimensions. Larger dimensions capture more nuance but increase storage and processing cost. Switching embedding models later requires reprocessing all stored vectors, so fix the model choice early. pgvector (an open-source PostgreSQL extension under the PostgreSQL License, per the pgvector GitHub page) lets companies add vector search to an existing database without deploying a new system; the DDL uses a VECTOR column sized to match the embedding model’s output dimensions.
For accuracy improvement: reranking re-scores vector search candidates before passing them to the LLM, filtering out loosely related chunks. A before/after example: without RAG, a question about internal parental leave policy returns a generic legal answer; with RAG referencing the company’s actual rules, the response cites the specific article number, duration, and extension conditions. Metadata filtering enables role-based access control — for example, restricting certain document chunks to specific departments or job levels using SQL WHERE clauses on the metadata columns. Subquery decomposition splits compound questions into independent searches before merging results. Conversation history management stores prior exchanges in a database and includes recent turns in each new search query, maintaining multi-turn context.
For RAG evaluation, RAGAS (an open-source Python toolkit) provides metrics such as Context Precision, Context Recall, Faithfulness, and Response Relevancy. Starting with manual inspection of 10–20 test questions before moving to automated RAGAS evaluation is the practical sequence.
RAG has structural limits: it is not well-suited for holistic analysis across documents, since chunking loses cross-document relationships. Extensions that preserve cross-document relationships exist, but are better treated as a future step rather than a day-one requirement.
For deployment: if internal documents cannot leave the company network, a local setup using a locally-run LLM and pgvector works without cloud connectivity. If cloud storage is permitted, cloud managed services reduce infrastructure burden.
Companies should consider outsourcing if they lack Python-capable engineers or need help deciding which problems are suitable for RAG. For cost information, see the AI outsourcing cost overview article.
まとめ｜RAG構築は4工程で進める
RAGの構築と精度改善のポイントを整理します。
- RAGは「再学習」ではなく「検索して渡す」仕組み。準備段階（チャンク分割→embedding→ベクトルDB保存）を一度実行し、利用段階で質問のたびに検索・reranking・生成を回す
- まず効くのはチャンク設計とembeddingモデルの選択。embeddingモデルを変えると全データの作り直しが必要なため、最初に固める。モデル選択時はMTEBのスコアと次元数（ストレージ・検索速度の負担）をセットで見る
- pgvector（PostgreSQLライセンス・PostgreSQL拡張）を使えば、新たなDBを立てずにベクトル検索を始められる。DDLのVECTOR列の次元数はembeddingモデルの出力次元数に合わせる
- ローカル構成かクラウド構成かは「社内情報をクラウドに置けるか」で決まる。制約があればローカルで動かせるLLMとpgvectorの組み合わせが選択肢になる
- 精度改善はチャンク調整→メタデータ付与（アクセス制御含む）→ハイブリッド検索→rerankingの順で試す。会話を扱うならマルチターン対応の設計を初期から検討する
- 精度改善の効果はRAGASで測る。「何がどのくらい変わったか」を測定しながら調整しないと、どの変更が効いたか分からなくなる
次のアクションは、3つのうちどれか1つで構いません。
- 今日: この記事の「4工程と必要なもの一覧」の表を見ながら、自社のドキュメントをどの工程に当てはめるかを書き出す
- 今週: 「社内情報のクラウド保存可否」と「Pythonが書けるエンジニアの有無」を確認し、ローカル構成かクラウド構成か・内製か外注かを決める
- 今月: 試す対象ドキュメントを1種類に絞り、小規模な試作を動かして精度を確かめる
RAGは最初から完璧な精度を目指すより、試して調整するサイクルを早く回すほうが近道です。構築の入口から相談したい場合は、当社のAI適用診断が出発点になります。
次に読む
- RAGをエージェントの部品として組み込む設計を知りたい → AIエージェントの作り方｜非エンジニアの5ステップ・費用・失敗例【2026年8月】
- RAGとMCPの使い分けを知りたい → MCPとは｜3つの部品と10言語SDK・接続前の確認3点【2026年8月】
- 外注する場合の費用相場を知りたい → AI受託開発の費用相場【2026年】
更新履歴
- 2026-08-28: 初版公開。4工程の解説・チャンク分割手法比較（TextSplitter・TokenTextSplitterの実装例）・embeddingモデル選択軸・ベクトルDB比較・pgvectorのDDL例・reranking手法比較・精度改善7手法・RAGなし vs RAGありの回答比較・RAGAS評価・ローカルとクラウドの選択基準・内製か外注かの判断基準を収録。
- 次回更新予定: 2026年11月（embeddingモデルの評価状況とRAGツールの動向を再確認します）
本記事は2026年8月28日時点のAWS公式ページ・pgvector公式GitHub・LangChain公式ドキュメント・OpenAI公式APIドキュメント・HuggingFace公式モデルカード・MTEB/Ragas公式リポジトリ・HyDE原論文に基づきます（公開日: 2026年8月28日）。各ツール・サービスの仕様や価格は変更される場合があるため、最新情報は各公式サイトでご確認ください。
参考・出典
- AWS「Retrieval-Augmented Generation (RAG)」 https://aws.amazon.com/what-is/retrieval-augmented-generation/（参照日: 2026年8月28日）
- pgvector「pgvector: Open-source vector similarity search for Postgres」 https://github.com/pgvector/pgvector（参照日: 2026年8月28日）
- LangChain「Retrieval Augmented Generation (RAG) with Deep Agents」 https://docs.langchain.com/oss/python/langchain/rag（参照日: 2026年8月28日）
- LangChain「langchain_text_splitters リファレンス」 https://reference.langchain.com/python/langchain_text_splitters/（参照日: 2026年8月28日）
- OpenAI「Embeddings」 https://developers.openai.com/api/docs/guides/embeddings（参照日: 2026年8月28日）
- HuggingFace「intfloat/multilingual-e5-base」 https://huggingface.co/intfloat/multilingual-e5-base（参照日: 2026年8月28日）
- HuggingFace「intfloat/multilingual-e5-large」 https://huggingface.co/intfloat/multilingual-e5-large（参照日: 2026年8月28日）
- Ragas「指標一覧（RAG向けの評価指標）」 https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/（参照日: 2026年8月28日）
- MTEB「Massive Text Embedding Benchmark」 https://github.com/embeddings-benchmark/mteb（参照日: 2026年8月28日）
- Ragas「Ragas 公式リポジトリ」 https://github.com/explodinggradients/ragas（参照日: 2026年8月28日）
- Gao et al.「Precise Zero-Shot Dense Retrieval without Relevance Labels」（HyDE の原論文） https://arxiv.org/abs/2212.10496（参照日: 2026年8月28日）
- 当社サービス資料: 案件カテゴリにAIエージェント/チャットボット構築が含まれる（2026年8月時点）。本文の設計の考え方は、発注側が要求してよい条件として整理したもので、個別案件の実測値ではない
よくある質問
- RAGとは何ですか？
- RAGとはRetrieval-Augmented Generation（検索・拡張・生成）の略で、対話型AIサービスの中核にあるLLM（＝大規模言語モデル）に社内ドキュメントなどの外部データを参照させる手法です（AWSの公式解説ページでも取り上げられています）。LLMの学習データにない情報でも、必要な文書を検索してから回答を生成するため、事実に基づいた回答が得られます。LLMを再学習させるより低コストで、情報の更新にも柔軟に対応できます。
- RAGはどういう仕組みですか？
- 大きく準備段階と利用段階に分かれます。準備段階では、①ドキュメントをチャンク（＝小さなまとまり）に分割し、②embeddingモデルでベクトル（＝数値の配列）に変換し、③ベクトルDBに保存します。利用段階では、質問もベクトルに変換し、意味的に近いチャンクを検索してLLMに渡すことで回答を生成します。LangChain公式が文書化している標準パイプラインはこの流れに沿っています。
- 社内RAG構築とは何ですか？
- 社内の規程・マニュアル・議事録・製品資料などを検索対象として、社員の質問に回答するRAGシステムを自社に構築することです。LLMの学習データには社内固有の情報が含まれないため、RAGを使うことで「社内文書を参照したAI検索」が実現します。構築はクラウドサービスを使う方法と、ローカルでゼロから組む方法があります。
- RAGのチャンクサイズはどうやって決めますか？
- 文書の性質によって異なります。短い情報（FAQや箇条書き）は小さめに、長い説明文（マニュアルや報告書）は大きめに設定するのが基本の考え方です。設定後は実際に質問を投げて回答の質を確かめ、「答えが途中で切れる」「関係ない情報が混じる」と感じたら調整します。チャンク間にオーバーラップ（重複部分）を設けると、分割位置で情報が欠落するリスクを減らせます。
- RAGの精度を上げるにはどうすればいいですか？
- まずチャンクサイズとオーバーラップの調整が効きます。次にメタデータ（文書名・更新日・部門名）をチャンクに付けることで検索精度が上がります。それでも足りない場合は、ハイブリッド検索（ベクトル検索とキーワード検索の組み合わせ）やrerankingモデルの追加を検討します。精度改善は一度で完成せず、実際に使いながら繰り返し調整する工程です。
- RAG構築にPythonは必須ですか？
- コードで構築するならPythonが最も情報が多く、LangChainなどのライブラリも充実しています。ただしノーコードでRAGパイプラインを組めるツールを使えばコードなしで構築できる選択肢もあります。外注する場合はPythonの知識は不要で、要件の整理と動作確認が主な仕事になります。
- RAG構築に使えるツールはありますか？
- 大きく3種類あります。①LangChainなどのPythonライブラリ（RAGのパイプラインを組む部品が揃っている）、②ノーコードで画面から組めるツール、③クラウドプロバイダーが提供するマネージドサービスでRAGの仕組みを提供するものです。自社のスキルと運用コスト、セキュリティ要件で選びます。
- RAGはローカル環境で動かせますか？
- 動かせます。ローカルで動かせるLLMを使い、pgvector（＝PostgreSQLのベクトル検索拡張機能・PostgreSQLライセンス・pgvector公式GitHubより）をベクトルDBとして使えば、インターネットに接続せずにRAGを動かせます。機密性の高い社内情報を扱う場合や、クラウド利用を制限しているケースで選ばれる構成です。
- RAGを対話型AIサービスと組み合わせるにはどうすればいいですか？
- 外部のLLMをAPI経由で呼び出し、チャンク分割・embedding・ベクトルDB・rerankingの4工程は自社で組む方法と、クラウドプロバイダーのマネージドサービスでembeddingモデルを使う方法があります。どちらも4工程の設計は同じで、LLMの呼び出し先を変えるだけです。
- RAG構築を外注するといくらかかりますか？
- 対象文書の量・整備状況と、どこまで自社で持つかで幅が出ます。設計だけを頼むのか、構築・運用まで含めるのかで見積の桁が変わるため、範囲を先に決めてから相見積を取るのが現実的です。金額の目安はAI受託開発の費用相場の記事で整理しています。外注する場合は、まず「RAGが自社の課題に合う手法かどうか」を切り分けることが先決になります。
- RAGでマルチターン対話（複数回のやりとり）を実現するにはどうすればいいですか？
- 直前の会話履歴（質問と回答のセット）をDBに保存し、次の検索クエリを作るときに履歴の内容を含めてLLMに渡す構成が基本です。「さっきの話に戻りますが」「それはAの規程ですか、Bの規程ですか」のような前の発言を前提にした質問でも、文脈を維持した回答ができるようになります。履歴が長くなるほどコンテキストの消費量が増えるため、直近N件に絞る、または要約して渡す方式とセットで設計します。
- RAGに部門や役職ごとのアクセス制御は付けられますか？
- チャンクにメタデータとして「部門コード」「役職区分」「閲覧対象」などを付けることで実現できます。検索時にこのメタデータでフィルタリングすると、「管理職にのみ表示する規程」「人事部門の文書は人事部員の検索にのみ返す」といった制御が可能です。チャンク設計の段階でアクセス区分をメタデータとして定義しておくことが前提です。pgvector（PostgreSQLライセンス）などのベクトルDBはSQLのWHERE句でメタデータフィルタリングができます。
- RAGの回答精度をどうやって測りますか？
- RAGAS（＝LLMアプリの評価に使うPythonのオープンソースツールキット）を使うと、RAG向けの代表的な指標として文脈の精度（Context Precision）・文書の網羅性（Context Recall）・回答の忠実度（Faithfulness）・回答の関連性（Response Relevancy）などを自動で測定できます。まずは人手で「正解情報を含むチャンクが検索上位に返っているか」と「LLMの回答と根拠チャンクに矛盾がないか」の2点を質問10〜20件で確認し、安定してきたらRAGASでの自動評価に移行するのが現実的な流れです。
- rerankingを入れると精度はどのくらい上がりますか？
- rerankingの効果はドキュメントの種類・チャンク設計・ベクトル検索の設定によって異なるため、一律の数値はありません。改善が期待できる状態の目安は、「ベクトル検索の上位N件には正解チャンクが含まれているが、上位K件（LLMに渡す件数）に入らない」ケースが繰り返される状況です。質問10〜20件でベクトル検索の上位5件に正解チャンクが入っているかを確かめてから、rerankingの追加を試す順番が現実的です。
