ローカルLLM×RAGの作り方｜オフライン実装【2026年10月】

ここからは、ローカルLLMとRAGの役割を整理したうえで、OllamaとLangChainを使う再現可能な実装へ進みます。掲載コードは公式ドキュメントの2026年10月4日版に合わせ、古い/api/embeddingsではなく現行の/api/embedに対応するOllamaEmbeddingsを使います。

当日の更新確認：Ollama v0.35.1は2026年9月29日（UTC）公開の安定版です。直近2週間のOllama／LangChain公式更新を確認した範囲では、この記事で使う/api/embed、OllamaEmbeddings、ChatOllama、Chroma永続化の基本構文を変更する告知はありませんでした。

ローカルLLMだけでは文書検索にならない

ローカルLLMとRAGは、置き換え関係ではありません。ローカルLLMは文章を生成する役、RAGは質問に関係する資料を選んで生成前に渡す役です。RAGを追加してもモデル自体が再学習されるわけではなく、回答のたびに取得した文脈を入力へ加えます。

たとえば「出張精算の締切はいつか」と質問しても、社内規程を入力していないローカルLLMは、その会社固有の締切を知りません。RAGでは、質問をベクトルへ変換し、規程の断片から意味が近い箇所を検索し、その本文と出典をモデルへ渡します。資料に答えがなければ「確認できない」と返す指示も加えます。

部品	担当する処理	今回の実装	切り分ける症状
文書取り込み	PDFから本文とページ情報を読む	pypdf	文字が空、表の順序が崩れる
分割	検索しやすい断片へ分ける	RecursiveCharacterTextSplitter	必要箇所が別チャンクへ切れる
埋め込み	文書と質問を同じベクトル空間へ写す	OllamaEmbeddings	関連文書が上位に来ない
保存・検索	ベクトル、本文、メタデータを保持して検索する	Chroma	古い版や別部署の文書が混ざる
生成	取得文書だけを根拠に回答を組み立てる	ChatOllama	取得は正しいのに回答が逸れる

RAG全体の定義やファインチューニングとの違いから確認したい場合は、既刊のRAGとは｜仕組み・作り方・精度を上げる順番を先に読むと、今回の実装がどこに位置するかをつかみやすくなります。

オフラインRAGの境界を先に決める

「Ollamaを使っているからオフライン」とは限りません。現在のOllamaはローカルモデルとクラウドモデルの両方を扱えます。LangChain側でも、クラウド型の埋め込み、クラウド型ベクトルDB、LangSmithトレースを選べます。つまり、生成モデルだけをローカルにしても、アプリ全体がオフラインとは言えません。

今回の構成では、次の境界を採用します。対象文書はPC内のdataディレクトリから読み、埋め込みと生成は
PH_2_のOllamaへ接続し、ChromaはPC内のchroma_dbへ保存します。外部URLを読むローダー、クラウドモデル、クラウドDB、外部トレースは使いません。

• オンライン準備：Ollama本体、Pythonパッケージ、生成モデル、埋め込みモデルを取得する
• ローカル実行：文書の読み込み、分割、埋め込み、保存、検索、生成をPC内で行う
• 別途確認：OSや周辺アプリを含む外向き通信、ログ保存先、バックアップ経路を確認する

Ollama公式FAQは、ローカル実行時にプロンプトやデータをOllama側で見ないと説明する一方、クラウドモデル利用時はサービス提供のために内容を処理すると分けています。また、クラウド機能を無効化するOLLAMA_NO_CLOUD=1とdisable_ollama_cloudの設定も案内しています。したがって「Ollama」という製品名ではなく、どのモデルと接続先を使うかまで記録する必要があります。

社内文書を入れる前に確認すること

ベクトルDBには、埋め込みだけでなく検索結果として返す本文断片やメタデータも保存します。元PDFと同じ機密区分で保存先を扱い、OSのアクセス権、端末暗号化、バックアップ、削除手順を決めてください。アクセス権の異なる部署文書を1つのコレクションへ混在させると、検索結果を通じて本来見えない本文が渡る可能性があります。ローカル化は通信経路を減らしますが、権限設計の代わりにはなりません。

埋め込みモデルとベクトルDBを選ぶ

生成モデルの大きさだけを比較しても、RAGの検索品質は決まりません。質問と文書の近さを計算するのは埋め込みモデルです。Ollamaの現行Embeddingドキュメントは、embeddinggemma、qwen3-embedding、all-minilmを推奨候補として挙げ、登録時と検索時に同じ埋め込みモデルを使うよう明記しています。

