ollama ragをローカルで構築する実装ガイド｜設計から運用まで

Ollama RAGとは、文書検索とローカルLLM推論を組み合わせた、外部APIに依存しない質問応答パイプラインの実装を指す。RAG（Retrieval-Augmented Generation）は、LLMの学習データに含まれない文書を実行時に検索してコンテキストとして与えることで回答精度を引き上げる手法だ。OllamaをLLMバックエンドに据えることで、OpenAI APIへの依存を排除し、機密文書を外部サーバへ一切送出せずに処理できる構成を実現できる。

前提として確認しておきたいのは、Ollamaはモデルを自作・提供するツールではなく、Qwen3・DeepSeek・Gemma 4などのオープンウェイトモデルをローカルで動かすランナーであるという点だ。Ollamaライブラリ（ollama.com/library）から必要なモデルをollama pullコマンド一つで取得し、OpenAI互換のREST APIとしてローカルポート（デフォルト:11434）に公開する。この互換性がLangChainやLlamaIndexとのインテグレーションを容易にしており、既存のRAGコードベースをほぼそのまま流用できる（Ollama公式GitHub README、2026年6月8日確認）。

RAGの基礎的な仕組みについてはRAGとは何か・仕組みの基礎解説を、Ollama自体の概要についてはOllamaの概要・仕組み解説をそれぞれ参照されたい。

ollama ragのアーキテクチャ：パイプラインの全体像

実装に入る前に、処理の全体像を整理しておく。パイプラインは大きく「インデックス構築フロー」と「クエリ処理フロー」の二つに分かれる。

構成要素は四層に整理できる。

• 文書ローダー：PDF・Markdown・HTMLなど各種形式を読み込みテキスト化する
• 埋め込みモデル：テキストチャンクを数値ベクトルに変換する（検索精度の要）
• ベクトルDB：ベクトルを格納し近傍検索を高速に行う
• 生成LLM：検索結果をコンテキストとして受け取り自然言語で回答を生成する

Ollamaはこのうち「埋め込みモデル」と「生成LLM」の両方をローカルで賄える点が重要だ。nomic-embed-textやmxbai-embed-largeといった埋め込みモデルもOllamaライブラリから取得して利用できる。外部APIに依存するコンポーネントをゼロにできるかどうかは、データガバナンス要件を満たせるかどうかに直結するため、設計初期に明示的に確認すべきポイントだ。

ollama ragのコンポーネント選定と技術的トレードオフ

実装に先立ち、各レイヤーでの選択肢と技術的トレードオフを整理しておく。選定を誤ると後から大規模なリファクタリングが必要になるため、この段階の判断が最も費用対効果に直結する。

生成LLMの選定（2026年6月時点）

RAG用途では「長いコンテキストをロスなく処理できるか」「日本語トークナイザの質」「応答速度」の三点が主な選定基準になる。Ollamaライブラリで配布されているモデル系列の代表例を以下に整理した（Ollama公式ライブラリ・GitHub README、2026年6月8日確認）。

モデル系列	代表パラメータ規模	RAG向き特性	量子化後VRAM目安	備考
Qwen3 / Qwen3.5 / Qwen3.6	8B〜35B	日本語・多言語対応、thinking mode対応、pulls数最多級（30.4M+）	8〜24GB	現時点でRAGの第一候補
Gemma 4	12B / 26B / 31B	vision＋tools＋thinking、長文コンテキスト対応	16〜24GB	2026年最新世代、マルチモーダル対応
DeepSeek-R1	7B〜70B	推論特化、CoTによる高精度回答（87.1M pulls）	8〜48GB	2026年6月時点では推論深度が必要なドキュメントQAに有効。現行の旗艦はV4系
gpt-oss（OpenAIオープンウェイト）	20B / 120B	o3-mini級推論、調整可能な推論強度	16GB〜	Ollamaと提携配布。Ollama製ではない
Llama 3.2	1B / 3B	軽量・低スペック環境向け	4〜8GB	旧世代だがエッジ用途に依然有効

VRAM目安はQ4量子化を適用した概算であり、実環境での計測値とは差が生じることがある。Llama 3.1はpull数こそ115.6M超と多いが現時点では旧世代に分類される（Ollama公式ライブラリ、2026年6月8日確認）。モデル系列の詳細比較についてはOllamaと他ツールの比較も参照のこと。

ベクトルDBの選定

ローカル完結を前提にする場合、代表的な選択肢はQdrant・Chroma・FAISSの三つだ。

