社内文書RAGの作り方2026。パース・埋め込み・リランクの最新構成

Q: 社内文書RAGとは何ですか？

社内文書を検索し、見つかった内容をLLMに渡して回答を生成させる仕組みです。質問のたびに関連文書を検索して文脈として渡すため、社内の最新文書に基づいた回答を機密データを外部に出さずに得られます。構成は「パース→埋め込み→検索→リランク」の4段パイプラインが2026年時点の日本語最適解です。

Q: ベクトルDBはpgvectorとQdrantのどちらを選ぶべきですか？

すでにPostgreSQLを運用しているならpgvectorです。既存DBに拡張として相乗りでき、中小規模に向きます。大規模・高スループットでハイブリッド検索を前提にするなら、ネイティブでハイブリッド検索に対応した専用ベクトルDBのQdrantです。どちらの場合も、ベクトル検索とキーワード検索（BM25）を組み合わせるハイブリッド構成が実務標準です。

社内文書RAGの精度は、LLM本体よりも「文書の読み込み方と検索の設計」で決まります。「RAGを組んだが回答がずれる」という悩みの多くは、モデルを大きくしても解決しません。本記事では、日本語の企業文書に最適化した2026年時点の構成を、パース・埋め込み・検索・リランクの4段パイプラインとして、意思決定に必要な粒度で整理します。

この記事の要点

RAGの精度不足の原因は、LLM本体の性能ではなく文書パースの失敗や検索の外れであることが大半です

日本語に最適化した構成は「パース→埋め込み→検索→リランク」の4段パイプラインです

埋め込みは国産オープンモデル（Ruri v3等、Apache 2.0）が完全ローカルのままOpenAI API級の検索品質に達しています

検索はベクトル検索＋キーワード検索（BM25）のハイブリッドが実務標準です。リランクはCPUで動き、既存構成に数行足すだけで精度が一段上がります

個人〜小規模はOllama＋AnythingLLMで半日、部門展開はvLLM＋ハイブリッド検索＋リランカーが標準構成です

RAGの精度が出ない原因はLLMではない

「RAGを組んだが回答がずれる」——この原因を分解すると、多くはLLM本体ではありません。実際に起きているのは、次のような失敗です。

文書のパース（読み込み）に失敗して、そもそも本文が壊れている
検索が外れて、関係ない文書をLLMに渡している
文脈の渡し方が悪い

LLMの性能不足が原因であるケースは少数派です。だからこそRAGの改善は、LLMを大きくする前に、パイプラインの各段を見直すことから始めます。日本語の社内文書に最適化した構成は、次の4段です。

段	役割	2026年時点の要点
段階1: パース	文書を正しくテキスト化する	最初にして最大の難所。品質を目視確認してから先へ進みます
段階2: 埋め込み	検索できるベクトルに変換する	国産オープンモデルが完全ローカルでOpenAI API級に
段階3: 検索	正しい候補を拾う	ベクトル＋BM25のハイブリッドが実務標準
段階4: リランク	候補を精密に並べ直す	CPUで動作。数行の追加で精度が一段上がります

以下、各段を順に見ていきます。

段階1: 文書パース——最初にして最大の難所

日本語の企業文書には、PDFのレイアウト崩れ・罫線帳票・スキャン画像という三大障害があります。この段階でテキストが壊れると、後段の埋め込みや検索をどれだけ頑張っても無駄になります。主なツールの選択肢は次の通りです。

ツール	強み	注意点
Docling（IBM発OSS）	表・図・レイアウト・数式を含む文書理解に強い。PDF/DOCX対応	—
YomiToku	縦書き・帳票に強い	CC BY-NC-SA（非商用）ライセンス。商用利用は別契約が必要です
VLM直読み	画像をそのままLLMに読ませる方式	OCRツールとの用途別の使い分けが必要です（『日本語OCR徹底比較2026』というテーマで別途整理しています）

鉄則は「パース品質を先に目視確認してから次へ進む」ことです。サンプル文書を実際にパースし、本文と表が正しく取れているかを人間の目で確認します。この工程を飛ばすと、RAG全体が砂上の楼閣になります。

段階2: 埋め込みモデル——国産がOpenAI API級になった

