ollama modelfileの書き方｜構文・パラメータ設定・カスタムモデル作成手順

Ollama Modelfileとは――カスタムモデルの設計図

Modelfileは、Ollamaでカスタムモデルを定義するための設定記述ファイルだ。ベースモデル・推論パラメータ・システムメッセージ・プロンプトテンプレートを1つのファイルにまとめ、ollama createで「名前の付いた再利用可能なモデル」としてビルドする。Dockerfileがイメージの設計図であるのと同じ関係だと考えるとわかりやすい。

Modelfileを使う利点は、設定が実行時オプションではなくモデル側に焼き込まれる点にある。ollama runのたびにシステムプロンプトや温度を指定し直す必要がなくなり、チームや本番環境で同じ挙動を再現できる。

本記事はOllama公式ドキュメント（Modelfile Reference）の仕様を一次ソースとして、全インストラクションの構文・全パラメータの既定値・ビルド手順を整理する（2026-07-19確認）。Ollama自体の導入やモデル選定についてはOllama導入ガイドとOllamaモデル選定ガイドを参照してほしい。

Modelfileの基本フォーマットとインストラクション一覧

Modelfileの書式は極めて単純で、1行につき「命令（INSTRUCTION）＋引数」を書く。#で始まる行はコメントとして扱われる。

# comment
INSTRUCTION arguments

命令名は慣例として大文字で書くが、公式ドキュメントの表記に合わせておくのが無難だ。使用できるインストラクションは次の8種類である。

インストラクション	説明
FROM（必須）	使用するベースモデルを定義する
PARAMETER	Ollamaがモデルを実行する際のパラメータを設定する
TEMPLATE	モデルに送られる完全なプロンプトテンプレート
SYSTEM	テンプレート内で設定されるシステムメッセージを指定する
ADAPTER	適用する(Q)LoRAアダプタを定義する
LICENSE	法的ライセンスを指定する
MESSAGE	メッセージ履歴を指定する
REQUIRES	そのモデルが必要とするOllamaの最小バージョンを指定する

必須なのはFROMだけで、他はすべて任意だ。最小構成はFROM1行でも成立する。

【最小構成】Modelfileを書いて ollama create でビルドする手順

公式ドキュメントに掲載されている基本例が、そのまま最小構成の雛形になる。

FROM llama3.2

# sets the temperature to 1 [higher is more creative, lower is more coherent]
PARAMETER temperature 1

# sets the context window size to 4096, this controls how many tokens the LLM can use as context to generate the next token
PARAMETER num_ctx 4096

# sets a custom system message to specify the behavior of the chat assistant
SYSTEM You are Mario from super mario bros, acting as an assistant.

この内容をModelfileという名前で保存し、次の2コマンドでビルドと実行を行う。

ollama create choose-a-model-name -f ./Modelfile
ollama run choose-a-model-name

-fにはModelfileのパスを渡す。ファイル名はModelfileでなくても構わないが、慣例に従っておくとプロジェクト内で見つけやすい。

既存モデルがどんなModelfileでできているかは、次のコマンドで確認できる。自作する前にまず既存モデルの定義を読むのが遠回りに見えて最短だ。特にTEMPLATEとstopはモデル固有で、ゼロから書くとまず動かない。

ollama show --modelfile llama3.2

FROMの3つの書き方――既存モデル・Safetensors・GGUFファイル

FROMはベースとなる重みを指定する必須命令で、書式はFROM <model name>:<tag>である。指定方法は3通りある。

1. 既存モデルから作る

FROM llama3.2

Ollamaライブラリで配布されているモデルを土台にする、最も一般的な方法だ。

2. Safetensorsモデルから作る

FROM <model directory>

指定するディレクトリには、対応アーキテクチャのSafetensors重みが含まれている必要がある。公式が現在サポートしているアーキテクチャは以下のとおり。

• Llama（Llama 2、Llama 3、Llama 3.1、Llama 3.2を含む）
• Mistral（Mistral 1、Mistral 2、Mixtralを含む）
• Gemma（Gemma 1、Gemma 2を含む）
• Phi3

3. GGUFファイルから作る

FROM ./ollama-model.gguf