この実装では、多言語対応が公式に明記され、比較的取得しやすいqwen3-embedding:0.6bを例にします。Ollama Libraryの2026年10月4日表示ではファイル容量639MB、32Kコンテキストです。ただし、モデルページの多言語対応は日本語文書での優位性を保証するものではありません。自社の規程、略語、製品名を含む質問セットで比較してください。軽さを優先する場合は、公式推奨にあるembeddinggemmaも候補です。

ベクトルDBは「最も高性能なもの」を決めるより、運用形態に合わせます。最初の1台で永続化まで試すならChroma、単一プロセス内へ検索ライブラリとして組み込むならFAISS、後から独立サーバーやHybrid検索へ広げるならQdrantが判断しやすい分岐です。固定の件数しきい値は一次情報に共通基準がないため、利用人数、更新頻度、メタデータ絞り込み、バックアップ方法で選びます。

候補	ローカル構成	永続化	向く場面	注意点
Chroma	プロセス内／ローカルサーバー	persist_directory	まず永続化付きRAGを作る	プロセス内構成と本番サーバー構成を分けて考える
FAISS	単一プロセス内の類似検索ライブラリ	LangChainのsave_local	DBサーバーなしで検索を組み込む	保存メタデータの再読込は信頼できるファイルだけに限定する
Qdrant	RAM／オンディスク／独立サーバー	QdrantClient(path=...)	サービス化や検索方式の拡張を見込む	小規模ローカルモードとサーバー運用を混同しない

詳細な比較軸は、既刊のAIエージェント用ベクトルDB比較とEmbeddingモデル選定ガイドで補えます。今回はコードを短く保つためChromaを採用します。

OllamaとLangChainでローカルRAGを作る

実装は「モデル準備」「文書を索引へ登録」「質問して回答」の3つに分けます。以下のコードは構文確認済みですが、PCのメモリや対象PDFの構造は環境ごとに異なります。本番環境で使用する前に、必ずテスト環境で動作確認してください。

1. 生成モデルと埋め込みモデルを取得する

掲載例はPython 3.11、ローカルで起動したOllama、テキストを持つPDFを前提にします。生成にはqwen3.5:4b、埋め込みにはqwen3-embedding:0.6bを使います。モデルタグはollama pullとPythonコードで完全に一致させてください。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
ollama pull qwen3.5:4b
ollama pull qwen3-embedding:0.6b

python3 -m venv .venv
source .venv/bin/activate
python -m pip install -U \
  langchain-core \
  langchain-ollama \
  langchain-chroma \
  langchain-text-splitters \
  pypdf

mkdir -p data

Windows PowerShellでは仮想環境の有効化コマンドが異なりますが、PythonパッケージとOllama側のモデルタグは同じです。Ollama自体のインストールとローカルAPIの確認は、既刊のOllamaの使い方 2026を参照してください。

2. PDFを分割してChromaへ登録する

dataへPDFを置き、次をingest.pyとして保存します。ページ番号、ファイル名、分割開始位置をメタデータへ残し、検索後に出典を表示できるようにします。chunk_size=1000とchunk_overlap=200はLangChain公式チュートリアルにある汎用例であり、最適値ではありません。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
import hashlib
from pathlib import Path

from langchain_chroma import Chroma
from langchain_core.documents import Document
from langchain_ollama import OllamaEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter
from pypdf import PdfReader

DATA_DIR = Path("data")
DB_DIR = Path("chroma_db_v1")
COLLECTION = "local_docs_v1"
EMBED_MODEL = "qwen3-embedding:0.6b"


def load_pdf_pages(path: Path) -> list[Document]:
    reader = PdfReader(path)
    pages = []
    for page_number, page in enumerate(reader.pages, start=1):
        text = page.extract_text() or ""
        if text.strip():
            pages.append(
                Document(
                    page_content=text,
                    metadata={
                        "source": path.name,
                        "page": page_number,
                    },
                )
            )
    return pages


if DB_DIR.exists():
    raise SystemExit(
        "chroma_db_v1 は既に存在します。更新時は新しいDB名で再構築してください。"
    )

documents = []
for pdf_path in sorted(DATA_DIR.glob("*.pdf")):
    documents.extend(load_pdf_pages(pdf_path))

if not documents:
    raise SystemExit("data ディレクトリに文字抽出可能なPDFがありません。")

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200,
    add_start_index=True,
)
chunks = splitter.split_documents(documents)

embeddings = OllamaEmbeddings(
    model=EMBED_MODEL,
    base_url="http://localhost:11434",
)
vector_store = Chroma(
    collection_name=COLLECTION,
    embedding_function=embeddings,
    persist_directory=str(DB_DIR),
)

