Ollama Modelfile パラメータ徹底解説：専用カスタムモデルを作る完全ガイド

2026-06-08 更新：Ollama 公式 Modelfile ドキュメントで命令一覧を再確認しました——命令は 7 つ（FROM / PARAMETER / TEMPLATE / SYSTEM / ADAPTER / LICENSE / MESSAGE、REQUIRES は存在しません）。入門リンクを修正し、同系列の関連記事を追加しました。

前回の記事でモデルを動かす方法を説明しましたが、ずっと気になっていた問題があります——回答がブレすぎるのです。

どう言えばいいでしょう。llama3.2 に簡単なコードの質問をすると、3行の簡潔な答えをくれることもあれば、論文を書いてくることもあります。温度パラメータを 0.8 にすると「創意あふれる発揮」を始め、0.1 にすると今度は教科書を暗唱するように硬直してしまう。さらに厄介なのは、毎回の対話で system prompt を設定し直さなければならず、コピペにうんざりすることです。

その後、Ollama に Modelfile というものがあると知りました。ありていに言えば、モデルに「性格の履歴書」を書いてあげるようなもの——一度設定すれば永続的に有効です。この記事では、自分がハマった落とし穴とチューニングの経験を整理しました。10個のコア パラメータのチューニング提案と、そのまま使える4つの実戦テンプレートを含みます。

まだ Ollama を入れたことがないなら、まず Ollama 入門ガイド を読むのをおすすめします。この記事は応用編で、ollama run がすでに使えることを前提にしています。

一、Modelfile とは何か、なぜ必要なのか

Modelfile はモデルの「設定ブループリント」のようなもので、Dockerfile の概念とよく似ています——どのモデルをベースに使うか、どんなパラメータを設定するか、システムプロンプトに何を書くかを Ollama に伝え、それに名前をつけます。以降はこの名前で呼び出すたびに、すべての設定が自動的に有効になります。

要するに、3つの悩みを解決します：

悩み1：毎回設定し直さなければならない

きっとこんな経験があるはずです。ターミナルを開いて ollama run llama3.2、そして system prompt を一文打ち込む。翌日もまた一回。3日目もまた……うんざりしませんか？Modelfile はこうした固定設定を書き込んでしまうので、一度設定すれば一生有効です。

悩み2：出力スタイルが不安定

同じモデルでも、パラメータ設定が違えば出力は天と地ほど変わります。コードアシスタントには安定した出力が必要で、創作には多様な発揮が必要です。「あ、そうだ、このタスクは temperature 0.3 で、あっちは 0.8 だった」と毎回覚えていられるわけがありません——Modelfile があなたの代わりにプリセットを保存しておいてくれます。

悩み3：モデルのバリエーション管理

「コードレビュー版 llama3.2」「ライティングアシスタント版 llama3.2」「JSON出力版 llama3.2」が欲しい。どうしますか？モデルを3つコピーする？その必要はありません。Modelfile で3つの名前付きバリエーションを作ればよく、土台は同じモデルファイルのまま、設定だけが違うのです。

基本の流れはたった3ステップ：

# 1. Modelfile ファイルを作成する
echo 'FROM llama3.2
SYSTEM "你是一个代码审查专家"' > Modelfile

# 2. ollama create で新しいモデルを生成する
ollama create my-coder -f Modelfile

# 3. そのまま実行する
ollama run my-coder

これだけです。続いて、Modelfile の中に何が書けるのかを詳しく説明します。

二、Modelfile の構造と7大ディレクティブ

Modelfile の文法はとてもシンプルです。コメントは #、ディレクティブは大文字の単語で始めます。こんな感じです：

# これはコメントです
FROM llama3.2
PARAMETER temperature 0.8
SYSTEM "你是一个友好的助手"

ファイル全体は2種類のものだけ：コメントとディレクティブです。ディレクティブは全部で7種類です。まず全体像をお見せします：

