ollama rag 構築の完全ガイド｜設計・実装・本番運用まで

Ollama RAG構築の全体像とアーキテクチャ設計

Ollama RAG構築を一文で定義するなら、「文書検索とローカルLLM推論を組み合わせた、外部APIに依存しない質問応答パイプラインの実装」となる。RAG（Retrieval-Augmented Generation）は、LLMの学習データに含まれない文書を実行時に検索してコンテキストとして与えることで回答品質を引き上げる手法だ。Ollamaをバックエンドに据えることで、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日確認）。

Ollama RAG 処理パイプライン

インデックス構築

文書ローダー PDF / MD / TXT

チャンク分割 + 埋め込み生成

ベクトルDB Qdrant / Chroma

クエリ処理

ユーザー質問 クエリ埋め込み

近傍検索 上位K件取得

Ollama LLM Qwen3 / Gemma4

回答出力 RAG応答

RAGの基礎概念についてはRAGとは何か・仕組みの基礎解説も参照されたい。パイプラインを構成する要素を整理すると以下の四層になる。

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

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

Ollamaの全体像についてはOllamaの概要・仕組み解説でより詳しく取り上げている。

Ollama RAG構築に必要なコンポーネントの選定と技術的トレードオフ

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

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

RAG用途では「長いコンテキストをロスなく処理できるか」「日本語トークナイザの質」「応答速度」の三点が主な選定基準になる。Ollamaライブラリで配布されているモデル系列の中から、RAG用途に適した代表例を以下に整理した（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	推論深度が必要なドキュメントQAに有効
gpt-oss	20B / 120B	o3-mini級推論、調整可能な推論強度	16GB〜	OpenAIオープンウェイト、Ollamaと提携配布
Llama3.2	1B / 3B	軽量、低スペック環境向け	4〜8GB	旧世代だがエッジ用途に依然有効

上表のVRAM目安はQ4量子化を適用した概算であり、実環境での計測値とは差が生じることがある。なお、Llama3.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）では、文書の前処理品質とチャンク戦略がシステム全体の精度に大きく寄与することが示されており、「チャンクの粒度」と「重複設定」が主要なチューニングパラメータとして言及されている（https://www.jstage.jst.go.jp/article/jpla/70/3/70_90/_article/-char/ja）。

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に差し替えるだけで済む。この差し替えコストの低さがLangChainを採用する実装上のメリットの一つだ。RAGの詳細な事例についてはRAGの実装事例・活用例も参照されたい。

本番構成でGPUコンテナのリソース割り当てを行う場合、NVIDIA Container Toolkitが別途必要になる点に注意されたい。

Ollama RAG構築の精度向上とチューニング・本番運用の注意点

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

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

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

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

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

本番運用でのリソース管理とセキュリティ

JAEAによるスーパーコンピュータを用いたオンプレミス生成AI基盤の構築・展開に関する技術報告（JAEA-Technology-2025-017）では、ローカル環境でのLLM基盤構築における実運用上の課題が整理されており、モデルサイズと応答速度のバランスが設計上の重要な検討事項として挙げられている（https://jopss.jaea.go.jp/pdfdata/JAEA-Technology-2025-017.pdf）。同様の判断は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非搭載のサーバで大型モデルを動かしたい場合、2026年時点ではOllama Cloudというホスト型推論サブスクリプションが選択肢になる。Free（$0）・Pro（月$20）・Max（月$100）の三プランが固定料金で提供されており、従量課金ではないため予期せぬコスト超過が発生しない設計になっている（Ollama公式pricing、2026年6月8日確認）。なお「Turbo」は旧称であり、現在の正式名称は「Ollama Cloud」だ。料金については$200といった誤記が二次情報に散見されるが、Maxプランの公式価格は月$100である。

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

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

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

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

RAGシステムのコスト比較全般については無料で使えるRAGサービス・ツールの比較も参考になる。他のRAGフレームワークとの技術比較についてはRAGフレームワーク比較でまとめている。

一次体験からの実装上の知見

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

Ollamaを活用したシステム全体の導入事例についてはクリスタルメソッドのAIソリューションブログも参照されたい。

---

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

弊社が開発するDeepAI（クリスタルメソッドのAIソリューション）では、こうしたオンプレミスLLM・RAG基盤の設計・導入支援にも対応している。

---

参考文献

• 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日確認）
• JAEA-Technology-2025-017「スーパーコンピュータを用いたオンプレミス生成AI基盤の構築と展開」日本原子力研究開発機構: https://jopss.jaea.go.jp/pdfdata/JAEA-Technology-2025-017.pdf
• 「Difyで作成した図書館サービスへの質問に回答するRAG型チャットボット」日本図書館情報学会誌 vol.70 no.3: https://www.jstage.jst.go.jp/article/jpla/70/3/70_90/_article/-char/ja
• JST J-GLOBAL「自動車産業PDFチャットボットのためのRAG技法の最適化」: https://jglobal.jst.go.jp/detail?JGLOBAL_ID=202402211663346024