Hugging Face等から入手したGGUFファイルを取り込む場合はこの形式になる。パスは絶対パス、またはModelfileからの相対パスで指定する。ビルドが「ファイルが見つからない」で失敗するケースの大半は、このパス基準の取り違えだ。

PARAMETER一覧と既定値――どの値にすべきかの判断基準

PARAMETERの書式はPARAMETER <parameter> <parametervalue>である。公式ドキュメントに定義されているパラメータと既定値は次のとおり。

パラメータ	説明	型	既定値
num_ctx	次のトークン生成に使うコンテキストウィンドウのサイズ	int	2048
repeat_last_n	繰り返し防止のためにどこまで遡るか（0=無効、-1=num_ctx）	int	64
repeat_penalty	繰り返しへのペナルティの強さ。高い値（例1.5）ほど強く罰し、低い値（例0.9）ほど寛容	float	1.1
temperature	モデルの温度。上げるほど創造的な回答になる	float	0.8
seed	生成に使う乱数シード。固定すると同じプロンプトで同じ出力になる	int	0
stop	ストップシーケンス。遭遇すると生成を止めて返す。複数指定は複数行書く	string	―
num_predict	生成時に予測する最大トークン数（-1=無限生成）	int	-1
draft_num_predict	ドラフトモデル利用時に1ステップで予測する投機的ドラフトトークン数の上限（0で無効）	int	別個のドラフトモデルは4
top_k	無意味な生成の確率を下げる。高い値（例100）ほど多様、低い値（例10）ほど保守的	int	40
top_p	top-kと併用。高い値（例0.95）ほど多様、低い値（例0.5）ほど焦点が絞られる	float	0.9
min_p	top_pの代替。最有力トークンの確率に対する採用最小確率	float	0.0

設定例は次のように書く。

PARAMETER num_ctx 4096
PARAMETER temperature 0.7
PARAMETER top_k 40
PARAMETER top_p 0.9
PARAMETER repeat_penalty 1.1
PARAMETER seed 42

SYSTEMとTEMPLATEで挙動を固定する――Goテンプレート変数とstopの役割

SYSTEMはテンプレート内で使われるシステムメッセージを指定する。複数行を書く場合は三重引用符で囲む。

SYSTEM """<system message>"""

TEMPLATEはモデルに渡す完全なプロンプトテンプレートで、Goテンプレート構文を使う。システムメッセージ・ユーザーメッセージ・モデルの応答を組み立てる部分であり、構文はモデル固有である点に注意したい。使える変数は3つ。

変数	説明
{{ .System }}	独自の振る舞いを指定するシステムメッセージ
{{ .Prompt }}	ユーザーのプロンプトメッセージ
{{ .Response }}	モデルからの応答。応答生成時、この変数より後ろのテキストは省略される

公式に掲載されているChatML形式のテンプレート例は次のとおり。

TEMPLATE """{{ if .System }}<|im_start|>system
{{ .System }}<|im_end|>
{{ end }}{{ if .Prompt }}<|im_start|>user
{{ .Prompt }}<|im_end|>
{{ end }}<|im_start|>assistant
"""

そしてllama3.2系では、テンプレートと対になる形でstopが複数設定される。ollama show --modelfile llama3.2の出力から抜粋する。

TEMPLATE """{{ if .System }}<|start_header_id|>system<|end_header_id|>
{{ .System }}<|eot_id|>{{ end }}{{ if .Prompt }}<|start_header_id|>user<|end_header_id|>
{{ .Prompt }}<|eot_id|>{{ end }}<|start_header_id|>assistant<|end_header_id|>
{{ .Response }}<|eot_id|>"""
PARAMETER stop "<|start_header_id|>"
PARAMETER stop "<|end_header_id|>"
PARAMETER stop "<|eot_id|>"
PARAMETER stop "<|reserved_special_token"

TEMPLATEを差し替えるなら、stopもそのモデルの特殊トークンに合わせて設定し直す必要がある。テンプレートだけ他モデルからコピーしてstopを放置すると、モデルが停止トークンを出しても生成が止まらず、応答の後ろにユーザーの発話やシステム文が続いて出力される、という壊れ方をする。

ADAPTER・MESSAGE・LICENSE・REQUIRESの使いどころ

残る4命令は使用頻度こそ低いが、役割は明確だ。