ディレクティブ	役割	必須か	いつ使うか
FROM	ベースモデルを指定	必須	すべてのファイルに必要
PARAMETER	推論パラメータを設定	任意	温度やコンテキストなどを調整
TEMPLATE	プロンプトテンプレート	任意	対話フォーマットをカスタマイズ
SYSTEM	システムメッセージ	任意	役割と振る舞いを設定
ADAPTER	LoRA アダプタを読み込む	任意	モデルのファインチューニング時
LICENSE	ライセンス表記	任意	モデルを公開するときに必要
MESSAGE	対話履歴をプリセット	任意	few-shot 例

正直なところ、日常的な使用の90%は FROM、PARAMETER、SYSTEM のこの3つだけで足ります。それ以外は具体的なニーズに出会ったときに見ればよいでしょう。

FROM ディレクティブの3つの使い方

FROM は唯一必須のディレクティブで、3つの書き方があります：

書き方1：モデル名を使う（最も一般的）

FROM llama3.2
FROM llama3.2:3b
FROM mistral:latest

Ollama がサポートするモデル名をそのまま使えばOKです。コロンの後ろはバージョンタグで、書かなければデフォルトで latest になります。

書き方2：ローカルの GGUF ファイルを使う

FROM ./my-model.gguf

別の場所から GGUF 形式のモデルファイルをダウンロードした場合は、直接そこを指定できます。

書き方3：Safetensors ディレクトリを使う

FROM ./my-safetensors-dir

このケースは比較的まれで、たいていは Hugging Face からダウンロードしたモデルの元の形式です。

さて、基本構造の説明は終わりました。続いては本題——PARAMETER パラメータです。

三、PARAMETER パラメータ徹底解説

このパートは記事全体で最も実用的な部分です。自分がパラメータ調整でハマった落とし穴をすべて整理し、そのまま写せる設定表をお渡しします。

まず完全なパラメータ一覧を見てみましょう：

パラメータ	デフォルト値	型	何に使うか	どう調整するか
temperature	0.8	float	ランダム性を制御。高いほど「奔放」になる	コード 0.3、創作 1.0
num_ctx	2048	int	コンテキストウィンドウのサイズ	長文は 4096〜8192
top_k	40	int	確率が最も高い K 個の単語からのみ選ぶ	出力が乱れない限り基本そのまま
top_p	0.9	float	核サンプリング。多様性を制御	temperature と組み合わせて使う
min_p	0.0	float	確率が低すぎる単語を除外する	高品質な出力には 0.05
seed	0	int	乱数シードを固定し、出力を再現する	テスト時は 42 や固定値に
stop	なし	string	これを見たら生成を停止する	複数の stop を重ねられる
num_predict	-1	int	最大出力長。-1 は無制限	出力を制限するなら 100〜500
repeat_penalty	1.1	float	繰り返しの内容にペナルティを与える	長文生成では 1.5 まで上げる
repeat_last_n	64	int	直近 N 個の単語が重複していないか検出	repeat_penalty と組み合わせて

以下、最も重要なパラメータをいくつか取り上げて詳しく説明します。

temperature：創造性 vs 安定性

これは最も理解しやすいパラメータです。temperature が高い（たとえば 1.0）と、モデルは「自由に羽ばたき」、確率は低いけれどより創造的な単語を選びます。temperature が低い（たとえば 0.1）と、モデルは保守的になり、確率が最も高い単語だけを選ぶので、出力がより安定します。

llama3.2 が異なる temperature で同じ質問に答えるときの違いをテストしてみました：

問：Python でファイルを読み込むには？

• temperature 0.1：教科書のような出力で、最も標準的な答えだけ
• temperature 0.5：「エンコーディングに注意」など実用的なヒントを少し補足する
• temperature 0.8：場面ごとの異なる方法に触れ、例まで挙げることがある
• temperature 1.0：回答が千差万別で、ときに話題から逸れる