日本語の埋め込みモデルは、国産オープンモデルがOpenAI APIと並ぶ水準に達しました。Ruri v3やPLaMo-embedding-1b（いずれもApache 2.0ライセンス）を使えば、完全ローカルのままAPI級の検索品質が出ます。機密文書を外部に送信せずに高精度の検索基盤を持てるという意味で、これは2026年の大きな変化です。

モデルごとの詳細な比較は『日本語埋め込みモデルはOpenAI APIを超えたか』というテーマになりますが、選定で迷ったらRuri v3系が第一候補です。

段階3: 検索——ベクトルだけでは足りない

ベクトル検索（意味で探す検索）には、型番・固有名詞・略語の完全一致に弱いという明確な弱点があります。「XR-2000」を「XR-3000」と混同する、といった取りこぼしが典型です。

そこで、ベクトル検索＋キーワード検索（BM25）のハイブリッド検索が実務標準になりました。意味で拾う検索と文字列で拾う検索を組み合わせ、両方の弱点を補い合う構成です。ベクトルDBの現実解は2つに絞られます。

ベクトルDB	位置づけ	向いているケース
pgvector	既存のPostgreSQLに拡張として相乗り	運用資産を活かしたい中小規模
Qdrant	専用ベクトルDB。ネイティブでハイブリッド検索に対応	大規模・高スループット

「すでにPostgresを運用中」ならpgvector、「大規模でハイブリッド検索前提」ならQdrant、という選び分けです。

段階4: リランク——CPUでできる精度の一段上げ

検索で拾った候補（例: 上位50件）を、日本語リランカーで精密に並べ直すのが最後の段です。国産リランカーはCPUで動く軽さで、既存構成に数行足すだけで導入できます。GPUへの追加投資なしで検索品質が上がる、最も費用対効果の高い一手です（詳細は『CPUで動く日本語リランカー』というテーマで扱っています）。

構成例: 規模別レシピ

ここまでの4段を、規模別の具体的な構成に落とし込みます。

規模	構成	特徴
個人〜小規模	Ollama + AnythingLLM / Open WebUI内蔵RAG	半日で立つ。まず試す用
部門	vLLM + ハイブリッド検索 + リランカー	標準構成。精度と速度の両立

AnythingLLM（MITライセンス）はRAG＋エージェントが主機能で、ゼロ設定で始められます。Open WebUIはチャットが主でRAGは従の位置づけであり、かつライセンスに注意が必要です（『Open WebUIで社内ChatGPTを作る』というテーマで別途整理しています）。

小規模のOllama構成から部門展開のvLLM構成へ乗り換えるタイミングと性能差は『試作はOllama、本番はvLLM。乗り換えのタイミングと20倍の性能差』で、構築にかかる費用・工数の実額は『ローカルLLM導入費用の実額内訳』でまとめています。

RAGで解決しないケース

RAGは「知識を検索してLLMに渡す」仕組みです。したがって、次のような要件は苦手です。

文体・書式を覚えさせたい — これはRAGではなくLoRA（ファインチューニング）の領域です。必要なGPUや手順は『LoRAで自社データをローカルLLMに学習させる』で解説しています
効果が不明なまま対象を拡大したい — 拡大の前に、評価セットで精度を測ることが先です。撤退・見直しの基準の決め方は『ローカルLLMのPoCで300万円溶かす前に』で扱っています

RAG構築前チェックリスト

構築に着手する前に、次の項目を確認してください。いずれもここまでの4段パイプラインに対応しています。

対象文書の種類を把握した（レイアウト崩れPDF・罫線帳票・スキャン画像の有無）
サンプル文書のパース結果を目視確認した（本文・表が正しく取れているか）
パースツールのライセンスを確認した（YomiTokuは非商用。商用は別契約）
埋め込みモデルを選定した（迷ったらRuri v3系が第一候補）
検索はベクトル＋BM25のハイブリッドを前提に設計した
ベクトルDBを既存資産で選んだ（Postgres運用中ならpgvector、大規模ならQdrant）
リランカーの導入を検討した（CPUで動作・数行の追加）
評価セットで精度を測ってから対象を広げる計画にした
RAGで解決しない要件（文体・書式の学習）を切り分けた

まとめ