• ADAPTER：ベースモデルに適用するファインチューン済みLoRAアダプタを指定する。値は絶対パス、またはModelfileからの相対パス。ベースモデルはFROMで指定しておく必要がある
• MESSAGE：メッセージ履歴を指定する。あらかじめ数往復の会話例を焼き込み、応答スタイルを例示したい場合に使う
• LICENSE：配布時の法的ライセンスを明示する
• REQUIRES：そのモデルが必要とするOllamaの最小バージョンを指定する。新しい機能に依存するModelfileを配布する際、古いOllamaで壊れるのを防げる

設定値を決めるときの実務的な考え方

パラメータは「とりあえず全部書く」ものではない。既定値から動かす理由が説明できるものだけを書くのが、後から挙動を追える設定になる。判断の軸は次のように整理できる。

• num_ctxはコストと直結する：既定は2048と小さく、長い文書を扱うなら拡張が要る。ただしコンテキストウィンドウの拡大はメモリ消費と処理時間に効くため、扱う入力長の実測に合わせて決める。「大きいほど良い」ではない
• 出力の揺れを抑えたいならtemperatureを下げる：既定0.8は会話向けの設定で、分類・抽出・定型フォーマット出力のように再現性が要る用途では下げる方向に振る。seedを固定すれば同じプロンプトに対する出力を再現できるため、評価・デバッグ時に有効
• top_k／top_p／min_pは同時に強くいじらない：いずれも候補トークンの絞り込みに効くため、複数を同時に変更すると原因の切り分けができなくなる。まず1つだけ動かす
• 繰り返しはrepeat_penaltyだけの問題とは限らない：既定1.1から上げれば繰り返しは減るが、上げ過ぎると自然な語の再出現まで罰して不自然な言い回しになる。repeat_last_n（既定64）で参照範囲も変わるため、両者をセットで見る
• num_predictの既定は-1＝無限生成：APIから叩く用途では、停止条件をstopとあわせて設計しておかないと、想定外に長い応答でタイムアウトやコスト超過を招く

なお、Modelfileはテキストファイルなのでバージョン管理に載せられる。パラメータをコマンドの実行時オプションではなくModelfileに書いておく最大の利点は、「なぜこの値なのか」をコメントとして残せることだ。#コメントを併記しておけば、半年後に設定を見直すときの根拠になる。

ollama create でよくあるエラーと対処

• GGUFやSafetensorsが見つからない：FROMのパスは絶対パスか「Modelfileからの相対パス」。コマンドを実行したカレントディレクトリ基準ではない点を確認する
• Safetensorsの取り込みが通らない：対応アーキテクチャはLlama系・Mistral系・Gemma系・Phi3に限られる。範囲外のアーキテクチャはGGUFに変換してからFROM ./model.ggufで取り込む
• 応答が止まらない／余計な発話が続く：TEMPLATEを差し替えたのにstopが元のままのケースを疑う。ollama show --modelfileで元モデルのstop設定を確認して揃える
• SYSTEMが効いていないように見える：TEMPLATEを自前で書いた場合、{{ if .System }}...{{ .System }}...{{ end }}のブロックが抜けていればシステムメッセージはプロンプトに差し込まれない。テンプレート側の変数を確認する
• 長い入力で出力が途切れる：num_ctxが既定2048のままだと入力と出力の合計が窓に収まらない。入力長の実測に合わせて拡張する

ollama show --modelfile で既存モデルの定義を読む――自作の最短ルート

Modelfileをゼロから書こうとして最初に詰まるのがTEMPLATEとstopだ。これらはモデルごとに使う特殊トークンが違うため、正解を推測で書くことはできない。確実なのは、動いているモデルの定義をそのまま読むことだ。

ollama show --modelfile llama3.2

出力は、そのモデルを構成しているModelfileそのものである。読むときの着眼点は3つ。

• 先頭のコメント行：# Modelfile generated by "ollama show" に続き、# To build a new Modelfile based on this one, replace the FROM line with: # FROM llama3.2:latest と書かれている。出力されたFROMはblobの実体パスを指しているため、派生モデルを作るときはこの行をモデル名に書き換えるのが公式の指示だ
• TEMPLATEで使われている特殊トークン：llama3.2系なら<|start_header_id|>や<|eot_id|>、ChatML系のモデルなら<|im_start|>といった具合に系統が分かれる。ここを他モデルからコピーすると壊れる
• PARAMETER stopの並び：TEMPLATEで使われている特殊トークンと対応している。TEMPLATEを触るならstopも必ず対で見る