• Qdrant：Rustで書かれた高性能ベクトルDBで、Dockerコンテナ一つで起動できる。スカラフィルタとのハイブリッド検索をネイティブサポートしており、本番規模での安定性と将来的な水平スケールアウトの両方を見据えた選択として適している。永続化もビルトインで対応する。
• Chroma：Pythonネイティブで最も導入が手軽。プロトタイプ段階ではDockerすら不要なインメモリモードが使えるため、検証サイクルを短縮したい場合に向く。大規模本番環境への適用にはスケールアウトの制約を事前に確認すべきだ。
• FAISS：Metaが開発したライブラリで検索速度は最速クラスだが、永続化とフィルタリングは別途実装が必要になる。シンプルなインメモリ用途に限れば選択肢になる。

本番運用を見据えるならQdrant、プロトタイピング優先ならChromaという選択が、現場では多いパターンだ。

オーケストレーションフレームワーク

LangChainはOllama向けのlangchain-ollamaパッケージを提供しており、OpenAI互換インタフェースでLLMや埋め込みモデルをそのまま呼び出せる。LlamaIndexも同様にOllamaに対応しており、RAGのインデックス管理やクエリエンジンが充実している。選定の判断基準は主にチームの既存技術スタックに合わせることが現実的だ。LangChainはチェーンの柔軟な組み合わせに強く、LlamaIndexはドキュメント管理とインデックス戦略の抽象化に強みがある。RAGの実装パターン全般についてはRAGの実装方法・ハウツー解説も参考になる。

ollama ragのステップ別実装手順

Step 1: Ollamaのセットアップとモデル取得

Ollama本体のインストールは公式サイト（ollama.com）からmacOS・Linux・Windows各インストーラを取得する。Linuxであれば以下のワンライナーで完了する。

curl -fsSL https://ollama.com/install.sh | sh

起動確認後、RAGで使う生成LLMと埋め込みモデルをそれぞれpullする。

# 生成LLM（Qwen3の8Bクラスを例示）
ollama pull qwen3:8b

# 埋め込みモデル
ollama pull nomic-embed-text

サービス起動確認はcurl http://localhost:11434でレスポンスが返ることで行う。Apple SiliconではOllamaがMLXエンジンを利用でき、Unified Memoryを活かした効率的な推論が可能だ（Ollama 0.30系、2026年6月時点）。セットアップの詳細手順はOllamaのセットアップ・インストール手順にまとめている。

Step 2: 文書のチャンク分割と埋め込み生成

チャンクサイズは検索精度とコンテキスト長のバランスを取る重要なパラメータだ。J-STAGEに掲載された図書館サービス向けRAGシステムの研究（日本図書館情報学会誌 vol.70 no.3）では、文書の前処理品質とチャンク戦略がシステム全体の精度に大きく寄与することが示されており、「チャンクの粒度」と「重複設定」が主要なチューニングパラメータとして言及されている（J-STAGE, 日本図書館情報学会誌 vol.70 no.3）。

LangChainを用いた実装例を示す。一般に500〜1000トークン程度が出発点として妥当な範囲とされているが、文書の構造や用途に応じた検証が不可欠だ。

from langchain_community.document_loaders import DirectoryLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_ollama import OllamaEmbeddings
from langchain_community.vectorstores import Chroma

# 文書読み込み（Markdownを例示）
loader = DirectoryLoader("./docs", glob="**/*.md")
docs = loader.load()

# チャンク分割
splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=100
)
chunks = splitter.split_documents(docs)

# 埋め込み生成とChromaへの格納
embeddings = OllamaEmbeddings(model="nomic-embed-text")
vectorstore = Chroma.from_documents(
    chunks,
    embeddings,
    persist_directory="./chroma_db"
)

chunk_overlap=100を設定することで、チャンク境界で文脈が分断される問題を軽減できる。日本語テキストでは形態素を考慮した分割も有効で、MeCabやjanomeとの組み合わせも選択肢になる。埋め込みモデルの品質はこの段階で検索精度全体を左右するため、後述する多言語対応モデルへの切り替えも視野に入れておくべきだ。

Step 3: RAGチェーンの組み立てとプロンプト設計

生成LLMとリトリーバーを結合するRAGチェーンを実装する。プロンプトテンプレートには「コンテキスト外の情報を無断で生成しない（ハルシネーション抑止）」という指示を明示的に含めることが重要だ。

from langchain_ollama import ChatOllama
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate

llm = ChatOllama(model="qwen3:8b", temperature=0)

template = """以下のコンテキストのみを参照して質問に回答してください。
コンテキストに情報がない場合は「提供された文書には該当情報がありません」と答え、
推測や補完を行わないでください。

コンテキスト:
{context}

質問: {question}
回答:"""

prompt = PromptTemplate(
    template=template,
    input_variables=["context", "question"]
)

qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectorstore.as_retriever(search_kwargs={"k": 4}),
    chain_type_kwargs={"prompt": prompt}
)

result = qa_chain.invoke({"query": "社内の休暇申請手続きを教えてください"})
print(result["result"])

temperature=0を設定することで回答の再現性を高め、ハルシネーションのリスクを一定程度抑制できる。ただし完全な防止はできないため、プロンプトエンジニアリングとの多層的な組み合わせが必要になる。search_kwargs={"k": 4}は取得するチャンク数で、コンテキスト長と応答速度のバランスで調整する。

Step 4: Qdrantへの切り替えと本番構成

プロトタイプ検証後に本番スケールへ移行する場合はQdrantへ切り替える。Docker Composeを用いたローカル起動は以下のとおりだ。

version: '3.8'
services:
  qdrant:
    image: qdrant/qdrant:latest
    ports:
      - "6333:6333"
    volumes:
      - ./qdrant_storage:/qdrant/storage

  ollama:
    image: ollama/ollama:latest
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

Pythonコード側でのベクトルDB切り替えは、LangChainのインタフェースが共通化されているためChromaをQdrantVectorStoreに差し替えるだけで済む。なお、GPUコンテナのリソース割り当てを行う場合はNVIDIA Container Toolkitが別途必要になる点に注意されたい。RAGの具体的な活用事例についてはRAGの実装事例・活用例も参照されたい。

ollama ragの精度チューニングと本番運用の注意点

検索精度を左右するチューニングポイント

初期実装を動かした後の最大の課題は検索精度の安定化だ。以下の三点が実装上の主要な調整箇所になる。

埋め込みモデルの品質：生成LLMと同等以上に検索精度を左右する要素だ。英語特化モデルを日本語文書に適用すると類似度計算が不安定になる。intfloat/multilingual-e5-large等の多言語対応埋め込みモデルをOllamaライブラリまたはHugging Face経由で使用することを検討したい。JST J-GLOBALに登録された自動車産業PDFチャットボット向けRAG技法の最適化に関する研究では、埋め込みモデルの選定がドメイン特化型RAGの精度に直接影響することが示唆されている（JST J-GLOBAL「自動車産業PDFチャットボットのためのRAG技法の最適化」）。

ハイブリッド検索：ベクトル検索（意味的類似性）とキーワード検索（BM25等の全文検索）を組み合わせることで、専門用語・固有名詞・型番など正確なマッチングが必要な検索漏れを減らせる。Qdrantはこのハイブリッド検索をネイティブサポートしており、本番構成でQdrantを選ぶ理由の一つになる。

リランキング：検索上位N件を取得後、クロスエンコーダモデルで再スコアリングして最終的なコンテキストを絞り込む手法だ。精度は向上するが推論レイテンシが増加するトレードオフがある。リアルタイム応答が要件の場合はレイテンシ上限を事前に計測したうえで導入を判断すべきだ。

リソース管理とセキュリティ

日本原子力研究開発機構（JAEA）によるスーパーコンピュータを用いたオンプレミス生成AI基盤の構築・展開に関する技術報告（JAEA-Technology-2025-017）では、ローカル環境でのLLM基盤構築における実運用上の課題が整理されており、モデルサイズと応答速度のバランスが設計上の重要な検討事項として挙げられている（JAEA-Technology-2025-017）。同様の判断はOllama RAG構築においても避けられない。

Ollamaはモデルをメモリ上にロードした状態を維持するため、複数モデルを同時稼働させるとVRAM消費が積み上がる。環境変数OLLAMA_KEEP_ALIVEを調整することで、アイドル時のモデルアンロードを制御できる。デフォルトは5分で、長時間バッチ処理を走らせる場合は延長を検討するとよい。GPUが搭載されていない環境ではCPU推論にフォールバックするが、8Bクラスのモデルでも実用的な応答速度を得るには相応のCPUコア数と処理時間を見込む必要がある。

セキュリティ面では、Ollamaはデフォルトで127.0.0.1:11434にバインドする。ネットワーク越しに公開する場合はOLLAMA_HOST環境変数でバインドアドレスを明示的に設定し、リバースプロキシ（Nginx等）とAPI認証を組み合わせて保護することが必要だ。社内文書をRAGのデータソースにする場合、ベクトルDBへのアクセス制御も忘れずに実装すべきポイントだ。

Ollama Cloudという選択肢

