blog

AIブログ

Ollamaのモデル一覧｜おすすめ・DL・削除【2026年版】

監修

河合継（クリスタルメソッド株式会社代表取締役）

AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番組でのAI解説実績を持つAI研究者として、AIの研究開発を主導している。
運営会社について｜編集方針

Ollama Models とは何か――ローカルLLM運用の核心

Ollamaを使ってローカル環境でLLMを動かす上で、最初に理解すべきなのが「モデル（models）」の概念です。どのモデルを選ぶかは、推論精度・速度・メモリ消費・ライセンスのすべてに影響します。本記事では、Ollamaライブラリで利用できる主要モデルの種類と特性、選定基準、実運用での使い分け、そしてカスタムモデルの作成・管理方法まで深く掘り下げます。Ollama全体の概要や導入手順については別記事で詳しく解説していますので、モデル選定・活用の深掘りにフォーカスしてお読みください。

Ollama Modelsの基本構造を理解する

Ollamaにおける「モデル」とは、単なるウェイトファイルではありません。Modelfileと呼ばれる設定ファイル、量子化されたGGUFウェイト、システムプロンプト、テンプレートがひとまとまりになったユニットです。この構造を理解することで、単にpullするだけでなく、自社用途に最適化したモデルを作れるようになります。なお、Ollama自体はモデルを開発・提供する主体ではなく、外部のオープンウェイトモデルをollama.com/libraryで配布・管理するローカル実行環境です。

Modelfileの役割

ModelfileはDockerfileに着想を得た設定記述ファイルです。ベースモデルの指定（FROM）、システムプロンプトの固定（SYSTEM）、推論パラメータ（PARAMETER）、プロンプトテンプレート（TEMPLATE）を一元管理します。一度Modelfileを定義すれば、ollama createコマンドで再現性のあるモデルユニットが生成でき、チーム間での共有・バージョン管理が容易になります。

GGUF量子化の仕組み

Ollamaが内部的に使用するllama.cppはGGUF形式のウェイトを扱います。量子化ビット数（Q4_K_M、Q5_K_M、Q8_0など）によって、モデルサイズ・推論速度・精度がトレードオフになります。たとえばQ4_K_Mは4bit量子化の中でも比較的精度劣化が少なく、8〜16GBのVRAM環境に最適です。Q8_0はほぼfloat16相当の精度を保ちますが、サイズが約2倍になります。

量子化タイプ	ビット数	精度への影響	推奨シナリオ
Q4_K_M	4bit（Kグループ中精度）	軽微な劣化	8〜16GB VRAM／日常利用
Q5_K_M	5bit（Kグループ中精度）	Q4よりさらに精度高	16GB VRAM／高精度優先
Q8_0	8bit	float16とほぼ同等	24GB+ VRAM／品質最重視
F16	16bit（非量子化）	劣化なし	研究・ファインチューン後評価

Ollama Libraryの主要モデル一覧と特性

公式のOllama Library（ollama.com/library）には100以上のモデルが登録されています。すべてを試すのは非現実的なので、実運用での検証結果を踏まえて用途別に整理します。

汎用テキスト生成・対話モデル

モデル名	パラメータ規模	ライセンス	特徴・強み	推奨VRAM目安
Qwen3 系（最人気級）	0.6B〜235B（dense／MoE）	Apache 2.0等	汎用・推論・多言語。30.4M+ pulls。最新世代はQwen 3.5／3.6	4GB〜（サイズによる）
gpt-oss（OpenAIオープンウェイト）	20B / 120B	要確認	調整可能な推論強度。o3-mini級とされる。Ollamaと提携配布	16GB〜（Q4で）
DeepSeek-R1	多サイズ（MoE含む）	MIT	推論特化。87.1M+ pulls の高人気モデル	サイズによる
Gemma 4（Google）	12B / 26B / 31B	Gemma Terms of Use	vision＋tools＋thinking対応の最新世代マルチモーダル	10GB〜（サイズによる）
Llama 3.2	1B / 3B	Meta Llama 3 Community	軽量・エッジデバイス向け。旧世代だがpull数は多い	4GB〜
Phi-4	14B	MIT	Microsoftの小型高性能モデル。推論・数学が得意	10GB〜

コーディング特化モデル