つまり自作の実務的な手順は「ゼロから書く」ではなく、「近いモデルの定義を出力し、FROM行をモデル名に置き換え、SYSTEMとPARAMETERだけ自分の用途に合わせる」になる。TEMPLATEとstopは、明確な理由がない限り触らないのが安全だ。

用途別・そのまま使えるModelfile 3例

公式ドキュメントの例は「Marioとして振る舞うアシスタント」1つだけで、業務用途にそのまま流用しづらい。ここでは目的の異なる3パターンを示す。いずれも公式仕様の命令とパラメータだけで構成している。

1. 出力フォーマットを固定する（分類・抽出タスク向け）

分類や情報抽出では、表現の多様さは不要で、同じ入力に同じ形式で返ることが価値になる。temperatureを下げ、seedを固定し、余計な前置きをstopで断ち切る。

FROM llama3.2

# 出力を安定させる（既定 0.8 → 下げる）
PARAMETER temperature 0.2
# 同じ入力で同じ出力を再現できるようにする（既定 0）
PARAMETER seed 42
# 長い前置きを防ぐ（既定 -1 = 無限生成）
PARAMETER num_predict 256

SYSTEM """
あなたは問い合わせ文の分類器です。
入力された文を「見積依頼」「不具合報告」「その他」のいずれか1語だけで出力してください。
説明・前置き・記号を出力してはいけません。
"""

2. 会話例で応答スタイルを教える（MESSAGE）

SYSTEMで指示しても口調が安定しないときは、MESSAGEで会話履歴そのものを焼き込む。公式仕様ではMESSAGE <role> <message>という書式で、複数回書いて会話を組み立てる。使えるroleは3種類だ。

role	説明
system	SYSTEMメッセージを与える別の方法
user	ユーザーが尋ねたであろう例
assistant	モデルがどう応答すべきかの例

FROM llama3.2

SYSTEM """
社内ヘルプデスクの一次回答を担当します。回答は結論から1〜2文で述べてください。
"""

# 応答の型を会話例で示す
MESSAGE user パスワードを忘れました
MESSAGE assistant 社内ポータルの「パスワード再発行」から手続きしてください。反映まで数分かかります。
MESSAGE user VPNにつながりません
MESSAGE assistant まず有線・無線を切り替えて再接続してください。改善しない場合は情報システム部へ連絡してください。

公式ドキュメントの例（MESSAGE user Is Toronto in Canada? → MESSAGE assistant yes の往復）と同じ構造だ。指示文を増やすより、望ましい応答を2〜3往復示すほうが型が伝わりやすい場面は多い。

3. 手元のGGUFファイルを取り込む

Ollamaライブラリに無いモデルを使う場合は、GGUFファイルをFROMで直接指定する。パスは絶対パス、またはModelfileからの相対パスだ。

FROM ./models/your-model-q4_k_m.gguf

PARAMETER num_ctx 8192
PARAMETER temperature 0.7

SYSTEM """
日本語で簡潔に回答してください。
"""

取り込んだモデルの応答が途中で止まらない、あるいは応答の後ろに余計な発話が続く場合は、そのGGUFが想定するチャットテンプレートとstopが設定されていないことを疑う。近い系統のモデルでollama show --modelfileを実行し、TEMPLATEとPARAMETER stopの書き方を確認して合わせる。

ADAPTER・LICENSE・REQUIRESの実際の書き方

使用頻度は低いが、配布やLoRA適用の場面では必要になる命令だ。公式仕様に沿った書式は次のとおり。

ADAPTER（LoRAアダプタの適用）

FROM llama3.2
ADAPTER ./ollama-lora.gguf

Safetensor形式のアダプタも指定できる（ADAPTER <path to safetensor adapter>）。対応アーキテクチャはLlama（Llama 2 / 3 / 3.1）、Mistral（Mistral 1 / 2 / Mixtral）、Gemma（Gemma 1 / 2）。公式は「ベースモデルがアダプタのチューニング元と異なる場合、挙動は不安定になる」と明記しているため、FROMで指定するベースは必ず揃える。