ids = []
for chunk in chunks:
    raw_id = "|".join(
        [
            str(chunk.metadata.get("source", "")),
            str(chunk.metadata.get("page", "")),
            str(chunk.metadata.get("start_index", "")),
            chunk.page_content,
        ]
    )
    ids.append(hashlib.sha256(raw_id.encode("utf-8")).hexdigest())

vector_store.add_documents(documents=chunks, ids=ids)
print(f"{len(chunks)} chunks indexed in {DB_DIR}")

同じディレクトリへ無条件に追加し続けると、更新前後のチャンクが混ざる原因になります。この例は既存DBがあれば停止し、chroma_db_v2のような新しい保存先へ再構築する設計です。検証後に参照先を切り替えれば、問題が起きたときに前の索引へ戻せます。

3. 検索結果をOllamaへ渡して回答する

次をask.pyとして保存します。重要なのは、回答を先にモデルへ考えさせるのではなく、まずChromaから文書を取得し、その本文と出典だけをプロンプトへ入れることです。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
import sys

from langchain_chroma import Chroma
from langchain_ollama import ChatOllama, OllamaEmbeddings

DB_DIR = "chroma_db_v1"
COLLECTION = "local_docs_v1"
EMBED_MODEL = "qwen3-embedding:0.6b"
CHAT_MODEL = "qwen3.5:4b"

question = " ".join(sys.argv[1:]).strip()
if not question:
    raise SystemExit('例: python ask.py "出張精算の締切はいつですか"')

embeddings = OllamaEmbeddings(
    model=EMBED_MODEL,
    base_url="http://localhost:11434",
)
vector_store = Chroma(
    collection_name=COLLECTION,
    embedding_function=embeddings,
    persist_directory=DB_DIR,
)

retrieved = vector_store.similarity_search(question, k=4)
context_parts = []
for doc in retrieved:
    source = doc.metadata.get("source", "不明")
    page = doc.metadata.get("page", "不明")
    context_parts.append(
        f"[出典: {source} / ページ: {page}]\n{doc.page_content}"
    )
context = "\n\n".join(context_parts)

prompt = f"""あなたは社内文書検索の回答担当です。
次の資料だけを根拠に、日本語で簡潔に回答してください。
資料に答えがない場合は「資料内では確認できません」と答えてください。
回答末尾に、使った出典のファイル名とページを列挙してください。

質問:
{question}

資料:
{context}
"""

llm = ChatOllama(
    model=CHAT_MODEL,
    base_url="http://localhost:11434",
    temperature=0,
)
response = llm.invoke(prompt)
print(response.content)

print("\n--- 取得結果 ---")
for doc in retrieved:
    print(doc.metadata)

実行例はpython ask.py "出張精算の締切はいつですか"です。回答だけでなく「取得結果」も確認してください。回答が間違っているとき、取得文書が違うなら検索側、取得文書が正しいならプロンプトまたは生成モデル側に原因を絞れます。

PDFが画像ならOCRを別工程にする

このコードのpypdfはOCRエンジンではありません。公式ドキュメントも、画像だけのスキャンPDFから文字を読めないと説明しています。PDF上の文字を選択・コピーできない場合は、OCRを先に行い、結果を人が確認してから索引へ登録してください。表もPDF内部に意味構造を持たないことがあるため、列の順序が崩れていないかをサンプル出力で確認します。

本当にオフラインかを確認する

アプリが動いたことと、通信せずに動いたことは別です。まずオンラインのうちにモデルとパッケージを取得し、テスト用PDFで索引を作ります。その後、Ollamaのクラウド機能を無効にして再起動し、ネットワークを切った状態で同じ質問が完了するかを確認します。

Ollama公式FAQが案内するローカル専用設定は次のとおりです。設定ファイルは~/.ollama/server.jsonです。既存設定がある場合は内容を消さず、該当キーを統合してください。

{
  "disable_ollama_cloud": true
}

環境変数を使う場合はOLLAMA_NO_CLOUD=1です。設定後にOllamaを再起動すると、ログへOllama cloud disabled: trueと表示されることが公式FAQに記載されています。さらに、次の項目を順番に確認します。

1. ollama lsで生成モデルと埋め込みモデルがローカルに存在する
2. Pythonコードの接続先がlocalhost:11434で、クラウドモデル名を使っていない
3. Chromaの保存先がローカルディレクトリで、Cloud接続設定がない
4. LANGSMITH_TRACINGなど外部トレースを有効にしていない
5. ネットワークを切った状態でも索引検索と回答生成が完了する
6. 組織の要件が厳しい場合は、OSの通信監視やファイアウォール記録でも外向き通信を確認する