モデル名	パラメータ規模	強み	実運用でのユースケース
Qwen3-Coder	30B級	agenticコーディング・thinking対応の現行定番	CI/CDパイプラインでのコードレビュー補助
Qwen2.5-Coder	1.5B〜32B	多言語コーディング・FIM対応	VSCode拡張連携、インライン補完
DeepSeek-Coder-V2	16B / 236B（MoE）	コード補完・バグ検出	レガシーコード解析・ドキュメント生成
Codestral	要確認	Mistral製コーディング特化	マイナー言語の補完・変換タスク

日本語・多言語対応モデル

日本語タスクを扱う場合、モデル選定は特に重要です。実際に社内ツールや日本語テキスト処理パイプラインに複数モデルを組み込んで検証した経験から言えるのは、Qwen3シリーズ（特に数B〜30B台）が日本語の自然さとコスト効率のバランスが優秀であることです。

Qwen3（中規模サイズ・Q4_K_M）：日本語要約・分類タスクで安定したアウトプット。8〜16GB VRAMで動作
Gemma 4 12B：Googleの多言語学習データを活かした自然な日本語生成とビジョン対応
EZO-Common（Hugging Faceから変換）：日本語特化ファインチューニングモデル。Modelfile経由でOllamaに組み込み可能

ただし「日本語が動く」と「日本語で高品質な出力が出る」は別問題です。実際のタスク（要約・分類・抽出・QA）でベンチマークを取ることを強く推奨します。

Embeddingモデル

RAG（検索拡張生成）パイプライン構築では、テキスト生成モデルとは別にEmbeddingモデルが必要です。Ollamaは埋め込み専用モデルも管理できます。

nomic-embed-text：高品質・軽量。RAG用途の定番。コンテキスト長8192トークン
mxbai-embed-large：MXBAIによる英語Embeddingモデル。MTEBスコアが高い
snowflake-arctic-embed：エンタープライズ用途向けの高精度Embedding

マルチモーダルモデル

画像とテキストを同時に扱えるビジョンモデルもOllamaで管理できます。

Gemma 4（12B/26B/31B）：vision＋tools＋thinkingを統合した現行最新世代。Google製
Qwen3-VL：Qwen3系のビジョン対応バリアント
Kimi K2.6：マルチモーダル対応の新着モデル
Moondream：1.8Bの超軽量ビジョンモデル。Raspberry Pi級でも動作

モデルの取得・管理コマンドを使いこなす

Ollamaのモデル管理はCLIで完結します。基本コマンドを押さえておけば、複数モデルの切り替えも容易です。

pullする
ollama pull qwen3:14b
Libraryからウェイトをダウンロード

一覧確認
ollama list
ローカルの全モデルを表示

削除する
ollama rm modelname
ディスクから完全削除

モデル情報
ollama show qwen3:14b
Modelfile・パラメータを表示

コピーする
ollama cp base custom
カスタムモデルの雛形作成に使う

タグ指定でバージョンを固定する

モデル名の後にコロンでタグを付けることで、特定の量子化バージョンや派生を指定できます。

ollama pull qwen3:30b-a3b-q4_K_M（Qwen3 MoE 30B・Q4_K_M量子化）
ollama pull gpt-oss:20b（gpt-oss 20Bのデフォルトタグ）
ollama pull nomic-embed-text:latest（Embeddingモデル最新版）

本番環境では:latestを避け、明示的なタグで固定することを推奨します。pullし直すたびにウェイトが変わると、出力の再現性が失われるためです。社内の実運用でも、モデルのタグをInfrastructure as Codeで管理しています。

Modelfileで独自モデルを作る実践

Ollamaの強みのひとつが、Modelfileによるカスタムモデルの作成です。ベースモデルにシステムプロンプトや推論設定を焼き込んだ「専用アシスタント」を作れます。

基本的なModelfileの構造

FROM qwen3:14b
PARAMETER temperature 0.3

PARAMETER top_p 0.9

PARAMETER num_ctx 8192
SYSTEM “””

あなたは日本語に特化したテキスト要約アシスタントです。

入力されたテキストを、箇条書き3点で簡潔に要約してください。

“””

上記をModelfileとして保存し、ollama create my-summarizer -f ./Modelfileを実行するとmy-summarizerという独自モデルが作成されます。