RAGの精度不足は、LLM本体よりも「パース・検索の設計」が原因であることが大半です。改善は4段パイプライン（パース→埋め込み→検索→リランク）の見直しから始めます
パースが最大の難所です。Docling・YomiToku（非商用ライセンスに注意）・VLM直読みを使い分け、必ず目視確認してから先へ進みます
埋め込みは国産オープンモデル（Ruri v3等）で完全ローカルのままAPI級の品質が出ます。検索はベクトル＋BM25のハイブリッドが標準です
リランクはCPUで動き数行で足せる、費用対効果最大の一手です
小規模はOllama＋AnythingLLMで半日、部門はvLLM＋ハイブリッド検索＋リランカーが標準構成です。文体・書式の学習はRAGではなくLoRAで対応します

よくある質問

Q. 社内文書RAGとは何ですか？

社内文書を検索し、見つかった内容をLLMに渡して回答を生成させる仕組みです。LLM本体に知識を覚えさせるのではなく、質問のたびに関連文書を検索して文脈として渡すため、社内の最新文書に基づいた回答を機密データを外部に出さずに得られます。構成は「パース→埋め込み→検索→リランク」の4段パイプラインが2026年時点の日本語最適解です。

Q. RAGの回答精度が上がらない原因は何ですか？

多くの場合、原因はLLM本体ではありません。文書のパースに失敗して本文が壊れている、検索が外れて関係ない文書を渡している、文脈の渡し方が悪い、のいずれかが大半です。改善はLLMを大きくする前に、パース品質の目視確認・ハイブリッド検索への切り替え・リランカーの追加という順でパイプラインを見直すのが定石です。

Q. 日本語PDFのパースにはどのツールを使えばよいですか？

表・図・レイアウト・数式を含む文書にはDocling（IBM発のOSS、PDF/DOCX対応）、縦書きや帳票にはYomiTokuが強い選択肢です。ただしYomiTokuはCC BY-NC-SA（非商用）ライセンスで、商用利用には別契約が必要です。画像をそのままLLMに読ませるVLM直読みという方式もあります。どのツールでも、サンプル文書のパース結果を目視確認してから次の工程へ進むことが鉄則です。

Q. RAGの埋め込みモデルは何を選べばよいですか？

日本語では国産オープンモデルのRuri v3やPLaMo-embedding-1b（いずれもApache 2.0ライセンス）が、OpenAI APIと並ぶ水準に達しています。完全ローカルで運用でき、機密文書を外部に送信する必要がありません。選定に迷ったらRuri v3系が第一候補です。RAGの後段で回答を生成するLLM本体の選び方は『日本語で使えるローカルLLMおすすめ2026』を参照してください。

Q. ベクトルDBはpgvectorとQdrantのどちらを選ぶべきですか？

すでにPostgreSQLを運用しているならpgvectorです。既存DBに拡張として相乗りでき、運用資産をそのまま活かせるため中小規模に向きます。大規模・高スループットでハイブリッド検索を前提にするならQdrantです。専用ベクトルDBとしてネイティブでハイブリッド検索に対応しています。なおどちらを選ぶ場合も、ベクトル検索単体ではなくキーワード検索（BM25）と組み合わせるハイブリッド構成が実務標準です。

Q. RAGとファインチューニング（LoRA）はどう使い分けますか？

RAGは「知識を検索してLLMに渡す」仕組みなので、社内文書の内容に基づいて回答させる用途に向きます。一方、文体や書式を覚えさせたい場合はRAGでは解決できず、LoRA（ファインチューニング）の領域になります。必要なGPUや進め方は『LoRAで自社データをローカルLLMに学習させる』で解説しています。

Q. 小規模で社内文書RAGを試すには何から始めればよいですか？

Ollama＋AnythingLLM、またはOpen WebUI内蔵RAGの構成が半日で立ち上がり、まず試す用途に向きます。AnythingLLM（MITライセンス）はRAG＋エージェントが主機能でゼロ設定で始められます。Open WebUIはチャットが主でRAGは従の位置づけで、ライセンスにも注意が必要です。効果が確認できて部門展開する段階では、vLLM＋ハイブリッド検索＋リランカーの標準構成へ移行します（乗り換え時期は『試作はOllama、本番はvLLM』を参照してください）。

主な参考資料: Docling (GitHub)、Qdrant (GitHub)、pgvector (GitHub)、AnythingLLM (GitHub)

TodoONadaでは、社内文書RAGの構築を受託しています。既存文書だけでなく、POSや基幹システムとの接続まで含めた構成のご提案が可能です。パース品質の確認から規模に合った構成の選定まで、ローカルLLM導入支援としてお手伝いします。

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。