私の経験：

• コードを書く、技術的な質問応答：0.3 前後で安定させる
• 創作、ブレインストーミング：0.8〜1.0 で意外性を出す
• JSON 出力、固定フォーマット：0.1〜0.2 で正確さを出す

num_ctx：コンテキストウィンドウ

このパラメータは、モデルがどれだけの内容を「覚えていられるか」を決めます。デフォルトは 2048 トークンで、だいたい漢字 1500〜2000 文字くらいです。

長い記事を読ませて要約させたい？2048 では足りないかもしれません。長く対話していたのに、突然前の内容を忘れてしまう？おそらく num_ctx が小さすぎるのです。

重要な注意：num_ctx を大きくすると、より多くのメモリを消費します。llama3.2 をテストしたとき、num_ctx を 2048 から 8192 に上げると、メモリ使用量が倍以上になりました。マシンのメモリが 8GB しかないなら、4096 くらいがちょうどよいでしょう。

私の経験：

• 短い対話、簡単な質問応答：デフォルトの 2048 で十分
• コードレビュー、技術的な議論：4096 が快適
• 長文処理、小説執筆：8192（メモリが足りる前提）

stop：停止シーケンス

このパラメータはとても便利です——モデルに「これを見たら止まれ」と伝えます。

たとえばモデルに JSON を出力させるとき、余計なおしゃべりが多くなるのを心配するなら：

PARAMETER stop "\n\n"
PARAMETER stop "```"

モデルは2つの改行やコードブロックの記号を見ると停止し、出力がよりすっきりします。

stop は複数重ねられます。これを知らない人は多いです。

repeat_penalty：おしゃべり防止

モデルには悪い癖があります：同じ文を繰り返しがちなのです。repeat_penalty はその繰り返しの内容にペナルティを与えるためのものです。

デフォルト値は 1.1 ですが、これでは足りないと感じています。長文を書かせるときは、たいてい 1.3〜1.5 に設定し、「先ほど述べたように」「以上をまとめると」といった冗長な表現を効果的に減らします。

場面ごとのパラメータ比較表

よくある4つの場面の最適設定をまとめました。そのまま写して使えます：

場面	temperature	num_ctx	その他パラメータの提案
コードアシスタント	0.3	4096	stop ”```”, seed 42（再現しやすく）
創作	1.0	2048	top_p 0.95, repeat_penalty 1.5
技術的な質問応答	0.5	4096	min_p 0.05（低品質な単語を除外）
JSON 出力	0.1	2048	stop “\n\n”, stop ”```”

ここまで読めば、各パラメータのイメージがつかめたはずです。続いては実戦編——そのまま使える4つの Modelfile テンプレートをお渡しします。

四、実戦ケース：4つの完全な Modelfile

理論は終わりました。さっそくコードを見ましょう。この4つのテンプレートはどれも実際にテスト済みで、コピペすればそのまま実行できます。

ケース1：ロールプレイ——猪八戒アシスタント

これは私が作った面白い小さなモデルで、猪八戒の話し方を真似ることに特化しています：

# 猪八戒助手 Modelfile
FROM llama3.2

SYSTEM """你是西游记中的猪八戒，说话风格要幽默、接地气。
回答问题时：
- 偶尔抱怨师傅太唠叨
- 提到吃的会很兴奋
- 用"俺老猪"自称
- 遇到困难会说"散伙算了"""

PARAMETER temperature 0.8
PARAMETER num_ctx 2048

なぜこう設定するのか：

temperature を 0.8 にすることで、猪八戒の話し方により「個性」を持たせ、硬直しすぎないようにします。SYSTEM には具体的な振る舞いのルールを書きました——食べ物に触れると興奮する、「俺老猪」と自称する——こうした細部が、キャラクターをより生き生きとさせます。

使い方：

ollama create pig-bajie -f Modelfile
ollama run pig-bajie