GPU非搭載のサーバで大型モデルを動かしたい場合、Ollama Cloudというホスト型推論サブスクリプションが選択肢になる。Free（$0）・Pro（月$20）・Max（月$100）の三プランが固定料金で提供されており、従量課金ではないため予期せぬコスト超過が発生しない設計になっている（Ollama公式pricing、2026年6月8日確認）。なお「Turbo」は旧称であり、現在の正式名称は「Ollama Cloud」だ。一部の二次情報にMaxプランを「$200」と誤記しているものが散見されるが、公式価格は月$100である。

ただし、Ollama Cloudを利用する場合は社外サーバへのデータ送出が発生する。機密文書や個人情報を含むデータソースを扱うシステムでは、ローカル完結構成が引き続き適切な選択だ。料金体系の詳細はOllamaの料金・プラン比較を参照されたい。

Ollama RAG構築の限界と現実的なデメリット

実装上の限界についても明記しておく。

• 初期構築コスト：Azure AI SearchなどクラウドマネージドのRAGサービスと比較すると、インフラ設計・チューニング・監視の実装コストが高い。チームのインフラ運用能力を事前に評価すべきだ。
• モデル更新管理：Ollamaライブラリのモデル系列は更新が速く（2026年6月時点でQwen3.6が約6日前リリースという状況）、定期的なollama pullによる更新管理が運用負担になる。バージョン固定の方針と更新頻度をチームで決めておく必要がある。
• ハルシネーション：RAGによってハルシネーションは低減されるが完全に防止はできない。検索スコアのしきい値設定・プロンプトエンジニアリング・回答後の検証ステップによる多層的な対策が必要だ。
• スケールアウトの複雑性：単一サーバ構成から水平スケールアウトへの移行には、ベクトルDBのクラスタ化・ロードバランサの追加など追加実装が伴う。初期設計時にスケール要件を確認しておくことが重要だ。

コスト面でのオプション比較については無料で使えるRAGサービス・ツールの比較、他のRAGフレームワークとの技術比較についてはRAGフレームワーク比較をそれぞれ参照されたい。

モデルサイズ選定の実務上の判断軸

弊社が開発するDeepAIは、実在の人物の容姿・表情・声・振る舞いをデジタル空間で再現するバーチャルヒューマン／AIアバターソリューションであり、対話AIとして接客・研修・広報などの用途に活用されている。オンプレミスLLM基盤の設計・運用において共通して言えることは、推論精度とリソース消費のバランスがモデルサイズの選定段階で大半が決まるという点だ。8Bクラスで精度が不十分と判明してから32Bクラスに切り替えると、VRAMとレイテンシの再設計が必要になる。PoC段階から複数パラメータ規模を計測しておくことが、後工程のコストを抑えるうえで現実的な選択だ。

---

Ollama RAG構築は、ローカルでの完全制御とデータプライバシーの確保を同時に実現できる構成の一つだ。初期の構築コストこそかかるものの、社内文書の検索性能を高め続けるための改善サイクルを外部APIの制約なく回せることは、長期的な技術的アドバンテージになりうる。本記事のコードサンプルと選定基準を起点に、自社のユースケースと要件に合わせて調整を進めてほしい。

弊社が開発するDeepAI（クリスタルメソッドのAIソリューション）では、バーチャルヒューマン・AIアバターを活用した対話システムの設計・開発に取り組んでいる。オンプレミスLLM基盤との連携を含めた構成について関心がある方は、お問い合わせいただきたい。

---

参考文献

• Ollama公式pricing: https://ollama.com/pricing（2026年6月8日確認）
• Ollama公式library: https://ollama.com/library?sort=newest（2026年6月8日確認）
• Ollama GitHub（README）: https://github.com/ollama/ollama（2026年6月8日確認）
• Ollama公式blog: https://ollama.com/blog（2026年6月8日確認）
• 「スーパーコンピュータを用いたオンプレミス生成AI基盤の構築と展開」JAEA-Technology-2025-017, 日本原子力研究開発機構: https://jopss.jaea.go.jp/search/servlet/search?5087020&language=1
• 「Difyで作成した図書館サービスへの質問に回答するRAG型チャットボット」日本図書館情報学会誌 vol.70 no.3, J-STAGE: https://www.jstage.jst.go.jp/article/jpla/70/3/70_90/_article/-char/ja
• 「自動車産業PDFチャットボットのためのRAG技法の最適化」JST J-GLOBAL: https://jglobal.jst.go.jp/detail?JGLOBAL_ID=202402211663346024
• LangChain v1 × Ollama ローカルRAG構築ガイド, NTTデータ技術ブログ（Zenn）: https://zenn.dev/nttdata_tech/articles/2b80f968856c36
• Python × ChromaDB × OllamaでRAGを実現, swgoh-chiptips.jp: https://swgoh-chiptips.jp/it/2026/01/15/python-chromadb-ollama-ai-rag/