なぜローカルRAGなのか
社内文書を SaaS 検索や外部 LLM に丸投げできない業界（医療・金融・士業・自治体・防衛装備サプライ）では、RAG（Retrieval-Augmented Generation）をローカル完結で組む需要が 2026 年にかけて急増した。本稿では Open WebUI + Ollama + Chroma + 日本語埋め込みモデル、という中小企業でも届く構成を、設計・実装・運用の3段で解説する。なお記述は各プロジェクトの公開ドキュメントに基づく一般的構成であり、実環境での性能・品質は要件次第である点にご留意いただきたい。
アーキテクチャ全体像
構成要素は次の通り。
- 推論層: Ollama（OpenAI 互換 API）、生成モデルは Qwen3-14B-Instruct や Llama 3.x-8B 等
- 埋め込み層: 日本語対応の埋め込みモデル（multilingual-e5-large、bge-m3、jina-embeddings 系など）
- ベクタDB層: Chroma（ローカルファイル DB として手軽。中規模以上は Qdrant への移行を想定）
- UI 層: Open WebUI（社内 Web アクセス、ユーザ管理、RAG パイプライン）
- ジョブ層: 取り込みワーカー（PDF/DOCX/PPTX → テキスト → 分割 → 埋め込み → 投入）
すべて Docker Compose で1ホストに収まる構成から始め、トラフィックが増えたら推論ノードと取り込みノードを分離する2段階アプローチが現実的だ。
チャンク戦略：日本語固有の落とし穴
日本語文書のチャンク化では、英語前提の固定文字数分割（例: 1000 chars）は失敗しがちだ。日本語1文字は英語数文字に相当する情報量を持ち、500-800 文字程度で英語の 1000-1500 トークン相当になる。さらに長文の段落構造、箇条書き、表組みを尊重したセマンティックチャンク化が品質に効く。
```python # LangChain RecursiveCharacterTextSplitter の日本語向け設定例 from langchain_text_splitters import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter( separators=["\n\n", "\n", "。", "、", " ", ""], chunk_size=600, chunk_overlap=80, length_function=len, ) chunks = splitter.split_text(doc_text) ```
`separators` に日本語の句点・読点を含めるだけで、文の途中で切れる事故が大幅に減る。表や箇条書きは Markdown へ事前変換し、リスト要素単位でチャンクを切ると検索ヒット率が上がりやすい。
埋め込みモデル選定
日本語向け埋め込みは選択肢が増えた。multilingual-e5-large はバランス型、bge-m3 はマルチリンガル＋ハイブリッド検索（dense + sparse）、jina-embeddings-v3 は長文コンテキスト対応で日本語を含む多言語ベンチで好成績が公開されている、といった特徴がある。中小企業の最初の一歩としては multilingual-e5-large または bge-m3 を Ollama または専用埋め込みサービス（text-embeddings-inference 等）で立てる構成が手堅い。
Chroma へのインデックス投入
Chroma はローカルファイル DB として運用しやすく、Python から数十行で動かせる。
```python import chromadb from chromadb.config import Settings
client = chromadb.PersistentClient(path="./chroma_db") collection = client.get_or_create_collection( name="kga_internal_docs", metadata={"hnsw:space": "cosine"}, )
collection.add( ids=ids, documents=chunks, embeddings=embeddings, metadatas=metas, # 出典・権限ラベル・更新日時 ) ```
`metadatas` に部署・機密ラベル・原本URLを必ず入れておくのが運用の肝だ。検索時にユーザの所属に応じて metadata フィルタを掛ければ、権限境界をまたぐ漏洩を簡易に防げる。
Open WebUI への組み込み
Open WebUI は Pipelines という拡張機構を持ち、リクエスト前後に Python 関数を挟める（公式ドキュメント記載）。社内 RAG では「ユーザの質問 → ベクタ検索 → 再ランク → 生成プロンプト組み立て → Ollama 呼び出し → 出典挿入」の流れをパイプラインとして書く構成が標準的だ。
再ランクには bge-reranker-v2-m3 などの cross-encoder を使い、初段で top-50 を取って top-8 に絞ると、生成側のコンテキスト圧迫を避けつつ精度を保ちやすい。
評価とハルシネーション対策
ローカル RAG の品質は「正答率」と「出典提示率」「過剰自信率（出典なしで断定する率）」の3点で見るのが実用的だ。Ragas や独自評価セットで月次回帰し、しきい値割れで再学習・再インデックスを発火させる運用が望ましい。
ハルシネーション抑制には、(1) システムプロンプトで「提示文書外の情報は答えない」と明示、(2) 出典を必ず本文末に列挙、(3) 信頼度の低い回答には「不明」を返すルール、の3点を最低限組み込みたい。
KGA IT の実装テンプレ
KGA IT では、上記スタックを Docker Compose 化したテンプレートを案件ベースで提供している。文書取り込みは Tika ベースで PDF/Office 文書を網羅し、権限ラベルは Active Directory 連携で自動付与、UI は Open WebUI に SSO を被せる構成である（公開情報ベースの一般的構成）。中小企業の最初の RAG は、機能を盛らず「社内 FAQ＋規程集」から始めるのが成功率が高い、というのが現場の知見だ。