安全なローカルRAG構築：Ollama×Chromaで作る
完全オフラインのドキュメントQ&Aシステム
社外秘ドキュメントを1バイトも外に出さない。Ollama＋埋め込みモデル＋ベクターDBによる、ゼロ・データ漏洩のローカルRAG構築術 ―― そして「結局どのモデルを選ぶべきか」を徹底解説
📋 目次
🔒 なぜ「ローカルRAG」が必要なのか
社外秘ドキュメントとAIを安全に組み合わせるための大前提
RAGは「持ち込みあり試験」のようなもの
RAG（検索拡張生成）の仕組みは、しばしば「オープンブック試験」にたとえられます。資料を持ち込めない「クローズドブック試験」では学習済みの記憶だけで答えますが、RAGは辞書や教科書を参照しながら回答する「オープンブック試験」のようなものです。LLMは追加トレーニングなしで、自社固有のドキュメントを参照しながら回答できるようになります。
なお「動いているように見えるが、本当に文書の内容どおりに回答しているか」は別問題です。RAGの回答品質を測る評価フレームワークとして、生成された回答が検索結果に忠実かどうかを採点する「Faithfulness（忠実性）」のような指標も研究されています。本記事ではモデル選定に焦点を当てますが、本番運用に乗せる際はこうした評価の仕組みも合わせて検討すると安心です。
クラウドAIで実際に起きた漏洩事例
2023年3月、韓国サムスン電子では、導入からわずか20日でChatGPT関連の情報漏洩が3件発生しました。エンジニアがソースコードのバグ修正を依頼したケースや、社内会議の録音をテキスト化して入力したケースが原因です。サムスンは緊急措置としてプロンプトの容量を制限し、最終的に社内でのChatGPT利用を全面禁止しました。同時期、Apple・Amazon・JPモルガン・チェースなど複数の大手企業も同様の利用制限を行っています。
📊 データの流れ：クラウドAPI型 vs 完全ローカル型
地味に大きい法務メリット
クラウドの生成AIに個人情報を含むデータを入力する場合、提供先が国外にあるAIベンダーであれば、個人情報保護法28条の「外国にある第三者への提供」規制との関係を検討する必要があります（基準適合体制の整備や本人同意が論点になります）。一方、データがネットワークを一度も通過しない完全ローカル構成では、そもそも「提供」という行為自体が発生しないため、この論点ごと回避できます。
🧬 埋め込みモデル選定の裏側
nomic-embed-textは「正解」なのか、それとも「選択肢の一つ」なのか
埋め込みモデルは何をしているのか
埋め込み（Embedding）モデルは、文章を「意味の近さ」を表す数百〜数千次元の数値ベクトルに変換します。「プロジェクトXの予算は？」という質問と「プロジェクトXの予算計画」という文書チャンクは、文字列としては違っても、ベクトル空間上では近い場所に配置されます。逆に「プロジェクトXの予算は？」と「来週の懇親会の場所」のように意味が遠い文章同士は、ベクトル空間上でも遠く離れた場所に配置されます。この距離の近さ・遠さを使って関連文書を検索するのがRAGの土台です。多くのチュートリアルはnomic-embed-textを「定番」として紹介しますが、実際には用途によって最適解が変わります。
nomic-embed-text
開発元：Nomic AI
重み・学習コード・学習データの収集手順まで含めて完全に公開された、再現可能性を重視するモデル。最大の特徴は8,192トークンという長いコンテキスト長です。多くのオープンソース埋め込みモデルが512トークン程度で設計される中、長い社内マニュアルや議事録を分割しすぎずに、ひと続きの意味を保ったままベクトル化できます。法務文書や研究レポートのような「長文を丸ごと検索したい」用途に向いています。
mxbai-embed-large
開発元：Mixedbread AI
335Mパラメータ級ながらBERT大型クラスでトップクラスの性能を示し、ベクトル次元を落としても精度を維持しやすいのが特徴。Apache 2.0ライセンスで商用利用しやすく、「まず何を選べばいいか分からない」場合の標準装備として紹介されることが多いモデルです。
BGE-M3
開発元：BAAI
100以上の言語をサポートし、多言語・クロスリンガル検索に優れたモデル。単一フレームワークで高密度検索・マルチベクトル検索・スパース検索の3方式に対応します。日本語ドキュメントと英語ドキュメントが混在する社内ナレッジベースなど、言語が混じる環境で強みを発揮します。
EmbeddingGemma 系
開発元：Google
軽量かつ100以上の言語をカバーするモデル群。CPUのみのノートPCや、リソースが限られた環境でのPoC（概念実証）に向いています。精度面では大型モデルに一歩譲る場面もありますが、「とにかく動かしてみたい」という最初の一歩には十分な性能です。
jina-embeddings-v2-base-code
開発元：Jina AI
ソースコードと自然言語の混在検索に特化したモデル。社内のコードベースやAPI仕様書をRAG化したい場合に向いています。応答速度が比較的速い一方、汎用文書での回答精度はnomic-embed-textやmxbai-embed-largeにやや劣るという検証結果もあり、「コード検索だけに使う」など用途を絞った採用が現実的です。
📊 埋め込みモデル比較（目安スコア）
| 評価項目 | nomic-embed-text | mxbai-embed-large | BGE-M3 |
|---|---|---|---|
| 長文対応力 | |||
| 日本語・多言語適性 | |||
| 軽量さ・速度 | |||
| 商用ライセンスの自由度 | ◎ Apache 2.0 | ◎ Apache 2.0 | ◎ MIT系・要確認 |
※ スコアは各モデルの設計特性に基づく目安であり、厳密なベンチマーク数値ではありません。本番導入前には自社ドキュメントでのA/Bテストを推奨します。
ベンチマークだけで決めてはいけない
埋め込みモデルの選定は精度・速度・コスト・運用制約を同時に左右し、後からの入れ替えコストも高い意思決定です。ベンチマークはあくまで指標の一つに過ぎず、未知のドメインや専門用語が多い社内文書では、自社のドキュメントと代表的な質問パターンを使ってA/Bテストするのが最短ルートです。
地味に重要：チャンクサイズはモデルのコンテキスト長と連動する
ハンズオンのコードではchunk_size=500（文字数）に分割していますが、この数値は埋め込みモデルが一度に処理できるコンテキスト長と無関係ではありません。512トークン前後で設計されたモデルに長いチャンクを渡すと、後半部分が切り捨てられたり意味の希薄化が起きたりします。逆にnomic-embed-textのように8,192トークンを扱えるモデルなら、章単位でまとめた大きめのチャンクでも意味のつながりを保ったままベクトル化できます。「どの埋め込みモデルを選ぶか」と「チャンクをどう切るか」は本来セットで決めるべき設計判断です。
🦙 LLM選定の裏側とライセンス論点
回答生成を担うLLMは何を基準に選ぶべきか
なぜQwen3系がよく使われるのか
Qwen3はAlibaba Cloudが開発するLLMファミリーで、0.6B〜235B-A22Bまで幅広いサイズ展開と、複雑な推論ではステップバイステップで考える「Thinkingモード」、シンプルな対話では高速応答する「Non-Thinkingモード」を切り替えられるハイブリッド推論が特徴です。シングルGPU、あるいはCPUだけでも動かせる4B・8Bクラスのモデルは、ローカルRAGの回答生成役として広く使われています。
Qwen3-4B
Alibaba Cloud
シングルGPUでの利用に適したサイズながら、前世代の大規模モデルに匹敵する性能を持つとされるモデル。ネイティブで32,768トークン、YaRN技術を使えば最大131,072トークンまでコンテキスト長を拡張可能です。
Qwen3-8B
Alibaba Cloud
4Bよりワンランク上の精度を求める場合の選択肢。エージェント的なタスクやツール呼び出しの精度も強化されており、複数ステップの推論を要する質問応答で安定感が増します。
Qwen3.5-4B
Alibaba Cloud
Gated DeltaNetという線形アテンション機構を採用した新世代の小型モデル。従来のソフトマックスアテンションよりも長文処理の計算コストを抑えやすく設計されています。Qwen3系からの乗り換え先として最新の選択肢です。
Llama 3.2 / Gemma系
Meta / Google
処理速度を最優先したい場合の代替候補。検証によっては前世代のLlamaモデルより処理速度が大幅に向上しているケースもあり、「精度よりレスポンス優先」のチャットボット用途で検討する価値があります。
📊 LLM比較（目安スコア）
| 評価項目 | Qwen3-4B | Qwen3-8B | Qwen3.5-4B |
|---|---|---|---|
| 推論速度 | |||
| 推論精度（目安） | |||
| 必要VRAM（4bit量子化時） | 約4〜6GB | 約6〜10GB | 約4〜6GB |
| 思考モード | ○ 切替式 | ○ 切替式 | △ デフォルト無効 |
※ スコアは公開情報に基づく傾向の目安です。実際の速度・精度はハードウェアと量子化形式によって変動します。
GGUF量子化を理解すると、選べるモデルの幅が広がる
Ollamaで配布されているモデルの多くはGGUF形式の量子化版です。同じQwen3-8Bでも、16bitのフル精度版なら16GB前後のVRAMが必要ですが、4bit量子化版なら6〜10GB程度のVRAMでも動かせます。精度はわずかに落ちますが、「VRAM 8GBのノートPCだから諦める」のではなく「量子化レベルを落として同じモデルを動かす」という選択肢があることを知っておくと、モデル選定の自由度が大きく変わります。
DenseモデルとMoEモデルの違い
Qwen3ファミリーには、すべてのパラメータが常に計算に参加する「Dense（密）モデル」（0.6B〜32B）と、入力ごとに一部の専門家ネットワークだけを起動する「MoE（Mixture of Experts）モデル」（235B-A22Bなど）の2系統があります。MoEは総パラメータ数が巨大でも、トークンごとに実際に使われるのは一部だけなので、推論コストを抑えながら高い性能を狙える設計です。ローカルPCで動かす4B〜8BクラスはほぼDenseモデルなので、この記事のハンズオンではDenseモデルの選定がそのまま当てはまります。
Apache 2.0ライセンスの中身
Qwen3系モデルの多くはApache 2.0ライセンスで提供されています。これは「商用利用を含めあらゆる目的で無料で利用・改変・再配布できる」「再配布時には元の著作権表示とライセンス条文を含める必要がある」という比較的自由なライセンスです。ただし、モデルバリアントごとにライセンス条件が異なる場合もあるため、商用デプロイ前には各モデルカードの最新記載を個別に確認するのが安全です。
「モデルの出自」を意識すべき場面とは
Qwen系はAlibaba Cloud（中国）が開発しています。一部の企業向けコンプライアンスチェックリストでは、DeepSeekやQwen、MiniMaxなど中国系AIサービスをクラウドAPI経由で業務利用する場合、中国の個人情報保護関連規制（PIPL）の越境移転規制を確認すべきという項目が挙げられています。規制の厳しい業界（金融・医療・政府機関）では、こうした観点での調達審査が課題になることもあります。
ただし、これはあくまでクラウドAPIとして使う場合の論点です。本記事のようにOllamaでウェイトをダウンロードし、インターネット接続を切った状態でローカル実行する場合は、推論時に外部へ通信が発生しないため、越境移転規制そのものが適用される場面がありません。「モデルの開発元がどこか」と「データがどこへ送られるか」は別の論点として整理しておくと、社内説明がしやすくなります。
🛠️ 実装ハンズオン：5ステップで動かす
LangChain + Ollama + Chromaで組む最小構成
🛠️ モデルの準備
埋め込みモデルとLLMの2つをOllamaにダウンロードします。
# テキストを数値化（ベクトル化）する軽量・高性能モデル ollama pull nomic-embed-text # 質問に回答するLLM（例：日本語に強く軽量なQwen3の4Bモデル） ollama pull qwen3:4b
📦 ライブラリのインストール
LangChainとChromaを使うための依存パッケージを入れます。
pip install langchain langchain-community langchain-chroma chromadb
📁 ドキュメントの読み込みと分割
docsフォルダ内のテキストを読み込み、ベクターDBに入りやすいサイズに分割（チャンク化）します。
from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter # docsフォルダ内のすべての.txtファイルを読み込む loader = DirectoryLoader('./docs', glob="**/*.txt", loader_cls=TextLoader) documents = loader.load() # 長い文章を適切なサイズに分割 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=100) texts = text_splitter.split_documents(documents)
🧠 ベクトル化してChromaに保存
nomic-embed-textで埋め込みを生成し、ローカルの./dbフォルダに保存します。
from langchain_community.embeddings import OllamaEmbeddings
from langchain_chroma import Chroma
embeddings = OllamaEmbeddings(model="nomic-embed-text")
# ローカルの「db」フォルダにベクトルデータを保存（完全オフライン）
vector_store = Chroma.from_documents(
documents=texts,
embedding=embeddings,
persist_directory="./db"
)
💬 検索＆回答生成
質問に関連するチャンクを検索し、Qwen3に渡して回答を生成します。
from langchain_community.llms import Ollama
from langchain.chains import RetrievalQA
retriever = vector_store.as_retriever(search_kwargs={"k": 3})
llm = Ollama(model="qwen3:4b", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
llm=llm, chain_type="stuff", retriever=retriever
)
query = "社外秘プロジェクト『X』のリリース時期と注意点は何ですか？"
response = qa_chain.run(query)
print(response)
🔍 実行時に裏側で起きていること
⚠️ 知っておくべき新しいリスク
ローカル化で消えるリスクと、新たに生まれるリスク
「ローカルだから絶対安全」ではない
完全オフラインのRAGはクラウドへのデータ送信リスクをゼロにしますが、RAG特有の別の攻撃面が存在します。検索対象の文書に悪意あるテキストが混入していると、LLMがそれを「指示」として読み込んでしまう「間接プロンプトインジェクション」が発生し得ます。これは通常のプロンプトインジェクションと異なり、利用者が直接入力していない場所（取り込んだ文書そのもの）が攻撃の入り口になる点が特徴です。
社外から取得したPDFやWebページをそのままdocsフォルダに放り込むチュートリアル的な使い方は、出典が不明なテキストや改ざんされた文書を無自覚に取り込むリスクがあります。社外秘ドキュメントのRAG化では、信頼できる社内ソースのみを読み込み対象にすることが基本的な防御線になります。
「合言葉はXXです」のような機密情報をプロンプトやシステムプロンプトに直接書き込むのは避けてください。プロンプトインジェクション攻撃を受けると、AIは指示を無視してそのままシステムプロンプトを出力してしまうことがあります。機密情報は関数呼び出し（Function Calling）の裏側など、プロンプトの外側に隠蔽する設計が安全です。
「誰でも検索できる」状態にしていないか
個人やチームでのPoCではあまり意識されませんが、複数人が使うナレッジベースに育てていく場合は、ベクターDBに全文書を入れて誰でも検索可能にしてしまう実装はリスクが高い、という指摘があります。役員報酬規定や人事評価のような閲覧範囲が限定された文書を混在させる場合は、検索後にアクセス権限でフィルタリングするのではなく、検索対象に含めるかどうかの時点で権限を分ける設計が望ましいとされています。個人用のローカルRAGから一歩進めて社内共有ツールへ拡張する際は、この点を意識しておくと安心です。
📝 まとめ：用途別モデル選びチェックリスト
結局、何を選べばいいのか
「正解の構成」は存在しない
ここまで見てきたように、埋め込みモデルにもLLMにも一つの「正解」はありません。長文の法務文書を扱うなら長いコンテキスト長を活かせるnomic-embed-text、日本語と英語が混在する環境ならBGE-M3、まずは動かしてみたいだけならEmbeddingGemma系といった具合に、扱う文書の性質と使える計算リソースの両方から逆算するのが現実的です。同じ考え方はLLM側にも当てはまり、推論速度を優先するか、エージェント的な複雑なタスクへの強さを優先するかで4Bと8Bの選択は変わってきます。以下のチェックリストを、構成検討の出発点として使ってください。
📄 長文の法務・研究文書中心
- 埋め込みモデル → nomic-embed-text
- LLM → Qwen3-8B（精度重視）
🌏 日本語・多言語が混在
- 埋め込みモデル → BGE-M3
- LLM → Qwen3-4B（多言語対応）
🪶 まずPoCで試したい
- 埋め込みモデル → EmbeddingGemma系
- LLM → Qwen3-4B（軽量・CPUでも可）
🆕 最新性能を試したい
- 埋め込みモデル → mxbai-embed-large
- LLM → Qwen3.5-4B（2026年3月リリース）
データは外に出ない
Wi-Fiを切断しても同じ結果
第三者提供規制が論点外
28条の越境移転規制も対象外
モデルは用途で選ぶ
ベンチマークより自社データで検証
新しいリスクは別途存在
間接プロンプトインジェクションに注意
□ インターネット接続を切断した状態で動作確認済み
□ 採用した埋め込みモデル・LLMのライセンスを確認済み
□ 読み込み対象ドキュメントの出典を信頼できるソースに限定済み
□ 機密情報をプロンプト直書きしていないことを確認済み
コメント