主要パラメータの意味と実践的な設定値

パラメータ	意味	低い値の効果	高い値の効果	実運用での推奨
temperature	出力のランダム性	決定論的・一貫性高	多様・創造的	分類・抽出：0.1〜0.3、創作：0.7〜1.0
top_p	サンプリング幅	高確率トークンに絞る	幅広く選択	temperatureと組み合わせ。0.9が汎用
num_ctx	コンテキストウィンドウ長（トークン）	メモリ節約	長文処理可能	RAG用途：8192〜16384
top_k	上位K件からサンプリング	出力が絞られる	多様なトークンを検討	40〜80が一般的
repeat_penalty	繰り返し抑制	同じ表現が続きやすい	多様な表現を強制	1.1〜1.15で繰り返しを自然に抑制

Hugging FaceのGGUFモデルをOllamaに取り込む

Ollama Libraryに存在しないモデルも、GGUF形式のファイルがあればModelfileで直接参照できます。

FROM /path/to/your-model.gguf
SYSTEM “日本語専用モデルです。”

Hugging Faceから直接pullすることも可能です（ollama run hf.co/username/repo-name）。ただし対応フォーマットはGGUFのみです。PyTorchやsafetensors形式は変換が必要です。

用途別・環境別のモデル選定フレームワーク

実際の現場では「とりあえず最大サイズを使う」のが最善ではありません。以下の判断軸で選定することで、コスト・速度・品質を最適化できます。

ステップ1
ハードウェア確認
VRAM / RAM

→

ステップ2
タスク定義
対話/コード/RAG等

→

ステップ3
言語要件確認
日本語重要度

→

ステップ4
ライセンス確認
商用利用可否

→

ステップ5
複数モデルでABテスト

ハードウェア別の現実的な選択肢

環境	VRAM/RAM目安	推奨モデル	コメント
MacBook Air（M2/M3）	8GB統合メモリ	Llama 3.2 3B、Qwen3 0.6B〜数B	軽量モデルならサクサク動作。16GB版なら7B〜14B可
MacBook Pro / Mac Studio	32〜64GB統合メモリ	Qwen3 14B〜30B、gpt-oss:20b（Q4）	Appleシリコンの統合メモリはVRAMと共有。大型モデルに強い
Linux PC（RTX 3090/4090）	24GB VRAM	Qwen3 14B〜30B、Qwen3-Coder 30B	Q4量子化で大型MoEも試行可。推論速度は最速クラス
Linux サーバー（A100×2）	80GB×2 VRAM	gpt-oss:120b、DeepSeek-R1大型版	複数GPU利用はGPULayersで分散可能
CPU only（16GB RAM）	VRAM不要	Qwen3 0.6B〜数B、Phi-4 mini系	速度は遅いが動作はする。軽量タスク専用と割り切る

ライセンスの注意点

社内ツールやSaaS組み込みでの商用利用を検討する場合、ライセンスの確認は必須です。主要モデルのライセンス形態は以下の通りです。

Apache 2.0（Mistral 7B、Qwen3系多数等）：商用利用・改変・再配布ともに自由。最も制約が少ない
Meta Llama Community License（Llama 3.x系）：月間アクティブユーザー7億人超のサービスは別途ライセンス申請が必要。それ未満は商用利用可
MIT（Phi-4等）：Apache 2.0同様、商用利用可。帰属表示が必要
Gemma Terms of Use（Gemma 4等）：商用利用可だが、競合するAIサービスへの組み込みや危険コンテンツ生成に制限あり。詳細はGoogle公式を確認

Ollamaの料金体系と商用利用のコスト比較については別記事で詳しく解説しています。ライセンスコストの観点も含めて参照してください。

複数モデルの並列管理と切り替え戦略

実務では「1モデルで全タスク」は非効率です。タスクごとに最適モデルを切り替えるオーケストレーション設計が、品質とコストの両立につながります。

APIを使ったモデル切り替え

OllamaはOpenAI互換APIエンドポイント（http://localhost:11434/v1）を提供しています。modelパラメータを変えるだけで実行モデルを切り替えられます。LangChainやLlamaIndexとの組み合わせで、タスクに応じてモデルを動的に選択するルーターを構築できます。

並列ロードとメモリ管理