「プログラミングを上達させるには？」と聞いてみて、どう答えるか試してみてください。

ケース2：専門アシスタント——Python コードレビュー

これは私が日常業務で使っている設定で、コードレビューに特化しています：

# Python 代码审查助手 Modelfile
FROM llama3.2:3b

SYSTEM """你是资深 Python 开发者，审查代码时关注：
1. 类型安全——是否有潜在的类型错误
2. 异常处理——边界情况是否覆盖
3. 性能瓶颈——有没有不必要的循环或重复计算
4. 安全隐患——敏感数据是否暴露

回复格式：
问题 → 影响 → 建议 → 代码示例"""

PARAMETER temperature 0.3
PARAMETER num_ctx 8192
PARAMETER seed 42

なぜこう設定するのか：

temperature 0.3 は出力の安定を保証します——コードレビューに「創意の発揮」は不要です。num_ctx を 8192 にするのは、コードファイルが非常に長くなることがあるからです。seed 42 は再現のため——同じ質問に同じ提案を返すので、比較テストに便利です。

使用効果：数百行の Python コードを投げ込むと、「問題→影響→提案→例」のフォーマットに従って、明快なレビューレポートを返してくれます。

ケース3：構造化出力——JSON フォーマット

モデルの出力を他のプログラムに渡す必要があるなら、JSON フォーマットが最も便利です：

# JSON 输出助手 Modelfile
FROM llama3.2

SYSTEM """你的输出必须是合法的 JSON 格式。
分析结果格式：
{"result": "分析内容", "confidence": 0-100, "tags": ["标签1", "标签2"]}

不要输出任何其他内容，不要加代码块标记。"""

PARAMETER temperature 0.1
PARAMETER num_ctx 2048
PARAMETER stop "\n\n"
PARAMETER stop "```"

MESSAGE user 分析这段代码的安全风险
MESSAGE assistant {"result": "存在 SQL 注入风险，用户输入未过滤", "confidence": 85, "tags": ["安全", "SQL"]}

なぜこう設定するのか：

temperature 0.1 は出力を最も安定させるため——JSON フォーマットは少しのズレも許されません。stop パラメータは改行とコードブロックの記号を除外し、モデルが余計な内容を出すのを防ぎます。MESSAGE 部分は1つの few-shot 例です——「出力はこんなふうに」とモデルに教えています。

この設定は自動化フローで使っています：エラーログをモデルに投げると、構造化された分析結果を出力し、それをプログラムが自動で処理します。

ケース4：長コンテキスト——ドキュメント要約

長い記事を処理するときは、コンテキストウィンドウを十分に大きくする必要があります：

# 文档摘要助手 Modelfile
FROM llama3.2

SYSTEM """你是文档摘要专家，输出要求：
- 总结不超过 5 个要点
- 每个要点不超过 50 字
- 先提取核心观点，再补充细节
- 使用中文输出"""

PARAMETER temperature 0.5
PARAMETER num_ctx 8192
PARAMETER num_predict 300

なぜこう設定するのか：

temperature 0.5——要約は安定が必要ですが、硬直しすぎてもいけません（低すぎると要約が単なる箇条書きになってしまう）。num_ctx 8192 で長文を確実に処理できます。num_predict 300 は出力長を制限します——要約が原文より長くなってはいけません。

私はこの設定で技術記事を処理しています：3000 字の記事を投げ込むと、5つの要点を各50字以内で返してくれるので、読むのがずっと効率的になります。

まとめ

この4つのテンプレートはよくあるニーズをカバーしています。自分の必要に応じて SYSTEM の内容を変えたりパラメータを調整したりしてかまいません——どうせ Modelfile を直したらもう一度 ollama create するだけで、デバッグコストはとても低いのですから。

五、TEMPLATE と MESSAGE の応用

