生成AIに社内規程を質問したら、存在しない条項を自信満々に引用された——。LLMを業務で使おうとした企業の多くがぶつかるのが、この「幻覚（ハルシネーション）」です。原因は単純で、LLMは社内文書を学習していないため、足りない知識を一般知識で補完してしまうからです。
RAG×LLMはこの課題を構造的に解消します。質問のたびに社内文書を検索して根拠をLLMに渡す「LLM RAG連携」の構成にすることで、回答精度は92%まで引き上げられ、どの文書のどこを出典にしたのかまで確認できるようになります。社内AI導入の全体像は社内AI導入完全ガイドにまとめています。
このガイドで分かることは、次の3点です。
- 幻覚が起きる2つの原因と、RAGがこれを抑え込む仕組み
- RAG アーキテクチャの4層構成（Embedding／Vector DB／Retriever／LLM）と設計の要点
- 回答精度92%を達成したオンプレミス構築の3ステップ（2週間PoC→1ヶ月本番）
RAG×LLMとは？LLM単体の課題とRAGによる解決
RAG×LLMとは、大規模言語モデル（LLM）の回答生成に、社内文書などの外部知識をその都度検索（Retrieval）して参照させる技術の組み合わせである。検索と生成（Generation）を質問ごとに連携させることで、学習データに含まれない固有・最新の情報にも根拠付きで回答できる（2026年時点でエンタープライズAI導入の標準構成）。
まず、LLMを単体で業務に使った場合に何が起きるかを整理します。
- 社内情報を知らない：LLMの学習データは公開Web情報が中心。自社の規程、契約書、マニュアルは一切学習されていません
- 知識が古い：モデルの学習時点で知識が止まります。改正された法令や今年度の予算などには答えられません
- 出典を示せない：回答の根拠が分からないため、担当者が確認しようとしても検証のしようがありません
- 幻覚（ハルシネーション）：知識の穴をそれらしい文で埋めてしまうため、誤りに気づきにくいのが最大の問題です
RAGは「学習」ではなく「検索」でこの穴を埋めます。社内文書をあらかじめベクトル化しておき、質問が来るたびに関連箇所を取り出してLLMに渡す。この違いを比較すると次のとおりです。
| 項目 | LLM単体 | RAG×LLM |
|---|---|---|
| 社内文書への回答 | 不可（一般知識で補完） | 可能（検索した文書から回答） |
| 情報の鮮度 | 学習時点で固定 | 文書を更新すれば即時反映 |
| 出典の確認 | できない | 引用箇所を明示 |
| 幻覚リスク | 高い（検知困難） | 低い（根拠なし回答を抑止） |
| 社内データの扱い | 学習させるには再学習が必要 | 文書を置くだけ（学習不要） |
オンプレミス環境でLLMを運用する場合の土台となる知識は、オンプレミス生成AI導入ガイドで体系的にまとめています。RAGとの組み合わせで、機密データを社外に出さずにこの精度を実現できます。
LLMの幻覚問題をRAGが解決する仕組み
幻覚が起きる原因は2つに絞られます。1つは知識の欠如。学習していない情報について問われても、LLMは「知らない」とは答えにくい性質を持っています。もう1つは確信の偏り。文として自然な文章を生成するよう訓練されているため、内容の正しさと文体の自然さが結びついてしまい、誤りであっても確信ありげに述べられます。
RAGはこの両方に、プロンプトの段階で対処します。具体的な動作フローは次の3段階です。
- 検索：ユーザーの質問をベクトル化し、社内文書の中から意味的に関連する箇所（チャンク）を上位取得する
- 根拠の注入：取得したチャンクを「以下の資料のみに基づいて回答せよ」という制約とともにプロンプトに挿入する
- 生成：LLMは渡された資料の範囲内で回答を組み立て、出典となる文書名・箇所を併記する
この構造の効果は大きいです。該当する文書が存在しない質問には「資料に記載がありません」と回答させられるため、でっち上げが構造的に起こりにくくなります。回答には引用箇所が付くため、担当者は該当ページを開けば数十秒で検証できます。GBase OnPremでの検証では、このLLM RAG連携の構成により社内文書Q&Aの回答精度が92%に到達しました（2026年、GBase調べ）。
ハイブリッド検索（ベクトル検索＋キーワード検索）を組み合わせると、精度はさらに安定します。詳細は次のアーキテクチャ設計で扱います。
RAG×LLMのアーキテクチャ設計 — EmbeddingからVector DB、Retriever、LLMまで
RAG アーキテクチャは4つの層に分解できます。大規模言語モデルに検索拡張を組み込む際、各層の選択がそのまま回答精度と運用コストを決めます。
1. Embedding層 — 文書をベクトルに変換する
社内文書を意味比較可能なベクトル（数値列）に変換する層です。ここで使うEmbeddingモデルの多言語性能が低いと、日本語文書の検索精度が目に見えて落ちます。日本語と英語が混在する社内文書では、多言語対応モデルの選定が前提です。変換単位（チャンク）の切り方については後述します。
2. Vector DB層 — ベクトルを社内に蓄積する
変換済みベクトルを高速に検索するためのデータベースです。QdrantやMilvusなどのOSSを自社サーバー上（Docker）で動かせば、機密文書のベクトルも社外に送信せずに済みます。件数が数万規模になってもミリ秒台の類似検索が可能です。
3. Retriever層 — 何を取ってくるかを決める
質問に対して「どのチャンクをLLMに渡すか」を決める層で、RAGの精度を最も左右する箇所です。ベクトル検索だけでは「意味は近いが用語が違う」ケースに強い一方、製品型番・条文番号・氏名のような完全一致が必要な検索で取りこぼしが出ます。ベクトル検索とBM25系キーワード検索を併用するハイブリッド構成が、エンタープライズ利用での事実上の標準です。
4. LLM層 — 根拠から回答を組み立てる
最後に、Retrieverが渡したチャンクに基づいて回答を生成します。モデルの選定基準は日本語応答性能・コンテキスト長（一度に読める資料量）・推論に必要なGPUリソースの3点。DGX Sparkのような1PFLOP級のローカルGPU環境なら、GPT-4oクラスのOSSモデルを社内で完結して動かせます。モデル選定とGPU要件の詳細は、NVIDIA DGX SparkでLLMをローカル運用する方法で解説しています。
| 層 | 役割 | 主な選択肢 |
|---|---|---|
| Embedding | 文書・質問のベクトル化 | 多言語対応Embeddingモデル |
| Vector DB | ベクトルの蓄積・高速検索 | Qdrant、Milvus（OSS・ローカル稼働） |
| Retriever | 関連チャンクの取得 | ベクトル検索＋BM25のハイブリッド、リランキング |
| LLM | 根拠に基づく回答生成 | Llama 3.1系、GPT-4oクラスOSSモデル |
なお、RAGとナレッジベースは役割が補い合う関係です。文書の整備・蓄積の設計についてはAIナレッジベース構築ガイドを合わせて参照してください。ナレッジの質が低いと、どれだけアーキテクチャを精緻にしても回答精度は頭打ちになります。
エンタープライズ向けRAG構築の3つのポイント
アーキテクチャを正しく組んでも、実装の細部で精度は大きく変わります。PoCで失敗するケースの多くは、次の3点のいずれかが欠けています。
ポイント1：チャンキング戦略 — 文書の切り方で検索精度が決まる
チャンキングとは、文書を検索可能な小片に分割する処理です。固定長（例：500文字）で機械的に切ると、見出しと本文が分離し、表の行が途中で断絶します。取得されたチャンクだけでは文脈が成立せず、LLMが誤読する原因になります。
エンタープライズの実務では、文書の論理構造（見出し・段落・表）を認識した適応的チャンキングが有効です。規程類なら「条第項」単位、マニュアルなら見出し単位で分割し、表は行単位で切り出した上で列見出しを各行に付与する。これだけで検索時の文脈欠落が大幅に減ります。
ポイント2：リランキング — 取得した結果の順序を最適化する
ハイブリッド検索で上位20件を取得した後、Cross-Encoder型のモデルで質問との関連度を再スコアリングするのがリランキングです。第一段階の検索は速度優先のため、関連度の順序が甘くなります。ここで上位のみをLLMに渡すよう並べ替えると、GBaseの検証では検索精度が最大40%向上しました（2026年、GBase調べ）。
コンテキスト長には限りがあるため、「上位N件をそのまま渡す」構成より「多めに取得してリランキングで絞る」構成のほうが、同じリソースで高い精度を出せます。
ポイント3：評価指標 — 数字で改善を管理する
RAGの精度は体感で議論しては改善しません。最低限、次の4指標をPoC段階から測定します。
| 指標 | 測定する内容 | 目安 |
|---|---|---|
| 正答率 | 質問に対する回答の正しさ | 90%以上 |
| 引用正確性 | 引用した箇所が本当に根拠になっているか | 95%以上 |
| 検索適合率 | 取得チャンクに正解根拠が含まれる割合 | 90%以上 |
| 応答速度 | 質問から回答までの時間 | 5秒以内 |
評価用に業務担当者から50〜100問の質問セットを集め、正解と出典を人手で登録しておくのが実務上の近道です。RAGASなどの自動評価フレームワークを併用すれば、モデルやチャンク設定を変えるたびに発生する回帰テストを機械に任せられます（ツール名は参考情報です）。
GBase OnPremでRAG×LLMをオンプレミスに構築する
ここまでの設計を自力で実装するには、LLMエンジニアの確保と2〜3ヶ月の構築期間が必要です。一方、クラウドのRAGサービスは機密文書を社外に送信する構成になるため、金融・医療・製造・官公庁ではセキュリティ審査を通りにくいという現実があります。
GBase OnPremは、この両方の課題を回避するターンキー型のオンプレミスAIソリューションです。社内データを一歩も外に出さずに、Advanced RAG環境を構築・運用できます。清水建設との共同研究で大規模企業環境での実証も済んでいます。
Advanced RAGの技術的優位性 — ハイブリッド検索とマルチモーダル対応
回答精度92%の源泉は、GBase OnPremのRAGが「単なるベクトル検索」ではない点にあります。
- ハイブリッド検索：ベクトル検索（意味的類似）とキーワード検索（BM25）を統合。「言い換えられた質問」と「型番・条文の完全一致が必要な質問」の両方に対応します
- リランキング内蔵：Cross-Encoderによる再スコアリングで検索精度を最大40%向上。前述のポイント2が初期状態で組み込まれています
- LLM＋VLMのデュアルモデル：Llama 3.1系LLMに加え視覚AI（VLM）を搭載。図面・図表・写真を含むPDFもテキスト層だけに頼らず検索・回答できます
- GPT-4oクラスのOSSモデル：OSS-GPT-120B（MMLU-Pro 90.0%）とQwen3-Next-80B（256Kコンテキスト）を搭載し、ベンチマーク上でGPT-4o（87.0%）を上回る回答精度をオンプレミスで出せます
- NVIDIA DGX Spark対応：従来構成の1/20のコストで導入でき、GPUリソースを85%削減。スペックの詳細はNVIDIA DGX Sparkとは？仕様・性能・企業AI活用を参照してください
- データ完全社内保持：ベクトルDB・LLM・VLMすべてが自社環境内で稼働。外部送信なし、従量課金なし
GBase OnPremなら、RAG×LLMをオンプレミスで安全に構築できます
導入ステップ（STEP 1〜3）— 2週間のPoCから本番稼働まで
導入は3ステップで完了します。2週間のPoCで効果を確認し、最短1ヶ月で本番稼働まで進められます。
STEP 1：ナレッジベースを作成し、社内文書を取り込む
管理画面からナレッジベースを新規作成し、PDF・Word・Excel・Markdownなどの社内文書をドラッグ＆ドロップでアップロードします。取り込んだ文書は適応的チャンキングとベクトル化が自動で実行され、社内環境のVector DBに格納されます。画像を含むページはVLMが内容を認識します。
STEP 2：モデルと検索方式を設定する
用途に応じてLLM／VLMを選択し、ハイブリッド検索とリランキングの有効化を行います。長文資料の要約には256KコンテキストのQwen3-Next-80B、正確な規定の質疑応答にはOSS-GPT-120B、といった使い分けが管理画面上で完結します。
STEP 3：AIチャットで運用を開始する
社内ユーザー向けにAIチャットを公開します。回答には出典文書と引用箇所が表示されるため、各部門が自分で根拠を確認しながら使えます。アクセス権限はナレッジベース単位で制御でき、機密区分ごとの運用も可能です。
PoC期間中に先述の評価指標（正答率・引用正確性）を週次で測定し、閾値をクリアしたら本番へ移行します。コスト面の試算はオンプレミスとクラウドのコスト比較が参考になります。GPU稼働率の観点からも、全社展開時のTCOはオンプレミス構成が有利に働くケースが多いです。
よくある質問（FAQ）
Q1：RAGとファインチューニングはどちらを選ぶべきですか？
A：社内文書の質疑応答が目的ならRAGです。ファインチューニングはモデルに知識を焼き込むため、文書を更新するたびに再学習のコストが発生します。RAGは文書を差し替えるだけで情報が最新化され、出典も示せます。業界特有の文体や専門用語の使い分けまで学習させたい場合はファインチューニングを併用します。
Q2：RAG構築にはどのくらいの期間と人員が必要ですか？
A：OSSで自力構築する場合、LLMエンジニア1〜2名と2〜3ヶ月が目安です。ターンキー型のGBase OnPremなら、2週間のPoCを経て最短1ヶ月で本番稼働まで進められ、専任の運用エンジニアは不要です。
Q3：オンプレミスでRAGを構築するメリットは何ですか？
A：最大のメリットは機密文書を社外に送信しないことです。金融・医療・製造・官公庁などのセキュリティ審査に通しやすく、データ所在地の統制も自社で握れます。加えて従量課金がないため、全社展開してもコストが跳ね上がりません。DGX Spark対応構成ならGPUコストを85%削減できます。
Q4：回答精度はどうやって評価すればいいですか？
A：正答率・引用正確性・検索適合率・応答速度の4指標を継続測定します。PoCの段階で業務担当者から50〜100問の評価用質問セットを集め、正解と出典を登録しておくと、モデルや設定変更のたびに客観比較ができます。
Q5：図面やグラフが含まれる文書でも検索できますか？
A：VLM（視覚言語モデル）を併用していれば可能です。テキスト層のない図面・グラフ・写真も画像として内容を認識し、ベクトル化して検索対象に含められます。GBase OnPremはLLM＋VLMのデュアル構成のため、従来のテキスト抽出型RAGでは扱えなかった資産も活用範囲に入ります。
まとめ：RAG×LLMで根拠のあるAIを社内に浸透させる
- LLM単体の課題（社内情報への無知・知識の陳腐化・幻覚）は、RAG連携で構造的に解消できる
- RAG アーキテクチャはEmbedding／Vector DB／Retriever／LLMの4層。精度を最も左右するのはRetrieverの設計
- 実装ではチャンキング戦略・リランキング・評価指標の3点が成否を分ける（リランキングで検索精度最大40%向上）
- 機密データを扱う企業ではオンプレミス構築が前提。GBase OnPremならハイブリッド検索＋LLM/VLMデュアルモデルで回答精度92%、2週間PoC→1ヶ月本番稼働
生成AIを業務の中心に据えるには、回答が正しいことと、その根拠を誰でも確認できることが条件です。RAG×LLMはこの2つを同時に満たす構成であり、オンプレミスに置けば機密性の高い文書ほどAI活用の効果が大きくなります。まずは自社文書100件・評価質問50問の小さなPoCから始めて、精度の数字を自分の目で確かめてみてください。