この確認で言えるのは、検証した構成と条件でローカル処理が完了したという範囲です。「どの環境でもデータが絶対に外へ出ない」とは断定できません。自動バックアップ、エンドポイント管理、EDR、入力元アプリなど、RAGコード外の経路も組織側で確認してください。

検索精度は取得結果から直す

回答が弱いと、すぐ生成モデルを大きくしたくなります。しかし、正しい箇所が検索できていなければ、生成モデルを替えても根拠は増えません。まず「期待する文書断片が上位に入ったか」を評価し、その後に回答文を評価します。

質問と正解根拠を対にする

実際の利用者が聞きそうな質問を集め、各質問について「正解を含むファイル」「ページ」「答えがない場合の期待動作」を記録します。規程名をそのまま含む質問だけでなく、現場で使う略称や言い換えも入れます。文書にない質問では、もっともらしい回答ではなく「確認できない」が期待値です。

取り込みから生成まで段階ごとに見る

• 取り込み：文字が抽出され、見出し・表・ページ情報が壊れていないか
• 分割：質問への答えと条件・例外が同じ断片、または同時に取得できる範囲にあるか
• 埋め込み：登録と質問で同じモデル、同じ出力次元を使っているか
• 検索：正解根拠が上位へ入り、部署や版のメタデータで絞れているか
• 生成：取得文書だけを使い、出典と「該当なし」を守るか

埋め込みモデルを変更した場合は、既存のベクトルをそのまま使わず索引を再構築します。文書更新時も、元ファイルを置き換えるだけでは回答は更新されません。再抽出、再分割、再埋め込み、再登録までを一連の更新処理にしてください。

本番運用で起きやすい4つの落とし穴

失敗1：Ollamaを使えば自動的に完全オフラインだと思う

❌ 生成だけローカルにし、埋め込み、ベクトルDB、トレースはクラウドのままにする。
⭕ 各部品の接続先を一覧化し、モデル事前取得、クラウド無効化、切断テストまで行う。

なぜ重要か：データが通る経路は生成モデルだけではありません。質問、検索用ベクトル、取得本文、トレースのそれぞれを確認する必要があります。

失敗2：登録と検索で埋め込みモデルを変える

❌ 索引をembeddinggemmaで作り、質問だけqwen3-embeddingへ切り替える。
⭕ 同じモデルと次元を使い、変更時は別コレクションへ全件を再登録する。

なぜ重要か：Ollama公式は、索引作成と検索で同じ埋め込みモデルを使うよう案内しています。異なるベクトル空間を混ぜると、意味の近さを一貫して比較できません。

失敗3：スキャンPDFをそのまま投入する

❌ 文字を選択できないPDFをpypdfへ渡し、空の索引や崩れた本文に気づかない。
⭕ OCRと目視確認を前工程に置き、ページごとの抽出文字数とサンプル本文を確認する。

なぜ重要か：検索精度の調整以前に、根拠となる文字が索引へ入っていなければRAGは答えられません。

失敗4：回答だけを見て検索結果を保存しない

❌ 正解らしい文章が出れば合格とし、どの断片を取得したか記録しない。
⭕ 質問、取得文書、ファイル名、ページ、回答を1組で確認し、「該当なし」もテストする。

なぜ重要か：偶然正解した回答と、根拠に基づく回答を区別できます。文書更新後の回帰確認にも同じ質問セットを使えます。

よくある質問

ローカルLLMとRAGの違いは何ですか？

ローカルLLMは自分の端末や管理下のサーバーで文章を生成するモデルです。RAGは、質問に関係する外部文書を検索し、その本文を生成モデルへ渡す仕組みです。ローカルLLMにRAGを組み合わせると、社内文書を根拠にした回答をローカル構成で作れます。

OllamaだけでRAGを作れますか？

Ollamaは生成と埋め込みを担当できますが、文書の読み込み、分割、ベクトルの保存・検索、出典管理も必要です。Ollama公式のRAG例もChromaを組み合わせています。今回の構成ではLangChainで各処理をつなぎます。

インターネット接続なしで使えますか？

必要なモデル、Ollama本体、Pythonパッケージを事前取得し、ローカル文書・ローカル埋め込み・ローカルベクトルDBだけを使えば、実行時にネット接続へ依存しない構成にできます。切断テストと通信監視を行い、周辺アプリやバックアップ経路も別途確認してください。

WindowsとMacのどちらでも構築できますか？