前のケースはどれも TEMPLATE を使っていません。このパラメータは「応用機能」に属するからです——対話フォーマットをきめ細かく制御する必要があるときに初めて使います。

TEMPLATE の Go template 文法

Ollama は Go の template 文法を使い、3つの重要な変数があります：

• {{ .System }} —— あなたの SYSTEM の内容
• {{ .Prompt }} —— ユーザー入力
• {{ .Response }} —— モデルの出力（出力フォーマットの定義に使う）

簡単な例：

FROM llama3.2

TEMPLATE """{{ .System }}

用户问题：{{ .Prompt }}

回答：{{ .Response }}"""

SYSTEM "你是一个技术专家"

この TEMPLATE は対話の構造を定義しています：まず SYSTEM の内容を置き、次にユーザーの質問、最後にモデルの回答です。

正直なところ、ほとんどの場合 TEMPLATE をカスタマイズする必要はありません——Ollama のデフォルトテンプレートで十分です。ではいつ変える必要があるのでしょうか？

場面1：他のツールと連携する

Ollama をあるチャットシステムに接続したとき、そのシステムが特定の入力フォーマットを要求する。このとき TEMPLATE で適合させます。

場面2：特殊な対話フォーマット

対話に「プレフィックス」を付けたい、たとえば各文の冒頭に [AI] や [USER] を付けたいなら、TEMPLATE で実現できます。

MESSAGE：対話履歴をプリセットする

MESSAGE の役割は「モデルにいくつかの例を見せる」ことです。先ほどの JSON 出力のケースで使いました：

MESSAGE user 分析这段代码的安全风险
MESSAGE assistant {"result": "存在 SQL 注入风险", "confidence": 85}

これはモデルに「ユーザーがこういう質問をしたら、こう答えるべきだ」と伝えるのに相当します——few-shot 学習の概念です。

複数の対話履歴をプリセットすることもできます：

MESSAGE user 你好
MESSAGE assistant 你好，有什么我可以帮你的？
MESSAGE user 天气怎么样
MESSAGE assistant 我不知道实时天气，建议你查看天气应用。

モデルは起動時にこれらの対話を「覚えて」おり、その後の新しい対話はこのスタイルを引き継ぎます。

モデルの Modelfile を確認する方法

あるモデルの Modelfile がどう書かれているか見てみたいなら、このコマンドが使えます：

ollama show --modelfile llama3.2

出力内容はとても長く、モデルのデフォルト設定がすべて含まれています。コピーして修正すれば、あなたのカスタム版を作れます。

このコマンドは特に便利です——効果の良いモデル（たとえば誰かが共有したカスタム版）を見つけたとき、ollama show でその Modelfile をエクスポートして、相手がどう設定しているかを学べます。

六、よくある問題と落とし穴対策ガイド

パラメータ調整というのは、落とし穴にハマるのが避けられない道のりです。出会った典型的な問題をいくつか整理して、地雷を避けてもらいます。

問題1：temperature を低くしすぎて、出力が暗唱のよう

temperature は低いほど良いと思っている人がいます——出力が安定するから、と。私も最初はそう思って、コードアシスタントの temperature を 0.05 にしました。

結果はどうだったか？モデルは標準解答を暗唱するように答え、まったく柔軟性がありませんでした。「Python でファイルを読むには」と聞くと、3つの方法をくれますが、どれも教科書どおりの標準的な書き方で、実用的なヒントはまったくありません。

私の教訓：temperature は低いほど良いわけではありません。コードレビューは 0.3 で十分で、0.2 を下回ると硬直します。正確な出力（JSON など）が欲しいなら確かに低くすべきですが、日常の対話ではその必要はありません。

問題2：num_ctx を大きくしすぎて、メモリが溢れた

あるとき思いつきで、num_ctx を 16384 に設定しました——超長文を処理させたかったのです。数分実行したところ、システムが激しく swap を始め、マシン全体が固まって動かなくなりました。