LICENSE・REQUIRES（配布時に効く）

FROM llama3.2

LICENSE """
Apache License 2.0
"""

# このモデルが必要とするOllamaの最小バージョン
REQUIRES 0.14.0

REQUIRESには有効なOllamaバージョン（例: 0.14.0）を書く。新しい機能に依存するModelfileを配布する際、古いOllama環境で不可解な失敗が起きるのを防げる。社内で配る場合ほど効いてくる指定だ。

チームでModelfileを運用するときの実務

Modelfileの利点は、モデルの挙動がテキストファイル1枚に固定されることにある。実行時オプションで都度指定する運用と比べたときの差はここに出る。

• Gitに載せる：Modelfileはプレーンテキストなので差分が読める。「なぜtemperatureを0.2にしたのか」を#コメントで併記しておけば、パラメータ変更のレビューが成立する
• モデル名に用途とバージョンを入れる：ollama createの第1引数はそのまま呼び出し名になる。helpdesk-v2のように用途＋世代が分かる名前にしておくと、複数モデルを併用する環境で取り違えが減る
• ベースモデルのタグを固定する：FROM llama3.2のようにタグを省くと、環境によって指すものが変わりうる。再現性が要る場面では明示的なタグで固定する
• 公式仕様上の細かい前提：Modelfileは大文字小文字を区別しない。また命令の順序は自由で、FROMを先頭に書くのは読みやすさのための慣例だと公式は説明している。チーム内で書式を揃えるときの根拠になる

Ollama Modelfileに関するよくある質問

Modelfileはどこに置けばよいですか？

置き場所に決まりはありません。任意のディレクトリにModelfileとして保存し、ollama create <モデル名> -f ./Modelfileのように-fでパスを渡します。ただしFROMでGGUFやSafetensorsを相対パス指定する場合、その基準はModelfileの場所になります。

既存モデルのModelfileを見ることはできますか？

できます。ollama show --modelfile llama3.2のように実行すると、そのモデルのFROM・TEMPLATE・PARAMETERの定義が出力されます。TEMPLATEやstopはモデル固有のため、自作する前に元の定義を確認するのが確実です。

temperatureやnum_ctxの既定値はいくつですか？

公式ドキュメントではtemperatureが0.8、num_ctxが2048、top_kが40、top_pが0.9、repeat_penaltyが1.1、repeat_last_nが64、num_predictが-1（無限生成）と定義されています。

Hugging FaceのGGUFファイルをOllamaで使えますか？

使えます。FROM ./ollama-model.ggufのように、GGUFファイルを絶対パスまたはModelfileからの相対パスで指定してください。

Modelfileでstopを設定しないとどうなりますか？

ストップシーケンスは、そのパターンに遭遇したときにLLMが生成を止めて返すためのものです。TEMPLATEを差し替えたのにstopをモデルの特殊トークンに合わせていないと、停止すべき箇所で止まらず、応答の後ろに余計なテキストが続く原因になります。

まとめ――Modelfileの書き方の要点

ModelfileはOllamaでカスタムモデルを定義する設計図であり、書式は「命令＋引数」の1行単位という単純な構造だ。要点を整理する。

• 必須命令はFROMのみ。他の7命令（PARAMETER / TEMPLATE / SYSTEM / ADAPTER / LICENSE / MESSAGE / REQUIRES）は任意
• FROMは「既存モデル」「Safetensorsディレクトリ」「GGUFファイル」の3通り。パスは絶対パスかModelfileからの相対パス
• PARAMETERは既定値から動かす理由が言えるものだけ書く。num_ctxは既定2048、temperatureは既定0.8
• TEMPLATEはGoテンプレート構文でモデル固有。差し替えるならstopも対で設定し直す
• ビルドはollama create <名前> -f ./Modelfile、実行はollama run <名前>
• 自作前にollama show --modelfile <モデル>で既存定義を読むのが最短

どのベースモデルを選ぶかについてはOllamaモデル選定ガイド、Ollama自体の導入手順はOllama導入ガイド、日本語での利用はOllamaで日本語モデルを使うを参照してほしい。