社内RAG（社内文書を検索してLLMに回答させる仕組み）をオープンウェイトLLMで作る動きが2026年後半に一段と広がっています。
ただし、LLMを選ぶだけでは社内RAGは動きません。埋め込みモデル・リランカー・運用体制まで組み合わせて判断します。
この記事では、日本語文書を扱う社内RAGを前提に、LLM側と埋め込みモデル側の選定基準、実装で確認すべき項目、運用開始後の指標を整理します。モデル一般比較や推論インフラ論とは切り分けて、RAG運用に絞った実務基準を並べます。
社内RAG向けオープンウェイトLLMと日本語埋め込みモデルの選び方2026年後半
画像: Generated by OpenAI via Codex
この記事でわかること
- 社内RAGでオープンウェイトLLMを選ぶときの4つの判断軸
- 日本語対応の埋め込みモデルとリランカーの選び方
- LLMと埋め込みモデルを組み合わせるときの実装チェックリスト
- 運用開始後に見る指標と、採用しないほうがよい条件
結論サマリー：LLMと埋め込みは「別々に評価」して組み合わせる
社内RAGで使うオープンウェイトLLMと埋め込みモデルは、別軸で評価してから組み合わせます。同じベンダーで揃える必要はありません。
| 役割 | 第一候補（2026年後半） | 主な理由 | 注意点 |
|---|---|---|---|
| LLM（推論・回答生成） | Qwen 3.6シリーズ／Nemotron 3 Ultra | 日本語含む多言語、Apache 2.0または開放ライセンス | GPU要件はモデル規模で大きく変わる |
| LLM（軽量PoC） | Mistral Medium 3.5／Gemma 4 | dense構成で挙動が安定、Apache 2.0 | 大規模知識では上位群に届かない |
| 埋め込みモデル | Qwen3-Embedding／BGE-M3 | 100超言語対応、MTEB v2上位 | 次元数と推論速度で使い分ける |
| リランカー | Qwen3-Reranker 4B／0.6B | 検索精度の底上げに有効 | 追加GPUと遅延増加を許容できるか確認 |
迷ったら、LLMは中規模から入り、埋め込みは多言語対応の定番から始めるのが安全です。運用開始後に自社の日本語文書で再評価し、置き換え可否を判断します。
※本記事は2026年7月11日時点の公開情報をもとに整理しています。モデルの公開状況、ライセンス、料金は変更される場合があります。導入前に必ず公式情報で最新条件を確認してください。
社内RAGの基本：何をどう組み合わせる仕組みか
社内RAGは、社内文書を検索して見つかった箇所をLLMに読ませ、回答させる仕組みです。文書検索の担当が埋め込みモデル、回答生成の担当がLLMです。両者は役割が違うため、別々に選びます。
| 用語 | 意味 |
|---|---|
| RAG | 社内文書を検索し、その内容を根拠にLLMが回答する構成 |
| 埋め込みモデル | 文章を数値ベクトルに変え、意味が近い文章を探せるようにするモデル |
| リランカー | 検索候補の並び順を、精度の高い評価器で並べ直す仕組み |
| コンテキスト長 | LLMが一度に読み込める文章量。長文業務に影響する |
| ハルシネーション | 事実と異なる内容をもっともらしく出力してしまう現象 |
RAG運用は、この3つのモデル（埋め込み・リランカー・LLM）が並列で動く前提です。1つを差し替えると別の指標がずれるため、評価は「組み合わせ全体」で行います。
なぜ2026年後半に「LLMだけでなく埋め込みも見直す」のか
理由は3つです。オープンウェイトLLMの日本語品質が実務に届いた一方で、埋め込み側の選択肢と精度も大きく更新されているためです。
- 2026年6月にNVIDIAがNemotron 3 Ultra（550B/55B active、1Mコンテキスト）を公開し、RAGとエージェント用途を前面に出した
- AlibabaがQwen3-Embeddingシリーズ（0.6B／4B／8B）を公開し、日本語を含む100超言語でMTEB v2上位を獲得した
- BGE-M3やmultilingual-e5-largeなど、既存の定番オープンウェイト埋め込みも引き続き強く、LLMを差し替えるだけでは検索精度が伸びない場面が増えた
LLM側だけを追いかけると、検索が古い埋め込みで詰まったまま「LLMがうまく答えない」と誤診する例が起きます。RAG運用では、埋め込み側の再評価を年1〜2回のペースで組み込むのが2026年後半の実務解です。
LLM側の判断軸：日本語精度と推論効率で先に絞る
LLM選定では、ライセンスやベンチマーク順位だけで決めず、次の4軸で並べます。
| 比較軸 | 確認すること | 実務上の意味 |
|---|---|---|
| ライセンス | 商用利用、再配布、利用者数上限 | SaaS化や外販の可否を左右する |
| 日本語出力品質 | 用語、敬語、社内文書の再現 | 業務での納得感と修正工数に効く |
| 推論効率 | 必要GPU、量子化耐性、応答遅延 | 継続運用の総コストと定着率に効く |
| コンテキスト長 | 長文入力の上限、根拠テキスト量 | 引用付き回答のしやすさを決める |
主要オープンウェイトLLMの一次候補（2026年後半）
| モデル | ライセンス | 主な特徴 | 向くケース |
|---|---|---|---|
| Qwen 3.6シリーズ | Apache 2.0 | 日本語を含む多言語、幅広い規模帯 | 汎用RAG、日本語ナレッジ検索 |
| Nemotron 3 Ultra | 開放ライセンス | 550B/55B activeのMoE、1Mコンテキスト、RAG向け設計 | 長文根拠を扱う高精度RAG |
| Llama 4 Scout／Maverick | Llama 4 Community License | マルチモーダル、長大コンテキスト | 図表を含む文書のRAG |
| DeepSeek V4 | MIT | 推論・コーディング系で商用APIに肉薄 | 論理整合が問われる回答生成 |
| Mistral Large 3／Medium 3.5 | Apache 2.0（要公式確認） | dense/密〜MoE、欧州データ主権に強い | EU規制対応、軽量PoC |
| Gemma 4 | Apache 2.0 | 軽量、単一GPUで動かしやすい | 短期PoC、オンデバイス補助 |
Llama 4はMeta独自のCommunity Licenseで、700M MAU超の事業者に別許諾を求めます。中小企業の社内利用では通常該当しませんが、外販時は事前確認が必要です。
日本語出力の品質は、公開ベンチマーク順位ではなく、自社の実文書を投げてブレを見るのが確実です。同じ入力で3回程度の再生成を比較し、要約・引用抜き出し・敬語整合を見ます。
埋め込みモデル側の判断軸：多言語・次元数・推論工数
埋め込みモデルは、日本語文書検索の精度そのものを左右します。LLMを強くしても、埋め込みが弱いと検索段階で外し、LLMが「根拠に無いこと」を答えてしまいます。
| 比較軸 | 確認すること | 実務上の意味 |
|---|---|---|
| 多言語対応 | 日本語を含む言語数、公式評価 | 社内文書と英語資料の混在に効く |
| 次元数 | 埋め込みベクトルの次元 | ベクトルDBの容量と検索遅延に影響 |
| 推論効率 | 1文書あたりの生成コスト、GPU要件 | 大規模再インデックスの実現性を決める |
| ライセンス | 商用利用と再配布条件 | 顧客提供時の可否を左右する |
主要オープンウェイト埋め込みモデル（2026年後半）
| モデル | 提供元 | ライセンス | 主な特徴 |
|---|---|---|---|
| Qwen3-Embedding | Alibaba | Apache 2.0 | 0.6B/4B/8Bの3規模、MTEB v2で開放ウェイト上位 |
| BGE-M3 | BAAI | MIT | 100超言語、Dense/Sparse/Multi-Vectorを1モデルで扱える |
| multilingual-e5-large | Microsoft | MIT | 94言語、1024次元、実装事例が多い |
| Qwen3-Reranker | Alibaba | Apache 2.0 | 0.6B/4B/8Bの3規模、検索候補の並び替え専用 |
Qwen3-Embedding 8BはMTEB v2で開放ウェイトの上位に位置し、多言語での安定した検索精度が報告されています（Qwen3 Embedding論文）。BGE-M3は密ベクトル・疎ベクトル・マルチベクトルを1モデルで扱える点が実務で有利です。
日本語検索では、埋め込み単体で決めず、リランカーで並び替える2段構成が実務では強く出ます。リランカーは推論遅延を増やすため、応答時間の要件と一緒に判断します。
実装・運用で確認すべき項目
RAG運用では、モデル選定と同じ比重で、データ・ログ・評価の設計を決めます。ここが抜けると、モデルを差し替えても品質が伸びません。
導入前に確認する項目:
- チャンク戦略：文書の分割単位、重複幅、メタデータ付与の方針
- 再インデックス頻度：ドキュメント更新から検索反映までの許容時間
- 評価データ整備：正解回答と根拠箇所を100〜300件先に用意する
- 回答フォーマット：引用元URL、章番号、根拠テキストの表示ルール
- ハルシネーション対策：出典が無い場合の「答えない」応答テンプレート
- 監査ログ：誰がどの質問をし、どの文書が返ったかの記録要件
- 権限管理：文書ごとの閲覧権限を検索段階で反映する仕組み
- モデル差し替え計画：LLM／埋め込み／リランカーそれぞれの評価データと差分管理
運用開始後に見る指標:
- 検索ヒット率（上位5件に正解文書が含まれる割合）
- 引用付き回答率（根拠付きで回答できた割合）
- 幻覚率（根拠と回答が食い違う割合）
- ユーザー修正率（回答に対して人が修正したり再質問した割合）
- 応答遅延（p50、p95、p99）
- 月次GPU／API費用と1回答あたりコスト
注意 ベンチマーク順位や公開スコアは、社内文書での再評価をスキップしません。日本語業務や社内固有の用語では、公開スコアと実務精度がずれることが多々あります。
リスクと限界：オープンウェイトRAGを止めるべき条件
オープンウェイトLLMで社内RAGを回すと、商用APIより運用責任が自社に寄ります。次の条件に当てはまる場合は、無理に自社ホスティングにこだわらず、商用APIとの併用か、専用ホスティングAPIに切り替えたほうが健全です。
- 24時間365日のSLA監視と障害対応を担える人員が確保できない
- 月次GPU費用が商用API利用より恒常的に高くなる見込み
- 日本語出力品質が、社内評価データで商用APIとの差を埋められない
- ライセンス条件（利用者数、再配布、
Built with表示）が事業モデルと整合しない - モデル差し替えのたびに全社評価が数週間止まる運用になっている
- セキュリティ要件（監査ログ、権限管理、データ保持）を運用側で担保できない
RAG運用は、モデル選定より運用ループの設計で差が出ます。オープンウェイトを選ぶ理由が「安く済むから」だけの場合は、実質的な運用コストで逆転するリスクがあります。
Blackfordの見解：RAGを「モデル選定」ではなく「運用ループ設計」で見る
Blackford Technologiesは、社内RAGを「どのLLMを選ぶか」ではなく「どのデータ・評価・運用ループを組むか」で捉えることを推奨します。モデルは代替可能な部品として扱い、業務課題・データ・評価・監視・改善を同じテーブルで設計します。
RAG導入を検討する際にBlackfordが提供できる観点は次の通りです。
- 業務課題整理：どの検索・回答業務を、どの精度で、どのSLAで運用するかを決める
- データ設計：社内文書の分類、権限、更新頻度、メタデータ付与を業務側と合意する
- モデル選定：LLM・埋め込み・リランカーを自社評価データで比較し、置き換え可否を判断する
- クラウド構成：オンプレ、VPC型基盤の
/dataroid-cloud、社内設置型の/dataroidを、業務データの機密度で振り分ける - 評価・監視：検索ヒット率、幻覚率、応答遅延、月次コストをダッシュボード化する
- 運用体制：モデル差し替え、再インデックス、社内問い合わせ対応の責任者と頻度を決める
社内AI基盤としての社内設置型/dataroid、既存クラウドを活かす/dataroid-cloud、営業データを扱う/salesroidは、RAG運用の設計次第で使い分けます。プロダクトありきではなく、業務課題とデータから逆算する順番が重要です。
よくある質問
オープンウェイトLLMと商用APIは、社内RAGでどう使い分ければよいですか？
機密度と運用体制で分けます。機密度が高い社内文書はオープンウェイトLLMをVPCやオンプレで動かし、社外向けや軽い対話は商用APIに任せる構成が実務では現実的です。運用人員が薄い場合は、まず商用APIでRAGを立ち上げ、負荷とコストが読めた段階でオープンウェイトへ寄せます。
埋め込みモデルを差し替えると、既存のベクトルDBはどうなりますか？
既存ベクトルは基本的に再生成が必要です。埋め込みモデルが違うとベクトル空間が別物になるため、そのまま検索に混ぜられません。差し替えは、全文書の再インデックス時間と業務停止影響を見積もり、切り替え期間中の並行運用を計画します。
日本語文書のRAGに、多言語モデルとは別に日本語専用モデルを使うべきですか？
まずは多言語モデルから始めて、実データで不足が出た場合に検討します。Qwen3-EmbeddingやBGE-M3などの多言語モデルは日本語を含めて実務水準に達しており、いきなり日本語専用モデルに寄せる必要は薄いです。ただし、法務・医療など専門用語が多い領域では、後から専門特化モデルの追加検討が有効です。
リランカーは必ず入れるべきですか？
必須ではありませんが、検索精度に伸び悩みがあるなら効果が出やすい追加です。リランカーは検索候補の並び順を再評価するため、上位n件に正解を入れ込む力が上がります。ただし推論遅延が増えるため、応答時間の要件と月次GPU費用の増加を先に見積もります。
オープンウェイトLLMの社内運用で、最初に整備すべき指標は何ですか？
検索ヒット率、幻覚率、月次コストの3つを先に整えます。検索ヒット率で「そもそも根拠が拾えているか」を見て、幻覚率で「LLMが根拠通り答えているか」を見ます。月次コストは、GPU使用時間・API併用費・運用人件費まで含めて算出します。
まとめ：モデル選定は目的ではなく「運用ループの1部品」
社内RAGでオープンウェイトLLMを選ぶときは、モデル単体比較で終わらせず、埋め込み・リランカー・評価・運用体制を同じ設計に載せます。2026年後半は、Qwen3-EmbeddingやBGE-M3といった開放ウェイト埋め込みの選択肢が広がり、LLM側もNemotron 3 UltraやQwen 3.6シリーズなどRAG向け設計が増えました。
ただし、日本語文書での実務精度は公開ベンチマークだけでは決められません。自社の実データで評価データを先に作り、モデルを差し替えられる運用ループを設計することが、オープンウェイトRAGを長く運用する条件です。
自社での運用設計に迷う場合は、業務課題・データ機密度・既存クラウド構成を整理したうえで、専門家に相談することをおすすめします。
＼社内RAGの運用設計を相談できます／ Blackfordに相談する