私のマシンは 16GB メモリしかありません。llama3.2:3b 自体が約 2GB を占め、num_ctx を 2048 から 16384 に上げると、メモリ使用量が一気に 8GB 超に跳ね上がりました。さらに他のプログラムも加わると……

教訓：num_ctx は無闇に上げてよいものではありません。自分のメモリ状況に合わせましょう：

• 8GB メモリ：num_ctx は最大 4096
• 16GB メモリ：num_ctx は 8192 まで可能
• 32GB 以上：ようやく 16384 を試せる

問題3：SYSTEM と MESSAGE を混同する

この2つのディレクティブは役割が異なり、混同しやすいです：

• SYSTEM：永続的に有効な役割設定で、毎回の対話に付いてくる
• MESSAGE：プリセットの対話履歴で、few-shot 例に相当する

例を挙げます：モデルにコードレビュー専門家を演じさせたいなら、SYSTEM に役割定義を書き、MESSAGE にいくつかの問答例を書きます。

多くの人は SYSTEM だけ書いて MESSAGE を書かず、結果としてモデルは「自分がコードレビュー専門家であること」は分かっても、具体的な質問にどう答えればよいか分かりません。MESSAGE の例をいくつか加えると、出力の質が明らかに良くなります。

問題4：作成後に更新したい場合

Modelfile で作成したモデルの設定を変えたいときはどうするか？

簡単です——もう一度 ollama create で同名上書きします：

# 最初の作成
ollama create my-coder -f Modelfile

# 設定を変えたい？ Modelfile を修正してもう一度実行する
ollama create my-coder -f Modelfile

Ollama は同名モデルをそのまま上書きするので、先に削除する必要はありません。もちろん、上書きしたくないなら、名前を変えればOKです：

ollama create my-coder-v2 -f Modelfile

問題5：他人の Modelfile を再現する方法

誰かが共有したカスタムモデルの効果が良くて、その設定方法を学びたいなら：

# まずそのモデルを取得する
ollama pull someone-elses-model

# その Modelfile をエクスポートする
ollama show --modelfile someone-elses-model > learned-modelfile

# 確認、学習、修正する
cat learned-modelfile

このコマンドはよく使います——コミュニティのカスタムモデルから、パラメータチューニングのコツをたくさん学べます。

関連記事

• Ollama 入門ガイド：ローカル LLM を手早く動かす
• Ollama API 実践：OpenAI 互換の呼び出し
• Ollama GGUF 量子化 完全ガイド

まとめ

ここまで長々と話してきましたが、Modelfile のコアロジックは一言です：設定を固定化し、毎回の手動調整を避ける。

今すぐできる3つのことをお渡しします：

1. ロールプレイモデルを作る

猪八戒アシスタントのテンプレートを試すか、好きなキャラクター（ドラえもん、アイアンマンなど）に変えてみましょう。何ラウンドか対話を実行して、temperature パラメータが出力スタイルに与える影響を体感してください。

2. 異なるパラメータの出力を比較する

同じ質問を、temperature 0.3 と 0.8 でそれぞれ一度ずつ実行し、出力にどんな違いがあるか見てみましょう。この実験は何度もやりましたが、毎回新しい発見があります。

3. よく使う場面を1つ見つける

コードレビュー、ドキュメント要約、創作——日常で使う場面を1つ選び、上のテンプレートを自分の必要なバージョンに作り替えましょう。何ラウンドかデバッグすれば、あなた専用のカスタムモデルができあがります。

次回は Ollama の API 連携を説明します——ローカルモデルをどうやって自分のプログラムに接続し、OpenAI 互換インターフェースで呼び出すか、です。Modelfile を設定しておけば、API 呼び出しはより安定します——パラメータをコード内で渡す必要がなく、カスタムモデルをそのまま使えばよいのです。

質問があればコメントしてください。私がハマった落とし穴が、いくつかの地雷を避ける助けになるかもしれません。