OllamaはmacOS、Windows、Linux向けに提供され、Pythonの主要コードは共通です。仮想環境の有効化、Ollamaの環境変数設定、GPU利用方法はOSで異なります。まず小さなモデルと少量文書で動作を確かめてください。

日本語文書の埋め込みモデルは何を選べばよいですか？

公式に多言語対応が記載された候補としてqwen3-embeddingとembeddinggemmaがあります。ただし、日本語社内文書での優劣を一律には断定できません。自社の略語、表記揺れ、長文、規程の例外条件を含む質問で検索結果を比較してください。

ChromaとFAISSとQdrantのどれがおすすめですか？

1台で永続化まで早く試すならChroma、単一プロセスへ類似検索を組み込むならFAISS、独立サーバー化やDense・Sparse・Hybrid検索への拡張を見込むならQdrantが候補です。固定の文書件数ではなく、同時利用、更新、絞り込み、バックアップで決めます。

RAGを入れればハルシネーションはなくなりますか？

なくなりません。検索漏れ、古い文書、誤ったチャンク、生成時の読み違いは残ります。出典を表示し、資料にない場合の応答を決め、取得結果と回答を分けて評価する必要があります。

文書を更新したら自動で回答も更新されますか？

元ファイルを置き換えただけでは更新されません。変更を検知し、再抽出・再分割・再埋め込み・再登録する処理が必要です。安定したIDと文書版を持たせ、古い索引が混ざらないようにします。

ファインチューニングとRAGはどちらを先に試すべきですか？

更新される事実や社内文書を根拠に答えたい場合は、まずRAGが合います。出力形式や口調など、モデルの振る舞いを変えたい場合はファインチューニングが候補です。両者は併用できますが、目的を分けて評価してください。

結論

ローカルLLM×RAGを作るときの中心は、生成モデルではなく「どの文書を、どの埋め込みで、どう検索し、どの出典と一緒に渡したか」を追える設計です。最初はOllama、LangChain、Chromaの1台構成で、テキスト抽出できる少量のPDFから始めてください。

次に確認する順番は、取り込み、分割、埋め込み、検索、生成です。正解根拠が検索できたことを確認してから回答を評価し、モデルや索引を変えたときは同じ質問セットで再確認します。オフライン要件がある場合は、モデルを事前取得し、Ollamaのクラウド機能を無効化し、ネットワーク切断下でも一連の処理が完了するところまでを受け入れ条件にします。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

• Embeddings — Ollama公式。現行の埋め込みモデル、/api/embed、同一モデル利用、バッチ入力を確認（参照日：2026年10月4日）
• FAQ — Ollama公式。ローカル／クラウドのデータ処理、クラウド無効化、既定のローカル待受を確認（参照日：2026年10月4日）
• Embedding models — Ollama公式、2024年4月8日公開。埋め込み・検索・生成のRAG基本フローを確認。コードは現行API資料を優先（参照日：2026年10月4日）
• Build a semantic search engine with LangChain — LangChain公式。Document、PDF、分割、埋め込み、ベクトル検索の現行手順を確認（参照日：2026年10月4日）
• OllamaEmbeddings integration — LangChain公式。langchain-ollamaとOllamaEmbeddingsの現行構文を確認（参照日：2026年10月4日）
• ChatOllama integration — LangChain公式。ChatOllamaの生成呼び出しを確認（参照日：2026年10月4日）
• Chroma integration — LangChain公式。ローカル永続化と検索APIを確認（参照日：2026年10月4日）
• Qdrant integration — LangChain公式。ローカルモード、オンディスク保存、検索モードを確認（参照日：2026年10月4日）
• FAISS vector store — LangChain公式ソース。LangChain統合のsave_localと、保存データの再読込を信頼済みファイルに限定する注意を確認（参照日：2026年10月4日）
• Faiss Wiki — Meta公式。FAISSが密ベクトルの類似検索・クラスタリング用ライブラリであることを確認（参照日：2026年10月4日）
• Extract Text from a PDF — pypdf公式。pypdfがOCRではなく、PDF画像から文字を抽出しない点を確認（参照日：2026年10月4日）

このテーマの関連記事

• ▸ n8n AI Agent入門｜ノード基本編【2026年10月】
• ▸ LangGraph MCP連携3手順【2026年10月4日】
• ▸ LangGraph Studioの使い方｜可視化・デバッグ【2026年10月】
• ▸ ローカルLLMをMac miniで動かす5手順【2026年10月】
• ▸ ローカルLLMとは｜仕組み・クラウドとの違い・始め方【2026年10月】