Ollamaはデフォルトで最後にロードしたモデルをメモリにキャッシュします（OLLAMA_KEEP_ALIVE環境変数で制御、デフォルト5分）。複数モデルを頻繁に切り替える場合は以下を検討してください。

OLLAMA_MAX_LOADED_MODELS：同時にメモリにロードするモデル数の上限（デフォルト1）
OLLAMA_KEEP_ALIVE=0：推論後すぐにモデルをアンロードしてVRAMを解放
用途が異なる複数モデルは、別々のOllamaインスタンスをDockerで起動する構成も有効

プロダクション環境でのモデル管理パターン

弊社の実運用では、以下のような役割分担でモデルを使い分けています（具体的な取引先名・社内システム名は伏せます）。

高速分類・フィルタリング：Qwen3 数B（低レイテンシ優先）
日本語テキスト要約・構造化抽出：Qwen3 14B Q4_K_M
コードレビュー補助：Qwen3-Coder 30B Q4_K_M
RAGのEmbedding：nomic-embed-text（軽量・高速）
品質評価・難しいタスク：gpt-oss:20b または DeepSeek-R1 大型版（高品質優先）

この構成により、全タスクを大型モデルで処理するのと比較して推論コストを大幅に削減しつつ、品質が重要なタスクでは精度を確保できています。

Ollamaを他のローカルLLMツールと比較した場合の優位性については、Ollama比較記事で詳しく解説しています。

モデル選定でよくあるミスと対策

「パラメータ数が大きければ良い」という誤解

大型モデルが常に小型モデルより優れているわけではありません。特定のタスク（短文分類、キーワード抽出など）では、小型モデルで十分な精度が出ることが多く、速度・コストの面で明確に有利です。ベンチマークはタスク固有で取ることが鉄則です。

コンテキスト長の見落とし

モデルが対応するコンテキスト長と、Ollamaのnum_ctx設定は別物です。num_ctxを増やすとVRAM消費が増加します。長文RAGで「途中から回答精度が落ちる」場合、num_ctx不足が原因のことが多いです。モデルのネイティブコンテキスト長を確認し、ollama showで実際の設定値を検証してください。

量子化による劣化の過小評価

Q4量子化で「精度劣化が軽微」とされますが、数値推論・論理タスクでは劣化が顕在化しやすいです。数学・コードのテストケースでQ4とQ8を比較し、許容範囲かどうかを事前に確認することを推奨します。

まとめ

Ollama Modelsを使いこなすポイントは、「モデルは選ぶもの、作るもの」という認識の転換にあります。Ollama Libraryには100以上のモデルが揃っていますが、そのまま使うだけでなく、Modelfileでシステムプロンプト・パラメータを焼き込んだカスタムモデルを作ることで、初めて本格的な実務活用が実現します。

量子化（Q4_K_M / Q5_K_M / Q8_0）とVRAMのトレードオフを理解してモデルを選ぶ
日本語タスクにはQwen3シリーズが現時点でバランスが良い（最新はQwen 3.5／3.6）
Embeddingモデル（nomic-embed-text等）はRAG構築に必須
Modelfileで用途別カスタムモデルを作り、タグで固定管理する
タスクに応じて軽量モデルと大型モデルを使い分けるオーケストレーション設計が実務の鍵
ライセンスはApache 2.0が最も自由。商用利用時はモデルごとに必ず確認する

Ollamaの全体像や初期設定についてはOllamaとは何かおよびOllama導入ガイドを参照してください。モデルを動かす環境を整えた上で、本記事のモデル選定フレームワークを活用して最適な構成を見つけてください。

参考文献

Study about AI

AIについて学ぶ

Meta インドデータセンター AIインフラ——Reliance 168MW契約の深層と日本企業の実務対応

監修河合継（クリスタルメソッド株式会社代表取締役） AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番...
ワーナー Sureel AI 音楽著作権——買収の意味と日本企業への示唆

監修河合継（クリスタルメソッド株式会社代表取締役） AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番...
Vector Lakebase ベクターDB RAG——Zillizが示す統合AIデータ基盤の論点

監修河合継（クリスタルメソッド株式会社代表取締役） AI・ディープラーニングに関する特許16件の発明者。過去、国立がん研究センターとの共同研究や、テレビ番...